2026 年 9 月，SpaceXAI 办了一场持续多天的直播企划：三位工程师 Matt Palmer、Lauren Tan、Roshan Sadanani 当着观众的面，用 72 小时从零搭一家能运转的公司，GitHub 组织现场新建，连名字都是现起的——Ship by Thursday。本文整理自这场直播的 54 分钟视频，覆盖上午的 GrokBot 101 课程和下午开工的前半段。
这场工作坊值得看的原因不在“三天搭一家公司”的直播叙事，而在它把 GrokBot 的产品哲学讲透了：AI 同事不是一堆可以外包的零散任务，而是承担职责、对结果负责的队友。落到产品上是三个决策——按职责建 Bot 而不是按任务开会话、一切常驻云端、每台 Bot 有自己可操控的 Linux 虚拟机。直播里从一句话生成表单、自动转二维码、录制技能、细粒度授权到多 Bot 群聊编排，全程真机演示。如果你正在评估怎么把智能体组织进日常业务，或者纠结哪些重复工作值得外包给常驻 Agent，这篇整理可以当速查用。
01 这场直播在干什么：三个人、72 小时、一个空 GitHub 组织
先交代舞台。三位出场工程师里，Matt Palmer 负责开场主持，Lauren Tan 是亲手做出 GrokBot 的人之一，Roshan Sadanani 在 SpaceXAI 做产品、同时写 GrokBot 的性能优化代码。规则讲得很清楚：把项目当独立公司运作，起点是一个完全空白的 GitHub 组织。
组织名叫 Ship by Thursday，公开可查，里面一个仓库都没有——团队强调事先没做任何准备，所有东西直播里从无到有。协作工具当场定：Slack 频道人和 Bot 共用、Notion 做知识空间、Linear 管工单。流程上他们开了个玩笑式的狠招：不开 pull request，直接合并 main 分支，再在直播画面上挂一个 commit meter 计数器。Matt 顺口算了笔账：他过去一个月往生产环境合并了约两千五百个 PR，摊下来每天八十三个，乘以三天就是两百五十个——这个数字成了团队给自己定的量。
开场 Matt 还展示了他自己的日常用法，这个流程值得单独记：他平时在 X 上收藏看起来有意思的技术和 npm 包，然后让 GrokBot 扫描这些书签、自动启动 Cursor 云端智能体把仓库跑起来、接上 Cloudflare 做预览部署。于是每天早上他收到的消息是“你昨天收藏的这项技术已经有部署好的版本，链接在这”。商业目标也说得直白：要赚钱，钱进银行账户才算生意；做“build something people want”的东西，最好自己也会用；并且全程用 GrokBot 开发 GrokBot，把自己产品的重度用户当护城河。
02 产品哲学：按职责建 Bot，不是按任务开会话
上午的 GrokBot 101 课程由两位工程师 Roman 和 Amrita 主讲（注意：他们不属于搭公司的三人组）。Roman 开场给出的问题意识是：AI 队友和人类队友在同一间公司里协作时，人们不再只是分派孤立任务，而是像对待真人同事那样，把一整块业务交给它、信任它独立做完、要它对结果负责。GrokBot 的三个产品决策都从这一点推出来。
第一，用起来像和同事发消息。界面是轻聊天化的，左侧一列 Bot，比如“销售外联”“收件箱管理”，每个 Bot 对应一条明确的工作线。核心思路不是为每件待办开一个对话，而是为“AI 能整块接过去的工作”建一个 Bot。Roman 的原话是：和只能帮你做到 90%、最后 10% 还得你收拾残局相比，一件事被端到端跑完、几乎不用插手的体验几乎是魔法。
第二，一切在云端。现在很多 AI 工作流跑在自己笔记本上，这在直播里被直接称为“尴尬的阶段”：你设了凌晨两点自动执行的任务，睡着了、合上电脑，任务就不会触发；第二天想从手机手动启动，它还绑在那台笔记本上。GrokBot 跳过这个阶段：Bot 常驻云端，手机、电脑随时可调用，你关机它也在线。
第三，每台 Bot 有自己可操控的计算机。底层是轻量 Linux 虚拟机，启动快、网络稳。演示者的实际用法是：飞机上 Wi-Fi 差的时候，把长时任务整个丢给 GrokBot 的虚拟机去跑；对还没有 MCP 接口的工具（Google Forms、Qualtrics 这类），让它用自己的电脑像人一样去操作。编者的看法：这三个决策里最可迁移的是第一个——按职责组织你的智能体，而不是按任务，这个原则不绑定任何具体产品。
03 现场演示：从一句话到一张能扫的二维码
Amrita 的演示环节是全场信息密度最高的部分，链条完整，值得逐段看。第一步，创建一个叫 Data Dan 的 Bot。GrokBot 会根据名字自动推测用途——你建一个叫 Workflow Builder 的 Bot，它会主动列出“你主要想让我做什么”的选项。
第二步，用语音模式让 Data Dan 生成一份 Google 表单。原话是两道题：您每天喝几杯咖啡；您最喜欢的旧金山咖啡店是哪几家，选项给 Ritual、Philz、Sightglass、Blue Bottle。选 Google Form 的理由也讲得很实：没人喜欢手工搭表单，但它又是从员工、客户、用户研究里批量收数据最常见的工具，Qualtrics 等表单工具思路完全一样。
第三步，表单完成后自动转成二维码，免去反复分发链接。到这里，“一句话进、一张能扫的码出”的闭环走完了——这条链正是后面整场工作坊反复复用的模式：人定结果，Bot 负责拆步骤和执行。这条链也真的卡过一次：二维码一度扫不出来，反馈“大家扫描不了这个内容”、提示“需要确认链接是否已设置为公开”后，它自动检查共享设置、获取副本响应链接，确保所有人都能正常访问。
同屏的还有另外两台 Bot：Email Ethan 管邮件，Slide Sonia 管幻灯片——她的电脑上已经加载好待编辑的幻灯片，你可以亲手编辑，也可以训练她。适用场景直播里给了两个具体的：万人线下活动统计饮食禁忌，用户研究员从客户那里批量收反馈。
04 Teach a Task：把你的操作录成可复用的技能
教 Bot 干活有两条路：嘴上描述，或者直接演示。Teach a Task 走第二条——你接管 Bot 的电脑操作一遍，它把过程录下来。演示里 Amrita 亲自操作 Slide Sonia 的电脑，走“插入 → 添加动画 → 飞入”，再输入标题，这一串动作就被记住了。
之后随时可以调用，说法就是“记得之前给你演示过的那个动画吗，我要在这一节里加上”。系统会把选中的对象、类型和可选参数保存成一项技能，演示结束后技能列表里已经多了“添加动画”这一条。
比单次录制更实用的是例行任务。直播里现场给 Sonia 加了一条：每天上午九点汇总这份幻灯片的最新修改、告知谁做了变更；还可以跨 Bot 协作——让 Sonia 和 Ethan 配合，每周把这周所有改动整理成邮件发给上级。幻灯片共享给多位同事后，谁删了一页、谁加了内容，都由 Bot 持续追踪。这就是“按职责建 Bot”的第二层收益：Bot 不是用完即弃的对话，是能长期积累上下文的同事。Ethan 可以学一整年的邮件往来，Sonia 可以随时教她适配新品牌。
05 权限与记忆：让它敢干活，又不越界
演示里 Data Dan 频繁弹出审批请求，Amrita 特意解释这不是故障：企业可以预设规则，让 Bot 在发邮件、对外发 Slack 消息这类操作前必须经人工审批。运行时它先请求授权，你放行一次，任务继续。
粒度可以做到很细。设置页里逐类操作配置：发邮件必须经我明确许可；创建幻灯片自动执行不用问；哪怕只是“在桌面新建一个文件夹”这种无害操作，你也可以强制它每次询问。直播里那次表单任务，Bot 还主动确认收集的字段不涉及 PHI/PII——内置的自动审查在替你把关，而且按演示的说法，表现得“过于谨慎”。
谨慎的另一面是打扰，解法是记忆。当它问“可以用这段文案给某人发邮件吗”，你批准之余再说一句“以后类似情况直接发，不必再问我”，它就把这条偏好存进长期记忆，下次不再问。企业接入问题也有人问起：能不能访问内部系统？答案是取决于鉴权——在 Bot 的虚拟机上配好凭据就能访问 MongoDB 这类实例，可以接入公司 VPN，最近还发布了 1Password 集成，让 Bot 按需安全取用凭据。编者判断：授权规则加记忆，这套组合才是这类产品能不能进企业的关键，比“多聪明”重要。
06 多 Bot 编排：群聊可见性、依赖管理、互相调度
Bot 之间的协作直播里给了实打实的通信记录：Email Ethan 会注明“Amrita 让我做这件事”；Data Dan 回复“这部分数据还没准备好，我还在电子表格里处理”；Ethan 于是改用自己的咖啡杯样本数据集先跑。Ethan 还可以直接调用 Slide Sonia 获取上下文，这叫 bot steering。
除了 Bot 间私聊，还可以建包含多个 Bot 的群聊。区别在可见性：群聊里你能一眼看到三台 Bot 之间的交互协议，不用逐个点开私聊拼凑。直播现场向群聊发了一条问候，观察三台 Bot 如何回应。
群聊里更值钱的是依赖管理。每台 Bot 守住自己的职责范围（swim lane），同时理解其他 Bot 的能力边界：Ethan 可以持有一条备注，等 Sonia 的幻灯片完成再发，避免冲突。这套机制对工程场景的意义被特别点出——识别到下游依赖的智能体会自动绕开相关文件，等依赖解除再推进，能明显减少代码合并冲突。出问题时也不用你去逐台排查：直接在群里问“Data Dan 卡在这一环节，我们怎么推进”，编排层会同步给相关 Bot。用一句直播里的话收束这节：使用者实际上是在搭建属于自己的公司，按项目还是按专长划分智能体，取决于你的业务。
07 模板与 Marketplace：把一个 Bot 变成全公司的标准
自建的 Bot 可以点顶部的 Share as template 分享出去，公司里任何人都能看到并使用。直播给的例子是设计团队：发布一个品牌设计 Bot，让颜色、字体、排版在全员输出里保持统一，后续迭代所有人自动同步最新版。Marketplace 上已有 Lauren Tan、Lenny Rachitsky、Claire Vo、Eric Zakarasson 等创作者公开发布的机器人，可以直接引入自己的 GrokBot 体系。
两个容易被忽略的细节记在这里。一是复制：duplicate 一台 Bot，新 Bot 保留你设定的角色设定（还是那个管邮件的 Ethan），但上下文和记忆全部清零——相当于一个零记忆但已具备工作能力的新同事。二是删除：Bot 会记住你告诉它的一切，但如果它曾把任务委派给某台后来被删除的子 Bot，它不会自动知道对方已不存在，需要你主动更新它的记忆。演示者用的办法是明确告诉 chief of staff bot：“之前创建过两个机器人，别再把任务委派给它们。”记忆是资产，也是要人工维护的债。
08 下午场：真的开始招机器人了
101 课程结束后回到搭公司的主线程，嘉宾是 Peter Yang：做了十多年产品经理，现在运营一人公司，做实操向的 AI 访谈和教程，自称整天和自己的机器人对话、几乎不跟真人交流。他的加入让“要开始打造产品，先请真正打造过产品的人”这句话有了着落。
茶歇的三十分钟里团队也没闲着：Ship by Thursday 组织还空着、仓库待建；Slack 频道已建，参考的是 SpaceXAI 内部人和 Bot 混用的日常；Notion 工作区就绪，打算写手册和给机器人准备的入职指南。文档策略上三人有分歧：一位不习惯记笔记，认为文档很快过时，主张精简敏捷只记必要项；Peter 倾向当下即记。最终取向是先精简、快速迭代。
然后是本文标题里那个动作：招人。Roshan 切到 GrokBot，界面全空，唯一完成的是在市场里连好了 X 的 MCP。第一个招聘对象定了市场调研 Bot——理由很直接：这类活以前是产品经理做的用户研究，现在交给机器人干。后续计划是再招两台“创始工程师 Bot”和一台“实习生 Bot”。现场还有条被反复强调的最佳实践：给机器人起个有趣的名字。有人直接命名为 market research bot，立刻被嫌弃太平淡，起名问题最后被抛给了观众。
09 边界，和今天就能做的第一步
几条编者判断，供采信时校准。
“三天搭一家公司”是直播叙事，可复用的是机制不是速度。这场直播自带产品宣传属性（Galaxy 挑战赛、免费下载的号召都在里面），动机这层要计入。演示里值得信的部分是真机操作和完整链条，而非任何时效性承诺。
反直觉的一条产品观察：演示中频繁请求授权不是缺陷。收尾总结里说得很直白——Bot 执行任务前必须获得人工审批，是它具备进入企业环境的条件：既不擅自采取危险动作，也不做超出许可范围的事。你在自己部署时嫌它烦，调权限规则和记忆，而不是绕过审批。
调试它也有明确方法，值得原文照抄：不要只说“不工作”，先说清期望产出（“我要一个能用的二维码”）；反馈时同时给问题描述、修法，以及它做对时的肯定——直播的经验法则是，细节越具体、正向反馈越充分，表现越好。Bot 拒绝执行或反过来提问时，把它当成该教它点什么的信号，一句“以后称呼我只用名字，别用全名”就会存进长期记忆。
如果只带走一个启动动作，用收尾那句：先问自己“今天最让我烦恼、又不得不做的事是什么”。可能是建表单收数据，可能是发外联邮件——为这件事建第一台 Bot，从期望的结果倒着让它拆步骤。三天搭不搭得出一家公司另说，第一台替你干活的同事，今天就能招。
本文转述自 SpaceXAI 官方 GrokBot 工作坊直播，原视频由 Carnage（@0xCarnagee）发布于 X。奥思典