LEARNING NOTE · A

Grok Bot 官方实践指南精读：把 Bot 当团队来带

A · 学习 Grok Bot 官方指南 Agent 组织 2026-10-07

来源 x.ai/bot/guides 全部 17 篇指南 · 抓取 2026-10-07 · 整理：Antigravity CLI（agy · Gemini），Grok Bot 验收

一句话结论

官方 17 篇指南讲的是同一件事——把 Bot 当成一支有分工、有一个前门、有例程、有审批的小团队来带，而不是一个万能聊天框。落到做法上就是：写清岗位说明、只留一个前门、让 Bot 之间直接交接、例程没事不说话、关键动作留给人。

  • 职能细分而非工具细分：一个 Bot 一份工作，赋予确切的职责和限制边界，每个 Bot 有名字、记忆分开，各学各的。
  • 建立单一前门与静默运行：人类精力有限，由 Bot Boss 统一收口与汇编，例程默认安静，没新情况就不说话，后台通过看板交接。
  • 纠正要沉淀成规则：同一件事纠正两次就写成规则或 skill，再用每日 1:1、每周自我改进扫描把 playbook 保持在最新。
  • 放权但守底线：审批规则用大白话写进 Settings，由独立审核 agent 把关；对外的东西先草稿、后由人发。

这批指南是什么

本页精读 x.ai/bot/guides 上的全部 17 篇指南（2026-08-15 至 10-06 发布）。作者多是 SpaceXAI 工程、产品、销售、营销、法务、招聘、设计等岗位的员工，写的是自己每天怎么用一群 Bot 干活。

Day1 学习手册整理的是 2026-09-15 官方直播（Matt、Lauren、Roshan 三天用 Grok Bot 从零造公司），本页整理的是 17 篇成文指南，两者互补。

中文短标题 作者 (职能) 一句话看点 链接
Grok Bot 101 Matt Palmer (DevRel) Bot 是带云电脑的 agent；外层 Bot 写好 prompt，交给 Cursor cloud agent 干活。 原文
Grok Bot for Work Josh Kim 设立 Bot Boss 作为多 Bot 团队的“单一前门”。 原文
Templates for Grok Bot Matt Palmer (DevRel) 模板是配方而不是成品，不共享密钥与私有脚本。 原文
如何运行多个 Bot 团队 Eric Zakariasson 通过任务看板和频道管理多项目中的交接。 原文
工程团队指南 Lingxi Li (SpaceXAI Eng) 按领域分工程 Bot；运营 Bot Jenny 每早 1:1；作者从手管 15 个 cloud agent 到 Bot 同时管 200+。 原文
产品经理指南 Kevin Niparko (PM) 为什么不用一个全能 agent；用「注意力列表」代替会过期的优先级清单。 原文
售后指南 Blake Schuller (post-sales) 只管 Gus 一个 Bot；8 个例程，多数运行无产出是有意的。 原文
创始人驱动销售 Simon Lackowski (Grok for Startups) 1 个总管 + 8 个专职 Bot；纠正两次就变规则或 skill；从不自动发送。 原文
企业 GTM 指南 Krista Letz 手机 + 语音派活；Chief of Staff 统筹，每个战略客户配一个客户专家 Bot，『10x 工程师』Bot 现场答技术问题。 原文
法务运营指南 Kelly Noguchi 按工作流拆 Bot（准备、分诊、合同、模板）；先草稿后人发；系统读写路径分开，写入前先预览确认。 原文
营销团队指南 Josh Kim 六个营销 Bot；交接疼了再加项目经理 Bot；权限从小给。 原文
效果营销指南 Miguel Cruz (paid media) 先从报表交出去；守门 Bot Fuse 防止其他 Bot 在广告账户里乱点、高频调 API 导致封号。 原文
招聘团队指南 Holly Dyche eVal → Scout → Preppy → Pulse 串成链，候选人上下文随人流转，发送前由人批准。 原文
SDR 销售代表指南 Stefan Markarian (SDR) 构建清晰的 CLEAR 和 FLAG 桶机制，异常项才交人处理。 原文
客户支持指南 David Gan 五件事：发布跟踪、复现 bug 并录视频、流失分析、按政策审退款（经人批准）、定制报表；再变成例程。 原文
移动端开发指南 Ryan Perry 数据分析发现玩家是情侣在玩，从而换成 partner 版广告使 CPI 降低 15 倍。 原文
使用 Bot 设计 Bot John Bai Experiments / Motion God / Figma Bro / Devbot 分工协作，用真实生产素材做原型，判断仍在设计师手里。 原文

