SMS Notify（短信通知 Skill）

通过新消息通道给用户本人手机发送任意内容的短信通知。场景不设限：工作待办、定时提醒、出门提醒、生活琐事……只要用户想把一件事以短信形式发到自己手机上，就可以用本 Skill 发送。

发送前必须确认用户已授权且已配置手机号。

与旧版「任务强提醒」的区别

🎯 使用范围（不设限，举例如下）

> 本质：用户说什么就发什么。内容是"提醒内容"，不再局限于"任务完成状态"。

认证方式

通过 token_service 获取一次性 creditToken，通过 Authorization header 传递。授权信息保存在 scripts/auth_info_ydrz.json。

📤 数据外发说明

本 Skill 在运行时将向下述外部服务端点发送数据：

数据最小化声明

• ✅ 仅发送用户需要通知的短信文本 — 不发送用户个人隐私数据（手机号由后端经 token 自动获取）
• ✅ 仅传输必要标识信息 — Token 认证请求中仅包含技能/开发者/业务方等运行时必需的标识参数
• ✅ 设备风控参数为匿名信息 — osType、osVersion、hostName、cpuId 仅为设备指纹，不涉及用户个人身份信息
• ✅ 日志默认关闭 — token_service.js 的 _log 函数默认关闭（log_enabled: false）

🚀 核心能力

• ✅ 任意内容 - 用户指定内容原样发送，不设模板限制
• ✅ 场景不限 - 工作/生活/出行/健康提醒均可
• ✅ AES+RSA 混合加密 - 加密敏感信息
• ✅ 失败自动重试 - 最多 3 次重试
• ✅ 渠道来源标识 - 通过 --channel 参数注入

📝 短信内容规则

内容优先级

1. 用户指定内容 → 原样/轻加工后发送（尊重用户原意，不擅自增删）
2. 用户未指定内容 → 按场景使用推荐模板

推荐模板（用户未指定内容时）

{事件/事项描述}。
例：周会将在 15:00 开始，还有 5 分钟。

> 短信正文就是通知内容本身，不加任何前缀、符号或署名。

规则

• ✅ 用户指定了什么就发什么，不擅自改写（仅在明显缺主谓时补全）
  • 内容偏长或含多个信息点时，按下方「📐 消息体美化」整理排版——只动排版，不动内容
  • 用户明确要求"原文照发 / 别改 / 就发这句"时，原样发送并加 --raw 参数
• ✅ 内容保持简洁直白（短信通道，一般不超过 100 字）
• ✅ 时间、地点、数字等关键信息要准确
• ❌ 不加【】等方括号符号——如 【提醒】会议通知，直接写内容
• ❌ 不加"来自 XX"的署名/来源说明——用户知道通知是自己设的，不需要标注是谁发的
• ⚠️ 不加点击链接、按钮（纯文本通道，链接无法点击）
• ⚠️ 不在短信内容里引导用户交互——短信无法与智能体交互，禁止出现"回复 X 确认""点击下方链接""按 1 重发"等话术
  • 若事项确实需要用户做决定或回复，写"回到{Agent名称}对话中处理"即可
  • 但不要用它替代内容：禁止删减内容后写"完整内容/详情回到对话查看"——要发的东西原样完整发下去
• ⚠️ emoji 适度：整条 1–3 个，只点睛关键行，不必每行都有；用户强制原文照发时一个都不加
• ⚠️ 不加互动引导
• ❌ 不把短信发给别人 — 本 Skill 只发到用户本人手机

📐 消息体美化（默认开启，短消息长消息都做）

> 短信是纯文本通道，没有标题、加粗、图片，排版决定观感。
> 只要不是用户强制指定的原文，Agent 都要主动美化后再发——分行、分点、空行、适度 emoji，让消息清爽好读。
> 美化的主体是分行分点，emoji 只是点缀。
> 美化只加排版和 emoji，内容一个字都不删。

何时美化 / 何时原文照发（这条最关键）

