Codex 高阶用法：AGENTS.md、Skills、MCP 与自动化

原文作者：Mocha · 原文来源：今日头条

本文为作者本人文章的站内同步版本。

不少人初次接触 Codex 时，用法都大同小异：打开工具，敲一句 “帮我修复这个 bug”，便等着代码输出。

这样的用法自然能用，但只触碰到了 Codex 能力的表层。真正拉开使用效率差距的，从来不是写提示词的技巧有多花哨，而是你是否将 Codex 视作一套可定制的工作系统 —— 让它熟记项目规则、复用标准化流程、对接外部工具、自动完成代码评审，甚至定时执行巡检任务，将复杂任务拆解给多个智能体并行处理。

本文不聊基础入门操作，只谈多数人尚未真正落地的 Codex 高阶用法。说到底，用好 Codex 的核心门槛，从来不是提示词功底，而是你能否把自身的工作方法论沉淀进这套系统里。

先用一次小改动验证工作流

选择仓库中的一个可复现问题，交代现象、修改范围和验收命令。让 Codex 先读取项目说明，再修改、验证并报告尚未通过的检查。下面是可按仓库实际情况改写的任务模板：

请复现这个问题：[现象与复现步骤]。
先读取适用的 AGENTS.md 和相关实现，只修改 [范围]。
使用项目已有的 [验收命令] 验证；说明改动文件、检查结果和未解决的问题。
涉及部署或外部写入时，遵循本次会话已有授权与项目流程。

本文涉及的入口会随客户端、账号与版本变化。项目规则、技能和定时任务分别参考 AGENTS.md 官方说明、技能文档 和 定时任务说明。核对实际任务结果，不把任务创建等同于执行成功。

办公流程示例可继续阅读 WorkBuddy Skill 工作流，工程应用可看 Agent 开发实践。

1. 用 AGENTS.md 沉淀项目规则，免去重复沟通

很多人每次和 Codex 协作，都要反复交代同一件事：项目怎么启动、测试如何执行、代码要遵循什么风格、哪些目录不能随意改动、PR 描述该按什么格式写。

这些重复性的说明，本不必每次复述 —— 你可以把它们整理进 AGENTS.md 文件。你可以把它理解为 “给 AI 智能体读的项目规范”，它不是写给新人看的长篇说明文档，而是 Codex 在当前仓库工作时的行动准则。你可以直接参考这样的写法：

AGENTS.md- 修改代码前先阅读相关测试。- 前端改动后运行 npm test。- 不要修改 generated/ 目录。- PR 描述需要包含变更摘要和验证方式。这件事的价值在于，Codex 最容易出错的地方，往往不是写不出代码，而是不了解项目里的隐性约定。把规则白纸黑字落下来，它就能少做很多无效猜测。

但这里有个反常识的要点：AGENTS.md 绝非越长越好。如果你把它堆成包罗万象的百科全书，塞满边缘规则、历史遗留问题和个人偏好，反而会变成噪音干扰判断。更高效的写法是只保留核心内容：

• 最常用的操作命令

• 最容易踩坑的约束

• 必须遵守的代码规范

• 标准的验证流程

• 那些你已经反复提醒过 Codex 三次以上的问题

别把 AGENTS.md 做成规则仓库，要让它成为项目操作的安全护栏。

2. 将重复流程沉淀为 Skills，把沟通变成可复用能力

如果说 AGENTS.md 定义了项目内的操作规则，那 Skills 就是可跨项目复用的标准化工作流。

很多人会反复对 Codex 下达同类指令：按固定格式生成发布说明、做一次安全代码审查、把文章改成公众号排版风格、依照团队规范生成 PR 描述…… 这类高度重复的任务，最适合沉淀成独立的 Skill。

Skill 的价值远不止保存一句提示词 —— 它可以配套说明文档、参考样例、执行脚本与输出模板。下次遇到同类任务，Codex 就能直接依照这套完整流程执行，不用你再从头描述要求。适合做成 Skill 的典型场景包括：

• 版本发布说明（release note）生成

• 代码安全审查

