issue 列表翻到第38页还没找到答案？先承认吧 - 你提取信息的方式一直是错的

一个反例开场

先说我自己踩过的坑。

去年我在排查一个依赖库的内存泄漏问题，issue 列表里躺着两百多条相关记录。我的做法是：逐条点开、肉眼扫描、把「看起来相关」的复制到备忘录里。三个小时后，我攒下了四十多条碎片信息，却依然回答不了最关键的问题——这个 bug 到底修没修？哪个 PR 修的？我的版本受不受影响？

这不是勤奋，这是用体力劳动模拟数据库。类似失败做法还有几种：

• 只搜关键词不看时间线：issue 从提出到修复往往横跨数月，只看正文不看评论，结论可能早已过时。
• 把 issue 全文直接丢给 AI 问「帮我总结」：AI 只会给你一段四平八稳的摘要，回答不了你的具体问题。
• 让 AI「分析所有 issue」：上下文塞不下，模型开始一本正经地编造 issue 编号和结论，你还得逐条去核对——比手动看还累。

问题不在 AI 不行，而在你把它当成了一个「更快的搜索引擎」。

正确的路径：让 AI 做结构化提炼，而不是泛泛总结

转变思路的关键是：先明确你要什么字段，再让 AI 从噪音里抽字段。

issue 区的有效信息其实高度结构化：复现条件、环境版本、报错信息、维护者态度、关联 PR、解决状态。人眼扫这些东西慢，是因为正文里混杂了大量「我也是」「+1」、跑题讨论和情绪宣泄。而这恰恰是 AI 最擅长的场景——从长文本里按固定格式抽取信息。

我现在的流程是这样的：

第一步，筛选与预处理。 用 GitHub 的搜索语法（label、状态、关键词）把 issue 范围缩到几十条，导出正文加评论。这一步必须人来把关，AI 帮不了你判断「什么算相关」。

第二步，分批喂给 AI 做结构化提取。 每批十来条，用统一的字段模板，要求 AI 对每条 issue 输出固定结构，并明确标注「原文未提及」而不是让它猜。

第三步，让 AI 做汇总判断。 把所有批次的结构化结果拼起来，问具体问题：这个 bug 影响哪些版本？有没有 workaround？维护者是打算修还是标记 wontfix？

第四步，人工抽查。 对 AI 给出的关键结论（尤其是 issue 编号和 PR 关联），点回原文验证。这一步不能省，AI 抽取准确率很高但不是百分百。

前后对比

改造前（纯手动）： 三小时翻完两百条 issue，得到一堆无序碎片，写不出结论，第二天接着翻。

改造后（AI 辅助流程）： 半小时完成筛选导出，十分钟跑完提取，十分钟汇总，十分钟抽查验证。产出的不是「我大概记得有人提过」，而是一张可以直接贴进团队文档的表格：每个问题的状态、影响范围、修复 PR、临时绕过方案，一列一列清清楚楚。

顺带一提，这套流程跑多了 token 消耗并不小，尤其是几十条长 issue 的评论全文。如果你想控制成本，可以选按量计费、支持多模型的 API 服务（价格以官网价格页为准），把提取任务交给性价比高的模型，汇总判断这一步再换更强的模型，成本能压缩不少。

可复制的提示词模板

分批提取时，我固定用这个模板（放在每批 issue 内容前面）：

你是一个 GitHub issue 信息提取助手。我会给你若干条 issue 的完整内容（含评论）。
请对每条 issue 严格按以下格式输出，不要添加任何额外解释：

【Issue 编号】#xxx
【标题】一句话概括
【问题类型】bug / 功能请求 / 使用疑问 / 讨论 / 无法判断
【复现条件】具体环境、版本、触发步骤；原文未提及则写"未提及"
【关键报错信息】原文摘录；无则写"无"
【社区反馈】多少人报告同样问题（依据是评论数与内容）
【维护者态度】已确认 / 已忽略 / wontfix / 无回应 / 未提及
【关联 PR】有则列出编号，无则写"无"
【当前状态】已修复 / 修复中 / 未修复 / 已关闭未说明
【信息可信度】高 / 中 / 低（依据原文信息完整度判断，不要凭空推断）

注意：
1. 所有结论必须来自原文，禁止推测或编造编号
2. "我也是""+1"类评论只计入社区反馈数量，不作为问题证据
3. 如果一条 issue 在评论中状态发生变化（如后来被修复），以最新状态为准

汇总阶段的提问也尽量具体：「基于以上结构化数据，列出所有与内存泄漏相关且仍未修复的 issue，按报告人数排序，并说明各有哪些临时绕过方案。」问得越像 SQL，答案越像查询结果。

几句提醒

这套方法不适用于所有场景：如果你只查三五个 issue，手动看反而更快；如果 issue 正文本身就是高质量的 bug report，直接读原文比走流程划算。AI 的价值在规模——当信息量大到人力读不完时，结构化提取才真正省钱省时间。

另外，涉及「要不要升级依赖版本」这类决策，AI 提取的结果只是输入，最终判断还得结合你自己的项目情况。AI 帮你把两百条 issue 压缩成一张表，但读表做决定的，仍然是你。

如果你想动手试试这套流程，需要一个稳定、支持多模型切换的 API 通道，可以看看这个：https://api.thistoken.ai/register

---

不想折腾多家供应商的接入差异？在 https://api.thistoken.ai/register 注册，用一个 base_url 调用所有模型。