D1.16.1Result verifiability设计研究
用户需要能验证反馈所声称的结果确实发生
别名: verifiable feedback · outcome verification · system trust · audit trail
概念解释
结果可核对性（result verifiability）是指系统说某项操作成功、已保存、已发送、已发布或已更新后，用户能够通过对象状态、记录、产物、对方可见性或历史证据独立确认该结果确实发生。反馈本身是声明，不是证据；对低后果本地操作，屏幕上的对象变化可能已足够。对支付、发布、共享、同步、删除或跨端任务，仅凭一句「成功」无法排除延迟、局部缓存、权限失败、覆盖或后续回滚，必须有可查验的结果路径。
机制
系统与用户掌握的信息不对称：后台过程、外部服务和其他用户的状态不可直接看到。可核对证据把抽象承诺转化为可观察事实，帮助用户建立信任、及时发现异常并在需要时向他人说明发生了什么。没有核对路径时，用户只能相信提示或靠重复操作试探；一旦结果与提示不符，错误往往拖到后续流程才暴露，恢复成本更高。核对不是不信任系统，而是分布式和异步系统中必要的闭环。
怎么研究
让参与者完成不同后果的操作后，不提示他们「现在请检查」，观察是否能自然找到结果、判断其范围和发现故意注入的不一致。测量验证成功率、定位时间、错误发现时机、重复操作和对系统可信度的判断。测试应包含跨设备、外部收件人、权限变化、离线恢复与后台失败；只在操作端显示成功的 happy path 无法证明结果可核对。
边界
并非每个微操作都值得生成审计记录或二次确认。核对成本应与后果匹配，不能把简单编辑变成繁琐的验证流程。另一方面，显示更多日志并不自动可核对：用户需要能理解证据与操作的关系。敏感结果还要平衡隐私、权限和信息暴露，可用受控历史、摘要或授权查看，而不是完全取消可验证性。
怎么落地
- 为每类关键结果定义可观察证据：对象的新状态、版本、时间戳、收件人可见性、交易记录、可下载产物或可查询历史。
- 将成功反馈链接到证据而非仅展示文本，并说明结果范围、可能仍在进行的部分和何处继续追踪。
- 对跨端或外部依赖结果区分「本端已提交」与「对方/服务已生效」，不要用一个成功词覆盖不同承诺。
- 在故障、延迟与权限变更中测试：用户应能发现声明与事实不一致，并得到安全的恢复或求助路径。