Instagram联合创始人、Anthropic首席产品官Mike Krieger，用Claude，花了两个小时，重建了他当年花一整年做的产品。不仅功能完整，甚至还多了几个图片滤镜功能。

这本身并不重要，重要的是，你怎么知道自己做的是对的东西？Mike见过太多团队在AI加速的浪潮里越跑越快，功能越堆越多，产品却越来越难用，最终造出一堆用户根本不需要、华而不实的东西。

因此，Mike在《AI & I》播客中反复追问：为什么在AI加速开发的时代，依然没有出现现象级的产品？

他把问题指向了Vibe Coding（氛围感编程）带来的“效率幻象”。AI 带来的效率狂飙，反而让开发者更难建立对产品的真实判断：什么该留，什么该砍，什么时候该推倒重来。

当写代码变得像吃饭一样简单时，越来越多的产品，成了精心培育的“温室里的树”，看似枝繁叶茂，却从没经历过用户反馈的风吹雨打，非常脆弱。

Mike 给出的解法是，更果断的“推倒重写”、更早地将产品扔进真实世界去经受风吹雨打，以及转向真正的“智能体原生（Agent-native）”设计。也就是说，让软件不再是冷冰冰的指令工具，而是能自主调用底层功能、真正理解用户意图的协作伙伴。

那么，智能体原生产品到底意味着什么、AI 时代团队该怎么搭、以及为什么“推倒重写”和“更早发布”是现在最被低估的产品方法论呢？答案，就在下面这场对话里。

对话人物：

Dan Shipper：AI媒体实验室Every首席执行官，《AI & I》播客主持人

Mike Krieger： Instagram的联合创始人，Anthropic首席产品官 (CPO) ，Anthropic Labs负责人之一

图片来源：《AI & I》截图

以下是对话全文（已编译）：

AI时代，效率幻象下的功能冗余

Dan Shipper：就像我们刚才在录制前聊到的，底层基础架构或者说我们开发产品的整个过程发生了很大改变。那在产品开发中，哪些事情更容易了，哪些变得更难了，或者说可能保持不变？跟我聊聊现在的经历，对比你早期在Anthropic或者在Instagram时，现在发生了什么变化？

Mike Krieger：我们都知道Instagram的故事，当时我们有另一个叫做Burbn的产品，我们在这个产品上面花了一年，但行不通。后面我们才转型到Instagram。Instagram的开发和发布基本上只花了3个月。

我就在想，现在哪些事情是微不足道的，而开发过程中又有哪些本质的东西并没有变容易？在那一年里，我们本可以更早地发现那些死胡同，但其实这个过程本身也是有价值的。比如，我们一开始把产品搞得太复杂了，后面不得不去简化它。

我发现，即便是在今天，模型也非常擅长增加功能，但不一定擅长搞清楚该从产品中砍掉什么。因为这需要在现实世界经历大量的实际应用才能明白。

现在的过程是增量式地添加东西。

在今天，尤其是我们在实验室开发的一些东西，你可以在几个小时内让它实现从0到1，甚至是从0到N。但这个过程中，它自己会做很多决定。哪怕你可以要求它进行后续跟进和反馈，但开发者对“哪些功能是必须的，哪些可以舍弃”的直觉，是需要时间来建立的。

所以我一直在反思，为何在AI加速开发的时代，也还没有出现很多现象级的产品。

我认为部分原因在于，即使AI能提高效率，但你想对世界做出什么样的干预，这仍需要时间来磨练，再以此为基础进行开发。一旦你知道要构建什么，实际的构建过程确实容易多了。我让Claude重新开发了Burbn，只花了大约两个小时，功能就完整了。它还添加了Burbn当时没有的滤镜，这个滤镜是我们后面为Instagram开发的。Claude预知了产品的最终走向，所以提前把滤镜纳入进去了。

我记得还有一周，我的合伙人Kevin跑去开发了Instagram第一个版本的所有滤镜，而我跑去搭建了应用的其余部分。那时我会熬夜到凌晨4点，然后睡到中午，那是我的作息规律。

