先把 Claude Code 和 Codex 分清楚
一个人开发者不需要再靠自己手写所有代码、自己拆需求、自己做审查、自己记住每个重复流程。Claude Code 和 Codex 可以分别承担不同环节，但前提是你不要把它们当成同一个工具用。
Claude Code 更适合规划、理解项目上下文、处理复杂逻辑和做高层审查。Codex 更适合执行明确任务、批量修改、运行命令、整理 diff 和做结构化检查。
这套组合的核心不是让 AI 自动接管项目，而是形成一个可重复的闭环：Claude Code 负责思考和拆解，Codex 负责执行和自动化，再由 Claude Code 或你本人做最后审查。
- Claude Code：需求澄清、架构规划、复杂逻辑推理、IDE 内代码协作
- Codex：命令行执行、代码生成、批量修改、自动化检查、diff review
- 你本人：决定边界、确认风险、运行关键验证、决定是否上线
为什么一个人开发者适合这套组合
一个人开发者最常见的问题不是不会写代码，而是没有第二个人帮你拆需求、查遗漏、审 diff、补测试和提醒风险。
只用一个 AI 工具时，效率会不稳定。它可能一会儿在做规划，一会儿在改文件，一会儿又跳到审查，最后每个环节都做了，但没有一个环节足够清楚。
把 Claude Code 和 Codex 分工后，你可以把工作流压成三个阶段：思考、执行、审查。这样每一步都有明确输入和输出，也更容易发现哪里没有完成。
- 交互写代码效率不稳定
- 不同工具的强项没有集中利用
- 代码风格、集成和审查没有统一流程
- 重复任务仍然靠手工复制提示词
- 开发完成后缺少可复查的验证记录
准备好 Claude Code 的工作入口
开始前先把 Claude Code 放到你真实写代码的位置。你可以使用 Claude Code CLI，也可以在 VS Code 里使用 Claude Code 扩展。
如果你主要在 VS Code 写代码，Claude Code 扩展可以直接在 IDE 内打开会话、查看选中文件、提出修改，并在写文件前展示 diff。官方文档也说明了 VS Code 扩展和 CLI 的区别：有些能力在 CLI 更完整，IDE 扩展更适合日常结对和审查改动。
对一个人开发者来说，Claude Code 的第一价值是理解上下文。不要一上来就让它改文件，先让它读项目规则、当前目录、相关组件和已有测试。
先阅读当前项目规则和相关文件，不要改文件。
请输出：
1. 这个需求涉及哪些模块
2. 最小修改范围
3. 可能影响的旧行为
4. 需要运行哪些验证命令
5. 哪些地方需要我确认后再改准备好 Codex 的执行入口
Codex 适合放在终端和仓库级任务里使用。你可以用 Codex CLI 做明确的执行任务，也可以用 Codex 做 review、批量检查和发布前整理。
安装和登录方式以 OpenAI 官方 Codex 文档为准。常见准备动作是安装 CLI、登录账号，然后在项目根目录让 Codex 读取仓库上下文。
如果你在一个已有项目里使用 Codex，先让它查看当前 diff 和项目规则，再允许它改文件。这样能降低它顺手改动无关文件的风险。
npm install -g @openai/codex
codex login如果官方安装命令发生变化，按 OpenAI Codex CLI 文档更新本地安装方式。
阶段一：让 Claude Code 做规划
正式开发前，先用 Claude Code 做需求澄清和任务拆解。这一步决定了后面 Codex 执行任务时会不会跑偏。
Claude Code 在这个阶段不要直接写代码。你要让它输出可以交给执行器的任务卡：范围、输入、输出、验收标准、测试方式和风险点。
对 Solo Dev 来说，规划阶段最重要的是把模糊需求变成小块任务。任务越小，Codex 后面越容易执行，review 也越容易判断对错。
请根据下面需求生成开发计划。
要求包括：
1. 任务拆分
2. 优先级
3. 每个任务的预期输出
4. 涉及文件或模块
5. 测试策略
6. 可能破坏的旧行为
需求：...阶段二：把明确任务交给 Codex 执行
当任务已经被拆清楚，就可以把执行部分交给 Codex。Codex 更适合处理结构化、边界清楚、结果可以验证的任务。
不要把“做完整系统”这种大目标直接扔给 Codex。更好的方式是把 Claude Code 产出的任务卡拆成一个个小命令，让 Codex 每次只处理一个明确目标。
每次执行后，都要看 diff。一个人开发最容易忽略的不是代码没生成，而是 AI 顺手改了你没要求它改的地方。
- 生成一个明确模块的代码
- 重构一个指定函数或组件
- 补一组测试用例
- 修复静态分析错误
- 整理重复代码
- 按清单检查文章或配置元数据
- 运行并汇总验证命令结果
codex exec "根据 docs/task-card.md 实现用户管理 REST API，只修改 src/routes/users.ts 和 src/services/users.ts，完成后报告 diff 和未验证项"阶段三：让 Claude Code 做高层审查
Codex 执行完以后，不要马上合并。下一步让 Claude Code 回到规划上下文里审查结果。
Claude Code 更适合看逻辑一致性、架构偏差、需求是否漏掉、错误处理是否完整。它不只是看语法，而是看这次实现有没有偏离最初计划。
你可以把 Codex 的 diff、验证结果和失败日志交给 Claude Code，让它给出风险清单。最后是否修改，仍然由你决定。
请审查这次变更是否符合最初开发计划。
重点看：
1. 是否有任务外改动
2. 数据流是否一致
3. 权限和错误处理是否遗漏
4. 测试是否覆盖主路径和失败路径
5. 哪些风险需要我手动确认模式一：Claude 规划，Codex 执行，Claude 审查
这是最稳的基础模式。Claude Code 先拆任务，Codex 根据任务卡执行，Claude Code 再审查结果。
它适合偏结构化、需要质量保证的功能开发。比如新增一个后台页面、补一个 API、改一个表单流程、整理一组测试。
这个模式的优点是每一阶段职责清楚。缺点是步骤比直接让一个工具全自动慢一点，但对一个人维护长期项目来说，这个慢是值得的。
- Claude Code：生成任务卡和验收标准
- Codex：按任务卡执行文件修改和命令检查
- Claude Code：审查 diff、逻辑和遗漏
- 开发者：确认风险、运行关键命令、决定合并
模式二：Claude 负责逻辑，Codex 负责细节实现
当任务里有复杂业务规则时，可以让 Claude Code 先把逻辑写清楚，再交给 Codex 做具体实现。
比如登录模块不只是写一个接口，还要包含 JWT 验证、数据库模型、错误处理、过期策略、权限边界和安全提醒。Claude Code 可以先把这些规则整理成实现规格。
Codex 拿到规格后，只负责把它落到代码里。这样可以避免 Codex 一边猜业务规则，一边改文件。
请先把登录模块写成实现规格，不要写代码。
规格必须包括：
1. 数据模型
2. API 输入输出
3. JWT 过期策略
4. 错误码
5. 权限边界
6. 测试用例清单
规格确认后，再交给 Codex 实现。模式三：Codex 快执行，Claude 复盘
有些任务不需要复杂规划，比如批量改文案、补类型、修 lint、整理重复字段。这类任务可以先让 Codex 快速执行，再让 Claude Code 复盘。
这个模式适合快速迭代，但要限制文件范围。你可以让 Codex 先做一个小 diff，然后让 Claude Code 判断是否继续扩大范围。
如果 Codex 的第一版 diff 已经出现任务外改动，就不要继续扩大范围。先回滚或收窄任务。
- 适合：批量小改、格式统一、测试补齐、简单重构
- 不适合：支付、权限、安全、数据迁移、生产配置
- 必要动作：限制文件、看 diff、保留回退点
用 Git Hook 做自动审查前先控制风险
你可以把 Codex 审查放进 Git Hook，让每次提交前自动生成审查报告。这个思路适合重复频繁的项目，但不要让 Hook 自动修复或自动提交。
更稳的方式是让 Hook 只输出报告，再由 Claude Code 或你本人读取报告并决定下一步。自动审查负责提醒，不负责替你承担上线责任。
如果审查命令很慢，可以先作为手动命令使用，稳定后再放进 Hook。
# .git/hooks/pre-commit
codex review HEAD~1..HEAD > review.mdHook 脚本要根据你本机 Codex 版本和项目命令实际调整，不要直接在生产仓库里启用未验证脚本。
把 Claude Code 当项目经理代理时要设边界
你可以让 Claude Code 扮演项目经理代理：判断任务是否清楚、是否需要交给 Codex、是否需要先补测试、是否存在高风险操作。
但这个代理不能拥有无限权限。它可以建议调用 Codex，可以拆任务，可以生成提示词，但涉及删除数据、改权限、改部署配置、改支付逻辑时，必须先停下来等待人工确认。
一个人开发者最需要的不是更大的自动化，而是更清楚的自动化边界。
- 允许自动处理：文案、样式小改、类型补齐、测试补充、文档整理
- 必须人工确认：数据库迁移、权限策略、支付流程、生产配置、依赖安装
- 必须保留证据：diff、验证命令、失败日志、未验证项
高风险任务要加安全与验证清单
如果你开始让 AI 参与部署、权限、SQL 操作、文件删除或用户数据处理，就不能只靠提示词约束。
至少要加一层安全与验证清单：先读、再计划、再确认、再执行、再验证。任何一步缺失，都不要进入下一步。
这不是形式主义。一个人开发时，没有同事帮你拦危险操作，流程本身就是你的第二双眼睛。
- 是否会写入或删除用户数据
- 是否会改变权限或认证逻辑
- 是否会影响支付、订单、发票或账务
- 是否会改生产环境变量或部署脚本
- 是否有备份、回滚和验证命令
- 是否有人工确认点
一人开发者可以照这个模板跑
下面是一套适合 Solo Dev 的 Claude Code + Codex 工作流。它覆盖从初始规划、代码执行、质量审查到最终部署的完整生命周期。
你不需要每次都完整走完全部步骤。低风险任务可以简化，高风险任务必须补齐审查和验证。
- Start Project：Claude Code 制定计划，输出 specs.md 或 task-card.md
- Implementation Phase：对每个任务调用 Codex 生成或修改代码，保存到 feature 分支
- Review Phase：Codex 输出 diff 或 review 草稿，Claude Code 分析设计缺陷和遗漏
- Test Phase：Codex 根据测试描述补测试，开发者运行关键验证命令
- Deploy Phase：Claude Code 检查部署步骤和回滚方案，开发者手动执行上线
每天可以按这个节奏工作
一个人开发者可以把日常节奏固定下来，减少每次重新设计工作流的成本。
这套节奏不追求全自动。它追求你在每一次交付前都能看见风险，看见验证结果，也看见没有验证的尾部状态。
- 早上：Claude Code 拆当天任务和风险点
- 开发中：Codex 执行小块任务并报告 diff
- 每个任务后：Claude Code 或 Codex review 当前改动
- 提交前：运行必要验证命令，记录未验证项
- 结束前：把重复提醒写进 AGENTS.md、CLAUDE.md 或 Skill
交付前必须看到这些证据
不管用 Claude Code 还是 Codex，结束时都要拿到验证结果。没有验证结果，就还没交付。
AI 可以帮你写代码，但它不能替你证明代码已经适合发布。一个人开发时，交付报告要比平时更严格。
最后请报告：
1. 改了哪些文件
2. 为什么这些文件属于本次范围
3. 运行了哪些验证命令
4. 每条命令的结果
5. 没有运行的命令和原因
6. 还需要人工检查的页面或状态
7. 是否存在任务外改动总结：一个人开发也要有团队流程
Claude Code + Codex 的价值，不是让一个人假装拥有完整团队，而是把团队里最容易缺失的几个环节补上：规划、执行、审查、验证和记录。
Claude Code 适合做策略与规划，Codex 适合做执行与自动化。组合起来以后，你可以把很多重复开发任务变成可复用流程，把临时提示词变成规则文件，把一次性审查变成稳定检查。
真正有效的 Solo Dev 工作流不是“AI 全自动开发”，而是“人负责判断，AI 负责加速，流程负责兜底”。当这个闭环稳定下来，一个人开发者就能更快交付，也更不容易把隐藏风险带进生产。