AI时代的软件熵增：一个月40万行代码后的崩塌

一位来自巴西的Principal Software Engineer在博客中记录了一次AI辅助开发实验：一个月内产出超过40万行代码、150个功能、240个修复和50次重构，随后开发速度崩塌，系统熵值加速积累。他的结论是，如果没有专业工程师持续构建和强化约束机制，AI编码的代码库注定走向失控。

什么是软件熵增

作者将热力学中的熵概念引入软件开发：熵是系统自然趋向无序或不确定性的倾向，软件熵增则是任何软件系统在持续增长过程中走向混乱的必然趋势。

新增功能、新模块、紧急修复、快速交付的取巧方案，无论事先设计了多么完善的六边形架构、可组合模式，都无法预先覆盖所有用例。熵增不是缺陷，而是任何成长中系统的基本属性。真正的问题从来不是它是否会发生，而是它发生得有多快，以及你是否具备管理它的机制。

软件熵增的理论根源可追溯至比利时化学家伊利亚·普里高津的耗散结构理论。普里高津指出，开放系统通过持续输入能量和信息，可以在远离平衡态的情况下维持有序结构——生命本身即是例证。软件系统同样如此：它天然趋向混乱，但通过持续的工程投入（代码审查、重构、测试、架构治理）可以维持局部有序。一旦这种能量输入中断或不足，系统便会加速滑向无序。Meir Lehman在1980年代提出的软件演化定律也印证了这一观点，其中“复杂度持续增长定律”指出，除非有主动的维护工作来对抗，否则系统复杂度会随演化不断上升。这解释了为什么AI加速代码生成时，如果监督和约束的“能量输入”没有同步增加，熵增就会被急剧放大。

AI如何加速软件熵增

作者带领两名设计师，利用AI生态开发一款全新的聊天体验产品。在写第一行代码之前，他先对齐了范围、契约和整体架构，包括技术栈、仓库结构、架构指南，以及为AI代理准备的上下文文件和技能配置。

起步阶段进展顺利，功能一个接一个地增加，测试覆盖和项目规范似乎都得到了遵守。三周后，代码库超过40万行，包含大量动画和微交互，这些若由工程团队手工完成可能需要多个冲刺周期。但问题开始集中爆发：每个功能的开发速度开始下降，新行为与旧状态交互后竞态条件激增，一个新功能可能破坏三个已有功能，原本几小时能完成的功能现在需要数天。

据B站UP主和YouTube频道对同一话题的讨论，这种“先快后崩”的曲线并非孤例。多位开发者反馈，AI生成代码在前期带来明显的速度幻觉，但在缺乏架构约束时，债务积累速度远超人工编写。

熵增的量化证据

作者的个人实验与多项行业研究相互印证。据2025年DORA《AI辅助软件开发状况》报告，AI采用率每提升25%，交付稳定性下降7.2%，因为AI让开发者生成代码的速度大幅加快，导致批次变大，审查变慢，系统不稳定性上升。

New Relic的2026年AI编码状况报告调查了200位技术负责人，94%的人认为AI生成代码在审查时质量更高，但78%的人报告上线后事件增多，82%的人在过去六个月经历至少一次与AI生成代码相关的生产故障。他们称之为“代理债务”——未经审查的架构逻辑快速累积，最终引发生产事故。

一项覆盖34项研究、2847名开发者的系统性综述发现，每1000行AI生成代码会让技术债务本金增加1.8人天，若不加干预，债务比率在六个月内翻倍。

据arXiv论文《Beyond the 'Diff'》的定义，代理熵是一种系统性漂移，传统的基于代码差异和人类中心可解释AI的方法无法捕捉，因为它们只关注局部输出而非全局代理行为。功能检查（例如确认代码能运行）会掩盖更深层的架构违规和安全缺口，制造出快速进展的假象，而漂移在表面之下不断累积。

**代理债务（Agentic Debt）与代理熵（Agentic Entropy）**是AI编码时代新出现的两个关键概念，需与经典技术债务区分。经典技术债务源于人类团队在时间压力下的权衡取舍，通常有明确的决策记录和可追溯的责任人；而代理债务由AI代理在缺乏充分审查的情况下批量生成代码所累积，其特点是分散、隐性且难以定位。代理熵则更进一步，描述的是AI代理行为在全局层面上的系统性漂移——模型可能持续生成看似正确、局部可运行的代码，但其架构决策、命名约定、依赖关系逐渐偏离原始设计意图。传统的代码差异审查只关注单次提交的局部变更，无法捕捉这种全局性的、跨多个提交逐渐累积的架构偏移，因此功能测试通过反而可能掩盖更深层的系统退化。

