这是「AI 协作」系列二第 5 篇。上一篇解决的是输出形态：怎样把“像我”拆成可执行标准；这一篇继续往前走一步，处理输入可信度：信息不够时，Skill 应该什么时候停下来。
读完这篇，你不需要马上重写整份 Skill。先给它加一道开工闸门：关键事实不足时，不生成完整方案，先暴露未知。
为了把前后差异放在同一把尺子上，下面仍然用一个脱敏合并示例：
某新锐美妆 DTC 品牌，希望优化会员积分过期提醒，减少积分到期后的客诉，同时提升积分兑换率。
如果把这句话交给我自己写的早期 PRD Skill，它会立刻开始工作，把一句话扩成一份看起来完整的方案骨架。
几分钟后，一份章节完整、语气也像我的 PRD 初稿就出来了。
那一刻很容易产生一种虚假的轻松：文档已经有了，我似乎只需要检查。但真正开始核对后，我才发现，写作工作少了，判断工作却被藏得更深。
第一眼看，它很勤快。真正要命的，是桌面上那些还没被确认的便签。
早期版本不知道这些，却会用常见做法把空白填满。
后来的版本面对同一句需求，第一步不是写 PRD，而是先停下来：
“当前信息不足以支持完整方案生成。我先整理已知事实、当前理解和待确认问题。”
这一步的价值，不是换一种更谨慎的写法，而是把那些原本会被藏进正文的判断先摆出来。
我后来把一次次返工写成了一条硬规则：
关键事实不足时，先暴露未知，不得用行业常识补齐。
它慢的不是生成速度，而是把“能不能写”这一步提前了。
这篇要解决的不是“AI 会不会问问题”，而是更前面的判断：
现在的信息，够不够支撑它开始写完整方案？
如果不够，未知信息就应该有权阻止 AI 开工。
格式稳定以后，合并案例里出现过一条写得非常顺的业务规则：
“积分一经到期不可恢复，用户可通过任务中心重新获取积分。”
这句话的问题不在文笔。
它不像一句明显的胡话，甚至正好落在我习惯写业务规则的位置。
真正的问题是：案例设定里可能存在客服补发机制，部分特殊客诉也允许人工延期。输入里没有这条历史规则，AI 却把“不可恢复”写成了正式结论。
主流程看起来没偏，但客诉兜底、特殊例外和人工处理口径被一并遮住了。
这类错误最危险的地方，不是它错得离谱，而是它错得很像一份成熟文档。
越像你写的错误，越容易骗过你自己。
这里说“装懂”，不是说 AI 有意骗人，而是我们的协作流程没有要求它标出：哪一句有事实来源，哪一句只是常见推断，哪一句必须等人确认。
如果把这条规则拆开，它不是一个错误点，而是一组被熟悉表达包住的判断：
第四篇解决的是“好输出长什么样”。到了第五篇，我才发现还缺一层：
输出标准解决“怎么写”，开工闸门解决“现在能不能写”。
我之前一直在修“它写出来的东西”。
规则散了，就让它按“条件 / 动作 / 结果 / 例外”写。文字太长，就让它少解释常识。多状态交互看不清，就让它补流程图。
这些修改都有用，但它们解决的是输出层问题。
积分过期这个错误发生得更早：它在开工前就缺少事实，却仍然进入了完整生成。
这也是为什么有些 AI 初稿看起来很省时间，最后却没有真的省时间。它几分钟生成了一整份 PRD，我要花更久逐段确认：
等完整文档已经出来，再去核对每一句，成本就变成了整篇返工。
最消耗我的不是改字，而是所有判断同时回来找我：既要追查每句话的依据，又要重新确认目标、边界和责任人。
后来的修改不是继续加一句“请谨慎”，而是给 Skill 增加一条开工规则：
信息不足时停止，不编造，不替人拍板。
开工闸门不是让 AI 把问题问得越多越好。
问题太多，读者会烦；问题太虚，业务也答不上来。真正有用的是那些“缺了就会影响判断”的信息。
我现在会让 PRD Skill 在生成前先检查五类信息：
这五项不是固定答案，也不要求所有细节一次齐全。它们分别决定方案方向、当前入口、职责边界、可写规则和落地约束。
判断一项未知是否必须阻止开工，要看它会不会改变目标、可行性、核心规则、系统边界或验收口径。会改变这些关键判断，就停止完整生成；只影响文案和局部细节，可以标明假设，继续生成不受影响的部分。
所以真正的闸门不是“还有没有问题”，而是“剩下的问题会不会让方案方向发生变化”。
我写回 Skill 的规则也不再是“请尽量提问”，而是：
在开始生成 PRD 前，先检查现有输入是否足以支持业务判断。
如果缺少以下任一关键信息，不得自行编造：
1. 业务目标与衡量口径
2. 当前流程和主要痛点
3. 涉及角色与系统边界
4. 已确认的业务规则
5. 明确不能改变的约束
请先输出：
– 已知事实
– 当前理解
– 待确认问题
– 缺失信息会影响的章节
等我确认后，再继续生成完整内容。
这一步看起来会慢一点，但它把人工确认放在了完整生成之前。
以前是我把需求交出去等作业，最后再整篇批改；现在是它先摊开理解，我确认方向后再继续。
真正让我轻松的不是少写了几段文字，而是判断终于按优先级回到我面前：我负责确认方向，AI 负责整理和表达。
信息不足时，Skill 不应该只说“请补充更多信息”。
这句话太空了，下一步仍然不知道怎么做。
更有用的方式，是让它先把内容拆成四部分：
真正的变化不是多了四个标签，而是每一类信息拥有了不同的使用权限：事实可以写，推断必须标，待确认会阻止相关内容继续生成。
还是用积分过期提醒举例，早期版本会直接写：
“系统将在积分到期前 7 天、3 天、1 天分别通过短信和站内信提醒用户。”
后来，我不再把它们当成四份一次性清单，而是让信息状态随着人工补充持续更新：
这不是格式升级，而是可信度升级。 读者终于知道：哪句话可以直接使用，哪句话只是暂时判断，哪句话必须停下来确认。
而且，这不是一次性的分类。每次补充信息或纠正判断后，Skill 都要重新判定信息状态、更新使用权限，并只解锁受影响的内容。
继续生成时如果又暴露新的未知，就再次进入同一轮检查。事实逐轮增加，推断逐轮收敛，待确认逐轮减少，方案也因此逐渐完善。
这一篇只处理“哪些信息有权进入方案”。完整 PRD 应该拆成哪些确认节点、出错后退回哪里，留到下一篇再展开。
改完开工闸门后，我先做一次最小验收，不再用“文档是不是更完整”判断修改有没有用。
我只看三个行为信号：未知有没有主动暴露，关键事实不足时有没有停止编造，人工确认有没有发生在完整文档生成之前。
在积分过期提醒案例里，它们分别对应历史异常被主动指出、短信能力不再被擅自补齐，以及确认清单完成前不生成完整文档。
这三个信号不能互相替代。停止编造不等于确认前置，覆盖遗漏也不等于已经主动暴露未知；三项都出现，才能说明开工闸门真的改变了协作行为。
这里只做一次最小验收。怎样保存失败记录、管理版本和设计正式复测，留到第七篇再展开。
这里还有一个边界要说清楚：开工闸门并不等于 AI 可以替我判断业务。
它只是把“我必须判断的地方”提前摊开。
以前这些问题藏在完整文档里，我要自己逐段挖出来；现在它们先被摆在桌面上，变成我可以确认、补充或驳回的内容。
一个成熟的 Skill，不是更会回答，而是更早知道自己不该回答。
这一篇完成了从“怎么写”到“现在能不能写”的转换：
开工闸门没有替人判断业务，只是把必须由人判断的地方提前摆出来。
这一轮最明显的感受，不是“AI 终于更听话”，而是工作重心发生了变化：我不再把大量时间花在逐句排雷，而是集中确认目标、事实、边界和取舍。
AI 接走的是整理和表达，产品经理守住的是判断责任。生成越便宜，决定什么能写、何时能写、由谁确认，越是产品经理的价值。
这次不要只列“我希望 AI 先问什么”。
给自己 30 分钟，用一个真实任务完成三步：
可以从这个最小版本开始：
在开始生成方案前，先检查现有输入是否足以支持判断。
当缺少以下任一会影响方案方向的关键信息时，不得生成完整方案：
– 业务目标与衡量口径
– 当前流程与已知痛点
– 涉及角色与系统边界
– 已确认规则与待定规则
– 不能改变的历史约束
请先输出：
– 已确认事实
– 当前推断
– 待确认问题
– 受影响章节
等我确认后，再继续生成完整内容。
这段规则只做三件事：定义开工门槛、规定何时停止、规定停止后先输出什么。
如果你做的不是 PRD，也可以把五项检查换成自己的场景：
完成标志： 在一次真实运行中，Skill 会停止完整生成，指出至少一项关键缺口，并把它交还给你确认。
例如：
写运营方案 + 默认补齐触达渠道 + 渠道能力未确认时只输出待确认清单
系列二 · AI 协作 · 第 6 篇：别让 AI 一口气写完，把一次生成改成可回退流程。
开工前问清楚，只解决了“能不能开始”。一份 PRD 仍然包含一串相互依赖的判断，如果继续一口气生成，任何中途偏差都会让后续章节一起返工。
下一篇继续拆：
第五篇解决“现在能不能写”；第六篇解决“开始以后，怎样不一口气写到底”。
作者：Zoe产品手记 公众号：Zoe产品手记
本文由 @Zoe产品手记 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自 Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。