适用范围：Claude Code / Codex 的 CLI、桌面客户端、IDE 与云端任务

本方案面向需要在不同 AI 编程工具之间切换的个人或小团队。目标不是评选“哪个模型更强”，而是建立一套即使工具、入口、额度或账号发生变化，项目仍可被安全接管的工程系统。

1. 一页结论

最佳实践的核心不是“长期绑定某个工具”，而是“让执行工具可替换，让项目事实不可替换”。代码、任务范围、关键决策、测试结果和下一步必须存在于 Git 仓库、任务卡和 CI 中；聊天记录只能作为临时工作记忆。

推荐采用“一个任务、一个分支、一个独立 worktree、同一时刻一个写入者”的默认模型。Claude Code 和 Codex 都可以是实现者，也都可以是审查者，但不能在同一目录中同时改同一批文件。若需要并行，必须使用不同 worktree，并且任务边界和文件边界明确分离。

统一事实源。仓库根目录用 AGENTS.md 承载两个工具都必须遵守的长期规则；Claude Code 的 CLAUDE.md 只导入 AGENTS.md，再补充极少量 Claude 专属说明。任务级信息放进独立任务卡，不把不断变化的进度塞进长期规则文件。

统一交付标准。“完成”不能由 Agent 自己口头宣布，而要由可重复执行的测试、lint、类型检查、构建、接口探活或截图对比证明。主分支通过 PR、必需状态检查和审查保护，任何客户端里的“自动完成”都不能越过这些门禁。

统一切换协议。额度耗尽、服务异常或账号不可用时，先停止写入、做 Git 检查点、更新任务卡，再让另一工具读取同一 worktree、同一提交和同一验收标准继续。这样切换的是执行者，不是重新启动项目。

统一双工具分工。默认使用“一方实现、另一方独立审查”。实现者负责修复，审查者以只读方式检查 diff、边界、测试和风险；重大修改后再复审。不要固定成“Claude 永远写后端、Codex 永远写前端”，应按任务和入口选择当前最合适的执行者。

2. 设计依据与目标

2.1 研究方法

本方案综合了 Claude Code、Codex、Git 与 GitHub 的官方资料，并用实际项目中出现过的冲突、规则漂移、环境缺失和交接困难作为问题样本。样本用于暴露风险，不等同于推荐做法；最终规则以可恢复、可验证、可审计的工程原则为准。

Claude Code 和 Codex 的官方最佳实践都强调三件事：先给清楚的上下文与完成条件；复杂任务先研究和计划；给 Agent 一个可以自行运行的验证闭环。两者也都原生支持 worktree、持久项目说明、Skills 和本地生命周期钩子，但文件位置和细节并不完全相同。因此，方案需要一层工具无关的公共协议，再由各工具做薄适配。

2.2 真实样本暴露出的风险

风险	常见现象	方案中的处理
规则漂移	AGENTS.md、CLAUDE.md 与真实代码口径不同	单一公共规则源；规则变更与代码一同走 PR
目录冲突	两个 Agent 在同一 checkout 同时改文件或 lockfile	一任务一 worktree；同一时刻只有一个写入者
聊天依赖	换工具后重新解释背景，关键决定遗漏	任务卡、提交记录和测试证据外置
环境不一致	新 worktree 没依赖、环境变量或启动方式不同	统一 bootstrap/verify 脚本与最小环境契约
高风险并发	Schema、鉴权、部署或配置被多个 Agent 同时修改	高风险区域单一所有者、串行修改、人工批准

2.3 建议的成功指标

指标	推荐目标	计算方式
工具接管时间	普通任务不超过 15 分钟	从原工具停止到新工具给出正确续作计划
并发写冲突	0 次	同一 worktree 或同一热点文件的并发写入次数
首次 CI 通过率	逐周提升	首次推送后必需检查全部通过的任务比例
返工率	逐周下降	因遗漏需求、规则或环境导致的返工任务比例
无证据完成	0 次	没有测试、构建或可复核证据却宣布完成的次数

