让 Codex 听懂你：上下文、提示词和斜杠指令怎么用

💡 **这篇解决什么问题：**Codex 经常理解错需求、改动范围失控、一个小 bug 却翻了半个项目。这篇讲怎么把上下文喂准、怎么写任务提示词、斜杠指令怎么用，让它少猜、少乱动。

更多 Codex 文章：省点力 · Codex 小类

大家卡在哪里

• 理解错需求、改动范围失控：插件装好了，Codex 却经常把需求理解错，或者改到没有授权的文件。
• 上下文不完整：缺少相关文件、调用关系或业务约束，Codex 就只能猜。
• 任务没有写清楚：目标、范围和验收条件缺一项，都可能让结果偏离预期。Codex 能直接改项目，任务说明要像一份简短的需求文档。
• 一次要求太多：一上来就交整个大项目，不给验收条件，还期待一条提示词解决所有问题。
• 白白浪费：明明只是一个小 bug，却让 Codex 读了半个项目。

一、先分清两种输入

Codex 里有两种输入：

• 普通 prompt：你让 Codex 干活，比如“帮我看一下这个项目怎么启动”“帮我修一下登录页 bug”“帮我把这个函数重构得清楚一点”。
• 斜杠指令：以 / 开头，比如 /init、/model、/plan、/diff、/review、/compact。它们是你控制 Codex 工作方式的按钮，不是写代码的需求。

一句话区分：普通 prompt = 你让 Codex 干什么活；斜杠指令 = 你怎么管理 Codex 这个工具。

二、把上下文喂准

很多时候 Codex 跑偏，是因为它一开始就钻进了和当前任务关系不大的代码区域。下面这些办法都在做同一件事：给它一个清楚的起点。

1. 直接用编辑器里已有的上下文

VS Code 插件可以把打开的文件、选中的代码、最近的对话直接加进输入框。Codex 从你正在看的代码开始，你就不用把问题重新描述一遍，提示词可以写得更短，结果也更准。

比如，一个项目用到了 service worker，里面有一个看不懂的 return 语句。开发者不用离开编辑器，打开 Codex 问“这个语句是干什么的？”。Auto Context 按钮会把你最近在 IDE 里的活动告诉 Codex，如果这段 return 用于处理浏览器不支持 service worker 的情况，就让它说明判断条件和提前退出的作用，再对照代码核实。像这种简单问题，它不需要翻遍整个项目就能很快回答。

2. 点名文件：@ 和 /mention

• 在 CLI 里可以用 @ 提到某个文件再提问，比如：“这个文件现在是怎么工作的？如果要加一个按钮，应该改哪里？”IDE 里选中文件、把它作为上下文交给 Codex 也一样。
• 也可以用 /mention 指令：

/mention src/api/user.ts
帮我解释这个文件的请求流程。

适合指定报错文件、组件、配置文件，让 Codex 只围绕某个文件分析，别在全项目乱找。

• 点名的文件不一定是最后要改的文件，它只是一个起点，Codex 会沿着相关代码路径继续探索。与其说“帮我看看这个项目里的登录逻辑”，不如说：

先从 src/auth.ts 开始，找出登录流程和相关的调用关系。

3. 用快捷键把选中的代码加进去

在 IDE 插件里可以给常用功能绑定快捷键。例如绑定 Command + Shift + C：选中几行代码，按下快捷键，这些代码就作为补充上下文交给 Codex。比如选中 hero.tsx 里的 10 行，一次加入上下文，不用反复复制粘贴。适合：

• 解释选中的某段代码；
• 给选中的组件增加一个功能；
• 重构一段不太理解的逻辑；
• 根据现有样式调整页面。

4. 视觉问题直接发截图

改动很难用文字讲清楚时，截图比描述更直观。与其解释“左边第三个按钮叫什么、在哪个位置”，不如截一张图。

• CLI 里：截取当前页面 → 把截图粘贴进对话 → 说明怎么改。
• IDE 插件里：点输入框旁边的加号，添加图片（比如桌面上的 screenshot.png），再写要求。

例如，页面里的三个安装命令都没有背景色，可以截图后要求：“根据这张图片，把这些内嵌代码标签的背景改成橙色。”让 Codex 定位对应组件，只改这些标签，再到浏览器里检查结果。按钮颜色、间距、布局等视觉细节也适合这样描述。

5. Appshots：把当前应用的现场截给它看

Codex App 的 Appshots 可以把当前应用的截图交给 Codex。适合：

