AI Issue Triage：让独立产品的反馈不再堆成山

一、反馈多不是好事，能处理才是

独立产品上线后，用户反馈会从各种地方涌来：GitHub issue、邮件、客服表单、社群消息、应用内反馈。刚开始每条都能认真看，用户一多就容易堆积。AI 可以帮助做 issue triage，把反馈分类、去重、提取复现步骤和判断优先级，但它不能代替产品判断。

反馈处理的目标是让问题更快进入正确队列。Bug、功能建议、使用疑问、账单问题、文档缺失、环境兼容问题，处理方式完全不同。AI 的价值是先整理，而不是直接决定路线图。

二、分流链路：收集、分类、去重、入队

flowchart TD A[用户反馈] --> B[AI 摘要] B --> C[分类标签] C --> D[相似问题匹配] D --> E[优先级建议] E --> F[人工确认] F --> G[进入开发队列]

AI 摘要要保留关键信息：用户想做什么、实际发生什么、预期是什么、环境是什么、是否有复现步骤、影响范围多大。如果反馈很情绪化，模型可以帮忙去掉噪声，但不能丢掉事实。用户的挫败感本身也是信号。

去重也很重要。十个用户反馈同一个同步失败问题，应该合并成一个高优先级 bug，而不是十条独立 issue。相似问题匹配可以用文本相似度或 embedding，AI 再帮忙判断是否真的是同一问题。重复反馈数量本身可以作为优先级依据。

实际落地时，我推荐从简单的文本相似度入手，比如先用 OpenAI embedding 对历史 issue 做向量化：

import openai def get_embedding(text: str) -> list[float]: response = openai.embeddings.create( model="text-embedding-3-small", input=text ) return response.data[0].embedding def find_similar(new_issue: str, existing_issues: list[dict], threshold=0.85): new_vec = get_embedding(new_issue) results = [] for issue in existing_issues: similarity = cosine_similarity(new_vec, issue["embedding"]) if similarity > threshold: results.append({"id": issue["id"], "score": similarity}) return sorted(results, key=lambda x: x["score"], reverse=True)

当用户提交"同步失败"时，系统自动匹配到已有的"跨设备同步问题"issue，然后在评论里提示"此问题可能与 ISSUE-42 相关，已有 8 位用户报告"。这样既不会重复建 ticket，用户也能看到问题已经被关注。

在实际使用中，我们发现 embedding 相似度阈值设定很重要。阈值太高（比如 0.95）容易漏掉同义但不同表述的问题；阈值太低（比如 0.7）会把不相关的问题错误合并。建议从 0.85 开始，然后根据人工审核反馈调整。

另外，多语言反馈的去重也是一个坑。同一个 bug，用户可能用中文、英文、日文描述，文本相似度会很低。这时可以先做语言检测，再用对应语言的 embedding 模型，或者在摘要阶段统一转英文再比较。

对于独立产品，可以不用自己搭建 embedding 服务。直接用 OpenAI、Cohere 或国内的向量数据库云服务，几条 API 调用就能跑起来。独立开发者最缺的不是技术，而是决定什么值得投入时间。反馈去重能直接减少处理负担，值得优先投入。

三、结构化输出：让反馈进入看板

下面是一个适合 AI 输出的结构。它可以直接写入 issue 系统的字段。

{ "type": "bug", "summary": "用户在 Safari 中导出 PDF 后文件为空", "severity": "high", "repro_steps": ["打开报表页", "点击导出 PDF", "下载文件大小为 0KB"], "environment": "Safari 17, macOS", "similar_issue_ids": ["ISSUE-128"], "needs_human_review": true }

结构化输出比一段自然语言摘要更适合后续自动化。可以根据type分配标签，根据severity排队，根据environment找负责模块。独立开发者也可以用简单的 JSON 文件或 Notion 数据库开始，不必一上来搭复杂平台。

要注意隐私。用户反馈可能包含邮箱、订单号、截图和业务数据。送给模型前应脱敏，至少隐藏手机号、邮箱、密钥和支付信息。反馈系统越智能，越要小心数据边界。

脱敏可以用简单的正则先处理，再让 AI 检查是否还有遗漏的关键信息：

import re def redact_sensitive(text: str) -> str: text = re.sub(r'[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}', '[EMAIL]', text) text = re.sub(r'1[3-9]\d{9}', '[PHONE]', text) text = re.sub(r'(sk-|api_key=)[a-zA-Z0-9]+', r'\1[REDACTED]', text) return text

这份代码把邮箱、手机号和 API key 做了字面替换。实际场景中，还可以识别身份证号、银行卡号和内部 IP。AI 在生成摘要时，拿到的就是脱敏后的文本，不会泄漏敏感信息。反馈原文可以保留在后端数据库中，但不送入模型。

四、优先级判断：模型建议不等于产品决策

AI 可以根据影响范围、复现稳定性、付费用户数量和业务关键路径给出优先级建议。但最终排序仍要结合产品阶段。一个小 bug 如果影响新用户激活，可能比一个高级功能建议更重要。独立产品资源有限，优先级不是客观数学题。

反馈闭环也要做好。被合并的问题要给用户状态更新，已修复的问题要记录版本。AI 可以生成回复草稿，但语气和承诺要谨慎。不要轻易承诺上线时间，也不要把模型生成的道歉话术当成真实沟通。

我们给 AI 回复草稿设了明确的约束 Prompt：

你是一个客服回复草稿助手。回复时遵守以下规则： 1. 不承诺具体上线时间 2. 如果问题已修复，说明版本号，不夸大效果 3. 如果问题在排队，说明已收录，不暗示优先级 4. 如果你不确定如何回复，标记为需要人工处理 5. 回复语气礼貌但简洁，不超过 80 字

这个约束能防止 AI 写出那种"我们非常抱歉给您带来不便，我们会尽快处理"的万能模板。用户需要知道的是：问题是否被理解了、是否有人会处理、是否有临时绕过方案。AI 适合生成初稿，但最终发送前，开发者应该扫一眼确认内容无误。

最后，定期复盘未处理队列。哪些问题重复出现，哪些功能建议长期被忽略，哪些文档缺失导致大量咨询，这些都是产品方向信号。Issue triage 做好了，反馈就不只是负担，也是路线图的输入。

五、总结

AI Issue Triage 能帮助独立产品整理反馈、分类去重、提取复现步骤和建议优先级，但人工确认和产品判断仍然关键。结构化输出、隐私脱敏、相似问题合并和反馈闭环，能让用户声音真正进入开发节奏。