第 5 章 · 拆解开发任务：别让 AI 一次做完
把 PRD 切成 5 个纵向切片任务，每个都能跑、能看、能验收——并学会怎么下任务、约束修改范围、审查结果、保存阶段版本。
这一章解决什么问题
拿到 PRD 直接说「AI，帮我把这个生词本做出来」，会发生什么：它一口气生成一大坨代码，跑不起来；跑起来了你也不知道哪句代码对应哪个功能；改一个小问题，它顺手「优化」了八个不相关的地方。一次要求 AI 完成所有功能，是假成功和不可维护的重灾区（见反模式图鉴的假成功）。
解法是把 PRD 切成小任务：每个任务都做出一条能跑通、能演示、能验收的完整小链路，做完一个存一个版本。这一章教你怎么切、怎么下指令、怎么审、怎么存。
开始前你要有什么
- PRD（AC1–AC8 是切任务的原材料）
- 第 4 章选定的模板 + 复用/补充清单
- 项目已初始化 git（模板自带，确认
git status能用）
分工：人判断什么，AI 做什么
| 人负责（判断） | AI / Skills 负责（加工） |
|---|---|
| 决定任务切法、顺序、每个任务的验收标准 | 按你的任务指令写代码 |
| 审查改动是否越界（diff 检查） | 列出它改了哪些文件、为什么 |
| 决定何时保存版本 | 执行 git 命令（或给你命令由你执行） |
| 验收通过后才进下一个任务 | 对验收失败给出修复 |
可用 to-tickets 一类 skill 帮你起草切分，但切分的粒度和顺序必须你拍板——这是架构判断，不是文字工作。
怎么做
第 1 步：理解「纵向切片」——为什么不能按层切（约 5 分钟）
新手最常见的切法是横向的：先做完所有页面 → 再做所有后端 → 再做数据库。问题：前两个任务完成时没有任何东西能跑，你无法验收，AI 也不知道自己写的页面最终对接的后端长什么样。
正确切法是纵向：每个任务像一根子母弹的弹道，从页面一路打穿到数据库，落地就能演示：
横向切（别这样）： [全部页面] → [全部接口] → [全部建表]
（做完俩月啥也跑不起来）
纵向切（这样做）： T1 空壳上线（部署链路通）
T2 录一个词 → 存进库 → 列表能看见（最细的一条全链路）
T3 列表完善（筛选+状态切换）
T4 登录接入（真账号替换假账号）
T5 异常与权限收尾第 2 步：生词本的任务清单 T1–T5（约 15 分钟）
| 任务 | 做什么（用户视角） | 验收（引用 AC） | 依赖 |
|---|---|---|---|
| T1 | 模板空壳部署上线：一个网址能打开 | 网址能访问、登录页能显示 | 无 |
| T2 | 「添加一个单词」最细全链路：表单录入 → 服务端校验 → 存库 → 列表出现 | AC2 + AC3 的雏形（先写死一个测试账号，不做真登录） | T1 |
| T3 | 列表完善：状态切换 + 按状态筛选 + 空状态 | AC4、AC5 | T2 |
| T4 | 真登录：邮箱注册/登录/退出，词归属真实账号 | AC1、AC3 | T2 |
| T5 | 异常与权限收尾：重复词、失败提示、账号隔离 | AC6、AC7、AC8 | T3、T4 |
三个切分判断，示范给你看：
- 为什么 T1 是部署？ 部署是整个项目风险最高的未知数（账号、平台、配置）。先花一小时把「改代码 → 网址更新」这条管道打通，后面每个任务做完都能立刻发出去看。把最大风险放在第一天，是排险的基本功。
- 为什么 T2 先写死测试账号？ T2 的目标是打通「页面→服务端→数据库→页面」这条链路（第 6 章就讲它）。登录是另一条独立的链路，混在一起做，两边都查不清。写死的账号会在 T4 换成真的。
- 为什么 T5 收尾而不是随手做？ AC6–AC8 是「不高兴路径」（重复、失败、越权），它们依赖正常路径已稳定。AI 写「高兴路径」很靠谱，写「不高兴路径」容易漏——集中一个任务专门收拾，验收时逐条过。
第 3 步：学会下达任务的标准格式（约 10 分钟）
每个任务都用这个模板发给 AI（可整体复制）：
当前任务：T2 添加一个单词（最细全链路）
背景：项目是 Next.js + Supabase 起步模板，T1 已完成部署，
数据库已建 words 表（表结构：粘贴第 3 章 PRD 第 6 节）。
本次只做：
1. 列表页顶部加录入表单（单词、释义必填；例句、来源选填）；
2. 提交后服务端校验（非空、长度上限），校验失败给中文错误提示；
3. 校验通过写入 words 表，user_id 暂时写死为测试账号 ID；
4. 列表显示该账号所有词，新词出现在最上面，状态默认「未掌握」。
明确不动：登录逻辑（T4 才做）、筛选和状态切换（T3 才做）、
页面整体样式、模板自带的其他文件。
完成后报告：改了哪些文件、新增了什么、我如何一步步验证
（给出具体操作步骤）。不要做超出本清单的事。「明确不动」一节是防跑偏的关键——AI 顺手改无关内容是高频问题，白纸黑字列出来，审查时才有据可依。
第 4 步：审查结果（每个任务必做）
AI 报告完成后，三步审查：
- 让它列改动清单：「列出本次改动涉及的所有文件，每个文件一句话说明改了什么。」和「明确不动」清单对照，越界的让它撤掉（「把 X 文件的改动恢复原样，那个不在本次范围」）。
- 自己跑验收：按任务验收列的操作走一遍。T2 的验收就是：录一个词 → 列表出现 → 刷新还在（数据库真存了）。
- 抽查一处代码：不用全看懂，挑核心一处（比如 INSERT 那几行）让 AI 逐句解释，你判断它说的和做的事是否一致。看不懂的地方记下来——第 6 章专治这个。
第 5 步：保存阶段版本（每个任务验收后）
git add -A
git commit -m "T2: 添加单词全链路（AC2 通过，写死测试账号）"规矩：一个任务一个版本，验收通过才提交。提交信息写任务号和验收结论，将来「哪个版本是好的」一目了然。这些版本就是第 7 章「改坏了退回去」的本钱。注意：git 保存的是代码的版本，用户录入的数据不跟着走——两者的区别第 7 章排错时专门讲。
产物与检查
产物：任务清单文件（建议存为项目里 docs/tasks.md，含状态列）+ 已完成任务的验收记录。检查表：
- 每个任务都有用户视角的描述、AC 编号的验收、依赖关系
- 每个任务的验收都是「能跑起来看到的现象」，不是「代码写完了」
- 任务指令里有「明确不动」清单
- 已完成的任务都有对应的 git 版本
不满意或失败时怎么调整
- 一个任务反复失败（改三轮还跑不通）：任务切太大了。把它对半切——比如 T2 卡住，先只做「表单+校验」，存库下一步再做。任务越小，AI 犯错空间越小，你审查越容易。
- AI 越改越多：停。恢复上一个版本（
git status+git restore 文件名或重讲到第 7 章），把「明确不动」写得更具体，重下指令。不要在跑偏的改动上继续叠指令——那是把错上加错。 - 验收时发现 AC 依赖没满足（T2 想「刷新还在」，结果数据没存进去）：恭喜，你提前抓到了一个真 bug。这正是纵向切片的价值——问题在链路的哪一环，下一章教你定位。
交给下一章什么
- T1–T5 的执行进度——第 7 章验收时按 AC 逐条过，就是拿每个任务的验收记录汇总；
- T2 做出的那条最细全链路——第 6 章把它解剖给你看：你跟着 AI 做完的每一步，页面、服务端、数据库各自干了什么。
案例进度：T1、T2 已完成（案例假设），「添加一个单词」链路已通。下一章走进这条链路内部。