AI使两版开发法可行：先快速原型验证，再正规生产

AI 时代的代码审查：为什么写两遍反而更快

如果你已经编程几年，你可能经历过这样的噩梦：你完成了第一个版本，终于让它跑起来，然后意识到你误解了一半的需求，遇到了三个技术死胡同，而且架构无法支撑下一次迭代。想从头重写？截止日期不答应。所以你不断打补丁，三年后，那个代码库变成了没人敢碰的遗留怪物。

这个问题已经存在了几十年。但 AI 编程工具意外地给了我们一个新解决方案。

我的方法：两个版本，两种标准

这个想法并不新鲜。软件工程教科书称之为“原型开发”：先构建一个粗糙版本来验证想法，然后进行真正的开发。但实际上没人这么做，因为太昂贵了。构建一个可行的原型可能花费真正实现的一半时间。谁有那样的预算？

情况变了。AI 写代码的速度仍然让我措手不及。一个过去需要三天的功能，现在可能三小时就有可运行版本。这种速度的变化使原型开发从“理论上的好”变成了“实际上的值得”。

具体做法：构建两个独立的版本。

版本一：原型，让 AI 自由发挥

第一个版本有明确的目的：它是原型，不是产品。只有两个目标：确认需求，解决硬技术问题。

原则是“无约束”：不考虑架构，不担心代码质量，忽略安全和性能。专注于一件事：让它工作。合并 AI 生成的代码而不审查。让 AI 迭代直到你的产品经理点头说：“是的，这就是我想要的。”

这段代码注定要被丢弃，所以把它放在单独的分支甚至独立仓库中。它的价值不在于代码本身，而在于两件事：弄清楚实际需求是什么，以及先踩上所有技术地雷。

无论你的需求文档多么详细，你常常只有在构建了一些东西后才能清晰思考。技术挑战也一样，理论和现实是不同的东西。第一个版本的存在是为了以最低成本踩上每一个地雷。

把它想象成建筑师的草图。草图不需要精确的线条或完美的比例。它们帮助你快速外化你的想法，尝试、调整、确认方向。没有人会按草图建造。

版本二：生产，回归传统工程

一旦第一个版本扫清了道路，你就构建第二个版本。这才是实际交付的。

现在你回到传统软件工程：先设计，然后拆分成模块，运行 CI 流水线，进行适当的代码审查。保持小的提交，以便人类可以真正审查它们。考虑设计、可维护性、安全性，所有重要的东西。

在这个阶段，AI 仍然做重活，但人类主导。先设计再实现。使用计划模式让 AI 根据你的思路生成代码。

第一个版本的代码并非完全浪费，某些模块可以重用，尤其是算法实现和核心业务逻辑。

这就像从草图中提取有价值的部分，放入正式的施工图中。

为什么这实际上有效

为什么要费力做两个版本？

核心原因：在第一个版本完成之前，你对需求的理解几乎肯定是不完整的。

传统开发的问题在于，它在第一个版本上投入了太多精力。你在需求完全明确之前就开始架构。你在解决技术挑战之前就考虑可扩展性和可维护性。结果？针对“也许某天会发生”但从未发生的情景进行大量过度工程。时间花在边缘案例上，而真正的问题被忽视。