Bug 报告怎么写提示词：把「用不了了」整理成开发一看就能复现的缺陷单
测试、产品、客服或用户反馈了问题，要提交到缺陷管理系统（Jira、禅道、飞书项目）时用：把零散的描述、截图文字、聊天记录整理成标准缺陷单，写清复现步骤、期望与实际结果、环境和严重程度，并列出还缺的信息。
通用大模型 对话模型通用
请把下面的问题反馈整理成一份规范的缺陷报告。读者是负责修复的开发，目标是让他不用再来回追问就能复现问题。 原始反馈（聊天记录、用户描述、截图里的文字都可以）： [粘贴原始反馈] 已知环境信息：[已知环境信息]（例：iOS 18 + App 3.2.1、Chrome 最新版、测试环境） 缺陷系统的字段要求：[缺陷系统的字段要求]（例：标题、模块、严重程度、优先级，没有就写默认） 缺陷单结构： 1. 标题：「在哪里 + 做了什么 + 出现了什么问题」，30 字以内，例如「订单详情页点击申请退款后页面白屏」。不要写「有 Bug」「无法使用」这种笼统标题。 2. 环境：端、系统版本、浏览器或 App 版本、账号类型或权限、测试环境还是生产环境、网络情况。 3. 前置条件：复现需要的数据或状态，如「账号有一笔已发货订单」。 4. 复现步骤：编号列出，每步一个操作，具体到点击哪个按钮、输入什么值。 5. 期望结果与实际结果：分开写；实际结果包括报错文字、错误码、页面表现。 6. 复现频率：必现、偶现（大约几次中出现几次）、只出现过一次。 7. 影响范围与严重程度：按「致命 / 严重 / 一般 / 轻微」给出建议并说明理由（例如影响支付、是否有绕过办法、影响多少用户）。 8. 附加信息：时间点（便于查日志）、请求 ID、相关截图或录屏的说明。 9. 初步线索（可选）：如果反馈里有能帮助定位的信息（比如只有某个版本出现），单独列出，但不要猜测代码原因。 原始反馈中缺失、需要找反馈人补充的信息，列在最后的「待补充」清单里，写成可以直接发给对方的问题。 手机号、地址等用户个人信息在缺陷单里打码处理。
高亮处换成你自己的内容：[粘贴原始反馈]、[已知环境信息]、[缺陷系统的字段要求]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[原始反馈] 越原始越好，用户的原话常常包含关键线索（比如「换了 WiFi 就好了」）。[已知环境信息] 写多少算多少，缺的部分 AI 会列进「待补充」。
常见坑：
- 复现步骤写成「进入页面，操作一下就出错」，开发无法复现，只能来回追问。每一步都要具体到操作和输入值。
- 期望和实际混在一起写，开发不清楚「对的」应该是什么样。分开写。
- AI 可能根据经验「补全」复现步骤。模板要求缺失信息列进待补充，提交前要核对步骤是否真实发生过。
追问技巧：开发回复「无法复现」时，把他的回复贴回来，问「为了复现，还需要向用户收集哪些信息，比如日志、账号状态、操作时间」。
示例输出
示例，仅供参考
标题：订单详情页点击「申请退款」后页面白屏
| 字段 | 内容 |
|---|---|
| 环境 | iOS 18.0，App 3.2.1，生产环境，4G 网络 |
| 前置条件 | 账号有一笔「已发货」状态的订单，订单使用了优惠券 |
| 复现频率 | 用户称连续 3 次都出现（待确认是否必现） |
| 严重程度建议 | 严重：用户无法自助退款，但可以通过客服处理 |
复现步骤：
- 进入「我的订单」，打开该订单详情；
- 点击底部「申请退款」。
期望结果：进入退款申请页。
实际结果：页面白屏，约 5 秒后自动返回订单列表。
待补充：
- 发生问题的大致时间（精确到分钟），方便查日志？
- 没有使用优惠券的订单是否也会这样？
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～