• 页面报错，但你不想复制一堆文字；
• 某个设置页你不知道怎么选；
• 前端页面有视觉问题，需要 AI 看截图；
• 想让它基于当前界面继续解释下一步。

注意隐私：截图前看一眼有没有邮箱、token、项目名，能打码就打码；不要把私密聊天、财务页面、后台用户数据直接丢进去。要公开发的截图，再多检查一道。

6. 调试时把完整报错贴进去

别只摘一句报错，也别只说“它报错了”。把完整的错误信息和堆栈都贴给 Codex，它会顺着报错里出现的文件、函数和调用关系去代码库里查，比一句含糊的描述省时间得多。

7. 把代码里的 TODO 变成任务

Codex 能找到代码里的待办注释，把它变成任务。例如，一个按钮组件有一条“加 hover 效果”的注释，点一下注释就会开一个本地对话，并带上实现所需的上下文。不用从头写详细提示词，也不用把文件复制到另一个聊天窗口。流程是 5 步：

1. 在代码里找到一条有用的 TODO；
2. 把相关的编辑器上下文交给 Codex；
3. 让它探索项目并完成修改；
4. 在 IDE 里审查改动；
5. 到浏览器里看效果。

验收时把鼠标移到按钮上，检查阴影和位移是否符合要求，比如阴影变大、卡片微微上移；同时确认点击功能没有受影响。

IDE 里还有待办事项功能：新建一条待办，比如“像刚才的示例一样，在这个页面上实现一个按钮”，然后点击用 Codex 实现，Codex 就会在右侧启动任务，自己读文件、找位置、改代码。同一个项目里可以先列出多条待办，再让 Codex 依次处理。大任务拆开后，每一步都有明确目标，也不用把所有要求塞进一条很长的消息里。

8. 随时确认它找对了方向

• 界面下方会列出它已经读过的文件，你能大致判断它有没有找对地方。
• IDE 里会出现可点击的文件标签，点开就能看到它正在参考哪个文件。
• 它会先列一份简短的计划，把要做的事拆成几步，你能提前看出它准备改哪里。
• 任何时候都可以让它总结当前任务的目标和进度，完成后它也会给一份完整总结。
• 别只看最终答案。要看它中间做了什么：读了哪些文件、跑了哪些命令、为什么要改某个函数、测试失败以后怎么处理。Codex 真正有价值的地方在于执行过程可以追踪。

三、把任务提示词写清楚

1. 一段好提示词要说清 4 件事

一条完整任务要交代：想完成什么；当前项目是什么情况；哪些限制不能碰；最后希望得到怎样的结果。AGENTS.md 管项目里的长期说明（见 一次配好 Codex：AGENTS.md、config.toml、Skills 与 MCP），提示词负责补充眼前这次任务的具体要求。

2. 通用模板

背景：这是一个什么项目，现在遇到什么问题。
目标：我希望你完成什么。
范围：可以改哪些文件，不能动哪些文件。
约束：不要引入新依赖，不要改公开 API，不要改数据库结构。
验收：完成后请告诉我改了哪些文件，并运行哪些测试或检查命令。

把 Codex 当成一个会犯错、但执行力很强的临时工程师。写得越详细，它越不用猜你的想法；没说清的地方，再发一条补充就行。

3. 功能需求怎么写

你是这个项目里的临时工程师。
任务目标：
把用户设置页里的保存按钮，在请求中时显示 loading，并禁止重复点击。
上下文：
这个项目是 React + TypeScript。
设置页在 src/pages/settings 目录。
已有 Button 组件，优先复用，不要新造 UI 组件。
范围：
可以修改 settings 页面和相关 hook。
不要改接口层，不要改路由，不要改样式系统。
验收：
1. 保存中按钮显示 loading
2. 请求未结束前不能重复提交
3. 请求失败后恢复按钮状态
4. 运行 npm run lint
5. 最后说明改了哪些文件

这里面没有玄学，就是把目标、上下文、范围、验收讲清楚。

4. 修 bug：先让它出方案

请排查这个 bug，但先不要直接改代码。
现象：
用户在移动端点击提交后，页面偶尔没有反馈。
我希望你先做：
1. 找到相关代码路径
2. 判断可能原因
3. 给出 2-3 个修复方案
4. 推荐最小改动方案
等我确认后再实施。

这种写法很适合高风险场景。和带新人一样：新人上来就乱改你肯定不放心，先让他读代码、讲判断、列方案，你会放心很多。

5. 告诉它怎么算完成

