别只会让 Codex 写文案：真正好用的是这些操作
很多人第一次用 Codex，方式都差不多：
打开，输入一句“帮我改这个 bug”，然后等它输出代码。
这当然能用。但如果你只这样用 Codex，其实只用到了很浅的一层。
真正拉开差距的，不是你会不会写更复杂的提示词，而是你有没有把 Codex 当成一个“可配置的工作系统”：让它记住项目规则、复用你的工作流程、接入外部工具、自动 review、定时巡检，甚至把复杂任务拆给多个 agent 并行处理。
这篇不讲基础入门，讲一些大多数人还没认真用起来的 Codex 操作。
Codex 的真正门槛，不是会不会写提示词，而是你有没有把自己的工作方式沉淀给它。---
1. 用 AGENTS.md 给 Codex 写一份“项目说明书”
很多人每次都在重复告诉 Codex：
这个项目怎么启动、测试怎么跑、代码风格是什么、哪些目录不要乱动、PR 描述怎么写。
其实这些内容不该每次重复说，而应该写进 AGENTS.md。
你可以把它理解成“给 AI agent 看的 README”。它不是写给人类新人看的长文档，而是告诉 Codex：在这个仓库里工作时，你应该遵守什么规则。
比如：
# AGENTS.md
- 修改代码前先阅读相关测试。
- 前端改动后运行 npm test。
- 不要修改 generated/ 目录。
- PR 描述需要包含变更摘要和验证方式。
这件事的价值非常大。
因为 Codex 最容易犯错的地方，往往不是“不会写代码”，而是“不知道这个项目的隐性约定”。你把约定写下来，它就少猜一点。
但这里有个反直觉点：
AGENTS.md 不是越长越好。
如果你把它写成一本百科全书，把所有边缘规则、历史包袱、个人偏好都塞进去，Codex 反而会被噪音干扰。
更好的写法是：
- 写最常用的命令；
- 写最容易踩坑的约束；
- 写必须遵守的代码风格；
- 写验证方式；
- 写那些你已经提醒过 Codex 三次以上的问题。
不要把 AGENTS.md 当说明书仓库，要把它当项目里的操作护栏。---
2. 把重复提示词做成 Skills
如果说 AGENTS.md 是项目说明书，那 Skills 就是“可复用工作流”。
很多人会反复对 Codex 说：
“按我的格式写发布说明。”
“帮我做一次安全 review。”
“把这篇文章改成公众号风格。”
“按我们团队规范生成 PR 描述。”
这些其实都适合沉淀成 Skill。
Skill 的好处是：它不只是保存一句提示词，而是可以包含说明文件、参考材料、脚本、模板。下次遇到类似任务，Codex 可以按这套流程执行。
举几个适合做成 Skill 的场景：
- release note 生成；
- 安全审查；
- 前端视觉 QA；
- 技术文档整理；
- 长文润色；
- 固定格式的周报/日报；
- PR 描述和 changelog 生成。
提示词是一次性沟通，Skill 是把沟通产品化。如果你发现自己已经第三次对 Codex 说同一套要求，就该考虑把它做成 Skill。
这也是很多人用 Codex 的分水岭。
普通用法是每次临场描述。
高级用法是把自己反复做的事变成一个可调用的工作流。
3. MCP：让 Codex 接入外部工具
MCP 是很多人听过但没真正用起来的东西。简单说，它是 Codex 连接外部世界的接口。
没有 MCP 时，Codex 主要依赖当前项目文件、你输入的上下文，以及它能调用的本地工具。
有了 MCP，它就可以接入 GitHub、Linear、Figma、数据库、内部文档、浏览器、知识库等外部系统。
你可以这样理解三者区别：
- AGENTS.md 解决：这个项目里应该怎么做？
- Skills 解决：这个重复流程应该怎么做？
- MCP 解决：需要外部信息和外部动作怎么办？
比如你想让 Codex 查 GitHub issue、读 Linear 任务、看设计稿、查公司内部文档，MCP 就会变得很关键。
它不是噱头，而是把 Codex 从“代码助手”变成“工作台”的关键接口。
尤其是在团队环境里，MCP 的价值会更明显。
因为真实工作不是只发生在代码仓库里。需求在 Linear，讨论在 Slack，设计在 Figma，文档在 Notion，CI 在 GitHub，数据在数据库。
如果 Codex 只能读代码，它只能处理一部分问题。
如果 Codex 能接入这些系统，它就开始接近一个真正的工作流 agent。
4. Slash Commands：长任务里的救命按钮
Codex 里有一批斜杠命令，很多人几乎没用过。
但它们在长任务里非常有用。
几个最值得记住的：
- /compact：压缩长会话上下文，任务跑久了很有用。
- /diff：查看 Codex 到底改了什么。
- /review：只做代码审查，不直接修改文件。
- /mention：明确把某个文件带进上下文。
- /status：查看当前状态。
- /permissions：调整权限。
- /new：开启新会话。
- /init：生成项目说明文件。
尤其是 /compact 和 /review。
很多长任务不是死在能力上，而是死在上下文越来越乱。
会用 /compact，相当于给 Codex 做中场整理。
会用 /review，相当于先让它当审稿人，再让它当执行者。
这也是我非常建议新手养成的习惯：
不要一上来就让 Codex 大改。
先让它读，先让它 review，先让它讲风险。
等你确认方向之后，再让它动手。
5. 让 Codex 看图，不只是读代码
Codex 现在不只是读文字和代码，它也可以处理图片输入。
这对前端尤其有用。
你可以把截图、设计稿、报错弹窗、移动端页面发给它，然后让它判断：
- 页面哪里溢出了？
- 哪个组件和设计稿不一致？
- 这个报错截图可能是什么原因？
- 移动端为什么按钮被遮住？
- 这张 UI 截图应该怎么还原？
这会改变前端协作方式。
以前你要描述：“右上角按钮在 390px 宽度下被挤到第二行，而且和标题重叠。”
现在可以直接丢图：
“照这个问题修。”
这不是小功能。
因为很多 UI 问题，用文字描述会变形。你说的“偏一点”“挤一点”“不对齐”，对 Codex 来说都很模糊。
但截图会把问题固定下来。
前端问题最怕凭空猜。让 Codex 看到画面，它就少了一半误判。---
6. 用 In-app Browser 让 Codex 边看页面边改
如果你做前端，只让 Codex 读代码是不够的。
真正好用的是：让它打开页面、观察页面、截图、修改，再验证。
Codex App 的 In-app Browser 就是为这个场景准备的。
它可以在任务过程中打开浏览器预览页面，观察 UI 状态，发现布局问题，再继续改代码。
这样 Codex 不再只是“根据代码猜页面长什么样”，而是可以真的看见结果。
这类能力特别适合：
- 修复移动端适配；
- 对齐设计稿；
- 检查按钮、弹窗、表单状态；
- 调整视觉细节；
- 修复页面重叠、溢出、空白；
- 给前端页面做视觉回归检查。
前端问题最怕盲改。让 Codex 看见页面，很多问题会简单一半。很多人用 AI 写前端，最大的问题不是写不出来，而是写出来之后没人认真看。
有了浏览器能力，Codex 可以进入“看见问题、修改代码、再次验证”的循环。
这比单纯生成一段组件代码有用得多。
7. 先让 Codex Review，再让它动手
很多人一上来就说：
“帮我重构这个模块。”
这其实很危险。
更稳的流程是：
- 先让 Codex review。
- 让它列出风险、坏味道、可能的回归点。
- 你确认方向。
- 再让它修改。
也就是先让它当审稿人，再让它当工程师。
这个习惯能显著降低“改太多”“改偏了”“把隐藏逻辑删掉”的风险。
在 GitHub 场景里，还可以通过 @codex review 让 Codex 对 PR 做代码审查。你也可以指定它重点关注安全风险、过期依赖、测试缺口、性能问题。
我非常建议把这个当成默认工作流：
先 review，再实现。
先找风险，再写代码。
先确认范围，再放手执行。
让 Codex 少犯错的办法，不是让它更自信，而是让它先进入审查模式。---
8. Automations：让 Codex 定时回来工作
这是很多人完全不知道的能力。
Codex 不一定只能在你打开它时工作。它可以做 Automations，也就是定时任务。
比如：
- 每天早上生成项目简报；
- 每周扫描最近提交里的潜在 bug；
- 每隔一段时间检查部署状态；
- 定期 review 依赖升级风险；
- 定时回来看某个长期任务有没有变化；
- 每天汇总未合并 PR 和失败 CI。
这会把 Codex 从“即时问答工具”变成“后台巡检助手”。
你不一定每天都记得查项目状态，但可以让 Codex 每天回来帮你看一眼。
这个能力的想象空间很大。
因为很多工程问题不是一次性任务，而是持续性问题：
- 有没有新失败的测试？
- 有没有长时间没合并的 PR？
- 最近依赖有没有安全风险？
- 某个线上问题有没有复现？
- 项目里哪些 TODO 已经拖太久？
以前这些事靠人记。
现在可以让 Codex 定期提醒。
9. Subagents：复杂任务不要只交给一个 Codex
有些任务天然很复杂。
比如你要重构一个支付模块，它可能涉及：
- 业务调用链；
- 测试覆盖；
- 数据库变更；
- 安全边界；
- 前端展示；
- 历史兼容逻辑。
这时候只让一个 Codex 从头查到尾，很容易上下文爆炸。
更好的方式是用 Subagents。
你可以让不同 agent 做不同的事：
- 一个查调用链；
- 一个查测试；
- 一个查安全风险；
- 一个查历史实现；
- 主 agent 汇总结论并制定方案。
这有点像临时组了一个小型工程团队。
当然，Subagents 不适合所有任务。小改动没必要开多 agent。但复杂项目、跨模块重构、排查疑难 bug 时，它会很有用。
复杂任务不要只问“让 Codex 怎么做”，还要问“这件事该不该拆给多个 Codex 做”。这也是 agent 工作流真正有意思的地方。
它不是把一个人变得更强，而是让一个人能临时调度一组小型执行者。
10. 权限、Sandbox、Hooks：给 Codex 装护栏
高阶使用 Codex，不是给它无限权限。
恰恰相反，是知道什么时候该给权限，什么时候该限制权限。
Codex 有权限和沙盒机制，你可以控制它能不能访问网络、能不能改文件、哪些命令需要审批。
更进一步，还可以通过 Hooks 在关键节点做检查，比如在执行命令前拦截高风险操作，在提交前强制跑测试。
这类配置一开始看起来“麻烦”，但它决定了你能不能放心把更大的任务交给 Codex。
一个成熟的 Codex 工作流，应该有三层边界：
- 哪些事它可以直接做；
- 哪些事它必须先问你；
- 哪些事它永远不能做。
比如：
- 读文件可以放开；
- 改工作区代码可以允许；
- 删除文件、重置 Git、访问外部网络要谨慎；
- 生产环境操作必须拦住；
- 涉及密钥、数据库、支付、用户隐私的操作要单独设规则。
真正成熟的用法，不是让 Codex 什么都能做，而是让它在正确边界里做更多事。---
11. IDE 插件：不要把 Codex 只关在终端里
还有一个容易被忽略的点：Codex 不只有 CLI。
它可以在 App 里用，可以在命令行里用，也可以在 IDE 里用。
IDE 插件的好处是，它离你的编辑现场更近。
当你正在看某个文件、某个函数、某段报错时，直接在编辑器里叫 Codex，比切到另一个窗口重新描述上下文更自然。
适合 IDE 场景的任务：
- 解释当前函数；
- 给当前文件补测试；
- 对当前 diff 做 review；
- 重构选中代码；
- 根据报错定位附近逻辑；
- 在不离开编辑器的情况下推进小任务。
而 App 更适合长任务、规划、跨文件工作、浏览器验证和持续跟踪。
CLI 更适合本地工程流、脚本、权限明确的执行任务。
所以不要问“哪个 Codex 入口最好”。
更好的问题是：
这件事发生在哪个现场？
在编辑器里，就用 IDE。
在本地仓库里，就用 CLI。
要跨页面、跨任务、长期跟踪，就用 App。
最后：Codex 的门槛不是提示词，而是沉淀
如果只把 Codex 当成聊天框，你会越来越依赖“临场描述”。
每次都要重新解释项目、重新说明规则、重新贴上下文、重新强调不要乱改。
但如果你把它当成工作系统，思路就变了：
- 项目规则写进 AGENTS.md；
- 重复流程做成 Skills；
- 外部工具接进 MCP；
- 长任务用 slash commands 管理；
- 前端问题让它看图、看浏览器；
- 大改动先 review，再执行；
- 周期性任务交给 Automations；
- 复杂任务拆给 Subagents；
- 高风险操作用权限、Sandbox、Hooks 管住；
- 不同任务放到 CLI、IDE、App 的不同现场里处理。
这时候 Codex 不再只是一个“更会写代码的聊天框”。
它更像一个可以被训练、被配置、被调度的开发工作台。
同样是 Codex，有的人只把它用成“更聪明的自动补全”。
有的人却已经把它用成了一个可协作、可复用、可长期运行的工程系统。
差距不在模型，而在工作流。
Codex 的真正门槛，不是会不会写提示词，而是你有没有把自己的工作方式沉淀给它。
