第 1 周 · D5约 4 小时

Claude 与 Codex 选型与协作：同一任务双工具实测对比、一个写一个审的混用工作流

用同一个任务分别走一遍 Codex 与 Claude Code，从交代方式、审批、验证、成本四个维度做对比，再把两家工具组合成「一个写、一个审」的日常工作流。

今日目标 0/3

能用同一个任务在 Codex 与 Claude Code 上各跑一遍，并按四个维度记录可比的运行数据
能说清两家 coding agent 在项目上下文、审批模型、验证习惯上的异同，并向团队解释选型理由
能搭一条「一个写一个审」的混用工作流，并知道它在什么情况下不值得

登录后可以勾选并保存进度。

今日目标

能用同一个任务在 Codex 与 Claude Code 上各跑一遍，并按四个维度记录可比的运行数据
能说清两家 coding agent 在项目上下文、审批模型、验证习惯上的异同，并向团队解释选型理由
能搭一条「一个写一个审」的混用工作流，并知道它在什么情况下不值得

四天下来，OpenAI 这位搭档的工作方式你已经摸透了。今天把另一家的搭档请进同一间屋子，交同一件活，看两人怎么干。要解决的问题只有一个：当有人问你「我们团队该用哪个」时，你能给出一套对方能验证的理由，而不是一句「我用着顺手」。读完做完，回到页面顶部把三条目标勾掉。

小白版讲解

为什么要实测而不是看榜单

两位搭档来自不同公司，你想知道谁更适合你的团队。最省事的办法是看榜单——但榜单测的是「解一道标准题」，你的团队干的是「在一个有历史包袱的仓库里改一个接口」，两者的差距大到榜单基本没有参考价值。更要命的是，榜单只报一个分数，而你在日常里真正在乎的是四件很具体的事：

维度	你实际在问的问题
交代	我要写多少字、准备多少上下文，它才能开始干对的活
审批	它中途打断我几次，每次是为了什么
验证	它是自己跑了测试才说做完，还是说做完了让我去跑
成本	花了多少时间、多少 token、多少钱

这四个维度有一个共同点：它们全部是可以在你自己的仓库里、用你自己的任务量出来的。所以本课的最后一天不给结论，给一套量法。任务就是这五天一直在用的那个：给一个 Express 或 FastAPI 的 TODO API 补上输入校验和对应的单元测试——隔壁 Claude 高效使用课的 D3 到 D5 用 Claude Code 做的也是它，两门课的读者可以直接互相对照数据。

量之前先定规矩，否则数据不可比：同一个仓库起点（同一个 commit）、同一段需求文字、两边各自的项目说明文件写同样的内容、都用默认权限、都要求「跑完测试再汇报」。这些规矩写进实验的记录模板里，你照着填就行。

同一任务走 Codex：AGENTS.md、workspace-write、/review 一路下来

Codex 这一边你已经很熟了，把前四天串起来就是完整流程。

交代：项目根目录放 D1 写好的 AGENTS.md（校验用 zod、测试用 vitest、错误响应形状），然后在 codex 里给一段需求：

TextText

给 POST /todos 补输入校验（title 1–200 字非空，done 可选布尔，失败返回 400 与 { error: string }），
并为 POST / GET / DELETE 三个路由补单元测试。校验库与测试框架按 AGENTS.md。
改完跑 pnpm test，全绿后用一句话汇报改了哪些文件。

记下这段需求的字数，以及 AGENTS.md 的字数——这就是「交代成本」。

审批：默认 Auto（workspace-write 加 on-request）。读文件、改文件、跑 pnpm test 都在沙箱内，不会弹；如果它决定装一个新依赖，npm install 要联网，会弹一次。记下弹了几次、每次为什么。

验证：观察它是不是真的跑了 pnpm test，输出里有没有测试通过的数字；如果测试红了它是自己修还是来问你。这一条最能看出「搭档」和「打字员」的区别。

成本：从开始到汇报的墙钟时间，加上会话结束时它报告的 token 用量。跑完再用 /review 让它自审一遍，把审查意见的条数和你认可的条数也记下来——这是下一节要用的数据。

