发布于 2026年1月6日

译：以推理速度交付

原文： https://steipete.me/posts/2025/shipping-at-inference-speed
作者： Peter Steinberger
译者： Gemini 3 Pro High

五月以来的变化#

今年“氛围编码（vibe coding）”的发展程度令人难以置信。虽然在五月左右，我还在为某些提示词能开箱即用地生成代码而感到惊讶，但这现在已经成了我的基本预期。我现在交付代码的速度快得不真实。从那时起，我消耗了大量的 Token。是时候更新一下情况了。

这些智能体（Agent）的工作方式很有趣。几周前有一种观点认为，一个人需要亲自写代码才能感受到糟糕的架构，使用智能体会造成脱节——对此我完全不同意。当你花足够多的时间与智能体相处，你会确切地知道某件事应该花多长时间，如果 Codex 返回结果时没有一次性解决问题，我就已经开始怀疑了。

我现在能创建多少软件，主要受限于推理时间和深度思考。老实说——大多数软件并不需要深度思考。大多数应用程序只是将数据从一个表单推送到另一个表单，也许将其存储在某个地方，然后以某种方式展示给用户。最简单的形式是文本，所以默认情况下，无论我想构建什么，它都从 CLI 开始。智能体可以直接调用它并验证输出——从而形成闭环。

模型转变#

真正解锁像工厂一样构建软件的是 GPT 5。发布后我花了几周时间才意识到这一点——等待 Codex 赶上 Claude Code 拥有的功能，并花了一些时间学习和理解它们之间的差异，但随后我开始越来越信任这个模型。这些天我已经不怎么读代码了。 我会看着输出流，有时会查看关键部分，但老实说——大多数代码我都不读。我知道哪些组件在哪里，事物是如何组织的，以及整体系统是如何设计的，通常这就足够了。

现在的关键决策在于语言/生态系统和依赖项。我处理 Web 内容的首选语言是 TypeScript，CLI 用 Go，如果需要使用 macOS 功能或有 UI 则用 Swift。就在几个月前，我甚至完全没考虑过 Go，但最终我试了试，发现智能体非常擅长编写 Go 代码，而且它简单的类型系统使得 Lint 检查非常快。

对于构建 Mac or iOS 应用的朋友：你不再那么需要 Xcode 了。我甚至都不使用 xcodeproj 文件。如今 Swift 的构建基础设施对大多数事情来说已经足够好了。Codex 知道如何运行 iOS 应用程序以及如何处理模拟器。不需要特殊的东西或 MCP。

Codex vs Opus#

我正在写这篇文章的时候，Codex 正在处理一个巨大的、耗时数小时的重构，并清理 Opus 4.0 留下的旧烂摊子。Twitter 上的人经常问我 Opus 和 Codex 之间有什么大区别，既然基准测试如此接近，为什么这很重要。依我看，越来越难以信任基准测试了——你需要亲自尝试两者才能真正理解。无论 OpenAI 在后训练阶段做了什么，Codex 在开始之前已经被训练成会阅读大量的代码。

有时它只是静静地阅读文件 10 到 15 分钟，然后才开始写代码。一方面这很烦人，另一方面这又很棒，因为它大大增加了修复正确问题的几率。另一方面，Opus 更加急切——非常适合小的修改——但不太适合较大的功能或重构，它经常不阅读整个文件或遗漏部分内容，然后交付低效的结果或遗漏某些东西。我注意到，即使 Codex 有时在类似任务上花费的时间是 Opus 的 4 倍，我通常还是更快，因为我不必回头去修复那个修复，这在我还在使用 Claude Code 时感觉是很常态的事情。

