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