> ⚠️ 判断标准：用户是"给了要发的具体原文"，还是"只给了意图"？
> - 给了具体原文并明确要原样发 → --raw，不动
> - 只给了意图、内容由你组织 → 美化
>
> ⚠️ 美化只动排版，不动内容：加 emoji、分行、分点都可以，
> 但绝不删减、绝不截取、绝不加"完整内容回到对话查看"——用户要发什么，就完整、好看地发下去。

美化工具箱

1. 分行 — 一个信息点一行，不要把多件事挤成一坨（这是美化的主体）
2. 分点 — 并列事项用 • / ①②③ / 1. 开头，保持对齐
3. emoji（点缀） — 整条 1–3 个，只放标题行或最关键的信息行，其余行用 • 分点即可
4. 空行分隔 — 标题与正文之间空一行，靠留白拉开层次
5. 结构对齐 — 同类信息保持相同句式（如都用 • 名称：值）

emoji 使用尺度（点睛，不铺满）

• ✅ 短消息：开头 1 个场景 emoji 就够
• ✅ 长消息：整条 1–3 个——标题行 1 个，最多再给 1–2 个关键信息行
• ✅ 分点行默认用 • 或 ①②③，不带 emoji
• ❌ 不要每行都加 emoji——花成一排反而难读、显乱
• ❌ 一行不堆 2 个以上 emoji；句子中间不插 emoji
• ❌ 不硬凑：纯事务性通知（如内部工作消息）没有合适场景时，只用分行分点也可以

emoji 语义映射

长度参考（仅供参考，不据此删内容）

> send.cjs 会在发送前输出实际字数与预计占用条数。
> 字数只是参考，绝不因此删减用户内容——长就长，完整发下去。

示例

① 短消息（一句话也要加 emoji）

美化前：会议将在 14:00 开始，请提前 5 分钟入场。
美化后：⏰ 会议将在 14:00 开始，请提前 5 分钟入场。

美化前：出门前记得带身份证。
美化后：📌 出门前记得带身份证，今天办事要用。

美化前：该喝水了。
美化后：💧 喝水时间到！起身活动一下。

② 长消息（分行分点为主体，emoji 只点睛）

美化前（一坨文字，手机上很难读）：
今日Q3经营分析报告已经生成完毕，报告包含营收、成本、利润三个部分的分析，其中营收同比增长12%，报告已保存到工作区。

美化后（清爽好读，内容一点没少）：
✅ Q3 经营分析报告已生成

• 营收：同比 +12%
• 覆盖：营收 / 成本 / 利润
• 已保存到工作区

> 差别只在排版——事实、数字、原意一点没变，一个字都没删。
> emoji 只在标题行放了 1 个 ✅，分点用 •，干净不花哨。

克制原则（加得好看，但不加过头）

• ❌ 不加【】等方括号符号（【提醒】会议通知 这类一律不要）
• ❌ 不加"来自 XX"的署名/来源说明
• ❌ 每行都带 emoji——emoji 是点睛，不是行标
• ❌ 一行堆 2 个以上 emoji；句子中间不插 emoji
• ❌ 为凑 emoji 生造场景——不合适就不加，分行分点本身就已是美化
• ❌ 不加无关装饰：花边、长分隔线、连续空行
• ❌ 不因为排版改写事实、数字、时间、人名
• ❌ 不删减、不截取用户内容，长文本照常完整发送
• ❌ 不加"完整内容/详情回到对话查看"这类引导——不要替用户做取舍

🛡️ 诈骗风险提示（脚本自动追加）

> Agent 无需手动添加——send.cjs 会自动检测并在内容末尾另起一行追加防诈骗提示。

两层提示（按风险等级）

Agent 无需手动添加——send.cjs 会自动检测并在内容末尾另起一行追加对应等级的提示。

> 判定规则：只要命中任一高危特征，就按高危处理；否则命中轻度词按轻度处理。
> 两句话都固定，不要简写、不要改写措辞。

检测特征

🔴 高危 — 典型诈骗特征

🟡 轻度 — 一般敏感词（日常也常用，易误报）

