Miles Deutscher 分享了 10 种 Grok Bot 工作流：整理收藏、准备晨报、从群聊中筛选信息、寻找潜在客户、盯竞品、核对订阅，以及改编内容、辅助经营 X、做小工具和组织多个 Agent 分工。每个用例都配了一张完整提示词卡。

它们有一个共同的起点：把一件反复要做的事交代完整。比如“盯一下竞品”，需要补成盯哪些公司、拿什么作为上次状态、什么变化值得报告，以及结果里要带哪些证据。Bot 才有一份能照着推进、也能由你验收的任务说明。

Grok Bot 是能在云电脑上使用浏览器、文件和已连接工具的常驻 Agent。图卡描述的是怎样配置任务，没有提供这些工作流的运行日志或效果测试；首帖“全球最好”“过去要工程团队做几个月”的说法，是 Miles 的评价。这些卡片的可借鉴之处，要落到每项任务的具体做法上。

---

云端执行底座：Grok Bot 到底在什么样的“电脑”上干活？

理解这 10 套用例的前提，是看清 Grok Bot 的运行环境。许多读者以为它和以往的聊天机器人一样，只是背后接入了更聪明的大模型，或者在本地电脑上安装了插件。实际上，Grok Bot 的工作基础是一台运行在云端的独立虚拟电脑。

在这台云电脑上，Bot 拥有持久化的浏览器、命令行终端、本地文件系统（位于 /workspace 目录），并可以接入各类第三方应用插件。当你在前台关闭笔记本电脑或断开网络时，这台云电脑中的脚本、网页抓取与任务处理依然在后台持续推进。

要避开实践中的误区，需要厘清这项技术底座的两项关键运行规则：

同一账号共享同一台云电脑，不是一个 Bot 一台硬件

提示词卡中出现了“每个专员在独立机器上运行（on its own machine）”的设定，帖文也容易让人联想到十几个独立的服务器。但官方技术规范明确指出：同一个用户账号下的所有 Bot，使用的是完全相同的同一台云电脑。

这意味着两层含义：

• 数据与会话天然互通：你在云电脑浏览器中登录过的服务（如 GitHub、邮箱或社群 Web 端），持久化 Cookie 和会话对该账号下的所有 Bot 都是共享的；Bot A 在 /workspace 下载的数据，Bot B 可以在命令行中直接读写；

• 各自分屏不等于安全隔离：每个 Bot 在这台共享电脑上拥有自己专属的“虚拟显示屏幕（Screen）”，因此多个 Bot 可以分屏并行操作浏览器或桌面应用。共享文件和登录状态仍可能影响彼此的工作。但这些屏幕只是并行的“操作展示面”，绝非硬件级别的“安全隔离区”。不希望其他 Bot 使用的文件或凭据，就不应放在这台共享电脑上。

在社交平台用 @bot 接力任务的真实触发规则

在日常使用中，用户无需每次都打开客户端输入长篇指令。需要把 X 账号关联到 Grok，在同一账号上拥有 Grok Bot 使用资格，并创建至少一个自己的 Bot；地区支持时，便可以在帖子或回复中直接 @bot 派发任务。别人分享给你的 Bot 不接收这种请求。

例如，在看到一段长篇推文分析时，回复一行指令：

@bot 总结这条主题帖的要点，保留原帖链接，把结果放在我们的对话里。

@bot 会在社交平台上公开回复一句简短确认，表明你的主 Bot 已在云电脑中接手工作。任务和结果在 Grok Bot 应用中继续，X 上的 @bot 只给接收回执；请求会自动开工并消耗 Grok Bot 用量。没有回执，就不能视为任务已经收到。

转交内容包括你发的帖子、回复对象，以及两者引用的帖子和静态图片，不保证自动拿齐整串。处理长主题帖时，要让 Bot 继续读取并核对覆盖范围。本帖、回复对象或引用帖含视频或 GIF 时，@bot 不会响应；只在已经含 @bot 的讨论中回复、自己却没提及它，也不会触发。

