AI 知识库

triage

Properties1
tagsskill, 修bug

4分钟阅读

triage

产品介绍

triage 是 Matt Pocock Skills 中「修 bug 流水线」的第 1 步，是一个 Bug 分流 Skill。安装在 ~/.trae-cn/skills/triage/SKILL.md，用户手动调用 /triage 时触发。核心功能是把 bug 报告分流到正确的状态，避免一上来就修结果修错方向。

为什么要先分流

接到 bug 报告时，最自然的反应是「赶紧修」。但很多时候：

  • 信息不足：报告者可能只说了现象，没说复现步骤
  • 方向错误：问题可能不在代码里，而在配置、数据或环境
  • 优先级不对：看似严重的 bug 可能只影响 1 个用户，而看似轻微的 bug 可能影响所有用户

所以先分流、再动手，是更稳妥的做法。

五种分流状态

状态含义什么时候用
needs-triage待评估刚收到报告，信息不够，需要进一步了解
needs-info需要更多信息已经大致了解，但缺关键信息才能判断
ready-for-agent可以交给 AI 处理信息完整、方向明确、AI 可以直接开工
ready-for-human需要人工处理涉及架构决策、安全问题、或需要生产环境权限
wontfix不修复不是 bug（是 feature request）、超出范围、或修复成本高于收益

分流的判断逻辑

接到 bug 报告后，按以下顺序判断：

  1. 这是 bug 吗？

    • 如果不是 → wontfix
    • 如果是 → 进入下一步

  2. 信息够吗？

    • 如果不够 → needs-info（列出缺哪些信息）
    • 如果够 → 进入下一步

  3. 能复现吗？

    • 如果不能 → needs-triage（需要进一步定位）
    • 如果能 → 进入下一步

  4. AI 能处理吗？

    • 如果能 → ready-for-agent
    • 如果不能 → ready-for-human（说明为什么需要人工）

实际例子

场景：用户报告「系统偶尔会崩」

不好的处理：

好的，我看看代码 → 找到一个可能的问题 → 改 → 测试 → 修好了

（可能修的根本不是这个问题）

好的处理（走 triage）：

1. 这是 bug，不是 feature request → 继续
2. 信息不够：没有复现步骤、没有日志、没有触发条件 → needs-info
3. 列出需要的信息：
   - 什么时候发生的？（时间点）
   - 操作了什么？（操作步骤）
   - 期望什么结果？（期望行为）
   - 实际发生了什么？（实际行为）
   - 有没有错误日志？（日志链接）

拿到这些信息后，AI 才能进入下一步 diagnosing-bugs。

使用场景

  • 接到 bug 报告时，先分类再处理
  • 避免一上来就修，结果修错方向
  • 团队协作时，明确 bug 的归属（谁处理、什么时候处理）

与下游的关系

triage 是整个修 bug 流水线的第一步。分流完之后：

  • ready-for-agent → 进入 diagnosing-bugs 诊断循环
  • needs-info → 等信息到位后再重新分流
  • ready-for-human → 交给团队处理
  • wontfix → 记录原因，关闭

相关笔记

相关日记

反向链接