> 为什么"移动""客服""退款"只算轻度：这些词在日常提醒里太常见（"提醒我申请退款""联系客服""去移动营业厅"），
> 一律扣"谨防诈骗"太重、也容易误导收信人。所以只做轻提示，让对方"谨慎识别"即可。
> 只有当内容同时出现链接、验证码、转账这类典型诈骗手法时，才升级为"谨防诈骗"。

Agent 须知

• ✅ 命中后内容照常发送，只是多一行提示——不拒绝发送、不改写、不删减用户内容
• ✅ 脚本会输出命中等级与分类日志，Agent 转告用户"已自动加上提示"即可，不用复述具体等级细节
• ✅ 若确为用户本人的正常自用内容（如"提醒我申请退款""今晚抢红包"），属误报，正常现象，可忽略
• ❌ 不要重复手动加提示（脚本已自动加）
• ❌ 不要因为命中风险特征就拒绝发送或删改用户内容
• ❌ 不要手动把轻度提示升级成"谨防诈骗"——等级由脚本判定

输出示例

高危：

⚠️ 内容命中高危诈骗特征：利益诱导、可疑链接
   已自动在末尾另起一行追加：（内容由智能体生成发送，请谨慎识别，谨防诈骗）
   提示（对 Agent）：内容照常发送，无需拒绝或额外处理。

轻度：

ℹ️ 内容命中一般敏感词：涉及中国移动（日常也常用，轻度提示即可）
   已自动在末尾另起一行追加：（内容由智能体生成发送，请谨慎识别）
   提示（对 Agent）：内容照常发送，无需拒绝或额外处理。

Commands

发送短信通知

node scripts/send.cjs "会议将在 14:00 开始，请提前 5 分钟入场。" --channel feishu

参数说明：
- 第一个参数：短信内容（含空格用引号包裹）
- --channel <名称>：可选，渠道来源标识（如 feishu、scheduler、cli），用于后台统计
- --raw：可选，用户明确要求"原文照发"时使用，跳过消息体美化提示
- --no-risk-tip：可选，关闭诈骗风险提示自动追加（慎用）

输出示例

发送成功

[短信通知] 正在获取认证 Token...
[短信通知] Token 获取成功
[短信通知] 内容：会议将在 14:00 开始，请提前 5 分钟入场。
[重试 1/3]
[尝试] API: https://5gvas01.cmicmaap.com/...
✅ 发送成功

内容偏长（提示美化排版）

[短信通知] 内容：今日Q3经营分析报告已经生成完毕，报告包含营收成本利润三个部分的分析……
[短信通知] 长度：约 66 字，预计占用 1 条短信
💡 提示（对 Agent）：这段内容可以更好看（没加 emoji、未分行），建议美化后再发——
   ① 适度加 emoji：整条 1–3 个点睛即可（⏰ 📅 📍 ✅ 💰 等），分点行用 • 就行，不必每行都有；
   ② 一个信息点一行；并列事项用 • 或 ①②③ 分点；标题与正文间空一行；
   ③ 只加排版和 emoji——内容一个字都不删，不要写"回到对话查看"；
   （若用户强制原文照发，加 --raw 参数，一个字都不动）

> 收到该提示时，Agent 应先按「📐 消息体美化」重新组织内容，再重新调用发送。

需要手机号授权（首次调用）

[短信通知] 正在获取认证 Token...
📱 需要完成手机号授权
   授权页面：https://vctest.cmccsign.com/vch5/#/pages/singleSignOn/index?authRecordId=XXX
   二维码生成链接：https://api.qrserver.com/v1/create-qr-code/?size=300x300&data=<URL编码后的授权链接>
   UUID：MjAyNjA1MjgwOTMwMTgzMzY=

🔐 手机号授权流程（首次使用必读）

> 「短信通知」需要一个接收短信的手机号。首次使用需要用户完成手机号授权，确认短信发到哪个号码。

什么时候引导授权

• 首次使用前：用户第一次提出短信通知诉求、且尚未绑定手机号时，先引导授权再发送
• 授权过期/失效：发送时提示需要重新授权（返回 103001），立即重新引导
• 更换设备/重装后：授权信息丢失，需重新授权

判断用户端

Agent 在下发授权之前，必须判断用户当前是在电脑端还是手机端：

