（3687期）prd-development – 结构化需求转化为可执行PRD

结构化需求转化为可执行PRD 结构化PRD生成工具，将模糊需求转化为开发可执行的文档，通过六阶段工作流确保需求清晰、完整、可落地 使用说明 核心用法 PRD开发工作流是一个系统化的产品需求文档生成工具，核心目标是将模糊的业务需求转化为开发人员可直接执行的PRD文档。其工作流程分为六个严格阶段： 项目背景确认 — 强制提取「问题」与「目标」两个核心要素，检查信息完整性、检测矛盾点并提供补全建议 专业领域识别 — 自动匹配并加载领域专用skill（如DNS分析、僵尸网络分析），若无匹配则询问领域 用户故事拆解 — 按统一格式（角色-场景-意图-动机）将需求拆解为编号用户故事（US-XX） 大纲确认（强制卡点） — 输出功能要点大纲后必须等待用户确认，未确认不得进入下一阶段，防止返工 功能说明撰写 — 包含功能描述、业务规则（前置条件/实现逻辑/字段状态/数据校验） 界面交互说明 — 描述页面结构、区块关系、默认状态及完整交互流程（触发-执行-成功-失败-边界） 文档输出 — 调用docx_handler生成Word文档 显著优点 流程刚性约束：阶段四的强制确认机制是核心设计亮点，有效避免需求理解偏差导致的返工 结构化思维框架：六阶段设计覆盖了从模糊意图到可执行文档的完整转化链路 领域扩展性：支持通过skill加载实现专业化增强，兼顾通用性与垂直场景 开发者视角写作：明确强调"具体可执行"原则，要求每一条需求都能直接启动开发 潜在缺点与局限 流程较重：简单需求可能因六阶段流程显得繁琐 领域依赖：当前仅内置DNS分析、僵尸网络分析两个领域skill，覆盖范围有限 自动化程度待提升：领域识别阶段若匹配失败需人工介入选择 未明确非功能性需求：性能、安全、可用性等约束未在流程中显式覆盖 适合人群 产品经理：需将会议记录/口头需求快速转化为开发文档 技术负责人：需统一团队PRD输出标准 敏捷团队：需通过用户故事驱动开发 外包/跨团队协作场景：需降低需求传递损耗 常规风险 流程卡点误用：用户可能不理解阶段四强制确认的重要性，试图跳过 领域skill缺失：非安全领域（当前内置skill均为安全方向）的需求可能无法获得专业增强 [待确认]标注累积：写作原则虽要求标注不确定项，但缺乏后续跟踪机制 设计系统依赖：界面交互阶段依赖外部design-system.md，若未提供可能导致描述不完整 原始说明 将产品需求转化为Coding Agent可执行的需求文档。当用户提到"写PRD"、"产品需求文档"、"用户故事"、"功能说明"，或提供会议记录/功能描述需要整理成开发文档时触发。