当AI生成PRD已成常态，为何还要专门设计一款Skill？本文作者通过四次关键迭代，将个人判断、团队知识与交付标准融入AI工作流，揭示效率之外更核心的价值——让AI稳定执行产品工作流，而非简单生成模板。

最近，我做了一件看起来有点多余的事：专门设计了一款写 PRD 的 Skill。

毕竟，现在让 AI 写一份 PRD 已经不难。把需求背景贴进去，再补一句“请输出完整的产品需求文档”，几分钟后，用户故事、功能范围、异常流程和验收标准就都有了。单看生成速度，它甚至比很多产品经理写得还快。

那为什么还要多做一层 Skill？保存一段 Prompt，不也能用吗？

我最初想解决的确实是效率问题。后来一路改下来，我发现效率只是最表面的收益。真正值得做成 Skill 的，是把个人判断、团队知识和交付标准，变成 AI 可以稳定执行的产品工作流。

这三件事不是一个 Prompt 能同时解决的。

第一版只想写得更快，结果更像一台模板填充机

最早的思路很直接：准备一份 PRD 模板，告诉 AI 按固定章节输出，再补几条写作要求。这个版本马上就能看到效果——不用从空白文档开始，标题、表格和验收标准都能自动生成。

但用不了多久，问题就出来了。

首先，AI 很擅长把空白补得“像真的”。需求里没有角色权限，它会根据常见产品补一套；没有异常策略，它会生成一套看似合理的重试和兜底；模板里如果残留示例内容，它甚至可能把示例当成本次需求的一部分。

文档因此变得完整，却不一定真实。

第二个问题是固定模板会把不同需求拉成同一种形状。页面改版需要交互状态和原型，数据任务更关心口径、幂等与回滚，跨系统需求还要写责任边界和失败对账。把同一张检查表无条件套在所有需求上，只会制造大量“看起来没填完”的假问题。

第三个问题更隐蔽：模板只能约束输出长什么样，不能约束 AI 在生成前如何判断。一份 PRD 有五个章节还是十个章节，并不决定研发能不能实现、测试能不能验收。

我后来把这几种做法放在一起看，区别就很清楚了。

真正需要迭代的不是模板，而是模板前后的整条工作链路。

这张演进图里，越往后增加的越不是“更多内容”，而是更多边界：什么可以自动完成，什么必须回到我确认，什么条件没有满足就不能交付。

第一次关键迭代：参考 grill-me，先找事实，再向我提问

这一轮我参考了grill-meSkill 的思路：把模糊方案当成一棵决策树，能从现有材料找到的答案先自己找，再沿着依赖关系逐个解决真正需要人判断的分支，直到形成共同理解。

如果你经常让 AI 参与产品方案设计，我很推荐把grill-me作为必备 Skill——它最大的价值不是“多问”，而是让模糊想法在动手前变成可以执行的决策。

我给 Skill 加上的第一条硬规则，不是“写得更详细”，而是先不要写。

它要先从当前对话、项目文档、产品规范和已有材料里提取事实，再把信息分成三类：已经确认的、可以支撑分析的合理假设，以及必须由我决定的事项。

这一步听起来慢，实际是在省时间。以前我需要反复向 AI 解释项目背景；现在，能从已有材料找到的答案由 Skill 自己读取。只有那些会改变范围、实现或验收结论的问题，才交还给我。

而且一次只问一个。

很多 AI 产品喜欢一口气抛出七八个澄清问题，表面上很全面，实际像是把我变成了表单填写员。问题之间往往还有依赖：目标用户没定，权限怎么定；范围没定，异常策略怎么定；数据口径没定，验收又怎么写？

所以我把提问改成按决策依赖推进。每个问题都要说明为什么需要确认，并给出推荐答案及取舍。我做完当前决定，Skill 才进入下一条分支。

这里还有一个我很在意的边界：没有解决的问题，不能躲进最终 PRD 的“待确认”里。

如果一个问题会改变本次范围，就继续确认；如果明确暂缓，就把它转成范围外事项。最终交付稿只保留已经确认的需求和边界。否则所谓 PRD，只是把讨论现场搬进文档，并没有真的形成结论。

第二次关键迭代：不再重复喂背景，把团队知识放进 references

提问流程稳定后，我遇到的下一个问题是：为什么每次还要重新告诉 AI 团队怎么写 PRD、常见业务规则是什么、哪些场景必须检查？

答案不是继续把 Prompt 写长，而是把 Skill 拆成不同职责的文件。

Agent Skill 采用的是一种很朴素的结构：主文件描述它何时触发、按什么流程工作；参考资料和模板放在独立目录，需要时再读取。这样做叫“渐进式披露”——先让 Agent 知道有哪些能力，任务命中后再加载主流程，只有特定场景出现时才读取对应知识。