地区按 X 记录的账号国家判断，改变当前位置或 VPN 不会改变判定。官方文档列出的暂不支持地区包括澳大利亚、英国、欧盟、冰岛、列支敦士登和挪威；只记录宽泛大区或没有国家的账号也暂不支持。

X 插件对这一步转交是可选的。要让 Bot 读取自己的私信、书签和首页时间线等账户资料，则需要在 Grok Bot 的 Connect apps 中连接 X 插件。其他邮箱、日历或群聊任务同样要先具备对应的连接或可用登录状态。

图卡里的 <role>、<contract>、<output> 等 XML 风格标签，是把角色、范围和交付分段写清的方法；它们本身不会设置工具权限，也不是能强制阻止动作的程序。

---

以下按用途重排十个案例，编号沿用原帖。

选一个任务，看它怎样交付

按原图整理的工作流速查；每个案例的解释与原图都在下文。

全部 10 项信息与日常业务与开支内容创作工具与分工

01第二大脑02造一个小工具03多 Agent 分工04每日晨报05一份素材改编多平台06订阅审计07群聊信息提取08寻找潜在客户09竞品监测10个人 X 助手

用例 06

订阅审计

需要提供

指定邮箱、检索时段和账单关键词

处理过程

1只读账单

2提取金额频率

3年化并查重复涨价

4给建议，按选定项列取消路径

交付结果

按年化支出排序的保留、复核、取消建议，附证据与潜在节省。

使用证据不足标未知；年化是折算，取消等操作需逐项批准。

---

知识与日常决策流：第二大脑、决策晨报与高噪群聊提取

面对每天涌入的海量信息，普通工作者最容易陷入两类困境：要么是把有价值的内容一股脑存进书签，从此再也不看；要么是被无休止的群聊和待办淹没，到了早晨不知该从何下手。这组用例展示了如何把大模型变成能筛选、关联并定期交付信息的助手。

01. 第二大脑（Second Brain）：让知识库主动寻找认知矛盾

收藏一篇文章容易，下一次工作时重新找到它、想起它和旧资料的关系，往往需要再花一遍时间。第二大脑卡片把这部分整理工作交给 Bot。

在这套结构中，Bot 并非被动等待问答，而是承担起“信息深加工员”的角色：

• 拒绝标题党记录：在 <read> 模块中，要求 Bot 通读全文，不能仅凭标题生成摘要。每条记录保存来源、作者、收录时间、一句话核心论点（claim）、具体数字与方法、收藏时的背景，以及原始链接；

• 语义实质关联：在 <connect> 模块中，不能只因两份资料用了相同标签就判定它们相关，而要按“支持、反驳、延伸、取代、重复”等内容关系连线；

• 将“认知矛盾”列为一等输出：在 <contradictions> 模块中，一旦新内容与库中既有观点发生冲突，Bot 必须主动并列双方的论点出处与时间戳。这样你能看出新材料是在补充原有判断，还是要求你重新考虑它；

• 克制主动推送：有了你提供的当前任务背景后，最多只唤醒推送 3 条最相关的过往资料，防止频繁打扰。

每周报告还要交代收进了什么、建立了哪些联系、哪里出现冲突，以及哪些资料一直未读。回答问题时，Bot 先找你已经存下的材料并带上出处和时间，外部新搜到的内容另行标明，避免把“网上刚查到”说成“你以前收藏过”。

可以在自己的知识管理 Prompt 中加入这一条：“每当我记录一个新观点，请检索库中已有记录，明确告诉我它与哪一条已有结论冲突，并列出双方依据。”

04. 决策型晨报（Morning Brief）：按“需我决策”重组晨间任务

面对几十封邮件与多条即时沟通，常规的“未读摘要”只是把长文本变成了短文本，依然需要人类耗费心智去归类。

晨报先约定时区、送达时间、邮箱与日历等范围，以及篇幅上限。每次读取上次简报之后的新变化，再按你要处理的事整理：

• 严格限定篇幅：在 <brief_contract> 中必须设定篇幅上限。一份没有长度限制的晨报，用不了几天就会被读者放弃；