• 前端视觉 QA 检查

• 技术文档梳理归档

• 长文内容润色

• 固定格式的周报 / 日报输出

• PR 描述与变更日志（changelog）生成

单次提示词是一次性的沟通，Skill 是把这套沟通产品化了。当你发现自己已经第三次对 Codex 说同一套要求时，就该考虑把它做成 Skill 了。这也是普通用户和高阶用户的分水岭：前者每次临场描述需求，后者把反复做的事变成可一键调用的工作流。

3. 借助 MCP 对接外部系统，打破代码仓库的边界

MCP（Model Context Protocol）是很多人有所耳闻却从未真正用起来的能力。

简单来说，它是 Codex 连接外部世界的通用接口。没有 MCP 的时候，Codex 的信息来源局限于当前项目文件、你输入的上下文，以及内置的本地工具；接入 MCP 后，它就能对接 GitHub、Linear、Figma、数据库、内部文档、浏览器、企业知识库等各类外部系统。

我们可以这样区分三者的定位：

• AGENTS.md 回答 “在这个项目里该怎么做”

• Skills 回答 “这类重复流程该怎么做”

• MCP 解决 “需要外部信息和外部操作怎么办”

小到让 Codex 查询 GitHub issue、读取 Linear 任务、对照 Figma 设计稿、查阅公司内部文档，大到串联全链路工作流，MCP 都是核心的连接层。它不是华而不实的噱头，而是让 Codex 从「代码助手」升级为「开发工作台」的关键能力。

在团队协作场景中，它的价值会更加凸显 —— 真实的研发工作从来不止发生在代码仓库里：需求在 Linear、沟通在 Slack、设计在 Figma、文档在 Notion、构建在 GitHub、数据在数据库。如果 Codex 只能读取代码，就只能解决一部分问题；当它能接入这些系统，才真正接近一个完整的工作流智能体。

4. 善用斜杠命令，掌控长任务的节奏

Codex 内置了一系列斜杠命令，很多人几乎从未使用过，但它们在处理长周期任务时格外实用。

几个最值得常备的命令值得记住：

• /compact：压缩冗长的会话上下文，任务推进越久越能体现价值

• /diff：快速查看 Codex 对代码做了哪些具体改动

• /review：仅执行代码审查，不直接修改文件

• /mention：将指定文件明确纳入上下文

• /status：查看当前任务的执行状态

• /permissions：调整工具的操作权限

• /new：开启全新会话，避免上下文干扰

• /init：一键生成项目说明文件

其中尤其推荐用好/compact和/review。很多长任务最终效果不好，不是模型能力不足，而是会话上下文越积越杂，信息出现混乱。 会用/compact，相当于给 Codex 做一次中场信息整理；会用/review，相当于先让它扮演评审者，再让它担当执行者。

这也是非常建议新手养成的习惯：不要一上来就让 Codex 大刀阔斧地修改。先让它通读代码，先做审查，先列出潜在风险，等你确认方向无误后，再让它动手实现。

5. 让 Codex “看见” 画面，降低前端问题的沟通损耗

如今的 Codex 早已不止能处理文字与代码，图像输入能力同样成熟，这对前端开发来说尤其实用。

你可以把页面截图、设计稿、报错弹窗、移动端适配问题直接发给它，让它直观判断：

• 页面哪里出现了溢出

• 哪个组件和设计稿存在偏差

• 报错截图对应的可能原因

• 移动端按钮被遮挡的问题根源

• 这张 UI 截图该如何用代码还原

这会从根本上改变前端协作的效率。过去你需要费力描述 “右上角按钮在 390px 宽度下被挤到第二行，还和标题发生重叠”，现在你只需要丢一张图，说一句 “照着这个问题修复”。

这绝不是可有可无的小功能。很多 UI 问题用文字描述很容易出现偏差，你口中的 “偏一点”“挤一点”“没对齐”，对模型来说都是模糊的信息。而截图能把问题精准固定下来，让 Codex 少了一半的误判空间。

6. 用内置浏览器实现闭环，让前端修改不再盲改

