这不是一份教你写代码的教程，而是一份教你“如何管理 AI 开发”的操作手册。你不需要理解每一行代码，但需要知道怎样布置任务、怎样避免两个工具互相覆盖、怎样在 Claude Code 和 Codex 之间安全切换，以及怎样判断项目是否真的做完。

你的实际经历会作为问题样本：你会在 Claude Code、Codex、桌面客户端、IDE 等入口之间切换，也会遇到额度、服务或账号不可用。但这些经历只用于识别真实问题，不被直接当作最佳实践。本手册给出的方案以“即使换工具，项目也能继续”为目标重新设计。

1. 先说结论：你只需要管住五件事

最重要的一句话：工具可以换，项目记录不能丢。

Claude Code 和 Codex 都只是临时接手工作的“开发人员”。项目目标、当前进度、已经改了什么、怎样验收、下一步是什么，必须记录在项目本身，而不能只留在某一段聊天里。

非技术负责人不需要学会编程，但需要像项目负责人一样管住下面五件事：

1. 任务要说清楚：要解决谁的什么问题，不做什么，做到什么程度算完成。

2. 同一时间只有一个工具负责改：Claude Code 和 Codex 可以轮流接手，也可以互相检查，但不要同时在同一个项目文件夹里改同一项任务。

3. 过程要留存档：每完成一个可验证的小阶段，就留下一个可恢复的存档点。

4. 完成要有证据：不能只接受“已经完成”，还要看到测试结果、前后对比、影响范围和回退办法。

5. 高风险操作必须由人批准：上线、删除数据、改权限、动支付、改生产数据库、公开发布，都不能让 AI 自行决定。

这套方法解决什么问题

• Claude Code 用不了时，Codex 能接着做，而不是从头再讲一遍。

• Codex 用不了时，Claude Code 也能看到同样的项目状态和验收标准。

• 客户端、IDE 或命令行入口变化时，项目不会跟着入口走丢。

• 两个工具不会因为同时修改同一处内容而互相覆盖。

• 你即使看不懂代码，也能用证据判断工作是否可靠。

请记住：最佳实践不是“永远使用某个更强的模型”，而是让任何合规、可用的工具都能按照同一套项目规则接手。

2. 先认识七个词：不用学技术，只要会看路标

下面这些词在开发过程中经常出现。你不需要掌握技术原理，只要知道它们分别代表什么管理动作。

技术词	可以把它想成	你只需要知道
项目仓库（Repository）	项目的官方档案柜	代码、说明和历史记录都应该在这里；聊天记录不是官方档案。
Git	带时间轴的版本相册	可以看到谁改了什么，也可以回到过去的安全版本。
分支（Branch）	一条独立的草稿线	新任务先在草稿线上做，不直接改正式版本。
独立工作房间（Worktree）	为一项任务单独开的施工房间	并行任务要在不同房间里做，避免互相踩到文件。
存档点（Commit）	一次带说明的保存	换工具前必须先保存到一个可恢复的位置。
合并申请（PR）	把草稿申请放进正式版	应该先检查、测试，再批准进入正式版本。
自动质检（CI）	流水线上的自动检测	它会自动检查测试、格式、构建等；没通过就不应上线。

用装修来理解整个过程

项目仓库像一套房子的完整档案；正式版本像已经交付的房子；分支像设计草稿；独立工作房间像不同施工区域；存档点像每个阶段的验收照片；合并申请像申请把施工成果纳入正式交付；自动质检像水电和安全检查。

Claude Code 和 Codex 是施工团队。你不是施工工人，而是业主和项目负责人。你的职责不是亲自布线，而是说清需求、控制施工边界、要求验收证据，并决定是否交付。

3. 默认工作方式：把 AI 当成两支外部开发队

3.1 四个角色

角色	谁来担任	主要责任
需求负责人	你	说明为什么做、做给谁、什么算成功，以及哪些内容不能动。
实现者	Claude Code 或 Codex 中的一个	在明确范围内修改项目，并提供过程记录和验证结果。
审查者	另一个工具，或可信的技术人员	独立检查是否做错、遗漏、越界，默认先只看不改。
放行者	你或获得授权的人	决定是否合并、上线、改数据、改权限或公开发布。

