给Skill加一道开工闸门：先暴露未知，再生成方案

这是「AI 协作」系列二第 5 篇。上一篇解决的是输出形态：怎样把“像我”拆成可执行标准；这一篇继续往前走一步，处理输入可信度：信息不够时，Skill 应该什么时候停下来。

读完这篇，你不需要马上重写整份 Skill。先给它加一道开工闸门：关键事实不足时，不生成完整方案，先暴露未知。

同一句需求，为什么早期版本会直接开写

为了把前后差异放在同一把尺子上，下面仍然用一个脱敏合并示例：

某新锐美妆 DTC 品牌，希望优化会员积分过期提醒，减少积分到期后的客诉，同时提升积分兑换率。

如果把这句话交给我自己写的早期 PRD Skill，它会立刻开始工作，把一句话扩成一份看起来完整的方案骨架。

几分钟后，一份章节完整、语气也像我的 PRD 初稿就出来了。

那一刻很容易产生一种虚假的轻松：文档已经有了，我似乎只需要检查。但真正开始核对后，我才发现，写作工作少了，判断工作却被藏得更深。

第一眼看，它很勤快。真正要命的，是桌面上那些还没被确认的便签。

早期版本不知道这些，却会用常见做法把空白填满。

后来的版本面对同一句需求，第一步不是写 PRD，而是先停下来：

“当前信息不足以支持完整方案生成。我先整理已知事实、当前理解和待确认问题。”

这一步的价值，不是换一种更谨慎的写法，而是把那些原本会被藏进正文的判断先摆出来。

我后来把一次次返工写成了一条硬规则：

关键事实不足时，先暴露未知，不得用行业常识补齐。

它慢的不是生成速度，而是把“能不能写”这一步提前了。

这篇要解决的不是“AI 会不会问问题”，而是更前面的判断：

现在的信息，够不够支撑它开始写完整方案？

如果不够，未知信息就应该有权阻止 AI 开工。

越像你写的错误，越容易骗过你

格式稳定以后，合并案例里出现过一条写得非常顺的业务规则：

“积分一经到期不可恢复，用户可通过任务中心重新获取积分。”

这句话的问题不在文笔。

它不像一句明显的胡话，甚至正好落在我习惯写业务规则的位置。

真正的问题是：案例设定里可能存在客服补发机制，部分特殊客诉也允许人工延期。输入里没有这条历史规则，AI 却把“不可恢复”写成了正式结论。

主流程看起来没偏，但客诉兜底、特殊例外和人工处理口径被一并遮住了。

这类错误最危险的地方，不是它错得离谱，而是它错得很像一份成熟文档。

越像你写的错误，越容易骗过你自己。

这里说“装懂”，不是说 AI 有意骗人，而是我们的协作流程没有要求它标出：哪一句有事实来源，哪一句只是常见推断，哪一句必须等人确认。

如果把这条规则拆开，它不是一个错误点，而是一组被熟悉表达包住的判断：

第四篇解决的是“好输出长什么样”。到了第五篇，我才发现还缺一层：

输出标准解决“怎么写”，开工闸门解决“现在能不能写”。

问题发生在开工之前

我之前一直在修“它写出来的东西”。

规则散了，就让它按“条件 / 动作 / 结果 / 例外”写。文字太长，就让它少解释常识。多状态交互看不清，就让它补流程图。

这些修改都有用，但它们解决的是输出层问题。

积分过期这个错误发生得更早：它在开工前就缺少事实，却仍然进入了完整生成。

这也是为什么有些 AI 初稿看起来很省时间，最后却没有真的省时间。它几分钟生成了一整份 PRD，我要花更久逐段确认：

• 哪些是输入里明确存在的事实；
• 哪些是 AI 按常识补出来的内容；
• 哪些规则不符合系统边界；
• 哪些内容必须重新问业务、客服或技术。

等完整文档已经出来，再去核对每一句，成本就变成了整篇返工。

最消耗我的不是改字，而是所有判断同时回来找我：既要追查每句话的依据，又要重新确认目标、边界和责任人。

后来的修改不是继续加一句“请谨慎”，而是给 Skill 增加一条开工规则：

信息不足时停止，不编造，不替人拍板。

给 Skill 加一道开工闸门

开工闸门不是让 AI 把问题问得越多越好。

问题太多，读者会烦；问题太虚，业务也答不上来。真正有用的是那些“缺了就会影响判断”的信息。

我现在会让 PRD Skill 在生成前先检查五类信息：

这五项不是固定答案，也不要求所有细节一次齐全。它们分别决定方案方向、当前入口、职责边界、可写规则和落地约束。

判断一项未知是否必须阻止开工，要看它会不会改变目标、可行性、核心规则、系统边界或验收口径。会改变这些关键判断，就停止完整生成；只影响文案和局部细节，可以标明假设，继续生成不受影响的部分。

所以真正的闸门不是“还有没有问题”，而是“剩下的问题会不会让方案方向发生变化”。

我写回 Skill 的规则也不再是“请尽量提问”，而是：

在开始生成 PRD 前，先检查现有输入是否足以支持业务判断。

如果缺少以下任一关键信息，不得自行编造：

1. 业务目标与衡量口径

2. 当前流程和主要痛点

3. 涉及角色与系统边界

4. 已确认的业务规则

5. 明确不能改变的约束

请先输出：

– 已知事实

– 当前理解

– 待确认问题

– 缺失信息会影响的章节

等我确认后，再继续生成完整内容。

这一步看起来会慢一点，但它把人工确认放在了完整生成之前。