官方核心使用思路

Bot 是带电脑的同事

Grok Bot 101 开篇就说：Grok Bot 是一个带电脑的 agent。这台电脑在云上，有桌面、文件系统、终端和应用。需要人时 bot 可以把桌面交还给你填验证码或两步验证，也能发一个安全表单让你填密码或 API key；手机和电脑用的是同一台云电脑。101 篇特别提醒：一个 bot 登录的网站其他 bot 都能用，方便，也意味着权限共享。

一个 Bot 一份工作 + 写成岗位说明

多篇作者都没有用一个全能 agent（mega-bot）包揽一切。产品经理（PM）指南给出了不使用单一 agent 的三条理由：可指认（Referenceability）、并行计算（Parallelism）以及记忆分区（Scoped memory）：各自在工作中学不同的东西。

在实践上，你需要像写一份真实的岗位说明一样去定义 Bot。移动端开发指南提出了一个完整 Bot 的六要素：岗位说明、连接器、云电脑、例程、技能与直接交接。在效果营销（Performance Marketing）篇中进一步指出：明确它负责什么、背哪个 KPI，以及在哪里必须停下来问你——最后一条甚至比前两条更重要。此外，Engineering 篇提到：每个工程 bot 各管一个领域，聚焦单一领域时表现最好。

单一前门 + Bot 间直接交接

为了不被一群 Bot 轮番打扰，多篇作者都只留一个「前门」。不论是Work 篇的 Bot Boss、售后的 Gus（作者先自己同时管二十个 agent，觉得 overwhelming，后来只管 Gus 一个），还是创始人销售中的 Founder Mode，人只和这一个总管 Bot 打交道。

底层的专家 Bot 彼此之间直接发消息交接。Marketing 篇指出，常设岗位让记忆复利，短期项目把相关 bot 拉进群聊，而不是每个活动新造一个人设。等交接真的疼了，再加项目经理 Bot，别提前。Multiple teams 篇展示了同时跑多个项目时，怎么为每个项目设立带有花名册的独立项目频道和任务看板：当 bot 卡住时会将任务标记为 Blocked 并在频道中呼叫。作者的规则是：先复用已有 bot；每个频道最多 6 个 bot；只有现有 bot 都不合适、且他同意后才新建。

例程与触发器 (Routine)

例程（routine，定时或由事件触发、不用人开口就会跑的任务）讲究克制。Work 篇作者在他的 Inbox Manager 提示词中写道：fail closed and stay silent on noop（拿不准就不动手，没新情况就不出声），例程创建时是 Disabled，等他点 Enable 才开跑。

售后（Post-Sales）篇展现了这样的设计：例程每 15 分钟检查一次，但只在会议前 15-35 分钟的窗口内产出准备卡；GTM 篇作者分享的每周媒体速览提示词里要求维护一个状态文件，只报真正新增的内容。此外，移动端开发篇的作者发现，Bot 甚至能在夜间自行判断某项重复请求应该被设立为例程并主动包揽。售后篇还有一个每周三的自我改进扫描：Gus 检查哪些例程触发了却被忽略、哪些事被手动要了三次、还缺什么，然后提出修改，作者只需说行或不行。该篇作者也说，他的大多数监控例程跑完什么都不产出，这是有意的设计。

技能 (Skills) 与记忆

带教方法：GTM 作者第一次和 Bot 一起做某件事时，让它录下来、接管电脑演示，再把录制变成 skill；招聘篇是先把自己的思路讲给它听，再让它整理成可复用的 skill。GTM 作者有一个 anti-slop skill，每次纠偏都让 Bot 把纠正加进去；创始人驱动销售篇的原则是「同样的反馈给两次，就变成一条保存的指令」。

