📊 ulives vs 人升 — 为什么我们从零重建
人升（LifeUp）是我们在 2018 年推出的一款开创性游戏化效率应用，而 ulives 是其官方精神续作——从头重建，面向多平台未来。本文详细说明两者的差异、重建的原因，以及两款应用各自的发展方向。
快速对比
| 人升（LifeUp） | ulives | |
|---|---|---|
| 平台 | 仅 Android | iOS · iPadOS · macOS · Android |
| 技术栈 | 原生 Android（Java / Kotlin） | KMP + SwiftUI / Jetpack Compose |
| 发布时间 | 2018 年 | 2025 年 |
| 定价模式 | 付费下载¹ | 免费下载 + 高级功能订阅 |
| UI 风格 | Material Design 2 + 3（双轨维护） | 原生平台设计（SwiftUI / Compose） |
| 跨平台数据同步 | 无计划 | 全平台统一数据格式 |
| 在线功能 | 世界模块（基础功能） | 暂未上线——计划推出在线素材库 |
| API / 扩展性 | ✅ Open API + 开源 SDK² | ❌ 暂未提供（需设计跨平台方案） |
| 人升数据导入 | — | ✅ 支持 |
| 数据导出 | ✅ 完整导出 | ✅ 完整导出 |
¹ 同时在部分国家/地区通过 Google Play Pass 提供。
² 包含 LifeUp Cloud、LifeUp SDK 和 LifeUp Desktop。
为什么必须重来而非升级
1. 平台锁定
人升完全基于 Android 原生技术（Java，后迁移至 Kotlin）开发。将其移植到 iOS、鸿蒙、桌面端或 Web 端根本不具备可行性——代码库无法复用。要覆盖 Android 以外的用户，全面重写是唯一的路。
2. 技术债务积累
人升早期架构为了快速上线做出了一些务实的取舍：
- 数据库层：选型适合快速原型开发，但在当前规模下已成为性能瓶颈
- 属性系统多次迁移：从 6 个固定属性 → 可自定义 6 个属性 → 完全可自定义属性列表 + 分组功能——每次迁移都在旧代码上叠加新逻辑
- UI 双轨维护：同时支持 Material 2 和 Material 3 两套主题，每次改动都需要双倍的设计和测试工作量
这些是真实存在的问题，但在原地修复意味着几乎要重写大部分应用——还伴随着破坏现有用户数据的持续风险。
3. 早期决策带来的设计约束
人升是在社区反馈中逐步演化出来的，这是优势，但也把许多功能和 UI 模式固化在了产品里。在原地改动往往意味着破坏现有数据、工作流，或两者兼有：
- UI 风格难以大改 — 我们仍同时完整维护 Material 2 与 Material 3 两套主题，几乎每个界面都有两份实现；视觉或结构上的 overhaul 意味着每次改动都要双倍的设计、开发与测试
- 任务重复的底层存储 — 重复任务按每次 occurrence 生成实例克隆，而非统一的「周期」模型；这套 schema 与历史记录、奖励、统计、导出深度耦合——要重设计几乎会牵动所有模块
- 金币作为一等公民 — 金币不只是另一种物品，它有独立的存储、界面与 API；商店、合成、仓库都围绕这种扁平货币搭建，因此彼此显得割裂
- 内置奖励规则（计步换力量经验值、点赞兑换、固定系统成就）— 早期「App 定制规则」的产物，与后来演化的完全自定义理念不协调
- 分散的历史视图 — 任务历史、金币流水、计时记录、仓库等散落在不同页面，数据结构也不统一
- 世界模块机制 — 早期的在线实验，自带服务端逻辑；我们维持基础功能，但要扩展就需要重构从未为规模化设计的成本与数据模型
- 多种登录方式 — Google、邮箱、手机号等渠道在多年迭代中陆续叠加；账号绑定、找回、会员换绑逻辑围绕各路径生长，每次动认证或客服都会增加维护负担
这些不是零散的 bug，而是多年真实用户数据与使用习惯写进了产品。逐个重构，本质上仍等于重写大部分应用。
4. 无法做减法
人升的每个功能都有用户在使用。原地移除或重新设计任何功能都会破坏某些用户的工作流。从零开始给了我们重新抉择的自由——审慎地选择哪些功能值得延续。
ulives 带来的新功能
全新功能（仅 ulives）
| 功能 | 说明 |
|---|---|
| 倒数日 | 在任务旁跟踪重要日期和里程碑 |
| 多档案切换 | 在完全独立的配置之间切换（如「工作」vs「个人」） |
| 清单胶囊 | 将任务按可折叠胶囊分组，组织更清晰 |
| 统一活动时间轴 | 所有历史记录集中在一个可滚动页面——任务完成、奖励兑换、计时记录等 |
| 货币融入物品系统 | 货币不再是一个独立概念——金币就是物品，物品也可以作为货币 |
| 专注模式 | 番茄钟支持灵动岛（实时活动）、iOS 小组件 |
| iPad & macOS 适配 | 为平板和桌面端做了完整的大屏幕适配 |
| iCloud 备份 | 苹果生态无缝备份与恢复 |
| App 图标切换 | iOS 上可切换多种 App 图标 |
| iOS 小组件 | 主屏幕和锁屏小组件，快速查看任务 |
暂未引入的功能
以下人升功能不会立即出现在 ulives 中。我们可能会在后续以优化形式重新引入：
- ATM（复利模拟）
- 物品倒计时
- 系统成就与内置奖励
- 计步兑换属性经验值
- 点赞数兑换奖励
人升的独有优势
尽管年代较久，人升在多个方面仍然具有显著优势：
| 优势 | 详情 |
|---|---|
| Android 端稳定性 | 多年实战打磨，功能成熟稳定 |
| 智能清单 | 高级任务过滤与分组 |
| Open API 生态 | REST API 可编程查询和修改应用内部数据 |
| 开源生态 | LifeUp Cloud（自托管同步）、LifeUp SDK（Java/Kotlin）、LifeUp Desktop（跨平台桌面伴侣） |
| 自动化联动 | 可与 Tasker、自定义脚本、AI 代理等自动化工具深度集成 |
| 更低的价格 | 多数地区为一次性买断（无订阅） |
| 成熟的功能集 | 各项功能经过多年真实使用场景打磨 |
特别是 API 生态，赋予了人升一个 ulives 尚不具备的「开发者友好」层面。用户已构建了丰富的工作流——通过 Tasker 自动化习惯跟踪、AI 生成任务、自定义数据看板——将人升与其他工具结合使用。
定价模式与商业化
人升和 ulives 是两款独立应用，拥有独立的商店、购买、许可证和数据。将人升备份导入 ulives 不会转移你的人升会员权益。
为什么不能共用一次购买
人升自始至终基于纯 Android 原生技术开发。受单平台限制，人升的定价因此设得足够低——不可能用一次买断覆盖开发者未来所有 App 的维护成本。
海外 Google Play 上，人升永久会员从约 1 美元起，因运营成本多次调整，至今约 4 美元——仍远低于多数同类产品（不少 App 一上线就卖 200–300 元买断，或每月涨几十元）。国内渠道则在上线会员后的约 8 年内，永久会员从约 6 元涨到 29.8 元。人升的收入不足以支撑全职开发，更谈不上 ulives 的跨平台维护与运营。
ulives 是基于跨平台（KMP）技术的全新代码库，由不同团队在全新技术栈上开发——制定人升定价时，ulives 尚不存在。定价综合考虑开发成本、并非完全统一的团队，以及长期可维护性。规划上，ulives 会员权益将面向 iOS、Android、鸿蒙 等平台通用，数据与权益预期互通；但现阶段尚未上线服务端，权益仍依赖各平台自身的内购校验，跨平台兑换前期可能需要联系官方获取平台兑换码，后续会尝试上线服务端与账号系统。
我们也可以让两款 App 会员互通——但那相当于捆绑销售：用人升的低门槛永久会员，就等于顺带买断 ulives。若走这条路，更诚实的做法是从一开始就把人升定价调高，让一次购买覆盖两款 App 的开发与长期维护。我们没有这么做：人升维持 Android 单平台的定价，ulives 单独定价。
人升付费用户没有任何权益损失。 与 ulives 会员不互通，不会回溯或削减人升权益。自开通会员以来，人升已有长达 8 年的维护与功能更新；现有付费用户将继续享有对应权益，我们仍会投入人升的开发与维护——包括近期 MCP 服务器等重大更新。
两款 App 的永久会员定价，都远低于绝大部分同类产品。
Google Play：付费下载
在 Google Play 上，人升采用付费下载，叠加较低门槛的永久会员。双重门槛阻碍了我们触达更多用户，也反向抑制了更新节奏与反馈收集——进一步损害了已有会员的使用体验。
人升还有持续的服务器成本、大量低门槛永久会员带来的人工换绑处理（包括多年前购买的用户找回账号），以及多种登录方式带来的账号找回复杂度——这些都进一步挤占了可用于维护与迭代的精力。
开发之外：被运营与支持挤占的时间
我们是业余时间开发的独立小团队，没有专职客服。邮件回复、授权换绑、反复议价和一对一「售前咨询」，都会直接占用本可用于修 Bug、做功能、发版本的时间——最终影响的是全体用户（包括付费会员）能得到的更新速度。
下面两张截图来自真实记录（个人信息已打码）。大约一个月内，同一位用户向人升支持邮箱发送了大量邮件：反复要求大幅降价甚至免费获取、要求与人升/ ulives 及 Habitica、Do It Now、Skillion 等 App 做详细对比、要求在「证明值得买」之前不愿付费。我们回复过几次，但往来频率和深度很快超出了业余团队能承受的限度，只能停止继续跟进。
ulives Android 上线后收到第一条商店评价时，我们又看到了同一个名字——对早期 alpha 版本打出 1 星，评论为 Ne marche pas bien !（「不好用！」）。
我们写这些不是为了点名批评谁。预算有限、对产品失望，这些感受都可以理解。但当用户期待一个两人业余项目提供持续的一对一咨询、定制折扣和「先证明再购买」式服务时，它与人升和 ulives 的开发时间形成直接竞争。这也是我们强调可持续定价与合理边界的原因之一：让我们能把精力留给产品本身，而不是被不可持续的运营负担拖垮。
国内渠道：免费下载与历史定价
人升起初带有一些理想主义色彩——曾尝试开源免费，但因几乎没有外部代码贡献，最终还是走向了闭源维护。
国内版则起初直接走免费功能路线；上线数年后，因大量用户反馈与维护需要，才逐步推出会员与付费模式。此后约 8 年内，永久会员从约 6 元涨到 29.8 元——不及现在一些 App 一个月的涨幅，也远低于多数长期维护 App 的永久会员定价。因此我们仅对后续部分个性化能力设置付费门槛，并宣称 95%+ 功能免费。
但坦率地说，这套模式并不健康：付费用户获得的权益不对称 → 开发者收益不符合预期 → 无法投入更多维护 → App 体验降级，损害付费会员权益。健康的 App 应该是：合理定价、合理会员权益、合理开发者收益与再投入、再带来合理的运营与用户增长。
甚至 ulives 今天也被这套逻辑反噬：开始有用户质问为什么不能用人升的会员权益、为什么不能 95% 功能免费、为什么自动成就要会员——这进一步让我们确认需要走向更可持续的模式。
上图是 App Store 上的一条真实评价（2026-08-27）。用户的感受可以理解，但也说明：人升长期宣传的「95%+ 功能免费」已内化为用户预期，而这套预期并不适用于一款需要长期跨平台维护的独立产品。
ulives 并未承诺与人升相同的「95%+ 功能免费」比例。两款 App 的免费/付费划分不同，不宜直接套用同一标准评价 ulives 的会员价值。
「95%+ 功能免费」损害的是谁
表面看对用户「友好」，实质上却在持续损害：
- 付费会员：低门槛永久会员叠加大量免费功能，稀释了付费用户的边际价值，难以获得与投入相匹配的体验与更新
- 开发者：收益不足以覆盖维护、服务器、人工客服与跨平台投入
- 产品长期发展：更新放缓、体验降级，最终连付费用户也一起受损
人升所宣称的「95%+ 功能免费」，本质上是对付费会员权益、开发者合理收益与应用长期发展的损害——而非可持续的商业模式。
我们也曾对人升会员做出过退款承诺，初衷是帮助确有需要的用户。但实践后发现，真正使用这项权益的往往并非真正遇到困难的人——而是使用数年后申请「仅退款」，或购买兑换码转卖后再申请退款等情形。这类滥用进一步说明：过度宽松、缺乏边界的权益设计，无法支撑一款需要长期维护的产品。
ulives 以长期可维护性为前提
ulives 的会员划分、功能门槛、定价与跨平台规划，首要考量是长期可维护性——让合理收益能持续投入开发、自动化测试、平台适配与用户支持，而不是复刻人升历史上不可持续的路径。具体包括：
- 全新架构与 KMP 跨平台：基于重新设计的技术架构，核心业务逻辑一次开发、多端共享与互通，各平台保留原生 UI，显著降低重复开发与长期维护成本
- 更轻量的运营负担：人升还承担服务器、人工换绑、多种登录方式的账号找回等长期运营工作；ulives 在架构与产品设计上尽量避免不可持续的重运营路径（现阶段仍依赖各平台内购校验，服务端与账号系统会在产品就绪后逐步上线）
- 可持续的开发与测试投入，避免「改一处、崩一片」的维护困境
- 各平台原生体验，以及后续 Android、鸿蒙版本的交付能力
- 避免重复人升「低门槛 → 低收益 → 低维护 → 全体用户受损」的循环
两款 App 的永久会员定价仍远低于绝大部分同类产品——但 ulives 不会以「95%+ 功能免费」作为承诺或营销口径。
ulives 的开发投入
开发 ulives 投入了大量精力与时间。几乎每一项功能都会先根据用户反馈重新设计、全面打磨，再融入 ulives 的机制——例如智能清单一上线就支持常见内置清单、「我的一天」和自定义智能清单。开发成本并不低，持续消耗的 AI token 与上架打磨也消耗非常多，不太可能跟着人升共享会员，或以同等低价买断开发者。
能力反哺人升
开发 ulives 的过程中，不少功能也反哺回了人升，例如：商店、仓库与合成系统的融合；购买、使用限制等能力的扩充。
两款应用的未来规划
人升：稳定维护
我们承诺在可预见的未来持续维护人升。但方向如下：
- 新功能开发比较受限：只能面向 Android 一端开发，需兼容历史逻辑但缺少全面的自动化测试覆盖，存在 Material 2/3 双轨维护、数据库选型性能劣化等技术债务
- 我们会谨慎开发、更长时间验证，但以 Bug 修复、性能优化、稳定性及现有模块的渐进改进 为主
- 不计划引入新的重大功能模块
- 继续维护 Material 2 和 Material 3 双主题的现有功能对等
- 开源生态（Cloud、SDK、Desktop）将继续可用
ulives：大胆创新
ulives 是我们投入未来的方向：
- 大量自动化测试让我们在修改逻辑时更放心，避免改出大偏差
- KMP 共享数据层——数据层面的改动可接近无缝地在 iOS、Android、鸿蒙及未来可能的 Windows/Linux 桌面端复用
- 各平台原生 UI——iOS 基于 SwiftUI，Android 基于 Compose——迭代更快，也能充分结合系统特性（如 Live Activities）
- 在线功能——计划引入在线素材库、共享模板等社区功能，这些在人升架构下从未可行
数据：导入、导出与连续性
| 能力 | 人升 | ulives |
|---|---|---|
| 导出完整数据 | ✅（数据库 + 媒体文件） | ✅（数据库 + 媒体文件） |
| 导入人升数据 | — | ✅ |
| 跨应用同步 | ❌ | 计划中（统一数据格式） |
如果你是从人升转过来的用户，可以导入你的人升备份文件，在 ulives 中延续使用体验。两款应用都支持完整的快照导出——包括数据库和媒体附件——你的数据永远不会被锁定在一个平台上。
我该选哪个？
| 你的情况 | 推荐 |
|---|---|
| Android 用户，需要 API / 自动化 | 人升——功能成熟丰富 |
| Android 用户，想用最新功能 | ulives 已登陆 Google Play，仍在完善；如需成熟自动化/API 可继续用 人升 |
| iOS / iPad / Mac 用户 | ulives——唯一选择，且为苹果生态深度定制 |
| 多平台用户 | ulives——数据将在所有设备间同步 |
| 人升老用户，感觉被「困在」Android 上 | ulives——导入数据，获得跨平台自由 |
| 预算敏感，仅 Android、追求最低永久会员价 | 人升 |
| 多平台或苹果生态用户 | ulives——需单独购买，长期规划跨平台通用会员 |
| 想免费试用再决定 | ulives |
总结
人升曾经——而且仍然——是一款卓越的应用，在移动端开创了游戏化生产力这一品类。但其仅限 Android 的架构、积累的技术债务和早期设计约束，使其无法演变为一个现代的多平台产品。
ulives 是我们的答案：一次干净的重建，保留了人升的灵魂（深度自定义、RPG 式的成长体系、用户驱动的游戏化），同时解锁了 iOS、iPadOS、macOS 与 Android——共享一个代码库、一种数据格式。
两款应用都将持续运营。 人升负责稳定；ulives 负责创新。