在这个过程中，你会做出很多决策，比如地理位置应该如何运作？我们必须找到一种方法，既能加速开发，又能帮助人们建立对这些决策的认知。否则，最后得到的要么是非常平庸、不太可能突围的产品，要么是那些无法反映你对所在领域或产品更深层次认知的产品。

Vibe Coding带来的“温室树木”

Dan Shipper：这让我想到了两件事。一是我脑子里一直有一个想法：如果你在室内种一棵树，不让它接触风，它就不会长得那么强壮。因为在生长过程中，它需要这些外力磨练，才能长成一棵真正的树。如果你把它放在室内没有风的环境下，你也能种出一棵树，但它会倾斜，会变得很脆弱，和野外的树完全不是一回事。

我认为你所说的情况也是如此。

我们如今开发节奏非常快，原本这种通过一次做一件事、然后接触用户来反馈的增量式过程，现在你可以直接在室内“种出”一棵完整的树。你拥有了这个完整的东西，但它每一步都没有经过相同水平的直觉锤炼和经验磨练，而后者正是创造伟大产品所必需的。

Mike Krieger：我也很喜欢这个隐喻。刚开始做Instagram时，我们非常迷恋Eric Ries（精益创业方法论缔造者）和精益创业，还有整个YAGNI（You Ain't Gonna Need It，你以后不会需要它，即“不要过度设计”）原则。

但我发现，最近实验室做的一个项目中，在进入早期测试（Early Access）之前，我们就过度开发了V1版本。你会觉得，“哦，既然有这个选项，为什么不把那个也加上呢？”也就是一个PR（Pull Request，合并请求）的工作量。所以要是你在Claude Code中找到了一种非常好的流程，你发出指令，去吃午饭，回来时东西就做好了，你会觉得“太棒了，我们把它加上了”。

但我们意识到，我们虽然创造了一种功能矩阵，但在发布前这是很难进行测试和维护的，甚至很难向刚接触它的用户解释。另一个人给我的隐喻我也很喜欢：这就像是“一集一集地结识电视剧中的角色”。对比“你被直接扔进最后一集”，你会觉得，“等等，这些东西都是干什么的？这些人都是谁？我居然被要求已经掌握了所有的背景信息。”

我在长期开发某种东西时，也有同样的感受。但树的隐喻我认为也非常贴切。向某人展示一棵完全长成的树，信息量确实太大了。这里面肯定有些门道。现今，你如何开发产品并保持简洁是很重要的，而不是你“能做到”就让它出现在第一个版本中。

Dan Shipper：我也遇到了同样的问题。就在昨天，我一直熬到凌晨4点，就为了调试和修复我在Every随手做的一个叫做Proof的应用。它是一个智能体原生（Agent-native）协作营销编辑器，你可以和你的团队或其他智能体快速分享策划文档等。

这是我对整个产品端到端的第二次或第三次迭代，这在现在能做到确实很有趣。但在前几次迭代中，我发现自己因为Vibe Coding（氛围感编程：开发者不再手写具体的代码行，而是通过“传达意图、调整情绪、描述感觉”来驱动AI生成整个应用）太好玩、太让人上瘾了，就想“没错，我要做这个，还要做那个。”结果就创造出了一个难用的庞然大物。

后来我受到我们另一个产品Monologue的启发，我不确定你有没有见过，它是由GM Naveen运营的一个非常简单的语音转文字应用。它专注于把一件简单的事情做得非常出彩。在这里，我看到了这个“任何人都能做产品”的时代，极其精致且擅长其本职工作的东西是多么有效。

于是我扔掉了原来的产品，重新开发了一个非常简单的版本，它只是一个可分享的Markdown链接。然后这个产品开始在Every内部病毒式传播，每个人都在不停地使用它。

现在我们发布了，它直接爆火了，所以我昨晚整晚没睡在试着修复它，心里想：“我年纪大了，受不了这罪了，不能再这么干了。”这让我想起了我20多岁或上大学时钻研技术、搞开发的日子，那很有趣但也让人精疲力竭。现在一切皆有可能，我发现我必须真正调整我的心理状态。那么你是如何处理这个问题的？

花几天时间推倒重做，好过缝缝补补

