用途：在声称某个缺陷修复、代码改动、重构或功能验证完成之前，按科学方法确认修复确实有效。适用于声明缺陷已修复、验证代码改动符合预期、确认实现满足需求、确认重构保持功能、测试功能行为是否正确等场景。
核心原则：成功等于观察到预期行为，而不是没有报错。仅“能跑不报错”不算验证通过，必须展示出具体预期结果。
四步协议：
- 复现失败状态：在修复前明确制造或确认问题存在，记录可观察症状，如确切错误信息、错误取值或输出、异常行为、系统状态问题，并确认能稳定复现。
- 定义成功标准：说明何种可观察输出代表修复成功，区分成功与非成功指标，成功不等于无错误、无警告或“运行不失败”。
- 应用修复并观察：带着修复运行代码，寻找第二步定义的成功指标，逐字记录实际输出、返回值和行为，并与成功标准对照。
- 验证结果：确认失败状态已消失，重跑第一步的复现步骤，确认第二步的成功标准均被满足，每条都需有证据，部分成功不算成功，并记录验证证据。
常见反模式：未复现失败就宣称成功；把“无错误”等同于成功；跳过验证，仅凭“应该能行”；只做部分验证，忽略边界条件。
与测试的关系：该协议补充但不替代自动化测试。自动化测试用于防止回归、系统性验证预期行为；验证协议用于确保具体修复解决了具体观察到的问题。建议二者结合：按协议验证修复，补充自动化测试防止回归，并运行完整测试套件。
限制：资料未提供该技能的安装方式、具体命令、平台或收费信息。