如何在一个小时内深入使用 Grok Bot

8月底，Grok Bot 刚发布，@Poteto 送了一个 Grok Bot 试用资格，开始了我的 Grok Bot 之旅。经过一个多月时间的深度使用，把经验整理成一份不到万字的指南。

先让 Grok Bot 完成一次任务，如果结果不错，就把过程保存成可重复使用的技能。这就是 Grok Bot 的用法，也是理解这产品的起点。

查资料、打开后台、整理文件、核对数据，这些工作常常散落在不同应用里。每一步都不难，连起来却会占掉不少时间。

Grok Bot 把云电脑、应用连接、长期记忆和定时任务放在一起。你给它一个明确的职责，它就能在获得授权后，沿着这条工作流程继续做下去。

本文会从产品和运行方式讲起，再介绍配置、自动化、协作、实际用途、限制和故障处理。

目录

1. Grok Bot 是什么

2. 它在什么地方工作

3. 工作环境能保留，重要文件仍要另存

4. 使用资格、额度和支持的设备

5. 创建第一个 Bot

6. 把角色说明写成工作要求

7. 怎样连接应用和网站

8. 复杂任务先把计划讲清楚

9. 先跑一次，再检查交付结果

10. 把稳定的方法保存成技能

11. 用操作演示教它做事

12. 给技能安排执行时间

13. 把 Bot 分享成模板

14. 让整个团队使用一个 Bot

15. 选一个日常联系的主 Bot

16. 多个 Bot 怎样交接工作

17. 哪些工作已经适合交给它

18. 哪些任务值得做，哪些适合换工具

19. 审批和权限怎样设置

20. 记忆不能替代业务记录

21. 博客、课程和小应用可以怎样用

22. 常见问题怎么处理

23. 新 Bot 上线前，最后检查一次

1. Grok Bot 是什么

Grok Bot 是一个让 AI 长期承担具体工作的产品。它与 X 里用于问答的 Grok 入口有所区别，重点在于执行任务。

每个 Bot 可以有自己的名字、职责、对话和工作记忆。你给它资料，连接需要的工具，再说明最终想拿到什么。它可以跨应用处理任务，并在需要你决定时回来询问。

工作做顺后，还可以保存方法、安排重复执行，或者把配置分享出去。

判断它有没有用，最后还是要看它交出了什么。 比如一份可核对的报告、一封待发送的邮件，或一份能复现问题的测试记录。

2. 它在什么地方工作

Grok Bot 的主要工作环境是一台云电脑。里面有浏览器、文件系统和终端，能使用已连接的应用。

同一账号下，多个 Bot 共用这台电脑。它们各有自己的操作画面，可以并行处理工作，但底层文件、浏览器登录状态和命令行凭据是共享的。

图 1　同一账号下的多个 Bot，共享一套底层工作环境。

资料助手存好的文件，编辑助手可以接着读。这让交接变得方便，但你不能靠新建一个 Bot 来隔离敏感账号。

不同名字代表不同分工，不代表不同权限空间。

3. 工作环境能保留，重要文件仍要另存

合上自己的电脑，云端工作仍可继续。浏览器登录和文件也能跨会话保留。

不过，临时目录、手动安装的部分软件和未保存的应用状态，不能当作长期存储。官方建议把需要保留的项目文件放在 /workspace。

可以给每项工作设一个固定文件夹。每天的报告按日期保存，附件放在旁边，方便回看和交接。

最终成果还应回到你平时使用的系统。代码放进仓库，正式文件放进文档库，客户状态留在 CRM。这样以后更换工具，也不用重新找资料。

4. 使用资格、额度和支持的设备

截至 2026 年 10 月 11 日，官方列出的主要使用入口包括付费个人 Cursor 套餐、Cursor Teams，以及可关联的个人 SuperGrok、SuperGrok Plus、SuperGrok Heavy 和 X Premium+ 订阅。

企业账号和 Grok Business 席位有各自的接入规则。

套餐包含每周用量，部分账号可以使用额外付费额度。同时持有 Cursor 和可关联的 Grok 订阅时，用量通常取较高的一档，不会简单相加。

桌面端支持 macOS、Windows 和 Linux。安装时要选对芯片架构，Linux 还要选合适的安装包。

移动端支持 iOS 18 及以上、Android 9 及以上，iPad 也有对应支持。手机连接的是同一组 Bot 和云电脑，适合交代任务、查看结果和处理审批。

第一次使用时，先做一个范围清楚的小任务。看完结果和消耗，再决定执行频率。

5. 创建第一个 Bot

从 官方下载页 安装应用，登录有使用资格的账号。云电脑第一次准备时，可能需要等一会儿。

