大神教你6个Codex实用玩法！居然还能这么用！

为什么你用 Codex 还是反复返工？问题可能不是它不够强，而是你还没把它当成项目助手来用。

一、全文速览图

前几天我一直在测 Codex，从安装、日常技巧，到把设计稿还原页面。

作为一个设计师，我一开始对它的理解其实很简单：这东西能帮我把想法做出来，把设计稿跑起来。

已经很666了！

后来我又去看了Jason 写的《Getting the most out of Codex》，以及 OpenAI 官博那篇《OpenAI 如何使用 Codex》。

说实话，看完感觉我对Codex的能力开发还不到30%。

官方博客分享了 OpenAI 内部怎么用 Codex：理解代码、重构迁移、性能优化、补测试、提速开发，更偏代码层面的技巧；

Jason 则把这件事往前推了一层——它不仅仅是一个狭义的编码助手，更像是一个完成计算机工作的系统。

看完这两份资料以后，我最大的收获是：

Codex 更适合被当成一个可以持续协作的项目助手。

本篇就不做纯资料翻译了，想结合我的实测，把 OpenAI 内部这套用法拆成几个普通人也能直接参考的工作方法。

二、先让它读懂输入，不要急着写代码

第一个用例，是代码理解。顾名思义：先让 Codex 帮工程师理解陌生代码库。

官方给的提示词很具体：

此仓库中的身份验证逻辑是在哪里实现的？
梳理请求在本服务中，从入口到响应的完整流转流程。
哪些模块与某个模块存在交互，异常故障又是如何处理？

重点在这里：它问的不是“帮我看看代码”，而是入口在哪、流程怎么走、模块之间怎么连。

放到 Figma 设计稿转代码页面，可以换成：先让它读懂设计稿。

可以直接试这句：

请先梳理这个页面的结构：顶部区域、主要内容区、底部操作区、弹窗或特殊状态。
标出哪些元素需要固定，哪些区域需要滚动，哪些按钮有不同状态。
如果有看不清或无法判断的地方，先列出来，不要直接脑补。

那么你就能得到AI反馈，给AI补充交互语义，以便于更准确生成页面：

第一版生成后，第二轮修改就可以让它同时读“Figma 原稿 + 当前页面代码”：

对照这个 Figma frame 和当前页面代码，找出还原不一致的地方。
重点看：布局层级、字号间距、固定区域、滚动区域和图标识别。
先列出问题清单，不要直接动代码。

这一步看起来慢，其实是在省返工，类似「设计走查」。

很多时候，慢就是快。

三、大任务不要一口吞，先拆成小模块

第二个很典型的用例，是重构与迁移。

OpenAI 工程师会让 Codex 处理跨文件、跨包的修改，比如更新 API、迁移依赖、拆分大模块、把旧写法换成新模式。

官方示例里有两句很值得抄：

按业务职责拆分当前文件为独立模块，并为各模块生成对应测试。
将所有基于回调的数据库访问转换为 async/await。

这两句话的好处是，它没有停在“整体优化一下”。

它直接给了 Codex 三件事：按什么拆、往哪里迁、做完以后要补什么。

设计稿还原也一样。最容易翻车的提示词，是这种：

帮我把这个页面还原得更像一点。

这句话人能懂，但 Codex 不一定懂。

“更像”到底是顶部导航、按钮高度、卡片间距，还是图标样式？不说清楚，它只能猜。

换成这种会稳很多：

按页面区域拆分当前代码：顶部导航、内容卡片、底部操作栏、弹窗状态。每个区域尽量独立，方便后续单独修改。不要改变现有视觉风格。拆完后说明每个模块对应哪个 Figma 区域。

这才是 Codex 比较吃得下的任务。边界清楚，模块清楚，改完还能检查。

四、需求没想清楚时，先倒出来

大规模改动，先用询问模式让 Codex 给实施方案，再切到代码模式执行。

Jason 提到一个更贴近真实工作的功能：语音输入。

口喷需求的价值，不是因为它更酷，而是因为很多想法在变成文字之前，本来就是乱的。

很多时候，脑子里可能只有一句：

「这个页面好像哪里不对，但我还没想清楚」

「客户刚刚说页面太冷了，但他应该不是想要更花」

这种话写成正式 prompt 很别扭，但说出来反而自然。

Codex 如果能接住语音、会议记录、随手想法，就可以先帮你把问题排顺。

还有一种方式：把产品需求反馈先贴进去让 Codex 帮你做第一版代码初稿，后续再自行完善优化。

