逐日AI
English
登录注册
第 1 周 · D2约 4 小时

Codex 进阶：云端任务、代码审查、MCP 接入、自定义指令、IDE 集成

把 Codex 从终端里的一个会话，扩展成能并行跑云端任务、能审 PR、能接外部工具、能在 IDE 里随手用的一整套工作方式。

今日目标 0/3

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

今日目标

  1. 能把一个任务派到 Codex 云端环境并行执行，回来审阅 diff 并决定是否开 PR
  2. 能用 /review 与 GitHub 上的 @codex review 让 Codex 审代码，并说清审查与生成的分工
  3. 能用 codex mcp add 接入一个 MCP server，并用 skills 沉淀一段可复用的流程

昨天你在终端里带着 Codex 干了一件活，全程盯着。今天要解决的问题是：活多了怎么办？盯不过来怎么办？它不会的事怎么办？答案分别是云端并行、代码审查、MCP 与 skills。读完做完，回到页面顶部把三条目标勾掉。

小白版讲解

云端任务：把活派出去，回来只看 diff

接着昨天那位外援搭档的故事。头几天他坐在你旁边，每改一处你都看着。等你信任他的工作方式了，下一步自然是：把活派给他，让他回自己公司做，做完把成果发过来，你只看结果。而且既然是派出去，一次派三件也没问题，反正不占你的桌子。这就是 Codex 云端任务的全部思路——任务在 OpenAI 那边的隔离容器里跑，跟你本地机器无关，你可以同时派出多个，每个跑完回来只看 diff。

入口有好几个：浏览器里打开 chatgpt.com/codex；终端里用 codex cloud 浏览或发起云端任务；IDE 扩展里可以把当前任务「派到云端」；手机上的 ChatGPT 也能发。它们背后是同一套东西：一个绑定了你 GitHub 仓库的云端环境（environment），每次任务在这个环境的一个新容器里 clone 你的仓库、跑你配的 setup 脚本、然后开始干活。

它和本地 CLI 最大的差别不是「在哪跑」，而是审批模型变了。本地有你实时点头；云端没有人在旁边，所以它的边界完全由环境配置事先画好：能不能联公网、装哪些依赖、有哪些环境变量。这意味着在云端你要把昨天「弹审批时再决定」的事，全部提前想清楚写进环境配置。回到工作流上，一个任务跑完，你会拿到一份摘要加一份 diff，可以做三件事：接受并一键开 PR、追问一句让它继续改、或者直接丢弃。codex apply 可以把某次云端任务的 diff 直接打到你本地的工作树上，适合「云端出方案、本地跑测试」的组合。

云端环境的配置：依赖、变量、要不要给它公网

环境配置是云端任务成败的分水岭，因为容器里没有你昨天那台装好一切的电脑。配置项就四类：

  1. 基础镜像与依赖：选运行时版本（Node、Python 等），在 setup 脚本里写安装命令，比如 pnpm install。setup 脚本在每次任务开始前跑一遍，跑失败任务就废了，所以它要像 CI 脚本一样可复现。
  2. 环境变量与密钥：测试要用的变量放进来。不要放生产密钥——容器里跑的是一个会自主执行命令的程序，你给它什么它就能用什么。
  3. 公网访问：默认关闭。开了它就能 npm install 新依赖、查文档；关了它只能用 setup 阶段装好的东西。折中方案是只在 setup 阶段联网装依赖，任务阶段断网。
  4. AGENTS.md：仍然生效。它随仓库一起被 clone 进容器，所以昨天写的手册在云端一样管用——这正是把规矩写进仓库而不是写进你脑子里的好处。

配置一次后，接下来所有任务共用，值得花半小时把它调到「随便发一个任务 setup 都能过」的状态。实验里你会真的配一遍。

代码审查：本地 /review 与 GitHub 上的 @codex review

搭档的活交回来了，谁来审？你当然要看，但你也可以让另一位审阅者先过一遍。Codex 的代码审查有两个入口，对应两种节奏。

