统一通知运维 是做什么的?
当真正的问题不是缺少提醒,而是通知系统碎片化时使用此技能。
任务是将分散的事件整合到一个运维界面上,做到:
- 明确的严重性
- 明确的所有权
- 明确的路由
- 明确的后续行动
何时使用
- 用户希望在 GitHub、Linear、本地钩子、桌面提醒、聊天或邮件之间建立统一的通知通道
- CI 失败、审查请求、问题更新和运维事件出现在不同的地方
- 当前配置产生的不是行动,而是噪音
- 用户希望将重叠的通知分支或积压方案合并到一个 ECC 本地通道
- 工作区已有钩子、MCP 或连接工具,但没有一致的通知策略
首选界面
从已有的内容开始:
- GitHub 问题、PR、审查、评论和 CI
- Linear 问题/项目状态变更
- 本地钩子事件和会话生命周期信号
- 桌面通知原语
- 已连接的邮件/聊天界面(如果实际存在)
优先使用 ECC 本地编排,而非建议用户采用独立的通知产品。
不可妥协的规则
- 绝不暴露令牌、密钥、webhook 密钥或内部标识符
- 分离:
- 事件来源
- 严重性
- 路由通道
- 运维操作
- 当打断成本不明确时,默认使用摘要优先方式
- 不要将每个事件广播到每个通道
- 如果真正的解决方法是更好的问题分类、钩子策略或项目流程,请明确说明
事件流水线
将通道视为:
- 捕获事件
- 分类紧急程度和负责人
- 路由到正确的通道
- 去重并压缩低信噪波动
- 附加下一个运维操作
目标是更少、更好的通知。
默认严重性模型
| 级别 | 示例 | 默认处理方式 |
|---|---|---|
| 关键 | 默认分支 CI 损坏、安全问题、版本发布受阻、部署失败 | 立即打断 |
| 高 | 审查请求、失败的 PR、需负责人处理的交接 | 当日内提醒 |
| 中 | 问题状态变更、重要评论、积压变动 | 摘要或队列 |
| 低 | 重复成功、常规波动、冗余的生命周期标记 | 抑制或折叠 |
如果工作区没有严重性模型,在提出自动化方案前先构建一个。
工作流程
1. 盘点当前界面
列出:
- 事件来源
- 当前通道
- 发送提醒的现有钩子/脚本
- 同一事件的重复路径
- 重要事项未被呈现的静默失败案例
指出 ECC 已经拥有的内容。
2. 确定哪些值得打断
针对每个事件类别,回答:
- 谁需要知道?
- 他们需要多快知道?
- 这应该打断、批量处理、还是仅记录?
使用以下默认值:
- 打断:版本发布、CI、安全问题和需负责人处理的事件
- 摘要:中等信噪比的更新
- 仅记录:遥测和低信噪比生命周期标记
3. 在添加通道之前先进行去重
查找:
- 同一个 PR 事件同时出现在 GitHub、Linear 和本地日志中
- 同一失败的重复钩子通知
- 应当总结而非直接转发的评论或状态波动
- 相互重复且未提供更好操作路径的通道
优先使用:
- 一个权威摘要
- 一个负责人
- 一个主通道
- 一个备用路径
4. 设计 ECC 本地工作流
针对每个真实的通知需求,定义:
- 来源
- 门控
- 形态:即时提醒、摘要、队列或仅仪表盘
- 通道
- 操作
如果 ECC 已有原语,优先使用:
- 一个用于运维分类的技能
- 一个用于自动发送/执行的钩子
- 一个用于委托分类的代理
- 仅在真正缺少桥接时才使用 MCP/连接器
5. 返回一个面向行动的设计
最终输出:
- 保留什么
- 抑制什么
- 合并什么
- ECC 下一步应封装什么
输出格式
当前界面
- 来源
- 通道
- 重复项
- 空白
事件模型
- 关键
- 高
- 中
- 低
路由计划
- 来源 -> 通道
- 原因
- 运维负责人
整合
- 抑制
- 合并
- 权威摘要
下一步 ECC 动作
- 技能 / 钩子 / 代理 / MCP
- 下一步要构建的确切工作流
推荐规则
- 倾向于一条强的通道,而非多条弱通道
- 倾向于中等和低信噪比更新的摘要
- 当信号应自动发送时,倾向于使用钩子
- 当工作是分类、路由和审查优先的决策时,倾向于使用运维技能
- 当根本原因是积压/PR 协调而非提醒时,优先使用
project-flow-ops - 当用户首先需要来源盘点时,优先使用
workspace-surface-audit - 如果桌面提醒就够了,不要创造不必要的外部桥接
好的用例
- “我们有 GitHub、Linear 和本地钩子提醒,但没有统一的运维流程”
- “我们的 CI 失败很嘈杂,人们都忽略了”
- “我想要一个在 Claude、OpenCode 和 Codex 界面间统一的通知策略”
- “找出哪些应该打断,哪些应该放入摘要”
- “将重叠的通知 PR 想法合并成一个权威的 ECC 通道”
相关技能
workspace-surface-auditproject-flow-opsgithub-opsknowledge-ops- 当通知痛点属于账单/客户运维而非工程时,使用
customer-billing-ops