Routines：定时与事件触发的自动化（含 Webhook）
上一课把方法存成了 Skills 与示教，这一课给它加个定时器：routine 告诉一个 Bot 何时自动跑——定时（每个工作日 8 点、每 2 小时），或事件触发（Slack 消息、GitHub / Linear / Sentry / PagerDuty 事件、Bot 邮箱的新邮件、webhook 调用）。如果你搜过「Grok Bot 定时任务」，想要的大概就是这个能力。它不需要在设置面板里搭 workflow：创建 routine 的方式，就是对 Bot 说一句话。
工作流导读 的主线在这里走完最后一步：先干成一次 → 存成 skill → 再交给 routine 自动跑。官方反复强调别跳步——先把一次性任务做可靠，再自动化。
两个先记住的点：routine 在云电脑上跑，合上笔记本也不停；每次 run 都消耗每周用量池，触发范围和频率要设计，不是越多越好。
全程约 14 分钟。创建和修改在聊天里就能完成；Test 和 webhook 三字段的查看要用桌面版。
学完你能做什么
- 用一段对话给 Bot 创建定时 routine，并把官方要求的 6 项确认核对全：负责的 Bot、排程与时区、输入源、期望结果、审批边界、源缺失策略
- 让 routine 在事件发生时自动跑：Slack 消息、GitHub / Linear / Sentry / PagerDuty 事件、Bot 邮箱的新邮件、webhook 调用
- 给 routine 配 webhook：拿到 POST to / key / header 三件套，用一条 curl 触发，并知道返回 200 只代表「已受理」
- 用 Test 立即验证新 routine，不等下一个时间点（测试需要桌面版，且做的是真实工作）
- 管理与排错：暂停、编辑、删除、看 Run history，心里有每 Bot ≤50 个、间隔 ≥5 分钟、每小时 300 / 200 次的限额账
你现在的困境
- 「每天早上都要手动发一句『帮我汇总昨天的工单』，忘了发就没有简报」——任务做对了，但每天还得人肉触发
- 「想让 Bot 在 Slack 有人喊 needs repro 时自动开工，不知道从哪配起」——触发条件在你脑子里，没变成 Bot 的排程
- 「设了个每小时跑的 routine，一周用量两天就见底，还总撞速率限制」——自动化跑起来了，但没算过用量和限额的账
什么时候用这一招
当你需要：
- 把已经跑通（最好已存成 skill）的任务，交给 Bot 定时或按事件自动执行
- 让外部系统（CI、监控告警、表单服务、你自己的脚本）用一个 HTTP 调用唤起 Bot
- 合上笔记本之后任务照常进行——routine 在云电脑上跑，不依赖你的电脑开机
而且不想：
- 每天手动发同一句指令
- 用第三方调度工具加脚本自己拼一套定时系统
- 把没验证过的流程直接放去自动跑
🎒 开始前的准备
- 完成了 Skills 与示教：把成功任务存成可复用技能——官方顺序是先跑通一次性任务、存成 skill，最后才自动化；这一课直接消费那个成果
- 手头有一个想自动化的任务，而且至少手动跑对过一次（还没跑对？先回上一课）
- 任务需要的应用已连接（Slack、Gmail、日历等）——事件触发的集成连在拥有这个 Bot 的 Cursor 账号上
- 桌面版在手边——Test 和 webhook 三字段在桌面 app 查看；手机能看 Run history、暂停、删除，但测试要桌面版
- 知道自己的每周用量池怎么看（订阅与价格）——每次 run 都花用量
核心思路
routine 只回答一个问题：这个 Bot 何时自动跑。跑什么，来自它的 Instruction——通常就是上一课存好的 skill，或一段写清楚的流程。
| 回答什么 | 例子 | |
|---|---|---|
| skill | 怎么做 | 「周度客户健康检查」的步骤与边界 |
| routine | 何时做 | 「每个工作日 8:00 跑一次」 |
一句话记住：skill 是菜谱，routine 是闹钟。
五种触发方式（都写在 routine 的 When to run 里）：
| 触发方式 | 什么时候跑 |
|---|---|
| 定时 schedule | 按你说的排程：every weekday at 8:00 AM、every 2 hours |
| Slack 消息 | Bot 被提及、某个词或短语出现、你回应表情、或任何消息；可盯一个频道或整个 Slack |
| 工具事件 | GitHub、Linear、Sentry、PagerDuty 的事件，如 When a Linear issue is created |
| 邮件 | 发到 Bot 专属邮箱的新邮件；可按发件人或整个域过滤，不能按主题 |
| Webhook | 任何系统向 routine 的 URL 发一个 HTTP POST |
三条设计原则，后面每一步都会用到：
- 先窄后宽：触发范围越窄越好——官方明确说宽监听（比如「每条新消息」）制造噪音、消耗用量、还容易对无关输入采取行动。
- 先准备后执行：让 Bot 先草拟、核对、建议；发送、购买、删除、发布、改生产系统这类有后果的动作留在审批后面。
- 想好失败怎么办：源数据缺失时用什么策略（报错，而不是拿旧数据硬算）——这是创建时官方要求确认的 6 项之一。
💡 事件触发走 Cursor 账号集成
Slack、邮件这类事件由 Cursor account integrations 启动，它们和 Slack、GitHub 的连接应用是分开的，可能需要各自连接。依赖 Slack 触发之前，先在拥有这个 Bot 的 Cursor 账号上把 Slack 连好。
跟我做
第 1 步：用一段对话创建 routine（Grok Bot 定时任务）
为什么：Grok Bot 的设置哲学是「设置是一条消息，而不是 workflow builder」——routine 也一样，在聊天里对应该负责的 Bot 说清楚就行。
对拥有这项工作的 Bot 说。官方示范：
Every weekday at 8:00 AM, run the Daily customer-risk skill against the current account list. Post a linked watch list in this conversation. Do not contact customers. If the source data is unavailable, report the failure instead of using old data.
（每个工作日早上 8:00，对当前客户列表跑 "Daily customer-risk" 这个 skill，把带链接的关注清单发到这个对话里。不要联系客户。如果源数据不可用，报告失败，不要用旧数据。）
这句示范的密度值得照抄：时间（工作日 8:00）、跑什么（按名字点 skill）、输入（当前客户列表）、结果去哪（本对话）、审批边界（不联系客户）、失败策略（报错不用旧数据）——一口气覆盖六件事。
Bot 创建后，逐项核对官方要求的 6 项确认：
| # | 确认项 | 自查 |
|---|---|---|
| 1 | 负责的 Bot | 是不是你正在对话的这个 Bot |
| 2 | 排程与时区 | 时间对不对；时区下一步核对 |
| 3 | 输入源 | 数据从哪来 |
| 4 | 期望结果 | 产出长什么样、发到哪 |
| 5 | 审批边界 | 哪些动作必须停下来等你 |
| 6 | 源缺失时怎么办 | 报错还是跳过——别让它拿旧数据硬算 |
手机上也可以创建：打开 Bot 的 profile，在 Routines 下点 Add routine——Grok Bot 会起一条以 "Set up a routine to" 开头的消息，把这句话补完发送即可。
你应该看到：Bot 确认创建，routine 出现在这个 Bot 的 routines 列表里（桌面版：点聊天顶部的 Bot 名字 → Details 标签）。
- 6 项确认全部对上，特别是审批边界和失败策略
第 2 步：核对 When to run：时间、时区与触发条件
为什么：自然语言排程好写也好错——「每天 8 点」到底是你的 8 点还是别的时区的 8 点，写错了 routine 会在错误的时间跑一整周。
排程用大白话说就行，比如 every weekday at 8:00 AM 或 every 2 hours。然后打开 routine 检查 When to run——它用文字显示保存下来的排程，和你的本意对不上就选 Edit，告诉 Bot 改哪里。
时区在这里设：Settings → Bot → Timezone。
| 选项 | 行为 | 什么时候用 |
|---|---|---|
| Auto-detect | 跟随这台电脑 | 你在哪，routine 就按哪的时间跑 |
| 手动选一个时区 | 固定下来 | 工作属于另一个时区的办公室时 |
最容易踩的时间坑：新建的 routine 不会立即跑。它等下一个排程时间点——8:05 创建「每天 8:00」的 routine，第一次运行是明天 8:00。想马上验证，用下一步的 Test。
你应该看到：When to run 显示的排程文字与你的本意一致，时区正确。
- When to run 的文字排程与你的本意一致
第 3 步：用 Test 立即验证，不等下一个时间点
为什么：等到明天 8 点才发现 routine 跑错了，浪费一整天；Test 让你现在就看结果。
在桌面版打开 routine，选 Test（测试 routine 需要桌面 app，手机端没有）。
你应该看到：
- 按钮显示 Running… 直到跑完，结果出现在 Bot 的聊天里
- 测试无法启动时，你会看到 Couldn't start a test run，或一条说明原因的消息
有些 routine 不显示 Test——它们照样按排程或触发运行；这类就让 Bot 在聊天里用一份安全输入把同样的工作做一次。
⚠️ Test 做的是真实工作
测试运行会真的浏览网站、改文件、调用已连接的工具。用安全输入，把写操作留在审批后面。
跑完按官方清单检查 5 件事：
- 选的是当前输入，不是旧数据
- 输出符合要求的格式
- 每个动作都有来源或审计痕迹
- 停在了预定的审批点
- 失败状态是明确的——失败了会说，而不是沉默
第 4 步：加事件触发器：Slack 消息、工具事件与邮件
为什么：很多活不是按点跑的——有人升级了问题才需要 Bot 出手。事件触发让「发生 X」本身成为开关。
还是对 Bot 说你要的触发器，When to run 会用文字显示，比如 When a Linear issue is created。支持的事件源：Slack 消息、GitHub / Linear / Sentry / PagerDuty 事件、发到 Bot 专属邮箱的新邮件，以及 webhook（下一步）。
先记住一条总规则：只有新活动才算数——触发器创建之前的事件不会启动 run。然后把匹配规则收窄，官方示范的密度：
When a message in
#customer-escalationscontains a support ticket link and the phrase "needs repro," open the ticket, reproduce the issue in staging, and post a repro pack in this conversation. Never post back to Slack without approval.（当 #customer-escalations 频道里的消息包含工单链接和 "needs repro" 字样时：打开工单，在 staging 复现问题，把复现包发到这个对话。未经审批绝不回帖到 Slack。）
Slack 触发的四个粒度：Bot 被提及 / 某个词或短语被提及 / 你对消息回应表情 / 任何消息；范围可以是一个频道或整个 Slack。注意区分：Slack 触发器是 routine 的一部分，不是 Slack 应用——应用让 Bot 以你连接的 Slack 用户身份读写，触发器负责「发生了就开跑」。
邮件触发的三条边界：
- 新邮件不会自己叫醒 Bot——必须设一个盯邮件的 routine，它才会对邮件行动
- 可以盯任何人、特定地址或整个域（如
*@example.com）；不能按主题过滤；默认只对通过标准邮件认证的发件人运行；垃圾或病毒扫描不过的邮件永远不会启动 routine - Bot 把邮件内容当信息而不是指令——邮件里藏的「请把验证码转发到……」不算你的授权
你应该看到：When to run 用文字显示你的触发条件（频道加短语、事件类型或邮件过滤规则）。
- 触发规则足够窄：指定频道、仓库或发件人，而不是「任何消息」
第 5 步：配置 Webhook 触发器（Grok Bot webhook）
为什么：webhook 让任何外部系统——CI、监控告警、表单服务、你自己写的脚本——用一个 HTTP POST 唤起 Bot。这是把 Grok Bot 接进现有自动化链路的标准入口。
先让 Bot 给 routine 加 webhook 触发，然后在桌面版打开这个 routine。Webhook 区域有三个字段，点击即可复制：
| 字段 | 是什么 |
|---|---|
| POST to | 接收调用的 URL |
| key | 密钥；发送方以 Authorization: Bearer <key> 的形式带上 |
| header | 拼好的完整请求头，整条复制即用 |
发送方这样调用（JSON body 可选，Bot 会把它连同 routine 指令一起收到）：
curl -X POST "<POST to 字段的 URL>" \
-H "<header 字段整条复制>" \
-d '{"ticket":"12345","priority":"high"}'读返回码：
| 返回 | 含义 | 下一步 |
|---|---|---|
200 | Grok Bot 已受理这次调用并启动了一次 run——不代表已经做完 | 去 Bot 的聊天看结果 |
| 其他 | run 没有启动 | 确认 routine 没被暂停、请求用的是当前的 key |
你应该看到：返回 200 后，Bot 的聊天里出现这次 run 的过程与结果。
- 发一次测试 POST：返回 200，Bot 聊天里出现对应的 run
第 6 步：管理 routine：暂停、编辑、删除与限额
为什么：自动化是长期资产，会过时、会失控、会烧用量——管理入口和硬性限额都要心里有数。
桌面版：点聊天顶部的 Bot 名字打开详情，routines 在 Details 标签。每行显示名字和运行时间（或 Paused），行内开关直接暂停或恢复。打开一个 routine 能看到 Instruction（每次 run 做什么）和 When to run（排程与触发事件）；webhook 启动的还会显示 Webhook 区域。底部按钮：
| 按钮 | 作用 |
|---|---|
| Pause / Resume | 暂停 / 恢复 |
| Test | 立即跑一遍（有的 routine 提供） |
| Edit | 起一条以 "Edit your routine:" 开头的消息，补上要改的内容发送 |
| Delete routine（垃圾桶图标） | 删除，需确认；不可撤销，未来的 run 全部停止 |
右键 routine 同样能 Pause / Resume、Test、Edit、Delete。Bot 还没有 routine 时，列表显示 Ask in chat to set a routine。
手机版：Bot 的 profile → Routines。点开能看到 Active、Schedule、Next run、Instruction 和 Run history；关掉 Active 即暂停，滑动一行即删除。Run history 把每次 run 标为 Running / Succeeded / Failed，失败的带原因；No runs yet 表示还没任何东西启动过它。
硬性限额与记录：
| 限额项 | 数值 |
|---|---|
| 每个 Bot 的 routine 数 | 最多 50 个 |
| 排程间隔 | 至少 5 分钟 |
| 速率：你所有 routine 合计 | 每小时最多 300 次 |
| 速率：单个 routine | 每小时最多 200 次 |
| Run 记录 | 每个 routine 保留最近 20 条 |
超速的 run 会以 Automation run rate limit exceeded 失败。另外，删除 Bot 会连带删除它拥有的 routines。
还有一条容易被忽略：长时间没人使用后，Grok Bot 可能会问你是否保持 routine 运行，不回应就可能暂停它们——回来时记得检查被暂停的 routine。
你应该看到：你能三步找到任何一个 Bot 的 routine 列表，并说出它下次什么时候跑。
检查点 ✅
- 你能用一句话创建 routine，且 6 项确认（负责 Bot / 排程与时区 / 输入源 / 期望结果 / 审批边界 / 缺失策略）都对得上
- 知道新建的 routine 等下一个时间点才首跑；验证用桌面版的 Test，且测试做真实工作
- 事件触发规则够窄，且知道只有触发器创建之后的新活动才算数
- webhook 三字段（POST to / key / header）能配能调；200 = 已受理 ≠ 已完成
- 心里有限额账：每 Bot ≤50 个、排程间隔 ≥5 分钟、每小时合计 300 次 / 单个 200 次
踩坑提醒
❌ Webhook 返回 200 就认为任务完成了
现象：你的系统收到 200，标记「已处理」，结果 Bot 那边其实还在跑，甚至没做完预期的动作。
原因：200 的含义是 Grok Bot 接受了调用并启动了一次 run，不是 Bot 完成了指令。
正确做法：把 200 当「已受理」，结果去 Bot 的聊天里确认。非 200 才是没启动——查 routine 是否被暂停、key 是否是当前的。
❌ 撞上 Automation run rate limit exceeded
现象：routine 频繁失败，Run history 里的原因写着 Automation run rate limit exceeded，但你算了算自己的频率好像没超。
原因：两个可能。真超了——所有 routine 合计每小时 300 次、单个每小时 200 次；或者撞上了所有 Grok Bot routine 共享的一个限额——官方已确认这是已知问题，你自己的频率不高也可能被误伤。
正确做法：真超了，让 Bot 收窄触发器或放宽排程；被共享限额误伤的，等一等再跑。失败的 run 不会自动重试——自己用 Test 重跑，webhook 的就把调用重发一次。
❌ routine 的审批卡 30 分钟没人理，动作悄悄没做
现象：早上看 routine 的成果，发现最后一步没执行，聊天里躺着一张 Expired 的卡。
原因：你在聊天里发起的工作，审批卡会一直等你；但 routine、触发器或别的后台工作唤起的卡，30 分钟后过期，过期后那个动作不会执行。
正确做法：给跑 routine 的 Bot 打开 Notifications；对信得过的动作选 Always allow 存成规则；过期了就让 Bot 把任务再试一次。边界怎么划，见 审批与 Auto Review。
❌ 用量烧得比想象快
现象：周一还剩大半的每周用量，周二就见底了。
原因：每次 run 都花用量。每小时一跑、很短的间隔、或繁忙频道上的 Slack 触发，一天能烧掉一周的用量。从不运行的 routine 不花钱，但 Test 花——它真的干活。
正确做法：先暂停不需要的 routine，再让 Bot 放宽排程、收窄 Slack 触发；这些都做了还不够，才考虑升计划或调 on-demand 限额。用量池口径见 订阅与价格。
进阶技巧（可选）
给 routine 补一套「信任设计」。官方为自动化给了 7 条信任原则，创建前照着过一遍：
| # | 原则 | 一句话版 |
|---|---|---|
| 1 | 先自动化准备，再自动化执行 | 汇总、草拟先上；发送、变更后上 |
| 2 | 让 Bot 先草拟、核对、建议 | 产出可审阅的东西，而不是直接动手 |
| 3 | 发送、购买、删除、发布、改生产系统必须审批 | 后果大的动作留在审批后面 |
| 4 | 写清无数据与陈旧数据策略 | 没数据就报错，别拿旧数据硬算 |
| 5 | 重试尽量幂等 | 重跑一次不会造成两次副作用 |
| 6 | 告诉 Bot 部分完成时向哪报告 | 半成品要可见 |
| 7 | 网站、应用或源格式变了就重测 | 自动化会悄悄过时 |
没跑起来时按官方清单排查。先查 6 项：
- 没被 Paused（手机上 Active 开着）
- When to run 的排程和时区符合预期
- 拥有它的 Bot 还在
- 需要的插件仍处于已认证状态
- 云电脑能连上源系统
- 用量或账户访问没被暂停
事件触发的再确认源频道、仓库和匹配规则仍然有效。都没问题却 24 小时以上没跑也没报错？带上 Bot 名字和 routine 详情报告 bug。更多报错对照见 报错速查。
邮件加 routine，就是免值守的收件处理线。把收件规则（按发件人或域）设成 routine 触发，Bot 邮箱收到的账单、通知就能自动归档汇总；而 routine 发出的邮件一律存草稿等你 Send，没有无人值守发送。完整玩法见 Bot 专属邮箱 和 邮件简报实战。
本课小结
✅ Grok Bot 定时任务的创建方式是一段对话：对负责的 Bot 说清时间、跑什么、输入、结果去向、审批边界和失败策略，再核对 6 项确认。
✅ 排程用自然语言说；时区在 Settings → Bot → Timezone（Auto-detect 跟随本机）。新建的 routine 等下一个时间点才首跑，验证用桌面版的 Test——测试做真实工作。
✅ 事件触发覆盖 Slack 消息、GitHub / Linear / Sentry / PagerDuty 事件、Bot 邮箱新邮件和 webhook；只有新活动算数，规则宁窄勿宽。
✅ Webhook 三字段：POST to（URL）、key（Authorization: Bearer）、header（整条复制）；返回 200 = 已受理并启动 run，不等于已完成。
✅ 限额账：每 Bot ≤50 个 routine、排程间隔 ≥5 分钟、每小时合计 300 次 / 单个 200 次、保留最近 20 条 run 记录；失败的 run 不自动重试。
关键位置速查：
| 字段 / 位置 | 用法 |
|---|---|
| Settings → Bot → Timezone | 排程时区；Auto-detect 跟随本机 |
| routine → When to run | 文字显示排程与触发；对不上就 Edit |
| routine → Webhook | POST to / key / header 三字段，点击复制 |
| Bot 详情 → Details → Routines | 暂停 / 恢复、Test、Edit、Delete |
| 手机 Bot profile → Routines | Active 开关、Run history、滑动删除 |
下一课预告
routine 会跟着 Bot 走。下一课把配置好的 Bot 打包送人：Bot 模板：把配置好的 Bot 分享给团队。
你会学到：
- Share → Create a copy → Publish → Copy link，四步把 Bot 发布成模板
- 公开链接会暴露 identity、description、skills 和 routines——发布前先检查
- 团队关闭模板分享时的两条报错原文与对策
- 从 Connect apps → Bot templates 进入模板库