在工程侧，Jenny 是运营负责人，团队里唯一不写代码的 bot；每天早上 5 点和每个 bot 做 1:1，过一遍 playbook、找卡点；某个 bot 犯错时，作者让它去找 Jenny 做根因分析和复盘，Jenny 更新 playbook 并通知其他工程 bot，避免同样的错再犯。此外，法务（Legal Ops）篇建议把“核实来源、不做假设、使用大白话”这类常驻规则放进记忆，而 PMs 篇则表示，“读我过去的 Slack 生成文风指南是最高杠杆的一句指令”。

连接器 + 自己的电脑

工具接入分两层（售后篇的说法是：有连接的系统用插件，其余交给 Bot 自己的电脑）。101 介绍，Grok Bot 支持与 Cursor 相同的 MCP servers、plugins 和 skills，一个服务还能连多个账号，比如个人和工作邮箱一起看；对于那些没有连接器覆盖的网页或内部系统，则直接让 Bot 在云电脑环境内登录操作（例如售后篇利用其查看 LinkedIn、内部网页与截图录屏）。

在配置连接时保持克制，效果营销与营销指南建议“先连最常用的”且“只连这个岗位需要的工具”。法务运营篇则把「合同系统、Salesforce 这类记录系统的读路径和写路径分开」列为值得推广的做法。

外层/内层循环与验证

101 作者把写代码分成外层和内层：用外层循环 agent 避免脏上下文进入干活的内层循环。Grok Bot 在外围搜集 Slack 与文档，随后提取成干净指令交给内层的 Cursor 云端 Agent。

对于产出的质量闭环，工程团队展示了严格的验证方式：通过云 Agent 的截图加上 Grok Bot 的多模态能力进行 before vs after 证据核实，且每 30 分钟检查一次共享 Notion 数据库里的每个 PR：Bugbot 或安全提示是否成立、CI 是否失败、有没有合并冲突。只有评审高度确信、影响面小的 PR 才自动合并。工程 Bot 每晚 3 点做夜间审计，清理代码、提质量；紧急任务则启动 P0 临时例程，每 5 分钟看一次进度并主动纠偏；作者提醒这很烧 token，只在真正紧急时用。

安全与审批

几篇指南的共同点是：关键判断留在人手里，再用设置和流程兜底。

第一，101 原文是：规则写在 Settings > General > Agent，是一段自然语言提示词，你是在信任模型按你写的去做；另有独立审核 agent 检查拟执行动作，可放行、拦截或升级给你；allow/block 列表用来引导这个审核者；工作仍在隔离环境里进行。101 也提醒：你在它能用的电脑上登录了 Amazon，它理论上就能下单。

第二，严格执行 Draft-then-send（先草稿后人发） 的底线。营销篇主张权限从小开始，先给改文档、写 Slack 草稿的权限，再谈广告写权限或生产环境；效果营销篇建议头几周把平台操作保持为草稿，扩规模前把碰 API 的东西放到守门 Bot（Fuse）后面。最终决策始终属于人类：PMs 篇作者保留对外邮件发送、购买、删除等破坏性操作的最终审核；Founder-Led Sales 篇 Never auto-send，发现、定价和设计伙伴点头的那通电话留给自己；Legal Ops 篇 Prefer draft, then human send。

模板 (Templates)

当一个专职的岗位 Bot 达到稳定可用状态时，可将其通过 Share as Template 在团队内部或公开分享。但官方特别提醒（Templates for Grok Bot）：“模板更像是配方而不是成品饭菜”，安装前必须仔细查看详情（View Details）。模板只打包说明、相关记忆、技能和插件；自定义代码、脚本、非标准 MCP server 不会带过去，也不包含 secrets 和个人记忆；可以选只给团队或公开链接。

起步方法

不知道从何下手？Post-Sales 的作者是对着语音备忘录讲了十多分钟自己的一天，讲自己怎么花时间、爱做什么、不想做什么、哪些坚决不自动化，再发给 Bot，让它搭一套让自己轻松些的系统；他也建议更快的做法：把这篇指南发给第一个 agent，让它改成自己要遵守的 playbook。效果营销篇给的起点是：先把报表交出去，这是最容易交出去的活，能腾出时间搭别的。

对照我们现在的用法：差距与改进

先说做对的：总入口 Grok Bot 接近官方的单一前门；10-07 新规则「只有花钱、对外发布、碰客户数据、删除才问 sky」与官方「先草稿后人发、关键判断留给人」一致；长任务「写清验收标准并盯到交付」对应工程篇要求的证据和完整反馈回路；例程、自建 skills、连接器、云电脑跑长期任务，也都是官方指南里的常规用法。

