GPT-5.6 + Codex 真正好用的地方：让 Codex 改代码，让 GPT-5.6 做 Diff Review

GPT-5.6 出来以后很多人第一反应是那是不是以后写代码直接让 GPT-5.6 搞定就行了Codex 还要不要单独用两个放在一起是不是就能自动完成项目这个问题不能只看“模型强不强”。真正要看的是开发流程有没有变得更可控。OpenAI 官方页面显示GPT-5.6 面向更复杂的工作流覆盖 coding、knowledge work、research、cybersecurity、computer use、design 等场景同时GPT-5.6 会逐步在 eligible ChatGPT plans 中提供并且官方帮助文档说明若要在 Codex 中访问 GPT-5.6需要满足对应的 ChatGPT desktop app 或 Codex CLI 版本要求。来源https://openai.com/index/gpt-5-6/另外OpenAI 也提到Codex app 正在并入新的 ChatGPT desktop appCodex 仍然是面向开发者的 coding agent并带来 inline editing within diffs、侧边栏 PR review、更快的 computer use、单项目多仓库支持等能力。来源https://openai.com/index/chatgpt-for-your-most-ambitious-work/这说明一个方向GPT-5.6 更适合复杂理解、判断和审查 Codex 更适合贴近仓库执行、修改、运行和整理结果 两者组合后最有价值的不是“自动写完”而是“执行后可审查”。所以这篇不讲“怎么让 GPT-5.6 直接写代码”。我们讲一个更适合真实项目的流程Codex 先改代码GPT-5.6 再做 Diff Review。一、为什么不要让 Codex 改完就直接提交Codex 的强项是贴近仓库执行。它能读取项目文件理解目录结构修改多个文件运行命令生成 Git Diff协助处理 PR在桌面端里做更贴近本地工作流的代码操作。但越是能动手越不能直接信任结果。一个典型任务修复用户中心保存失败时没有错误提示的问题。Codex 可能会改这些文件src/pages/user-center/profile.tsx src/api/user.ts src/components/form/ErrorMessage.tsx tests/user-center/profile.test.ts docs/user-center.md这看起来合理。但真正合并前你还要问它有没有改到任务范围外 有没有改变接口字段 测试是不是真的覆盖了失败场景 错误提示有没有泄露后端敏感信息 有没有顺手改了不该改的配置 如果线上出问题怎么回滚这就是 GPT-5.6 适合发挥的地方。不是让它继续改代码而是让它做审查。二、推荐流程Codex 执行GPT-5.6 审查我建议把流程拆成两层第一层Codex 执行 第二层GPT-5.6 审查完整流程是1. 开发者给出需求和边界 2. Codex 读取仓库并执行修改 3. Codex 输出变更文件、测试命令和执行结果 4. 开发者导出 Git Diff 5. GPT-5.6 读取需求、Diff、测试结果 6. GPT-5.6 输出 GPT56_CODE_REVIEW.md 7. 人工根据报告 Review 高风险文件 8. 再决定是否合并重点是第 6 步。GPT-5.6 的任务不是继续写代码而是回答这次 Codex 改得是否符合需求 有没有越界 有没有测试缺口 哪些文件必须人工看 是否建议合并这比一句“帮我检查一下代码有没有问题”要稳得多。三、先让 Codex 输出 CODEX_EXECUTION_SUMMARY.mdCodex 执行完以后不要只看它一句“已完成”。建议让 Codex 固定输出一份执行摘要。文件名CODEX_EXECUTION_SUMMARY.md示例# CODEX_EXECUTION_SUMMARY ## 1. 任务目标 修复用户中心保存失败时没有明确错误提示的问题。 --- ## 2. 实际修改文件 | 文件 | 修改原因 | |---|---| | src/pages/user-center/profile.tsx | 在保存失败时展示错误提示 | | src/api/user.ts | 统一处理接口错误返回 | | src/components/form/ErrorMessage.tsx | 新增可复用错误提示组件 | | tests/user-center/profile.test.ts | 补充保存失败场景测试 | --- ## 3. 未修改文件 - 未修改 package.json - 未修改 pnpm-lock.yaml - 未修改 .env - 未修改 .github/workflows/** - 未修改数据库迁移文件 --- ## 4. 执行过的命令 bash pnpm typecheck pnpm test tests/user-center/profile.test.ts pnpm build5. 命令结果pnpm typecheck: passed pnpm test tests/user-center/profile.test.ts: passed pnpm build: passed6. 风险点src/api/user.ts涉及接口错误处理需要人工确认是否影响其他调用方错误提示文案需要产品或业务确认测试只覆盖用户中心保存失败场景没有覆盖所有 API 错误分支。7. 回滚建议如出现异常优先回滚src/pages/user-center/profile.tsxsrc/components/form/ErrorMessage.tsxsrc/api/user.tstests/user-center/profile.test.ts这份摘要的价值很大。 它让 GPT-5.6 后续审查时不是只看一堆 Diff而是有上下文 text 任务是什么 Codex 改了什么 跑了什么命令 哪些地方 Codex 自己认为有风险。四、再导出 Git Diff接下来导出 Diff。如果你要审查当前工作区gitdiffHEADcodex_changes.diff如果你只审查已暂存内容gitdiff--cachedcodex_changes.diff如果你想看变更文件列表gitdiff--name-status HEADcodex_changed_files.txt如果你想看每个文件增删行数gitdiff--numstatHEADcodex_numstat.txt建议至少准备 3 个文件CODEX_EXECUTION_SUMMARY.md codex_changes.diff codex_changed_files.txt如果项目比较大再加codex_numstat.txt这样 GPT-5.6 做 Review 时就不会只凭 Codex 的总结而是能同时对照真实 Git Diff。五、给 GPT-5.6 的 Diff Review Prompt把这些文件内容交给 GPT-5.6 后可以这样问下面是 Codex 执行完代码修改后的材料 1. CODEX_EXECUTION_SUMMARY.md 2. codex_changed_files.txt 3. codex_numstat.txt 4. codex_changes.diff 请你不要继续修改代码只做 Diff Review。 请按以下结构输出 GPT56_CODE_REVIEW.md 1. 任务是否完成 2. 改动范围是否合理 3. 是否修改了不该改的文件 4. 是否存在接口兼容风险 5. 是否存在测试缺口 6. 是否存在安全或隐私风险 7. 哪些文件必须人工 Review 8. 是否建议合并 9. 合并前还需要运行哪些命令 10. 回滚建议。 要求 - 不确定的信息标记为“待确认” - 不要编造测试结果 - 不要只说“看起来没问题” - 每个风险点都要对应到具体文件或具体 Diff。这里最关键的是请你不要继续修改代码只做 Diff Review。很多开发者让 AI Review 时AI 会顺手开始修。这会把流程搞乱。Review 阶段的目标不是继续改而是先看清楚。六、GPT56_CODE_REVIEW.md 应该长什么样GPT-5.6 输出的报告可以长这样# GPT56_CODE_REVIEW ## 1. 总体结论 本次 Codex 修改基本符合“用户中心保存失败时展示明确错误提示”的任务目标。 建议状态需要人工 Review 后再合并。 原因 - 页面层改动合理 - 测试覆盖了主要失败场景 - 但 src/api/user.ts 涉及统一错误处理可能影响其他调用方 - 错误文案需要业务确认。 --- ## 2. 变更范围检查 | 文件 | 判断 | 原因 | |---|---|---| | src/pages/user-center/profile.tsx | 合理 | 属于用户中心页面范围 | | src/components/form/ErrorMessage.tsx | 合理 | 新增复用错误展示组件 | | src/api/user.ts | 需要人工 Review | 接口错误处理可能影响其他页面 | | tests/user-center/profile.test.ts | 合理 | 补充失败场景测试 | 未发现 package.json、锁文件、CI/CD、数据库迁移等高风险文件被修改。 --- ## 3. 测试缺口 当前测试覆盖 - 用户中心保存失败 - 错误提示渲染。 可能缺口 - API 返回空错误信息时的兜底文案 - 网络中断时的错误提示 - 其他使用 src/api/user.ts 的页面是否受影响。 --- ## 4. 必须人工 Review 的文件 1. src/api/user.ts - 检查是否改变统一错误处理行为 - 检查是否影响其他调用方 - 检查是否泄露后端原始错误信息。 2. src/pages/user-center/profile.tsx - 检查用户操作路径 - 检查 loading / disabled 状态 - 检查错误提示是否可关闭或覆盖。 --- ## 5. 合并前建议运行命令 bash pnpm typecheck pnpm test pnpm test tests/user-center/profile.test.ts pnpm build6. 回滚建议如果上线后出现错误提示异常优先回滚src/pages/user-center/profile.tsx如果影响多个页面再回滚src/api/user.tsErrorMessage.tsx如未被其他页面使用可一并回滚测试文件随功能回滚。这份报告比“AI 说没问题”有用得多。 因为它把风险点落到了具体文件上。 --- ## 七、用 Python 自动生成 Review 输入包 如果团队经常这么做可以写个脚本自动收集 Codex 执行材料。 新建 text prepare_gpt56_review_pack.py代码如下#!/usr/bin/env python3from__future__importannotationsimportargparseimportsubprocessfrompathlibimportPathdefrun_git(args:list[str],allow_fail:boolFalse)-str:resultsubprocess.run([git,*args],textTrue,stdoutsubprocess.PIPE,stderrsubprocess.STDOUT,checkFalse,)ifresult.returncode!0andnotallow_fail:raiseSystemExit(result.stdout.strip())returnresult.stdout.strip()defensure_git_repo()-None:resultsubprocess.run([git,rev-parse,--is-inside-work-tree],textTrue,stdoutsubprocess.PIPE,stderrsubprocess.STDOUT,checkFalse,)ifresult.returncode!0:raiseSystemExit(当前目录不是 Git 仓库请在项目根目录执行。)defread_optional(path:Path)-str:ifnotpath.exists():return未提供。try:returnpath.read_text(encodingutf-8)exceptUnicodeDecodeError:returnpath.read_text(encodingutf-8-sig)defmain()-None:parserargparse.ArgumentParser(descriptionPrepare a GPT-5.6 review pack after Codex execution.)parser.add_argument(--summary,defaultCODEX_EXECUTION_SUMMARY.md,helpCodex execution summary file.,)parser.add_argument(--base,defaultHEAD,helpGit diff base, such as HEAD, main, origin/main.,)parser.add_argument(--output,defaultGPT56_REVIEW_INPUT.md,helpOutput review input file.,)argsparser.parse_args()ensure_git_repo()summaryread_optional(Path(args.summary))changed_filesrun_git([diff,--name-status,args.base],allow_failTrue)numstatrun_git([diff,--numstat,args.base],allow_failTrue)diffrun_git([diff,args.base],allow_failTrue)outputf# GPT56_REVIEW_INPUT## 1. Codex 执行摘要{summary}---## 2. Git 变更文件列表text{changed_filesor无变更文件。}3. Git 增删行统计{numstat or 无增删行统计。}4. Git Diff{diff or 无 Diff。}5. 给 GPT-5.6 的审查要求请你不要继续修改代码只做 Diff Review。请输出任务是否完成改动范围是否合理是否修改了不该改的文件是否存在接口兼容风险是否存在测试缺口是否存在安全或隐私风险哪些文件必须人工 Review是否建议合并合并前还需要运行哪些命令回滚建议。不确定的信息请标记为“待确认”不要编造测试结果。“”Path(args.output).write_text(output, encodingutf-8) print(f已生成{args.output})ifname “main”:main()运行 bash python prepare_gpt56_review_pack.py会生成GPT56_REVIEW_INPUT.md然后你把这个文件交给 GPT-5.6 做审查即可。八、什么时候特别适合用 GPT-5.6 做 Diff Review不是所有小改动都需要这么完整的流程。下面这些场景更适合场景为什么适合Codex 改了多个文件人工 Review 容易漏文件涉及接口字段需要检查兼容性涉及错误处理容易影响用户体验和日志安全涉及权限 / 鉴权风险高必须二次审查涉及订单 / 支付业务后果严重涉及数据库迁移回滚成本高涉及配置文件可能影响构建或部署涉及 shared-types / SDK影响多个调用方涉及测试补充要检查测试是否真的覆盖需求如果只是改一个 README 错别字就没必要这么复杂。但只要 Codex 改了业务代码尤其是多文件改动这套流程就很值得。九、不要让 GPT-5.6 的 Review 变成“二次乱改”这里有个非常重要的边界GPT-5.6 做 Review 时不要让它继续改代码。否则会变成Codex 改第一轮 GPT-5.6 审查时又改第二轮 Codex 再修第三轮 最后 Diff 越来越乱正确做法是Review 阶段只输出问题 修复阶段再单独开任务 修复后重新生成 Review 输入包。也就是说执行和审查要分离。这也是 GPT-5.6 Codex 合并使用时最容易被忽略的一点。不是模型越强越应该让它连续做所有事。而是模型越强越应该把它放到更清晰的流程节点里。十、最后总结GPT-5.6 Codex 真正好用的地方不是让 AI 一口气写完代码。而是让两个能力形成闭环Codex执行代码修改 GPT-5.6审查 Diff 和测试结果 开发者决定是否合并推荐流程是Codex 修改代码 → 输出 CODEX_EXECUTION_SUMMARY.md → 导出 Git Diff → 生成 GPT56_REVIEW_INPUT.md → GPT-5.6 做 Diff Review → 输出 GPT56_CODE_REVIEW.md → 人工 Review 后合并这样做的价值很明确改动范围更清楚风险文件更容易发现测试缺口更容易暴露回滚方案更容易提前准备人工 Review 更有依据Codex 的执行结果不会直接“裸奔”进项目。