Grok Bot 怎么玩？我把官方 56 个玩法模板全扒了，主要就是这六种！

admin@yesmiracle.net (万戈) — Thu, 15 Oct 2026 21:40:00 +1000

如果你已经把 SuperGrok 或者 Cursor 的订阅费交了，却还只把 Grok Bot 当成一个更会聊天的框，那这笔钱基本是白花的。

这东西 8 月 11 日上线，官方对它的一句话定义是「AI teammates you can give real work to」——能直接派活的 AI 同事。中文圈大多还停留在「xAI 又出了一个 agent」的介绍层面，但真正决定你怎么用它的，是官方玩法页上摆着的 56 个现成模板。我把那 56 个从页头到页尾过了一遍，又翻了官方的 guides，想说的是：这 56 个模板看着像 56 个功能，其实只在反复回答同一个问题——你打算把哪一段工作交出去。

而把这个问题拆开，主要的路数其实只有六种。

先把两件事分清楚

第一件，别把 Grok Bot 和 Grok Build 搞混。Grok Build 是 7 月 15 日 xAI 开源到 GitHub 的那套终端 coding agent（1.32M 行 Rust、77 个 crate、Apache 2.0），它是 grok 这个 CLI 的底层运行时，跟你本地跑不跑、怎么改，都是你自己的事。Grok Bot 是另一条线——8 月才发布、不开源、跑在 xAI 云上的多 Agent 平台。一个是你能 fork 的代码，一个是你要按月订阅的服务。名字像，血缘完全不同。

第二件，别按「一个 agent 帮你干一件事」的旧剧本去理解它。Grok Bot 的公理只有一条：每个 Bot 有一台自己的云电脑——有桌面、有文件系统、有终端、有浏览器。你可以像用远程桌面一样点进它的窗口，它也能像你一样登录你已经登录过的那些 App 和网站。你要记住这句话，因为它后面每一种玩法都是从这一条长出来的。

玩法一：把它当同事发消息，而不是当工具下 prompt

其他 AI 工具通常会先让你「搭工作流」「配置 routine」。Grok Bot 的官方说法是：直接给 Bot 发消息，让它去做。

这条听起来像营销话术，但落到操作上是实打实的差别。它没有要先建 pipeline，也没有要先画节点图。你在桌面端或者 iOS 上像给同事发微信一样发一句话，它就去干了；同一条对话在手机上起的头，回到桌面能接着看。官方对它的定位是「an agent with a computer」——一个字面意义上拥有电脑的 agent，而不是一个会调用工具的聊天接口。

官方的 101 指南里，作者——一个 DevRel——把自己的 bot 直接定义成三个字段：

Name: Tech Demos Title: Daily X tech scout Description: Look at my bookmarks each weekday, pick one technology worth demoing, draft a prompt in my style, wait for approve or deny, then kick a Cursor cloud agent.

就这么三行。剩下的用自然语言随便写，甚至可以录一段语音让 bot 自己整理成指令。这跟写 JSON、写 YAML、写一堆 if/then 的老路数完全是两个物种。

玩法二：从 56 个现成模板里挑一个开跑

官方玩法页最实在的东西，是那 56 个「Add to Grok Bot」按钮。每个模板都是一支已经定义好的 bot：一句话职责 + 一段描述，点一下就装进你的账号。

我把它们的分类数了一遍，长这样：

分类	模板数	典型例子
Marketing	13	竞品情报分析师、付费媒体调剂、社区运营
Sales	10	外呼、账户研究、Deal Desk、CRM 运维
General	6	Chief of Staff、每日简报写手
Operations & Finance	5	费用管理、合同台、发票处理
Product	5	Beta 采用观察、文档审计、通话 FAQ 挖掘
Engineering	5	Bug 复现、产品性能巡检、云 Agent 编排
Customer Success & Support	4	账户健康、客户经理
Recruiting & People	4	人才搜寻、日历协调
Life & Leverage	4	公寓筛选、订阅/开销审计
合计	56

看这张表能读出一件有意思的事：营销和销售加起来 23 个，占了四成。 这不是巧合。官方自己说这套东西是先在 SpaceXAI 内部当原型跑起来的，最早铺开的正是销售外呼、市场活动、运维这些「连续、重复、流程清楚」的岗位。技术含量高的工程类反而只有 5 个，而且大多做的是取证的活——复现 bug、抓性能热点、盯云 agent——不是替你写代码。这个分布本身就说明了它擅长什么、不擅长什么。

玩法三：录一遍，存成 routine