本地、会话里：在 CLI 敲 /review，它给三个选项——审当前未提交的改动、对着某个基准分支审整条分支的 diff、或者你写一段自定义的审查指令（「只看有没有漏掉错误处理」）。审查结果以逐行评论的形式出现，不会改你的工作树，只报问题。脱手版本是 codex review，非交互，适合放进 pre-push 脚本。

远端、PR 上：在 GitHub 仓库里装好 Codex 的集成后，在 PR 评论里写一句 @codex review，它会读整个 PR 的上下文和已有评论，把审查意见以行内评论的形式贴回 PR。团队可以配成每个 PR 自动审。

一个很自然的疑问：让同一家的模型既写代码又审代码，审查还有意义吗？答案是有，但要理解它的边界。审查时模型拿到的输入不同——它看的是 diff 而不是需求，是站在「找问题」而不是「完成任务」的立场上，这种角色切换本身就能抓出不少生成时的疏漏（漏掉的边界情况、没更新的调用方）。但它抓不出「需求本身理解错了」这类问题，因为审查者和生成者共享同一份对需求的理解。所以最有价值的审查组合是：生成用一家、审查用另一家，D5 我们会正式把这条工作流搭起来。

MCP 接入：一条命令让 Codex 多一双手

搭档很能干，但有些事他做不了：查你们公司内部的工单系统、读你们自建的知识库、操作某个内部服务。你需要给他开账号、给他工具。MCP（Model Context Protocol）就是给 coding agent 接外部工具的通用协议——一个 MCP server 暴露一组工具，任何支持 MCP 的客户端都能调用。30 天课 D23 有它的协议细节，这里只讲怎么在 Codex 里用。

接一个 server 就一条命令：

BashBash
codex mcp add <server-name> --env KEY=VALUE -- <启动 server 的命令>

-- 后面是启动这个 stdio 型 server 的命令，--env 传它需要的环境变量。命令背后其实是往 ~/.codex/config.toml 里写了一段配置：

tomltoml
[mcp_servers.<server-name>]
command = "npx"
args = ["-y", "某个-mcp-server"]
env = { SOME_TOKEN = "从环境变量读，不要写死" }

直接编辑这段配置和敲命令是等价的。codex mcp list 查看已接入的 server；对需要 OAuth 登录的远程 server，用 codex mcp login <server-name> 完成授权。接好以后，Codex 在会话里会把这些工具当成自己的能力来用——你只需要用自然语言说「把这个 bug 记到工单系统里」，它会自己找到对应的工具。

还有一个反向用法值得知道：codex mcp-server 把 Codex 自己变成一个 MCP server。也就是说，别的 Agent（包括你在 D4 用 Agents SDK 写的那个）可以把「让 Codex 去改代码」当作一个工具来调用。这是把 coding agent 嵌进更大系统的入口。

自定义指令与 skills：规则归 AGENTS.md，流程归 skill

到这里你已经有两种「教」Codex 的方式：AGENTS.md 写规则，MCP 加工具。还差一种——可复用的流程。比如「发版前的检查流程」：改版本号、更新 changelog、跑全量测试、打 tag。这不是一条规则，也不是一个工具，而是一串步骤加一些判断，你不想每次都在提示词里重新描述一遍。这就是 skills 要解决的问题。

一个 skill 就是一个目录，里面有一个 SKILL.md，frontmatter 至少写 name 和 description，正文写这个流程怎么走；旁边可以放 scripts/（流程里要跑的脚本）和 references/（要参考的文档）。放的位置决定作用范围：仓库里的 .agents/skills/ 只对这个项目生效，用户目录下的 ~/.agents/skills/ 对你所有项目生效。

调用有两种方式：显式地在输入框里敲 $skill-name，或者什么都不做——Codex 会根据 description 判断当前任务是否匹配某个 skill，匹配了就自动用。所以 description 要写成「什么时候该用我」，而不是「我是什么」。

三者的分工可以一句话记住：AGENTS.md 管「做事的规矩」，MCP 管「能碰到的外部系统」，skill 管「反复要走的流程」。规矩每次会话都读；工具按需调用；流程按任务匹配。分不清的时候问自己：这段内容是每次都要遵守的（规矩），还是要去外面拿数据（工具），还是一套多步骤的做法（流程）？