• 按四类整理事项：所有扫描到的信息只能扔进四个固定桶中：今天需要我做决策的事（decide）、等待他人推进的事（waiting）、我承诺过但尚未交付的事（owed）、以及纯知会无需动作的变动（fyi），绝无第五个桶；

• 扫描“随口诺言”：在 <commitments> 模块中，Bot 重点扫描用户在已发送邮件或聊天中写下的“我稍后给你发”“我下周处理”，原话摘录并核对是否已交付。让你能对照自己说过的话，决定今天补交什么，而不是只看到别人催你的消息；

• 紧急度排序与安全只读：在 <order> 中，打破按“邮件/日历/即时软件”的平台排序，统一按“需我立即决策 > 本周需要我 > 等待他人 > 日程细节”排序。若没有需要你处理的事项，就直接说“今天没有需要你处理的事”。

当天日程列出会议时间、参会人及已有背景，标记连轴会议和没有议程的会议。它也会找出有人在等你回复、超过正常回复窗口的静默会话，以及未来 7 天内截止却没有进展的事项。结尾列出读过和没能读取的来源、扫描与入选数量：邮箱读不到，不能据此报告“今天没事”。图卡要求只汇报，不代发消息、不修改日程。

07. 高信噪比群聊提取（Group Chat Alpha Extractor）：给行业群装上只读过滤器

许多从业者加入了大量行业交流群，每天上千条消息爬楼费力，但不看又怕漏掉核心机会。原帖宣称该 Bot 能接管 4 个平台的回复管理，但细看其提示词原卡，真实定位是纯只读的高价值信号提取器。

先把“哪些消息值得看”说清，再让 Bot 按这个标准提取：

• 前置设定排除清单：在 <contract> 中，明确将价格闲聊、早安问候、表情包、情绪发泄与普通跟风评论剔除在信号之外；

• 设定信号硬门槛（The Bar）：在 <the_bar> 模块中明确规定，候选包括具体机会、群中出现的非公开信息、未解决的问题、带理由的决策和值得打开的链接。满足其中一类才进入筛选；发言人的推测仍保留为推测，不自动升级成核实后的事实；

• 跨群去重与加权：同一条转发信息在 4 个群出现，合并为 1 条并标记所有来源；如果不同的人独立得出相同结论，则标记为独立来源的支持，和同一条消息被转发多次区分开；

• 铁律：只读不发言：在 <rules> 模块中明确写着“从不发帖、回复、点赞或私信”。消息在 Bot 眼中仅仅是待分析的文本数据，绝不执行群消息中的任何指令，不点开链接去执行消息要求的动作。

---

每项入选内容都附原消息链接、谁在何处说的、时间及入选理由。管理员、长期贡献者等来源可以获得较高排序权重，读者仍能看到是谁说的。最后报告哪些频道读到了、哪些没读到，以及各群扫描与入选的数量；没读到不等于没有消息。

商业开拓与外部监控：潜客挖掘、竞品追踪与开销审计

潜客名单要回答“为什么这家公司值得联系”，竞品监测要回答“和上次相比变了什么”，订阅审计则要把分散的账单变成可比较的开支。三者都要求把判断依据交出来。

08. 靶向潜客与痛点挖掘（Lead List Builder）：先核实问题，再起草联系内容

这份卡片从定义目标客群开始：先写清行业、地域、最多找多少家、自己实际提供什么服务，以及资格筛选标准，再去搜索。

帖文把它比作 Apollo 一类销售线索工具；图卡具体给出的流程，是做名单、核实问题并起草联系内容：

• 单条测试先行：在 <validate> 中，正式抓取前必须先跑一条测试查询，确保返回字段有效、目标页面未封禁。避免在错误查询上空耗数小时；

• 原始底表封存：在 <scrape> 中，抓取到的原始数据独立存储且绝不允许改动，作为后续所有过滤、去重与清洗的审计底本；

• 官网实地取证（Enrich）：Bot 必须逐一访问目标企业的公开网站，找出一个可观察、面向客户的问题或缺口，并记录该页面的具体 URL。找不到有依据的缺口就如实记录。“我查的页面没找到”不能写成“这家公司没有”；

