使用 AI Agent 处理真实开发任务时，经常会遇到另一种很明显的低效：

它每改一点代码，就把整套测试重新跑一遍。

常见表现包括：

• 只改了一个小函数，却执行完整测试套件；
• 改一行 → 跑十几分钟测试 → 再改一行 → 又跑一遍；
• 长任务里真正写代码的时间不多，大量时间都花在等待测试；
• 为了避免慢，后来又干脆不测试，结果风险反而更高；
• Agent明明只是局部修改，却始终按照“最终交付”的标准做全量验证。

这类问题的核心不是：

测试跑得太多。

而是：

验证范围没有跟修改阶段和影响范围匹配。

一、不是所有修改都需要立刻跑全量测试

假设Agent只改了：

user.service.ts

里的一个边界判断。

如果每次都执行：

• 全量单元测试；
• 全量集成测试；
• Build；
• Lint；
• Type Check；
• E2E；

当然很安全。

但效率会非常低。

尤其是大型项目，一套完整测试可能需要十几分钟甚至更久。

所以更合理的问题不是：

要不要测试？

而是：

当前这一步应该测到什么范围？

二、验证范围应该跟“影响范围”一起缩放

可以把修改简单分成几类。

小范围局部修改

例如：

• 一个函数；
• 一个组件；
• 一个校验条件。

这时候更适合先跑：

相关单测 + 必要的快速检查。

模块级修改

例如：

• 一个Service；
• 一组API；
• 一个业务模块。

可以扩大到：

模块测试 + 集成测试。

公共核心修改

例如：

• 共享类型；
• 公共组件；
• 核心配置；
• 数据库Schema。

这时候才更有必要扩大验证范围。

也就是说：

改得越广，测得越广。

而不是任何改动都直接从最高级别开始。

三、为什么Agent特别容易选择“全量测试”？

因为从风险控制角度看：

多测一点通常比少测更安全。

所以当Agent不确定影响范围时，它很容易选择最保守的方案：

全部跑。

这种方式单次看没有问题。

但在长任务里，如果每一轮修改都这么做，就会变成：

修改成本很低，验证成本极高。

最终整个任务的瓶颈不再是写代码，而是：

测试等待。

四、修改阶段和交付阶段应该使用不同验证策略

任务进行中，目标是：

快速发现当前方向对不对。

任务结束前，目标才是：

确认整体可以交付。

这两种阶段不应该完全一样。

例如修改阶段可以：

改代码 → 相关单测 → 继续。

而最终交付前再做：

完整测试 → Build → Type Check → Lint → 必要E2E。

这样既保留快速反馈，也不会放弃最终质量。

五、可以建立三层验证结构

一个比较实用的方式是：

第一层：快速反馈

每次小修改以后执行。

例如：

• 当前函数对应测试；
• 当前组件测试；
• 静态检查。

目标是：

几十秒到几分钟内知道方向有没有错。

第二层：阶段验证

完成一个模块或一个子任务以后执行。

例如：

• 模块测试；
• 集成测试；
• 局部Build。

目标是确认：

这一阶段的修改可以稳定成立。

第三层：最终验收

准备提交或合并前执行。

例如：

• 全量测试；
• 完整Build；
• Type Check；
• Lint；
• 必要的E2E。

目标才是：

证明整个任务可以交付。

六、增量测试的关键是“找到真正相关的测试”

如果Agent改了：

payment.service

就应该优先找到：

• payment相关单测；
• payment模块集成测试；
• 直接依赖该逻辑的关键测试。

而不是因为不确定，就直接：

npm test

全跑。

所以Agent在修改前，除了找代码，还应该知道：

这段代码对应哪些测试？

这会直接决定后面的验证效率。

七、什么时候应该扩大测试范围？

如果出现下面这些情况，就值得从局部测试扩大到更大范围：

• 修改了公共模块；
• 改了接口契约；
• 改了共享类型；
• 调整数据库结构；
• 修改了全局配置；
• 局部测试通过，但集成行为异常；
• 修改影响多个调用方。

也就是说，扩大测试范围应该由：

风险信号

触发。

而不是固定每一步都全量运行。

八、全量测试失败时，也不要马上全部重跑

还有一种常见低效：

Agent跑完整测试，发现只有一个模块失败。

修完以后，又从头跑完整套件。

更合理的方式可以是：

先跑失败测试 → 确认修复 → 再决定是否需要全量回归。

否则一个十分钟测试套件，可能因为一个小失败重复执行很多次。

尤其在调试阶段，这种等待成本非常明显。

九、测试结果也应该记录，避免重复验证

Agent长任务里有时会忘记：

哪些测试刚刚已经跑过？

结果同样的命令重复执行。

所以可以让它维护一份简单状态：

已验证：

• user.service.test ✅
• auth.integration ✅

未验证：

• 全量E2E
• Production Build

这样每一步都知道：

当前缺什么证据。

而不是每次修改以后重新从零判断。

十、可以直接这样约束Agent

以后遇到大型任务，可以要求：

请根据本次修改范围选择验证范围，不要每次小改动都跑完整测试。局部修改先运行相关单测或最小验证；完成一个模块后再运行模块级或集成测试；准备最终交付前，再执行全量测试、Build、Type Check和必要E2E。如果全量测试只出现局部失败，先针对失败项修复和验证，再决定是否重新执行完整回归。

这样Agent就能把：

验证质量

和

验证成本

同时考虑进去。

十一、测试越多，不等于反馈越快

这是一个很容易忽略的点。

如果每次反馈都要等十分钟，Agent就很难形成高效迭代。

更好的开发节奏通常是：

小改动 → 快反馈 → 小修正 → 阶段验证 → 最终全量验收。

真正高质量的验证不是：

每一步都做最多测试。

而是：

每个阶段都做最合适的测试。

最后

AI Agent每改一点就跑全量测试，任务越来越慢，本质上不是测试太严格。

而是：

验证策略没有分层。

真正高效的Agent工作流应该根据修改范围和任务阶段，使用不同验证强度：

局部修改用快速测试，阶段完成用模块验证，最终交付再做全量验收。

这样既不会因为频繁全量测试拖慢任务，也不会为了追求速度完全放弃验证。

Agent真正成熟的表现，不只是：

会不会自动跑测试。

还包括：

能不能知道什么时候该跑哪些测试，以及什么时候才值得把验证范围扩大。

---

持续更新 Codex、AI Agent 与大模型开发工作流实战内容，更多深度内容和稳定订阅渠道欢迎搜索关注「孤狼GPT」。