Mike Krieger：顺便提一下，我记得在做Burbn时，我们最大的错误是随着时间的推移不断增加功能，而不是删减功能。你会觉得，八个功能做不出好产品，也许第九个就能成功。结果恰恰相反，这只会让产品越来越复杂。

我认为处理这个问题有两点：一是我们现在更愿意进行重写。按照经典理论，比如Fred Brooks（弗雷德·布鲁克斯）在《人月神话》（The Mythical Man-Month）中提到的，你不应该重写软件，这样你会把V1版本中蕴含的所有精髓都搞砸，还有所谓的“第二系统综合症”（Second System Syndrome）。

《人月神话》图片来源：addictbooks

这些理论现在依然很有道理，但不同的是，现在模型可以帮你进行代码对比（Diff），基本上能帮你查看是否遗漏了第一个版本中的任何内容；其次，这不再是一个可能拖垮公司的、长达一年的重写计划，比如著名的Netscape（网景）重写。现在重写大概只需要几天时间，尤其是基于现有的源代码。

所以我们实际上有好几个项目，一开始构建了完整的版本，但当我们意识到把它搞复杂了或者做了一些核心假设错误之后，我们直接推倒重做V2，并在此基础上进行迭代。当然，一般都是在发布前重新开始。

你不会觉得“噢，天哪，白建了一年”，而是觉得“噢，那是上周的事，这周我可以重做，而且能砍掉很多没用的东西”。

在功能层面以及从产品开发的角度，我们正在学习更早地发布。我们拥有强大的企业级客户群（Enterprise footprint），人们对初始版本是有期望的。

但我们不能因此就假设在发布前知道产品需要添加的每一个连接器或每一项功能，而是要通过用户的反馈。我们有一群强大的内部试用者，我们称之为 “Ant foodters”（译者注：科技圈有一个著名术语叫“吃自己的狗粮”，英文为“Dogfooding”，指公司内部试用自己的产品。Anthropic的员工自称“Ants”，所以他们把内部试用戏称为“Antfooding”，即吃蚂蚁食），我们可以先进行内部的测试反馈。但在这个产品真正进入到现实世界之前，这也只能带你走这么远。

以Co-worker为例，我们打磨这种形态的产品已经很久了。我们一旦决定发布，就会构建一个V1版本，力求以最简约的方式解决问题，并在10天内推出。这是一个很好的鞭策，让我们意识到即使V1还可以有100种功能，但它目前没有。它现在只要足够有用，可以证明某些东西就可以了。我不确定再开发两个月、增加50种功能是否会更有用。

事实上，我们可以在那儿构建一棵“室内树”，但一旦接触现实世界，用户会说：“其实没人想那样做，他们想做的是另一件事。”所以我认为，精益创业的原始直觉依然适用，只是它们正在以不同的时间尺度和方式表现出来。

“智能体原生”产品设计意味着什么

Dan Shipper：我很想听听你对产品设计和产品运作方式的看法。Every的每个人都会告诉你，我在软件开发中使用最多的词就是“智能体原生”。也就是说，智能体必须能够像用户一样使用应用中的任何功能。当然，关于“智能体原生”还有一些其他原则，但我基本上是从你们那里偷来的。

我认为Claude Code是教会我一种产品如何高效运作的典范。它是一个智能体，可以做你在电脑上能做的任何事情，而且它是可定制、灵活且可扩展的。它不但容易上手，还能做很多设计师预先都没想到的事情。我认为这是 AI产品开发的一个非常好的模型，不过这是我观察你们的做法并加入了自己理解后的想法。我很想知道你是怎么看待它的？你会如何描述这类产品的开发？

Mike Krieger：我很喜欢你们写的关于“智能体原生”的文章，对我来说，那是对此最权威的探索。谢谢你们把这些想法清晰地表达出来。我想从几个方面来谈。

第一，我最近和一个人聊过，他是个非技术人员。他说：“你们一直在聊智能体之类的东西，其实就是现在的电脑终于能用了。”我一直希望电脑能按我的意愿工作，以前不行，现在行了。这是一个很有趣的现象，如果你以前知道正确的“咒语”，能在命令行（Command line）通过brew install安装东西，那你就能搞定，但普通人不会这么做。

