“Peter Steinberger：我提交的代码，我不读”

一位前创始人，在精疲力竭、出售股份并从科技界消失三年后，又回来了，并且每天提交 600 次代码。Peter Steinberger 声称他并不阅读他提交的大部分代码，这听起来有些鲁莽，但当你了解他围绕代码构建的系统时，就会明白其中的道理。在与 Gergely Orosz 在 The Pragmatic Engineer 上进行的近两个小时的对话中，详细介绍了成熟的 AI 原生开发工作流程在实践中的实际情况。

前期准备

Steinberger 构建了 PSPDFKit，这是一个在超过 10 亿台设备上运行的 PDF 框架。他最初是奥地利乡村的一名自由职业者，他的第一台编程设备是 Amiga（“不是 Mac，因为我们太穷了”）。他进入移动开发领域是通过为自己构建一个同性恋约会应用程序，在当时这需要真正的勇气。从那时起，他注意到 iOS 上的 PDF 渲染效果很差，于是开始构建一个框架，并在 13 年的时间里将其发展成为一家拥有约 60 名员工的公司。

早期非常简陋：通过 WordPress 模板销售许可证，客户通过 Dropbox 链接下载 SDK。公司不断发展，但从工程师到 CEO 的转变逐渐使他远离了代码。在连续运营 13 年后，他结束了。

他退休了三年（2022-2025 年），完全没有接触编程。这段时间恰好涵盖了 AI 编码工具从糟糕到非常强大的演变过程。当他在 2025 年 4 月回归时，恰逢 Claude Code 的 Beta 版发布，他对 AI 没有负面的偏见。他跳过了整个“AI 编码不可靠”的阶段，并以完全开放的心态拥抱了这些工具。

几个月内，他构建了 OpenClaw（最初名为 Clawdbot），这是一个超个性化的 AI 助手，成为科技界最热门的 AI 项目，其 Google 搜索量超过了 Claude Code 或 Codex。其数量之大令人震惊：仅 1 月份就提交了 6,600 多次。

“From the commits, it might appear like it’s a company. But it’s not. This is one dude sitting at home having fun.” 从提交记录来看，它可能看起来像是一家公司。但事实并非如此。这是一个家伙坐在家里自娱自乐。

闭环

Steinberger 工作流程中最重要的概念是他所说的“闭环”。这是有效的 AI 辅助编码和令人沮丧的氛围编码之间的明确界限。

AI 编写代码，但代码必须通过自动验证来证明其自身，然后才能被接受。测试、代码检查、类型检查、构建验证。如果其中任何一项失败，AI 都会收到错误输出并再次尝试。人类永远不会阅读中间代码；他们阅读测试结果。

“I ship code I don’t read. And that’s not as crazy as it sounds, because I don’t need to read it if the tests pass.” 我提交我不阅读的代码。这并不像听起来那么疯狂，因为如果测试通过了，我就不需要阅读它。

这只有在对反馈基础设施进行大量投资的情况下才有效。Steinberger 估计，他大约 40% 的时间用于构建和维护测试、CI 管道和验证系统。剩下的 60% 是实际的功能开发，但如果没有闭环，这种速度是不可能实现的。

他做出了明确的区分：氛围编码是指你提示 AI 并接受任何结果。闭环是指你构建系统来防止不良代码落地。一种是赌博；另一种是工程。这也是为什么 AI 真正擅长编码但不擅长写作的原因：代码可以自动验证，散文则不能。

为什么代码审查已死

Steinberger 最具挑衅性的观点：传统意义上的代码审查已经过时。

当 AI 每天生成数千行代码时，人工审查就成为一个无法扩展的瓶颈。更重要的是，审查者缺乏 AI 生成代码时的上下文。你最终会浏览差异视图，发现表面问题，而忽略实际的逻辑错误。

他的替代方案：将审查精力投入到更好的测试中。全面的测试套件比人工审查员能发现更多的错误，可以立即运行，并且可以无限扩展。在收到 OpenClaw 的 PR 时，他阅读贡献者的提示语比阅读他们的代码更多。

