Claude+Codex 科研工作流

Codex + Claude 搭配使用工作流

核心分工

推荐分工：

Codex = 项目规划 / 代码库理解 / 任务拆分 / 改动边界 / 测试验收

Claude = 核心代码生成 / 复杂逻辑实现 / 重构代码输出

Codex = 落地集成 / 跑测试 / 发现问题 / 形成下一轮任务

一句话总结：

Codex 先想清楚怎么改，Claude 负责把关键代码写好，Codex 再把代码放回项目里验证。

---

总体闭环

Codex：读项目 → 拆任务 → 生成 Claude 任务包

Claude：生成核心代码 → 解释实现逻辑

Codex：集成代码 → 跑测试 → 定位报错

Claude：处理复杂逻辑 bug

Codex：最终验收 → 输出修改报告

---

第一步：让 Codex 阅读项目并做规划

把下面这段发给 Codex：

请阅读当前项目，先不要修改代码。

我的需求是：……

请输出：

1. 当前项目结构理解

2. 和需求相关的核心文件

3. 需要修改的文件

4. 不应该修改的文件

5. 推荐实现方案

6. 每个文件具体要改什么

7. 给 Claude 生成代码时应该提供的上下文

8. 测试与验收标准

要求：

- 不要写代码

- 不要大范围重构

- 先给我一份可执行的开发计划

这一阶段，Codex 的角色是：

项目经理 + 代码库阅读器 + 技术负责人

它不急着写代码，而是先把项目结构、修改边界、风险点和验收标准想清楚。

---

第二步：让 Codex 生成 Claude 任务包

继续让 Codex 输出一份给 Claude 的代码生成任务包：

请把刚才的实现方案整理成一份给 Claude 的代码生成任务包。

要求包含：

1. 背景说明

2. 当前相关代码摘要

3. 需要 Claude 生成的具体代码

4. 输入输出要求

5. 边界条件

6. 不能改动的接口

7. 代码风格要求

8. 预期测试方式

9. 环境地址：E:\\Anaconda\\envs\\research\\python\.exe

10. 如果需要下载第三方库，你只需要指明需要下载哪些，我自己手动下载即可

这一步的目标是让 Claude 拿到足够清晰的上下文，而不是只收到一句“帮我写代码”。

---

第三步：让 Claude 生成核心代码

把 Codex 整理好的任务包发给 Claude：

你是主力代码实现者。请根据下面的任务包生成高质量代码。

要求：

1. 优先保证正确性和可维护性

2. 不要改变任务包中禁止修改的接口

3. 给出完整代码片段或 patch

4. 说明每一处关键修改的作用

5. 补充必要的边界条件处理

6. 如需要新增测试，请一并生成

任务包如下：

……

这一阶段，Claude 的角色是：

核心代码生成者 + 复杂逻辑实现者 + 重构实现者

更适合交给 Claude 的任务包括：

• 写核心算法；

• 写复杂业务逻辑；

• 重构某个函数或模块；

• 生成高质量类、函数、接口；

• 补充边界条件；

• 写单元测试；

• 对复杂代码做解释。

---

第四步：让 Codex Review Claude 生成的代码

Claude 已经根据上一阶段 Codex 输出的“代码生成任务包”在当前项目中生成或修改了代码。

请你直接读取当前项目代码和变更，Review Claude 的实现是否符合任务包要求。

重点检查：

1. 读取上一阶段 Codex 的代码生成任务包，明确任务目标、应改文件、实现方式、接口约定、边界条件和禁止事项。

2. 检查 Claude 的实际改动，包括 git status、git diff、新增/修改/删除文件。

3. 对照任务包判断：

    - 是否完成了要求的功能

    - 是否修改了正确文件

    - 是否遗漏必要实现

    - 是否引入任务包之外的无关代码或重构

    - 是否破坏现有架构、类型、命名、依赖或模块边界

    - 是否存在 import、路径、类型、导出等问题

    - 是否覆盖任务包要求的边界条件

要求：

- 主要任务是 Review，不要直接大范围重写 Claude 代码。

- 只有小问题可以做最小范围修复，例如修 import、类型、导出、路径。

- 如果发现实现方向错误、功能遗漏、架构偏离或越界修改，请输出 Review 结论和修改建议，不要直接重写。

- Review 后运行测试或最小验证命令。

最后输出：

- Claude 修改文件列表

- 任务包完成情况

- 符合要求的部分

- 不符合要求的部分

- 超出任务范围的改动

- 测试/验证结果