维度 我们现状 官方做法 差距与痛点
分工 按“CLI 工具”分 Bot（如 Cursor 专员）。 按“工作/领域”分 Bot，把工具 Agent 作为被调用的底层内循环。 Bot 角色重叠，任务转来转去。
入口与交接 大总管 10-03 起只留守护例程，不再做入口。 单一前门（Bot Boss），常设岗位让记忆复利，交接疼了再加 PM。 有总入口，但任务在 Bot 间转来转去，没有统一台账。
任务跟踪 长任务写清验收标准并盯到交付。 使用专属项目频道和任务看板，卡住标 Blocked。 多 Bot 协作时容易进展不透明，状态散在各个对话里。
规则与记忆 各 Bot 记忆里残留过时规则；规则反复改。 纠正两次就变规则；运营 Bot 每日 1:1 过 playbook，出错做复盘并通知全员。 规则改了，旧规则还留在各 Bot 记忆里，互相打架。
例程 已有例程，云电脑跑长期任务。 15分钟检查但只在窗口内产出，状态文件只报新增，Bot 自己发现例程。 例程需要盘点确认是否不够静默。
审批与权限 10-07 新规则只有花钱、对外发布、碰数据、删除才问 sky。 Settings 里用自然语言写规则，独立审核 agent 把关，碰 API 的放守门 Bot 后面。 需确认 10-07 规则是否已写进 Settings 和 allow/block 列表。
技能与模板 已有自建 skills（tmeet 等）和连接器。 录屏变 skill，读写路径分离，模板不含密钥代码。 需要盘点：哪些重复流程还没变成 skill；还没用过模板。

