Codex高级用法实战教程：多维度权限与Skills应用全攻略
大家知道吗，Codex用得越久，反而越不想让它一上来就改代码。一开始的做法很直接：打开Codex，输入一句“帮我实现一下”，然后等它改代码。现在完全不同了，会先让它把计划说清楚，再调整权限。跑完一轮后，再看diff、页面和测试结果。原因也简单：这样不容易返工。
现在大家应该都不再怀疑Agent能力了，但存疑的是，Agent会不会能力太强，改动太大。你让它改一个按钮，它可能额外整理import、改公共组件，把一个小问题带成一次小重构。这样就造成额外的不必要的工作量。
这里讲一下最常用、也确实能减少返工的10个技巧。
计划
第一个技巧是/plan。这个命令基本会在两类场景里使用：跨文件修改，或者需求本身还不清晰。以前经常直接说“帮我改一下”，Codex很快就会开始修改。问题是，修改开始得越快，越容易跳过边界确认。因为它还没讲清楚三件事：准备改哪里，怎么验证，哪些地方不能碰。现在常用的提示词是：先不要改代码，请先读相关文件，给一个计划：要改哪些文件、哪些地方不碰、改完怎么验证、这件事最容易出问题的点在哪里。这一步会多花一点时间，但能减少后面的返工。你会很快发现它有没有理解错需求，有没有准备动一个不该动的模块，有没有把验证写成一句没有依据的“应该没问题”。
第二个技巧是/goal。这个适合长任务，比如迁移、重构、批量修复、整理一堆历史问题。但不会直接写“把这个项目优化一下”，这种goal太宽泛了，执行过程中容易偏离目标。它会一直推进，但你不知道它到底离完成标准还有多远。通常的做法是给它一个终点线：目标是把模块从旧接口迁移到新接口，完成标准是相关单测全部通过、页面原有行为不变、不改认证逻辑、收尾输出改动文件验证命令和失败尝试。没有验证方式的goal，很容易偏离目标。之前跑过很长的任务，跑到后面Codex的回复结构还正常，但方向已经偏了。后来养成一个习惯：goal跑一段，就让它停下来复盘一次计划。问它现在离终点还差什么、原来的边界有没有被突破、下一步准备干什么。这一步的作用很具体：定期对齐任务状态，防止长任务偏离原始目标。
权限
第三个技巧是/permissions。这个功能之前也踩过两个坑。一种是权限过窄，什么都问，Codex频繁中断。另一种是直接给full access，改动范围很快变大，事后diff很难审。现在通常的做法是按任务切权限。读代码、查资料、梳理方案，可以适当放宽一点。但是要写文件、装依赖、跑迁移、动配置，就需要收紧。如果是支付、权限、数据库迁移、安全配置，宁愿它多问几次。Codex现在的权限配置已经能细到文件系统、workspace root、网络域名，甚至能把.env这类文件直接deny掉。
第四个技巧是AGENTS.md。这个文件不要写空泛要求。不要写“请保持代码优雅”“请遵循最佳实践”，这种话约束很弱，也不方便后面检查。建议写这种：修改前端后要启动本地服务并打开目标页面、修改API行为后要跑对应测试、不主动重构未涉及模块。Review只报告真实风险，不报风格偏好。不读取、不修改.env，不改认证、支付、权限逻辑，除非任务明确要求。Codex会在开工前读AGENTS.md。全局可以放在~/.codex/AGENTS.md，项目里也可以放一个更具体的。更建议把它当成工作协议，不要当成偏好合集。
第五个技巧是hooks。有些规则不能只靠提示词。比如不要改.env，不要跑危险命令，改完某类文件自动跑lint。这些事情，靠prompt约束并不稳。该强制执行，就写hook。Codex的hooks可以插进agentic loop里，在工具调用前后、线程开始、子任务启动这些节点触发脚本。非托管hook还要review和trust之后才会跑，这个设计挺合理。现在的理解是：AGENTS.md负责写规则，hooks负责在关键节点做校验。一个是规则，一个是校验。前者告诉Codex怎么做，后者检查它有没有越过边界。
审查
第六个技巧是/diff。这个命令不显眼，但用习惯之后，能明显降低review成本。如果你一直用xhigh，Codex的改动范围很容易变大。单个改动规模都不大，加起来review成本就上来了。所以通常在它第一轮改完后马上看/diff。用diff来看看它的改动和想要的是否一致。方向对，再继续。方向不对，就在这轮打住了。
第七个技巧是/review，再配合行内评论。Review不会做宽泛审查。一般会说：review当前diff，只看真实风险，包括bug、安全问题、回归风险、缺测试。不要报风格偏好，不要建议无关重构。这样出来的结果会更接近工程review，而不是只给出“这里可以更优雅”这种建议。Codex app的Review pane还有一个好用点：可以直接在具体代码行旁边留行注释。以前要重新描述：“你刚才改的那个函数，第三个if那里不对。”现在直接点到那一行，写一句：这里不要吞掉错误，调用方需要知道失败原因。然后告诉Codex：处理这些inline comments，保持范围最小。这比在聊天框里来回解释更准确。
前端
第八个技巧是in-app browser。现在对前端任务有一个固定要求：没有打开页面验证，就不要说完成。lint只能说明代码规则大体通过。测试也覆盖不到所有视觉状态，比如移动端换行、弹窗层级、表单校验、loading、empty和error。截图只能说明某个状态下页面正常，不能替代真实点击和多尺寸检查。Codex的in-app browser适合干这类事。你可以让它打开本地dev server，检查目标页面，点按钮，截图，甚至针对页面上的具体区域留评论。常用的提示词是：启动项目，打开http://localhost:3000/settings。只检查这个页面：桌面宽度、移动宽度、loading/empty/error三种状态。发现视觉问题先截图说明，再改代码。注意这里的关键不是“用浏览器”，关键是把验收对象说清楚。页面是哪一个，状态是哪几个，改动边界是什么。你不说清楚，它就会自己扩大范围。前端任务一旦扩大范围，页面风格和交互细节就容易被改偏。
拆分会话
第九个技巧是worktrees和subagents。把它们放一起讲，因为它们解决的是同一个问题：不要让一个会话承载太多上下文。单个Codex会话跑久了，context里会堆满探索记录、失败尝试、日志、临时判断。跑到后面，前面的失败尝试、临时判断和日志会影响后续判断。回复结构还完整，但上下文里已经混入了太多的临时判断。就像是一个缝合怪。
Subagent适合读多写少的活。比如让一个agent看安全风险，一个看测试缺口，一个看可维护性。它们各自在自己的上下文里翻材料，再把结论交回来。Worktree适合会改文件的并行活。比如一个worktree修UI，一个worktree查CI，一个worktree做迁移方案。互相不踩文件，也不污染主工作区。但subagent和worktree都不能滥用。很多任务根本不需要多agent。任务没拆清楚就拉subagent，会增加成本、拉长耗时，也会提高合并复杂度。判断标准是：任务能独立拆开，并且会产生大量日志和探索记录，用subagent。任务会改文件，而且几条线可能互相影响，用worktree。只是改一个函数，就不要拆多agent。
重复动作
第十个技巧是Skills + MCP。这两个功能不属于同一层，但实际使用时经常连在一起。Skills解决“重复流程”，MCP解决“外部上下文”。同一段指令反复复制，就适合做成skill。写公众号文章有写作流程，code review有审查流程，前端验收有浏览器检查流程。每次都重新贴一遍，既浪费上下文，也容易贴漏。Codex的skill是按需加载的，它一开始只知道skill的名字、描述和路径，实际用到的时候再读完整SKILL.md。所以不要把所有习惯塞进一个很大的“我的工作流”，要细分一点，一个skill负责一件事。通常这样分：wechat-article只负责公众号文章写作流程，frontend-verify只负责启动页面截图检查移动端，pr-review只负责看diff和风险。
MCP则是减少手动复制粘贴。Issue、Figma、浏览器、内部文档、开发者文档，如果有MCP，就让它靠近原始材料。复制粘贴最大的问题是材料会变形。你复制一段issue，可能漏了评论；复制一段日志，可能漏了时间；复制一张设计稿截图，可能漏了状态。MCP解决的是材料来源问题。它让Codex直接读issue、设计稿、内部文档和开发者文档，而不是靠你手动复制一段不完整的上下文。但工具越多，权限边界越要清楚。能读Figma，不代表它应该自动改设计系统。能看GitHub，不代表它应该随便推commit。能查外部网页，不代表网页里的话都可信。所以常见的组合是：MCP负责拿材料，skill负责告诉它怎么处理材料，permissions和hooks负责守边界。当你把这套组合跑清楚跑明白之后，你的工作流会稳很多。
收尾
这10个技巧背后，其实是一件事。不要把Codex只当成一个Agent，而是要把Agent当成你的脑机接口来用。今天是/plan、/goal、/diff、/review、Skills、MCP、hooks、worktrees、subagents、browser。明天肯定还会多几个入口。因为工具随时会变，但流程要保证稳定。先定义问题，再给上下文，再设权限，然后执行，认真验证。Codex适合执行，但前提是你把标准写清楚。验收标准不清楚，它就只能按自己的理解做。改动边界不清楚，它就容易扩大范围。你知道什么叫完成，它才有机会把事做完。
本文的使用判断来自最近一段时间对Codex的实际使用。功能描述主要对照OpenAI Codex官方文档：Codex CLI、Slash commands in Codex CLI、Codex app commands、Custom instructions with AGENTS.md、Permissions、Review、In-app browser、Worktrees、Agent Skills、Subagents、Hooks、Model Context Protocol、Workflows、Codex Use Cases。