SDD 证据日志模板

当“评审通过”还不足以证明安全时，用证据日志记录每条验收标准如何被验证、证据在哪里、上线时看哪个停止信号。

evidence.md

# Evidence Log

Spec:
Release:
Owner:
Date:

## Acceptance Evidence
| Criterion | Evidence | Link | Result |
| --- | --- | --- | --- |
| AC-1 | Test | | Pass/Fail |
| AC-2 | Screenshot | | Pass/Fail |

## Operational Evidence
- Log query:
- Metric:
- Alert:
- Stop signal:

## Manual Checks
- [ ] ...

## Known Gaps
- Gap:
- Risk:
- Owner:
- Follow-up date:

什么时候使用这份模板

发布影响资金、数据完整性、权限或客户可见状态。
评审者需要看证据，而不是只看总结。
团队想保留稳定的发布说明和回滚上下文。
AI 生成代码在合并前必须提供具体证据。

填好后应该是什么样

模板只有在写入真实决策、负责人和证据后才有价值。下面是一个可评审的片段。

| Criterion | Evidence | Link | Result |
| --- | --- | --- | --- |
| AC-2 重放幂等 | Integration test | refund_timeout_replay | Pass |
| AC-3 客服阻断 | Screenshot | support-refund-pending.png | Pass |

Stop signal: duplicate_refund_attempts > 0.5% 持续 15 分钟。

实现前先检查这些点

每条验收标准都有证据类型和结果。
运行时信号是具体查询、看板、指标或告警。
已知缺口有负责人和日期。
回滚或停止信号对发布评审者可见。

弱写法 vs 强写法

弱写法

测试通过，QA 看过了。

强写法

AC-2 由 refund_timeout_replay 覆盖，AC-3 由客服 UI 截图验证，上线停止信号是 duplicate_refund_attempts 超过 0.5% 持续 15 分钟。

FAQ

每次变更都要证据日志吗？

不需要。高风险发布、API 变更、迁移、支付流、权限和 AI 生成 diff 更适合使用。

什么算证据？

测试、fixture、截图、日志查询、指标、看板、告警、手工检查或发布门禁。

它为什么能提高内容质量？

读者看到的是可操作的交付产物，而不是抽象建议；团队也能把评审变成可复现流程。

编辑说明

这份模板面向 spec-driven development 工作流，示例用于展示结构，不代表特定公司的内部流程。

作者: Daniel Marsh
编辑政策: 我们如何审阅和更新内容

建议把它放在仓库的 /docs/specs/ 或 /.specs/ 下，并在实现过程中持续更新。最后更新：2026 年 5 月 11 日。