完整实战流程

流程总图

整件事只有两部分：开始前只做一次的准备，和不断转圈的主体。 下面用 1–7 给简化流程编号，完整版有另一套编号，两者在下一节对照。

简化版 1–7 与完整版七阶段

第 7、8 章讲的是完整版。它把同样的事拆成七个阶段，每个阶段配一个现成技能：

① 拷问 → ② 研究（可选）→ ③ 原型（可选）→ ④ 写规格 → ⑤ 拆票 → ⑥ 实现 → ⑦ 审查（含验收）

在这七个阶段之前，第 7 章还有一节「立项六步」，先判断这件事该不该做。 下面是把简化版 1–7 贴到这套编号上——先看对照，不要混用两套编号。

开工之前：选工具、建文件夹、第一次存档

选一个能动手的工具 可选

最理想的是能读写你电脑上文件、能跑命令的 AI 工具， 比如 Claude Code、Cursor、Codex。它们的共同点是：能在项目文件夹里直接动手。 具体选哪个不重要，换工具的成本远低于换方法的成本。

建一个空文件夹

给项目建一个专门的文件夹，比如 D:\我的项目\午饭登记， 然后让 AI 只在这个文件夹里工作。 不要让它在桌面或下载文件夹里乱来，否则你很快会找不到东西。

第一件事：建存档

文件夹建好之后，第一句话就可以是： “帮我把这个文件夹变成一个 Git 仓库，并提交一次空状态。” 这一步花不到一分钟，但从这一刻起你就有了后悔药。 一定要在写任何代码之前做。

第 1 步：把想法问清楚

目标只有一个：把脑子里的“感觉”变成一份写下来的清单。 先用自己的话说想做什么，再要求它像面试官一样，一次只问一个问题。 每个问题都是你后面会返工的地方；答不上来就说“我不确定，你推荐哪个”。

问完让它整理成 spec.md，写清做什么、为什么、明确不做什么。 完整做法见 第 7 章 · 拷问；这里只记住顺序：先问，后写。

第 2 步：定验收标准

动手之前，先拿到一份你能亲手点一遍的清单。 每条写成“打开页面能看到什么”“点一下会发生什么”，不要写“实现了数据持久化”这种你无法验证的话。

清单写进 spec.md。如果一条都点不出来，说明需求还没想清楚。 规格的七段结构见 第 7 章 · 写规格， 审查时怎么对照清单验收见 第 8 章 · 审查。

第 3–5 步：一片一片长大

这是主体。每一片都走同样的五步： 切出最小可跑的一片 → 让它做并说“做完停下” → 你亲手跑 → 通过就存档 → 判断下一片。

切片标准是：窄到一次能做完，完整到能跑起来看到效果。 如果发现切不出来，说明你切得太大了，再切一刀。 完整版的拆票规则见 第 8 章 · 拆票， 实现的五个节拍见 第 8 章 · 实现。

第 6–7 步：收尾与审查

功能都做完，还有两件事。第一，换一个干净会话，让它以代码审查员身份挑错， 重点看安全问题和明显 bug。第二，让它写一份交接文档： 做了什么、文件各管什么、下一步能做什么。

审查发现的问题，不要让它一口气全修；把每一项当成新的小片，一片一片做。 完整审查流程见 第 8 章 · 阶段七 · 审查。

午饭登记完整实录

场景：团队要在一个网页上登记午饭。组织者看列表、删掉填错的记录； 同事打开链接，填姓名和想吃的菜。下面是关键对话， 旁注会解释每一步在干什么、验证的是什么。

GET    /api/lunch-orders?date=today
POST   /api/lunch-orders
DELETE /api/lunch-orders/{id}

第 0 步：建仓库

第 1 步：让它问，别让它做

第 2 步：把结论写成 spec.md

第 3 步：拿到能亲手点的验收清单

第 4 步：第一小片，只做“读空列表”

第 5 步：第二小片，把记录写进服务器

第 6 步：第三小片，删除一条

第 7 步：出问题了

第 8 步：聊太久了，换会话

第 9 步：收尾

什么时候该回头

如果它开始忘掉你说过的要求、同一个错纠正了三次、改一处坏一处， 或者你开始觉得“算了就这样吧”，不要继续硬推。 完整的危险信号清单和对应处理动作，见 第 10 章 · 危险信号清单。