企业官网建设流程全解析

我给自己排了一个 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”的说法，听起来太玄。但从实测看，两组提示词的差别确实很大，我整理成表格对比：

差距不在模型能力，而在它每次猜我意图的代价。默认工作流本身擅长“按规格施工”，但不擅长“读心”。你把规格写得越清楚，它跑得越顺利，这就是第一天最直接的 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 的两次任务记录，不是实验室基准，但也足够说明问题：

两组任务的代码量差不多，复杂度也等同，所以对比是有效的。总耗时从 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%，这个结果不是它自己发生的，而是靠“减少返工、锁定上下文、允许自动修复”换来的。第二天我打算用这套模板去跑一个稍大的功能开发，看看拆解粒度再粗一点会不会更稳。如果你在刚接触默认模式时也经常觉得“配合起来很累”，可以先从第一节的隐性浪费开始排查，别再急着找更复杂的参数。