---
title: "Codex 还是 Claude Code：两个都重度用过之后，我现在这样分工"
url: https://jacquesao.com/zh/posts/claude-code-vs-codex-how-i-split-the-work/
lang: zh-CN
author: Jacques AO
date: 2026-10-03
category: "科技趋势"
tags: ["Claude Code", "Codex", "AI 编程", "Agent", "工作流", "非程序员"]
description: "Codex 和 Claude Code 怎么分工、怎么一起用？我默认让 Claude Code 自己干，Codex 只接两类活。附分工表、踩过的四个坑，以及给不写代码的人的建议。"
alternates:
  zh: https://jacquesao.com/zh/posts/claude-code-vs-codex-how-i-split-the-work/index.md
  fr: https://jacquesao.com/fr/posts/claude-code-vs-codex-how-i-split-the-work/index.md
  en: https://jacquesao.com/en/posts/claude-code-vs-codex-how-i-split-the-work/index.md
---

# Codex 还是 Claude Code：两个都重度用过之后，我现在这样分工

我现在的分工很简单：默认让 Claude Code 自己干，Codex 只接两类活——要同时并行跑好几个互不相干的编码任务，或者一次性的超大批量机械活。拿不准的时候，不派 Codex，Claude Code 自己干。

这篇不比功能、价格和版本，只写我自己怎么分、为什么这样分、踩过哪些坑。它接着六月那篇[《用 Claude 这几个月，我把 Codex 和 ChatGPT 都搁下了》](https://jacquesao.com/zh/posts/claude-heavy-user-notes/)写，那时我的分工是 Claude 派单，Codex 跑机械活。Codex 本身怎么用，站里另有一篇[给非程序员的入门说明](https://jacquesao.com/zh/posts/codex-for-non-programmers-guide/)。

## 分工表

下面是我现在写在规则里的分工，格式是「什么活 → 给谁 → 原因」。

- **小改快修、功能开发、调试、上下文重的迭代，以及任何高判断、怕出错的活** → Claude Code 自己干。原因：更快更准，信息零丢失，没有交接和审核成本。
- **要同时并行跑多个互不相干的编码任务** → Codex。原因：要的是吞吐，几件事一起做。
- **一次性的超大批量机械活，比如几百个文件批量改** → Codex。原因：想让当前对话保持精简。
- **拿不准** → Claude Code 自己干。原因：派给 Codex 要写完整、自包含的任务单，做完还要严格审核；自己干没有这笔交接和审核成本。
- **上线、删除、付款、对外发送** → 谁干都要我点头。原因：这几类事做了就收不回来。

这里的「Claude Code 自己干」，也包括它派出去的 Claude 子 agent：由主 AI 派出去单独干活的小帮手，干完只把结论带回来。

## 两边各管什么

Claude Code 是总指挥：拆任务、派单、验收、汇报。Codex 是执行者：拿到任务自己拆，做到底，自己验证，再报告。我在它的规则里写明了，它是被派来把任务干完的，不是只做规划。

六月那篇里我写过两者的脾气：Codex 像程序员，需求得讲得很清楚，从 0 做到 90% 很强，最后那 10% 要反复磨；Claude 更像老板，更贴近人的思考方式，沟通成本低一截。这和现在的规则对得上：派 Codex 的活，我要求写成完整、自包含的任务单，做完严格审核。

派给 Codex 的活，流程是固定的。先把「改什么、怎么改」定下来，预演一遍（只看会改什么，不真改）；我确认后，Codex 在专用分支（和主版本隔开的一条改动线）上动手；做完由 Claude Code 审 diff（改动清单）、跑测试，才合进去；碰线上、部署、删数据，再等我点头。六月底定下这个流程时，我的原话是：「不是让你直接全部改完，而是确定了之后再去修改。」

## 为什么默认是 Claude Code

先算交接和审核这笔账：每把一件事交给另一个工具，就多一次「把前情讲完整」，和一次「事后审一遍」。上下文重的迭代尤其如此，前情都在当前对话里，自己干，信息零丢失。

另一笔账是对话的体积。我的规则是过程沉到子 agent，主对话只留结论。原话：「对话我不需要知道详细的分析过程，我没时间看，给子 agent 弄，我只需要汇总的结果。」九月底的一次实测里，我这台电脑上的 1110 个历史子 agent，中位数在内部用掉约 4.2 万 token（AI 处理文字的计量单位），带回主对话的只有约 900。主对话越胖，压缩越勤，AI 忘得越多。这条规则我在两边的规则文件里都写了，也是超大批量机械活交给 Codex 的原因之一。

## 踩过的四个坑

**1. 卡死不动。** 这是我抱怨最多的问题。派 Codex 或跑长命令时，如果在前台跑，或者 AI 写一句「我等 Codex 做完再继续」就结束这一轮，它自己不会醒，对话就永远停在那里。现在的规矩：这类活一律放后台跑，完成时系统自动叫醒 AI，由它验收、继续，不用我催。测试、爬虫、大文件下载同理。

在 Claude Code 里，同步跑的子 agent 还会被我发的任何新消息打断，记成「被用户停止」，我等久了问一句「好了吗」就把它杀了，后台任务不受这个影响。

另一种卡法是死磕一个小项，所以两边的规则里都有同一条：每做完一项马上存盘；单项试两次搞不定就跳过，记一行「待人工」；永远要出部分结果，不要零产出。比如 30 项里有 3 项失败，也要交 27 项的汇总表加那 3 项的清单。

**2. 互相覆盖。** 有个项目，Claude 和 Codex 来回干，老版本把新版本盖掉了。查下来，那个项目当时不是 git 仓库（会记录每次改动的项目目录）：后写的直接盖掉先写的，救不回来。

现在分三层：项目做成 git 仓库，误覆盖能找回；一个任务同一时间只有一个写者，改项目前先看有没有别人在改，没人才能拿锁，拿不到就去做别的事，不硬上，锁两小时自动过期；开工前先读项目的进度文件。派 Codex 之前再加一条：先查目标项目有没有没提交的改动，它只在干净的分支上干，不删、不覆盖。

**3. 同一个对话里的子 agent 也会撞车。** 同一个 Claude 对话派出两个子 agent，一个修网站的汉堡菜单，一个同时做性能优化，改的是同一批文件。第二个以线上版本为起点，部署之后线上变成「有性能优化、没有菜单修复」。根子是起点选错了，不是手快手慢：以线上为起点，天然会吞掉所有还没上线的本地改动。最后靠三方合并补了回来，但那是运气，两处改动碰巧没碰同一行。现在的规矩：本地镜像（本机上留的那份副本）才是唯一基准；会改同一批文件的子 agent，要么串行，要么按文件切开。

**4. 规则写错了文件。** Claude Code 读 CLAUDE.md，Codex 读自己全局目录下的 AGENTS.md，各读各的。九月底，AI 去改 Codex 的规则，改到了一份 Codex 平时读不到的镜像文件（把 CLAUDE.md 里的 Claude 换成 Codex 得到的那份），第二天靠一次实测才发现。还有一条：Codex 的工具说明要求，没有用户或规则文件明确要求，不准派子 agent，所以我在它的规则文件里专门写了一段授权。

## 如果你不写代码

几条可以直接拿去用的：

- **先让一个工具干到底。** 只有出现这两种信号才请第二个：要同时做好几件互不相干的事，或者有一次性的大批量机械活。拿不准，还是第一个。
- **进度写进项目里的一个文件，别留在聊天里。** 我用 COWORK.md，顶部固定四行：当前状态、下一步、卡点、更新。换工具、换对话，新来的先读它就能接上，你不用当传话筒。对话只是干活的手，记忆放在文件里。
- **项目做成 git 仓库，同一批文件同一时间只让一个 AI 改。** 前者管「改坏了救得回来」，后者管「不被同时改」。
- **交活要证据，别收一句「已完成」。** 要求 AI 在说「改好了」之前，先自己端到端验证；子 agent 回报了，也抽查关键证据。对外发邮件、发消息，AI 只拟草稿，我明确说「发」才发，「好」「可以」都不算。