每次派任务时，顺便告诉它完成后怎么验证：运行测试、检查代码格式、跑项目配置的代码检查工具。如果这些已经写在 AGENTS.md 里，就不用每次重复。也可以把完成标准列成一把“尺子”：

下面是这项功能完成时必须满足的要求。每完成一部分，就对照这些要求检查进度。

它做事时就能随时拿这把尺子衡量自己有没有做到位，改完代码也不会草草收工。验收怎么看、测试证据怎么要，见 Codex 改代码不翻车：权限、分支、Diff、测试和 Code Review。

6. 从小任务开始，大任务先让它拆

刚开始先练小任务：改一个简单功能、修一个小问题、只检查某个文件，方便你判断它靠不靠谱。任务越大，出错的地方越多，审查也越费劲。大任务你不用自己先想好所有步骤，可以让它先研究再拆：

先通读相关代码，确认这个功能目前是怎么实现的，再把它拆成几个可以单独完成的小任务。

然后逐个交给它，每一步之后检查结果、继续补充要求。

7. 别写虚任务

“帮我优化一下这个项目”“帮我重构整个系统”这种任务太虚，失败概率很高。先拆成：先读项目并给重构建议，不改代码。

8. 一条提示词搞不定，就多轮推进

真正的工作流是多轮的：读代码 → 出方案 → 改一小步 → 运行验证 → 再继续。不要幻想一条 prompt 直接变成完美工程。

9. 让它告诉你下一步做什么

完成一个功能后，可以继续问：

基于现在的代码库，下一步可以做什么？

Codex 会结合整个项目来回答，不只盯着刚改的几行。把回答整理成待办清单，挑真正有价值的部分继续推进。可以养成一个习惯：**每次让 Codex 完成一个功能后，再问它下一步该做什么。**也可以问一些更开放的问题，比如一起想功能还能怎么改、性能还能怎么提升。

想深入的话，OpenAI 开发者网站还有更详细的 Codex 提示词指南。

四、第一次的三条任务

按分析、修改、验收逐步推进：

第一条：只读分析

请先阅读这个项目的 README、package.json 和主要入口文件。
只做分析，不改代码。
告诉我：
1. 这个项目是干什么的
2. 本地怎么启动
3. 测试命令是什么
4. 你建议我下一步让你做哪 3 个小任务

第二条：只改文档

请修复 README 里"本地启动步骤"不清楚的问题。
只改 README.md。
不要改代码。
改完后给我总结改动。

第三条：开始碰代码

请找到项目里负责登录页表单校验的代码。
只修复错误提示文案不统一的问题。
不要改接口逻辑。
改完后运行现有 lint 或测试。

Codex 的任务是围绕一个 workspace 持续推进的，你可以补上下文，可以让它改、让它撤、让它解释。

五、可以交给它的活

官方推荐的新手任务

• 读懂代码库：让它解释项目是做什么的、主要模块怎么分工，或者针对某个功能写一份简短说明。
• 补一份 README：也可以拿公司里另一个团队的代码库练习。
• 修复一个 bug：贴完整堆栈，让它自己找问题并修改。
• 扩大测试覆盖：让它检查某个功能可能遗漏的边界情况，再补上测试（提示词见下）。
• 跨文件重构：某个通用组件的逻辑分散在多个实现里，让它找出相似模式、抽出通用组件（提示词见下）。
• 补齐文档：工程师不爱写文档，正好交给 Codex。功能改完、接口变了，顺手让它根据最新代码更新说明。

找测试缺口，可以从一个很具体的问题开始。它不只回答该测什么，还能根据代码里的实际实现把测试补上：

看看这个功能需要考虑哪些边界情况。为了补齐测试覆盖，还应该增加哪些测试？

重复的重构工作，直接描述目标。它会先浏览相关代码、识别重复部分，再抽取调整，比手工翻文件快，也不容易漏掉某个实现：

找出这些实现中的共同模式，把它们整理成一个通用组件，并让不同接口都使用这个组件。

日常写代码时的用法

• 让它解释当前文件的作用；
• 选中一段代码，让它重构或补注释；
• 把报错信息贴进去，让它定位问题；
• 给某个函数补单元测试；
• 代码重构、代码审查；
• 把脚本改成命令行工具、给旧代码补注释这类真实小任务，最适合用来磨合。

查 Git 历史，快速补背景

Codex 可以像在命令行里一样用 Git，查出某个文件是谁改的、提交记录是什么、项目最近有哪些变化。刚接手一个项目时，这能很快补上背景。这类请求可以先用只读提示测试，比如让它整理项目历史、总结文件之间的关系，确认理解没问题再让它动手。

