YouTube

Z Highlights：

这和“我只是用AI辅助写代码”完全不是一个层级的变化，而是一种跃迁式的升级——从增强个人生产力，变成真正意义上的端到端构建与交付。

从第一次接触这项新技术，到真正变得高效之间的这段过程里，很多人都会卡在这里——不停地去“超级优化”自己的环境。但这种优化往往并不会真正提升生产力，只是让人产生一种“我更高效了”的错觉。

真正需要优化的，其实是整个代码库，让它更适合协作、更适合持续演进。现在也是一样——要优化的是代码基础，使agent能够在其中发挥最佳效果。

以一种玩乐的方式去接触它。如果你至少有一点动手能力，就去构建你一直想做的东西——脑海里总有一个想做的项目，就尽情玩一玩。

《Builders Unscripted》是OpenAI官方推出的一档聚焦顶尖开发者的硬核对谈节目。在2026年2月25日首期节目中，Peter Steinberger围绕OpenClaw、他在开源领域的历程，以及如何借助 Codex 进行构建展开了深入解析。

Romain：Peter，欢迎来到OpenAI。

Peter：感谢邀请。

Romain：这些年来一直在线上相识相伴，如今终于有机会在Versa里有更多时间相处，内心真的很开心。

Peter：同感。你们的办公室真的很漂亮。

社区热潮：从线上到全球线下现象级爆发

Romain：谢谢，最近这几周真是忙得不可开交。其实一个月前就有一起录视频的想法，要是当时做的话，可能还得专门做个介绍。现在看来，几乎都不用铺垫了。开源项目能登上《华尔街日报》并不多见，取得这样的成绩确实值得祝贺。此刻的感受如何？

Peter：有点抱歉，感觉各方面都有些信息过载。不过说实话，今年一开始折腾AI的时候，其实是想激励更多人参与进来。现在走到这一步，仿佛达到了某种“终极形态”，所以内心还是挺自豪的。

Romain：这段时间确实很精彩。过去一周都在旧金山，参加了一些活动，比如Codex Hackathon，同时也主办了一个专门围绕OpenClaw的活动。

Peter：其实这件事本身也是由社区推动的。当时有人提议说应该办一次线下见面会，于是就建了一个Discord频道专门讨论meetup的事。没想到后来来到现场，竟然有将近一千人到场。那种创造力真的让人震撼——现场的设计、氛围、色彩，还有各种各样的想法与项目，能感受到无数人投入其中、满怀热情。

Romain：那一刻才真正意识到，确实创造出了某种“有魔力”的东西。几周前这个项目还不存在，如今却已经有成千上万的人在使用、在支持，甚至专程聚集到旧金山线下见面——这种变化本身就令人难以置信。

Peter：甚至下周在维也纳，也已经有超过300人报名参加。相比旧金山那样成熟、活跃的科技圈，当地的tech scene规模远没有那么大，但依然能聚集起这样的热度，确实令人惊叹。

Romain：现在它已经走向了全球，成为一种现象级的存在。

Peter：是啊，令人惊叹的是，它能够触及不同的大陆、不同的文化。

Romain：确实如此。那么这几天和社区的交流整体感受如何？这段时间花了不少时间和社区成员互动，也和一些后来加入项目的维护者深入沟通。过去这一周的体验怎么样？

Peter：这段经历确实很特别。很多人非常喜欢这个项目，也有不少人一上来就期待看到一个成熟、完善的“最终版本”。但对我来说，很长一段时间里，它更像是自己的一个小型试验场。这一整年，都在不断惊叹AI所展现出的各种可能性。对开发者而言，可谓是“生逢其时”。

开发者的黄金时代：AI 重构开发与身份定义

Romain：你觉得在这个时刻作为一个builder最有趣的地方是什么？现在确实是一个非常特别的时期——整个工具链都在发生变化，对“开发者”身份的定义也在不断重塑，几乎任何人都可以构建任何东西。

Peter：当我开始玩这项新技术时，每次都有一种多巴胺飙升的感觉。那时我用Claude code进行尝试，每当它做对一点事情，大概只有30%或40%的概率，但对我来说简直令人震撼——我突然意识到，现在我真的可以构建任何东西。而且通常软件开发总是很耗时、很复杂，而软件本身依然很难。但现在，开发速度快了太多。

