← 顶级AI播客总结
Lenny's Podcast

一小撮人 30 天做出 Grokbot:给每个 bot 一台自己的电脑

How a handful of people built Grok Bot in 30 days | Roman Ugarte (SpaceXAI)
节目时长 83 分钟 阅读约 40 分钟
▶ 在 YouTube 收看原片

Cursor 15 号员工复盘:为什么不把知识工作塞进 Cursor,而是关进山洞从零重来。

核心要点

  • 30 天出原型:一小撮人被物理隔离在办公室一角、用私有 Slack 频道,一个月从第一行代码做到可用原型。Roman 认为人一多、周期一长,就到不了最终落地的形态 4:365:23
  • 两个决策定成败:其一是运行时彻底在云端,用户永远不必考虑本地还是云端;其二是每个 bot 有自己的电脑,因为人类不是通过 MCP 和 API 工作的,是点像素、填输入框 30:4531:32
  • 手工 onboard 两三百人:包括 Lenny。前几场很糟,但核心团队亲自坐在电话里看着用户卡住 20 分钟,第二天就必须修好。他们还刻意找非典型用户,比如一位咖啡店老板 11:3016:52
  • 「现在能」而不是「现在有」:把「Grokbot now has」改成「Grokbot can now」,前者补全出来是新按钮新下拉框,后者才是能力。发布前他们大量下架,包括模型内部思考的可见性面板 27:3919:58
  • 自然语言定义自动化:竞品要你进侧边栏、点加号、选触发器、选动作;Grokbot 让你直接对 bot 说「每天早上八点提醒我」——现在平台上 99% 的自动化是这么建的 29:11
  • 90% 和 100% 是两个品类:只完成 90% 的 AI,意味着你在它干活时还得一直惦记、还得介入纠偏,那其实不叫 90% 完成度,你还是在做这件事。Grokbot 给人的是「不回头传球」的体验 62:23
  • 护城河是被发现的,不是规划出来的:如果 Cursor 当初从策略图或抽象的护城河概念倒推,不会有今天的结果;真正起作用的是「痴迷于今天造一个有用的东西」,然后反复把三个月后才可能的事拉到今天 73:10

章节时间轴

详细内容

一、进山洞的一个月

Grokbot 的起点是一张白纸 3:51。Roman 说团队很久以来的感觉是:他们想做一个不只是服务开发者和工程师的伟大产品——那是他们的起点,也是他们积累了大量「怎么做出好 agent 和有用产品」直觉的地方——但同样的产品对知识工作来说该长什么样?

做法是成立一个非常小的内部团队,「真的只有一小撮人」,进山洞一个月,唯一目标是做出一个能把 agent 带给公司其余部门的、了不起的知识工作产品 4:36。从第一行代码到内部发布原型只用了大约一个月,是个很快、很草莽的原型。

他强调这件事的组织前提 5:23:「事后看,如果换成一个大得多的组,这不可能做成。它需要一个小的、聚焦的、与公司其余部分完全隔离的小组——我说的是字面意义上的隔离:办公室里单独的一块区域,私有的 Slack 频道。」 原因是他们每天要做大量微决策,其中不少并不显然,也不是他们在别的产品界面上做过的事。「如果是一大群人,而且我们在想一个六到十二个月的愿景,我们根本到不了最后落地的那个地方。」

原型出来之后是全员发布 6:09。Roman 说这才是真正的压力测试:自己造的东西自己当然爱用,因为你懂它的机理和擅长什么;问题是别人会不会真的从其他内部外部工具切过来,把 Grokbot 当成主要的 agent 界面? 结果他形容为「非同寻常」——那些原本天天用聊天界面的人,把全部日常 agentic 工作都切了过来,而且来自一些你意想不到的人和部门。

完整时间线 18:24:一个月做原型 → 三周内部 beta → 公开发布 → 录制时距发布三周。 Lenny 的反应是「从我的视角看,它已经改变了世界」。

二、为什么不做进 Cursor

Lenny 指出一个有意思的对照 8:27:Anthropic 和 OpenAI 都是从编码 agent 出发,发现人们拿它做知识工作,于是在既有产品里长出知识工作组件(co-work 从中演化出来,Codex 也朝通用方向投入);而 Cursor 这边选择了另起炉灶。