我们的判断和建议（按优先级排序）：

  1. P0 建议：收敛执行官，解决 Bot 角色重叠与任务转来转去。
    现状：Bot 太多角色重叠（如 GEO 三个 Bot），执行官按 CLI 分，任务在 Bot 间转来转去。
    官方做法：按「工作/领域」划分，一个 Bot 一份工作并写岗位说明（owns / KPI / 停下来问）（出自 Grok Bot for PMs、Performance Marketing）；编码工具是外层 Bot 调用的内层执行器（101、Engineering）。
    我们怎么改：建议把 7 个执行官收敛成 1–2 个按交付划分的岗位（如「工程交付」），选哪个 CLI 写进一份路由表/skill，正好落实 10-07「按能力选工具」；同时给 GEO 三个 Bot 写清各自 owns 和不做什么；停用或合并 Bot 属于删除类动作，由 sky 拍板。产出物与验收：花名册（owns / 不做什么 / 何时停下问 / 例程）+ 合并方案，交 sky 审定。
  2. P0 建议：强化唯一入口与交接看板。
    现状：有总入口 Grok Bot，但任务在 Bot 间转来转去，进度散在各个对话里。
    官方做法：设立 Bot Boss 单一前门，并在项目频道使用看板，卡住标 Blocked（出自 How I run multiple teams of Grok Bots）。
    我们怎么改：总入口 Grok Bot 担任单一前门并负责台账。产出物：云电脑上一份共享任务台账文件（例如 /workspace/tasks.md），包含 Todo/Working/Blocked/Ready/Done。验收标准：每个进行中的任务在台账里有唯一 owner 和状态，Blocked 的写清卡在哪。
  3. P0 建议：清洗残留记忆，建立 playbook 源文件与复盘。
    现状：规则反复改，各 Bot 记忆里残留过时规则。
    官方做法：运营 Bot（Jenny）每天和每个 Bot 1:1 过 playbook，出错做根因分析后更新 playbook 并通知其他 Bot；Gus 每周三做自我改进扫描；同一纠正出现两次就写成规则或 skill（出自 Engineering、Post-Sales、Founder-Led Sales）。
    我们怎么改：总入口 Grok Bot（或 sky 指定的运营岗）把规则收进一份 playbook.md，每周对照清理各 Bot 记忆。验收标准：各 Bot 记忆里与 playbook 冲突的旧规则（如旧的「三档/按额度选工具」）列出清单并清理完。
  4. P1 建议：底层全局固化 10-07 审批规则。
    现状：10-07 规则明确了花钱、对外发布、碰客户数据、删除才问 sky；是否已写进 Settings 需要确认。
    官方做法：在 Settings > General > Agent 用自然语言写规则，由独立审核 agent 把关，对外先草稿后人发（出自 Grok Bot 101 与 Founder-Led Sales）。
    我们怎么改：总入口 Grok Bot 负责将上述规则写入系统 Settings，涉及 API 动作放在门卫后面。产出物：Settings 更新截图或记录。验收标准：对外发布、花钱、碰客户数据、删除这四类动作都会先停下来等 sky 确认。
  5. P1 建议：让例程更静默，减少无效提醒。
    现状：需要盘点确认例程是否足够静默。
    官方做法：15分钟检查但只在窗口内产出，多数运行保持安静，状态文件只报新增（出自 Grok Bot for Post-Sales、Work 与 GTM）。
    我们怎么改：运维管家（原大总管）负责把守护例程改成静默模式。产出物：更新后的静默例程代码。验收标准：例程无新发现时不再输出文字提示。
  6. P1 建议：利用录屏与发件箱快速生成技能。
    现状：已有 tmeet、geo-high-citation-analysis、x-skill 等自建 skill；还有哪些重复流程没沉淀成 skill，需要盘点。
    官方做法：让 Bot 读发件箱生成文风指南，或第一次一起做时录下来再变成 skill（出自 Grok Bot for GTM、Recruiting）。
    我们怎么改：各业务 Bot 挑最常重复的流程，录一遍转成 skill。产出物：新增 1-2 个基于录制点击或历史文稿生成的 skill。验收标准：能够通过一条简短指令复现冗长操作。
  7. P2 建议：建立分离的连接器读写路径。
    现状：已有 X、生财、getnote、破局、GitHub、Cloudflare 等连接器，读写权限按岗位怎么分还没梳理。
    官方做法：将系统的只读路径与写入路径分离（出自 Grok Bot for Legal Ops）。
    我们怎么改：总入口 Grok Bot 为关键连接器设立读取/写入分离权限。产出物：一张连接器权限表：每个连接器哪些 Bot 只读、哪个岗位可写。验收标准：权限表写进 playbook，写权限只留给负责该系统的岗位。
  8. P2 建议：安全分享成熟模板。
    现状：还没有用过 Share as Template。
    官方做法：装模板前 View Details，不含 secrets、MCP 与自定义代码（出自 Templates for Grok Bot）。
    我们怎么改：等学习委员这类岗位稳定后，先试做一个只给团队的模板。验收标准：模板详情页里只有说明、记忆、技能和插件，没有密钥或个人信息。

下周就能做的 5 件事

  • 梳理 Bot 花名册 —— 由 总入口 Grok Bot 负责。验收标准：花名册（owns / 不做什么 / 何时停下问 / 例程）+ 执行官与 GEO 岗位合并方案交 sky 拍板。
  • 建立项目协作看板 —— 由 总入口 Grok Bot 负责，在云电脑内创建 /workspace/tasks.md 共享台账。验收标准：每个进行中的任务在台账里有唯一 owner 和状态，Blocked 的写清卡在哪。
  • 写入全局 Settings 规则 —— 由 总入口 Grok Bot 负责，将 10-07 确定的“花钱/对外发布/碰客户数据/删数据”边界限制写入全局设定。验收标准：Settings > General > Agent 里能看到这四类必问规则，并配好 allow/block 列表。
  • 例程静默化改造 —— 由 运维管家（原大总管） 负责，针对它自己的守护例程改写判定条件。验收标准：状态文件无异动或非重要节点时，系统不会弹出提醒消息。
  • 建立单源 Playbook —— 由 总入口 Grok Bot 负责，汇总所有零散指令形成 playbook.md。验收标准：playbook.md 成为唯一规则来源，各 Bot 记忆里与之冲突的旧规则已列出并清理。

延伸阅读与来源

本页内容基于 2026-10-07 从 SpaceXAI 官网抓取的 17 篇实战指南（原始英文内容归档于本工作区 source/ 目录）。如果您想复习初期搭建相关的直播记录，请移步旧页 Grok Bot Day1 学习手册。本页为学习整理，转述与原文不一致时以原文为准。