一次一件
一次只让它做一件能被单独验证的事。做完，你确认，再做下一件。
你会遇到的现象
- 一次生成几百上千行，读到一半就放弃了，直接跑跑看
- 出了问题不知道是哪一步引入的，只能整块重来
- 改一个地方，它顺手动了三个不相干的文件
大任务的代价不在生成，在验证。一次两千行代码，你要么全部读完，要么跳过验证直接跑——多数人选后者，然后在几步之后为它买单。
小步还有个隐性好处：每一步都是一个可以回退的存档点。第三步做坏了，退回第二步重来，前面的成果都还在。大步走的话，只能整块推倒。
一步多大合适
| 判断标准 | 说明 |
|---|---|
| 能被单独验证 | 做完之后你能立刻点一下、看一眼，判断对不对 |
| 你愿意读完它的输出 | 如果预感自己会跳过不读，说明太大了 |
| 大约在一屏到几屏代码 | 超过这个量级，先想想能不能再切一刀 |
| 失败了不心疼 | 做砸了直接丢掉重来的成本能接受 |
怎么拆
- 竖着拆，不横着拆。按一次完整的用户动作拆（记一笔、看一次列表），不按前端后端数据库分层拆（见最小切片）。
- 数据先行。第一步永远是把实体和关系定下来。这一层错了，后面每一步都要返工。
- 先跑通再补全。先让主流程从头到尾能走一遍，四态、边界、异常留到后面单独一步。
- 一步一确认。做完就看一眼，别攒着三步一起验。攒着看等于没拆。
- 规格写超过一屏，说明该再拆。这条跟先规格后代码互为检验。
拆完之后，把这份任务清单本身写进文件，让它每做完一步更新状态。这样即使会话中断，进度也不会丢——这是把上下文写到外部的一种具体用法。