做前端开发只让 Codex 读代码是远远不够的，更高效的方式是让它打开页面、观察渲染效果、截图比对、修改代码，再回头验证结果。

Codex App 的内置浏览器（In-app Browser）正是为这个场景设计的。它可以在任务执行过程中打开页面预览，实时观察 UI 渲染状态，发现布局问题后继续调整代码，不再只是 “根据代码推测页面长什么样”，而是能直观看到最终效果。

这项能力尤其适配这些场景：

• 修复移动端适配问题

• 对齐设计稿细节

• 检查按钮、弹窗、表单的交互状态

• 微调视觉样式细节

• 解决页面重叠、溢出、空白等布局问题

• 对前端页面做视觉回归检查

**前端修改最怕的就是「盲改」。**让 Codex 能真实看见页面效果，很多问题的难度都会直接减半。很多人用 AI 写前端，最大的问题不是写不出代码，而是生成后没人验证效果。有了浏览器能力，Codex 就能进入 **「发现问题 - 修改代码 - 验证结果」的完整循环 **，比单纯生成一段组件代码价值高得多。

7. 先审查再执行，给大改动装上安全阀

很多人习惯一上来就指令 “帮我重构这个模块”，这其实蕴藏着不小的风险。

更稳妥的流程应该是四步走：

• 先让 Codex 做代码审查

• 让它列出潜在风险、代码坏味道、可能的回归影响点

• 由你确认修改方向

• 再让它动手实现

简单来说，就是先让它当评审员，再让它当工程师。

这个习惯能大幅降低 “改动范围失控”“修改方向跑偏”“误删隐藏逻辑” 之类的问题。在 GitHub 协作场景中，你还可以通过@codex review指令让 Codex 对 PR 做专项审查，指定它重点关注这些方向：

• 安全风险

• 过期依赖

• 测试覆盖缺口

• 性能隐患

非常建议把这个流程设为默认操作规范：先审查，再实现；先找风险，再写代码；先确认范围，再放手执行。 让 Codex 少犯错的方法，从来不是让它更自信，而是先让它进入审慎的审查模式。

8. 开启 Automations 定时任务，让 Codex 后台自动巡检

很多人完全不知道，Codex 并非只能在你打开它的时候工作 —— 它支持 Automations 自动化定时任务。

你可以配置这些典型的定时场景：

• 每天早上生成项目进展简报

• 每周扫描近期提交中的潜在 bug

• 定时检查部署状态

• 定期评审依赖升级的风险

• 跟踪长期任务的变更情况

• 每日汇总未合并 PR 与失败的 CI 流水线

这项能力让 Codex 从「即时问答工具」变成了「后台巡检助手」。 你未必每天都记得逐一检查项目状态，但可以让 Codex 定时回来帮你过一遍。它的想象空间远不止于此。很多工程问题都不是一次性任务，而是需要持续关注的事项：

• 有没有新增的测试失败

• 有没有长期未合并的 PR

• 依赖有没有新的安全漏洞

• 某个线上问题是否复现

• 项目里哪些 TODO 已经搁置太久

过去这些事全靠人主动记挂，现在你可以交给 Codex 定期巡检并同步结果。

9. 复杂任务用 Subagents 拆解，组建临时工程团队

有些任务天然复杂度很高，比如重构一套支付模块，可能涉及多个维度：

• 业务调用链路

• 测试覆盖情况

• 数据库变更

• 安全边界

• 前端展示逻辑

• 历史兼容规则

这种时候只让单个 Codex 智能体从头到尾处理，很容易出现上下文过载、考虑不周的问题。更优的方案是启用 Subagents 子智能体能力。你可以给不同的子智能体分配不同的专项任务：

• 一个梳理业务调用链

• 一个核查测试覆盖情况

• 一个排查安全风险

• 一个调研历史实现逻辑

主智能体汇总结论并制定最终方案

这就像临时组建了一个小型专项工程团队。

当然，Subagents 并非所有任务都适用，小型代码改动完全没必要启用多智能体。但在处理跨模块重构、复杂项目改造、排查疑难杂症等场景时，它的价值会非常突出。