这是我认为最被低估的一条，也是它跟「prompt 工程」最不一样的地方。

官方原话是：让 bot 跟着你做完一次工作流。你在它面前操作一遍，它看着，把你的步骤记下来，存成一个 routine，下次自己跑。它还会接你的纠正，慢慢把「你喜欢怎么做」吃进去。

这话的分量在哪？在于它把「教一个 agent」的成本从写脚本降到了演示一次。过去你要让一个自动化工具帮你处理发票，你得先把发票格式、字段、规则全写成代码；现在你把处理发票的流程在它面前走一遍就行。官方引用的一位销售用户说得很直白：

我给它演示过一次工作流，现在我就完全放心让它一直跑。我觉得自己效率高了 2 到 3 倍，因为它做完我不需要再逐项核对了。

我把这条称为「示范式编程」。它的上限是你演示得多细，下限是你敢不敢信——这两个都是人的问题，不是模型的问题。

玩法四：给它排班，给它埋触发器

一个 routine 是「怎么做」，routines + triggers 解决的是「什么时候做」。

官方支持两种触发：按时间表（比如每个工作日早上跑一次），和听事件（比如盯一条 Slack 线程、盯一个 GitHub PR）。101 指南里那个 DevRel 的用法就很典型——工作日扫一遍自己的 X 收藏，挑一个值得做 demo 的技术，按他的口吻起草一段 prompt，等他点批准，再去踹一个 Cursor 云 agent 起来。

这里的关键词是「等他点批准」。它默认不把事情做完，而是做到「就差你点头」那一步。 你去看官方那套 bot 的通用句式，几乎都是同一个骨架：先干完所有不涉及判断的活，把需要判断的那一下留给你。 销售外呼 bot 是把名单研究好、邮件草拟好，然后「leaves a review list for you to approve」；付费媒体 bot 是把预算调剂建议算好，然后「holds for your approval before making adjustments」。

理解了这一条，你就能理解为什么它把「触发器」和「审批」绑在一起卖——触发让它不用你在场，审批让它不用你在场也敢用。

玩法五：组一支小队，你只在判断点上出现

到这一步，玩法从「一个 bot」变成「一支队伍」。

官方描述是：一个 chief of staff 坐在最上面，下面是每个赛道一个 specialist——收件箱、报销、招聘、修 bug、运维。这些 bot 可以互相发消息、在线程里共享上下文。你把几个 bot 丢进一个群聊，它们会自己分配任务、交接负责人，只在真的需要判断的时候把你拽进来。

101 指南里那个例子就很鲜活：市场 bot 在盯 Facebook Marketplace 上的半自动咖啡机，遇到拿不准的，它自己去问那支 Chief of Staff bot。

这跟我前几天写的那一层「Agent 操作层」是同一个命题的两面。那篇讲的是人同时管七八个 coding agent 时注意力怎么崩；Grok Bot 给的答案是让 agent 自己互相管，把「你是中间人」这件事拆掉。官方引用的一位用户把它形容成「像长了八条胳膊的章鱼，每条胳膊都在干我会干的活」。

但我要泼一盆冷水：这一条也是最容易翻车的。 一支小队的产出上限，取决于每个成员职责边界划得清不清。划不清，你得到的是四个 bot 在群里互相点头，而不是活干完了。

玩法六：让它登进那些没有 API 的系统

如果只能留一条玩法，我会留这一条。

官方的说法是：Grok Bot 登录一次，就能像你一样去用那些「比较难搞」的工具——包括没有干净 API、没有 MCP 服务的平台。这一条是它跟绝大多数 agent 的根本分界线。别的 agent 能调 API，它能替你点进去。官方产品负责人那句被反复引用的话说到了点子上：在「做完 90%」和「做完 100%」之间有一道巨大的鸿沟，大多数 AI 只能把你带到差不多，Grok Bot 能把这一杆挥完，因为工作落在了人本来会放它的地方——真正的那个工具里。

这也是为什么它必须托管、必须有一台真的电脑、必须让你把账号登进去。能力越强，绑得越深。 顺手说一句，这条玩法也是风险最集中的地方——我之前写过一篇关于 personal agent 该拿「工牌」还是拿你「分身」的文章，那里的逻辑在这里同样成立：它登进去的每一个账号，都是你交出去的一份凭据。

规矩是「一段话」，不是「一段代码」

既然它能登进你的系统、能调 API、理论上能替你下单付款，那约束它的东西是什么？

