5项检查捕获AI生成代码的隐性回归

考虑这样一个场景：一个 Coding Agent 被要求向一个共享的折扣服务添加一个新的促销类型。这个任务看起来很窄。Agent 修改了一个 API 端点，添加了针对性的测试，返回了一个干净的 diff。

然而，任务范围内的每一步都正确，发布的版本却仍然可能改变续订价格、发票总额、账户权限，或者某个依赖同一服务的报表任务。

这就是只围绕任务边界来审查 Agent 生成代码的核心问题。实现细节在 Pull Request 中是可见的，但它的后果可能分布在整个产品中。

一次有用的发布审查需要的不仅仅是一个通过的信号。它需要证据，这些证据从任务的狭窄意图移动到团队计划部署的构建物的更广泛行为——通常称为发布候选版本（release candidate）。

通过任务不等于发布信心

Coding Agent 根据它收到的上下文工作：提示词、仓库指令、选择的文件、工具输出以及已知的测试。这些上下文可能不包含依赖于被修改行为的每个业务流。

同样的边界也适用于传统的审查工具：

Diff 显示仓库中发生了什么变化。

测试套件显示编码的期望是否通过。

静态分析显示是否违反了选定的规则。

安全扫描器显示其检查是否发现了已知类别的问题。

每个信号都是有价值的。没有任何一个能够证明所有现有的产品行为都保持完整。

GitHub 关于 Coding Agent 的负责任使用指南明确指出了人类的边界：生成的输出仍然需要审查和验证。实际问题是，审查者在批准发布之前应该要求什么证据。

以下五项检查构建了一份有用的发布记录。

在做发布决策之前，从任务意图移动到行为比较。

1. 在审查代码之前先定义预期行为

从预期的变更开始，而不是 Agent 生成的实现开始。

写下请求的结果、重要约束以及必须保持不变的行为。对于促销示例，任务可能需要一个新的促销类型，同时保留现有促销的优先级、授权、续订规则和舍入行为。

一份有用的意图声明需要回答四个问题：

• 什么用户或系统结果应该改变？
• 哪些现有行为必须保持不变？
• 哪些接口、数据规则或安全边界适用？
• 当需求模糊时，谁来做出决策？

这防止了一个精心打磨的实现悄悄重新定义任务。它还给审查者提供了一个不依赖于 Agent 自己解释其工作的标准。

保持简洁。目标不是第二份规格说明。而是让预期的变更和受保护的边界足够明确，以便验证。

2. 检查 Diff 以及产生它的路径

最终的 Diff 是必要的，但它不是整个审查面。

在条件允许时，检查 Agent 的工作记录：提示词、仓库指令、读取的文件、运行的命令、选择的测试、工具批准以及假设。这份记录不能确立正确性。它显示了 Agent 考虑过的边界。

例如，对折扣计算的正确修改仍然值得更深入的审查，如果 Agent 从未检查过续订代码、发票生成或权限更新的话。缺失的上下文不是缺陷的证明。它是关于不确定性仍然存在哪里的证据。

还要审查代码中常见的失败模式：

• 不正确的授权或数据访问。
• 不完整的错误处理。
• 意外的 schema 或持久化变更。
• 超出请求范围的变更。
• 只为让失败消失而修改的测试。
• 与产品规则冲突的假设。

正确的问题不仅仅是"这段代码看起来合理吗？"要问："Agent 知道什么？它修改了什么？它没有检查哪些相关上下文？"

3. 运行可复现的检查，并指定人对结果负责

运行可复现的对照：构建、类型检查、linter、策略和安全检查、依赖检查，以及相关的单元、组件、集成和端到端测试。

为验收标准和重要的错误路径添加针对性的测试。然后在修改预期结果之前调查每个失败。

这种区分很重要。一个失败的测试可能表示预期的产品变更、过时的断言、环境问题或真正的回归。Agent 可以帮助调查原因，但不应该在状态变绿之前静默重写测试。

通过的对照回答的是一个有边界的问题：发布候选版本是否满足了运行的检查？它们不显示每个受影响的行为是否有覆盖。

记录运行了什么、跳过了什么以及为什么。"所有测试都通过了"是较弱的证据，因为没有人能说出哪些测试是相关的，或者所需的环境是否不可用。

4. 将变更映射到受影响的业务流

从文件和函数移动到产品行为。

共享服务可以参与在别处实现的客户、财务、管理和报表流。因此，影响边界很少与变更文件的边界相同。

对于促销变更，受影响-flow 映射可能包括：

• 使用促销创建订阅。
• 续订现有订阅。
• 合并账户和活动折扣。
• 计算发票总额和税款。
• 付款后应用权限。
• 导出促销数据用于报表。

使用架构文档、产品负责人、服务关系和领域专业知识来构建此映射。它不是一个自动证明影响的依赖图。它告诉团队哪些已建立的结果值得证据。

该映射还暴露了所有权差距。如果一个变更可能影响计费，但审查发布的人不拥有计费行为，那么发布流程在客户遇到问题之前就发现了协调问题。

5. 将候选行为与生产基线进行比较

测试从团队预期并编码的场景开始。基线比较从已建立的行为开始，然后问发生了什么变化。

将发布候选版本中相关流的受控运行与生产基线进行比较。基线可以是捕获的生产行为或由此派生的受控参考。不要向生产环境发送状态变更的测试流量。 Instead，对差异进行分类，而不是将它们扁平化为单一的通过或失败结果。

一些差异是预期的，因为任务有意改变行为。另一些则揭示了意外影响。审查者需要足够的证据来区分两者，并识别谁确认了每个预期的变更。

当代码变更在本地但产品效果不在本地时，这种比较特别有用。它可以揭示新的促销按请求工作，而现有的续订路径现在计算出了不同的总额。

基线比较也有局限性。生产行为可能包含现有缺陷。测试数据可能不代表每个客户状态。环境可能不同。记录这些约束，而不是将比较呈现为确定性。

保持五个信号分离

团队经常将多项检查合并为一个令人放心的状态。这会移除决策所需的信息。

一份有用的发布记录保留每个层：

没有一层可以替代另一层。一份完整的 Agent 工作记录不能替代测试。绿色的套件不能替代影响分析。基线差异不能解释变更是否预期。

最终决定仍然是人类的且可问责的

在批准发布之前汇总证据：

• 实现是否满足了声明的意图？
• 是否有未解决的审查发现或假设？
• 哪些检查运行了、失败了、通过了或被跳过了？
• 哪些业务流可能受影响？
• 哪些行为与基线不同？
• 哪些差异是预期的，谁确认了它们？
• 哪些差距仍未验证？

Agent 可以收集证据、总结发现并调查失败。它不应该将不完整的上下文变成自动批准。

工程、QA、产品或发布负责人决定发布什么。该负责人应该在发布记录中可见，以及决策背后的证据和剩余不确定性。

目标不是默认不信任生成的代码。而是在风险存在的层级验证变更。Coding Agent 修改文件。发布改变产品。

Originally published on Early: 5 Ways to Check Agent-Generated Code for Regressions.