Grok Bot 上手十步：从第一个 Bot 到一组会互相交接的 Bot

这篇教程解决一个问题：刚拿到 Grok Bot，怎么一步步把它从“一个能聊天的助手”用成“一组各管一摊、互相交接、只在需要你拍板时才来找你的 Bot”。

十个步骤的框架来自 X 用户 @0xMorlex 的一篇英文长文。本文按中文读者的习惯重新整理，并逐条对照了 Grok Bot 的官方文档；原文有几处说法和官方文档不一致，文中都按官方的写了，并注明了出入。文中的示意图和提示词来自原文，提示词译成了中文。

先弄清：最近变了什么

以前的智能体是“一整套”卖的：电脑、登录状态、记忆、定时任务这一层（原文叫 harness），和驱动它的模型，出自同一家公司。

Grok Bot 现在把这两层拆开了。按官方帮助中心的说法：Grok Bot 不局限于单一模型，每个任务都会选用最有可能带来最佳结果的后端模型，可能是 xAI 自己的模型，也可能是第三方的模型；页面里点名提到了 Claude Opus 5.5。

有三点要先知道，原文在这几处的说法和官方文档有出入：

原文的说法	官方文档的说法
Opus 5.5 是每个 Bot 的默认模型	没有“默认模型”。每次请求用哪个模型由系统决定，你看不到，也选不了，每次请求用的模型可能不同
用 Opus 5.5 会不会更快耗光额度，官方还没说	官方已经回答：不会。任务被交给 Opus 5.5 不会改变每个 token 的消耗，用量取决于你交给它的工作类型和工作量
每个 Bot 有自己的一台云电脑	你账户里的所有 Bot 共用同一台云电脑，文件、浏览器登录状态和命令行凭据都是共享的；每个 Bot 只是有自己的屏幕

第三点对后面的几步影响很大，下文会反复提到。

1装好，先建一个“总管”

Grok Bot 是一个应用，界面更像聊天软件而不是聊天机器人：左边是一个个有名字的 Bot，右边是对话。按官方的快速入门，桌面应用支持 macOS、Windows 和 Linux，iPhone 上有 App Store 版本；用 Cursor 账户登录，不需要单独的 Grok Bot 账号。

先只建一个通用的 Bot，原文管它叫 Chief（总管）。它的用处是：你还不确定一件事该交给哪个专门的 Bot 时，先发给它。

官方文档里创建 Bot 的步骤：

1. 在侧边栏选“新建”，再选“创建新 Bot”。
2. 点聊天顶部的 Bot 名称，进“Bot 设置”，填名称、标签和描述。
3. 发第一个真实的任务，并写明做到什么算完成。

第一个任务要选一个你 30 秒内就能核对结果的。 后面的每一步都是在把更大的活交给它，所以先从一件能验证的小事开始建立信任。

2给 Bot 写一份职责说明

一句提示词是一次请求；一个 Bot 是一个角色，它会一直存在、积累记忆、负责一块领域。所以用岗位来给它起名：收件箱管理、调研负责人、销售外联。

然后像带新同事一样交代三件事：它负责什么、做好是什么样、到哪里必须停下来问你。

原文的核心观点是：模型变强了，可以把整件事交给它，而不只是第一步；但更强的模型得到的是更多的步骤，不是更大的权限。“到哪里停下”那一段要和以前一样严格。

一份调研 Bot 的职责说明，译自原文：

你是我的调研负责人。

【你负责什么】
给你一个主题，把整件事从头做到尾：找到一手来源，打开你引用的每一个页面，
每个数字至少用两个来源交叉核对，写出一份 1500 字的简报。

【做好是什么样】
每个数字旁边都有链接。来源之间有冲突时标出来，不要取平均。
草稿放进我的云盘文件夹，不要贴在聊天里。

【到哪里停下】
绝不发布。绝不给任何人发邮件。只写草稿。
两个来源说法不一致、你又判断不了时，先放着，来问我。

官方文档对“写在哪里”有明确的区分：长期适用的规则写进 Bot 的描述，只和这一次任务有关的说明写在对话里。 例如“未经批准，绝不发送外部消息”属于描述，“为这十二个账户起草后续跟进”属于消息。安全边界要写在描述里，不要指望它靠记忆记住。

3工具只连一次，同时划出数据的界线

Grok Bot 有一个插件面板，可以一键连接 Notion、Slack、Google Drive、Gmail 等服务。官方文档说明，插件在整个账户范围内可用：连一次，你的每个 Bot 都能用。

方便的另一面是：每连一个工具，你所有的 Bot 都能碰到它。而且现在数据多了一个去处。官方帮助中心写明，处理请求的可能是第三方提供方的模型，哪些提供方可能处理你的数据，以官方的“次级处理方列表”为准。