官方的答案是自然语言规则。你在 Settings > General > Agent 里用大白话写规则；有一个单独的审查 agent 会去检查 bot 打算做的每个动作，可以放行、拦截，或者升级给你人工判断；再加一份 allow / block 名单来引导那个审查 agent。bot 的工作仍然发生在一个隔离的环境里。

101 指南里作者写了一句话，我觉得值得每个想上手的人贴在显示器上：

如果你在一台 agent 能用的电脑上登进了 Amazon，那它理论上能买任何它想买的东西，跟你亲自登录能做到的一样。

他还补了一句更要命的：你用 A bot 登进了某个网站，那么你账号下所有其它 bot 都能进这个网站。

我把这两句放在一起看，得出一个不带修饰的判断：Grok Bot 的权限模型，比它宣传的要粗。 审查 agent 批评的是「这个动作该不该做」，管不了「哪个 bot 有资格碰这个账号」。在单账号、个人用户场景里这不算问题；但只要你把公司级账号登进去，再组一支小队，这套粒度是撑不住的。这是它现阶段的真实边界，不是可以靠配置绕过去的东西。

它靠什么收钱，也决定了它不会做什么

接下来把商业侧也说清楚。Grok Bot 目前是 beta，含在几个已有订阅档里：Cursor Pro（$20/月起）、SuperGrok Plus（$30/月起）、Cursor Teams（$40/座/月）这些入门档，更高的 Cursor Ultra / SuperGrok Heavy 也在列。它有一个独立的用量池，不吃你原来的 Grok 和 Cursor 配额——这一点对重度用户挺关键，等于派活不心疼。平台是桌面（macOS，其它平台陆续）+ iOS，企业侧走 waitlist。

值得留意的是它的定价结构：它不是一个独立产品，是一个订阅的赠品。 这意味着 xAI 会用「反正你都订了」的方式把它铺到几百万付费用户面前，也意味着它不需要靠这个功能自己挣钱——所以它没有动力去做那些「企业要买、但会劝退个人用户」的重活，比如细粒度的 per-bot 权限、可审计的规则版本管理。这些恰好是团队真正需要的东西。赠品的商业模式，决定了它会在个人场景做到极致，在企业场景留一堆洞。

哪些玩法其实不该用

官方那一页全是正面案例，我补一张反面清单。

有位早期用户把他的经验总结成一条挺好用的规则：如果一个任务一周砸到你头上超过五次、又几乎不需要判断，它才值得交出去；而且一开始只放一个 bot 干一件事，别上来就组一支军队。（这属于个人用户调研、不是官方口径，样本也偏「爱折腾、愿意公开自己工作流」的那一类，所以当方向参考就行，绝对值要打折。）

按这个尺子，下面几类玩法我不建议现在就交出去：

需要微妙判断的活。 官方自己说得很清楚——bot 在「连续、低判断」的工作上才发光。做决定、谈价格、写给人看的终稿，这些判断点密的地方，它给你的是一份草稿，不是一个结果。
单次成本高、试错贵的活。 它能替你下单付款，也意味着它能下错单。低频但代价极大的动作，审批链必须卡死。
你需要它「可复现」的活。 规则是自然语言写的，不是代码。同一句话，今天和明天可能执行得不一样；换个模型版本，可能又是另一个样。要严格复现的场景，别指望它。
把公司核心账号登进去。 回到上面那条——一个 bot 登过，全队都能进。这一步在你没有摸清权限粒度之前，别做。

写在最后

把这六种玩法连起来看，你会发现 Grok Bot 真正的分水岭根本不是「功能多不多」，而是那一条：它替你登进你已经在用的系统，把最后一公里走完了。 别的 agent 卡在「我能调这个 API」；它卡在「我替你点了这个按钮」。这一条决定了它必须托管、必须绑账号、必须共享一台云电脑，也决定了它的风险全在这里。

所以我的判断是：这是一套把「流程拼接」这层人肉胶水最快抹平的工具，但代价是你把一串凭据交了出去。 想尝鲜，从玩法二挑一个模板、用玩法三录一条 routine 试水就行，十分钟能起来。但在我看到它把「哪个 bot 能碰哪个账号」这层做出来之前，我不会把它接到任何带钱的系统上。

顺带一提，如果你对这套「多 Agent 怎么互相管」的命题感兴趣，可以连着看这两篇：《94 位工程师只有 8 位还在逐行读 Agent 的代码》讲的是操作层这个品类的诞生，《Grok 4.5 横空出世》讲的是它背后那颗模型的来路。三篇合起来，大致就是这个平台从模型、到运行时、到人机分工的完整切面。

Agent 编排 on AI博士 万戈