一场静悄悄的成本转移正在软件行业发生。当大模型把编写代码的边际成本压到接近零，当GPT-6 Luna把单次任务的价格打到几美分，当任何团队都能在一周内复制出功能完备的智能体原型，一个更尖锐的问题浮出水面：这些被廉价复制出来的系统，其全生命周期的运营成本究竟由谁承担？Richard J. Wolff在技术社区发表的长文提出了"判断债务"的概念，指出团队在所有权未明时就开始依赖AI成果，被推迟的责任最终以排查、对账和支持的形式落到并未获得初始收益的团队头上。与此同时，OpenAI的GPT-6 Sol与Anthropic的Claude Opus 5.5在同日发布，定价战背后隐藏着一个反直觉的真相：代码生成越便宜，系统运维越昂贵。
廉价生成的幻觉
如果把软件行业比作建筑业，那么今天的AI工具就像一台可以瞬间打印出整栋大楼图纸的机器。图纸本身几乎免费，但把图纸变成能住人的建筑，需要打地基、通水电、做防水、装电梯，更需要有人在之后的几十年里维护电梯运转、更换老化管线、处理住户投诉。问题在于，行业当前的兴奋点几乎全部集中在"打印图纸"的环节，而对后续几十年的"物业管理"选择性失明。
这种错配在微观层面已经显现。一位开发者用AI工具为十个客户快速生成了十个定制化应用，每个应用都"能用"，但当他需要为这十个应用同时推送安全补丁时，发现每个客户的部署环境、数据结构和权限模型都有微妙差异。自动化部署脚本需要逐一适配，故障排查需要分别进行，退役某个应用时需要确认没有遗留数据。这些工作无法被AI一键完成，反而因为实例数量的增加而呈线性增长。Wolff在文中描述的"副本继承的义务"正是如此：当客户专属部署从1个变为N个，每次安全更新都需要覆盖所有环境的实例，配置一致性、版本追踪、退役识别均需专人负责。
更深层的矛盾在于部门博弈。销售团队签下订单时承诺"快速交付"，技术团队用AI工具兑现承诺，但交付后的运维责任往往落在另一个预算独立的IT部门头上。初始的开发效率提升计入了销售团队的业绩，后续的运维成本却成为IT部门的负担。这种成本转移在组织内部制造了隐蔽的激励扭曲，导致"生得多、养得少"的系统性偏差。
当边际成本趋近于零
经济学中有个经典概念叫"边际成本递减"，指每多生产一单位产品所需的成本随着产量增加而下降。软件行业曾是这一规律的极致体现：复制软件的边际成本几乎为零，这使得微软、谷歌等公司获得了空前的规模效应。但AI生成代码正在把这一规律推向新的极端——不仅复制代码的边际成本为零，连编写代码的边际成本也趋近于零。
这听起来像是技术乌托邦，但历史告诉我们，当某种生产要素的成本骤降，往往会导致该要素的过度使用，并引发其他要素的相对稀缺。十九世纪末，贝塞麦转炉炼钢法让钢材价格暴跌，人们开始用钢建造一切——包括那些用木头或石头更合适的建筑。结果是城市天际线的钢铁化，以及后续高昂的维护成本。今天的AI代码生成正在重演这一幕：因为生成代码太容易，团队倾向于为每个场景生成新的副本，而不是维护一个统一的、可配置的系统。
Wolff提出的"判断债务"概念精准捕捉了这一现象。团队在所有权和审查责任未明确前就开始依赖某个AI生成的成果，被推迟的责任最终以排查、对账、支持或移除的形式出现。这类似于金融领域的"次贷"：借款人获得贷款时感觉良好，但当利率重置、还款压力增大时，才发现自己根本无力偿还。在软件领域，这个"利率重置"的时刻就是系统需要扩展、更新或退役的时刻。
更严重的是，这种债务具有隐蔽性。AI生成的代码往往"看起来能跑"，但其内部可能基于已失效的假设，或者与特定环境的耦合度过高。当使用范围扩大，这些隐藏的问题才会暴露，而此时修复成本已远高于初始开发成本。Wolff警告说，复制的提示词可能基于已失效的假设仍输出"看似合理"的答案，工具可能遇到不同的数据结构和访问边界，导致团队不断"追逐依赖包"。
被补贴的存量与透支的未来
2009年7月，美国政府推出了"旧车换现金"计划，向报废高油耗旧车并购买新车的消费者提供3500至4500美元补贴。计划表面上是刺激汽车消费、提升燃油效率的双赢政策，实际运行却揭示了产业补贴的深层扭曲。布鲁金斯学会2013年的评估显示，该计划带来的38万辆额外汽车销量中，约60%属于"时间转移"——消费者只是把原本计划在几个月后的购车提前了，计划结束后汽车销量迅速回落。更关键的是，每创造一个就业岗位的成本高达140万美元，远高于同期其他刺激政策。
这组数据与今天的AI代码生成热潮形成了令人不安的镜像。AI工具降低了"生成代码"的门槛，就像"旧车换现金"降低了"购买新车"的门槛。结果是大量本不需要更换的系统被替换，本可以统一维护的系统被拆分成多个副本。这些新系统在生成时看似创造了价值，但全生命周期成本可能远高于收益。
劳工统计局对"旧车换现金"参与者的画像显示，受益者主要集中在中高收入群体，低收入群体因无力支付新车首付而基本被排除在外。类似地，AI代码生成的最大受益者也是那些已经拥有技术团队、能够承担运维成本的大公司，而小型团队和个人开发者虽然也能生成代码，却往往缺乏维护这些系统长期运行的资源和能力。这导致技术债务的分布呈现"马太效应"：资源充足的团队能够消化"判断债务"，资源匮乏的团队则可能被债务压垮。
NBER（美国国家经济研究局）的研究进一步指出，“旧车换现金"计划的环境收益被高估了，因为被报废的旧车中很多本来也很少上路，而新车的高销量部分来自于消费者选择了更大、更耗油的车型（因为补贴基于新车与旧车的燃油效率差，而非绝对效率）。这与AI领域的现状惊人相似：团队用AI生成了大量"更智能"的系统，但这些系统的实际业务价值提升有限，反而因为复杂度增加而消耗更多运维资源。Wolff在文中强调，必须区分"工具成功运行"与"任务成功”——API返回200不代表取回了正确数据，测试命令执行完毕不代表bug已修复。
按结果计价的替代方案
“旧车换现金"计划实施期间，曾有经济学家提出替代方案：与其补贴购买新车，不如直接提高燃油税，让市场机制引导消费者选择更高效的车辆。这一方案未被采纳，因为提高税收在政治上不受欢迎，而直接补贴看起来更"亲民”。但学术评估显示，提高燃油税的成本效益比补贴购车高出数倍，且能更精准地激励节能减排行为。
类似地，在AI代码生成领域，也存在被忽视的替代方案。Wolff提出的"按被接受结果的成本"计价模式就是其中之一。当前行业普遍按"每次模型调用成本"计价，这激励厂商生成尽可能多的代码和调用，而不关心这些代码是否真正解决了问题。如果改为按"每个被接受结果的成本"计价，即只有在目标记录已更新、变更通过必要检查、异常已上报、操作员可见结果时才计入成本，那么激励机制将完全改变。
这种计价方式会自然引导团队关注系统的全生命周期成本，而非仅仅关注初始生成成本。它会抑制"为每个客户生成一个副本"的冲动，鼓励构建统一、可配置的系统；它会惩罚那些"看起来能跑"但实际上充满隐藏假设的代码，奖励那些经过充分验证、易于维护的设计。Wolff在文中详细定义了"完成"的标准：目标记录已更新、变更通过必要检查、异常已上报、操作员可见结果。仅生成计划或尝试调用不算完成。
另一个替代方案是建立"判断债务"的显性化机制。在团队开始依赖某个AI生成的成果前，必须明确所有权、审查责任、更新路径和退役计划，并将这些承诺写入项目预算。这类似于金融领域的"压力测试"：在情况良好时模拟最坏情况，确保系统在压力下仍能运行。Wolff提出的四个问题——谁受益谁支持、下一个团队带来什么变化、下一个副本产生什么责任、谁能修改回滚或停止——正是这种压力测试的具体化。
效率与责任的再平衡
历史不会简单重复，但总是押着相似的韵脚。十九世纪的铁路狂热、二十世纪初的电力革命、二十世纪末的互联网泡沫，每一次技术突破都伴随着"建设成本骤降、运营成本被低估"的周期。AI代码生成正在经历同样的周期，只是速度更快、规模更大。
当前行业对AI的兴奋集中在"能做什么"，而对"该做什么"和"做完之后怎么办"关注不足。这种偏差在宏观层面可能导致资源错配，在微观层面则表现为一个个被"判断债务"拖垮的项目。Wolff的文章之所以重要，在于它把讨论从"生成"拉回到了"运营"，从"代码"拉回到了"责任"。
未来的竞争不属于那些能生成最多代码的团队，而属于那些能最好地管理代码全生命周期的团队。这需要技术能力的提升，更需要组织机制的变革：让运维成本在决策时就被显性化，让支持责任在生成时就被明确化，让"判断债务"在积累时就被追踪化。只有这样，AI才能真正成为生产力的解放者，而不是债务的制造者。
代码可以廉价，但运行必须负责。这是技术成熟的标志，也是行业可持续发展的前提。