用 Spec Skills 做 Bug 分流与事故记录

凌晨 3:04，PagerDuty 在嗡嗡作响。一条工单写着"登录很慢，客户在投诉"，没有别的任何信息。当晚 on-call 只有我一个人。在叫醒任何人之前，我把这条工单粘到 Spec Skills 里，一分钟之内就拿到了一份经过分流的第一小时响应方案。这套工作流是我两年前就希望自己有的，也是我现在再也不愿意离开的工具。

发布于 2026-03-10 · ✓ 已更新 2026-05-06 · 阅读约 7 分钟 · 作者：Spec Coding 编辑部 · 审校：编辑与事实核查政策

为什么 bug 分流是 AI 工具最晚搞定的一件事

市面上每一款 AI 编码工具都乐意给你写一个 React 组件，或者帮你重构一个函数。但凌晨三点、需要真正做判断的时候，它们几乎没有一个派得上用场：这事有多严重？该叫谁起床？四十分钟之内我要怎么向客户交代？分流不是自动补全。它要求你在严重度和影响范围之间做权衡，把用户的语言翻译成运营层面的影响，还要判断这到底是上周二修过的老 bug，还是一个全新的问题。

这也正是为什么我在拿 Spec Skills 写代码之前，就先用它做分流了。spec-first 的框架会逼着 AI 给出结构化的判断，而不是一堆模糊的感觉。而凌晨三点的我，要的就是结构。

我真正在用的那个 intake 提示词

我的 intake 提示词只有四个问题，没有任何花哨的东西。我把原始 bug 报告粘进去，让 Spec Skills 给我：最小复现步骤、带推理过程的严重度判断、受影响用户数的估计，以及建议 page 谁。就这四条。没有"帮我写个 spec"，也没有"给我一份方案"。四个字段，没了。

关键在于每个字段都会逼模型下判断。带推理过程的严重度判断意味着它没法用"看情况"混过去。受影响用户估计逼它从症状反推影响范围。"该叫谁"是四个字段里最有立场的一条，也是我最常推翻的一条，但这个建议本身仍然有用，因为它把模型对这套系统的心智模型给暴露出来了。

对照一份真实的严重度矩阵做推断

我把团队实际在用的严重度矩阵喂给 Spec Skills。P0 是客户数据丢失或泄露；P1 是关键功能对相当比例的用户下线；P2 是性能降级，或者某条工作流走不通但有 workaround；P3 是视觉问题或者边角 case。

给定这份矩阵，Spec Skills 对用户描述的映射好得出乎我意料。"登录很慢"变成 P2 降级，因为没有数据丢失、功能技术上还在线。"我看不到发票，页面是空白的"变成 P1 关键功能下线。"按钮是绿色的，应该是蓝色"还是 P3。模型并没有在发明一个严重度，它只是在把文字对到我的评级标准上。这件事它很擅长。

复现校验这一轮

我跑的第二轮是复现校验。我会问："给定这份 bug 报告，写一份初级工程师照着就能跑的最小复现步骤。"如果 Spec Skills 写不出具体步骤，那就说明这份报告太模糊，我会在 page 任何人之前先回去找报告人问清楚。光是上个月，这一步就帮我避免了三次没必要的 page。复现校验也是重复检测的起点，因为具体的复现步骤可以和最近的事故做 diff 对比。

和近期历史做重复检测

我维护着一份滚动的日志，里面是最近 30 天的事故，以及最近 30 天合并过的修复，都是纯文本。在 Spec Skills 敲定严重度之前，它会拿报告去和这份日志比对一下。2026 年 4 月出现的"登录很慢"，看起来跟我们 3 月 29 日修过的那次连接池打满非常像。AI 把相似性标出来，我去看那次的修复，四十分钟的 debug 就这样省掉了。现在重复命中率是我在持续追踪的指标之一。

分流输出的 Given/When/Then 验收标准

- Given a raw bug report and the severity matrix
  When Spec Skills runs the intake prompt
  Then the output contains repro steps, severity with reasoning, affected-users estimate, and paging recommendation

- Given a severity of P0 or P1
  When the on-call reviews the triage output
  Then a human confirms severity before any page is sent

- Given a candidate duplicate of a recent incident
  When similarity exceeds a reasonable threshold
  Then the triage output links the prior incident and proposes deduplication

走一遍"登录很慢"那个例子

