统一通知运维 是做什么的?
当真实问题不是缺少一次提醒,而是通知系统碎片化时,使用此技能。
目标是将散落的事件转化为一个统一运维界面,包含:
- 清晰的严重等级
- 清晰的责任人
- 清晰的路由
- 清晰的后续操作
何时使用
- 用户希望跨 GitHub、Linear、本地 Hook、桌面提醒、聊天或邮件建立一个统一通知通道
- CI 失败、审查请求、问题更新和运维事件抵达在互不相连的位置
- 当前设置产生的是噪声而非行动
- 用户希望将重叠的通知分支或积压提案合并到一条 ECC 原生通道中
- 工作区已有 Hook、MCP 或已连接的工具,但没有连贯的通知策略
首选界面
从已有工具出发:
- GitHub 的 Issue、PR、审查、评论和 CI
- Linear 的问题/项目变更
- 本地 Hook 事件和会话生命周期信号
- 桌面通知原语
- 已连接的邮件/聊天界面(如果确实存在)
优先使用 ECC 原生编排,而非让用户采用单独的通知产品。
不可妥协的规则
- 绝不暴露令牌、密钥、Webhook 密钥或内部标识符
- 区分以下内容:
- 事件来源
- 严重等级
- 路由通道
- 运维操作
- 当中断成本不明确时,默认采用摘要优先方式
- 不要将每个事件广播到所有通道
- 如果真正的解决方案是更好的问题分类、Hook 策略或项目流程,请明确说明
事件管道
将通道视为:
- 捕获事件
- 分类紧急程度和负责人
- 路由到正确通道
- 折叠重复和低信号干扰
- 附加下一步运维操作
目标是更少但更优质的通知。
默认严重模型
| 等级 | 示例 | 默认处理方式 |
|---|---|---|
| 关键 | 默认分支 CI 失败、安全问题、版本发布受阻、部署失败 | 立即中断 |
| 高 | 审查已请求、PR 失败、等待负责人交接 | 当天告警 |
| 中 | Issue 状态变化、重要评论、积压移动 | 摘要或队列 |
| 低 | 重复成功、常规干扰、冗余生命周期标记 | 抑制或折叠 |
如果工作区没有严重模型,请先构建一个,然后再提议自动化方案。
工作流
1. 盘点当前界面
列出:
- 事件来源
- 当前通道
- 已有的发出告警的 Hook/脚本
- 同一事件的重复路径
- 重要事项未被发现的静默失败情况
指出 ECC 已拥有哪些部分。
2. 决定哪些事项值得中断
针对每一类事件,回答:
- 谁需要知道?
- 他们需要多快知道?
- 应中断、批处理还是仅记录?
使用以下默认规则:
- 版本发布、CI、安全及阻塞负责人事件应中断
- 中等信号更新应以摘要形式呈现
- 遥测和低信号生命周期标记仅记录
3. 在添加通道之前先折叠重复项
寻找:
- 同一 PR 事件同时出现在 GitHub、Linear 和本地日志中
- 同一失败反复触发 Hook 通知
- 应被汇总而不必逐条转发的评论或状态变化
- 没有提供更好操作路径的重复通道
优先:
- 一份规范化摘要
- 一个负责人
- 一条主要通道
- 一条备用路径
4. 设计 ECC 原生工作流
为每个真实通知需求定义:
- 来源
- 门控
- 形态:即时告警、摘要、队列或仅仪表盘
- 通道
- 操作
如果 ECC 已有原语,优先使用:
- 用于运维人员分类的技能
- 用于自动触发/强制的 Hook
- 用于委托分类的智能体
- 仅在确实缺少桥梁时才使用 MCP/连接器
5. 返回以行动为导向的设计
最后输出:
- 保留什么
- 抑制什么
- 合并什么
- ECC 下一步应包装什么
输出格式
当前界面
- 来源
- 通道
- 重复项
- 缺口
事件模型
- 关键
- 高
- 中
- 低
路由方案
- 来源 -> 通道
- 原因
- 运维负责人
合并方案
- 抑制
- 合并
- 规范化摘要
下一步 ECC 操作
- 技能 / Hook / 智能体 / MCP
- 下一步要构建的确切工作流
推荐规则
- 优先选择一条强壮的通道,而非多条弱通道
- 中低信号更新优先使用摘要
- 当信号应自动发出时,优先使用 Hook
- 当工作是分类、路由和审查优先决策时,优先使用运维人员技能
- 当根本原因是积压/PR 协调而非告警时,优先使用
project-flow-ops - 当用户首先需要来源清单时,优先使用
workspace-surface-audit - 如果桌面通知足够,不要发明不必要的外部桥梁
良好用例
- “我们有 GitHub、Linear 和本地 Hook 告警,但没有统一的运维流程”
- “我们的 CI 失败很嘈杂,大家都忽略”
- “我想要一个跨 Claude、OpenCode 和 Codex 界面的统一通知策略”
- “弄清楚哪些事项应该中断,哪些应该落入摘要”
- “将重叠的通知 PR 想法合并到一条规范的 ECC 通道中”
相关技能
workspace-surface-auditproject-flow-opsgithub-opsknowledge-opscustomer-billing-ops:当通知痛点来自计费/客户运维而非工程时使用