同一任务走 Claude Code：CLAUDE.md、Plan Mode、权限模式一路下来

换到 Anthropic 这位搭档。如果你没上过 Claude 高效使用课，这里只用到几个已经确认存在的功能，够你跑完对比。

交代：Claude Code 的项目说明文件叫 CLAUDE.md，放在仓库根目录，作用和 AGENTS.md 完全对应；把同样的内容复制一份过去（/init 可以帮你生成初稿，但为了可比，今天直接用同一份文字）。需求文字一字不改。

审批：Claude Code 的权限模型是「按工具类型授权」——读文件默认放行，改文件和跑命令默认逐次询问，可以用 /permissions 把某类命令（比如 pnpm test）加入允许列表。它还有一个 Codex 没有直接对应物的东西：Plan Mode（Shift+Tab 切换，或 --permission-mode plan 启动）。在这个模式下它只读不写，先给你一份「打算怎么改」的计划，你点头后才开始动手。今天为了可比，两边都用默认权限；但在实验里，你可以多跑一次带 Plan Mode 的版本，看「先出计划」这一步对审批次数和返工次数的影响。

验证：同样看它是否主动跑测试。Claude Code 对 CLAUDE.md 里「改完必跑测试」这类规则的遵守度，和 Codex 对 AGENTS.md 的遵守度，是你可以直接对比的一项。

成本：同样记墙钟时间和 token。Claude Code 有 /context 可以看当前上下文占用，会话结束时也有用量统计。跑完用 /code-review 让它自审，记同样的数据。

两边都跑完，你手上有两份运行记录。把它们按实验给的 JSON 模板填好，对比脚本会替你生成对比表。

对比结果怎么读：差异多半来自工作方式

拿到对比表，最常见的误读是「谁的测试多谁就强」。先别急，用这个顺序看。

先看可比性。两边的需求文字一样吗？项目说明文件内容一样吗？起点是同一个 commit 吗？有一项不一样，后面的差异就说不清来源。

再看结构性差异，这些跟模型强弱无关。审批次数不同，多半是两家的默认权限模型不同：Codex 用操作系统沙箱划边界、边界内不问；Claude Code 按工具类型逐次问、可以加白名单。这不是谁更安全，是两种设计——一种把「安全」交给运行时限制，一种把「安全」交给人的逐次确认。验证行为不同，多半来自项目说明文件里那句「改完必跑测试」被放在什么位置、写得多明确。成本不同，先看 token 里输入占多少——输入 token 高说明它读了更多文件，可能是更谨慎，也可能是项目说明文件没告诉它该看哪里。

最后才看能力差异。同样的需求，一边写出的测试覆盖了「title 超过 200 字」这个边界、另一边没有，这才是能力层面的差异——而且要多跑几次才能确认，coding agent 的输出本身有随机性，单次结果不能下结论。

下面这段是实验里对比脚本的核心：把两份记录变成同一张表。它不需要调模型，两个版本教的是同一件事——先把数据归一，再做比较。

compare.ts

interface RunRecord {
  tool: 'codex' | 'claude-code'
  promptChars: number
  instructionsChars: number
  approvals: { count: number; reasons: string[] }
  verification: { ranTests: boolean; testsPassed: number; testsFailed: number }
  cost: { minutes: number; inputTokens: number; outputTokens: number }
  filesChanged: number
}
 
function row(label: string, pick: (r: RunRecord) => string | number, runs: RunRecord[]): string {
  return `| ${label} | ${runs.map(pick).join(' | ')} |`
}
 
export function renderTable(runs: RunRecord[]): string {
  const header = `| 维度 | ${runs.map((r) => r.tool).join(' | ')} |`
  const sep = `| --- | ${runs.map(() => '---').join(' | ')} |`
  return [
    header,
    sep,
    row('交代：需求字数 + 说明文件字数', (r) => r.promptChars + r.instructionsChars, runs),
    row('审批：中断次数', (r) => r.approvals.count, runs),
    row('验证：自己跑了测试', (r) => (r.verification.ranTests ? '是' : '否'), runs),
    row('验证：通过 / 失败', (r) => `${r.verification.testsPassed} / ${r.verification.testsFailed}`, runs),
    row('成本：分钟', (r) => r.cost.minutes, runs),
    row('成本：token（输入 + 输出）', (r) => r.cost.inputTokens + r.cost.outputTokens, runs),
    row('改动文件数', (r) => r.filesChanged, runs),
  ].join('\n')
}