以前是我把需求交出去等作业，最后再整篇批改；现在是它先摊开理解，我确认方向后再继续。

真正让我轻松的不是少写了几段文字，而是判断终于按优先级回到我面前：我负责确认方向，AI 负责整理和表达。

让输出分清事实、推断和待确认

信息不足时，Skill 不应该只说“请补充更多信息”。

这句话太空了，下一步仍然不知道怎么做。

更有用的方式，是让它先把内容拆成四部分：

• 已确认事实：输入材料中明确存在的内容；
• 当前推断：基于事实形成、但仍需判断的理解；
• 待确认问题：缺少依据，不能直接进入方案的内容；
• 受影响章节：哪些部分暂时不能生成或只能生成草稿。

真正的变化不是多了四个标签，而是每一类信息拥有了不同的使用权限：事实可以写，推断必须标，待确认会阻止相关内容继续生成。

还是用积分过期提醒举例，早期版本会直接写：

“系统将在积分到期前 7 天、3 天、1 天分别通过短信和站内信提醒用户。”

后来，我不再把它们当成四份一次性清单，而是让信息状态随着人工补充持续更新：

这不是格式升级，而是可信度升级。 读者终于知道：哪句话可以直接使用，哪句话只是暂时判断，哪句话必须停下来确认。

而且，这不是一次性的分类。每次补充信息或纠正判断后，Skill 都要重新判定信息状态、更新使用权限，并只解锁受影响的内容。

继续生成时如果又暴露新的未知，就再次进入同一轮检查。事实逐轮增加，推断逐轮收敛，待确认逐轮减少，方案也因此逐渐完善。

这一篇只处理“哪些信息有权进入方案”。完整 PRD 应该拆成哪些确认节点、出错后退回哪里，留到下一篇再展开。

改完后，我只看三个行为信号

改完开工闸门后，我先做一次最小验收，不再用“文档是不是更完整”判断修改有没有用。

我只看三个行为信号：未知有没有主动暴露，关键事实不足时有没有停止编造，人工确认有没有发生在完整文档生成之前。

在积分过期提醒案例里，它们分别对应历史异常被主动指出、短信能力不再被擅自补齐，以及确认清单完成前不生成完整文档。

这三个信号不能互相替代。停止编造不等于确认前置，覆盖遗漏也不等于已经主动暴露未知；三项都出现，才能说明开工闸门真的改变了协作行为。

这里只做一次最小验收。怎样保存失败记录、管理版本和设计正式复测，留到第七篇再展开。

这里还有一个边界要说清楚：开工闸门并不等于 AI 可以替我判断业务。

它只是把“我必须判断的地方”提前摊开。

以前这些问题藏在完整文档里，我要自己逐段挖出来；现在它们先被摆在桌面上，变成我可以确认、补充或驳回的内容。

一个成熟的 Skill，不是更会回答，而是更早知道自己不该回答。

总结：会停下来，才算真正开始协作

这一篇完成了从“怎么写”到“现在能不能写”的转换：

1. 开工前先判断信息是否足以支撑业务结论；
2. 关键未知阻止完整生成，但不影响安全部分继续推进；
3. 停下来后不只说缺信息，而是交付事实、推断、待确认和受影响章节；
4. 是否生效，不看文档更满，而看未知暴露、停止编造和确认前置。

开工闸门没有替人判断业务，只是把必须由人判断的地方提前摆出来。

这一轮最明显的感受，不是“AI 终于更听话”，而是工作重心发生了变化：我不再把大量时间花在逐句排雷，而是集中确认目标、事实、边界和取舍。

AI 接走的是整理和表达，产品经理守住的是判断责任。生成越便宜，决定什么能写、何时能写、由谁确认，越是产品经理的价值。

轮到你：写一段能放进 Skill 的规则

这次不要只列“我希望 AI 先问什么”。

给自己 30 分钟，用一个真实任务完成三步：

1. 把下面五项检查替换成你岗位里的关键信息；
2. 把规则写进 Skill，用同一条真实需求重新运行；
3. 检查它有没有主动拦下一项会改变方案方向的未知。

可以从这个最小版本开始：

在开始生成方案前，先检查现有输入是否足以支持判断。

当缺少以下任一会影响方案方向的关键信息时，不得生成完整方案：

– 业务目标与衡量口径

– 当前流程与已知痛点

– 涉及角色与系统边界

– 已确认规则与待定规则

– 不能改变的历史约束

请先输出：

– 已确认事实

– 当前推断

– 待确认问题

– 受影响章节

等我确认后，再继续生成完整内容。

这段规则只做三件事：定义开工门槛、规定何时停止、规定停止后先输出什么。

如果你做的不是 PRD，也可以把五项检查换成自己的场景：

完成标志： 在一次真实运行中，Skill 会停止完整生成，指出至少一项关键缺口，并把它交还给你确认。

灵魂拷问

例如：

写运营方案 + 默认补齐触达渠道 + 渠道能力未确认时只输出待确认清单

下期预告

系列二 · AI 协作 · 第 6 篇：别让 AI 一口气写完，把一次生成改成可回退流程。

开工前问清楚，只解决了“能不能开始”。一份 PRD 仍然包含一串相互依赖的判断，如果继续一口气生成，任何中途偏差都会让后续章节一起返工。

下一篇继续拆：

• 一份完整 PRD 应该在哪些节点停下来确认；
• 目标、流程、规则或系统出错时，分别退回哪里；
• 怎样让流程看起来变长，实际返工范围变小。

第五篇解决“现在能不能写”；第六篇解决“开始以后，怎样不一口气写到底”。