把 PRD 协作当作一次需求访谈，而不是填表。优先一次问一个关键问题；如果确实有必要，也可以一次问几个关键问题，但不要过多。尽早起草，再逐步迭代。PRD 要始终聚焦产品表达：说明业务意图、规则、状态、文案和验收标准，但不要默认滑向 API、字段类型或后端实现细节。
当用户明显进入需求梳理阶段时，即使没有明确说出 开始写 PRD，这个 skill 也应该自动触发。
这是一个“主流程 + 按需方法参考”的 skill：
SKILL.md 负责需求协作主流程references/ 负责按需加载的 PM 方法，不要在每次触发时全部展开当用户想开始做需求、写 PRD、把功能想法整理成需求文档，或使用类似表达时触发，例如：
优先一次问一个问题；如果信息之间强相关，也可以一次问几个关键问题，但不要太多。
始终优先补齐当前最关键、最影响方向的缺失信息。
必读顺序参考：阅读 references/prd-input-workflow.md。
默认输入模板来源：使用 references/prd-input-template.md。
当下面这些信息已经基本清楚时，就先写出 V0.1，不要无限追问：
默认使用内置标准模板 references/prd-output-template.md。
只有在以下情况才覆盖默认模板：
起草后用 references/prd-output-guardrails.md 做复核边界。
V0.1 之后继续迭代。继续以少量关键问题为单位推进，优先补齐高风险缺口：
如果在迭代中遇到下面这些问题，再按需读取参考资料：
如果某个事实跨项目都稳定成立，就沉淀到业务知识体系。
如果发生了关键决策、命名变化或结构变化，就记录到复盘日志。
如果一个需求跨多轮持续澄清，就创建或更新项目级的需求访谈记录。
必读参考：
string、enum、text、object 这类字段类型如果用户明确要求技术设计，把它当作 PRD 之后的另一层工作来处理。
不要默认把业务知识当作项目里的附录。
除非用户明确提出例外，否则稳定的业务规则、术语、角色、流程和上下游关系，都应该沉淀到 references/business-knowledge-system.md 所描述的全局业务知识体系中。
在判断 PRD 可以进入评审前，先检查是否明确覆盖以下内容：
精简复核清单见 references/prd-output-guardrails.md。
如果用户已经不在“从 0 到 1 梳理需求”，而是在补文档结构、判断范围优先级、整理下游交接，可以跳过连续提问，直接基于现有 PRD 与上述参考资料做增量修订。
如果用户要求对已有文档做质量检查，先判断输入来源：
问题顺序、最小起草门槛和后续追问优先级。
当用户没有提供项目专用输入模板时，可跨项目复用的标准 PRD 输入模板。
当用户没有提供项目专用输出模板时，可跨项目复用的标准 PRD 输出模板。
PRD 最终起草时的产品边界规则和防遗漏检查。
用于在准备交付或评审需求文档时，执行统一的带分数、带结论、强约束的结构化自检主流程。
用于检查 AI 生成 PRD、正式 PRD、项目输出版 PRD，重点关注结构完整性、流程闭环、规则与验收可执行性。
用于检查公司内部需求文档、禅道需求、字段化导出内容或纯文本需求正文，重点关注章节完备度、业务规则清晰度与公司模板适配度。
用于检查 PRD 是否缺关键章节，以及哪些内容更适合归到功能流程、页面方案、规则、异常或协作附录。
用于需求范围收敛、优先级判断、Must/Should/Could 区分，以及避免 PRD 一次装下过多子问题。
用于把零散访谈原话、聊天记录、事实描述提炼成目标用户、核心场景、功能点、规则和风险。
用于把 PRD 转成给设计、研发、测试的可执行交接清单，而不是重复正文目录。
如何把业务知识当作跨项目可复用的长期文档来维护。
复盘日志该记录什么，以及在什么情况下记录。
如何配合 PRD 和复盘日志，一起维护项目级需求访谈记录。
共 4 个版本