你选不了模型在哪里运行，但能决定 Bot 碰什么。原文建议在每个 Bot 的职责说明里加上这样一段（译自原文）：

【数据界线】
不要打开、阅读或总结：
  - 我云盘里“法务”和“财务”文件夹中的任何内容
  - 我的律师、会计或银行发来的邮件
  - 任何含有密码、助记词或两步验证码的消息

如果任务需要用到这些，先停下来问我。
处理文档时，只使用任务需要的那部分。

只连你确实需要的工具，其余的不连。

再提醒一次那个容易忽略的事实：所有 Bot 共用一台云电脑。官方文档说得很直接，各个 Bot 的屏幕“是工作界面，并非安全边界”；不希望其他 Bot 用到的凭据，就不要放在这台电脑上。

4交接登录，绝不交出密码

公司里用的很多软件既没有 API，也没有现成的插件。Grok Bot 靠下面这个机制照样能用它们：

1. Bot 在自己的云端浏览器里操作，直到遇到登录页面。
2. 它把电脑的控制权交给你。
3. 你完成登录，再让 Bot 继续。它接着在同一个浏览器会话里往下做。

Bot 拿到的是登录后的会话，不是密码。官方文档确认了这一点：遇到密码、两步验证码、验证码图片、付款或身份验证时，Bot 会把控制权交给你；Bot 不会输入凭据，也看不到你的密码。接管之后只完成被卡住的那一步，然后交还给它。

要守住的规矩只有一条：任何时候都不要把密码或一次性验证码粘贴到普通聊天里。 聊天里的文字模型是读得到的，而在交接的屏幕上完成的登录它读不到。官方文档也是这么写的；确实需要给它一个密钥时，用它弹出的“安全机密信息请求”来填，那个输入框是遮蔽的，不会进入会话记录，也不会显示给模型。

还要知道：登录后的会话会保留下来供以后的任务使用，并且在你的各个 Bot 之间共享。

5演示一遍，然后做成定时任务

你可以亲手做一遍让 Bot 看着，它会把步骤存下来，下次自己做。

官方文档里这个功能叫“教会任务”：在打开电脑视图的一对一对话里选择它，说明想要的结果，然后把流程做一遍。有几点限制：

• 最多记录十分钟的可见操作，不录声音。
• 演示里不要出现机密信息。
• 学到的只是一份技能的草稿，要补上判断规则、出错怎么办和哪里需要批准，再用安全的输入测试。
• 这个功能在逐步推出。看不到的话，让 Bot 根据文字说明和做过的任务来创建技能。

最适合拿来演示的，是每周都要做、跨两个以上应用、步骤很少变的事：说起来啰嗦，演示一遍只要四十秒。

然后给它一个触发的理由。两种方式都用大白话设置，不需要画流程图（下面的例子译自原文）：

【按时间】晨报
每个工作日早上 7 点，查看我的日历、收件箱和 #launches 这个 Slack 频道。
给我一份简短的晨报：今天有什么安排，哪些需要回复，昨晚有什么变化。

【按事件】接住新来的询价
只要有邮件来自不在我联系人里的域名，并且提到了价格，
就按模板起草一封回复，先放着等我看。

【最省事的一句】
每周都这样做一次。
   （在一件你满意的任务做完之后说）

官方文档给的顺序是：先做成一次，确认稳定可靠，再存成技能，最后才自动化。 另外两条提醒：

• 测试运行会执行真实的操作，可能访问网站、改动文件、调用已连接的工具。测试时用安全的输入。
• 触发条件要写得窄。像“每条新消息”这样宽泛的监听会产生噪声、消耗用量，还会对不相干的输入采取行动。

6按领域建专门的 Bot

同时运行几个 Bot，每个负责一块领域。分开的 Bot 有各自的对话和记忆，出了问题也有一条干净的线索可查。

按领域分，不要按任务大小分。 一个只管报销的 Bot，会越来越懂你的报销。官方文档的建议一致：当工作有明确不同的目标、工具、工作方式、批准边界或定期安排时，才单独建一个 Bot。

原文还提到，Bot 可以派出运行 Cursor 模型的云端代理来干重活：Bot 负责规划和保存上下文，云端代理并行做具体的事，Bot 再审查交回来的结果。原文给的一份职责说明（译自原文）：

你是我的仓库维护人。

当 GitHub 上有 issue 被标为“bug”时：
1. 在你的电脑上复现它，并写一个会失败的测试。
2. 派一个 Cursor 云端代理，在新分支上修复它。
3. 对结果运行完整的测试。
4. 开一个草稿 PR，包含测试、修复和三行的说明。