Roman 说这个决策当时完全不显然,内部讨论很多,但他很庆幸最后落在了这一侧 9:13。理由分两层:

然后是他对竞品的评价,这段很直接 9:58:「我们看到某些竞争对手在做的事情是——这一切都是同一个界面,每来一种新形态就加一个新标签页,于是它显得杂乱。用户能感觉到这不是一个关于工作应该如何运作的一致愿景,而是三个不同的愿景共用一块屏幕,你可以在中间跳来跳去。这有点像在交付你的组织架构图,而用户对此反应是负面的。」

Lenny 顺势提炼了对听众的价值 10:44:与其把新东西塞进一个已经复杂的既有 AI 产品,从零开始可能才是解法。 他也公允地指出 Codex 走的是相反方向、现在正把东西合成一个,所以路不止一条。

关于「为什么别的公司没做云端 + 每 bot 一台电脑」这个决策,Roman 的解释同样落在「从零开始有多解放」上 33:04:Grokbot 里的很多原语他们此前都尝试或以别的方式造过——云基础设施是为编码 agent 建的,给 agent 命名并把它们当作离散实体对话的模式,在开发者侧也正在出现(把具名 agent 拉进 Slack)。但他们没有把这些概念往新界面或既有界面上硬套——那本该是大多数公司的强默认——而是决定从零开始。

他还特别不居功 33:51:「这些想法并不是我们的天才之举。我认为它们是已经被其他产品验证并获得关注和产品市场契合的原语——比如 OpenClaw 那一类。我们从中获得了大量灵感,然后把它产品化成一个更紧凑、需要更少设置、更多人够得着的界面。」 他认为竞品也看到了同样的机会和市场反馈,「只是如果你被困在既有范式里、在那个范式上有大量沉没成本,从零造一个新东西会非常痛苦」。

三、手工 onboard 两三百人

团队用两周时间人工 onboard 了两三百人,包括 Lenny 11:30。Roman 坦白:「最初几场 onboarding 相当痛苦。Lenny,很高兴你碰上了一场好的。」

他解释为什么这件事不能外包 11:30:核心团队必须在场,必须在电话里坐上 20 分钟,看着电脑起不来,或者看着某个人在 onboarding 里完全懵掉。 因为紧接着你就会说「这绝不能再发生一次,我们明天就得解决,因为明天我要 onboard 另一个人,而那次必须更好」。

比学到产品问题更重要的是打破群体思维 12:17。他说这类产品容易形成使用上的从众:SpaceX 内部人们不断分享 Grokbot 的技巧,一些模式开始浮现,团队觉得这些模式对外部世界也有用,但他们并不确定,而且绝对不想污染外部世界的判断。

他举的那个模式非常有意思 13:02:内部推广后头一两周,常见用法是你有五到十个 bot,每个给一个不同的范围、不同的领域,相当于不同工作泳道的速记。到第二周末,Slack 里开始出现一种消息——人们在「提拔」自己那个表现特别突出的 bot(通常是主力个人助理)当参谋长(chief of staff);此后他们主要和参谋长对话,由参谋长把任务分发给其他 bot、管理整个团队。他说有一些很好笑的截图:人真的去告诉那个 bot「你被提拔了」,而 bot 会问自己是不是能涨薪、token 预算是不是会变高。

关键在于他们怎么处理这个发现 13:47:在 onboarding 和早期访问项目里,他们刻意不去「引导证人」——不会说「创建一个参谋长 bot,然后让它这样管理其他 bot」——而是看外部早期用户会不会自己走到那里。结果很多人确实自己走到了。于是他们才在产品里给出一个稍微有观点的引导:这看起来是个有效模式,我们应该轻微鼓励它——但它不该是一扇单向门。

第二个被早期 onboarding 验证的假设是用户到底想看多少 14:33。Roman 说这是 Grokbot 与其他产品相比最让人意外或不同的地方之一:Grokbot 内部运作的大量机制并不展示给用户。 理由还是那个同事类比——你不会要求队友逐秒汇报他按了哪些按钮、访问了哪些网站,那么要求你的 bot 这么做也太过分了,而且说实话这令人不堪重负,害处可能大于好处。