这些数值是建议的内部管理目标，不是厂商承诺。最重要的是持续记录趋势，而不是为了达成数字牺牲质量。

3. 统一协作架构：把项目状态放到工具之外

3.1 五类事实源

事实类型	唯一权威位置	不要放在哪里
代码状态	分支、commit、worktree、Git diff	聊天里的“我已经改好了”
任务范围	Issue / 任务卡 / PR 描述	只存在于某个 Agent 的会话
长期规则	根目录 AGENTS.md	两份各自维护且内容重复的规则
架构与决策	docs/ai/、ADR、接口契约	自动记忆或口头约定
完成证据	测试输出、CI、构建产物、截图或探活记录	Agent 的主观总结

聊天、Claude 自动记忆、Codex 记忆和客户端会话都可以提高效率，但它们是缓存，不是数据库。凡是换一个工具后仍必须知道的信息，都要写回上述事实源。

3.2 推荐的仓库结构

project/ ├── AGENTS.md ├── CLAUDE.md ├── docs/ai/ │ ├── architecture.md │ ├── testing.md │ └── decisions/ ├── .ai/tasks/ │ └── TASK-123.md ├── .agents/skills/ ├── .claude/skills/ ├── scripts/agent/ │ ├── bootstrap.sh │ └── verify.sh ├── .worktreeinclude └── .github/ └── pull_request_template.md

AGENTS.md 应保持简短、稳定、可验证，建议控制在 200 行以内。它只写项目目标、不可破坏的架构边界、常用命令、测试要求、危险区域和提交规则。频繁变化的进度、完整 API 文档和长教程放到任务卡或 docs/ai/，由 AGENTS.md 指向相关资料。

Claude Code 官方文档明确说明它读取 CLAUDE.md 而不是直接读取 AGENTS.md，因此推荐让 CLAUDE.md 以导入方式复用同一份规则：

@AGENTS.md ## Claude Code 专属 - 复杂改动先使用 Plan mode。 - 结束前运行 scripts/agent/verify.sh。

不要把完整公共规则再复制一遍。若确有工具专属差异，只在适配文件里保留少量差异，并定期审查它是否仍然必要。

3.3 中立 worktree，而不是厂商私有工作区

Claude Code 与 Codex 客户端都能自动创建 worktree，但跨工具长期接管时，优先使用一个有稳定路径、有人类可识别名称的中立 worktree，例如仓库同级的 project-worktrees/TASK-123-login-timeout。两个工具可以依次打开它，但同一时刻只有一个工具拥有写入权。

短暂、一次性且不需要跨工具交接的后台任务，可以直接使用客户端托管的临时 worktree。需要频繁在 Claude Code、Codex、IDE 和客户端之间移动的任务，则用长期 worktree，并保留明确分支。

.worktreeinclude 可帮助新 worktree 携带必要的忽略文件，但应谨慎使用。优先通过 Keychain、密码管理器、云端密钥服务或本地 bootstrap 注入凭据；不要为了方便把高权限密钥复制到每个临时 worktree。

3.4 Skills 和 Hooks 只做薄适配

两个工具都采用 SKILL.md 形式的可复用工作流，但项目扫描目录不同：Codex 使用 .agents/skills/，Claude Code 使用 .claude/skills/。建议把真正的命令和校验逻辑放在 scripts/agent/，两个 Skill 只负责调用同一脚本。若团队能够可靠处理 Git symlink，可让两个目录链接到一份中立 Skill；否则使用生成脚本和 CI 一致性检查，避免手工复制后长期漂移。

Hooks 同理：Claude 与 Codex 各自保存轻量配置，但调用同一组仓库脚本。规则文件用于指导 Agent，Hooks 用于本地即时提醒或阻断，CI 和分支保护负责最终强制执行。

4. CLI、客户端、IDE 应该怎么选