compare.py

from dataclasses import dataclass
from typing import Callable
 
 
@dataclass
class RunRecord:
    tool: str
    prompt_chars: int
    instructions_chars: int
    approvals: int
    ran_tests: bool
    tests_passed: int
    tests_failed: int
    minutes: float
    input_tokens: int
    output_tokens: int
    files_changed: int
 
 
def row(label: str, pick: Callable[[RunRecord], object], runs: list[RunRecord]) -> str:
    return f"| {label} | " + " | ".join(str(pick(r)) for r in runs) + " |"
 
 
def render_table(runs: list[RunRecord]) -> str:
    header = "| 维度 | " + " | ".join(r.tool for r in runs) + " |"
    sep = "| --- | " + " | ".join("---" for _ in runs) + " |"
    return "\n".join(
        [
            header,
            sep,
            row("交代：需求字数 + 说明文件字数", lambda r: r.prompt_chars + r.instructions_chars, runs),
            row("审批：中断次数", lambda r: r.approvals, runs),
            row("验证：自己跑了测试", lambda r: "是" if r.ran_tests else "否", runs),
            row("验证：通过 / 失败", lambda r: f"{r.tests_passed} / {r.tests_failed}", runs),
            row("成本：分钟", lambda r: r.minutes, runs),
            row("成本：token（输入 + 输出）", lambda r: r.input_tokens + r.output_tokens, runs),
            row("改动文件数", lambda r: r.files_changed, runs),
        ]
    )

表格本身不下结论，结论是你在报告模板里写的那几行。模板里有一栏叫「这个差异来自工作方式还是能力」，每一行差异都要填——填不出来的差异，就是你还没搞懂的地方。

一个写一个审：把两家工具串成日常工作流

D2 讲代码审查时留了一个话头：审查和生成用同一家模型，抓不出「需求理解错了」这类问题，因为两者共享同一份理解。解法就是换一家来审。今天两位搭档都在屋里，正好把这条工作流搭起来。

流程只有三步。第一步，A 写：用你顺手的那家（假设是 Codex）完成任务，跑通测试。第二步，B 审：把 diff 连同需求原文和验收标准交给另一家（Claude Code），要求它只找问题不改代码，输出结构化的审查意见——文件、行号、问题、严重级别。第三步，人裁决：你逐条看审查意见，决定哪些回给 A 修、哪些驳回。修完可以再审一轮，但通常一轮就够。

两家都有脱手模式，所以这条流程可以写成脚本：Codex 用 codex exec，Claude Code 用 claude -p 加 --output-format json（还可以用 --allowedTools 把审查方限制成只读）。审查方拿到的输入很关键——一定要给需求原文，只给 diff 它就退化成了 lint；一定要要求结构化输出，不然你没法自动统计「哪些意见被采纳了」。

BashBash

# 第一步：A 写（Codex 脱手模式）
codex exec "$(cat task.md)。改完跑 pnpm test，全绿后停下。"
git diff > /tmp/change.diff
 
# 第二步：B 审（Claude Code 脱手、只读、结构化输出）
claude -p "需求见 task.md，验收标准见 acceptance.md。只审查不修改，按 JSON 数组输出：file、line、issue、severity。" \
  --allowedTools "Read,Grep,Glob" --output-format json < /tmp/change.diff > /tmp/review.json
 
# 第三步：人裁决，把采纳的意见回给 A

什么时候不值得这么做？三种情况。一是任务小到审查成本高于任务本身——改一个错别字不需要两家会审。二是团队只买了一家的额度，跨家审查意味着双份账单，要算清「多抓出的问题」值不值这笔钱。三是审查意见没人看——如果团队习惯一键接受，那第二家的意见只是多了一层噪音。这条工作流的价值全部来自第三步的人，人不在场，前两步就是浪费。

