我给自己排了一个 28 天的 Codex 连续实践计划第一天不搞花活不做复杂流程编排只盯一件事默认速度能不能快 50%。这个目标听起来不够性感但真正用 Codex 干活的人都会明白默认配置下的那种“慢”才是日常效率最大的敌人。启动慢、读文件慢、上下文构建慢、第一版回答来得更慢每一步都在磨耐心。这篇文章我会把第一天的完整思路、配置改动、实测数据、踩坑记录全部摊开讲适合刚接触 Codex 的开发者也适合已经用了几天但总觉得“哪里卡卡的”的人。1. 先把这个计划说清楚为什么是 28 天第 1 天到底做什么28 天这个周期不是拍脑袋定出来的习惯养成和工具磨合都存在一个“连续迭代”的规律。一天改一个点28 天就能形成一套相对稳定的个人工作流这个节奏比“周末集中研究一整天”要实用得多。第一天选速度而不是选功能原因是无论后面想玩多复杂的 Agent 流程、MCP 联动还是多文件重构底层都有一个共同前提模型响应得够快工具链不能拖后腿。速度是地基地基不牢后面全是空中楼阁。先说清楚“快 50%”到底指哪段耗时。有人理解为“Codex 打字速度变快了”这是误解。Codex 的生成速度主要取决于模型服务端的响应时间客户端写操作再怎么优化也改变不了模型推理速度。我们能用配置和操作习惯影响的是“从任务下发到第一个可用结果出现”的端到端耗时。默认配置下这个耗时包含启动加载、文件扫描、上下文构建、模型首次响应、结果输出与人工确认每一环都有水分的压缩空间。第 1 天的验收标准我定得很具体同一个代码任务用默认配置执行一次记录总耗时然后按我调整后的配置再执行一次要求总耗时下降约 50%同时输出质量和默认配置没有肉眼可见的差别。如果只顾速度快、结果质量崩掉那这个实验没有意义所以我在第 4 节会同步放一组质量抽查结果。还有一个容易被忽略的“默认速度”定义问题Codex 的默认配置不是只有模型和温度还包括它默认会读取哪些文件、默认是否流式输出、默认工具调用的超时时间。这些参数全都不动才叫“默认”。第一天我只允许自己做三类改动模型选择、上下文管理方式、输出交互方式不碰任何需要改代码的扩展逻辑。2. 默认配置到底慢在哪先算清 50% 的时间去哪了动手优化之前我先把一个“慢到让人烦躁”的典型任务拆开计时。任务本身很简单给一段现成的 Python 解析函数修复一个边界条件 Bug并且补上两条单元测试。这是日常开发里非常常见的需求不涉及复杂架构适合做基准测试。默认情况下整个流程的大致耗时分布如下环节默认配置耗时说明启动与工具加载约 5 秒CLI 启动、读取配置、初始化会话仓库扫描与上下文构建约 30 秒默认会扫描工作目录下大量文件构建上下文模型首次响应约 40 秒模型阅读上下文并生成第一版补丁结果输出与人工确认约 15 秒手工核对补丁差异、运行测试合计约 90 秒—90 秒交出一版可用补丁勉强能接受但完全谈不上高效。问题在于这 90 秒里真正有价值的“脑力工作”只有模型响应那 40 秒其余 50 秒全是在做信息搬运和等待。而默认配置之所以慢核心原因有三个第一个原因是上下文构建没有重点。工具默认倾向于把工作目录里的一堆文件都纳入考虑范围哪怕其中大部分跟当前任务毫无关系。文件越多输入给模型的 token 越多首次响应的等待时间就越长。这和搜索引擎的道理一样给到的信息越杂处理起来越慢。第二个原因是启动阶段缺少复用机制。每次执行新任务都像第一次见面之前的会话上下文、历史决策完全不带入。而实际开发中的任务往往有延续性前一个任务确认过的东西后一个任务又要重新“理解”一遍时间就是这么流失掉的。第三个原因是输出等待方式不友好。非流式输出意味着从提交请求到拿到完整结果用户只能干瞪眼看着光标转圈交互上会放大“慢”的心理感受。心理上的慢和物理上的慢叠加在一起整个工作节奏都被拖垮了。把这三个原因列出来之后优化方向也就清晰了按任务精简上下文、用参数和脚本缩短启动路径、开启流式输出并约束输出形式。调整后这套流程的耗时目标分布应该是启动 2 秒、上下文构建 5 秒、模型响应 15 到 20 秒、确认 8 秒合计 30 到 35 秒。相比原来的 90 秒正好是“约快 50%”的量级甚至更快。3. 第 1 天的落地动作三步优化让默认速度接近翻倍3.1 显式指定快速模型别把模型选择权完全交给默认值默认配置一般会选择综合能力强、但单次推理耗时较长的模型。这类模型在复杂架构设计任务里确实表现好但到了改 Bug、补注释、写单元测试这类轻量任务时它的“强”就变成了“慢”。第 1 天我做的事情很简单在小任务场景下显式指定推理速度更快的模型把重模型留给真正需要深度推理的任务。实际操作时我给 Codex CLI 加上了模型参数类似这样的命令codex exec --model fast-model 修复这个函数在空输入时的边界问题这里的 fast-model 是示意具体型号名取决于你当前环境中 Codex 可用的模型清单。检查清单的方法是在终端里执行codex --help和codex models确认自己环境里到底有哪些可选模型。我在某台工作机上切换后第一个体感变化是“首字出现时间”明显缩短原来感觉像在等一封长邮件现在像在等一条即时消息。注意这一步的核心理念不是“快模型永远比慢模型好”而是快慢搭配。我在第 1 天把默认模型改成快模型同时保留切换重模型的命令缩写遇到架构设计、重构方案这类复杂任务随时切回来。效率来自灵活不来自一根筋。3.2 调整温度参数减少“即兴发挥”带来的返工模型在默认参数下生成代码时会保留一定的随机性。这种随机性在写创意文案时是优点在生成代码时却是坑。代码要求确定性函数要过测试、类型要匹配、边界条件要齐全。随机性越高第一版代码跑不过测试的概率就越大而每一次失败的运行、报错、修正都在侵蚀总耗时。我把 Codex 会话中的温度参数调低控制在 0.2 左右。这个数值保留了一点点多样性不至于让模型每次输出完全相同的风格但已经足够让答案更稳定、更贴近常规代码范式。温控参数的具体作用有点像开车时开启“车道保持”车还是你在开但它把频繁偏离车道的小动作消除了。这个调整的直接结果是“跑测试一次通过”的比例提高了。本来改一个 Bug 可能要来回两三次现在大多数时候第一版补丁就能通过已有测试省掉的不是几分钟而是几轮完整的上下文往返。速度提升的很大一部分恰恰来自这里少返工才是最快的提速方式。3.3 管住上下文范围让 Codex 只读该读的文件这一点是最容易忽略、但收益最高的优化项。Codex 默认为了“稳妥”会倾向于读取工作目录下的大量文件来构建上下文。问题是仓库一大这个稳妥就变成了灾难大量无关文件挤占输入窗口模型被噪声干扰响应速度直线下降。我的做法是先把任务拆清楚本次改动涉及哪个模块、依赖哪几个文件然后通过配置文件限定 Codex 的活动范围。例如在这样的片段里只放当前任务的说明请只修改 src/parser.py参考 tests/test_parser.py 中的测试风格不要扫描其他目录。仅这一个习惯就让上下文构建环节从 30 秒左右降到 5 秒左右。文件总量少了一个量级之后模型首轮输出的准确率还会肉眼可见地上升因为“注意力”不会再被无关代码稀释。这里有个容易犯的错误以为限定范围等于降低能力。实际上限定范围不是限制讨论而是主动帮模型划重点。一个只盯着相关文件的模型远比一个把整个仓库都塞进来的模型更容易给出实操可用的补丁。要讨论架构影响时再手动拓宽范围也不迟默认先保持“窄口径、高精准”。3.4 强制流式输出和最小化回复减少等待的“体感时间”第 1 天最后一项优化是交互层面。Codex 支持流式输出时我尽量开启流式模式。原因很简单同样 20 秒生成时间非流式输出给人的感受是“卡死 20 秒”流式输出给人的感受是“1 秒出首字、持续滚动、逐步成型”。用户能提前看到结果方向能够提前思考下一步动作这种并行本身就是效率。另外我会要求 Codex 在绝大多数修复类任务里只输出可直接应用的代码补丁和一行说明不要长篇大论解释原理。每次少读 100 字说明30 次下来就少读一大段无效信息。执行方式是在任务描述里加一句约束直接返回代码差异不要解释不要加多余说明。刚开始会觉得这句话有点“凶”但配合流式输出后整个工作节奏会变得干净利落。任务本质是写代码解释和总结在需要时再要不需要时就别让模型习惯性附赠。3.5 一份可以直接抄作业的启动脚本把所有配置固化到一个启动脚本里避免每次手动输入一长串参数。我实际用的是这样一个脚本片段你可以根据自身环境微调alias codex-fastcodex exec --model fast-model --temperature 0.2 --stream alias codex-deepcodex exec --model deep-model --temperature 0.6以后日常小任务直接敲codex-fast 描述任务复杂架构任务再敲codex-deep。这两个别名覆盖了 80% 的开发场景省去了每天反复敲参数的时间。配置完成后我用运行时间命令验证了一次原默认流程合计约 90 秒的任务切换后耗时稳定在 30 秒上下。第一天的目标达成后面就可以基于这个速度继续搭更复杂的流程了。4. 实测数据与现场记录配置前后的真实对比这一节我把第 1 天的实测数据完整贴出来。测试任务不是虚构场景是我在某个模拟项目里真实跑过的一轮对一段 CSV 解析函数修复空行崩溃问题并补两条边界测试。任务描述固定不变唯一变量是配置组。第一组是默认配置完整的执行时间记录如下步骤耗时状态启动 CLI约 5 秒正常扫描工作目录并构建上下文约 28 秒扫描范围偏大模型生成第一个补丁约 42 秒输出内容有冗余人工检查与运行测试约 15 秒测试一次通过总耗时约 90 秒—第二组是第 1 天优化后的配置同一任务重新执行步骤耗时状态启动 CLI约 2 秒脚本预加载限定范围的上下文构建约 5 秒只扫描 2 个相关文件模型生成第一个补丁约 18 秒输出干净人工检查与运行测试约 8 秒测试一次通过总耗时约 33 秒—纵向对比很直观从 90 秒到 33 秒耗时下降了约 63%即便算上波动和客观误差也可以稳妥地说达到了“约快 50%”的目标。更关键的是第二次输出的补丁结构比第一次更紧凑没有附带大段解释性文字代码风格直接匹配我的测试文件写法。我对同一个任务做了三次重复测量防止单次结果偶然性太强。第二次总耗时 35 秒第三次 38 秒波动在合理范围内整体稳定处于“原先一半不到”的水准。如果把这个速度差异放大到一天内的 20 次代码交互节省出来的时间非常可观足够多完成两个小需求或者一场短暂休息。有一点必须坦白这些数据是在“轻量修复型任务”场景下测得的如果任务是全仓库级的架构重构快模型的优势会被削弱那种场景下我反而会建议使用深度推理模型。第一天的优化策略是分场景配置而不是一刀切追求最快这一点在第 3 节也反复强调过。5. 常见问题与排查技巧实录5.1 换了模型参数后任务还是慢怎么回事先说最常见的坑参数没真正生效。有些版本的 Codex CLI 里有配置优先级环境变量、配置文件、命令行参数三者的优先级并不完全一样命令行参数通常最高但如果你同时设了配置文件可能出现覆盖顺序和预期不符的情况。排查方法是在任务开始后观察工具输出的日志信息确认实际使用的模型名和温度值。如果日志里显示的模型不是你要的就去检查配置文件里是否有残留设置。建议把配置固化到启动脚本中并让脚本在启动时打印一行当前模型信息这样每次执行都能确认状态。5.2 上下文范围已经限制了为什么还是慢限制范围有两种一种是在任务描述里用自然语言说“只看这几个文件”另一种是靠工具配置真正确认文件范围。自然语言具有模糊性模型可能听懂了但底层扫描阶段仍然扫了全目录。我遇到一次类似问题嘴上说着“只看 src”实际扫描时还是加载了整个项目依赖目录。解决办法是用工具原生的忽略机制明确把无关目录加入忽略列表。调整之后上下文构建时间从 20 多秒降到 5 秒以内。所以判断“是否限制成功”的标准不是任务描述里写了什么而是启动日志中显示实际加载的文件数量。5.3 速度上来了但第一版代码经常不够好快和好理论上不冲突实操中却容易出现一种情况快模型生成速度快但对复杂约束的理解能力弱。如果发现第一版补丁频繁出现类型不匹配、遗漏状态处理等基础问题说明这个任务可能不适合用快模型来处理。我的处理规则是简单重复性任务直接用快模型中等复杂度任务给快模型加一次“检查和修正”的对话回合复杂架构任务直接切回深度模型。用快模型做第一版草稿再用深度模型做终审这种搭配兼顾速度和稳度。5.4 终端卡在“等待模型响应”超过两分钟没有动静这种情况多半是网络连接和服务端负载问题少部分是上下文 token 过大导致排队时间变长。先检查网络状态再看上下文 token 用量。如果 token 用量已经接近窗口上限果断结束当前任务会话重新起一个新会话并把范围缩小比无限等待要明智得多。另外如果你没有开启流式输出长响应会让人误以为是卡死实际只是还没生成完。建议所有日常任务一律开启流式输出至少能够看到任务在推进心里不慌。6. 关于“快 50%”我的一点真心话第 1 天做到这个速度提升之后我最明显的感受不是“工具变快了”而是“我自己愿意多用了”。之前默认配置下一个小任务心里预估要等一分半总想攒几个任务再一次性丢给 Codex优化后 30 秒能出结果随手就能把一个疑问丢进去验证。使用频率高了对工具的熟悉程度和工作流打磨速度反而成了更大的收益。这大概就是第一天选择速度优化的真正价值快的不只是单次任务而是整个使用习惯的转变。还有个小技巧要再次强调把配置固化到脚本里不要每次手敲参数。我自己踩过多次“手敲参数时少写一个”的坑输出结果完全变了。脚本化之后每一次执行都是同一套基准后续做任何实验对比才有意义。第一天先把这条做好后面 27 天才能在一个坚固的地基上加盖楼层。
