以前让 ChatGPT、Codex 改代码任务通常很小。改一个函数。修一个Bug。补一个测试。这种情况下验证也很直接跑对应单测。看一下Diff。确认接口正常。基本就结束了。但现在越来越多任务不是这样。一个需求丢进去以后Agent可能会一次改Controller。Service。Repository。数据库Model。缓存逻辑。消息事件。测试。配置。甚至顺手改掉一部分公共工具类。最后Git里出现二十个文件。三十个文件。五十个文件。这时候最容易产生一个错觉测试都绿了应该没问题了吧真正危险的地方恰恰就在这里。因为随着Agent修改范围越来越大最容易失控的往往不是Agent有没有写错某一行代码。而是这次真正发生变化的地方验证到底有没有全部覆盖到。一、测试通过不等于这次Change已经被完整验证假设Codex这次修改了订单Service。库存逻辑。Redis缓存。事件消息。API返回字段。最后你跑Service单元测试。全部通过。从测试结果看绿了。但真正的问题是你验证的只是Service这一层。这次Change真正影响的却是API。数据库。缓存。消息。上下游消费者。也就是说Change Surface已经扩大了但Validation Surface没有同步扩大。这就是一个很典型的Validation Coverage Gap——验证覆盖缺口。二、以前为什么这个问题没那么明显因为人工开发通常有一个天然限制一次能改的东西不会无限扩大。一个开发者今天可能只改一个模块。几个文件。一个接口。验证范围和修改范围通常比较接近。但Agent不一样。只要上下文足够、权限足够它可以一次搜索几十个文件。改多个模块。批量重构调用链。更新测试。甚至主动修相关代码。效率当然提高了。但与此同时Change Surface扩张速度也远远超过以前。于是一个新的工程问题就出现了Agent修改能力提高以后我们的验证能力有没有同步提高如果没有那开发速度越快积累的验证缺口反而可能越大。三、真正需要先画出来的是Change Surface很多团队验证代码时第一反应是跑哪些测试我反而建议先问这次到底改到了哪些行为面比如一个“订单状态重构”。表面看只是把status从字符串改成枚举。但继续往下看可能会影响数据库持久化。JSON序列化。API返回。消息事件Schema。缓存内容。历史数据读取。定时任务判断。前端状态映射。这时候真正的Change Surface已经远远超过“改了一个字段”。所以Agent改完以后第一步不是马上跑一堆测试。而是先建立Change Map。也就是代码改了哪里 → 行为可能影响哪里 → 谁依赖这些行为。只有这个图先出来后面的验证才知道该覆盖什么。四、Git Diff只能告诉你“改了哪里”不能告诉你“影响了哪里”这是特别容易混淆的一点。Git Diff能看到OrderService.java改了。OrderDTO.java改了。OrderEvent.java改了。但它不能直接告诉你这个DTO字段变化会不会影响移动端旧版本。这个Event变化会不会让下游消费者解析失败。这个Service调整会不会让缓存失效策略变化。所以File Change ≠ Behavior Impact而验证真正应该追踪的是后者。如果只按照“修改文件”决定测试范围很容易漏掉那些代码没有改但行为被间接影响的模块。五、一个很典型的场景测试全绿线上还是坏了比如Agent修改订单取消流程。本地测试包括Service单测。Repository测试。API集成测试。全部通过。上线以后却发现退款消息没有被下游消费。继续排查才发现Agent顺手把一个状态字段从CANCELLED改成CANCELED当前服务测试全部更新了。所以全部绿。但是下游消费者没有改。于是生产事故出现。这个问题不是测试没跑。而是验证范围只覆盖了当前仓库没有覆盖真实契约边界。这类问题以后会越来越多。六、所以验证不能再只按“测试类型”设计传统思路经常是单元测试。集成测试。端到端测试。这些当然重要。但Agent时代我觉得还需要再加一层按Change Surface设计验证。比如这次涉及数据库Schema。那就验证旧数据能不能读。Migration是否安全。涉及消息就验证Producer和Consumer契约。涉及缓存就验证旧Key、新Key、失效策略。涉及API就验证旧客户端兼容。涉及配置就验证不同环境配置是否一致。这样验证才真正和变化对应。七、我更推荐先做一张“Change → Validation”映射表不一定真画成很复杂的表。核心思想就是每一个重要Change至少要对应一个Validation。例如API字段变化→ Contract Test数据库字段变化→ Migration Historical Data Test缓存逻辑变化→ Cache Hit / Miss / Invalidation Test事件Schema变化→ Producer-Consumer Compatibility Test事务逻辑变化→ Concurrency / Rollback Test权限变化→ Permission Boundary Test这种映射最大的价值是防止“改了很多但只验证了最容易验证的部分”。八、Agent最容易制造的一种假象它会顺手把测试也一起改对这件事非常微妙。Agent修改实现以后通常也能同时更新测试。于是最后你会看到代码改了。测试也改了。测试全绿。看起来非常完整。但这里有一个风险实现和测试可能同时朝同一个错误方向变化。比如以前行为是A。Agent把实现改成B。同时又把原来验证A的测试改成验证B。最后测试仍然全绿。但你真正想保持的行为可能其实应该是A。所以面对大范围Agent修改时不能只问测试有没有通过还要问这些测试验证的是原有契约还是只是跟着新实现一起变化了这也是为什么Behavior Baseline。Characterization Test。独立验证会越来越重要。九、验证最好有一部分不由“修改者”自己定义如果一个Agent修改代码。修改测试。定义成功标准。再告诉你“已经全部通过”。那本质上很多验证仍然属于Self Validation。更稳的方式是至少保留一些独立来源。比如旧行为快照。固定Contract Test。外部E2E。真实流量回放。生产样本。独立测试集。这些验证标准不要完全随着当前Change一起被修改。这样才能真正发现Agent是不是把“错误答案”和“测试答案”一起改掉了。十、Change Surface越大越应该分阶段验证如果一次改50个文件不要最后才做一次总验证。更好的方式是阶段A数据结构变化验证数据兼容。↓阶段B核心Service迁移验证业务规则。↓阶段CAPI适配验证Contract。↓阶段D缓存和事件验证副作用。↓阶段E整体E2E验证完整链路。这样每个阶段都有对应Validation Surface。一旦某一步出问题定位也更容易。这和昨天讲的Commit Boundary其实能自然衔接但两件事并不一样。Commit解决的是变更怎么切。Validation Coverage解决的是每一块变更到底验证到没有。十一、别追求“测试数量”要追求“覆盖变化”Agent时代很容易出现新增了100个测试。看起来非常有安全感。但如果这些测试全都集中在Service内部逻辑。而真正变化最大的地方是消息契约。历史数据。权限边界。那测试数量再多也没有解决核心风险。所以我现在更愿意看的是测试是否覆盖了主要Change Surface。而不是一共跑了多少Test Case。十二、给自己看一个指标Validation Coverage Ratio这篇只保留一个指标Validation Coverage Ratio——验证覆盖率可以简单理解为已经有明确验证手段的重要变化面 ÷ 本次识别出的重要变化面总数比如这次Change Map识别出10个关键影响面。其中8个已经有明确验证。2个只是“应该没问题”。那么验证覆盖率 80%。真正危险的就是那两个“应该没问题”。因为线上事故往往就藏在这种没有明确验证手段的区域里。十三、验证覆盖率低最该做的不是继续补代码如果发现Change已经改了很多。但Validation Coverage只有50%。这时候最不应该做的是继续让Agent扩大修改范围。更合理的是先暂停Write。转到Validation阶段。把缺口补出来哪些行为没有测。哪些依赖没有看。哪些边界没有跑。哪些兼容场景还没有确认。只有Validation Surface追上Change Surface以后再继续下一轮修改。十四、一个更稳的Agent Workflow应该长这样我现在更推荐这种顺序Map Change Surface先确认这次可能影响哪里。↓Execute Change开始修改。↓Map Validation Surface列出每个变化对应的验证方式。↓Find Validation Gaps找哪些变化没有验证。↓Add Targeted Validation补定向验证。↓Release再进入交付。这里最关键的一步其实不是Run Tests。而是Find Validation Gaps。因为测试存在不代表验证已经完整。十五、什么情况下最容易出现验证覆盖不上几个信号很明显。第一一次改动跨3个以上模块。第二同时涉及代码和数据。第三同时涉及同步和异步链路。第四存在缓存、消息、第三方依赖。第五Agent顺手改了大量测试。第六Diff看起来已经很难一次Review完。这些情况一旦出现就应该默认验证范围需要单独设计。而不是继续沿用“跑一下现有测试就行”。十六、Plus和Pro怎么判断如果你平时让 ChatGPT、Codex改动范围比较小。一次只是几个文件。验证也主要是单元测试、局部集成测试。这种情况下Plus通常已经够用。因为真正需要解决的还是如何把Change Surface和Validation Surface对应清楚。如果你的工作已经变成一次Agent任务经常改几十个文件。跨多个模块。需要同时分析代码、测试、API、数据库、缓存、消息。还要持续补验证、跑回归、重新定位缺口而且这种任务每天都在发生那就属于长时间、高频、多阶段工程Workflow。这种强度下Pro会更适合。因为更多任务容量可以真正用在长上下文。多轮修改。多轮验证。多模块回归。但前提仍然是你有明确的Validation Strategy。否则Agent额度越高只是让Change Surface扩张得更快验证缺口也可能跟着越来越大。最后Agent一次改几十个文件真正危险的到底是什么不是它一定会改错。而是改动能力已经扩大了但我们的验证能力还停留在原来的尺度。以前一个开发者一天改几个文件跑几个测试大多数时候还能跟得上。现在Codex可以一次改几十个文件。多个模块。多个行为边界。如果验证方式还只是“测试绿了就行。”那迟早会出现Change Surface Validation Surface的问题。所以真正成熟的Agent工程Workflow不只是让AI改得更多、更快。而是每一次Change扩大以后Validation也必须同步扩大。当修改和验证开始一一对应Agent的大范围改动才真正从“高效率风险”变成可控的工程能力。持续分享 Codex、大模型开发与 AI 编程实战内容。长期深度使用各类代码大模型也整理了稳定的Plus/Pro会员订阅渠道有需要可自取。
ChatGPT、Codex工程方法：Agent一次要改几十个文件，为什么真正危险的不是改错，而是“验证覆盖不上”？
以前让 ChatGPT、Codex 改代码任务通常很小。改一个函数。修一个Bug。补一个测试。这种情况下验证也很直接跑对应单测。看一下Diff。确认接口正常。基本就结束了。但现在越来越多任务不是这样。一个需求丢进去以后Agent可能会一次改Controller。Service。Repository。数据库Model。缓存逻辑。消息事件。测试。配置。甚至顺手改掉一部分公共工具类。最后Git里出现二十个文件。三十个文件。五十个文件。这时候最容易产生一个错觉测试都绿了应该没问题了吧真正危险的地方恰恰就在这里。因为随着Agent修改范围越来越大最容易失控的往往不是Agent有没有写错某一行代码。而是这次真正发生变化的地方验证到底有没有全部覆盖到。一、测试通过不等于这次Change已经被完整验证假设Codex这次修改了订单Service。库存逻辑。Redis缓存。事件消息。API返回字段。最后你跑Service单元测试。全部通过。从测试结果看绿了。但真正的问题是你验证的只是Service这一层。这次Change真正影响的却是API。数据库。缓存。消息。上下游消费者。也就是说Change Surface已经扩大了但Validation Surface没有同步扩大。这就是一个很典型的Validation Coverage Gap——验证覆盖缺口。二、以前为什么这个问题没那么明显因为人工开发通常有一个天然限制一次能改的东西不会无限扩大。一个开发者今天可能只改一个模块。几个文件。一个接口。验证范围和修改范围通常比较接近。但Agent不一样。只要上下文足够、权限足够它可以一次搜索几十个文件。改多个模块。批量重构调用链。更新测试。甚至主动修相关代码。效率当然提高了。但与此同时Change Surface扩张速度也远远超过以前。于是一个新的工程问题就出现了Agent修改能力提高以后我们的验证能力有没有同步提高如果没有那开发速度越快积累的验证缺口反而可能越大。三、真正需要先画出来的是Change Surface很多团队验证代码时第一反应是跑哪些测试我反而建议先问这次到底改到了哪些行为面比如一个“订单状态重构”。表面看只是把status从字符串改成枚举。但继续往下看可能会影响数据库持久化。JSON序列化。API返回。消息事件Schema。缓存内容。历史数据读取。定时任务判断。前端状态映射。这时候真正的Change Surface已经远远超过“改了一个字段”。所以Agent改完以后第一步不是马上跑一堆测试。而是先建立Change Map。也就是代码改了哪里 → 行为可能影响哪里 → 谁依赖这些行为。只有这个图先出来后面的验证才知道该覆盖什么。四、Git Diff只能告诉你“改了哪里”不能告诉你“影响了哪里”这是特别容易混淆的一点。Git Diff能看到OrderService.java改了。OrderDTO.java改了。OrderEvent.java改了。但它不能直接告诉你这个DTO字段变化会不会影响移动端旧版本。这个Event变化会不会让下游消费者解析失败。这个Service调整会不会让缓存失效策略变化。所以File Change ≠ Behavior Impact而验证真正应该追踪的是后者。如果只按照“修改文件”决定测试范围很容易漏掉那些代码没有改但行为被间接影响的模块。五、一个很典型的场景测试全绿线上还是坏了比如Agent修改订单取消流程。本地测试包括Service单测。Repository测试。API集成测试。全部通过。上线以后却发现退款消息没有被下游消费。继续排查才发现Agent顺手把一个状态字段从CANCELLED改成CANCELED当前服务测试全部更新了。所以全部绿。但是下游消费者没有改。于是生产事故出现。这个问题不是测试没跑。而是验证范围只覆盖了当前仓库没有覆盖真实契约边界。这类问题以后会越来越多。六、所以验证不能再只按“测试类型”设计传统思路经常是单元测试。集成测试。端到端测试。这些当然重要。但Agent时代我觉得还需要再加一层按Change Surface设计验证。比如这次涉及数据库Schema。那就验证旧数据能不能读。Migration是否安全。涉及消息就验证Producer和Consumer契约。涉及缓存就验证旧Key、新Key、失效策略。涉及API就验证旧客户端兼容。涉及配置就验证不同环境配置是否一致。这样验证才真正和变化对应。七、我更推荐先做一张“Change → Validation”映射表不一定真画成很复杂的表。核心思想就是每一个重要Change至少要对应一个Validation。例如API字段变化→ Contract Test数据库字段变化→ Migration Historical Data Test缓存逻辑变化→ Cache Hit / Miss / Invalidation Test事件Schema变化→ Producer-Consumer Compatibility Test事务逻辑变化→ Concurrency / Rollback Test权限变化→ Permission Boundary Test这种映射最大的价值是防止“改了很多但只验证了最容易验证的部分”。八、Agent最容易制造的一种假象它会顺手把测试也一起改对这件事非常微妙。Agent修改实现以后通常也能同时更新测试。于是最后你会看到代码改了。测试也改了。测试全绿。看起来非常完整。但这里有一个风险实现和测试可能同时朝同一个错误方向变化。比如以前行为是A。Agent把实现改成B。同时又把原来验证A的测试改成验证B。最后测试仍然全绿。但你真正想保持的行为可能其实应该是A。所以面对大范围Agent修改时不能只问测试有没有通过还要问这些测试验证的是原有契约还是只是跟着新实现一起变化了这也是为什么Behavior Baseline。Characterization Test。独立验证会越来越重要。九、验证最好有一部分不由“修改者”自己定义如果一个Agent修改代码。修改测试。定义成功标准。再告诉你“已经全部通过”。那本质上很多验证仍然属于Self Validation。更稳的方式是至少保留一些独立来源。比如旧行为快照。固定Contract Test。外部E2E。真实流量回放。生产样本。独立测试集。这些验证标准不要完全随着当前Change一起被修改。这样才能真正发现Agent是不是把“错误答案”和“测试答案”一起改掉了。十、Change Surface越大越应该分阶段验证如果一次改50个文件不要最后才做一次总验证。更好的方式是阶段A数据结构变化验证数据兼容。↓阶段B核心Service迁移验证业务规则。↓阶段CAPI适配验证Contract。↓阶段D缓存和事件验证副作用。↓阶段E整体E2E验证完整链路。这样每个阶段都有对应Validation Surface。一旦某一步出问题定位也更容易。这和昨天讲的Commit Boundary其实能自然衔接但两件事并不一样。Commit解决的是变更怎么切。Validation Coverage解决的是每一块变更到底验证到没有。十一、别追求“测试数量”要追求“覆盖变化”Agent时代很容易出现新增了100个测试。看起来非常有安全感。但如果这些测试全都集中在Service内部逻辑。而真正变化最大的地方是消息契约。历史数据。权限边界。那测试数量再多也没有解决核心风险。所以我现在更愿意看的是测试是否覆盖了主要Change Surface。而不是一共跑了多少Test Case。十二、给自己看一个指标Validation Coverage Ratio这篇只保留一个指标Validation Coverage Ratio——验证覆盖率可以简单理解为已经有明确验证手段的重要变化面 ÷ 本次识别出的重要变化面总数比如这次Change Map识别出10个关键影响面。其中8个已经有明确验证。2个只是“应该没问题”。那么验证覆盖率 80%。真正危险的就是那两个“应该没问题”。因为线上事故往往就藏在这种没有明确验证手段的区域里。十三、验证覆盖率低最该做的不是继续补代码如果发现Change已经改了很多。但Validation Coverage只有50%。这时候最不应该做的是继续让Agent扩大修改范围。更合理的是先暂停Write。转到Validation阶段。把缺口补出来哪些行为没有测。哪些依赖没有看。哪些边界没有跑。哪些兼容场景还没有确认。只有Validation Surface追上Change Surface以后再继续下一轮修改。十四、一个更稳的Agent Workflow应该长这样我现在更推荐这种顺序Map Change Surface先确认这次可能影响哪里。↓Execute Change开始修改。↓Map Validation Surface列出每个变化对应的验证方式。↓Find Validation Gaps找哪些变化没有验证。↓Add Targeted Validation补定向验证。↓Release再进入交付。这里最关键的一步其实不是Run Tests。而是Find Validation Gaps。因为测试存在不代表验证已经完整。十五、什么情况下最容易出现验证覆盖不上几个信号很明显。第一一次改动跨3个以上模块。第二同时涉及代码和数据。第三同时涉及同步和异步链路。第四存在缓存、消息、第三方依赖。第五Agent顺手改了大量测试。第六Diff看起来已经很难一次Review完。这些情况一旦出现就应该默认验证范围需要单独设计。而不是继续沿用“跑一下现有测试就行”。十六、Plus和Pro怎么判断如果你平时让 ChatGPT、Codex改动范围比较小。一次只是几个文件。验证也主要是单元测试、局部集成测试。这种情况下Plus通常已经够用。因为真正需要解决的还是如何把Change Surface和Validation Surface对应清楚。如果你的工作已经变成一次Agent任务经常改几十个文件。跨多个模块。需要同时分析代码、测试、API、数据库、缓存、消息。还要持续补验证、跑回归、重新定位缺口而且这种任务每天都在发生那就属于长时间、高频、多阶段工程Workflow。这种强度下Pro会更适合。因为更多任务容量可以真正用在长上下文。多轮修改。多轮验证。多模块回归。但前提仍然是你有明确的Validation Strategy。否则Agent额度越高只是让Change Surface扩张得更快验证缺口也可能跟着越来越大。最后Agent一次改几十个文件真正危险的到底是什么不是它一定会改错。而是改动能力已经扩大了但我们的验证能力还停留在原来的尺度。以前一个开发者一天改几个文件跑几个测试大多数时候还能跟得上。现在Codex可以一次改几十个文件。多个模块。多个行为边界。如果验证方式还只是“测试绿了就行。”那迟早会出现Change Surface Validation Surface的问题。所以真正成熟的Agent工程Workflow不只是让AI改得更多、更快。而是每一次Change扩大以后Validation也必须同步扩大。当修改和验证开始一一对应Agent的大范围改动才真正从“高效率风险”变成可控的工程能力。持续分享 Codex、大模型开发与 AI 编程实战内容。长期深度使用各类代码大模型也整理了稳定的Plus/Pro会员订阅渠道有需要可自取。
