在同一仓库中分工使用 Claude Code 与 Codex：新手操作指南

#1 · 先选一个能清楚验收的小任务

第一次协作，不要让两个工具一起“优化整个项目”。可以从“给列表页增加筛选条件”开始，将验收标准写清楚：参数不合法时返回明确错误，筛选后分页正常，已有功能不受影响。先确认项目能够安装依赖、运行测试，并提交当前修改，留下可回退的起点。

#2 · 按交付物分工，不按工具印象分工

让 Claude Code 负责服务端筛选逻辑，让 Codex 负责页面交互，是一种可行安排；反过来也可以。关键不是认定谁更擅长某类代码，而是让两边交付物独立。提前写好接口约定，包括参数名、返回字段、错误格式和默认行为，避免两边各自猜测。

#3 · 为两个工具准备独立工作目录

不要让两个会话同时修改同一个工作目录。可以从同一基准提交创建两个分支与工作树，例如分别执行 git worktree add ../repo-server -b task/server 和 git worktree add ../repo-ui -b task/ui。两个命令应在仓库中执行，分支名需尚未存在。随后分别进入对应目录启动工具，按项目要求安装依赖。

#4 · 给每个会话一份明确的任务说明

提示中至少写明目标、允许修改的目录、不能触碰的文件、接口约定和测试命令。例如：“只修改服务端目录；不要改依赖清单和锁文件；完成后列出修改文件、测试结果及未解决问题。”另一边使用对应边界。遇到必须跨边界的修改，要求先说明原因，由你决定归属。

#5 · 把共享文件留给一个负责人

依赖清单、锁文件、公共类型和数据库迁移容易成为冲突点。指定其中一个会话负责，另一边只提出需求。开发服务器也可能争用同一端口，数据库或缓存更可能共享状态；为两个工作目录设置不同端口和测试资源。工作树隔离了文件修改，并不自动隔离运行环境。

#6 · 并行开发，但在接口变化时暂停对齐

两边开始工作后，不必互相复制全部对话。只同步接口变化、阻塞问题和已完成的提交。若服务端必须改变返回结构，先更新约定，再通知页面一侧。每个会话都应运行相关测试；没有实际运行的检查，必须明确标注，不能把“代码看起来正确”写成“测试通过”。

#7 · 逐个合并，再做一次完整验收

先审查一个分支的差异，确认没有越界修改，再合入集成分支；随后合入另一个分支。发生冲突时，依据接口约定决定最终内容，不要只为了消除冲突而任选一边。最后重新运行测试、构建和关键流程，尤其检查参数传递、错误展示与分页联动。两个分支各自通过测试，不代表组合后一定正确。

#8 · 按需要统一接入，再复用这套流程

如果你需要为多个工具统一安排模型接入，可以考虑按量付费的 Relay365。它支持 Claude Code、Codex、Gemini CLI 和 OpenAI SDK；具体配置应分别核对工具说明与平台提供的模型标识，不要假设所有客户端共用同一套设置。密钥应放在环境变量或安全配置中，不要提交到仓库。

有这类接入需求时，可以创建一个 Relay365 账户，先用小任务验证配置。无论选择哪种接入方式，可靠协作的核心仍是：任务边界清楚、工作目录独立、共享文件有人负责、合并之后重新验收。