AI 编程邪修心得:写两遍,真的很快

前几天在宝玉老师的推特上看到一个观点，当时觉得挺反直觉的：AI 时代写代码，写两遍反而更快。我当时是觉得比较浪费时间的，但后来这几天正好有一个需求的更改，让我在实际工作中无意的实践了一次这种写法。然后我觉得效果竟然还很不错，下面就具体聊聊。

两轮版本开发法

这个方法的核心思路其实很简单：把开发分成两轮版本，第一版是原型版，第二版是生产版。

第一版：利用 AI 快速编码的能力，迅速实现需求

第一个版本完全不考虑架构设计、代码质量，只考虑一件事：把功能实现出来。这个版本你会发现在过程中会出现很多冗余的代码，或者说你们踩过很多坑，最终缝缝补补才达到目的，但没关系，因为这个版本本来就是不需要的，它的价值在于你们在这个相互协作沟通达到目的的过程中，明白了你最终到底要得到的东西是什么样子，以及在技术上你们踩过什么坑，有什么经验。

第二版：按生产标准步步为营

第一版的感觉就像是你派出了一支先遣部队去进行探路和地图的绘制，然后再拿着成果返回。这个时候你才要进行正式的大军出击，拿着你现在的这张地图作为经验，就可以提前做一些谋略和设计，在代码工程中你就可以先做模块的划分、架构的设计、技术的选择等等。在这一步中你可以从一个很小的实现开始，然后不断的去叠加你想要的那些功能和需求。之所以现在可以这样做，是因为你已经明白了整个路径。所以从小的实现进行功能迭代，可以减轻每次人为审核的负担，保持架构设计的清晰。

我的实战案例：PDF 上传组件改造

说个具体的例子。我最近在工作中有个需求是改造现有的图片上传组件，让它能够支持 PDF 的上传和预览。

第一轮：一口气实现，拉了坨大的

一开始，我让 AI 直接一口气实现所有功能。结果发现有很多东西它处理不好：PDF 的前端库选择、如何处理翻页、怎么避免触发浏览器自带的下载插件、是否用 iframe 加载……几轮对话下来调整了很多，代码改动量巨大，最终虽然完成了我想要的样子，但这个时候的代码已经面目全非，我根本没有办法进行审核。因为修改的数量实在是太庞大了。

这时候我意识到：需求其实我自己都没想得很清楚，所以第一次的实现反反复复。但走过的路就熟了，我已经明确知道了自己想要什么，以及如何达到。

第二轮：重新来过，逐步迭代

于是我全部推翻重来。这次我让 AI 从最简单的 MVP 开始——先实现一个能上传、能显示的最小版本，回显也不使用缩略图，直接用一个简单的 icon 替代，然后在这个基础上一步一步调整。

这样做的好处立刻显现出来了：

1. 每次改动量可控：每一步的代码变动都很有限，我能快速进行人工审查

2. 版本管理清晰：每个小步骤都能独立提交，出问题容易回滚

3. 需求明确：在第一轮中我已经明确了最终我想要什么样的 UI 交互

4. 技术路径清晰：第一次试错让我知道了需要什么技术，第二次就能有的放矢

最终，虽然这个组件花的 token 和时间也不少（当然相对于手写来说，肯定还是 n 倍提效的），但代码结构绝对是生产级别的，也不是 AI 生成的“屎山”。

为什么这个方法有效？

回过头来想，这个方法之所以有效，核心原因在于：一开始你对需求的理解其实并不完整。这里的需求包括：页面交互的设计以及技术难点和选择。特别是对于我这种前后端什么都做，但是又没有专业的产品经理来对齐的时候，尤其明显。

换在以前，只要代码能够完成你想要的功能，大家可能就不再想去动它。随着功能的迭代，也就成了大家戏称的屎山上继续拉屎，因为推翻改动的成本太大，那就“能跑就行”。

但现在不一样了，AI 广泛的知识域和它快速编码的能力能够让你非常迅速的去验证和实现你的原型和需求。你可以肆无忌惮地来回跟它在第一轮进行沟通和反复的修改，不在乎内部是怎么实现的，直到你们最终达到想要的结果。这个时候再回过头来总结你们踩过的坑和用到的技术的等等，把这些经验凝练下来，然后进行第二次正式开发，你会发现效果会好非常多。

邪修的最佳实践

如果你也想试试这个方法，我的建议是：

1. 思路不连贯时，先放飞自我：专门开一个分支，让 AI 自由发挥，快速实现一个版本

2. 不要急着做版本管理：第一版就是用来试错的，不需要刻意做 git 提交

3. 在试错中学习：跟 AI 不断沟通，看它的实现效果，记住你们踩过的坑和选择的技术栈

4. 第二版才是正式开发：明确路径后，重新开始，小步迭代，做好审核

用宝玉老师的话来说，“以前做两遍太贵，现在做两遍反而更划算”。这种“邪修”打法，可能不符合传统软件工程的教条，但在 AI 时代，它确实很管用。