31 · 进阶技巧与提速：拖慢你的不是模型，是你给的烂上下文
📚 系列导航：上一篇「30 怎么选模型」讲的是「同一句话该派哪个模型、配多大推理强度去跑」。这一篇接着往下走——光选对模型还不够，真正决定你一天能干多少活的，是你怎么喂上下文、怎么管会话、怎么让多条线同时跑。下一篇「32 从 Claude Code 迁移」再聊老用户怎么平滑搬家。
上一篇结尾我埋了句话：很多时候拖慢你的不是模型不够强，而是你给的上下文太乱、让它走了冤枉路。 这一篇就来还这个债。
先给你看我自己的一笔账。2025 年 3 月我做一个 Python 小工具，有个功能让我跟 Codex 来回折腾了整整一下午——我后来翻 /status 的会话记录数了数，光这一个需求就跑了 11 轮，期间它两次改错文件、一次把我没让它碰的配置也顺手「优化」了。复盘的时候我才反应过来：不是 gpt-5.5 不行，是我第一句话就只甩了一句「帮我加个导出功能」，剩下十轮全在补我本该一次说清的上下文。
说句实话，AI 编程里最大的慢，从来不是模型转圈那几秒，是返工。 一次没说清，它走一条岔路，你再拉回来，来回三趟，半小时没了。模型再快，也快不过「一次做对」省下来的那些轮次。
这一篇不教你什么玄学咒语，就讲六件能实打实砍掉返工、让整条流程跑顺的事。
看完这一篇，你会拿到：
- 一个反直觉的提速心法：少返工 > 盲目求快，一次做对才是最省时间的「快」
- 一套「好请求」的固定配方：目标 + 上下文 + 约束 + 验收标准，附一张 Before/After 提示词对照表
- 管好上下文窗口的三招：
/compact压缩、该新开会话就新开、用@精准喂文件而不是糊一整个库 - 按任务降档省时省钱的思路（接上一篇的模型选择）
- 让多条线并行跑、让 Codex 自己验证的进阶玩法
- 一个能立刻照做的动手练习：把一句含糊需求改写成四段式，亲眼看返工率怎么降
⚠️ 本篇命令、配置键、默认行为以 Codex 官方文档为准；模型名、信用点（credit，Codex 里换算用量的计费单位）倍率、
/fast等会随版本变，以你本地codex --help和官方文档实际为准。
01 提速的本质：少返工，而不是盲目求快
先把心法摆正，不然后面所有技巧都是瞎使劲。
新手一想到「提速」，第一反应都是「换更快的模型」「把推理强度调低」「开个加速模式」。这些后面都讲，但它们都是末节。真正的大头是返工。
类比：做菜。 你做一道菜慢，很少是因为灶火不够旺。多半是你切到一半发现葱忘买了、盐放多了得重来、菜谱看错了步骤。真正吃掉时间的是这些「推倒重来」，不是灶火大小。把火开到最大，救不了一个一边做一边返工的厨子。
AI 编程一模一样。Codex 走一条岔路、改错一个文件、领会错你的意图，你拉回来重说一遍——这一来一回的代价，远超它多想几秒。
官方文档里有句话我印象很深，意思是：Codex 在能验证自己工作的时候，产出质量明显更高。换句话说，让它一次走对、走稳，比让它走得快，重要得多。
我自己有过特别典型的一次。去年底我让它「把这个函数优化一下」，没说优化什么、不许动什么、怎么算优化成功。它热情地把函数重写了，顺手改了我的接口签名，连带三个调用方全报错。我花了二十分钟才把它「优化」出来的烂摊子收回去。那次之后我立了条铁律：模糊的「优化一下」永远不说，宁可多打两行字。
记住这个排序，后面五节全是它的展开：
| 你以为的提速 | 真正的提速 |
|---|---|
| ❌ 换更快的模型一把梭 | ✅ 第一句话就说清，减少返工轮次 |
| ❌ 推理强度无脑调低图快 | ✅ 按任务难度匹配算力（上一篇讲过） |
| ❌ 把整个项目都丢给它读 | ✅ 用 @ 精准喂相关文件 |
| ❌ 一个会话从早开到晚 | ✅ 一个任务一个会话，及时压缩或新开 |
| ❌ 改完自己肉眼一行行检查 | ✅ 给验收标准，让它自己跑测试验证 |
💡 一句话总结：AI 编程最大的慢是返工，提速的第一性原理是「一次做对」，而不是「跑得更快」。
02 给足上下文、别让它猜：好请求的固定配方
上一节说返工是大头，那返工从哪来？绝大多数来自第一句话没说清，逼着 Codex 去猜。 它一猜，就有概率猜歪，你就得返工。
类比：交代外卖备注。 你只写「来份炒饭」，骑手和厨房只能按默认来——可能放葱、可能辣、可能咸。你要是写「扬州炒饭，不要葱、微辣、米饭软一点」，一次就对。给 Codex 的请求也一样，你省下来的每一个字，它都得替你猜，猜错了就返工。
官方在「最佳实践」里给了个我照搬至今的配方。一个好请求，默认带这四样：
- 目标（Goal）：你到底要改什么、建什么？
- 上下文（Context）：哪些文件、文档、报错跟这事相关？用
@把它们点出来。 - 约束（Constraints）：要守哪些规范、架构、不许碰什么？
- 验收标准（Done when）：什么情况算做完？测试过、行为变了、bug 不复现了？
这四样不用每条都写满，但目标和验收标准几乎不能省。我现在敲需求，哪怕再急，也会在脑子里过一遍这四个槽位。
下面这张对照表，是我把自己以前踩过的烂提示词翻出来重写的，你直接感受差距：
| ❌ Before（含糊，注定返工） | ✅ After（四段式，一次过概率高） |
|---|---|
| 帮我加个导出功能 | 目标：给 report.py 加一个把报表导出为 CSV 的函数。上下文：参考 @export/json_export.py 现有的写法。约束：复用现有的 Report 数据类，不要改它的字段。验收：能导出含表头的 CSV，且 tests/test_export.py 全过 |
| 这个函数有点慢，优化下 | 目标：search() 在 1 万条数据上要 2 秒，降到 200ms 内。上下文：函数在 @core/search.py。约束：不许改函数签名和返回结构。验收：跑 pytest tests/test_search.py::test_perf，断言耗时 < 0.2s 通过 |
| 修一下这个 bug | 目标：修复登录后跳转到空白页的问题。上下文：复现步骤是「输对账号密码 → 点登录 → 白屏」，相关代码在 @auth/login.py。约束：不要动权限校验逻辑。验收：复现步骤走一遍能正常进首页 |
看出来了吗？右边不是更啰嗦，是把你脑子里本来就有、却懒得打出来的信息补全了。 你不补，Codex 就得猜；你补了，它就直奔目标。
我做那个 Python 小工具复盘时算过，同一个需求，我用左边的写法平均要 5 到 8 轮才搞定，换成右边的四段式，多数时候 1 到 2 轮就过了。多打的那两行字，省下的是后面三趟来回。
还有个偷懒但有效的招：任务太难、你自己都没想清楚怎么描述时，别硬写，让 Codex 先帮你理。 官方推荐用计划模式（Plan mode），CLI 里用 /plan 或者 Shift+Tab 切换，它会先收集上下文、反问你几个问题、列个方案，等你点头再动手。与其让它带着误解一路写歪，不如花一分钟让它先把方案理出来。
💡 一句话总结：一个好请求 = 目标 + 上下文 + 约束 + 验收标准，省下的每个字 Codex 都得替你猜，猜错就返工。
03 管好上下文窗口：别把整个库糊上去
第二节解决「说清楚」，这一节解决「别说太多」。这俩听着矛盾，其实不是——要的是相关信息说全，无关信息别带。
每个会话（Codex 叫 thread）能装的信息有上限，这就是上下文窗口（context window），指模型一次能「记住」的全部内容总量。它装满了，旧信息要么被压缩、要么挤掉，质量就开始掉。
类比：一张办公桌。 桌面就那么大。你把当前任务需要的三份文件摊开，干活顺手。要是把整个文件柜的几百份文档全倒桌上，你反而找不到要用的那份了。Codex 的上下文窗口就是这张桌子，喂得越精准，它越专注；糊一整个库上去，它反而被无关信息带偏。
管好它，记住三招：
第一招，用 @ 精准喂文件，别让它自己满库瞎找。 你心里清楚改的是哪几个文件，就直接 @ 点出来。它不用花上下文去到处 grep 摸索，又快又准。我那次下午折腾的根因之一，就是我没指文件，它读了七八个不相关的模块才找到该改的地方——那些读进去的内容全占着桌面。
第二招，会话长了就 /compact。 一个会话聊久了，前面的内容会堆很多。/compact 让 Codex 把早期上下文总结压缩成精简版，腾出空间继续干。官方也说了，Codex 会在必要时自动压缩，但你手动 /compact 能在它变笨之前主动清场。
第三招，也是官方反复强调的——一个任务一个会话，别一个会话从早开到晚。 官方「常见错误」里专门点名：用「一个项目一个会话」而不是「一个任务一个会话」，会让上下文越堆越臃肿，结果越来越差。
我现在有条铁律：这个需求做完了，下个不相关的需求，我直接新开会话。 CLI 里相关的几个命令很顺手：
text
/compact 把当前会话的早期上下文压缩成摘要，腾空间
/status 看当前会话状态，包括上下文还剩多少
/fork 基于当前会话另开一条线，保留原始记录
/resume 恢复之前存过的某个会话一条判断原则：上下文该「准」不该「多」。同一个问题就待在同一个会话里，保住推理链条；活儿真分叉了，才 /fork 或新开。
判断标准很简单：还是同一个问题的延续，就留在原会话；换了个不相关的活，就新开一个。 别舍不得那点「历史记录」，臃肿的上下文换来的是更差的结果，不划算。
💡 一句话总结：上下文要准不要多，
@精准喂文件、/compact及时压缩、一个任务一个会话，是管好上下文窗口的三件套。
04 按任务降档：简单活别用旗舰顶配
这一节接上一篇，简单带过——上一篇把模型选择讲透了，这里只补「提速」这个视角。
类比：通勤选交通工具。 楼下买瓶水你不会开车去，走两步就到；跨城出差你也不会骑共享单车。任务的难度，决定该调多大的算力，跟通勤距离决定交通工具一个道理。
具体到操作，就一条原则：简单、范围明确的活，降档跑。 官方「最佳实践」里给的推理强度建议很清楚——
- 范围清楚的快活：用
low，甚至更简单的活可以更低 - 复杂改动、调试：用
medium或high - 又长又重、需要大量推理的活：才上
xhigh
模型层面同理，琐碎活儿、子代理跑的探活，用轻量的 gpt-5.4-mini 就够，没必要事事都搬旗舰 gpt-5.5 出来。改 typo、改个变量名、跑个简单查询，降到 gpt-5.4-mini + low，又快又省信用点。
我自己 ~/.codex/config.toml 里默认就是中档，遇到硬骨头才会在会话里临时往上拨。别学我以前那样把默认锁死 gpt-5.5 + xhigh——改个变量名等它「深思熟虑」一分钟，那种蠢我领教过。 具体怎么配、四种切换姿势，回去翻第 30 篇。
💡 一句话总结：简单活降档跑，
gpt-5.4-mini+low又快又省，把旗舰顶配留给真正的硬骨头。
05 并行起来：多条线同时跑
前面四节都在让单条线跑得更顺。这一节换个维度——别死等一条线跑完，让多条线同时转。
官方「常见错误」里有一条说得很直白：把 Codex 当成一个你得一步步盯着的工具，而不是跟你并行干活的搭子，是新手的典型误区。 你完全可以让它在一边吭哧吭哧重构，你这边继续干别的。
但有个前提坑——别让两条线同时改同一批文件。 它们会互相踩脚，改乱你的工作区。官方给的解法是 git worktrees（工作树），第 25 篇专门讲过。
类比：装修时多工种同时进场。 水电、木工、油漆要同时干，就得各占各的房间，不能挤在同一间互相碰。worktree 就是给每条线分一个独立的「房间」，互不干扰。
并行有两种常见姿势，对应前面讲过的篇目：
| 玩法 | 怎么隔离 | 对应篇目 |
|---|---|---|
| 多个任务同时跑 | 每条线一个 git worktree，各占独立目录 | 第 25 篇 worktrees |
| 主线 + 分包 | 主代理盯核心问题，把探活、测试、排查甩给子代理 | 第 21 篇 subagents |
官方对子代理（subagent）的建议是：让主代理专注核心问题，把那些边界清楚的活——探索代码、写测试、排查问题——甩给子代理去办。 主线不被这些杂活打断，整体就快。
我现在做稍大一点的需求，习惯是：主会话推进核心逻辑，同时另开 worktree 让 Codex 跑一遍测试和 lint。等我主线写完，它那边的检查结果也差不多出来了，两件事并着走，比串着干省一大截时间。
💡 一句话总结：让多条线并行跑，worktree 做隔离、子代理分边界活，但绝不让两条线同时改同一批文件。
06 让它自己验证：砍掉来回确认的轮次
最后一招，也是最容易被忽略、回报却最高的一招——让 Codex 自己验证，别什么都你来肉眼检查。
回到第一节的心法：返工是最大的慢。而你来回确认，本身就是一种慢。 它改完，你打开文件一行行看，发现不对，再说一遍——这一轮轮的人工核对，全是时间。
官方说得很清楚：Codex 在能验证自己工作时产出更好，但前提是它得知道「好」长什么样。这个标准要么来自你的提示词，要么来自项目说明书 AGENTS.md。
类比：交作业前的检查清单。 你给下属派活，附一张「交付前自己核对这五条」的清单，他自查完再交，你只需抽检。要是没清单，全靠你逐行挑错，你就成了瓶颈。给 Codex 验收标准，就是给它这张自查清单。
具体让它自己做这些（来自官方「最佳实践」）：
- 给改动写或更新测试
- 跑对应的测试套件
- 跑 lint、格式化、类型检查
- 确认最终行为跟你要的一致
- 自己 review 一遍 diff，找 bug、回归、危险写法
CLI 里有个 /review 命令很顺手，能按基准分支做 PR 式 review、review 未提交的改动、或者按你给的自定义规则审。
更一劳永逸的做法：把「怎么算做完」「跑哪些测试」写进 AGENTS.md，以后每次它都自动按这套来验，你不用每次在提示词里重复。 这块第 11 篇讲过。
我现在的标准动作是，需求里直接带一句**「改完跑一遍 pytest，全绿再告诉我」**。它跑完测试、确认通过才回来，我省掉了「它说改好了 → 我跑测试 → 发现挂了 → 再让它修」这整整两轮往返。说白了，让它把验证这步包圆，你才能真正从「盯着它」里解放出来。
💡 一句话总结：给验收标准、让 Codex 自己跑测试和 review，能砍掉你来回人工确认的轮次，这是回报最高的提速招。
07 顺带一提：快速模式这类小招
前面六节是骨架，这一节是补充，点到为止。
Codex 有个快速模式（Fast mode），能把支持的模型提速约 1.5 倍，代价是信用点消耗更高。按官方说明，它目前支持 GPT-5.5 和 GPT-5.4，GPT-5.5 用快速模式按标准速率的 2.5 倍扣信用点，GPT-5.4 按 2 倍。
CLI 里用这几个命令开关和查看：
text
/fast on 开启快速模式
/fast off 关闭
/fast status 看当前状态想让它默认开着，可以在 ~/.codex/config.toml 里持久化：
toml
service_tier = "fast"
[features]
fast_mode = true注意两个前提： 一是快速模式靠 ChatGPT 登录才有，用 API key 接入的话走的是标准 API 计价，用不了这个；二是它花的是钱（信用点）换速度，不是免费的。
说句实话，快速模式是「最后一公里」的小招，不是主菜。 前面六节（说清需求、管好上下文、按任务降档、并行、自己验证）省下的时间，是以「轮次」「整段返工」为单位的；快速模式省的是单次响应那 1.5 倍。先把前面六件事做对，再考虑要不要为这点速度多花信用点。 我自己平时不常开，只在赶时间、又确定任务值这个钱的时候临时 /fast on 一下。
💡 一句话总结：快速模式用信用点换 1.5 倍速度，是锦上添花的小招；前六节省的是整段返工，先做对那些再谈这个。
08 动手环节：把一句含糊需求改写成四段式
光看不练记不住。这个练习五分钟，亲手感受「一次过」和「来回返工」的差距。
第一步，找一句你平时会随手敲的含糊需求。 比如：
text
帮我给这个项目加个日志功能第二步，按第 02 节的配方，改写成四段式。 在脑子里（或直接打出来）补全这四个槽位：
text
目标：给项目加一个统一的日志工具，能按 INFO/ERROR 分级输出到控制台和文件。
上下文：参考 @utils/config.py 里读配置的写法，日志级别从配置读。
约束：用标准库 logging，不要引第三方日志库；不改现有任何函数签名。
验收：在 main 入口能 import 并打印一条 INFO 日志到 logs/app.log，文件能正常生成。第三步，把两个版本分别发给 Codex，数轮次。 先开一个会话发含糊版，等它做完（注意它会反问你几个问题、或者自作主张选方案），数一下到你满意一共来回了几轮；再新开一个会话发四段式版，同样数轮次。
预期你会看到：
- 含糊版：Codex 大概率先反问「输出到哪」「要不要分级」「用什么库」，或者直接替你选了一套你未必想要的方案，来回通常 3 轮起步。
- 四段式版：它基本直奔主题，多数 1 到 2 轮就交付，而且交付物更贴你的预期。
这个练习的重点不是某次具体跑了几轮，而是让你亲身体会：多打的那四行字，换回的是后面好几趟来回。 这笔账，永远划算。
做完这个练习，再把你最满意的那套四段式约束、验收习惯，沉淀进 AGENTS.md，以后就不用每次手打了。
💡 一句话总结：亲手把含糊版和四段式版各跑一遍、数数轮次，你会直观看到多打的四行字怎么把返工省下来。
小结
这一篇把「提速」从「换更快的模型」这个误区里拽了出来，落到六件真正省时间的事上：
- 心法：少返工 > 盲目求快，一次做对才是最省时间的快。
- 说清需求：目标 + 上下文 + 约束 + 验收标准，省下的字 Codex 都得替你猜。
- 管上下文：
@精准喂文件、/compact压缩、一个任务一个会话。 - 按任务降档：简单活
gpt-5.4-mini+low，旗舰顶配留给硬骨头。 - 并行起来：worktree 隔离、子代理分活，别让两条线踩同一批文件。
- 自己验证：给验收标准、让它跑测试和 review，砍掉人工来回。
- 快速模式这类小招，锦上添花，先把前面做对再谈。
你现在应该能：拿到一个需求时，先在脑子里过一遍四段式配方而不是张口就甩一句模糊话；会用 @ 和 /compact 把上下文喂得又准又干净；知道简单活该降档、复杂活该并行、所有活都该让 Codex 自己验。把这套养成肌肉记忆，你一天的产出会肉眼可见地往上走——不是因为模型变快了，是因为你不再让它走冤枉路了。
下一篇〔32 从 Claude Code 迁移 〕给一类特定读者：你是从 Claude Code 转过来的老用户。 CLAUDE.md 对应这边的什么？权限模式、Skill、子代理这些概念怎么平移？哪些习惯能直接搬、哪些得改？留个小思考——你在 Claude Code 里养成的哪个习惯，到了 Codex 这边可能反而拖你后腿？下一篇见分晓。