推送示例库

# 推送示例库

本文件是 SKILL 文档的附属参考。组装推送内容前来这里找最接近的场景，照着骨架改；不需要一次性读完，也不用预加载。

# 怎么用

用户偏好优先于本文件的所有示例。 如果用户说过自己的推送偏好（要不要 emoji、单条还是多条、标题格式、要不要表格、是否要分通道），按用户说的执行；本文件的示例只用来补他没提到的部分。这与 SKILL.md 文首的「优先级总则」是同一条规则。

先判给谁 → 数据要进你的业务系统（落库 / 入库 / 触发下游）看第 1 节，那里是 JSON + 零 emoji；给人看的通知看第 2 节及以后。这一步做错，后面全白做。
定位场景 → 在目录里找最接近的一节。
套骨架 → 保留分区标题和 emoji 结构，只替换里面的具体数值。
必查三件事：head 是不是「结论 + 一个 emoji」（webhook 则是纯文本批次标识）；body 有没有分区或是不是合法 JSON；有没有给「下一步」。

不要整段照抄示例。示例里的域名、金额、耗时都是占位数据，照抄会推送假信息。

# 长度参考

平台	标题可见上限	正文可见上限
iOS	~25–50 字符	~150 字符
Android	~65 字符	~240 字符
Web push	~30–50 字符	~80–120 字符

head 字段本身允许 200 字符，但超过 30 字符就会被截断。做法：标题自带结论和关键数值，正文展开。反例「2026 年 10 月 3 日的每日签到任务已经顺利完成了哦」；正例「🎉 签到成功：积分 +10」。

# 通用骨架

head: <emoji> <结论>：<关键数值>
body: ## <分区标题>
      - <结果符/状态灯> **<标签>**：<值>
      ...
      ## 📌 下一步
      1. <动作>

1
2
3
4
5
6

三类注入需要根据严重程度切换 head 的 emoji：正常 🎉 / 🟢，注意 ⚠️ / 🟡，阻断 💣 / 🔴。

# 目录

先看第一列：「给机器」还是「给人」。 走错分支等于白推——给机器的数据加了 emoji 会 JSON.parse 失败，给人看的 Markdown 塞进业务库会污染字段。

#	场景	典型 head
—	机器读：`body` = JSON，零 emoji	—
1	Webhook：结构化数据入库（商品 / 线索 / 监控 / 舆情）	批次标识，无 emoji
—	人读：`body` = Markdown，head 加 emoji	—
2	网站签到 / 打卡 / 权益领取	🎉 / 💣
3	数据采集 / 网页变更监控	📥 / 👀
4	服务器与站点监控	🟢 / 🔴
5	定时任务 / 备份 / CI 构建	🤖 / 💣 / 🚀
6	AI 长任务完成汇报	🤖 / 🎉
7	表格报告（单条）/ 批量采集（多条）	📊 / 🎉 + N 条
8	订单 / 物流 / 价格库存	📦 / 🚚 / 💰
9	行情 / 账单 / 余额	📈 / 💰 / ⚠️
10	生活服务：快递 / 出行 / 天气 / 挂号	🎫 / ✈️ / 🌤️ / 🏥
11	账号安全事件	🔒 / 🔑
12	周期汇报：日报 / 周报	📊 / 📅
13	反例对照	—

# 1. Webhook：结构化数据入库（机器读）

这一节排在最前面是有意为之：动手之前先分岔。 push-server 有两类完全不同的用法，走错分支等于白推——给机器的数据加了 emoji 会 JSON.parse 失败，给人看的 Markdown 塞进业务库会污染字段。

两类用法

	机器读（本节）	人读（第 2 节起）
通道	webhook 类通道（`web_hook_push`）	浏览器 / IM / 邮件等
`body`	一整段合法 JSON 字符串	Markdown
emoji	零个（`head` 也不加）	head 一个 + body 按规范
终点	你的商品库、线索库、工单表、时序库	人的通知栏

