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