所以他们完全走向另一边 15:19:你发一条消息、告诉 bot 做什么,它就开始做;它按自己认为合适的节奏发进展更新;你只看到那个打字指示器和小绿点表示它在活动、在干活、待会儿回来找你。你看不到内部机制、看不到 tool call、看不到它在自己电脑上点的每一下。 他们确实收到过一些反馈——「我想看我的 bot 的待办清单」「我想大致知道它怎么排优先级」——但没有人想要那种一长串流式吐出的文字和思维链序列,这反而确认了方向是对的 15:19。

Lenny 追问:小团队做两三百场 onboarding 电话是巨大的时间投入,理论上是对开发的干扰——但显然不是,显然是成功的核心。这是必须做的量吗?Roman 的补充是早期访问名单不只是有影响力的品味制造者 16:07:他们当然想要 Lenny 这种极接近市场、又是这些产品重度用户的人的反馈,但他们同样想要那些公司从未接触过的非典型画像。

那个例子很动人 16:52:一位咖啡店老板,通过朋友的朋友听说了 Grokbot,某天核心团队有人给他演示了 TestFlight,他非常兴奋——最后不但成了 Grokbot 的重度用户,还成了极丰富的反馈源。他们有一条非常活跃的反馈线程,里面是大量 bug 和功能请求,而且是一个完全不同的用例:经营一家小生意。比如 Shopify 集成不太稳,或者产品文案没有按某种方式写——这类反馈和内部 dogfooding 得到的完全不同。

他把这件事的意义讲得很清楚 17:38:

四、下架、「现在能」,以及后端爬坡

发布前那三周最大的动作是下架(unship) 19:11。Roman 说他真希望能给 Lenny 看发布前两周产品长什么样:核心团队当时有大量实验性功能想拿内部反馈(这本身有用),而且他们把类似开发者的可见性工具直接塞进了 Grokbot,而不是另做一个观测面板 19:58——比如确实暴露了模型的大量内部思考、它存下的具体记忆等等,这对调试有用,你在做产品时也不想为了拉上下文跑到别处去。

但他们必须极其激进地修剪「用户绝对需要看到的」和「不需要的」。 他说这方面还有更多空间可跑,团队现在正focus 在怎样无情地简化产品、把任何用户不需要主动思考的东西都抽象掉 19:58。

第二个大推进是「就是能用」 20:45。他的判断是:人们想从 AI 那里得到的,不是一个有一堆下拉菜单和花哨功能的东西,而是一个你描述一个对你有意义的任务、它就去做、然后带着完成的工作回来,或者带回一个你可以反应并在下一轮里引导它的东西。 而要兑现这个承诺,做的其实不是功能路线图那类事,而是在后端爬五个非常重要的问题的坡——这些问题用户不直接体验,但当你的 bot 出去干活却点不到正确的按钮、或者登不上某个网站而彻底卡死时,你百分之百能感觉到 21:30。所以那几周他们收集了一套很丰富的数据:人们实际交给 bot 的任务是什么、怎么量化、怎么按任务类别逐周看重要维度上的进步。

那个具体案例来自销售 21:30:公司内部最「bot 化」的一个群体是 go-to-market 团队。 原因是销售用的一堆工具没有得到良好支持的 MCP 或 API——这正是 bot 对他们前后差别巨大的原因:这些事他们没法可靠地交给任何别的 AI 工具,总会在流程某处卡住;而 bot 让他们感觉像有了一个助理、像给自己团队 onboard 了一个人,给了他一台笔记本,他就能自己跑。

具体障碍很琐碎但致命 22:16:大概有十到二十处地方,因为鼠标控制不够精细,点不中 Salesforce 仪表盘上那个确切的位置之类。团队把这些带回做基础设施的核心组:「这里有一个非常具体的例子,agent 缺乏对浏览器/对屏幕像素的这种可见性,导致这个任务不可能完成。」 他说这比看仪表盘上一个数字缓慢上涨具体得多——感觉像是一整块新的工作被解锁了:你发布一个幕后的基础设施改进,第二天就会收到销售团队涌来的感谢,因为过去七天一直失败的那条工作流终于跑通了 23:02。

招聘团队是另一个重度用户 23:49。Roman 说最有意思的用例是主动寻源(sourcing),而这背后是公司的招聘哲学:「正在找工作、在市场上,不是我们试图雇你的前提条件。」 最好的招聘方式是看公司最大的问题里哪一个需要有人接手或推到下一层,然后在全世界的人里找出谁最合适,再不择手段地去说服他加入。