商业价值最高的一类用法就在这节：不是「发个通知」，而是把 AI 的产出变成业务系统里的一条数据——AI 负责采集、清洗、结构化，push-server 负责把结构化结果原样 POST 到你自己的接收接口，落库、进仓、触发下游流程。人到人的通知只是它的副产品。

格式铁律：

项	规则
`head`	纯文本批次标识，如 `采集批次 2026-10-03T10:32`。它常被接收端当索引或去重键入库，加 emoji 等于毁掉唯一性
`body`	裸 JSON 字符串：合法可 `JSON.parse`、不包 Markdown、不包代码块围栏、不含任何 emoji
通道	必须是 webhook 类型通道码，别混用浏览器 / IM 通道
上限	≤50000 字符，超量拆批推或改推索引

怎么判断走哪条：看接收方是 JSON.parse 还是人的眼睛。用户没明说时，默认走人读版。

# 1.1 商品采集 → 商品库入库

{
  "head": "采集批次 2026-10-03T10:32",
  "body": "{\"batchId\":\"20261003-1032\",\"source\":\"shop.example.com/new\",\"collectedAt\":\"2026-10-03T10:32+08:00\",\"total\":48,\"items\":[{\"sku\":\"SKU1001\",\"name\":\"降噪耳机\",\"price\":899,\"stock\":132},{\"sku\":\"SKU1002\",\"name\":\"机械键盘\",\"price\":459,\"stock\":3}]}"
}

1
2
3
4

要点：字段名对齐你的表列名；金额用数字类型不是字符串，否则入库后没法聚合；建议必带 collectedAt 和 batchId，否则无法增量、无法去重，重推一次数据翻倍。

# 1.2 线索名单采集 → CRM 入库

{
  "head": "线索批次 2026-10-03 华东制造",
  "body": "{\"batchId\":\"lead-20261003-01\",\"region\":\"华东\",\"collectedAt\":\"2026-10-03T11:05+08:00\",\"leads\":[{\"name\":\"宁波xx精密机械\",\"contact\":\"王先生\",\"hash\":\"sha256:9f2c\",\"intent\":82},{\"name\":\"苏州xx自动化\",\"intent\":64}]}"
}

1
2
3
4

要点：联系人这类敏感字段只推哈希或脱敏值，不要出现明文手机号 / 邮箱（见 SKILL.md 安全红线）；每条数据建议要带唯一业务键（batchId 或 sku / 公司名），接收端才能幂等去重。

# 1.3 批量采集 → `send_multi_message` 分源入库

这是 send_multi_message 最正当的用法：N 个采集源，每个源一条独立记录，各自入库各自的库表或走各自的 webhook 通道。

