技术债堆成山，一个小改动引发全面崩塌

那天发生了什么

你的项目已经运行了半年，功能逐渐丰富起来。每次需要新功能时，你就让 AI 在现有代码上快速添加。有时候 AI 的方案不太理想，但"能用就行"——你没有时间去把它做得更好。

这样的"凑合"一次两次问题不大。但半年下来，代码里积累了太多的临时方案：同一个逻辑被复制粘贴到了四五个地方，有些绕过性的代码你已经忘了为什么要加，文件越来越长但你能描述的功能并没有增加多少。

某天你想添加一个很小的功能——修改一下价格的显示方式。AI 帮你改了一处代码。你运行一看：价格显示确实变了，但购物车的计算结果不对了。你让 AI 修购物车，修好之后发现订单页面又出问题了。

你开始感到恐慌。试着阅读代码想搞清楚是怎么回事，却发现你已经完全看不懂这些代码了——到处都是补丁和绕过，逻辑分散在十几个文件里，没有任何清晰的结构可循。

每修一个问题就冒出两个新问题。几天之后你不得不接受一个残酷的现实：这些代码已经没救了，你需要从零开始。

这就是技术债累积到临界点的结果。

每一次"先凑合"的选择——复制粘贴而不是提取公共逻辑、堆叠补丁而不是解决根本问题、绕过而不是正面处理——都在给未来的自己埋下一颗小地雷。单个地雷可能没什么，但当地雷密度超过临界值，随便踩一脚就会引发连锁爆炸。

在与 AI 协作时，这个问题尤其容易发生。因为 AI 生成代码的速度很快，你可能在短时间内就积累了大量你并不完全理解的代码。而你不完全理解的代码，是最难维护的。

定期"还债"。 不需要一次性清理所有问题。但在每几轮迭代之后，花一些时间让 AI 帮你审视代码：有哪些重复的逻辑可以合并？有哪些临时的绕过可以用正式方案替代？有哪些过于复杂的部分可以简化？

保持对代码的理解。 你不需要理解每一行代码的细节，但你至少应该能用简单的语言描述"这个模块大致在做什么、数据从哪里来到哪里去"。如果你说不清了，让 AI 帮你解释，然后在这个过程中做必要的简化和重构。

敢于及早推翻。 当你发现一个方向越改越复杂时，不要因为"已经写了很多"而硬撑。及时推倒重来的成本，永远低于在一个注定崩塌的地基上继续加盖的成本。

记住：代码能跑不代表它是好代码。 "能勉强跑"和"能长期稳定跑"之间，隔着的就是你有没有认真对待技术债这件事。