2026-05-14
Question
你在团队里引入了一个 AI Coding Agent，它可以根据 issue 自动改代码、运行测试、提交 PR。
但上线一段时间后发现两个问题：
- Agent 有时只跑了很小范围的单元测试，就认为改动安全；
- 有时又会跑非常重的全量测试，导致反馈很慢、成本很高。
问题：你会如何设计 AI Coding Agent 的 test selection / verification boundary 机制，让它既不过度自信，也不过度测试？
可以从这几个角度回答：
- Agent 应该根据哪些信息判断要跑哪些测试？
- 什么情况下必须扩大验证范围，甚至要求人工确认？
- 如果测试缺失或测试结果不稳定，Agent 应该怎么处理？
- 你会如何评估这个机制是否有效？
Your Answer
我不知道
Review
本次未作答，完整示范回答如下。
Improved Answer
结论先行：AI Coding Agent 的 test selection 不应该只按“改了哪个文件”机械决定，而应该基于改动影响面、风险等级、历史信号和测试可信度，动态决定验证边界。目标是在“足够安全”和“反馈成本可控”之间做工程权衡。
1. 先用改动影响面决定基础测试范围
Agent 至少要分析四类信息：
- 代码 diff：改了哪些文件、函数、模块、接口。
- 依赖关系：被改代码被哪些模块调用，是否影响公共 API。
- 变更类型：
- 文案、注释、样式类改动：可以较小范围验证；
- 业务逻辑、权限、支付、数据写入：需要扩大测试；
- schema、配置、依赖升级、框架升级：通常要更大范围验证。
- 测试映射关系：哪些测试覆盖了被修改模块，例如 test file mapping、coverage、历史失败记录。
所以基础策略可以是：
先跑最相关的单元测试和静态检查，再根据风险决定是否扩大到集成测试、端到端测试或全量测试。
2. 高风险场景必须扩大验证边界
以下情况不能只跑局部测试：
- 改动跨多个模块，影响调用链较长；
- 修改公共接口、数据库 schema、权限逻辑、支付逻辑；
- 修改 shared utils、middleware、基础配置；
- 相关测试缺失或覆盖率很低；
- Agent 自己无法明确判断影响范围；
- 本次改动是 bug fix，但没有新增回归测试。
这时 Agent 应该升级验证范围，比如：
- 从单测扩大到模块级测试；
- 从模块级测试扩大到集成测试；
- 必要时标记为需要人工 review；
- 对高风险改动要求补充 regression test。
核心原则是：不确定性越高，验证范围越大；副作用越严重，越不能自动合并。
3. 测试缺失或不稳定时，不能假装安全
如果没有相关测试，Agent 不能直接说“验证通过”，而应该明确标记：
- 当前缺少自动化测试覆盖；
- 本次只完成了静态检查、构建或手动验证说明；
- 建议或自动补充最小 regression test；
- 如果无法补测试，需要人工确认。
如果测试 flaky，Agent 应该：
- 重跑有限次数；
- 区分是稳定失败还是偶发失败；
- 查看历史 flaky 记录；
- 不把 flaky pass 当作强信号；
- 必要时把 PR 标记为“验证不稳定”。
也就是说，Agent 的输出应该区分：
verified、partially verified、not verified、verification unstable，而不是简单地说 pass / fail。
4. 防止过度测试，需要设置成本和分层策略
为了避免每次都跑全量测试，可以做分层验证：
- 快速层：lint、type check、相关单元测试。
- 中等层：受影响模块测试、关键集成测试。
- 重型层：端到端测试、全量回归测试、性能测试。
Agent 默认从快速层开始。只有当风险信号触发时，才升级到更重的测试层。
同时可以设置：
- 最大测试耗时预算；
- CI 分阶段执行；
- 高风险路径白名单；
- 改动类型到测试集合的规则；
- 历史缺陷数据驱动的测试推荐。
这样可以避免“为了安全永远全量测试”，也避免“为了快只跑一个单测”。
5. 评估机制是否有效，要看缺陷拦截和成本平衡
我会用几个指标评估：
- 漏检率：Agent 标记通过但后续出问题的比例；
- 测试命中率：选中的测试是否真的覆盖相关改动；
- 平均验证耗时：是否比全量测试更快；
- 升级准确率：高风险改动是否被正确扩大测试范围；
- 人工 review 反馈：reviewer 是否经常认为验证不足；
- 回归缺陷数量：上线后是否减少相同类型问题。
最终，这套机制不是追求每次最少测试，而是追求：
低风险改动快速反馈，高风险改动充分验证，不确定时显式升级，而不是让 Agent 自信地假装安全。