3.2 四个默认规矩

1. 一个任务，一张任务卡。任务卡记录目标、范围、完成标准、当前进度和下一步。

2. 一个任务，一个独立工作房间。它让其他任务不受影响，也方便中途换工具。

3. 同一时间，一个唯一写入者。一个工具负责修改，另一个工具只能审查；换人时先完成交接。

4. 一次交付，一组验收证据。至少包括改了什么、怎样证明、还有什么风险、出问题怎么退回。

3.3 一项任务的日常流程

1. 你先用普通话说明问题、用户和期望结果。

2. 让 AI 把你的描述整理成一张任务卡，你确认后再开始。

3. 让实现者先阅读项目规则，只做检查和计划，不立刻大范围修改。

4. 确认计划、风险和预计修改范围，再授权它实施。

5. 实现者在独立工作房间里小步完成，并留下存档点。

6. 实现者提交测试、截图、前后对比或其他可复现证据。

7. 另一个工具以审查者身份检查结果，先不要直接修改。

8. 没有阻断问题后，由你或指定人员决定是否放进正式版本。

这套流程看起来多了几步，但它减少了返工、误删、互相覆盖和“AI 说完成、实际不能用”的概率。越重要的项目，越应该把这些动作固定下来。

4. 客户端、IDE、命令行和云端任务怎么选

“Claude Code”或“Codex”是能力，“客户端、IDE、命令行、云端任务”是不同的工作入口。入口不同，不应该改变项目规则和验收标准。

入口	适合什么时候使用	给非技术负责人的建议
桌面客户端	讨论需求、查看进度、阅读计划、比较方案、处理普通任务	作为日常默认入口。界面直观，适合持续对话和监督。
IDE	需要精确查看文件变化、和技术人员共同处理、修改界面细节	适合在有人协助或你已经熟悉项目时使用；不要因为能看到代码就默认批准。
命令行（CLI）	复杂排查、批量操作、持续测试、开发人员的深度工作	不必作为你的日常入口。可以让技术人员或 AI 使用，但同样要遵守任务卡和验收流程。
云端任务	任务边界非常清楚、耗时较长、可以异步完成的工作	只交付定义清楚、可独立验证的任务；涉及生产环境或敏感数据时不要直接放权。

选择入口的简单判断

• 需要先把问题想清楚：用客户端。

• 需要看清某个页面或某几处文件变化：用 IDE 或客户端的变更视图。

• 需要跑复杂检查或做深度排查：让技术人员或 AI 在命令行中执行，并把结果翻译给你。

• 任务已经非常标准、可以等待结果：考虑云端任务。

不要把“换入口”误认为“换项目”。无论从哪个入口开始，都应该进入同一个项目仓库、同一张任务卡和同一个独立工作房间。聊天可以分散在不同工具里，项目事实不能分散。

5. 常见开发场景应该怎么安排

场景	推荐安排	你要特别确认
很小的错误修复	一个工具负责定位和修复，另一个工具快速审查结果。	是否真的复现了原问题；修复后是否证明问题消失。
新增一个功能	先让一个工具整理需求和方案，你确认后再让它实现；完成后交给另一个工具审查。	用户流程、成功标准、不做范围和兼容影响。
需求大、方向还不清楚	先用 Claude Code 和 Codex 分别给方案，不让任何一方立刻修改；比较后只选择一个方案进入实施。	先做最小可验证版本，不要一开始把整个系统重做。
页面或视觉问题	实现者负责修改，审查者重点检查真实页面、不同尺寸和关键交互。	必须看前后截图或可操作的页面，不能只看文字报告。
多个任务并行	每项任务使用不同的独立工作房间、不同任务卡和不同负责人。	两个任务是否会修改相同页面、数据库结构、权限或公共配置；如果会，就改为先后执行。
线上紧急故障	先止损、保存现场、做最小修复；恢复后再补完整分析和长期方案。	谁授权上线、怎样回退、数据是否受损；不要趁机顺手大改。
上线、数据库、账号权限、支付	AI 可以分析和准备方案，但执行前必须由有权限的人确认；重要项目最好再找技术人员复核。	目标环境、影响范围、备份、回退方案和授权人。

