0:00 大家好，我是娜娜。
0:01 你把一项工作交给 AI
0:03 然后关掉电脑去做别的事，
0:05 等你回来，
0:06 它已经把事情办完。
0:07 这种体验和 AI
0:09 帮你写了一份还需要反复修改的初稿。
0:11 到底差在哪里？
0:12 GrokBot
0:13 的产品负责人罗曼乌加特有一个判断，
0:16 能把工作完整接过去的 AI
0:18 与只能帮你推进到 90% 的 AI
0:20 带来的感受属于不同的类别。
0:22 在他描述的委派体验里，
0:24 关键是任务交出去以后，
0:26 人能不能真正放下心，
0:27 不再一直惦记着。
0:29 在 2026 年 9 月 8 日发布
0:31 的 Lenny's Podcast 访谈中，
0:32 罗曼讲了这款产品的诞生过程。
0:35 他曾负责 Cursor 的增长，
0:36 也是 GrokBot
0:37 从早期原型走到发布的核心成员。
0:40 他们想解决的问题很具体，
0:42 编程之外，
0:43 那些每天处理邮件、
0:44 招聘、销售和信息整理的人。
0:47 怎样才能拥有一个真正替
0:48 自己干活的 AI 伙伴？
0:50 这件事最值得看的地方在于，
0:52 他们把像同事一样工作落实成了一连串产品决定，
0:56 而这些决定既涉及 AI 在哪里运行，
0:58 也涉及用户究竟需要看见多少东西。
1:01 先说一个招聘案例。
1:02 按照罗曼介绍的内部招聘思路，
1:05 找人的起点是公司有一个具体问题需要谁来解决。
1:08 合适的人可能根本没有投简历，
1:10 甚至没有找工作的打算。
1:12 因此，他们希望 AI 持续做这样一套工作。
1:15 每天早上访问某个学术会议网站，
1:17 下载新出现的论文 PDF
1:19 找出尚未追踪过的作者，
1:21 把名字补进表格，
1:23 研究这些人的背景。
1:24 再看看公司里有没有人认识他们。
1:27 如果存在直接联系，
1:28 就通过 Slack 请求同事引荐。
1:30 这里面跨过了网站、
1:32 文件、表格和内部沟通工具。
1:35 它还有时间上的连续性，
1:36 今天看过哪些人，
1:38 明天出现了哪些新名字。
1:40 都需要衔接。
1:41 招聘团队希望接到的是值得进一步沟通的人选，
1:45 然后把精力放到交流和争取候选人上。
1:48 这个例子也解释了为什么罗曼那么
1:50 强调最后一段路。
1:52 如果 AI 只找到了论文，
1:53 剩下的下载、
1:54 查重、整理和联系都等人接手，
1:57 那么人仍然需要记住整件事，
1:59 判断它卡在哪里，
2:00 再把流程往前推。
2:01 哪怕前面生成了很多内容，
2:03 这项工作依然占着人的注意力。
2:06 为了让 AI 继续往下做，
2:07 GrokBot
2:08 团队很早就确定运行环境放在云端。
2:11 用户不应该反复研究合上笔记本以后任务
2:14 还会不会执行，
2:15 从手机发起的工作是不是还要连着家里的电脑。
2:18 罗曼希望机器人独立于用户设备存在。
2:20 你从不同地方联系它，
2:22 它都保留一致的工作状态。
2:24 这个决定让等我回来再看结果有了基础，
2:27 因为任务的持续执行不再系在你眼前这台设备上。
2:30 他们还给机器人提供自己的计算机使用环境，
2:33 理由同样来自具体工作。
2:35 销售团队用到的一些软件并没有
2:37 完善的 API 或者 MCP 支持。
2:40 你可以把这些接口理解成软件留给
2:42 程序的办事通道。
2:43 通道不好用的时候，
2:44 人依然能打开网页、
2:46 点击按钮、
2:47 在输入框里填写内容。
2:49 机器人也需要这套能力。
2:51 罗曼用了一个很容易理解的比喻，
2:53 你招来一位新同事，
2:54 会给他配电脑。
2:56 如果让他永远坐在你旁边，
2:57 两个人轮流抢同一台笔记本，
2:59 还互相碰到对方的登录凭证，
3:01 协作会非常别扭。
3:03 让 AI 有自己的工作环境，
3:04 就是在减少这种互相干扰。
3:06 不过有了环境，
3:08 具体动作仍然可能失败。
3:10 他提到早期机器人
3:11 操作 Salesforce 仪表盘时，
3:13 鼠标控制不够精细，
3:14 点不到某个区域，
3:15 整个工作流就卡住了。
3:17 团队把这种明确的失败交给底层基础设施团队，
3:20 一项项解决。
3:21 当一个过去连续 7 天失败的
3:23 销售流程终于跑通，
3:24 使用者第二天就能感受到变化。
3:26 这样的改进在界面上未必多出一个按钮，
3:29 但它让一整块工作变得可以交出去。
3:32 对这款产品而言，
3:33 能不能点击正确的位置和模型能不能给
3:37 出漂亮的分析，
3:38 同样影响最终交付。
3:40 罗曼描述的交付也包括先带回一份结果，
3:43 等用户反馈，
3:44 再进入下一轮工作。
3:45 关键在于机器人能把该自己推进的部分接过去，
3:49 在需要人判断的时候再把问题交回来。
3:51 这样人的参与有了明确的位置，
3:54 不必始终守着整个执行过程。
3:56 而有自己电脑的同事还应该记得之前
3:58 一起做过什么。
4:00 罗曼对每项任务都新建一个聊天窗口的
4:02 方式不太满意，
4:03 他发现自己总在不同窗口之间复制粘贴背景。
4:07 GrokBot 尝试按工作角色来组织智能体，
4:10 让负责某类事务的机器人保留过去的交互记忆，
4:13 持续积累对用户的了解。
4:15 内部试用时，
4:16 常见的方式是一个人设置 5~10 个机器人。
4:19 分别负责不同领域。
4:21 大约到第二周结束，
4:22 有人开始把其中表现突出的一个设为幕僚长，
4:26 用户主要跟它沟通，
4:27 再由它分派任务给其他机器人。
4:30 有意思的是，
4:31 团队没有立刻把这个用法写成所有人的标准答案。
4:34 他们在外部用户上手时，
4:35 刻意不先教大家搭建幕僚长，
4:37 而是观察用户会不会自己走到这个方向。
4:40 看到不少人独立形成了类似用法之后，
4:43 团队才开始适度鼓励这种模式，
4:45 同时保留其他组织方式。
4:47 这段经历说明他们也在学习用户怎样
4:50 管理一支 AI 团队。
4:51 角色划分和长期记忆提供了基础。
4:54 具体要设几个角色，
4:55 是否需要统一协调者，
4:57 则需要在工作里摸索。
4:58 罗曼自己更深入的用法是让机器人持续
5:01 处理大量信息。
5:03 基础版本接入邮箱和 Slack，
5:05 再告诉它自己在公司的职责、
5:07 关心什么，
5:08 哪些情况需要立即提醒，
5:09 哪些内容放进每日简报就够了。
5:12 在他的进一步配置里，
5:13 机器人还会关注 X 上
5:15 提到 GrokBot 的内容，
5:16 结合内部信息，
5:17 把收到的故障反馈交给测试机器人尝试复现。
5:20 并通过消息服务推进后续处理。
5:23 这样，收集信息和处理信息之间就有了连接。
5:26 测试机器人也有一个很具体的任务，
5:28 在自己的环境里安装 GrokBot。
5:31 测试桌面应用的新版本，
5:32 跑指定的 10 个工作流，
5:34 把结果写入 Notion 文档，
5:36 再与旧版本的测试记录对比。
5:38 一个机器人操作另一个 AI 产品，
5:40 在这里承担的是实际的软件测试工作。
5:43 罗曼还提到一个容易被忽略的细节。
5:45 机器人越来越多，
5:46 产出的内容也会越来越多。
5:48 他会规定这些成果存放的位置，
5:50 让每天要读的摘要统一写进一个数据库。
5:53 方便自己查看。
5:55 对使用者来说，
5:56 完成任务还包括把成果交到合适的地方。
5:58 假如结果散落在不同对话里，
6:00 人每天仍要挨个寻找，
6:02 整理负担就会重新回到自己身上。
6:04 当这些流程长期运行，
6:06 AI 就开始有条件主动找人。
6:08 罗曼说，
6:09 有些用户已经让机器人在特别紧急时呼叫自己。
6:12 他在访谈时还没有这样设置。
6:14 这个用法能否成立，
6:16 取决于用户相信它能辨别紧急情况，
6:19 不会不断误报。
6:20 所以，主动性也有明确的工作要求。
6:23 该打断时及时打断，
6:24 其余信息安静地整理好。
6:26 否则，
6:27 一个全天候运行的助手也可能变成全天候
6:30 制造通知的来源。
6:31 再回头看，
6:32 这样一款产品是怎么做出来的？
6:34 时间线很紧凑，
6:35 从第一行代码到内部原型大约一个月，
6:38 从内部测试到公开发布又过了大约三周。
6:41 录制访谈时距离公开发布也只有大约三周。
6:45 罗曼强调，
6:46 最初只有几个人，
6:47 他们坐在独立的办公区域，
6:49 用私有 Slack 频道沟通，
6:51 每天快速决定大量细节。
6:53 团队的任务是探索通用知识工作的体验。
6:56 因此选择从零构建独立产品。
6:58 这并非一开始就毫无争议，
7:00 Cursor 已经有人拿来处理非编程任务，
7:03 沿用现成产品有它的吸引力。
7:05 但罗曼担心开发者熟悉的界面会让非技术
7:08 用户望而却步。
7:09 不同产品思路不断塞进新标签页，
7:12 也容易让整个体验失去一致性。
7:14 重新开始给了他们重新安排交互的自由。
7:17 不过这种自由没有自动带来可用性。
7:20 真正让团队看见问题的，
7:22 是接下来那些很费时间的人工上手指导。
7:25 罗曼说，在大约两周里，
7:27 核心团队亲自带着几百名早期用户使用产品。
7:30 有时云端电脑迟迟启动不了，
7:32 或者用户完全不明白接下来该干什么，
7:35 团队成员就在通话里一起等上 20 分钟。
7:38 亲眼看着用户卡住，
7:39 会让一个抽象的待办事项变得非常具体。
7:42 明天还有新用户要来，
7:43 同样的问题必须尽快解决。
7:46 研发者熟悉系统，
7:47 会下意识绕过的障碍，
7:48 在这些通话里被重新看见。
7:51 他们邀请的也包括公司不熟悉的用户。
7:53 一位通过朋友认识的咖啡店老板，
7:55 后来成了重度用户。
7:56 他反馈， Shopify 集成不稳定，
7:58 也会指出商品文案没有按需要的方式写。
8:01 这些问题与技术公司内部试用得到的
8:04 反馈很不一样。
8:05 这让团队看见了通用产品的另一面。
8:07 你希望服务普通经营者，
8:09 就要理解对方怎样经营生意。
8:11 开发团队内部觉得顺手，
8:12 还不足以回答这个问题。
8:14 在这段发布前的迭代里，
8:15 罗曼给出的一个关键词是下线功能。
8:18 早期原型里放了很多实验性设计，
8:21 也把方便研发调试的内容塞进了用户界面，
8:24 包括模型的内部过程、
8:25 存储的具体记忆等。
8:27 到了真正面向用户的时候，
8:29 团队重新判断哪些信息需要用户主动处理，
8:32 哪些应该藏到后台。
8:34 他们希望用户交代任务后看到机器人正在工作，
8:37 并在合适的时候收到进展，
8:39 而不必逐次围观它调用工具、
8:41 点击网页。
8:42 用户反馈也提供了更细的边界。
8:45 有些人想看机器人的待办清单，
8:47 了解任务优先级和当前状态。
8:49 这和阅读一长串底层执行日志
8:51 是两种不同的信息需求。
8:53 前者帮助人协调工作，
8:55 后者未必能帮助人做决定。
8:57 罗曼把这套取舍浓缩成一个发布文案的练习。
9:00 团队应该试着补完 GrokBot
9:02 现在可以这句话，
9:03 把新增能力说清楚。
9:05 例如
9:05 用户直接说每天早上 8 点提醒自己做某件事，
9:09 机器人就把定期任务设好。
9:11 设置流程中的触发条件和动作仍然需要被
9:14 系统正确处理，
9:15 但用户可以通过一句话交代。
9:17 按照罗曼在访谈中的说法，
9:19 当时平台上 99% 的自动化任务
9:22 都是这样建立的。
9:23 这套产品思路
9:24 受到了 OpenClaw 的启发。
9:25 罗曼认可它展示的两点，
9:27 让模型接触更充分的工具，
9:29 以及把 AI 当成持续协作的伙伴。
9:31 GrokBot
9:33 进一步追求的是减少搭建环境和学习
9:35 操作方式的负担。
9:37 让更多人能够用起来。
9:38 他甚至希望普通用户不需要知道什么是技能，
9:41 也不必记住斜杠命令。
9:43 那些能力可以在后台存在，
9:44 产品负责在需要时用上它们。
9:47 界面变简单以后，
9:48 系统承担的责任反而更多，
9:50 因为它必须把用户的意图转成可靠的执行。
9:53 当然，这支团队的目标还在向前延伸。
9:56 罗曼希望人与机器人有时能像同事一样，
9:58 开一个 5 分钟短会，
10:00 分享屏幕，
10:01 把问题说清楚，
10:02 然后回到各自异步工作的状态。
10:04 这是他想构建的体验。
10:06 进入企业以后，
10:07 还有更多问题需要回答。
10:08 机器人怎样在多人团队里协作？
10:11 怎样理解公司系统里积累的历史？
10:13 组织层面的记忆又该如何安排？
10:15 罗曼承认，
10:16 这些问题中还有很多没有答案。
10:18 个人生活和工作也可能需要不同的机器人组合，
10:21 保持边界，
10:22 同时采用相近的协作方式。
10:24 要沿着这个方向快速推进。
10:26 团队内部也需要一套共同的判断方法。
10:29 罗曼说，当两个产品方案各有道理，
10:31 很难取舍时，
10:33 他们会退后一步，
10:34 想想在同样的情境下，
10:35 希望一个真实队友怎样做。
10:37 这个问题帮助团队形成一致方向，
10:40 再去解决实现上的困难。
10:42 它把讨论落到了合作体验上。
10:44 人需要得到什么反馈？
10:45 什么时候需要参与？
10:47 哪些事情可以放心交给对方？
10:49 执行上，他经常重复的另一句话是，
10:52 直接去做。
10:53 在他描述的文化里，
10:54 发现问题的人要主动调动资源推动解决。
10:58 他加入 Cursor
10:59 时团队大约 15 人，
11:00 后来发展到 1000 多人，
11:01 又成为 SpaceX AI 的一部分。
11:03 他认为保持快速行动的关键在于团队互相信任、
11:07 执行能力，
11:08 也清楚共同的方向。
11:10 与此同时，
11:11 他承认这种争分夺秒、
11:12 带有混乱感的环境并不让所有人都觉得舒服。
11:16 速度也包括愿意重审已有方向。
11:18 罗曼认为，
11:19 随着模型能力变化，
11:20 公司的优先级、
11:22 核心产品和用户体验都需要持续更新。
11:25 两年前合适的产品未必适合今天。
11:28 这种压力解释了为什么他们会投入一款独立的
11:31 知识工作产品，
11:32 也解释了为什么发布前还能大幅删减
11:34 原型中的设计。
11:36 这就带出了访谈后段的商业问题。
11:38 如果模型不断变强，
11:40 别人也能获得类似能力，
11:41 一家 AI 产品公司靠什么持续赢得用户？
11:45 罗曼的回答是反复把未来几个月可能做到的事
11:48 尽量提前变成今天可以使用的产品。
11:51 模型暂时做不好的地方，
11:53 先通过工程和产品设计补上。
11:55 等模型能力追上来，
11:56 再拆掉那些临时结构，
11:58 继续解决下一批问题。
12:00 这也是他所说的删除产品。
12:02 过去为了弥补模型不足而增加的操作和功能，
12:05 可能随着能力进步失去必要性。
12:07 团队需要愿意放下自己已经做出来的东西，
12:10 让产品继续变得简单、
12:12 强大。
12:13 按照他的理解，
12:14 用户信任来自这一轮轮持续交付。
12:16 他们愿意投入时间，
12:17 是因为产品不断带来新的实际用途、
12:20 分发优势和数据优势，
12:22 可以在这个过程中积累。
12:23 护城河的讨论需要接到当下具体
12:26 解决了什么问题上。
12:27 我觉得把这段回答放回前面的销售和招聘
12:30 案例就很清楚了。
12:32 所谓把未来提前带来，
12:33 有时候落实为一个很小的改进。
12:36 过去点不到的按钮终于点到了，
12:38 原本中断的流程终于完成了，
12:40 用户少了一次接管，
12:41 才开始愿意把更多任务交出来。
12:43 这也让 AI
12:44 同事这个说法有了可以观察的标准。
12:46 它有没有获得必要的背景和工具？
12:48 能不能连续推进？
12:50 遇到问题是否合理反馈？
12:51 最后有没有把结果放到人能使用的地方？
12:54 每一项都需要真实工作来检验。
12:56 罗曼给新用户的建议也很朴素。
12:59 提供必要的工作背景，
13:00 再让机器人建议几件能够接手的事情。
13:03 他自己曾让它阅读邮箱和 Slack，
13:05 提出 5 项建议，
13:06 其中两项确实有用，
13:08 于是就创建了两个机器人去做。
13:10 从两项具体工作开始，
13:11 交代清楚、
13:12 观察交付，
13:13 再逐步扩大范围，
13:15 这比一开始设想一支无所不能的数字
13:17 团队更容易落地。
13:18 GrokBot
13:19 分享的这些早期经验最终都回到同一个问题。
13:22 当任务交出去以后，
13:24 你能不能把注意力真正转向另一件事？
13:27 如果这种放心能够在越来越多的工作里重复发生，
13:29 AI 作为伙伴的价值才会一点点建立起来。
13:33 好了，以上就是本期视频的所有内容。
13:35 如果你喜欢本期视频，
13:36 不要忘记订阅、
13:38 点赞、分享，
13:39 这样就不会错过每一期的精彩内容。
13:41 感谢收看，
13:42 我们下期再见！