一文搭好你的 Codex 工作流系统

摘要：上一篇我们讲了 Codex 第一天怎么安全上手：给材料、划边界、让它先观察，再产出可审查的初稿。这篇继续往下走：当你已经跑通第一个任务后，如何用入口选择、任务设计、Plan 模式、AGENTS.md、权限验证、MCP（模型上下文协议）、Skills（可复用工作流说明）和 Automations（定时自动化任务），把 Codex 变成一套稳定、可复用、可扩展的工作流系统。

在上一篇《Codex 上手第一天：5 步把 AI 从聊天框搬进工作流》里，我们讲的是如何把 AI 从聊天框搬进一个受控工作区：先给材料和边界，再让它观察、产出初稿、接受人工审查。

第一次跑通任务，只说明 Codex 能用。第二次、第三次继续用时，麻烦会慢慢冒出来：

每次都要重新解释项目规则。
大任务一上来就改偏，回头很难收拾。
结果看起来完成了，但不知道怎么验证。
好用的 prompt 和流程没有沉淀，下次还得重来。

这篇不再重复「Codex 和 ChatGPT 有什么不同」，也不再展开会议准备、项目复盘、KPI 分析这些普通白领场景。我们只处理一个问题：如何从会用 Codex，走到用稳 Codex。

我会结合 CodexGuide 这个中文开源实战指南，以及 OpenAI 官方文档，把 Codex 的核心能力压缩成一套进阶路线：

入口选择 → 任务设计 → Plan 模式 → AGENTS.md → 权限与验证 → MCP / Skills / Automations → 案例迁移 → 7 天进阶路线。

一、先选入口：不要把所有任务都塞进同一个界面

许多人用 Codex 的第一个混乱点，是入口太多。

Desktop App、CLI、IDE 插件、Cloud、手机端、浏览器插件、MCP、Skills、Automations……名字一多，初学者就容易陷入一种错觉：要把所有入口学完，才算真正入门。

不用。

Codex 的入口对应不同任务节奏。先判断任务适合放在哪个工作台里完成。

可以先用这张表判断：

入口	适合什么任务	你什么时候该用
Desktop App	项目、多任务、Skills、Automations、浏览器/插件	你想把 Codex 当成一个长期工作台
CLI	本地仓库、命令执行、测试验证、diff 审查、精细审批	你需要贴着工程环境推进任务
IDE	当前文件、局部修改、代码解释、审查	你正在编辑代码，希望 Codex 贴着上下文工作
Cloud / Web	长任务、PR、后台执行、团队协作	你希望任务在后台跑，最后给出分支、diff（变更对比）或 PR
手机端	查看进展、补充上下文、审批	你离开电脑，但还想继续跟进任务

记一个口诀就够了：

管仓库用 CLI，管项目用 App，写代码用 IDE，跑长任务用 Cloud，离开电脑用手机端跟进。

需要反复跑测试、看报错、改文件的任务，放进 CLI 里一般更顺；需要浏览器、技能、自动化串起来的任务，放在 Desktop App 里更自然；只涉及当前文件的小改动，放在 IDE 里最省心。

不要一上来追全家桶。先找到你最高频任务对应的入口。

二、任务设计：把需求写成 Codex 能执行的工作单

上一篇我们讲过，第一次用 Codex，最好先让它观察，不要直接动手。

进阶之后，这个原则要升级成一张完整的「任务单」。

一个稳定的 Codex 任务，至少要包含六个要素：

要素	你要写清什么
目标	最终要完成什么
背景	为什么要做，当前问题是什么
范围	可以读写哪些文件、目录、材料
约束	哪些事情不能做
验证	怎么证明做对了
交付	最后按什么格式汇报

可以直接复制这个模板：

请处理：[明确目标]

背景：
- [当前现象/业务上下文]

范围：
- 可以修改：[文件/目录]
- 保持不变：[文件/目录/行为]

约束：
- 不引入新依赖
- 不读取 .env、密钥或 token
- 不执行部署、迁移、删除数据命令

验证：
- 运行：[命令]
- 如果失败，请说明缘由和阻塞点

交付：
- 根因
- 改动
- 验证结果
- 剩余风险

这段模板看起来比普通 prompt 啰嗦，但它解决的是同一个问题：

与其追求神奇措辞，不如先把 prompt 写成一张任务单。

你要做的是把一个原本模糊的工作，拆成它能执行、能验证、能交付的结构。

先看一个对比。

模糊写法：

帮我优化这个项目。

更稳的写法：

请先阅读当前项目，不要修改文件。

请输出：
1. 项目类型和核心目录
2. 安装、开发、测试、构建命令
3. 新手最适合做的 3 个低风险任务
4. 哪些文件、命令或数据需要谨慎处理