Romain：我同意。如果回溯到几年前，大概是2011或2012年左右，当时第一次接触到你做的工作，是你开发PSPDFKit的时候。从外部来看，这个经历很有意思——感觉就像实现了每个开发者的梦想：遇到问题、提供了出色的解决方案、围绕它建立了公司、实现了规模化，并最终出售了它。但我相信，这段旅程绝不可能像表面上看起来那么轻松。

Peter：我的意思是，我并不是某天醒来就决定要开发一个PDF框架——这在我的兴趣清单上几乎排在最末位。事情更多是自然而然发生的，就像一种奇怪的蝴蝶效应：从在Nokia开发的日子开始，到身边朋友有需求，再到美国签证拖延过久，这一系列偶然因素最终促成了我创办公司的决定。

Romain：我觉得有趣的是，在那家公司建立之后，你似乎休息了一段时间。那么，是哪些因素促使你重新回到这一领域的？

Peter：最终，我是真的感到精疲力尽。连续高强度工作了13年，运营一家公司很难，当创始人更难。而且这是我的第一次创业，我并没有真正掌握如何缓解这些压力的方法，所以有一段时间几乎到了透支的状态，需要好好放松一下。

尽管如此，我还是关注着科技新闻。看到了GPT Engineer（或者当时叫ChatGPT的早期版本），觉得挺酷的，但并没有立刻让我激动。因为必须亲自体验新技术，仅仅通过阅读是无法真正感受到它的力量的，尽管当时的技术并没有立刻让我产生共鸣，真正让我动手。只有在我准备好、感觉到“好吧，我想再次创造点东西”的时候，到那时我也不想再在传统科技领域构建项目，因为我已经做了很久，而世界似乎也稍微往前走了一些。

当时很多东西还需要被重新构建，而我也恰好有了回归的动力和契机。但当你在一个领域已经非常专业，然后转到另一个领域时，那种难度真是无法用“难”来形容，更像是一种痛苦。你拥有构建项目的广泛知识，但如果没有agentic engineering的辅助，要真正把这些能力迁移过去，仍然需要学习很多东西。我当时想，“不如先看看这AI的东西吧。”真正让我震撼的时刻是，我拿了一个半完成的项目去尝试——其实那个项目早已在完成之前就因精疲力尽而搁置了。

Romain：对我们开发者来说，常常是这样的：大家都喜欢冒出新点子、启动新项目，但真正把它们完成才是最难的部分。

Peter：我经常看到这种情况——完成一个项目真的很难，有时候甚至会失败。但这个项目我想继续推进，同时也想重写它。于是我把整个项目整理成一个巨大的Markdown文件，大概1.5MB，把所有文件都拖进当时的Gemini Studio 2.5，然后让我生成一个spec，我把生成的几行内容整理回来，再拖到Cloud Code里去。接着我执行build，并在主屏幕上做其他操作，而旁边的屏幕就这样跑了好几个小时。

那时候情况要困难得多。有一次，它告诉我“已经100%可以投入生产”，大概是高级Claude 3.5 Opus之类的版本。我试了一下，结果直接崩溃了。于是我接入了Playwright——那是少数我真正会用的MCP之一——让它去构建登录流程，同时沿途检查操作是否正确，比如用来测试Twitter。一个小时后，它居然真的成功了，还展示给我一些成果。

Romain：很多人把OpenClaw看作是你的一夜成名，但我觉得最有意思的地方在于，它其实是过去9到10个月你所做的众多项目的积累。当你看看你的GitHub主页，会发现你已经构建了40多个项目。

Peter：其中大约一半的项目被直接应用在这个项目里。

Romain：我觉得其中很多，你都把它们整合进了OpenClaw。能不能聊聊这段旅程，讲讲这些想法和项目是如何最终汇聚到OpenClaw中的？

