ChatGPT、Codex工程实录：能跑不代表能交，交付前必须补上的最后一段验证链

最近用 ChatGPT、Codex 做真实项目时我越来越明显地感觉到一件事Agent把代码做完和这个任务真的能交付中间其实还差很远。最典型的情况就是代码改完了。本地能跑。测试也通过了。Diff看起来没什么大问题。于是很容易得出一个结论这个任务应该已经完成了。但真正进入CI、测试环境甚至生产前问题才开始冒出来数据库Migration执行顺序不对。新配置没有准备。Docker镜像缺少依赖。旧版本数据不兼容。某个环境变量没配置。服务虽然启动成功但关键接口实际上不可用。甚至最麻烦的一种上线以后才发现根本没办法安全回滚。所以真实工程里能跑不等于能交。真正缺失的往往是最后一段Delivery Validation Chain——交付验证链。一、“代码完成”其实只是交付链的中间节点假设让Codex完成一个功能给订单服务增加批量取消能力。Agent可能完成代码实现 ↓ 单元测试 ↓ 本地验证 ↓ 任务完成从开发角度看没有明显问题。但真正交付时还要继续回答新接口能不能在目标环境启动数据库有没有变化历史订单还能不能正常读取旧客户端是否兼容配置是不是已经准备监控能不能看到异常如果新版本出问题能不能回退这些问题都不是“代码能不能运行”能够回答的。所以真正的链路应该更接近实现 ↓ 代码验证 ↓ 构建验证 ↓ 环境验证 ↓ 数据验证 ↓ 运行验证 ↓ 回滚验证 ↓ 交付少任何一段都可能形成上线后的盲区。二、第一个容易漏掉的是目标环境和开发环境不是一回事本地能运行最容易给人一种安全感。但真实环境可能有完全不同的Java / Node / Python版本。系统库。CPU架构。环境变量。网络权限。数据库版本。依赖服务。比如本地Node 22CI里却还是Node 20代码语法没有问题本地测试全部通过到构建阶段才失败。所以交付前第一件事不是“再跑一次本地测试”。而是确认Target Environment是否真的能够承载这次变更。三、第二个容易漏掉的是数据库变化Agent特别容易把代码修改完成理解成整个功能完成。但如果任务包含字段新增。索引修改。Schema调整。数据迁移。真正危险的地方可能根本不在代码。例如新代码开始读取refund_status测试数据库已经有这个字段。但正式环境Migration还没执行。结果应用一启动就报错。还有一种更危险Migration确实能执行但需要锁大表几十秒。代码本身完全正确上线照样可能造成事故。所以涉及数据库时至少要验证Migration能否成功 ↓ 旧数据能否兼容 ↓ 执行耗时是否可接受 ↓ 旧版本还能不能运行 ↓ 必要时能不能回退四、第三个问题测试通过不代表关键业务路径真的可用测试往往验证的是已经写出来的场景。但真实交付需要验证用户真正会走的那条链路。比如支付功能测试已经全绿。但真正上线以后流程是API ↓ DB ↓ Kafka ↓ Consumer ↓ 第三方支付 ↓ Callback单元测试可能只覆盖API Service。于是测试全绿真实链路仍然可能失败。所以交付前最好至少做一次Smoke Test——冒烟验证。不是把所有测试重新跑一遍。而是挑最关键的真实路径登录。下单。支付。退款。关键后台任务。确认它们在目标环境真正能够走通。五、配置也是交付的一部分很多功能上线失败不是代码问题。而是配置没有同步。比如新功能依赖PAYMENT_V2true开发环境有。测试环境有。生产环境没有。或者配置中心已经增加了Key但部分实例仍然没有刷新。于是代码本身完全正确上线后的行为却不一致。所以交付验证里必须单独有一项Configuration Readiness至少确认配置是否存在。默认值是否安全。不同环境是否一致。Feature Flag初始状态是什么。配置变化失败时会发生什么。不要等发布以后再问“这个配置生产上有没有”六、依赖服务也必须纳入验证链假设新版本需要调用一个新的内部服务。开发环境接口正常。但生产环境可能DNS不同。网络策略没放行。鉴权Token缺失。访问白名单没配置。这时候服务本身能够正常启动。Health Check甚至也是绿的。只有真正走到业务请求时才失败。所以Service Started ≠ Feature Available交付前要验证的不只是应用有没有起来。还要验证它依赖的关键资源是不是真的可以访问。七、还有一个容易被忽略的问题可观测性准备好了吗假设新功能上线以后出现错误。你至少应该能回答哪一批请求失败失败在哪一层新版本错误率有没有上升Latency有没有变化数据库负载有没有异常如果这些都看不到即使功能本身能跑也不能算真正具备稳定交付条件。因为出问题以后你甚至不知道问题到底在哪。所以复杂任务交付前最好同时确认日志。Metrics。Trace。关键业务指标。是不是已经覆盖新的执行路径。八、真正容易翻车的是只验证“正向发布”没验证“回滚”很多团队的交付检查做到这里新版本启动成功。测试通过。接口正常。然后就结束了。但真正上线前还有一个问题必须问如果10分钟以后发现问题怎么退例如新版本已经写入新字段。写入新状态。发送新版消息。修改缓存格式。然后你把应用回滚到旧版本。旧版本还能不能理解这些数据如果不能代码可以回滚。系统状态却回不去了。这时候所谓Rollback其实只是把旧代码重新启动。并不是真正意义上的可恢复。九、所以交付前应该有一条“最后验证链”我现在比较推荐让 ChatGPT、Codex 在任务结束后不要直接说已完成。而是再跑一次交付检查1. Build目标环境能否构建。2. Test单测、集成测试是否通过。3. Migration数据库变化是否安全。4. Configuration生产所需配置是否齐全。5. Dependency外部和内部依赖是否可访问。6. Smoke核心业务链路能否走通。7. Observability新功能出现问题能否被发现。8. Rollback失败以后是否真的能够退回。这8项通过以后才更接近Deliverable。十、最好让Agent输出“交付证据”而不是一句“测试通过”比如任务结束时输出Delivery Evidence Build PASS Tests 128 passed Migration 已在测试库执行 耗时4.2s Config 3个新增配置已确认 Smoke 下单 / 取消 / 查询通过 Monitoring 新增错误率和Latency指标 Rollback 旧版本可读取新版本数据这种结果比所有测试已经通过。有用太多。因为它直接告诉Review的人这次任务到底验证到了哪一层。十一、ChatGPT、Codex特别容易停在“代码完成”原因其实很简单。Agent最容易观察的是代码。测试。命令执行结果。这些信息都在当前开发环境里。而真正交付还涉及部署平台。配置中心。数据库。网络。监控。运行环境。这些东西如果没有提供给Agent它就很容易默认Code Complete Task Complete所以复杂工程任务开始时最好直接告诉它代码实现完成后不要结束继续检查构建、配置、Migration、关键链路和回滚条件并输出交付验证结果。这样任务边界就会从开发完成延伸到交付准备完成。十二、给自己看一个指标交付回滚率这篇我建议只看一个核心指标Delivery Rollback Rate——交付回滚率可以简单理解为因交付前未发现的问题而需要回滚的发布次数 ÷ 总发布次数例如一个月发布20次。其中3次因为配置遗漏。Migration问题。运行环境不兼容。真实链路失败而紧急回滚。那么交付回滚率 15%。这个指标长期偏高通常说明问题不只是代码质量。而是开发验证和交付验证之间存在断层。十三、交付回滚率高先检查什么我会优先看是不是只验证本地。目标环境有没有验证。数据库Migration有没有提前演练。生产配置是不是发布前才临时确认。有没有核心Smoke Test。监控是不是上线以后才补。Rollback是否真正测试过。如果这些步骤长期缺失让Agent写得再快最后也可能只是更快地产生“开发完成、交付未完成”的任务。十四、Plus和Pro怎么判断如果你的ChatGPT、Codex任务经常出现代码做完了。测试也通过。但到了CI、测试环境、发布阶段又不断返工那当前真正限制效率的通常不是AI容量。而是交付验证链还没有建立。这种阶段 Plus 通常已经够用。先把Build。Migration。Config。Smoke。Monitoring。Rollback这些步骤固化下来收益会更明显。如果这些机制已经非常成熟Agent完成开发以后能够自动进入交付检查。关键Evidence能够自动收集。Rollback也经过验证。交付回滚率长期较低。同时还有大量成熟工程任务等待执行这时候 Pro 才更容易放大效率。因为增加的AI容量最终能够真正转化成可交付的工程产出。最后“代码能跑了。”在真实项目里其实只是一个中间状态。真正值得交付的任务应该继续回答能不能构建目标环境能不能运行数据库安全吗配置准备好了吗依赖能访问吗关键链路真的能走通吗出了问题能不能发现最后能不能安全回滚所以以后让 ChatGPT、Codex 做完一个复杂任务后不要只问“测试通过了吗”再补一句“现在有什么证据证明这个版本已经真的可以交付”当这条最后的验证链补上以后Agent完成的才不只是能运行的代码。而是真正能够进入下一阶段的工程结果。持续分享 Codex、大模型开发与 AI 编程实战内容。长期深度使用各类代码大模型也整理了稳定的Plus/Pro会员订阅渠道有需要可自取。