选择入口时不要先问“今天用 Claude 还是 Codex”，而应先判断任务需要怎样的反馈速度、上下文、隔离和验收。以下是默认选择：

场景	推荐入口	原因	关键约束
小范围、即时编辑	Claude / Codex IDE	可直接使用当前选区、打开文件、诊断与原生 diff	一次只做一个清晰变更
深度调试、命令密集	Claude Code / Codex CLI	终端上下文直接，适合日志、测试和脚本闭环	使用独立 worktree
复杂需求澄清与方案	任一工具的 Plan mode	先只读探索，再形成任务卡和实施计划	计划获批前不写业务代码
多小时独立任务	桌面客户端的 worktree 或云端任务	可后台运行并在完成后集中审查	验收标准必须可自动执行
UI、浏览器、交互验收	带浏览器预览的客户端，或 IDE + 本地浏览器	便于截图、DOM 与真实交互验证	使用隔离测试账号和测试数据
机械式批量修改	CLI 非交互模式或独立后台 worktree	可脚本化、可重复、便于保存结构化输出	先抽样，再全量执行
代码审查	未参与实现的另一个工具	新上下文更容易发现实现者忽略的假设	默认只读，不直接顺手重写
数据库、鉴权、部署、发布	单一主会话 + 人工批准	副作用大，必须串行和可审计	禁止多 Agent 并发执行

4.1 Claude Code 各入口的适用方式

CLI。适合连续的研究—计划—实现—测试循环，支持恢复会话、非交互执行和 --worktree 隔离。需要跨多次工作时给会话命名，但仍要把关键进度写回任务卡。

IDE。适合围绕当前选区和打开文件进行聚焦修改。Claude Code 的 IDE 集成可以使用原生 diff、当前选区和诊断；当任务扩展到多个模块时，应转到独立 worktree，而不是在原 IDE checkout 中无限扩大范围。

Claude Desktop Code。适合可视化管理多个隔离会话、终端、diff、浏览器预览和 PR/CI 状态。它的多会话同样基于 worktree；不要因为界面能同时开很多任务，就忽略热点文件和共享环境的串行约束。

4.2 Codex 各入口的适用方式

CLI。适合终端内的实现、自动化、恢复会话和独立代码审查。将 AGENTS.md、任务卡和验证脚本作为启动上下文，避免每次重新口述项目规则。

IDE。适合快速、聚焦、可视化的编辑和原地审查。官方入口支持使用当前打开文件与选区，也能在任务变大时把长任务交给云端，再回到编辑器审查结果。

ChatGPT / Codex 桌面客户端。适合协调后台任务、托管 worktree，以及在 Local 与 Worktree 间做 Handoff。跨 Claude 接管时，不依赖客户端私有 Handoff，而是回到公共分支、提交和任务卡。

4.3 一个实用判断

需要人在旁边快速纠偏，优先 IDE 或 CLI；任务已清楚、验证可自动执行，才交给客户端或云端长跑。需要同时开多个任务时，先确认它们是否真正独立，再增加并发。入口越自动，任务卡和门禁越要清楚。

5. 一项需求从开始到合并的标准流程

5.1 需求进入：先形成任务合同

任何超过一次小改的任务，都先创建任务卡。任务卡不是长篇 PRD，而是一份可执行合同：目标、非目标、基线 commit、工作分支、worktree、允许和禁止修改的范围、验收标准、测试命令、风险和下一步。若需求仍模糊，让任一工具在 Plan mode 中采访需求方并补齐任务卡，期间不写业务代码。

5.2 计划：先读事实，再选实现者

1. 读取根目录 AGENTS.md、相关架构文档和任务卡。

2. 核对当前分支、基线 commit、Git 状态和远端差异。

3. 只读探索相关代码、测试和历史提交，列出计划与风险。

4. 冻结接口、数据结构、验收条件和明确的非目标。

5. 决定由 Claude Code 或 Codex 担任本任务实现者，并记录在任务卡。

