客户报了一个 bug，开发说"我测过没问题"，客户说"我一点就坏了"。最后谁也拿不出当时的记录，只能靠回忆和态度谈判。
这类扯皮我以前也遇到过。后来我想明白：问题不在于谁更认真，而在于"我测过了"这句话没有可复现的证据。
所以我做了一个很小的东西：验收证据包。核心流程已经开源。
它长什么样
一次运行只覆盖 3 条关键路径，每一步只有三种状态：
- PASSED：按步骤执行，实际结果与预期一致，附截图；
- FAILED：实际结果与预期不一致，附截图，修复后独立复验一次；
- UNVERIFIED：没测、测不了、或不适合自动测的，明确写"没测"，不混进通过率。
报告里同时保留执行步骤、预期结果、实际结果、截图和时间。它的价值不是"全绿"，而是争议发生的时候，双方能指着同一份记录说话。
怎么跑
仓库里带了一个合成样例站，不依赖任何客户数据，5 分钟可以跑完：
bash
npm i playwright
npx playwright install chromium
node proxy.mjs &
node run.mjs --manifest manifest.json --out out/clean
open out/clean/report.html执行链是 manifest 驱动的：每条路径写清楚要做什么、预期什么、失败了怎么复验。代理层只负责注入演示故障，不碰真实业务。
我今天从 GitHub 全新 clone 了一份跑，12 PASSED / 0 FAILED / 0 UNVERIFIED------注意这不代表"没有 bug"，只代表这 12 项确实按步骤跑过。
成功和失败样例都放了
干净基线是全绿。但失败样例更值得看。
一次注入多个故障时，两个故障可能互相掩蔽：前一个把页面搞坏，后一个就根本观察不到。演示报告会把"被掩蔽"如实标出来，而不是把"没观察到"当成"通过"。
这也是我做这个工具时最大的教训：没测到，不等于没问题。
它不做什么
- 不是安全扫描，不找漏洞；
- 不代表全站质量，只覆盖 manifest 里写的那几条路径；
- 不含后端写操作、支付、登录后的私有流程；
- 不承诺"零 bug"，只承诺"这些步骤确实跑过、结果可复现"；
- 自动执行之外仍需人工复核，尤其是失败项和未测项。
我把它跑在另一个自己的项目上（换成另一份 manifest、另一个被测目标），6 步全过，但通用检查报了 2 个资源 404------那是我自己项目里的老 bug。链子的机制是：这种属于基线已知偏差的要在 manifest 里声明，声明之后不参与门控，但报告里仍然原样列着，不会被藏起来。
为什么开源
如果证据只能由我一个人生成，那它还是"我说了算"。开源核心流程，是为了让客户或第三方能自己复跑一遍，而不是只看我给的截图。
MIT 许可，合成样例数据全虚构。欢迎跑一遍，尤其是挑"哪一步看不懂、哪条证据不可信、哪个失败样例其实没复现"。
如果你最近正好经历过一次验收扯皮，也欢迎说说当时手里有什么证据------这比单纯点个赞有用。核心流程免费；付费层只是限定范围的首次接入、人工复核和一次复测。这篇文章不卖东西，先把"可复现"这件事做扎实。