> ## Documentation Index
> Fetch the complete documentation index at: https://docs.smew.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Claude Code 与 Codex 协同开发

这篇文档介绍一种更适合 SmewAI 当前能力边界的工作方式：**一个主会话负责规划，另一个 Codex 会话负责执行与复核。**

## 1. 为什么推荐双会话协同

当任务稍复杂时，把“想清楚”和“动手改”拆开，通常更稳：

* **主会话负责理解需求**：拆任务、定范围、识别风险
* **执行会话负责落地**：改代码、跑测试、修报错
* **复核会话负责审查**：独立检查改动是否遗漏问题

这种方式的核心价值是：上下文更清晰、每个会话目标更单一、回滚和追踪也更方便。

## 2. 基本工作流

### 步骤一：先在主会话写清任务

建议至少写明这四件事：

1. 目标是什么
2. 改哪些文件
3. 不要动哪些地方
4. 如何验证完成

### 步骤二：把实现任务交给执行会话

适合交出去的任务包括：

* 修一个明确的 bug
* 补一组测试
* 做一个边界清晰的小功能
* 清理一个局部模块

### 步骤三：完成后做一次独立复核

复核时重点看：

* 是否真的满足最初目标
* 是否改出了不该碰的文件
* 是否漏跑测试或构建
* 是否引入新的配置风险

## 3. 推荐提示词模板

### 让执行会话接手实现

```text theme={null} theme={null}
请在当前仓库中完成下面这个任务：
1. 目标：...
2. 允许修改的文件：...
3. 不要修改的内容：...
4. 验证方式：...
完成后请总结改动，并说明你实际运行了哪些验证。
```

### 让复核会话做审查

```text theme={null} theme={null}
请审查当前改动，重点关注：行为回归、边界条件、遗漏测试、配置错误。
如果发现问题，请按严重程度列出，并给出文件位置。
```

## 4. 什么时候适合这样做

* 你想减少一个会话里塞太多上下文
* 你需要把规划、实现、审查分开
* 你要并行处理多个相互独立的小任务

## 5. 什么时候不适合

* 只是改一两行字
* 问题非常依赖长期对话上下文
* 需求还没有收敛，连目标都不清楚

## 6. 实战建议

* 任务描述要具体，避免“帮我优化一下”这种宽泛表述
* 执行会话结束后，先看 diff，再看总结
* 复杂任务先拆成 2 到 4 个子任务，不要一口气全丢出去
* 同一轮里最好明确谁负责实现、谁负责复核

## 7. 常见问题

### 一个会话能不能同时规划又执行？

可以，但任务越复杂，混在一起越容易丢上下文。只要你发现自己在来回切换“想方案”和“修细节”，就值得拆会话。

### 复核会话应该看什么？

优先看高风险点：接口变更、共享配置、测试覆盖、用户可见行为。

### 会不会更耗时？

简单任务会稍微增加一点切换成本；中等以上任务通常更省心，因为返工更少。