绝不合并。绝不推送到 main。
如果修复涉及登录认证、计费或数据库迁移，先放着等我。

这一条来自原文，本站没有在官方文档里核对到“派出 Cursor 云端代理”的具体用法。

7把它们拉进一个群

Bot 之间可以互相发消息。把几个 Bot 放进一个群聊，它们会自己协调：传递工作、分配负责人，只在需要判断时才来找你。

官方文档里的要点：

• 一个群可以放 2 到 6 个 Bot。
• 正常发消息，由 Bot 自己决定谁来回复；用 @ 把请求交给某一个；@everyone 向全组通报。
• Bot 之间交接的消息只支持文字。需要某个 Bot 看图时，直接把图发给它。
• 每个阶段只设一个负责人。 并行交接会造成重复劳动和大量无关的更新。

原文的窍门是：给群一个目标，不要给一张任务清单。 给清单说明你已经替它们拆好了；给目标，让它们自己拆（译自原文）：

目标：周五下午 5 点前发出十月的通讯。

调研负责人负责事实和来源。
收件箱管理负责订阅者的回复。
总管负责进度，并告诉我哪里卡住了。

你们自己分工。任何要公开的内容先放着等我。

8划出必须由你批准的那条线

Grok Bot 的设计是让 Bot 把事情从头做到尾，只在需要你批准时才回来。这就要求你自己定义什么叫“需要批准”，因为它的默认理解未必和你一样。

管用的那条线和任务大小无关，看的是能不能撤销：Bot 自己能撤销的，让它独自做完；外部世界会看到的、涉及钱的、收不回来的，停下来等你。

原文给的写法（译自原文）：

【这些独自做完】
起草、归档、打标签、总结、调研、准备、对账
   所有可以撤销的事。不用问，直接做，并记下来。

【这些停下来等我】
向公司以外的任何人发送任何东西
花钱、转钱，或者承诺一个价格
发布任何公开的内容
删除任何不是明显垃圾的东西
接受任何条款，或者注册任何东西

【拿不准的时候】
如果一分钟之内撤销不了，就先放着来问我。

这和官方文档的说法是一致的：发送、购买、删除、发布以及更改生产环境，都应该经过批准；来源缺失或过时的时候，应该报告问题，而不是设法绕过。

模型越强，这条线越要写清楚，因为它会在碰到你的线之前把事情推进得更远。理想的状态是原文里那句话：起草了 36 封，发出 0 封。

9盯住用量

你在 Grok Bot 里不按 token 付费，用量包含在套餐里。

原文把“交给 Opus 5.5 的任务会不会更快耗光额度”列为官方还没回答的问题。这一点官方帮助中心已经回答了：不会。 把任务路由到 Opus 5.5 不会改变每个 token 的消耗；用量消耗的快慢取决于你交给它的工作类型和每项任务需要的工作量。

不过原文的建议仍然值得照做：加定时任务之前，先观察一周的用量。 定时任务会在你不看的时候持续消耗。查看的位置是 Grok Bot 里的“设置 > 用量与计费”。那里只显示“Grok Bot 用量”，不会按模型分开。

原文还提到，公告里的 Midjourney 和 Suno 当时没有上线时间。这一点本站没有核对；以你自己的 Bot 实际能做到的为准。

10每周花十五分钟复查

在日历上留出每周十五分钟，让 Bot 自己汇报（译自原文，最后一句按官方文档改过）：

列出你这一周运行过的每一个例程。对每一个说明：

  - 触发了多少次
  - 产出了什么
  - 有哪些被跳过、失败了，或者是靠猜的
  - 有哪些你放着等我、而我一直没回的

然后告诉我哪一个最没用，为什么。

原文的提示词最后还有一句“如果你分辨不出某一步是哪个模型处理的，就直说”。按官方文档，Bot 本来就不会显示处理请求的模型，所以这一句可以不要。

每个例程再亲手抽查一份产出。让 Bot 给自己的工作打分，它和你有同样的盲区。

在桌面端点聊天顶部的 Bot 名称，选“任务”，可以看到每个例程的说明和运行时间，并暂停、恢复、测试、编辑或删除它。长时间不用之后，Grok Bot 可能会问你是否继续运行例程，你不回应它就会暂停。

小结

原文的结论是：以前大家问的是哪个模型最好，现在的问题变成了哪一层“外壳”最好。电脑、登录状态、记忆和定时任务在这一层，模型可以在下面换。

对使用的人来说，要做的事没有变。三件事由你决定，并且都要写进 Bot 的描述里：

1. 把什么交给它；
2. 它的权限到哪里为止；
3. 它可以碰哪些数据。

想看用 Grok Bot 做一件具体的事，见 用 Grok Bot 做视频：让 AI 写代码渲染成片的八步流程。