夜雨聆风
一、软件熵：从Brooks到AI时代
在传统软件工程中，软件熵是一个令人沮丧却真实存在的规律：每一次修改，系统的无序度都会倾向增加。
这种无序，体现为：
模块耦合加深 隐式依赖增多 边界逐渐模糊 缺陷越来越难预测
AI 确实降低了代码生成成本，但它同样降低了“生成糟糕代码”的门槛。当代码变得极其廉价时，熵增反而可能被进一步放大。
大模型出现后，生成代码的边际成本暴跌。但低成本≠低熵。恰恰相反：如图一所示，AI 默认倾向于生成局部正确、全局松散的浅层代码，它们函数庞杂、责任不清、边界模糊。如果人的角色从构建者退化为接受者，熵将以指数级增长。
反馈的速度就是你速度的上限。
如果反馈来自生产环境的崩溃，那你的速度上限就是崩溃的速度。
图一 浅层模块
为什么 AI 偏爱浅层模块？
训练数据中充斥着这类上帝类或工具箱类
生成一个职责单一但边界清晰的深层模块，需要全局理解，AI 天然欠缺
浅层模块允许 AI 一次只生成一个小函数，看似安全，实则让调用方必须理解全部细节
熵在浅层模块间的连接处疯狂滋长：修改一个函数可能影响 30 个调用点，没有人（包括 AI）能安全预测影响范围。
二、逆转熵增：深层模块 + TDD
深层模块的定义（John Ousterhout 在《A Philosophy of Software Design》中提出）：
模块提供简单接口，但内部完成复杂工作。
深层模块的价值 = 接口复杂度 vs 功能复杂度，比值越低越深。
如图二所示，在大模型驱动开发中，深层模块是天然的抗熵单元：
接口少：AI 生成调用代码时不易出错
边界清晰：修改内部实现不影响外部
可单独测试：测试一个深层模块的接口，比测试 20 个浅层函数组合要可靠得多
而TDD的关键，在于控制AI的反馈速率。如果不加约束，AI会以outrunning its headlights的速度大批量生成代码，导致最终产物不可用。Pocock认为反馈速率就是你的速度限制，而TDD要求的写失败测试 、让测试通过 、重构的短周期循环，恰好将反馈周期缩到最短（及时纠错），让AI始终在可控的轨道上运行。
浅层模块的代码库正让开发者和AI双双陷入疲惫（作者最近也有深深的体会）。 当AI快速生成大量功能正确但边界模糊、逻辑脆弱的代码时，开发者不得不在反复调试和审查中消耗远超预期的精力。问题不在AI，而在于我们缺少清晰的分工边界。
战略层面需要明确：人负责顶层架构、安全边界和测试合约，AI负责非关键模块的内部实现。 尤其集成测试与业务边缘场景必须由人把控，因为AI无法感知真实的业务规则与基础设施风险。同时，浅层模块催生了认知债务算法膨胀等新型技术债务。
最终，开发者要从写代码转向教AI写代码。 把可批量生成的样板逻辑交给AI，把创造力与所有权集中在架构设计、边界防御和多环境集成上。唯有重新划定人机分工，才能将消耗式疲惫转化为系统价值。
Pocock, M. (2026, April 23). Software Fundamentals Matter More Than Ever [Video]. YouTube. https://youtube.com/watch?v=v4F1gFy-hqg