不确定的内容请标注“待确认”。

真正影响结果的，往往是你有没有把「边界」和「完成标准」讲清楚。

三、Plan 模式：复杂任务先规划，别让它直接动手

如果任务很小，列如改一段文案、整理一份 Markdown、修一个明确的测试失败，可以直接让 Codex 做。

但只要遇到下面几种情况，就提议先进入 Plan 思路：

跨多个文件或模块。
涉及架构、权限、数据、认证、支付。
修改后不容易验证。
你自己还没完全想清楚方案。
一旦改偏，回滚成本很高。

这时，不要上来就说「帮我实现」。先让 Codex 规划。

可复制模板：

请先不要修改文件。请先给出计划：

1. 你会检查哪些文件
2. 你预计修改哪些文件，为什么
3. 你会如何分步骤实施
4. 最高风险点是什么
5. 如何验证结果

等我确认后再执行。

如果任务更复杂，可以再加一条：

如果你需要推测，请明确标注“推测”。
如果代码、文档和测试之间有冲突，请先停下来说明冲突，不要自行选择一个方向继续改。

上一篇的原则是「先观察」。

这篇升级为：

先规划，再执行。

这听起来慢了一步，但实际会省许多返工。Codex 最容易出问题的地方，是一开始理解错方向，随后又很勤奋地把错误方向实现完整。

Plan 的价值，就是在它投入行动之前，先把误解暴露出来。

在团队项目里，这一步更像一次微型技术方案评审：先看它准备读哪些文件、改哪些地方、怎么验证，再决定是否放行。

四、AGENTS.md：让 Codex 记住项目规则

如果你每次打开 Codex，都要重新告知它：

这个项目用什么包管理器。
测试命令是什么。
哪些目录不能改。
代码风格是什么。
PR 描述要写什么。
什么操作必须先问人。

那你很快会烦。

AGENTS.md 就是为了解决这个问题。

你可以把它理解成：

给 Codex 看的项目入职手册。

README 更像写给用户看的说明，AGENTS.md 负责给 AI Agent 提供工作规则。OpenAI 官方提供了 AGENTS.md 相关说明，CodexGuide 里则给了更适合中文用户的模板和使用场景。

最小版本可以这样写：

# AGENTS.md

## 项目命令
- 安装依赖：
- 本地开发：
- 测试：
- 构建：

## 改动规则
- 修改前先阅读相关文件。
- 保持现有代码风格。
- 不做无关重构。
- 新增功能需要补充或更新测试。

## 安全边界
- 不读取 .env、密钥、token。
- 不执行部署、迁移、删除数据命令。
- 高风险操作先说明影响，等待确认。

## 交付要求
- 说明改了什么。
- 说明如何验证。
- 说明剩余风险。

如果是团队项目，再补目录边界、测试要求和 PR 规则；如果是文档或知识工作流，就把「实际、推断、缺口」写进输出规则。AGENTS.md 的重点在于把每次反复解释、反复纠正的内容固定下来。

五、权限与验证：让 AI 干活，但别让它失控

Codex 和普通聊天框最大的区别，是它能碰真实环境。

它可以读文件、改文件、跑命令、连接工具、生成产物。能力越强，越不能只靠「我信任它」。

你至少要盯住五类风险：

风险	你要问的问题
文件	它能读写哪些目录？会不会碰到不该碰的文件？
命令	它能否安装依赖、跑脚本、迁移数据库？
网络	它能否访问外部服务、下载内容、调用 API？
凭据	它是否可能读取 token、cookie、密钥、证书？
数据	它是否会影响生产资源、客户数据、账单或权限？

可以把这段安全提示词常备在手边：

涉及删除文件、安装依赖、访问网络、读取敏感文件、推送代码、部署或数据库迁移时，请先说明理由、命令和影响范围，等我确认后再执行。

权限之外，还要有验证。

许多人用 AI Agent 时最危险的习惯是：看它说「完成了」，就真的以为完成了。

不要只看总结，要看证据。

一套基本验证闭环可以这样设计：

验证项	解决什么问题
diff	它到底改了什么
测试	行为是否符合预期
lint / typecheck（代码风格和类型检查）	是否过关
构建	项目是否还能正常打包
截图 / 预览	UI、文档、图表是否真的可用
风险说明	哪些地方没验证、仍需人工判断

如果是非开发任务，也可以换成：

重大结论是否能追溯到材料。
实际和推断是否分开。
数据口径是否说明清楚。
输出格式是否能直接进入下一步工作。
哪些内容需要负责人确认。