{
  "channelCode": "11111111111111111111111111aaaaaa",
  "messages": [
    {
      "head": "采集批次 site-a 2026-10-03",
      "body": "{\"site\":\"site-a\",\"batchId\":\"20261003-a\",\"collectedAt\":\"2026-10-03T10:32+08:00\",\"ok\":true,\"total\":48,\"items\":[{\"sku\":\"A1\",\"price\":19.9}]}"
    },
    {
      "head": "采集批次 site-b 2026-10-03",
      "body": "{\"site\":\"site-b\",\"batchId\":\"20261003-b\",\"collectedAt\":\"2026-10-03T10:33+08:00\",\"ok\":true,\"total\":12,\"items\":[{\"sku\":\"B1\",\"price\":88}]}",
      "channelCode": "22222222222222222222222222bbbbbb"
    }
  ]
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14

要点：失败的源也要推结构化记录，不能只推成功的——业务侧要靠它做任务对账和配额统计。

# 1.4 探测数据 → 监控 / 时序入库

{
  "head": "uptime probe 2026-10-03T13:00",
  "body": "{\"target\":\"api.example.com\",\"checkedAt\":\"2026-10-03T13:00+08:00\",\"code\":200,\"rt\":312,\"healthy\":true,\"checks\":[{\"type\":\"http\",\"ok\":true},{\"type\":\"dns\",\"ok\":true}]}"
}

1
2
3
4

# 1.5 内容与舆情批次 → 内容库入库

{
  "head": "舆情批次 2026-10-03 品牌词 24h",
  "body": "{\"keyword\":\"xx品牌\",\"window\":\"24h\",\"collectedAt\":\"2026-10-03T12:00+08:00\",\"items\":[{\"title\":\"xx品牌服务调整公告\",\"sentiment\":\"negative\",\"hot\":78},{\"title\":\"xx品牌发布新品\",\"sentiment\":\"positive\",\"hot\":52}]}"
}

1
2
3
4

# 1.6 五个高频踩坑

body 里包了 Markdown 代码块围栏（三个反引号 + json）→ 接收端 JSON.parse 直接失败。必须是裸字符串。
数字写成字符串（"price": "899"）→ 入库后不能求和分档，除非对方列就是字符串。
缺 batchId / collectedAt → 无法增量去重，重推一次数据翻倍。
emoji 或换行装饰混进 JSON 字段值 → 排序错位、唯一键失效，部分库直接报错。
单条超过 50000 字符才拆批 → 超量前就该拆；大对象建议存对象存储，只推索引。

想看同一批数据给人看时的样子，见第 3 节（数据采集 / 网页变更监控）——同样一份采集结果，两条路的写法完全不同。

# 2. 网站签到 / 打卡 / 权益领取

国内自动化最高频的一类（签到脚本、网盘扩容、会员签到），每天都会推，所以越短越好——推长了三天就会被静音。

成功：

{
  "head": "🎉 签到成功：积分 +10",
  "body": "## 🟢 签到结果\n- ✅ **站点**：example.com\n- ✅ **本次奖励**：+10 积分\n- 📊 **当前积分**：325\n- 🏆 **连续签到**：100 天\n- 🕐 **执行时间**：2026-10-03 09:14\n\n> 🎯 再坚持 5 天解锁「百日打卡」徽章"
}

1
2
3
4

重复签到（今天签过了，不算失败也别报成功）：

{
  "head": "🟡 今日已签到，无需重复执行",
  "body": "- ⚪ **本次动作**：跳过（当日已签到）\n- 🏆 **连续签到**：99 天，纪录保持中\n- 📊 **当前积分**：315",
  "url": "https://example.com/user/sign"
}

1
2
3
4
5

失败（登录态失效是这个场景最主要的失败模式）：

{
  "head": "💣 签到失败：登录态已失效",
  "body": "## ❌ 失败详情\n- ❌ **站点**：example.com\n- ❌ **失败原因**：Cookie 失效，请求被重定向到登录页\n- 🕐 **执行时间**：2026-10-03 09:14\n\n## 📌 需要你处理\n1. 🔑 更新站点登录凭据后我重新执行\n2. 🔍 确认是否触发了平台验证码风控\n\n> 🔒 凭据原文不会写入推送内容"
}

1
2
3
4

要点：绝不在推送里出现 Cookie / Token / 密码原文（见 SKILL.md 安全红线）。签到类消息通常每天推，成功后一句 > 引用就够了，别写成长报告。

# 3. 数据采集 / 网页变更监控

给你自己看（Markdown + emoji）；要落库 / 进业务系统的话，改看第 1 节的 webhook JSON 写法——同一批数据，两条路格式完全不同：

{
  "head": "📥 商品列表采集完成：共 48 条",
  "body": "## 🟢 采集概览\n- ✅ 成功 **48** ｜ ❌ 失败 **2**\n- 🌐 shop.example.com/new ｜ 🕐 12.4s\n\n## 📋 预览（前 2 条）\n1. **无线降噪耳机** ｜ ¥899 ｜ 🟢 充足\n2. **机械键盘** ｜ ¥459 ｜ 🟡 仅剩 3 件\n\n> 📦 要入库？改走第 1 节的 JSON 写法",
  "url": "https://example.com/collect/2026-10-03"
}

1
2
3
4
5

网页变更监控（有变更才推，无变更不要推）：

{
  "head": "👀 目标页面已更新",
  "body": "## 🔔 变更摘要\n- 🌐 **页面**：example.com/pricing\n- 📝 **区块**：价格表（企业版 ¥1,999 → ¥2,299）\n- 🕐 **检测于**：10-03 11:20（上次无变化）\n\n## 📌 下一步\n1. 🔗 查看 diff 快照",
  "url": "https://example.com/diff/9f2c"
}

1
2
3
4
5

要点：head 带条数，不用点开就知道规模；明细超过 5 条时只放预览 + 「… 其余 N 条同结构，略」。另外 Markdown 表格要慎用：接收端用 showdown 渲染 body，若未开启 tables 扩展，表格会被当成纯文本输出，这种情况改用「有序列表 + ｜分隔」更稳。

# 4. 服务器与站点监控

可用性巡检（正常）：

{
  "head": "🟢 巡检通过：api.example.com",
  "body": "## 🟢 监控状态\n- 🟢 **状态码**：200 ｜ **响应**：312ms（阈值 1000ms）\n- 🟡 **证书剩余**：68 天，建议尽早续期\n- 🌐 api.example.com ｜ 🕐 10-03 13:00\n\n## 📊 近 24 小时\n- ✅ 可用率 99.8%\n- 🟡 12:07 出现 1 次 1.2s 慢响应"
}

1
2
3
4

探测失败：

{
  "head": "🔴 探测告警：目标不可达",
  "body": "## ⚠️ 告警详情\n- 🏷️ **探测**：liveness（HTTP GET /）\n- 🔴 **等级**：服务不可用\n- 🔴 **失败项**：连接超时 >5s，连续 3 次\n- 🟢 DNS 解析正常\n\n## 📌 处置建议\n1. 🔍 检查安全组 / 防火墙\n2. 🧪 curl -I https://api.example.com 复现\n3. 📣 10 分钟未恢复则升级",
  "url": "https://grafana.example.com/d/uptime"
}

1
2
3
4
5

证书 / 域名到期（分级推送，越临近越频繁）：

{
  "head": "⚠️ 证书将在 7 天后过期",
  "body": "## 🟡 到期提醒\n- 🌐 **域名**：www.example.com:443\n- 🔴 **剩余**：7 天（10-10 到期，阈值 30 天）\n- 🛠️ **签发方**：Let's Encrypt\n\n## 📌 下一步\n1. ♻️ 执行 certbot renew 续期",
  "url": "https://example.com/monitor/certs"
}

1
2
3
4
5

服务恢复（告警闭环的一部分，别漏）：

{
  "head": "🎉 服务已恢复",
  "body": "- 🟢 api.example.com 已于 13:11 恢复，响应 420ms\n- ⏱️ **中断时长**：9 分 12 秒\n- 📉 **可用率影响**：本次事件 -0.6%\n\n> ♻️ 建议复盘超时根因，避免再次触发"
}

1
2
3
4

要点：巡检类消息把状态灯直接放进 head（🟢 / 🔴），因为「正不正常」就是唯一关键信息，比用 🤖 更快传达。只有正常态可以不推，异常态必须推；否则用户会默认「没消息 = 正常」，真出事时也没人看。

# 5. 定时任务 / 备份 / CI 构建部署

定时备份：

{
  "head": "💾 数据库备份完成：4.2 G",
  "body": "## 🟢 备份结果\n- ✅ **数据量**：4.2 G（较昨日 +180M）\n- ✅ **耗时**：6 分 12 秒\n- 🗂️ backup-2026-10-03.sql.gz → S3\n\n> 🧹 已清理 30 天前旧备份 3 份"
}

1
2
3
4

备份失败（比成功重要得多）：

{
  "head": "💣 备份失败：磁盘空间不足",
  "body": "## ❌ 失败详情\n- ❌ **任务**：db-daily-backup\n- ❌ **失败步骤**：导出阶段\n- ❌ **原因**：目标目录剩余 1.2G，不足所需 5G\n- 🔴 **影响**：今日无可用备份\n\n## 📌 下一步\n1. 🧹 清理旧备份或使用更大存储\n2. ♻️ 修复后立即手动补跑一次",
  "url": "https://example.com/jobs/db-daily-backup"
}

1
2
3
4
5

CI 构建失败：

{
  "head": "💣 构建失败：单测未通过 3 项",
  "body": "## ❌ 失败用例\n- ❌ `UserServiceTest#login` 断言超时\n- ❌ `OrderServiceTest#refund` 空指针\n- ❌ `PayServiceTest#callback` 签名校验失败\n- 🟢 其余 125 项通过\n\n## 📌 下一步\n1. 🔍 查看完整日志\n2. 🛠️ 修复后重跑 CI",
  "url": "https://example.com/build/128"
}

1
2
3
4
5

部署上线：

{
  "head": "🚀 v2.4.0 已发布至生产",
  "body": "## 🟢 发布结果\n- ✅ **版本**：v2.4.0 → 生产环境\n- ✅ **灰度比例**：100%（观察 30 分钟无异常）\n- 🟢 **错误率**：0.02%（发布前 0.03%）\n- 🕐 **完成于**：2026-10-03 14:05\n\n> ♻️ 回滚命令已备好，异常时 1 分钟内可切回 v2.3.9",
  "url": "https://example.com/deploy/2042"
}

1
2
3
4
5

# 6. AI 长任务完成汇报

这是本 skill 最典型的用法：任务跑完推一条，用户不必盯着对话窗口。

{
  "head": "🎉 财报解读已完成",
  "body": "## 🟢 产出\n- 📄 **报告**：2026 Q3 财报解读（12 页）\n- ✅ 营收拆解、毛利分析、风险提示\n- ⚠️ 子公司明细缺失（数据源不全）\n\n## 🔑 核心结论\n- 📈 营收同比 +18.2%，超预期 2.1pct\n- 🟡 毛利率环比 -1.4pct（原材料涨价）\n- 🔴 经营性现金流连续两季为负\n\n## 📌 下一步\n1. 🔗 查看全文",
  "url": "https://example.com/report/q3"
}

1
2
3
4
5

失败 / 部分完成（不要粉饰）：

{
  "head": "⚠️ 任务部分完成：2/3 项已产出",
  "body": "## 🟡 完成情况\n- ✅ 竞品功能对比：已完成\n- ✅ 价格区间汇总：已完成\n- ❌ 用户评价分析：数据源反爬，抓取失败\n- 🕐 **已耗时**：8 分 12 秒\n\n## 📌 下一步\n1. 🛠️ 换用官方 API 重试评价部分\n2. 👀 或你确认一下前两项能否先交付"
}

1
2
3
4

要点：部分完成要用 ⚠️ + 🟡 而不是 🎉 + 🟢，否则用户会以为全做完了。

# 7. 表格报告 vs 批量采集（选单条还是多条）

这是全篇最容易选错的地方。先问一句：用户要的是「一张能横向对比的表」还是「N 条各自独立的结果」？

用户的要求	选哪个
「分别推送」「分开推送」「一条一条发」	`send_multi_message` ——用户点了名就照做，不要替他合并
「批量采集这 N 个 X」	`send_multi_message`
同一份内容发到多个不同通道	`send_multi_message`
「整理成表格」「做成报告」「做个对比」	单条 `send_push_message` + Markdown 表格

默认走单条。 send_multi_message 的范围要收窄——只有用户明确要求分开推、批量采集、跨通道这三种情况才用。

# 7.1 表格报告 → 单条 + Markdown 表格

表格的价值在行列之间的横向对比。拆成多条后，用户拿到 N 条孤立数据，得靠回忆才能对比，表格就废了。所以用户要表格时，哪怕数据是 20 行，也塞进单条 body。

{
  "head": "📊 竞品功能对比：3 款产品",
  "body": "## 🟢 结论\n- 🏆 **综合最强**：产品 C，覆盖 18/20 项\n- 💰 **性价比**：产品 E，¥99 覆盖 15/20 项\n\n## 📋 对比明细\n| 产品 | 单价 | 覆盖 | 推荐度 |\n|---|---|---|---|\n| 产品 C | ¥399 | 18/20 | 🟢 |\n| 产品 E | ¥99 | 15/20 | 🟢 |\n| 产品 F | ¥599 | 9/20 | 🔴 |\n\n## 📌 下一步\n1. 🧪 出 C / E 的详细试用对比",
  "url": "https://example.com/report/competitors"
}

1
2
3
4
5

要点：

head 给出唯一最有价值的那个结论，表格留在 body 里让人展开看细节。不要写「竞品对比表已生成」这种只描述格式的话。
emoji 只放状态列（推荐度、是否支持），其余单元格保持纯数据；每格都加 emoji 会盖掉数字本身。
## 📌 下一步 不能省——表格给的是「现状」，用户真正缺的是「然后呢」。

# 7.2 批量采集 → `send_multi_message`

send_multi_message 的典型场景：一批并列的结果，每条本身就是一个完整主题（一个站点、一笔订单、一次任务），不是同一张表的行。做法仍是 1 条汇总 + N 条明细。

{
  "messages": [
    {
      "head": "🎉 批量采集完成：2 个站点 / 共 32 条",
      "body": "## 🟢 汇总\n- ✅ 成功 **1** 站点 ｜ ❌ 失败 **1** 站点\n- 📊 累计入库 **32** 条 ｜ 🕐 1m46s\n\n> 📌 每个站点单独一条，详见后续 2 条"
    },
    {
      "head": "📥 站点 1/2：商品列表 · 32 条",
      "body": "- ✅ 成功 **30** ｜ ❌ 失败 **2**\n- 🕐 8.2s ｜ 🟡 失败原因：详情页 403\n\n## 📌 下一步\n1. 🛠️ 重跑失败的 2 个详情页",
      "url": "https://example.com/collect/shop"
    },
    {
      "head": "💣 站点 2/2：论坛采集失败",
      "body": "## ❌ 失败详情\n- ❌ **目标**：bbs.example.com\n- ❌ **原因**：整站反爬，返回验证页\n- 🔴 **入库**：0 条\n\n## 📌 下一步\n1. 🔑 改用官方 API 或补登录态"
    }
  ]
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

要点：

汇总条排第一；明细条 head 带 n/N 序号 + 主题名（如「站点 1/3：知乎热榜」），缺条时能立刻发现。
head 要有区分度：成功用 📥 / 🎉，失败用 💣，不要清一色同一个 emoji——并列多条时 head 是唯一的区分维度。
每条各自完整的 pair：自己的成败 + 自己的下一步，不要让「下一步」全部堆在汇总条里。
单次最多 32 条，任一条失败整次调用失败。
条数超过 20 条时要认真重估：此时它往往已经变成「表格问题」而不是「多条问题」了，改走 7.1 的单条 + Markdown 表格更合适，也避免刷屏。
案例、方案、评测这类需要横向对比的内容，一律用 7.1 的表格写法，不要拆成多条。

# 8. 订单 / 物流 / 价格库存

发货：

{
  "head": "📦 订单已发货",
  "body": "- 🧾 **订单号**：SO-20261003-8842\n- 📦 **承运**：顺丰 SF1234567890\n- 🕐 **发货时间**：2026-10-03 15:20\n- 📍 **预计到达**：10-05（上海）\n\n> 🔗 点标题查看物流轨迹",
  "url": "https://example.com/order/8842"
}

1
2
3
4
5

价格变动 / 补货：

{
  "head": "💰 关注的商品降价 18%",
  "body": "## 🟢 降价详情\n- 🛒 **商品**：Sony WH-1000XM6 耳机\n- 💰 **现价**：¥1,899（原价 ¥2,299，降 18%）\n- 🟢 **库存**：充足\n- 🕐 **监控起始**：2026-09-20（历史最低）\n\n> ⏰ 是否现在下单？我可以帮你走完流程",
  "url": "https://shop.example.com/p/wh1000xm6"
}

1
2
3
4
5

# 9. 行情 / 账单 / 余额

行情提醒：

{
  "head": "📈 沪深300 突破 4200 点",
  "body": "## 🟢 触发提醒\n- 📊 **标的**：沪深300（000300）\n- 📈 **现价**：4,207.35（+1.82%）\n- 🎯 **触发条件**：站上 4200 点\n- 🕐 **触发时间**：2026-10-03 10:42\n\n> 数据仅供参考，不构成投资建议"
}

1
2
3
4

账单 / 余额告警（金额类消息 emoji 要克制，别用 🎉）：

{
  "head": "⚠️ 云账户余额低于阈值",
  "body": "## 🟡 账户状态\n- 💰 **当前余额**：¥86.40（阈值 ¥500）\n- 📉 **近 7 天消耗**：¥1,203\n- 🗂️ **主要支出**：GPU 实例 ¥890\n- 🕐 **预计耗尽**：约 3 天后\n\n## 📌 下一步\n1. 💳 及时充值避免实例停机\n2. 🧹 检查是否有闲置资源可释放",
  "url": "https://console.example.com/billing"
}

1
2
3
4
5

要点：涉及钱的消息避免 🎉 🚀 这类庆祝表情，用 💰 / 📊 / ⚠️ 更得体。

# 10. 生活服务：快递 / 出行 / 天气 / 挂号

快递待取：

{
  "head": "📮 快递已到驿站",
  "body": "- 📦 **运单**：中通 ZT9876543210\n- 📍 **取件点**：菜鸟驿站（阳光店）\n- 🔑 **取件码**：8823-1\n- ⏰ **保留至**：10-06 20:00\n\n> 🕐 建议今天去取，逾期可能退回"
}

1
2
3
4

航班 / 列车变动（高时效，head 必须带变更内容）：

{
  "head": "✈️ 航班延误 2 小时",
  "body": "## 🟡 变动详情\n- ✈️ **航班**：CA1832 北京 → 上海\n- ⏰ **原定**：14:30 → **现预计**：16:35\n- 🚪 **登机口**：C12（未变）\n- 📍 **状态**：等待前序航班抵达\n\n## 📌 下一步\n1. 🕐 建议延后出发，避免长时间候机\n2. 🔗 查看实时动态",
  "url": "https://example.com/flight/ca1832"
}

1
2
3
4
5

天气预警：

{
  "head": "🌤️ 明日暴雨，记得带伞",
  "body": "## 🟡 明日天气（10-04）\n- 🌧️ **天气**：中雨转暴雨\n- 🌡️ **气温**：18 ~ 23℃\n- 💨 **风力**：东南风 6 级\n- ⚠️ **预警**：市气象台已发布暴雨蓝色预警\n\n> 🚗 早高峰可能拥堵，建议提前 20 分钟出门"
}

1
2
3
4

预约 / 挂号提醒：

{
  "head": "⏰ 明天 10:00 有预约",
  "body": "## 📅 预约提醒\n- 🏥 **地点**：市一医院 · 骨科门诊 3 诊室\n- 👤 **医生**：张医生\n- 🕐 **时间**：2026-10-04 10:00\n- 🎫 **取号**：请提前 30 分钟自助机取号\n\n> 📎 带上既往检查报告和医保卡"
}

1
2
3
4

# 11. 账号安全事件

安全类消息必须立刻可读（锁屏第一眼就要看懂），emoji 用 🔒 / 🔑，不要用中性的 🤖。

异地登录：

{
  "head": "🔒 检测到异地登录",
  "body": "## ⚠️ 事件详情\n- 🌐 **位置**：广东深圳（IP 113.x.x.x）\n- 💻 **设备**：Chrome / Windows\n- 🕐 **时间**：2026-10-03 12:58\n- 🟡 **历史位置**：上海（最近 30 天）\n\n## 📌 如非本人操作\n1. 🔑 立即修改密码\n2. 🚪 强制下线所有设备\n3. 📞 联系客服冻结账户",
  "url": "https://example.com/security/sessions"
}

1
2
3
4
5

密钥 / 凭据轮换：

{
  "head": "🔑 API 密钥已轮换",
  "body": "- ✅ **旧密钥**：已于 12:00 失效\n- ✅ **新密钥**：已生成并写入配置\n- 🕐 **生效时间**：2026-10-03 12:00\n- ⚠️ **待办**：部署了旧密钥的服务需同步更新\n\n> 🔒 密钥原文不出现在任何推送中"
}

1
2
3
4

# 12. 周期汇报：日报 / 周报

每日汇总：

{
  "head": "📊 运维日报 · 10-03",
  "body": "## 🟢 今日概览\n- 🟢 **可用率**：99.95%（目标 99.9%）\n- ✅ **告警**：3 起，均已闭环\n- 🕐 **故障时长**：9 分 12 秒\n\n## 📌 需要关注\n- 🟡 api-gateway 内存占用升至 78%\n- 🟡 www 证书剩余 21 天\n\n## 📅 待办\n1. 🧹 排查 api-gateway 内存泄漏",
  "url": "https://example.com/report/daily/2026-10-03"
}

1
2
3
4
5

周报：

{
  "head": "📈 第 40 周数据周报",
  "body": "## 📊 核心指标\n- 📈 **新增用户**：1,284（+12.3%）\n- 🟢 **留存 D7**：41.2%（+1.8pct）\n- 🟡 **转化率**：3.1%（-0.2pct）\n- 💰 **营收**：¥482,300（+8.7%）\n\n## 🔴 异常\n- 10-01 转化率跌至 1.9%，疑与支付超时相关\n\n## 📌 下周重点\n1. 🔍 复盘支付链路稳定性",
  "url": "https://example.com/report/weekly/40"
}

1
2
3
4
5

# 13. 反例对照

反例	问题	正例
用户要表格对比，却拆成 6 条用 `send_multi_message` 推	行列被切断，横向对比失效还刷屏	单条 `send_push_message`，body 写 Markdown 表格
`head: "2026年10月3日的签到任务已顺利完成"`	超过 30 字符，结论被截断	`🎉 签到成功：积分 +10`
`head: "任务执行完毕"`	不说哪个任务、成功还是失败	`💣 备份失败：磁盘不足`
`head: "🎉🚀✅ 三个都完成了"`	emoji 堆砌	`🎉 三项任务全部完成`
`body: "❌"`	只有 emoji 没有文字，读屏无法朗读	`- ❌ 构建：单元测试未通过`
`body: "- ✅ 正常\n- 🟢 也正常"`	同类语义混用两种符号	全篇统一用 ✅ 或全用 🟢
`body: "{\"name\":\"xx\"} 🎉"`	JSON 里塞 emoji，破坏解析	webhook 版 JSON 零 emoji
`body: "服务器好像有点问题，麻烦看一下谢谢！"`	无结构、无下一步	分区 + `📌 下一步`

# 一句话 recap

先看去向：进业务系统的用 JSON、一个 emoji 都不写；进通知栏的才用 emoji 排版。head 给结论和一个 emoji，body 先分区再逐行给状态灯或结果符，最后一定给「下一步」。涉及钱的别用 🎉。

Last Updated: 2026/10/13, 00:19:47

推送示例库

# 推送示例库

# 怎么用

# 长度参考

# 通用骨架

# 目录

# 1. Webhook：结构化数据入库（机器读）

# 1.1 商品采集 → 商品库入库

# 1.2 线索名单采集 → CRM 入库

# 1.3 批量采集 → send_multi_message 分源入库

# 1.4 探测数据 → 监控 / 时序入库

# 1.5 内容与舆情批次 → 内容库入库

# 1.6 五个高频踩坑

# 2. 网站签到 / 打卡 / 权益领取

# 3. 数据采集 / 网页变更监控

# 4. 服务器与站点监控

# 5. 定时任务 / 备份 / CI 构建部署

# 6. AI 长任务完成汇报

# 7. 表格报告 vs 批量采集（选单条还是多条）

# 7.1 表格报告 → 单条 + Markdown 表格

# 7.2 批量采集 → send_multi_message

# 8. 订单 / 物流 / 价格库存

# 9. 行情 / 账单 / 余额

# 10. 生活服务：快递 / 出行 / 天气 / 挂号

# 11. 账号安全事件

# 12. 周期汇报：日报 / 周报

# 13. 反例对照

# 一句话 recap

# 1.3 批量采集 → `send_multi_message` 分源入库

# 7.2 批量采集 → `send_multi_message`