1. 为什么我要把 Issue 分诊这件事交给机器维护过开源项目的人都有一个共同体会写代码本身不累累的是每天打开仓库通知栏看到十几条新 Issue 躺在那里标题五花八门内容质量参差不齐。有的只写了一句用不了求修复有的把使用问题当成 Bug 报有的其实是重复提交还有的干脆是广告。真正需要你花脑力去判断的可能只占三成剩下七成都是重复性的脏活。我维护的项目规模不算大但每天稳定进来五到十条 Issue。最开始我坚持人工处理每条都认真读、认真回、认真打标签。坚持了两个月之后我发现自己花在分诊上的时间已经超过了写核心功能的时间而且情绪消耗极大——面对一条信息量为零的 Issue你很难保持耐心。更麻烦的是有些 Issue 放了两三天才看到提交者已经失去耐心在评论区开始抱怨没人管。这就是我做这个 Issue 分诊助手的直接动机把第一轮筛选、分类、打标签、回复引导这些机械动作交给 AI人只处理真正需要判断力的部分。它不是一个自动关闭 Issue 的机器人而是一个帮你把脏活干完、把干净的信息递到你面前的助手。这篇文章我会完整讲清楚这套系统的设计思路、核心模块、提示词工程细节、踩过的坑以及实测下来的效果边界。适合正在维护开源项目、内部工具仓库或者任何需要处理大量用户反馈的开发者参考。哪怕你只是想了解怎么把大模型接进日常研发流程这里面的思路也能直接迁移。先说结论这套东西上线之后我每天处理 Issue 的时间从平均 40 分钟压缩到 10 分钟以内重复 Issue 的识别准确率在实测样本里能到八成以上标签自动打准的比例大概七成。它不是万能的但确实把最烦人的那部分工作接走了。2. 分诊助手到底要解决哪几件事在动手写代码之前我花了整整一个晚上把过去三个月的 Issue 全部翻了一遍做了一次人工归类。这一步非常关键因为如果你不清楚脏活具体脏在哪里后面设计出来的自动化流程一定是拍脑袋的。2.1 把 Issue 按处理动作而不是内容主题分类大多数人第一反应是按内容分类这是 Bug、那是功能请求、那是使用问题。但真正决定你工作量的不是内容主题而是你需要对它做什么动作。我最后归纳出五类处理动作动作类型典型特征人工耗时直接关闭广告、无意义内容、明显跑题低但烦引导补充信息缺失无法复现中标记重复与已有 Issue 高度相似中转交讨论区使用问题而非缺陷低进入待办真实有效的 Bug 或需求高价值这个分类方式直接决定了后面 AI 的输出结构。我要的不是一个这条 Issue 讲的是什么的摘要而是一个这条 Issue 该走哪条流水线的决策。2.2 第一轮分诊的三个硬性产出经过反复调整我把助手的输出锁定为三个必须产出的东西缺一不可分类标签对应上面五类动作之一外加一个置信度。结构化摘要用固定字段把 Issue 里的关键信息抽出来比如复现步骤、环境信息、期望行为、实际行为。建议回复一段可以直接复制粘贴的引导语针对信息缺失类特别有用。为什么一定要有置信度因为这是人机协作的关键。置信度高的我直接采纳置信度低的我自己看一眼。没有置信度我就得逐条复核那自动化就失去意义了。2.3 明确划出AI 不碰的红线这一点我想单独强调。分诊助手再聪明也有它绝对不该碰的地方任何涉及关闭 Issue、修改 Issue 状态、 提交者的操作一律由人来做。AI 只负责生成建议不负责执行。我见过一些项目做了全自动关闭机器人结果误伤真实用户口碑崩得很快。分诊的价值在于减负不在于替代判断。把执行权留给人是这套系统能长期用下去的前提。3. 系统骨架从 Webhook 到建议卡片的数据流整套系统的架构其实不复杂核心就是一条单向流水线。我刻意把它设计得很笨因为越简单的链路越不容易出问题。3.1 触发与拉取为什么用轮询而不是实时 Webhook理论上最优雅的方案是监听仓库的 WebhookIssue 一创建就触发处理。但我实测下来选择了定时轮询每五分钟拉一次最近更新的 Issue 列表。原因有三个第一Webhook 需要暴露一个公网可访问的接收端点对个人项目来说运维成本偏高还要处理签名校验、重放攻击这些安全细节。第二Issue 创建后往往几分钟内提交者还会补充编辑实时处理容易拿到半成品。第三轮询天然具备补偿能力某次处理失败下一轮会自动重试不需要额外做失败队列。轮询的代价是延迟但对分诊场景来说五分钟延迟完全可以接受。我用一个简单的状态标记来避免重复处理每条 Issue 处理完后在本地数据库里记录它的更新时间戳下一轮只处理时间戳变化的。def fetch_new_issues(repo, last_check): issues repo.get_issues(stateopen, sincelast_check) return [i for i in issues if i.updated_at last_check]3.2 预处理把 Issue 变成模型能吃的干净文本原始 Issue 直接丢给模型效果很差因为里面混着大量噪声签名档、无关的截图链接、大段日志、引用回复。我做了三层清洗截断正文超过 4000 字符的部分直接砍掉只保留开头。实测发现绝大多数有效信息都在前 2000 字里后面的多是日志堆砌。剥离代码块把 包裹的内容替换成占位符[CODE_BLOCK]避免模型把日志当成自然语言去理解也省 token。提取元信息把 Issue 的标题、标签、提交者历史 Issue 数量单独抽出来作为额外信号。这里有个细节值得说提交者历史 Issue 数量是个被低估的信号。一个第一次提 Issue 的新用户信息不全的概率远高于老用户。我把这个数字作为特征喂给模型让它对新手更宽容、对老手更严格。3.3 模型调用结构化输出是唯一正确的姿势我踩过的最大坑就是一开始让模型自由发挥输出一段分析文字。结果每次格式都不一样后面根本没法程序化解析。后来我强制要求模型输出 JSON并且用 schema 约束字段。{ category: duplicate | needs_info | question | valid | spam, confidence: 0.0, summary: { reproduce_steps: ..., environment: ..., expected: ..., actual: ... }, suggested_reply: ..., duplicate_candidates: [#123, #456] }用 JSON 输出的另一个好处是我可以在提示词里明确告诉模型每个字段的含义和取值范围模型输出的稳定性会明显提升。实测下来加了 schema 约束之后解析失败率从接近两成降到了 2% 以下。4. 提示词工程让模型稳定干活的几个关键设计这部分是整套系统的灵魂。同样的模型提示词写得好和写得烂效果差距是数量级的。我前后迭代了十几版提示词下面几个设计是我认为最有效的。4.1 用角色 任务 约束 示例四段式搭骨架我的提示词结构固定为四块顺序不能乱角色设定明确告诉模型它是一个经验丰富的开源项目维护者助手而不是通用助手。角色越具体输出越贴合场景。任务描述逐条列出要它做的事用编号不要用大段文字。硬性约束比如不确定时置信度必须低于 0.5不要编造 Issue 里没有的信息。少样本示例给两到三个输入输出对覆盖典型场景。少样本示例这块我要多说一句。很多人觉得大模型现在很聪明不需要给例子。但在分诊这种需要稳定格式的任务上示例的作用不是教模型做事而是锚定输出风格。我给的示例里特意包含了一个信息严重缺失的案例模型看到之后对这类 Issue 的处理明显更到位。4.2 置信度不是让模型感觉而是给它可计算的依据一开始我让模型直接输出一个 0 到 1 的置信度结果它给的值基本都在 0.8 到 0.95 之间毫无区分度。后来我改成让模型先回答几个判断问题再根据答案推导置信度Issue 里是否包含明确的复现步骤是否包含环境信息版本号、操作系统等描述是否与标题一致是否能在已有 Issue 列表里找到高度相似的每个问题回答是加一定分值最后归一化成置信度。这样得到的数值有实际依据区分度也上来了。实测中真正需要人工介入的 Issue置信度普遍落在 0.4 到 0.6 区间和我的直觉判断吻合度很高。4.3 重复检测先召回再精排别指望模型一步到位重复 Issue 检测是最难的部分。我一开始让模型直接对比新 Issue 和所有历史 Issue结果 token 爆炸而且准确率很差。后来改成两阶段第一阶段召回用简单的文本相似度比如标题的词集合 Jaccard 相似度从历史 Issue 里筛出 Top 10 候选。这一步很快纯字符串计算不消耗模型调用。第二阶段精排把这 10 个候选的标题和摘要喂给模型让它判断哪个是真正的重复并给出理由。这个两阶段设计把模型调用量降了一个数量级准确率反而更高。因为模型不用在几百条里大海捞针只需要在 10 个候选里做精细判断注意力更集中。提示召回阶段宁可多召回不要漏。我一开始把相似度阈值设得很高结果真正的重复 Issue 根本没进候选列表后面精排再准也没用。后来把阈值调低召回 10 条里哪怕只有 1 条是对的也比漏掉强。4.4 建议回复的语气控制建议回复是直接面向用户的语气很重要。我在提示词里明确要求不使用你的 Issue 不合格这类指责性表述先肯定用户提交反馈的行为用清单形式列出需要补充的信息结尾给出一个明确的下一步实测下来带这种引导回复的 Issue用户补充信息的比例比冷冰冰的模板高出不少。这说明分诊助手不只是减轻维护者负担也在改善整个社区的沟通氛围。5. 实测中的意外情况与踩坑记录系统上线之后我记录了两周的实际运行数据也踩了不少坑。这部分可能是最有价值的内容因为很多问题只有真正跑起来才会暴露。5.1 模型对中文口语化描述的误判我遇到过一个典型案例用户写这个东西点了没反应是不是坏了。模型把它分类成了信息缺失置信度 0.45。但实际上这条 Issue 后面附了一段完整的录屏和日志只是正文写得很口语化。问题出在哪模型过度依赖正文文本忽略了附件信息。我的修复方案是在预处理阶段把是否包含附件作为一个显式特征写进提示词并且在示例里加了一个正文简短但有附件的案例。改完之后这类误判明显减少。这个坑给我的教训是模型看到的信息和你以为它看到的信息可能不是一回事。预处理阶段一定要把关键信号显式化不能指望模型自己去发现。5.2 重复检测的假阳性比假阴性更烦人假阴性是漏掉重复假阳性是把不重复的判成重复。我原以为漏掉重复更严重实测下来恰恰相反假阳性对用户体验的伤害更大。因为一旦系统提示这条可能是 #123 的重复用户会觉得你根本没认真看我的问题情绪立刻上来。所以我在精排阶段加了一条硬约束只有当模型能明确说出两条 Issue 的核心问题相同时才标记为重复。如果只是主题相关一律不标。宁可漏不可错。5.3 长 Issue 的截断策略需要按段落而不是按字符我最初按字符数截断结果经常把关键信息砍掉。后来改成按段落截断优先保留包含复现步骤环境版本等关键词的段落其余段落按顺序填充直到达到长度上限。这个改动看起来小但对摘要质量的影响很大。因为 Issue 的有效信息往往集中在某几个特定段落按字符截断很容易正好错过它们。5.4 成本控制不是每条 Issue 都值得调用大模型跑了两周之后我看了一下账单发现成本比预期高。复盘之后发现有相当一部分 Issue 是明显的广告或垃圾内容根本不需要动用大模型。我的优化方案是加一层轻量预筛用关键词黑名单和简单的规则比如正文长度小于 10 个字符、包含大量链接先过滤掉明显无效的内容剩下的才进模型。这一层过滤掉了大约 15% 的调用量而且几乎不影响准确率。优化项优化前优化后日均模型调用次数约 120 次约 95 次单条平均 token 消耗约 1800约 1200解析失败率约 18%约 2%6. 把建议卡片递到人面前交互层的设计取舍模型跑通只是第一步真正决定这套系统好不好用的是它怎么把结果呈现给人。我试过三种方案最后选了最朴素的一种。6.1 三种呈现方案的对比方案 A直接写回 Issue 评论。优点是用户立刻能看到引导。缺点是风险极高一旦模型判断错误错误信息已经公开可见撤回成本大。方案 B发到即时通讯群。优点是实时。缺点是信息流太快容易被淹没而且和 Issue 本身割裂。方案 C生成一张本地建议卡片人工确认后再操作。这是我最终选的方案。方案 C 的核心思路是AI 的输出永远先进入一个待确认的中间态由人决定是否采纳。这个中间态可以是一个本地网页、一个命令行工具甚至一个 Markdown 文件。我用的是一个简单的本地看板每条 Issue 一张卡片显示分类、置信度、摘要和建议回复旁边有采纳修改忽略三个按钮。6.2 卡片上必须显示的信息一张好的建议卡片要让人在五秒内做出判断。我最后保留的字段是Issue 标题和链接方便快速跳转分类标签和置信度用颜色区分高置信度绿色低置信度黄色三行以内的摘要超过三行说明摘要没做好建议回复的预览可折叠重复候选列表如果有我特意去掉了模型分析理由这个字段。一开始我觉得理由很重要能帮我判断模型是否靠谱。但实际用下来发现理由太长我根本不看反而干扰视线。真正需要理由的时候我会点进 Issue 自己看。6.3 采纳率反馈闭环我在看板上加了一个简单的统计每天采纳了多少条、修改了多少条、忽略了多少条。这个数据非常有用它是我判断提示词是否需要迭代的核心依据。如果某类 Issue 的修改率特别高说明模型在这类场景上判断不准我就去翻具体案例针对性调整提示词或补充示例。这个反馈闭环让系统能持续进化而不是上线即巅峰然后慢慢退化。7. 这套系统适合谁以及它的能力边界写到这里我想诚实地聊聊这套系统的适用范围。它不是银弹用错场景反而添乱。7.1 适合的场景个人或小团队维护的开源项目Issue 量在每天几条到几十条之间人工处理有压力但又不至于需要专职人员。内部工具仓库同事提的反馈质量参差不齐需要统一引导。任何需要处理大量非结构化用户反馈的场景思路可以迁移到工单分诊、用户反馈归类等。7.2 不适合的场景Issue 量极少的项目一天不到一条人工处理比搭系统快。对实时性要求极高的场景轮询有延迟不适合秒级响应。完全无人值守的自动化我始终坚持人在回路全自动关闭 Issue 这类操作风险太大。7.3 一个容易被忽略的边界模型的知识截止模型对项目本身的历史、约定、术语是不了解的。比如项目里有个约定俗成的缩写模型可能完全看不懂。我的应对方式是在提示词里加一段项目背景说明把关键术语和约定写进去。这段说明不长但对准确率的提升很明显。提示项目背景说明要定期更新。我一开始写了一次就没管后来项目加了新模块模型对新模块相关的 Issue 判断明显变差排查半天才发现是背景说明过期了。8. 我实际用下来最想分享的几条经验最后这部分我想抛开技术细节聊聊这套系统跑了两周之后我个人最真实的几点体会。第一分诊助手的价值不在于准而在于稳。它不需要每条都判断对它需要的是每天稳定地把脏活干完让你打开看板时面对的是已经整理好的信息而不是一堆原始 Issue。这种确定性本身就是巨大的减负。第二提示词的迭代是长期工作不是一次性投入。我到现在还在每周微调提示词因为项目在变、用户在变、Issue 的类型也在变。把它当成一个需要持续维护的产品而不是一个写完就扔的脚本。第三保留人工确认这一步是这套系统能长期用下去的关键。我见过太多自动化工具因为一次误判就被弃用。人在回路不是效率的妥协而是信任的基础。用户知道最终决定是人做的对系统的容忍度也会更高。第四别追求一步到位。我最开始的版本只做了分类连摘要都没有但已经能帮我省下不少时间。后面才逐步加上摘要、重复检测、建议回复。每加一个功能都基于实际痛点而不是看起来应该要有。如果你也在被 Issue 淹没我建议你先从最小版本开始一个轮询脚本、一段提示词、一个本地看板。跑起来看数据再迭代。这套东西的门槛比想象中低但带来的改变比想象中大。 
长河君 · 2026/10/16 11:06:56 · 阅读 1.2k AI驱动的Issue分诊助手：从设计到落地的工程实践
1. 为什么我要把 Issue 分诊这件事交给机器维护过开源项目的人都有一个共同体会写代码本身不累累的是每天打开仓库通知栏看到十几条新 Issue 躺在那里标题五花八门内容质量参差不齐。有的只写了一句用不了求修复有的把使用问题当成 Bug 报有的其实是重复提交还有的干脆是广告。真正需要你花脑力去判断的可能只占三成剩下七成都是重复性的脏活。我维护的项目规模不算大但每天稳定进来五到十条 Issue。最开始我坚持人工处理每条都认真读、认真回、认真打标签。坚持了两个月之后我发现自己花在分诊上的时间已经超过了写核心功能的时间而且情绪消耗极大——面对一条信息量为零的 Issue你很难保持耐心。更麻烦的是有些 Issue 放了两三天才看到提交者已经失去耐心在评论区开始抱怨没人管。这就是我做这个 Issue 分诊助手的直接动机把第一轮筛选、分类、打标签、回复引导这些机械动作交给 AI人只处理真正需要判断力的部分。它不是一个自动关闭 Issue 的机器人而是一个帮你把脏活干完、把干净的信息递到你面前的助手。这篇文章我会完整讲清楚这套系统的设计思路、核心模块、提示词工程细节、踩过的坑以及实测下来的效果边界。适合正在维护开源项目、内部工具仓库或者任何需要处理大量用户反馈的开发者参考。哪怕你只是想了解怎么把大模型接进日常研发流程这里面的思路也能直接迁移。先说结论这套东西上线之后我每天处理 Issue 的时间从平均 40 分钟压缩到 10 分钟以内重复 Issue 的识别准确率在实测样本里能到八成以上标签自动打准的比例大概七成。它不是万能的但确实把最烦人的那部分工作接走了。2. 分诊助手到底要解决哪几件事在动手写代码之前我花了整整一个晚上把过去三个月的 Issue 全部翻了一遍做了一次人工归类。这一步非常关键因为如果你不清楚脏活具体脏在哪里后面设计出来的自动化流程一定是拍脑袋的。2.1 把 Issue 按处理动作而不是内容主题分类大多数人第一反应是按内容分类这是 Bug、那是功能请求、那是使用问题。但真正决定你工作量的不是内容主题而是你需要对它做什么动作。我最后归纳出五类处理动作动作类型典型特征人工耗时直接关闭广告、无意义内容、明显跑题低但烦引导补充信息缺失无法复现中标记重复与已有 Issue 高度相似中转交讨论区使用问题而非缺陷低进入待办真实有效的 Bug 或需求高价值这个分类方式直接决定了后面 AI 的输出结构。我要的不是一个这条 Issue 讲的是什么的摘要而是一个这条 Issue 该走哪条流水线的决策。2.2 第一轮分诊的三个硬性产出经过反复调整我把助手的输出锁定为三个必须产出的东西缺一不可分类标签对应上面五类动作之一外加一个置信度。结构化摘要用固定字段把 Issue 里的关键信息抽出来比如复现步骤、环境信息、期望行为、实际行为。建议回复一段可以直接复制粘贴的引导语针对信息缺失类特别有用。为什么一定要有置信度因为这是人机协作的关键。置信度高的我直接采纳置信度低的我自己看一眼。没有置信度我就得逐条复核那自动化就失去意义了。2.3 明确划出AI 不碰的红线这一点我想单独强调。分诊助手再聪明也有它绝对不该碰的地方任何涉及关闭 Issue、修改 Issue 状态、 提交者的操作一律由人来做。AI 只负责生成建议不负责执行。我见过一些项目做了全自动关闭机器人结果误伤真实用户口碑崩得很快。分诊的价值在于减负不在于替代判断。把执行权留给人是这套系统能长期用下去的前提。3. 系统骨架从 Webhook 到建议卡片的数据流整套系统的架构其实不复杂核心就是一条单向流水线。我刻意把它设计得很笨因为越简单的链路越不容易出问题。3.1 触发与拉取为什么用轮询而不是实时 Webhook理论上最优雅的方案是监听仓库的 WebhookIssue 一创建就触发处理。但我实测下来选择了定时轮询每五分钟拉一次最近更新的 Issue 列表。原因有三个第一Webhook 需要暴露一个公网可访问的接收端点对个人项目来说运维成本偏高还要处理签名校验、重放攻击这些安全细节。第二Issue 创建后往往几分钟内提交者还会补充编辑实时处理容易拿到半成品。第三轮询天然具备补偿能力某次处理失败下一轮会自动重试不需要额外做失败队列。轮询的代价是延迟但对分诊场景来说五分钟延迟完全可以接受。我用一个简单的状态标记来避免重复处理每条 Issue 处理完后在本地数据库里记录它的更新时间戳下一轮只处理时间戳变化的。def fetch_new_issues(repo, last_check): issues repo.get_issues(stateopen, sincelast_check) return [i for i in issues if i.updated_at last_check]3.2 预处理把 Issue 变成模型能吃的干净文本原始 Issue 直接丢给模型效果很差因为里面混着大量噪声签名档、无关的截图链接、大段日志、引用回复。我做了三层清洗截断正文超过 4000 字符的部分直接砍掉只保留开头。实测发现绝大多数有效信息都在前 2000 字里后面的多是日志堆砌。剥离代码块把 包裹的内容替换成占位符[CODE_BLOCK]避免模型把日志当成自然语言去理解也省 token。提取元信息把 Issue 的标题、标签、提交者历史 Issue 数量单独抽出来作为额外信号。这里有个细节值得说提交者历史 Issue 数量是个被低估的信号。一个第一次提 Issue 的新用户信息不全的概率远高于老用户。我把这个数字作为特征喂给模型让它对新手更宽容、对老手更严格。3.3 模型调用结构化输出是唯一正确的姿势我踩过的最大坑就是一开始让模型自由发挥输出一段分析文字。结果每次格式都不一样后面根本没法程序化解析。后来我强制要求模型输出 JSON并且用 schema 约束字段。{ category: duplicate | needs_info | question | valid | spam, confidence: 0.0, summary: { reproduce_steps: ..., environment: ..., expected: ..., actual: ... }, suggested_reply: ..., duplicate_candidates: [#123, #456] }用 JSON 输出的另一个好处是我可以在提示词里明确告诉模型每个字段的含义和取值范围模型输出的稳定性会明显提升。实测下来加了 schema 约束之后解析失败率从接近两成降到了 2% 以下。4. 提示词工程让模型稳定干活的几个关键设计这部分是整套系统的灵魂。同样的模型提示词写得好和写得烂效果差距是数量级的。我前后迭代了十几版提示词下面几个设计是我认为最有效的。4.1 用角色 任务 约束 示例四段式搭骨架我的提示词结构固定为四块顺序不能乱角色设定明确告诉模型它是一个经验丰富的开源项目维护者助手而不是通用助手。角色越具体输出越贴合场景。任务描述逐条列出要它做的事用编号不要用大段文字。硬性约束比如不确定时置信度必须低于 0.5不要编造 Issue 里没有的信息。少样本示例给两到三个输入输出对覆盖典型场景。少样本示例这块我要多说一句。很多人觉得大模型现在很聪明不需要给例子。但在分诊这种需要稳定格式的任务上示例的作用不是教模型做事而是锚定输出风格。我给的示例里特意包含了一个信息严重缺失的案例模型看到之后对这类 Issue 的处理明显更到位。4.2 置信度不是让模型感觉而是给它可计算的依据一开始我让模型直接输出一个 0 到 1 的置信度结果它给的值基本都在 0.8 到 0.95 之间毫无区分度。后来我改成让模型先回答几个判断问题再根据答案推导置信度Issue 里是否包含明确的复现步骤是否包含环境信息版本号、操作系统等描述是否与标题一致是否能在已有 Issue 列表里找到高度相似的每个问题回答是加一定分值最后归一化成置信度。这样得到的数值有实际依据区分度也上来了。实测中真正需要人工介入的 Issue置信度普遍落在 0.4 到 0.6 区间和我的直觉判断吻合度很高。4.3 重复检测先召回再精排别指望模型一步到位重复 Issue 检测是最难的部分。我一开始让模型直接对比新 Issue 和所有历史 Issue结果 token 爆炸而且准确率很差。后来改成两阶段第一阶段召回用简单的文本相似度比如标题的词集合 Jaccard 相似度从历史 Issue 里筛出 Top 10 候选。这一步很快纯字符串计算不消耗模型调用。第二阶段精排把这 10 个候选的标题和摘要喂给模型让它判断哪个是真正的重复并给出理由。这个两阶段设计把模型调用量降了一个数量级准确率反而更高。因为模型不用在几百条里大海捞针只需要在 10 个候选里做精细判断注意力更集中。提示召回阶段宁可多召回不要漏。我一开始把相似度阈值设得很高结果真正的重复 Issue 根本没进候选列表后面精排再准也没用。后来把阈值调低召回 10 条里哪怕只有 1 条是对的也比漏掉强。4.4 建议回复的语气控制建议回复是直接面向用户的语气很重要。我在提示词里明确要求不使用你的 Issue 不合格这类指责性表述先肯定用户提交反馈的行为用清单形式列出需要补充的信息结尾给出一个明确的下一步实测下来带这种引导回复的 Issue用户补充信息的比例比冷冰冰的模板高出不少。这说明分诊助手不只是减轻维护者负担也在改善整个社区的沟通氛围。5. 实测中的意外情况与踩坑记录系统上线之后我记录了两周的实际运行数据也踩了不少坑。这部分可能是最有价值的内容因为很多问题只有真正跑起来才会暴露。5.1 模型对中文口语化描述的误判我遇到过一个典型案例用户写这个东西点了没反应是不是坏了。模型把它分类成了信息缺失置信度 0.45。但实际上这条 Issue 后面附了一段完整的录屏和日志只是正文写得很口语化。问题出在哪模型过度依赖正文文本忽略了附件信息。我的修复方案是在预处理阶段把是否包含附件作为一个显式特征写进提示词并且在示例里加了一个正文简短但有附件的案例。改完之后这类误判明显减少。这个坑给我的教训是模型看到的信息和你以为它看到的信息可能不是一回事。预处理阶段一定要把关键信号显式化不能指望模型自己去发现。5.2 重复检测的假阳性比假阴性更烦人假阴性是漏掉重复假阳性是把不重复的判成重复。我原以为漏掉重复更严重实测下来恰恰相反假阳性对用户体验的伤害更大。因为一旦系统提示这条可能是 #123 的重复用户会觉得你根本没认真看我的问题情绪立刻上来。所以我在精排阶段加了一条硬约束只有当模型能明确说出两条 Issue 的核心问题相同时才标记为重复。如果只是主题相关一律不标。宁可漏不可错。5.3 长 Issue 的截断策略需要按段落而不是按字符我最初按字符数截断结果经常把关键信息砍掉。后来改成按段落截断优先保留包含复现步骤环境版本等关键词的段落其余段落按顺序填充直到达到长度上限。这个改动看起来小但对摘要质量的影响很大。因为 Issue 的有效信息往往集中在某几个特定段落按字符截断很容易正好错过它们。5.4 成本控制不是每条 Issue 都值得调用大模型跑了两周之后我看了一下账单发现成本比预期高。复盘之后发现有相当一部分 Issue 是明显的广告或垃圾内容根本不需要动用大模型。我的优化方案是加一层轻量预筛用关键词黑名单和简单的规则比如正文长度小于 10 个字符、包含大量链接先过滤掉明显无效的内容剩下的才进模型。这一层过滤掉了大约 15% 的调用量而且几乎不影响准确率。优化项优化前优化后日均模型调用次数约 120 次约 95 次单条平均 token 消耗约 1800约 1200解析失败率约 18%约 2%6. 把建议卡片递到人面前交互层的设计取舍模型跑通只是第一步真正决定这套系统好不好用的是它怎么把结果呈现给人。我试过三种方案最后选了最朴素的一种。6.1 三种呈现方案的对比方案 A直接写回 Issue 评论。优点是用户立刻能看到引导。缺点是风险极高一旦模型判断错误错误信息已经公开可见撤回成本大。方案 B发到即时通讯群。优点是实时。缺点是信息流太快容易被淹没而且和 Issue 本身割裂。方案 C生成一张本地建议卡片人工确认后再操作。这是我最终选的方案。方案 C 的核心思路是AI 的输出永远先进入一个待确认的中间态由人决定是否采纳。这个中间态可以是一个本地网页、一个命令行工具甚至一个 Markdown 文件。我用的是一个简单的本地看板每条 Issue 一张卡片显示分类、置信度、摘要和建议回复旁边有采纳修改忽略三个按钮。6.2 卡片上必须显示的信息一张好的建议卡片要让人在五秒内做出判断。我最后保留的字段是Issue 标题和链接方便快速跳转分类标签和置信度用颜色区分高置信度绿色低置信度黄色三行以内的摘要超过三行说明摘要没做好建议回复的预览可折叠重复候选列表如果有我特意去掉了模型分析理由这个字段。一开始我觉得理由很重要能帮我判断模型是否靠谱。但实际用下来发现理由太长我根本不看反而干扰视线。真正需要理由的时候我会点进 Issue 自己看。6.3 采纳率反馈闭环我在看板上加了一个简单的统计每天采纳了多少条、修改了多少条、忽略了多少条。这个数据非常有用它是我判断提示词是否需要迭代的核心依据。如果某类 Issue 的修改率特别高说明模型在这类场景上判断不准我就去翻具体案例针对性调整提示词或补充示例。这个反馈闭环让系统能持续进化而不是上线即巅峰然后慢慢退化。7. 这套系统适合谁以及它的能力边界写到这里我想诚实地聊聊这套系统的适用范围。它不是银弹用错场景反而添乱。7.1 适合的场景个人或小团队维护的开源项目Issue 量在每天几条到几十条之间人工处理有压力但又不至于需要专职人员。内部工具仓库同事提的反馈质量参差不齐需要统一引导。任何需要处理大量非结构化用户反馈的场景思路可以迁移到工单分诊、用户反馈归类等。7.2 不适合的场景Issue 量极少的项目一天不到一条人工处理比搭系统快。对实时性要求极高的场景轮询有延迟不适合秒级响应。完全无人值守的自动化我始终坚持人在回路全自动关闭 Issue 这类操作风险太大。7.3 一个容易被忽略的边界模型的知识截止模型对项目本身的历史、约定、术语是不了解的。比如项目里有个约定俗成的缩写模型可能完全看不懂。我的应对方式是在提示词里加一段项目背景说明把关键术语和约定写进去。这段说明不长但对准确率的提升很明显。提示项目背景说明要定期更新。我一开始写了一次就没管后来项目加了新模块模型对新模块相关的 Issue 判断明显变差排查半天才发现是背景说明过期了。8. 我实际用下来最想分享的几条经验最后这部分我想抛开技术细节聊聊这套系统跑了两周之后我个人最真实的几点体会。第一分诊助手的价值不在于准而在于稳。它不需要每条都判断对它需要的是每天稳定地把脏活干完让你打开看板时面对的是已经整理好的信息而不是一堆原始 Issue。这种确定性本身就是巨大的减负。第二提示词的迭代是长期工作不是一次性投入。我到现在还在每周微调提示词因为项目在变、用户在变、Issue 的类型也在变。把它当成一个需要持续维护的产品而不是一个写完就扔的脚本。第三保留人工确认这一步是这套系统能长期用下去的关键。我见过太多自动化工具因为一次误判就被弃用。人在回路不是效率的妥协而是信任的基础。用户知道最终决定是人做的对系统的容忍度也会更高。第四别追求一步到位。我最开始的版本只做了分类连摘要都没有但已经能帮我省下不少时间。后面才逐步加上摘要、重复检测、建议回复。每加一个功能都基于实际痛点而不是看起来应该要有。如果你也在被 Issue 淹没我建议你先从最小版本开始一个轮询脚本、一段提示词、一个本地看板。跑起来看数据再迭代。这套东西的门槛比想象中低但带来的改变比想象中大。