# 证据对照表

> 中文学习版译自 [AI-Native Product Management 英文原文](https://www.ainativeproductmanager.com/artifacts/proof-table.md)。

准备五条真实输入，分别交给你正在比较的模型运行，再依据一条在任何模型运行前就写好的标准来判断结果。复制这张表，先填一次；之后每当提示词、数据结构或模型发生变化，就重新跑一遍。对第一个版本来说，这是成本最低的回归防线；到了「实战篇」，它会自然发展成评测体系。

---

## 如何选择这五条输入

你的功能会遇到几类真实情况，就为每一类准备一条输入。每条都必须来自真实用户或真实记录，绝不能凭空想象。

- **典型情况。** 你预计日常最常见的输入；模型在这里失败，就意味着它到处都会失败。
- **拥挤情况。** 信息量远高于平均水平的输入：很长的清单、塞满内容的页面，或一条同时提出六个要求的消息。
- **受损情况。** 以残缺状态到达的输入：模糊照片、大量错别字，或复制粘贴后格式已经损坏的内容。
- **近乎空白的情况。** 几乎没有信息的输入；诚实的输出应该是一句简短答复，或反问一个问题。
- **类型错误的输入。** 这个功能原本就不该处理的内容；合格的输出应当拒绝处理，而不是编造答案。

第一次运行前，先为每一行写一句话，说明怎样的输出才算通过。如果看过输出后才写标准，你就会不自觉地修改标准去迁就结果。

## 对照表

| 输入（及其来源） | 模型 A 的输出合格吗？ | 模型 B 的输出合格吗？ | 备注／用一句话写明失败原因 |
| --- | --- | --- | --- |
| 典型情况： | | | |
| 拥挤情况： | | | |
| 受损情况： | | | |
| 近乎空白： | | | |
| 类型错误： | | | |

把每条输入都交给两个模型运行，并按照事先写好的标准，在每个单元格标记「是」或「否」。某一行失败时，用一句同事可以据此采取行动的话写明原因。

## 结论

**最终上线的模型：** _____

**最关键的一项失败：** _____

**不靠更大模型的修复办法**（一条提示词规则、一次值校验或一个后备方案）：_____

## 重跑记录

每次修改后都重跑全部五行，然后在这里新增一条记录。某一行从通过变成失败，就是你在用户遇到之前抓住的一次回归。

| 日期 | 改了什么 | 哪几行发生反转 |
| --- | --- | --- |
| | | |
| | | |
| | | |

## 什么时候扩充这张表

真实用户开始使用后，就停止编造输入。他们实际发来的五件最古怪的东西，应当成为第六到第十行；「上线之后：观察真实使用，再决定下一步」一章会告诉你如何从日志里把这些输入找出来。