在 Codex 系列的第一篇 Vol.01：从跑通 CLI 开始，看懂 Codex 怎么工作 和第二篇 让 Codex 读懂开源项目 Typer中我们先把 Codex CLI 跑起来，又用一个开源项目练习了“读代码”：看目录、找入口、追运行链路、读测试，再尝试做一个很小的修改。
到了第三篇，可以换成一个更真实的场景：接手一个已经做出来的项目。
我前面用 Codex app 做了一个 AI 志愿填报 Demo，你可以来体验它。项目讲解可以参考七牛云的文章：AI 填志愿火了，我们用 1 天做了一个志愿决策沙盘
AI 志愿项目简述
它一开始只是一个小七同事的想法：做一个高考填志愿的小 demo。
在项目实现的过程中，Codex 一路帮我优化，借助七牛 LAS 的公网域名功能部署到了服务器，变成了一个可被大家访问的静态站点：
它展示了高考省份、位次、选科组合和偏好画像等等关键信息，并搭配了院校专业推荐、志愿方案、专业解释、院校对比等进阶功能。除此之外，还做了移动端适配，补过了几轮演示数据，尽量覆盖高位次、中位次、低位次考生，让他们都能来试玩下。
整个开发过程有点像真实项目的开发。一开始可以靠和 AI 聊天推进，想到什么就问什么；项目变长之后，继续靠一轮轮自然语言对话，就会出现一些需要我们注意的问题：Codex 当前在哪个目录里工作？这次准备改哪些地方？它有没有动到无关样式？修改之后到底产生了哪些 diff？前面对话太长，会不会影响后面的判断？
这时候，就要拿出本篇要讲的 slash command 了。
在本篇，小七会和你一起看几个 Codex 里比较好用的 slash command。不用死记硬背它们，跟着真实项目里的示例理解就好：/status 用来看当前状态，/goal 用来设定持续目标，/plan 用来提前规划，/mention 用来指定关键文件，/diff 和 /review 用来检查改动，/compact 用来处理长对话，/resume 用来接回之前的任务。
/status
看清当前状态
↓
/goal
明确这一阶段要优化什么
↓
/plan
先想清楚这一轮怎么改
↓
/mention
把注意力聚焦到关键文件
↓
/diff
看清这次到底改了什么
↓
/review
再做一轮复查
↓
/compact 或 /resume
长对话就压缩，隔天继续就恢复
这些 slash command 合在一起，其实就是 Codex 会话里的控制面板。
/status 看清当前状态
当我们接手一个已有项目时，第一步建议先敲/status。它的作用就是确认 Codex 当前项目状态，让你知道当前模型、工作目录、权限策略、可写目录和上下文使用情况。
一般真实开发项目，会存在多个目录：本地开发目录、下载目录、服务器目录、旧版本备份目录。你以为 Codex 在改当前项目，可能实际上它在另一个路径里工作。
以这个项目为例，我们现在打开终端，输入 codex 进入 Codex，并输入 /status。再切到 AI 志愿的项目下，重新进入 Codex，并输入 /status，对比两边的 Directory。
很明显，左侧的 Directory 是这台电脑的用户主目录，也就是当前没有进入具体项目目录；右侧的 New Project 才是 AI 志愿项目所在目录。
此外，还要留意 Permissions，上图是 Ask for approval，就是需要人类介入授权；还有 Context window，就是模型经常会提到的上下文，比如 DeepSeek 支持百万级上下文，说的就是这个。一旦超过上下文窗口，系统就会摘要、截断和压缩部分之前的记录。
/goal 给连续优化设一个方向
其实，这个 AI 志愿项目现在已经比较完善了。首页、画像、推荐、我的方案、认识专业、院校对比、移动端和部署流程都跑通了。我们要进行继续优化的话，重点就不是从零补功能，而是稳住现有体验，继续打磨页面细节和演示数据。
这就很合适 /goal 了。它可以给一段长任务设定持续方向。
但是，我们用 /goal 命令时，不要把需求写得太空，比如“继续优化这个项目”这个需求就被 GPT 说不够具体。一个好的写法是把项目状态、优化重点、边界和验收方式都说清楚：
/goal 继续优化这个 AI 志愿填报 Demo。保持现有功能和视觉风格稳定，重点完善页面细节和演示数据覆盖，让高位次、中位次、低位次用户都能获得可试玩的推荐结果；所有数据必须明确标注为演示样本，仅供试玩，不作报考参考；每次修改后检查 diff，并自测画像、推荐、方案和院校对比的核心路径。
这条目标里有 5 层信息：
项目方向清楚：继续优化 AI 志愿填报 Demo。
当前基线清楚：现有功能和视觉风格已经基本稳定，不要大幅重做。
优化重点具体：页面细节和演示数据覆盖。
数据边界必须保留：它是演示样本，只能用于试玩，不能写成真实报考建议。
每轮修改后要验收：检查 diff，并自测画像、推荐、方案和院校对比。
这样后面继续提需求时，Codex 会更容易沿着同一个方向推进。比如你说“继续补低位次用户能看到的学校”，它就应该优先考虑数据覆盖、位次段、城市和专业方向，而不是顺手重画页面。
图注：这里看下 kuku 在干活的 Codex
/plan 管住这一轮怎么改
上面提到的/goal 把控长期方向，/plan 负责单轮执行。
目前，我们的项目能跑了，但高校演示数据还不够多。如果你和 Codex 直接说“帮我丰富数据”，它很可能马上开始往 app.js 里塞学校。这不够优雅，比较友好的方式是先让它分析现状：
/plan 当前 demo 的高校数据仍然偏少。请你先分析现有数据覆盖了哪些位次段、城市、学校层次和专业方向，找出明显缺口，先不要修改代码。
这样，我们让 Codex 先把问题拆开：高位次够不够，中位次够不够，低位次有没有结果；北京、上海、杭州、南京、广州这些城市是否都有样本；计算机、医学、财经、师范、工科、文科等方向是否有覆盖；公办、民办、职业本科和高职是否有基本层次。
等它给出的计划合理：
我们再让它开始跑相关的内容：
按刚才的计划扩充演示数据。保持免责声明口径不变，新增数据只作为试玩样本，不要写成真实录取预测。
这样 Codex 的修改会更可控，也更容易在后面用 diff 检查。现在我们看下 plan 给出的计划，继续下一个 slash command：
/mention 指定关键文件
如果你知道关键逻辑在哪个文件里实现，可以用：
/mention app.js
因为这个 Demo 是纯静态项目，页面入口在 index.html，样式在 styles.css，主要交互和演示数据都在 app.js。所以，我要改推荐逻辑、画像联动、方案生成或数据样本的话，直接把 app.js 拉进上下文，会比让 Codex 自己到处找更稳定。
像是这样：
/mention app.js
再继续追问：
请你只基于 app.js，梳理当前院校数据、画像筛选、推荐排序和我的方案生成之间的关系。
上面这个问题可以帮你先看清数据流，好决定让它改哪里：
这一步是让 Codex 先基于 app.js 梳理数据流，确认院校数据、画像筛选、推荐排序和方案生成之间的关系。
/diff 看清它改了什么
只要 Codex 开始改项目，就应该立刻养成一个习惯：
/diff
这个命令会展示当前 Git diff。你可以看到它改了哪些文件、哪些行，有没有顺手动了无关内容：
如果你只是让它扩充高校数据，它却改了首页样式、按钮文案或布局结构，这时候通过 diff 命令就能发现。
看完 diff 后，q 退出之后，我们可以继续追问：
请你解释这次 diff 中每一处修改的原因，特别说明有没有改到无关样式或无关功能。
/review 做一轮本地复查
看 diff 之后，还可以跑 /review。这个命令它适合放在一轮修改之后，让 Codex 先做一次本地复查。
这个 Demo 后期出了不少问题：画像更新后推荐没有同步；“我的方案”页面缺少手动新增入口；按钮点了没有反应；院校对比可以重复选择；低位次用户没有足够可试玩的结果。
这些问题单看页面不一定能立马发现。所以，我们可以让 Codex 按真实用户路径检查：
请你按真实用户路径自查一遍：修改画像 → 推荐刷新 → 添加志愿 → 方案排序和删除 → 生成报告 → 专业测试 → 院校对比。重点检查按钮是否可点、空状态是否合理、数据是否同步。
之后再用 /review 将代码层面的风险过一遍。
/compact 管住长对话
这个 AI 志愿项目的对话其实有点长。从产品思路、页面实现、视觉调整、画像功能、推荐逻辑，到多 tab、部署、字体打包、数据扩充，信息一直在累积。
长对话会带来一个问题，就是 Codex 可能会带着早期临时想法继续执行。尤其是进入新阶段后，前面的很多细碎讨论会影响 Codex 的最终交付。
因此，一个阶段结束后，我们可以用 /compact 来压缩下上下文。
压缩上下文之前，可以让 Codex 先总结当前状态：
请你总结当前项目状态：已经实现的功能、关键文件、当前目标、已知限制和后续优化重点。
然后再执行 /compact。这样后面继续做页面和数据优化时，Codex 可以带着一份更干净的项目摘要往前走。
/new、/resume 和 /fork管理会话
一般项目不是一两天就能做完的，饶是这个 AI 志愿项目，也因为我不是时时刻刻在和它交流，零零散散做了 2 个工作日。周一改了页面，补齐了点数据，周二部署上线，交给同事 Demo 的时候又觉得数据不够，回头补了点数据，顺便修改了下推荐逻辑。
这时候，我们就可以用这几个会话管理命令。
新任务可以用
/new之前的任务继续，可以用
/resume想尝试另一条改法，又不想影响当前主线，可以用
/fork
像是满意当前的页面视觉风格，但想尝试另一个数据展示方案，就可以 fork 一条新线。新线的效果好的话，再把思路带回主线；效果一般，也不干扰主线。
/init 沉淀项目规则
如果这个 Demo 还要继续长期维护，可以考虑使用/init 。它会生成 AGENTS.md 的脚手架，用来写项目规则。
虽然这个 AI 志愿项目很简单，但有很多信息可以沉淀下来：
它是纯静态项目，不需要构建；
入口是
index.html；样式在
styles.css；交互和数据在
app.js；上线包需要包含
assets/fonts；演示数据必须有免责声明；
不要把模拟位次写成真实报考建议；
现有视觉风格已经稳定，不要随意大改。
这些规则写进 AGENTS.md 后，下次 Codex 接手项目时，就不用每次重新解释。
一图串流程
把上面的命令串起来，实际可以这样跑。