工具选择不需要永久固定。可根据当前可用额度、入口、任务规模和模型能力决定，但任务开始后尽量保持单一实现者，除非进入标准切换流程。

5.3 建立任务环境

从经过同步和确认的基线创建一个独立分支与 worktree。根 checkout 只用于集成、查看和紧急操作，默认不直接开发。worktree 初始化必须由统一 bootstrap 完成，包括依赖、必要环境检测、子模块和基础测试。初始化失败属于任务阻塞，不应让 Agent绕过检查继续编码。

5.4 实现：小步提交，持续校验

实现者按计划小步推进。每完成一个可解释的里程碑，就运行最小相关测试并创建可恢复的 commit。一个提交应表达一个意图，避免把重构、功能、依赖升级和格式化混在一起。未完成但需要切换工具时，允许创建明确标记的本地 WIP commit；它比匿名 stash 更容易审计和接管。

若发现任务范围需要扩大、接口需要变化或必须触碰禁止文件，先更新任务卡并重新确认计划，而不是让 Agent自行扩大授权。

5.5 验证：用证据关闭循环

验证至少分三层：相关单元/组件测试；项目级 lint、类型检查和构建；面向用户的行为验收。UI 任务要包含截图或真实交互，API 任务要包含请求和响应探活，数据任务要包含样本与完整性检查。所有命令和结果摘要写进任务卡或 PR。

5.6 独立审查与合并

1. 实现者提交完整 diff 和验证证据。

2. 另一个工具在干净上下文中进行只读审查，优先找逻辑错误、回归、权限、安全、数据边界和缺失测试。

3. 原实现者处理有效问题；重大修改后由审查者复查。

4. 创建 PR，等待必需 CI、会话解决和人工批准。

5. 合并后删除任务 worktree，保留任务卡、PR 和必要决策记录。

“另一个 AI 工具已审查”不能替代人的责任。涉及资金、权限、生产数据、发布和不可逆操作时，必须由授权的人做最终判断。

6. Claude Code 与 Codex 的切换和故障接管

6.1 标准切换协议

切换工具之前先让项目进入可恢复状态。推荐顺序如下：

1. 停止。中断当前 Agent，确认没有仍在运行的写入、迁移、构建发布或后台脚本。

2. 检查。记录当前 worktree、分支、HEAD、git status 和 diff 概览。

3. 验证。运行当前阶段能运行的最小测试；失败也要记录真实错误，不能省略。

4. 检查点。将有价值的改动做成正常 commit 或明确的本地 WIP commit。避免仅靠未命名 stash。

5. 更新任务卡。写明已完成、未完成、关键决策、改动文件、测试结果、已知问题和唯一的“下一步动作”。

6. 移交写入权。明确原工具已停止，新的工具现在是唯一实现者。

7. 新工具冷启动。读取公共规则、任务卡、最近提交和当前 diff，然后先复述续作计划，不立即改代码。

8. 继续并复核。新工具实现后走正常验证与跨工具审查。

如果原工具因账号或服务问题无法打开聊天，这套流程仍然成立，因为关键状态已经在本地工作树、Git 和任务卡中。无法恢复聊天不应导致无法恢复项目。

6.2 三种切换要区别对待

切换类型	例子	处理方式
同工具换入口	Claude CLI 换 IDE，Codex IDE 换桌面客户端	优先打开同一中立 worktree；确认会话历史是否共享，不假设自动共享
跨工具切换	Claude Code 换 Codex，或反向	严格执行检查点和任务卡接管；以 Git 为准
账号或服务不可用	额度用尽、服务故障、账号被限制	停止依赖该会话，使用合规的另一产品或已批准的 API/企业入口继续

6.3 账号连续性设计

第一层：入口冗余。同一账号下的 CLI、IDE 和客户端方便切换，但它们通常共享额度或账号状态，只解决界面问题，不是真正的供应商冗余。

