--- layout: single title: "以推理速度交付：为什么我不再阅读代码，而是看着它飞速流转" date: 2026-02-15 10:00:00 +0800 categories: [AI 与大模型, 编程开发] tags: [Agent, Software Development, Vibe Coding, Agentic Engineering, Peter Steinberger, OpenClaw, OpenClaw AgenticEngineering] --- **Peter Steinberger** (`OpenClaw` 的创造者) 分享了他在使用 AI 智能体构建软件方面的最新经验，特别是关于如何以推理速度交付代码，以及他对模型（如 GPT 5.2 和 Opus）的看法。 ## 自五月以来的变化 “氛围编程”（Vibe Coding）在今年取得的进步令人不可思议。大约在五月份时，我对某些提示词（prompts）能直接生成可运行的代码感到惊讶，而**现在，这已经成了我的预期**。我现在的代码交付速度快到不真实。从那时起，我消耗了[大量的Token](https://x.com/thsottiaux/status/2004789121492156583)。是时候更新一下心得录了。 这些智能体（Agents）的工作方式很有趣。几周前有人争论说，[为了感受糟糕的架构，人必须亲手写代码](https://x.com/steipete/status/1997380251081490717)，使用智能体会导致脱节——我**完全不同意这种观点**。当你花足够多的时间与智能体合作，你就会准确地知道某件事应该花多少时间。当 codex 回来时如果未能一次性解决问题，我立刻就会产生怀疑。 我能创建的软件数量，现在主要 **受限于推理时间** 和 **硬核思考**。坦率地说——大多数软件并不需要硬核思考。大多数应用只是把数据从一个表单搬运到另一个表单，也许存进某个地方，然后以某种形式展示给用户。最简单的形式是文本，所以默认情况下，无论我想构建什么，它都始于 CLI（命令行界面）。**智能体可以直接调用它（CLI）并验证输出——从而闭环**。 ## 模型转变 真正解锁[像工厂一样构建软件](https://github.com/steipete/)能力的，是 GPT 5。在它发布几周后我才意识到这一点——我也花了一些时间让 codex 追平 Claude Code 的功能，并理解它们之间的差异，但随后我开始越来越信任这个模型。**这些天我不太阅读代码了**。我看着代码流转，偶尔看一下关键部分，但我必须坦白——大多数代码我都不读。我**确实知道组件在哪里，结构如何，整体系统是如何设计的，通常这就足够了**。 如今重要的决定是**语言/生态系统和依赖项**。我的首选语言是用于 Web 开发的 TypeScript，用于 CLI 的 Go，以及如果需要调用 macOS 原生功能或有 UI 需求时的 Swift。几个月前我甚至没想过用 Go，但最终我尝试了一下，发现智能体非常擅长编写它，而且它简单的类型系统使 linting（代码检查）速度很快。 对于那些构建 Mac 或 iOS 应用的人：你不再需要频繁使用 Xcode 了。[我甚至不使用 xcodeproj 文件](https://github.com/steipete/clawdis/tree/main/apps/ios)。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 所必需的许多繁文缛节。我不使用“**计划模式**”（plan mode），而是 **[直接与模型开始对话](https://x.com/steipete/status/1997412175615246603)**，提问，让它搜索、探索代码、一起制定计划，当我对自己所看到的感到满意时，我会输入“build”或“write plan to docs/*.md and build this”（将计划写入 docs/*.md 并构建）。计划模式感觉像是一个 hack 方案，是旧版本模型在遵循提示方面表现不佳时所必需的，因此我们不得不拿走它们的编辑工具。我有一个[被高度误解的推文](https://x.com/steipete/status/2001228002953158928)仍在流传，这表明大多数人并不理解[计划模式并不是魔法](https://lucumr.pocoo.org/2025/12/17/what-is-plan-mode/)。 ## Oracle（预言机） 从 GPT 5/5.1 到 5.2 的提升是巨大的。大约一个月前，我构建了 **[oracle 🧿](https://github.com/steipete/oracle)**——这是一个 CLI 工具，允许智能体运行 GPT 5 Pro 并上传文件+提示词，并管理会话以便稍后检索答案。我这样做是因为很多时候智能体卡住了，我让它把所有东西写进一个 markdown 文件，然后自己进行查询，这感觉是一种重复性的时间浪费——也是一个闭环的机会。指令在我的[全局 AGENTS.MD](https://github.com/steipete/agent-scripts/blob/main/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](https://vibetunnel.sh/)。一个终端复用器，让你可以随时随地编程。今年早些时候，我投入了几乎所有的时间在上面，两个月后它变得如此好用，以至于我发现自己在和朋友外出时也在用手机编程……为了心理健康，我决定应该停止这样做。当时，我试图将复用器的核心部分从 TypeScript 重写。我尝试了 Rust、Go……天哪，甚至 Zig。当然我可以完成这个重构，但需要大量的手动工作，所以在搁置之前我从未完成。上周，我给它去了去灰，给 codex 下了一个**两句话的提示词**，让它[将整个转发系统转换为 Zig](https://github.com/amantus-ai/vibetunnel/compare/6a1693b482fa4ef0ac021700a9ec05489a3a108f...a81b29ee3de6a2c85fd9fa41423d968dcc000515)，它运行了 5 小时并进行了多次压实（compactions），一次性完成了工作转换。 你问我为什么把它翻出来？我目前的重点是 [Clawdis](https://clawdis.ai/)，一个**完全访问我所有电脑**、[信息](https://imsg.to/)、[邮件](https://github.com/steipete/gogcli)、[家庭自动化](https://www.openhue.io/cli/openhue-cli)、[摄像头](https://camsnap.ai/)、灯光、[音乐](https://sonoscli.sh/)，甚至能控制[我床的温度](https://eightctl.sh/)的 AI 助手。当然它也有[自己的声音](https://github.com/steipete/sag/)、[发推的 CLI](https://github.com/steipete/bird) 和它自己的 [clawd.bot](https://clawd.bot)。 Clawd [可以看到并控制我的屏幕](https://www.peekaboo.boo/)，有时会发表尖刻的评论，但我还想让他有能力检查我的智能体，获取**字符流**远比看图像更高效……这能否成功，我们拭目以待！ ## 我的工作流 我知道……你们来这里是为了**学习如何更快的构建**，而我只是在为 OpenAI 做营销广告。我希望 Anthropic 正在研发 Opus 5，让局势再次逆转。竞争是好事！同时，我也*喜爱* Opus 作为通用模型。我的 AI 智能体如果在 GPT 5 上运行就不会这么有趣了。Opus 有一些[特别的东西](https://soul.md/)，让与它工作成为一种享受。我将它用于大多数计算机自动化任务，当然它也驱动着 Clawd🦞。 我的工作流与[十月份的上次分享](https://steipete.me/posts/just-talk-to-it)相比并没有太大的变化。 * 我通常同时处理 **[多个项目](https://x.com/steipete/status/2005083410482733427/photo/1)**。根据复杂度，数量在 **3 到 8 个之间**。上下文切换会很累人，我只有在家里安静且专注地工作时才能做到。需要梳理的思维模型太多了。幸运的是，大多数软件都很枯燥。创建一个 CLI 来[检查你的外卖订单](https://ordercli.sh/)不需要太多的思考。通常我的重点是一个大项目和一些同步进行的卫星项目。当你做多了智能体工程，你就会对什么是容易的、模型可能在哪里挣扎产生一种感觉，所以通常我只需要输入一个提示词，codex 就会忙活 30 分钟，我就能得到我需要的东西。有时需要一点折腾或创造力，但通常事情都很直接。 * 我广泛使用 codex 的**队列功能**——当我有了新想法，我就把它添加到流水线中。我看到很多人在尝试各种多智能体编排系统、邮件或自动化任务管理——目前我没觉得有多大必要——通常我是瓶颈。我构建软件的方法非常迭代。我构建一些东西，玩弄它，看看它“感觉”如何，然后得到新的想法来细化它。我脑子里很少有完整清晰的画面。当然，我有一个大概的想法，但这通常会在探索问题领域时发生巨大变化。因此，将*完整想法*作为输入然后交付输出的系统不适合我。我需要玩弄它、触摸它、感觉它、看到它，这就是我进化它的方式。 * 我基本上**从不回滚**或使用检查点。如果有什么我不喜欢的地方，我会让模型修改它。codex 有时会重置文件，但通常它只是回滚或修改编辑内容，很少需要彻底返回，我们只需要转向不同的方向。构建软件就像徒步登山。你不会直接直线向上，而是环绕它前行，有时会偏离路径不得不走回来，过程是不完美的，但最终你会到达你需要去的地方。 * 我直接**提交到 main 分支**。有时 codex 认为太乱了，会自动创建一个工作树（worktree）并合并更改，但这很少见，我只有在特殊情况下才会提示这样做。我发现必须考虑项目中不同状态所带来的认知负荷是没有必要的，我倾向于线性演进。较大的任务我留到分散注意力的时候做——例如在写这篇文章时，我正在对 4 个项目进行重构，每个项目需要 1 到 2 小时才能完成。当然我可以在工作树中做，但这会引起大量的合并冲突和次优的重构。警告：我通常独自工作，**如果你在更大的团队中工作，这种工作流显然行不通。** * 我已经提到过我规划功能的方法。我**一直在交叉引用项目**，特别是如果我知道我已经在某处解决了问题，我会让 codex 去查阅 ../project-folder，这通常就足够它从上下文中推断出在哪里查找。这对于节省提示词非常有用。我可以只写“查看 ../vibetunnel 并对 Sparkle 变更日志做同样的事情”，因为它已经在那里解决了，并且有 99% 的保证它会正确复制并适应新项目。这就是**我构建新项目的方式**。👍 * 我见过很多让人们引用过去会话的系统。这是我从不需要或使用的另一件事。我维护每个项目中 **docs 文件夹**内的子系统和功能文档，并使用[一个脚本+一些指令](https://github.com/steipete/agent-scripts/blob/main/scripts/docs-list.ts)在我的全局 AGENTS 文件中强制模型阅读特定主题的文档。项目越大，这带来的回报就越丰厚，所以我并没有到处使用它，但它对于保持文档最新和为我的任务构建更好的上下文非常有帮助。 * 关于上下文。我以前非常勤奋地为新任务重启会话。**使用 GPT 5.2**，不再需要这样做了。即使上下文更丰富，性能也非常好，而且通常有助于提高速度，因为模型在已经加载了大量文件时工作得更快。显然，这只有在序列化任务或保持更改距离足够远以至于两个会话互不影响时才有效。codex 没有像 Claude Code 那样的“此文件已更改”的系统事件，因此需要更加小心——另一方面，codex 在上下文管理方面要好得多，我觉得我在一个 codex 会话中完成的工作量是 Claude 的 5 倍。这不仅仅是客观上更大的上下文窗口，还有其他因素在起作用。我猜 codex 内部思考非常精简以节省 Token，而 Opus 非常啰嗦。有时模型会出错，[其内部思考流会泄漏给用户](https://x.com/steipete/status/1974108054984798729)，所以我见过很多次这种情况。真的，[codex 表达方式](https://x.com/steipete/status/2005243588414931368)我觉得非常幽默。 * 提示词。我以前用语音听写写很长的提示词。使用 codex，我的**提示词变得短得多**，我经常重新输入，而且很多时候我添加图像，特别是在迭代 UI（或 CLI 的文本副本）时。如果你告诉模型哪里错了，几句话就足以让它做你想做的事。是的，我就是那种拖入 UI 组件截图并配上“修复边距”或“重新设计”的人，很多时候这要么解决了我的问题，要么让我走得很远。我以前引用 markdown 文件，但有了我的 **docs:list 脚本**，不再需要这样做了。 * Markdowns。很多时候我写“**write docs to docs/*.md**”，然后让模型选择文件名。你为模型训练的内容设计的结构越明显，你的工作就越轻松。毕竟，我设计代码库并不是为了让我自己容易导航，我对其进行工程化是为了让智能体高效工作。与模型对抗通常是浪费时间和 Token。 ## 工具与基础设施 * **什么仍然很难？** 选择正确的依赖项和框架是投入相当多时间的事情。维护得好吗？对等依赖关系（peer dependencies）怎么样？受欢迎吗=会有足够的世界知识，以便智能体能轻松应对？同样，系统设计。我们将通过 WebSockets 通信吗？HTML？我把什么放在服务器上，把什么放在客户端上？什么数据流向哪里？通常这些问题很难向模型解释，研究和思考能带来回报。 * 因为我管理很多项目，通常我让一个智能体在我的项目文件夹中运行，当我发现一个新模式时，我让它“**查找我最近所有的 Go 项目**并在那里也实现此更改+更新变更日志”。我的每个项目在文件中都有一个提升的补丁版本，当我重新访问它时，一些改进已经在等着我测试了。 * 当然我**自动化一切**。有一个技能（skill）可以注册域名并更改 DNS。有一个编写优秀前端的。我的 AGENTS 文件中有一个关于我 Tailscale 网络的说明，所以我可以直接说“去我的 Mac Studio 并更新 xxx”。 * 关于**多台 Mac**。我通常在两台 Mac 上工作。我的 MacBook Pro 在大屏幕上，Jump Desktop 会话连接到另一个屏幕上的 Mac Studio。有些项目在那里制作，有些在这里。有时我在每台机器上编辑同一个项目的不同部分，然后通过 git 同步。这比使用工作树更简单，因为 main 分支上的漂移很容易调和。还有一个额外的好处是，任何需要 UI 或浏览器自动化的东西我都可以移动到我的 Studio 上，它不会用弹窗来烦我。（是的，Playwright 有无头模式，但在很多情况下这不起作用） * 另一个好处是任务**保持在那里运行**，所以每当我旅行时，远程就成了我的主要工作站，即使我合上 Mac，任务也会保持运行。我过去尝试过像 codex 或 Cursor web 这样的真正异步智能体，但我错过了可控性，最终工作以 pull request 的形式结束，这又增加了我设置的复杂性。我更喜欢终端的简单。 * 我过去常玩斜杠命令（slash commands），但从未发现它们特别有用。技能取代了其中的一部分，其余的我继续输入“**commit/push**”，因为它的时间与 /commit 相同并且总是有效。 * 过去我经常花专门的日子来**重构和清理**项目，现在这更多是即兴的。每当提示词开始需要太长时间，或者我看到代码流中飞过丑陋的东西时，我会立刻处理它。 * 我尝试过线性或其他**问题追踪器**，但没有一个坚持下来。重要的想法我会立刻尝试，其余的我会记住，或者它不重要。当然，我为使用我的开源代码的人提供公开的 bug 追踪器，但当我发现 bug 时，我会立即提示它——这比写下来然后稍后不得不将上下文切换回来要快得多。 * 无论构建什么，**从模型和 CLI 开始**。我脑子里很长一段时间都有一个[总结 YouTube 视频的 Chrome 扩展程序](https://x.com/steipete/status/2005320848543298009)的想法。上周我开始工作，这是一个将任何内容转换为 markdown 然后输入模型进行总结的 CLI。首先我搞定了核心，一旦那个工作得很好，我在一天内就构建了整个扩展。我很喜欢它。可以在本地、免费或付费模型上运行。在本地转录视频或音频。与本地守护进程对话，速度非常快。[试试看吧！](https://github.com/steipete/summarize/releases/latest) * 我的首选模型是 **gpt-5.2-codex high**。同样，KISS（保持简单）。除了速度慢得多之外，xhigh 几乎没有什么好处，我不想花时间考虑不同的模式或“超思考”。所以几乎所有东西都在 high 上运行。GPT 5.2 和 codex 足够接近，以至于切换模型没有意义，所以我只用那个。 ## 我的配置 这是我的 `~/.codex/config.toml`: ```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。 这就是现在的全部内容。我计划再次多写一些文章，脑子里有很多想法，只是 **[太沉迷于](https://codexbar.app/)** **[构建东西](https://x.com/steipete/status/2005393881395835045)** 了。如果你想听更多关于如何在这一新世界中构建的杂谈和想法，[在 Twitter 上关注我](https://x.com/steipete)。 ## 参考资料 - [Shipping at Inference-Speed](https://steipete.me/posts/2025/shipping-at-inference-speed)