电脑端 — 二维码 + 链接同时发（推荐）

用户当前在电脑端时，二维码和链接一起发（扫码或点击均可，覆盖更多操作习惯）：

话术：

📱 用短信通知前，先绑定接收手机号，两步搞定：
① 扫下方二维码，或直接点击链接：
🔗 <授权链接>
② 确认绑定后，回来跟我说一声，我确认没问题就可以开始用啦～

二维码生成方式：

https://api.qrserver.com/v1/create-qr-code/?size=300x300&data={URL编码后的授权链接}

手机端 — 直接发链接

用户当前在手机端时，直接把授权链接发给用户点击：

话术：

📱 用短信通知前，先绑定接收手机号～请点击下方链接完成：
🔗 <授权链接>
绑定完成后回来跟我说一声，我确认没问题就能开始用啦～

授权完成后 — 引导使用（关键体验）

用户回复"已授权"或"好了"后，Agent 再次调用发送功能验证授权是否成功，确认成功后回复：

🎉 搞定！短信通知已经可以正常使用啦～

你可以这样用：
- "报告生成完发短信告诉我" → 工作待办通知
- "每天 15:00 提醒我开周会" → 定时短信提醒
- "出门前提醒我带身份证" → 出门提醒
- "每 2 小时提醒我喝水" → 健康小助手
- "帮我把 XXX 这段话发到我手机上" → 任意内容直发

想体验一下？直接跟我说"发条测试短信给我"就行 😊

> 授权完成后主动给用户 1-2 个使用示例，帮助用户快速理解用法；不要只回一句"搞定"就结束。
> 授权完成后发给用户的提醒短信，千万不要引导用户交互，告诉用户短信通知Skill已经安装完成，验证通过即可，不要加多余的引导用户交互，或者让用户误以为可以直接给短信发送消息的字眼。

> ⚠️ 措辞要求：说"短信通知已经可以使用了"，不要说"开通成功/已开通/业务已开通"——用户没有"开通业务"的认知，会以为是办了什么套餐或收费服务。

授权时的安全说明（可附在引导话术中）

• 短信只会发到你自己绑定的手机号，不会发给任何人
• 手机号授权用于确认「短信发到哪个号码」，由安全平台完成，放心～
• 短信内容由你自己决定，不会自动发送你的隐私数据

禁止行为

• ❌ "请去龙虾那边获取授权链接"（把授权流程推给其他 Agent）
• ❌ "这是示例链接，请找到真实链接后点击"
• ❌ 只发链接不写文字引导
• ❌ 电脑端只发链接不发二维码（应二维码+链接同时发）
• ❌ 手机端反而让用户扫码
• ❌ 授权完成后不做使用引导，直接结束
• ❌ 让用户"复制链接在手机浏览器打开"（直接说"扫码或点击链接"即可）
• ❌ 向用户透露授权链接的有效期/时效（如"链接 X 分钟内有效"），平台未授权此类信息
• ❌ 向用户复述或透露手机号（包括尾号，如"已发送到 138****1234"），统一表述为"你绑定的授权手机号"
• ❌ 说多余的话、把决定抛给用户（如"你看看要不要装""觉得合适就用""可以考虑开一下"）——用户已安装本 Skill，直接引导授权和使用即可
• ❌ 在短信内容里引导用户回复/交互（如"回复 1 确认""点击链接查看"）——短信无法与智能体交互，需要交互时引导用户回到智能体对话
• ❌ 在短信内容里加【】等方括号符号，或加"来自 XX"的署名/来源说明——直接发通知内容本身
• ❌ 改写防诈骗提示文案——固定为"（内容由智能体生成发送，请谨慎识别，谨防诈骗）"，不简写、不扩写
• ❌ 授权完成或发送成功后说"开通成功/已开通/业务已开通"——统一说"短信通知已经可以使用了"

🚫 灰度开放名单限制（用户未开放时必读）

功能处于灰度测试阶段，平台对用户账号有开放名单限制。当调用 send.cjs 后出现以下情况，即代表用户当前不在开放名单中：