这就是上一篇里「人工审查」的进阶版。

不要只看一眼结果顺不顺，要建立一套可重复的检查动作。

AI Agent 时代，信任要靠一次次可检查的交付建立。

六、从一次任务到工作流：MCP、Skills、Automations

当你已经能稳定完成单次任务，下一步就会自然遇到三个问题：

Codex 需要看工作区之外的信息怎么办？
同一套 prompt 总是反复复制怎么办？
有些任务每周、每天都要做怎么办？

这就对应 Codex 生态里三个重大致念：MCP、Skills、Automations。

能力	解决的问题	典型例子
MCP	Codex 能接触什么	GitHub、浏览器、Notion、Figma、飞书、内部文档
Skills	这件事该怎么做	PR 审查、发布检查、文档生成、案例收集
Automations	什么时候自动做	每周检查死链、每天汇总 CI、定期生成报告

可以这样理解：

MCP 是外接工具，Skill 是工作说明书，Automation 是定时器。

不要一上来就全部接满。

更稳的路线是：

第一次：手写 prompt，把流程跑通。
第三次重复：沉淀成 Skill。
流程稳定、风险可控：再思考 Automation。

列如你每周都要检查一个文档站，第一次可以手写 prompt，把链接、构建结果、格式问题和验证命令说清楚。如果你连续三周都在做同样的事，就可以把它写成一个 Skill。不用一开始就写得很复杂，先把四件事固定下来：

触发场景：什么时候使用。
工作步骤：先读什么，再检查什么，最后怎么验证。
输出格式：问题、文件、提议修复、验证方式。
安全边界：哪些操作必须先确认。

等这个 Skill 稳定后，再思考让 Automation 每周跑一次。

这就是从 prompt 到工作流的过程。许多人一开始就想「全自动」，结果自动化的只是混乱。更好的顺序是：

先跑通，再固化，最后自动化。

七、案例库怎么读：从 CodexGuide 学迁移，别照抄

CodexGuide 是一个面向中文用户的 Codex 开源指南，内容覆盖 App、CLI、IDE、Cloud、配置、安全、任务设计和团队实践。它最适合当作系统学习地图：你可以先看入口和基础设置，再顺着案例库找和自己工作接近的场景。

其中最值得看的部分之一，是实战案例库。

但案例库不要当成「照着做一遍」的教程清单来看。更好的读法是：

看每个案例背后对应的是哪类工作流。

可以分成四类：

案例类型	CodexGuide 中的代表	你该问自己的问题
内容表达	PPT、、HyperFrames	我有没有重复生成文档、图表、PPT 的工作？
知识管理	Obsidian、LLM Wiki、Notion	我有没有资料整理、知识库维护任务？
浏览器与设计协作	Playwright、Chrome、Figma	我有没有网页检查、浏览器操作、设计稿还原流程？
工程自动化	GitHub Actions、远程修 Bug、DKFile	我有没有 CI、排障、发布前检查这类重复工程任务？

列如 MCP 的重点，不在「AI 会画架构图」这个噱头，而在这个问题：

你能不能把一段系统描述，转成可编辑、可复审、可迭代的结构图？

Obsidian 案例更值得看的是：

你能不能让 AI 在本地知识库中读取材料、生成内容、保留引用和上下文？

所以，读案例时不要只问「我能不能复刻」。

更应该问：

这个案例背后的输入是什么？
Codex 做了哪些关键动作？
输出如何验证？
风险在哪里？
我自己的工作里，有没有类似结构？

案例的价值在于帮你识别哪些工作可以 Agent 化。

一旦你能这样读案例，就不会被工具名牵着走。无论是 PPT、Obsidian、Figma、Notion，还是 GitHub Actions，本质都是同一个问题：

把散落的输入，变成可审查、可交付、可复用的输出。

八、7 天进阶路线：从能用到用好

如果你想把这篇文章落成行动，可以按 7 天走。

天数	目标	动作
Day 1	跑通安全小任务	新建干净目录，只放非敏感材料，让 Codex 先观察再提议任务
Day 2	只读分析真实项目	让 Codex 输出结构、命令、风险区域和低风险任务
Day 3	练 Plan 模式	选一个中等复杂任务，先审查计划，再决定是否执行
Day 4	写 AGENTS.md	固定项目命令、改动规则、安全边界和交付要求
Day 5	补验证闭环	为高频任务写清测试、构建、截图、口径或人工审查方式
Day 6	复刻一个案例	从 CodexGuide 选一个接近自己工作的案例，记录输入、过程、验证
Day 7	沉淀模板或 Skill	把重复任务整理成触发场景、输入材料、工作步骤、输出格式和安全边界