编程开发 编辑复核
Bug 复现与分诊记录
把用户描述转成最小复现步骤、实际/预期结果、环境和证据，方便开发直接定位。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名质量工程师。请将问题描述整理成开发可以执行的复现报告，不要把猜测的根因写成结论。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 一句话现象与影响范围
2. 最小复现步骤和前置数据
3. 预期结果与实际结果
4. 浏览器、设备、版本、账号权限和频率
5. 日志、截图、请求 ID 和下一步排查
输入变量：
- 原始反馈（{{report}}）：提供用户原话、时间和脱敏上下文。
- 环境（{{environment}}）：提供环境、版本、设备和账号类型。
- 已尝试步骤（{{steps_taken}}）：列出已尝试的复现和结果。
- 证据（{{evidence}}）：提供可安全分享的日志、截图和请求标识。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 先隐藏用户身份和令牌，再把最小复现提交给开发。
- 复现失败时记录条件，不要为了关闭工单而猜根因。
WHEN IT FITS
适用判断
适合这些情况
- 你已经能稳定复现问题，需要写成开发能直接上手的报告。
- 要提交给外部团队或开源项目，需要信息齐全。
- 需要把复现路径固定下来，避免修完无法验证。
换个做法更好
- 还不能稳定复现：用《Bug 复现与分诊记录》先整理线索。
- 问题就在你自己手上要修：写报告不如直接修。
- 你只有用户的模糊描述：报告需要确定的复现步骤。
FAILURE MODES
常见翻车与修正
- 复现步骤缺少前置条件，别人照着做复现不出来。
要求把账号状态、数据前提、配置项和环境版本都列进「前置条件」，缺一项就标注。
- 报告里粘贴了包含真实用户数据或 token 的日志。
要求所有日志和截图先脱敏，涉及标识的替换为占位符，并检查请求头里没有凭据。
- 把猜测的原因写成了事实。
要求严格分开「观察到的现象」和「我的推测」，推测部分标注为待验证。
ACCEPTANCE
怎么判断输出合格
- 前置条件完整，别人照着能复现。
- 所有粘贴的日志和数据都脱敏了。
- 现象和推测严格分开。
- 写清了预期行为和实际行为的差异。
SAFETY BOUNDARY
使用边界
- 截图和录屏里的用户数据要打码，工单系统的可见范围通常比你以为的大。
- 模型基于描述推测的复现步骤未必成立，提单前自己按步骤复现一次确认。