深度｜OpenAI对话OpenClaw：AI 正在重新定义开发者，以一种玩乐的心态去面对AI

深度｜OpenAI对话OpenClaw：AI 正在重新定义开发者，以一种玩乐的心态去面对AI 深度｜OpenAI对话OpenClaw：AI 正在重新定义开发者，以一种玩乐的心态去面对AI Modified March 19 Peter ： 是啊，我最大的失误是把它禁用了，但忘了我其实有一个启动守护进程（ launch daemon ）。启动守护进程主要做什么？如果服务崩溃或者 MGE （ sol ）被终止，它会自动重启，因为你希望服务是可靠的。苹果当初设计它，就是为了保持服务稳定。我没考虑到这一点，所以把它 “ 杀掉 ” 了，结果它在五秒内自己重启，而我就去睡觉了。现在我吸取了教训，也加入了 sandboxing 。他在 Gemini Studio 里看到时非常自豪，把它称作 “ 城堡 ” 。我把它放进了一个小型容器，但这些模型真的非常有创造力。 比如第一次我做了一个 Alpine Docker 容器，里面几乎什么都没有。我当时对 Malte 说： “ 嘿，能帮我看看这个网站吗？ ” 它却说： “ 这里连 curl 都没有，什么都做不了。 ” 我就对它说： “ 发挥你的创造力吧。 ” 它居然自己用 TCP socket 构建了一个 curl ，还用 C 编译器编译，生成了一个简陋版本的 curl ，竟然可以真正访问网站 —— 效果完全正常，简直疯狂。这些模型的资源调度能力和创造力真的令人难以置信。 Romain ： 当然也遇到了一些挑战。很多人会从安全角度审视项目，期待它从第一天起就做到非常完善、非常稳健。但当时只是把一个开源项目公开出来，本身还处在早期探索阶段。 Peter ： 每当有人问我： “ 能不能帮我联系一下你们的 CEO 、人力资源，或者团队里的其他成员？ ” 我都会忍不住笑。其实就是我一个人在 “ 山洞里 ” 写代码而已。但这恰恰体现出那种认知上的错位 —— 从外界看来，这像是一家成熟公司的成果；可实际上，如果没有这些模型和 agent 的加持，单凭一个人根本不可能做到这样的规模与复杂度。 现在确实有维护者加入，也会收到 PRs 。但从本质上说，这个项目最初是我一个人完成的 —— 而放在一年前，这几乎是不可能的。当时根本没有这样的模型能力，让一个人可以构建出这种规模和复杂度的系统。所以从传统视角来看，甚至都不该把它当作 “ 一个人能完成的事情 ” 。 Romain ： 我们不妨就聊聊这个话题。我想很多开发者都会好奇 ——Peter 的生产力到底是怎么做到的？今天早上我又看了一下你的 GitHub ，过去一年在 120 多个项目里累计了 9 万多次 contribution 。更有意思的是， GitHub 活动图在年初几乎是一片空白、浅绿色，到了秋天，尤其是 10 月和 11 月，突然变成了深绿色。那段时间究竟发生了什么？ Peter ： 每一代模型都在进步。但变化不仅仅在于 agent 变得更强，模型本身的 “ 智能上限 ” 也在提升。同时，我对如何驾驭它们的理解，以及自己的 workflow 也在不断优化。有些人仍然用过去的方式写代码，觉得那套方法不会改变；当他们尝试用 AI 时，把这种方式称作 “vibe coding” 。 在我看来，这个词本身就带点贬义。他们去尝试 AI ，却没有意识到这其实是一种技能。就像拿起一把吉他，第一天不可能就弹得很好。于是因为体验不好，就下结论说： “ 不行，这行不通。 ” 如果用一种更玩味、更探索的心态去对待它，就必须愿意学习。 现在我对不同 prompt 会产生什么效果、大概需要多长时间，已经有了一种直觉。如果过程变得异常漫长，我就会反思 —— 是不是提示写错了？架构不对？思路出了问题。这和写代码很像。当你在写代码时，也会有一种感觉：某个功能是自然融入整体架构，还是在 “ 对抗系统 ” 、处处别扭。这种判断力需要时间去积累。 走 出 Agentic Trap ：保持简单，专注问题本身 Romain ： 那么，如果有人希望提升到类似你的效率水平，你现在的 coding setup 是怎样的？你之前也提到过，很多人把自己的开发环境搞得过于复杂。 Peter ： 其实我自己也曾这样做过，我把这种情况叫做 “agentic trap” 。从第一次接触这项新技术，到真正变得高效之间的这段过程里， 很多人都会卡在这里 —— 不停地去 “ 超级优化 ” 自己的环境。但这种优化往往并不会真正提升生产力，只是让人产生一种 “ 我更高效了 ” 的错觉 。看起来很忙、很高级，实际产出却未必更多。 我写过一篇博客，当时也挺有争议。我只是说，你要把它当成一种对话去对待。模型更像是在跟你交流 —— 这并不完全是传统的 pair programming ，而是另一种形式，更像 ISS ，本质上是一场持续的对话，我基本上就是直接告诉它我想要什么。我总会问模型一句： “ 你有什么问题吗？ ” 因为默认情况下，它会直接尝试解决问题，并自行做出各种假设。而这些默认假设未必总是最优的 —— 尤其要记住，它的训练数据里包含了大量代码，也包括很多较早期、甚至已经过时的代码。因此，通过反问，让它先澄清问题，往往能得到更好的结果。 “ 你有什么问题吗？ ” 其实是一个非常关键的问题。模型通常是以 “ 空白状态 ” 开始的，它不像我们一样逐步积累上下文。每一次新的 session ，对它来说都是 “ 我对这个代码库一无所知 ” 。它只能根据当前对话去搜索、定位相关片段，然后尝试解决你提出的那个具体问题。但它们通常看不到完整的全貌。如果要把这件事做好，完整的画面必须先在自己脑海里成型，同时还需要稍微引导模型，告诉它去看看这里、再看看那里。而 Codex 在这方面更强一些，更擅长先做一次整体性的浏览，再进入具体细节。我用的是一种非常基础的方法。甚至都不用 worktree ，只是简单地做 1 到 10 个 checkout 。 保持简单，反而让我能更专注于真正的问题本身。 我基本不去折腾复杂的分支策略，而是专注于不同的问题模块。理想情况下，当项目规模稍微大一些时，这种方式反而更轻松 —— 可以在彼此不冲突的不同部分上并行推进，而不至于互相 “ 打架 ” 。 Romain ： 你在构建 OpenCloud 的过程中大量使用了 Codex 。那么除此之外，它还在哪些方面改变了你的工作方式？ Peter ： 我尝试过很多工具。但在目前所有工具中，我对 Codex 的信任度最高 —— 它构建出我想要结果的成功率非常高， “ 直接就能跑起来 ” 的情况也越来越多。很多人没有意识到， GPT 5.2 又带来了一次质的跃迁，几乎可以说是一次 “ 量子级 ” 的飞跃。那种 “ 它真的就能正常工作 ” 的感觉，非常明显。到现在，我仍然会为它已经达到的稳定程度感到惊讶。 Romai n ： 这 真的太棒了 —— 可以直接动手构建各种东西。本身就已经非常不可思议。 Peter ： 是的，我觉得大家真的应该亲自试一试。 Romain ： 你之前也提到过，现在甚至会发布一些自己都没有逐行阅读的代码。这种做法是如何发生变化的？ Peter ： 大多数代码其实都很 “ 无聊 ” 。无非是把一种数据结构转换成另一种数据结构，最后呈现给用户，或者传递到下一个系统。因此，对于模型生成的绝大部分代码，我其实心里大概有数。我只需要看一下输出流，确认它生成的内容，大体符合我脑海里的心智模型 —— 也就是它 “ 应该 ” 长成的样子 —— 基本就够了。之前带过一个团队，手下有不少软件工程师。这也意味着必须接受一个事实：他们最终写出来的代码，不会完全符合我心中理想的写法。 真正需要优化的，其实是整个代码库，让它更适合协作、更适合持续演进。 现在也是一样 —— 要优化的是代码基础，使 agent 能够在其中发挥最佳效果。而这未必等同于 “ 人类写得最舒服 ” 的方式。这也意味着要接受，生成的代码未必完全是我理想中的写法。确实可以通过 prompt 把模型往某种风格上引导，但很多问题本身就有多种结构化方式，大多数时候并不存在唯一正确的实现。如果后来真的出现性能问题，再针对那一部分做优化即可。关键是先让系统运转起来，在需要的时候再精细打磨。 Romain ： 刚才提到对 “ 代码价值 ” 的看法，其实也在改变我看待开源的方式。就拿 Open Cloud 来说，现在大概有两千个 PR 处于打开状态。过去在没有 AI 的时候，每一个 PR 都需要认真阅读，因为代码本身就是核心价值所在。但现在有时更愿意把它理解为一种 “prompt request” ，而不仅仅是 pull request 。真正重要的，往往不是那段具体的实现代码，而是 PR 背后的想法、意图和方向。代码可以由模型重写、重构甚至重新生成。 Peter ： 有时候处理一个 PR 花的时间，比自己动手做还要久。因为我对模型 “ 不具恶意 ” 的信任，往往高于一个从未听说过、之前也没有任何交流的外部贡献者，所以对这样的 PR 必须更加仔细地审查。但当我看到一个 PR ，开始做 review 时，首先会问模型一句： “ 你理解这个 PR 的意图吗？ ” 因为 我真正关心的并不是代码本身，而是这个人到底想解决什么问题。很多时候，它更像是一个 issue ，外加一套体量很大的解决尝试。首先，不少人仍然不知道如何真正去 yield agent 。 其次，他们往往只给出一种非常局部的解决方案，因为他们脑中并没有整个系统的全貌。难点在于，这个小小的新功能如何嵌入到整个更大的系统里？或者这个小修复 —— 它确实只是一个很小的 fix—— 它真的是对的吗？问题会不会其实更偏向某个模块，甚至是一个更系统性、架构层面的问题？如果只是和模型进行对话，它其实非常擅长处理这种情况。当我说 “ 好，现在把这个实现出来 ” ，模型就会开始构建。但在此之前，我会先问它：这个改动的意图是什么？这是最优解吗？ 有时它会回答是，但更多时候会说不是。然后我们才会开始一起探索，什么才是更合适的修复方式。这是不是一个架构层面的问题？比如说，如果这是一个消息处理上的问题，它真的只影响 WhatsApp ，还是也可能影响到 Signal ？既然如此，是不是应该用一种更通用的方式来解决，而不是只做一个局部修补？这算是一个新功能吗？我们真的需要这个新功能吗？有时候，这样的讨论会持续十到十五分钟。我通常会用语音，因为那种感觉真的就像是在和一个非常聪明的同事交流。 Romain ： 用语音输入 token ，其实 比打字更轻松。 Peter ： 当我确认方向没问题之后，会触发一个 slash command—— 比如 LPR—— 它会把整个流程说明清楚：创建 branch 、完成所有修改、再到把 PR 合并。我希望建立一个社区，所以即便整个过程用时比自己从头写一遍还要长，仍然会保留原作者的署名。因为我很珍惜大家能够参与其中。 Romain ： 展望未来，在越来越多贡献者围绕这个项目参与进来的情况下， OpenClaw 接下来会走向哪里？另外，是否把自己视为某种 “ 探路者 ”—— 为 “ 个人 AI agent 应该是什么样子 ” 提供一种范式，让未来可能有数十亿人使用类似系统时，有一个可以参照的方向？ Peter ： 是的，我希望在两者之间找到一种平衡：一方面，它应该简单到连我妈妈都能安装；另一方面，它又必须保持有趣、可 hack ，这本身就很难。大多数开源项目的使用方式是下载一个 package 直接安装。但很长一段时间里，我的默认安装方式是 git clone 、 build 、 run 。这样一来，源码就直接在本地磁盘上， agent 就 “ 坐 ” 在源码之中，并且对这份 source code 是有感知的。 如果有任何不喜欢的地方，只需要对 agent 下一个 prompt ，它就会自行修改 —— 某种意义上，是真正的 “ 自我修改软件 ” 。 也正因为如此，很多原本从未给我提过 PR 的人，现在也开始提交 PR 。这也是为什么我更愿意把它称为 “prompt request”—— 关键不只是代码本身，而是对 “ 如何构建一个能够长期演进的软件 ” 的理解。与此同时，整个安全行业几乎都在盯着它。这很有意思，但也多少有些令人沮丧，因为其中确实忽略了一些新的东西。举例来说，我做的那个 web server ，最初只是为了调试而写，后来才把界面做得更好看一些。它本来的设计前提，是只在本地网络、也就是受信任的网络环境中访问。但因为我也希望它能成为某种 “ 黑客乐园 ” ，所以确实提供了一个选项，可以自行修改访问方式。毕竟有些人的部署环境很特殊，比如会使用某些特定工具，或者通过 reverse proxy 来做转发。 所以当初没有把它做成强限制模式，是有原因的。但现在却有人把它直接暴露在 open internet 上，尽管我在一份文档里反复强调 “ 不要这样做 ” ，因为那根本不是它的设计初衷。随后就会有安全行业的人指出：它没有登录限制，也没有那些在公共网络上运行服务所必须具备的安全机制。问题在于，那本来就不是它被设计出来的使用场景。确实，当初并不是按那种用途来设计的。但因为它是可配置的，于是就被直接归类为一个 CVSS 10 级别的问题。所以在这件事上，确实有些挣扎。后来也引入了一位安全专家，把安全作为核心关注点。因为已经意识到，无法阻止别人以非预期的方式使用它。 现在更重要的是支持这些不同的 use case ，同时尽量避免让用户 “ 误伤自己 ” 。 Romain ： 这正是开源的魅力所在 —— 人们可以拥抱它，并提出一些连我都未曾想到的想法。 Peter ： 是的，这既是它的魅力所在，也是它的疯狂之处。 Romain ： 稍微跳出 OpenClaw 这个话题。这周和不少开发者聊到你即将参加 Codex Hackathon ，他们都很好奇： Peter 是怎么想到这么多好点子的？这些创意从哪里来？不知道是否有一个明确的答案，还是说这更多只是出于个人的好奇心，一路追随自己的兴趣不断探索。 Peter ： 更像是一种意识到：现在很多事情变得很容易。即便已经有一个开源项目能解决我 70% 的问题，我也会选择自己动手做 —— 而这在一年前几乎是不可能的。现在的状态是，只需要下一个 prompt ，把它放在第二块屏幕上，让 Codex 跑起来，它就开始工作了。 Romain ： 我们俩都来自欧洲。当我离开旧金山回到欧洲时，我相信你也有同样的感受：很多开发者和工程师还没有真正开始使用 Codex 和 agentic 工具。对他们来说，你的建议是什么？在入门时，他们是否应该重新思考自己的工作方式和工作流程？ Peter ： 我的第一个建议始终是： 以一种玩乐的方式去接触它。 如果你至少有一点动手能力，就去构建你一直想做的东西 —— 脑海里总有一个想做的项目，就尽情玩一玩。必须以一种玩乐的心态去面对这个事物。我记得 Nvidia 的 CEO 也说过： “ 短期内，你不会被 AI 取代，而是被会使用 AI 的人取代。 ” Romain ： 用得更好的人。 P e ter ： 但如果你的身份认同是：我想创造东西，我想解决问题 —— 如果你有高自主性，如果你足够聪明，你的需求量将比以往任何时候都高。 Romain ： 现在正是创作者拥抱这些工具、引导好奇心的绝佳时机，也是真正将任何想法付诸实践的时刻，就像你通过这些精彩项目和 OpenClaw 所做的那样。 Peter ： 我觉得一年之内，这将会彻底爆发。 Romain ： 是啊， 2026 年将会非常有趣。我觉得这是一个非常棒的结束方式。非常感谢你， Peter ，抽出时间接受采访。能和你共度时光真是太棒了。我们在 OpenAI 都非常喜欢你的工作，也很乐意支持像你这样的开发者，坦率地说，你是整个开发者社区真正的灵感来源。再次感谢，我们迫不及待想看到你接下来会做些什么。 原视频： Builders Unscripted: Ep. 1 Peter Steinberger, Creator of OpenClaw https://www.youtube.com/watch?v=9jgcT0Fqt7U 编译： Lureen Zheng 请注意，本文编译自文末载明的原始链接，不代表 Z Potentials 立场。如果您对本文有任何想法或见解，欢迎在评论区留言互动探讨。 Z Potentials 将继续提供更多关于人工智能、机器人、全球化等领域的优质内容。我们诚邀对未来充满憧憬的您加入我们的社群，与我们共同分享、学习、成长。 Peter ： 是啊，我最大的失误是把它禁用了，但忘了我其实有一个启动守护进程（ launch daemon ）。启动守护进程主要做什么？如果服务崩溃或者 MGE （ sol ）被终止，它会自动重启，因为你希望服务是可靠的。苹果当初设计它，就是为了保持服务稳定。我没考虑到这一点，所以把它 “ 杀掉 ” 了，结果它在五秒内自己重启，而我就去睡觉了。现在我吸取了教训，也加入了 sandboxing 。他在 Gemini Studio 里看到时非常自豪，把它称作 “ 城堡 ” 。我把它放进了一个小型容器，但这些模型真的非常有创造力。 比如第一次我做了一个 Alpine Docker 容器，里面几乎什么都没有。我当时对 Malte 说： “ 嘿，能帮我看看这个网站吗？ ” 它却说： “ 这里连 curl 都没有，什么都做不了。 ” 我就对它说： “ 发挥你的创造力吧。 ” 它居然自己用 TCP socket 构建了一个 curl ，还用 C 编译器编译，生成了一个简陋版本的 curl ，竟然可以真正访问网站 —— 效果完全正常，简直疯狂。这些模型的资源调度能力和创造力真的令人难以置信。 Romain ： 当然也遇到了一些挑战。很多人会从安全角度审视项目，期待它从第一天起就做到非常完善、非常稳健。但当时只是把一个开源项目公开出来，本身还处在早期探索阶段。 Peter ： 每当有人问我： “ 能不能帮我联系一下你们的 CEO 、人力资源，或者团队里的其他成员？ ” 我都会忍不住笑。其实就是我一个人在 “ 山洞里 ” 写代码而已。但这恰恰体现出那种认知上的错位 —— 从外界看来，这像是一家成熟公司的成果；可实际上，如果没有这些模型和 agent 的加持，单凭一个人根本不可能做到这样的规模与复杂度。 现在确实有维护者加入，也会收到 PRs 。但从本质上说，这个项目最初是我一个人完成的 —— 而放在一年前，这几乎是不可能的。当时根本没有这样的模型能力，让一个人可以构建出这种规模和复杂度的系统。所以从传统视角来看，甚至都不该把它当作 “ 一个人能完成的事情 ” 。 Romain ： 我们不妨就聊聊这个话题。我想很多开发者都会好奇 ——Peter 的生产力到底是怎么做到的？今天早上我又看了一下你的 GitHub ，过去一年在 120 多个项目里累计了 9 万多次 contribution 。更有意思的是， GitHub 活动图在年初几乎是一片空白、浅绿色，到了秋天，尤其是 10 月和 11 月，突然变成了深绿色。那段时间究竟发生了什么？ Peter ： 每一代模型都在进步。但变化不仅仅在于 agent 变得更强，模型本身的 “ 智能上限 ” 也在提升。同时，我对如何驾驭它们的理解，以及自己的 workflow 也在不断优化。有些人仍然用过去的方式写代码，觉得那套方法不会改变；当他们尝试用 AI 时，把这种方式称作 “vibe coding” 。 在我看来，这个词本身就带点贬义。他们去尝试 AI ，却没有意识到这其实是一种技能。就像拿起一把吉他，第一天不可能就弹得很好。于是因为体验不好，就下结论说： “ 不行，这行不通。 ” 如果用一种更玩味、更探索的心态去对待它，就必须愿意学习。 现在我对不同 prompt 会产生什么效果、大概需要多长时间，已经有了一种直觉。如果过程变得异常漫长，我就会反思 —— 是不是提示写错了？架构不对？思路出了问题。这和写代码很像。当你在写代码时，也会有一种感觉：某个功能是自然融入整体架构，还是在 “ 对抗系统 ” 、处处别扭。这种判断力需要时间去积累。 走 出 Agentic Trap ：保持简单，专注问题本身 Romain ： 那么，如果有人希望提升到类似你的效率水平，你现在的 coding setup 是怎样的？你之前也提到过，很多人把自己的开发环境搞得过于复杂。 Peter ： 其实我自己也曾这样做过，我把这种情况叫做 “agentic trap” 。从第一次接触这项新技术，到真正变得高效之间的这段过程里， 很多人都会卡在这里 —— 不停地去 “ 超级优化 ” 自己的环境。但这种优化往往并不会真正提升生产力，只是让人产生一种 “ 我更高效了 ” 的错觉 。看起来很忙、很高级，实际产出却未必更多。 我写过一篇博客，当时也挺有争议。我只是说，你要把它当成一种对话去对待。模型更像是在跟你交流 —— 这并不完全是传统的 pair programming ，而是另一种形式，更像 ISS ，本质上是一场持续的对话，我基本上就是直接告诉它我想要什么。我总会问模型一句： “ 你有什么问题吗？ ” 因为默认情况下，它会直接尝试解决问题，并自行做出各种假设。而这些默认假设未必总是最优的 —— 尤其要记住，它的训练数据里包含了大量代码，也包括很多较早期、甚至已经过时的代码。因此，通过反问，让它先澄清问题，往往能得到更好的结果。 “ 你有什么问题吗？ ” 其实是一个非常关键的问题。模型通常是以 “ 空白状态 ” 开始的，它不像我们一样逐步积累上下文。每一次新的 session ，对它来说都是 “ 我对这个代码库一无所知 ” 。它只能根据当前对话去搜索、定位相关片段，然后尝试解决你提出的那个具体问题。但它们通常看不到完整的全貌。如果要把这件事做好，完整的画面必须先在自己脑海里成型，同时还需要稍微引导模型，告诉它去看看这里、再看看那里。而 Codex 在这方面更强一些，更擅长先做一次整体性的浏览，再进入具体细节。我用的是一种非常基础的方法。甚至都不用 worktree ，只是简单地做 1 到 10 个 checkout 。 保持简单，反而让我能更专注于真正的问题本身。 我基本不去折腾复杂的分支策略，而是专注于不同的问题模块。理想情况下，当项目规模稍微大一些时，这种方式反而更轻松 —— 可以在彼此不冲突的不同部分上并行推进，而不至于互相 “ 打架 ” 。 Romain ： 你在构建 OpenCloud 的过程中大量使用了 Codex 。那么除此之外，它还在哪些方面改变了你的工作方式？ Peter ： 我尝试过很多工具。但在目前所有工具中，我对 Codex 的信任度最高 —— 它构建出我想要结果的成功率非常高， “ 直接就能跑起来 ” 的情况也越来越多。很多人没有意识到， GPT 5.2 又带来了一次质的跃迁，几乎可以说是一次 “ 量子级 ” 的飞跃。那种 “ 它真的就能正常工作 ” 的感觉，非常明显。到现在，我仍然会为它已经达到的稳定程度感到惊讶。 Romai n ： 这 真的太棒了 —— 可以直接动手构建各种东西。本身就已经非常不可思议。 Peter ： 是的，我觉得大家真的应该亲自试一试。 Romain ： 你之前也提到过，现在甚至会发布一些自己都没有逐行阅读的代码。这种做法是如何发生变化的？ Peter ： 大多数代码其实都很 “ 无聊 ” 。无非是把一种数据结构转换成另一种数据结构，最后呈现给用户，或者传递到下一个系统。因此，对于模型生成的绝大部分代码，我其实心里大概有数。我只需要看一下输出流，确认它生成的内容，大体符合我脑海里的心智模型 —— 也就是它 “ 应该 ” 长成的样子 —— 基本就够了。之前带过一个团队，手下有不少软件工程师。这也意味着必须接受一个事实：他们最终写出来的代码，不会完全符合我心中理想的写法。 真正需要优化的，其实是整个代码库，让它更适合协作、更适合持续演进。 现在也是一样 —— 要优化的是代码基础，使 agent 能够在其中发挥最佳效果。而这未必等同于 “ 人类写得最舒服 ” 的方式。这也意味着要接受，生成的代码未必完全是我理想中的写法。确实可以通过 prompt 把模型往某种风格上引导，但很多问题本身就有多种结构化方式，大多数时候并不存在唯一正确的实现。如果后来真的出现性能问题，再针对那一部分做优化即可。关键是先让系统运转起来，在需要的时候再精细打磨。 Romain ： 刚才提到对 “ 代码价值 ” 的看法，其实也在改变我看待开源的方式。就拿 Open Cloud 来说，现在大概有两千个 PR 处于打开状态。过去在没有 AI 的时候，每一个 PR 都需要认真阅读，因为代码本身就是核心价值所在。但现在有时更愿意把它理解为一种 “prompt request” ，而不仅仅是 pull request 。真正重要的，往往不是那段具体的实现代码，而是 PR 背后的想法、意图和方向。代码可以由模型重写、重构甚至重新生成。 Peter ： 有时候处理一个 PR 花的时间，比自己动手做还要久。因为我对模型 “ 不具恶意 ” 的信任，往往高于一个从未听说过、之前也没有任何交流的外部贡献者，所以对这样的 PR 必须更加仔细地审查。但当我看到一个 PR ，开始做 review 时，首先会问模型一句： “ 你理解这个 PR 的意图吗？ ” 因为 我真正关心的并不是代码本身，而是这个人到底想解决什么问题。很多时候，它更像是一个 issue ，外加一套体量很大的解决尝试。首先，不少人仍然不知道如何真正去 yield agent 。 其次，他们往往只给出一种非常局部的解决方案，因为他们脑中并没有整个系统的全貌。难点在于，这个小小的新功能如何嵌入到整个更大的系统里？或者这个小修复 —— 它确实只是一个很小的 fix—— 它真的是对的吗？问题会不会其实更偏向某个模块，甚至是一个更系统性、架构层面的问题？如果只是和模型进行对话，它其实非常擅长处理这种情况。当我说 “ 好，现在把这个实现出来 ” ，模型就会开始构建。但在此之前，我会先问它：这个改动的意图是什么？这是最优解吗？ 有时它会回答是，但更多时候会说不是。然后我们才会开始一起探索，什么才是更合适的修复方式。这是不是一个架构层面的问题？比如说，如果这是一个消息处理上的问题，它真的只影响 WhatsApp ，还是也可能影响到 Signal ？既然如此，是不是应该用一种更通用的方式来解决，而不是只做一个局部修补？这算是一个新功能吗？我们真的需要这个新功能吗？有时候，这样的讨论会持续十到十五分钟。我通常会用语音，因为那种感觉真的就像是在和一个非常聪明的同事交流。 Romain ： 用语音输入 token ，其实 比打字更轻松。 Peter ： 当我确认方向没问题之后，会触发一个 slash command—— 比如 LPR—— 它会把整个流程说明清楚：创建 branch 、完成所有修改、再到把 PR 合并。我希望建立一个社区，所以即便整个过程用时比自己从头写一遍还要长，仍然会保留原作者的署名。因为我很珍惜大家能够参与其中。 Romain ： 展望未来，在越来越多贡献者围绕这个项目参与进来的情况下， OpenClaw 接下来会走向哪里？另外，是否把自己视为某种 “ 探路者 ”—— 为 “ 个人 AI agent 应该是什么样子 ” 提供一种范式，让未来可能有数十亿人使用类似系统时，有一个可以参照的方向？ Peter ： 是的，我希望在两者之间找到一种平衡：一方面，它应该简单到连我妈妈都能安装；另一方面，它又必须保持有趣、可 hack ，这本身就很难。大多数开源项目的使用方式是下载一个 package 直接安装。但很长一段时间里，我的默认安装方式是 git clone 、 build 、 run 。这样一来，源码就直接在本地磁盘上， agent 就 “ 坐 ” 在源码之中，并且对这份 source code 是有感知的。 如果有任何不喜欢的地方，只需要对 agent 下一个 prompt ，它就会自行修改 —— 某种意义上，是真正的 “ 自我修改软件 ” 。 也正因为如此，很多原本从未给我提过 PR 的人，现在也开始提交 PR 。这也是为什么我更愿意把它称为 “prompt request”—— 关键不只是代码本身，而是对 “ 如何构建一个能够长期演进的软件 ” 的理解。与此同时，整个安全行业几乎都在盯着它。这很有意思，但也多少有些令人沮丧，因为其中确实忽略了一些新的东西。举例来说，我做的那个 web server ，最初只是为了调试而写，后来才把界面做得更好看一些。它本来的设计前提，是只在本地网络、也就是受信任的网络环境中访问。但因为我也希望它能成为某种 “ 黑客乐园 ” ，所以确实提供了一个选项，可以自行修改访问方式。毕竟有些人的部署环境很特殊，比如会使用某些特定工具，或者通过 reverse proxy 来做转发。 所以当初没有把它做成强限制模式，是有原因的。但现在却有人把它直接暴露在 open internet 上，尽管我在一份文档里反复强调 “ 不要这样做 ” ，因为那根本不是它的设计初衷。随后就会有安全行业的人指出：它没有登录限制，也没有那些在公共网络上运行服务所必须具备的安全机制。问题在于，那本来就不是它被设计出来的使用场景。确实，当初并不是按那种用途来设计的。但因为它是可配置的，于是就被直接归类为一个 CVSS 10 级别的问题。所以在这件事上，确实有些挣扎。后来也引入了一位安全专家，把安全作为核心关注点。因为已经意识到，无法阻止别人以非预期的方式使用它。 现在更重要的是支持这些不同的 use case ，同时尽量避免让用户 “ 误伤自己 ” 。 Romain ： 这正是开源的魅力所在 —— 人们可以拥抱它，并提出一些连我都未曾想到的想法。 Peter ： 是的，这既是它的魅力所在，也是它的疯狂之处。 Romain ： 稍微跳出 OpenClaw 这个话题。这周和不少开发者聊到你即将参加 Codex Hackathon ，他们都很好奇： Peter 是怎么想到这么多好点子的？这些创意从哪里来？不知道是否有一个明确的答案，还是说这更多只是出于个人的好奇心，一路追随自己的兴趣不断探索。 Peter ： 更像是一种意识到：现在很多事情变得很容易。即便已经有一个开源项目能解决我 70% 的问题，我也会选择自己动手做 —— 而这在一年前几乎是不可能的。现在的状态是，只需要下一个 prompt ，把它放在第二块屏幕上，让 Codex 跑起来，它就开始工作了。 Romain ： 我们俩都来自欧洲。当我离开旧金山回到欧洲时，我相信你也有同样的感受：很多开发者和工程师还没有真正开始使用 Codex 和 agentic 工具。对他们来说，你的建议是什么？在入门时，他们是否应该重新思考自己的工作方式和工作流程？ Peter ： 我的第一个建议始终是： 以一种玩乐的方式去接触它。 如果你至少有一点动手能力，就去构建你一直想做的东西 —— 脑海里总有一个想做的项目，就尽情玩一玩。必须以一种玩乐的心态去面对这个事物。我记得 Nvidia 的 CEO 也说过： “ 短期内，你不会被 AI 取代，而是被会使用 AI 的人取代。 ” Romain ： 用得更好的人。 P e ter ： 但如果你的身份认同是：我想创造东西，我想解决问题 —— 如果你有高自主性，如果你足够聪明，你的需求量将比以往任何时候都高。 Romain ： 现在正是创作者拥抱这些工具、引导好奇心的绝佳时机，也是真正将任何想法付诸实践的时刻，就像你通过这些精彩项目和 OpenClaw 所做的那样。 Peter ： 我觉得一年之内，这将会彻底爆发。 Romain ： 是啊， 2026 年将会非常有趣。我觉得这是一个非常棒的结束方式。非常感谢你， Peter ，抽出时间接受采访。能和你共度时光真是太棒了。我们在 OpenAI 都非常喜欢你的工作，也很乐意支持像你这样的开发者，坦率地说，你是整个开发者社区真正的灵感来源。再次感谢，我们迫不及待想看到你接下来会做些什么。 原视频： Builders Unscripted: Ep. 1 Peter Steinberger, Creator of OpenClaw https://www.youtube.com/watch?v=9jgcT0Fqt7U 编译： Lureen Zheng 请注意，本文编译自文末载明的原始链接，不代表 Z Potentials 立场。如果您对本文有任何想法或见解，欢迎在评论区留言互动探讨。 Z Potentials 将继续提供更多关于人工智能、机器人、全球化等领域的优质内容。我们诚邀对未来充满憧憬的您加入我们的社群，与我们共同分享、学习、成长。 🔗 原文链接： https://mp.weixin.qq.com/s/t4cjz2JA... https://mp.weixin.qq.com/s/t4cjz2JA... OpenAI OpenAI Z Potentials2026年3月18日 20:46 北京 图片来源： YouTube Z Highlights ： • 这和 “ 我只是用 AI 辅助写代码 ” 完全不是一个层级的变化，而是一种跃迁式的升级 —— 从增强个人生产力，变成真正意义上的端到端构建与交付。 • 从第一次接触这项新技术，到真正变得高效之间的这段过程里， 很多人都会卡在这里 —— 不停地去 “ 超级优化 ” 自己的环境。但这种优化往往并不会真正提升生产力，只是让人产生一种 “ 我更高效了 ” 的错觉 。 • 真正需要优化的，其实是整个代码库，让它更适合协作、更适合持续演进。 现在也是一样 —— 要优化的是代码基础，使 agent 能够在其中发挥最佳效果。 • 以一种玩乐的方式去接触它。 如果你至少有一点动手能力，就去构建你一直想做的东西 —— 脑海里总有一个想做的项目，就尽情玩一玩。 《 Builders Unscripted 》是 OpenAI 官方推出的一档聚焦顶尖开发者的硬核对谈节目。在 2026 年 2 月 25 日首期节目中， Peter Steinberger 围绕 OpenClaw 、他在开源领域的历程，以及如何借助 Codex 进行构建展开了深入解析。 Romain ： Pet er ，欢迎来到 OpenAI 。 P eter ： 感谢邀请。 Romain ： 这些年来一直在线上相识相伴，如今终于有机会在 Versa 里有更多时间相处，内心真的很开心。 Peter ： 同感。你们的办公室真的很漂亮。 社区热潮：从线上到全球线下现象级爆发 Romain ： 谢谢，最近这几周真是忙得不可开交。其实一个月前就有一起录视频的想法，要是当时做的话，可能还得专门做个介绍。现在看来，几乎都不用铺垫了。开源项目能登上《华尔街日报》并不多见，取得这样的成绩确实值得祝贺。此刻的感受如何？ Peter ： 有点抱歉，感觉各方面都有些信息过载。不过说实话，今年一开始折腾 AI 的时候，其实是想激励更多人参与进来。现在走到这一步，仿佛达到了某种 “ 终极形态 ” ，所以内心还是挺自豪的。 Romain ： 这段时 间确实很精彩。过去一周都在旧金山，参加了一些活动，比如 Codex Hackathon ，同时也主办了一个专门围绕 OpenClaw 的活动。 Peter ： 其实这件事本身也是由社区推动的。当时有人提议说应该办一次线下见面会，于是就建了一个 Discord 频道专门讨论 meetup 的事。没想到后来来到现场，竟然有将近一千人到场。那种创造力真的让人震撼 —— 现场的设计、氛围、色彩，还有各种各样的想法与项目，能感受到无数人投入其中、满怀热情。 Romain ： 那一刻才真正意识到，确实创造出了某种 “ 有魔力 ” 的东西。几周前这个项目还不存在，如今却已经有成千上万的人在使用、在支持，甚至专程聚集到旧金山线下见面 —— 这种变化本身就令人难以置信。 Pet