一个真实场景
某天下午，一份产品方案在群里被宣布为"定稿"——产品经理发了会议纪要链接，@了设计和测试，写了"最终版方案已对齐，进入推进阶段"。
我打开那份"定稿"：
- 112 行
- "产品结构"部分：一张白板嵌入图
- "产品大图"部分：另一张白板嵌入图
- 5 个功能模块：全空表格
- 智能预测（核心功能）：3 张图表占位，无文字描述
工时估算已经透传给业务方了（后端 30+ 人天，前端 15-25 人天）。但估算是基于什么做的？一份内容大量空白的"定稿"。
这就是假定稿。
什么是"假定稿"
假定稿 (Assumed Draft) 是一种看起来完整、实际上充满未验证假设的产出物。
它的特征：
| 特征 | 表现 |
|---|---|
| 结构完整 | 有目录、有章节、有表格——骨架看着像回事 |
| 内容空心 | 核心细节是占位符、空表格、或"见图"但图无说明 |
| 状态膨胀 | 被标记为"定稿"/"对齐"/"ready"——超出实际成熟度 |
| 下游已启动 | 基于它已经做了排期、分配了资源、通知了利益相关者 |
关键在于最后一条：假定稿的危险不在于它本身不完整——而在于下游把它当成完整的了。
我的论点
AI 时代，每一份 AI 产出都是假定稿——除非经过人工验证。 而假定稿最危险的地方不是错误，是它让你跳过了本该做的验证。
这不只是关于产品方案。AI 帮你写的代码、设计的架构、起草的邮件、准备的会议材料——全部是假定稿。
因为 AI 的产出基于训练数据的概率推理，不是基于你的具体业务上下文的实证研究。它看起来对，是因为它在大量相似案例上"平均化"了——但你的情况可能恰好在平均值之外。
为什么假定稿比"明显错误"更危险
明显的错误容易发现——格式乱了、数字对不上、逻辑矛盾。你一看就知道不能用。
但假定稿长得像正确答案。它结构完整、措辞专业、逻辑连贯——唯一的问题是它的每一个推理都建立在未验证的假设上。
类比：
- 明显错误 = 一栋明显歪了的房子 → 你不会住进去
- 假定稿 = 一栋精美的样板间 → 你可能直接搬进去，然后发现管道没接
AI 的训练让它极其擅长产出看起来对的东西。这恰恰是问题——因为"看起来对"让人的警觉性降低。
识别假定稿的 4 个信号
基于多次翻车经验，我总结了 4 个"假定稿预警信号"：
信号 1：篇幅 >> 输入信息量
你给了 AI 3 句话的需求描述，它输出了 2000 字的完整方案。
那多出来的 1900 字从哪来的？ 答案是：AI 从训练数据中"补全"的。也就是说——假设。
经验法则：AI 产出的长度超过输入信息量 5 倍以上时，高概率是假定稿。
信号 2：没有不确定性标注
真实的专业分析会说"这里有两种可能"、"取决于 X 条件"、"需要进一步确认"。
假定稿的特征是百分百肯定语气。没有"可能"、没有"待确认"、没有"假设前提"。每个结论都像铁板钉钉——但铁板下面是空气。
信号 3：核心细节是"模板化"的
真正的方案设计会在核心难题上花大量篇幅讨论 trade-off。假定稿的核心部分往往是"标准流程"——看起来正确但完全通用，没有针对你的具体约束做思考。
信号 4：无人质疑就进入了下一阶段
最危险的信号：方案出来后，没有人问"这个假设成立吗？"就直接进入了排期/设计/开发。
防范机制
知道了假定稿的存在，怎么防？
1. 假设显式化
对 AI 产出的任何方案，追加一个步骤：列出它依赖的所有假设。
我的方案假设：
- [ ] 用户有 XX 需求（来源：产品推测 / 用户研究 / 训练数据）
- [ ] 后端接口 YY 可用（来源：技术评估 / 假设）
- [ ] 性能满足 ZZ 要求（来源：测试验证 / 估算）
把隐含假设变成可检查的清单。未验证的假设不是问题——未识别的假设才是。
2. "降级"策略
当 AI 产出一份"完美方案"时，主动降级它的状态标签：
- AI 说"定稿" → 你标记为"假设集合"
- AI 说"最终版" → 你标记为"待验证版"
- AI 说"对齐完成" → 你标记为"假设对齐（非事实对齐）"
不让假定稿享受"完成品"的待遇。
3. demo 杠杆
面对假定稿最好的武器不是"更完善的文档"——而是 demo。
把方案里的核心假设做成最小可演示的东西——一个 4-6 小时的决策剧本、一个 UI 骨架、甚至一个静态原型。
一份决策剧本（4-6h 工作量）暴露的缺口，比一份完美文档（数天工作量）暴露的多得多。
因为 demo 强制你面对真实约束——而文档可以永远活在假设里。
4. 验证 checkpoint
在流程中设置强制验证点：
| 阶段 | 验证要求 | 不满足后果 |
|---|---|---|
| 方案→排期 | 核心假设列表 + 至少 1 项已验证 | 不允许给工时估算 |
| 排期→开发 | demo 已暴露并处理 top 3 缺口 | 不允许分配开发资源 |
| 开发→测试 | 原始假设 vs 实际实现的 diff 记录 | 不允许进入测试 |
AI 时代的特殊性
假定稿不是 AI 发明的——产品经理写的空心 PRD、管理层的"战略方向"PPT、咨询顾问的"最佳实践"——都可能是假定稿。
但 AI 让这个问题指数级放大了，因为：
- AI 产出速度极快 — 验证速度跟不上产出速度
- AI 产出看起来更专业 — 格式完美、措辞得体，降低了警觉性
- AI 不会标注自己的不确定性 — 除非你显式要求
- AI 产出容易形成锚定效应 — 一旦"看到了方案"，就很难跳出来重新思考
结语
回到开头那个场景。
那份"定稿"最终没有按原样执行——因为我们用 demo 暴露了 3 个根本性缺口，迫使方案在节后做了大幅修正。但如果没有人在第一时间识别它是假定稿，设计和测试可能已经基于它排了两周的期，然后在开发中途发现"原来需求根本没定义清楚"。
一句话结论：
每次 AI 给你一份"完美方案"时，先问自己：它的每个结论基于什么？是验证过的事实，还是看起来合理的假设？
如果答案是后者——恭喜，你手里拿的是一份假定稿。不是不能用——但请把它当成起点而不是终点。
本文概念源自一次真实的产品方案对齐会议。"假定稿"这个词是我在当天复盘时造的——后来发现它是 AI 协作中最高频出现的反模式之一。