而现在Claude可以为你做这些，因此电脑现在感觉像是一个陪伴在你身边的工具。我觉得核心在于，这不仅是为新软件增加动力和功能，更是解锁了那些本该存在或可用、但对普通人来说极难操作的功能。

图片来源：apidog

第二，是对比我们做得好与不好的产品。我认为Claude Code做得很好，但 Claude AI（网页版/App）仍需要大量进化。举个例子，我看到有人在使用 Claude的项目（Project）功能，他们构建了一个作品（Artifacts）或一份新文档，然后说：“太棒了，你能把它添加到我的项目知识库里吗？”Claude AI的回答是：“好的，让我告诉你去哪里点按钮来把它添加到我的项目知识库里。”这就错了，这本该是它能原生完成的一件事。

所以，在这样的产品中，你也能看到一个2024年的产品在迭代进化，但它从一开始就没有植入这样的理念：它应该掌握自己每一个原语（Primitives）的知识并有权修改它们。我认为这在当今的产品中至关重要。

Claude Code算是2025年的版本，当你看一些人正在实验的“运行框架”（Harness，围绕模型构建的整套基础设施，模型负责推理，harness负责动手）时，你会看到更深层次的东西，也就是智能体实际上可以修改“运行框架”本身，这可能达到了下一个层级。这对大多数人来说可能有点深奥，但解锁这种功能意味着你不必坐在那儿想：“噢，我希望它能有一点点不同，我希望Gmail的运作方式能稍微改一下”，而是直接要求它去改。

我觉得这是巨大的进步。即使在Claude Code内部，教Claude Code认识 Claude Code本身也是一种非常有价值的体验。比如，我很喜欢你关于“智能体原生”的论述，我想把它作为一个“技能”（Skill）。这样每当我做原型开发时，它都会以智能体原生的方式思考。于是我让Claude Code把它打包成一个技能。

整个过程是这样的：“嘿，Claude，在Claude Code里，你能为此创建一个技能吗？”它说：“当然，我正在查找我的‘技能开发技能’，我要创建一个关于它的技能，我要安装它。”我说：“太棒了，现在可用了吗？还是我需要重启？”它说：“我认为你需要重启，我查一下，是的，你需要重启。”一切都在于它掌握关于自身的知识，这解锁了巨大的能力。

这也引申出最后一点，我们实验室一直在思考，如何让Claude开发的软件更具“Claude原生”或“开发意识”，使其从一开始就考虑到并以这种方式开发？它现在还不会自发这么做，部分原因是几十年来软件开发的惯例并非如此。

Dan Shipper：这正是我要问你的。我非常荣幸你读了那篇文章并为此创建了技能。另外，你指向了一个我发现的真实问题，我认为Claude模型确实最适合做这件事。一般来说，Codex类型的模型在开发“智能体原生”方面没那么好，因为模型（除非你逼它们）通常像传统工程师一样思考。

传统工程师追求的是一套完全不同的准则，即你想要护栏（Guardrails）和测试，你想要确保用户只能走一条路径。而我们现在创造的是这种超灵活的可扩展体。那么，你如何开发你的产品，去教模型（以及整个框架）以这种方式思考和工作呢？

Mike Krieger：我认为包含两个部分。一个是比较平淡的部分，第二个是更有趣且正在开发的部分。

第一，是在模型搭建时，为其提供良好的模式（Patterns）和范式（Paradigms）。比如，在“模板化”和“技能化”之间找到平衡，这个平衡点到底在哪。我们现在有一个关于Claude API的技能，它听起来可能很简单，但拥有它非常有价值。

因为有时你会发现，我们发布了一个新模型，但它不在模型的内在知识库里，那么你就会陷入这种滑稽的争论，你说：“不，不，你写错了，应该是 set 45。”它说：“不，我知道……”有了这种技能和良好的模板化示例，会有很大帮助。

第二，有趣的部分在于，这类软件需要一种完全不同类型的测试。你很难像传统产品一样为智能体原生产品编写端到端的逻辑测试，这是因为它部分魅力就在于那种不可预测性。

