如何治理AI多轮编码导致的代码库熵增问题

问题：效率狂欢之后的“代码变异”

用AI编程助手或Agent工作流做开发，几乎所有人都会经历同一个剧本：项目启动阶段效率惊人，两三天就能跑通一个可演示的原型；但随着对话轮次和功能迭代不断累积，代码库开始“变异”，改一个按钮的颜色，后端某个接口莫名返回500；想加一段鉴权逻辑，却发现仓库里已经存在三套互不兼容的用户校验实现，散落在不同文件里。

这不是幻觉，而是规律。可以把这个现象概括为“AI编码的熵增定律”：在缺乏外部干预的前提下，随着人机交互轮次的增加，代码库的混乱程度只会单调上升；想让它回落，必须由工程师持续输入“负熵”——也就是你的架构判断与工程规范。

直接给结论：对AI产出代码的重构与治理，不是可选项，而是高频动作，其频率应高到融入每一次提交之前。但只喊一句“让AI重构一下”没有意义，因为模型并不知道什么是好的架构，它只擅长消除眼前的报错。要真正破局，需要从工具调教、工作流改造、架构思维三个维度同时下手。

一、根因：上下文窗口是物理瓶颈，注意力是有损耗的

很多开发者有一个误区：既然主流大模型的上下文窗口已经达到数十万甚至上百万token，把整个仓库塞进去不就万事大吉了？恰恰相反。即便模型“吃得下”整个代码库，其注意力机制在超长上下文中也会衰减，并存在明显的近因偏置：在第50轮对话里让它修一个bug，它大概率会优先参考第49轮对话中出现过的代码片段，而不是项目根目录下那份定义了全局规范与公共工具的模块。

为了“高效”响应当前这句指令，模型倾向于就地硬写一段逻辑，哪怕同样的逻辑在别处早已实现。这就是重复代码的来源。一个典型场景：一个简单的日期格式化函数，在前端组件里实现了一遍，在后端API层又写了一遍，数据库迁移脚本里还有第三遍，且三遍互不相同，前端用了某个第三方日期库，后端用了另一种库，脚本里则是手写的原生处理。这不仅是美观问题：三处行为不一致、升级不同步、测试不共享，是实打实的维护噩梦。

更隐蔽的劣化还包括：

• 命名漂移：同一个概念在不同轮次被命名为user_check、verifyUser、authGuard，语义逐渐分裂；
• 防御性复制：模型倾向新起函数而不敢改动旧函数，导致调用点越堆越多；
• 规范遗忘：早期定下的目录结构、错误码约定，在几十轮之后被悄悄绕开。

理解根因后，治理思路就清晰了：既然模型的“工作记忆”不可靠，就把关键信息外置；既然单轮产出是局部最优，就用流程强制做全局收敛；既然模型不懂架构，就由人来定义架构、让模型执行体力活。

二、工具调教：为AI建立可靠的外部记忆

1. 维护项目级规范文件。 在仓库根目录放一份机器可读的规范说明（约定固定文件名，主流智能编程工具都会自动读取），内容覆盖技术栈选型、目录结构、命名约定、错误处理范式与禁止事项。其价值在于：每一次新会话，规范都“在场”，不依赖对话历史。示意：

# 项目规范（供AI编码助手读取）
- 技术栈：前端框架A + 状态管理方案B；后端语言C
- 日期处理：统一使用 utils/datetime 模块，业务代码禁止直接引入日期库
- 错误处理：统一抛出 AppError 并携带错误码，禁止裸抛字符串
- 目录约定：公共逻辑必须收敛到 services/ 或 utils/，组件不得内嵌业务请求
- 提交前：运行单元测试与静态检查，任何告警视为失败

2. 任务原子化，会话短周期。 一个对话线程只解决一个问题。长会话是熵增的温床：历史越厚，近因偏置越强。复杂需求先拆解为多个可独立验证的子任务，每个子任务开新会话、带干净的上下文。

3. 先检索，再编码。 要求AI动手前先阅读相关模块与既有实现，并复述“将要改哪些文件、为什么”。让它先输出改动计划，你确认合理后再放行，把审查从“事后挑错”提前为“事前把关”，成本最低。

4. 精选上下文，而非倾倒仓库。 与其把全库塞进上下文，不如人工或借助检索工具挑出真正相关的几个文件。上下文越精准，注意力越集中，就地硬写的概率越低。

三、工作流改造：把收敛动作嵌入每一次提交

1. 提交前重构。 建立硬性习惯：每次提交前，让AI对本次改动做一次局部收敛——消除新引入的重复、合并相似分支、统一命名。注意分工：人给出“往哪儿收敛”的判断（例如“这三段校验合并到validators模块”），模型负责执行与回归。AI不懂架构，但执行机械重构非常可靠。

2. 用测试做安全网。 没有测试的重构是盲飞。建议顺序：先让AI为既有行为补齐单元测试固化现状，再动重构；新增功能先写测试或契约，再写实现。失败用例还能精准圈定问题边界，反过来为AI提供高质量上下文。

3. 在CI里加质量门禁。 把人的判断固化成机器规则：重复代码检测阈值、单函数圈复杂度上限、单文件行数上限、公共模块覆盖率要求，不达标则阻断合并。可借助云平台（如百度智能云）提供的持续集成、代码检查等通用工程能力来落地，把规范从口头约定变成强制约束——对AI和人一视同仁。

4. 人审diff，而非只看结果。 Agent模式下最危险的惯性是“功能能跑就合并”。必须坚持审查每次改动范围：是否越界改了无关文件？是否引入了未声明的依赖？是否出现绕过公共模块的私有实现？

四、架构思维：为AI设计“防熵增”的工程结构

1. 清晰分层与单一职责。 表现层、业务层、数据访问层边界分明，模块间只通过显式接口通信。好处是爆炸半径可控：改按钮颜色只该触碰表现层，鉴权只该有一个入口。分层不是教条，而是给AI划定“活动范围”，压缩模型的自由发挥空间。

2. 公共逻辑单一事实源。 日期处理、鉴权、错误码、分页等高频能力，必须“有且仅有”一个权威实现，并在规范文件中明确禁止旁路。当AI试图就地实现时，门禁与review会把它拦回来。

3. 控制文件与模块规模。 给单文件、单函数设定硬性上限（如单文件不超过400行）。小而专注的文件不仅人易读，对模型也更友好——相关上下文天然聚拢，检索命中率与注意力质量同步提升。

4. 设计文档即外部记忆。 维护一份轻量的架构决策记录（为什么选这个方案、放弃了什么）与模块地图。每个新会话开始时先让AI读这份文档，等于把几十轮对话积累的隐性共识，固化成随时可注入的显性上下文，这是对抗“规范遗忘”最有效的手段。

五、可落地的治理清单

• 根目录维护规范文件，架构调整后同步更新；
• 一个会话一个任务，复杂需求先拆解；
• AI动手前先读代码、先出计划；
• 提交前执行局部重构与回归测试；
• CI启用重复率、复杂度、覆盖率门禁；
• 每个迭代末安排一次全局收敛专项重构；
• 人工审查diff范围，拒绝“能跑就行”。

结语

AI编码的熵增不可避免，但工程的意义就在于对抗熵增。上下文窗口再长也替代不了你的架构判断，生成速度再快也替代不了质量门禁。正确的分工是：人负责定义结构、守住底线，模型负责检索、生成与机械重构。做到这一点，AI产出的就不再是一座随轮次增高的“屎山”，而是一份越写越顺手的工程资产。