用 AI 写代码，最坑的地方不是写得慢，是写得太快。

省时间这事是真的。GitHub 早年那个随机实验里，用上 Copilot 的人，完成某一类编码任务快了一半还多；另一些面向开发者的调研也说，一个人一周大概能省出三四个钟头。注意这俩是两回事——一个是特定任务的实验数字，一个是开发者自己报上来的体感，别拿它去套「所有代码都能快一半」。

可省下来的时间，不等于代码债跟着消失了。有团队的内部指标、也有行业基准报告里观察到：AI 上得猛之后，上线的事故未必更少，甚至可能不降反升；那些没人回头管的 AI 代码，维护成本也不会凭空蒸发，只是被推到了后面。还有个更扎心的角度：对老手来说，AI 有时候反而让他更慢，因为给它擦屁股、把它写的东西改到合规的活变多了。

项目里最常见的麻烦，往往不是 AI 一开始帮你提了多少速，而是过段时间回头看：堆了一摞 AI 生成的代码，跑是能跑，可没人真看懂，一改就崩，排查起来比自己重写还费劲。当初省的那点工夫，全在这种地方一点点还回去。

这事的本质，是 AI 写得快，但「快」是借来的。

它几秒钟吐一大段，你扫一眼能跑，就合并了。可这段代码到底干净不干净、有没有埋雷、跟整个项目搭不搭，没人细看。雷不会当场炸，它攒着。攒到某天，一个小改动牵出一串问题，你才发现底下早是一堆债。

说白了，用 AI 写代码有点像刷信用卡买东西：当下很爽，账单都在后面。还得起还不起，看你有没有一直在记账。

那记账的活是什么？就是验收。调查里有个挺一致的倾向：那些有一套正经 review、有质量检查工具盯着的团队，更可能把 AI 的「快」转成「好」；而把 AI 当甩手掌柜、写完就用的，债越滚越大。同样一个工具，一个团队用出了效率，一个团队用出了一屁股债，差的就是中间这道关。

具体记什么账？几条最实在的——

一是 AI 写的每一段，合并前自己过一遍，别扫一眼能跑就完事：它有没有重复造了项目里已经有的轮子？有没有处理边界（空值、超时、报错）？命名和风格跟现有代码搭不搭？这几个问题问下来，大部分埋雷的段落当场就露馅了，根本拖不到上线。

二是让它给自己写的代码补测试，再把测试跑起来。逼它自己出用例，常能照出它当时没想到的坑——尤其是那些它写得理直气壮、其实压根没考虑的异常情况。这一步几乎不花你脑子，却最能兜底。

三是隔段时间回头清一次：那些「当时能跑、现在没人看得懂」的段落，趁它还没在项目里长成大树，该重构的重构、该删的删。

就这几下，费不了多少工夫，但决定了那笔账是越滚越小，还是越滚越大。

所以别被「快多少」忽悠。AI 写代码这事，省下的时间是真的，但它没帮你把「这段到底行不行」的判断也包了——那一步，还得是人。能写多快，决定你今天爽不爽；肯花多少工夫验收，决定你半年后哭不哭。

#马力的AI知识分享#