反过来，它最值的场景也很清楚：改动会影响多个调用方、需求本身有歧义、或者这次改动要上生产。这三种情况下，多一份来自不同模型的独立意见，抓出一个理解偏差就回本了。

接下来往哪走：从会用工具到会造工具

五天里你学会了怎么用 OpenAI 这边的工具干活：让 Codex 在本地和云端改代码、让它审代码、用 Responses API 和 Agents SDK 写自己的小 Agent，最后把两家工具放在一起比较和组合。这门课的定位是「会用」，它有意没碰的是「会造」。

三个方向，按你的情况选。

想把另一家也用顺手：去 Claude 高效使用课，五天，结构和这门课逐天对位，用的是同一个 TODO API 任务，两门课读完你手里就有一份完整的双工具对比。

想知道 Codex 和 Agents SDK 底下是怎么造出来的：去 30 天从前端工程师到 Agent 工程师。它从第一天的 LLM API 开始，手写 Agent 循环、工具系统、多 Agent 编排，一路做到生产级的网关与工作池。你今天用的 run 函数、handoff、guardrail，在那门课里都会亲手实现一遍。

想深挖某一层：D2 接的 MCP server 怎么写、D2 讲的 skills 怎么设计成可复用的能力，分别是即将上线的 mcp-7days 与 agent-skills-7days 两门专题课的内容。两门课都以「你已经会用 Codex 或 Claude Code」为起点，正好接在今天之后。

最后回到这门课的类比。两位搭档的工作方式不同，但你带他们的方法是一样的：写清楚入职手册、画清楚权限边界、要求他们跑完验证再汇报、重要的活让另一位审一遍。这套方法不属于任何一家公司，它属于你。

源码导读

动手实验

🧪 D5 实验：双工具对比脚本与对比报告模板

代码位置：labs/codex-mastery/day-05-dual-tool-compare

验收标准：

两份运行记录 runs/codex.json 与 runs/claude-code.json 都按模板填完，起点 commit、需求文字、说明文件字数三项在两份里一致。
pnpm start runs/codex.json runs/claude-code.json 输出一张 Markdown 对比表，四个维度全部有数据。
MOCK=1 pnpm start 用内置样例数据也能输出同样形状的表。
报告模板里每一行差异都填了「来自工作方式还是能力」，并写下了一条你自己的混用工作流。

代码在 labs/codex-mastery/day-05-dual-tool-compare，starter/ 挖了四个练习点，solution/ 是完整答案。这个脚本不调任何模型，MOCK=1 的作用是用内置的样例记录代替你自己的两份 JSON，方便先看到表长什么样。

准备同一个起点：把 D1 的 TODO API 提交一次，记下 commit id，git worktree add 两个工作副本分别给两家工具。
在 Codex 副本里放 AGENTS.md、跑任务、跑 /review，按 runs/template.json 的字段填出 runs/codex.json。
在 Claude Code 副本里放同内容的 CLAUDE.md、跑同一段需求、跑 /code-review，填出 runs/claude-code.json。
先 MOCK=1 pnpm start 看样例表，再 pnpm start runs/codex.json runs/claude-code.json 生成你自己的对比表。
把表贴进 report-template.md，逐行填「工作方式还是能力」，最后写下你的选型结论和一条混用工作流。

面试题

今天 3 道题在下方题库区，侧重 coding agent 选型的可比维度、混用工作流的收益与成本、如何向团队解释取舍。展开后先看「分析过程」再看要点——照着推导练，比背要点管用。

检查清单与明日预告

能用同一个任务在 Codex 与 Claude Code 上各跑一遍，并按四个维度记录可比的运行数据
能说清两家 coding agent 在项目上下文、审批模型、验证习惯上的异同，并向团队解释选型理由
能搭一条「一个写一个审」的混用工作流，并知道它在什么情况下不值得
能对任何一行对比差异说出「这来自工作方式还是能力」
实验的 4 条验收标准全部通过
3 道面试题不看要点也能答出至少 2 道

这是本课的最后一天。回头看 D1 的自己：那时你还在装 Codex，现在你能把两家工具放在同一张表上比较，并且知道差异从哪来。下一步去 Claude 高效使用课补齐另一边，或者去 30 天课亲手把今天用过的东西造一遍。

