我用 AI 做了 16 个迭代，靠的是一套「笨办法」
用 AI 写代码半年，我发现一个反直觉的事：
AI 越快，我越不敢直接让它写代码。
不是因为 AI 不行。恰恰相反，它太行了。你给一句模糊的话，它能唰唰唰写出一大坨——跑得通、有注释、看着还挺专业。
就是方向可能全错。😅
AI 最擅长的，是"精致的垃圾"
我给孩子做了个英语阅读 app，从第一行代码起就用 AI 协作。
早期我也犯过懒，张嘴就来："给书架加个封面。"AI 立刻动手，写得飞快。结果呢？它用加载完整 PDF 的方式去渲染一个 200 像素的小缩略图。100 本书，一下子拉了 20MB 流量，书架直接卡死。
代码有错吗？没错。能跑吗？能跑。但这是我要的吗？不是。
这就是 AI 的陷阱：它会把你的模糊需求，实现成一份精致的垃圾。语法漂亮、结构工整，就是解决了一个错误的问题。
而且它越快，这份垃圾产出得越多，你返工越累。
核心矛盾：AI 不会替你"想清楚"
想明白这点，我意识到一件事：
AI 能替你写代码，但不能替你判断"该做什么、做成什么样"。
写代码是执行。判断要什么、边界在哪、怎么取舍——这是思考。AI 把执行的成本打到了地板，但思考的成本一点没降，反而更显眼了。
因为以前你想不清楚，顶多是自己写得慢、错得慢。现在 AI 帮你加速，你想不清楚，它就帮你加速地错。
所以问题不是"怎么让 AI 写得更快"，而是"怎么让我自己想得更清楚，再让 AI 去快"。
我的笨办法：四步，一步都不许跳
我给自己定了个规矩。每个迭代，雷打不动四步：
第一步，先写需求文档。
不许直接碰代码。先把这几件事写下来：要解决什么问题、具体要哪些功能、有哪些技术约束、几个方案怎么取舍、会影响哪些文件。
写需求文档的过程，就是逼自己把模糊的念头挤清楚的过程。很多"我以为我想好了"的需求，一落笔就露馅——原来还有这么多没想明白。
第二步，再写测试用例。
把"做成什么样"翻译成一条条能验证的标准。比如"接口返回正确分数""录音不到半秒不提交""这个按钮在那种情况下不显示"。
这一步特别关键。需求文档说的是"我想要什么"，测试用例说的是"怎么算做到了"。后者才是 AI 能照着干、干完还能自查的东西。
第三步，写开发计划。
把整件事拆成一个个小任务，标好谁依赖谁、哪些能并行、按什么顺序做。
第四步，才轮到编码。
到这一步，我才把前面三份文档丢给 AI，让它照着干。
我甚至在项目规则里写死了三条禁令：不许不写文档直接改代码、不许跳过测试用例设计、不许先写代码后补文档。
为什么"笨办法"反而最快
你可能会问：写这三份文档，不慢吗？
打个比方。AI 是史上最强的施工队，盖楼飞快。但你不能让它边盖边想——今天想加个阳台，明天想改个朝向，它每改一次都要拆墙。
文档就是图纸。先画好图纸，施工队一天的活，比你边盖边改一个月都快。🏗️
我这套笨办法跑下来：16 个迭代，留下了 45 篇文档，攒下 155 个自动化测试。那个阅读 app 从一个空仓库，长成了能持续演进、还接了 AI 语音测评的产品。
慢的是想，快的是做。把慢的功夫下在前面，后面才真快。
测试，是 AI 的"紧箍咒"
这套办法里，我最想单独夸的是测试。
AI 改代码有个毛病：它改 A，可能悄悄弄坏 B，自己还浑然不觉。你光看它新写的那段，根本发现不了。
测试就是给它戴的紧箍咒。每次改完，155 个测试一跑，哪个红了，就是哪里被搞坏了。AI 自己看到红测试，就会回头去修。
有了这层护栏，我才敢放手让 AI 大范围改代码。不然每次改完我都得提心吊胆地人肉检查，那 AI 的意义就少了一半。✅
还有一个隐藏红利：架构
文档和测试之外，我另一件没偷懒的事，是把架构分层做干净——业务逻辑、外部接口、界面框架，各管各的，中间用抽象接口隔开。
好处在我上一篇里讲过：我把语音评测从一家换成另一家，前端一行没改。
16 个迭代能一路演进、不推倒重来，靠的就是这个底子。AI 写得再快，架构是烂的，几十次迭代下来早就成一团解不开的乱麻了。
写在最后
回到开头那个反直觉的事。
很多人觉得，AI 时代了，写文档、写测试、搞架构这些"老派功夫"该淘汰了——AI 写得那么快，谁还磨这些。
我的体会正好相反：
AI 越强，这些慢功夫越值钱。
因为 AI 把"做"的成本打没了，"想清楚"就成了最稀缺、最决定成败的那一环。而文档、测试、架构，恰恰是逼你想清楚、并且把想清楚的成果固化下来的工具。
旧地图套不上新大陆。但有些老道理，换了个时代，反而更灵了。
那套笨办法，一点都不酷。但它真的好用。👷
如果你也在用 AI 写代码，却被"精致的垃圾"坑过，点个在看，转发给你的同事——也许他正需要这套笨办法。
你用 AI 协作有什么独门心得？欢迎评论区聊聊——每一条留言我都会看。