如果这是你的思维方式,那要自动化的就不是「这里有一堆简历,读一读、帮我排序」,而是「这里有一整个宇宙的潜在人选,帮我把它匹配到这个非常具体的业务问题或职位上,帮我联系上他们,帮我约到咖啡」 24:34。他给的具体指令堪称模板 25:20:

「这篇论文的共同作者是谁?PDF 在 Google Scholar 上不存在,只存在于这个会议网站上。我要你每天早上去那个会议网站,把新增的 PDF 下载下来,找出每一个我们还没跟踪过的新名字,把名字加进一张表,做背景研究,再看看 SpaceX 里有没有人与他直接相连——如果有,给那个人发 Slack 消息请求引荐。」

「这类常开式寻源过去极其手工,而现在这正是 AI 超人的领域,我们的团队可以专注于把优秀候选人谈下来,而不是去拉这些巨大的名单。」 Lenny 的即时反应是:马上就会有人把这段转录丢进 bot 做自己的版本——而且「你们其实可以把这个 bot 的模板卖十亿美元」。

关于下架,Roman 给了一条可以直接用的内部准则 27:39:对任何在做的东西,问「发布贴长什么样」——如果那条推不吸引人,也许我们就不该做它。 更进一步的是措辞的改造:

「老派软件的倾向是说『Grokbot 现在有了……』,而当你去补全这个句子,补出来的会是一个新按钮、一个新下拉框,或者一个你可以点加号添加的新集成。我们把它改成『Grokbot 现在能……』——这是一种更人性的描述能力的方式。」28:24

这个改动反过来约束了产品思维:要想的是我们能给 Grokbot 什么工具和能力,而不是能往产品里加什么新东西。给产品加东西不是目标,那不会推动产品前进、也不会让它对更多人更有用。 所以在下架的语境下,很多「Grokbot 现在有了」的东西其实只是不需要像素的能力——「让我们杀掉尽可能多的像素,这些东西可以由你的 bot 在幕后操作,你不需要直接控制」。

最好的例子是自动化 29:11:竞品的做法是你进侧边栏、点加号、选触发事件、选之后的动作,可能再用自然语言描述一下——非常笨重,导致人们其实不会为很多事情设置自动化(他说在编码领域也确实见过这个现象)。Grokbot 的回应是:自动化就该用自然语言定义。你告诉你的 bot「请每天早上 8 点提醒我」,它就该照做,而你永远不必看到那个创建自动化的界面。 结果是平台上 99% 的自动化就是这么建的。

五、两个真正的决策:云端,和每个 bot 一台电脑

Lenny 把最大的问题摆上桌 29:58:很多人回复他说,这些用 Codex 和 co-work 技术上都能做——那你们到底做了什么不同的事?

Roman 的答案是两个当时并不显然、事后看却至关重要的早期决策。

第一,你永远不该去想本地与云端。30:45 「工作流在哪里跑?我的电脑需要醒着吗?我从手机发起,它需要连回家里的电脑吗?人们试图理解这个运行时住在哪里时,有太多的别扭。」他们很早就决定这一切都该在云端。而一旦它在云端、是一个有自己电脑的持久同事,它就能做自己的工作,在你与它交互的任何地方都保持同样的状态,于是打开了很多机会:给你的 bot 发短信、从手机上发起任务;未来你应该能从任何地方打电话给你的 bot,而它能做真实的工作。它是自己的实体,独立于你的设备而存在。 他认为现有产品没有做同样的决策,而用户每天都在感受由此带来的一堆小割伤。

第二,这些 bot 应该有自己的电脑。31:32 一层原因前面说过:很多任务没有得到良好支持的 MCP 和 API,而且——「我们人类并不是通过 MCP 和 API 做我们的工作的。我们用电脑,我们点像素,我们在输入框里打字。」

而更进一步的那层论证是全集最好的一段 32:17:

「我认为我们正处在一个很怪的时刻,将来回头看会觉得『我很惊讶当时很多人是这样和 AI 一起工作的』——你在给这些超级聪明的新同事、这些 AI bot 做入职,却要求他们和你共用同一台电脑。这太疯狂了。如果你给团队新人做入职,你说:今天是你第一天,你没有自己的笔记本,你就坐我旁边,我们永远共用这一台、不断互相踩脚,你能访问我的凭据,我能访问你的凭据——这不是人们的工作方式,而且有很好的理由。」