“Pull requests, I see them more as prompt requests now. I read the prompts more than I read the code.” Pull Request，我现在更多地将它们视为提示请求。我阅读提示语比阅读代码更多。

他告诉贡献者：把你的提示语写好，因为这样他就可以将他的代理指向该问题，然后它就会构建它。小的修复 PR 让他感到沮丧：“请不要这样做。我需要花费 10 倍的时间来审查它。只需在 Codex 中输入‘修复’，然后等待几分钟即可。”

PR 已经变成了关于架构和品味的讨论，而不是逐行代码检查。当有人提交了一个添加语音通话的 PR 时，他没有直接合并，而是让 Codex 分析 PR 以及他现有的项目，设计了一个插件架构，并正确地重新实现了它。

与代理协作的架构

Steinberger 的日常工作流程与传统的开发截然不同。

多个 AI 提供商并行运行。 他使用 Claude Code 进行复杂的推理，使用 Codex 进行广泛的重构，同时在独立任务上运行 5-10 个 Codex 代理。当他需要将 OpenClaw 从单代理架构切换到多代理架构时，Codex 在三个小时内完成了重构。如果让他自己来做，需要两周时间。

计划是轻量级的，并且是迭代的。 他不会提前编写详细的规范。他的心智模型是一个螺旋：你不会直接爬上山顶，而是绕着它转，有时会偏离道路，最终到达山顶。反对像 Gastown 这样的前期规划工具：

“How can you even know what you want to build before you built it? You learn so much in the process of building it.” 在你构建它之前，你怎么知道你想构建什么？你在构建过程中学到了很多东西。

上下文管理至关重要。 他广泛使用 CLAUDE.md 文件，这些项目章程告诉 AI 工具关于代码库结构、约定和约束。这些文件充当跨会话的持久记忆。他设计代码库不是为了自己，而是为了代理：命名、结构和文件组织都针对模型理解进行了优化。

将测试作为一流的架构。 测试不是事后才考虑的事情；它们是主要的反馈机制。他在编写功能代码之前编写测试规范，让 AI 实现两者，并信任测试结果而不是代码检查。

OpenClaw：构建 Siri 应该成为的样子

最初的愿景甚至不是 Clawdbot，而是“amant machina”（爱的机器）：一个深度个性化的 AI，它会提醒你已经三个星期没有联系某个朋友了，而他们正好在城里，或者注意到你在与特定的人见面后总是感到悲伤。2025 年夏天，模型的能力还不够，所以他搁置了它。

他从更简单的开始：一个 WhatsApp 中继，从他的手机触发他电脑上的代理任务。转折点发生在摩洛哥之旅中。该代理自主处理语音消息，这是他从未明确编程过的功能。他对它的足智多谋感到震惊，并不断添加技能：Google Places、Sonos 扬声器、家庭摄像头、床控制、照明。

构建策略是纯粹的 Unix 哲学：一切皆为 CLI。

“I was just building CLIs for everything: for Google, for my bed, for lamps, for music.” 我只是为一切构建 CLI：为 Google、为我的床、为灯、为音乐。

CLI vs MCP：一个令人惊讶的强烈观点

Steinberger 对 MCP 的批评是具体和结构性的：

• MCP 在会话加载时预先导出所有函数和描述，从而污染了上下文窗口
• 它返回大量不必要的数据（天气查询返回 50 个字段，而你只想知道是否下雨）
• 它无法链接调用（无法“获取超过 25 度的城市，然后过滤特定信息”）
• 安装新的 MCP 需要重新启动 Claude Code

CLI 的优势：代理原生理解 Unix，可以使用 jq 过滤 JSON，可以通过管道进行组合。他构建了 make-porter，这是一个将 MCP 转换为 CLI 的工具。用户可以在他们的手机上说“使用 Vercel MCP 来做 X”，然后代理会找到 MCP，加载它并使用它。

他细致的看法：MCP 最大的贡献不是协议本身，而是它让公司重新考虑开放更多的 API。生态系统效应比技术实现更重要。

在 Discord 上公开