下面是我上周实际拿到的输出。工单源流程："登录很慢，我花了 30 秒才进去，我们组其他人也在抱怨。"我把这段话连同矩阵、事故日志一起粘进去。Spec Skills 返回的是：复现步骤（新开会话登录、测从登录到 dashboard 渲染的时间、用三个账号各试一遍）；严重度 P2 降级，附带理由（"功能可用、延迟升高、无数据影响"）；受影响用户估计（"投诉集中在同一组里，提示更像是 tenant 维度的问题，不是全机群"）；以及 page 建议（"不要 page，明早给 auth 团队开一条高优工单；若 p99 超过 10 秒再升级"）。

我看了一眼 auth 的 dashboard，p99 是 4.2 秒，升高了但没到崩。我没 page。auth 团队早上 9 点接手，查出是那个 tenant 的 SSO provider 出了一个很糟糕的 query plan。对我的成本总计：90 秒的 Spec Skills，加上一眼 dashboard 的 sanity check。这就是胜利的样子。

postmortem-seed 提示词

事故解决之后，我把时间线、影响数字、修复 commit 一起喂给 Spec Skills。它会起草一份 postmortem，分成 summary、timeline、impact、detection、response、next steps 这几块。它不会做、我也不想让它做的，是"这件事为什么会发生"这一节。根因分析需要模型不具备的组织背景。如果我放它去写，它会欢快地在那儿瞎猜，所以我不让。postmortem-seed 让我每次事故大概省下两个小时的格式化工作，也就是最无聊的那部分。思考的部分还是留在我自己手里。

事故笔记模板，以及什么时候推翻 AI

我的事故笔记永远是同样的六个字段：时间、严重度、用户影响、假设原因、已采取的动作、后续步骤。Spec Skills 会从分流输出里填好其中五个。假设原因那一栏我自己填，因为这里最吃操作者的上下文。如果我这个月已经为同一个子系统被 page 了四次，我知道的事情比模型多得多。什么时候推翻 AI：当你掌握它没有的历史上下文时；当严重度矩阵和当前情境对不上时；当报告来自一个"slow"有特殊含义的客户时。什么时候相信 AI：报告结构清晰、症状明确、近期事故日志也是新鲜的时候。

告诉我这套流程真的有效的三个指标

三个数字。从收到报告到完成分流的时间，从大约 14 分钟降到了 3 分钟以内。重复命中率，现在大约有 30% 的新报告会被正确标记为近期历史中的重复。Spec Skills 判断的严重度与最终接手工单的人所认定的严重度之间的一致率，稳定在 85% 左右。那些不一致的 case 才是我学到最多的地方，而且通常就是矩阵自己需要更新的信号。

可复制产物：Spec Skills 工作流包

把这段用于真实的 Spec Skills 运行前。它会把输入、边界和人工评审点放在同一处，避免输出看起来完整但责任不清。

Spec Skills 工作流包：用 Spec Skills 做 Bug 分流与事故记录

本次要做的决策：
- 把这篇文章里的工作流应用到一个真实工单，并确认输入、边界、输出和人工评审点。

责任人检查：
- 产品责任人：
- 工程责任人：
- QA 或运维评审：

范围边界：
- 本次包含：
- 本次不包含：
- 仍需确认的假设：

验收证据：
- 测试或 fixture：
- 日志、指标或截图：
- 人工复核步骤：

工具边界：模型可以起草结构和问题，范围、契约行为、发布风险仍然必须由责任人确认。

评审追问：
- 没参加需求会的人还会误解哪里？
- 哪个证据能证明这次改动足够安全，可以发布？

编辑复核记录

复核日期：2026-04-28。本次补充了可复用产物，按相关主题 Hub 检查了文章定位，并收紧下一步链接，让页面更像可操作参考，而不是孤立长文。

事故笔记清单

事故笔记要短到适合值班交接，也要具体到另一个工程师能继续推进，而不是重新分诊。

下载：incident-note-template.md

• 记录原始报告、来源渠道，以及你信任的第一个时间戳。
• 把已验证事实和假设分开写，避免后续响应者把猜测当结论。
• 用书面阈值映射严重度，不靠当班人的直觉。
• 开新调查前先链接可能重复或相邻的事故。
• 写清下一步负责人，以及关闭或升级这条笔记的条件。

需要追踪的证据

看分诊质量时，重点追踪从报告到负责人确认的时间、重复命中率、人工复核后的严重度变化，以及由薄弱笔记导致的重开事故。这些数字能说明流程是在减少混乱，还是只是在生成更漂亮的事故文字。