> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 智能体工程实战手册
- URL: https://www.hubwiz.com/blog/the-agentic-engineering-playbook/
- Published: 2026-05-17T14:28:48.000Z
- Updated: 2026-10-13T15:35:44.000Z
- Description: 来自 OpenClaw 创造者的Vibe Coding经验
- Author: admin
- Tags: VIBE CODING, #Import 2026-10-14 14:41

Peter Steinberger 与 Lex Fridman 进行了三小时的对话。大多数报道关注的是 OpenClaw 的起源故事、与 Anthropic 的命名"纠纷"、以及 Meta 和 OpenAI 的收购洽谈。这些都很有趣，但不是引起我注意的地方。

在对话中隐藏着 Steinberger 实际使用 AI agent 的具体原则。不是理论。不是感觉。而是具体的决策——这些决策让他在大约三个月内，基本独自一人，构建了 GitHub 历史上增长最快的开源项目之一。

我通读了完整的文字记录，提取出了真正有用的内容。

## 1、Vibe coding 是一个贬义词

Steinberger 对此直言不讳。他称 vibe coding 是一个贬义词。他更喜欢的术语是 agentic engineering。

这个区别很重要。Vibe coding 是不加思考地提问，希望模型能搞定。Agentic engineering 是刻意地引导有能力的 agent 走向你深思熟虑后的结果。

"我总是告诉别人我做的是 agentic engineering，然后也许凌晨 3 点之后我会切换到 vibe coding，然后第二天我就会后悔。"

正如 Lex 所说的"羞愧之路"。你醒来，看着自己产出的东西，然后花一上午收拾残局。我们都经历过。

## 2、Agentic 陷阱

Steinberger 描述了一个大多数构建者都会经历的曲线。它看起来像一个 U 形。

