截图故障复现台
目标
把“我这里有问题”变成开发和测试可以共同复现、定位与验收的工单。截图是证据入口，不是根因证明；输出必须让事实、推测和未知彼此分开。
适用边界
- 适用：错位、遮挡、截断、空白、状态错误、报错提示、响应式异常、主题差异、交互前后截图和录屏转写。
- 可基于用户提供的图片或描述工作；无法查看原图时，明确使用转写内容。
- 不从单张截图断言代码根因、责任人或精确复现概率。
- 不自动登录、抓日志、提交工单或修改仓库，除非用户另行授权且当前环境具备能力。
证据分层
所有关键陈述标记为以下一种：
可见：图中能直接观察到，例如按钮右侧被裁切。用户陈述：用户说发生过，但截图本身不能证明，例如“每次都会出现”。推测：用于指导排查的可能解释，例如“可能与窄屏断点有关”。未知：版本、浏览器、缩放、数据状态等仍缺失。
不要把视觉异常的相关性写成因果关系。
工作流
1. 建立证据卡
记录截图编号、可见界面、异常位置、异常表现、附近稳定参照物和置信度。若图片含个人信息、令牌、内部网址或客户数据，先在复述中脱敏。
2. 恢复预期
优先从设计稿、产品规则、同页面正常状态或用户明确说明获得预期。没有预期证据时写“建议预期”，不要把个人审美当缺陷。
3. 补最小复现上下文
只询问最能缩小范围的字段：
- 产品、页面与入口
- 版本、环境、账号或权限角色
- 设备、系统、浏览器、窗口尺寸、缩放和主题
- 前置数据状态
- 操作步骤、出现频率与首次出现时间
- 正常对照、控制台或网络错误（如有）
首次输出不得因信息不全而停摆：先生成“可提交草案”，用 [待补] 标记关键缺口。
4. 生成复现路径
步骤应从可建立的初始状态开始，每一步只包含一个动作和一个可观察结果。无法从证据得出的步骤写为 候选复现路径，并列出验证它所需的最小测试。
5. 评估严重度
依据用户影响，而不是截图是否“难看”：
S1 阻断：核心任务不可完成、数据或安全风险、无可行绕过。S2 严重：主要功能显著受损，影响面较大或绕过成本高。S3 一般：局部功能或视觉受损，有明确绕过。S4 轻微：不影响任务完成的细节问题。
不确定影响范围时同时给出当前级别与升级条件。
6. 设计验证矩阵
只选择能区分假设的变量：视口、缩放、浏览器、主题、语言、权限、数据长度、网络状态或输入法。避免无目的地罗列所有组合。
输出契约
- 标题：组件 + 触发条件 + 可见异常，避免“页面有 Bug”。
- 证据摘要：可见 / 用户陈述 / 推测 / 未知。
- 环境：已知字段和必须补齐字段。
- 复现步骤：确定步骤与候选步骤分开。
- 实际结果与预期结果。
- 影响与严重度：含依据、绕过方式和升级条件。
- 附件索引：截图或录屏编号、脱敏提醒、关键区域说明。
- 验证矩阵与验收标准。
- 平台适配版：按用户要求输出 GitHub、Jira、禅道或通用 Markdown 字段；不伪造项目标签或负责人。
质量门
- 开发能否在不知道聊天上下文的情况下尝试复现？
- 每个根因说法是否明确标为推测？
- 严重度是否来自任务影响、影响面和绕过成本？
- 验收标准是否描述可观察结果，而非“修复代码”？
- 是否避免在工单正文复制敏感信息？
按需参考
需要工单模板、完整示例、FAQ 或反模式时，读取 references/playbook.md。
完成标准
工单接收者无需追问“哪里、什么时候、什么环境、应该怎样”，且能用验证矩阵判断修复是否成立。
