测试与结果验证

建立证据链

工具调用成功只说明命令执行了，不说明用户问题已经解决。错误修复应先得到能稳定失败的用例，再实施修复并看到它转为通过。

验证强度要与风险匹配。纯函数可以用单元测试，接口变更需要集成测试，视觉问题需要真实浏览器检查，部署变更还需要生产健康检查。

1. 复现原始问题并记录失败现象。
2. 添加最小回归测试，确认修复前失败。
3. 实现修复并运行定向测试。
4. 运行相关全量测试、类型检查和构建。
5. 检查最终差异与真实用户路径。

处理无法运行的测试

如果环境缺少服务、凭据或平台能力，不要把未执行描述成通过。报告具体阻塞、已完成的静态验证，以及用户可运行的精确命令。

不要为了让测试变绿而删除断言、扩大容差或跳过失败用例，除非需求本身明确改变了被测试行为。