为什么有的人用 Codex，一晚上能修完项目、写完文档、跑完验证、顺手把 GitHub PR 也审了。

另一些人用 Codex，只得到一句很客气的：

“你可以尝试检查一下配置。”

差距真不是模型智商。

更像同样叫了一支施工队，有人把图纸、材料、验收标准、施工边界、门禁权限都准备好了；有人只站在门口喊了一句：“帮我把房子弄好。”

Codex 目前最容易被误解的地方就在这。

许多人还在把它当“代码版 ChatGPT”：问一句，答一句；给一段报错，让它猜一段修法；写完之后自己再手动复制粘贴。

但 OpenAI 官方给 Codex 的定位，实则已经不是“更会写代码的聊天框”。在开发者文档里，Codex 被描述为可以贯穿你写代码的各个地方的 agent；官方产品页也展示了线程、任务、文件改动、终端、代码审查这些东西。

说白了，Codex 不是坐在旁边给你出主意的参谋。

它更像一个能进工地的项目搭档。

前提是，你得会把活交给它。

先说结论啊。

Codex 使用全技巧，不是背一堆提示词模板，而是建立一套“把目标变成交付”的工作系统。

这套系统大致有九层：

目标要像工单。

上下文要像图纸。

规则要写进 AGENTS.md。

专业经验要沉淀成 Skills。

工具要通过 MCP、浏览器、终端、文件系统这些能力接上。

危险动作要交给沙盒和审批。

复杂任务要拆给子代理。

重复任务要变成自动化。

每次交付都要有验证证据。

欸，听起来有点像工程管理课。

但问题就在这：Codex 的上限，恰恰不是“会不会聊天”，而是你有没有把它当工程系统来用。

一、别再说“帮我看看”，要说“交付什么”

普通用户最常犯的第一个错，是把 Codex 当搜索框。

列如：

“帮我看看这个项目有什么问题。”

这句话当然不是不能问。

但它的问题是，目标太散了。Codex 不知道你要的是代码审查、架构诊断、性能排查、依赖升级、测试修复，还是单纯想听一句安慰。

一个好任务，应该像一张小工单。

它至少要有四个东西：

你要它改什么。

不许它动什么。

完成之后怎么验证。

最后要交付什么。

列如同样是排查问题，你可以这样交代：

“请检查登录流程里导致刷新后状态丢失的问题。只允许修改认证状态管理相关文件，不要改 UI。完成后跑现有测试，如果测试覆盖不到，请补一个最小回归测试。最终告知我改了哪些文件、验证结果，以及还有什么风险。”

这个提示词没有什么玄学。

它只是把“看看”翻译成了“施工任务”。

Codex 最喜爱这种任务。

由于它可以读文件、定位问题、编辑代码、跑命令、看测试输出，然后在最后汇报证据。你越让它知道验收标准，它越不容易变成一个只会输出提议的文本机器。

反过来，如果你只说“优化一下”，那就很容易翻车。

优化什么？

速度？可读性？体积？首屏？内存？交互？文案？视觉？

你不说，它只能猜。

而 agent 一旦开始猜，后面的许多麻烦就不是模型犯傻，而是任务本身没有边界。

所以第一条技巧很朴素：

不要向 Codex 许愿，要向 Codex 派单。

二、上下文不是越多越好，是越贴近现场越好

许多人觉得，既然 Codex 上下文变强了，那我是不是应该把所有资料都扔进去？

不必定。

上下文这东西，像给师傅看图纸。

你装修厨房，当然要给水电图、橱柜尺寸、燃气位置。你把小区绿化规划、物业公告、十年前买房合同也塞进去，只会让人更难找重点。

Codex 也是一样。

真正有用的上下文，一般是这些：

项目结构。

相关文件路径。

报错原文。

复现步骤。

已有测试。

设计约束。

你不想被改动的边界。

官方文档里专门把 Prompting 拆成 prompts、threads、context、goal mode 等概念，本质上也是在强调一件事：和 Codex 协作，不是单轮问答，而是围绕一个持续目标积累上下文。

这就像开一个工地群。

第一条消息不是“师傅你看着办”，而是把现场照片、问题描述、预算、禁区、验收方式都放进去。后面每一次沟通，都围绕同一个现场继续推进。

但这里有个反直觉的点：

上下文不是越长越专业。

许多时候，你给 Codex 最有价值的一句话，是：