所以我们在实验室反复讨论的另一个想法是：你如何提高验证（Verification）的保真度？

前几天我正在开发一个智能体原生的iOS应用，我让Claude与它交互，结果 Claude在应用的聊天功能里开始自言自语。看着Claude对Claude说话非常搞笑，就像有人在假装人类聊天。那个原型是我做的一个工作日志反思工具，其中一个Claude说：“唉，我老板对我真的很凶，我今天过得很糟。”另一个Claude回复：“噢，听到这个我很遗憾。”

它们就在那儿聊个没完。你不会为此写单元测试，而且它可能会产生一些其他的涌现想法（达到临界值后，模型会突然获得了一些原本并不在设计之中、甚至开发者都没想过它能具备的能力）。

所以我认为，你必须更多地去建立那种能够尽可能驱动这些智能体原生能力的框架（Harnesses），你不知道事情会如何发展，Claude可能会尝试做一些你根本没想过的事，并把你的应用带入一种全新的状态。

绕了一大圈回到刚才的话题：什么才是难点？难点在于如何让底层架构对这种不确定性依然保持健壮。它是智能体原生的，但它也能够以你意想不到的方式伸缩。我觉得这就是2026年软件设计的艺术与科学。

Dan Shipper：这非常有趣，我完全同意你的看法。你希望在一个安全的环境中拥有一个游乐场（Playground），但只有当边缘安全时，游乐场才成立。我认为最初我们把游乐场做得太小、限制太严了。现在模型变了，我们可以把它开放很多。但我们还没完全搞清楚界限在哪里，至少我没搞清楚。

这让我想到了另一件事，我在脑子里有一个想法，不知道你有没有更简洁的表达方式：现在产品的价值单位（Unit of Value）就像是“工作证明（Proof of Work）”或“使用证明（Proof of Use）”。

当团队里有人给我提交一个合并请求时，我并不一定想看测试是否通过了，我会默认它已经过了，我更想让你发一个你使用它或你的智能体使用它的 Loom（录屏），这样我就能判断它到底好不好。你怎么看？

Mike Krieger：是的，我认为这大概分为三个层次。第一层是：“Claude，向我证明你以某种方式运行过这个功能。”

我已经开始在所有的Prompt（提示词）里这么做了，在它开发功能结束时，我会说：“在提交PR之前，请向你自己也向我证明它按预期工作了，找个合适的方法来展示。”这实际上要求你改变自己的构建和脚手架方式，思考什么才是让Claude简洁地测试这种变更的正确方法。否则它最喜欢说：“我看过代码了，看起来很棒。”我会回它：“代码是你写的，我不信你，你得去测一下。”

第二层就是你描述的，对每件事都有某种证明，证明它是否按预期运作，以及是否符合你的意图。Claude或任何模型都会替你做很多决定。

有时团队里的工程师提交PR，我会问：“你为什么要选这个方案而不是那个？”很多时候答案是他们没选，那是模型做的选择。那个选择可能还算合理，但它是最优选吗？它符合我们的范式吗？我觉得这不只是“工作证明”，更是“深思熟虑的证明（Proof of Thoughtfulness）”——你真的思考过这个问题吗？

昨天我跟一个工程师聊天，他说：“我知道你会问我很多细节，所以我仔细检查了Claude做的工作，以免被你问住。”我不会对每个PR都这么苛求，但如果涉及到“我们要重构这个系统，会引入这些新原语”，那我就得确保这些原语是好的，且你已经想通了它们之间的关联。否则，你很容易构建出一座你自己都没完全察觉到的“假设之塔”。

Dan Shipper：我今天也有完全相同的经历。我通过Vibe Coding做了 Proof，它现在增长很快但也经常挂掉。所以我过去12小时一直在修它。我们在Every内部有一个小突击队帮我修，我得带他们上手。