在我现在使用的版本里，已经沉淀了一套规模较大的内部产品知识库。文章不会展示其中的业务术语、规则和案例。这一轮先完成最关键的分离：SKILL.md保留触发条件、边界和主流程，团队规范、业务知识与专项检查规则放进references/，只有命中对应场景时才加载。

这里最重要的，不是文件夹叫什么，而是区分两类上下文。

稳定上下文包括团队规范、业务术语、常见异常、产品原则和历史经验，可以提前沉淀；本次需求事实包括目标、范围、新规则和具体取舍，仍然要从当前材料与我的确认中获得。

所以“有知识库以后不需要很多上下文”，准确的说法是：我不必每次重复解释稳定背景，只需要补充本次新增的事实与决策。知识库减少重复，但不会替我补齐本次需求事实。

知识库越大，治理反而越重要。过期规则如果继续被加载，AI 会非常稳定地做错事；不同资料互相冲突，Agent 也未必知道哪一份优先。因此专属知识不能只是往目录里堆文件，还需要明确适用场景、维护责任和优先级。

第三次关键迭代：生成 PRD 只是中点，不是终点

有了事实和知识，AI 生成的 PRD 已经像样很多。但我又发现一个问题：结构正确，不代表产品方案经得住评审。

例如，一个页面功能可以把字段、按钮和状态写得很完整，却没有回答用户为什么要做这个动作；一个跨系统需求可以画出调用链，却没有明确失败后由谁处理；验收标准可以句句通顺，却没有覆盖真正影响结果的业务规则。

于是我把“生成后检查一下”拆成了三个不同动作。

第一个动作发生在生成前：从产品价值、核心场景、认知负担和范围边界出发做预审。它不是让 AI 自己增加功能，而是帮助找出哪些产品决策还没做完。

这个预审不是让 AI 凭“产品经验”自由发挥。我在references/中单独维护了product-review-principles.md，把成熟的产品设计原则变成审查依据：页面交互会看尼尔森的状态可见、符合现实心智与防呆容错原则，也会按场景检查菲茨定律；表单和配置流程会看席克定律、米勒定律与奥卡姆剃刀；所有需求还会用狩野模型、聚焦核心场景和“少即是多”审视价值与范围。

这些原则不是一张“逐条加功能”的清单。Skill 会先判断需求类型和核心场景，只启用适用原则；只有会改变范围、规则、实现或验收的发现，才进入后面的逐题盘问，其余内容不能被 AI 擅自写进 PRD。

第二个动作发生在成稿后：分别站在产品和开发视角复审。产品视角看目标、角色、业务规则、异常路径和验收覆盖；开发视角看依赖、数据归属、权限、安全、并发、降级、回滚和测试可执行性。

第三个动作才是质量检查：检查模板占位符是否清干净、章节和表格是否正确、关键规则能否追溯到验收项、图表与正文是否一致。

这三个动作不能混成一张大清单。预审负责发现决策缺口，专业复审负责挑战方案，质量检查负责判断交付物是否合格。机械问题可以自动修正；凡是涉及业务取舍、数据口径、权限策略和范围变化的内容，都必须回到我这里确认。

还有一个容易被忽略的设计：检查项必须先判断是否适用。纯后端任务不应该因为没有页面截图而失败，简单页面调整也不需要硬塞一张系统架构图。质量门禁的作用是拦住真实风险，不是奖励文档长度。

第四次关键迭代：排版和图表不是装饰，也是 PRD 质量

我以前自己写 PRD 时，最容易拖延的部分之一就是画图。

流程已经想明白了，但真要打开工具画一张流程图、时序图或者状态机图，仍然要花时间摆节点、连箭头、调颜色。赶时间时，最后往往变成一串文字箭头。写的人觉得很清楚，研发和测试却要自己在脑子里重新还原关系。

所以在这款 Skill 里，排版和图表不是最后的美化动作，而是交付质量的一部分。

但我没有规定“每份 PRD 必须有一张图”。那只会让 AI 为了达标制造装饰。更稳妥的做法是先识别关系，再选择图表。

简单需求用表格和文字就能说清，不必画图；复杂关系一旦出现，就不再用一长串箭头代替。图里的节点和分支也只能来自已经确认的事实，不能借画图的机会偷偷补方案。

我没有把这些图只导出成图片，而是让 Skill 用 Mermaid 生成流程图、时序图、架构图和状态机图，并把源码直接嵌进 Markdown PRD。关系变化时，只需修改节点、条件或连线；在代码仓库里也能直接查看版本差异，不必重画整张图。

这让 PRD 同时服务两类读者：研发和测试可以直接看图，后续 Agent 也能读取正文与 Mermaid 源码，识别节点、分支、调用和状态关系，继续拆实现任务、生成测试或做变更评审，不需要先从图片里重新还原逻辑。PRD 因此不只是一份给人看的交付件，也成为 Agent 可以直接消费的需求上下文。

