# 判据定义表（模板）

> 用法：在项目立项会或第一次方案评审前，把这张表填到**每一行都能被第三方复算**为止。
> 填不出来的格子不是"以后再补"，而是"这个项目现在还不能开始"。
> 配套文章：判据先行 · [定义成功](https://xiciyang.com/blog/topics/defining-success/)

## 一、把诉求翻译成判据

| 诉求方 | 原话诉求 | 隐含约束（谁来测、在什么条件下） | 最终产物上的判据 | 归谁验收 |
|---|---|---|---|---|
| 业务 | 例：P99 ≤ 800ms | 在多少并发、多长上下文下测？ | 例：目标流量下 P99 ≤ 800ms，超时率 < 1% | 业务方 |
| 技术 | 例：单卡吞吐 ≥ 200 QPS | 时延上限是多少？batch 能开多大？ | 例：满足 P99 前提下，单卡 ≥ 200 QPS | 技术负责人 |
| 财务 | 例：单位成本减半 | 按哪套算力口径折算？含不含闲置？ | 例：按 30 天实测账单折算，单请求成本 ≤ ¥X | 财务 |

## 二、三条反例（出现任意一条，这张表还不成立）

- [ ] 判据只写在链路中间某一层（召回率、命中率、单层时延）——中间层全绿、端到端仍不可用。
- [ ] 判据没有写测量条件（并发、上下文长度、硬件、数据分布）——换个人换个环境就复算不出来。
- [ ] 判据没有验收人——没人能说"这算不算过"，方案就永远收敛不了。

## 三、四步法

1. **列冲突**：把每个诉求方的原话与隐含约束分开写。冲突通常不在诉求，在约束。
2. **选产物**：判据必须定义在最终产物上（用户看到的那一屏、交付的那份报告、跑起来的那条链路）。
3. **写条件**：每条判据补上"在什么条件下测"，否则它只是一句愿望。
4. **定验收**：每条判据指定一个验收人与一次验收动作（跑哪个脚本、看哪张表）。

## 四、签字栏

| 角色 | 姓名/工号 | 认可的判据编号 | 日期 |
|---|---|---|---|
| 业务 |  |  |  |
| 技术 |  |  |  |
| 财务 |  |  |  |

> 判据不是"大家都同意"，是"大家都同意用同一句话验收"。