Claude Code + Codex实战教程：从GitHub Issue到自动修复PR，我的AI编程工作流完整拆解

最近 AI 编程圈最火的两个工具，一个是 Claude Code，一个是 Codex。前者擅长读长上下文、分析复杂问题；后者擅长执行任务、改代码、跑测试、自动迭代。

很多人现在的问题不是“要不要用 AI 编程”，而是：这些工具到底怎么组合起来，形成一套真正能落地的工程工作流？

我自己最近常用的一套流程是：先让 Claude Code 读 GitHub Issue 和项目上下文，做问题分析和修复方案；再把明确的修改计划交给 Codex 执行改代码、补测试、跑验证；最后人工 review diff，整理成 PR。

这篇文章不写泛泛的工具介绍，而是写一份从 GitHub Issue 到自动修复 PR 的实战教程。你可以直接照着搭一套自己的 AI 编程流水线，同时我也会讲清楚国内开发者怎么用 bblabu API 中转站 统一接入 Claude Code、Codex，把模型成本和线路稳定性一起管住。

一、为什么要 Claude Code + Codex 组合？

单独用任何一个工具，都有短板。

所以我的分工很明确：

• Claude Code 负责想清楚：读 Issue、读代码、定位问题、写计划；
• Codex 负责干活：按计划改文件、跑测试、修失败、生成 diff；
• 人负责把关：review 关键修改、确认边界、合并 PR。

这样做比直接对一个工具说“帮我修一下”靠谱得多。AI 编程最重要的不是让模型乱冲，而是把任务拆成清晰阶段。

二、准备环境：Node.js、Git、Claude Code、Codex

先确认基础环境：

node -v
npm -v
git --version

安装 Claude Code：

npm install -g @anthropic-ai/claude-code

安装 Codex：

npm install -g @openai/codex --registry=https://registry.npmmirror.com

如果你还没配置过，可以先看我整理的完整教程：docx.kkkliao.cn。里面把 Node.js、Claude Code、Codex、CC Switch、VS Code 插件的接入流程都写好了。

三、API 配置：两类协议别搞混

Claude Code 和 Codex 的 API 协议不同，这是国内用户最容易踩的坑。

3.1 Claude Code：Anthropic 兼容接口

export ANTHROPIC_API_KEY="你的 bblabu Key"
export ANTHROPIC_BASE_URL="https://api.bblabu.cn"

注意：Claude Code 不要加 /v1。

3.2 Codex：OpenAI 兼容接口

export OPENAI_API_KEY="你的 bblabu Key"
export OPENAI_BASE_URL="https://api.bblabu.cn/v1"

Codex 走 OpenAI Compatible，所以这里要加 /v1。

如果你不想每次手动切，建议用 CC Switch 把 bblabu 主线 和 bblabu 备线 都配好。主线慢了，切备线就行。

四、第一步：把 GitHub Issue 变成技术任务

真实项目里，Issue 通常不是技术任务，而是用户语言。比如：

用户反馈：导出 CSV 时，部分中文字段乱码；如果字段里包含英文逗号，导出的列会错位。

这时候不要直接让 Codex 改。我的第一步是让 Claude Code 分析问题：

请阅读当前项目中和 CSV 导出相关的代码，结合下面的 Issue 描述，输出：
1. 可能的根因；
2. 需要检查的文件；
3. 最小修复方案；
4. 应补充的测试用例。
先不要修改代码。

Issue：用户反馈导出 CSV 时，部分中文字段乱码；如果字段里包含英文逗号，导出的列会错位。

这个提示词里有一个关键点：先不要修改代码。先让 Claude Code 做分析，避免它还没搞清楚就开始改。

Claude Code 的输出一般会把问题拆成两类：

五、第二步：让 Claude Code 生成 Codex 可执行计划

分析完之后，我会继续让 Claude Code 把方案压缩成 Codex 能执行的任务单：

请把上面的分析整理成 Codex 可执行的任务单，格式如下：
- 目标
- 修改范围
- 不要修改的范围
- 具体步骤
- 验证命令
- 预期测试用例
要求：步骤尽量明确，避免大范围重构。

一个好的任务单应该像这样：

目标：修复 CSV 导出中文乱码和逗号错列问题。
修改范围：src/export/csv.ts、tests/export/csv.test.ts。
不要修改：前端 UI、数据库结构、导出接口参数。
步骤：
1. 检查现有 csv 序列化函数；
2. 对包含逗号、引号、换行的字段做标准 CSV 转义；
3. 导出内容使用 UTF-8，并在需要时添加 BOM；
4. 补充中文、逗号、双引号、换行四类测试；
5. 运行 npm test -- csv。
验证命令：npm test -- csv

这个任务单越明确，Codex 后面越不容易跑偏。

六、第三步：交给 Codex 执行修改

进入项目目录，开新分支：

git checkout -b fix/csv-export-encoding

然后把任务单交给 Codex：

请严格按下面任务单修改代码：

目标：修复 CSV 导出中文乱码和逗号错列问题。
修改范围：src/export/csv.ts、tests/export/csv.test.ts。
不要修改：前端 UI、数据库结构、导出接口参数。
步骤：
1. 检查现有 csv 序列化函数；
2. 对包含逗号、引号、换行的字段做标准 CSV 转义；
3. 导出内容使用 UTF-8，并在需要时添加 BOM；
4. 补充中文、逗号、双引号、换行四类测试；
5. 运行 npm test -- csv。