画 Mermaid 时序图

根据这个代码库，提供一张干净的 Mermaid 时序图。

它会先看代码、整理流程关系，再生成一段简洁的 Mermaid 图，可以直接复制或下载，再继续追问让它补充说明、调整细节。结构复杂、文件多的代码库特别省事。

生成一个文档站，再一轮轮加功能

例如，在 agents.md 项目里，可以让 Codex 生成一个 HTML 页面 assets.html，展示文件之间的关系。只需要查阅时用 Markdown 就够；需要导航和交互时，再做成可在浏览器打开的文档页面。

• 生成的 assets.html 不用配置预览工具，直接用 Chrome 打开，就像一份完整的项目文档，还整理出了项目里的不同流程和各文件的作用。
• 在 Codex 面板里可以查看已有的提示词和不同会话，选中当时的会话就能看到它生成了哪些文件，点开可以在侧边面板预览。
• 接着新开一个会话加功能：

能不能在"查看示例"和"GitHub"按钮旁边，再加一个下载按钮和一个复制页面 Markdown 的按钮？

• 切到 Agent 模式后，Codex 会自己读取主视觉组件、确定按钮位置、接入现有页面，并沿用原来的风格。完成后主视觉区域多了下载仓库、前往 GitHub、复制当前页面 Markdown 的按钮。

安排任务的两步法：先让它实现具体改动，说明按钮放在哪里、点击后做什么；再打开生成的文件检查实际效果，不满意的地方继续交给它改。先做出一个看得见的成果，再围绕它一轮轮追加功能。

不写代码的人也能用

• 产品经理：让它理解需求、拆验收标准、看实现有没有漏。

请阅读这个 PR 和需求描述。
从产品经理视角检查：
1. 是否覆盖需求里的每个验收点
2. 是否有明显边界漏掉
3. 是否需要补充空状态、错误状态、加载状态
4. 是否有用户体验风险
不要改代码，只给检查清单。

• 设计师：把设计稿、原型、已有页面串起来，让它做出能运行的东西。
• 运营和内容：写脚本、批处理、整理数据、检查页面。

前提只有一个：把任务说清楚。不会写代码没关系，不会描述目标才是问题。

六、斜杠指令怎么用

先记住 3 个常识

1. 指令必须放在开头。/model 是对的；“请帮我 /model”不对，Codex 只在输入框第一个字符看到 / 才当成指令。
2. 忘了就输入 /。会弹出当前能用的指令列表，继续输入字母可以过滤，比如输入 /mo 就能看到 /model。每个人看到的列表可能不一样，取决于系统、版本、插件、权限和实验功能，以你本地输入 / 看到的列表为准。
3. 别把 Claude Code 的习惯硬套过来。Claude Code 里常见 CLAUDE.md、/btw、/branch；Codex 里对应的是 AGENTS.md、/side、/fork。

常用指令速查

/plan 的用法

大任务不要直接让 Codex 动手。不要一上来说“帮我重构权限系统”，应该说：

/plan 帮我分析当前权限系统，给出最小风险的重构方案，先不要改代码。

越大的任务，越要先 /plan。

第一次用 Codex 的 8 步流程

# 1. 进项目目录
cd my-project
codex

# 2. 初始化项目说明
/init

# 3. 看状态
/status

# 4. 先让它读项目，不要直接改
先不要改代码，帮我读一下这个项目结构，告诉我启动命令、测试命令、主要模块和最危险的目录。

# 5. 大任务先计划
/plan 帮我修复登录页提交后 loading 状态不消失的问题。先定位相关文件，给出最小改动方案，不要直接改代码。

# 6. 确认方案后再让它改
按方案实现，保持改动尽量小。

# 7. 看真实改动
/diff

# 8. 提交前审查
/review

先让它读，再让它想，再让它改，最后你验收。别一上来就全自动。

一段口诀

先 /init，让 Codex 认识项目。再 /status，确认状态。大任务先 /plan。关键文件用 /mention。改完必须 /diff。提交前跑 /review。对话长了用 /compact。明天回来用 /resume。临时问一句用 /side。想试新路线用 /fork。

最后

把 Codex 当成一个很聪明、但需要你管理的编程同事：

• 你给它上下文，它就少猜；
• 你给它边界，它就少乱动；
• 你看 diff，它就不敢糊弄你。

会用 Codex 的人，会让 AI 坐在副驾，帮你看路、查地图、修车，方向盘还在自己手里。

按需查阅的官方文档

• Codex IDE 官方使用指南
• Codex 官方 VS Code 插件页