第二层：双供应商冗余。同时保留 Claude Code 与 Codex 的合规可用入口。任一供应商不可用时，另一方读取同一仓库事实源继续。

第三层：组织级认证冗余。对关键业务，评估合法的 API 或企业认证方式。Claude Code 官方支持 Claude 订阅、Claude Console，以及 Bedrock、Vertex AI、Microsoft Foundry 等组织方案；Codex 支持 ChatGPT 登录和 API Key。不同入口的账单、权限、数据政策和模型可用性可能不同，应由组织预先审批并定期演练。

合规边界。备用方案用于业务连续性，不用于绕过平台处罚、使用共享或转售账号、盗用 OAuth、转发个人订阅凭据或规避服务条款。若账号被限制，应同时走官方申诉或支持流程；开发接管与账号处置分开进行。

6.4 建议的恢复时间目标

普通功能任务的接管目标为 10–15 分钟；复杂跨模块任务为 30 分钟以内；涉及生产数据库、鉴权或部署的任务不追求快速切换，先确保没有进行中的副作用，再由人工确认恢复点。速度必须服从安全和可审计性。

7. 两个工具怎样协作，而不是互相踩代码

7.1 默认模式：一方实现，另一方反向审查

最有价值的协作不是把同一任务同时丢给两个工具，而是分离“产出”和“反驳”。主工具负责理解、实现、测试和提交；另一工具从干净上下文读取任务卡、diff 与测试结果，主动寻找实现中的错误假设。审查工具默认不给写入权，避免它边审边大改，掩盖问题来源。

发现问题后仍由原实现者修复，保持代码所有权清楚。只有当实现者不可用或正式移交时，才执行第 6 章的切换协议。

7.2 可以并行与必须串行的边界

风险级别	可以怎么做	限制
低风险	独立文档、独立测试、叶子组件、只读研究可分 worktree 并行	文件集合明确不重叠
中风险	接口已冻结的前后端任务可以并行	先写契约测试；共享文件指定唯一所有者
高风险	Schema、鉴权、计费、反作弊、数据采集、部署和 lockfile 串行	单一实现者、人工批准、完整回滚方案

两个独立 worktree 解决的是文件写入冲突，不会自动解决语义冲突。两项任务即使不改同一个文件，只要同时改变同一接口、数据库口径或业务规则，仍应视为冲突任务并串行处理。

7.3 不按品牌永久分工

不要建立“Claude 负责架构、Codex 负责编码”或相反的永久制度。模型、功能、额度和入口会持续变化，固定品牌分工会形成新的单点。更稳的方法是定义角色：需求澄清者、计划者、实现者、验证者、审查者和发布负责人；每个任务再把工具分配到角色。

同一任务中，计划者和实现者可以是同一个工具，但审查者尽量使用另一个工具或新会话。对高风险任务，AI 审查之外仍要有人的批准。

7.4 上下文管理原则

一个会话只承载一个任务。Claude Code 和 Codex 都支持恢复会话，但恢复功能只是效率工具，不能替代任务卡。研究产生的大量日志与文件读取可交给独立只读子任务；主会话只保留结论、决策和实施状态。出现两次以上同类纠偏时，优先停止、总结有效信息并开启干净会话，而不是在污染的上下文中继续堆指令。

7.5 一个推荐的日常节奏

早上用主工具完成任务澄清和计划；白天由单一实现者在独立 worktree 推进；达到里程碑就提交和验证；完成后由另一个工具做新鲜上下文审查；晚上只保留已经有检查点和任务卡的后台任务。任何无人值守任务都必须有明确停止条件和可自动运行的验证。

8. 自动化、权限与质量门禁

8.1 三个公共脚本

bootstrap.sh。检查运行目录、Git 状态、工具版本、依赖、子模块和必要环境变量是否存在；只报告变量名和状态，不输出密钥值。

