AI 就是最好的混乱放大器：代码熵管理实战

作者：袖梨 2026-07-27

一个令人不安的发现

OpenAI 的驭缰工程团队在实验初期遇到了一个意想不到的问题：

智能体会复现代码库里已有的模式——包括坏模式。

如果仓库里有一个手写的辅助函数，AI 会模仿着再写一个。如果错误处理方式不统一，AI 会继续用不一致的方式处理。如果某个文件有 1000 行，AI 就觉得文件可以 1000 行。

AI 不知道哪个模式是"好的"，哪个是"历史遗留的坏习惯"。对它来说，仓库里存在的就是"正确的"。

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

最初，团队每周花 20% 的时间手动清理"AI 残渣"——重复代码、不一致的错误处理、过时的文档。

结果：不具备可扩展性。

这和传统工程里的技术债本质相同，只不过速度被 AI 拉快了 10 倍。

OpenAI 最终找到的解决方案，用了一个非常精准的类比：垃圾回收（Garbage Collection）。

在编程语言中，GC 不是等内存全用光了再一次性清理。而是持续地、小颗粒地、自动地回收不再使用的内存。

技术债管理也应该是这样：

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

OpenAI 定义的黄金规则（有主观意见的机械规则）：

这些不是写在文档里的"建议"，这是编码成 lint 规则和结构测试的可执行约束。

定期后台 Codex 任务 → 扫描全仓库 → 寻找偏差 → 更新质量评分 → 发起重构 PR → 大多数 1 分钟内审查 + 自动合并

这是 AI 在清理 AI 留下的残渣。

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

人类发现的坏模式一旦编码为规则，后续代码都会自动遵守——不用每次都靠人盯着。

张汉东的《驾驭工程》（马书）从 Claude Code 源码中提炼了几条直接相关的原则：

这看起来反直觉——我们不是一直在追求 DRY（Don't Repeat Yourself）吗？

但在 AI 编码的世界里，过早抽象比适度重复更危险。因为：

AI 有一个倾向：顺手"优化"它路过的代码。加注释、加类型、重构命名。

这看起来是好事。但它增加了 diff 的噪音，让 review 变困难，还可能引入意外变更。

这一条其实就是范围匹配：只改该改的，不多管闲事。