在侧边栏选择 New，在新对话中创建 Bot。随后打开 Bot 的资料设置，填写名字、标签和职责描述，再给它一项具体任务。

名字最好能看出工作内容。网站巡检、客服草稿、课程资料整理，都比万能助手更容易分清职责。

下面以网站巡检为例。它的目标是每天看看网站有没有需要处理的问题，并把证据交给你。

6. 把角色说明写成工作要求

写角色说明时，先想清它每天要交什么，再补充来源、范围和不能做的事。临时要查的某个页面，可以放在对话里，不必每次都改长期描述。

下面这段可以作为起点：

你负责检查我的网站。只访问我提供的页面名单，以及已经授权的部署记录和统计后台。

每次先检查首页、最新文章和订阅入口。记录无法访问的页面、明显过期的说明，以及前后不一致的信息。

发现问题时，保存页面链接、检查时间和截图。把页面上直接看到的事实，与需要进一步确认的判断分开写。

最后交一份按影响程度排序的报告。每项写清问题、证据和建议的下一步。没有发现问题时，列出本次检查过的范围。

报告放在 /workspace/site-check/。可以读取资料和保存报告，不得修改网站、发布内容、联系用户或更改账号设置。

遇到登录失效或无法确认的信息，说明缺口，继续检查其他页面。不要反复尝试同一个失败步骤。

这段要求能直接拿来验收。你可以检查它是否查完指定页面，是否保留证据，是否把推测写成了事实。

角色说明里最有用的内容，是工作范围和完成标准。

7. 怎样连接应用和网站

优先使用插件和连接器

打开 Connect Apps，找到所需应用，完成授权。在对话里可以用 @ 引用连接器。旧版界面可能仍显示 Marketplace，官方更新日志已说明入口名称的变化。

连接器能直接提供应用里的操作和数据，通常比在网页上找按钮更可靠。只有它无法完成的步骤，再交给浏览器。

连接多个账号时，把账号和工作区写清楚。例如指定公司的文档库，避免把个人资料混进任务。

图 2　连接方式要跟着任务选，不必一开始就开放所有入口。

购物付款交给 Stripe Link

Grok Bot 支持通过 Link 处理购物付款。付款卡片会显示金额，让你选择允许或拒绝。

可以先让它比较商品、整理订单。确认时再核对商家、数量、总价、运费，以及是否涉及订阅。能完成付款，不等于可以替你决定买什么。

在 X 上查资料和处理内容

公开的 X 内容可以用于搜索和阅读。需要访问私信、书签或个人时间线等内容时，要连接 X 插件并登录。

一种实用起点是让它关注固定账号，整理产品更新，并为值得讨论的话题准备草稿。发布、回复和私信另设审批要求。

用 Finance 查看账户信息

原文还介绍了通过 Plaid 连接账户的 Finance 插件，并将其描述为只读访问。可以据此考虑账目汇总，但银行覆盖和当前可用范围应查看自己的插件界面。

读取账户和向别人发送账户数据是两件事。涉及金额、交易和个人信息的报告，应先交给自己查看。

重复工作可以用 API 或命令行

有些应用没有合适的插件，但提供官方 API 或命令行工具。对于反复执行的查询、导出和核对，这类接口往往更容易留下记录，也更方便验证。

让 Bot 先做一次最小范围的读取。确认账号、字段和结果无误后，再扩大范围。接口本身允许做什么，也要与任务需要一致。

需要看页面时，再用云浏览器

检查版式、走注册流程、核对按钮是否可用，都需要浏览器。让 Bot 记录最后看到的状态，别只用点击过某个按钮来判断成功。

遇到密码、验证码或人工验证时，接过电脑完成这一步，再交还控制。密码和密钥应通过支持的安全输入方式提供。

通过自己的网络访问

如果需要访问本机所在网络里的服务，可以在设置中查看 Route egress through this desktop。

开启后，云电脑的网页流量经过当前桌面设备，目标网站看到的是该设备的网络出口。

工作仍发生在云电脑上。这项设置与直接操作本机是不同功能，也会受到团队策略限制。

本机访问按需开启

只有文件、应用或运行环境确实在本机上，才需要本地执行权限。官方设置提供逐次审批等选项。

开始时保留逐次确认，会更容易看清 Bot 到底需要做什么。

8. 复杂任务先把计划讲清楚

查看一个页面，可以直接做。涉及多个后台、几十个文件或外部修改时，先要一个简短计划更省事。

可以这样交代：

先列出要检查的系统、使用的账号、可能改动的内容和最终交付物。说明怎样验证结果，哪些步骤需要我确认。先把计划交给我。

