作者：Peter Steinberger
链接：Shipping at Inference-Speed
日期：2025年12月28日
- 当前的 AI 编码助手已能直接产出可用代码，极大地提升了软件开发的速度。
- GPT-5.2 Codex 在处理大型重构和理解复杂上下文方面，显著优于其主要竞品。
- 高效的工作流应拥抱 AI、简化流程，将重心从编码本身转向系统设计与决策。
自五月以来的变化
“氛围编程”（vibe coding）在今年取得了令人难以置信的进展。大约在五月份时，我对某些提示词能直接生成开箱即用的代码还感到惊讶，而现在这已经成了我的常态。我如今能以一种看似不真实的速度发布代码。从那时起，我烧掉了大量的 token。是时候更新一下心得了。
这些 AI 代理（agent）的工作方式很有趣。几周前曾有这样一个论点：你需要亲手写代码才能感受到糟糕的架构，而使用代理会造成一种脱节感——对此我完全无法苟同。当你与代理相处足够久，你就能准确地知道某项任务应该花多长时间。当 codex 返回结果却没能一次性解决问题时，我就会开始起疑心。
我现在能创造的软件数量，主要受限于推理时间和深度思考。老实说，大多数软件并不需要深度思考。多数应用只是将数据从一种形式转换成另一种，或许存到某个地方，然后以某种方式展示给用户。最简单的形式是文本，所以默认情况下，我想构建的任何东西都从命令行工具（CLI）开始。代理可以直接调用它并验证输出，从而形成闭环。
模型的转变
真正让我实现工厂式开发的关键是 GPT 5。在它发布几周后，我才真正看到其威力——等 codex 赶上了 claude code 的一些功能，也花了一些时间学习和理解它们之间的差异，然后我开始越来越信任这个模型。如今，我已不再大量阅读代码了。 我会观察代码流的生成过程，有时会看一些关键部分，但说实话，大部分代码我都不读。但我清楚各个组件的位置、事物的结构以及整个系统的设计，这通常就足够了。
如今，重要的决策在于语言/生态系统和依赖项。我的首选语言是：用于 Web 开发的 TypeScript，用于 CLI 的 Go，以及在需要使用 macOS 功能或有 UI 界面时的 Swift。就在几个月前，我甚至从未考虑过 Go，但最终我尝试了一下，发现代理非常擅长编写 Go 代码，而且它简单的类型系统使得代码检查（linting）速度飞快。
正在开发 Mac 或 iOS 应用的朋友们：你们不再那么需要 Xcode 了。我甚至都不用 xcodeproj 文件。如今，Swift 的构建基础设施对大多数事情来说已经足够好。codex 知道如何运行 iOS 应用以及如何与模拟器打交道，不需要任何特殊的东西或 MCP。
codex 与 Opus 的对决
我写这篇文章时，codex 正在进行一个巨大的、耗时数小时的重构，清理 Opus 4.0 过去犯下的烂摊子。Twitter 上常有人问我 Opus 和 codex 的主要区别是什么，以及为什么 benchmarks 如此接近，区别却还那么重要。在我看来，现在越来越难相信 benchmarks 了——你需要亲身体验两者才能真正理解。无论 OpenAI 在后训练阶段做了什么，codex 显然被训练过在开始编码前阅读大量代码。
有时它会静默地读取文件 10 到 15 分钟，然后才开始写任何代码。一方面这很烦人，但另一方面这又很了不起，因为它极大地增加了修复正确问题的几率。相比之下，Opus 则急切得多——非常适合小型编辑，但对于大型功能或重构就不那么好了。它常常不会读完整个文件或遗漏部分内容，然后交付低效的成果或有所疏漏。我注意到，尽管 codex 在处理类似任务时花费的时间有时是 Opus 的 4 倍，但我通常反而更快，因为我不需要回去修复那个修复，而在我还在用 Claude Code 时，这感觉是家常便饭。
codex 也让我戒掉了许多 ранее 使用 Claude Code 时必需的“装模作样”。我不再使用“计划模式”，而是直接与模型展开对话，问一个问题，让它去搜索、探索代码，我们一起制定计划。当我满意我所看到的，我就会输入“构建”或“将计划写入 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 在许多实际编程任务上有多大的提升。它几乎能一次性搞定我扔给它的任何事情。
另一个巨大的胜利是知识截止日期。GPT 5.2 的数据截至八月底，而 Opus 还停留在三月中旬——这大约是 5 个月的差距。当你想使用最新的工具时，这个差距就非常显著了。
一个具体案例：VibeTunnel
再给你们举个例子，看看模型进化到了什么程度。我早期的一个高强度项目是 VibeTunnel，一个终端复用器，让你能随时随地编程。今年早些时候，我几乎把所有时间都投入其中，两个月后它已经非常好用，以至于我发现自己和朋友出去玩的时候还在用手机写代码……然后我决定该停下来了，更多是出于心理健康考虑。当时我曾尝试将复用器的核心部分从 TypeScript 重写，但旧模型总是让我失望。我试了 Rust、Go……天晓得，甚至还有 Zig。当然，我本可以完成这个重构，但这需要大量手动工作，所以在我搁置它之前一直没能完成。上周，我把它从尘封中翻了出来，给了 codex 一个只有两句话的提示，让它将整个转发系统转换为 Zig，它运行了超过 5 个小时，经历了多次上下文压缩，并一次性交付了一个可用的转换版本。
你可能会问，我为什么又把它翻出来？我目前的重心是 Clawdis，一个 AI 助手，它拥有对我所有电脑上一切的完全访问权限，包括消息、邮件、家庭自动化、摄像头、灯光、音乐，天哪，它甚至能控制我床的温度。当然，它也有自己的声音、一个发推的 CLI 和它自己的 clawd.bot。
Clawd 能够看到并控制我的屏幕，有时还会发表些俏皮话。但我也想赋予它检查我的代理们的能力，而获取字符流远比看图像高效……至于这是否行得通，我们拭目以待！
我的工作流
我知道……你来这里是想学习如何更快地构建软件，而我却像在为 OpenAI 写营销文案。我希望 Anthropic 正在酝酿 Opus 5，让局势再次逆转。竞争是好事！同时，我非常喜欢 Opus 作为通用模型。如果我的 AI 代理运行在 GPT 5 上，乐趣会减半。Opus 有一种特别的气质，让与之协作成为一种享受。我用它来处理大部分电脑自动化任务，当然它也驱动着 Clawd
。
我的工作流与我十月份的那篇文章相比，变化不大。
- 我通常会同时处理多个项目。根据复杂性，可能是 3 到 8 个。上下文切换可能很累人，我真的只有在家、安静且专注时才能做到。这需要切换大量的心理模型。幸运的是，大多数软件都很普通。创建一个检查你的外卖的 CLI 并不需要太多思考。通常我的重心会放在一个大项目上，同时有一些卫星项目在稳步推进。当你进行足够多的代理辅助工程后，你会对哪些任务容易，哪些模型可能会遇到困难产生一种感觉。所以我常常只是输入一个提示，codex 会处理 30 分钟，然后我就得到了我需要的东西。有时需要一些小调整或创意，但通常都很直接。
- 我广泛使用 codex 的队列功能——每当有新想法，我就会把它加入管道。我看到很多人在试验各种多代理编排系统、邮件或自动任务管理——到目前为止我没看到这方面的太多需求——通常瓶颈是我自己。我构建软件的方式是非常迭代的。我构建一些东西，玩一玩，看看“感觉”如何，然后获得新的想法来完善它。我脑中很少有一幅完整的蓝图。当然，我有一个大致的想法，但随着我探索问题领域，这个想法常常会发生巨大变化。所以那种输入完整想法然后交付输出的系统对我来说效果不好。我需要玩它、触摸它、感受它、看到它，我就是这样让它进化的。
- 我基本上从不回滚或使用检查点。如果有什么地方我不喜欢，我就让模型去改。codex 有时会重置一个文件，但通常它只是撤销或修改编辑，我很少需要完全退回，而是我们一起走向一个不同的方向。构建软件就像登山。你不会直线上升，你会绕着山走，转弯，有时会偏离路径，需要往回走一点，这不完美，但最终你会到达目的地。
- 我直接提交到主分支。有时 codex 觉得太乱了，会自动创建一个工作树（worktree），然后再把更改合并回来，但这很少见，而且我只在特殊情况下才会这样提示。我觉得为项目思考不同状态所增加的认知负担是不必要的，我更喜欢让它线性发展。我会把较大的任务留到我分心的时候做——例如，在写这篇文章时，我正在对 4 个项目进行重构，每个大约需要 1-2 小时才能完成。当然我可以在工作树里做，但这只会导致大量的合并冲突和次优的重构。需要说明的是：我通常是独自工作，如果你在更大的团队里，这种工作流显然行不通。
- 我已经提到了我规划功能的方式。我一直都在交叉引用项目，尤其当我知道我已经在别处解决了某个问题时，我会让 codex 去
../project-folder看看，这通常就足以让它从上下文中推断出该看哪里。这对于节省提示词非常有用。我可以只写“看看 ../vibetunnel，为 Sparkle 的更新日志做同样的事情”，因为它已经在那里解决了，并且有 99% 的把握它会正确地把东西复制过来并适应新项目。我也是这样搭建新项目的脚手架的。 - 我见过很多让人们引用过去会话的系统。这是我从不需要或使用的另一件事。我在每个项目的docs 文件夹中维护子系统和功能的文档，并在我的全局 AGENTS 文件中使用一个脚本和一些指令来强制模型阅读特定主题的文档。项目越大，这种做法的回报就越大，所以我不是到处都用，但它对于保持文档最新和为我的任务构建更好的上下文非常有帮助。
- 说到上下文。我过去非常勤奋地为新任务重启会话。有了 GPT 5.2，这不再需要了。即使上下文很满，性能也非常好，而且通常有助于提高速度，因为模型在加载了大量文件后工作得更快。显然，这只有在你序列化任务或保持更改相隔足够远，以至于两个会话不会太多相互影响时才行得通。codex 没有像 claude code 那样的“此文件已更改”的系统事件，所以你需要更小心——但另一方面，codex 在上下文管理方面要好得多，我感觉在一个 codex 会话中完成的工作量是 claude 的 5 倍。这不仅仅是客观上更大的上下文窗口，还有其他因素在起作用。我猜测 codex 内部的思考非常凝练以节省 token，而 Opus 则非常啰嗦。有时模型会出问题，其内部的思考流会泄露给用户，所以我见过好几次这种情况。说真的，codex 的遣词造句方式我觉得 strangely entertaining（有一种奇怪的娱乐性）。
- 提示词。我过去常用语音听写来写很长、很详细的提示。有了 codex，我的提示词变得短多了，我常常又开始打字了，并且很多时候我会添加图片，尤其是在迭代 UI（或 CLI 的文本副本）时。如果你向模型展示哪里错了，只需几个词就足以让它做你想要的事。是的，我就是那种会拖入一张 UI 组件截图并写上“修复内边距”或“重新设计”的人，很多时候这要么解决了我的问题，要么让我取得了相当大的进展。我过去常常引用 markdown 文件，但有了我的 docs:list 脚本，这也不再必要了。
- Markdowns。我常常写“将文档写入 docs/*.md”，然后让模型自己选一个文件名。你把结构设计得越符合模型的训练数据，你的工作就会越轻松。毕竟，我不是为了方便自己导航而设计代码库，我是为了让代理能在其中高效工作而设计的。与模型对着干通常是浪费时间和 token。
工具与基础设施
- 什么仍然困难？ 选择合适的依赖项和框架是我投入相当多时间的事情。这个维护得好吗？对等依赖项（peer dependencies）怎么样？它流行吗？= 会有足够的“世界知识”让代理轻松上手吗？同样，系统设计也是。我们是通过 web sockets 通信还是 HTML？我该把什么放在服务器，什么放在客户端？数据如何以及从哪里流向哪里？这些通常是比较难向模型解释的事情，也是研究和思考能带来回报的地方。
- 由于我管理着很多项目，我常常让一个代理直接在我的项目文件夹里运行，当我发现一种新模式时，我会让它“找到我所有最近的 go 项目，并在那里也实现这个更改 + 更新更新日志”。我的每个项目在该文件中都有一个递增的补丁版本号，当我重新访问它时，一些改进已经等着我测试了。
- 我当然会自动化一切。有一个注册域名和更改 DNS 的技能。一个编写优秀前端的技能。我的 AGENTS 文件里有一条关于我的 tailscale 网络的注释，所以我可以说“去我的 Mac Studio 更新 xxx”。
- 说到多台 Mac。我通常在两台 Mac 上工作。我的 MacBook Pro 在大屏幕上，另一个屏幕上是连接到我 Mac Studio 的 Jump Desktop 会话。一些项目在那边跑，一些在这边。有时我在每台机器上编辑同一个项目的不同部分，然后通过 git 同步。这比工作树简单，因为主分支上的差异很容易协调。还有一个好处是，任何需要 UI 或浏览器自动化的东西我都可以移到我的 Studio 上，它就不会用弹窗来烦我了。（是的，Playwright 有无头模式，但有很多情况下那行不通）
- 另一个好处是任务可以持续运行，所以无论我何时出差，远程桌面就成了我的主工作站，即使我合上 Mac，任务也会继续运行。我过去曾试验过像 codex 或 Cursor web 这样的真正的异步代理，但我怀念那种可控性，而且最终工作成果会变成一个 pull request，这又给我的设置增加了复杂性。我更喜欢终端的简单性。
- 我曾尝试过斜杠命令，但从没觉得它们特别有用。技能取代了其中一部分，其余的我继续写“commit/push”，因为它花费的时间和
/commit一样，而且总是有效。 - 过去我常常会专门花几天时间来重构和清理项目，现在我更多地是即兴处理。每当提示开始花费太长时间，或者我看到代码流中飞过一些丑陋的东西，我就会立刻处理它。
- 我试过 Linear 或其他问题追踪器，但没有一个能坚持下来。重要的想法我马上就尝试，其他的要么我会记住，要么就不重要。当然，对于使用我开源代码的人们，我有公开的 bug 追踪器，但当我发现一个 bug 时，我会立即用提示词让 AI 修复它——这比把它写下来，然后稍后还要切换上下文回去要快得多。
- 无论你构建什么，都先从模型和 CLI 开始。我很早就想做一个总结 YouTube 视频的 Chrome 扩展。上周我开始开发
summarize，一个将任何东西转换成 markdown 然后喂给模型进行总结的 CLI。我先把核心功能做好了，一旦它运行良好，我花了一天时间就构建了整个扩展。我相当喜欢它。它可以在本地、免费或付费模型上运行。在本地转录视频或音频。与本地守护进程通信，所以速度超快。试试看吧！ - 我的首选模型是 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
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"
这让模型可以一次性读取更多内容，默认值有点小，会限制它能看到的东西。它会静默失败，这很痛苦，他们最终会修复的。还有，Web 搜索默认竟然还不是开启的？unified_exec 取代了 tmux 和我旧的 runner 脚本，其余的也很好。别害怕上下文压缩（compaction），自从 OpenAI 切换到他们新的 /compact 端点后，这东西工作得足够好，任务可以跨越多次压缩并最终完成。这会让事情变慢，但常常像是一次审查，模型在再次审视代码时会发现 bug。
暂时就这些了。我计划再次多写点东西，脑子里积压了不少想法，只是沉迷于 构建东西无法自拔。如果你想听到更多关于如何在这个新世界中构建的杂谈和想法，在 Twitter 上关注我。