110-requirement-planning

name: 110-requirement-planning description: 软件需求规划技能，通过启发式访谈将用户想法转化为PRD。当用户需要：(1)规划新产品或梳理功能范围, (2)编写PRD文档, (3)设计业务流程和站点地图时触发。 alwaysApply: false author: "axeon(23231269@qq.com)" version: "2.0.0"

需求规划

项目环境检测

从当前目录向上查找 project-info.md，最多 3 层，找到后记为 PROJECT_ROOT。详见 检测方法与前置检查。未找到 → 提示用户先执行 0-init。

核心原则

需求三层模型

需求存在三个层次，各司其职：

三层之间的关系：

前后端编号独立：前端M按导航结构编号，领域M按业务领域编号，通过映射表关联。

触发检查

检查 PROJECT_ROOT/project-info.md 是否存在。

跳转 0-init 时的信息传递： 告知 0-init 当前是从 110-requirement-planning 跳转而来，0-init 完成初始化后应自动触发回到 110-requirement-planning。

角色职责

规划流程

Phase 1: 需求访谈与澄清（必须首先完成）

在编写任何文档之前，必须通过多轮启发式访谈与用户充分澄清需求细节。访谈执行原则：逐轮推进、确认理解、启发式追问、记录决策、用户确认。详见 访谈原则。

各阶段详细执行方法：1.1-1.6 每个阶段的详细提问清单、话术示例、检查清单见 访谈指南。

访谈执行原则（全局要求）

重要：以上原则是全局要求，适用于所有阶段（1.1-1.6）。详细的访谈原则、追问策略和执行方式见 访谈指南。

提问方式规范

所有访谈问题必须使用 AskUserQuestion 工具，参数要求：question（问题内容）、header（≤12字符）、options（3-5个可点击选项）、multiSelect（true/false）。工具自带"Other"选项供自由录入。

访谈框架（6个阶段）

1.1 项目背景访谈（Discovery）

目标：理解业务上下文、成功标准和约束条件。6个核心问题逐个提出。

1.2 需求探索与头脑风暴（Brainstorming）

目标：在理解背景后、锁定需求前，主动探索产品可能性。

架构能力识别：基于 UniWeb + SaaS 技术栈，识别需求中已被架构覆盖的功能。展示格式和完整清单见 访谈指南。

1.3 产品架构规划（Architecture）

用户角色和终端平台是 N:N 关系。先确定角色，再为每个角色选择平台。详见 role-platform-matrix.md。

1.4 站点地图与页面规划（Sitemap & Pages）

目标：将模块功能映射为用户可见的页面结构，确定完整的站点地图、页面层级和导航关系。

仅对前端项目执行，后端项目不参与本阶段。

门控规则：站点地图未确认前，禁止进入1.5需求澄清阶段。

详细执行步骤、展示格式和检查清单见 访谈指南。

1.5 需求澄清与验证（Clarification & Verification）

从按模块澄清改为按页面澄清，每个页面的澄清覆盖其包含的所有模块功能。仅对前端项目执行。

每个页面7步法：页面定位 → 页面元素 → 交互流程 → 异常路径 → 状态设计 → 线框图（强制） → 复述验证。

详细执行步骤、提问模板和检查清单见 访谈指南。

流程裁剪规则

根据项目复杂度自动简化访谈流程。详见 流程裁剪规则。

1.6 汇总确认（Final Confirmation）

将所有访谈信息整合为完整汇总文档，向用户提出最终确认三问，全部通过后才允许进入文档编写。

访谈检查清单（1.6最终门控）

所有访谈结束后，对照以下清单确认是否可以进入文档编写：

基础检查（1.1-1.3）：

• 项目背景和触发因素已明确
• 成功指标已量化
• 目标用户和角色已定义（含用户故事）
• 用户角色和终端平台已确认
• 项目清单已确认
• 模块划分与优先级已确认
• 架构已支持能力已识别

站点地图检查（1.4）：

• 全局导航结构已确认（Tab/侧边栏/浮动按钮）
• 完整页面清单已列出（含Tab主页、子页面、弹窗/浮层）
• 前端M→领域M映射表已完成
• 页面间跳转关系已描述
• 用户已确认完整站点地图

需求澄清检查（1.5）：

• 每个页面的定位和核心使命已明确
• 每个页面的元素和布局已描述
• 每个页面的交互流程已说明
• 每个页面的异常路径已覆盖（操作失败、超时、冲突）
• 每个页面的状态设计已完成
• 每个页面有线框图（强制）
• 页面间导航和用户体验连贯性已验证
• 用户已复述确认所有页面需求

任一项未完成，不得进入文档编写阶段。

完整清单、追问策略和示例对话见 访谈指南。

访谈记录保存

Phase 1全部完成后（1.6汇总确认通过）统一保存一份完整的访谈记录。

保存路径、命名规则和模板详见 访谈记录模板。

Phase 2: PRD文档编写

访谈完成且用户确认后，进入文档编写阶段。

输出范围限制（重要）

需求阶段只输出产品需求文档（PRD），不输出技术设计文档。

PRD文档结构（三层）

文档职责边界：

产出结构：

prds/
├── README.md                # 项目总览（唯一汇总文档，包含所有项目信息）
├── domains/                 # 业务领域（整合多端共享的业务对象和规则）
│   └── M{seq}-{name}.md    # 领域模块文档
├── {role}-{platform}/            # 前端项目
│   └── M{seq}-{name}/       # 一级菜单/功能组
│       └── M{seq}P{seq}-{name}.md  # 页面组文档
└── reviews/

文档内容要求

前端页面组文档（M{seq}P{seq}-{name}.md） 必须包含：

领域模块文档（domains/M{seq}-{name}.md） 必须包含：

重要：领域模块文档描述"业务上存在什么概念及其关系"，不定义字段、类型、表结构、API路径、技术选型。这些属于技术设计阶段的工作。

根目录 README.md 必须包含以下章节，按顺序排列：

重要：### 领域模块 必须在 ### 交互流程 上面。交互流程的时序图中 participant 必须使用具体模块名（如 M01-用户与认证），禁止使用模糊的"业务领域"。

交互流程设计规范：

按 PRD模板 编写。

⚠️ 完成验证（强制，全自动执行）

开发工作完成后，立即按以下顺序自动执行：

1. 强制调用 111-requirement-review
2. 如果评审不通过（< 95），自动修复问题，然后回到步骤 1（最多 5 轮）
3. 直到评审通过（≥ 95），才向用户报告最终结果

此流程全自动执行：中间不暂停、不询问、不汇报。 未收到通过确认前，禁止结束本技能任务。

输出要求

语言要求: 所有输出文档必须使用中文编写（包括PRD、访谈记录、评审报告等）

输出位置: PROJECT_ROOT/requirement/prds/

目录结构: 详见 目录结构

参考

• 访谈指南 - 启发式提问策略、苏格拉底式追问和示例对话
• PRD模板 - 需求文档模板（含页面文档模板和模块文档模板）
• 需求评审技能 - REVIEW评审技能