One thing at a time
Have it do one thing at a time that you can verify on its own. Done? You confirm. Then the next.
- 一次生成几百上千行，读到一半就放弃了，直接跑跑看
- 出了问题不知道是哪一步引入的，只能整块重来
- 改一个地方，它顺手动了三个不相干的文件
The cost of a big task is not in generation, it is in verification. Two thousand lines at once means you either read all of it or skip verification and just run it — most people pick the second, and pay for it a few steps later.
Small steps have a hidden benefit: each step is a save point you can roll back to. Mess up step three and you revert to step two with everything before it still intact. Take big steps and your only option is to tear the whole block down.
How big should one step be
| 判断标准 | 说明 |
|---|---|
| 能被单独验证 | 做完之后你能立刻点一下、看一眼，判断对不对 |
| 你愿意读完它的输出 | 如果预感自己会跳过不读，说明太大了 |
| 大约在一屏到几屏代码 | 超过这个量级，先想想能不能再切一刀 |
| 失败了不心疼 | 做砸了直接丢掉重来的成本能接受 |
How to break it down
- Split vertically, not horizontally. Split by one complete user action (record an entry, view a list), not by frontend/backend/database layers (see thin slice).
- Data first. The first step is always pinning down entities and relationships. Get this layer wrong and every step after comes back for rework.
- Get it running end-to-end before filling in. Let the main thread run through from start to finish first; the four states, edges, and exceptions come in a later dedicated step.
- Confirm one step at a time. Look right after each step — don't save up three steps to verify at once. Saving them up means you didn't really split.
- If the spec runs over one screen, split further. This and spec before code are mutual sanity checks.
After breaking it down, write the task list itself into a file and have it update the status after each step. That way even if the session is interrupted, the progress survives — a concrete way of writing context to the outside.