![None](https://www.hubwiz.com/blog/content/images/2026/05/1-wR64KmVz6na8vIz7VaEHkg.png)

左边：你是初学者。简短的提示。"请修复这个。"简单直接。

中间：你发现了力量。八个 agent 同时运行，复杂的编排，多次检出，将 agent 链接在一起，一个包含 18 个不同斜杠命令的库。

像 LinkedIn 和 Reddit 上的所有人一样，你在构建复杂的大教堂。

右边：你从另一端出来了。再次使用简短的提示。"嘿，看看这些文件，然后做这些修改。"但现在这种简单是挣来的。你知道什么可以省略。

大多数人卡在中间。他们过度工程化工作流，自动化一切，试图将自己完全排除在循环之外。Steinberger 认为那是一条死路。

"那些试图使用编排器来自动化整个过程的人，我觉得如果你那样做，就失去了风格、热爱和人情味。"

## 3、与 agent 共情

这是 Steinberger 反复提到最多的一条原则。考虑一下 agent 如何看待你的代码库。

每次会话都从零开始。Agent 对你的项目一无所知。你的项目可能有十万行代码。Agent 每次都必须从零开始探索。

"你在抱怨你的蠢机器，但你没有意识到它们从零开始，而你对你的代码库一无所知。你进去一看，你的代码库完全是乱七八糟的命名。然后人们抱怨 agent 不好用。"

他的实用建议：给 agent 一些关于在哪里查找的提示。你有一个可以用一两句话表达的系统级理解。分享它。不要让你的 agent 从头重新发现你的架构。

这直接对应于管理初级工程师。你不会把一个新员工扔到 10 万行代码库面前，在没有任何上下文的情况下说"修复这个 bug"。给 agent 和你给人一样的尊重。

## 4、不要和命名作对

这一点让我感到惊讶。Steinberger 故意让 agent 选择变量名、文件名和函数名，即使他自己会有不同的选择。

"不要和他们选择的名称作对，因为这个名字很可能就在权重里，是最明显的名字。下次他们搜索时，他们会找那个名字。如果我决定不喜欢这个名字，我只是让他们的工作变得更难。"

他在为 agent 的可导航性设计代码库，而不是为了自己的偏好。这是一个真正的思维转变。你不是在构建一个对你来说完美的代码库。你是在构建一个让 agent 容易工作的代码库。

这需要放手。就像管理一个工程师团队一样，你接受代码不会完全按照你写的方式写出来。它推动项目前进，这才是重要的。

## 5、用说的，不要用打的

Steinberger 使用语音进行大部分提示。多个终端窗口，用键盘在它们之间切换，但实际的 agent 指令是口头说出的。他曾经有一段时间因为和 agent 说话太多而失声。

除了速度优势，语音改变了你提问的方式。你更健谈。你自然地解释上下文。你会说"嘿，看看认证模块，有一个关于过期令牌的奇怪边界情况"，而不是精心设计的文字提示。

## 6、对话模式

![None](https://www.hubwiz.com/blog/content/images/2026/05/1-2lDCbUG6PpdYqs6Spvx2ig.png)

他与 agent 的工作流遵循一个特定的节奏：

**构建之前：** 进行讨论。"讨论这个。给我一些选项。先不要写代码。"Agent 探索，你们一起讨论。当你准备好时，说"好，开始构建"，然后让它运行 20 分钟。

**审查过程中：** 在审查 PR 时，他的第一个问题从来与代码无关。而是"你理解这个 PR 的意图吗？"他希望 agent 在查看实现之前先把握问题。

**构建之后：** 每次完成一个功能，他都会问："现在你构建了它，你会做得有什么不同？"和"我们可以重构什么？"Agent 在构建过程中发现了痛点，就像人类开发者一样。在这些上下文消失之前利用它。

**神奇的问题：** "你有什么问题要问我吗？"然后他浏览这些问题。如果它们都可以通过阅读更多代码来回答，他会说"读更多代码来回答你自己的问题。"如果 agent 再次回来，剩下的问题才是真正的问题。

## 7、绝不回滚，始终前进

Steinberger 不回滚。如果出了问题，他让 agent 修复它，而不是恢复到以前的状态。

"如果我回滚所有东西，只会花更长时间。如果我看到某样东西不好，我们就继续前进。"

Main 分支始终是可发布的。没有功能分支。没有 develop 分支。他保留同一个仓库的多个副本，都在 main 上，这样他就不需要处理分支命名或合并冲突。测试在本地运行。如果通过，他就推送。

这听起来鲁莽，直到你考虑经济性。回滚消耗上下文。Agent 在会话期间建立起了对问题的理解。回滚丢弃了这些。向前修复保留了它。

## 8、CLI 优先于 MCP，始终如此

他在互联网上构建了最流行的 AI agent 框架，核心却不支持 MCP。这是一种表态。

他的论点简单而技术性。模型是在 Unix 上训练的。它们知道如何调用 CLI。MCP 需要特殊的语法，必须被烘焙到训练中。CLI 是可组合的，你可以通过 jq 或 grep 传递输出。MCP 每次都将完整响应倾倒入上下文中，用 agent 不需要的数据污染它。

"就用 CLI。机器人真的很擅长 Unix。你可以有任意多个，它就能用。"

他构建了一个叫 makeporter 的工具，可以将 MCP 转换为 CLI，让你两全其美而没有开销。

## 9、Codex 优于 Claude Code（有细微差别）

Steinberger 更喜欢用 Codex 进行构建。他的理由很具体：Codex 在决定修改什么之前会读取更多代码。你不需要那么多"做戏"来获得好的输出。

但这个比较有细微差别。他把 Opus 描述为一个有时有点傻但很有趣的同事，你会留着他们。Codex 是角落里安静古怪的人，你不想和他说话，但可靠且能完成任务。

Claude Code 更具交互性。如果你运行一两个会话，那很好。但 Steinberger 同时运行四到十个 agent。不那么交互的模型，消失 20 分钟后带着结果回来，更适合那个工作流。

他的底线："如果你是一个熟练的驾驶员，你可以用任何工具获得相当好的输出。"在评判任何新模型之前，给它一周时间。

## 10、情感的现实

当 Steinberger 谈到倦怠时，采访出人意料地坦诚。

他运营 PSPDFKit 13 年。倦怠不是来自工作太多。而是来自人的问题、与联合创始人的冲突、高压客户情况。当他最终卖掉公司离开后，他无法编程了。他坐在屏幕前，感到空虚。

"我就像 Austin Powers 被抽走了魔力一样。它消失了。"

他订了一张去马德里的单程票，停了下来。持续了三年。

他对那些追求"努力工作，提前退休"梦想的人的警告：不要。

"如果你早上醒来没有任何期待，没有真正的挑战，那会变得非常无聊，非常快。然后当你无聊的时候，你会去其他地方寻求刺激，那会把你引向一条非常黑暗的道路。"

恢复来自玩耍。只是摆弄 AI 工具。构建小东西，没有商业计划，没有增长策略，没有压力。为了构建而构建。技能和好奇心的复利最终产生了 OpenClaw。

## 11、哀悼手艺是可以的

Steinberger 承认了一些大多数 AI 布道者完全跳过的内容。

"今天早上我读到一篇文章，有人说哀悼我们的手艺是可以的。我内心的一部分对此非常认同。我花了很多时间修补，沉浸在心流中，大量产出代码，寻找真正优雅的解决方案。从某种意义上说，这很悲伤，因为那将会消失。"

他没有假装这种转变不伤人。但他也说心流状态并没有消失，只是改变了形态。与 agent 合作、深入思考架构、引导多个会话——这些都产生了自己版本的心流。

他说，我们所知道的编程会变得像 knitting。人们仍然会做，因为他们热爱它。不是因为这是最高效的构建方式。

---

原文链接: [The Agentic Engineering Playbook](https://kotrotsos.medium.com/the-agentic-engineering-playbook-546ad65f0cc5?ref=hubwiz.com)

汇智网翻译整理，转载请标明出处

> **这是「Agent / MCP」专题的一部分。**完整地图见：[Agent / MCP / 自动化完全指南](https://www.hubwiz.com/blog/agent-stack/)