技能介绍

需求为什么总在「对不齐」

一个功能的想法往往散落在聊天记录、访谈纪要和竞品报告里。等写到文档阶段，常常只剩一句「做个批量导出」。研发按自己的理解开工，测试按口头描述写用例，最后在验收时才发现各方说的不是同一件事。更常见的是文档里只有功能描述、没有可测的验收条件，Definition of Done 全靠自觉。

这个技能做什么

它扮演资深产品经理的撰稿搭档，把零散输入整理成一份可直接评审、可排期的结构化 PRD。工作流分五步：

收集与澄清：背景动机、业务目标、目标用户与场景、范围边界（in/out）、约束与依赖。
套用 10 节标准结构：从背景与问题、目标与成功指标、用户与场景，到功能详细、交互与界面、数据需求、非功能需求（NFR）、验收标准、排期与变更管理。
功能拆成用户故事 + 验收标准：每个模块至少一条，格式为「作为…我希望…以便…」，验收标准写成可测的 Given/When/Then。
用 MoSCoW 标注优先级：Must / Should / Could / Won't，把「本期不做」显式写进文档，避免范围蔓延。
给出里程碑草案与变更约定：评审通过即冻结，之后变更走申请，影响范围、工期、成本、风险留痕。

输出形态是结构化 PRD 大纲（Markdown）加关键工件 JSON（UserStory / Requirement）再加一句话摘要。互操作方面，上游可消费 biz-competitor-analysis 的竞品结论与调研结论，下游 biz-project-management 可直接读取 UserStory 与 PRDDocument.modules 做 WBS 分解和排期。

使用边界

它不适用于纯营销文案或 UI 视觉稿。如果诉求缺少明确的用户与场景，技能会先引导补全背景和目标，而不是硬写。量化指标一律使用占位符如 +X% / <Xms，等真实数据填入，不编造数字。PRD 带版本号，变更记录在 change_log。负责人与详细排期由项目经理在下游工具中确定，技能只提供里程碑草案。