本文为 AtomGit 码动四季·开源同行征稿活动参与文章摘要LLM 分诊解决 issue 的归类效率解决不了 issue 的命运。ArticlePilot 的分诊体系用分流页 三模板把三无issue 占比从 30% 压到 6%追问后石沉大海率从 57% 降到 20%首响从 2.7 天缩到 1.1 天。本文拆解体系四件模板怎么用必填四字段当过滤器、八个标签怎么保证人和机器说同一种语言、SLA 为什么只承诺自动化能兑现的部分、拒绝话术怎么决定漏斗宽度——以及必填字段、24 小时承诺、标签膨胀三个设计坑的完整复盘。系列写到第四篇时我在评论区收到一条留言大意是“你的机器人分类准确率 87%然后呢被标记成 bug 的 issue 还是没人理我的项目也是这样。”这条留言点中了 04 号文章的边界LLM 分诊解决的是 issue 的归类效率解决不了 issue 的命运——一个被正确分类的 issue如果没有模板约束信息质量、没有标签定义优先级、没有 SLA 兜底响应、没有 good first issue 通道转化为贡献它只是从乱糟糟的收件箱搬进了整整齐齐的收件箱。系列收官这篇讲分诊体系里机器不管的部分模板怎么设计、标签怎么定语义、SLA 怎么承诺、贡献者怎么不被吓跑。文中的模板和话术都是 ArticlePilot 仓库的实际在用版本不是设计稿。一、先看漏斗你的贡献者在哪一层流失分诊体系设计的第一步不是写模板是搞清楚人从哪里流失。开源项目的贡献者漏斗长这样四个流失点里前两个发生在 issue 环节——这正是分诊体系的地盘。后两个在任务认领和 PR review 环节本篇第八节会简要带过。我仓库开放 issue 后首月的真实数据把流失点照得清清楚楚23 个 issue 中“三无” issue无版本号、无复现步骤、无日志7 个其中 4 个在第一轮追问后发布者再没回复过——追问本身成了劝退动作3 个 feature 建议收到回复超过 48 小时其中 1 个明确表达了愿意自己写但因为没有任何任务认领机制这份热情没有着陆点。二、模板过滤器更是引导员2.1 三套模板 一道前置分流issue 模板的完整解不是三个模板文件而是分流页 三模板的结构。用户点New issue先看到的不是空白框而是分流页config.yml# .github/ISSUE_TEMPLATE/config.ymlblank_issues_enabled:falsecontact_links:-name:使用提问先查文档url:https://atomgit.com/{owner}/{repo}/discussionsabout:使用问题请到 Discussionsissue 只收缺陷报告与功能建议-name:常见问题 FAQurl:https://atomgit.com/{owner}/{repo}#faqabout:部署失败、Token 配置、平台适配等高频问题已有解法blank_issues_enabled: false是关键一刀不给空白 issue 入口。没有模板的 issue 就是三无预备役。前置分流把纯提问挡到 Discussions 后issue 区剩下的都是带着明确意图来的。2.2 bug 模板必填字段收敛到四个YAML 表单issue forms可以强制必填但必填项是双刃剑——约束越强完成率越低。我第一版的 bug 模板设了 7 个必填字段观察两周后发现表单放弃率高得反常有人宁可去 Discussions 发泄也不填表。收敛后的版本必填只剩四个# .github/ISSUE_TEMPLATE/bug_report.yml节选name:缺陷报告description:接口报错、页面异常、发布失败labels:[type:bug,status:needs-triage]body:-type:inputid:versionattributes:label:版本/commitdescription:填 Release 标签或运行 git rev-parse--short HEAD 的输出validations:required:true-type:textareaid:reproduceattributes:label:复现步骤description:从什么命令开始期望什么实际发生了什么validations:required:true-type:textareaid:logsattributes:label:报错日志/截图description:完整报错信息文本优于截图validations:required:true-type:dropdownid:osattributes:label:操作系统options:[macOS,Windows,Linux]validations:required:true被降级为选填的三项终端环境细节、仓库版本、补充截图——这些信息可以追问补齐不值得为它们劝退一个报障者。必填字段的判断标准缺了它就无法开始排查的才配 required。2.3 feature 模板里的钩子feature 模板比 bug 模板多设计了一个下拉字段-type:dropdownid:contribution-willingnessattributes:label:你愿意参与实现吗options:-只提建议希望维护者实现-愿意讨论方案-愿意自己提 PR可分配 good first issuevalidations:required:true这个钩子字段是首月数据教训的直接产物那个明确说愿意自己写的贡献者如果当时有这个字段他的 issue 会直接被标上good first issue并回复认领规则——一条现成的贡献者不需要任何额外运营动作。漏斗从提 issue跳到提 PR的最短路径就藏在这个下拉框里。三、标签体系两个维度八个语义标签标签是最容易被滥用成心情记录的治理工具。我删掉了第一版里 14 个随手建的标签重建为双维体系维度标签判定标准速查表type它是什么type:bug已复现或描述足以定位的缺陷type:feature新能力诉求type:question使用提问通常被分流到 Discussionstype:docs文档改进建议status它到哪了status:needs-triage新进件等待分诊status:waiting-info已追问等提交者补充status:confirmed确认有效进处理队列status:duplicate重复评论中关联原 issue第一维度没有 priority——这是我刻意砍掉的。一个人的维护带宽撑不起三维度而且没有兑现能力的优先级是负资产为什么砍坑 3 有完整复盘。任务难度维度用good first issue单独承担不进 status 流转。标签判定的一页速查表我直接钉在仓库docs/labels.md配合 04 号 bot 自动打标使用bot 的分类词表与这张速查表是同一份 YAML 源保证人和机器说同一种语言。从分流页到标签流转的完整通路——每个 issue 进来先过哪道门、贴哪张签四、SLA只承诺做得到的其余诚实说明我在 README 写了三条响应承诺每一条都先算过自己能否长期兑现承诺内容为什么敢承诺首响新 issue 72 小时内首次回复含分诊 bot 自动确认分诊自动化后确认收到环节零人工追问响应提交者补充信息后 72 小时内重新处理同上重分类是机器活修复排期不承诺具体修复时间只承诺 confirmed 的 issue 每周逐一过审并更新 status诚实单人维护排期承诺必然违约第三条是踩过坑才改成这样的。早期我写过高危问题 24 小时内修复——写的时候热血两周后就被一个 issue 的评论戳穿上次说的 24 小时呢SLA 的信用是不可再生资源违约一次之后所有承诺都会被按最坏预期解读。48 小时认领释放规则也属于这个体系good first issue被认领后 48 小时无动静bot 自动评论释放认领标签重新开放。规则公开写在 CONTRIBUTING.md机器执行无人情债。五、回复话术拒绝的温度决定贡献者的去留分诊体系里最考验人的不是流程是那几类必须说不的回复。三类高频拒绝场景我的在用话术追问信息对应status:waiting-info感谢反馈。要定位这个问题还需要补充1) 运行{version_cmd}的输出2) 从哪条命令开始复现。补齐后我会立即重新处理。可以参考文档的环境信息收集一节。指向重复对应status:duplicate这与 #{原编号} 是同一个问题我先关闭这条后续进展在原 issue 里更新。你的描述里提到的{补充细节}原 issue 没有覆盖已合并过去——感谢补充。拒绝 feature保持 open 或转 Discussions不轻易 close这个需求超出了本工具的定位{一句话定位}短期内不计划实现。不过你的场景很有价值我建议1) 移步 Discussions 的 ideas 区继续讨论2) 如果你有兴趣基于现有接口自己实现我可以协助设计接入方式。三条话术的共同结构先接住情绪或肯定价值 → 说清不的理由 → 给出下一步可走的路。拒绝 issue 的语言决定了贡献者是这次没成还是这个维护者傲慢——前一种人还会回来后一种会带着情绪走并且告诉别人。六、设计期的三个坑正文的坑展开的账前四节的每个设计决策背后都有一次返工把三笔账摊开坑 1bug 模板设 7 个必填字段两周换来高放弃率现象第一版 bug 模板 7 个必填字段观察两周发现表单放弃率高得反常——有人宁可去 Discussions 发泄也不填表。根因把我排查方便当成了设计目标忘了站在填表人一侧约束越强完成率越低。解决必填收敛到四个版本、复现步骤、日志、操作系统其余三项降级为选填、追问补齐判断标准定成一句话——缺了它就无法开始排查的才配 required。效果三无issue 占比从 30% 降到 6%追问后石沉大海率从 57% 降到 20%见第七节对比表。感受少三个必填字段换回一倍的表单完成意愿这买卖划算。教训模板的第一读者是报障的人不是排查的人。坑 2SLA 写了24 小时修复两周就被戳穿现象早期 README 承诺高危问题 24 小时内修复写的时候热血两周后一个 issue 的评论区出现一句上次说的 24 小时呢。根因承诺只有愿望没有核算——单人维护的修复排期根本不受自己控制必然违约。解决重写成三条可核算的承诺见第四节首响和追问响应交给自动化的部分敢承诺 72 小时修复排期只承诺confirmed 的 issue 每周逐一过审并更新 status。效果新承诺上线后零违约人工首响从 2.7 天缩到 1.1 天评论区再没出现过催账。感受SLA 被戳穿那次的难堪比任何一次发版事故都记得牢。教训SLA 的信用是不可再生资源违约一次之后所有承诺都会被按最坏预期解读。坑 3随手建了 14 个标签沦为心情记录现象第一版标签是遇到一个 issue 建一个攒到 14 个语义互相重叠——urgent和high并存wontfix和invalid分不清人和 bot 都没法按稳定语义消费。根因标签跟着当下情绪长没有维度设计更没有判定标准。解决全部删掉重建为 type status 双维八个见第三节速查表判定标准钉在docs/labels.md分诊 bot 的分类词表与这份速查表同源。效果人和机器说同一种语言bot 打标可复核顺手砍掉了没有兑现能力的 priority 维度——一个人的带宽撑不起三维度。感受标签多到记不住的那天我才承认治理工具的膨胀速度比治理对象快得多。教训标签少而准胜过多而全没有判定标准的标签建得越快烂得越快。七、效果漏斗前两层的数字变化体系模板 标签 SLA 话术上线前后各一个月的对比04 号的 bot 在两组数据里都在运行本表隔离的是体系设计的增量一个 issue 从进入分诊到关闭的完整生命周期是理解这套体系运作方式的最短路径体系模板 标签 SLA 话术上线前后各一个月的对比04 号的 bot 在两组数据里都在运行本表隔离的是体系设计的增量指标上线前上线后变化“三无” issue 占比30%7/236%1/17模板强制的直接效果追问后石沉大海率57%4/720%1/5追问话术 必填收敛issue 首响时长人工部分平均 2.7 天平均 1.1 天SLA 兜底 分诊减负feature 建议转认领0/32/4钩子字段 认领规则good first issue 平均停留26 天9 天难度校准 48h 释放石沉大海率的变化最说明问题从 57% 降到 20%。这 20% 里剩下的那一个我复盘时觉得是真心不用了的产品反馈——分诊体系能把被流程劝退的流失清干净但清不掉本来就不在乎的流失这是体系的合理边界。八、超越 issue认领与 review 环节的两个要点漏斗的后两个流失点不在 issue 区简要给出对策任务认领good first issue的准入必须校准——验收标准是贡献者凭 issue 描述本身就能开工不需要私聊维护者。我第一批 good first issue 里混进了一个需要理解全套目录结构才能做的任务认领者三天后留言放弃。此后每个任务打标前我先自问假设我完全不了解这个仓库能按这个 issue 做完吗不能就补描述补不出就不打标——标签信用比任务消化速度重要。PR reviewCONTRIBUTING.md 里公开 review 的默认时限一周内首次回应和合并标准CI 绿 符合 03 号的 commit 规范 02 号的 DCO sign-off。贡献者最怕的不是被拒是不知道自己的 PR 处于什么状态——时限公开后“遥遥无期变成下周三前一定有回音”。九、总结系列写到这里把我踩出来的四个结论留下。模板是过滤器更是引导员必填字段只留缺了没法干活的分流页替 issue 区挡掉纯提问。标签少而准胜过多而全两个维度八个标签每个都有可执行的判定标准人和机器共用一份词表。SLA 承诺做得到的信用不可再生宁可承诺得少不可违约一次。拒绝的话术决定漏斗的宽度每一句不都要给一条可以这么走。至此这个系列收尾01 把仓库洗干净开源02 定好法律边界03 让发版零人工04 让机器管筛选05 让每个进来的人不被晾着。一个人维护的仓库靠这套组合做到响应比很多团队项目还快——不是因为我更勤奋是因为每个环节只让机器做它擅长的人只出现在必须人在场的地方。你的 issue 首响时长是多少作为贡献者你被晾过最久的一次是多久评论区对个数。真实性声明本文模板、标签表、话术均为 ArticlePilot 仓库地址见文末实际在用版本对比数据来自平台后台两个自然月的统计样本量已注明钩子字段与 48 小时释放规则为真实上线功能。文中引用的留言经当事人授权概括转述已脱敏。开源仓库地址ArticlePilot本文分诊体系的落地案例含 issue 模板、标签词表与 04 号的三件套治理配置https://atomgit.com/dickeryang/articlepilot参考资源GitHub issue forms 官方文档Open Source Guides: Best Practices本系列上一篇的自动化底座04 用 AI 机器人治理开源仓库专栏导航上一篇用 AI 机器人治理开源仓库三件套落地下一篇AI 编程助手从企业走向开源社区选型决策矩阵与落地避坑指南如果本文对你有帮助欢迎点赞、收藏、转发。有任何问题或建议请在评论区留言交流。行文仓促定有不足之处欢迎各位朋友在评论区批评指正不胜感激。