“你先读 src/auth 和 tests/auth，不要全项目乱扫。”

这句话比你贴 5000 字背景有用。

由于它把 Codex 的注意力从“互联网式泛泛分析”拉回到“本地现场施工”。

三、AGENTS.md 是长期规矩，不是临时备注

如果说单次 prompt 是一张工单，那 AGENTS.md 就是贴在工地门口的施工规范。

OpenAI 官方文档给 AGENTS.md 单独开了一页，标题就是 Custom instructions with AGENTS.md，也就是用 AGENTS.md 给 Codex 项目级的额外指令和上下文。

这东西很重大。

由于你不可能每次都重新告知 Codex：

我们用 pnpm，不用 npm。

测试命令是什么。

不要随意改数据库迁移。

不要碰用户没要求的重构。

前端组件要遵守什么设计系统。

中文稿件默认保存到哪里。

最终回复要说清验证结果。

这些都不是某一次任务的小要求。

它们是这个项目的“家规”。

家规写在聊天框里，下一轮可能就散了。写进 AGENTS.md，Codex 每次进项目时都能读到。

这对个人用户也有用。

你可以写：

“默认和我说中文。”

“涉及所有文件修改前先说明意图。”

“最终回复必须包含改动、验证和风险。”

“不要只给提议，能执行就执行。”

这些东西听起来不像技术。

但它们决定了 Codex 是像一个有记性的搭档，还是像一个每次都要重新培训的临时工。

更高级一点，你可以做分层。

全局 AGENTS.md 写你的个人偏好。

项目根目录 AGENTS.md 写项目规则。

子目录里再写更细的模块规则。

列如后端目录强调数据库和接口兼容，前端目录强调视觉规范和可访问性，内容目录强调文风和交付格式。

这就有点像公司制度。

总部有制度，部门有规范，小组有 checklist。人可以换，规矩不乱。

四、Skills 是把“经验”打包，不是把提示词收藏起来

Codex 的 Skills，许多人一开始会理解成“高级提示词”。

这就低估它了。

官方文档里说 Skills 是给 Codex 新能力和专业知识。它不只是几句口令，而是一套可以包含说明、参考资料、脚本、模板、资产和工作流的能力包。

用人话说，Skill 像什么？

像公司里的老师傅把自己的手艺写成 SOP，再把常用工具也装进工具箱。

后来新人来了，不需要从零摸索。

直接按 SOP 干。

这对 Codex 特别关键。

由于许多任务不是“会不会写代码”，而是“懂不懂这个场景的交付标准”。

写公众号文章，不只是生成正文，还要调研、配图、台账、纯文稿、文件结构、最终校验。

做 PPT，不只是改字号，还要检查 AutoFit、实际截图、参考页结构、无答案页和有答案页配对。

修项目，不只是改 bug，还要保留用户已有改动、跑测试、说明风险。

这些都不是一条 prompt 能稳定解决的。

它们应该沉淀成 Skills。

真正好用的 Skill，至少解决三件事：

第一，什么时候触发。

第二，按什么顺序做。

第三，怎么判断做完。

许多人做 Skill 的坑，是把它写成“你要写得专业、优雅、全面”。

这等于没写。

Codex 需要的不是形容词，是流程、约束和验收。

列如：

“先读取输入材料。”

“再建立证据表。”

“只选择一个内容模块。”

“图片必须保存到 assets。”

“完成后运行 validate。”

这才是能执行的 Skill。

说白了，prompt 是一次性口头交代；Skill 是可复用的工艺包。

全技巧用户，迟早会从“收藏提示词”升级到“维护 Skills”。

五、MCP 和工具，是让 Codex 长出手脚

如果只看文字能力，Codex 再强也只是坐在屋里想。

真正让它变成 agent 的，是工具。

文件系统让它能读写项目。

终端让它能跑测试和构建。

浏览器让它能看真实页面。

MCP 让它能接数据库、设计工具、知识库、GitHub、邮件、内部系统。

这就是“手脚”。

没有工具的 Codex，像一个很机智但只能隔着电话指导你的师傅。

有工具的 Codex，才像师傅真的进了现场。

但手脚越多，越要管住。

能连数据库，不代表应该让它随意跑写操作。

能发邮件，不代表应该让它自己决定收件人。

能访问网页，不代表所有网页内容都可信。

所以工具使用的核心不是“越多越爽”，而是“越清楚每个工具该干什么，不能干什么”。

