AI写代码越快，你欠的技术债越多

上个月，一个做SaaS的朋友跟我吐苦水。他的创业团队用Cursor三天搭出了MVP，投资人看了演示直接拍板给了种子轮。钱到账那天他发了个朋友圈：”AI时代，速度就是一切。”

两周后他找我喝酒，一脸苦相。招来的三个工程师看完代码，一个当场摇头，一个委婉建议”不如重写”，最后一个更直接——第二天就提了离职。

三天写出来的代码，没有一个专业工程师愿意碰。

速食代码，吃得快但保质期是零

Andrej Karpathy去年造了个词叫Vibe Coding——氛围感编程。听着很浪漫：你不用懂代码，把需求用人话告诉AI，它写好了你直接运行，”跟着感觉走”就行。

这词一出来，圈内外都很兴奋。设计师能写App了，产品经理能搭后台了，运营能自己做数据看板了。门槛被踹了个粉碎。

但门槛这东西，踹掉了不代表不存在。它只是换了个位置——从入口处挪到了你往前走的路上。

Google工程师Addy Osmani说得更具体，他管这叫”70%问题”：AI能帮你秒杀70%的功能，但剩下那30%可能让你加班到怀疑人生。这30%是什么？错误处理、并发控制、安全防护、边界条件。全是那种”不出事你以为不存在”的东西。

AI降低了写代码的门槛，但一个字都没降低维护代码的门槛。 这两个门槛之间的鸿沟，就是技术债的温床。

连造AI工具的人都在反思

前段时间有个事挺有意思。Claude Code团队的工程师Thariq公开写文章说，他们内部正在把文档格式从Markdown换成HTML。

你可能觉得这是个小事，但细想一下：Markdown不是够用了吗？简洁、好写、人人都会。但Thariq说了句大实话——”超过100行的Markdown，我读起来就很吃力。”

他坦承HTML生成比Markdown慢2到4倍。但他宁愿慢，因为结果更好。

这件事折射出一个比格式之争大得多的问题：连AI工具的开发者，都开始抛弃”够用就行”的心态了。 你还在靠Vibe Coding糊弄自己，人家已经在往精细化走了。

更扎心的一个数据：有经验的工程师观察发现，AI生成代码积累的技术债，大约是手写代码的3到5倍。因为AI不会主动做代码复用，不会考虑长期可维护性，它只管”让这段代码跑起来”。

跑起来和能用，中间差着十万八千里。

失控三部曲：从快感到噩梦

每个Vibe Coding项目，几乎都会经历同样的三个阶段。

第一阶段：原型期。 快感拉满。你输入几句话，AI唰唰唰生成几百行代码，跑起来了，功能有了，界面也像那么回事。你觉得自己是天才。这个阶段大概持续三天到一周。

第二阶段：迭代期。 开始痛苦。你想加个新功能，AI改了A文件，B文件崩了。修好B，C又出问题了。Addy Osmani说这叫”两步前进，三步后退”——修一个Bug冒出三个新Bug。你开始频繁地跟AI说”不对，退回去”，但你说不清该退到哪个版本，因为你从来没真正理解过这些代码。

第三阶段：维护期。 完全失控。代码库膨胀到几千行，没有测试，没有文档，函数名像AI起的（确实是AI起的），变量作用域混乱，同一个逻辑在三个文件里各写了一遍。你找来一个有经验的程序员看看能不能救，对方打开编辑器，沉默了三十秒，然后问你：”这是谁写的？”

你说：”AI。”

对方说：”看得出来。”

没有人会维护一份自己看不懂的代码。 连写代码的AI都不行——因为下次它看到这份代码，会忘掉上次为什么这么写。

“让AI重写”为什么不是解药

很多人踩完坑之后的第一反应是：”那就让AI重新写一遍呗。”

这思路听着合理，但它是个陷阱。

AI重写代码，本质上是再做一次Vibe Coding。新代码可能解决了老问题，但大概率带来一批新问题。因为AI不知道你在上一个版本里踩过哪些坑、做过哪些妥协、为什么那个看起来很蠢的判断逻辑其实是在处理一个真实的边界情况。

这就像你住的房子漏水，解决方案不是把房子推倒重建——因为新房子可能在另一个地方漏水。你需要的是一个懂结构的工程师，找到问题根源，精准修复。

重写是最贵的bug修复方式，因为它把所有学到的经验都扔了。

五个原则，从氛围感走向工程化

AI编程不是问题，Vibe Coding才是。区别在于：你是在驾驭工具，还是被工具牵着走？

原则一：读懂每一行再接受。 AI给你生成代码之后，花五分钟把它读一遍。不需要每行都看懂，但至少搞清楚数据从哪来、到哪去、中间做了什么处理。读不懂就让AI解释——但别只听它的，用你的常识核对。

原则二：测试不能省。 Vibe Coding最容易省掉的就是测试。”能跑就行嘛”。不行。你不需要自己写测试代码，但你必须定义”什么算对”。写好测试用例让AI去实现，如果测试通过，代码至少在功能层面没翻车。这比”点两下看看”靠谱一百倍。

原则三：限制AI的改动范围。 “帮我写一个用户注册功能”是Vibe Coding。”帮我写一个用户注册功能，密码用bcrypt加密，邮箱做唯一性校验，失败返回具体错误码不要返回500”——这才是工程化。约束越精确，AI越不容易发挥过头。

原则四：代码审查不是形式主义。 一个人写，一个人看。哪怕另一个”人”也是AI——让一个AI写代码，另一个AI来审代码，效果比你想象的好。关键是别让同一个上下文又写又审，那跟自己批改自己的作文一样，啥问题都看不出来。

原则五：架构设计是人的活。 AI可以帮你写函数、写模块、写接口，但”这个系统应该怎么拆分、模块之间怎么通信、数据流怎么走”——这些决策你得自己做。你可以让AI给你提方案，但最终拍板的必须是你。因为你要对这个系统的未来负责，AI不用。

为烂代码买单的，永远是未来的你

回到开头那个朋友。后来怎样了？

他花了两个月，老老实实补了测试，理清了代码结构，重新定义了接口规范，然后再用AI逐模块重构。整个过程比当初三天写MVP痛苦得多，但他说了一句话让我印象很深：”那三天省下来的工作量，我后面用两个月还回去了，而且还加了利息。”

技术债就是高利贷。借得越爽，还得越惨。

AI改变了写代码的速度，但没改变软件工程的底层规律。代码是要被人读的，系统是要被人维护的，产品是要在真实世界里跑的。这些事情，从来没有捷径。

Vibe Coding可以是你的起点，但如果它也是你的终点，那你只是在用更快的速度制造技术债。

下次AI帮你生成一段代码的时候，多问自己一个问题：半年后回来看这段代码，你还能看懂吗？

如果答案是”不确定”——那你就知道该怎么做了。