问题复现与修复版本证据矩阵

怎样用于你的项目

本模板讨论问题关闭前的证据链，区别复现样本许可、诊断资料分享和API故障分工。它不声称任何实际缺陷已定位或修复，也不把另一环境、历史成功或源码猜测当当前问题的结论。

先确认问题范围和影响版本，再按约定安排复现、修复与复测。首次讨论用脱敏现象和预期结果，现场资料与操作权限在实施前确认。

窄屏可在表格区域横向滚动。

问题证据模板：现象、原因、改动与复验
证据位置	请记录的版本与条件	由谁核对	待验的边界
现象与实际范围	什么现象已有依据，环境、版本和未知是什么	有权业务与问题接手人	描述或退出码不自动证明完整原因和影响
假设与允许材料	原因假设、来源类别和允许查阅的范围	资料权利人与工程人员	假设不能写成实锤，也不自动授权读取客户现场
复现与未复现	哪些条件实际运行、结果如何，哪些没做	有权执行人与核对人	一次未复现不证明问题不存在，失败和未知不能重标成功
修复版本与差异	拟议改动、真实代码版本和影响范围怎样对应	源码与问题负责人	提交或代码差异不证明修复已验证或生产已更新
回归与残余范围	复验版本、原场景、相关路径及剩余未知	有权业务与工程检查人	其他版本成功不能替本头签通过，局部回归不等完整业务验收
关闭与后续决定	依据、未覆盖、原失败记录和接手责任	有权问题与业务人员	模板不是问题已关闭、服务恢复、时限或质量保证

保留原始状态和每一步所用版本，确认哪些结论已有证据，哪些仍是假设。真实查阅、复现、修复或回归必须先批准；公开模板不操作现场，也不因提交已出现就宣称问题闭环。

有原因假设或一份错误描述，就能把软件问题写成已定位吗？

先记录发生了什么、在哪个版本、希望得到什么结果。把已知现象与原因猜测分开，使用允许分享的示例帮助定位。

修复提交已经存在，就表示问题消失、回归通过并已更新生产吗？

修复提交、复测结果和部署安排分别确认。按约定场景检查原问题及受影响功能，再由双方决定是否关闭问题。

另一个环境或旧版本成功，可以直接替当前问题和候选头签通过吗？

每个版本和环境分别保留检查结果，失败与尚未检查的部分都清楚列出。新的验证以当前版本为准，便于后续接手和复查。