什么时候可以让两个工具并行

只有在任务边界完全分开时才并行，例如：一个负责整理文档，另一个负责补测试；或者两个功能位于完全不同的区域，并且有不同的独立工作房间。

什么时候必须排队进行

只要两个任务会碰到同一个页面、同一份公共配置、数据库结构、账号权限、依赖清单、发布流程或同一批文件，就应该先做一个、检查完成后再做另一个。

6. Claude Code 与 Codex 怎样配合最顺畅

6.1 最稳妥的组合：一方实现，另一方审查

双工具的最大价值不是让两边同时写得更快，而是形成第二双眼睛。默认安排如下：

1. 选择当前更顺手、更可用的一个工具担任实现者。

2. 让它先提出计划、风险和预计修改范围。

3. 必要时让另一个工具只审查计划，帮助发现遗漏。

4. 仍由原实现者完成修改和验证，避免多人同时施工。

5. 完成后把任务卡、变化记录和验证证据交给另一个工具独立审查。

6. 如果审查发现问题，交回实现者修复，再由审查者复查。

不要长期规定“Claude 只能做后端、Codex 只能做前端”。模型能力、项目熟悉度、入口和可用性都会变化。应该固定的是角色和流程，而不是品牌。

6.2 三种推荐搭配

搭配	适用情况	做法
Claude 实现，Codex 审查	当前 Claude 已经熟悉任务或更容易继续上下文	Claude 保持唯一写入权；Codex 读取项目记录和变化，只报告问题。
Codex 实现，Claude 审查	当前 Codex 更方便操作本地项目、执行检查或持续工作	Codex 保持唯一写入权；Claude 独立核对需求、边界和风险。
双方先出方案，再由一方实施	需求复杂、方向不确定、一次选错代价较高	两边都先不改文件，分别给方案；你选择后，只指定一个实现者。

6.3 审查时不要问“你觉得怎么样”

应该让审查者重点寻找以下问题：是否偏离需求、是否扩大范围、是否漏掉异常情况、是否影响原有功能、是否碰到权限或数据风险、测试是否真的覆盖了关键行为、所谓“完成”是否可以复现。

审查者发现问题时，先给出问题位置、影响和验证方法，不要直接接管修改。这样可以避免两个工具同时成为写入者。

7. 额度耗尽、服务异常或账号不可用时怎样接管

切换工具不是重新开始，而是更换接班人。接班人必须先读交接记录、核对存档，再继续施工。

7.1 八步接管法

1. 让原工具停止修改。明确说“先暂停，不要继续写文件或执行发布”。

2. 确认后台工作已经停止。尤其是自动测试、长时间任务或云端任务，避免它稍后又改动项目。

3. 留下存档点。把当前能保存的内容保存下来；即使有未完成部分，也要记录真实状态。

4. 更新交接记录。写清已完成、未完成、改过的内容、测试结果、已知问题和下一步唯一动作。

5. 新工具进入同一个独立工作房间。不要另开一个来历不明的项目副本。

6. 新工具先复述，不要立刻修改。让它说明自己理解的当前状态、风险和下一步。

7. 核对一致后再移交写入权。从这一刻起，新工具才成为唯一实现者。

8. 完成后仍要独立审查。接管成功不代表结果自动正确。

7.2 账号或服务不可用时的原则

• 真正的备份应该跨供应商。同一供应商的客户端、IDE 和命令行可能共享账号或服务故障，它们不是完整的备份。

• 项目必须保存在你能控制的位置。代码、任务卡、测试方法和交接记录不能只存在某家工具的聊天历史里。

• 使用官方、合规的账号和授权。不要把“接管方案”建立在共享账号、转售账号、规避平台限制或绕过安全措施上。

• 提前验证备用通道。不要等主工具不可用才第一次让备用工具打开项目；每隔一段时间让它做一次只读审查。

• 敏感信息单独管理。密钥、生产权限和付款信息不要写进聊天或项目普通文件；切换工具时也不要随手复制。

7.3 不完整工作也可以交接，但不能假装完整

原工具突然不可用时，不必强求它先“收尾”。新的工具可以接管未完成内容，但必须先标记哪些结果没有验证、哪些文件可能只改了一半、哪些测试失败。最危险的不是半成品，而是把半成品误认为已经完成。