看计划时，重点找多出来的动作：你要一份报告，它却准备改配置；你只想查两个来源，它却打算搜索整个行业。这时修正方向，比做完再返工容易得多。

9. 先跑一次，再检查交付结果

先选一组自己熟悉的资料，手动发起任务。因为你知道答案的大致范围，更容易发现漏项和误读。

网站巡检可以先查三个页面。客服草稿可以先做两封。数据整理可以先用一小段样本。

交付物要能打开、能修改、能查来源。官方建议把已确认事实、推测、已完成操作、待审批操作和未解决问题区分开来。

你需要看见一份具体报告，而不仅是一句检查完成。对于网页问题，至少要有页面地址、操作步骤、预期结果和实际结果。

10. 把稳定的方法保存成技能

技能保存的是做事方法。它可以包含输入要求、操作步骤、判断规则和输出格式，后续通过 / 引用。

网站巡检跑顺之后，可以让它保存成技能，再补一句自己的要求：

下次页面没有报错，但内容与昨天相同，不要直接当成异常。只有预定内容没有按时出现，或页面状态不符合要求时，才列入问题清单。

这种细节会逐渐把你的判断方式补进去。换一批资料再试一次，比立即安排每天执行更容易发现规则漏洞。

11. 用操作演示教它做事

如果账户中有 Teach a task，可以在 Bot 的电脑视图里演示一遍浏览器操作。系统会根据可见交互生成技能草稿。官方说明目前最多记录十分钟，不录麦克风音频，功能可能分批开放。

演示之后仍要补规则。你录下的是这次怎样成功，未必说明了下次失败怎么办。

例如导出报表时，应补上没有记录时怎么处理、导出日期怎么选、下载文件怎样检查。页面改版后，也要重新试跑。

12. 给技能安排执行时间

技能说明怎么做，例行任务说明何时做。

例行任务可以按时间运行，也可以在支持的情况下由事件触发。定好时间后，核对负责的 Bot、时区、资料来源和结果去向，再执行一次测试。

图 3　先验证工作方法，再安排重复执行。

网站巡检的安排可以写得很直接。

每个工作日北京时间上午 9 点，运行网站巡检技能。完整报告保存在项目文件夹。发现新问题时通知我，并附证据。没有新问题就保存记录，不重复提醒。检查受阻时，说明卡在哪一步。

通知频率不必等于检查频率。一天检查几次，可以只在出现变化时提醒。

每十五分钟一次，一天就是 96 次。设置前先想清楚，这件事是否真需要这么频繁。短期观察结束后，也要记得停掉任务。

13. 把 Bot 分享成模板

模板适合分享一套可复用的配置。接收者添加后，会在自己的账号里得到副本，再连接自己的应用。

在 Bot 的 Share 菜单里创建模板，查看分享内容，选择公开链接或团队范围。模板不会把你的云电脑、登录会话和完整对话交给对方。

分享前逐项检查角色描述、技能和例行任务。去掉内部链接、客户资料和凭据，另外写明依赖哪些插件、文件或工具。

别人分享给你的模板，也先读再装。先试一个小任务，看看它会访问什么、交付什么，再决定是否长期使用。

14. 让整个团队使用一个 Bot

模板让每个人拿到自己的副本。Team Bot 则由负责人配置并发布，供团队成员使用，还可以接入 Slack。

每位成员有自己的私人对话，团队共享的资料与记忆则用于共同工作。需要用户登录的连接器，通常使用提问者自己的账号；以共享密钥配置的工具，要特别留意密钥权限。

图 4　个人使用、分享模板和团队共用，解决的是三种不同需求。

成员的私人对话运行在该成员的电脑环境中。Slack 频道等共享会话使用单独的共享电脑。例行任务仍归创建者个人所有，用量也通常由相应成员承担。

负责人可以指定管理者维护共享配置。适合这类形式的工作，包括内部知识问答、工单整理和团队报表查询。

15. 选一个日常联系的主 Bot

Primary Bot 可以作为平时最先联系的助手。官方更新记录提到，它会主动发现可能帮你处理的工作并提出建议。

职责可以这样划分。临时查资料、整理待办，先交给主 Bot。网站巡检、客服草稿这类固定工作，由对应的专门 Bot 负责。

不要因为它是主 Bot，就省略权限要求。把哪些事情可以自行处理、哪些要交给其他 Bot、哪些必须等你决定，都写清楚。

16. 多个 Bot 怎样交接工作

多个 Bot 可以互发消息，也可以在群组里协作。群组适合需要看见交接过程的任务，但每个阶段仍应有明确负责人。协作说明

