在 X 上刷 GrokBot 的人，多半停在同一个用法：开一个对话窗口，问一句答一句。这场 workshop 的讲者 Alex 不是这么用的——他是一位 YouTube 创作者，同时在开发一款 App、运营一个在线社群，他把 GrokBot 的左侧栏布置成了一支挂着头衔的团队：内容、软件、社区各占一条线，每条线有自己的负责人。视频把它包装成「99% 的人只会拿它当聊天窗口，顶尖的 1% 在养一支自动成交的团队」，这句营销话可以不信，但下面这套机制值得逐条看：它不是提示词技巧，是组织设计。
先交代体例：本文转述自 SpaceXAI 一场十五分钟 workshop 的录像（含答问环节），视频原帖由 X 账号 Carnage 发布；配图全部来自视频画面，不是编者的实践复盘——画面里那套系统，以及 Cindy 上线首日谈下约一万美元赞助，都是讲者 Alex 的成果。全文带走三样东西：7 条编排原则、3 件插件、2 个维护动作。
01 原则一：给 Bot 起人名，把职能钉在头衔上
Alex 的第一条规矩听起来有点玄：不要把机器人叫「邮件专员」「内容专员」，要给它起一个具体的名字，再在名字旁边标上职位头衔。理由很实际——GrokBot 里的机器人会看彼此的头衔，头衔就是它们互相识别的依据。
画面里看得很清楚。他为正在开发的 App（Henry Intelligent Machines）配的团队，成员一栏写着 Kelly、Hank、Reed，名字后面各缀着头衔，Reed 那一格干脆就是 HIM Researcher。跨项目的 CTO 叫 Build——他自嘲这个名字起得毫无创意，但头衔一挂，谁该找谁就清楚了。
这一条的全部要点是：名字是给你自己用的，头衔是给其他机器人读的。通用标签抹掉了职能边界，Bot 之间就只剩「另一个聊天对象」；具体头衔一挂，组织结构自己浮出来。Alex 说他在整套系统上花的全部精力，其实只投在一件事上：确保每个机器人有正确的上下文、正确的头衔、正确的归属团队和正确的下属角色。
02 原则二：不画协作图，让头衔自己路由
这套系统最反直觉的地方是：协作链一条都没有预设。Kelly 负责统筹那款 App 的全部事务，遇到权限问题会主动去找开发者 Hank；Hank 自己拿不准，就请示 Kelly——「我打算这样做，可以吗」；Kelly 需要更高层级的授权，就直接找 CTO Build。Alex 反复强调，他从未告诉机器人之间要如何通信、如何协作，这些行为是自己长出来的。
画面右侧是 Kelly 的对话窗，聊的全是真工单：一条改动（HIM-395，合进 PR 253）谁在复核、部署完成后谁去验证、当前在等 PASS 还是 FAIL；窗口顶上挂着「与 Hank 的 2 条消息」「来自 Build 的消息」。机器人之间的协作不是演示脚本，是在跑生产核查。
更高一级的风险同样自动路由：谁要执行高风险操作，会主动去找负责权限的 CTO 确认。Alex 管这叫 GrokBot 的「魔力」——后台似乎有什么让它能精准识别彼此的身份、职责与上下文，在恰当的时机找对的人。编者更愿意把它拆开看：头衔提供了路由表，目标提供了方向感（见原则五），剩下的「聪明」是模型本来就会的部分。
自治程度的检验更直接：他大概已经一个星期没给 Kelly 发过任何消息，她照常每天运转、主动和 Hank 沟通、把卡住的事逐级往上推。
03 原则三：每条业务线一个 Leader，不设总调度
内容、社区、App、技术、产品研究，五条线各设一名负责人；他明确不用「幕僚长（Chief of Staff）」这个总调度角色，理由放在第九节讲——那是个 token 黑洞。他要的形态是模块化小团队：Leader 向上只对站会频道负责，向下管自己那条线。
有个诚实的细节值得记下来：画面侧栏里其实还挂着一个 Slate，头衔正是 Chief of Staff——旧角色没删干净，或是早期方案的痕迹。主张和现状有出入，不影响主张本身：他现在的说法是每线一个 Leader，站会频道里发言的也是各线负责人。
侧栏的分组是「按业务线拆分」的画面实证：Exec Team 之外，Community Team（Dusty，社群负责人）、Content Team（Cindy，收入运营；Barry，内容负责人）、Tech team、Product Research Team 各自成列——和一张真公司的组织架构表没有区别。
04 原则四：每天早上，主管们进同一个频道开站会
所有负责人拉进同一个频道，每天早上八点四十五分开站会。固定议程四步：本周短期目标、当前进度、阻塞项、今天为推进目标要做的下一步。每人还要报当天最重要的四项优先级，然后基于彼此的优先级互相给反馈——反馈不是走过场：内容线的 Frederick 看到社区里有值得做的选题，会直接拉社群的 Dusty 一起干。
画面里这场站会正在跑：Slate、Frederick、Flo、Wes 轮流发言，内容细到工单级——「prod check（abundant-roadrunner-85）：252 个 waitlist-retry 函数」「Smoke 通过后标记、HIM-395 的对账……全部已在产线」。Flo 的汇报里甚至聊到工位：Dusty 和 Frederick 中间那张桌子。站会不是摘要腔，是干活的口吻。
05 原则五：把目标写进主管的记忆，否则全是废话
这是全场最硬的一条警告。他的原话叫 AI slop：让机器人无限循环地互聊而没有目标，产出的只会是一堆无意义的废话。解法是给每个团队配一组长期加短期目标，把这些目标写进主管的记忆，作为行事准则；再放进每日站会，它们就会真的朝目标推进，而不是空转。
答问环节他给了两个目标的样子。社群负责人的：一个月内把流失率从 X 降到 Y——每天站会出应对方案，用自己独立的账号进社群看数据，分析完决定给过去一周不活跃的用户逐个发私信，然后逐一执行。App 团队的：三周内上线 Beta——自动拆解发布前的任务清单，判断其中哪些是今天可以推进的，一步步逼近上线日。
目标是写进记忆的常驻项，不是提示词里的过场话。这一条决定了 Bot 是在推进事项，还是在表演忙碌。
06 原则六：从三四个领域起步，让角色自己长出来
最佳路径不是回家一口气建四十个机器人——那只会把自己搞得过载。先想清楚生活里最希望 AI 接管的三到四个领域，每个领域建一个「首席」，其余角色等它们自己涌现。
涌现的真实过程是这样的：内容负责人 Barry 的需求是第一时间获知 AI 动态、抢在所有人前面出 YouTube 视频吃流量，他的例行任务是每五分钟扫一次 X。做着做着邮件成了瓶颈——订阅过 5 人的 YouTube 频道，每天约一千封垃圾推广邮件；Alex 自己的收件箱一天要涌入一万封。既然 Barry 已经在盯内容线，他索性在 Barry 手下加了 Cindy，头衔挂收入运营（Revenue Ops），专盯收件箱里真正的赞助合作。上线第一天，Cindy 独立谈下了约一万美元的赞助。
新角色就是这样从实际工作里长出来的：出现一个，创建一个，而不是一回家就把所有事一次性预设完。
07 原则七：把 Bot 当同事养，而不是当功能堆
X 上很容易刷到号称握着 14000 个机器人的账号，看完头脑发热回去照搬——他明确说不可取。原因不是成本，是你会失去「哪个机器人擅长哪类任务」的直觉：收到一封真假难辨的赞助邮件，他的第一反应是丢给 Cindy 审，因为她看过上万封同类邮件，有判断力。如果一开始就铺几万个 Bot，这种直觉无从建立，熟悉和信任也一样。
放大看他的侧栏，这支队伍的规模感就出来了：Exec Team 之外每条业务线两三个人，每个人都叫得出名字、说得出擅长什么。规模是涌现的结果，不是入场券。
08 三件装备：X、Agent Mail、Tailscale
插件只推三件。第一件是 X 本身：按他的说法，这是 GrokBot 独有、别的聊天机器人给不了的原生集成，配置最省事、收益最直接。
第二件 Agent Mail，免费。它解决的是「把 Bot 接进你的账号」这件麻烦事：在它出现之前，要么给机器人单独开一个 Gmail（麻烦），要么让它们访问你自己的 Gmail（风险太大）。现在一句话就能办：「开一个账号，自己管理，把自己加进我的团队」。他当场声明这句不是广告——没收任何人的赞助费。用法举例：跟 Dusty 说去社群开个账号，她就以版主身份进驻了。
画面右侧是 Dusty 的日常作业记录，值得细看：每日 AI 资讯帖「Sep 1 已上线」带着社群链接，往下是一条故障自述——发帖接口出错，正在重试；前一天 Aug 31 的帖子也是「修好再重试」。机器人不只是挂着头衔，它在真的值班、真的排障。
第三件 Tailscale，给电脑不止一台的人：家里几台机器（日常机、AI 实验室、技术团队的机器）各配一个 Bot，用 Tailscale 连成一张私网。价值在调度——进任意一个 Bot，下指令让桌面机加载这个模型、让 DGX Spark 加载那个，跨设备的模型调度就变成一句话。
09 两个维护动作：系统审计，和管住 token
第一个动作是给整套系统做体检。做法：让系统生成一份 Markdown，写清有哪些 Bot、各自的角色职责、彼此怎么协作，然后把这份文档丢给最重的旗舰模型（他自己用 Grok 4，还补了一句期待 Grok 5 早日上线），直接问：基于这份文档，还能怎么优化？该加哪些 Bot、改哪些流程、新增哪些例行任务？定期做一轮，团队保持精简高效。手册里这条原本写着「让 Chief of Staff 来生成文档」——但答问环节他会亲口拆掉这个角色，所以文档由谁生成并不重要，重要的是把系统摊平成一份可读文档，再借最重模型的眼睛看一遍。配套工具是 Linear：所有 Bot 在同一个看板上协作、任务集中一处，他称之为第二大脑。
第二个动作是管住用量。Grok 的额度每周重置，最容易烧穿的正是 Chief of Staff 这类总调度层：每次委派都要把任务在它那里过一遍上下文，token 像流水一样出去。他现在的主张是直接去找手握相关上下文的对口 Bot，不走编排路由。要一段 YouTube 视频脚本，就直接对 YouTube Bot 说。顺带两个稳定性结论：长对话从没出过行为异常、也不需要重置，前提是拆分合理、上下文精简、不让单个 Bot 包揽一切；至于把沟通型 Agent 串联重型编码 Agent 省 token 的玩法（用 Grok 的虚拟机登录别的编程工具、强制指定模型），他见过但不推荐——链路复杂、脆弱、反直觉，Cursor 额度紧张时宁可直接开另一个 Agent。
10 今天就能迈的第一步
把这场十五分钟压缩成一个动作：今晚只建三个 Bot。挑三个你最想让 AI 接管的领域，各建一个「首席」，起人名、挂头衔、把本周目标写进它的记忆，再建一个频道把它们拉进去。明早八点四十五分看一眼它们互相说了什么——有没有报优先级、有没有报阻塞，是干活的样子还是废话的样子，一眼可辨。三天后做自治检验：你一句话都不发，看目标有没有仍在推进。
边界也要交代清楚：这是一套单人创作者场景的编排（YouTube、在线社群、独立 App），所有数字——每天一万封邮件、首日一万美元——都是讲者自述，后者是极端样本而非预期收益；GrokBot 的界面、额度与插件生态都在快速变动，照抄之前先看一眼现状。真正可迁移的不是 GrokBot 本身，是那套组织判断：头衔即路由，目标即记忆，Leader 即边界。
原作者：Alex（YouTube 创作者）；本文观点出自其在 SpaceXAI workshop 的演示与答问（视频全长 15 分 42 秒），视频原帖由 X 账号 Carnage（@0xCarnagee）发布。