Codex 还让我摒弃了许多在使用 Claude Code 时必需的伪装。我不再使用“计划模式”，而是简单地与模型开始对话，提出问题，让它去 Google、探索代码、共同制定计划，当我对我看到的内容感到满意时，我写下“构建”或“将计划写入 docs/*.md 并构建这个”。计划模式感觉像是一种黑客手段，对于旧一代不太擅长遵循提示词的模型来说是必要的，所以我们不得不剥夺它们的编辑工具。有一条被高度误解的推文至今仍在流传，这向我表明大多数人并不明白计划模式并非魔法。

Oracle#

从 GPT 5/5.1 到 5.2 的跨越是巨大的。大约一个月前，我构建了 oracle 🧿——这是一个 CLI，允许智能体运行 GPT 5 Pro 并上传文件 + 提示词，并管理会话以便稍后检索答案。我这样做是因为很多时候当智能体卡住时，我会让它把所有内容写入 markdown 文件，然后自己进行查询，这感觉像是重复的时间浪费——也是一个闭环的机会。说明文件在我的全局 AGENTS.MD 文件中，模型有时会在卡住时自行触发 Oracle。我每天使用它多次。这是一个巨大的解锁。Pro 版本在快速浏览约 50 个网站然后进行深度思考方面做得好得惊人，几乎每次都能给出完美的回答。有时它很快，需要 10 分钟，但我也有过运行超过一个小时的情况。

现在 GPT 5.2 出来了，我需要它的情况少多了。我自己有时会用 Pro 进行研究，但我要求模型“询问 Oracle”的情况从每天多次变成了每周几次。我对此并不生气——构建 Oracle 非常有趣，我学到了很多关于浏览器自动化、Windows 的知识，并最终花时间研究了技能（Skills），此前我曾一度否定这个想法。这确实表明 5.2 在许多现实生活中的编码任务上变得有多好。它几乎能一次性搞定（one-shot） 我扔给它的任何东西。

另一个巨大的胜利是知识截止日期。GPT 5.2 到了 8 月底，而 Opus 停留在 3 月中旬——这大约是 5 个月的差距。当你想要使用最新的可用工具时，这一点非常重要。

一个具体案例：VibeTunnel#

再举一个例子来说明模型已经发展到了什么程度。我早期的一个高强度项目是 VibeTunnel。一个终端复用器，让你可以随时随地编码。今年早些时候，我几乎把所有时间都投入到了这个项目中，2 个月后它变得非常好用，以至于我发现自己在和朋友外出时还在用手机写代码……于是我决定停止这个项目，更多是为了心理健康。当时我试图将复用器的一个核心部分从 TypeScript 重写，但旧模型总是让我失望。我试过 Rust、Go……上帝保佑，甚至试过 Zig。当然我可以完成这个重构，但这需要大量的手工工作，所以我从未在将其搁置之前完成这项工作。上周我把它重新翻出来，给 Codex 一个两句话的提示词，要求将整个转发系统转换为 Zig，它运行了超过 5 个小时，进行了多次压缩，并且一次性交付了一个可工作的转换版本。

你可能会问，我为什么要把它翻出来？我目前的重点是 Clawdis，这是一个 AI 助手，拥有对我所有电脑、消息、邮件、家庭自动化、摄像头、灯光、音乐的完全访问权限，甚至可以控制我床的温度。当然它还有自己的声音、发推特的 CLI 和它自己的 Twitter 账号。

Clawd 可以看到并控制我的屏幕，有时会发表讽刺性的评论，但我也想让它能够检查我的智能体，获取字符流比查看图像要高效得多……这是否行得通，我们拭目以待！

我的工作流#

我知道……你来这里是想学习如何更快地构建，而我只是在为 OpenAI 写营销软文。我希望 Anthropic 正在酝酿 Opus 5，局势能再次逆转。竞争是好事！同时，我爱 Opus 作为通用模型。如果运行在 GPT 5 上，我的 AI 智能体的乐趣会少一半。Opus 有某种特殊的东西，让与之合作成为一种乐趣。我用它来处理我大部分的计算机自动化任务，当然也是它驱动了 Clawd🦞。

自十月份我上次谈论这个问题以来，我的工作流并没有太大改变。

我通常同时在多个项目上工作。根据复杂程度，可能在 3-8 个之间。上下文切换可能会很累人，我真的只能在家里、安静且精神集中的时候这样做。这需要在大脑中切换很多心理模型。幸运的是，大多数软件都很无聊。创建一个 CLI 来检查你的外卖并不需要太多思考。通常我的重点是一个大项目和一些伴随进行的卫星项目。当你做了足够多的智能体工程，你会对什么是容易的、模型可能在哪里挣扎产生一种感觉，所以通常我只是输入一个提示词，Codex 会运行 30 分钟，我就得到了我需要的东西。有时需要一点微调或创造力，但通常事情都很直截了当。
我广泛使用 Codex 的排队功能——当我有新想法时，我把它加入管道。我看到许多人尝试各种多智能体编排系统、电子邮件或自动任务管理——到目前为止，我没看到这有多大必要——通常瓶颈在我自己。我构建软件的方法是非常迭代的。我构建一些东西，玩一下，看看它“感觉”如何，然后获得新想法来改进它。我很少在脑海中对想要的东西有一个完整的图景。当然，我有一个粗略的想法，但随着我探索问题领域，这个想法通常会发生巨大的变化。所以那些以完整的想法作为输入然后交付输出的系统对我来说效果不佳。我需要把玩它，触摸它，感受它，看到它，这就是我演进它的方式。
我基本上从不回滚或使用检查点。如果有些东西我不喜欢，我会要求模型更改它。Codex 有时会重置文件，但通常它只是简单地回滚或修改编辑，我很少需要完全回退，相反我们只是转向不同的方向。构建软件就像登山。你不会直直地走上去，你会绕着它转，转弯，有时你会偏离路径，不得不往回走一点，这并不完美，但最终你会到达你需要去的地方。
我只是简单地提交到 main 分支。有时 Codex 认为太乱了，会自动创建一个 worktree 然后将更改合并回来，但这很少见，我只在特殊情况下提示这样做。我发现必须考虑项目中不同状态的额外认知负担是不必要的，我更喜欢线性地演进它。更大的任务我留到我分心的时候做——例如在写这篇文章时，我在这里运行 4 个项目的重构，每个大约需要 1-2 小时完成。当然我可以在 worktree 中做，但这只会导致大量的合并冲突和次优的重构。警告：我通常独自工作，如果你在更大的团队中工作，这种工作流显然行不通。
我已经提到了我规划功能的方式。我一直在交叉引用项目，特别是如果我知道我已经在其他地方解决了某个问题，我会让 Codex 查看 ../project-folder，这通常足以让它从上下文中推断出在哪里查找。这对于节省提示词非常有用。我可以只写“查看 ../vibetunnel 并为 Sparkle changelogs 做同样的事情”，因为它已经在那里解决了，而且有 99% 的保证它会正确地复制过来并适应新项目。这也是我搭建新项目的方式。
我见过很多系统是为了让人们引用过去的会话。这是另一件我从不需要或使用的东西。我在每个项目的 docs 文件夹中维护子系统和功能的文档，并在我的全局 AGENTS 文件中使用一个脚本 + 一些指令来强制模型阅读关于特定主题的文档。项目越大，回报越高，所以我并非在所有地方都使用它，但这对于保持文档最新和为我的任务设计更好的上下文非常有帮助。
说到上下文。我过去非常勤奋地为新任务重启会话。有了 GPT 5.2，这不再需要了。即使上下文较满，性能也非常好，而且通常这有助于提高速度，因为当模型已经加载了大量文件时，它的工作速度更快。显然，这只有在你串行化任务或保持更改间隔较远以至于两个会话互不影响时才有效。Codex 没有像 Claude Code 那样的“此文件已更改”的系统事件，所以你需要更加小心——反过来说，Codex 在上下文管理方面要好得多，我觉得在一个 Codex 会话中完成的工作量是用 Claude 的 5 倍。这不仅仅是客观上更大的上下文窗口，还有其他因素在起作用。我的猜测是 Codex 内部思维非常精简以节省 Token，而 Opus 非常啰嗦。有时模型会搞砸，其内部思维流会泄露给用户，所以我已经见过好几次了。真的，Codex 的措辞方式我觉得奇怪地有趣。
提示词。我过去常用语音听写写很长、详尽的提示词。有了 Codex，我的提示词变得短了很多，我经常重新打字，而且很多时候我会添加图片，尤其是在迭代 UI（或带有 CLI 的文本副本）时。如果你向模型展示哪里出了问题，只需几个字就足以让它做你想做的事。是的，我就是那种拖入某个 UI 组件的截图并附上“修复填充”或“重新设计”的人，很多时候这要么解决了我的问题，要么让我取得了相当大的进展。我过去常引用 markdown 文件，但有了我的 docs:list 脚本，这不再必要了。
Markdown。很多时候我写“将文档写入 docs/*.md”，然后简单地让模型选择文件名。你为模型训练的内容设计的结构越明显，你的工作就越容易。毕竟，我不是将代码库设计成便于我导航，我是为了让智能体能高效地在其中工作而设计它们。与模型对抗通常是浪费时间和 Token。

工具与基础设施#

==什么依然很难？ 选择正确的依赖项和框架来构建是我投入相当多时间的地方。这个维护得好吗？对等依赖项怎么样？它流行吗 = 是否会有足够的世界知识让智能体轻松上手？同样，系统设计。我们要通过 Web Socket 通信吗？HTML？我把什么放在服务器端，什么放在客户端？数据如何流向哪里？通常这些是向模型解释起来有点难的地方，研究和思考会有回报。==
由于我管理很多项目，通常我让一个智能体简单地在我的项目文件夹中运行，当我找出一个新模式时，我会要求它“找到我所有最近的 Go 项目并在那里也实施此更改 + 更新变更日志”。我的每个项目在那个文件中都有一个提升的补丁版本，当我重新访问它时，一些改进已经在等着我测试了。
当然我自动化一切。有一个 Skill 是注册域名和更改 DNS。一个 Skill 是编写好的前端。我的 AGENTS 文件中有一个关于我的 Tailscale 网络的注释，所以我可以直接说“去我的 Mac Studio 更新 xxx”。
说到多台 Mac。我通常在两台 Mac 上工作。我的 MacBook Pro 在大屏幕上，另一个屏幕上是通过 Jump Desktop 连接到我的 Mac Studio。一些项目在那里运行，一些在这里。有时我在每台机器上编辑同一个项目的不同部分，并通过 git 同步。比 worktree 简单，因为 main 分支上的偏差很容易协调。额外的好处是，任何需要 UI 或浏览器自动化的东西我都可以移到我的 Studio 上，它不会用弹窗打扰我。（是的，Playwright 有无头模式，但有足够多的情况那行不通）
另一个好处是任务保持运行，所以每当我旅行时，远程就成了我的主要工作站，即使我合上 Mac，任务也会继续运行。我过去确实尝试过像 Codex 或 Cursor web 这样真正的异步智能体，但我怀念那种可操控性，而且最终工作结果是拉取请求（PR），这又给我的设置增加了复杂性。我更喜欢终端的简单性。
我过去常玩斜杠命令（slash commands），但从未觉得它们太有用。技能（Skills）取代了其中一部分，对于其余部分，我坚持写“commit/push”，因为它花费的时间与 /commit 相同，而且总是有效。
过去我经常花专门的日子来重构和清理项目，现在我更多是临时做这件事。每当提示词开始耗时太长，或者我看到代码流中有丑陋的东西飞过，我会立即处理它。
我尝试过 Linear 或其他问题追踪器，但没有坚持下来。重要的想法我会立即尝试，其他所有东西我要么记得住，要么它不重要。当然，对于使用我的开源代码的人，我有公开的 bug 追踪器，但当我发现一个 bug 时，我会立即提示它——比写下来然后稍后必须切换上下文回去处理要快得多。
无论你构建什么，首先从模型和 CLI 开始。我脑海中有一个总结 YouTube 视频的 Chrome 扩展的想法已经很久了。上周我开始开发 summarize，这是一个 CLI，可以将任何内容转换为 markdown，然后将其提供给模型进行总结。首先我把核心部分搞定，一旦那个工作得很好，我在一天内构建了整个扩展。我很喜欢它。在本地、免费或付费模型上运行。在本地转录视频或音频。与本地守护进程对话，所以速度超快。试一试！
我首选的模型是 gpt-5.2-codex high。再次强调，KISS 原则。除了慢得多之外，xhigh 几乎没有什么好处，我不想花时间思考不同的模式或“过度思考”。所以几乎所有东西都在 high 上运行。GPT 5.2 和 Codex 足够接近，更改模型没有意义，所以我只用那个。

我的配置#

这是我的 ~/.codex/config.toml：

model = "gpt-5.2-codex"
model_reasoning_effort = "high"
tool_output_token_limit = 25000
# Leave room for native compaction near the 272–273k context window.
# Formula: 273000 - (tool_output_token_limit + 15000)
# With tool_output_token_limit=25000 ⇒ 273000 - (25000 + 15000) = 233000
model_auto_compact_token_limit = 233000
[features]
ghost_commit = false
unified_exec = true
apply_patch_freeform = true
web_search_request = true
skills = true
shell_snapshot = true

[projects."/Users/steipete/Projects"]
trust_level = "trusted"

这允许模型一次读取更多内容，默认值有点小，可能会限制它看到的内容。它会静默失败，这很痛苦，他们最终会修复这个问题。另外，网页搜索仍然默认没开启？unified_exec 取代了 tmux 和我旧的 runner 脚本，其余的也很棒。不要害怕压缩（compaction），自从 OpenAI 切换到他们新的 /compact 端点后，这工作得足够好，任务可以在多次压缩中运行并完成。它会让事情变慢，但通常起到了审查的作用，模型在再次查看代码时会发现 bug。

就这些，暂时。我计划再多写点东西，脑子里积压了很多想法，只是太沉迷于构建东西了。如果你想听到更多关于如何在这个新世界中构建的胡言乱语和想法，在 Twitter 上关注我。