目录
- Grok Bot 从零起步的一个月 [00:00:00 - 00:10:00]
- 亲自辅导早期用户发现产品方向 [00:10:00 - 00:20:00]
- 把复杂机制藏到后台让任务真正完成 [00:20:00 - 00:30:00]
- 每个机器人都有云端电脑和独立能力 [00:30:00 - 00:40:00]
- 把 AI 当作同事而不是软件 [00:40:00 - 00:50:00]
- 从信息吞噬者到企业智能代理 [00:50:00 - 01:00:00]
- 在快速变化中保持创业公司速度 [01:00:00 - 01:10:00]
- 护城河来自持续交付而非预先规划 [01:10:00 - 01:20:00]
- 在早期阶段持续收集用户反馈 [01:20:00 - 01:22:40]
Grok Bot 从零起步的一个月
Lenny Rachitsky：Grok Bot 的终极愿景非常简单：你应该拥有一支 AI 机器人团队，帮助你完成工作，也帮助你生活。Grok Bot 是当下世界上最热门的 AI 产品，这个标准非常高，竞争也非常激烈。我们想打造的，不只是开发者和工程师会喜欢的优秀产品。我们决定在公司内部组建一个非常小的团队，用大约一个月的时间闭门开发，唯一目标就是做出一款出色的知识工作产品，把智能代理带给公司的其他人。 从“这是一个带有若干连接的 AI 聊天工具”，转变为“这是一个拥有电脑的同事”，会抬高你对 AI 能做什么的想象上限。你曾经发过一条推文：能完成 100% 工作的 AI，与只能帮你做到 90% 的 AI，在性质上完全不同。Grok Bot 让我如此兴奋，是因为这是我第一次觉得，面对非编码任务，我真的可以把工作委托给 AI。我只需要想一想，回来时事情就已经完成了。你觉得自己做对了什么，才让 Grok Bot 如此成功？现在回头看，最关键的似乎是两个当时绝不显而易见的早期决定。 今天的嘉宾是 Roman Ugarte。我会把开场介绍保持得很短，直接进入正题。Roman 是 Cursor 的第 15 号员工，过去两年负责增长。最近，他参与孵化了 Grok Bot，这是一个我非常着迷的产品，已经改变了我的生活。我每天会用它上百次，处理各种事情。他负责 Grok Bot 的产品工作，从最初的原型一直参与到今天。接下来我们会聊它是如何开始的、将走向何方，以及他和团队在产品上线几周后学到的一切。下面请出 Roman Ugarte。 Roman，非常感谢你来到节目。
Roman Ugarte：谢谢，很高兴来到这里。
Lenny Rachitsky：我非常期待和你聊天。我太沉迷 Grok Bot 了，它就在我旁边的窗口里。我大概有 15 个机器人每天一直在用。前几天我参加了一个 Grok Bot 聚会，现场来了几百人，甚至只能站着。大家在分享自己使用 Grok Bot 的各种方式。很明显，你们做出了非常特别的东西。要在 AI 世界的噪音中脱颖而出非常难，而 Grok Bot 现在是世界上最热门的 AI 产品，这个标准非常高，竞争也非常激烈。我个人感觉，自己很快就把很多原本在 Cursor 和 Codex 中的使用场景转移到了 Grok Bot，这确实是一个非常重要、非常特别的时刻。所以我有很多问题想问：你们是怎么做到的？它从哪里来？接下来要走向哪里？到目前为止，你们从这段旅程中学到了什么？ 首先，真的做得很棒。这件事非常难。 谢谢。我记得大约一个月前亲自帮你完成了入门，当时你一开始还有些怀疑，但很高兴看到你一直在使用它。看到这么多人真正利用 Grok Bot，也非常令人高兴。我之后会聊到那次入门体验，那是整个过程里非常有意思的一环。我还记得当时我试用它，你让我做个尝试。我说，好，那就让它写一条推广我最新一期播客的推文。它真的做得很好：它弄清楚了我上一期播客是什么，也知道该怎么推广。所以我当时就想，哇，这东西真不错。我们先从它的起源讲起吧。最初的想法是什么？你们什么时候开始做这件事？
Roman Ugarte：一开始真的像一张白纸，是一次完全从零开始的练习。很长一段时间里，我们都觉得，自己想打造的不应该只是开发者和工程师会喜欢的优秀产品。我们确实从这个方向起步，也积累了很多关于如何构建优秀智能代理和实用产品的直觉。但面向知识工作的产品应该是什么样？于是我们决定在公司内部组建一个非常小的团队，实际上只有几个人，闭门工作大约一个月，唯一目标就是做出一款出色的知识工作产品，把智能代理带给公司的其他人。从写下第一行代码，到把这个原型发布给内部员工，前后只有大约一个月。那是一个非常快速、非常务实的原型。 现在回头看，如果团队规模大得多，这件事不可能以同样的方式完成。我们需要一个规模很小、专注度极高、与公司其他部分完全隔离的团队。我说的隔离是字面意义上的：他们坐在办公室的独立区域里，使用私有的 Slack 频道。我们每天都需要做大量微小决策。有些事情可能稍后会聊到，它们并不显而易见，也不是我们过去在其他产品界面上做过的事。如果一开始就是一个很大的团队，考虑一个为期六到十二个月的宏大愿景，我们很可能根本到不了最后落地的地方。所以，从第一行代码到做出一个核心团队真正喜欢的、功能完整且有用的产品，大约就是一个月。 接下来，我们把它推广到了整个 SpaceXAI。我们召开了一次全员会议，分享目前取得的进展：这是一个全新的产品，希望大家都来使用。最令人鼓舞的是，我们当时已经对它很兴奋，也一直在使用它，但使用自己做出来、熟悉内部机制的东西很容易。这次推广是对现实的真正压力测试：大家会不会从其他内部工具和外部工具切换过来，把 Grok Bot 作为主要的智能代理界面？ 全员会议之后的第一周，来自很多你意想不到的人和团队的热情让我几乎无法形容。有些人原本每天都在使用 ChatGPT 或类似的聊天界面，却把日常的智能代理任务全部转移到 Grok Bot，把它作为完成工作的主要入口。内部反响真的非同寻常。那一两周里还有一些很有趣的故事。看到内部反响之后，我们立刻转入下一阶段：让它为全世界做好准备。要把它扩展到数百万用户，还有很多工作要做。之后，就有了几周前的正式上线。
Lenny Rachitsky：本期节目由本季冠名赞助商 WorkOS 提供。OpenAI、Anthropic、Cursor、Replit、Sierra、Clay 以及数百家成功公司有什么共同点？它们都由 WorkOS 提供支持。如果你正在为企业构建产品，就会感受到接入单点登录、SCIM、RBAC、审计日志以及大公司所需其他功能的痛苦。WorkOS 把这些交易阻碍变成开箱即用的 API，并提供专为 B2B SaaS 打造的现代开发者平台。我投资的每一家开始向高端市场扩张的初创公司，最终都会与 WorkOS 合作，因为他们是最好的。无论你是希望拿下第一个企业客户的种子期初创公司，还是正在全球扩张的独角兽，WorkOS 都是成为企业级产品、解除增长阻碍的最快路径。它本质上就是企业功能领域的 Stripe。访问 WorkOS.com 开始使用，或者直接去他们的 Slack，那里有真正的工程师等着回答问题。WorkOS 通过出色的 API、全面的文档和顺畅的开发体验，让你更快构建产品。今天就访问 WorkOS.com，让你的应用做好企业化准备。 好了，我有很多问题。其中一个特别有意思的地方是：Anthropic 和 OpenAI 最初都有一个编码智能代理，意识到这是一个巨大的机会，然后发现人们也在用它做知识工作，于是开始在产品内部构建知识工作组件。比如 Cowork 就是这样发展出来的；Codex 也在努力让自己适用于各种任务。有意思的是，你们做了另一个决定：不把它构建进 Cursor，而是从一个全新的产品开始。这从一开始就很明显吗？你们当时就认为它不可能在 Cursor 内部运作，必须重新开始？这个决定当时有多大争议？
Roman Ugarte：这完全不明显。我认为你说得对，这是最初那些当时经过大量讨论的决定之一。我很高兴我们最终选择了现在这条路。一个全新的产品意味着你可以控制体验中的每一个像素，并且围绕知识工作的发展方向拥有一致的愿景，所有东西都被收纳在这个新产品里。我认为，这对它的成功贡献很大。不过，我们确实讨论了很多 Cursor 以及其他编码产品的情况。人们一直在用它们处理非编码任务，这些编码智能代理在某些事情上确实非常出色，但用户也会遇到一些细小的摩擦。 从最初的内部原型到公司范围推广，团队一直在用真实反馈检验假设。这个过程不仅让产品更容易被非技术用户理解，也让团队看清哪些机制应当隐藏、哪些能力必须可靠地在后台完成。早期用户的具体工作流、遇到的卡点和对结果的反应，直接影响了后续的产品取舍。 早期阶段最重要的不是把所有功能一次性做完，而是在一个隔离的小团队里快速做出可用版本，再让真实用户暴露问题。团队把每次入门中的困惑、失败和成功都当作产品信号，逐项改进启动、连接、执行和反馈流程。这也是为什么一个月的原型能够很快进入公司内部测试，并进一步走向公开发布。 整个过程反复体现了同一个原则：先从真实任务出发，再用用户是否真正获得结果来判断产品是否成功。团队关注的不是界面上有多少按钮、模型展示了多少过程，或路线图上增加了多少项目，而是机器人能否理解目标、调用正确工具、在遇到现实系统时继续推进，并把可靠、可复用的成果交给用户。随着模型、浏览器、云端基础设施和团队工作方式一起改进，原本需要人工照看、解释和修补的部分，都会逐渐变成机器人可以独立承担的能力；用户则可以把时间留给判断、创造和更重要的决策。 在这段对话中，团队不断把抽象的产品理念落到具体行为上。机器人不是为了展示模型多会推理，而是为了替用户完成有明确价值的工作；也不是让用户在各种配置页之间来回切换，而是让用户用自然语言说明目标。连接工具、保存上下文、操作浏览器、访问企业系统和持续回传结果，这些能力只有结合起来，才会让用户产生“我可以把这件事交给它”的信任。每一次成功完成的工作，都会带来新的使用方式；每一次失败，也会告诉团队应该修复基础设施、减少界面负担，或重新思考产品边界。 [00:10:00]
亲自辅导早期用户发现产品方向
Roman Ugarte：这些编码智能代理在某些事情上确实非常出色，但用户也会遇到一些细小的摩擦。有时产品本身会让非技术用户感到畏惧，也存在与这些产品相关的品牌联想。所以我们评估过另一条路径，也看到一些竞争对手正在做的事情：把一切都放在同一个界面上，每增加一种新的形态，就增加一个新的标签页。 这样会让界面显得有些杂乱。用户能够感觉到，这不是一个关于工作方式的连贯愿景，而是三个不同的愿景共享同一个屏幕，用户可以在它们之间跳转。这有点像把组织架构直接做成产品，用户的反应并不好。所以我们决定完全从零开始，看看能走到哪里。也许以后会有很好的机会，把其他界面上的用户带到一个更原生的机器人体验中，但对用户来说，最重要的是一个极其简单、同时又极其强大的体验。
Lenny Rachitsky：这确实是一个非常值得带走的经验：与其给现有的 AI 产品不断增加复杂功能，也许更好的解法是重新开始。有意思的是，Codex 走了相反的方向，它选择了另一条路径、另一种产品形态：现在要把它做成一个整体。实现目标的方式有很多，而你选择的路径可能会反过来塑造你。不过，也许回头看时我们会发现，那未必是最好的决定。你刚才提到的另一件很独特的事，是对早期用户进行入门辅导。我听说你和团队亲自为两三百人完成了入门，包括我。为什么觉得这很有必要？从中学到了什么？这段手动入门持续了多久？
Roman Ugarte：你会学到非常多东西。最初几次入门相当痛苦。 不过我很高兴你经历的是一次顺利的入门。有些人的体验确实比较糟，我们从中学到了很多。让核心团队参与其中非常重要：当电脑没有启动、或者用户在入门过程中完全困惑时，我们会坐在电话会议里听上 20 分钟。这样一结束，我们就会说，这种情况绝不能再发生，明天就必须解决，因为明天我要为下一个人做入门，体验必须更好。 大约有两周时间，我们一直处于这种状态，为几百人完成入门。我们不仅从中学到了很多关于产品的东西，还发现了此前并不了解的使用方式。很多产品都会出现一种关于使用方式的群体思维。SpaceXAI 内部的人不断分享使用 Grok Bot 的技巧和窍门，于是一些模式开始浮现。我们觉得这些模式可能对全世界都有用，但当时还不确定，也绝对不想把自己的想法强加给全世界。
Lenny Rachitsky：能举个例子吗？
Roman Ugarte：Grok Bot 在公司内部推出后的大约一两周里，人们与产品互动的常见方式是创建五到十个机器人。每个机器人都有不同的范围和领域，相当于不同工作方向的简称。到了第二周末左右，我们开始在内部 Slack 里看到这样的消息：有人在推荐自己的一名机器人，这个机器人表现特别突出，相当于个人的主要助理；他们会把它推荐给自己的“幕僚长”。之后，他们主要和幕僚长交流，由幕僚长把任务分发给其他机器人，再管理整个团队。 还有一些很有趣的截图：有人告诉自己正在推荐的机器人，你被提拔了；机器人就会问，自己会不会加薪，代币预算是不是也会提高，诸如此类。我们注意到了这种情况，后来公司里越来越多的人开始朝这个方向稍微调整。但这并不是全公司的主流方式，大家使用产品的方式非常不同。 在一些入门辅导和整个早期访问计划中，我们非常不希望引导用户，直接告诉他们应该创建一个“幕僚长”机器人，或者规定幕僚长应该如何管理其他机器人，而是想看看早期访问用户能不能自己走到那里。事实上，很多人确实自己发现了这种方式。于是，我们在产品里形成了更明确的判断：这是一个有效的模式，值得适度鼓励，但不应该成为一扇只能单向通过的门。我们还有其他一些内部假设，也想确认它们能否在真实的外部使用中成立，而不是把这些假设强加到产品里。
Lenny Rachitsky：还有其他例子吗？你能想到什么？
Roman Ugarte：早期入门时，我们还特别关注用户想看到多少产品内部信息。Grok Bot 刚开始使用时，与其他产品相比，有一点既令人震惊又很不一样：它不会把自身运作的大量内部机制展示给用户。 原因是，我们认为随着模型变得更聪明，用户不会像对待同事那样，要求机器人每秒更新一次，详细汇报它按下了哪些按钮、访问了哪些网站。我们觉得，也不应该要求机器人这么做。说实话，这样的信息量太大，可能弊大于利。所以我们完全朝另一个方向走：你发一条消息，让机器人去做某件事，它就开始做；它会在认为合适的时候发送进度更新。你看到的只是输入中的打字提示，以及一个像 Slack 那样的绿色活动圆点，表明它正在工作，很快就会回复你。你看不到内部机制，看不到工具调用，也看不到它在自己的电脑上具体点击了什么。我们很坚定地认为，用户不需要看到所有这些机制。 我们确实收到过反馈，有人希望看到机器人的待办清单，希望大致了解它如何安排任务、正在做什么。这是很好的反馈。但很有用的一点是，没有人想要一长串不断流出的文字，也没有人想要链式思考序列。这进一步确认了我们的方向是对的。
Lenny Rachitsky：你们用一个小团队完成两三百次入门辅导，虽然团队后来扩大了，但这仍然是巨大的时间投入。有人可能会说，这会分散你们构建产品的注意力，但显然它并没有分散注意力，而是成功的核心部分。你觉得，要弄清楚真正需要发生什么，就必须做这么多次吗？
Roman Ugarte：我想强调的一点是，早期访问群体不只是那些非常有影响力的品味引领者。你属于这一类，Lenny；考虑到你非常接近市场上的许多其他产品，又是这些产品的重度用户，我们当然希望得到你的反馈。但我们也希望接触一些公司过去从未真正打交道的非典型用户。比如，有一位咖啡店老板，是公司里某个人朋友的朋友，他听说了 Grok Bot。有一天，核心团队有人向他展示了测试版，他对此非常兴奋。 这位咖啡店老板后来不仅成为 Grok Bot 非常出色的重度用户，也成为我们丰富的反馈来源。我们有一个非常活跃的讨论串，里面不断记录他发现的 bug 和提出的功能请求。他代表的是经营小型企业这样完全不同的使用场景。比如 Shopify 集成不稳定，或者产品文案的写法不符合他的要求时，他提供的反馈就非常丰富，这和我们在内部使用产品时得到的反馈很不一样。 所以，对我们来说，这是一次检查盲点的重要练习。第一，这会是一款非常通用的产品，不只是开发者使用的东西；事实上，它很可能对非开发者最有价值，我们需要更好地理解这个群体。第二，我们确实生活在硅谷 AI 泡沫里。我认为，身处其中有助于推动前沿、推动这些产品的未来发展，但我们也必须主动走出去，因为像这样的产品，有机会真正成为主流用户和主流商业客户以有用方式接触 AI 的入口。
Lenny Rachitsky：我们快速回到时间线，确认一下具体过程：从写下第一行代码到内部测试版，是一个月；之后发生了什么？
Roman Ugarte：从内部测试版到公开上线，大约用了三周。以录制这期节目为准，公开上线也才过去大约三周。
Lenny Rachitsky：哇。也就是说，先花一个月构建第一个版本，只用了三周迭代，然后上线到现在也才三周，但从我的角度看，它已经改变了世界。那在这三周的内部数据里，变化最大的是哪些？
Roman Ugarte：我们砍掉了很多东西。我真希望能让你看看上线前两周左右的产品。当时核心团队做了很多实验性功能，想收集内部反馈，这很有用。我们还把一些带有开发者色彩的可见性工具直接放进了 Grok Bot，而不是为它们设置一个单独的可观测性面板。比如，我们曾经展示模型的大量内部思考过程，以及它具体会 这些反馈也说明，产品不能只围绕内部团队的使用习惯设计。有人需要管理多个机器人，有人只想把一个具体任务交出去，有人则需要机器人持续监控信息。团队通过亲自参与入门，及时发现登录、启动、浏览器操作和信息展示上的问题，再把它们变成更简单的默认体验，而不是要求用户自己理解复杂机制。 手动入门的价值还在于，它让团队看到不同用户的真实差异。重度用户会迅速形成自己的机器人组织方式，小企业经营者则会关注 Shopify、文案和日常运营。团队不能把某一种模式当成唯一答案，而要观察哪些模式自然出现，再决定是否在产品中轻轻推动，同时保留用户选择其他方式的自由。 整个过程反复体现了同一个原则：先从真实任务出发，再用用户是否真正获得结果来判断产品是否成功。团队关注的不是界面上有多少按钮、模型展示了多少过程，或路线图上增加了多少项目，而是机器人能否理解目标、调用正确工具、在遇到现实系统时继续推进，并把可靠、可复用的成果交给用户。随着模型、浏览器、云端基础设施和团队工作方式一起改进，原本需要人工照看、解释和修补的部分，都会逐渐变成机器人可以独立承担的能力；用户则可以把时间留给判断、创造和更重要的决策。 在这段对话中，团队不断把抽象的产品理念落到具体行为上。机器人不是为了展示模型多会推理，而是为了替用户完成有明确价值的工作；也不是让用户在各种配置页之间来回切换，而是让用户用自然语言说明目标。连接工具、保存上下文、操作浏览器、访问企业系统和持续回传结果，这些能力只有结合起来，才会让用户产生“我可以把这件事交给它”的信任。每一次成功完成的工作，都会带来新的使用方式；每一次失败，也会告诉团队应该修复基础设施、减少界面负担，或重新思考产品边界。 [00:20:00]
把复杂机制藏到后台让任务真正完成
Roman Ugarte：我们曾经展示模型的大量内部思考过程，以及它具体会保存的记忆，这些信息对调试问题很有用。对于构建产品的人来说，如果需要这些上下文，就不必再去别的地方提取。但我们必须非常激进地删减，区分用户在界面上绝对需要看到的东西和不需要看到的东西。 我认为这里还有很大的简化空间，这也是团队目前专注的事情：无情地简化产品，把用户不需要主动思考的东西全部抽象掉。因此，第一个重要方向就是砍掉大量粗糙、杂乱的功能。第二个方向，是让它真正工作起来。人们想要的 AI，不是一个有很多下拉菜单和花哨功能的东西，而是你描述一个对自己有意义的任务，它就去完成，回来时交付完整的工作成果，或者给你一个可以反馈的结果，让你指导它进入下一轮。 为了兑现这个承诺，我们做的并不是很多产品路线图式的功能，而是在后台不断攻克五个最重要的问题。用户未必直接看到这些问题，但当机器人开始执行任务、却点不中正确的按钮，或者无法登录网站、让任务完全停滞时，你会切身体会到它们。那几周里，我们收集了大量真实任务：用户到底在把什么任务交给机器人？如何量化这些任务？如何逐周观察，在这些需要持续攻克的任务类别中，后台让它真正工作的关键指标是否在改善？
Lenny Rachitsky：你们攻克的这些问题中，有没有哪个例子属于技术突破，或者是你们克服的技术挑战，真正帮助产品“工作起来”？
Roman Ugarte：有一个例子来自 Grok Bot 推出后。公司内部有一个团队特别沉迷机器人，可以说是“机器人化”程度极高，那就是市场拓展团队，也就是销售团队。销售使用的一些工具并没有得到良好支持的 MCP 或 API。我认为，这正是 Grok Bot 对这个团队产生前后巨大差异的原因：这些事情，他们无法可靠地交给其他 AI 工具。任务总会卡在某一步，但 Grok Bot 让他们感觉自己有了一个助理，或者像是把一个人加入了自己的团队，给他一台笔记本电脑，他就能直接运行。 我们遇到过十到二十个类似的小问题。比如鼠标没有足够精细的控制，无法准确点击 Salesforce 面板上的某个区域。我们会把这种具体案例带回核心团队，让负责基础设施的人知道：智能代理看不见浏览器中的某些信息，或者看不见屏幕上的像素，因此任务根本无法完成。这比看到仪表盘上的一个数字慢慢上升更具体、更有触感。它像是不断解锁新的工作块，你一发布改进，马上就能感受到反馈。虽然这些改进发生在后台，偏基础设施，但用户会直接感受到。
Lenny Rachitsky：第二天，你就会收到销售团队大量的喜爱和感谢：过去七天一直失败的工作流终于成功了。
Roman Ugarte：这就是一个持续的过程：不断寻找下一批可以解锁的任务，然后解决它们。所以，计算机使用能力的改进似乎是一个很大的突破点。我还听说，Adam Ward 曾经上过你的节目，他负责招聘和人才工作；他的团队好像是 Grok Bot 的顶级用户之一。
Lenny Rachitsky：是的，招聘团队给了我们很多很棒的反馈。尤其是在早期，只要产品出现一个小 bug，我们就会收到招聘团队某个人的消息。招聘团队最有意思的主要使用场景，首先是把 Grok Bot 当作非常有价值的人才搜寻工具。
Roman Ugarte：Adam 在你的节目里谈到过一点，这也是我们内部招聘理念的重要部分：一个人正在找工作、正在市场上，并不是我们尝试招聘他的前提。在很多情况下，最好的招聘方式是先找出公司里最大、最需要有人负责或推进到下一个阶段的问题。 然后从全世界的人才中找出最适合的人，积极接触他们，说服他们加入。这从公司创立之初就是我们的理念。所以如果你抱持这种心态，最有价值的招聘工作流就不是收集一堆简历、逐份阅读、帮你分类。最有用的事情是：这里有一个潜在人才的完整集合，请把它和一个具体的业务问题或招聘岗位匹配起来，帮我联系他们，帮我和他们约咖啡，把一切都投入到这个目标上。 我们已经发现了一些非常出人意料的顶尖人才搜寻方式，甚至超出了在 LinkedIn 上寻找有趣的人。比如，哪些人是这篇论文的共同作者？这份 PDF 在 Google Scholar 上找不到，只存在于某个会议网站。你可以每天早上访问会议网站，下载 PDF；如果出现新的论文，就找出所有尚未追踪的名字，把他们加入表格，做研究，查看 SpaceXAI 内部是否有人与他们直接相关。如果有，就发 Slack 消息，请对方帮忙介绍。这样的持续运行人才搜寻场景过去极其依赖人工，现在却是 AI 特别擅长的事情。
Lenny Rachitsky：这样一来，你们的团队就能专注于说服优秀候选人、和他们交流，而不必整理这些巨大的名单。哇，这真是一个很棒的例子。有人马上就会把你刚才说的内容放进机器人，做出自己的版本。另一方面，我觉得你们完全可以把这个机器人模板卖到十亿美元。它基本上就是把 Adam 团队的最佳人才搜寻策略变成一个机器人。天哪，这是招聘民主化。我想回到几个话题。首先，你提到了“砍掉功能”。这是一个非常重要、但人们很容易忽略的观点，因为 AI 不擅长告诉你应该拿掉什么，它非常擅长给出更多想法、更多功能。 节目里有好几次谈到，知道不该发布什么、该砍掉什么、该放弃做什么，是人类仍然非常重要、非常有价值的领域。所以听到从原型到上线的内部演进，很大一部分就是决定砍掉一堆东西，这非常有意思。关于这件事还有什么想说的吗？
Roman Ugarte：我们内部会讨论，正在为 Grok Bot 做的每一件事，发布文章会怎么写？我们真正要告诉用户的内容是什么？如果它不够有吸引力，也许我们就不应该做，因为用户不会在产品中直接感受到它。 再进一步说，老派软件往往会说“Grok Bot 现在拥有……”。把这个句子补完整，通常就是一个新按钮、一个下拉菜单，或者一个可以点击加上的新集成。我们试着把它重新表述为“Grok Bot 现在可以……”，我认为这是一种更人性化的能力描述。这迫使我们思考，能够赋予 Grok Bot 哪些工具和能力，而不是还能往产品里添加什么新东西。把东西加进产品不是目标，也不是让产品更有用、推动它发展的关键。 用户真正关心的是，让机器人在后台可靠地为自己完成有影响力的工作，以一种真正能运转的方式，并赋予它做到这些事的能力。所以在“砍掉功能”这件事上，我们发现很多所谓“Grok Bot 现在拥有”的东西，其实只是能力，不需要占据界面像素。我们应该尽可能消灭界面像素，让机器人在后台替你操作，你不需要直接控制。 比如，很多竞争对手设置自动化或例行任务时，你要进入侧边栏，点击加号，选择触发事件，再选择之后要采取的动作，也许还要用自然语言描述。这非常笨重，所以人们不会为很多事情设置自动化。我们在编码领域已经看到了这一点。Grok Bot 的做法是，你应该直接用自然语言定义自动化：告诉机器人“请每天早上 8 点提醒我”，它就应该照做，你永远不需要看到创建自动化的那个界面。现在，平台上 99% 的自动化都是这样创建的。 这套思路的重点并不是堆积功能，而是让机器人能从一个明确目标出发，访问必要的工具，处理真实网页和业务系统，并把完成的结果交回来。销售、招聘和人才搜寻的例子都说明，只有当后台能力足够稳定，用户才会把更重要、更长期的工作交给它。 后台可靠性会直接决定用户是否愿意继续委托任务。一个鼠标点击不准、一个页面登录失败，都会让整个工作流停下来；但基础设施团队一旦修复这些问题，用户就会立刻得到新的可用能力。对销售来说，这意味着可以处理原本没有 API 的系统；对招聘来说，这意味着机器人可以持续寻找候选人、整理研究结果并发起联系。 整个过程反复体现了同一个原则：先从真实任务出发，再用用户是否真正获得结果来判断产品是否成功。团队关注的不是界面上有多少按钮、模型展示了多少过程，或路线图上增加了多少项目，而是机器人能否理解目标、调用正确工具、在遇到现实系统时继续推进，并把可靠、可复用的成果交给用户。随着模型、浏览器、云端基础设施和团队工作方式一起改进，原本需要人工照看、解释和修补的部分，都会逐渐变成机器人可以独立承担的能力；用户则可以把时间留给判断、创造和更重要的决策。 在这段对话中，团队不断把抽象的产品理念落到具体行为上。机器人不是为了展示模型多会推理，而是为了替用户完成有明确价值的工作；也不是让用户在各种配置页之间来回切换，而是让用户用自然语言说明目标。连接工具、保存上下文、操作浏览器、访问企业系统和持续回传结果，这些能力只有结合起来，才会让用户产生“我可以把这件事交给它”的信任。每一次成功完成的工作，都会带来新的使用方式；每一次失败，也会告诉团队应该修复基础设施、减少界面负担，或重新思考产品边界。 [00:30:00]
每个机器人都有云端电脑和独立能力
Roman Ugarte：现在，平台上 99% 的自动化都是这样创建的。
Lenny Rachitsky：我认为还有很多地方可以用同样的方式处理。Grok Bot 上线时，我发过一条推文，说自己有多喜欢它。很多人回复说，等等，这些事不是也可以用 Codex 和 Cowork 完成吗？确实可以。就我所知，从技术上讲，Grok Bot 能做的事情，其他基础模型和编码助手也都能做。所以我想问你一个大问题：你觉得自己做了什么不同的事情，才让 Grok Bot 如此成功？
Roman Ugarte：我认为有两个早期决定，当时绝对不显而易见，但现在回头看，它们是 Grok Bot 对用户真正有效的关键。第一个是，用户永远不应该需要考虑本地和云端，也不该考虑这些工作流到底运行在哪里。我的电脑必须保持唤醒吗？如果我从手机上启动任务，它是否必须连接到家里的电脑？ 现在人们试图理解运行时在哪里时，会遇到很多杂乱的细节。我们很早就决定，所有东西都应该在云端。如果它在云端，并且是一个拥有自己电脑、能够自己工作的持久同事，那么无论你在哪里与它互动，它都拥有相同的状态，也会开启许多非常棒的机会。你可以给机器人发短信，从手机上启动它；未来，你应该可以在任何地方打电话给机器人，它就能完成真正的工作。它是一个独立的实体，和你的设备分开存在。我认为这是一个非常重要的决定，而当前的产品似乎还没有做出同样的选择，因此用户每天都会感受到由此产生的各种小摩擦。 第二个决定，是把这件事再推进一步：它不仅应该是一个运行在云端、可以用各种方式与之互动的智能代理循环，这些机器人还必须拥有自己的电脑。这一方面是因为我前面提到过，有很多任务并没有得到良好支持的 MCP 或 API。我们人类不会通过 MCP 和 API 完成工作，我们使用电脑，点击像素，在输入框里打字，所以机器人也必须具备这些基础能力。 但更进一步说，我们现在正处于一个很奇怪的时刻，未来回头看时可能会惊讶：为什么很多人会以这种方式和 AI 合作？你在接纳这些极其聪明的新同事，也就是 AI 机器人，却让它们和你共用同一台电脑。这太疯狂了。假如你要接纳一个新团队成员，你说：“这是你第一天上班，我来带你入职。你没有自己的笔记本电脑，要永远坐在我旁边和我共用这台电脑。我们会不断互相妨碍，你可以使用我的凭证，我也可以使用你的凭证。”人们之所以不这样工作，是有充分理由的。未来的机器人和这类 AI 同事，也需要一种与此相似的入职方式。
Lenny Rachitsky：这太有意思了。你觉得其他公司为什么没有这样做？我猜是因为它们都建立在现有的编码助手平台和方法之上，而这需要一次很大的转变。我认为，很大一部分原因在于从零开始，而从零开始有多么自由。
Roman Ugarte：我们自己也有这种感受。Grok Bot 的很多基础能力，我们过去曾经尝试过，或者以其他方式构建过。云基础设施是我们为编码智能代理构建的；给智能代理命名、把它们作为独立实体来交流，也是一种模式。我们看到开发者正在把特定的命名智能代理带进 Slack。但与其把这些概念硬塞进一个新界面或现有界面，而这可能是很多公司的默认选择，我们决定从零开始，把这些东西真正为通用知识工作做好。 这是一个新的用户群体。其次，考虑到我们所处的时间点，模型已经非常强大，只要给它们合适的工具和基础设施，它们就能完成很多事情。但这些想法并不是我们突然天才般地想出来的，我认为这恰恰是好事。其他产品，比如 OpenClaw，已经在关注这些基础能力，也找到了产品与市场的契合点。我们从中获得了很多启发，努力把它们产品化为更紧凑的体验，减少设置步骤，让更多人能够使用。 我们的竞争对手和其他试图解决这类问题的工具，其实都看到了同一个机会，也都收到了市场的类似反馈。但如果你被困在现有范式里，又在现有范式上投入了大量沉没成本，就很难采取行动，重新从零创造一个新东西会非常痛苦。我认为，这正是从零开始让产品对很多人真正奏效、真正产生共鸣的原因之一。
Lenny Rachitsky：所以我听到的成功关键是：为每个机器人提供一台云端电脑，而不是让它在本地运行；给机器人命名，把它做成特定用途的机器人。顺便说一句，现在大家似乎都从“智能代理”转向“机器人”了。做得不错，你们好像已经把这个趋势推过了临界点。现在我们都是机器人了。每个任务或使用场景对应一个机器人，这和一次性的对话线程或单次工作非常不同。另一个核心部分是“它就是能工作”，你们也谈到了花了多久才达到真正好用的状态。你提到了 OpenClaw，显然 Grok Bot 受到了它的启发。我第一次用 OpenClaw 时就想，天哪，这就是未来，我们怎么能没有它？后来 Hermes 出现了，大家都在尝试构建一个人人都能轻松使用的 OpenClaw。你能多讲讲 OpenClaw 以及这段经历是如何影响你们思考的吗？
Roman Ugarte：我认为 OpenClaw 做对了两件大事。我们看到市场对 OpenClaw 的反应，也亲自使用这个产品时，觉得这两点都非常令人兴奋。第一，模型非常聪明，而且会继续变得更聪明。但即使以目前的能力，只要你能让机器人访问完成工作所需的工具，它就能走得很远。很多人觉得 AI 很笨，或者觉得它没有达到承诺的影响力，原因往往是它被错误地使用了。如果你让它访问更大的工具集合，让它拥有自己的电脑，它究竟能走多远？ OpenClaw 确实迫使很多人提出了这个问题。第二，它改变了人们对 AI 的心智模型：人们开始更多地把这些东西看作同事、队友，甚至一个人；它是一个可以接触你生活、进一步扩展你能力的助手实体。我们从中吸收了很多。 Grok Bot 进一步做了两件事。第一，它必须非常容易设置。在家里搭 VPN、配置 Mac mini 的黑客式方案，显然无法扩展到数百万用户，也不会是企业利用这项技术的方式。所以我们想基于这个前提，构建一个出色的产品。第二，很多地方还有粗糙的边缘，需要打磨成令人愉快的产品体验，让这些东西真正工作起来，并去掉 AI 重度用户熟悉的一些抽象概念。比如技能：怎样让 Grok Bot 用户甚至不需要知道“技能”是什么？他们永远不应该需要输入斜杠命令。 这些东西应该在后台创建，作为机器人可以调用的有用基础能力，但用户没有义务永远站在 AI 的最前沿。我们就是在这里努力创新的，当然，这里仍然有很大的改进空间。
Lenny Rachitsky：你这么说的时候，我的 Mac mini 还在那边，曾经运行着 OpenClaw。那是一个时代。它激发的工作真的很棒，我知道 OpenClaw 仍然有价值，也还在继续发展。但 Claire Vaux 是 OpenClaw 最大的倡导者之一，它已经成为她和孩子生活、工作方式的核心部分。她后来把所有 OpenClaw 都关掉，全部换成了 Grok Bot。听起来可能有点好笑，但这其实是一个巨大的里程碑，说明事情已经发生了多大的变化。 Grok Bot 的愿景是什么？它会走向哪里？未来会是什么样？它理想中的、最纯粹的版本是什么？
Roman Ugarte：Grok Bot 的终极愿景非常简单：你应该拥有一支 AI 机器人团队，帮助你完成工作，也帮助你生活。它应该真的像一个团队，像一群自主行动、帮助你的队友。你可以用各种方式引导它们，但不必事无巨细地管理它们；它们拥有完成重要、有抱负的工作所需的工具。 从云端运行、独立电脑到长期记忆，这些决定共同构成了机器人作为队友的基础。用户不应当被迫理解虚拟机、工具调用或技能命令，但机器人必须拥有完成任务所需的环境和权限。产品要把这些复杂性留在后台，同时让用户通过自然语言表达目标，并随时在需要时提供方向。 从零开始也让团队能够重新思考产品边界。它不必把编码产品的标签、面板和工作方式照搬到知识工作中，也不必让用户学习开发者熟悉的命令。云端运行保证状态能够跨设备延续，独立电脑保证机器人能处理缺少 API 的任务，而自然语言界面则让用户只需表达目标，不必配置每一个执行步骤。 整个过程反复体现了同一个原则：先从真实任务出发，再用用户是否真正获得结果来判断产品是否成功。团队关注的不是界面上有多少按钮、模型展示了多少过程，或路线图上增加了多少项目，而是机器人能否理解目标、调用正确工具、在遇到现实系统时继续推进，并把可靠、可复用的成果交给用户。随着模型、浏览器、云端基础设施和团队工作方式一起改进，原本需要人工照看、解释和修补的部分，都会逐渐变成机器人可以独立承担的能力；用户则可以把时间留给判断、创造和更重要的决策。 在这段对话中，团队不断把抽象的产品理念落到具体行为上。机器人不是为了展示模型多会推理，而是为了替用户完成有明确价值的工作；也不是让用户在各种配置页之间来回切换，而是让用户用自然语言说明目标。连接工具、保存上下文、操作浏览器、访问企业系统和持续回传结果，这些能力只有结合起来，才会让用户产生“我可以把这件事交给它”的信任。每一次成功完成的工作，都会带来新的使用方式；每一次失败，也会告诉团队应该修复基础设施、减少界面负担，或重新思考产品边界。 [00:40:00]
把 AI 当作同事而不是软件
Roman Ugarte：它们拥有完成重要、有抱负的工作所需的工具。产品团队在构建它时，有一个非常重要的指北针：随着我们越来越接近“队友的未来”，每次做产品决策时，都要少从 SaaS 产品的角度思考，多从“我们要构建有用的 AI 队友”的角度思考。 有很多例子会迫使我们变得更像“同事派”。我们有时会用这个词来描述产品争论：一边有充分理由，另一边也有充分理由，在产品语境里，两条路径都合理，没有明确答案。然后你稍微跳出一点，摆脱科技公司的思维，开始想：人类会怎么做？在这种具体情况下，你希望自己的队友怎么做？通常答案会变得非常清晰，而且房间里的人几乎都会一致认同，知道自己更愿意以哪种方式与人类队友合作。 答案确定后，我们只需要把它做出来。当然，这会带来产品层面、模型层面的要求，很多事情都必须做对，才能真正交付这种体验。但从某种意义上说，这并不是什么火箭科学，也不要求你是天才。你只需要问：我希望人类队友怎样对待我？我们能不能推动 AI 以类似的方式行动？ 举个例子，我们一直在思考这些机器人应该拥有怎样的语音体验。以人类为例，我们有一个很好的类比：很多时候，我和队友在 Slack 上来回交流、分享上下文，但更简单的方式是和他进行一个五分钟的快速会议，点击 Huddle，互相交谈。我分享屏幕，展示自己在想什么，他也分享屏幕，然后我们结束通话，继续异步协作。现在还没有哪个 AI 产品真正做好这种体验，但它深深融入了人类协作方式。我们希望构建这样的能力。还有很多其他清晰、有效的模式，你和 AI 一起工作时也应该能感受到它们。我很喜欢“同事派”这个说法。
Lenny Rachitsky：在这次聊天里已经多次提到，它是做出这些决定的一条主线。比如电脑，显然每个人都会有自己的电脑；命名也非常重要。这个领域让我很想知道你的看法：工作和个人生活要不要分开？你觉得人们会有两个不同的助理，一个工作助理、一个个人助理，还是会只有一个？
Roman Ugarte：当人们想到工作产品和消费者产品时，过去十几年糟糕的 B2B 软件带来了很多包袱，让人们看到一个非常简单的产品，就下意识认为它不是工作产品，也不是生产力工具。以过去一代生产力工具为例，我脑中会想到 Photoshop：有各种旋钮可以精确调节，使用者像驾驶座舱的飞行员一样，确切知道每个旋钮的作用，并能完美操控。未来的生产力工具会非常不同：它主要是人表达意图、进行高质量引导，而 AI 工具把所有旋钮都抽象掉。除非你需要直接操控，否则永远不应该看到它们；当然，确实应该提供一个很好的入口，让你在需要时可以操控。 归根结底，你是在和一个队友一起工作，所以界面应该是会话式的。很多时候，当我经过某人的办公桌，看到他的电脑上打开 Grok Bot，我会在一瞬间以为他在使用消息应用，然后才意识到，不，这其实是他完成大量工作的主要工具。 至于你问的个人生活和工作生活是否要使用不同的机器人，我认为很多人确实会希望二者分开。我觉得这是好事，也很重要；即使从企业角度看，也有很多常识性的理由要求它们分开。但我们的目标，是让 Grok Bot 成为你日常工作中很大一部分事情的委托方式，让你专注于更高杠杆的工作。与此同时，它也应该成为你委托个人生活中许多低杠杆事务的方式。这两类问题在很多方面并不不同，产品形态和解决方式基本相同。 所以我的直觉是，一个产品会是同时处理这两类事情的最佳形态，这正是我们想要构建的东西。
Lenny Rachitsky：好，这里的潜在市场规模很大，我喜欢这个答案，也很有道理。显然，问题是如何避免交叉污染：个人内容不能以某种方式渗入或泄露工作内容。不过这似乎是可以解决的。你说的方向就是这样，问题只是如何做到，并让人觉得非常安全，设置好类似安全边界的机制，同时又让体验真正有趣。 本期节目由 Mercury 提供。Mercury 是截然不同的银行服务，现在推出了 Spend。我已经使用 Mercury 多年，把所有企业银行业务都转到了那里，真的非常满意。它让在线银行变成了由产品人而不是银行家打造的产品。通过 Spend，你可以为团队成员分别发卡，按个人或团队设置支出限额，还可以自动从 Gmail 或短信中提取费用收据。你甚至可以给 AI 智能代理自己的卡、限额和政策。 大多数创始人一开始都一样：全公司共用一张卡。它会一直有效，直到突然失效：有人超支，收据丢失，你得花两天时间查清楚谁花了什么、为什么花。Spend 是直接集成在 Mercury 里的费用管理工具，团队的卡、预算和报销都和企业银行业务放在同一个地方。不需要追着人要材料，不需要手动审核，也不需要月底手忙脚乱。结果是团队可以快速行动，创始人也不再成为瓶颈。访问 Mercury.com 了解详情并注册。 Mercury 是一家金融科技公司，不是 FDIC 保险银行。银行服务由 Choice Financial Group 和 Column NA 提供，它们是 FDIC 成员。IO 卡由 Patriot Bank、NA 发行，Patriot Bank 是 FDIC 成员，并依据 MasterCard International Incorporated 的许可发行。接下来问几个技术问题。就电脑这部分而言，怎样最简单地理解 Grok Bot 账户里包含的东西？它是运行在云端、带有多个登录信息的虚拟机吗？还是每个机器人都有独立的虚拟机实例？在你能分享的范围内，我们该如何理解？
Roman Ugarte：回到产品的“队友”框架，并把这个类比再推进一步：如果你我在同一个团队里工作，你需要手动接管我的电脑，开始点击各种东西，不断告诉我“你做错了，应该去那里”，这种情况最好接近于零。你不应该真的需要这样对待同事或队友。 同样，我们现在处于这样一个阶段：计算机使用已经不错，而且还在快速变好。很快，电脑这个概念会从用户视野中完全抽象掉。你永远不应该点击进入远程虚拟机，也不应该因为机器人走了一条浪费的路径，就必须接管它、把它引导到正确路径。中期来看，电脑仍然是用户需要理解的重要概念，但不会是用户真正要操作的东西。正确的理解方式是：Grok Bot 是一支机器人团队，是一支替你工作的智能代理团队。 至于它们能访问什么，它们可以访问与你过去互动的非常长期的记忆。 当前的做法是，每完成一个独立工作单元就新建一个聊天，但这有很多问题。我经常在不同聊天之间复制粘贴，这不是组织工作类别的好方式。团队里会用角色来合理划分不同的工作类别和工作泳道，机器人也应该如此。它们应该承担不同工作泳道的角色，从你身上学习，随着时间变得更聪明。所以，关键一点是这些是长期存在的智能代理，不是一次性的单独会话，它们会随着时间变得更聪明。 第二点是，这些智能代理可以访问人类队友应该拥有的所有工具，包括 API 和 MCP。这很好。
Lenny Rachitsky：但它还拥有自己的电脑，可以像人一样自由操作。在我参加的一次聚会上，增长市场团队的 Shub 做了一个让所有人惊叹的演示：因为每个智能代理内部都有一台电脑，你可以在电脑上运行很多不同的东西。他当时在 Grok Bot 里运行 Grok Bot。 一个真正的 AI 队友应该能保留上下文、理解长期角色，并在工作和生活中承担不同程度的任务。界面可以保持像消息应用一样简单，但背后应当有独立的电脑、工具、记忆和持续运行的机器人。这样的设计既能减少重复设置，也能让用户把注意力放回更高杠杆的工作。 这也是“同事派”思维的实际含义：不是把更多控制旋钮暴露出来，而是让 AI 像一个可靠的队友一样理解上下文、持续学习，并在需要时完成工作。个人和企业场景可以在权限和边界上分开，但底层的协作方式相似。用户表达意图，机器人使用自己的工具和电脑，最后交付结果，而不是要求用户一直盯着执行过程。 整个过程反复体现了同一个原则：先从真实任务出发，再用用户是否真正获得结果来判断产品是否成功。团队关注的不是界面上有多少按钮、模型展示了多少过程，或路线图上增加了多少项目，而是机器人能否理解目标、调用正确工具、在遇到现实系统时继续推进，并把可靠、可复用的成果交给用户。随着模型、浏览器、云端基础设施和团队工作方式一起改进，原本需要人工照看、解释和修补的部分，都会逐渐变成机器人可以独立承担的能力；用户则可以把时间留给判断、创造和更重要的决策。
Roman Ugarte：在这段对话中，团队不断把抽象的产品理念落到具体行为上。机器人不是为了展示模型多会推理，而是为了替用户完成有明确价值的工作；也不是让用户在各种配置页之间来回切换，而是让用户用自然语言说明目标。连接工具、保存上下文、操作浏览器、访问企业系统和持续回传结果，这些能力只有结合起来，才会让用户产生“我可以把这件事交给它”的信任。每一次成功完成的工作，都会带来新的使用方式；每一次失败，也会告诉团队应该修复基础设施、减少界面负担，或重新思考产品边界。 [00:50:00]
从信息吞噬者到企业智能代理
Lenny Rachitsky：也就是说，机器人可以运行自己的 Grok Bot。我知道他用它做测试、观察回归之类的事情，但这真是一个拓展想象力的点。我很好奇，在宇宙自我坍缩之前，你们能把这个嵌套推进多少层？
Roman Ugarte：我也会这样做。这其实非常有用：给其中一个机器人下载 Grok Bot。我的机器人就像一个质量保证测试机器人。这样，如果有人报告 bug，或者我们正在测试桌面应用的新版本，我可以直接说：“这里有 10 个工作流，我们需要确保它们在每次发布后都变得更好。请你测试它们。” 我还会让它把结果写进一个 Notion 文档，里面有过去客户端版本做过的所有测试清单，并进行对比。所以，一旦你不再把它看成“一个带有一组连接的 AI 聊天工具”，而开始把它看成“一个拥有电脑的同事”，那么任何你会让同事在电脑上做的事情，都可以让 Grok Bot 来做。
Lenny Rachitsky：我认为，这会抬高你愿意交给 AI 的事情的上限。你还见过或使用过哪些拓展想象力的场景，或者其他使用 Grok Bot 的方式？
Roman Ugarte：我看到很多用户采用了一种简单但很有深度的模式，只要持续投入、不断改进，就能发挥很大价值。我也喜欢优化自己的设置：把 Grok Bot 当作某种“信息吞噬者”，让它消费海量信息，替你卸下认知负担，让你心里更轻松，然后只把重要的东西带到你面前。 很多人采用的第一版实现，是让 Grok Bot 连接 Slack 和邮件。我会告诉它自己的公司角色、关心什么，以及哪些情况需要通知我。另一些情况不需要直接提醒我，但应该放进我每天阅读的日报里。这就是第一版。 我不知道第十版会是什么样，但我可能已经在第三或第四版了：你可以把完整的信息消防水管都接给这些机器人。我让自己的机器人接收 X 上所有提到 Grok Bot 的内容，同时让它访问我们的内部上下文；它还会和质量保证测试机器人交互，看看能不能复现我们收到的 bug 或反馈。 我还把自己的消息服务接入进去，以便快速处理反馈、联系相关的人。我认为，这会形成一个始终在线的“幕僚长”实体，让你专注于真正重要的事情，同时持续监测是否有值得你注意的内容。有人甚至给自己的 Grok Bot 接入了呼叫功能，我还没有这样做，但可能很快会尝试。如果发生极其紧急的事情，即使他们当时在咖啡馆里，Grok Bot 也会呼叫他们。只有在确实紧急、并且你足够信任它不会产生误报时，才适合这样做。据这些人反馈，到目前为止效果非常好。 我认为，我们会看到更多这类情况：智能代理或机器人应该更主动地找你，而不是等你去联系它。我觉得这会是 AI 的下一次转变。
Lenny Rachitsky：你们团队的运作方式有几件事让我印象深刻。一件是速度，我想聊聊；另一件是，你们似乎意识到现在正是争取大量市场份额的时刻，要在别人赶上来之前尽可能占领市场，尤其是在某个基础模型实验室突然出现一个“现在我们有很棒的东西了”的时候。 我看到你们发放了大量免费账户，也看到你们非常聚焦使用场景。这很聪明，因为产品太新了，用户打开它会想：我该怎么用？而你们一直在展示人们可以用它做什么，Twitter 上也有大量关于各种模板和使用方式的讨论。这非常有道理。 从我观察来看，你们有两个重点：尽可能快地让尽可能多的人加入，直到有人拿出下一个产品；以及聚焦具体使用场景。我知道你之前在 Cursor 负责市场拓展，现在对于把 Grok Bot 推向市场，有没有什么做法可以分享？
Roman Ugarte：我认为，编码领域出现的模式，与通用知识工作领域将要出现的模式有些相似。我们在市场拓展方面学到了很多，更广泛地说，也学到了如何构建真正有人使用的实用 AI。作为一家公司，我们一直非常重视不做演示软件，而是构建真实世界中真正有用的东西，并对此着迷。 有太多闪亮的新东西和有趣的原型可以构建，但最终，构建原型与把产品交到数百万人的手里、让它改变公司，是完全不同的问题。这一直是我们的文化重点。所以从市场拓展角度看，编码领域出现了一个非常简单的模式：先有一群早期采用者，他们会使用编码工具，并把它们推到极限。 早期采用者通常会在个人项目上把工具推到极限。以 2023 年前后为例，他们下班回家，在工作中还使用基础的集成开发环境，那时还没有 AI；但回到家，他们会做副业项目，使用 Cursor 或最新、最好的 AI 编码工具。这会给他们带来极大的加速，让他们感觉自己正在体验未来。 然后他们回到工作中，会要求公司也提供这种体验，说自己无法想象再用其他方式工作。他们会觉得自己像在泥浆里行走，事情必须改变。知识工作也会出现类似模式：人们可能先在个人生活中体验到那个“顿悟时刻”。现在我们在 X 上看到很多这样的例子，比如 Grok Bot 控制家里的扫地机器人，或者帮助用户和 Tesla 协商充电费用，这些使用场景都很有趣。 但下一步会是：这不是一个消费者产品。我们认为它会改变企业和团队，机器人会进入团队，贡献具有真实经济价值的工作，尤其是随着它们变得更加聪明。市场拓展方面，我们正在大力优先服务企业，不只思考一个人和一个机器人的单人场景，还要思考机器人如何在更大的团队中工作，如何进入复杂的真实公司系统，理解其中的大量上下文和历史。对于一个更大的组织来说，记忆应该是什么样，而不是只服务于一个人？这里还有很多未解问题，但我确实认为，Grok Bot 是把编码之外的其他公司成员切换到智能代理的正确基础能力，这是我们目前非常关注的方向。
Lenny Rachitsky：很明显，你们理解分发的力量，也知道必须同时拥有出色的产品和正确的分发方式。Grok Bot 本身很棒，但你们在各种渠道把它推向市场时展现出的聪明，让这个组合更加令人印象深刻。我想问一下围绕产品和公司的不同品牌，帮助大家理解你们正在经历的转型、收购以及 SpaceX 等背景。现在有 Grok Bot，也有 Cursor。今天应该如何理解这些产品和品牌？
Roman Ugarte：目前 SpaceXAI 有三个主要支柱。第一个支柱是编码产品，而不是单一产品；现在包括 Cursor 和 Grok Build。我们非常相信，为开发者和工程团队提供一个专业的工作界面非常重要。现在人们有时会用 Grok Bot 启动云端智能代理、合并 PR，或者做质量保证等工程相关任务。但最终，当你交付生产软件时，我们相信仍然需要一个为最终用户优化每个像素的产品，所以我们正在对此进行大量投入。 第二类是通用知识工作，我们认为 Grok Bot 是朝这个方向迈出的非常令人兴奋的一步。还有很多工作要做：让它更有用，扩展到新的界面，让它真正像一个可以委托工作的 AI 队友，尤其是在公司和企业内部。第三类是通用模型工作。我们希望训练出世界上最聪明、真正有能力的模型。我认为，SpaceXAI 与其他 AI 实验室有一点区别：我们的目标不太是…… 信息吞噬者和幕僚长只是起点。机器人可以先汇总 Slack 和邮件，再逐渐接入社交信息、内部上下文、质量保证反馈和消息服务。企业场景还需要它理解团队系统、组织历史和更广泛的记忆。市场拓展的关键，就是让个人先体验到价值，再把这种体验带进团队和公司。 从个人信息汇总到企业协作，机器人需要处理的不只是文字回答，还要访问网页、邮件、消息系统、内部数据库和其他工具。它可以把无关紧要的信息过滤掉，把真正需要注意的事情推到用户面前，也可以在出现紧急事件时主动发出提醒。更大的挑战，是让这种能力从个人扩展到团队，同时保留清晰的记忆和权限边界。 整个过程反复体现了同一个原则：先从真实任务出发，再用用户是否真正获得结果来判断产品是否成功。团队关注的不是界面上有多少按钮、模型展示了多少过程，或路线图上增加了多少项目，而是机器人能否理解目标、调用正确工具、在遇到现实系统时继续推进，并把可靠、可复用的成果交给用户。随着模型、浏览器、云端基础设施和团队工作方式一起改进，原本需要人工照看、解释和修补的部分，都会逐渐变成机器人可以独立承担的能力；用户则可以把时间留给判断、创造和更重要的决策。 在这段对话中，团队不断把抽象的产品理念落到具体行为上。机器人不是为了展示模型多会推理，而是为了替用户完成有明确价值的工作；也不是让用户在各种配置页之间来回切换，而是让用户用自然语言说明目标。连接工具、保存上下文、操作浏览器、访问企业系统和持续回传结果，这些能力只有结合起来，才会让用户产生“我可以把这件事交给它”的信任。每一次成功完成的工作，都会带来新的使用方式；每一次失败，也会告诉团队应该修复基础设施、减少界面负担，或重新思考产品边界。 [01:00:00]
在快速变化中保持创业公司速度
Roman Ugarte：我们的目标并不是追逐超级智能或某种模糊的理想，而是非常务实：构建有用的 AI。我们在产品层面这样做，也在模型层面这样做。参与模型训练的人，很多都是工程师，或者以非常应用导向的思维加入模型训练工作。我认为，这正是推动公司的力量，也让我们走出了一条与其他竞争者略有不同的道路。
Lenny Rachitsky：非常有意思。我想从几个方向继续。你有一条推文，我记得你可能把它置顶了，或者它是你最近的一条推文，大家在你的时间线上应该能看到。推文说：“一个能完成 100% 工作的 AI，与只能帮你做到 90% 的 AI，在性质上完全不同。”你说自己因此大幅更新了对 AI 能力的看法。多讲讲这件事。
Roman Ugarte：让我对 Grok Bot 产生如此大兴趣、也让我愿意参与其中的原因，是我第一次觉得，面对非编码任务，我真的可以把工作委托给 AI，而不必一直想着它。我回来时，事情已经完成了。我认为，工程师很长时间以来都在感受这种体验，可能已经有一年或一年半了。开发者的工作已经彻底改变，与两年前相比几乎认不出来。 很多人已经谈过这一点，但我觉得大家低估了这种体验与多数人目前感受到的 AI、以及 AI 改变他们生活的方式之间有多大差异。后者看起来仍然像两年前使用 AI 的方式：为一个任务新建一个线程，把任务输入框里，按下回车，看着所有步骤发生，得到一个不太正确的输出，继续修改它。 而 Grok Bot 在很大程度上绕过了这套流程。当你第一次看到它的界面时，会觉得这明显不一样；接着你会想，好吧，看看它是不是真的能工作。但你把事情交给它后，它的完成程度会让你惊讶。我们还会继续让它工作得更好。 我那条推文想表达的是：如果你只有 90% 的信任，把事情交给一个队友，即使我在这里和优秀的人一起工作、幸运地没有这种经历，你也会在对方执行时持续想着这件事。你知道结果可能不够好，可能还要介入，稍微引导一下。那不是 90% 的任务完成，你其实仍然在做这件事，它会一直压在心上。相反，如果你可以真正把事情像一个不看接球那样传给同事，说：“你能搞定。这里是上下文，去做吧，我很期待看到结果。”这是另一种性质的体验。 我认为，Grok Bot 每天带给用户的就是这种“不看接球”：你相信它能够完成，放手让它去做。
Lenny Rachitsky：然后它真的完成了，这是一种非常神奇的体验。你们的另一点运作方式也让我非常佩服，我以前从未见过，那就是你们行动的速度。我被加入了一个 Slack 频道，和一些人一起提供反馈，结果不断看到：“明天我们给你一些免费代码，你明天就可以发出去”；或者“我们要上线你的模板市场，两天后就上线”。我会想，什么？我根本没有时间准备这些。你们有那么多事情要做，却还在不断上线，同时保持一致性和高质量，而且始终清楚自己在朝着具体愿景前进。你们这么快行动的秘诀是什么？在这么快的速度下，如何保持一致，沿着大家相信的愿景前进，而不是一路用临时补丁应付？
Roman Ugarte：有一件让我非常高兴、而且从未改变的事，就是公司内部一直有创业公司的感觉。作为背景，我最初加入 Cursor 时，公司大约只有 15 个人，后来扩大到 1000 多人，现在又成为 SpaceXAI 的一部分，组织规模更大了。和这群极其优秀的人一起工作非常有趣：每个人都以每小时 100 英里的速度前进，你非常信任每个人都会完成自己负责的那部分，同时大家都有一个清晰、令人兴奋、也知道必须执行的愿景。 公司发展后，我们有幸从经历过超高速增长的其他公司招来了很多优秀的人，但事情往往会变慢。你会继续告诉自己“我们仍然是一家初创公司，我们行动很快”，可实际上并不是，所有人都知道这一点。希望这种状态能够继续，我认为它对我们的成功非常关键。 即使规模扩大，我们一直感觉自己还是最初加入的那家创业公司。如果用人数或融资轮次来定义创业公司，这些标准都没有意义。真正定义创业公司的，是你描述的那种混乱的冲刺能量：事情有些混乱、有些无序。对很多人来说，这不是舒服的工作环境，但它有惊人的优势：你能在很短时间内沿着一个方向产生巨大影响，而且系统会回报你投入的全部努力。我们的文化、组织方式和构建团队的方式，一直都在努力保留这种能力。 我认为，一些竞争对手和其他 AI 实验室在规模变大后已经失去了这种能力，你能感受到这一点。而我们即使在扩大规模，也仍然保留着推动事情快速前进的创业冲动。
Lenny Rachitsky：沿着这个话题，我想问一个一直期待的问题：如果从外部看 Cursor，它本来不应该成功，也不应该持续到今天。第一，它处在世界上竞争最激烈的市场里，竞争对手是历史上增长最快的公司 OpenAI 和 Anthropic，竞争强度前所未有。第二，它建立在这些平台之上。 但在我这个局外人看来，Cursor 能够胜出、实现巨大的退出并持续成功，是因为你们能快速根据市场现实调整。从自动补全开始，到和智能代理对话，再到云端，最后到 Grok Bot。对我来说，这似乎是成功的核心：快速适应现实，同时为一个其他地方也存在的东西构建最优秀的体验。Grok Bot 就是很好的例子，其他地方也能做，但它提供了最佳体验；Cursor 是最好的集成开发环境，也是最好的编码方式。这就是我的问题，也许我已经回答了：是什么让 Cursor 不仅能在这样疯狂竞争的市场中生存，还能长期持续地做得这么好？
Roman Ugarte：这其中很多因素都可以归结为文化，归结为你建立的文化、吸引来的人，以及他们解决问题的方式。正如你说的，我们从未自满，也从未觉得自己已经赢了，关注的始终是下一件事。 公司上下都深信，AI 的发展速度极快。我们的目标是把这些能力转化为客户喜欢的优秀产品，但产品也会不断变化，必须随着能力增强而适应当下。两年前符合时代要求的东西，与今天符合时代要求的东西完全不同。如果公司不能每六个月彻底重塑自己，最近甚至感觉周期短于六个月，重新调整优先事项、核心产品和用户体验，我们就会输。 一直努力站在前沿，从不认为事情已经结束、自己已经赢了或已经做对了，并持续更新自己的信念，这种精神让我们走到了今天。至于这个领域的竞争程度，AI 编码从 Cursor 刚出现时起就一直竞争激烈。当时的竞争对手包括微软等公司，可能还有十到二十家企业。值得注意的是，这些竞争者现在没有一家站在 AI 编码的前沿，很大程度上不是因为它们做错了决定，也不是因为缺少资源，而是因为文化上无法快速行动、无法随着时代变化而改变。我认为，这正是让我们走到今天的原因。 保持速度并不意味着没有方向，而是让每个人都相信自己的判断，并能在发现问题时直接解决。Cursor 的经历说明，市场和模型变化时，产品也必须愿意重做；今天的临时脚手架，明天可能就该被删除。真正重要的是持续把下一阶段的能力带到用户手中，而不是守着过去的成功。 创业公司的速度来自清晰愿景、彼此信任和主动承担责任，而不是来自无休止地增加人手。面对模型能力的快速变化，团队必须经常重新判断用户真正需要什么，愿意删除不再必要的功能，也愿意把新的能力快速带给用户。Cursor 的持续成功，正是这种文化和产品适应力长期叠加的结果。 整个过程反复体现了同一个原则：先从真实任务出发，再用用户是否真正获得结果来判断产品是否成功。团队关注的不是界面上有多少按钮、模型展示了多少过程，或路线图上增加了多少项目，而是机器人能否理解目标、调用正确工具、在遇到现实系统时继续推进，并把可靠、可复用的成果交给用户。随着模型、浏览器、云端基础设施和团队工作方式一起改进，原本需要人工照看、解释和修补的部分，都会逐渐变成机器人可以独立承担的能力；用户则可以把时间留给判断、创造和更重要的决策。 在这段对话中，团队不断把抽象的产品理念落到具体行为上。机器人不是为了展示模型多会推理，而是为了替用户完成有明确价值的工作；也不是让用户在各种配置页之间来回切换，而是让用户用自然语言说明目标。连接工具、保存上下文、操作浏览器、访问企业系统和持续回传结果，这些能力只有结合起来，才会让用户产生“我可以把这件事交给它”的信任。每一次成功完成的工作，都会带来新的使用方式；每一次失败，也会告诉团队应该修复基础设施、减少界面负担，或重新思考产品边界。 [01:10:00]
护城河来自持续交付而非预先规划
Lenny Rachitsky：……无法随着时代变化而改变。我认为，这正是让我们走到今天的原因。你有没有一些核心价值观，或者用来提醒所有人“我们就是这样工作的”具体说法？
Roman Ugarte：有两个价值观，我经常会回到它们。第一个是“删除产品”。这正好对应你刚才说的：当你回看 Cursor 的每一次迭代，甚至 Grok Bot 的每一次迭代，你会发现，消失的东西比新增的东西更多。随着模型变得足够聪明，能够自行完成某些事情，那些因为模型还不够聪明而搭建的脚手架和产品遗留物，就会逐渐被移除。我们必须习惯做出艰难的决定，即使这会让一小部分用户或内部同事不高兴，也要让产品变得简单、强大，并适应未来的发展方向。 第二个价值观与执行速度有关，就是“直接去做”。即使公司变大了，我仍然经常重复这句话：这是你的责任。我们都在同一条船上，都想赢。如果你看到某件事需要发生，这里不是一个等待许可的文化。你应该直接去解决它，并调动完成它所需的资源。很多人在这里取得成功，正是因为这样做。我认为，这也是我们与 SpaceXAI 共享的价值观。
Lenny Rachitsky：很有意思。我最后可能想问的一个大问题，是关于护城河。很多人把 Cursor 看作一个有趣的例子：它所在的市场，从技术角度看可能没有护城河，但它一直在胜出并取得成功。人们谈到 Cursor 时想到的两个护城河，一是数据反馈循环：用户不断自动补全，产品了解他们在做什么，再据此训练模型，这一点很独特；二是最佳体验，以及成为一个高日活产品，随着时间找到有效的东西和用户需要的东西。你从中学到了什么？对于正在试图理解这个问题的人，有什么关于护城河的想法可以分享？
Roman Ugarte：现在讨论护城河很热门，创办公司的时机也非常有意思。我能理解为什么这么多创始人会问自己这个问题，试图推演 12 个月、24 个月后的情况，但在这个领域，24 个月感觉像一辈子。我想说的是，如果 Cursor 以及这一代许多成功公司在早期就思考护城河，或者试图从某个战略图、某种抽象的公司运作理念反推，我不认为会得到现在的结果，也不会创造出这个产品。真正创造 Cursor 魔力的，是对今天构建有用东西的痴迷。 我们不断做这样的练习：可以看到世界三个月后、六个月后会走向哪里。模型会变得更聪明，现在无法解决的事情最终会变得可解。Cursor 一直在问：即使需要在上面增加一些工程工作，甚至大量工程工作，我们如何把那些本来要三个月后才能实现的事情提前带到今天？即使需要以特定方式改变产品，让用户能够与这个新能力互动，我们如何把它提前？ 然后三个月后，我们应该删除所有这些东西，因为它们会变成产品中理所当然、最低限度的基础能力；接着，我们再为三个月后的未来构建下一件事。我们不断重复这个过程，让用户真正信任我们，把时间投入到我们的产品里，相信我们会把能力带到下一个前沿、下一个未来。所以我真心建议今天的创始人和创业者，以这样的视角思考：怎样才能让现在不可能的事情变得可能？用户会因为这件事来到你这里，你要把他们带到下一个不可能的前沿。在这个过程中，你会获得大量分发优势和数据优势，价值自然会出现。但关键是要在这里竞争。
Lenny Rachitsky：我喜欢这个答案。我的理解是：只要构建出让人着迷的东西，就不要过度思考护城河。如果你能持续做到这一点，最终就会找到某种护城河；Cursor 的情况就是这样，最后形成了几种护城河。你最近参加的另一档播客里也提到过，很多时候护城河是被发现的，而不是提前规划出来的。好，那我最后真的问一个 Grok Bot 使用问题。有些人可能会想：“天哪，我得试试这个东西，到底为什么大家这么兴奋？”对于刚开始使用的人，你会给什么成功建议？对于已经在使用、希望听到一个“原来如此”技巧的重度用户，又有什么建议？
Roman Ugarte：我不想给出特别黑客式的专家技巧，因为我们的团队和公司的理念是，这些东西不应该存在。不应该有一堆复杂旋钮。你应该把事情委托给 Grok Bot，它就应该完成。对于刚下载应用、正看着这个界面的新用户，我建议第一件事是给 Grok Bot 提供成功所需的上下文。就像让一个人加入团队一样，他最好能够访问每天使用的 Slack、邮件和公司记录。先把工具连接好，然后直接问 Grok Bot：你能为我做什么？让它检查你刚设置的这些连接。 我当时可能会给它邮件和 Slack。我第一次入门时很惊讶，因为那时还没有任何入门界面。我给它的第一个任务就是：查看我的 Slack 和邮件，建议五件你可以替我承担的事情，并说明完成它们需要什么。它给了我五个建议，其中两个非常有帮助。我立刻派出两个机器人来解决这两个问题，那就是我的“哇”时刻：过去没有任何 AI 工具能做到这两件事。这不是让它起草一封邮件，而是让它完成一块完整的工作。所以我建议新用户用这种方式开始。 对于已经在使用的人，我一直在发现新的模式，让机器人彼此互动、协作。我开始搭建更明确的脚手架，规定机器人创建的产物应该放在哪里，如何写入一个对我来说清晰易读的位置。我每天都会阅读频繁生成的摘要，它们会被推送到一个数据库里，我可以非常容易地阅读。因此，我建议重度用户思考一下，如何让 Grok Bot 把输出写入一个统一存储位置，更容易组织和管理大量产物。
Lenny Rachitsky：天哪，我们需要再录一期节目，深入讲讲你的 Grok Bot 设置。里面可能有太多私人敏感信息，没法展示，不过这个建议太棒了。Roman，在进入令人期待的快速问答之前，还有什么想分享或想谈的吗？
Roman Ugarte：没有了。我们已经聊了这么多，我不敢相信这才一个半小时左右，我感觉我们已经聊了很久，把我想谈的都谈到了。
Lenny Rachitsky：好，接下来是令人期待的快速问答。我有四个问题，你准备好了吗？
Roman Ugarte：准备好了。
Lenny Rachitsky：你最常向别人推荐的两三本书是什么？
Roman Ugarte：有两本。一本是 Kurt Vonnegut 的《猫的摇篮》，我很喜欢，也推荐给过很多朋友。第二本是 Steven Pressfield 的《The War of Art》，我经常会重新读它，即使一次只读一两页，也会推荐给任何人。
Lenny Rachitsky：《The War of Art》，非常棒。它是一本很短的书。人们听到这个书名，可能会以为是《孙子兵法》；但它不是《The Art of War》，而是《The War of Art》，这是一个文字游戏，讲的是进行创作、创造新事物时面对的挑战，以及如何克服阻力。我很喜欢这个推荐。下一个问题：最近最喜欢的电影或电视剧是什么？如果你有时间看这些的话。
Roman Ugarte：我最近每年都会重看《卡萨布兰卡》，这是我最喜欢的电影之一。巧合的是，里面还有一个角色和我的姓氏一样，叫 Ugarte；我想，这可能是媒体里唯一一个叫 Ugarte 的例子，所以《卡萨布兰卡》总是值得重看。电视方面，我偶尔会看一集《神探阿蒙》，小时候我和家人一起看过，现在住在旧金山后又重新看起来了。这部剧拍摄于上世纪 90 年代末到 21 世纪初，是旧金山一个很有意思的时代切片，我很喜欢。
Lenny Rachitsky：这是节目里第一次提到《神探阿蒙》。好，当前最喜欢或最有意思的 AI 产品是什么？你可以说 Grok Bot，如果你愿意，但…… 护城河、分发和数据优势都不是一开始就能完整设计出来的。它们往往来自持续交付用户真正着迷的产品，来自把不可能的事情变成可能，再把临时实现删除并继续向前。对新用户来说，最好的开始是提供上下文、连接工具，然后直接把一块真实工作交给机器人。 对于新用户，最有效的入门不是学习一套复杂技巧，而是连接自己每天真正使用的工具，再让机器人主动检查哪些事情可以代劳。对于重度用户，下一步是建立清晰的统一存储，把机器人生成的摘要、研究和结果放到容易阅读的地方。这样，多个机器人才能协同工作，用户也能持续积累自己的工作系统。 整个过程反复体现了同一个原则：先从真实任务出发，再用用户是否真正获得结果来判断产品是否成功。团队关注的不是界面上有多少按钮、模型展示了多少过程，或路线图上增加了多少项目，而是机器人能否理解目标、调用正确工具、在遇到现实系统时继续推进，并把可靠、可复用的成果交给用户。随着模型、浏览器、云端基础设施和团队工作方式一起改进，原本需要人工照看、解释和修补的部分，都会逐渐变成机器人可以独立承担的能力；用户则可以把时间留给判断、创造和更重要的决策。
Roman Ugarte：在这段对话中，团队不断把抽象的产品理念落到具体行为上。机器人不是为了展示模型多会推理，而是为了替用户完成有明确价值的工作；也不是让用户在各种配置页之间来回切换，而是让用户用自然语言说明目标。连接工具、保存上下文、操作浏览器、访问企业系统和持续回传结果，这些能力只有结合起来，才会让用户产生“我可以把这件事交给它”的信任。每一次成功完成的工作，都会带来新的使用方式；每一次失败，也会告诉团队应该修复基础设施、减少界面负担，或重新思考产品边界。 [01:20:00]
在早期阶段持续收集用户反馈
Lenny Rachitsky：好，当前最喜欢或最有意思的 AI 产品是什么？你可以说 Grok Bot，如果你愿意；如果还有别的答案，会额外加分。我一直是语义搜索的重度爱好者，喜欢各种语义搜索产品，尤其是那些不太寻常的产品。我当时很早就开始使用 Metaphor，后来它变成了 Exa。我很喜欢用 Exa 在互联网上做各种更奇怪的查询。 我还看到很多人对 MoMA 的嵌入式图片库构建语义搜索，或者做类似的事情。我总是很喜欢尝试这些。所以，只要是针对奇怪数据集的语义搜索引擎，我都会喜欢。 你会推荐 Exa 吗？
Roman Ugarte：我喜欢 Exa。
Lenny Rachitsky：很酷。好，常常在工作或生活中回想的座右铭是什么？
Roman Ugarte：它不算一句很短的座右铭，但我很喜欢《道德经》（Desiderata）。不知道你读过没有。我把它贴在门上，从十几岁起就一直这样，无论搬到哪里都会把它贴在那里。那是一首很短的诗，但每一行我每次读都会有新的发现，它让我非常踏实。
Lenny Rachitsky：Roman，今天太棒了。我们正处在 Grok Bot 和整个 AI 发展的一个特殊时刻。过一年再回头看这期节目一定很有趣，也许会发现，我们对很多事情既判断得非常正确，也判断得非常错误。非常感谢你参加节目。我知道你们团队现在非常忙，真的很感谢你抽出几个小时来聊天。 有什么地方想推荐大家去看吗？除了让大家试试 Grok Bot，还有什么想推广的？
Roman Ugarte：当然要试试 Grok Bot。最重要的是，请把反馈发给我们。我认为现在还处于非常早期的阶段。我们三周前才发布了测试版，早期用户的很多反馈，已经直接转化成我们构建的产品和构建方式。所以真的非常感谢大家提供的意见。
Lenny Rachitsky：Roman 和团队，做得好。我知道这一切背后有整个团队。Roman，非常感谢你来到节目。
Roman Ugarte：太棒了。谢谢你，Lenny。再见，大家。
Lenny Rachitsky：非常感谢大家收听。如果你觉得这期节目有价值，可以在 Apple Podcasts、Spotify 或你喜欢的播客应用上订阅。也请考虑给节目评分或留下评论，这会帮助其他听众找到它。你可以在 lennyspodcast.com 收听往期节目或了解更多信息。我们下一期再见。 节目的最后回到语义搜索、阅读和持续反馈，嘉宾也鼓励早期用户把真实使用感受告诉团队。产品仍处于早期阶段，用户反馈会继续影响它接下来如何构建。 [01:22:40]