• 返回提示包含「名单 / 灰度 / 白名单 / 内测 / 未开放 / 未开通 / 开放中 / 敬请期待」等字样
• getToken 返回码既不是 103000（成功）也不是 103001（需要授权），且描述指向名单限制

标准话术（语气友好，直接传达给用户）

😊 谢谢你的关注！「短信通知」目前正在灰度测试中，暂时还没轮到你的账号～
不过放心，它正在逐步开放，全面开放后马上就能用啦！敬请期待哦 🎉

其他可选变体：

🥹 这个功能目前还在灰度开放中，暂时还没轮到你的账号～
不过别担心！它正在一步步开放，等开放到你的账号，我会第一时间通知你！敬请期待 🎉

「短信通知」还在灰度阶段，暂时还没开放到你的账号～请耐心等一等，敬请期待哦 😊

处理规则

• ✅ 语气友好：说明"灰度测试中 / 逐步开放 / 敬请期待"，不要生硬地回复"失败"或"无权限"
• ✅ 可主动询问用户是否需要登记意向：开放后第一时间通知他
• ❌ 不暴露内部错误码（如 200011 等）——用户不需要看到技术细节
• ❌ 不反复重试调用——名单限制不会因重试而改变
• ❌ 不引导用户自行联系平台/找客服——这是产品灰度策略，不是用户操作问题

💡 Agent 调用指南

何时使用

调用前自检清单

1. 用户是否已授权且配置手机号？
   - 未授权 → 走授权流程（见上）
   - 已授权 → 继续
2. 内容是否明确？
   - 用户指定 → 用指定内容
   - 未指定 → 按场景套推荐模板
3. 消息体美化过了吗？（见「📐 消息体美化」）
   - Agent 组织的内容（**短消息也要**）→ 分行分点 + 适度 emoji（整条 1–3 个）
   - 用户强制原文照发（"把这段发给我""别改"）→ 原样发送，加 `--raw`
   - 一律：不删减内容、不加"回到对话查看"
4. 渠道来源是否可获取？
   - 有 → 加 --channel
   - 无 → 省略
5. 发送后 → 将结果反馈给用户（成功/失败原因）

调用流程

┌─────────────────────────────────────────────────────────────┐
│ 1. 收到用户短信通知诉求（任意场景）                           │
│    明确"内容 + 时机"：是立即发？还是任务完成后/定时发？        │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│ 2. 确认用户授权状态                                          │
│    已授权 → 继续；未授权 → 先完成授权流程（二维码+链接）       │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│ 3. 构造短信内容                                              │
│    用户指定内容优先；未指定用推荐模板                          │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│ 4. 调用 send.cjs 脚本                                        │
│    node send.cjs "<内容>" --channel <渠道>                  │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│ 5. 脚本内部流程：                                            │
│    a) getToken()：103000 → 发送；103001 → 返回授权页 URL；    │
│       其他（含名单限制）→ 识别错误类型并给出友好提示          │
│    b) 发送 API（AES+RSA 加密、最多 3 次重试）                 │
└─────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────┐
│ 6. 结果反馈                                                  │
│    ✅ 发送成功 → 告知用户已送达                              │
│    ⚠️ 需要授权 → 走授权流程                                  │
│    🚫 不在灰度名单 → 用"敬请期待"话术友好告知               │
└─────────────────────────────────────────────────────────────┘

安装后使用规则

• ✅ 授权后使用 - 用户完成授权并配置手机号后方可发送
• ✅ 发送前确认 - 每次发送前确认用户授权状态正常
• ✅ 内容以用户为准 - 用户指定内容优先，不擅自改写
• ✅ 场景不限 - 不判断"是否属于任务完成类"，任何短信通知诉求均可
• ✅ 所有渠道一致 - 不管用户在哪个渠道配置的，都可正常通知
• ✅ 手机号确认 - 从用户处获得
• ✅ 记录保存 - 授权状态与常用配置写入 MEMORY.md 或 memory 文件（含配置渠道）
• ✅ 定时任务联动 - 若用户要求"定时/任务完成后通知"，配合定时任务（automation）使用：任务 prompt 中注明"完成后调用短信通知 Skill 发送"