给 GitHub issue 分诊，听起来是件没技术含量的小事。读一眼标题，贴个标签，丢给对应团队，完事。PyTorch 这种一天几十个 issue 的仓库，居然专门为这事做了一个 skill，还上了 Smithery 平台。乍看是小题大做，读完才明白，分诊这事比想象中门槛高得多，贴错一个标签，issue 就得在错误的队列里躺上好几天。
多数人对 triage 的默认想象，就是「读标题、匹配关键词、贴标签」。但翻完这份 SKILL.md，我发现它的重心恰好相反：大量规则在约束「不做什么」。哪些 issue 要直接跳过，哪些要转走，哪些要停下来交给人类。这个 skill 的价值，恰恰藏在那些「停手」的决策里。
从 SKILL.md 的结构来看，它是一份可执行的决策树。用四个 GitHub MCP 工具落地，再靠一个 PreToolUse hook 强制标签只能在白名单里选。它不是生成器，不替你写一个字，它是把 PyTorch 维护者脑子里那套隐式规则，显式化成一条条可以照着走的判断流程。这种「把隐性知识写成可执行规则」的定位，正是它区别于普通自动 bot 的地方。
整条链路可以压成一句话：先判断该不该管（跳过或转走），再判断怎么标（按根因贴标签），最后决定要不要交人（人工复审）。每一步都在做减法，这是它跟市面上那些「全自动贴标签」的通用 bot 最根本的区别。
工作流拆解
流程从 Step 0 开始，规则就一句话：issue 已经带 oncall 标签就直接跳过，什么都不做。这条反直觉。多数人以为 bot 应该「多多益善」，但它认为已归属的 issue 属于子团队自己的队列，你插手反而是添乱。克制从第一行就立起来了。
Step 1 是分类。先分清楚这是使用问题，还是 bug 或 feature。纯使用问题直接关闭，用 redirect_to_forum 模板指到 discuss.pytorch.org；分不清的，用 request_more_info 模板要更多信息，然后停。注意它的动作是「问完就停」，不是「问完继续猜」，这个分寸感很关键。
Step 1.5 是个安全分支。检查 issue 正文里有没有需要下载才能复现的外部文件，判断依据是三类特征：
-
附件： .zip、.pt、.pth、.pkl这类文件 -
网盘：Google Drive、Dropbox、OneDrive 的分享链接 -
模型：Hugging Face Hub 上的模型文件
命中了就把正文里的下载链接抹掉，换成安全提示，再要求用户给一个自包含的复现脚本，然后等。这一步不贴 triaged，等于把球踢回给用户。
Step 2 到 3 是「转诊」环节。属于 vision、text、audio 这些子库的，转走；PT2 是特例，不是转走而是继续走完整流程；其余 oncall 贴一个标签后立刻停，不再贴 module 标签。路由规则的核心是：子团队拥有自己的队列，你只负责把 issue 送到门口。常见的转诊目标可以列成一张表：
| oncall 标签 | 适用场景 |
|---|---|
oncall: distributed |
DDP、FSDP、RPC、DTensor 等分布式 |
oncall: jit |
TorchScript |
oncall: export |
torch.export |
oncall: quantization |
量化 |
oncall: mobile |
iOS/Android，不含 ExecuTorch |
oncall: profiler |
CPU/GPU/Kineto profiler |
Step 4、5、7 是收尾。留在主队列的 issue 才开始贴 module 标签，并主动排查几类「最容易被漏掉」的标签：
Segfault / 非法内存访问 → module: crash
性能回归 / 优化请求 → module: performance
Windows 平台专属 → module: windows
曾可用、现损坏 → module: regression
反向传播 bug → module: autograd（叠加 op 模块）
碰到疑似高优先级，只加 triage review 交人工确认，绝不直接加 high priority。最后才轮到 triaged。
把这串决策点串起来，能看到一个清晰的模式：能不做就不做，能做一半就不做满，宁可不做也不做错。整个流程的骨架用一张图来看更直观。
架构解析
落地层是四个 GitHub MCP 工具，权限被刻意收窄了，能读的多、能写的少：
issue_read 读详情、评论、已有标签
issue_write 贴标签或关闭 issue
add_issue_comment 仅在转走问题时评论
search_issues 找相似 issue 补上下文
这个 skill 最硬核的设计在 hook 层。一个 PreToolUse hook 会校验每一个要贴的标签，是否在 labels.json 白名单里，不在就拦下来。这意味着「贴错标签」在机制上就不可能发生，而不是靠模型自觉。这是规则硬编码，不是 prompt 劝告。
数据层由三个文件撑起。labels.json 是可贴标签全集，主动排除了 CI 触发、test config、release notes 这些 triage 不该碰的标签；templates.json 是标准回复模板；pt2-triage-rubric.md 是 PT2 专属标注指南。除白名单外，它还有一份「永不加」清单，把这些需要人拍板的标签挡在门外：
-
sev 级别、merge blocking：需人拍板 -
actionable、needs reproduction：留给 reviewer -
任何含 deprecated 的标签：已废弃
规则和数据分离，改规则不用动流程本身。
一前一后两个 hook 构成了闭环。前面 PreToolUse 拦标签，后面 post-hook 自动贴 bot-triaged 标记。把「校验」和「记账」都自动化了，留给模型的是中间那段真正的判断。这个分工非常干净，也解释了为什么它敢把很多事交给规则。
从架构推断，设计者的核心意图是「让模型做判断，让机制做约束」。判断这件事（是 bug 还是 question）交给模型，约束（只能贴白名单标签、高优先级必须人工确认）交给 hook 和规则。这比把一切都塞进 prompt 里可靠得多。
使用场景
它最核心的用途，是处理 pytorch/pytorch 仓库的新 issue 洪峰。PyTorch 每天的 issue 量足够大，人工分诊是重体力活，而这一步恰好是规则清晰、判断边界明确的部分。把这种「量大但规则清楚」的活交给 skill，是它最合适的位置。
路由规则里藏着一堆只有 PyTorch 维护者才知道的隐性知识。MPS 不是 mobile，DTensor 走 distributed，ONNX 没有 oncall 只贴 module，CI 问题用 module: ci 而不是 oncall: releng。这些细则写进硬规则后，新人或外部贡献者也能按图索骥，不再靠老人传帮带。
对照 labels.json 贴标签这件事，对不熟 PyTorch 模块划分的人价值最大。sdpa 该贴 module: sdpa 而不是 module: nn，flex attention 同理。这种「具体标签优先于通用标签」的判断，恰恰是翻文档最花时间的部分，skill 把答案提前给好了。
它的局限也得说清楚。这份东西深度绑定 PyTorch 的 oncall 结构和 labels.json，换个仓库基本要重做路由表和标签库。别指望拿来就能给别的项目分诊，它是一份为 pytorch/pytorch 定制的产物，不是通用分诊框架。
另一个局限是依赖。它依赖 GitHub MCP 工具和 Smithery 那套 hook 基础设施，不是能独立跑的脚本。而且分诊本身是规则驱动，边界 case 还是要靠 Step 5 的人工复审兜底。它的适用边界，一句话概括就是：
-
适合：规则明确、量大、贴错标签代价低的场景 -
不适合：判断模糊、量小、出错代价高的场景
洞察与反思
Step 1.6 是全篇最精彩的一段，讲的是一条硬原则：按根因贴标签，不按关键词贴。import torch 报 ncclAlltoAll 是打包问题，贴 module: binaries，不是分布式 bug；参数名里带 nan，不代表 module: NaNs and Infs；栈里出现 autograd，不代表 module: autograd。
这条为什么重要？因为关键词匹配是绝大多数自动分诊的捷径，也是翻车率最高的地方。关键词只能告诉你「哪里报错了」，根因才能告诉你「该谁修」。这个 skill 用一个反问句统一了判断标准：修复要落在哪个模块，就贴哪个模块的标签。
把它和那些按 maintainers 名单加关键词规则自动 assign 的通用 GitHub bot 放一起，差异在克制。那些 bot 追求覆盖率和自动化率，这个 skill 追求不犯错。它宁可停手交人，也不贴一个不确定的标签。这是两种完全不同的工程哲学。
我一开始以为，好的自动化 skill 应该「尽量自动化」。读完反而被说服：它的高明之处是精确圈定了自动化的边界。那些「不做」的决策，比「做」更考验设计功力。真正的工程能力，体现在知道哪里该停。
从作者标识看，这是 pytorch 组织在 Smithery 上维护的官方 skill，跟之前那篇 docstring 是同一批出品。把维护经验 codify 成 skill，比写成 wiki 强在可执行：规则能直接驱动工具，而不是躺在文档里等人看。一个组织连「分诊」这种运维杂活都愿意沉淀成可复用 skill，本身就说明 Skills 生态正在从个人玩具，走向组织级的基础设施。
资源地址
| 资源 | 地址 |
|---|---|
| Smithery 页面 | https://smithery.ai/skills/pytorch/triaging-issues |
| labels.json 标签白名单 | https://smithery.ai/skills/pytorch/labels.json |
| pt2-triage-rubric.md | https://smithery.ai/skills/pytorch/pt2-triage-rubric.md |
| templates.json 回复模板 | https://smithery.ai/skills/pytorch/templates.json |
| PyTorch 仓库 | https://github.com/pytorch/pytorch |
总结
这个 skill 本质上做了一件事：把 PyTorch issue 分诊的隐性规则，写成一条「先判断该不该管、再判断怎么标、最后决定要不要交人」的可执行决策树，再用 hook 把约束钉死在机制层面。
如果你在维护 pytorch/pytorch，或者想搞清楚官方 issue 是怎么流转的，值得精读它的 SKILL.md 和 labels.json。如果你想要一个通用的 issue bot，直接抄代码会失望，但它的设计思想，白名单 hook、根因标签、人工复审门，这三样值得搬到任何项目里。
最后留一个问题。当约束能靠 hook 硬编码、判断能靠规则穷举时，大模型在这个流程里还剩什么价值？这个 skill 的答案是，只做分类和根因判断，其余交给机制。这个边界划得对不对，是它最值得琢磨的地方。