很多人说 AI 会让软件开发变得便宜得多。他们想象模型会取代工程师，在几分钟内完成任务。这个故事很诱人，但并不完全属实。构建软件的经济模式发生了转变，而非消失。当第一个编程助手问世时，技术债并没有蒸发，我们只是找到了另一种为其融资的方式。

旧账单：人员编制

几十年来，技术债创造了一个熟悉的“末日循环”。代码库会变得脆弱。曾经需要几天完成的功能开始需要几周。截止日期不断推迟，于是领导层开始增加招聘需求。规模更大的团队反而让进度进一步放缓。协调开销激增，站会（stand-ups）成倍增加，康威定律（Conway’s Law）开始显现：软件开始反映出构建它的那些人之间的沟通障碍。更多的 Bug 溜了进来。每一次补丁都增加了新的复杂性。公司只能用他们唯一熟悉的货币来为这种腐烂买单：人力薪酬。成本是显而易见的，它在每一次季度预算审查中都清晰可见。

新账单：Token 与上下文

生成式 AI 并未打破这一循环。它只是引入了一种替代的支付方案。公司不再通过雇佣五名工程师来应对阻力，而是通过刷信用卡来购买更多的算力。症状看起来不同，但潜在的病因是一样的。

当模型开始出错时——幻觉出内部 API、遗漏关键的边缘情况、生成因错误原因而通过的测试——人们的本能反应很少是重构。本能反应通常是花钱进行推理（inference）。团队购买上下文窗口（context-window）升级，缝合多智能体（multi-agent）重试循环，将工作负载提升到更大的前沿模型（frontier models），或者不断点击“重新生成”按钮，直到 diff 看起来可以接受。这些策略在几个冲刺（sprint）内维持了表面的开发速度。Jira 看板保持着绿色。与此同时，实际的架构却未曾触动：同样的纠缠不清的依赖关系，同样的易变全局状态，以及当前团队中没有人能完全理解的同一种单体架构（monolith）。

为什么脏代码会消耗 Token

大语言模型在面对清晰的抽象时推理效果最好。然而，大多数企业级代码库更像是考古现场。它们包含循环的包依赖、埋藏在初始化脚本中的隐藏副作用，以及散布在数据库触发器、中间件层和前端组件中的业务逻辑。在这种环境下，模型并不会把精力花在编写新逻辑上，而是把 Token 消耗在了理解上。

128,000 Token 的上下文窗口中，很大一部分会被用于在内存中维持系统的轮廓。剩下的部分才是真正用于解决问题的内容。这就像要求一名结构工程师在每次计算前，都必须凭记忆重新绘制现有建筑的蓝图，然后再设计一个新楼层。结果就是方案浅尝辄止。模型反映了它所看到的混乱，因为它缺乏先清理房间的权限或架构上下文。

输出更快，交付更慢

原始生成速度并不等同于交付速度。如果你的架构缺乏模块化，每一次 AI 生成的变更都需要详尽的人工审查和回归测试。一个模型可以在一个下午产生十个拉取请求（pull requests），但这些拉取请求仍需经过集成环境、安全扫描、合规性检查和生产环境金丝雀测试（canaries）。如果没有清晰的模块边界，AI 会以机器的速度引入 Bug。它可能会修改一个共享工具类，以微妙的错误假设更新三个遥远的调用点，并引入只有在凌晨三点被叫醒时人类才能发现的竞态条件（race conditions）。瓶颈从键盘转移到了验证流水线，而该流水线的设计初衷并非为了处理十倍增长的变更量。

隐藏的天花板

在前 AI 时代，硬性限制是你的招聘预算。这至少在电子表格上很容易读懂。而现在的约束则埋藏在大多数财务团队几乎不追踪的项目中：推理成本、embedding 存储、上下文窗口扩展，以及让 CI 运行器陷入瘫痪的自动化测试僵局。当每个新功能的真实成本在悄然复利增长时，生产力仪表盘却依然闪烁着绿光。

架构熵才是真正的元凶。LLM 虽然能出色地扩展代码生产规模，但它们并不能降低复杂度。它们无法理顺微服务，无法消除死代码，也无法简化继承层级。一旦系统跨越了人类难以对其进行逻辑推理的阈值，AI 也会陷入困境。在那个拐点，无论你...