关于技术实现,Lenny 问每个账户拿到的到底是什么(云上一台 VM 多个登录?每个 bot 一个 VM 实例?)。Roman 没有直接回答架构,而是把问题重新框定 47:43:回到同事类比,「如果我们在同一个团队,你需要手动接管我的电脑、开始点东西、说『你做错了、应该去这里手动输入』的次数,希望接近于零。」 所以在他看来:计算机使用(computer use)现在不错、还在快速变好,而在很短的时间内,「电脑」这个概念会被彻底从用户面前抽象掉——你永远不该点进一台远程虚拟机,永远不该去接管控制权。 中期内这仍是用户需要拥有的一个概念,但不是他们要交互的东西。

那么 Grokbot 到底是什么 48:29?它是一支 bot 团队、一支替你干活的 agent 团队。 它们拥有两样东西:

1. 很长的记忆,装着你和它们过去的交互。他明确批评当前范式:「每做一个离散的工作单元就新建一个会话,我认为问题很多——我总是在会话之间复制粘贴,这不是给工作分类的好方式。」 应该像团队一样按角色、按工作泳道来分组,而且它应该从你身上学习、随时间变聪明。这些是长生命周期的 agent,不是一次性会话。 49:15

2. 人类同事会有的全部工具:API、MCP 当然好,但还要有自己的电脑,它可以像你一样自由操作。

Lenny 提到聚会上一个让全场震惊的演示 49:15:因为每个 agent 里有一台电脑,你可以在 Grokbot 里跑 Grokbot——bot 可以运行它自己的 bot。 Roman 说他自己也这么做,而且这确实非常有用 50:03:他有一个 QA 测试 bot,「如果有 bug 报告,或者我们在测试桌面应用的新构建,我就说:这里有十条工作流,我们要确保每次发版都在变好;你去测,把结果写进那个 Notion 文档——里面有过去所有客户端版本的测试清单——然后做对比。」

他的总结是本集的另一个核心句 50:49:

「一旦你跳出『这是一个带一堆连接的 AI 聊天』——这是大多数人现在的概念——转到『这是一个有电脑的同事,任何我会让同事在电脑上做的事我都可以让 bot 做』,它就把你会想到交给 AI 的事情的天花板抬高了。」

关于 OpenClaw 的影响,Roman 的复盘很具体 36:09。他认为 OpenClaw 做对了两件大事:

而 Grokbot 在此之上延伸的是 37:45:必须极易设置——「你家里有个 VPN、配一台 Mac mini」这种 hacky 方案显然扩展不到几百万用户,更重要的是显然不会成为企业利用这项技术的方式;以及打磨掉大量粗糙边缘,把 AI 重度用户熟悉的那些抽象(比如 skills)藏起来——「我们怎样才能让 Grokbot 用户根本不需要知道 skill 是什么?他们永远不该打一个斜杠命令。这些东西应该在后台被创建成 bot 可以使用的有用原语,但用户没有义务永远站在 AI 的最前沿。」

Lenny 补了一个很有分量的数据点 38:31:Claire Vo——OpenClaw 最大的鼓吹者,它已经成为她生活和工作的核心部分——把她所有的 OpenClaw 全关了,切到了 Grokbot。

六、愿景:用「换成人类同事你会怎么想」来裁决产品争论

Roman 给的愿景一句话就说完了 39:17:「你应该拥有一支 AI bot 团队,帮你做工作、也帮你过生活。而且它真该感觉像一支团队——像一群自主的队友在帮你。你可以用各种方式引导他们,你不必微观管理他们,他们拥有做出伟大而有野心的工作所必需的工具。」

产品上的北极星是一个可操作的裁决机制 40:03:每一个产品决策,都不要从 SaaS 产品的视角出发,而要从「我们在造有用的 AI 队友」出发。 他们内部有个词叫「colleague-pill」(同事药丸):

「有时我们在争论某件事,两边都有好论据,两条路都说得通。在产品的语言里似乎没有明确答案。然后你往后退一步,把自己从这一切的『科技公司味』里拿出来,开始想:人会怎么做?在这个确切的情境里,你会希望你的队友怎么做?答案往往非常清晰,而且相当一致——关于『你更愿意和一个人类队友以什么方式共事』,房间里通常没什么分歧。答案一出来,我们就只需要把它造出来。」40:49