如果你上过隔壁的 Claude 高效使用课，会发现 Claude Code 也有几乎同构的三件套：CLAUDE.md、MCP、.claude/skills/。两家在这一层的设计高度收敛，这本身就是一个信号——这套分工是 coding agent 的通用模式，学会一次两边都能用。

IDE 集成：把选中的代码直接交给它

最后一个入口是编辑器。Codex 的 IDE 扩展支持 VS Code 及其衍生编辑器（Cursor、Windsurf）、JetBrains 系列和 Xcode。装好后侧边栏多一个 Codex 面板，你在编辑器里选中一段代码，它就成了对话的上下文，不用再复制粘贴、不用再描述「我说的是那个文件的第几行」。

IDE 里的工作流和 CLI 是一致的：同样读 AGENTS.md，同样有审批与沙箱，同样能 /review。多出来的是两件事：一是 diff 直接在编辑器里逐块接受或拒绝，比在终端里看 git diff 舒服得多；二是可以把当前任务一键「派到云端」，本地继续干别的，云端跑完再回来看。扩展还会在改动前后自动做 git 检查点，方便整体回退。

什么时候用 IDE、什么时候用 CLI？一个粗略的口径：改动局部、需要频繁看代码上下文的用 IDE；跨多文件的大任务、要脱手跑的、要进脚本的用 CLI。两者共享登录、配置和会话记录，切换没有成本。

源码导读

动手实验

🧪 D2 实验：一次云端并行任务的执行清单

代码位置：labs/codex-mastery/day-02-cloud-task-checklist

验收标准：

  1. 为一个 GitHub 仓库配好了一个云端环境，随便发一个任务，setup 脚本都能通过。
  2. 「补输入校验」与「补单元测试」两个任务同时派出并都跑完，清单里记录了各自的起止时间。
  3. 每份 diff 都按清单做出了接受、追问或丢弃的决定，且写下了理由。
  4. 对接受的 diff 跑过一次 /review，清单里有一处你不同意审查意见并写明了原因。

今天是文档型实验，产出是一页可复用的云端任务清单。starter/ 是留了空位的清单模板，solution/ 是用本课 TODO API 填好的一份示范。没有 GitHub 仓库的读者可以把 D1 那个 TODO API 推到一个新建的私有仓库里。

  1. 在 chatgpt.com/codex 里给仓库建一个环境：选 Node 运行时，setup 脚本写 pnpm install，先关公网，发一个「列出项目里所有路由」的只读任务验证 setup 能过。
  2. 把「给 POST /todos 补输入校验」和「给现有路由补单元测试」作为两个任务同时派出，各自记下发起时间，并在清单里写明你预期它们会不会改到同一批文件。
  3. 两个任务回来后逐个看摘要和 diff，按清单里的三选一（接受 / 追问 / 丢弃）做决定，每个决定写一句理由。
  4. 对接受的那份用 codex apply 打到本地，跑一次测试，再跑 /review，把审查意见逐条标成同意或不同意。
  5. 把整个过程里「下次还会这么做」和「下次要改」的点各写三条，填进清单末尾的复盘区。

面试题

今天 3 道题在下方题库区，侧重云端 coding agent 的审批边界、代码审查与代码生成的分工、MCP 与 skills 的区别。展开后先看「分析过程」再看要点——照着推导练，比背要点管用。

检查清单与明日预告

  • 能把一个任务派到 Codex 云端环境并行执行，回来审阅 diff 并决定是否开 PR
  • 能用 /review 与 GitHub 上的 @codex review 让 Codex 审代码，并说清审查与生成的分工
  • 能用 codex mcp add 接入一个 MCP server，并用 skills 沉淀一段可复用的流程
  • 能一句话说清 AGENTS.md、MCP、skill 三者的分工
  • 实验的 4 条验收标准全部通过
  • 3 道面试题不看要点也能答出至少 2 道

