AI 缺陷报告快照卡

解决的具体问题

软件缺陷常常以客服记录、用户抱怨、截图和半截日志的形式出现：现象说得清，但环境、触发条件、证据链和未知项混在一起。测试同学接手后，经常需要反复追问：这是哪个版本？用户角色是什么？错误文案是什么？截图是否包含敏感信息？这个技能解决的是这个 QA handoff 断层：把杂乱材料整理为一张可粘贴到 Jira、Linear、GitHub Issues 的缺陷报告快照卡。

它只做报告整理，不替团队做最终判断。不会运行测试、不修改系统、不自动提交 issue，也不会直接决定 severity，而是给出 proposed severity 和需要确认的问题。

技能如何工作

技能围绕“可复现、可核验、可脱敏”三个目标组织输出：

• 确认范围：用一句话说明受影响功能、用户流程和具体失败。
• 先脱敏再总结：要求隐藏密码、token、cookie、个人联系方式、订单号、内部主机名等；已有敏感内容用 [REDACTED_CREDENTIAL] 等占位符替代。
• 补齐环境信息：记录版本、设备、浏览器、账户角色、地区、flags、build 等，并标记 Confirmed / Unknown。
• 写最小复现路径：从清晰起点开始，避免假设，缺失项写 Unknown。
• 区分预期与实际：把 observable behavior 写进表格，避免主观猜测。
• 建立证据清单：列出截图、录屏、日志摘录，说明它们证明什么、是否已脱敏、是否可附件。
• 输出 Tester Handoff：给出最先测试场景、需要验证的变体、数据或账户准备，以及开放问题。

最终卡片通常包含 Summary、Environment、Steps To Reproduce、Expected vs Actual、Evidence Inventory、Impact And Frequency、Unknowns And Follow-Up Questions。

适用边界与注意点

它适合把支持投诉、bug 描述、日志摘录整理成测试交接材料，不适合直接执行自动化测试、修改线上状态或发布外部报告。涉及真实凭证、用户数据或内部敏感信息时，应优先执行脱敏，而不是继续补全报告。若材料中已经暴露秘密信息，应按组织 incident 流程处理，而不是把它写入普通 bug 卡片。