以更新一篇教程为例，可以这样分工。

• 资料 Bot 查官方文档，列出需要更新的内容。

• 核对 Bot 检查来源和适用版本，标出仍不确定的地方。

• 编辑 Bot 根据确认过的资料改稿，交回修改说明。

图 5　每一步留下文件和交接说明，下一个 Bot 才能接着做。

交接时带上文件路径、已完成内容、未解决问题和下一步要求。不要只发一句帮忙看看。

共享文件，不代表对方自动知道该读哪个文件。安排明确后，再考虑并行，能减少重复劳动。

17. 哪些工作已经适合交给它

官方场景和原文介绍的用途，大致覆盖下面这些方向。可以拿来设计自己的任务，但不能把场景介绍当成效果保证。

• 固定来源的监测与研究

关注产品发布、文档变化或指定公司的动态。每次只报新变化，保留原始链接，说明哪些需要进一步看。

比起每天得到一大段行业摘要，更实用的结果是几条与你当前工作有关的变化。

• 跨系统查资料和帮助新人熟悉业务

资料散落在文档、项目工具和聊天记录里时，可以让 Bot 帮忙查找、核对并整理入口。

让它说明结论来自哪份资料。旧讨论与现行说明冲突时，应把冲突列出来，不能自行选一个更顺口的答案。

• 客服回复和社区工作

先让它找相关帮助文档，再起草回复。缺少订单信息、涉及退款或政策例外时，转交给负责人。

适合自动化的部分，是收集上下文和准备草稿。接收者、措辞和承诺内容仍要检查。

• 浏览器测试和问题复现

给出测试环境、账号和页面范围，让它重走用户遇到问题的路径。

交付时保留操作步骤、截图、报错信息和环境。工程师拿到这些资料，才容易判断问题是否存在以及怎样修复。官方使用场景

• 围绕编程任务做前后协调

Grok Bot 可以先整理用户反馈、查相关文档，再把明确的修改要求交给编码 Agent。编码完成后，汇总返回的文件和证据，方便你审阅。

需求还没弄清楚时，先把资料查明白。开始改代码后，验收条件就应落到具体行为和测试上。

• 用对话准备个人小工具

可以从一个窄需求开始，例如把常查的资料做成一个可点击的查询原型。先说明输入、输出和一个完整使用过程，再检查原型是否解决了问题。

能运行只是第一步。是否值得长期维护，要看自己会不会继续使用。

• 内容和设计工作

整理选题资料、查找过期说明、为不同渠道准备草稿，都有清楚的交付物。设计相关任务也应给出已有素材、版式要求和参考文件。

尤其要把事实核对与文字润色分开。句子通顺，并不能证明产品版本、日期和价格正确。

• 个人事务与办公室行政

会议准备、行动项整理、报销材料核对、候选人研究，都能从收集和整理开始。对于邮箱任务，还应写清哪些内容可以跳过。

只报告需要回复的邮件，与总结整个收件箱，工作量和结果会差很多。官方也提供了简报、原型、内容运营和行政类角色供参考。官方场景库

• 复用现成角色

选模板时，重点看职责、输入、输出和工具要求。头像和名字很容易换，真正需要理解的是它准备怎样工作。

导入后先删掉自己不需要的步骤。一个适合别人团队的完整流程，可能并不适合你的两个日常任务。

18. 哪些任务值得做，哪些适合换工具

比较值得尝试的任务，通常有几个特点。它会重复发生，需要从多个地方找信息，过程中需要一点判断，最终又能交出容易检查的结果。

例如每周核对产品页面。你可能要对照发布日志、帮助文档和实际界面，才能知道哪些说明过期。Bot 在这种整理工作里有发挥空间。

• 规则固定的工作，用固定流程

如果任务只是把一列数字相加，或把表单内容写入指定字段，脚本和自动化工具通常更直接。

可以让 AI 帮忙搭建流程，但不必每次都重新让模型判断该怎么做。

• 严格时限的任务，不依赖对话式执行

需要确定响应时间的系统，应由专门设计的服务承担。后台助手适合做检查、调查和准备工作，不宜承担必须准时完成的关键响应。

• 需要严格隔离时，重新设计环境

两个任务如果不能共享文件、账号或凭据，就要从账号和运行环境上做隔离。新增 Bot 不能解决底层共享问题。

• 要自己指定模型时，先看其他方案

Grok Bot 的模型选择由产品管理，没有供用户自由切换的模型选择器。需要固定模型或控制推理环境时，这一点会影响选型。

• 大范围代办要拆成具体操作

把管理业务换成检查指定列表，把处理客户换成准备指定回复，把维护网站换成检查指定页面。