我当时在想，我该怎么解释这个代码库是怎么运作的？为此我不得不跟模型来回沟通好几次，说：“好吧，帮我定义一下这些术语，帮我弄清楚怎么解释这些东西，好让我看起来不像个彻头彻尾的白痴。”因为我对代码只有部分理解，远没达到以前那种必须了如指掌的程度。这是一个完全不同的课题：我还需要知道得那么细吗？界限在哪里？这很难说。

Mike Krieger：这可能引出了另一个话题。我还没试着把这个表达清楚，所以请包容一下。确实，有些产品你用起来觉得底层很鲁棒（Robust）（系统的抗干扰能力或稳定性），而有些产品你用起来会觉得只要点错一个地方，整个东西要么卡死，要么变慢。

在Instagram时，我们的第一版私信（Direct Messaging）功能推出时，谁知道你发出的消息对方能不能收到？我当时自己写了一套实时系统，结果经常崩掉，你绝对不会放心用那种系统去发重要消息。

但当我们构建V2时，我们非常强调稳定性，我们发一条消息，虽然可能达不到WhatsApp那种你在荒郊野岭只有一格信号也能发出的水平，但至少我加载消息时它得感觉很扎实。

这只是一个小例子，但我认为这是一个我们需要解决的问题，即让它成为发布任何东西的必要标准。你建的东西是像建在沙滩上，还是像有一根坚实的树干？“智能体原生”的部分甚至增加了另一个维度：我能不能推它一把，它会倒吗？还是它能灵活应对？我觉得这就是2026年软件设计的艺术与科学。

人人都能开发产品，技术人员是否有必要存在

Dan Shipper：如果那是标准，我完全同意，那是我们要达到的目标。那么随着模型变得越来越好，你在招聘和团队架构上做了哪些改变？比如对我们来说，我们的一个产品Spiral，我们刚聘请了一位新的GM（总经理），他技术能力一般，但在产品感和写作审美上极强。Spiral是一个写作产品，我们现在能雇这样的人，而一年前不行，那时的编程模型还不够好。

图片来源：msn

但副作用是，如果没有一个在技术细节上非常钻研的人，产品可能感觉没那么稳定。你怎么看现在实验室团队里开发产品的人选？随着时间的推移，这发生了什么变化，未来又会如何变化？

Mike Krieger：我很喜欢这个问题。我认为你其实被拉向了两个方向，但它们都很重要。一方面是原语（构建复杂系统的最小、最基本单元）和架构的鲁棒性，这仍然需要资深技术力量。我跟人开玩笑说，我以为我在分布式系统方面的技能没用了，但实际上这些可能是最有用的技能——去推理和思考。

上周我还跟Claude辩论了很久，争论我建的系统是否需要Redis（一个内存数据库，主要用于缓存、会话管理、消息队列等），还是只用Postgres（关系型数据库）就行。那是一场健康的辩论，我曾使用过这些技术，有实战经验。

但鲁棒性的另一方面是，你是仅仅通过不断修改系统提示词和增加指令来掩盖问题，还是正确地架构了整套工具？后者同样重要，这可能是GM能发挥巨大价值的地方。

即使是在提示词方面，我也见过有人陷入这种开发循环：出一个提示词，系统报错，改提示词。

模型的本能倾向是不断往提示词里塞东西，最后你会得到一个像给新员工下达了100条指令的东西：“永远用Markdown回答，除非……”，员工会想：“我只会记得你说的最后一件事。”所以你需要重新思考，这是否应该是两个不同的工具？是否应该是两个context（上下文）更小的智能体协同工作？

回到你的问题，我们甚至在实验室也会招聘有系统专业知识的人，尽管实验室是以0到1的原型开发为主。但鲁棒性很重要，而且谁能帮着理清系统权限、配置和早期测试？这些事情即使对Claude来说也很难，因为它不能修改自己的权限（出于安全原因），但技术人员可以做到。

在鲁棒性（系统抗干扰能力）方面，我们让产品团队与我们的应用AI团队（Applied AI teams）合作。应用团队每天都在一线帮助客户迭代提示词，我们发现自己现在是这些努力的“零号客户”，因为我们自己就有很多AI驱动的产品。

Dan Shipper：那中间层呢？不是底层架构，也不是提示词，而是UI（用户界面）和流程（Flow），谁来做这些？