他强调这不是火箭科学、不需要你是天才——你只需要问「你会希望人类队友怎么做」,然后推动 AI 表现出类似的行为,尽管兑现体验需要产品和模型两侧做对很多事。

他举的正在思考的例子是语音 41:36:人类同事之间的类比很清楚——很多时候你在 Slack 上和队友来回传上下文,而更简单的做法是开一个五分钟的 huddle,你分享屏幕、把你在想的东西直接摊开,对方也分享,挂掉之后继续异步。 「这不是任何 AI 产品目前做对了的体验,而它对人类协作而言是极其核心的。所以我们想造那样的东西。」

关于工作和生活是否要分开 42:21,Roman 先讲了一个更大的观点。他说「工作产品 vs 消费级产品」这个分类背负了过去一二十年糟糕 B2B 软件的包袱——人们看到一个简单的产品(ChatGPT 是这样,Grokbot 也有很多这类属性)就假定它不是工作产品、不是专业工具 43:08。而上一代人心目中的专业工具像 Photoshop:一堆可以精细调节的旋钮,使用者是那个知道每个旋钮干什么、能完美操作的座舱飞行员。

「而未来的专业工具会非常不同:主要是意图的表达加上人类这一侧良好的引导,而 AI 工具把所有旋钮都抽象掉。你不该看到它们,除非你需要直接操纵某一个——那种情况会发生,也该有很好的可供性——但归根结底它就是在和一个队友共事,所以界面相当对话化。」43:54 他说所以当他走过某人工位看到 Grokbot,有那么一瞬间他会以为对方在用一个即时通讯软件,而实际上那是对方完成大部分工作的主要工具。

至于分不分 44:40:他认为很多人会想要个人和工作的分离,这很好也很重要,从企业角度也有很多常识性理由;但他的目标是——Grokbot 应该成为你日常工作中很大一部分事情的委派方式,让你专注在更高杠杆的事情上;同时也成为你委派个人生活中低杠杆部分的方式。而这两件事其实不是不同的问题集,产品形态和解决方式基本一样。所以我的直觉是一个产品会是两者的最佳形态。

他还分享了一个自己的高阶用法:把 Grokbot 当「信息巨兽」(infovore) 51:36。V1 实现是很多人在做的:Grokbot 坐在 Slack 和邮件之上,你高层次地告诉它「这是我的角色、我在乎什么;这些情况通知我,那些情况不用直接 ping 我,但要放进我每天读的汇总里」。他说自己大概在 V3 或 V4:把整条信息消防水管接给它——他接入了 X 上所有对 Grokbot 的提及,让它与内部上下文交互、与 QA 测试 bot 交互去尝试复现收到的 bug 或反馈,还接入了自己的消息服务以便快速处理反馈并联系人 52:23。

他描述的形态是一个常开的参谋长实体,保护你对真正重要之事的专注,但一直在巡视有没有需要你注意的东西。还有更激进的用法 53:09:有人给自己的 Grokbot 开了「呼叫(page)」权限——真有紧急事情时,哪怕你在咖啡馆也会被 Grokbot 呼叫。他说这只有在你真的信任它不会误报时才敢开,目前这些人反馈很成功。「我认为我们会看到更多这类东西——agent 或 bot 应该比你主动联系它更主动地联系你。而我认为那会是 AI 的下一个转变。」

七、速度、文化,与护城河

Lenny 描述了他观察到的执行速度 63:09:他被拉进一个 Slack 给反馈,对面的回应是「明天给你一批免费码你发出去」「我们两天后上带模板的市场」——「什么?我可没时间跟上这个节奏。」

Roman 把它归给「始终没变的创业公司感觉」63:55。他自己的坐标很清楚:加入 Cursor 时公司约 15 人,扩张到一千多人,现在是 SpaceX AI 这个更大组织的一部分。 他的描述是:所有人以每小时一百英里的速度移动,你深度信任每个人会完成自己那部分,有一个所有人都为之兴奋并且知道必须执行的清晰愿景。

他也承认这有多难 64:40:「随着公司增长——我们有幸从其他经历过超高速增长的公司招到很棒的人——事情会变慢,而你会不断告诉自己『我们还是创业公司、我们还是很快』,但你其实并不是,而且所有人都知道你不是。说比做容易。」

