小步快跑 vs 一步到位

一步到位的诱惑

我刚开始用 Claude Code 的时候，干过一件特别「爽」的事：把一整个功能的需求写成一段超长的 prompt，按下回车，然后看着它哗哗地输出了几百行代码。当时的感觉是——这也太快了吧，以后写代码岂不是轻松加愉快？

然后我花了两个小时 debug，才发现第三步的一个小偏差导致后面整个逻辑全歪了。

这就是「一步到位」的陷阱。Claude Code 写得快，让人很容易产生一种错觉：既然它能一口气写完，那我就一口气让它写完呗。但现实是，AI 的速度优势会在出错时变成负担——它在错误的基础上继续堆砌代码的速度也一样快。

具体来说，一步到位有三个致命问题：

第一是错误放大效应。假设你让 AI 一口气完成 10 个步骤，第 3 步出了偏差，后面 7 步全是在错误基础上构建的。你拿到的不是一个有小瑕疵的成品，而是一个从根基上就歪了的建筑。

第二是审查困难。500 行代码摆在你面前，你很难逐行审查。人脑处理信息的带宽是有限的，一次看太多代码，注意力会分散，关键问题反而容易漏掉。

第三是回退代价高。如果中间没有 commit，发现问题后只能全部撤销重来。那种「我已经写了 500 行了不舍得扔」的心态，会让你在错误的路上越走越远。

我现在的工作节奏是这样的：每个步骤控制在 5 到 15 分钟，让 Claude Code 产出大概 30 到 100 行代码。拿到代码后快速审查，确认没问题就立刻 commit。

这个节奏有点像打游戏时频繁存档。你不会打了三个小时 Boss 才想起来存档，对吧？每过一个小关卡就存一次，这样挂了也只损失几分钟的进度。

举个实际的例子。有一次我要给一个电商项目加购物车功能，我本来想一口气让 Claude Code 把整个购物车写完——添加商品、修改数量、删除商品、计算总价、优惠券逻辑。后来我忍住了，改成分步走：

每一步都是可运行、可测试、可回退的。第三步算税费的时候 Claude Code 确实搞错了一个四舍五入的细节，但因为改动量小，我两分钟就定位到了问题。如果是一口气写完，这种细节很可能淹没在几百行代码里。

我的经验法则是：你能在 2 分钟内完成审查的量。如果拿到代码后需要花 10 分钟才能看完，说明粒度太大了，下次应该拆得更细。

当然，2 分钟不是死规矩。如果是你非常熟悉的模式化代码（比如 CRUD 接口），粒度可以稍大一些。如果是涉及复杂业务逻辑或者并发处理的代码，粒度反而要更小——因为这类代码出错的概率更高，审查时需要更多注意力。

还有一个判断标准：每一步的产出应该是「可独立理解」的。也就是说，单看这一步的代码改动，你就能明白它在做什么，不需要前后翻看才能搞清楚逻辑。

小步快跑的哲学和 Git 的 atomic commit 理念是一脉相承的——每个 commit 做一件事，可独立理解、可独立回退。在 AI 编程的场景下，这个原则比传统开发更重要，因为你需要更频繁地验证产出是否符合预期。

说实话，一开始执行小步快跑是有点别扭的。明明 AI 能一口气搞定，非要自己拆成好几步，感觉在人为制造麻烦。但坚持了一两周之后，我发现整体效率反而提高了——因为返工的次数大幅减少，而返工才是真正吃掉时间的怪兽。

我的建议是：先从一个简单的功能开始练习这个节奏。体会一下「小步 → 审查 → commit」的循环，感受一下那种「每一步都在掌控之中」的确定感。一旦习惯了，你就回不去了。