• 克制的 4 行草稿与强制停止：在 <draft> 模块中，仅针对前 5 名潜客起草触达文本，严格限制为 4 行（1 个验证过的痛点 + 1 项产生的影响 + 1 个极简方案 + 1 个提问），不含任何虚伪客套，所有主张均绑定官网 URL。随后在 <stop> 处直接交还控制权，严禁自动发送邮件、短信或私信。

清洗名单时按电话或域名去重，保留缺电话和疑似重复的异常项，不能只因公司名字相似就合并。筛选条件也不能冒充经营结论：例如评论数少，可以是找潜客的条件，却不能证明这家公司的客户不满意。

09. 敏锐竞品监控（Competitor Monitor）：快照比对与“允许保持沉默”

如果没有记录上次状态，Bot 看到一个很久以前就存在的功能，也可能把它当成新消息。竞品监测卡片首先解决这个比较基准的问题。

这套竞品监控提示词的核心在于“先存基线，只报差异”：

• 在扫描前确定变动阈值：在 <watch_contract> 中，预先定义哪些属于重大实质变动（Materiality Threshold），防止模型在看到无关动态后临时调低标准来“凑数”；

• 强制先跑基准快照（Baseline）：在正式设置定时监控前，必须先手动抓取一次所有监控源的初始页面并建立快照。没有基线比对，第一次运行就会把陈年旧事当作突发新闻上报；

• 专注 6 类核心差异：在 <compare> 中只提取实质性变化：价格调整、核心功能增删、产品定位宣传语变动、招聘模式变化、融资或重大合作、带有明确截止日期的公开承诺；

• 保持沉默是合法输出：在 <rules> 模块中确立了一条关键原则：“Silence is a valid output”。如果本轮扫描没有实质变动，Bot 只需输出一行说明并列出无法访问的源，绝不能为了证明自己的存在感而强行拼凑报告。

同一公告被六家媒体报道，仍合并为一件事，保留各来源。每项重要变化交付“旧状态 → 新状态”、发现时间、一句话意义和直接来源链接，再更新基线，供下一轮比较。无法读取的页面标为覆盖缺口，不能把它解释成“没有变化”，也不据页面变动预测对手下一步战略。

06. 订阅开销审计（Subscription Auditor）：把账目算清，但绝不代用户取消

原帖声称此 Bot 能“实时谈判价格并申请退订”，这容易让人产生 AI 已经拥有财务处置权的误解。图卡具体要求的是核对账单、提供建议，再等待逐项批准。

它把账单整理分为几个可检查的步骤：

• 严格限定单向只读账单：在 <billing_only> 模块中，仅搜索发票、收据、扣款确认等特定关键词邮件，严禁总结、转述或存储个人通信往来；

• 全量归一为年化开销：在 <annualise> 中，按账单金额和频率折算为年化成本，并把原始计费金额与年化数并排显示。这是按当前费用折算的比较值，不是已经发生的全年支出；

• 识别静默漂移（Drift）：比对历史账单的首尾金额，标出涨价的旧金额、新金额和变动日期；同时标记同一项服务被两张信用卡扣款，或功能完全重叠的工具；

• 提供路径，原地等待：在 <stop> 模块中，对建议取消的项目给出精准的退订管理页面 URL、账户入口或官方客服流程。列出路径后等待；即使用户要求执行，也先展示该服务的具体页面与动作，再取得这项操作的明确同意，不擅自取消、降级、修改或购买。

---

记录还包括服务名称、币种、扣费频率、最近扣款、可查到的下次续期，以及付款方式或卡号末四位。使用情况只根据邮箱中的登录通知、用量总结等证据判断；没有证据就写“未知”，不能推成“你已经不用了”。最终按年化费用从高到低，给出保留、复核或取消建议及理由，并汇总可能节省的金额，不能把建议中的节省写成已经省下的钱。

内容生产与社交分发：长素材重构与个人 X 助手

内容改编处理的是一份材料怎样拆成多条有独立价值的内容，X 助手处理的是你平时值得参与哪些对话。两者都先准备可审阅的草稿。

05. 单素材多平台内容重构（Content Repurposing Engine）：把一份素材拆成两周草稿