面对复杂任务，不要只纠结 “怎么让 Codex 做完这件事”，还要思考**「这件事该不该拆给多个 Codex 分头做」**。这也是智能体工作流真正的魅力所在：它不是让一个人变得更强，而是让一个人可以灵活调度一组专业的小型执行者。

10. 用好权限、沙盒与钩子，给操作划定安全边界

高阶使用 Codex，从来不是给它无限大的权限。 恰恰相反，成熟的用法是清楚什么时候放开权限、什么时候收紧约束。

Codex 内置了完善的权限与沙盒机制，你可以精准控制它能否访问网络、能否修改文件、哪些命令执行前需要人工审批。更进一步，你还可以通过 Hooks 钩子在关键节点做拦截校验 —— 比如执行高危命令前先拦截、提交代码前强制跑通测试。

这类配置一开始看起来有些繁琐，但它决定了你能不能放心把更复杂、更核心的任务交给 Codex。一套成熟的 Codex 工作流，应该划分三层操作边界：

• 哪些事它可以直接执行

• 哪些事它必须先征求你的同意

• 哪些事它绝对不能触碰

举个具体的划分参考：

• 读取文件可以完全放开

• 修改工作区代码可以允许

• 删除文件、重置 Git 状态、访问外部网络需要谨慎审批

• 生产环境操作必须严格拦截

• 涉及密钥、数据库、支付、用户隐私的操作要单独设置专项规则

真正成熟的使用方式，不是让 Codex 无所不能，而是让它在清晰的边界内高效做事。

11. 选对使用入口，让协作发生在正确的现场

还有一个容易被忽略的要点：Codex 不止有 CLI 命令行一种使用方式。它可以在独立 App 中使用，可以在命令行里操作，也可以通过 IDE 插件嵌入编辑器。

IDE 插件的优势在于，它离你的编码现场最近。当你正在查看某个文件、某个函数、某段报错信息时，直接在编辑器里唤起 Codex，比切换到另一个窗口重新描述上下文要自然高效得多。适合在 IDE 场景中完成的任务包括：

• 解释当前函数的逻辑

• 给当前文件补充测试用例

• 对当前代码 diff 做审查

• 重构选中的代码片段

• 根据报错定位附近的逻辑问题

• 不离开编辑器就能推进的小型任务

而独立 App 更适合处理长周期任务、方案规划、跨文件改造、浏览器验证和持续跟踪类工作；CLI 则更适配本地工程流、脚本执行、权限明确的自动化任务。

所以不要纠结 “哪个入口才是最好的”，更**好的问题是：这件事发生在哪个工作现场？**在编辑器里就用 IDE 插件，在本地仓库就用 CLI，需要跨页面、跨任务、长期跟踪就用独立 App。

写在最后：用好 Codex 的核心，是沉淀你的工作方法

如果只把 Codex 当成一个聊天窗口，你只会越来越依赖 “临场描述”—— 每次都要重新解释项目背景、重申规则、粘贴上下文、强调不能改动的范围。

但如果你把它视作一套工作系统，思路就会完全不同：把项目规则写进 AGENTS.md，把重复流程做成 Skills，把外部工具通过 MCP 接入，用斜杠命令管理长任务，前端问题让它看图、用浏览器验证，大改动先审查再执行，周期性任务交给 Automations，复杂任务拆给多个子智能体，高危操作用权限、沙盒、钩子管控，不同任务放到 CLI、IDE、App 对应的场景里处理。

到了这个阶段，Codex 就不再只是一个**「更会写代码的聊天框」，而是一套可训练、可配置、可调度的专属开发工作台**。

同样是使用 Codex，有人只把它用成了 “更聪明的代码补全工具”，有人却已经把它搭建成了可协作、可复用、可持续运行的工程系统。差距从来不在模型能力本身，而在工作流的设计与沉淀。 用好 Codex 的真正门槛，从来不是写提示词的技巧，而是你有没有把自己的工作方式，一步步沉淀进这套系统里。

原文链接：https://www.toutiao.com/article/7660951182130659874/