面试题库

团队要在两家 coding agent 之间选一个，你怎么给出一套可以向团队解释、也能被验证的对比维度？Your team must pick between two coding agents. How do you propose a comparison that teammates can both understand and verify?
国内高频海外高频进阶#coding-agent#evaluation#decision-making
分析过程 · 先想清楚再作答
这题考的是方法论而不是结论。上来就说「我觉得 X 好」会被判为没有工程判断；面试官想听的是你怎么让比较可复现。
先给维度：交代（写多少需求、准备多少说明文件）、审批（中断几次、为了什么）、验证（是否主动跑测试、红了怎么办）、成本（时间、token、钱）。这四项都能在自己的仓库里量出来。
再给可比性的前置条件：同一个起点 commit、同一段需求文字、说明文件同内容、默认权限、都要求跑完测试再汇报；有一项不同，差异就说不清来源。
然后是读数的顺序：先查可比性，再看结构性差异（权限模型、说明文件的位置与措辞导致的行为差别），最后才看能力差异，而且能力差异要多次运行取中位数。
落到团队沟通：报告里每一行差异都标「来自工作方式还是能力」，工作方式的差异靠配置弥补，能力差异才影响选型。
可预期的追问：榜单为什么不够？榜单测标准题，团队干的是有历史包袱的仓库里的改动，且榜单只给一个分数、不给四个维度。
How to reason about it · think before answering
This tests methodology, not a verdict; leading with 'I prefer X' signals weak engineering judgment. Show how you make the comparison reproducible.
Give the dimensions: instruction effort (prompt and instruction-file size), approvals (how many interruptions and why), verification (does it run tests unprompted, what happens on red), cost (time, tokens, money). All are measurable in your own repo.
State the preconditions for comparability: same starting commit, identical requirement text, identical instruction-file content, default permissions, and 'run tests before reporting' on both sides.
Then the reading order: check comparability, then structural differences (permission model, placement and wording of rules), and only then capability differences, which need several runs and a median.
For the team: label every differing row as 'workflow' or 'capability'; workflow gaps are closed by configuration, capability gaps drive the choice.
Expect the follow-up: why not benchmarks? They score standard problems with one number, while teams change legacy repos and care about four dimensions.
答题要点
四个可量维度：交代、审批、验证、成本，全部在自己仓库里测
可比性前置：同起点、同需求、同说明文件、默认权限、都要求跑测试
读数顺序：可比性、结构性差异、能力差异；能力差异要多次运行取中位数
每行差异标「工作方式还是能力」，前者靠配置弥补，后者才决定选型
Key points
Four measurable dimensions: instruction effort, approvals, verification, cost, all measured in your own repo
Comparability first: same commit, same prompt, same instruction file, default permissions, tests required
Read in order: comparability, structural differences, then capability, with medians over several runs
Label each gap as workflow or capability; only capability gaps should drive the decision
「一家写、另一家审」的混用工作流收益在哪？什么情况下不值得？Where does the 'one vendor writes, the other reviews' workflow pay off, and when is it not worth it?
国内高频海外高频进阶#code-review#workflow#coding-agent
分析过程 · 先想清楚再作答
题眼在「不值得」。只讲收益不讲代价，是没在预算表前坐过的人的答法。
先说收益的来源：同一家模型写与审共享同一份对需求的理解，需求理解偏差抓不出来；换一家审，最大的增量正是这类偏差，其次是不同模型的盲区互补。
再说怎么做才有收益：审查方必须拿到需求原文与验收标准而不只是 diff，否则退化成 lint；必须要求结构化输出，否则无法统计采纳率；最后一步必须由人裁决。
不值得的三种情况：任务小到审查成本高于任务本身；团队只有一家的额度，跨家意味着双份账单且多抓出的问题不值这笔钱；审查意见没人认真看，多一家只是多一层噪音。
最值的三种情况：改动影响多个调用方、需求本身有歧义、改动要上生产——抓出一个理解偏差就回本。
可预期的追问：能不能自动化？两家都有脱手模式，写与审都能脚本化，但「人裁决」这一步不能省，否则前两步就是浪费。
How to reason about it · think before answering
The crux is 'not worth it'; listing benefits without costs reads as never having sat in front of a budget.
Source of value: when one model both writes and reviews, they share one reading of the requirement, so misreads slip through; a second vendor catches exactly those, plus complementary blind spots.
How to make it pay: the reviewer needs the original requirement and acceptance criteria, not just the diff, or it degrades into lint; demand structured output so acceptance can be measured; a human makes the final call.
Not worth it when the task is smaller than the review, when only one vendor's quota exists and the extra bill outweighs extra findings, or when nobody reads review comments carefully.
Most worth it when a change touches many callers, the requirement is ambiguous, or the change ships to production; one caught misread pays for it.
Expect the follow-up: can it be automated? Both vendors have headless modes so writing and reviewing can be scripted, but the human adjudication step cannot be removed.
答题要点
收益来自独立的需求理解：换一家审能抓出同家审查抓不到的理解偏差
审查方要拿到需求原文与验收标准、输出结构化意见，最后由人裁决
不值得：任务太小、只有一家额度、没人认真看意见
最值：影响多个调用方、需求有歧义、要上生产
Key points
Value comes from an independent reading of the requirement, catching misreads a same-vendor review misses
The reviewer needs the requirement and acceptance criteria, must output structured findings, and a human adjudicates
Not worth it for tiny tasks, single-vendor budgets, or teams that do not read reviews
Most valuable for multi-caller changes, ambiguous requirements and production deploys
怎么评价一个 coding agent 这次任务的输出质量，而不只是看它跑没跑通？How do you judge the quality of a coding agent's output on a task, beyond whether it ran?
国内高频海外高频深入#coding-agent#evaluation#quality
分析过程 · 先想清楚再作答
这题考的是你有没有把「测试绿了」当终点。答「看测试」是及格线，区分度在测试之外。
拆成四层：正确性（测试是否覆盖了需求里的边界，比如 title 超长、done 传字符串）、契约（错误响应形状是否与需求一字不差，还是它自作主张改了）、范围（有没有改不该改的文件、有没有偷偷加依赖或改默认值）、可维护性（校验规则是否抽成常量、测试是否隔离、命名是否与仓库一致）。
再说怎么量：正确性看它写的测试之外你再补的反例能不能过；契约与范围看 diff 与需求逐条对照；可维护性交给第二家模型或人做结构化审查。
补一条随机性：单次结果不能下结论，同一需求跑三次看方差，方差大本身就是一个质量信号。
可预期的追问：它自己说「已完成并通过测试」能信吗？只信你能复现的部分——在你的机器上重跑测试、看 diff，agent 的汇报是线索不是证据。
How to reason about it · think before answering
This tests whether you treat green tests as the finish line; 'check the tests' is the pass mark, differentiation lies beyond it.
Four layers: correctness (do the tests cover the requirement's edges such as overly long titles or a string for done), contract (does the error shape match the spec exactly or did it improvise), scope (did it touch forbidden files, add dependencies or change defaults silently), maintainability (constants extracted, tests isolated, naming consistent with the repo).
How to measure: correctness by adding your own counterexamples beyond its tests; contract and scope by diffing against the requirement line by line; maintainability via a structured review by a second model or a person.
Add variance: one run proves nothing; run the same requirement three times and treat high variance as a quality signal in itself.
Expect the follow-up: can you trust its 'done, tests pass'? Only what you can reproduce; rerun tests and read the diff yourself, the agent's report is a lead, not evidence.
答题要点
四层：正确性、契约、范围、可维护性，测试绿只是正确性的一部分
正确性用自己补的反例验证，契约与范围对照需求逐条看 diff，可维护性做结构化审查
同一需求跑多次看方差，方差大本身是质量信号
agent 的汇报是线索不是证据，只信自己能复现的部分
Key points
Four layers: correctness, contract, scope, maintainability; green tests cover only part of correctness
Verify correctness with your own counterexamples, contract and scope by diffing against the spec, maintainability via structured review
Run the same requirement several times; high variance is itself a quality signal
The agent's report is a lead, not evidence; trust only what you reproduce

登录后即可参与讨论

还没有评论，来说第一句。