verify.sh。按仓库约定运行格式化检查、lint、类型检查、相关测试、构建和必要探活。支持快速模式与完整模式，但 PR 前必须运行完整模式。

handoff-check.sh。检查任务卡是否包含基线 commit、worktree、当前 owner、已完成、未完成、测试结果和下一步；在切换或提交前提示缺项。

脚本名称可以不同，关键是 Claude、Codex、IDE、客户端和 CI 调用同一实现。不要让两个工具分别维护两套“等价”命令。

8.2 规则、Hooks、CI 的职责边界

层次	适合做什么	不应承担什么
规则文件	说明架构、流程、命令和长期行为期望	不能当作不可绕过的安全控制
本地 Hooks	启动提示、保护目录提醒、编辑后格式化、停止前校验	不能替代服务端权限和最终 CI
CI / 分支保护	必需检查、PR 审查、阻止直接推主分支和未通过合并	不能替代产品验收与人的业务判断

推荐保护 main/master：禁止强推和直接删除，要求 PR、必需状态检查、会话解决和至少一次批准。高风险目录可再配 CODEOWNERS 或同等机制。AI 可以生成和审查修改，但不应拥有绕过主分支保护的常态权限。

8.3 权限与副作用

默认从最小权限开始。代码阅读和本地测试可以相对自动；安装生产依赖、修改数据库、创建密钥、发送消息、发布、部署、合并和删除属于副作用，应在任务卡中显式授权。生产凭据不进入 prompt、日志、任务卡、提交或 Hook 输出。

数据库迁移、支付、鉴权、发布和基础设施任务要有独立备份/回滚步骤。执行前记录目标环境与预期变化，执行后验证真实状态。若任何工具尝试把环境从开发扩大到生产，必须暂停并重新确认。

8.4 供应链与扩展管理

Skills、Plugins、MCP、Hooks 和浏览器扩展都能扩大 Agent 权限。只安装可信来源，固定版本，审查脚本，定期清理不用的扩展。企业项目应区分个人扩展和项目必需扩展；项目仓库不应静默要求开发者安装高权限第三方工具。

9. 建议的落地路线

9.1 第 0 阶段：先落地最小可用版本

不要一开始建设复杂 Agent 平台。先完成五件事：一份根目录 AGENTS.md；一份导入它的 CLAUDE.md；一个任务卡模板；一任务一 worktree；一个统一 verify 命令。只要这五项稳定，工具切换成本就会显著下降。

9.2 第 1 周：用三类任务试点

1. 选择一个小型 UI 或文档任务，验证 IDE 的快速闭环。

2. 选择一个跨文件功能，完整执行计划、worktree、实现、跨工具审查和 PR。

3. 选择一个高风险但可在测试环境完成的任务，验证串行所有权、审批和回滚。

每个任务记录接管时间、冲突、首次 CI 结果和返工原因。不要只记录 Token 消耗；返工和错误修复时间更能反映真实效率。

9.3 第 2 周：补自动化

根据试点中重复出现的问题，再补 Skills、Hooks、bootstrap、handoff-check、PR 模板和 CODEOWNERS。只有稳定、重复、边界清晰的流程才自动化。还在频繁变化的流程保留人工步骤，避免把错误做法固化。

9.4 稳定运行后的治理

每月做一次规则校准：随机抽取任务，检查 AGENTS.md、CLAUDE.md、Skills、脚本和真实代码是否一致；删除失效规则。每季度做一次供应商切换演练：故意在里程碑暂停主工具，让另一工具仅凭仓库事实源接管，并记录耗时和遗漏。

9.5 推荐的成熟度模型

级别	状态	达标条件
L1	可恢复	代码在 Git；有任务卡；另一工具能接管
L2	可并行	独立 worktree；边界清楚；无共享写入
L3	可验证	统一 verify；CI 必需检查；跨工具审查
L4	可治理	权限分层；高风险串行；扩展与凭据可审计
L5	可持续	定期校准规则、演练切换、用指标减少返工