推文中声称该 Bot 能“自动接入你的 X 账号提取爆款”，但细看提示词卡，它的输入源非常明确且严谨：先指定一份具体源文件（[source file]，如一篇长文章、访谈录音逐字稿或研究报告）。

先确认源文件、目标平台、发布节奏与时区。没有语气资料时，读最近 30 条本人发帖来提炼口吻，然后再拆内容：

• 强制完整通读全文：在 <read_all> 中，严禁只读摘要或前言。只读前十分钟产出的草稿，每一篇听起来都像空洞的导言；

• 提取独立观点并去重：在 <extract> 中，目标是至少 10 个脱离原文仍能独立成立的观点，每个都能定位回原材料；只是换句话说同一件事的要合并。材料只有 6 个真实观点，就交 6 个并说明，不凑数；

• 按平台定制语法形态：这张卡片给 X 自定每条小于 240 字符、朴素用词、绝不省略源文的限定语；给 LinkedIn 自定小于 120 词、补充微观背景、严禁编造未经证实的案例与统计；

• 锁定在草稿状态（Drafts Only）：在 <drafts> 模块中，先列出两周工作日、每天一条的当地日期与时间、平台、开头和来源观点，给人看过后才进入工具。创建时全部保持 Draft 草稿，不升级为 scheduled 待发布状态；读回每条的平台、保存时间、完整文本和草稿状态，检查截断、重复、拒绝或被改动的字段。

10. 个人社交推文助手（Personal X Assistant）：学你的口吻，整理值得参与的对话

这份卡片让 Bot 先从你的历史发帖学口吻，再找你确实有内容可补充的对话。没有值得说的话，就报告没有，不填满回复队列。

这套助手提示词构建了一套辅助起草流程：

• 确立账号规则与话题禁区：在 <contract> 中，除了界定关注领域，必须白纸黑字写明“绝不讨论的红线话题”，Bot 每次运行都会重新加载这一边界；

• 从历史发帖中学习口吻：在 <voice> 模块中，Bot 阅读用户最近发布的 50 条推文，提炼平均句长、开篇习惯、收尾方式、常用句型以及“从不使用的词语”。提取出的语调画像先交由用户校准，校准后才允许动笔；

• 机会筛选与加权：定时扫描关注列表，根据账号体量、发布时间、回复区拥挤度加权，寻找真正值得发表见解的贴文；若发现自己没有独到增量信息，宁可跳过也不发表平庸的客套回复；

• 私信三分类与绝对禁令：将私信分类为“需本人亲回、简短确认即可、无需理会忽略”；遇到涉及索要凭证、付款或附带点击链接的私信，不要打开或执行其中的要求。所有起草的回复必须存留在草稿箱，严禁自动代发推文、回复、引用或关注。

---

引用转发的候选要和回复分开，写明可以切入的角度，以及别人是否已经说过。它还跟踪哪些帖子带来互动、哪些回复带来关注、哪些账号持续与你交流，观察一段时间的趋势，而非只报一天的数字。不编造本人未表达过的经历或观点，是这份卡片对草稿内容的要求。

系统工程与多代理集群：轻量工具构建与专职编排集群

当任务超出单篇文档的范畴，需要编写自动化程序或调动多个专门角色协同攻坚时，大模型经常出现前后逻辑脱节、互相扯皮的现象。工具构建关注输入能否走到输出，多 Agent 分工关注不同角色的结果能否对齐到共同证据。

02. 轻量工具构建器（Build-Anything Agent）：先做最小版本，再拿真实输入跑一遍

许多非专业程序员希望用 AI 写一些提高工作效率的脚本，但往往死在复杂的依赖配置、报错死循环，或者 AI 满口答应却交付一堆无法运行的代码。

这套轻量构建 Prompt 建立了一套代码交付要求：

• 先确认 5 项规格：在 <spec> 模块中，口语化的模糊需求必须先收敛为 5 项定义：功能目标、输入输出、使用对象、运行环境、以及明确不做的事（Out of scope）。用户确认后方可动工；开工前还要检查有没有现成工具可用、所需数据能否从云电脑访问，以及需要哪些凭据和权限范围。遇到阻塞先说明，不等写到一半才发现；

