将通知作为统一的 ECC 原生工作流进行操作，涵盖 GitHub、Linear、桌面提醒、钩子以及连接的通信界面。当真正的问题是告警路由、去重、升级或收件箱崩溃时使用。
复制下面这句话，粘贴给 Claude Code、Codex、Cursor 等 AI 编程工具，它会读取安装说明并在你确认后完成安装。
请阅读 https://ai.atlankj.com/install/asset/gh-unified-notifications-ops-78945b8c6328 ，按照其中的说明把「unified-notifications-ops」安装到你（当前 AI 工具）中。执行前先告诉我将运行的命令和写入的位置，等我确认。
查看 AI 将读取的安装说明正在读取 GitHub 原文…
内容来自 GitHub 原始文件，由原作者维护。在 GitHub 查看
当真正的问题不是缺少通知，而是通知系统碎片化时，使用此技能。
任务是将分散的事件整合到一个操作员界面上，包含：
从已有资源出发：
优先使用 ECC 原生编排，而非建议用户采用独立的通知产品。
将通道视为：
目标是更少但更好的通知。
| 等级 | 示例 | 默认处理方式 |
|---|---|---|
| 严重 | 默认分支 CI 损坏、安全问题、发布受阻、部署失败 | 立即中断 |
| 高 | 请求审查、PR 失败、阻塞责任人的交接 | 当日提醒 |
| 中 | 问题状态变更、重要评论、积压变动 | 摘要或队列 |
| 低 | 重复成功、常规噪音、冗余生命周期标记 | 抑制或折叠 |
如果工作区没有严重等级模型，请先构建一个，再提出自动化方案。
列出：
指出 ECC 已拥有的部分。
针对每个事件族，回答：
使用以下默认值：
检查：
优先选择：
针对每个真实通知需求，定义：
如果 ECC 已有原语，优先使用：
最终输出：
当前表面
- 来源
- 渠道
- 重复项
- 缺口
事件模型
- 严重
- 高
- 中
- 低
路由计划
- 来源 -> 渠道
- 原因
- 操作员/负责人
整合
- 抑制
- 合并
- 规范摘要
下一步ECC行动
- 技能/钩子/代理/MCP
- 下一步要构建的具体工作流
project-flow-opsworkspace-surface-auditworkspace-surface-auditproject-flow-opsgithub-opsknowledge-opscustomer-billing-ops 当通知痛点涉及计费/客户运营而非工程时