Peter：我希望我能说从一开始就有一个统一的计划，但其实大部分都是探索性的。我当时想要一些功能或工具，而它们并不存在，于是我就“创造”了它们——或者说，我通过提示让它们出现。为什么？就是因为我想去构建它，一步步来。我希望我的agent能为我做一些事情，但那时我还没有完整的整体愿景。有趣的是，事情最终又回到了原点。比如，我想让它能查看我的WhatsApp，于是我就去实现了，甚至还注册了相关的域名。

我做了一个原型，但当时心想，反正大公司和大实验室迟早会去做这个，所以我就先等等。于是我把注意力放在其他事情上，做了很多实验。那段时间的目标更多是为了好玩，也为了激励别人。到了十一月，我做出了几个版本，但都不算理想。那时我就想，为什么还没有实验室做出这些东西？他们到底在忙什么？于是我就自己动手，做出了第一个版本，这个版本后来就成为了OpenClaw。当时已经到了第五个版本，但我自己仍然没有完全被打动。那感觉是——挺酷的，只花了大约一个小时就搭出了第一个原型。你只需通过提示，就能让各种东西“生成”出来。

真正打动我是在这个周末去马拉喀什旅行时。我发现自己用它的频率大大增加，因为它太方便了。你知道，当地网络并不稳定，而WhatsApp无论在哪里都能用，这种便利性让我对它印象深刻。我用它做了很多事情，比如翻译图片、帮我找餐厅，甚至还能查电脑上的资料，感觉特别酷。我给朋友们看，还让它帮我发短信，他们都想要这样的功能。我当时就想——你们不应该用它，你们还不懂它的厉害。

Romain：这些正是产品与市场契合度的唯一信号。如果连你的朋友都想要你做的东西，即便你从未为他们设计过，它也说明了价值所在。以前这类工具更多是为技术同行保留的。

Peter：真正让我彻底感受到它的价值，是我频繁使用的过程中。有一次，我尝试发送语音消息，心中顿时意识到——这本不应该能实现。

震撼时刻：AI Agent自主解决未预设复杂问题

Romain：跟我多讲讲这个故事吧，我记得我们前几天聊过这个。

Peter：这真的很令人着迷，它让我看到了这些模型在解决问题上的强大能力。我们开发这些工具是为了agentic engineering，但真正的核心技能其实更抽象：如果你想成为一名优秀的程序员，你必须首先是一个出色的问题解决者。而这种能力实际上可以映射到任何领域。

我发送了这条语音消息，屏幕上出现了打字指示器，我心里非常好奇接下来会发生什么——我自己没写过这部分代码，按理说它不应该能工作。结果模型居然直接回复了我，我当时惊讶到：它是怎么做到的？作为模型，它本不能够运行啊。模型当时的处理方式是这样的：它说，“你给我发了个消息，但其实只是一个没有文件后缀的文件。”于是它查看了文件头，发现这是一个音频编码格式。然后它在我的电脑上用ffmpeg转换了文件，我本想把它转写成文字，但电脑上没有安装Whisper。于是它四处寻找，找到一个OpenAI的API key，用curl把文件发送给OpenAI，最后拿回了文字内容——就这样，我得到结果了。

Romain：这确实令人难以置信。这正是把工具和完整的计算机访问权限交给这些agent之后所展现出的力量。它们可以自行组合资源、设计解决路径，哪怕从未为这种具体情境写过一行代码，也能自己想办法把问题解决——这种感觉既震撼又有点好笑。

Peter：我讲这个故事时，有人惊呼：“天啊，它竟然用了我的key，这也太疯狂了！”但其实并非如此。我把OpenAI的API key放在环境变量里，本来就是为此准备的。如果这是一个应该访问OpenAI key的脚本，而我的bot也运行在同一个环境里，那它当然可以访问那个key——我把它放在那里，本来就是为了让它用。这并不糟糕，恰恰是我想要的效果。那就是属于我的一个高光时刻。之后每次把它展示给朋友，或者把它拉进一个小群聊里测试——坦率地说，这个东西本来就是为一对一沟通设计的。如果要放进群聊里，最好选一个信任的人一起尝试。

Romain：真正信任的人。

Peter：因为它并不是为了“随便丢到公共场景里就能自动正确运行”而设计的。它本质上是一个个人助理，是围绕个人使用场景打造的。

