我给自己排了一个 28 天的 Codex 实践计划每天只做一个主题。第一天我没有去背更多高级参数反而把所有时间花在“默认模式”上。结果有点出乎意料同样两个改代码的任务完成时间从 120 分钟压到 65 分钟左右换算下来接近“约快 50%”。这篇内容不是给 Codex 的性能做评测也不是什么玄学调参指南而是我第一天实测后整理的三个根因、一组提示词对比、一套可以用来验证“快了 50%”的计时方法。如果你刚接触 Codex或者用了很久但总觉得“它生成本事不差可我怎么越配合越累”这篇应该对你有用。1. 为什么默认模式越用越慢赶走隐性等待才有“约快 50%”的空间1.1 默认工作流的“隐性四步”才是耗时大户很多人觉得 Codex 默认模式慢第一反应是“模型生成太慢”。但我第一天做计时记录时发现真正吃掉时间的不是生成代码本身而是整个默认工作流里的四个隐性步骤理解任务、建立上下文、生成补丁、自检返工。我举一个很常见的场景。假设你想改一个设置页的主题切换逻辑第一句话是“帮我改一下主题切换让它跟随系统”。Codex 默认启动后会先去项目里找相关文件判断这个设置页是什么框架、状态管理在哪、主题变量叫什么。这些步骤看不太见可是它们都在计时。真正开始改代码可能只用了两三分钟但在那之前模型已经花了几十秒甚至更久在“读项目”上。这本身不是问题因为必要的上下文是改对代码的前提。问题在于如果后续需求描述不清Codex 就会反复重新理解、反复补上下文、反复把同一批文件再翻一遍。你看到的现象是“它好像卡住了”“它在原地思考”。这不是模型变笨了而是你的输入方式让它默认工作流多走了好几轮。1.2 默认速度不等于模型速度我第一天得到的一个关键认知是默认速度约快 50%和模型生成 token 的速度关系不大和“往返次数”关系很大。可以把每次对话回合当成一次“下单”。Codex 的每个回合都要做一套完整流程理解自然语言、定位文件、生成补丁、写文件有时还要自己跑测试。你每多补充一句澄清就等于多下了一单每发现一次理解偏差就等于又补了一单。单子越多总时间越长而且不是线性增长——因为每次返工都要把前面的上下文重新载入一遍。所以第一天我真正在做的不是让模型跑得更快而是让模型“少跑几趟”。结果也很直接同样的工作量回合数如果从 4 轮压到 2 轮总时间大约能省一半。也就是标题里“约快 50%”的真正来源。1.3 这 50% 不是白来的它来自三处压缩把时间省下来不是靠某个神奇开关而是靠三个方向的压缩压缩“理解偏差”一开始就把改动范围和验收条件讲清楚减少模型猜错后返工。压缩“上下文重建”指定要改的文件和模块避免默认模式在整个项目里大海捞针。压缩“无效自检”任务结尾给出明确的完成标志让自动检查和修复一次做对。这三个方向都不需要安装插件也不需要改 Codex 的底层配置。第一天做完我把它们整理成了自己的“默认模式使用纪律”后面每个任务都按这套来耗时很稳定地下降。所以如果你想知道“默认速度约快 50%”怎么来的答案不是调参是减少浪费。2. 同一个改页面任务两组提示词实测时间差接近一半2.1 我先用“模糊敬业”的提示词跑了一组对照为了验证“提示方式影响默认速度”我找了一个真实的小任务来测。项目是我本地的一个模拟项目 X里面有一个跨平台系统的设置页界面大概几百行主题状态用前端的状态管理存着。我选了其中一个子任务把设置页的主题切换逻辑改成“跟随系统”。第一组我故意用最“人类天然习惯”的写法帮我把主题切换改成跟随系统。就这么一句话。然后 Codex 的默认工作流开始跑。它先翻项目结构找到设置页文件又看了主题状态文件然后开始改。第一轮生成后它改的是状态读取逻辑但我其实想说的是“默认跟随系统用户手动切换后覆盖系统设置”。因为没讲清楚它只做了一半。然后我开始补第二句“用户手动选的优先级要高。”它又改了一遍这时才把两套逻辑接上。补第三句“系统切换到浅色模式时界面上要立刻更新。”它又补了一轮事件监听。整组任务花了约 120 分钟其中大概三轮都是来回澄清和返工。2.2 第二组换成“带验收条件的结构描述”效果完全不同第二天做另一个等价子任务改造订单列表页的筛选栏布局。我不再甩一句话而是把任务写成一个四段式直接喂给 Codex改动范围只动 OrderList.tsx 和它同目录下的 FilterBar.tsx。 预期行为筛选栏从单行改为双列栅格排序下拉框保留搜索框宽度自适应。 验收条件跑通 npm run build保证两个现有测试用例不被破坏。 第 1 步先看两个文件现有结构再动手改完后简要说明改动点。这一组只用了约 65 分钟而且中间没有出现理解偏差。Codex 第一次生成的补丁就能编译通过又自己跑了测试确认两个用例没问题。对照下来输出质量差不多但时间少了接近一半。2.3 两组数据放在一起看差距不在智商在沟通我不太喜欢“用提示词调教 AI”的说法听起来太玄。但从实测看两组提示词的差别确实很大我整理成表格对比对比项模糊提示组结构化提示组任务内容主题切换跟随系统筛选栏双列改版提示词长度一句话四行说明往返澄清次数3 次0 次Codex 重读文件次数约 4 次约 2 次完成时间约 120 分钟约 65 分钟编译/测试返工有无最终效果可用但中途曲折一次通过差距不在模型能力而在它每次猜我意图的代价。默认工作流本身擅长“按规格施工”但不擅长“读心”。你把规格写得越清楚它跑得越顺利这就是第一天最直接的 50% 提速来源。3. 不用改配置也能提速把默认的上下文、自动修复、小步改动用到位3.1 默认上下文够用别总让 Codex 全仓库巡逻Codex 默认模式有个特点它会根据当前对话内容挑选相关文件作为上下文。这不是“只读文件不读全部”而是它会先构建一个项目索引再按相关性选取。问题是很多人用默认模式时习惯用特别大的措辞比如“帮我把整个模块迁移到新目录”“把这个跨平台系统的所有状态管理统一改掉”。这种描述会逼迫 Codex 把大量无关文件拉进上下文。上下文范围一大文件读取、索引更新、状态同步都变慢而且补丁的边界也不清晰。我第一天的处理办法很简单在提示词里主动指定影响范围宁可多做几次小任务也不要一次性提交一个大而全的需求。一个模块一个模块地改Codex 默认模式的表现会稳定很多。3.2 默认的自动修复循环别轻易打断Codex 默认模式通常不会只生成一次代码就完事它会在写完后自行检查比如跑编译、看报错、再改一轮。这个自动修复循环是默认行为里最有价值的部分也是最考验耐心的地方。许多人看到 Codex 第一次生成的代码有报错会着急打断它手动指出“这里错了改成那样”。这么一弄默认模式反而容易乱了节奏。更好的做法是先让它把自动修复循环跑完再根据最终结果决定要不要继续。实测里自动修复的后续轮次往往能自己解决语法错误、类型错误和一些简单的接口不匹配。你干预太早等于让它多走一圈“重新理解指令”的开销。当然不是所有情况都无脑等它具体什么时候该介入我放在第 5 节说。3.3 默认模式适合和不适合的任务边界第一天我还发现默认模式有明显的擅长区间和不擅长区间提前判断能省很多时间适合默认模式不适合默认模式单个文件内的逻辑修改跨几十个文件的大规模重构修复编译错误、类型错误需要全局架构决策的设计新增一个小功能点需求本身含糊不清的探索性任务按既有代码风格补代码要同时改数据库结构、接口和前端的工作如果你在上表的右半边看到了自己的任务正确做法是先把它拆成左半边那样的小任务再交给 Codex 默认模式。这个拆解动作比任何参数配置都更能提升速度。4. 给“约快 50%”一个可信的算法我的四段计时法与实测数字4.1 不凭感觉把一次编码任务切成四段时间很多人在聊“AI 写代码快不快”的时候只会凭印象说“感觉快了”“感觉没快”。第一天我特意用了一个非常原始的方法来避免感觉误差把一次任务从开始到结束切成四段——理解项目、生成改动、验证结果、返工修正。每一段单独记时间最终加总得到总耗时。具体操作也不复杂准备一个计时表任务开始时点“开始”如果中间我去查文档、回消息那段空白时间不计入。这样做的好处是你可以清楚看到时间到底消耗在哪个环节。第一天我统计下来对照组约 120 分钟里“返工修正”占了将近 50 分钟这一项是最大的黑洞。实验组约 65 分钟里“返工修正”只有不到 10 分钟省下的时间基本就是它。4.2 一天里的实测数字与统计口径下面这组数字来自我对模拟项目 X 的两次任务记录不是实验室基准但也足够说明问题计时片段对照组模糊提示实验组结构化提示理解项目22 分钟12 分钟生成改动28 分钟26 分钟验证结果20 分钟17 分钟返工修正50 分钟10 分钟总耗时120 分钟65 分钟两组任务的代码量差不多复杂度也等同所以对比是有效的。总耗时从 120 分钟降到 65 分钟省了约 46%四舍五入接近 50%。这里面生成改动本身没怎么提速真正快的是“返工修正”的大幅下降。统计口径我也说明一下计时的起点是“我把任务发给 Codex”终点是“代码通过构建且测试通过”。所以我说“约快 50%”指的是从需求到可用结果的整体交付时间不是模型每秒生成的 token 数。4.3 计时法的用途给自己建立反馈而不是得出普适结论我也得说清楚这个 50% 只是一个估计不能代表所有任务。换一个特别简单、本来就没什么歧义的任务比如“改一个按钮颜色”两组可能都快差距不明显。换一个涉及重新设计接口的任务结构化提示也未必能快这么多。但四段计时法的价值在于它能帮你建立自己的反馈。今天做一个任务记一下返工修正花了多少时间明天换了描述方式再记一次。只要返工修正那一栏明显下降你就知道自己的输入方式改对了。持续记录两周后你会对自己和 Codex 默认模式的组合效率有很准确的判断。5. 第 1 天结束后的可复用清单一个模板、三条纪律、三个边界5.1 一份直接能抄的默认模式提示模板第一天实践最大的产出是我总结出来的五要素提示模板。放到项目目录里的一个说明文档中每次要派任务时就套用[改动范围] 只涉及文件 A、文件 B。 不涉及数据库结构、其他模块。 [预期行为] 描述改动后应该有什么表现越具体越好。 [验收条件] 1. 编译通过。 2. 现有测试不破坏。 3. 手动场景xxx。 [步骤约束] 先浏览相关文件结构再动手。一次只改本任务相关代码。 [完成标志] 改完后简短说明每个文件发生了什么变化。这套模板不复杂但它的作用是帮 Codex 默认模式一开始就把上下文锁定在一个合理范围。改动范围管住文件选择预期行为管住方向验收条件管住自检标准步骤约束管住操作顺序完成标志管住收尾。五条下去默认模式会明显“安静”很多不再反复猜需求。5.2 三条默认模式操作纪律除了模板我还给自己定了三条纪律这几天一直在用第一任务发出后不追加模糊指令。如果第一次理解不对宁可重新发一版完整的任务描述不要零散地一句一句补。第二单次任务只碰一个模块。就算整体改动很多也拆成“设置页改完再改订单页”的顺序绝不把多个模块的需求揉进同一个提示词。第三等待自动修复循环结束。除非 Codex 连续两轮还在同一个问题上打转否则先看它自己怎么修。这个“等一等”的耐心给整个工作流省了大量往返时间。5.3 三个边界避免把默认模式用成“慢速模式”第一天我也踩过一些边界这里直接列出来需求模糊到你自己都讲不清时不要硬派任务。先手动整理思路至少列出预期行为和验收条件再交给 Codex。涉及全局架构的改动默认模式不适合一步到位的“重构”。你可以让它做迁移步骤里的一个小环节但不要让它在没有明确架构指令时自己决定全局方案。当改动范围跨到数据库、接口、前端三端时别指望一次对话完成。按层拆成多次任务每次只改一层否则上下文过长后默认模式的速度会明显变慢。这三条边界不是限制而是保护。守住它们默认模式基本都能保持一个比较健康的响应速度。第一天内容到这里就够用了。我的体会是Codex 默认模式默认速度约快 50%这个结果不是它自己发生的而是靠“减少返工、锁定上下文、允许自动修复”换来的。第二天我打算用这套模板去跑一个稍大的功能开发看看拆解粒度再粗一点会不会更稳。如果你在刚接触默认模式时也经常觉得“配合起来很累”可以先从第一节的隐性浪费开始排查别再急着找更复杂的参数。