要求：先展示计划，再修改文件；每次测试失败只分析新增错误，不要重读整个项目。

注意最后一句：每次测试失败只分析新增错误，不要重读整个项目。这是为了控制 Token 成本，尤其是 Codex 这种会自动迭代的工具。

七、第四步：跑测试和 review diff

Codex 修改完后，不要直接合并。先自己看 diff：

git diff -- src/export/csv.ts tests/export/csv.test.ts

再跑测试：

npm test -- csv

如果测试失败，我不会让 Codex “重新修一遍”，而是给它更小的上下文：

这是刚才新增测试的失败日志，请只分析这个失败原因，不要重新读取全项目。请给出最小修改。

这个习惯很重要。AI Agent 最容易浪费 Token 的地方，就是失败后重新扫描大量上下文。把失败日志和修改范围限定住，成本会低很多。

八、第五步：让 Claude Code 做二次审查

Codex 执行完之后，我会再让 Claude Code 看一遍 diff，做“审查员”：

请审查当前 git diff，重点看：
1. 是否真正解决 Issue；
2. 是否有边界 case 漏掉；
3. 是否引入兼容性风险；
4. 测试是否覆盖中文、逗号、引号、换行；
5. 有没有过度重构。
只输出 review 结论，不要修改代码。

Claude Code 在这种“看 diff + 评审”的场景里非常强，尤其适合发现边界情况。

如果它指出问题，再把明确问题交给 Codex 做小修，而不是让两个工具都自由发挥。

九、第六步：生成 PR 描述

最后让 Claude Code 或 Codex 根据 diff 生成 PR 描述：

请根据当前 git diff 生成 PR 描述，包含：
- 背景
- 修改内容
- 测试结果
- 风险点
- 回滚方案
语气简洁，适合发到 GitHub PR。

输出可以像这样：

## 背景
修复 CSV 导出在中文字段和包含逗号字段下的兼容问题。

## 修改内容
- 对 CSV 字段增加标准转义逻辑；
- 对中文导出增加 UTF-8/BOM 处理；
- 补充中文、逗号、双引号、换行字段测试。

## 测试
- npm test -- csv

## 风险
影响范围限定在 CSV 导出模块。

## 回滚
回滚本 PR 即可恢复旧逻辑。

这样从 Issue 到 PR 的闭环就完成了。

十、成本控制：为什么这套流程适合接 API 中转站

这套流程的模型调用并不少：

如果全部直连官网，成本会明显上升。通过 bblabu API 中转站，我会这样拆 Key：

这样一来，每个阶段花了多少钱都能看清楚。更重要的是，Codex 如果跑飞，也不会烧掉 Claude Code 的额度。

十一、主备线路配置

我建议一开始就把主线和备线都配好。

Claude Code：

export ANTHROPIC_BASE_URL="https://api.bblabu.cn"
# 备线：export ANTHROPIC_BASE_URL="https://api.bblabu.chat"

Codex：

export OPENAI_BASE_URL="https://api.bblabu.cn/v1"
# 备线：export OPENAI_BASE_URL="https://api.bblabu.chat/v1"

如果用 CC Switch，就把两条线路都做成 Provider。以后遇到延迟或临时故障，不用临时翻文档，直接切。

十二、完整流程模板

最后给一份可以直接复制的模板：

# 阶段1：Claude Code 分析
请阅读 Issue 和相关代码，只输出根因、影响范围、修复方案、测试建议。不要修改代码。

# 阶段2：Claude Code 生成任务单
请把分析结果整理成 Codex 可执行任务单：目标、修改范围、禁止修改范围、步骤、验证命令。

# 阶段3：Codex 执行
请严格按任务单修改代码。先展示计划，再修改。测试失败后只分析新增错误，不要重新读取全项目。

# 阶段4：Claude Code 审查
请审查 git diff，检查边界 case、兼容性风险、测试覆盖，不要修改代码。

# 阶段5：生成 PR 描述
请根据 diff 生成 PR 描述：背景、修改内容、测试、风险、回滚。

这套模板的核心是：分析和执行分离，修改和审查分离，自动化和人工把关分离。

总结：AI 编程不是让模型乱改，而是设计工作流

Claude Code 和 Codex 都是很强的工具，但真正提高效率的不是“把所有事情丢给 AI”，而是给它们清晰分工。

我的推荐流程是：

1. Claude Code 读 Issue 和代码，做根因分析；
2. Claude Code 输出 Codex 可执行任务单；
3. Codex 按任务单改代码、补测试、跑验证；
4. Claude Code 审查 diff；
5. 人工确认后发 PR。

国内开发者要长期用这套流程，还要把 API 成本和线路稳定性管好。我的做法是用 bblabu API 中转站 统一接入 Claude Code 和 Codex，再用独立 Key、预算和主备线路控制风险。

如果你还没跑通过 Claude Code / Codex，可以先看 docx.kkkliao.cn 的接入教程，先让工具跑起来，再把这套 Issue → 修复 → 测试 → PR 的工作流搭起来。

相关资源

• 🏠 bblabu API 中转站主线
• 🔄 bblabu API 中转站备线
• 📖 Claude Code / Codex / CC Switch 完整教程
• 🧠 Claude Code 国内使用教程
• ⚖️ AI 编程工具横评
• 🔌 MCP 接入 Claude Code / Cursor / Codex 教程

—— 廖万里 · 2026年6月5日实测整理