明天（D3）我们往下钻一层：Codex 这样的成品，底下是怎么用 Responses API 把模型、工具和多轮状态组织起来的。先用成品再看 API 是有意的顺序——你已经亲眼见过「模型请求一个工具、拿到结果、继续」这个循环在 Codex 里长什么样，明天看到 function_call 和 function_call_output 这两个字段时，就知道它们对应的是哪一步，而不是在读一份抽象的接口文档。

面试题库

  • 云端 coding agent 能同时跑很多任务，但没有人在旁边点头。它的审批边界应该画在哪里？A cloud coding agent can run many tasks in parallel with nobody around to approve steps. Where should its approval boundary sit?
    国内高频海外高频进阶#coding-agent#cloud#approvals

    分析过程 · 先想清楚再作答

    1. 这题考的是你有没有意识到「审批模型变了」：本地是逐步审批，云端只能事先授权、事后审阅。答成「跟本地一样弹窗」说明没用过。
    2. 拆法是把边界分成三个时间点：任务开始前（环境配置决定能联网什么、有哪些变量、装什么依赖）、任务执行中（容器隔离，改动只在容器里）、任务结束后（人审 diff 再决定开不开 PR）。
    3. 结论是：云端的审批边界就是「环境配置 + PR 前人工审阅」这两道门，中间不再有人；所以生产密钥不能进环境、公网默认关、合并权限保留在人手里。
    4. 补一条工程视角：并行任务之间的边界也要画——互相会改同一批文件的任务不要同时派，否则合并成本吃掉并行收益。
    5. 可预期的追问：能不能让它自动合并？可以在低风险仓库对通过全部测试的 PR 这么做，但要保留回滚手段，并且把「自动合并」本身当成一个需要审批的配置变更。

    How to reason about it · think before answering

    1. This checks whether you noticed the approval model changed: local means step-by-step approval, cloud means authorize upfront and review afterwards.
    2. Split the boundary across three moments: before the task (environment config decides network, variables, dependencies), during (container isolation), after (a human reviews the diff before any PR).
    3. Conclude that the cloud boundary is two gates, environment config plus pre-PR human review, with nobody in between; hence no production secrets, network off by default, merge rights stay human.
    4. Add the engineering angle: draw boundaries between parallel tasks too; tasks that touch the same files should not run concurrently.
    5. Expect the follow-up: can it auto-merge? Only in low-risk repos for fully green PRs, with rollback in place, and treat enabling auto-merge as a change that itself needs approval.

    答题要点

    • 云端没有逐步审批，边界变成事前的环境配置与事后的人工审阅两道门
    • 环境里不放生产密钥、公网默认关、合并权限保留给人
    • 并行任务之间也要画边界：会改同一批文件的任务不同时派
    • 自动合并只适用于低风险仓库且全绿的 PR，并保留回滚

    Key points

    • No step-wise approval in the cloud; the boundary becomes upfront environment config plus post-hoc human review
    • Keep production secrets out, network off by default, merge rights with humans
    • Draw boundaries between parallel tasks: never run file-overlapping tasks concurrently
    • Auto-merge only for low-risk repos with fully green PRs, with rollback ready
  • 让同一个模型既写代码又审代码，审查还有意义吗？怎么让审查更独立？If the same model both writes and reviews code, is the review still meaningful? How do you make it more independent?
    国内高频海外高频进阶#code-review#coding-agent#workflow

    分析过程 · 先想清楚再作答

    1. 题眼在「还有意义吗」——直接答「没意义」或「有意义」都不及格，要说清它能抓什么、抓不到什么。
    2. 先说能抓的：审查时输入变了（看 diff 而不是需求）、立场变了（找问题而不是完成任务），这种角色切换能抓出漏掉的边界情况、没同步的调用方、明显的风格违规。
    3. 再说抓不到的：审查者和生成者共享同一份对需求的理解，需求理解错了两边一起错；也共享同样的盲区与偏好。
    4. 结论给三条提高独立性的手段：换一家模型审、给审查者不同的信息（需求原文加验收标准而不是只给 diff）、用确定性工具（测试、lint、类型检查）做第一道审查。
    5. 可预期的追问：审查意见要不要自动应用？不要，审查是输入不是判决，误报与漏报都存在，最终判断留给人。

    How to reason about it · think before answering

    1. The crux is 'still meaningful'; a flat yes or no fails. Explain what it catches and what it misses.
    2. What it catches: the input changes (diff instead of requirements) and the stance changes (find faults instead of finish the job), which surfaces missed edge cases, unsynced callers and style violations.
    3. What it misses: reviewer and author share one understanding of the requirement, so a misread requirement passes; they share blind spots too.
    4. Conclude with three independence levers: review with a different vendor's model, feed the reviewer different information (original requirement plus acceptance criteria, not just the diff), and run deterministic checks first.
    5. Expect the follow-up: auto-apply review comments? No; review is input, not verdict, and both false positives and misses exist.

    答题要点

    • 有意义：输入与立场的切换能抓出边界情况、未同步的调用方、风格违规
    • 抓不到与需求理解相关的错误，因为审查者与生成者共享同一份理解
    • 提高独立性：换一家模型审、给审查者需求原文与验收标准、先跑确定性检查
    • 审查意见是输入不是判决，不要自动应用

    Key points

    • Yes: the switch of input and stance catches edge cases, unsynced callers and style issues
    • It misses requirement misreads because author and reviewer share one understanding
    • Increase independence: a different vendor's model, richer reviewer context, deterministic checks first
    • Treat comments as input, never auto-apply
  • MCP server 和 skill 都是在给 coding agent 加能力，什么时候该用哪一个？项目说明文件又放什么？MCP servers and skills both extend a coding agent. When do you reach for each, and what goes in the project instruction file instead?
    国内高频海外高频基础#mcp#skills#coding-agent

    分析过程 · 先想清楚再作答

    1. 这题考的是抽象层次的区分，是国内面试开始高频出现的「Function Call / MCP / Skills 三者区别」的工具侧版本。
    2. 拆法是问「加的是什么」：加的是访问外部系统的能力（查工单、读数据库、调内部服务）就是 MCP，它是协议层的工具；加的是一套多步骤的做法（发版检查、迁移流程）就是 skill，它是提示词层的流程包；每次会话都要遵守的约定就是项目说明文件。
    3. 再给触发方式的差别：MCP 工具由模型在需要数据时调用；skill 由用户显式点名或由模型按描述匹配；说明文件每次会话开头无条件读入。
    4. 结论落到一句话：规矩归说明文件、外部系统归 MCP、流程归 skill；同一件事只放一处，避免三处互相矛盾。
    5. 可预期的追问：skill 里能不能调 MCP 工具？可以，skill 的步骤里可以要求使用某个工具，两者是正交的层次，不是替代关系。

    How to reason about it · think before answering

    1. This tests separation of abstraction levels, the tooling-side version of the increasingly common 'function calling vs MCP vs skills' question.
    2. Ask what is being added: access to an external system (tickets, databases, internal services) is MCP, a protocol-level tool; a multi-step procedure (release checklist, migration flow) is a skill, a prompt-level workflow package; conventions to obey every session belong in the instruction file.
    3. Contrast triggers: MCP tools are invoked by the model when it needs data; skills are invoked explicitly by name or matched by description; instruction files are loaded unconditionally at session start.
    4. Conclude: rules in the instruction file, external systems via MCP, procedures as skills; keep each fact in one place to avoid contradictions.
    5. Expect the follow-up: can a skill use MCP tools? Yes; a skill's steps can call for a tool, the layers are orthogonal, not substitutes.

    答题要点

    • MCP 加的是访问外部系统的工具，由模型按需调用
    • skill 加的是多步骤流程，由用户点名或按描述匹配触发
    • 项目说明文件放每次会话都要遵守的约定、禁区与环境事实
    • 三者正交：规矩、外部系统、流程各放一处，skill 里可以要求用某个 MCP 工具

    Key points

    • MCP adds tools that reach external systems, invoked by the model on demand
    • Skills add multi-step procedures, triggered by name or matched by description
    • The instruction file holds conventions, no-go areas and environment facts read every session
    • The three are orthogonal: rules, external systems, procedures each live in one place; a skill may call for an MCP tool

评论

登录后即可参与讨论

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