任务越具体，越容易知道它做到了哪里，也越容易决定下一步。

19. 审批和权限怎样设置

角色描述应写明允许做什么，审批规则则决定哪些操作会停下来等你。新流程可以先用单次允许，熟悉后再考虑较窄的自动允许规则。

Auto Review 支持需要先问和可自动允许的规则。两者冲突时，需要先问的规则优先。它仍应与账号权限配合使用。审批规则

图 6　把可自动完成的准备工作，与需要确认的外部操作分开。

可以按实际任务安排。

• 读取指定页面、整理报告和保存草稿，可以在授权范围内直接做。

• 发邮件、发帖、付款、删除记录和修改正式系统，要求先展示具体操作。

• 密码、密钥和验证码，通过支持的安全输入或人工接管流程处理。

• 项目结束后，检查不用的连接、登录状态和例行任务。

不必写一条允许全部浏览器操作的规则。浏览器里既可能是公开文档，也可能是有管理权限的后台。

删除 Bot 后，共享电脑上的文件和登录状态可能仍然保留。退出账号和清理文件，需要另行处理。

20. 记忆不能替代业务记录

Bot 能记住稳定偏好和过去工作的部分上下文，但重要结论仍应回到当前来源核对。

比如它记得你偏爱周五发周报，这很有用。它记得客户上个月的状态，却不代表今天的状态仍然相同。

客户状态看 CRM，价格看当前定价页，项目进展看项目记录。记忆可以帮助它更快找到资料，最后的结论还是要有出处。

长期职责发生变化时，更新 Bot 的描述和技能。只在某段旧对话里说过一次，很容易让以后的人和任务难以追溯。

21. 博客、课程和小应用可以怎样用

放到自己的业务中，可以从下面三个方向设计任务。

• 博客和内容站

先建立页面名单，再给每类页面设检查标准。文章页看链接和版本说明，栏目页看入口是否正确，订阅页看流程是否通畅。

一次只交一份待处理清单。决定修哪几项后，再另开修改任务，避免检查和改动混在一起。

• 课程和知识产品

课程资料经常在介绍页、报名页和帮助文档里重复出现。可以让 Bot 对照一份已确认的课程资料，找出日期、适用对象和报名说明不一致的地方。

客服任务则从查资料、整理疑点和准备回复开始。涉及购买记录或访问权限时，交回负责人处理。

• 小应用和长期维护

为每个应用列出一条核心使用路径。比如注册后能否进入正确页面，导出的文件是否可打开，错误状态是否有清楚提示。

测试时使用指定环境和测试账号。交付清单应能让你按步骤重现，而不是只有一个总体正常的结论。

22. 常见问题怎么处理

• 一直讨论，却没有产出

先查看它是否在等待问题、审批或网页响应。方向不对时直接纠正；需要结束时明确让它停止。然后缩小任务，并重新指定交付物。

• 网站反复要求登录

人工接管并完成验证，确认页面已登录，再让 Bot 继续。部分网站会反复验证，不能承诺一次登录后永久可用。

• 插件突然失效

检查授权和账号是否正确。重新连接后，先做一个小范围读取，再重跑完整任务。

• 找不到之前的文件

让它检查具体文件夹，返回实际路径。确认文件是在云电脑、当前本机，还是其他应用里，不要只凭文件名搜索旧对话。

• 用量消耗太快

先看例行任务频率、浏览器步骤和重复尝试。把宽泛研究缩成明确问题，给失败重试设终点，再观察下一次运行。

• 更新后电脑异常

先重试、重启应用，再按提示恢复或更新电脑。Reset 应放在最后，因为它可能丢失最近未同步的状态。重要文件先备份。

23. 新 Bot 上线前，最后检查一次

• 它只负责一项说得清楚的长期工作。

• 使用哪些来源、账号和工具，已经写明。

• 最终交什么、放在哪里、怎样检查，都有约定。

• 缺资料、登录失败和没有新结果时，知道怎么处理。

• 需要你确认的外部动作，已经划出范围。

• 技能换过一组资料试跑，例行任务也核对过时区。

• 多 Bot 协作有明确交接文件和负责人。

• 最初几次运行的结果、耗时和用量，都看过一遍。

真正开始时，用不着同时创建很多角色。

挑一项你熟悉、又经常重复的工作，让它做一次。

哪里不对，就把要求补清楚。连续几次交付都能接着用，再安排长期执行。

一个月后再回头看：哪些 Bot 的结果你还在认真读，哪些通知已经习惯性忽略。留下前者，调整或停掉后者，才不会把省事的工具用成新的待办来源。