这里不要急着让它“直接做完”，先让它把需求拆清楚。

放到设计工作流也一样，可以先让它出计划：

我现在需求有点乱，先别写代码。请根据 Figma 截图、产品说明和当前代码，给我一份还原计划。
先做哪几块？哪些地方风险最大？哪些地方需要我确认？确认后再开始实现。

如果是一个产品页面 demo，也可以这样说：

我现在有一份产品需求、几张参考截图和当前页面代码。先不要写代码。
请先判断这个需求应该拆成哪些页面状态、哪些组件、哪些交互路径。
给我 3 个实现方案，并说明各自风险。

好的 prompt 不一定要一开始就完美。

更重要的是，先让 Codex 把事情理清楚。

五、过程中要引导转向，也要会排队

Jason 提到 steering 和 queuing。

（就是👇这玩意引导对话）

1. steering 是引导。任务还在跑，你发现方向不对，就中途把它拉回来。
2. queuing 是排队。你不打断当前任务，但把下一步先排进去，让它做完这一步以后继续处理。

Jason 举的例子很具体：走查页面时，可以直接用批注功能标注——这里小一点、这两个元素间距不对、这段文案错了。

这种用法也解释了为什么 Codex 适合处理碎片化任务：

日程被打断时，工程师可以把随手小修复、未完成任务和临时探索先交给它，等空下来再审核结果。

这个思路很像设计师批注设计稿。

不用整张图推翻重画，哪里不对圈哪里。

六、别说“高级一点”，要给验收标准

还有两个用例很实用：性能优化和提升测试覆盖率。工程师会让 Codex 找重复高开销操作、给缓存建议、写边界测试、补失败路径。

官方示例：

找出此请求处理程序中的重复高开销操作，并给出可使用缓存的优化建议。为此函数编写单元测试，覆盖边界场景与失败路径。扩充测试文件，以补充空输入与无效状态等缺失场景。

非工程师看这些词可能会觉得有点远。

但背后的思路很简单：不要靠感觉验收，要列检查项。

举个例子，设计稿还原也可以这样验收：

完成后请按这 6 项自检：

1.390×844 视口是否正常；
2.顶部导航是否固定；
3.底部按钮是否固定；
4.中间内容是否可滚动；
5.图标是否和 Figma 一致；
6.按钮状态是否完整。
最后列出仍不一致的地方。

如果是页面交互，也可以这么验收：

完成后请检查：

1.主要路径是否能从首页走到结果页；
2.每个按钮是否有可见反馈；
3.空状态、加载态、错误态是否都有基础处理；
4.移动端预览下是否有明显遮挡；
5.关键页面是否能截图给我对照。

这些其实都不复杂。只是把“高级一点”“优化一下”这种玄学要求，换成能检查的标准。

Codex 最怕的不是任务难，它怕的是不知道终点在哪里。

七、把规则写进文件，别全靠聊天记忆

还提到 AGENTS.md。它的作用，是把那些 Codex 不能单靠代码推断出来的规则写下来：命名规范、业务逻辑、特殊规则、依赖关系。

Jason 也提到类似思路：长期上下文不要只放在聊天里，可以放进 Obsidian vault 这类外部文件系统。

这点我很认同。长期线程很好，但重要规则最好写进文件。

开发项目可以写 AGENTS.md。

设计项目可以写 DESIGN.md。

比如设计项目里的 AGENTS.md，可以写得很朴素：

本项目是一个移动端 H5 demo，优先保证视觉还原和交互演示，不追求生产级工程结构。默认视口为 390×844。修改页面前，先检查 Figma 原稿里的字号、间距、固定区域和滚动区域。不要擅自替换品牌色、字体风格和图标风格。无法确认的地方，先列为待确认。

品牌视觉项目可以写进 DESIGN.md：

品牌主色、辅助色、字体倾向、按钮圆角、插画风格、禁用风格，都写在这里。后续生成页面、海报、组件时，先读取这个文件，再开始执行。

这些文件不用一开始就很高级。

能减少下一次重复解释，就已经OK了。

八、最后叨叨

看完这两份资料，我现在对 Codex 的理解变了。

如果只把它当代码助手用，就有点浪费了。

当它能接住上下文，再加上浏览器、桌面这些入口，它就开始有点像一个真正能跟着项目往前走的工作台。

如果把 Codex 放进你自己的真实工作流里，你觉得哪一步会是卡点？