1 月 1 日，Steinberger 做出了他所谓的“疯狂”决定：他将一个对他的计算机具有完全读/写权限的代理放入了一个公共 Discord 服务器中。人们可以观看他使用代理的全部能力：检查摄像头、控制家庭自动化、播放 DJ、让代理查看他的屏幕并报告其他代理的工作状态。

结果：在一周内从 100 个 GitHub 星标增加到 3,300 个，合并了 500 个 pull request。

该代理为新用户提供的引导流程特别聪明：一行安装命令，然后代理会引导你完成身份创建，询问你的姓名、兴趣和价值观。它会生成 user.md、soul.md 和 identity.md 文件。这些是不断发展的文档，代理会在交互过程中不断更新。该代理甚至可以自我更新。

工程师会发生什么变化

对话揭示了哪些技能仍然有价值的分层观点：

仍然至关重要： 系统思维、产品设计品味、知道要构建什么、理解失败模式、编写好的测试、架构一致性。

正在减少： 记忆 API、编写样板代码、手动代码审查、详细的前期规范、将大型代码库保存在你的脑海中。

新近关键： 构建验证系统、管理 AI 上下文窗口、知道何时使用哪个工具，以及即使在 AI 使其非常快速的情况下，也有不经过测试就不提交的纪律。

Steinberger 反驳了“初级开发人员将被取代”的说法。他的观点更为激进：整个工作流程正在重组，拒绝适应的高级工程师将失去他们相对于拥抱 AI 的初级工程师的杠杆优势。新的开发人员具有令人惊讶的优势：“他们以我们甚至没有想到的方式使用代理，因为他们不知道它不起作用，而且到那时它可能确实起作用了。”

关于经济学：如果一个熟练的、拥有 AI 工具的开发人员可以匹敌一个五人团队，那么软件公司会发生什么？他估计，使用 AI 重建 PSPDFKit 将需要大约 30% 的原始员工人数。他小心地指出，这并不意味着开发人员已经过时。这意味着一个开发人员可以完成的工作的门槛已经大幅提高。

再次构建的瘾

“I’ve never worked so hard as I do now. Not because I have to, but because it’s so addictive and so much fun.” 我从未像现在这样努力工作过。不是因为我必须这样做，而是因为它太令人上瘾，太有趣了。

管理多个 AI 代理在精神上比自己编写代码更累。他的理智策略：去健身房，把手机锁在储物柜里。“我真的有一个小时的时间可以真正感受到自我。”

一个说明问题的小细节：给他带来最大乐趣的科技产品不是 iPhone 17（买了但仍然未开封），而是一个 200 美元的 Android 相框。

后记

这是目前对完全 AI 原生开发在生产规模下的实际情况的最详细的第一人称叙述。Steinberger 不是在进行理论推演；他描述的是一个以极高的数量运行了几个月的工作流程，并以一个备受瞩目的开源项目作为证明。

• “闭环”原则看似简单，但它将所有获得结果的人与所有感到沮丧的人区分开来。大多数开发人员跳过验证基础设施，因为它很无聊。而这恰恰是杠杆所在。
• “提示请求”取代 pull request 不仅仅是一句俏皮话。如果贡献者的价值在于清晰地表达意图而不是编写代码，那么整个开源协作模式就会发生转变。Steinberger 说，他通过阅读提示语而不是代码来更好地判断贡献质量。
• 他对 CLI 与 MCP 的立场值得技术决策者认真关注。在当前的代理能力下，Unix 哲学（小型工具、管道组合、文本流）比结构化协议更适合代理工作流程。随着代理的发展，这种情况可能会发生变化，但在 2026 年初，这是一种强大的工程直觉。
• 从精疲力竭到回归的弧线本身就是一个信号。如果 AI 工具可以重新吸引那些因为组织复杂性扼杀了创造力而离开行业的人，那么这是一个劳动力故事，也是一个生产力故事。
• 他的每月提交次数引人注目，但真正的指标是 OpenClaw 可以工作并且人们正在使用它。没有质量的数量是噪音；测试基础设施是将数量转化为信号的东西。