他对「创业公司」的定义值得记 65:28:「如果你用人数或者融资轮次来定义创业公司,那都说不通。定义创业公司的核心是你刚才描述的那种东西——一种手忙脚乱的能量,事情有点混乱、有点没条理。对很多人来说那不是愉快的工作环境,但它有一个惊人的属性:你可以在短时间内在某个特定方向上造成极大的影响,而且你从系统里拿出的,真的等于你放进去的。」

Lenny 抛出他一直想问的大问题 66:13:从外部看,Cursor 本不该成——它在世界上最卷的市场里,对手是史上增长最快的公司 OpenAI 和 Anthropic,而且它还建在这些平台之上。他自己的答案是:Cursor 赢在能多快调整以适应市场的现实——从自动补全,到与 agent 对话,到搬上云,再到 Grokbot。

Roman 的回答落在文化上 67:46:「我们从来没有自满过。我们从来没有觉得自己赢了,永远是关于下一件事。公司上下有一个很深的信念:AI 在极快地前进,我们的目标是把这些能力翻译成给客户的了不起的产品——但这些产品会变,它们必须匹配当下的时刻。两年前匹配时刻的东西和今天完全不同。如果我们作为一家公司不能每六个月彻底重塑自己——最近这个周期感觉更短——包括对优先级、核心产品、用户感受的非常显著的重塑,那我们就会输。」

他补了一个历史观察 69:20:AI 编码从 Cursor 诞生之初就是竞争激烈的领域,当时的对手是微软和另外十几二十家公司。「值得指出的是,那些竞争者现在没有一个站在 AI 编码的前沿——很大程度上不是因为他们做错了什么决策,也不是因为资源不足,而是因为那种文化上的无力:无法快速移动、无法随着时刻的变化而改变。」

两条他反复回到的价值观 70:06:

关于护城河,Roman 的看法很鲜明 72:24。他理解为什么这么多创始人在问这个问题——现在起步,往前看 12 个月、24 个月都像永恒。但:

「如果 Cursor 以及许多这个年代的成功公司当初思考护城河、或者试图从某张策略图、某种更抽象的『公司应该如何运作』的概念倒推,我不认为那会创造出这个结果或这个产品。真正创造了 Cursor 那份魔力的,是对『今天造一个有用的东西』的痴迷。」73:10

他给出的机制非常具体:你大致能看到三个月后、六个月后世界会去哪儿——模型会变聪明,现在解不了的事终于能解。Cursor 反复在做的就是这个提示词:我们怎样才能把那些东西拉到今天?哪怕需要在上面做一点工程、甚至大量工程才能让它工作,哪怕需要为此以特定方式改变产品,好让用户能与这个新能力交互。把它拉到今天,然后三个月后我们应该把那些东西全删掉——因为那时它会变得好用而且成为产品的基本底线——然后我们再去造为「再三个月后」准备的东西。就这样一遍遍地做。 他认为正是这个循环让用户真正信任他们、愿意把时间放进他们的产品里。

「所以我会非常鼓励今天起步的创始人更扎根于这个视角:我怎样让现在不可能的事变得可能?用户会为那件事来找我。我会把他们拉到下一个不可能的前沿。而在这一切之中,我会获得大量分发优势、会获得数据优势,价值会在那里产生——但这才是该下场的地方。」73:56 Lenny 的提炼是:造一个让人着迷的东西,别过度思考护城河;而 Roman 补了一句他最近在另一个播客上听到的说法——护城河往往是被发现的,不是提前规划的。

关于公司结构,Roman 给了一个清晰的三支柱框架 58:33:

1. 编码产品:目前是 Cursor 和 Grok build。他们坚信为开发者和工程组织保留一个专业工作界面是关键的——人们有时用 Grokbot 去启动云端 agent、合并 PR、做 QA 等工程邻接任务,但真正交付生产软件时,需要一个每个像素都为该用户优化的产品。

2. 通用知识工作:Grokbot 是这个方向上令人兴奋的一步,但还有大量工作——让它更有用、扩展到新界面、真正感觉像一个你可以委派工作的 AI 队友,尤其是在公司和企业内部。

