AI作为最好混乱放大器代码熵管理实战详解

时间：2026-06-23 15:48

AI会放大代码库的混乱度，忠实地复现既有坏模式。OpenAI通过将黄金规则编码为lint规则、建立自动清理流程和自纠循环，让AI持续清理自身遗留的技术债。三行重复优于过早抽象，不修改未改代码的文档。不同场景需差异化管理，个人开发者可通过每周园艺时间和基础自动化控制熵增。

一个值得警惕的发现

起初，事情似乎并不对劲——OpenAI 专注于“如何驾驭AI”的研究团队，在实验初期就遭遇了一个棘手的挑战。

AI智能体在编写代码时，会不折不扣地复制仓库中已经存在的模式。即使是糟糕的模式也不例外。

举例来说，如果仓库中存在一个手写的辅助函数，AI会原样再复制一个；如果错误处理方式缺乏一致性，AI会延续这种不一致；如果某个文件的代码行数已经累积到1000行，AI会理所当然地认为文件就该如此庞大。

AI缺乏判断模式优劣的能力——它无法区分哪些是“良好实践”，哪些是“历史遗留的坏习惯”。在它眼中，仓库中存在的任何模式都是“正确的”。

这就是代码熵的体现——代码库的混乱程度会随着时间自然增长，而AI恰恰是这种混乱最好的放大器。

最初，团队尝试了传统方法：每周投入20%的时间手动清理“AI残留”——包括重复代码、不一致的错误处理逻辑以及过时的文档。结果如何？

从本质上讲，这依然是传统软件工程中的技术债务问题，只不过被AI加速了十倍。

OpenAI最终找到的解决方案，借助了一个极其精准的类比——垃圾回收（Garbage Collection）。

在编程语言领域，GC并非等待内存耗尽才一次性清理，而是通过持续、小颗粒、自动的方式回收。技术债务的管理也应遵循同样的理念：

❌ 传统模式：累积6个月 → 一个月的大型重构冲刺 → 再累积6个月 → ...
✅ Harness模式：每天进行小额偿还 → 持续清理 → 债务永不累积

OpenAI定义了几条黄金规则（本质上是一组带有主观判断的机械规则）：

请注意，这些并非写在文档中的“建议”——它们是被编码为lint规则和结构测试的可执行约束。

定期运行后台Codex任务 → 扫描整个代码仓库 → 检测偏差 → 更新质量评分 → 发起重构PR → 大多数情况下1分钟内审查并自动合并。

简而言之，这是让AI来清理AI自身留下的混乱产物。

人类审查发现不良模式 → 更新黄金规则文档 → 将其转化为lint规则 → 自动应用于所有代码 → doc-gardening智能体扫描文档一致性。

一旦人类发现的不良模式被编码为规则，后续的代码生成将自动遵循——无需每次都依赖人工监督。

张汉东在《驾驭工程》（马书）中从Claude Code源码提炼了几条与熵管理直接相关的原则，值得深入探讨。

这听起来有些反直觉——我们不是一直在追求DRY（不重复）原则吗？

但在AI编码的世界中，过早抽象比适度重复具有更大的危险。原因非常实际：

这里基于Claude Code的行为总结出一个实用习惯：AI存在一种倾向——顺手“优化”它经过的代码，添加注释、增加类型、重构命名。表面上看是好事，但实际上增加了diff的噪声，使代码审查变得困难，还可能引入意外的变更。

这条原则本质上就是范围管理：只修改应修改的部分，不要越界干预。