什么是triage？
如果你维护过任何一个有外部贡献者的开源项目，或者在一个稍具规模的团队里工作过，大概率对这种情况不陌生：Issue越积越多，分不清哪些是真Bug、哪些是脑暴、哪些早就该关掉。当你引入AI智能体来分担工作量之后，这个问题非但没有消失，反而被放大了——智能体很乐意去做事，但它无法替你判断“这件事到底该不该做、现在能不能做”。
开源作者Matt Pocock把这种困境叫作“地狱级Backlog”，triage就是他给出的工程化解法。
triage是Matt Pocock技能包里的一个核心工程技能。它的定位很明确：通过一套基于状态机的triage roles，把Issue从“收到”到“处理”或“关闭”的全生命周期管起来。
这个技能只干一件事：把Issue分类这件事标准化、可自动化。它不写代码、不修Bug、不生成功能，但它决定了“哪些Bug该修、哪些功能该做、哪些Issue可以丢给AI去干”。
主要功能
1. 两套角色体系：Category + State
triage把所有Issue拆成两个维度来管理：
Category Role（类别角色） ——这个Issue是什么性质：
bug：某个东西坏了enhancement：新功能或改进
State Role（状态角色） ——这个Issue现在处于什么阶段：
needs-triage：等待维护者评估needs-info：等待提交者提供更多信息ready-for-agent：已完整说明，可以交给AI智能体去实现ready-for-human：需要人类来实现wontfix：不会处理
每个经过triage的Issue必须且只能携带一个Category Role和一个State Role。
这套设计的精妙之处在于：Category回答“这是什么”，State回答“现在该怎么办”。两者组合起来，AI就能精准理解每一个Issue的当前状态和下一步动作。
2. 状态流转：一台清晰的状态机
未标记的Issue通常先进入needs-triage，然后根据评估结果移动到needs-info、ready-for-agent、ready-for-human或wontfix。
needs-info的Issue在提交者回复后，重新回到needs-triage等待再次评估。维护者可以随时覆盖任何状态流转——AI在发现异常流转时会先标记出来、询问维护者，再继续。
这套流转逻辑不复杂，但它把Issue管理从“凭感觉”变成了“按规则”。人和AI都在同一套规则下工作。
3. 三桶视图：一眼看清该干什么
当维护者输入/triage并说“帮我看看有什么需要我处理的”，AI会查询Issue tracker，按三个桶来呈现，旧的优先：
Unlabeled（未标记） ：从未被triage过的Issue
needs-triage（待评估） ：正在评估中的Issue
needs-info with recent activity（信息已回复） ：提交者已回复、需要重新评估的Issue
AI会显示每个桶的数量和每个Issue的一行摘要，让维护者选择接下来处理哪一个。这个视图让维护者不用在几十个Issue里翻找，一眼就知道优先级在哪里。
4. 完整的Triage工作流
当维护者指定要triage某一个具体的Issue或PR时，AI会执行一套完整的流程：
第一步：收集上下文。读取完整的Issue或PR——正文、评论、标签、作者、日期；对PR还要读diff。解析之前的triage notes，避免重复问已经解决的问题。
第二步：代码库检查。用项目的domain glossary探索代码库，遵守相关ADR。跑两项检查：
冗余检查：按领域概念搜索已有实现，如果找到了，那就是一个已实现的
wontfix历史否决检查：读取
.out-of-scope/*.md，找出任何与此请求相似的既往被否决记录
第三步：给出推荐。告诉维护者推荐的Category和State以及理由，附上相关的代码库摘要——包括它是否已经实现。等待指示。
第四步：验证主张。在进入任何深度讨论之前，先检查这个主张是否成立。对Bug，从提交者的步骤去复现；对PR，确认diff做到了它所声称的——checkout它、运行相关测试或命令。报告发生了什么。
第五步：深度讨论（如需要） 。如果请求需要进一步充实，一起运行/grilling和/domain-modeling技能——一次一个问题把它讨论成形。
5. 对PR的特殊处理
triage同样适用于PR。对PR而言，ready-for-agent表示已附加brief、AI应对diff采取下一步；ready-for-human表示已准备好由人类merge。
在发现阶段的“三桶视图”中，AI只会浮现外部贡献者的PR——协作者正在进行的PR不算triage工作。但如果维护者明确点名某个PR，无论作者是谁都会被triage。
如何安装triage
安装命令
在终端中执行以下命令：
npx skills add mattpocock/skills --skill triage
备选安装方式
如果你在安装过程中找不到triage这个技能名，可以尝试使用完整路径：
npx skills add mattpocock/skills --skill mattpocock-skills-skills-engineering-triage
前置配置：先跑setup
triage依赖一套每个仓库的本地配置——Issue tracker在哪里、triage labels用什么词。在首次使用triage或其他engineering skills之前，需要先运行：
/setup-matt-pocock-skills
这个配置会依次问你三个问题：Issue tracker（GitHub、Linear还是本地markdown）、triage labels的词汇映射、domain docs的存放位置。跑完一次，所有engineering skills就都有了确定的读写位置。
应用场景
场景一：开源项目的Issue队列管理
这是triage最典型的使用场景。你的开源项目每天都有新的Issue进来——有Bug报告、有功能请求、有纯提问。你一个人不可能全部及时处理，但放太久又会让贡献者觉得被忽视。用/triage，AI帮你把新Issue过一遍：检查是否重复、是否曾经被否决、信息是否充足，然后给出分类建议。你只需要做最后的确认。
场景二：团队内部的Backlog梳理
团队内部的需求池里堆了几十个条目，产品、开发、测试各说各话，没人知道哪些是真正要做的。用/triage的三桶视图，先把所有未标记的条目过一遍——区分Bug和Enhancement，标记信息不足的需要补充，清晰的直接打上ready-for-agent交给AI去实现。
场景三：准备AI智能体可以独立完成的任务
这是triage最实用的用法之一。你想让AI智能体（AFK agent）在你不在的时候独立完成一些任务，但前提是这些任务必须足够清晰、边界明确、不需要人工决策。用/triage把Issue标记为ready-for-agent，AI智能体就知道“这个我可以干”。
场景四：PR的快速分流
你的项目收到了一个外部贡献者的PR。你不知道该不该合、有没有问题、是不是方向对了。用/triage去处理这个PR——AI会读diff、跑测试、检查是否做到了它声称的，然后给出ready-for-agent（让AI继续完善）或ready-for-human（人类来merge）的建议。
使用案例
案例一：一个开源项目维护者的日常
一个流行的开源库每周收到15-20个新Issue。维护者以前的做法是：每天晚上花1-2小时手动浏览所有新Issue，判断是否重复、是否有效、优先级如何。重复劳动，而且容易漏。
装了triage之后，他的工作流变成了这样：每天早上输入/triage，AI把过去24小时的新Issue按三个桶呈现——未标记的、待评估的、信息已回复的。他挑一个看起来最紧急的，说“看一下#142”。AI花了几十秒读完Issue全文、搜索了代码库中是否存在类似实现、检查了.out-of-scope/里有没有历史否决记录，然后给出推荐：“这是一个bug，之前没有类似实现，建议标记为bug + ready-for-agent，因为它有完整的复现步骤。”他确认后，AI自动打上标签。整个过程从1-2小时缩短到了20分钟。
案例二：团队Backlog从“混乱”到“有序”
一个创业公司的产品 backlog 里有80多个Issue，有的是半年前提的，有的已经做完了但没关，有的描述模糊得没人看得懂。团队花了一个下午用/triage逐个过了一遍。AI对每个Issue做了冗余检查——发现有7个Issue描述的是同一个功能的不同表述，合并成了1个；发现有3个Issue在.out-of-scope/里有明确的否决记录，直接标记为wontfix；发现有十几个Issue信息严重不足，打上needs-info并自动生成了追问清单。一个下午之后，80多个Issue变成了40多个，而且每个都有清晰的状态标签。团队leader说了一句实在话：“不是AI替我们做了决定，是AI帮我们把‘该做什么决定’这件事变得清晰了。”
案例三：用AI智能体处理夜间Issue
一个维护者在欧洲，但项目的贡献者遍布全球。他睡觉的时候，亚洲和美洲的贡献者在不停地提Issue和PR。以前他每天早上醒来面对的是几十条未读通知，根本不知道哪些紧急、哪些可以放一放。
他配置了triage + 一个AFK AI智能体。夜间进来的所有新Issue，AI自动跑triage流程——检查冗余、检查历史否决、评估信息完整性——然后打上对应的状态标签。ready-for-agent的Issue，AI甚至可以直接开始处理（如果配置了对应的实现技能）。他早上醒来打开Issue列表，看到的是已经分好类的队列，而不是一团乱麻。
案例四：PR的自动化初筛
一个项目收到了一个外部贡献者的PR，改了200多行代码。维护者不确定这个PR质量如何、方向对不对、测试有没有过。他输入了/triage #89，AI读取了PR的完整diff、checkout了PR分支、运行了项目的测试套件、检查了diff是否真的做到了它所声称的。几分钟后AI给出了报告：“测试全部通过，diff实现了描述中的功能，建议标记为ready-for-human——代码质量良好，但涉及核心模块的变更建议人类review后merge。”
总结
triage解决的是一个在AI时代被放大了的问题：AI能干活，但AI不会判断“该干什么” 。
在单兵作战的场景下，这个问题不明显——你知道每件事的上下文和优先级。但在团队协作或开源维护的场景下，别人提的Issue到底是不是好主意？值不值得做？是不是早就被否决过？哪些已经足够清晰可以直接丢给AI？这些判断本质上是一道翻译工序。
triage的本质，就是把这道翻译工序标准化了。
两套角色体系：Category（是什么）+ State（怎么办）
清晰的状态流转：从
needs-triage到ready-for-agent或wontfix三桶视图：一眼看清该干什么
完整的triage工作流：收集上下文→代码库检查→推荐→验证→深度讨论
如果你在维护一个有外部输入的项目——无论是开源项目还是团队内部的需求池——triage可能是你装过的所有技能里，最能帮你把“混乱的待办队列”变成“有序的工作流”的那一个。
◯ 评论 0