Dmitry Buykin：当编码智能体快过审查，如何维护代码

编码智能体让代码变得便宜，也让混乱更容易产生。项目增长到我无法理解时，我删除了未使用的测试和样板代码并重写项目，结果损失了一些有用内容。智能体继续写代码后，混乱又回来了。我找到的另一条路是每周小规模清理，并在系统中建立反馈。

要避免变更数量超过检查能力，首先得知道什么叫正确。以修改已批准订单的金额为例：一个智能体编写指令，另一个在生产环境中执行。我们的系统覆盖 110 个国家、约一万种场景。变更通常只留在一个切片内，也就是一个国家的一项流程。

我估计系统四分之三是自然语言指令，因此它们也需要工程化。我们试过变异测试：故意改坏一个句子，看测试是否失败。几乎没有测试报错。智能体很容易重写内容，难的是知道哪些东西必须保留。代码可以用测试辅助判断，业务指令则需要人来判断。

智能体容易修复看得见的问题，却破坏一致性；人也会疲劳。我们把专家判断留给真正需要它的地方。业务指令要求“与团队确认”时，开发者会借助编码智能体查看运行轨迹，判断能否自动化。在订单例子中，由于可连接的数据有限，团队负责人仍需亲自决定。

业务专家了解规则，开发者了解底层系统之间的联系。我们让智能体记录这些联系，以便运行时检查。给专家的指南把分工说得很简单：业务人员说明要做什么，开发者解决如何做。

我们为两类读者维护同一份文档。智能体需要准确的指令块，专家则阅读并签署周围的说明；另存一份会逐渐产生偏差。专家也需要能读懂的代码说明，并按照智能体看到任务的方式审查。专家的意见成为下一次修改，并用同一任务测试。

专家逐项纠正任务，智能体却整天使用同一批指令。我们追踪接受和拒绝的结果，找出仍需要人审查的地方。一处指令可能把限额写成 1,500，代码却写成 1,000：同一订单会在一处通过、另一处被拒，而且不会抛出错误。

即使写着“不调用某工具”，提到它本身也可能让模型知道该工具存在。自然语言没有编译器，所以我们建立检查，将变更文件的检查结果记入台账。但检查不能阻止副本产生偏差，因此我们还观察智能体在指令中走过的路径。

当相同路径反复出现，我们把它变成工作流工具，删除原来描述路径的文字。第一批工具曾让情况变差，因为指令仍列出了工具内部步骤，智能体于是又运行了一遍。现在文字只保留决策；只有跨国家重复且一致的路径才变成代码。

变化的部分保留为可读的自然语言，并放在开发者维护的框架中。代码准备事实并执行结果，专家维护决策表，模型负责选择一行；没有匹配项就交给人处理。用工作流连接模型的小决策是下一步计划，目前还没有建成。

边界可以向两个方向移动。我们把几百行表达式从代码移到文字中，因为专家读不懂代码。正则表达式仍可用于识别关键的单个信号，数量多了则放进配置。判断应留在答案会变化、专家又能查看的地方。

控制从模型看到什么开始。我们曾让模型自己决定加载什么，它加载了所有内容，还因为看到价格而自行增加价格检查。现在由运行时选择任务所需的事实：在这个例子中只提供三个订单事实，完整记录仍留在运行时。

处理大型数据集时，模型传递一个简短的句柄，指向运行时已经持有的数据。运行时在写入前验证句柄和数据一致性，从而缩小上下文。即使模型拿到了正确事实，仍可能造成损害，因此团队在开发阶段和运行时两次控制变更；只有代码能打开写入路径。

写入之前有多道防线，之后还有检查确认结果是否落地。如果写入看似失败、智能体重试，日志会确保操作只执行一次。因此，控制不只是给智能体设置权限。

最初我阅读每一项变更，系统也由此学会了我的习惯。随着变更量超过一个人的能力，我感到精疲力竭，不再阅读每一份差异。智能体可能让技术负责人在几周内就成为瓶颈，而不是等几年，所以我需要一种不依赖一个人大脑的工作方式。

我的第一个指标是：我是否疲惫到无法解释发生了什么。即便仪表盘显示正常，这个警报也可能已经响起，所以我会先停下来修复流程。我还建立工具观察变更及其影响。引入一项新检查前，我们用几千次历史会话回放它；触发比例不到 1%。

单个信号看起来有问题时，我们等待它是否再次出现。多个切片出现相似问题，则需要修复背后的概念。放任智能体自行处理，它可能不断加条件直到今天的任务通过；移除这些条件可以暴露缺口。专家意见变成评估后，智能体会在相关国家切片中查找同类失败。

这些相关切片有意因市场和当地法律而不同，所以只有确认存在同一问题的地方才应用修复。系统可能同时有 10 到 20 个反馈循环。用户需要通过界面直接评价结果，而不必依靠我在用户和智能体之间传话。

每个循环都把工作写入台账。智能体会话结束后会遗忘，因此记忆保存在文件里。我们区分发生过什么和现在什么为真；下一次会话从当前状态开始。问题必须连接到根因，让智能体和检查依据证据行动，而不是依赖错误事实。

检查是限制速度的环节。我的智能体处理一次变更时，近十分之九的时间花在验证上；这也占据我一周中更大比例。我们按照证据能证明什么来排序，真实任务回放最有说服力。结果出来之前先写下什么会推翻判断，每项新检查都必须先故意失败一次才值得信任。

AI 重构可能悄悄丢失某个分支。在订单例子中，如果超过限额的分支丢失，订单可能未经团队负责人批准就通过。我们固定一组真实任务，分别在新旧版本中回放。如果没有真实任务经过某个分支，就没有关于该分支的证据。

第二个智能体依据清单检查工作，但不看作者的推理。六个月里，它逐渐承担了我的大部分检查。智能体上下文满时也可能悄悄跳过批次末尾的工作：有一次待办清单看似大多覆盖，实际上只有约四分之一能够关闭。台账让差距显现出来。

选择不只有保留全部内容或一次性删除全部内容。在一项流程的一年演变中，有些分支重新合并，有些仍在漂移，有些已经失效却看上去仍然活跃。一次清理无法阻止重新增长，产生混乱的力量仍在持续作用。

我们为每种增长设立指标、阈值和棘轮：一个只能下降的计数。目前有两个指标在运行，另外六个计划中。每周由真实使用情况决定保留什么；删除任何真实任务没有触及的内容前，先标明它并记录证据。

测试可能让已退役的变体继续存在，因为智能体会保留测试仍然提到的每个选项。现在淘汰一个变体时，也会移除对应测试。每周小规模清理使用了我当初重写时缺少的证据；此后我不必再进行那样的大规模删除。

系统上线后，我发现自己的工程原则已经融入设计。系统的技能和记忆携带着我的习惯与偏见：它会复制纠正它的人。我为六个方面各准备了三个问题，建议从你的代码库尚无法回答的一个问题开始。在还来得及阅读变更时，就建立这些反馈循环。