需求评审要问"数据从哪来"
AI 功能的需求文档常写"用大模型自动完成 X" ✗ —— 这不是需求，是手段 ✗。
评审时用下面七个问题把需求逼清楚 ✔，能挡掉大半会后返工 ✔。
七个问题
1. 输入是什么、从哪来？
用户输入？还是历史数据？格式稳定吗？（不稳定 → 先做解析与清洗 ✔）
2. 输出的"对"怎么定义？
谁来判对错、按什么标准？（说不出标准 → 先做标注与标准 ✔，见标注质量那篇 ✔）
3. 错了会怎样？
影响范围多大、能不能回滚？（后果不可控 → 必须加人工确认 ✔，见接线那篇 ✔）
4. 数据合规吗？
含个人信息吗？能喂给模型吗？（不能 → 先做最小必要与脱敏 ✔）
5. 评测怎么做？
有多少真实样本、多久跑一次？（答不上 → 先建 100~300 条评测集 ✔）
6. 成本与延迟预算是多少？
单次多少钱、P95 多少秒？（没有预算 → 见预算那篇 ✔）
7. 失败了怎么办？
降级链是什么？用户看到什么？（没有降级 → 见降级那篇 ✔）
三个常见反模式
- "先做出来看看" ✗：没有判定标准就无法验收 ✔，最后变成"看起来还行就上线" ✗；
- "用最强的模型" ✗：把成本问题推迟到线上暴露 ✔；
- "数据我们都有" ✗：实际往往没有标注、没有授权、没有评测集 ✔。
评审的输出应该是什么
一场有效评审的产出不是"通过" ✔，而是：
- 一份判定标准（含拒答/澄清类 ✔）；
- 一份评测集计划（样本来源、规模、周期）；
- 一张预算表（成本 + 延迟 + 配额）；
- 一个降级与回滚方案；
- 一串未解决的风险（如实列出 ✔，而不是假装没有 ✗）。
一条判据
如果评审会后没人能说清"怎么判断这个功能做得好不好" ✔，那这场评审只是签了个字 ✗。
适用边界
这套七问对新功能与大改动都适用 ✔；对纯样式/文案类改动不必走全流程 ✔（按影响面分级 ✔）。