很多开发者第一次使用 ChatGPT Codex 修 Bug 时工作方式通常是这样的发现报错 ↓ 复制错误信息 ↓ 发给 AI ↓ AI 猜原因 ↓ 复制代码 ↓ 自己运行 ↓ 发现还报错 ↓ 继续问 AI这种方式当然能用。但如果长期使用 ChatGPT Plus、ChatGPT Pro 和 Codex 做真实项目就会发现真正高效的 AI Debug不应该依赖“人不断复制错误给 AI”。更理想的方式应该是发现问题 ↓ Codex 复现问题 ↓ 读取日志 ↓ 定位调用链 ↓ 提出根因 ↓ 修改代码 ↓ 运行测试 ↓ 测试失败 ↓ 继续分析 ↓ 再次修改 ↓ 测试通过 ↓ 检查 Diff ↓ 输出最终报告也就是说让 Codex 从“回答 Bug 的聊天机器人”升级成“参与整个调试流程的工程 Agent”。这篇文章就系统讲一下在 ChatGPT Plus / Pro Codex 的开发流程中如何搭建一套真正可复用的自动 Debug 工作流。一、AI Debug 最大的问题不是不会修而是不会“复现”假设线上出现一个问题用户修改密码以后 旧 Token 仍然可以继续访问接口。很多人的第一句话是帮我修一下旧 Token 没失效的问题。这其实有一个隐藏风险。Codex 可能直接进入读代码 ↓ 猜原因 ↓ 改代码但它没有先确认这个问题真的能复现吗这是 Debug 中非常关键的一步。人类工程师遇到 Bug通常首先会做Reproduce也就是复现。所以更好的 Codex Prompt 应该是调查用户修改密码以后旧 Token 仍可访问的问题。 第一阶段不要修改代码。 请先 1. 找到密码修改接口 2. 找到 access token 校验逻辑 3. 找到用户 session / token version 相关逻辑 4. 尝试通过现有测试复现问题 5. 如果没有测试新增最小复现测试 只有确认问题以后再分析根因。这里最关键的一句话是先复现。因为如果连问题都无法稳定复现后面的修改很可能只是猜。二、Debug 的第一原则先建立 Failure Case一个 Bug 最有价值的状态并不是我知道哪里错了。而是我有一个稳定失败的测试。例如我们发现修改密码以后旧 Token 仍然有效。理想情况下先形成测试it(invalidates old token after password change,async(){constoldTokenawaitlogin(user);awaitchangePassword(user,new-password);constresponseawaitrequest(app).get(/api/profile).set(Authorization,Bearer${oldToken});expect(response.status).toBe(401);});但当前代码可能返回200于是我们就得到Expected: 401 Received: 200现在这个 Bug 变成了可验证问题。这非常重要。因为之后 Codex 所做的修改都可以用这个测试判断到底修好没有。三、不要让 Codex 一看到报错就直接改代码这一点特别重要。例如TypeError: Cannot read properties of undefined很多人直接问帮我修。但undefined可能只是表面现象。真正原因可能是数据库查询失败 ↓ repository 返回 undefined ↓ service 没做处理 ↓ controller 访问 user.id ↓ 报 TypeError如果只修最后一层if(!user){return;}虽然错误消失了但真正的问题可能仍然存在。所以 Debug Prompt 最好要求先定位 Root Cause 不要只修复异常发生的位置。可以直接写请区分 1. Error Location 2. Root Cause 3. Trigger Condition 不要仅在报错位置增加 defensive check 除非确认那里就是正确的业务边界。这个要求非常实用。四、一个 Bug 至少要分成三层来看我通常会让 Codex 区分Symptom Root Cause Fix例如Symptom用户支付成功。但是订单仍然显示pendingRoot CauseStripe webhook 已经收到。但是payment succeeded ↓ order update ↓ database transaction rollback订单状态没有提交成功。Fix可能是修复 transaction scope而不是前端看到 pending 就重新请求 3 次所以以后可以直接让 Codex 输出## Symptom ## Root Cause ## Fix这个结构能明显提升 Debug 质量。五、日志应该怎么让 Codex 看很多真实 Bug 并不能直接通过代码发现。需要结合Application Log Database Log HTTP Log Worker Log Queue Log比如用户付款成功 但是会员没有开通。单看业务代码可能看不出来。这时候需要还原Request ↓ Payment ↓ Webhook ↓ Queue ↓ Worker ↓ Database整个链路。可以让 Codex从日志中按 request id / order id / user id 还原完整调用链。例如 Prompt订单 ID order_123 请搜索相关日志。 按照时间顺序整理 1. 订单创建 2. 支付请求 3. webhook 4. 状态更新 5. 后台任务 6. 最终数据库写入 找出第一个出现异常的位置。注意不是问哪一行报错而是问第一个异常发生在哪里这两个问题差别很大。六、为什么“第一处异常”比“最后一个 Error”更重要例如日志10:21:01 payment webhook received 10:21:02 failed to acquire database lock 10:21:04 retry worker started 10:21:05 order not found 10:21:05 TypeError: Cannot read properties of undefined很多人看到最后一行TypeError就开始修undefined。但真正第一个异常其实是failed to acquire database lock后面的错误只是连锁反应。所以让 Codex 分析日志时可以明确要求不要只看最后一个 exception。 请找出 - First abnormal event - Primary failure - Secondary failures这对于复杂生产问题非常有用。七、给日志加 ID会大幅提高 AI Debug 效率如果你的系统日志只有Payment failedAI 很难判断是哪笔订单。如果日志是Payment failed user_id18291 order_id92818 request_idabc123就完全不同。在微服务架构里尤其推荐request_id trace_id user_id order_id job_id这样 Codex 就可以根据同一个 IDgrep trace_idabc123把不同模块日志连接起来。最终还原API Gateway ↓ Order Service ↓ Payment Service ↓ Queue ↓ Worker这其实就是Observability对 AI Agent 也非常重要。八、不要一次给 AI 5000 行日志如果你手动使用 ChatGPT 分析日志最常见的错误之一就是整份日志全贴进去。里面可能包含Health Check Debug Info Cron Metrics SQL Warning 其他用户请求真正相关的只有几十行。在 Codex 中更好的方式是让 Agent 自己过滤greporder_123app.log或者grepERRORapp.log或者greptrace_idabc123app.log然后进一步缩小范围。本质上还是Filter ↓ Analyze而不是Analyze Everything九、Codex Debug 最强的地方之一它可以直接跑命令相比纯 ChatGPT 对话Codex 的价值之一就在这里。如果只是 ChatGPT你需要自己运行如果是在 Codex 环境里Agent 可以执行例如pnpmtestpytestnpmrun lintgotest./...cargotest然后读取结果继续分析。因此工作流就可以变成代码 ↓ 运行 ↓ 反馈 ↓ 修改形成真正的闭环。十、一定要告诉 Codex测试失败以后不要立即停止非常实用的一句话If a relevant test fails, investigate and continue fixing.翻译成中文就是如果相关测试失败请分析原因并继续修复 不要只报告测试失败。否则有时候 Agent 会修改代码 ↓ 运行测试 ↓ 测试失败 ↓ 告诉你“有一个测试失败” ↓ 结束这显然不是最理想的 Agent 工作方式。更好的要求完成修改以后 1. 运行相关测试 2. 如果失败阅读失败输出 3. 判断是否由本次修改引起 4. 如果相关继续修改 5. 重新运行测试 6. 直到相关测试通过或者确认存在外部阻塞这就形成Fix Loop十一、什么是 Debug Loop可以简单理解成Observe ↓ Hypothesize ↓ Change ↓ Test ↓ Observe Again例如测试失败Codex 判断Cookie path 配置不正确。于是修改 Cookie path然后重新测试仍然失败。再判断测试环境 Domain 不一致。继续修改。直到PASS这就是 AI Agent 真正适合做的工作。因为 Debug 本身就是一个循环推理过程。十二、但是 Debug Loop 必须设置边界如果你只说一直修到成功。Agent 有时可能为了测试通过做出不理想的修改。例如删掉失败测试或者把 expectation 改掉甚至跳过测试所以要明确禁止Do not: - delete failing tests - weaken assertions - skip tests - disable lint rules - hide errors with broad try/catch中文版本禁止 - 删除失败测试 - 降低测试断言 - 使用 skip 绕过测试 - 关闭 lint 规则 - 使用大范围 try/catch 隐藏异常这类约束非常重要。十三、测试通过不代表 Bug 一定修好了这是很多人容易忽略的问题。假设原本测试expect(result).toBeDefined();Codex 修改后通过。但真实业务要求可能是用户只能看到自己的数据。所以更好的 Regression Test 应该验证正确行为而不仅是没有报错。例如expect(response.status).toBe(200);expect(response.body.userId).toBe(currentUser.id);expect(response.body.secret).toBeUndefined();这也是为什么 Bug 修复最好要求新增能够证明原 Bug 被修复的 Regression Test。十四、什么是 Regression Test中文一般叫回归测试最简单理解把这次出现过的 Bug 写成测试防止以后再次出现。例如历史 Bug用户 A 可以通过修改 ID 查看用户 B 的订单。修完以后添加it(prevents users from reading another users order,async(){// ...});以后再有人修改权限逻辑如果漏洞再次出现 ↓ 测试立即失败这对 AI Coding 特别重要。因为 Agent 未来可能重构代码而 Regression Test 是最可靠的边界之一。十五、让 Codex 写测试时不要只说“加测试”最好明确测试什么。比如新增 regression test覆盖 1. 正常登录 2. 修改密码 3. 使用修改前 token 请求接口 4. 预期返回 401 5. 使用新密码重新登录 6. 新 token 可以正常访问这样比增加测试要好得多。因为测试本身也是需求规范。十六、测试可以帮助 Codex 理解业务很多项目文档已经过时。但测试往往非常有价值。因为测试直接描述系统应该如何工作。例如it(does not charge the customer twice for duplicate webhooks)这句话本身就告诉 CodexWebhook 必须支持幂等。所以调查 Bug 时可以明确让 Codex优先阅读相关测试。很多情况下Tests比README更能准确表达真实行为。十七、Debug 时不要默认“测试错了”AI 很容易遇到这样的情况代码和测试冲突。这时候有两个可能代码错了或者测试过时了不能默认其中一个。可以让 Codex如果测试与实现冲突 1. 检查业务需求 2. 检查相邻测试 3. 检查历史接口行为 4. 判断测试是否代表当前预期 不要为了通过测试直接修改 assertion。这样更稳。十八、一个好的 Debug Prompt 应该包含什么我比较推荐Problem Reproduction Scope Constraints Validation Output例如# Problem 用户修改密码以后旧 access token 仍然有效。 # Expected Behavior 修改密码以后 - 当前旧 token 应失效 - 用户需要重新登录 - 新登录 token 正常工作 # Scope 优先检查 - src/auth - src/users/password - auth middleware - auth tests # Process 第一阶段 1. 阅读相关实现 2. 找到 token 校验流程 3. 尝试复现 4. 如果没有测试新增失败测试 5. 确认 Root Cause 第二阶段 6. 实施最小修改 7. 运行 targeted test 8. 如果失败继续分析并修复 9. 运行 auth 模块测试 # Constraints - 不修改 JWT 返回格式 - 不新增依赖 - 不修改无关代码 - 不删除已有测试 - 不通过降低 assertion 让测试通过 # Final Output ## Reproduction ## Root Cause ## Files Changed ## Tests ## Risks这是一个非常适合 Codex 的 Debug 模板。十九、先跑 Targeted Test不要直接全量测试例如大型项目有 6000 个测试。只修logout第一步就运行pnpmtest可能需要大量时间。还会产生海量日志。更合理pnpmvitest logout.test.ts然后pnpmtest:auth再pnpmtypecheck最后必要时pnpmtest形成Targeted ↓ Module ↓ Static Check ↓ Full Suite这和人类工程师的调试方式非常一致。二十、Lint 和 Type Check 也属于 Debug Loop很多人只把unit test当验证。实际上还包括Type Check Lint Build例如 TypeScriptpnpmtypecheck可能发现Property id does not exist on type User | null这可能直接暴露潜在 Bug。Buildpnpmbuild也可能发现import path 错误 SSR 问题 环境变量问题所以完整验证可以是Unit Test Integration Test Type Check Lint Build当然不一定每个小改动全部执行。应该根据风险决定。二十一、不同 Bug 对应不同测试方式例如纯函数 Bug适合Unit TestAPI Bug适合Integration Test用户交互 Bug适合E2E Test数据库问题适合Integration Test Realistic Fixture并发问题适合Concurrency Test所以不要简单要求写个测试。而应该让 Codex判断哪种测试最能证明问题被修复。二十二、并发 Bug 特别适合让 Codex 写复现脚本例如偶尔重复创建订单。单次测试可能永远成功。问题可能来自两个请求同时进入。可以写并发 10 个相同请求观察应该只生成 1 个订单。例如awaitPromise.all(Array.from({length:10}).map(()createOrder({userId,idempotencyKey,})));然后检查数据库最终只有 1 条记录。这类 Bug 让 Agent 自动构建复现环境往往比单纯读代码更有效。二十三、性能 Bug 不能只看代码要有 Measurement例如商品列表很慢。不要直接让 Codex优化一下。先要求建立性能基线。例如当前接口 P50 320ms P95 1.8s或者开发环境平均执行 850ms然后修改后重新测220ms这时候才能证明真的优化了。否则有些“性能优化”只是代码看起来更高级。二十四、SQL Bug 让 Codex 看 Query Plan 往往比猜更有效假设查询越来越慢。可以让 Agent找到 SQL ↓ 运行 EXPLAIN ↓ 检查扫描方式而不是直接给所有字段加索引。因为滥加索引可能带来写入变慢 索引膨胀 维护成本增加Debug 和性能优化的核心还是Evidence也就是证据。二十五、线上 Bug 要区分 Code Problem 和 Environment Problem有一种情况特别常见本地正常 线上失败这时候 Bug 不一定在代码。可能是Node 版本 环境变量 数据库版本 代理配置 时区 文件权限 容器 缓存 依赖版本所以可以让 Codex 对比Local vs Production例如请检查 1. Node version 2. 环境变量 3. DB version 4. package lock 5. timezone 6. reverse proxy 7. runtime configuration不要直接修改业务代码。二十六、最难 Debug 的问题之一环境差异典型开发环境正常 Docker 失败可能因为localhost在容器里指向当前容器自己而不是宿主机。这种问题单纯阅读业务代码意义不大。需要运行环境 配置 网络一起分析。所以好的 Debug Agent不能只懂Code还要能检查Runtime二十七、Bug 修完以后一定要让 Codex Review 自己的 Diff这一环经常被忽略。代码通过测试以后可以继续让它Review the final diff for regressions.并检查是否修改无关代码 是否改变 API 是否增加安全风险 是否遗漏 Edge Case 是否有重复逻辑Prompt 可以写在完成修复并通过测试以后 重新审查最终 git diff。 重点检查 1. 是否存在不必要修改 2. 是否破坏兼容性 3. 是否存在新的 null / error path 4. 是否遗漏测试 5. 是否有更小的实现方式 如果发现问题继续修正。这相当于Self Review二十八、为什么 Git Diff 是 Debug 中非常重要的上下文因为最后你真正要上线的不是Agent 的思考过程。而是Diff。例如4 files changed 31 insertions 12 deletions你应该重点检查为什么修改这些文件如果一个简单 Bug 最后38 files changed一般应该警惕。所以我经常建议Bug Fix 最小修改 Regression Test二十九、ChatGPT 和 Codex 可以怎样配合 Debug我比较喜欢这种分工。ChatGPT解释错误 讨论原因 分析架构 判断修复策略Codex搜索代码 运行命令 修改文件 执行测试 分析 Diff例如碰到数据库死锁先问 ChatGPTPostgreSQL 出现这种 deadlock 一般有哪些常见原因理解原理以后。再让 Codex调查项目中出现 deadlock 的事务调用链 不要直接修改 先定位不同 transaction 的锁顺序。这样效果通常比直接让 AI 乱改。更稳定。三十、ChatGPT Plus 用户怎么提高 Debug 效率Plus 用户不一定需要同时跑很多任务。更重要的是把单次任务做完整。也就是Reproduce ↓ Root Cause ↓ Fix ↓ Test ↓ Review而不是Prompt ↓ Code很多时候一个完整 Debug Loop比连续问 10 个碎片问题更有效。三十一、ChatGPT Pro 用户可以进一步做并行调查对于大型问题可以把Investigation拆成多个方向。例如订单偶发重复扣款可以分别调查Agent A 检查 webhook 幂等性 Agent B 检查数据库唯一约束 Agent C 检查重试逻辑 Agent D 检查前端重复提交然后把结果汇总。这种方式特别适合根因不明确 系统复杂的问题。但并行 Agent 最好先调查不要所有 Agent 同时修改代码。否则很容易互相覆盖。三十二、一个完整 Codex Debug 工作流最终可以整理成Bug Report ↓ Define Expected Behavior ↓ Reproduce ↓ Create Failing Test ↓ Inspect Relevant Code ↓ Inspect Logs ↓ Identify Root Cause ↓ Design Minimal Fix ↓ Implement ↓ Run Targeted Test ↓ Failure? ├─ Yes → Analyze → Fix Again └─ No ↓ Run Module Tests ↓ Type Check / Lint ↓ Review Git Diff ↓ Final Report这已经不再是简单AI 写代码。而是AI 参与软件工程 Debug Pipeline。三十三、我现在比较推荐的 Codex Debug 模板可以直接保存# Bug 描述当前 Bug。 # Expected Behavior 说明正确行为。 # Reproduction 如果已有复现步骤请按照步骤复现。 如果没有 先分析代码并创建最小失败测试。 # Investigation 在修改之前 1. 找到相关调用链 2. 阅读相关测试 3. 检查日志 / 错误 4. 找出最早异常 5. 区分 symptom 与 root cause # Constraints - 优先最小修改 - 不修改无关代码 - 不新增不必要依赖 - 不删除失败测试 - 不降低 assertion - 不使用 skip 绕过问题 - 不通过大范围 catch 隐藏错误 # Implementation 确认 root cause 后实施修复。 # Validation 依次执行 1. failing regression test 2. related test suite 3. type check 4. lint 5. 必要时 full tests 如果相关测试失败 分析并继续修复。 # Review 检查最终 git diff - regression - compatibility - security - unnecessary changes # Final Report ## Reproduction ## Root Cause ## Fix ## Files Changed ## Tests ## Remaining Risks三十四、从“让 AI 修 Bug”升级到“设计 Debug 系统”真正高效使用 ChatGPT Plus、ChatGPT Pro 和 Codex 后会逐渐发现最重要的问题已经不再是怎么问 AI而是我有没有一个可以验证 AI 的工程环境如果项目有稳定测试 结构化日志 Trace ID 清晰模块 自动化脚本 明确预期行为Codex 就很容易形成自主 Debug 闭环。反过来。如果项目没测试 日志混乱 错误被 catch 业务规则没人知道 本地无法复现Agent 也只能不断猜。三十五、结语Codex 真正厉害的不是“猜出 Bug”而是“证明 Bug 已经修好”很多人使用 AI 编程时最关注的是它有没有找到正确答案。但软件工程不是一道只有标准答案的考试题。真正重要的是问题是否能够复现 Root Cause 是否明确 修改是否足够小 测试是否覆盖 是否引入 Regression 最终代码是否可 Review所以我认为 ChatGPT Plus、ChatGPT Pro 与 Codex 在 Debug 场景中真正有价值的工作模式应该是人定义问题 ↓ Codex 调查 ↓ 测试证明问题 ↓ Codex 修改 ↓ 测试验证修改 ↓ Codex Review ↓ 人最终审核最终我们希望得到的不是“AI 说已经修好了。”而是Failing Test ↓ Code Fix ↓ Passing Test ↓ Clean Diff也就是有证据地证明这个 Bug 已经被修复。当 ChatGPT、Plus、Pro、Codex 真正进入日常软件开发以后我认为“会不会写代码”只是第一层。更重要的能力会逐渐变成会不会复现问题 会不会设计测试 会不会分析日志 会不会约束 Agent 会不会建立验证闭环这也是 AI Coding 真正从“生成代码”走向“工程化开发”的关键一步。