任务场景
客服收件箱里：“坏了。” 5 个字、零上下文、零复现步骤。你要一份工程真能动手的 bug report：具体标题、编号步骤、预期 vs 实际、严重度、环境。附赠的是——在 file 工单前，先问用户哪些澄清问题，免得工程把工单踢回来。
哪些情况适合让 AI 来做，哪些情况不要
AI 善于把模糊消息整理成标准 bug report 形状，并写出能定位歧义的澄清问题。但它不擅长”猜根因”——AI 自信地写”这是状态管理问题”时，删掉那一行。工单描述 bug，根因是工程师诊断的。
需要给 AI 的输入信息
- 用户消息原文
- 设备 / OS / 版本（从 header、日志、邮件可推断）
- 你能否复现：能 / 部分 / 不能
- 复现步骤（如有）
- 账号状态：免费 / 付费、地区、近期变更
- 你团队的严重度标准（S0 / S1 / S2 / S3）
可直接复制的 Prompt
把用户抱怨转成 bug report。
用户消息（原文）：
"""
<paste>
"""
设备 / OS / 版本：<贴 或 "未知">
复现状态：<能 / 部分 / 不能>
复现步骤：<贴>
账号状态：<免费 / 付费 / 地区 / 近期变更>
严重度标准：<S0-S3 定义>
请输出：
1. 标题——具体可搜，含功能区域
2. 复现步骤，编号
3. 预期行为
4. 实际行为
5. 严重度（S0-S3）——附用户影响理由
6. 环境——设备 / OS / 版本 / 地区
7. file 前要问用户的澄清问题——最多 3 个，按优先级
8. "不要假设" callout——工单里要删掉的根因推测
如果用户信息缺，不要凭空补，用 [未知：问用户]。移动端专用：“加 iOS / Android 差异检查——另一 OS 能复现吗？“
建议让 AI 输出成什么样
一份工单：标题、步骤、预期 / 实际、严重度、环境、澄清问题列表。“不要假设” callout 在传播前删掉根因猜测。如果你团队有模板，按模板。
怎么判断 AI 给的结果能不能直接用
- 标题可搜——含功能区域，不是”app 坏了”
- 复现步骤你自己也能复现
- 预期和实际都写出来——工程缺一不可
- 严重度有理由，不只是标签
- 澄清问题用户一行能答
- 工单正文没根因猜测
容易踩的坑
- 报告模糊——工程踢回，用户更暴躁
- 没预期 vs 实际——最常见的”信息不够”理由
- 没指派严重度——卡在 triage 炼狱
- 让 AI 猜根因——看着帮忙，实际把工程带偏
- 跳过澄清问题——file 后再问比 file 前问更慢
- 没采环境——只在一个 OS 复现的 bug 会被派给错团队
实操加深
做「用 AI 写 Bug Report：把模糊抱怨变成可复现的工单」这类任务时，AI 输出质量主要取决于输入包是否完整。至少给它受众、原始材料、目标格式、你要做的决策，以及一好一坏两个参考。第一轮先要求保留事实，第二轮再优化结构、语气或表达，不要让模型一边猜事实一边润色。
拿到结果后单独做一次复核：有没有遗漏限制、编造细节、行动项不清、语气和真实场景不符。最终稿最好能马上使用，包含明确对象、下一步和判断标准，而不是还需要别人重新解释一遍。
FAQ
- 用户态度差怎么办？ 先安抚再澄清。语气决定他会不会回。
- 和工程对严重度有分歧？ 用用户影响理由捍卫，不是功能重要性。
- AI 能分类 bug 区域吗？ 你的分类法稳定就能。否则让人 triage。
相关
- Bug 审计 Prompt ——更宽的 bug 审计流程
- Bug 复现 Prompt ——复现本身是 blocker 时
- 客服回复 ——file 时回用户
- 帮助中心 FAQ AI ——预防性文档
- 用户反馈聚类 AI ——多个报告里找 pattern
- App 评论回复 AI ——同 triage 用在商店评论
标签: #AI 写作 #产品创业 #Bug Report