过去两个月，最出圈的开发者事件无疑是 OpenClaw/Clawdbot 的爆火，其创始人 Peter Steinberger 在受到多家巨头争抢后，最终选择加入了 OpenAI。
在翻看他关于加入 OpenAI 的官方声明时，我偶然发现他还有一个更新频率“非常”不固定的个人博客。就在官宣加入 OpenAI 的那篇博文之前，他发布了一篇关于自己 Vibe Coding 实践经验的总结，内容涵盖了顶级模型如何选择、如何提交Git分支、如何进行迭代和重构等核心“心法”。这篇博客发布在 OpenClaw/Clawdbot 爆火之前，其价值因此显得更为独特。
尽管时隔两月，最顶级的模型已经迭代到了 GPT-5.3-Codex 和 Opus 4.6，但根据我个人的实践经验，Peter 在这篇博客中分享的绝大多数内容至今依然适用。更让我庆幸的是，我发现自己的很多 Vibe Coding 习惯与这位大神不谋而合。他在近期的一些播客访谈中也延续了相同的观点，其中或许也埋藏了他最终选择加入 OpenAI 的种子。
对于每一位投身于 AI编程 浪潮的开发者而言，这篇来自一线实践者的深度分享不容错过。
作者：Peter Steinberger
发布日期：2025 年 12 月 28 日（此文发布于OpenClaw/Clawdbot爆火之前）
阅读时长：18 分钟
原文：steipete.me/posts/2025/shipping-at-inference-speed
自（2025年）五月以来的变化
“氛围编程”（Vibe Coding）在今年取得的进步是惊人的。大概五月份的时候，我还会为有些提示词能生成可直接运行的代码而感到惊讶，但现在这已经是我对日常工作的正常预期了。我能以一种看起来不太真实的速度交付代码。从那以后，我消耗了大量的 token，现在是时候更新一下博客了。
关于 AI Agent 的工作方式，存在一个有趣的争论：有人认为开发者需要亲自写代码才能体会到糟糕的架构设计，而使用 Agent 会产生一种脱节感。对此，我完全不同意。当你和 Agent 协同工作足够长时间后，你就能精准地预判某件事应该花费多久。所以，当 Codex 返回了结果却没有一次性解决问题时，我反而会起疑心。
目前，我创造软件的速度主要受限于模型的推理时间和深度思考。坦率地说——大多数软件并不需要深度思考。大多数应用就是把数据从一个表单推到另一个表单，可能存储在某个地方，然后用某种方式展示给用户。最简单的形式就是文本，因此，无论我想构建什么，默认都会从 CLI（命令行界面）开始。Agent 可以直接调用它并验证输出，从而形成一个高效的闭环。
模型的转变
真正解锁我像工厂一样批量构建软件能力的，是 GPT-5 模型。发布后我花了几周时间才完全意识到这一点——Codex 需要追赶 Claude Code 已有的能力，也需要一些时间来学习和理解差异。但在那之后，我开始越来越信任这个模型。
如今，我已经不太阅读代码了。我看着代码流式生成，偶尔审视关键部分，但说实话——大多数代码我是不读的。我清楚哪些组件在哪里、事情是如何组织的、整体系统是如何设计的，而这通常就足够了。
如今，关键的决策在于语言/生态系统和依赖的选择。我的首选语言组合是：Web 项目用 TypeScript，CLI 用 Go，如果需要用到 macOS 原生特性或有 UI 需求就用 Swift。Go 是几个月前我丝毫不会考虑的语言，但在尝试之后，我发现 Agent 非常擅长编写它，而且其简单的类型系统让代码检查和排错变得很快。
正在构建 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 工具，允许 Agent 运行 GPT-5 Pro 模型，上传文件和提示，并管理会话以便后续检索答案。
我这样做是因为，很多时候当 Agent 卡住时，我会让它把所有内容写进一个 markdown 文件，然后我自己去查询。这感觉像是重复浪费时间的步骤，也是一个实现自动化闭环的机会。相关指令放在我的全局 AGENTS.MD 文件中，模型有时在卡住时会自己触发 Oracle。我每天都会使用它好几次。这是一个巨大的能力解锁。
Pro 模型在快速浏览约 50 个网站并进行深入思考方面表现得极其出色，几乎在每种情况下都能找到正确答案。有时很快，只需 10 分钟，但我也遇到过运行超过一个小时的情况。
现在 GPT-5.2 发布了，我需要用到 Oracle 的场景少了很多。我自己确实有时会用 Pro 做研究，但我让模型“问 Oracle”的频率已经从每天多次降到了每周几次。我对此并不感到遗憾——构建 Oracle 的过程超级有趣，我学到了很多关于浏览器自动化、Windows 的知识，最后终于花时间研究了 Skills（技能）——这个想法我之前曾相当长时间地拒绝过。它也展示了 5.2 模型对于许多现实世界的编码任务变得有多好。它几乎能一发入魂地解决我抛给它的任何问题。
另一个巨大的胜利是知识截止日期。GPT-5.2 的知识截止到 8 月底，而 Opus 卡在 3 月中旬——相差了大约 5 个月。当你想使用最新的可用工具或库时，这一点至关重要。
一个具体例子：VibeTunnel
再举一个例子，说明模型进步了多少。我早期的一个高强度项目是 VibeTunnel，一个终端多路复用器，让你可以在外出时编码。今年早些时候我几乎把所有时间都投入其中，两个月后它变得太好用了，以至于我发现自己和朋友外出时在用手机编码……然后我决定应该停止这样做，更多是出于心理健康而非其他原因。
当时，我试图将多路复用器的核心部分从 TypeScript 中重写出来，老模型 consistently 让我失望。我尝试过 Rust、Go……天哪，甚至 Zig。当然，我本可以完成这个重构，但这需要大量的手工工作，所以在我搁置它之前一直没完成。上周，我把它从“灰尘”中捞出来，给了 Codex 一个两句话的提示，要求它将整个转发系统转换成 Zig。它运行了 5 个多小时，经过多次（上下文）压缩，一次性交付了一个可用的转换版本。
你问我为什么要把它从“灰尘”中捞出来？我目前的重点是 Clawdis（译者注：OpenClaw 的前身），这是一个在我所有电脑上拥有完全访问权限的 AI 助手，包括消息、邮件、家庭自动化、摄像头、灯光、音乐，见鬼，它甚至能控制我床的温度。当然，它还有自己的声音、一个用来发推的 CLI 和自己的 clawd.bot。
Clawd 能看到并控制我的屏幕，有时会说些刻薄的话，但我也想让它有能力检查我的其他 Agent，而获取字符流比看图片效率高得多……这是否可行，我们拭目以待！
我的工作流
我知道……你读到这里是为了学习如何更快地构建，而我（看上去）只是在写 OpenAI 的营销文案。我希望 Anthropic 正在酝酿 Opus-5，让竞争局势再次变得有趣。竞争是好事！同时，我爱 Opus 作为通用模型。我的 AI Agent 如果运行在 GPT-5 上，不会有一半这么有趣。Opus 有一些特别的东西让它用起来很愉悦。我用它来处理大部分电脑自动化任务，当然，它也驱动着 Clawd🦞。
我的工作流程和去年 10 月我上次分享时相比，没有太大变化。
- 多项目并行：我通常同时处理多个项目。根据复杂程度，可能是 3 到 8 个。上下文切换可能会很累，我真的只有在家工作、环境安静且能高度专注的时候才能这样做。幸运的是，大多数软件都很“无聊”。创建一个检查外卖配送状态的 CLI 不需要太多思考。通常，我的焦点是一个大项目加上几个同步推进的卫星项目。当你做了足够多的 Agent 工程，你就会对什么东西会很简单、模型可能会在哪里挣扎产生直觉。所以，经常我只是丢进去一个提示，Codex 就会埋头干上 30 分钟，然后我就得到了我需要的东西。有时需要一点调整或创造力，但大多数事情都很直接。
- 广泛使用队列：我广泛使用 Codex 的队列功能——当我有新想法时，就把它加到流水线里。我看到很多人在实验各种多 Agent 编排系统、邮件或自动任务管理——目前我不太觉得有这需要——通常我自己才是瓶颈。我构建软件的方式是快速迭代的。我构建东西，玩一玩，看看它“感觉”如何，然后得到新的想法来完善它。我很少在脑子里有完整的图景。 当然，我有一个大致想法，但通常随着我探索问题领域，这个想法会发生剧烈变化。所以，那些把完整想法作为输入然后期望交付完整输出的系统，对我来说不太好用（译者注：这里指的是 Spec-Driven 的开发模式和相应的 Agents）。我需要玩它、摸它、感受它、看见它，这就是我让软件演进的方式。
- 极少回滚：我基本上从来不回滚或使用 Git 检查点。如果某件事的实现方式我不喜欢，我就让模型修改它。Codex 有时会重置一个文件，但更多时候它只是撤销或修改编辑，很少需要完全回退。相反，我们只是换了个方向前进。构建软件就像爬山。你不会直直地往上走，你会绕着山走、转弯，有时候你会偏离路径不得不往回走一点，这不完美，但最终你会到达你需要去的地方。
- 直接提交到 main：我只是直接提交到 main 分支。有时 Codex 觉得改动太乱会自动创建一个 worktree（工作树），然后把改动合并回来，但这很少见，我只在特殊情况下才会提示它这样做。我觉得必须在脑中思考项目中不同分支状态的额外认知负担是不必要的，我更愿意线性地演进它。更大的任务我会留到分心的时候做——比如写这篇文章的时候，我在这里对 4 个项目运行重构，每个大概要花 1 到 2 小时完成。当然我可以在 worktree 里做，但那只会造成大量的合并冲突和次优的重构。注意事项：我通常一个人工作，如果你在更大的团队，那这套工作流显然行不通。
- 跨项目引用：我已经提到过我规划功能的方式。我经常跨项目引用，特别是如果我知道已经在别的地方解决了某个问题，我会让 Codex 去看
../project-folder，这通常足够让它从上下文中推断出该看哪里。这对节省提示词非常有用。我可以直接写 “look at ../vibetunnel and do the same for Sparkle changelogs”， 因为它已经在那里解决了，有 99% 的把握它会正确地复制过来并适应新项目。我也是这样搭建新项目的。
- 维护项目文档：我见过很多人用来引用过去会话的系统。这是另一件我从来不需要或使用的东西。我在每个项目的 docs 文件夹里维护子系统和功能的文档，并使用一个脚本加上一些指令（在我的全局
AGENTS 文件中）来强制模型在需要时阅读某些主题的文档。项目越大，这样做越值得，所以我不在所有地方都用它，但它对保持文档更新和为任务设计更好的上下文有很大帮助。
- 会话管理：说到上下文。我曾经非常勤奋地为新任务重启会话。有了 GPT-5.2，这就不再需要了。 即使上下文更满，性能也非常好，而且通常在速度上有帮助，因为当模型已经加载了大量文件时它工作得更快。显然，这只有在你序列化你的任务或让目前的改动保持足够分散，以至于两个任务不太会互相触碰时才有效。Codex 没有像 Claude Code 那样的“这个文件改了”的系统事件，所以你需要更小心——但另一方面，Codex 在上下文管理方面要好得多，我觉得在一个 Codex 会话中能完成的事情是在 Claude 中的 5 倍。 这不仅仅是客观上更大的上下文尺寸，还有其他东西在起作用。我的猜测是 Codex 内部思考得非常浓缩以节省 token，而 Opus 非常“啰嗦”。有时模型会搞砸，它的内部思考流泄露给用户，我有好几次看到这个。说真的，Codex 有它自己的说话方式，我觉得莫名地有娱乐性。
- 提示词风格：提示词。我曾经用语音输入写很长、很详细的提示词。使用 Codex 后，我的提示词变得短多了，我经常打字，很多时候我会添加图片，特别是在迭代 UI（或使用 CLI 时的文本复制）时。如果你给模型展示什么是错的，只需要几个词就足够让它做你想做的事。是的，我就是那种拖一张 UI 组件的截图进去说 “fix padding” 或 “redesign” 的人， 很多时候这要么解决了我的问题，要么让我走得相当远。我曾经引用 markdown 文件，但有了我的
docs:list 脚本后就不再需要了。
- 让模型写文档：Markdown。很多时候我写 “*write docs to docs/.md”，直接让模型自己选文件名。你为模型训练的内容设计的结构越明显，你的工作就会越容易。毕竟，我设计代码库不是为了让我自己容易导航，我是为了让 Agent 能在其中高效工作而工程化它们。和模型对抗通常是浪费时间和 token。**
工具和基础设施
- 什么仍然很难？ 选择正确的依赖和框架是我会花相当多时间的事情。这东西维护得好吗？peer 依赖怎么样？它流不流行 = 会有足够的世界知识所以 Agent 能轻松处理？同样，系统设计。我们会通过 WebSockets 通信吗？用 HTML？我把什么逻辑放在服务器里，什么放在客户端？如何以及哪些数据从哪里流向哪里？通常这些是对模型来说有点难解释的事情，也是研究和思考有回报的地方。
- 批量项目更新：因为我管理很多项目，我经常让一个 Agent 直接在我的项目文件夹里运行。当我想出一个新模式时，我让它 “找到我最近的所有 go 项目” 并在那里也实现这个改动 + 更新 changelog。我的每个项目在那个文件里都有一个递增的 patch 版本号，当我重新访问它时，一些改进已经在等着我测试了。
- 自动化一切：当然我自动化一切。有一个 Skill 用来注册域名和修改 DNS。一个用来写邮件前端。我的
AGENTS 文件里有一条关于我的 Tailscale 网络的说明，所以我可以直接说 “去我的 Mac Studio 更新 xxx”。
- 多台 Mac 协同：说到多台 Mac。我通常在两台 Mac 上工作。我的 MacBook Pro 接在大屏幕上，另一个屏幕上是到我的 Mac Studio 的 Jump Desktop 远程会话。有些项目在那里运行，有些在这里。有时我在每台机器上编辑同一个项目的不同部分，通过 Git 同步。这比使用 worktree 简单，因为 main 分支上的微小差异很容易调和。还有一个好处是，任何需要 UI 或浏览器自动化的东西我可以移到我的 Studio 上运行，它不会用弹出窗口烦我。（是的，Playwright 有无头模式，但有足够多的情况下那不管用）
- 任务持续运行：另一个好处是任务在那里继续运行，所以每当我出差时，远程机器变成我的主要工作站，任务即使我合上 MacBook 也继续运行。我过去曾实验过像 Codex Web 或 Cursor Web 这样的真正异步 Agent，但我想念可控性，而且最终工作会以 Pull Request 结束，这又给我的设置增加了复杂性。我更喜欢终端的简单性。
- 斜杠命令：我曾经玩过斜杠命令，但从来没觉得太有用。Skills 替换了其中一些，剩下的我继续写 “commit/push”，因为花的时间和键入
/commit 一样，而且总是有效。
- 即时重构：过去我经常花专门的日子来重构和清理项目，现在我做这件事更加即兴。每当提示词开始花费太长时间，或者我在代码流中看到丑陋的东西飘过，我会立刻处理它。
- Issue 追踪器：我试过 Linear 或其他 issue 追踪器，但什么都没坚持下来。重要的想法我会立刻尝试，其他的事情我要么会记住，要么它就没那么重要。当然，我有公开的 bug 追踪器给使用我开源项目的人用，但当我发现一个 bug 时，我会立刻提示模型修复——这比写下来然后之后不得不切换上下文回去要快得多。
- 从 CLI 开始：无论你构建什么，先从模型和 CLI 开始。我脑子里有做一个 Chrome 扩展来总结 YouTube 视频的想法很久了。上周我开始做
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
# 在 272-273k 上下文窗口附近留出原生压缩的空间。
# 公式：273000 - (tool_output_token_limit + 15000)
# 当 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 脚本，其他的也不错。别被压缩吓到，自从 OpenAI 切换到他们新的 /compact 端点后，这工作得足够好，任务可以跨多次压缩运行并完成。它会让事情变慢，但经常起到二次审查的作用，模型在再次查看代码时会发现 bug。
暂时就这些。我计划写更多东西，脑子里有相当多的想法积压，只是玩得太开心了在构建东西。如果你想听更多关于在这个新世界构建的想法和碎碎念，在 𝕏 (原 Twitter) 上关注我 (译者注：@steipete)。
想了解更多关于 AI 编程、开源实践和开发者工作流的深度讨论与资源？欢迎访问 云栈社区 的 开发者广场，与其他技术爱好者一起交流探索。
发表于 5 天前
|
查看: 15|
回复: 0
