上个月，一个朋友跟我说了件事。他们团队花三天重构了一个中等规模的模块，改善命名、拆分函数、优化结构。代码质量确实提高了，code review也顺利合入。两周后，业务方向微调，那个模块被整体重写——用AI生成新代码，前后不到两小时。

三天的人工优化，被两小时的AI生成覆盖了。

他问我：那我那三天算什么？技术债还了吗？还是说，还了个寂寞？

这个问题我想了挺久。不是因为答案难找，是因为答案让人不舒服——在代码可以轻易重写的时代，传统意义上的"技术债"，可能正在变成一个过时的概念。

代码从资产变成了耗材

以前我们写代码，心态跟盖房子差不多。地基打好了，后面一层层往上加。技术债就是某个环节偷了工减料——用了便宜的材料、省了一道工序——未来得花钱补回来。这个比喻成立的前提是：修改已有代码的成本很高。高到你宁愿在烂代码上打补丁，也不愿意推翻重来。

但现在情况变了。AI生成代码的成本趋近于零。

你让Cursor写一个模块，几分钟就能出活。不满意？重新生成一个。再不满意？换个prompt再来一次。"重写"这个词的含义变了——过去重写是伤筋动骨的大手术，现在重写就是重新打一行prompt的事。

代码正在从"资产"变成"耗材"。资产需要维护，耗材用完就扔。

这个转变引发的连锁反应比想象中更大。第一个被冲击的就是代码审查。如果代码注定是临时的，审查的意义就从"确保代码质量"变成了"确保行为正确"。风格、命名、设计模式——这些在一次性代码面前显得不那么重要了。

我之前看到过一个数据：给代码片段前面加几十个字的功能描述和边界说明，审查发现的缺陷数量提升了将近50%。这几十个字的价值，超过了大多数团队花几周做的代码规范整理。

这说明什么？代码本身的质量在贬值，围绕代码的"元信息"——意图、边界、约束条件——反而变得更重要了。

看起来干净，才是最大的坑

AI生成的代码有一个反直觉的特征：它看起来特别干净。

不是说代码真的干净。是说它的外观干净——命名规范、注释完整、结构清晰、变量名有意义。这种"干净"会让审查者放松警惕。

人工写的烂代码，你一眼就能看出来——变量名叫a、b、c，函数体两百行，没有注释，缩进混乱。你的大脑会立刻进入"找茬模式"。

AI生成的代码不给你这个信号。它的注释看起来合理——虽然可能只是从训练数据里学到的常见说法。变量名看起来专业——虽然可能跟业务含义有微妙的偏差。错误处理看起来完整——虽然可能在某个关键分支上直接吞掉了异常。

更隐蔽的是，AI生成的代码有一种"确定感"。它不会犹豫，不会写"这里可能有更好的方案"，不会在注释里留下TODO。代码看起来很自信，即使它是错的。这种确定感会传染——审查者也会被这种表面的自信影响，降低质疑的力度。

前几天看到一个案例。一段AI生成的支付回调处理函数，看起来结构完整、命名规范、注释详尽。但仔细看，重试逻辑里有个竞态条件——如果回调重复到达且间隔极短，可能创建两笔成功的记录。这种bug在人工代码里也很常见。区别是：人工代码通常外观粗糙，审查者会多留个心眼。AI代码包装得太好了，好到你不太想去质疑它。

技术债不是消失了，是变异了

传统技术债的运作模式是：慢慢积累，集中偿还。你赶工期欠了债，后面找个窗口期重构、还债。这个模式能运转的前提是：债是可见的——你知道哪里有问题，知道问题有多大，知道什么时候该还。

AI时代的技术债运作方式完全不同。

一句prompt生成三千行代码，一句prompt也可能引入三千行隐患。这些隐患不会立刻显现。AI生成的代码上线时看着没问题，三周后某个边界条件触发了，才发现有个分支处理不对。而因为是AI写的代码，团队成员对它的理解深度远不如自己手写的代码——出了问题要重新读一遍逻辑链路，搞清楚AI当时"为什么这么写"。

更麻烦的是，"生成代码的人"可能根本没仔细看过那些代码。这就形成了一个循环：生成了，上线了，出问题了，重新生成，再上线，再出问题。每次循环都留下一些没人完全理解的"遗留代码"。

技术债没有消失，只是从"我知道这里有坑"变成了"我不知道哪里有坑"。从明牌变成了暗牌。

这跟传统技术债有本质的不同。传统的债是明牌——你知道它在哪里、有多大、什么时候该还。AI时代的债是暗牌——它藏在没人逐行审查过的代码里，藏在看似合理但没人理解的设计决策里，藏在那些"反正AI写的先跑着"的模块里。

一次性代码时代，架构该怎么想

如果代码可以无限重写，什么样的架构才重要？

我越来越觉得，答案不是代码质量，而是系统的可替换性。外部接口要稳定，模块随时可替换而不影响下游。功能边界要清晰，每个模块只做一件事，职责不含糊。自动化测试覆盖核心路径，确保新代码不会悄悄破坏已有行为。模块自包含，新人读一个文件就能理解输入输出，不用翻遍整个仓库。

这不是新概念。微服务架构一直在讲这些原则。但AI时代的到来，让这个需求从"最好这么做"变成了"必须这么做"。

之前了解到一个团队的做法。他们把一个单体应用拆成了四十多个微服务，每个服务足够小，理论上可以被独立替换。但真正让他们受益的不是拆分本身，而是拆分之后强制推行的接口契约——每个服务对外暴露的API都有完整的契约定义和自动化验证。这意味着，不管服务内部的代码是人工写的还是AI生成的，只要契约不变，替换就不会影响上下游。

他们发现，真正的瓶颈不在重写本身，而在替换过程——服务之间的契约够不够稳定，下游系统的适配成本够不够低，回归测试的覆盖够不够全。可替换性看起来是个设计问题，实际上是个工程基础设施问题。

AI能帮你重写代码，但不能帮你搞定接口契约、部署流水线、回归测试。这些基础设施的价值，在AI时代不是降低了，而是更高了。

那技术债到底怎么办

回到开头那个加班重构的朋友。他的困惑其实是：在代码可以轻易重写的时代，"优化代码质量"这个理由本身就不够用了。重构的对象可能已经不是代码本身了。

也许重构的定义正在发生变化。以前重构是"改善现有代码的结构而不改变其行为"。在新的语境下，它可能更像是"判断一个模块是否值得重写"——如果不值得，就做最小化维护；如果值得，就整体替换。而这个判断本身，变成了一个管理决策：投入多少时间重写、重写的风险有多大、重写后的收益怎么评估。

技术债也在变形。过去的债是时间和质量的权衡——先快后慢，先糙后细。现在的债更像是可替换性和耦合度的权衡——代码本身可以不完美，但系统要允许你随时替换不完美的部分。

说实话，重构这个概念还成不成立，我自己也没完全想清楚。也许它正在变成一种完全不同的实践，只是我们还在用旧的名字叫它。