TL;DR
把用户的原话，加上你手头能拿到的环境信息，一起贴进下面这个 Prompt。AI 只在一件事上可靠：把一段模糊消息重新整理成标准工单字段（标题、编号复现步骤、预期 vs 实际、严重度、环境），并草拟在你提交工单之前该问用户的澄清问题。它在猜根因上不可靠——所以这个 Prompt 会明确要求它把任何推测单独标出来再删掉。截至 2026 年 6 月，Claude（Opus 4.7，或更便宜的 Sonnet 4.6）在多条工单上保持固定输出结构方面比多数模型更稳，这正是可重复的 triage 流程需要的。
任务场景
客服收件箱里：“坏了。” 五个字、零上下文、零复现步骤。工程拿到这个动不了手。你要一份工单：可搜索的标题、编号步骤、预期 vs 实际、有理由的严重度、环境。更难、也更值钱的部分，是在提交之前该问用户的澄清问题——这样工单才不会被打回、标上”信息不够”。后者正是工单卡住最常见的原因。
哪些情况适合让 AI 来做，哪些不要
AI 在这里确实擅长两件事：把乱糟糟的消息整理成标准工单形状，以及写出能定位歧义的澄清问题。但它不擅长诊断。如果模型自信地写”这是状态管理的竞态条件”，删掉那一行。工单的职责是把可观察到的行为描述得足够精确，让工程师能复现；诊断由工程师负责。一份带着错误根因猜测的工单，比一份没有根因的更糟，因为它会把 triage 带进错误的方向。
需要给 AI 的输入信息
- 用户消息原文（原样贴，别转述——措辞本身就是证据）
- 设备、OS、app 版本、浏览器（尽量从邮件 header、请求日志或用户签名里推断）
- 你能否复现：能 / 部分 / 不能
- 复现步骤（如果有）
- 账号状态（如相关）：免费或付费、地区、近期是否换过套餐、是否开了 beta 开关
- 你团队的严重度标准，连定义一起给（这样模型映射到的是你的标签，而不是通用标签）
严重度 vs 优先级——一定要分开
triage 里最常见的错误，是把这两个数字揉成一个。它们是两条独立的轴，最干净的团队会分别打分：
| 轴 | 它回答的问题 | 谁来定 |
|---|---|---|
| 严重度（Severity） | 从技术上看，这个 bug 把产品破坏得有多狠？ | 离技术证据最近的人（QA / 报告者） |
| 优先级（Priority） | 从业务上看，这个 bug 必须多快修？ | 掌握业务上下文的人（PM / 负责人） |
经典例子：一个没人用的功能里的启动即崩溃，严重度高、优先级低；结账”支付”按钮上偏了一个像素，严重度低、优先级高，因为它影响转化。让 AI 去定严重度（它能从工单内容推理出来的部分），优先级留给人来判断。
很多 QA 团队常用的四级分级：
| 级别 | 含义 | 例子 |
|---|---|---|
| S0 / 致命 | 数据丢失、安全暴露，或大面积停服 | 全体用户无法登录；支付重复扣款 |
| S1 / 阻断 | App 崩溃，或核心流程被完全卡死，无变通办法 | 所有设备上结账按钮点了没反应 |
| S2 / 严重 | 一个重要功能失效，但有变通办法 | 导出 PDF 失败，但还能导出 CSV |
| S3 / 轻微 | 外观或低影响问题 | 标签错位；tooltip 里有错别字 |
可直接复制的 Prompt
把用户抱怨转成 bug report。
用户消息（原文）：
"""
[paste]
"""
设备 / OS / 版本 / 浏览器：[贴 或 "未知"]
复现状态：[能 / 部分 / 不能]
复现步骤（如有）：[贴]
账号状态：[免费 / 付费 / 地区 / 近期变更]
我们的严重度标准：[贴你的 S0-S3 定义]
请输出：
1. 标题——具体、可搜，含功能区域
2. 复现步骤，编号，从一个清晰的起点开始
3. 预期行为
4. 实际行为（只写观察到的，不写推断的原因）
5. 严重度（S0-S3）——附一行理由，关联用户影响
6. 环境——设备 / OS / 版本 / 浏览器 / 地区
7. 提交前要问用户的澄清问题——最多 3 个，按优先级，每个用户一行能答
8. "不要假设" callout——把你想加的根因推测列出来，让我确认它们绝不进工单
规则：不要凭空补缺失的事实。字段未知就写 [未知：问用户]。不要指派优先级——那是人来定的。移动端 bug 再加一行：加 iOS / Android 差异检查——同样的复现步骤在另一个 OS 上会发生吗？如果你是批量 triage，可以让模型同时输出一段紧凑的 JSON，字段一致，就能直接进 Linear、Jira 或 GitHub Issues。
怎么判断 AI 给的结果能不能直接用
- 标题可搜：含功能区域，绝不是”app 坏了”
- 你能照着编号步骤自己复现这个 bug
- 预期和实际都写出来——工程缺一不可
- 严重度带一行理由，不只是一个标签
- 澄清问题用户每个都能一行答完
- 正文里没有根因猜测（检查”不要假设” callout 是否起了作用）
- 环境采全了；只在 iOS Safari 上出现的 bug，永远不会在 Windows Chrome 上复现
容易踩的坑
- **报告模糊。**工程把工单打回，来回期间用户更暴躁。
- **没有预期 vs 实际。**头号”信息不够”理由。两者都不可省。
- **没指派严重度。**工单卡在 triage 真空里，没有任何东西能拿来排序。
- **让 AI 猜根因。**看着帮忙，悄悄把工程师带偏。
- **跳过澄清问题。**提交前问，比提交后拉一条好几天的评论串快得多。
- **丢掉环境。**只在某个 OS 上的 bug 会被派给错团队然后卡住。
FAQ
- **该用哪个模型？**截至 2026 年 6 月，Claude Sonnet 4.6 是一个又强又便宜的默认选项，它能在大量工单上稳定保持固定输出结构；遇到又长又乱的对话串就上 Opus 4.7。GPT-5.5 也好用——把结构固定在 Prompt 里，每次都用一模一样的，工单才好横向比较。
- **用户态度差怎么办？**先安抚，再澄清。语气决定他会不会回你的问题，而问题没人回，工单就卡住。见客服回复。
- **工程跟我对严重度有分歧？**用用户影响的理由去捍卫，而不是功能重要性。“全体用户在启动时遇到”胜过”这是我最喜欢的功能”。
- **AI 能分类 bug 区域吗？**能，前提是你的分类法稳定，并且把列表给模型。如果分类模糊，让人来 triage，AI 只负责写。
- **能一次批量处理很多报告吗？**能。让它输出 JSON，把多条抱怨依次喂进去，但前几条要抽查——一个在结构上漂移的模型会悄悄把你的字段错位。
相关
- Bug 审计 Prompt ——更宽的 bug 审计流程
- Bug 复现 Prompt ——复现本身是 blocker 时
- 客服回复 ——提交工单时同步回用户
- 帮助中心 FAQ AI ——把反复出现的 bug 变成预防性文档
- 用户反馈聚类 AI ——在多个报告里找 pattern
- App 评论回复 AI ——同一套 triage 用在商店评论
标签: #AI 写作 #产品创业 #Bug Report