修复：收紧约束机制

作者采取的修复措施包括四个层面。在AI代理中设置直接指令、特定技能和上下文文件，强制架构模式。引入确定性工具，包括lint规则、流水线验证和自定义检查，在合并前验证架构一致性。建立严格的定期重构周期，主动削减债务本金。最重要的是专家监督——一名专业开发者持续增强指南，判断什么该用什么不该用，如何修复，并纠正AI遵循新的严格规则。

作者强调，如果没有这位专业开发者持续增强指南、理解取舍并主动强化约束，这个代码库注定失败，或者只能被全面重构或降优先级处理。

确定性约束（Deterministic Constraints）与概率性约束的区别是理解修复方案的关键。AI代理的指令、技能文件和上下文提示属于概率性约束——它们影响模型输出的倾向，但不能保证输出一定符合预期，模型仍可能在不同上下文中产生偏离。而lint规则、流水线验证、自定义架构检查属于确定性约束——它们以二元方式判断结果（通过或不通过），不依赖模型的“理解”或“配合”。在应对代理熵时，仅靠概率性约束远远不够，因为熵增本质上是概率性偏差的累积效应。确定性约束在合并前提供硬性闸门，将不可接受的架构违规拦截在代码库之外。两者的组合策略是：用概率性约束引导AI尽可能生成合规代码，用确定性约束确保即使AI偏离也会被拦截，最后由专家监督不断更新规则以覆盖新出现的偏离模式。

代码库的指数级衰退

一个月内发生的一切，相当于多个团队、多名开发者经年累月积累技术债务才能达到的混乱水平——每个新功能破坏三个旧功能。作者称之为代码库的指数级衰退，这不是比喻，而是当熵产生速率以数量级超过人类监督速率时的真实后果。

IEEE Computer Society直言：站在问题AI输出和下游灾难之间的，是软件工程师。具备软件生命周期知识、能够引导和监督AI助手及其输出的工程师，其价值不可估量。

ACM技术政策委员会的TechBrief on vibe coding警告，这种做法常常跳过确保系统安全、可靠和可维护的核心工程实践。主要作者Simson Garfinkel表示，它让开发者效率大幅提升，但也引入了安全漏洞、增加了技术债务，并产生了难以维护的代码。

Gartner预测，到2029年，60%的组织将大规模采用更小的软件工程团队，而2026年这一比例为15%。但更小的团队加AI并不意味着没有工程师，而是工程师需要不同的技能：架构师、监督者、约束构建者。

指数级衰退的数学直觉可以用一个简单模型说明：假设每个新功能平均引入0.3个与现有功能的隐性冲突，且每个冲突使后续功能的开发时间增加2%。当功能数量从10增长到100时，累积冲突数从3增长到30，但每个冲突对开发速度的拖累是非线性的——因为冲突之间会相互作用，产生复合效应。实际观察到的“每个新功能破坏三个旧功能”意味着修复工作量以功能数量的平方级增长，而开发速度则相应呈指数下降。这与人工开发的根本区别在于时间尺度：人类团队在数月内积累的债务，AI辅助开发可能在一个月内完成，使得问题在团队尚未建立应对机制之前就已集中爆发。这也是为什么作者强调必须在早期就建立约束和重构节奏，而非等熵增显现后再补救。

给工程领导者的反思

作者向管理者、工程负责人、VP和CTO提出三个问题。你的组织在朝什么方向设计——是AI写代码、工程师做监督，还是工程师用AI作为工具同时保留架构所有权？你的缺口在哪里——是否有机制检测累积中的软件熵，是否有确定性约束而不仅是指南，是否有工程师能识别AI何时偏离架构意图？你的监督模型是什么——New Relic数据显示62%的技术负责人信任AI生成代码足以直接上线，不做逐行人工验证，这是否是你愿意承担的风险？

结语：工程师仍然必要

作者并不反对代理编码，也不反对非工程师写代码。他的结论是，当前AI工具尚未准备好完全由AI狂热者驱动。工程师将继续存在，这是新常态。我们不应恐惧AI，而应拥抱新工具，理解如何提高生产力，把更多时间投入到战略、功能、设计模式、职业发展、身心健康和家庭中。

一个人在AI辅助下取代整个工程团队的幻觉，只是幻觉。一个月内发生的一切，正是把专业知识从循环中移除的后果：熵加速，速度崩塌，成本复利。软件工程师仍然必要，问题在于，我们是否在建设懂得如何使用他们的组织。