3. 通用模型:他说有一点让 SpaceX AI 与其他 AI 实验室略有不同——「我们的目标与其说是追逐超级智能或某个模糊的宏大理想,不如说非常实际:造有用的 AI。」 而且参与模型训练的是工程师、是带着应用心态进来的人,他认为这是驱动这家公司的东西。

至于上市打法 54:41,他预期知识工作会复制编码的路径:早期采用者在个人项目上把这些工具推到极限(他想的是 2023 年前后——白天在公司用基础 IDE,晚上在家做副业项目用最新的 AI 编码工具),获得极大的加速、感觉像在体验未来,然后回到公司去要求它——「我无法想象用别的方式工作,我现在感觉像在糖浆里走路,这必须改变。」 他说现在 X 上确实能看到大量个人场景的顿悟时刻——Grokbot 控制家里的扫地机器人、Grokbot 帮人在 Tesla 充电桩谈判上省钱——「但下一步是:这不是一个消费级产品。我们认为它会改变企业、改变团队,会是 bot 进入团队并贡献真正有经济价值的工作。」 所以他们现在在大力优先企业侧,思考的问题是bot 如何在更大的团队中工作、如何在复杂且有大量上下文与历史的真实公司系统里工作、组织层面的记忆该长什么样。

八、90% 与 100%,以及两条上手建议

Roman 有条被置顶的推文:「一个能完成 100% 工作的 AI,和一个把你带到 90% 的 AI,感觉上是完全不同的品类。我已经显著更新了我对 AI 能做什么的看法。」60:52

他解释说,让他对 Grokbot 如此兴奋的原因是——这是第一次在非编码任务上,他感到自己可以真正把工作委派给 AI、不必再去想它,回来时事情已经做完了 60:52。他指出工程师已经体验这种感觉一年到一年半了,开发者的工作已经彻底改变、与两年前完全认不出来,但这与大多数人当下对 AI 的感受有多不同,被严重低估了——多数人的用法看起来仍然像两年前:为一个任务新建一个线程,在输入框里打字,回车,看着一堆步骤发生,得到一个不太对的输出,继续折腾 61:38。

他把 90% 的问题讲得很透 62:23:

「当你有一个你只信任 90% 的队友,你把东西交给他——我很幸运在这里没有这种体验,因为我和很棒的人共事——但如果你委派给某人,而你心里知道『在你做的过程中我还得一直想着这件事,我知道它多半不会到位,我得介入、得稍微纠偏』,那不叫 90% 的任务完成度。你还是在做这件事,感觉也是这样,它同样压在你身上。这和真正给同事传一个不回头传球、说『你能行,这是上下文,去跑吧,我很期待你做出什么』完全是两个品类。」

最后是两条上手建议 75:29。他刻意避开花哨技巧——「我们团队和公司的哲学是那些东西本就不该存在。不该有一堆疯狂的旋钮,你应该能把事情委派给 Grokbot,它就该做好。」

闪电轮 78:36:

金句

你在给这些超级聪明的新同事做入职,却要求他们和你共用同一台电脑。这太疯狂了。 —— Roman Ugarte 32:17
不要说「Grokbot 现在有了……」,要说「Grokbot 现在能……」。给产品加东西不是目标。 —— Roman Ugarte 28:24
让我们杀掉尽可能多的像素——那些东西可以由你的 bot 在幕后操作。 —— Roman Ugarte 28:24
一旦你跳出「这是带一堆连接的 AI 聊天」,转到「这是一个有电脑的同事」,它就把你会想到交给 AI 的事情的天花板抬高了。 —— Roman Ugarte 50:49
你只信任 90% 的委派,其实不叫 90% 完成度——你还是在做这件事,它同样压在你身上。 —— Roman Ugarte 62:23
如果我们不能每六个月彻底重塑自己,我们就会输。 —— Roman Ugarte 67:46
那些竞争者现在都不在 AI 编码的前沿,不是因为决策错误或资源不足,而是那种文化上的无力。 —— Roman Ugarte 69:20
护城河往往是被发现的,不是提前规划的。 —— Roman Ugarte 转述 74:43

提到的书·产品·人物

适合谁听

正在做 agent 产品的产品经理与创始人——尤其是纠结于「做进现有产品还是另起炉灶」「该给用户看多少内部过程」的团队;以及想知道 Grokbot 到底哪里不同、值不值得迁移的重度 AI 用户。

← 返回全部观看原片 ↗