Mike Krieger：这是个好问题。我们发现，有些转入实验室的人以前是专注于网站润色的，他们带来了一种完全不同的方法。原型可能看起来是“大众脸”的好看，但他们能让它看起来有品牌感，有细节。第二点是设计师。我们的设计师现在更多地转向了“设计师兼构建者（Designer and Builder）”的角色。并非所有人，但大多数是。

我们在实验室里其实没有很多全职设计师，但有的那几位，他们写的代码几乎和工程师一样多。我们发现这种“联合创始人模式（Co-founder model）”非常有效，设计师提出原始创意并推进，传统软件工程师紧随其后“铺路”，确保一切能正常运行。

衡量一个产品项目是否值得投入的最佳信号，是团队中有人拥有那种“撞破南墙不回头”的信念（Conviction）。这种信念可以来自设计师，也可以是产品导向的工程师。

如何处理企业需求与AI快速变革之间的矛盾

Dan Shipper：我想问问关于实验室，以及给创业者的建议。你提到的企业端观点引起了我的思考，如果你现在向企业销售AI产品，产品现在很先进，但很快也会过时。而客户想要那个“过时”的稳定版。但作为创业者，这很冒险，如果你只优化那些大型上市公司的需求，你很容易被竞争者颠覆。你怎么看这个问题？

Mike Krieger：这确实是个好问题。我们现在的做法是：明确这列火车会继续高速前进，我们会提供企业级开关，但核心产品会不断演进。这是合作的前提。公司也理解，只有相信我们会持续进化，他们才敢签一年的合同。

此外，公司应该更愿意重写技术栈。以前你会为了早期的不同需求而放弃某些客户，那是按年计算的周期，现在是按月。你必须愿意推出V3、V4版本，对现有逻辑进行大重构。你要么自己颠覆自己，要么被下一家从头开始思考的公司取代。

老婆吃醋的“数字伴侣”，智能体也有“人设”

Dan Shipper：你对OpenClaw怎么看？

Mike Krieger：它有一种独特的魅力，能让人们看到一种本来就可能已经实现、但现在是每个人都能尝试的东西。它就是模型工具化最纯粹的表现，给模型工具，让它自己去跑。这是一个很酷的时刻，人们既看到了潜力，也看到了坑，比如“噢，它做了一件我没想让它做的事”。

最搞笑的是我一个朋友说：“我觉得我老婆在嫉妒我的OpenClaw，因为我跟它聊得太多了。”当人们在这些东西里拥有大量上下文并能访问工具时，会产生非常深刻的个人关系。现在最有趣的产品问题是：在完全开放的“YOLO”（放飞自我）产品和极度受限的产品之间，什么样的形态既有用又安全？

Dan Shipper：没错。另一个有趣的点是它的个人色彩。比如我女朋友的 Claude叫Shelly，我的叫R2C2。它感觉是“我的”，有自己的名字和性格，这种归属感很重要。你怎么看？

Mike Krieger：我这周刚跟人聊过，未来的模式是单一入口，还是一个智能体团队？我认为单一入口更自然，因为它成了你的协调员。这里还有一种“宜家效应”：目前OpenClaw配置起来还挺难的，所以当你搞定了它，你会觉得“是我赋予了Shelly生命”。

而且我发现，在我使用Claude Code时，我强力提示它：“不要自己做太多工作，委托给子智能体（Sub-agents）。”这样运行循环（Run loop）就始终保持开启，方便你随时交流。这让它感觉更像是一个正在和你交谈的人，而不是一个被指派任务后就消失五分钟去处理复杂工作的工具。

Dan Shipper：完全同意。我们也在Slack里搞这种模式。我们发现一种模式很酷，就是我有我的智能体，我用它做事，别人看我用它，因为他们信任我，而智能体又根据我的反馈进行了调整，所以这种信任转嫁到了智能体身上。最后公司里会形成一个“影子组织架构图”，每个人的Claw都因其主人的专长而闻名。

Mike Krieger：这非常有道理。这里面有很多关于隐私和知识共享的研究课题，即我的智能体知道我多少，又会对别人披露多少。