prd-skill：从 AI 代写 PRD 到双角色工作流

prd-skill 最早的愿景很直接：把产品经理最耗时的 PRD 写作交给 AI，让它根据背景和模板产出一份像样的需求文档。

• 最开始的目标不是做一套复杂流程，而是让 AI 接住“写 PRD”这件事。
• 输入主要是需求背景、已有想法和一个 PRD 模板。
• 期待输出是一份结构完整、可以继续评审的需求文档。

第一版方法是把模板交给 AI，让它照着章节补内容。这个阶段能解决“空白页恐惧”，但解决不了需求本身是否清楚。

• 模板能保证章节齐全，却不能保证业务规则闭环。
• AI 会把模糊背景写得很顺，但顺不等于可开发。
• 很多待确认项会被包装成看似确定的正文。

真正的低效不是 AI 不会写，而是它会把没问清的问题写成一份看似完整的文档，后面再被状态、枚举、边界和口径不断打回。

• 用户、场景、边界不清时，AI 会默认补全。
• 业务规则没有唯一真相时，交互、验收和功能点会互相漂移。
• 模糊词没有关闭时，开发和测试仍然不知道该怎么落地。

下一阶段不再只让 AI 填模板，而是把写作和审查串成工作流：先写 PRD，再检查结构、业务规则、待确认项和 spec-readiness。

• prd-write 负责把需求组织成文档，而不是一次性定稿。
• prd-review 负责找边界、状态、失败路径和验收风险。
• 一条链路开始形成：写作、审查、修订、再交付。

实际体验里，同一个对话框先写再审，审查者会继承写作者的假设。它知道刚才为什么这么写，于是更容易替文档解释，而不是站在冷启动评审视角挑问题。

• 同一上下文会把口头解释当成已写入事实。
• AI 容易默认“前面聊过”，但开发、测试和下一个 agent 并没有这些隐含背景。
• 审查报告看起来有检查动作，但 spec-readiness 仍可能留下洞。

后续把 PRD 写作和 PRD 审查拆成两个 skill。写作者负责组织材料、关闭模糊词、形成正文；审查者负责冷启动读取文档，按评审标准找风险。

• prd-writer 不再假装自己能完成独立审查。
• prd-review 不继承写作对话里的隐含前提。
• 两个 skill 的输入、输出和验收标准开始分开。

当两个 skill 还不足以消除视角偏差时，就让不同 agent 扮演不同角色：一个负责生成和修订，一个负责冷启动审查，必要时再交叉确认。

• 写作 agent 更关注材料组织、术语统一和正文完整。
• 审查 agent 更关注状态组合、失败路径、枚举关闭和口径单一源。
• 多 agent 的价值不是热闹，而是让 PRD 经得起不同上下文的读取。

prd-skill 的核心不是“写得像 PRD”，而是让文档过关：模糊词要关闭，业务规则要成为唯一真相，spec-readiness 不能被漂亮结构稀释。

• “等、相关、默认、按需、合理”这类词必须关闭或挂账。
• 业务规则负责定义真相，交互设计和验收标准只能引用，不重复发明口径。
• spec-readiness 只判断开发和测试能不能不靠作者解释继续推进。

writing-plans 不是这个 Skill Desk 的独立主角，而是 prd-skill 拆分后的实现护栏：如果 prd-review 发现 Blocker，就不能把未封口的 spec 强行拆成实施计划。

• prd-review 输出的不只是建议，而是能否进入执行的信号。
• 有 Blocker 时，下一步是回到 PRD / spec 补规则、边界、验收和状态组合，不是继续拆任务。
• writing-plans 的价值在这里被限定为实现门禁：防止漂亮文档里的洞被带进开发阶段。

prd-skill 的价值不是让 AI 写一篇漂亮文档，而是把“我有一个需求”推进成团队可以评审、开发可以拆、测试可以验、后续可以复盘的交付资产。

• 当前形态是个人 PRD 生产与审查 workflow。
• 团队复用潜力在于把需求写作、冷启动审查、spec-readiness 和实现门禁变成 SOP。
• 企业级潜力在于把 PRD、审查报告、决策记录、实施计划和知识库沉淀打通。