一次只改一件事
One Change at a Time也常被叫作：小步改别一次改太多拆开做
「让他一次做完，结果哪里都不对，我也不知道是哪一步坏的。」
一次只改一件事 One Change at a Time
每一轮只改一个承重的东西，这样结果不对时你能立刻知道是谁的责任。
这条规则的目的不是「稳妥」这种模糊的好处，而是一个非常具体的能力：定位。
如果一轮里同时改了布局、数据逻辑和接口，结果页面坏了，你面对的是三个嫌疑人和一堆纠缠的改动。如果一轮只改布局，坏了就是布局。前者可能耗你半天，后者三十秒。
判断标准很简单：如果结果不对，你能一眼看出是哪一处引起的吗？ 能，就继续；不能，说明这一步太大了，拆开。
几个必须分开的组合，都是踩过坑的经验：改样式和改数据逻辑分开；重构和修 bug 永远分开（否则你分不清是修错了还是重构错了）；升级依赖和改功能分开。这不是效率损失——它换来的是「每一步都可验收」，而可验收才是你能持续往前的原因。
这条规则在 AI 协作里还要多一层执行细节：AI 天然倾向于一次多改，因为它把「一次做完」理解为效率。你需要在需求里明确写「分步做，每步等确认」，并且在它一次做完时，要求它退回重新分步——这比事后回滚便宜得多。
一个有用的配套习惯：每步结束都留一个可回退点。 不是要求每步都备份，而是保证每步结束时系统处于可用状态、你知道怎么退到上一步。这样任何一步出问题，你都能在不放弃整体进度的情况下修正它。「每步可验、每步可退」，这八个字是让长任务不失控的全部秘密。
长什么样 真实可交互，不是截图
结果：页面白屏
原因：三个嫌疑人，全都可能
第 2 轮只改数据 → 验一次
第 3 轮只升依赖 → 验一次
左边看起来快一步到位，但它的失败成本是右边的好几倍——而失败在 AI 协作里是常态，不是例外。
拆开看，里面有这几块
-
1
一个承重改动 One load-bearing change
这一轮真正会改变行为的那件事。其余都该等下一轮。
-
2
验收点 Checkpoint
每轮结束时你能亲手确认的一个结果。没有验收点的分步等于没分。
-
3
可回退点 Safe point
每轮结束后系统都处于一个可用状态，随时能停下。
容易搞混？这样区分
什么时候用得上
回想上一轮改了几件事。如果超过一件，先把它们拆开重做一遍。
永远分两次。合起来做，你永远说不清是修错了还是重构错了。
它常会说「我一起改了更方便」。回一句「先只做第一步，我验完再继续」。
你可以这样跟 AI 说
直接复制下面这段，把【】里的换成你的情况。它比一句「帮我加个 X」多说清楚了：改哪里、不许动啥、做完交什么。
这个任务请分步做，一轮只改一件事，每轮之间等我确认。 【第 1 步】只做 [一件具体的事] 做完后停下来，告诉我：改了哪些文件、我怎么自己看到效果 我确认之后你再进行下一步 【第 2 步】[下一件事]（等我说开始） 【第 3 步】[下一件事]（等我说开始） 重要：不要为了效率把几步合在一起做，即使你觉得一起改更方便。如果你认为某两步无法分开，先告诉我原因，让我决定。 每一步结束时，系统都应该处于一个可用状态——不要留下"改到一半、要等下一步才能跑"的状态。
最后那句「每步结束都可用」很关键：它防止 AI 把一个大改动机械切成三段，让你在中间两段完全无法验证。
它说「做好了」，你怎么自己验
这是本站的重头戏。AI 最会的不是写代码，是说「已完成」。这一条，它通常最多做到「运行时」这层：真的跑起来了，能在本机看到结果。
要亲眼看到这些，才算数
- 每一步结束时，你都能亲手看到一个结果（页面能打开、功能能用）。
- 对照它这一步改的文件数量：一件事通常改一到三个文件，一改十几个就要问原因。
- 确认它没有偷偷把后面几步一起做了（问「后面两步你动了吗」）。
- 任意一步之后停下来，系统仍然可用——不是「要等下一步才能跑」。
它常这么糊弄你
- 「我把这三步一起做了，更高效」——效率没错，但你失去了定位能力和中途停下的自由。
- 把一个大改动机械切成三段，中间两段根本无法运行。分步的意义是每步可验，不是切成三块。
- 一步里塞了「顺手的小调整」。小调整也是变量，坏了同样会混淆判断。
- 你说「先做第一步」，它做完顺势把第二步也做了，然后一起汇报。
这一条能验到「运行时」层：每一步结束你都亲手跑一次，看到系统是活的。
考考你 选一个你觉得对的
怎么判断这一轮的改动是不是太大了？
唯一真正重要的标准是可定位性。行数和文件数只是粗糙的代理指标：改 300 行样式很安全，改 5 行数据结构可能很危险。C 则把判断交给了最没有动力说「这很复杂」的一方。