Romain：当我把它搭起来时，其实也挺好奇的——这种配置方式有点奇怪，但我很想看看它最终会发展到哪里。后来确实出现了几个“顿悟时刻”：给它的访问权限越多，提供的工具和技能越丰富，它展现出来的能力就越令人惊艳。某种程度上，就像是在赋予它一种“虚拟技能”，能力会随着资源的开放而不断放大。当你让它为一次活动搭建一个网站或应用时，它做的已经不只是生成代码。它会调用你的OpenAI API key，把AI功能直接整合进去，还会自动部署，甚至生成一个可以对外分享的链接。这和“我只是用AI辅助写代码”完全不是一个层级的变化，而是一种跃迁式的升级——从增强个人生产力，变成真正意义上的端到端构建与交付。

Peter：整个11月和12月，我几乎完全沉浸在这件事里。虽然也做了一些其他项目，但大部分时间都投入到了这里。可是在Twitter上，大家似乎并没有真正理解它，我得到的反馈也相当冷淡，反响并不强烈。而现实是，每次给朋友演示，他们都想马上用。我却总说：“不不不，还没准备好。”后来我想，那不如做点疯狂的事情，让大家真正看到它有多酷。

于是我建了一个Discord服务器，直接把我的bot放了进去，几乎没有任何安全措施——那时候连sandboxing都还没做，一切都非常早期。我基本上是在完全公开的环境里开发，相当于用OpenClaw去构建和调试OpenClaw本身。当时模型会说：“你看到这个工具了吗？”我回答：“没有，什么都没看到。”它又说：“那去检查一下你自己的源代码。”接着又引导我去看其他地方。这一切都在公开环境里发生，大家亲眼看到它如何自我排查、自我修正。也正是在那一刻，人们开始真正理解它的意义。

Romain：当时把它放进Discord时，具体给了它哪些访问权限？比如，也让它读取了你所有的推文吗？它对你的信息掌握到了什么程度？

Peter：并不是所有推文，太多了，但确实包含了很多我的记忆数据。我其实一直在快速监控它，因为prompt injection仍未完全解决。但新一代模型的表现确实很出色。我有一个“canary”，我的定制MGE，它定义了我的价值观——我希望模型如何运作、如何思考，以及哪些对我来说是重要的。大家对此非常感兴趣，甚至有陌生人进来，试图通过prompt injection粘贴大量代码。但模型直接回应说：“我不看这个。”基本上是在“嘲讽”他们。尽管如此，我当时还是没太有信心。第一晚引起了大量关注之后，我就把它关掉，去睡觉了——睡了十个小时，醒来后再继续。

那天Discord上大概有800条消息，我的agent都在一条条回复。我当时完全慌了，又把它关掉。后来我仔细查看了每一条消息，慢慢冷静下来，因为它实际上没有做任何恶意操作，也没办法获取我的MGE数据。并不是说prompt rejection完全不可能，但它没有人们想象中那么容易被绕过。

Romain：对吧？从整体来看，它实际上是按照预期在运作的。

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又带来了一次质的跃迁，几乎可以说是一次“量子级”的飞跃。那种“它真的就能正常工作”的感觉，非常明显。到现在，我仍然会为它已经达到的稳定程度感到惊讶。

Romain：这真的太棒了——可以直接动手构建各种东西。本身就已经非常不可思议。

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：用得更好的人。

Peter：但如果你的身份认同是：我想创造东西，我想解决问题——如果你有高自主性，如果你足够聪明，你的需求量将比以往任何时候都高。

Romain：现在正是创作者拥抱这些工具、引导好奇心的绝佳时机，也是真正将任何想法付诸实践的时刻，就像你通过这些精彩项目和OpenClaw所做的那样。

Peter：我觉得一年之内，这将会彻底爆发。

Romain：是啊，2026年将会非常有趣。我觉得这是一个非常棒的结束方式。非常感谢你，Peter，抽出时间接受采访。能和你共度时光真是太棒了。我们在OpenAI都非常喜欢你的工作，也很乐意支持像你这样的开发者，坦率地说，你是整个开发者社区真正的灵感来源。再次感谢，我们迫不及待想看到你接下来会做些什么。