列如：

读文件、查文档、跑测试，这些可以相对开放。

删除文件、推送代码、访问生产环境、发送外部消息，就必须有明确边界和确认。

这不是保守。

这是 agent 时代的基本安全感。

你请施工队进家门，当然希望它能拿工具干活；但钥匙、燃气阀、电表箱，不可能全部无人看管。

六、沙盒和审批，不是碍事，是安全带

OpenAI 官方文档专门有 Sandboxing，也就是沙盒。

许多新用户看到权限确认会烦：

怎么又要批准？

怎么网络访问受限？

怎么写某个目录还要确认？

但从 agent 的角度看，这些不是麻烦。

这是安全带。

Codex 会执行命令、修改文件、访问网络。它的能力越接近真实操作，权限边界就越重大。

你不能一边希望它真的干活，一边又完全不管它碰了什么。

沙盒的意义，是把风险动作分层。

普通读写在工作区里做。

越界写入要确认。

联网、远程服务、包管理、数据库、云服务，要确认。

删除、重置、覆盖、推送这种可能造成损失的动作，更要确认。

这套机制不是为了拖慢你。

它是在避免“本来只是想修个 bug，结果把半个工作区清了”这种人间惨剧。

所以全技巧使用 Codex，有一个超级重大的心态：

不要把权限确认当成打扰。

它是你和 Codex 之间的责任分界线。

你可以授权它做事，但你要知道自己授权了什么。

七、子代理不是炫技，是把脑子分给不同工种

复杂任务最怕什么？

最怕一个线程里塞进太多角色。

又要调研，又要写代码，又要审稿，又要做图，又要检查安全，又要总结。

人会乱，模型也会乱。

Subagents，也就是子代理，解决的是这个问题。

它像什么？

像总包把任务拆给不同工种。

一个人负责读资料。

一个人负责代码审查。

一个人负责视觉检查。

一个人负责跑验证。

主代理负责收口和决策。

官方 Subagents 文档里提到，子代理工作流可以协助 Codex 保持专注，也可以为不同代理选择不同模型和推理方式。

这句话翻译成人话就是：

别让一个脑子同时当产品经理、工程师、测试、设计、法务和编辑。

它当然也能硬扛。

但越复杂越容易串线。

什么时候适合用子代理？

项目很大，需要并行读多个模块。

代码改动前，需要独立审查风险。

文章或报告很长，需要分头查证和校对。

UI 任务需要一个代理做实现，一个代理做视觉 QA。

安全任务需要一个代理找问题，另一个代理验证修复。

但子代理也不是越多越好。

拆得太碎，会增加沟通成本。

就像装修时，换个灯泡没必要叫总包、水电、监理、设计师一起开会。

全技巧的关键，是知道什么时候拆，什么时候不拆。

一句话：

小任务让 Codex 单线程闭环；大任务让它分工协作，再由主线程收口。

八、Worktrees 是并行施工现场，不是随手开分身

Codex app 文档里有 Worktrees。

这个功能许多人会低估。

Git worktree 本质上允许同一个仓库开出多个工作目录，每个目录可以在不同分支上工作。Codex app 文档的说法，是利用 Git worktrees 让 Codex 并行工作。

这就很像什么？

同一套设计图，开了几个独立施工间。

A 房间修登录。

B 房间改设置页。

C 房间升级依赖。

彼此不把水泥糊到对方墙上。

对个人用户来说，这个能力很香。

由于你可以让 Codex 在一个 worktree 里大胆试方案，而你的主工作区保持干净。

试成了，合并。

试坏了，丢掉。

这比直接在主目录里乱改安全多了。

但 worktree 也有坑。

如果你不知道哪个目录对应哪个分支，很容易把验证跑错地方。

如果多个 worktree 同时改同一块逻辑，后面冲突会很烦。

所以使用 worktree 的核心，不是“多开几个线程显得很先进”。

而是给并行任务明确命名：

fix-auth-session

refactor-settings-panel

upgrade-playwright

任务名像标签一样贴在施工间门口。

Codex 才不会进错门。

九、自动化适合巡检，不适合把判断权全交出去

Automations，也就是自动化，是 Codex app 里超级值得重点关注的能力。

官方文档把它定义为可以安排周期性 Codex 任务。

列如每天检查依赖更新。

每周整理项目风险。

定期跑安全扫描。

每天生成日报。

定时监控某个页面或数据源变化。

