我用 AI 从零做了一个健身训练管理 App：从需求到上线的完整复盘

目录

1. 缘起：为什么不用现成的健身 App
2. 需求拆解：把"我想要"翻译成"它能做"
3. 数据建模：训练数据比想象中更有层次
4. 与 AI 协作：我是怎么分工的
5. 交互设计：训练中记录，拼的是"打断成本"
6. 三个让我印象深刻的坑
7. 哪些地方必须由我亲自把关
8. 结论：AI 是执行力，人是判断力

1. 缘起：为什么不用现成的健身 App

我坚持每周健身三次，记录"练了什么、重量、组数、次数"。需求听起来很简单，但市面上的 App 总差一点：

• 免费版只允许记录三个自定义动作，剩下的必须付费；
• 数据默认同步到云端，我并不知道它拿这些数据干嘛；
• 主打社交/教练/课程推荐的功能，让一个只想"本地记个账"的人无所适从。

于是我给了自己一个任务：做一个"记健身训练日"的工具，规则只有三条——数据 100% 本地、一次训练记录不超过 10 秒、不要社交不要课程商城。

2. 需求拆解：把"我想要"翻译成"它能做"

这是我和 AI 协作的第一个环节，也是我后来认为决定项目成败的环节。

我最初的需求只有一句：“做一个健身训练记录 App。” AI 生成的版本能用，但只是一堆通用的功能列表。后来我把它拆成了可验收的颗粒：

心得：AI 擅长把"明确的细粒度需求"变成代码，但不会替你判断"你想要什么"。把需求拆成"可验收的任务清单"，是和 AI 协作的第一性原理。我把上面这张表格直接粘给 AI，它产出的页面一次通过率高了很多。

3. 数据建模：训练数据比想象中更有层次

"记录训练"听起来就是存几条数字，但真正建模时才发现它有两个层级：

训练日 WorkoutDay
 ├─ id、日期、备注（如"练胸"）
 └─ 动作条目 ExerciseEntry
     ├─ 动作名称（如"杠铃卧推"）
     ├─ 组数据 Sets[]
     │   ├─ 重量（kg）
     │   ├─ 次数
     │   └─ 是否完成
     └─ 全身照/备注（可选）

三个设计决策让我避开了后续返工：

1. "训练日"和"动作条目"必须分层。如果把它拍成扁平的"一条训练记录"，那么"这个动作练了 5 组"就没法表达。用训练日 → 动作 → 组 三层结构，几乎所有训练场景都能覆盖。
2. 动作名称存文本，不做硬字典。有人写"卧推"，有人写"bench press"，还有人写"杠铃卧推"。做成固定下拉列表会让人抓狂。我的方案：提供高频动作建议列表（点击填充），但允许用户输入任意文本——建议不强制。
3. 重量单位、完成与否这些"细节"别省略。一开始我没记录"是否完成组"，后来发现"练力竭了没"对判断训练强度非常重要。这个字段后来补进去，但已经动了数据结构——教训是第一版就把元数据字段留够。

4. 与 AI 协作：我是怎么分工的

整个开发我走的流程是：

梳理需求清单
   ↓
让 AI 产出完整页面（约束：单 HTML、本地存储、无构建）
   ↓
让 AI 自己 review 代码并列出潜在缺陷
   ↓
让它修复缺陷并跑语法校验
   ↓
让它按设计方向重构 UI（只动样式不动逻辑）
   ↓
让它基于真实代码沉淀一篇技术博客

其中"让 AI 自己 review"是最有价值的一步。它在自查时主动指出：

用 new Promise() 但没 await，后续代码会在图片/数据加载完成前执行，导致读取到空值。

这类异步时序问题正是我自己最容易忽视的。AI 的自我审查其实是在执行一套反模式检查，而我只需要给一句"检查一下有没有潜在问题"。

换个角度说：AI 不会主动找 bug，但只要你问"有没有问题"，它的 return value 往往超出预期。

5. 交互设计：训练中记录，拼的是"打断成本"

健身场景有一个特殊约束：用户手里可能拿着哑铃。所以交互设计的唯一目标就是——把屏幕上的操作次数压到最低。

我的最终交互流程：

打开 App → 日期自动定位今天 → 点击"开始训练"
→ 右侧面板显示最近动作（一键添加）
→ 输入重量 + 次数（默认复制上一组）
→ 回车保存 → 自动聚焦下一组

几个关键细节：

• "上一组"是默认值。每组重量/次数默认取上一组的值，用户只需要在变化时改一下。这比每次重新输入省了 80% 的击键。
• 当前训练节次的进度条常驻。完成了多少组、总容量（重量×次数总和）实时更新，有正反馈。
• "结束训练"之前不弹任何确认。训练中被打断离开，数据已经逐步写入，不会丢。

心得：一个"训练记录工具"的核心指标不是功能数量，而是"一次记录需要多少次交互"。每次省一次点击，就是在留住真实使用场景。

6. 三个让我印象深刻的坑

坑一：异步时序问题（最经典，必须说）。 如上文，初始化数据时用了 new Promise 但没等待加载完成，导致页面先渲染空列表，再在数据来后崩溃。修复方式是用 await 明确"等数据就绪再渲染"，并把初始化流程显式分成"加载 → 渲染 → 可交互"三个阶段。

坑二：金额/重量这类数值,别直接存浮点。 虽然健身重量一般是整数，但一旦用小数（如 2.5kg 的哑铃片），0.1 + 0.2 的问题就会浮现。我统一把重量以"克"为整数存，展示时再除以 1000。数据层面永远整数运算，从根上消灭精度误差。

坑三：导出/备份要去重。 支持"导出备份 JSON + 重新导入"后，出现了一个新问题：如果用户覆盖导入，旧数据会和新数据并存。我给每条记录生成一个稳定唯一键（日期+动作+时间戳），导入前对比去重。任何"有导入就有重复"的功能，都必须把幂等性设计进去。

7. 哪些地方必须由我亲自把关

AI 产出的东西，我最后做了几个"人肉 review"：

1. 隐私边界：确认没有第三方统计脚本、没有向任何域名发起网络请求。本地优先的产品，隐私是底线，必须肉眼确认。
2. 异常处理：AI 生成的代码"正常路径"很漂亮，但"用户点得很快"“双击”"空数据"这些边缘场景有时想不全。我会自己跑一轮疯狂点击测试。
3. 审美判断：设计方向（比如选 Linear 风格还是拟物风格）、配色、动效合不合适，AI 只能给方案，做最终决策的还是我。
4. 验收标准：功能做完了不等于需求完成。我会用最初的需求清单逐条勾对，AI 不会替你做这件事。

一句话：AI 交出了不错的执行稿，我是那个"最后拍板质量的人"。

8. 结论：AI 是执行力，人是判断力

做完这个项目，我对"用 AI 开发"这件事的认知有了明确更新：

• AI 擅长：把明确的细粒度需求翻译成可运行代码、执行反模式自查、按要求重构、生成高质量文档；
• 人需要做：需求拆解、验收标准定义、隐私与安全把关、设计方向的最终拍板。

换句话说，AI 把"怎么做"的效率提升了 10 倍，但"做什么、做到什么程度、什么东西绝对不能妥协"仍然是人的职责。

如果你也想用 AI 做一个小工具，我的建议是：从"本地优先、单文件、不依赖后端"的小需求开始，把它的输出当作"初稿而不是成品"，主动让它自查，你会惊讶于它的下限，并更清醒地意识到上限在哪里。