为什么你一定要学 Grok Bot？
你一定要学的，不只是一个新工具，而是一种人与 AI 协作的新方式。
过去两年，我们一直在学习怎么给 AI 一个更好的指令。
怎样写提示词，怎样补充上下文，怎样让它少说废话，怎样让它生成更像样的文章和代码。
后来有了 Codex 和 Claude Code，AI 终于不只是回答问题。它可以进入项目、阅读文件、修改代码、运行命令、检查结果。
但只要工作离开代码仓库，很多人仍然在替 AI 打工。
你看到一条重要消息，先复制链接；把链接发给 AI，让它总结；再把总结复制进文档；打开另一个网站核实；切到 X 写草稿；最后自己发布。
AI 很聪明，但真正操作软件、搬运信息、盯住流程的人还是你。
你不是在管理 AI。
你是 AI 和所有软件之间的人工中间件。
这也是 Grok Bot 最值得关注的地方。
Grok Bot 最吸引人的使用场景，看上去彼此毫不相关：把视频做成图文文章、自动阅读社交媒体、处理公司行政事务、寻找商业机会、分析产品数据。
这些场景真正重要的地方，不是 Grok 又会写文章、又会看网页。
而是用户不再亲自操作每一个软件。
用户只需要说清楚想要什么结果、允许它使用哪些工具、做到哪一步必须停下来。剩下的浏览、整理、生成文件和交付，由 Bot 在自己的工作环境里完成。
过去是：
人找资料 → 人切换软件 → 人整理信息 → AI 生成答案 → 人继续执行
现在开始变成：
人定义结果和边界 → Bot 操作电脑、网站和应用 → Bot 交付可以检查的结果 → 人判断、纠偏和批准高风险动作 → 成熟流程继续重复运行
这不是多了一个按钮。
这是工作责任第一次开始从人手里，成块地交给 AI。
所以，为什么你一定要学 Grok Bot？
不是因为它会永远领先，也不是因为所有人都应该立刻购买。
而是因为你必须开始学习一项新能力：
不再只给 AI 一个问题，而是给它一个岗位。
接下来的难点，不再只是“提示词怎么写”。
而是岗位怎么定义，工具怎么提供，边界怎么设置，结果怎么验收，失败以后怎么纠正，什么时候才能放心让它自动运行。
这篇文章会把整套方法讲清楚。
我们还会一起创建一个真正能工作的 AI 情报 Bot：它每天查看 AI 产品官网、GitHub、X 和指定博客，找出真正重要的变化，核验原始来源，生成一份情报日报；没有重要消息时保持安静，来源失败时明确报告，未经批准不得发布任何内容。
当你能把这个 Bot 从零建立起来，你学会的就不只是 Grok Bot。
你学会的是怎样管理一个数字员工。
一、Grok Bot 到底改变了什么？
Grok Bot 最容易让人误解的地方，是它看起来仍然像一个聊天软件。
你创建一个 Bot，给它起名，然后发消息。
如果只看这个界面，它和 ChatGPT、Claude 似乎没有本质区别。
区别藏在聊天框后面。
Grok Bot 的 Bot 可以在持续存在的云电脑上使用网站和应用，也会保留与岗位相关的工作状态。多个 Bot 可以拥有不同岗位、对话和屏幕，但它们共用用户级云电脑、文件、浏览器会话和登录状态。
这使它和普通聊天助手之间出现了四个重要变化。
第一个变化：从提示词变成岗位
普通聊天的默认关系是：你问一次，它答一次。
Bot 的默认关系应该是：你给它一个长期负责的结果。
“帮我看看今天有什么 AI 新闻”是一条提示词。
“每天检查这些官方来源，只保留会改变实际使用方式的更新，给出原始链接和影响判断，无法核实时放进待确认区”才是一份工作的开始。
前者每次都需要重新解释。
后者开始形成稳定岗位。
所以创建 Bot 时，真正重要的不是名字，也不是头像，而是它长期对什么结果负责。
第二个变化：从回答问题变成交付结果
聊天助手擅长输出一段文字。
但工作世界需要的通常不是一段文字，而是一件完成的东西：一份日报、一个更新后的文件、一组已经核验的候选信息，或者一个停在发布前的草稿。
这两个标准完全不同。
“回答得像”只要求语言通顺。
“工作完成了”还要求来源正确、时间正确、格式正确、文件放对位置，并且没有越过权限边界。
当 AI 开始操作真实工具，评价标准就必须从“答案好不好”升级为“结果能不能验收”。
第三个变化：从人做路由，变成 Bot 跨工具执行
传统 AI 工作流最浪费人的地方，不是输入那几句话。
而是人需要不断负责交接：从浏览器复制到聊天框，从聊天框复制到文档，再从文档复制到发布工具。
Grok Bot 的产品方向，是让同一个 Bot 在自己的工作环境中打开来源、读取信息、整理文件，再把结果交回来。
人不再负责每一次复制和切换，只负责三件更值钱的事：
- 决定要什么结果。
- 提供判断好坏的标准。
- 在不可逆动作前作出决定。
第四个变化：从每次重新开始，变成方法可以复用
一个任务做对以后，真正有价值的不是保存那次聊天。
而是把可靠方法留下来。
在 Grok Bot 里，Skill 用来描述一件事应该怎样完成；Routine 则把这个方法交给一个指定 Bot，规定它在什么时候运行。正确顺序是先完成一次真实任务，修正到可靠，再保存为 Skill，最后才建立 Routine。
这意味着你不是在不断积累提示词。
你是在逐步建立一套可以重复执行的工作制度。
有人把这种变化概括为“把 AI 当真人来用”。
这个方向对了一半。
像同事一样交代目标、背景和完成标准，确实比把它当搜索框更有效。
但 AI 终究不是人。它会误判，会使用过期资料，会在网站变化后点错位置，也可能严格执行一条写得不够严谨的错误指令。
所以更完整的原则应该是：
像管理同事一样交代结果，像管理系统一样设置边界。
你可以让它读资料、整理信息、生成草稿。
但发送、发布、购买、删除、修改权限和改动生产系统，应该停在明确的审批点。
真正先进的人机协作，不是人完全退出。
而是人退出低价值操作，把注意力留给判断、纠偏和责任。
二、已经有 Codex 和 Claude Code，为什么还要学 Grok Bot？
如果你已经用过 Codex 或 Claude Code，看到这里很可能会有一个疑问：
这些能力听上去并不新。
Codex 可以操作文件、运行命令，也有云端任务。Claude Code 不只在终端里工作，它已经覆盖 IDE、桌面和浏览器，还能建立云端或本地的定时任务。
这个质疑是对的。
因此，判断 Grok Bot 的价值，不能靠列一张“谁有浏览器、谁有 Routine、谁有记忆”的功能表。
这些产品正在快速互相吸收能力。今天还独有的功能，几个月后可能就会出现在另外三个产品里。
真正应该问的是：
这项工作默认发生在哪里？它最终要交付什么？
如果工作围绕代码仓库，优先使用 Codex 或 Claude Code
Codex 的强项是进入本地或云端开发环境，阅读项目、修改文件、运行测试、做代码审查，并与工程工作流连接。
Claude Code 同样是能够读取代码库、编辑文件、运行命令，并在终端、IDE、桌面和浏览器中工作的编码 Agent。现在它也提供云端 Routines 和桌面定时任务。
如果你的目标是修复 Bug、实现功能、补测试、审查 PR 或维护代码库，没有必要为了“像员工”这个隐喻，把任务强行搬到 Grok Bot。
编码 Agent 已经拥有更成熟的项目语境和工程工具。
如果工作跨越多个网站和业务应用，Grok Bot 更接近它的默认主场
AI 情报日报就是一个典型例子。
它的核心不是修改某个仓库，而是持续查看多个来源，维持必要的登录状态，把网页、文件和连接器中的信息整理成一份业务结果。
这类任务当然也可以通过代码、脚本、MCP 或 Claude Code Routines 实现。
但 Grok Bot 把“一个长期岗位拥有一台持续在线的通用工作电脑”放在了产品正中央。
新手不必先设计 Agent 框架、准备服务器、搭建调度器，再决定怎样把结果送回来。
先创建一个岗位，授权它需要的工具，再从一个真实任务开始。
这就是它降低的主要门槛。
如果你要的是自主部署和更深控制，Hermes Agent 是另一条路线
Hermes Agent 也不能被简单写成“消息转发器”。
它是 Nous Research 开源的个人 Agent，可以运行在自己的电脑或服务器上，覆盖 CLI、桌面、Telegram 等消息入口，并提供记忆、Skills、子 Agent、Cron、终端和浏览器工具。
你可以自己选择模型、提供商、运行环境和工具，也可以把它部署成统一入口和多 Agent 控制层。
代价是你需要承担更多安装、配置、权限、服务稳定性和日常维护工作。
Grok Bot 走的是另一条路：平台先把托管云电脑、Bot、登录状态、Skill、Routine 和审批界面放到一个产品里。
它牺牲了一部分自行搭建的自由，换取更低的起步门槛。
所以，这四种工具不是淘汰关系，而是职责分工
可以用一句最简单的话来判断：
- 主要在代码库里完成：先看 Codex 或 Claude Code。
- 主要跨网站、文件和业务应用持续执行：重点看 Grok Bot。
- 想自托管、自由选择模型并建立自己的 Agent 运行时：重点看 Hermes Agent。
- 只需要一次回答或一份临时内容：普通聊天 AI 已经够用。
边界不会永远固定。
Codex 和 Claude Code 会继续扩展浏览器、云端和业务工具；Hermes 会继续降低部署门槛；Grok Bot 也会吸收更深的工程能力。
所以你真正要学的不是四套产品功能表。
而是怎样拆分工作责任：谁负责代码，谁负责跨系统业务任务，谁负责调度，哪些动作必须由人批准。
Grok Bot 值得学，正是因为它把这套协作方式做成了一个新手也能直接看见的产品。
但看懂概念还不够。
接下来，我们会从下载、注册和安装开始，真正创建第一个 Bot，并用 AI 情报日报把岗位、任务、边界、Skill 和 Routine 一步步跑通。
三、怎样下载、注册和安装 Grok Bot？
先说明一件事：Grok Bot 目前仍处于快速变化期。
下面的账户、平台和界面信息核验于 2026 年 9 月 2 日。以后如果菜单位置或套餐名称变化，以你当时看到的客户端为准。
安装前先检查三件事
第一，你需要一个可以使用 Grok Bot 的账户。
目前可用范围包括：
- SuperGrok、SuperGrok Plus、SuperGrok Heavy。
- Cursor Pro、Cursor Pro+、Cursor Ultra。
- Cursor Teams Standard 和 Premium。
套餐变化很快，所以不要先看别人几个月前的价格截图。直接登录自己的账户确认是否出现 Grok Bot 入口，最可靠。
第二，你需要一台支持的设备。
- macOS：支持 Apple silicon 和 Intel。
- Windows：支持 x64 和 Arm64。
- iPhone：需要 iOS 18 或以上。
- 目前没有 Linux 桌面客户端，也不支持 Android 和 iPad。
需要注意：Grok Bot 的云电脑运行在 Linux 上，不等于它提供 Linux 桌面客户端。
第三，你必须接受云端数据存储。
Grok Bot 依赖持续存在的云电脑和云端状态。如果 Cursor 账户启用了 Legacy Privacy Mode，需要先切换到受支持的数据设置，否则无法启动。
如果你的工作不能把文件、登录状态或业务数据放到托管云环境里，就应该先停下来评估，而不是为了尝鲜直接授权。
macOS 怎么安装？
- 打开 Grok Bot 的产品页：https://x.ai/bot。
- 选择适合自己电脑的版本：Apple silicon 或 Intel。
- 打开下载的磁盘镜像。
- 把 Grok Bot 拖入 Applications。
- 第一次打开时，如果 macOS 弹出确认提示，选择打开。
不知道自己是哪一种芯片，可以打开：
苹果菜单 → 关于本机
看到“芯片”字段，一般就是 Apple silicon；看到“处理器”字段，则是 Intel。
Windows 怎么安装？
- 打开 Grok Bot 产品页。
- 进入其他下载选项。
- 选择 x64 或 Arm64。
- 运行安装程序。
- 从开始菜单打开 Grok Bot。
不知道系统架构，可以打开：
设置 → 系统 → 关于 → 系统类型
怎么注册和登录？
Grok Bot 使用 Cursor 账户登录。
第一次打开客户端后：
- 点击 Get started。
- 客户端会打开浏览器。
- 在浏览器里完成 Cursor 账户认证。
- 看到登录成功后，返回 Grok Bot。
如果使用企业 SSO，就完成所在组织的正常登录流程，不要临时换成另一个私人账户。否则你可能登录成功，却看不到组织已经购买的权限。
第一次进入时，Grok Bot 会介绍 Bot、共享云电脑和 Routine，并询问你平时使用哪些工具。
这里选中某个工具，只是在帮助它推荐第一个岗位，不代表工具已经完成连接，更不代表 Bot 已经获得那个账户的权限。
接下来，云电脑会在后台完成初始化。等它准备好以后，才开始创建第一个 Bot。
登录失败时先检查什么？
不要一上来就重装客户端。
按这个顺序检查：
- 浏览器是否真的显示 Cursor 登录成功。
- 当前账户是否包含 Grok Bot 权限。
- 企业账户是否要求 SSO。
- 是否因为 Legacy Privacy Mode 阻止云端存储。
- 客户端是否仍在等待云电脑初始化。
如果云电脑显示还在设置，先等几分钟。重置 Agent Computer 可能让最近尚未同步的工作消失，不应该当成第一个动作。
第一次打开以后，不要急着连接所有账户
一个常见错误，是安装完成后马上登录邮箱、X、Slack、网盘、CRM 和所有后台。
这会让一个还没有明确岗位的 Bot，先获得一大堆没有必要的权限。
更稳的顺序是：
先定义岗位 → 再确定它完成工作需要哪些来源 → 只连接必要工具 → 先做读取和草稿任务 → 最后才增加外部写入权限
我们现在先不登录任何敏感账户。
下一步，是看懂你即将创建的 Bot 到底由什么组成。
四、一个 Bot 到底由什么组成？
很多人打开 Grok Bot 后，会把侧边栏里的每一个 Bot 理解成一台独立电脑。
这是最危险的误解之一。
更准确的结构是：一个用户拥有一台持续存在的共享云电脑；这台电脑上可以运行多个拥有不同岗位、对话和屏幕的 Bot。
你的 Grok Bot 账户 │ ├── 一台共享云电脑 │ ├── /workspace 文件 │ ├── 浏览器登录状态 │ ├── 命令行凭证 │ └── 已安装的工具与连接器 │ ├── Radar Bot │ ├── 自己的岗位 │ ├── 自己的对话 │ ├── 自己的工作上下文 │ └── 自己的屏幕 │ └── Writer Bot ├── 自己的岗位 ├── 自己的对话 ├── 自己的工作上下文 └── 自己的屏幕
这套结构同时带来便利和风险。
便利是：Radar 已经登录的网站，Writer 在合适的情况下也能使用；Radar 保存到 /workspace 的文件，Writer 可以直接接手，不需要你来回复制。
风险是：如果一个登录或文件不应该让其他 Bot 使用，仅仅新建一个 Bot 并不能把它隔离起来。
所以记住一句话：
Bot 可以岗位分开，但不是安全边界。
Bot：谁对结果负责？
Bot 是一个持续存在的命名岗位。
它应该有：
- 一个清楚的名字。
- 一个主要工作。
- 一套稳定的判断标准。
- 明确的交付物。
- 明确的权限边界。
“万能助手”不是好岗位。
它看上去无所不能，实际上没有任何稳定责任。今天让它研究行业，明天让它管理邮箱，后天又让它修改网站，积累的上下文只会越来越混乱。
云电脑：工作发生在哪里？
Bot 的主要工作环境是一台托管云电脑，里面有浏览器、文件系统和终端。
你关闭笔记本，不会自动终止已经在云端运行的任务。Routine 也可以在设备关闭时继续执行。
但云电脑和你眼前的 Mac 或 Windows 电脑是两个不同环境。
如果 Bot 想直接访问你的本地文件或运行本地命令，还需要单独开启“Execution on Local Computer”权限。默认让本地操作逐次询问，是更安全的设置。没有明确需求时，可以直接禁止本地执行。
浏览器和连接器：它怎样使用工具？
Bot 使用工具通常有两条路。
第一条是连接器或插件。
它们提供更结构化的接口，通常比在网页上不断点击更稳定。能用连接器时，优先用连接器。
第二条是云电脑里的浏览器。
没有连接器的网站，Bot 可以像人一样打开网页和操作界面。但网页可能改版、阻止自动化、要求重新登录，或者弹出 CAPTCHA。
所以浏览器是能力补充，不是稳定性的保证。
文件：结果和交接放在哪里？
聊天消息适合讨论，文件适合交付。
一份真正可检查的工作结果，最好是：
- 带标题和来源的文档。
- 有固定列的表格。
- 包含截图和日志的文件夹。
- 一份明确没有发送的草稿。
- 一份把事实、推断、已执行动作和待批准动作分开的报告。
多个 Bot 之间需要交接时，优先使用 /workspace 里的项目文件夹，并使用清楚的文件名。
不要只让一个 Bot 对另一个 Bot 说“我弄好了”。
让它交付一个可以打开、检查和继续修改的结果。
Skill：一件事应该怎么做？
Skill 是可重复使用的工作方法。
一份可靠的 Skill 应该说明：
- 什么时候使用。
- 需要哪些输入和权限。
- 按什么顺序执行。
- 怎样判断结果正确。
- 应该返回什么。
- 哪些动作必须批准。
Skill 不是一句“帮我认真调研”。
它更像一份可以重复执行的 SOP。
Routine：谁在什么时候运行？
Routine 把一个工作流交给指定 Bot，并规定触发方式。
例如：每天上午 8 点让 Radar 执行情报 Skill；或者当某个 GitHub 事件发生时启动检查。
一句话区分：
Skill 解决怎么做，Routine 解决由谁在什么时候做。
审批：人在哪些地方重新进入？
审批不是拖慢自动化的麻烦，而是人机协作的刹车系统。
任何涉及发送、发布、购买、删除、修改权限、生产环境变更或接受法律条款的动作，都应该有清楚的审批点。
批准控制的是接下来要执行的动作，不会撤销 Bot 之前已经完成的工作。
所以不要只看“是否需要批准”，还要看批准卡片里的目标、范围和具体数值。
如果你看不懂它到底要做什么，就不要批准。先让 Bot 用人话解释，或者先生成草稿。
五、怎样从零创建第一个 Bot？
现在开始创建我们的 AI 情报 Bot：Radar。
在侧边栏选择 New，或者按 Cmd/Ctrl+N，然后选择创建新的 Agent。
你会看到三个最基本的字段：
- 名字。
- 主要工作。
- 它应该怎样工作的描述。
先填一个最小版本：
名字：Radar 主要工作：AI 行业情报 描述： 每天检查指定的 AI 产品官网、更新日志、GitHub 和 X 账号， 找出真正会影响产品能力、价格、使用方法或行业格局的新变化。 保留原始来源和发布日期，区分事实与推测。 生成情报日报，但不得自行发布、发送消息或修改任何外部系统。
这已经比“你是一个优秀的 AI 研究员”有效得多。
因为它没有花时间夸 Bot 聪明，而是说清楚了四件事：
- 负责什么结果。
- 去哪里工作。
- 怎样判断重要。
- 哪些事不能做。
先写共同宪法，再写具体岗位
当你以后拥有多个 Bot，最容易出现的问题不是分工不够细，而是它们使用了不同标准。
Radar 认为“能带来流量”最重要，Writer 认为“观点足够新”最重要，另一个 Bot 又把所有更新都当新闻。每个岗位看似认真，合起来却没有共同方向。
所以可以在 /workspace 建立一份很短的共同宪法，例如：
# 工作宪法 ## 我们追求什么 - 提供能改变实际行动的信息，而不是制造信息数量。 - 事实优先于观点，原始来源优先于转述。 - 不确定就明确说不确定。 ## 共同标准 - 所有时效信息必须记录日期。 - 所有重要判断必须能回到证据。 - 没有结果可以保持安静，来源失败必须报告。 ## 共同禁区 - 未经批准不得发布、发送、购买或删除。 - 不在普通聊天、文件或报告中保存密码和验证码。 - 不为了完成数量要求而编造或降低标准。
这份文件不是让所有 Bot 做同一件事。
它只负责统一方向、证据标准和通用禁区。
再写 Radar 的岗位说明书
一份完整岗位说明书至少需要十个部分。
下面这份可以直接复制，再替换成你自己的来源和标准：
# Radar｜AI 行业情报员 ## 1. 负责的结果 每天交付一份短而可靠的 AI 情报日报， 帮助我发现真正会改变产品能力、价格、使用方法或行业格局的新变化。 ## 2. 服务对象 这份报告服务于需要判断 AI 工具和工作流的人， 不是面向所有人的新闻摘要。 ## 3. 信息来源 - 指定 AI 产品的官网和更新日志 - 指定 GitHub 仓库的 Releases、重要 Issue 和公告 - 指定 X 账号、列表和关键词 - 指定博客、论坛和公开网页 ## 4. 来源优先级 1. 官方公告、官方文档、代码仓库和原始数据 2. 当事人或项目负责人的公开说明 3. 可信媒体和专业分析 4. 未经核实的社交媒体讨论，只能进入待确认区 ## 5. 工作方法 1. 检查时间范围内的新内容 2. 收集候选变化 3. 找到最接近事实源头的材料 4. 核验发布日期和事件发生时间 5. 与过去七天的日报去重 6. 按重要性筛选 7. 生成报告并保存文件 ## 6. 判断标准 优先保留： - 会改变用户工作方式的功能 - 会影响成本和选择的价格或套餐变化 - 会影响安全、权限或数据处理的规则变化 - 重要产品上线、关闭或战略转向 忽略： - 没有新事实的重复讨论 - 只换说法、不改能力的宣传 - 与目标读者无关的小更新 - 无法找到可靠出处的传闻 ## 7. 交付格式 每天最多五条，每条包括： - 发生了什么 - 为什么重要 - 会影响谁 - 原始来源 - 发布日期和事件日期 - 可信度或待确认状态 - 建议关注的下一步 报告结尾增加： - 今日无重要更新时的明确说明 - 无法访问的来源 - 仍然存在的冲突或疑问 ## 8. 权限边界 可以浏览、读取、整理、去重和创建报告文件。 可以生成内容草稿。 不得自行发布、发送消息、发送邮件、购买、删除或修改外部系统。 任何外部写入动作必须逐次获得批准。 ## 9. 失败处理 来源无法访问时，报告失败原因和受影响范围。 信息相互冲突时，保留冲突，不自行编造统一结论。 没有合格内容时，不得为了凑数降低标准。 任务只完成一部分时，必须明确标记已完成和未完成部分。 ## 10. 文件与交接 把每日日报保存在 /workspace/ai-intel/daily/。 文件名使用 YYYY-MM-DD-ai-intel.md。 维护一个去重索引，记录事件、原始链接和首次收录日期。 如果把日报交给其他 Bot，只能交接已经核验的事实和原始来源。
岗位说明书不是越长越好。
它的目标是让稳定规则只写一次，而不是把每一种未来情况都提前猜完。
如果一条规则只对今天有效，就放进今天的任务里；如果每次都有效，才放进岗位说明书。
这就是下面要用的三层结构：
共同宪法：所有 Bot 都遵守的方向和禁区 岗位说明书：Radar 长期负责什么、怎样判断 当前任务：这一次查什么、查多久、交付到哪里
六、平时应该怎样给 Bot 安排任务？
很多人写完岗位说明书，就开始随手发一句：“去看看今天有什么重要新闻。”
然后 Bot 找了一堆旧内容，用户又怪它不够聪明。
岗位说明书解决的是长期规则，不能替代本次任务的范围。
一条可以执行的任务，需要五个字段：
结果：最终要完成什么？ 来源：去哪里获得信息？ 限制：不能做什么？ 交付：返回什么文件或结果？ 复核点：做到哪一步必须停下来等我？
Radar 的第一次任务
不要第一天就建 Routine。
先用下面这条任务跑一次：
检查过去 24 小时内出现的 AI 产品更新。 重点查看： 1. 我指定的产品官网和更新日志 2. 指定 GitHub 仓库的 Releases 和公告 3. 指定 X 账号和关键词 只保留会改变产品能力、价格、实际使用方法、 安全边界或行业格局的内容。 每条信息必须给出原始来源、发布日期、事件发生时间， 并说明为什么值得我关注。 最多五条。没有合格内容时明确写“今日无重要更新”， 不要使用旧内容补足数量。 把结果保存到： /workspace/ai-intel/daily/YYYY-MM-DD-ai-intel.md 不要发布、不要发送邮件、不要私信任何人、不要修改外部系统。 如果需要登录、遇到 CAPTCHA、来源打不开或信息冲突，停下来告诉我。
这条任务不是完美提示词。
它只是把结果、来源、限制、交付和复核点说清楚，让第一次执行变得可检查。
工具什么时候连接？
只有 Radar 真正需要某个来源时，再去 Settings → Plugins 安装相应连接器。
例如，要稳定读取 X，可以连接 X 账户，让它搜索帖子、读取时间线、查看趋势或管理书签。当前这项集成仍在早期阶段，付费用户获得的是一部分起始 API credits，不是永久免费、无限调用的 X API。
如果没有合适连接器，再让 Bot 使用云浏览器。
登录时，Bot 可能要求你接管云电脑：
- 打开 Agent Computer。
- 点击接管控制。
- 亲自输入密码、Passkey、双重验证码，或完成 CAPTCHA。
- 确认已经进入正确账户。
- 把控制权交还给 Bot，并让它继续。
密码和一次性验证码不要发进普通聊天。
不只是因为“AI可能看到”，还因为聊天记录、复制内容和后续交接会扩大秘密的暴露范围。
用三级权限代替“全都允许”
第一层，可以直接完成：
- 浏览公开网页。
- 读取已经授权的来源。
- 整理和去重。
- 创建报告文件。
- 生成草稿。
第二层，先生成结果再等确认：
- 对外邮件草稿。
- 社交媒体内容草稿。
- 日历变更建议。
- CRM 或业务系统更新建议。
- 任何代表你表达立场的内容。
第三层，必须逐次批准：
- 发送和发布。
- 购买和付款。
- 删除或覆盖数据。
- 修改权限。
- 修改生产系统。
- 接受法律条款。
不要设置“浏览器里全部允许”这种宽泛规则。
网页会变化，按钮会变化，同一个动作在不同账户里也可能产生完全不同的后果。
审批规则应该尽可能窄：允许什么动作、作用于哪个系统、影响什么范围。
七、第一次运行，应该检查什么？
任务发出去以后，不要只等一句“已完成”。
打开 Agent Computer，看一次它实际怎样工作。
你需要观察的不是每一次鼠标移动，而是五个关键节点：
- 它是否打开了正确来源。
- 它是否把发布日期和事件日期混在一起。
- 它是否找到原始材料，而不是只引用转述。
- 它是否真的与历史日报做了去重。
- 它是否停在你规定的权限边界前。
一份合格的日报应该长什么样？
# AI 情报日报｜2026-09-02 ## 1. 某产品开放新的自动化能力 发生了什么： 用两三句话说明新事实。 为什么重要： 说明它改变了什么工作方式，而不是复述宣传语。 影响谁： 指出最直接受到影响的用户。 来源与时间： - 原始来源：URL - 发布日期：YYYY-MM-DD - 事件日期：YYYY-MM-DD 可信度：已由官方来源确认 下一步： 建议继续测试、观察或暂不行动。 ## 今日未能检查的来源 - 来源名称：失败原因 ## 待确认 - 相互冲突或无法核实的信息
第一次最常见的五种失败
第一，收录旧新闻。
Bot 看到的是今天有人重新讨论，不代表事件今天发生。
修正方式：要求同时记录内容发布日期和事件发生日期，按事件日期判断是否属于本次范围。
第二，只找到二手转述。
二手文章可以帮助发现线索，但不能自动成为事实来源。
修正方式：继续追到官方公告、更新日志、原始仓库或当事人说明。找不到就放进待确认区。
第三，同一件事重复出现。
官网、X、博客和媒体可能同时讨论一个更新。如果按链接去重，同一个事件会占满整份日报。
修正方式：按“事件”去重，不按“链接”去重。保留一个原始来源，必要时补充一个解释来源。
第四，为了凑满五条降低标准。
“最多五条”不是“必须五条”。
修正方式：把“今日无重要更新”定义为合格结果。宁可没有，也不要用噪声填满日报。
第五，来源失败却没有说明。
这最危险。报告看上去很完整，实际上可能漏掉了最重要的来源。
修正方式：在报告结尾固定增加“未能检查的来源”，写明失败原因和影响范围。
怎样纠正 Bot，而不是推倒重来？
不要只说“这份不行，重新写”。
指出可复用的错误：
第一条是旧事件，只是今天被重新转发。 以后必须分别记录发布日期和事件日期， 并以事件日期判断是否进入 24 小时范围。 第二条只有媒体转述，没有原始来源。 以后找不到官方或当事人材料时，放入待确认区， 不要列为已确认情报。 这两条属于长期规则，请更新后重新生成本次日报。
当你能明确说出“哪里错、为什么错、以后怎样判断”，Bot 才可能变得更稳定。
如果你自己也说不清什么是好结果，再强的 Agent 也只能猜。
八、怎样把一次成功变成 Skill 和 Routine？
第一次日报做对，只能证明 Radar 这一次做对了。
要让它以后重复完成，至少还要经过两步：把方法保存为 Skill，再把稳定方法交给 Routine。
顺序不能反。
单次任务 → 发现错误 → 修正规则 → 再次完成 → 保存 Skill → 换一组输入测试 → 创建 Routine
先把方法保存成 Skill
当 Radar 已经能稳定生成一份合格日报，可以这样要求它：
把刚才验证通过的流程保存成一个 Skill，名称叫“AI 情报日报”。 Skill 必须包含： 1. 适用场景 2. 必要输入和访问权限 3. 来源优先级 4. 收集、核验、去重和筛选步骤 5. 重要性判断标准 6. 日报输出格式 7. 无数据、来源失败和信息冲突的处理方法 8. 必须等待批准的动作 保存前先把 Skill 草稿展示给我检查，不要直接创建 Routine。
这里最重要的不是“保存”按钮，而是检查 Skill 有没有把一次任务中看不见的判断补齐。
例如：
- 它是否知道按事件去重，而不是按链接去重？
- 它是否区分发布日期和事件日期？
- 它是否知道找不到原始来源就降级到待确认？
- 它是否知道零条结果也是合格结果？
- 它是否知道任何外部发送都要停下来？
如果这些规则只存在于你脑子里，Skill 就只是把旧问题自动重复。
有 Teach a task，也不要把演示当成最终答案
部分用户会看到 Teach a task。你可以亲自演示一次浏览器流程，让 Bot 把操作录成 Skill 草稿。
这对路径固定、主要依赖网页点击的工作很方便。
但一次演示只能告诉它你当时点了什么，未必能告诉它：
- 为什么跳过某条信息。
- 页面打不开时怎么办。
- 两个来源冲突时听谁的。
- 什么动作必须审批。
- 怎样判断最后的报告合格。
所以演示得到的是草稿，不是免检流程。
为什么还要换一组输入再测一次？
一个流程可能只是记住了第一次的数据形状。
第一次测试只有产品更新，第二次可以加入：
- 同一事件的多个不同链接。
- 一条今天发布但事件发生在上周的内容。
- 一个无法打开的来源。
- 一条热度很高但没有原始出处的传闻。
- 一天内完全没有重要更新的情况。
如果 Skill 面对这些变化仍然能守住标准，才说明它学到的是方法，而不是答案。
最后再创建 Routine
Routine 必须写清六件事：
- 哪个 Bot 负责。
- 什么时间、什么时区运行。
- 使用什么 Skill 和输入来源。
- 结果交付到哪里。
- 哪些动作需要批准。
- 来源缺失或没有结果时怎么办。
Radar 的 Routine 可以这样写：
由 Radar 负责运行“AI 情报日报”Skill。 每个工作日上午 8:00，按照我在 Grok Bot 中设置的时区运行。 检查过去 24 小时的指定官网、更新日志、GitHub 和 X 来源。 把日报保存到： /workspace/ai-intel/daily/YYYY-MM-DD-ai-intel.md 同时在当前对话返回： - 最重要的三条变化 - 完整日报文件 - 未能访问的来源 - 等待我判断的问题 没有重要更新时，只回复“今日无重要更新”，不要补旧内容。 来源失败时明确报告，不要用历史结果代替。 不得发布、发送邮件、私信、购买、删除或修改外部系统。 任何外部写入动作必须逐次获得批准。
Test run 不是模拟运行
创建或修改 Routine 后，可以使用 Test run。
但 Test run 会真的访问网站、修改文件和调用已连接工具。它不是只给你看一遍“未来大概会做什么”。
测试前必须确认：
- 使用的是安全输入。
- 不会向真实客户或公开账号发送内容。
- 不会修改生产数据。
- 不会重复创建同一条记录。
- 外部写操作仍停在审批点。
如果一个任务重复执行两次会产生两封邮件、两条帖子或两次数据库修改，它就还不适合无人值守。
一个好 Routine 必须具备四种失败能力
第一，允许没有结果。
没有新闻就是没有新闻，不需要为了显得勤奋制造噪声。
第二，区分没有结果和没有数据。
“检查完了，没有重要更新”和“X 登录失效，所以什么都没看到”是两件完全不同的事。
第三，允许部分完成。
三个来源成功、一个来源失败，就报告成功部分和缺失部分，不要把整个任务包装成完整成功。
第四，能够安全重试。
重试不应该重复发消息、重复建文件或重复更新外部系统。能覆盖就覆盖，需要追加就先检查是否已经存在。
自动化不是让 Bot 永远不出错。
自动化是让错误变得看得见、停得住、可以重试。
九、什么时候才应该增加第二个 Bot？
一个 Bot 跑通以后，人很容易上头。
既然 Radar 能找情报，那就再建一个 Writer 写文章、一个 Publisher 发内容、一个 Manager 管理它们，再建一个 CEO 做最终决策。
几分钟后，你拥有了一家公司。
几天后，你每天都在解释它们为什么没交接好。
新建 Bot 的标准不应该是“这个角色听上去很酷”，而应该是下面四个条件至少满足一个：
- 它负责一个长期独立的结果。
- 它需要不同的工具或信息来源。
- 它需要独立、稳定的工作上下文。
- 它拥有明显不同的审批边界。
如果只是同一流程中的一个临时步骤，先用 Skill 或当前任务完成，不需要立刻新建岗位。
Radar 什么时候需要 Writer？
当 Radar 已经连续稳定交付经过核验的日报，而“把已确认情报改写成内容草稿”也变成了高频、稳定、需要独立写作上下文的工作时，才增加 Writer。
关系应该是：
共同工作宪法 │ ├── Radar │ 负责发现、核验、去重 │ └── 已核验日报文件 ↓ 人确认选题 ↓ Writer 负责写草稿 ↓ 人修改和批准 ↓ 才能发布
为什么中间要保留“人确认选题”？
因为 Radar 判断的是信息是否重要，Writer 判断的是内容怎样表达，而是否值得以你的名义公开，仍然是人的责任。
Bot 之间怎么交接？
可以通过三种方式：
- 共享文件：适合交付结构化结果。
- 群聊：适合让多个 Bot 看见讨论和分工。
- 明确转交：指定下一个 Bot、输入文件、预期结果和权限边界。
不要只说：“Radar，把这个交给 Writer。”
要说：
把今天已经核验的日报文件交给 Writer。 只允许使用“已确认”部分生成三个选题方向。 待确认内容不得写入草稿。 Writer 只生成草稿，不得发布。
交接的本质不是告诉下一个人“开始工作”，而是把输入、状态和责任一起交过去。
为什么不能把第二个 Bot 当成安全隔离？
Radar 和 Writer 可以拥有不同对话、岗位和屏幕，但它们仍然共用云电脑里的文件、浏览器会话和登录状态。
如果 Writer 不应该访问某个系统，安全做法是：
- 不给工作流连接那个系统。
- 使用权限更小的独立服务账户。
- 用外部系统本身的权限控制访问范围。
- 完成后退出登录、撤销连接并删除敏感临时文件。
“我把它放到另一个 Bot 里”不是权限控制。
什么时候需要主管 Bot？
只有当你已经有两个以上稳定岗位，而且分配、排期和交接本身开始重复时，主管 Bot 才有价值。
在那之前，主管只会制造一层新的沟通。
先把工人教会做事，再考虑经理。
十、Grok Bot 最特别的地方是什么？
Grok Bot 的很多单项能力，在其他 Agent 里都能找到。
浏览器不是它独有，定时任务不是它独有，记忆不是它独有，多 Agent 也不是它独有。
它最特别的地方，是把这些能力收进了一个容易理解的工作关系里：
你创建一个有名字的岗位，它拥有持续在线的工作环境，你通过聊天交代结果，它在网站、应用和文件之间完成工作，遇到关键动作再回来找你。
1. 它把云电脑变成了默认工作台
用户不必先准备服务器、拼接浏览器工具和调度系统，才能让 Agent 在设备关闭后继续工作。
这降低的不是模型使用门槛，而是工作流搭建门槛。
2. 它让岗位比对话更重要
普通聊天产品的中心是会话。
Grok Bot 的中心更接近岗位：这个 Bot 是谁，长期负责什么，使用哪些工具，积累什么工作上下文。
这会迫使用户从“这次该怎么问”转向“这份工作应该怎么设计”。
3. 它把跨工具交付放在产品中央
很多 AI 工具擅长给建议，Grok Bot 更强调进入真实工具完成工作。
对行政、运营、研究、内容、销售和客户支持来说，这比单纯提高回答质量更接近实际价值。
4. 它让演示、复用和定时连成一条路
你可以从一次任务开始，部分用户还可以通过演示让 Bot 学习网页流程，再把稳定方法保存为 Skill，最终交给 Routine。
它把“我偶尔让 AI 帮忙”推进成“这项工作以后由谁负责”。
5. 它把人放回关键判断点
好的设计不是要求人全程盯着，也不是让 AI 完全失控。
人退出重复操作，在发送、发布、付款、删除和生产变更前重新进入。
这才是“自动执行”和“责任仍在人”能够同时成立的方式。
十一、它目前有哪些不足？
如果只讲 Jarvis 感，不讲限制，这篇教程就会把新手带进最危险的阶段。
1. 产品仍在快速变化
套餐、额度、客户端、连接器和灰度功能都可能变化。别人截图里有的按钮，你的账户里不一定有。
使用它时必须保留一个习惯：涉及价格、权限和关键能力，先看当前账户和当前客户端，不靠旧教程猜。
2. 云浏览器不是万能钥匙
网站会改版，会限制自动化，会识别数据中心 IP，会要求重新登录，也会弹出 CAPTCHA。
今天能跑通的点击路径，下周可能失效。
能用连接器或 API 时优先使用结构化接口；只能用网页时，就把失败报告、截图、重试和审批写进流程。
3. 所有 Bot 共用同一安全边界
共享登录让交接更方便，也让权限影响范围更大。
一个 Bot 获得的浏览器会话、文件和命令行凭证，不能假定其他 Bot 看不到。
因此，最小权限、独立服务账户、定期退出登录和清理文件，比“多建几个 Bot”重要得多。
4. 它要求云端保存工作状态
如果公司政策、客户合同或数据类型不允许放入托管云电脑，这类工作就不适合直接迁移。
不要因为操作方便，把合规边界当成产品设置问题。
5. 记忆会积累，也会过期
Bot 可以保留岗位偏好和工作上下文，但记忆不能代替事实源。
价格、政策、账户状态和业务数据会变化。重要决定必须重新打开当前来源，而不是相信“它记得”。
6. Routine 会把小错误放大
一次任务引用错一条链接，影响可能有限。
每天自动运行的 Routine 如果一直沿用错误规则，会稳定地产生错误、噪声和消耗。
所以自动化以后仍然要抽查，来源或网页结构变化后必须重新测试。
7. 使用量和费用需要管理
后台运行不等于免费运行。
过于宽泛的监听、重复搜索、无意义的多 Bot 对话都会消耗额度。一个每天生成没人看的报告，不是数字员工，是自动扣费的噪声机器。
8. 复杂代码工作不一定是它的最佳战场
Grok Bot 有终端，也能处理代码任务。
但当工作中心是大型代码库、复杂测试、代码审查和工程协作时，Codex 或 Claude Code 往往拥有更自然的项目工具和工作习惯。
不要为了统一界面，放弃更适合的执行者。
十二、哪些坑会让数字员工变成数字负担？
坑一：第一天就创建一支 AI 团队
问题：岗位还没稳定，交接关系先变复杂。
正确做法：先用一个 Bot 对一个端到端结果负责。只有专业环节稳定重复后才拆分。
坑二：把岗位写成“万能助手”
问题：没有稳定目标，记忆和工具越积越乱。
正确做法：用“负责什么结果”定义岗位，不用“什么都会”定义能力。
坑三：把长期规则、本次任务和定时安排混在一起
问题：每次任务都要重复解释，临时要求又污染长期岗位。
正确做法：共同规则放宪法，稳定责任放岗位说明书，当次范围放任务，时间触发放 Routine。
坑四：先给全部权限，再决定让它做什么
问题：没有工作需要的权限，只会扩大出错范围。
正确做法：先岗位，后工具；先读取，后草稿；先批准，后外部动作。
坑五：把密码和验证码发进聊天
问题：秘密会进入聊天、复制内容和交接链路。
正确做法：接管云电脑亲自输入，完成登录后再把控制交回。
坑六：以为不同 Bot 彼此隔离
问题：它们共享云电脑、文件、浏览器会话和登录状态。
正确做法：安全隔离要依赖外部账号、权限范围和凭证管理。
坑七：第一次运行就允许发送和发布
问题：你还不知道它怎样理解目标，也不知道它会在哪一步误判。
正确做法：先让它读取、整理和生成草稿。经过多次验收后，再逐项增加外部动作。
坑八：把 Test run 当成无害预览
问题：测试可能真的改文件、访问网站和调用工具。
正确做法：使用安全输入，把所有不可逆动作留在审批后。
坑九：只规定步骤，不规定好结果
问题：Bot 可以完整执行所有步骤，却交出一份无法使用的报告。
正确做法：同时写清来源、时间、格式、质量标准和验收方法。
坑十：允许没有结果，却不区分来源失败
问题：“今天没新闻”可能只是“今天没登录成功”。
正确做法：无结果可以安静，数据源失败必须高声报告。
坑十一：没有设计重复执行
问题：重试一次就重复发信、重复发布或重复写入。
正确做法：先检查是否已经完成，同一事件使用稳定标识，外部动作默认不可重复。
坑十二：相信记忆，不检查当前事实
问题：Bot 很了解你的偏好，不代表它记得的价格、政策和账户状态仍然有效。
正确做法：偏好可以记，关键事实必须回到当前来源。
坑十三：成功时太吵，失败时太安静
问题：你每天收到大量“已完成”，真正的来源失败却埋在对话里。
正确做法：正常结果按约定格式交付；零变化保持简短；失败、冲突和待审批单独突出。
坑十四：删除 Bot，就以为一切都删除了
问题：删除 Bot 会移除它的岗位、对话和 Routine，但共享云电脑中的文件和登录状态可能仍然存在。
正确做法：同时暂停相关 Routine、退出网站、撤销连接器授权，并清理敏感临时文件。
坑十五：自动化以后从不复盘
问题：没人使用的结果会继续消耗额度，已经变化的来源会继续制造错误。
正确做法：每周检查三个问题：
这项工作还值得继续吗？ 结果真的被使用了吗？ 如果今天关闭它，我会想念什么？
没有明确价值的 Routine，暂停比优化更划算。
十三、第一次使用 Grok Bot 的最短路径
如果前面的内容太长，只收藏下面这一段也可以。
安装前
- [ ] 确认当前账户有 Grok Bot 权限。
- [ ] 确认设备受支持。
- [ ] 确认工作数据允许进入托管云环境。
- [ ] 不先连接所有账户。
创建第一个 Bot
- [ ] 只给它一个主要岗位。
- [ ] 用结果定义岗位，不用“万能”定义岗位。
- [ ] 写清来源、判断标准、交付格式和失败处理。
- [ ] 写清哪些动作不得自行执行。
安排第一次任务
- [ ] 说明最终结果。
- [ ] 说明信息来源。
- [ ] 说明限制和禁区。
- [ ] 说明交付文件或格式。
- [ ] 说明在哪一步停下来复核。
- [ ] 从读取和草稿任务开始。
验收第一次结果
- [ ] 来源是不是原始来源？
- [ ] 日期和时间范围是否正确？
- [ ] 有没有重复内容？
- [ ] 没有结果和来源失败是否分开？
- [ ] 是否明确列出未完成部分？
- [ ] 是否停在审批边界前？
保存为 Skill
- [ ] 写明什么时候使用。
- [ ] 写明需要哪些输入和访问。
- [ ] 写明执行顺序。
- [ ] 写明验证方法。
- [ ] 写明交付格式。
- [ ] 写明审批边界。
- [ ] 换一组输入再次测试。
创建 Routine
- [ ] 指定负责的 Bot。
- [ ] 检查时间和时区。
- [ ] 检查输入来源。
- [ ] 检查结果交付位置。
- [ ] 写清无数据和来源失败政策。
- [ ] 确认重试不会重复执行外部动作。
- [ ] 用安全输入执行 Test run。
每周维护
- [ ] 查看失败和暂停记录。
- [ ] 检查登录和连接器是否仍然有效。
- [ ] 抽查来源和结果质量。
- [ ] 网页或数据格式变化后重新测试。
- [ ] 暂停没有人使用的 Routine。
- [ ] 清理不再需要的登录和敏感文件。
这条最短路径可以浓缩成一句：
一个岗位，一个安全任务，一次认真验收；成功以后才保存，第二次通过以后才自动化。
结尾：要学的是怎样管理数字员工
每一次 AI 产品升级，我们都很容易盯着同一个问题：
它是不是更聪明了？
但 Grok Bot 真正提醒我们的，是另一个更重要的问题：
AI 变聪明以后，人和它的责任应该怎样重新分配？
过去，人负责操作，AI 负责建议。
现在，AI 开始拥有自己的工作环境，可以阅读、整理、执行、交接并持续运行。
人不再需要守在每一个按钮旁边。
但这不意味着人可以消失。
目标是谁定义的？
什么叫好结果？
哪些信息可以相信？
哪些风险不能接受？
哪些动作必须由人承担责任？
这些问题不会因为 Agent 有了云电脑就自动解决。
相反，AI 能执行得越多，人的目标、标准和边界就必须写得越清楚。
所以你一定要学 Grok Bot。
不是为了追一个新工具，也不是为了在侧边栏里摆满一支 AI 团队。
而是为了提前学会一种正在成为常态的工作方式：
不再亲自完成每一个动作，而是把一项完整责任交出去；不再用长提示词控制每一步，而是用岗位、制度和验收管理结果。
未来真正稀缺的，不是会不会让 AI 写一段漂亮答案。
而是能不能把一项模糊工作，变成一个目标清楚、输入可靠、边界明确、结果可验收的岗位。
最后只记住一句话：
像管理同事一样交代结果，像管理系统一样设置边界。
当你做到这一点，Grok Bot 才不只是一个更强的聊天框。
它才开始成为一个真正能工作的数字员工。