GrokBot 产品负责人复盘：一个月做出 GrokBot，从聊天框到“拥有自己电脑的 AI 同事”
Roman Ugarte 讲述 GrokBot 的诞生：为什么离开 Cursor 另起炉灶、为何给 Agent 一台云端电脑，以及小团队怎样用四周做出原型，再靠内测、删功能和可靠性修补走向公开发布。
把一项工作交给 AI，它很快完成了 90%，听起来已经很强。但最费人的往往正是剩下的 10%：核对事实、反复纠偏、补齐遗漏，再把结果搬进真正要使用的办公软件。只要你始终不敢离开，任务就没有真正交出去，AI 只是换了一种方式把工作还给了你。
这正是 GrokBot 想解决的问题。Roman Ugarte 把“完成 90%”与“完成整项工作”之间的差距视为一次质变：前者仍需要人全程监督，后者才会带来把责任交给一位同事的感觉。于是，团队没有继续做一个更强的聊天框，而是把 GrokBot 设计成长期在线的知识工作 Agent——它能记住上下文，在云端持续运行，还能使用自己的电脑完成跨软件任务。
Roman 曾负责 Cursor 的增长，后来参与孵化 GrokBot 并负责产品方向。在 Lenny's Podcast 的这场复盘中，他讲述了一支数人小组如何从第一行代码出发，用约四周做出内部可用原型，又用约三周完成内测并推向公开发布。所谓“一个月做出 GrokBot”，指的不是一个成熟产品突然诞生，而是团队在极短时间内跑通了最关键的产品假设。
真正值得追问的是：他们为什么不把通用 Agent 直接塞进 Cursor？为什么坚持让每个 Bot 拥有自己的云端电脑？一个能跑起来的原型，又如何经过真实工作、删功能和可靠性修补，逐渐变成可以交付任务的“AI 同事”？这几项选择，才是 GrokBot 诞生过程里最有复用价值的部分。
把 Agent 当作“拥有电脑的同事”，而不是“带插件的聊天框”
Roman 认为，多数人目前仍把 Agent 理解为“聊天机器人 + 若干外部连接（API/MCP）”：你向它发问，它调用搜索或特定的企业软件接口，最后给出一段回答。
GrokBot 团队在一开始就确立了一个被称为“以同事为尺”（Colleague-pilled）的思考锚点：如果把 AI 当作真实世界里招募的一位新同事，我们究竟会如何与它协作？
沿着这个视角，他们做出了两个关键的底层架构决策：
1. 彻底全云端化，状态持久保留
在早期探索中，OpenClaw 给团队带来了重要启发。Roman 明确提到，OpenClaw 做对了极为关键的两件事：一是给强模型提供了更真实的系统工具能力，二是率先把 AI 的心智模型从“聊天对话”推向了“协同工作的同事”。GrokBot 从中汲取了大量灵感，并试图把这些原语产品化，以降低设置门槛。Roman 所描述的使用摩擦包括：Agent 究竟运行在本地还是云端、电脑是否需要保持唤醒，以及从手机发出的任务是否仍依赖家中的电脑。
GrokBot 选择让所有 Agent 统一长在云端。每一个 Bot 都是一个长期存续的实体，拥有连续的交互记忆，不再是“一开新会话就失忆”的临时会话。用户在手机上发一条消息、在电脑上安排一项长期任务，Bot 都在同一套状态下在后台静默运转。
2. 让每个 Bot 能使用自己的云端电脑（Computer Use）
这是整个产品最核心、也最具有争议的技术决策。很多技术团队倾向于通过 API 或模型上下文协议（MCP）去连接外部工具，但真实工作场景中存在两个巨大的现实障碍：
- 现实世界中大量关键业务工具没有好用的 API：Roman 以销售团队使用的工具和 Salesforce 仪表盘为例；即使存在部分接口，也未必足以覆盖真实工作流程。
- 共享屏幕的荒谬性：Roman 打了一个形象的比方——如果公司新入职一位人类同事，你绝不可能对他说：“你没有自己的电脑，你就坐我旁边，我们俩共用这台笔记本，共用一套账号密码，屏幕点按互相打架。”
团队没有在访谈中公开具体的运行实例拓扑，但 Roman 确认，这些长期存续的 Bot 能使用自己的云端电脑（access to its own computer）。这意味着它能尝试像人类一样通过像素识别、移动光标与输入字符，与各种网页和桌面应用交互。当遇到没有 API 的老旧系统或复杂网页时，Bot 因而多了一条通过图形界面推进流程的路径，而不必完全受制于接口缺失。
更重要的是，GrokBot 团队认为这种云端电脑的底层操作在未来应当对用户彻底无感。用户不需要像操作远程桌面一样去接管屏幕，AI 只需要汇报工作进度，底层的“电脑操作”只是它干活的实现机制。
访谈没有披露每个 Bot 的具体资源隔离方式、成本或闲置策略。因此，能够确认的是“Bot 可使用自己的电脑”这一产品抽象，而不是一套可以据此估算的基础设施拓扑。
委托方式对照
同一个任务，聊天框和“数字同事”差在哪里？
切换两种模式，观察人的工作负担在哪一步重新出现。这里是访谈观点的概念示意，不代表实测完成率。
以回答为终点
- 人提出问题把背景压进一次提示词。
- AI 生成内容输出答案或中间材料。
- 工作交还给人检查、复制、登录系统、完成后续操作。
人的负担仍要亲自把最后一公里走完
以任务闭环为目标
- 人交代目标与边界提供上下文、权限和验收条件。
- Bot 持续推进调用接口，必要时操作自己的云端电脑。
- 按需汇报与确认遇到高风险动作或异常时让人介入。
- 交付可验收结果人重点检查结果，而非盯住每一步。
人的负担从执行者转向授权者与验收者
为什么离开 Cursor 另起炉灶，又如何在一个月内做出来？
在孵化 GrokBot 之前，团队背后的核心产品是已经在大批程序员中建立起口碑的 AI 代码编辑器 Cursor。Roman 加入 Cursor 时团队约 15 人，后来团队扩至 1000 多人，随后 Cursor 被 SpaceX 收购。主持人在访谈中把 GrokBot 的选择与另一种产品路径对照：把多种 Agent 形态放进同一个界面，每扩展一种任务形态就增加一个标签页，最终容易显得拥挤。
Cursor 团队内部曾有过激烈探讨：程序员也经常在 Cursor 里写非代码的内容，直接在现成产品上迭代岂不是阻力最小？
但他们最终选择了完全从零开始做独立产品，原因在于避免“把公司的内部组织架构当成产品形态交付给用户”（Shipping your org chart）：
- 认知门槛与心智包袱：代码工具的界面密布着终端、文件树、调试面板，对非技术人员具有天然的劝退感。如果只是在一个代码工具上硬塞一个“非代码工作区”，不仅界面会变得杂乱臃肿，而且用户能清晰地感觉到这是几个不同产品愿景在强行共用一块屏幕。
- 全生命周期的产品控制力：要打造适合通用办公的“同事感”，必须对界面上的每一个像素、每一处交互流向拥有完全从零设计的掌控力。
为了避免陷入大公司常见的漫长规划周期，团队组建了一个极小的封闭小组（仅有数人），搬到办公室的独立物理区域，使用独立的私密 Slack 沟通频道，在与外界相对隔离的状态下快速做出海量微观决策（micro decisions）。Roman 认为，如果当时采用大团队配合 6 到 12 个月的宏大愿景推进，很可能根本走不到最终结果。
这也引出了关于研发节奏的关键事实——整个项目其实由清晰的三阶段时间线构成（访谈中的数字均为约数）：
- 第一阶段（约一个月）：团队写下第一行代码到拿出首个内部可用的原型（functional, useful prototype）。这里的“一个月”指的是内部能跑通关键链路的最小可用版本，绝非对外发布的成熟成品；
- 第二阶段（约三周）：从内部测试（Internal Beta）走向公开上线（Public Launch），集中攻克关键系统问题；
- 第三阶段（约三周）：录制访谈时，距离公开发布又过去了约三周，产品仍在极早期演进中。
把“一个月”拆开看
从第一行代码到访谈录制，实际经历了三个阶段
点击阶段查看当时完成了什么、又还缺什么。时间均为访谈中的约数。
做到：关键链路内部可用
数人小组快速形成原型
独立办公区、私密 Slack 和大量微观决策减少了协调成本。这里的终点是 functional, useful prototype，不是成熟公开产品。
重点：删功能 + 修可靠性
从 Internal Beta 走向 Public Launch
团队隐藏调试信息、简化界面，并围绕真实任务收集失败类型、量化改善约 5 个关键后端问题。
状态：仍在 very early innings
公开发布不等于工作完成
录制访谈时，产品公开上线约三周。GUI 点击、登录、组织记忆和多 Bot 协作仍有明显边界。
团队先在全员会上推广 GrokBot，把它当作现实压力测试；第一周，来自意料之外部门的一些同事把原本在 ChatGPT 或其他聊天界面上做的日常 Agent 任务迁到 GrokBot；看到这种跨部门的真实工作迁移后，团队立即转向公开发布准备。
组织支撑：小团队为什么能在四周内做出原型？
在 Roman 看来，能在一个月内拿出原型，不仅是研发隔离的结果，更依赖于团队内部特定的速度文化：
- 高度信任与共识：团队成员对共同的前进方向有清晰共识，彼此深度信任同事能够独立执行并交付结果；
- 守护初创感：即使公司整体规模逐步扩大，团队仍刻意保留一种“略带混乱但能极速产生实际影响”的初创氛围（startup feeling）；
- 两条核心原则：一条是敢于下线甚至砍掉多余功能的“删产品”（deleting the product）；另一条是“直接把事情办成”（just do the thing）——当团队成员在工作中看到该做或该修的事时，不需要层层请示审批，而是主动认领、快速修好并拉齐所需资源。Roman 将这些解释为小团队在早期保持超常敏捷的组织土壤，而非普适的通用管理法则。
从内部原型到公开上线：接下来三周为什么主要在“删”？
当产品在公司内部推开、并逐步启动外部定向测试时，团队面临的最大挑战不是“功能不够用”，而是“功能做多了”。
在临近正式发布前的约三周里，产品经历了密集的下线功能（Unshipping）过程：
1. 拿掉工程师思维的“透明度工具”
在内测初期，为了方便排查问题，界面暴露了模型内部思考、记忆与工具调用等调试信息。
这些细节在开发者看来很有掌控感，但在通用办公中却造成了严重的认知过载。正如你不会要求真实同事每隔三秒向你汇报“我刚才点了哪个按钮、在脑子里想了哪句话”一样，人类不需要在交互界面中盯着滚动的文本流。团队收到过一些反馈，部分用户希望看到 Bot 的待办清单和大致优先级；但没人要求长串文本流和 chain-of-thought。最终团队将界面大幅精简：Bot 收到任务后，用户主要看到的是类似 Slack 风格的“正在输入”与绿色在线状态灯；Bot 按需发送阶段性进度，完成后呈现结果。
2. 从“增加了什么按钮”转向“Bot 能完成什么”
传统 SaaS 软件非常执着于在界面上展示“功能点”（比如侧边栏的各种设置项、流程图构建器、多选下拉菜单）。但在 Agent 时代，每增加一个复杂的界面控件，往往意味着把本该由 AI 处理的负担甩给了人类。
典型的例子是自动化流程（Automation）的配置：
- 很多工具的做法是在界面左侧提供复杂的流程画布：点击新建、选择触发条件、选择响应动作、配置定时器，交互极其繁琐，导致普通用户极少去配置自动化。
- GrokBot 选择彻底干掉自动化配置页面，直接支持自然语言定义：“每天早上 8 点提醒我。”所有的调度逻辑全由 Bot 在后台自行管理。据 Roman 称，平台上 99% 的自动化是通过这类自然语言对话建立起来的（这是受访者口述的平台数据，并非独立第三方审计）。 这种对多余控件的克制，逐步沉淀为团队内部可复用的两道判断题：
- “这项工作的发布文案是什么”：团队会问“这项工作的发布文案是什么”；如果无法说出足够有吸引力、用户能直接感受到的价值，这项工作也许不该做。
- 能否把“Grok Bot now has ...”改写为“Grok Bot can now ...”？：将审视焦点从“界面新增了某个按钮、下拉框或集成入口”转回“Bot 新增了哪项可直接执行的任务能力”，以此倒逼团队尽量删除界面上所有不必要的像素。
内测三周的真实攻坚：不仅是砍功能，更是量化修补系统缺陷
在公开发布前的这约三周内测中，团队所做的工作远不仅是做视觉减法或删掉实验性功能。Roman 透露，当时的 Bot 依然存在大量基础失败，例如经常点不中目标按钮、或者卡在系统登录环节无法进入。团队紧盯真实用户的具体任务，收集任务与失败类型，量化并按周改善。在那三周时间里，工程团队集中处理了大约 5 个最关键的后端问题。即便如此，系统也并非已经能稳定接管任何复杂流程，其底层仍有诸多需要人工兜底和持续打磨的边界。
把产品扔进真实工作：团队究竟验证出了什么？
在产品走向公开发布前的大约两周时间里，团队做了一件极其重度的事：由核心团队亲自下场，一对一手动为数百名早期用户（主持人估算约 200 到 300 人）完成使用引导（Onboarding）。这不只是数字展示，更形成了一个紧密的高频反馈闭环：在早期的 20 分钟辅导通话中，经常出现云端电脑起不来、或者用户面对界面完全不知如何开始的窘境。团队确立的原则是“今天发现的问题，必须在明天引导下一位用户前修掉”。同时，团队刻意邀请了独立咖啡店老板等完全处于硅谷技术圈之外的非技术用户，核心目的正是借此检验它是否真正算得上一款通用的知识工作产品，而非仅限极客使用的玩具。
在这场高密度的碰撞中，几种最具生命力的使用形态自然涌现出来：
1. “幕僚长”（Chief of Staff）协同模式
内部推出后的最初一两周，常见模式是每人建立 5 到 10 个 Bot，每个负责不同的工作领域。
到第二周末，团队观察到一些用户会挑一个表现突出的 Bot 作为“幕僚长”，主要与它对话，再由它把任务分派给其他 Bot。这是部分用户自发形成的用法，并非多数人的普遍状态，也不是不可逆的固定层级；团队只考虑对这种模式作轻度引导。
2. 人才招聘的主动挖掘
在人才招聘场景中，该公司的招聘团队认为，顶尖人才往往不是那些正在积极投简历的人，而是需要主动发掘的目标。
团队内部配置的招聘 Bot 展现了一种探索流程：访问前沿学术会议的网站，下载那些尚未被 Google Scholar 收录的最新 PDF 论文；提取论文中的作者名单，将新名字添加到表格（Spreadsheet）中；随后检查公司内部是否有人与其具备直接联系；如果有，就直接向相关同事发送一条 Slack 消息请求引荐。这一链条展示了云端电脑配合长流程 Agent 在串联非标网页、文档提取与内部协作上的探索潜力。
3. 销售与非标企业后台的探索
销售人员经常需要与缺少好用 API 的工具和企业看板打交道。在内测中，Bot 曾因鼠标无法精确点击 Salesforce 仪表盘的目标位置，或无法登录系统而失败。团队通过改善浏览器可见性、屏幕像素与鼠标控制等基础能力，尝试让 Bot 逐步具备操作这类界面的能力。但 Roman 同时指出，这种交互在当时仍会失败，仍需持续优化，并非已经稳定接管任何系统。
4. 个人探索案例：递归测试（Bot in Bot）
在内部测试中，这也催生了一些极客式的个人用法。例如 Roman 个人曾在自己的云端电脑环境中，反向下载并安装了桌面版 GrokBot 自身。他设置了一个 QA tester bot，专门用来测试 10 个需要持续确认其越来越好的关键工作流，并将测试结果写入 Notion 与历史客户端版本进行对比。需要指出的是，这属于 Roman 个人的使用尝试，并非团队已经全面制度化运行的固定 QA 流程。
5. 从“被动等待”到设定边界的主动提醒
初阶用户通常把 Agent 当作被动的信息整理工具，让它定期通报总结。而更进一步的探索方向是：在让 Bot 接入邮件、即时通讯等信息流后，给它设定明确的触发边界——在大多数时候保持静默，只在用户预先定义的极少数紧急情形下触发主动呼叫（Page）或提醒人类。这种用法成立的前提，是用户足够信任 Bot 不会频繁误报。
高阶协作：统一输出与每日摘要
除了单点任务，Roman 还提到了高阶用户的第二层协作方法：设计多个 Bot 之间的协同，让负责不同垂直领域的 Bot 把各自的产出集中写入一个统一、对人可读的数据库或存储区（如 Notion 或统一表格），人类用户无需逐个检查每个 Bot 的会话，而是通过一份整合后的每日摘要（Daily Digest）进行集中阅读与决策。
工作流拆解器
真正的 Agent，不只给答案，还要穿过一条工作链
选择一个访谈案例，查看 Bot 的输入、连续动作、人的检查点与当时的能力边界。
它证明什么：定时运行、非标网页、文档处理和内部协作可以串成一条链。
当时的边界：点击精度和登录仍会导致任务失败，Computer Use 不是万能路径。
证据边界：这是 Roman 的个人尝试，不是已制度化的团队 QA 流程。
它改变什么：用户不用逐个翻阅每个 Bot 的会话记录。
演进路径：从个人信息闭环到企业渗透的未决挑战
在信息闭环的探索中，Roman 区分了不同主体的模式：V1 是很多用户会采用的常见模式，Bot 覆盖 Slack 和邮件，按优先级即时提醒或放入每日汇总；Roman 说自己的个人配置大约处于 V3 或 V4，Bot 摄取 X 上的 GrokBot 提及，结合内部上下文，协同 QA tester 尝试复现 bug，再通过他自己的消息渠道快速响应反馈。这一探索的新增价值集中在“外部信号 → 内部上下文 → QA 复现 → 响应反馈”的链路。
从个人探索走向企业落地，Roman 回顾了 AI 编程工具的扩散路径：早期 AI 编程工具用户先在晚上和周末的个人项目中体验价值，回到工作场所后要求使用；Roman 预计知识工作 Agent 也会先在个人场景产生 aha moment，再进入团队并贡献有经济价值的工作。
不过 Roman 同时强调，当 Agent 尝试进入真实复杂的企业环境时，仍面临诸多未解问题（unanswered questions）：Bot 如何进入复杂公司系统、理解公司上下文和历史，如何在更大团队中工作，以及组织级记忆应是什么样。
护城河怎么来：先把未来三到六个月的能力做出来
在当前的 AI 创业环境中，创始人和投资人最焦虑的问题往往是：“如果底层大模型厂商（如 OpenAI、Anthropic）在下一代底座模型里直接集成了这类能力，上层产品的护城河究竟在哪里？”
针对这种战略焦虑，Roman 强调，不要从 12 到 24 个月后的战略图倒推产品，而要先专注于今天真正有用的东西。Lenny 随后把这套看法概括为：先做出一款让人着迷（Obsessed）的产品，护城河往往是在这个过程中被发现的，而不是预先规划出来的。
团队在过去几年的迭代中，摸索出一套类似“时间机器”的推进节奏：
- 预判趋势：大致判断未来 3 到 6 个月里，模型能力的提升会让哪些今天做不到的事变为可能。
- 提前拉取未来：不要只等底座模型成熟，而是在现有模型之上搭建工程脚手架（Scaffolding），尽量把那种未来体验提前交到用户手里。
- 果断删除脚手架：当底层模型原生补齐能力后，删掉已经不再必要的脚手架，把它变成产品的默认能力；然后继续瞄准下一个仍然困难的边界。
这也解释了 Roman 为什么认为，团队大约每六个月、近期甚至更短，就需要显著重塑产品优先级与核心形态：当模型能力和用户行为都在快速变化时，今天成立的产品边界未必能长期保留。
Roman 认为，这种不断“自我颠覆、敢于删代码”的快速循环，其核心逻辑在于不被动等待底座升级，而是通过工程手段把未来的能力提前交付给用户；在此过程中，团队有可能在真实用户的日常使用习惯、数据反馈与分发渠道上建立起先发优势，而不是依赖静态的战略图纸去空谈无法撼动的护城河。
普通人怎么开始：先交出一件边界清楚的工作
对于初次尝试脱离单次对话模式、尝试构建长效 Agent 助手的读者，访谈中给出了具体的落地切入点与探索建议：
-
像对待新员工一样提供真实上下文，但坚守安全边界 不要指望一个漂浮在真空中的模型凭空替你分忧。第一步往往是让 Bot 接入日常工作涉及的关键渠道（如工作邮箱、团队协作即时通讯工具、知识库）。Roman 认为，许多人会要求个人工作与公司工作彼此分离，并承认组织级记忆、多个 Bot 如何在真实复杂团队中协作仍有大量悬而未决的问题（unanswered questions）；Lenny 随后进一步提出了个人与工作数据混用（cross-contamination）及工作数据外泄（exfiltration）的风险。 基于这些风险，本文建议在实际开放权限时从最小权限与个人/工作数据分离起步，优先采用可随时撤销的授权，并对涉及外部发送或高风险操作的动作设置人工确认。
-
用“反向发问”破局冷启动 面对全新的 Agent 界面，很多人的困惑是“我不知道该让它干什么”。Roman 提到他在实际使用中的做法是让 Bot 翻阅自己的邮件与 Slack，并给出提示：建议 5 件可以帮我分担的事情，以及为了做到这些分别需要什么条件（Suggest like five things that you can take off of my plate and what it would take for you to do that）。
在实际尝试中，可按这个思路将其改写为更易落地的提示词：
“请通读我近期的邮件与日常沟通记录，结合我的业务角色，主动列出 5 项你可以直接帮我分担的具体工作块；并告诉我，如果要搞定这几项工作，你分别还需要获得哪些系统权限。”
Roman 在自己的那次尝试中，5 项里有 2 项对他确实有用，于是他为这两项各建了一个 Bot。对读者来说，更稳妥的起点是先选择 1 到 2 项边界清楚、结果可校验的任务，而不是立刻把全部工作一次性交出去。
从聊天框里的文字生成，到云端电脑上长效驻留的数字协作网，AI Agent 正在经历一场由“炫技演示”向“实际可用”的重心迁移。然而必须清醒地看到，正如 Roman 在访谈尾声所强调的，这一波 Agent 的探索仍处于“极其早期的阶段”（very early innings）。它远没有达到能让人类完全闭眼放权、彻底托付后背的成熟程度；更现实的路径，是在明确边界、保持校验的前提下，将那些重复性高、流程明确的劳动逐步交付，在人机协作的持续磨合中探索新的工作形态。