把四次迭代收拢，它最终按六步工作

到这里，这款 PRD Skill 已经从模板生成器变成一条有输入、决策点和质量门禁的工作流。

1.探索上下文与需求分类。 先读对话、项目文档、产品规范和材料，判断是页面交互、接口数据还是跨系统需求，再整理为已确认、合理假设和待确认三类。

2.进行资深产品原则预审。 向我提问前，先从 product-review-principles.md 选择适用原则，检查用户价值、可用性、核心场景和范围边界。预审只发现决策缺口，不把 AI 的建议直接写进 PRD。

3.按 grill-me 思路逐题盘问。 能从材料验证的事实自行验证；剩余问题按风险和依赖一次问一个，说明原因、推荐答案和取舍。未解决的问题不能进入最终稿。

4.生成 PRD。 只写已确认的事实、决策和范围外事项；遇到流程、调用、组件依赖或状态变化，才用 Mermaid 生成对应图表，截图也仅在有素材和授权时处理。

5.进行产品与开发双视角复审。 产品视角检查目标、范围、规则、角色、异常路径和验收；开发视角检查依赖、接口与数据契约、权限安全、并发、降级回滚和测试可执行性。

6.通过质量门禁后交付。 最后检查模板、结构、事实、图文一致性、规则与验收的可追溯性。格式和链接问题可以自动修正；涉及业务取舍、数据口径、权限策略或范围变化的问题，必须回到第三步重新确认，再生成、复审和复检。

这六步不是单向流水线。与模板生成器真正的区别，是它会把语义问题送回决策环节，直到阻塞问题都有结论，才向研发和测试交付 PRD。

设计到这里，我才确认它不是一段更长的 Prompt

回头看这几轮迭代，我真正做的事情可以归成四类：

• 把 AI 能自行查找的事实，与必须由我决定的问题分开；
• 把稳定的团队知识，与每次变化的需求上下文分开；
• 把生成、专业复审和交付检查分开；
• 把内容正确与表达清楚同时纳入质量标准。

四轮迭代收拢到一起，完整的 Skill 结构这时才真正出现：SKILL.md管稳定执行的主流程，references/按场景提供团队知识，assets/保存 PRD 模板与图形资源，tests/保护流程顺序、安全约束和交付门禁。

这套结构对产品经理并不陌生：主流程像产品主链路，references 像业务规则库，assets 像设计系统，契约测试与质量检查则像上线前的质量保障。Skill 设计不是神秘的“提示词工程”，仍然是在做边界、信息架构和流程设计。

这套 PRD Skill 与配套规范，已经在团队持续使用超过 3 个月。它最初从解决我自己的 PRD 工作开始：我把反复使用的判断浓缩成流程，把业务经验放进知识库，再用模板和门禁约束交付结果。

进入团队日常使用后，这件事开始反向运转。每一个新场景、边界问题和评审反馈，都会回来挑战原来的规则，迫使我重新解释为什么这样设计，再把新的判断更新进 Skill。

团队成员经常调侃：“你已经被炼成 Skill 了。”这句话其实只说对了一半——我把经验浓缩进 Skill，团队的使用反馈也在反向训练我，让我的产品方法随着 Skill 一起迭代。

这才是“团队贡献”真正吸引我的地方：不是交付一套固定答案，而是建立“个人经验—团队使用—反馈修正—Skill 更新”的循环。

它还没有完成，下一步也不只是继续加规则

目前最明显的缺口，是原型截图和自动标注还没有形成完整链路。我的设想不是让 PRD Skill 重做一套浏览器标注能力，而是联动我自己写的 MarkIt 插件：Skill 先根据需求生成待标注的页面、元素和说明清单，MarkIt 在浏览器里完成元素定位、框选、编号和截图，输出带元素信息的结构化 Markdown；Skill 再进行脱敏检查，把图片与标注结果写回 PRD。页面登录和访问仍由用户控制，不为了自动化绕过授权。

另一个缺口来自知识库本身。业务规则会变化，团队规范会迭代，历史经验也可能只适用于当时的系统。知识沉淀越多，越需要版本、适用范围和维护机制；否则知识库不是资产，而是更难被发现的过期说明书。

我现在越来越确定：对产品经理来说，设计 Skill 和设计一个产品没有本质区别——先找真正的用户问题，再拆工作流和知识边界，最后用真实任务验证它是不是比原来更好。

PRD Skill 不会替我做产品判断。它做的是另一件同样重要的事：让我已经形成的判断不用每次从头解释，也不再因为换了一次对话，就退回一份看起来完整、实际上没人敢直接开工的文档。