10. 可直接复制的模板、检查表与资料来源

10.1 任务卡模板

# TASK-123：任务标题 ## 目标 一句话说明需要改变的用户或系统行为。 ## 非目标 本任务明确不处理什么。 ## 基线与所有权 - Base commit： - Branch： - Worktree： - 当前唯一写入者： - 计划者 / 审查者： ## 修改边界 - 允许修改： - 禁止修改： - 高风险区域： ## 完成条件 - [ ] 行为验收 - [ ] 相关测试 - [ ] lint / typecheck / build - [ ] UI 截图或 API 探活（如适用） ## 当前状态 - 已完成： - 未完成： - 关键决策： - 修改文件： - 测试及结果： - 已知问题： - 下一步唯一动作：

10.2 实现者启动提示词

你是 TASK-123 的唯一实现者。 先读取 AGENTS.md、CLAUDE.md（如适用）、任务卡和相关架构文档。 核对当前 worktree、分支、HEAD 与 git status。 先只读探索并给出实施计划、风险和预计修改文件；我确认前不要扩大范围。 实施时按小步提交推进，完成后运行 scripts/agent/verify.sh。 只有提供测试、构建或行为验收证据后才能宣布完成。 若需要修改任务边界、禁止文件、数据库、鉴权、部署或生产环境，立即暂停并说明。

10.3 独立审查提示词

你是 TASK-123 的独立审查者，默认只读，不修改文件。 读取任务卡、AGENTS.md、基线 commit、当前 diff 和测试证据。 优先寻找：与需求不符、逻辑错误、回归、边界条件、权限/安全、数据口径、 并发问题、错误处理、缺失测试和无法复现的“完成”声明。 不要把风格偏好当成缺陷。按严重度列出可定位、可验证的问题； 如果没有阻断问题，明确说明仍存在的验证盲区。

10.4 切换提示词

你现在接管 TASK-123。原实现者已经停止写入。 先不要修改代码。依次读取公共规则、任务卡、最近 3 个提交、git status 和当前 diff。 检查任务卡中的已完成、未完成、测试结果、已知问题和下一步。 输出：你理解的当前状态、需要核实的风险、续作计划和第一个验证动作。 只有状态与 Git 证据一致后，才成为新的唯一写入者。

10.5 日常检查表

任务开始前

• 任务卡有目标、非目标和可验证的完成条件

• 基线 commit、分支、worktree 和唯一写入者已记录

• 已读取公共规则和相关架构资料

• 高风险区域和禁止修改范围已明确

工具切换前

• 原工具和后台写入进程已经停止

• 有可恢复 commit；Git 状态和失败测试已记录

• 任务卡已写明下一步唯一动作

• 新的工具先复述状态和计划，再开始修改

合并前

• 完整 verify 和 CI 已通过

• 另一个工具完成独立只读审查

• 生产副作用、迁移和回滚已获授权

• PR 描述包含变更、证据、风险与遗留项

10.6 官方资料来源

以下资料用于核对截至 2026-07-23 的产品能力。具体界面和命令可能继续变化，但本方案把核心状态放在 Git 与仓库事实源中，因此不依赖某个短期 UI。

• Claude Code：Best practices

• Claude Code：CLAUDE.md、AGENTS.md 导入与记忆

• Claude Code：Worktrees

• Claude Code：IDE integration

• Claude Code：Desktop Code

• Claude Code：Authentication

• Codex：Best practices

• Codex：AGENTS.md

• Codex：Git worktrees 与 Handoff

• Codex：IDE extension

• Codex：Build skills

• Codex：Authentication

• Git：git-worktree

• GitHub：Protected branches

最终建议：先用第 9 章的最小版本运行两周，不急着增加更多 Agent。只要做到了公共规则单一来源、任务状态外置、独立 worktree、单一写入者和证据化验收，Claude Code 与 Codex 就已经可以顺畅互为主力和备份。