这听起来很像把一个实习生安排成值班员。

每天到点巡逻。

发现问题写报告。

简单问题可以修。

复杂问题叫你来决定。

这才是自动化的正确姿势。

许多人一听自动化，就想让 AI 自己全权处理。

这就危险了。

尤其是涉及外部发布、删除数据、发邮件、改生产环境、推送代码的任务，自动化不应该绕开人的确认。

它最适合做三类事：

第一，重复但低风险的信息整理。

第二，固定流程的检查和提醒。

第三，有明确验收条件的小修小补。

自动化不是让你消失。

自动化是让你不用每天亲自去翻垃圾桶。

它把脏活累活先筛一遍，把真正需要判断的东西拿到你面前。

十、GitHub Review 是把 Codex 放到交付末端

Codex 不只适合写代码。

它也适合审代码。

OpenAI 官方 GitHub 集成文档里写了 Codex code review in GitHub，可以设置 PR 审查、用 @codex review 请求审查、启用自动审查，还能自定义审查指南。

这点很关键。

由于许多团队用 AI 的方式，是把它放在开发前半段：

帮我写一个函数。

帮我生成一个页面。

帮我改一个 bug。

但真正影响交付质量的，往往在后半段：

这个改动有没有破坏旧逻辑？

有没有漏测？

有没有安全风险？

有没有不该动的文件？

有没有把临时代码提交上来？

这时候 Codex 做 review，很像多了一个不困的二审。

当然，它不是最终责任人。

它会漏，也可能误报。

但它擅长在大段 diff 里找模式：空值、边界、并发、权限、错误处理、测试缺口、迁移风险。

人类审查最容易累的地方，恰好是它最能稳定扫一遍的地方。

所以全技巧用法里，Codex 不只负责“生成”。

还要负责“检查”。

写完让它自己跑测试。

改完让它解释 diff。

提交前让它做 review。

PR 上让它再查一遍。

这才是一个闭环。

没有验证的 AI 代码，只是半成品。

十一、最容易被忽略的技巧：让 Codex 说证据

许多人用 Codex，会在最后问：

“完成了吗？”

Codex 很可能回答：

“完成了。”

这句话没价值。

你真正应该问的是：

“你怎么验证的？”

这就像验房。

不是师傅说“好了”就好了。

你要看水压、插座、墙面、门缝、合同清单。

Codex 也一样。

最终回复里最好包含：

改了哪些文件。

为什么这么改。

跑了哪些测试。

测试结果是什么。

哪些没跑，为什么没跑。

还有什么风险。

这不是形式主义。

这是把 AI 输出从“看起来合理”变成“可以复核”。

尤其是代码、文章、PPT、数据处理、自动化脚本这种任务，最终都应该落到证据上。

文章有没有引用来源。

图片文件是否真实存在。

PPT 字号有没有截图复核。

测试是不是跑过。

生成文件是不是保存到目标目录。

这就是 Codex 和普通聊天机器人的分水岭。

普通聊天机器人给你答案。

Codex 应该给你结果和证据。

十二、把 Codex 当同事，而不是神灯

聊到最后，Codex 全技巧实则不是某个隐藏按钮。

它是一套协作心智。

你要把它当一个能力很强、执行力很强、但必须被清楚管理的同事。

别神化它。

它不是万能工程师，不会自动知道你的项目历史，不会天然理解你的审美，也不会对每个生产风险负责。

也别低估它。

它不是只会补全代码的小玩具。只要上下文、规则、工具、权限和验收方式给对，它可以从“提议你怎么做”一路走到“我已经做完，并且验证了”。

这中间差的不是一句更华丽的 prompt。

差的是工作系统。

所以如果你想真正用好 Codex，可以从一个最简单的模板开始：

“目标是什么；相关文件在哪里；不要动哪里；完成标准是什么；验证怎么做；最后怎么汇报。”

把这六件事说清楚，Codex 的表现会立刻不一样。

再往后，把重复规则写进 AGENTS.md。

把专业流程做成 Skills。

把外部能力接成工具。

把高风险动作交给沙盒和审批。

把大任务拆给子代理。

把周期任务交给自动化。

把每次交付都压到验证证据上。

这才是 Codex 真正的使用全技巧：不是让 AI 替你思考一切，而是让 AI 进入你的工作流，按你的规则，交付可以检查的结果。

神灯许愿，靠运气。

施工交付，靠系统。