- 最终结论：通过 / 有条件通过 / 不通过

- 下一步建议

你的角色是：代码审查者 + 任务包验收者 + 偏差识别者 + 最小修复执行者。

---

第五步：复杂 bug 再交给 Claude

如果 Codex 集成后遇到复杂逻辑错误，不要让 Codex 反复乱修。可以把报错、相关代码和 Codex 的分析发给 Claude：

下面是 Codex 集成 Claude 代码后遇到的问题。

请你作为核心代码实现者，分析并修复复杂逻辑问题。

要求：

1. 先判断错误原因

2. 说明是哪部分逻辑不匹配

3. 给出最小修改方案

4. 不要改变原始功能目标

5. 输出可直接交给 Codex 集成的代码

报错信息：

……

相关代码：

……

Codex 的初步分析：

……

然后再把 Claude 的修复代码交给 Codex 集成和测试。

---

角色分工表

---

不推荐的用法

1. 不要让两个工具同时自由修改同一批文件

错误做法：

Claude 改一遍项目，Codex 也改一遍项目。

这样容易导致：

• 文件冲突；

• 修改方向不一致；

• 代码风格混乱；

• 最后不知道谁的结果是正确的。

推荐做法：

Codex 负责规划和集成，Claude 负责生成关键代码。

---

2. 不要一上来就让 Codex 大范围重构

错误 prompt：

帮我优化整个项目。

更好的 prompt：

请只分析和用户登录功能相关的文件。

先不要修改代码。

请输出需要修改的文件、修改原因、风险点和测试方式。

---

3. 不要让 Claude 在没有项目上下文的情况下直接写代码

错误 prompt：

帮我写一个登录模块。

更好的 prompt：

下面是 Codex 读取项目后整理出的任务包。

请你严格按照任务包生成代码，不要改变已有接口。

---

推荐固定模板

模板一：给 Codex 的规划 prompt

请阅读当前项目，先不要修改代码。

我的需求是：……

请你输出一份开发规划，包含：

1. 项目结构理解

2. 相关文件

3. 需要修改的文件

4. 不能修改的文件

5. 推荐实现方案

6. 每个文件具体改动点

7. 风险点

8. 测试命令

9. 验收标准

10. 给 Claude 的代码生成任务包

要求：

- 不要直接写代码

- 不要大范围重构

- 修改边界要清楚

- 任务要能分步骤执行

---

模板二：给 Claude 的代码生成 prompt

你是主力代码实现者。请根据下面的任务包生成高质量代码。

要求：

1. 优先保证正确性和可维护性

2. 严格遵守任务包中的接口约束

3. 不要修改禁止修改的内容

4. 给出完整代码片段或 patch

5. 说明关键实现逻辑

6. 补充必要的边界条件

7. 如需要测试，请生成对应测试代码

任务包如下：

……

---

模板三：给 Codex 的集成 prompt

下面是 Claude 生成的代码，请你负责集成到当前项目中。

要求：

1. 先检查 Claude 代码是否和当前项目匹配

2. 只修改任务相关文件

3. 不要引入无关重构

4. 修改后运行测试或最小可运行命令

5. 如果报错，先分析原因，再小范围修复

6. 最后输出：

    - 修改文件列表

    - 修改内容摘要

    - 测试结果

    - 仍然存在的问题

Claude 代码如下：

……

---

模板四：复杂 bug 交给 Claude 的 prompt

下面是 Codex 集成代码后遇到的问题，请你分析并修复。

要求：

1. 判断错误原因

2. 说明是哪部分逻辑不匹配

3. 给出最小修改方案

4. 不改变原始功能目标

5. 输出可直接交给 Codex 集成的代码

报错信息：

……

相关代码：

……

Codex 的分析：

……

---

最终推荐

最适合的搭配方式是：

Codex 不当码农，当技术负责人。

Claude 不当顾问，当主力程序员。

具体执行顺序：

1. Codex 先读项目，告诉你“应该怎么改”

2. Claude 根据 Codex 的规划写代码

3. Codex 把 Claude 的代码集成进项目

4. Codex 跑测试，发现问题

5. 复杂代码问题再交给 Claude 修

6. 最后 Codex 做验收报告

这个工作流的优势是：

• Codex 更好地利用本地项目上下文；

• Claude 集中发挥代码生成能力；

• 每一步都有清晰边界；

• 不容易出现两个模型同时乱改项目；

• 更适合科研代码、工程项目、实验脚本、前后端项目和论文复现实验。