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