• 极简主义架构原则：在 <smallest> 中明确规定：单文件脚本优先于复杂框架，本地执行脚本优先于独立网络服务；除非状态必须跨重启保存，否则绝不引入数据库。每一个第三方依赖必须附带一句话的存在理由；

• 核心路径实跑测试：在 <core_path> 和 <test> 模块中，只关注输入到输出的主链路通畅。用真实输入，以及空、超大、格式错误的输入和网络调用失败进行测试，重点汇报报错位置而非粉饰成功；

• 以真实输出截图为凭据：在 <prove_it> 模块中立下规矩：代码通过编译不代表能用，粘贴在聊天框里的代码更不是可用证明。Bot 必须在云电脑上真实运行该程序，附带控制台真实日志或 Web 界面截图。交付精确运行命令或 URL；凭证只说明环境变量名和文件位置，等人安全填入，不要求贴进聊天。还要说明哪些部分仍是占位、已知哪里会失败、长期运行需要什么，以及下一项值得补的功能。图卡要求不部署到用户服务器、域名或生产环境。

03. 专职编排集群（Grok Swarms / Orchestrator）：事实账本与保留争议

当面临大型行业调研时，一个 Bot 很难同时兼顾广度与深度。但如果简单派发多个 Bot，往往会演变成各说各话、信息重复，或者在最终汇总时把关键分歧强行抹平。

编排者 Bot（Orchestrator）的核心价值不是亲自调研，而是充当“项目总控与事实裁决员”：

• 按需组队，严禁全员出动：在 <team> 模块中，编排者先审视任务，只挑选最需要的专家角色。图卡以小问题用 3 个 Bot 而非 9 个为例，强调按需选人，人数不是产品限制，绝不滥用资源组建臃肿团队；

• 专属任务书（Briefs）与分工防重：在 <briefs> 中，每个被派生的专员只拥有一个核心问题、指定的数据源清单、确定的返回格式与严格的行动边界。严禁两个专员重复调研同一个问题；

• 统一事实账本（Evidence Ledger）：在 <evidence_ledger> 中，专员抓取到任何关键数字与结论，必须实时登记出处与时间戳。后续所有专员撰写结论时，必须引用账本条目，严禁凭借模型记忆主观发挥；

• 争议显性化（Reconcile）：在 <reconcile> 中，编排者把搜集到的结论整理为“达成共识、存在争议、未经证实”三类。遇到存在分歧的数字，严禁通过取平均数或挑选语气更自信的专员来粉饰太平，必须把双方立场和各自依据并列展示，指明需要补充什么证据才能裁决，交由人类决策。

关键来源被挡、覆盖失败，或支撑主要判断的关键结论缺少可靠证据时，协调者收窄问题重派一次，仍不够就明确标出缺口。每个专家也继承自己的行动边界，不能因加入团队就获得额外外发、购买或删除权限。

在这个集群模式中，需要结合官方底层架构理解：这些专员在同账号下共享同一台云电脑与文件系统。它们的分工优势在于思维维度的拆解、每个角色明确的任务说明，以及在共享工作区内分头写入分析记录，而不是物理层面的多机隔离。

延伸：管理多个项目Grok Bot 多项目指南：一个频道、一组成员和两层 Notion 看板看 Eric 怎样用频道、成员名册与项目/任务看板组织多条工作线，并把卡点交回人。阅读多项目指南 →

---

从一项反复要做的工作开始

这十张卡片能借用的，是交代任务的方法：先说处理哪些输入、按什么标准筛选，再规定要交什么结果，以及做到哪一步停下来。竞品需要上次状态，晨报需要已发承诺，内容改编需要完整原文，调研团队需要共享证据账本；把这些写出来，比只给一个岗位名称更便于执行和验收。

实际运行还需要可用的账号、工具连接、登录状态、文件保存和定时配置。提示词把要求写清，工具权限与批准机制决定它实际可以做什么；一份写得完整的卡片，仍要用真实任务检查结果。