notify

核心用法

Notify 是一个面向 AI Agent 的通知策略指导文档，而非可执行代码。它系统性地定义了通知类型与渠道匹配规则：系统故障和安全警报需立即通过 Push+主聊天渠道触达；2小时内截止的紧急任务即时推送；任务完成类通知可批量延迟5-15分钟聚合发送；日报/周报则通过邮件或定时消息投递；调试信息仅记录日志不打扰用户。

文档提供了完整的格式化规范：Telegram/Discord 禁用 Markdown 表格改用列表；邮件支持完整格式但需 actionable 主题行；SMS 严格控制在160字符以内；Push 通知限定标题50字符+正文100字符。所有渠道遵循统一原则：以结果而非过程开头、包含单一明确行动项、使用用户时区时间戳、提供「是什么+影响+建议行动」的完整上下文。

显著优点

该技能的最大价值在于建立了系统化的通知治理框架。通过「静默时段」机制（默认23:00-08:00）和分级批处理逻辑，有效避免通知疲劳——同一项目5分钟内3条以上通知自动聚合，低优先级信息进入早晚摘要队列。反模式清单直击行业痛点：禁止「任务进行中」状态轰炸、禁止多通道重复发送、禁止 JSON 裸数据暴露、禁止无限循环提醒，这些规范显著保护用户信任度。

确认格式模板（✅ Scheduled + 📅 时间 + 📬 渠道 + 🔕 静默尊重）提供了可预期的交互契约，而四级升级机制（2小时等待→单条提醒→4小时后换渠道→3次停止）在紧急性与防骚扰之间取得平衡。用户偏好检查清单确保首次通知前完成渠道、时区、静默时段、紧急通道的配置，从源头减少误触。

潜在缺点与局限性

作为纯文档型资产，Notify 仅提供策略建议而无实际执行代码，开发者需自行实现路由引擎、批处理队列、时区计算等基础设施。文档未提供具体技术栈的 SDK 或集成示例，不同平台（Telegram Bot API、Discord Webhook、邮件服务）的对接成本需额外承担。

升级机制中的「4小时后换渠道」在跨时区场景可能引发新问题——若用户夜间睡眠期间触发紧急警报，次渠道（如 SMS）可能在清晨造成二次打扰。此外，「同一项目」的聚合判断依赖项目 ID 的明确定义，文档未说明如何界定项目边界（仓库级？任务级？用户级？），实际落地时易产生歧义。

适合的目标群体

• AI Agent 开发者：构建需要主动触达用户的对话式系统，如 DevOps 机器人、项目管理助手、监控告警 Agent
• SaaS 产品经理：设计多通道用户通知体系，平衡信息到达率与用户体验
• 平台运营团队：规范自动化消息的发送策略，降低用户退订率和投诉率
• 技术写作者：作为通知 UX 设计的参考规范，输出团队内部标准

使用风险

• 策略与实现落差：文档建议的批处理、时区感知、升级机制需要可靠的定时任务和状态存储支撑，自建系统需考虑故障恢复和重复投递防护
• 渠道配置依赖：静默时段和紧急通道的「用户配置」需持久化存储，若配置丢失可能导致关键警报被错误抑制或普通消息夜间骚扰
• 聚合逻辑复杂度：「5分钟窗口+3条阈值+同一项目」的批处理规则在分布式环境下需处理时钟同步和边界条件，实现不当可能漏发或延迟关键信息
• 合规边界：升级机制涉及 SMS 等可能产生资费的渠道，需确保用户明确授权，避免未经授权的计费行为引发法律风险