译：以推理速度发货
原文：https://steipete.me/posts/2025/shipping-at-inference-speed 翻译官：ChatGPT 5.2
自五月以来发生了什么变化
今年“氛围编码”的进步之大令人难以置信。大约在 5 月的时候，我还惊讶于某些提示词能生成开箱即用的代码，而现在这已经成了我的预期。我现在交付代码的速度快得不真实。从那以后我烧掉了大量 token。是时候更新一下了。
这些代理的工作方式真有意思。几周前有人争论说，人必须亲自写代码才能感受到糟糕的架构，而使用代理会造成一种脱节——对此我完全不同意。当你和代理相处得足够久，你就会非常清楚某件事应该花多长时间；而当 Codex 回来却没能一次就解决时，我就已经开始起疑了。
我现在能编写的软件数量主要受限于推理时间和深入思考。但说实话——大多数软件并不需要深入思考。大多数应用只是把数据从一种形式搬到另一种形式，可能存到某个地方，然后以某种方式展示给用户。最简单的形式是文本，所以默认情况下，无论我想做什么，它都从 CLI 开始。智能体可以直接调用它并验证输出——形成闭环。
模型转变
真正让我解锁像工厂一样构建的是 GPT 5。它发布后我花了几周才意识到这一点——也等了一段时间让 codex 在功能上追上 claude code，再花点时间学习并理解差异；但之后我开始越来越信任这个模型。**如今我几乎不怎么读代码了。**我会看着流式输出，有时也会查看关键部分，但说实话——大多数代码我都不读。我确实知道各个组件分别在哪里、事情是如何组织的，以及整个系统的设计方式，而这通常就足够了。
如今重要的决策是语言/生态系统和依赖。我首选的语言是：做 Web 用 TypeScript，做 CLI 用 Go，如果需要用到 macOS 的东西或有 UI 就用 Swift。几个月前我甚至一点都没考虑过 Go，但后来我试着折腾了一下，发现智能体特别擅长写它，而且它简单的类型系统让 lint 变得很快。
正在开发 Mac 或 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 时不得不做的“装腔作势”。我不再使用“计划模式”，而是直接与模型开始对话：提个问题，让它去谷歌、探索代码、一起制定计划；当我对看到的内容满意时，我就写“build”或“write plan to docs/*.md and build this”。计划模式感觉像是一种权宜之计——这是为早期那些不太擅长遵循提示的模型所必须的，所以我们不得不拿走它们的编辑工具。还有一条被严重误解、至今仍在流传的我的推文，它让我意识到大多数人并不明白计划模式并不是什么魔法。
Oracle
从 GPT 5/5.1 到 5.2 的跃迁非常巨大。我大约一个月前做了 oracle 🧿——这是一个 CLI，允许智能体运行 GPT 5 Pro，并上传文件 + 提示词，同时管理会话，以便之后可以取回答案。我这么做是因为很多时候智能体卡住时，我会让它把所有内容写进一个 markdown 文件，然后我自己再去查询，这感觉就是重复性的时间浪费——也是一个把闭环补上的机会。使用说明在 我的全局 AGENTS.MD 文件里，而且模型有时在卡住时会自己触发 oracle。我每天会用它好多次。这是一次巨大的解锁。Pro 擅长以“速通”的方式扫过大约 50 个网站，然后非常认真地思考，几乎每次都能把回答做对。有时它很快，只要 10 分钟，但我也遇到过跑了超过一小时的情况。
现在 GPT 5.2 已经发布，我需要它的情况少了很多。我自己有时会用 Pro 来做研究，但让我让模型“去问神谕”的次数，从每天多次变成了每周几次。我对此并不生气——构建 oracle 非常有趣，我学到了很多关于浏览器自动化和 Windows 的东西，也终于花时间去研究 skills，此前我相当长一段时间都把这个想法搁置了。这确实表明 5.2 在许多真实世界的编程任务上进步了多少。它对我抛给它的几乎任何东西都能一次搞定。
另一个巨大的优势是知识截止日期。GPT 5.2 一直到 8 月底，而 Opus 还停留在 3 月中旬——相差大约 5 个月。当你想使用最新可用的工具时，这一点非常重要。
一个具体示例：VibeTunnel
再给你一个例子，说明模型已经进步到了什么程度。我早期一个投入很深的项目是 VibeTunnel。它是一个终端复用器，让你可以随时随地写代码。今年早些时候我几乎把所有时间都投入到它上面，做了两个月后它好到让我在和朋友外出时都忍不住用手机写代码……然后我决定应该停下来，这更多是出于心理健康方面的考虑。那时候我尝试把复用器的一个核心部分从 TypeScript 重写出去，但旧模型总是搞不定。我试了 Rust、Go……天啊，甚至 zig。当然我本可以把这次重构做完，但它需要大量手工工作，所以在我把它搁置之前一直没能完成。上周我把它从灰尘里翻出来，只给 codex 一个两句话的提示，让它把整个转发系统转换成 zig，它跑了 5 个多小时，经历了多次压缩整理，一次性就交付了可用的转换结果。
你问我为什么还要把它从灰尘里翻出来？我目前的重心是 Clawdis，一个对我所有电脑上的一切都拥有完全访问权限的 AI 助手，还能访问消息、邮件、家庭自动化、摄像头、灯光、音乐，见鬼，它甚至还能控制我床的温度。当然，它也有自己的声音、一个用于发推的 CLI，以及自己的 Twitter 账号。
Clawd 可以看到并控制我的屏幕，有时还会说些刻薄话，但我也想让他具备查看我的智能体的能力，而获取角色流比查看图片要高效得多……这是否能行得通，我们拭目以待！
我的工作流程
我知道……你来这里是想学习如何更快地构建，而我却只是在给 OpenAI 写一段营销推介。我希望 Anthropic 正在打造 Opus 5，让潮水再次转向。竞争是好事！与此同时，我很喜欢 Opus 作为通用模型。我的 AI 代理如果跑在 GPT 5 上，乐趣恐怕连一半都没有。Opus 有某种特别之处，让人用起来很愉快。我把它用于大多数电脑自动化任务，当然 Clawd🦞 也是由它驱动的。
自从我在十月上一次写到这件事以来，我的工作流程并没有太大变化。
1）我通常会同时推进多个项目。根据复杂程度，可能在 3 到 8 个之间。频繁切换上下文会很累，我真的只能在家工作、安静且专注的时候才做得到。这需要在脑中来回切换很多心智模型。好在大多数软件都很无聊。做一个 CLI 来查看你的外卖配送状态并不需要想太多。通常我会把重心放在一个大项目上，旁边还有一些按部就班推进的卫星项目。当你做了足够多的智能体工程，就会对哪些事情很容易、模型可能会在哪些地方卡住形成直觉，所以我常常只要写个提示，Codex 就会跑上 30 分钟，然后我就能得到我需要的东西。有时需要稍微调一调或发挥点创造力，但很多时候都很直接。
2）我大量使用 codex 的队列功能——一有新点子，我就把它加到流水线里。我看到很多人在尝试各种多智能体编排系统、邮件或自动化任务管理——到目前为止我觉得没太大必要——通常瓶颈在我。我的软件构建方式非常迭代。我做点东西，玩一玩，看看“感觉”如何，然后就会有新想法去完善它。我脑子里很少会有一个完整的目标蓝图。当然，我会有个大概方向，但在探索问题领域的过程中，它往往会发生巨大的变化。所以，那些把完整想法作为输入然后输出结果的系统并不适合我。我需要去把玩它、触摸它、感受它、看见它——我就是这样让它不断演进的。
3）我基本上从不回退或使用检查点。如果有些东西不是我喜欢的样子，我就让模型去改。Codex 有时会重置一个文件，但更多时候它只是撤销或修改这些编辑；我很少需要完全退回去，而是我们会转向不同的方向。构建软件就像爬山。你不会直直往上爬，而是绕着山转、不断转弯；有时你会偏离路径，不得不往回走一小段。这并不完美，但最终你会到达你需要去的地方。
4）我就是直接提交到 main。有时候 codex 觉得太乱了，会自动创建一个 worktree，然后再把改动合并回去，但这种情况很少，我也只会在极少数例外情况下才会提示它这么做。我发现在项目里不得不去考虑不同状态会带来额外的认知负担，没有必要，我更喜欢按线性方式推进。更大的任务我会留到我分心的时候做——比如写这段话的同时，我在这里对 4 个项目跑重构，每个大概需要 1-2 小时才能完成。当然我也可以在 worktree 里做，但那只会导致大量合并冲突和不够理想的重构。注意：我通常是一个人工作，如果你在更大的团队里，这种工作流显然行不通。
5）我已经提到过我规划一个功能的方式。我一直在交叉参考项目，尤其是当我知道自己已经在别处解决过某个问题时，我会让 Codex 去查看 ../project-folder，这通常就足够让它从上下文推断出该去哪里找。这对于节省提示词非常有用。我只需要写“看看 ../vibetunnel，然后对 Sparkle 的变更日志做同样的事”，因为那边已经解决了，而且有 99% 的把握它会正确地把东西复制过来并适配到新项目。我也是这样来搭建新项目脚手架的。
6）我见过不少系统是给那些想要引用过去会话的人用的。另一件我从不需要也从不用的东西。我会在每个项目的 docs 文件夹 里为各个子系统和功能维护文档，并在我的全局 AGENTS 文件里使用 一个脚本 + 一些说明 来强制模型在某些主题上阅读文档。项目越大，这种做法的回报越高，所以我不会到处都用，但它对保持文档最新、并为我的任务构建更好的上下文非常有帮助。
7）说到上下文。我以前在开始新任务时会非常勤快地重启一个会话。有了 GPT 5.2 之后，这就不再需要了。即使上下文更满，性能也极其出色，而且往往还能提升速度，因为当模型已经加载了大量文件时运行会更快。显然，这只有在你把任务串行化，或者让改动彼此相隔足够远、以至于两个会话几乎不会互相影响时才行。codex 不像 claude code 那样有“这个文件变更了”的系统事件，所以你需要更小心——但反过来说，我感觉 codex 在上下文管理上就是好得多，我觉得用一个 codex 会话能完成的工作量是用 claude 的 5 倍。这不仅仅是客观上更大的上下文窗口，还有别的因素在起作用。我猜 codex 在内部会把思考压得非常精炼以节省 token，而 Opus 则非常啰嗦。有时模型会出错，它的内部思考流会泄露给用户，所以我见过这种情况好几次。说真的，codex 很会遣词造句，我觉得这有种奇怪的娱乐性。
8）提示词。我以前会用语音输入写很长、很精心的提示词。用了 Codex 之后，我的 提示词变得短了很多，我经常会重新打字，而且很多时候我会添加图片，尤其是在迭代 UI（或者用 CLI 处理文案文本）时。如果你把哪里不对给模型看清楚，只需要几个词就足以让它按你的想法去做。没错，我就是那种会拖进一张截取的 UI 组件图片，然后写上“修复内边距”或“重新设计”的人；很多时候这要么就解决了我的问题，要么也能把我推进到一个相当不错的程度。我以前会引用 markdown 文件，但有了我的 docs:list 脚本之后，就不再需要了。
9）Markdown 文件。很多时候我会写“把文档写到 docs/*.md”，然后干脆让模型自己挑一个文件名。你为模型所训练的内容把结构设计得越直观，你的工作就会越轻松。毕竟，我设计代码库不是为了让自己好导航，而是把它们工程化成让智能体能在其中高效工作的样子。与模型对抗往往是在浪费时间和 token。
工具与基础设施
1） 还有什么仍然很难？ 选择合适的依赖和要采用的框架这件事，我会投入相当多的时间。它维护得好吗？同级依赖怎么样？它流行吗——也就意味着会有足够的世界知识，让智能体更容易上手吗？同样还有系统设计。我们要通过 WebSocket 通信吗？还是 HTML？哪些放在服务器端，哪些放在客户端？数据如何以及通过哪些方式在不同部分之间流动、从哪里到哪里？这些往往是更难向模型解释的事情，而在这方面做研究和深入思考是值得的。
2） 由于我管理着很多项目，我经常让一个代理直接在我的项目文件夹里运行；当我摸索出一种新的模式时，我就让它“找出我最近的所有 Go 项目，并把这个改动也在那些项目里实现 + 更新变更日志”。我的每个项目在那个文件里都会把补丁版本号提高；当我回头再看时，往往已经有一些改进在等着我去测试了。
3） 当然，我会把一切都自动化。注册域名和修改 DNS 是一项技能。编写优秀的前端也是一项技能。我的 AGENTS 文件里有一条关于我的 Tailscale 网络的备注，所以我只要说“去我的 Mac Studio 并更新 xxx”。
4） 顺便说一下关于多台 Mac这事。我通常在两台 Mac 上工作：大屏上用我的 MacBook Pro，另一个屏幕上通过 Jump Desktop 连接到我的 Mac Studio。有些项目在那边跑着，有些在这边弄着。有时我会在每台机器上编辑同一个项目的不同部分，然后通过 git 同步。比起 worktree 更简单，因为 main 上的偏移很容易对齐。还有个额外好处是，凡是需要 UI 或浏览器自动化的东西，我都可以挪到 Studio 上跑，它弹出的各种窗口也不会烦到我。（是的，Playwright 有无头模式，但有不少情况下它就是不管用）
5） 另一个好处是任务会在那边持续运行，所以每当我旅行时，远程端就成了我的主工作站，即使我合上 Mac，任务也会继续跑。我过去确实试过像 codex 或 Cursor Web 这样的真正异步代理，但我怀念那种可控性，而且最终工作还是会以拉取请求的形式结束，这又给我的配置增加了复杂度。我更喜欢终端的简单直接。
6） 我以前玩过斜杠命令，但一直没觉得它们有多大用处。技能替代了其中一部分，至于剩下的，我一直写“commit/push”，因为这和输入 /commit 花的时间一样，而且总是能用。
7） 过去我经常专门抽出几天来对项目进行重构和清理，但现在我更多是临时顺手做。每当提示开始耗时太久，或者我在代码流里看到有什么丑陋的东西一闪而过，我就会立刻处理。
8） 我试过 Linear 或其他问题跟踪器，但都没能坚持用下去。重要的想法我会立刻去做，其他的要么我会记得，要么就不重要。当然，我为使用我开源代码的人提供了公开的 bug 跟踪器，但当我发现一个 bug 时，我会立刻把它处理掉——这比先写下来、然后以后再切换回那个上下文要快得多。
9） 无论你要做什么，先从模型和 CLI 开始。我脑子里一直有个想法：做一个用于总结 YouTube 视频的 Chrome 扩展。上周我开始做 summarize，一个 CLI：它把任何内容转换成 markdown，然后把它交给模型做摘要。我先把核心打磨正确，一旦跑得很棒，我就在一天内把整个扩展做出来了。我非常喜欢它。可在本地运行，支持免费或付费模型。在本地转录视频或音频。与本地守护进程通信，因此速度超级快。去试试吧！
10） 我首选的模型是 gpt-5.2-codex high。还是那句话，KISS。除了速度慢得多之外，xhigh 几乎没什么额外好处，而且我不想花时间去琢磨不同模式或“ultrathink”。所以基本上所有东西都跑在 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脚本，rest 也很整洁。而且别害怕压缩，自从 OpenAI 切换到他们新的 /compact 端点后，这个方案运行得足够好，任务可以跨多个压缩继续执行并最终完成。它会让进度变慢，但往往相当于一次复查，模型在再次查看代码时会发现 bug。
就先写到这里吧。我打算再多写一些，脑子里也积了不少点子，只是玩得太开心，一直在做东西。如果你想听更多碎碎念以及关于如何在这个新世界里构建的想法，在 Twitter 上关注我。
此文自动发布于：github issues