8. 哪些事可以放心交给 AI，哪些必须由人确认

可以把 AI 操作分成绿灯、黄灯和红灯。颜色代表需要多少人工确认，不代表工具能力强弱。

等级	典型事项	处理方式
🟢 绿灯	阅读和解释、整理计划、补文档、在独立房间内做小范围修改、运行普通测试	可以让 AI 自主推进，但仍要保留任务边界和结果证据。
🟡 黄灯	新增依赖、修改公共配置、大范围重构、数据库结构、登录鉴权、跨模块改动	AI 先给影响分析和回退方案；最好由另一工具或技术人员复核后再执行。
🔴 红灯	生产数据库、正式上线、删除数据、密钥和权限、支付、公开发布、发送外部消息	AI 只能准备方案和检查清单；执行前必须由明确授权的人确认，重要事项需要人工监督。

出现这些信号时，立即暂停

• AI 开始修改任务卡之外的大量内容，却不能解释必要性。

• AI 说已经完成，但拿不出测试、截图、前后对比或可复现步骤。

• AI 建议跳过测试、直接上线、先删除再说，或者隐藏失败结果。

• 同一个问题连续修两次仍没有改善，或者每次修复都带来新的问题。

• 两个工具对当前状态的描述不一致，或者都认为自己是当前实现者。

• 操作会触碰生产环境、真实用户数据、密钥、权限、支付或不可恢复的删除。

非技术负责人不确定时怎么做

不要问“这安全吗”，而要让 AI 分别回答：会影响谁、会改哪些地方、最坏会发生什么、怎样先备份、怎样回退、谁需要批准、如何在不执行的前提下先验证。答案仍然含糊时，就暂停并找技术人员复核。

9. 怎样判断“真的做完了”，而不是 AI 说做完了

9.1 “完成”必须有五份证据

1. 变化清单：改了哪些功能、页面或文件，哪些内容明确没有改。

2. 行为证据：问题修复前后有什么差别；页面类任务提供截图或可操作页面。

3. 检查结果：运行了哪些测试或自动质检，结果是什么；失败项不能省略。

4. 剩余风险：还有哪些情况没有覆盖，是否需要上线后观察。

5. 回退办法：如果结果不对，怎样恢复到修改前的安全版本。

9.2 你可以直接问的六个问题

1. 请用非技术语言说明：用户会看到什么变化？

2. 请展示问题修改前和修改后的对比。

3. 你实际做了哪些验证？请给出结果，不要只给结论。

4. 哪些情况还没有验证？最可能出错的地方在哪里？

5. 这次修改会不会影响现有用户、数据、权限或其他功能？

6. 如果上线后发现问题，最快怎样恢复？

9.3 不同任务的验收方式

任务类型	你应该看到的证据
页面和交互	真实页面、前后截图、关键点击路径、不同屏幕尺寸的结果。
数据和报表	数据来源、计算口径、样例核对、异常值和缺失数据说明。
接口和自动化	成功与失败样例、重复执行结果、超时或异常情况下的处理。
性能问题	相同条件下修改前后的数字对比，而不是“感觉更快”。
安全和权限	谁能访问、谁不能访问、错误权限是否被拒绝、是否留下审计记录。

一个简单标准：如果结果只能在原工具的聊天里“解释成立”，换一个人或工具就无法复现，那它还不能算完成。

10. 一周落地方案与可直接复制的模板

10.1 第一周怎么落地

1. 第 1 天：找技术人员做一次基础设置。建立项目规则、任务卡位置、独立工作房间的创建方法、标准检查方法和正式版本保护。你不需要自己敲命令，但要让对方留下操作说明。

2. 第 2 天：选一个低风险小任务试跑。从任务卡、计划、实施、证据到审查完整走一遍。

3. 第 3 天：安排一次双工具审查。让一个工具实现，另一个只读审查，观察它们是否能基于同一份记录协作。

4. 第 4 天：主动做一次切换演练。即使原工具可用，也暂停它，让另一个工具按照八步接管法继续。

5. 第 5 天：复盘流程。检查哪些信息仍只存在聊天里，哪些验收证据不够直观，并更新模板。

6. 之后每周：抽查一个任务的任务卡、存档、验证和审查是否齐全；每月做一次备用工具接管演练。

10.2 非技术任务卡模板

任务名称： 1. 为什么要做 谁遇到了什么问题？ 2. 希望看到的结果 用户完成什么动作后，应该看到什么？ 3. 这次不做什么 明确写出不在本次范围内的内容。 4. 不能碰的内容 例如：生产数据、账号权限、支付、其他页面。 5. 怎样才算完成 - [ ] 用户行为符合预期 - [ ] 原有重要功能没有受影响 - [ ] 有测试、截图或前后对比 - [ ] 已说明剩余风险和回退方法 6. 当前状态 当前唯一实现者： 已完成： 未完成： 验证结果： 已知问题： 下一步唯一动作：

10.3 给实现者的启动话术

你是这项任务当前唯一的实现者。 请先阅读项目规则和任务卡，先不要修改。 请用非技术语言告诉我： 1. 你理解的问题和目标； 2. 本次不应该做什么； 3. 你准备修改哪些部分； 4. 主要风险； 5. 如何证明完成。 我确认后再开始。实施过程中不要扩大范围。 涉及生产、数据库、权限、密钥、支付、删除、上线或对外发布时，立即暂停并请求确认。 完成后必须提供：变化清单、行为证据、检查结果、剩余风险和回退办法。

10.4 给审查者的话术

你是这项任务的独立审查者，先只检查，不要修改。 请阅读任务卡、项目规则、实际变化和验证证据，重点寻找： - 是否偏离需求或扩大范围； - 是否遗漏异常情况； - 是否影响原有功能、数据或权限； - 测试和截图是否真的能证明完成； - 是否存在上线、删除、密钥、支付或生产风险； - 如果出问题，是否能安全回退。 请把问题按“必须先解决 / 可以稍后改进”分组。 每个问题说明影响、证据和验证方法。 如果没有发现阻断问题，也请说明还有哪些内容没有验证。

10.5 工具切换交接话术

你现在接管这项任务，原工具已经停止修改。 先不要改任何内容。 请阅读项目规则、任务卡、最近的存档和当前未完成变化，然后回答： 1. 目前已经完成什么； 2. 哪些内容尚未完成或尚未验证； 3. 当前有哪些风险； 4. 你准备先做的第一个验证动作； 5. 接下来最小的续作计划。 请先复述状态。只有我确认你理解正确后，你才成为新的唯一实现者。

10.6 每日检查表

开始任务前

• 任务卡写清用户问题、期望结果和不做范围

• 高风险内容和禁止修改区域已经标出

• 已经指定唯一实现者和独立工作房间

切换工具前

• 原工具及后台任务已经停止

• 当前成果已经存档，失败和未完成项没有被隐藏

• 交接记录写清下一步唯一动作

• 新工具先复述状态，确认后才开始修改

正式交付前

• 已经收到变化、行为、检查、风险和回退五份证据

• 另一个工具或技术人员完成独立审查

• 红灯操作已经由有权限的人明确批准

10.7 给技术人员的一次性设置清单

你可以把下面这段交给技术人员，请他帮助完成一次基础建设：

• 把 Claude Code 和 Codex 的长期公共规则统一放在项目中，不依赖个人聊天。

• 建立任务卡模板，并规定每项任务必须使用独立分支和独立工作房间。

• 建立一条统一的自动检查方法，至少覆盖测试、代码检查和构建。

• 保护正式版本：未经检查和审查，不允许直接合并或上线。

• 给上线、数据库、权限、密钥、支付和删除操作设置人工确认。

• 写一页“新工具如何打开项目并接管”的说明，让非原开发者也能照着做。

10.8 技术实施参考

如果要让技术人员落地分支、独立工作房间、公共规则、自动检查和合并保护，可继续阅读技术版：Claude Code × Codex 多工具协作开发最佳实践。

最终建议：先用一个低风险小任务完整跑通，再增加并行任务或自动化。对非技术负责人来说，最值得养成的习惯不是学更多命令，而是坚持“任务卡、唯一实现者、存档点、独立审查、五份证据”。做到这五点，Claude Code 和 Codex 才能真正互为主力和备份。