@guru-ai-product/ai-product-kit 0.1.251112172507

package/skills/aipk_requirements/documentation/SKILL.md

@@ -0,0 +1,930 @@
+---
+name: requirements-documentation
+description: Unified guide for requirement documentation and iteration templates, ensuring correct template selection and execution.
+---
+
+# 需求文档与迭代模板指南
+
+## 执行指南
+
+**重要提示：本指南专为自动化文档生成设计，请严格按照以下规则执行**
+
+### 执行原则
+
+1. **严格遵循模板结构**：生成文档时必须完全按照提供的模板结构，不得添加模板中未定义的章节或内容
+2. **模板优先原则**：当本指南与具体模板内容存在差异时，以模板内容为准
+3. **内容完整性**：必须生成完整的五个部分文档，不得遗漏任何模板中定义的内容
+4. **格式一致性**：严格按照模板中的格式要求，包括标题层级、表格格式、代码块等
+5. **无额外内容**：禁止在模板结构之外添加任何额外的章节、说明或内容
+
+### 模板选择确认（必需步骤）
+
+**⚠️ 重要：在执行任何文档生成工作前，必须先完成模板选择确认**
+
+Agent必须遵循以下流程：
+
+1. **分析用户需求场景**：
+   - 判断是新产品/功能开发（从0到1）还是现有功能迭代优化
+   - 分析需求的复杂度和范围
+   - 评估是否需要完整的产品定位、商业化策略等
+
+2. **给出模板推荐**：
+   - **推荐使用"需求文档模板"的情况**：
+     - 新产品开发（从0到1）
+     - 重大功能模块开发
+     - 需要完整的产品定位、市场分析、商业化策略
+     - 需要用户旅程设计和完整的UI/UX规划
+   - **推荐使用"需求迭代模板"的情况**：
+     - 现有功能的优化迭代
+     - 小功能新增或修改
+     - 基于现有产品的功能改进
+     - 只需要描述功能变更逻辑和实现方案
+
+3. **等待用户确认**：
+   - 明确告知用户推荐的模板类型及推荐理由
+   - **暂停执行，等待用户明确确认**使用哪个模板
+   - 只有获得用户确认后，才能继续执行后续流程
+
+**确认格式示例**：
+
+```text
+根据您的需求描述，我建议使用 [需求文档模板/需求迭代模板]。
+
+推荐理由：
+- [理由1]
+- [理由2]
+- [理由3]
+
+请确认是否使用该模板，或告知需要使用另一个模板。
+```
+
+**模板选择决策树**：
+
+```text
+用户需求
+│
+├─ 新产品开发（从0到1）？
+│  └─ 是 → 需求文档模板
+│
+├─ 需要完整的产品定位、市场分析、商业化策略？
+│  └─ 是 → 需求文档模板
+│
+├─ 需要用户旅程设计和完整的UI/UX规划？
+│  └─ 是 → 需求文档模板
+│
+├─ 现有产品功能迭代优化？
+│  └─ 是 → 需求迭代模板
+│
+├─ 只需要描述功能变更和实现方案？
+│  └─ 是 → 需求迭代模板
+│
+└─ 其他情况 → 基于主要特征判断
+```
+
+### 执行流程
+
+**重要说明**：确认模板后，根据选择的模板执行对应的流程：
+
+- **如果选择"需求文档模板"**：执行下方的"需求文档模板执行流程"
+- **如果选择"需求迭代模板"**：执行下方的"需求迭代模板执行流程"
+
+**⚠️ 文件夹结构初始化（必需步骤）**：
+
+在执行任何文档生成工作前，必须先完成文件夹结构检查和创建：
+
+1. **检查 requirements 文件夹**：检查 `../requirements` 或项目根目录下的 `requirements` 文件夹是否存在，如果不存在则创建
+2. **检查版本文件夹**（⚠️ 兼容性优先）：
+   - **首先检查老结构**：检查是否存在 `requirements/versions/` 文件夹（忽略大小写）
+     - 如果存在，**必须使用老结构**，不要创建新结构，不要迁移文件
+   - **然后检查新结构**：如果不存在老结构，检查 `requirements/vX.X.X/`
+   - **创建新结构**：如果两种结构都不存在，创建新结构：`requirements/v1.0.0/`（默认版本）
+   - **必须创建需求池**：无论使用哪种结构，都必须创建 `v0.0.0` 文件夹作为需求池
+3. **检查子文件夹**：在每个版本文件夹下（包括 v0.0.0）检查并创建以下子文件夹：
+   - `draft/`：草稿文档
+   - `archived/`：已废弃的文档
+   - `assets/`：素材文件
+   - `reference/`：参考资料
+   - `changes/`：变化日志（可使用 `@requirements-changes` 工具来检查和记录变化）
+
+详细说明请参考 [6.3.1 文档存储位置和版本管理](#631-文档存储位置和版本管理)
+
+---
+
+## 需求文档模板执行流程
+
+**重要说明**：本执行流程与下方"3. 需求文档撰写全流程"中的各阶段紧密对应，请结合阅读。
+
+**⚠️ 流程完整性要求**：阶段零的两个步骤是**必需**的，不得跳过。只有完成阶段零-1和阶段零-2的确认后，才能进入正式的需求文档撰写流程。
+
+1. **文件夹结构初始化**（**必需** - 在执行任何文档生成前）
+   - **目标**：确保文档存储结构完整，便于后续文档管理和组织
+   - **执行步骤**：
+     - 检查并创建 `skills/aipk_requirements`（项目主仓库的规范位置），如需在单独项目中落地可在项目根目录下创建 `requirements/`
+     - 检查并创建版本文件夹（默认 `v1.0.0`）
+     - **必须创建需求池**：创建 `v0.0.0` 文件夹作为需求池
+     - 检查并创建版本文件夹下的子文件夹（`draft/`、`archived/`、`assets/`、`reference/`、`changes/`）
+   - **详细说明**：参考 [6.3.1 文档存储位置和版本管理](#631-文档存储位置和版本管理)
+
+2. **阶段零-1：快速草稿阶段**（**必需** - 对应撰写流程的阶段零-1）
+   - **目标**：快速确定产品核心方向，避免后续返工
+   - **模板读取**：读取 [产品需求草稿模板](./template/Draft_产品需求草稿.md) 了解草稿格式
+   - **文档生成**：使用草稿模板快速梳理核心想法，文档保存在版本文件夹下的 `draft/` 子文件夹中
+   - **核心内容**：基于第一性原理，专注最核心问题：核心问题、产品形态、解决方案、商业模式、关键指标、最大风险
+   - **Review与确认**：**暂停执行，等待产品负责人确认产品方向**
+   - **通过标准**：产品负责人明确确认产品方向、形态和核心价值主张
+
+3. **阶段零-2：用户旅程草稿阶段**（**必需** - 对应撰写流程的阶段零-2）
+   - **目标**：基于确认的产品方向，梳理用户使用流程和关键节点
+   - **前置条件**：必须完成阶段零-1的确认
+   - **模板读取**：读取 [用户旅程草稿模板](./template/Draft_用户旅程草稿.md) 了解草稿格式
+   - **文档生成**：使用用户旅程草稿模板梳理用户使用流程，文档保存在版本文件夹下的 `draft/` 子文件夹中
+   - **核心内容**：基于已确认的产品需求草稿，设计用户从发现到使用的完整旅程，识别关键用户接触点和决策节点
+   - **Review与确认**：**暂停执行，等待产品负责人确认用户旅程设计**
+   - **通过标准**：产品负责人明确确认用户旅程设计的合理性和完整性
+
+4. **阶段一：需求探索与定义阶段**（对应撰写流程的阶段一）
+   - 读取 [需求收集](../intake/SKILL.md) 和相关分析模板
+   - 进行需求来源识别、分析与验证、优先级排序
+   - **Review与确认**：暂停执行，等待产品团队确认目标用户和市场定位
+
+5. **阶段二：核心内容撰写阶段**（对应撰写流程的阶段二）
+   - 读取 [需求文档模板索引](./template/index.md) 了解整体结构
+   - 读取 [第一部分：产品定位与分析](./template/1_产品定位与分析.md) 和 [第二部分：功能需求](./template/2_功能需求.md) 模板
+   - 严格按照模板结构生成产品定位分析和功能需求文档
+   - 确保文档内容与模板要求完全一致
+   - 保持文档间的逻辑连贯性和内容一致性
+   - **Review与确认**：暂停执行，等待产品经理确认文档结构和内容
+
+6. **阶段三：方案细化与评审阶段**（对应撰写流程的阶段三）
+   - 读取 [第三部分：商业化策略](./template/3_商业化策略.md) 和 [第四部分：用户界面与体验](./template/4_用户界面与体验.md) 模板
+   - 进行商业化策略设计、用户界面设计、方案细化
+   - 补充界面文案和交互设计内容
+   - **Review与确认**：暂停执行，等待跨部门评审确认
+
+7. **阶段四：定稿与发布阶段**（对应撰写流程的阶段四）
+   - 获取关键利益相关者的最终批准
+   - 将文档归档，并通知所有团队成员
+   - **Review与确认**：暂停执行，等待产品负责人最终确认
+
+8. **质量检查阶段**（贯穿整个流程）
+   - 验证生成的文档是否完全符合模板结构
+   - 检查是否遗漏了模板中的任何必要内容
+   - 确认没有添加模板外的额外内容
+
+---
+
+## 需求迭代模板执行流程
+
+### 历史文档检查（必需前置步骤）
+
+**⚠️ 重要：在开始需求迭代前，必须先完成历史需求文档检查**
+
+在开始任何需求迭代工作前，必须执行以下步骤：
+
+1. **查找历史需求文档**：
+   - 在项目的 `requirements/` 或 `../` 目录下查找相关的历史需求文档
+   - 检查当前版本文件夹（如 `v1.0.0/`）及历史版本文件夹中的需求文档
+   - 查找与当前迭代功能相关的需求文档（包括需求文档模板和需求迭代模板生成的文档）
+
+2. **分析历史需求内容**：
+   - 仔细阅读历史需求文档中的相关功能描述、设计思路和实现方案
+   - 识别历史文档中的设计决策、交互流程、技术方案等关键信息
+   - 理解现有功能的完整上下文和设计意图
+
+3. **基于现状进行迭代**：
+   - **保持一致性**：尽量参考现有的设计（除了用户明确要调整的部分），保持统一和一致
+   - **继承现有设计**：对于用户未明确要求修改的部分，应继承历史文档中的设计思路和实现方案
+   - **明确变更范围**：清晰标识哪些是新增内容，哪些是对现有设计的修改
+   - **说明变更原因**：对于需要调整的部分，在需求背景中说明变更的原因和依据
+
+4. **文档引用**：
+   - 在需求背景或附录中引用相关的历史需求文档
+   - 明确说明本次迭代与历史文档的关系（继承、修改、扩展等）
+
+**检查清单**：
+
+- [ ] 已查找并阅读相关的历史需求文档
+- [ ] 已理解现有功能的完整设计和实现方案
+- [ ] 已明确本次迭代的变更范围和原因
+- [ ] 已确保未明确要求修改的部分与历史文档保持一致
+- [ ] 已在文档中引用相关的历史需求文档
+
+### 模板使用流程
+
+1. **历史文档检查**（**必需**）：完成上述历史文档检查步骤
+2. **结构遵循**: 严格按照模板的章节结构填写，不得添加或删除章节
+3. **内容填写**: 逐章节填写实质性内容，确保每个章节都有明确的信息
+4. **格式保持**: 保持与模板相同的标题层级、编号格式和内容组织方式
+5. **质量检查**: 完成所有章节后，检查是否遗漏任何模板定义的章节
+
+### 模板使用要求
+
+- 必须填写所有主要章节（需求背景、整体修改逻辑、客户端实现、服务端实现、附录）
+- 根据功能特点选择适用的子章节，不适用的章节使用 `*略*` 标记
+- 每个子部分都要有详细的实施说明
+- 保持文档简洁，专注于核心内容
+
+### 模板内容处理规则
+
+1. **标题处理**: 将模板标题中的 `[功能名称] - [功能描述]` 替换为具体的功能名称和描述
+2. **占位符处理**: 将模板中的 `[内容]` 替换为实际内容，替换后不要保留中括号
+3. **条件内容**: 根据功能特点选择适用的子章节，不适用的章节使用 `*略*` 标记
+4. **可选内容**: 模板中标注为"可选"的内容，根据项目实际情况决定是否填写
+5. **示例内容**: 模板中的示例内容应替换为实际项目相关内容
+
+### 质量检查清单
+
+- [ ] 文档标题已替换为具体的功能名称和描述
+- [ ] 所有模板章节都已填写
+- [ ] 没有添加模板外的章节
+- [ ] 标题层级与模板一致
+- [ ] 内容格式与模板保持一致
+- [ ] 没有多余的说明或注释
+- [ ] 所有占位符已替换为实际内容
+- [ ] 不适用的章节已使用 `*略*` 标记
+- [ ] 条件内容已根据实际情况处理
+
+### 文件命名规范
+
+**文档文件命名格式**: `YYYYMMDD_功能模块_迭代描述.md`
+
+**示例**:
+
+- `20250818_PickForMe_菜单识别推荐功能.md`
+- `20250818_健康指标_新增健康评分系统.md`
+- `20250818_引导页_用户体验优化.md`
+
+**文档标题格式**: `[功能名称] - [功能描述]`
+
+**示例**:
+
+- `PickForMe - 菜单识别推荐功能`
+- `健康指标 - 新增健康评分系统`
+- `引导页 - 用户体验优化`
+
+### 参考模板
+
+- [需求迭代模板](./template/需求迭代模板.md) - 完整的需求迭代模板
+- [需求迭代索引模板](./template/需求迭代索引.md) - 需求迭代索引模板
+
+### 关键约束
+
+- **禁止添加**：任何模板中未定义的章节、说明、注意事项等
+- **禁止修改**：模板中定义的标题结构、格式要求、内容组织方式
+- **禁止扩展**：模板中未明确要求的内容范围或深度
+- **必须包含**：模板中定义的所有必要章节和内容要求
+- **AI体验要求**：如果产品涉及AI功能，必须严格按照 [4.6 AI体验感标准](#46-ai体验感标准) 进行设计和描述
+
+### 文档输出要求
+
+- 严格按照 [8.3 文档输出规范](#83-文档输出规范) 中的要求生成文档
+- 确保文件命名、目录结构、版本管理完全符合规范
+- 索引文档必须包含完整的文档信息表格和修订历史
+- 各部分文档必须包含正确的导航链接
+
+### 特别注意事项
+
+1. **流程完整性**：**阶段零的两个步骤是必需的，不得跳过**。必须完成阶段零-1和阶段零-2的确认后，才能进入正式的需求文档撰写流程。
+2. **模板依赖**：所有文档内容必须基于提供的模板生成，不得自行创建新的文档结构
+3. **内容限制**：严格按照模板中定义的内容范围进行撰写，不得超出模板要求
+4. **格式保持**：保持模板中定义的所有格式要求，包括标题、列表、表格、代码块等
+5. **链接完整性**：确保所有模板链接和导航链接的正确性
+6. **版本控制**：严格按照版本管理规范创建文档目录结构
+7. **AI体验标准**：如果产品涉及AI功能，必须严格遵循AI体验感标准，确保用户输入简化、输出透明、支持迭代优化
+
+### 流程完整性检查清单
+
+在开始任何需求文档撰写工作前，请确认以下检查项：
+
+**需求文档模板检查项**：
+
+- [ ] **文件夹结构已初始化**：requirements 文件夹、版本文件夹（vX.X.X）及子文件夹（draft、archived、assets、reference、changes）已创建
+- [ ] **阶段零-1已完成**：产品需求草稿已生成并通过产品负责人确认
+- [ ] **阶段零-2已完成**：用户旅程草稿已生成并通过产品负责人确认
+- [ ] **产品方向明确**：核心问题、产品形态、解决方案、商业模式已确定
+- [ ] **用户旅程清晰**：主要用户旅程和关键接触点已识别
+- [ ] **团队共识达成**：所有关键利益相关者对产品方向达成一致
+
+**需求迭代模板检查项**：
+
+- [ ] **历史文档已检查**：已查找并阅读相关的历史需求文档
+- [ ] **现有设计已理解**：已理解现有功能的完整设计和实现方案
+- [ ] **变更范围已明确**：已明确本次迭代的变更范围和原因
+- [ ] **一致性已确保**：已确保未明确要求修改的部分与历史文档保持一致
+
+**注意**：如果以上任何一项未完成，请先完成相应的前置工作，再进行后续需求文档撰写。
+
+---
+
+## 1. 概述
+
+本指南旨在规范产品需求文档（PRD）的撰写流程和标准，确保需求文档的质量和一致性。高质量的需求文档是产品成功的基础，它能够清晰地传达产品愿景、目标和具体功能，为设计、开发和测试团队提供明确的指导。
+
+**重要提示：模板使用指南**
+
+当您使用本指南时，请根据具体需求主动读取相关的模板文档。本指南中提到的所有模板链接都是可访问的，建议您：
+
+1. **根据当前任务阶段**，读取对应的模板文档以了解具体的撰写要求
+2. **在开始撰写前**，先阅读相关模板的结构和内容要求
+3. **在撰写过程中**，随时参考模板以确保格式和内容的准确性
+4. **对于复杂任务**，建议同时阅读多个相关模板以获得完整的指导
+
+本指南中的模板链接都是相对路径，您可以直接访问这些文件来获取详细的模板内容。
+
+## 2. 需求文档的目的
+
+在开始撰写之前，首先要明确需求文档的核心目的：
+
+- **明确方向**: 定义产品的目标、范围和核心价值主张。
+- **达成共识**: 作为团队沟通和协作的基础，确保所有利益相关者对需求有统一的理解。
+- **指导执行**: 为产品开发、设计和测试工作提供清晰、可执行的路线图。
+- **规避风险**: 详细描述功能与约束，确定技术依赖，提前识别潜在风险。
+
+## 3. 需求文档撰写全流程
+
+本节将详细介绍从需求探索到最终文档定稿的完整流程，并将需求分析、文档结构等概念融入其中。**本流程与上方"执行流程"部分紧密对应，请结合阅读。**
+
+### 3.1 流程概览图
+
+```mermaid
+graph TD
+    A[阶段零-1：快速草稿<br/>**必需**] --> A1{Review & 确认};
+    A1 -- 通过 --> A2[阶段零-2：用户旅程草稿<br/>**必需**];
+    A1 -- 需要调整 --> A;
+    A2 --> A2_1{Review & 确认};
+    A2_1 -- 通过 --> B[阶段一：需求探索与定义];
+    A2_1 -- 需要调整 --> A2;
+    B --> B1{Review & 确认};
+    B1 -- 通过 --> C[阶段二：核心内容撰写];
+    B1 -- 需要调整 --> B;
+    C --> C1{Review & 确认};
+    C1 -- 通过 --> D[阶段三：方案细化与评审];
+    C1 -- 需要调整 --> C;
+    D --> D1{达成共识?};
+    D1 -- 是 --> E[阶段四：定稿与发布];
+    D1 -- 否 --> D;
+    E --> E1{Review & 确认};
+    E1 -- 通过 --> F[持续进行：需求变更管理];
+    E1 -- 需要调整 --> E;
+    
+    %% 样式定义
+    classDef required fill:#ffebee,stroke:#d32f2f,stroke-width:3px
+    classDef normal fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
+    classDef decision fill:#fff3e0,stroke:#f57c00,stroke-width:2px
+    
+    class A,A2 required
+    class B,C,D,E,F normal
+    class A1,A2_1,B1,C1,D1,E1 decision
+```
+
+**⚠️ 重要说明**：阶段零-1和阶段零-2是**必需**的，不得跳过。只有完成这两个阶段的确认后，才能进入正式的需求文档撰写流程。
+
+### 3.2 各阶段详解
+
+**重要提示**：以下各阶段与上方"执行流程"中的对应阶段保持一致，每个阶段都包含模板读取、文档生成和Review确认三个核心环节。
+
+#### 阶段零-1：快速草稿（**必需**）
+
+- **目标**: 在产品初期快速确定方向，避免过度设计和后续返工。
+- **重要性**: 这是整个需求文档撰写流程的**基础阶段**，必须完成，不得跳过。
+- **对应执行流程**: 阶段零-1：快速草稿阶段
+- **核心活动**:
+  - **模板读取**: 读取 **[产品需求草稿模板](./template/Draft_产品需求草稿.md)** 了解草稿的具体结构和要求
+  - **文档生成**: 使用草稿模板快速梳理核心想法，文档保存在版本文件夹下的 `draft/` 子文件夹中
+  - 基于第一性原理，专注最核心问题：核心问题、产品形态、解决方案、商业模式、关键指标、最大风险
+  - 团队内部快速讨论和确认产品方向
+- **关键产出**:
+  - 产品核心定位和功能优先级
+  - 产品形态选择和技术方向
+  - 商业化方向确认
+  - 关键风险识别
+- **Review与确认**:
+  - **暂停执行，等待人工确认**
+  - 产品负责人review草稿内容
+  - 确认产品方向和核心假设
+  - **必须获得明确确认**：产品方向、形态和核心价值主张
+  - 只有在获得人工确认后，才继续执行后续流程
+- **通过标准**:
+  - 产品负责人明确确认产品方向
+  - 产品形态选择合理且可行
+  - 核心价值主张清晰明确
+  - 商业化方向基本确定
+- **使用建议**:
+  - **所有产品需求文档撰写都必须从此阶段开始**
+  - 完成草稿后再进入用户旅程草稿撰写流程
+  - 草稿内容将作为完整需求文档的基础
+
+#### 阶段零-2：用户旅程草稿（**必需**）
+
+- **目标**: 在需求草稿确认后，快速梳理用户使用流程和关键节点，为后续详细设计提供基础。
+- **重要性**: 这是确保产品设计以用户为中心的**关键阶段**，必须完成，不得跳过。
+- **前置条件**: 必须完成阶段零-1的确认
+- **对应执行流程**: 阶段零-2：用户旅程草稿阶段
+- **核心活动**:
+  - **模板读取**: 读取 **[用户旅程草稿模板](./template/Draft_用户旅程草稿.md)** 了解草稿的具体结构和要求
+  - **文档生成**: 使用用户旅程草稿模板梳理用户使用流程，文档保存在版本文件夹下的 `draft/` 子文件夹中
+  - 基于已确认的产品需求草稿，设计用户从发现到使用的完整旅程
+  - 识别关键用户接触点和决策节点
+  - 团队内部快速讨论和确认用户旅程设计
+- **关键产出**:
+  - 用户旅程地图和关键节点
+  - 用户接触点和交互流程
+  - 潜在的用户体验问题和优化机会
+  - 用户旅程相关的功能需求
+- **Review与确认**:
+  - **暂停执行，等待人工确认**
+  - 产品负责人review用户旅程草稿内容
+  - 确认用户旅程设计的合理性和完整性
+  - **必须获得明确确认**：用户旅程设计合理且完整
+  - 只有在获得人工确认后，才继续执行后续流程
+- **通过标准**:
+  - 用户旅程设计合理且完整
+  - 关键用户接触点识别准确
+  - 用户流程逻辑清晰
+  - 潜在问题识别充分
+- **使用建议**:
+  - **所有产品需求文档撰写都必须完成此阶段**
+  - 完成用户旅程草稿后再进入正式的需求文档撰写流程
+  - 用户旅程草稿内容将作为后续详细设计的重要参考
+
+#### 阶段一：需求探索与定义
+
+- **目标**: 明确产品要解决的核心问题、目标用户和市场机会。这是所有后续工作的基础。
+- **对应执行流程**: 阶段一：需求探索与定义阶段
+- **核心活动**:
+  - **模板读取**: 读取 [需求收集](../intake/SKILL.md)、[市场机会评估与竞争分析模板](../intake/template/市场机会评估与竞争分析模板.md)、[深度用户行为与需求洞察模板](../intake/template/深度用户行为与需求洞察模板.md) 等模板文档
+  - **需求来源识别**: 从用户反馈、市场调研、竞品分析、内部业务需求、技术趋势等渠道收集原始需求。
+  - **需求分析与验证**:
+    - 使用**KANO模型**分析需求对用户满意度的影响。
+    - 通过**用户访谈**和**问卷调查**验证需求真伪。
+    - 运用**用户故事映射**将宏观需求转化为具体场景。
+  - **优先级排序**: 采用**优先级矩阵**或**影响力/工作量分析**对需求进行排序。
+- **关键产出**:
+  - 市场分析报告
+  - 用户画像 (User Persona) 与用户旅程图
+  - 经过验证和排序的需求列表
+- **Review与确认**:
+  - **暂停执行，等待人工确认**
+  - 产品团队review需求分析结果
+  - 确认目标用户和市场定位
+  - 验证需求优先级排序的合理性
+  - 只有在获得人工确认后，才继续执行后续流程
+- **参考工具与指南**:
+  - [需求收集](../intake/SKILL.md)
+  - [市场机会评估与竞争分析模板](../intake/template/市场机会评估与竞争分析模板.md)
+  - [深度用户行为与需求洞察模板](../intake/template/深度用户行为与需求洞察模板.md)
+    > **提示**：请根据具体需求读取这些模板文档，了解详细的分析框架和工具使用方法
+
+#### 阶段二：核心内容撰写
+
+- **目标**: 基于第一阶段的分析，使用模块化模板撰写需求文档的核心内容，形成初稿。
+- **对应执行流程**: 阶段二：核心内容撰写阶段
+- **核心活动**:
+  - **模板读取**: 首先读取 [需求文档模板索引](./template/index.md) 了解整体结构，然后读取 [第一部分：产品定位与分析](./template/1_产品定位与分析.md) 和 [第二部分：功能需求](./template/2_功能需求.md) 模板
+  - **文档生成**: 严格按照模板结构生成产品定位分析和功能需求文档
+  - **文档信息**: 填写版本、作者等基本信息。
+  - **产品概述**: 描述产品背景、市场定位、愿景目标和核心价值。
+  - **用户与市场**: 详细描述目标用户、用户角色和市场分析。
+  - **功能与非功能需求**: 定义核心功能列表、详细描述及优先级，并明确性能、安全、兼容性等非功能要求。特别注意多语言支持需求（英文、日文、韩文）。
+  - **AI功能体验要求**: 如果产品涉及AI功能，必须按照 [4.6 AI体验感标准](#46-ai体验感标准) 的要求进行功能设计，确保用户输入简化、输出透明、支持迭代优化。
+- **关键产出**:
+  - 包含产品定位分析和功能需求的PRD初稿 (v0.1)。
+- **Review与确认**:
+  - **暂停执行，等待人工确认**
+  - 产品经理review文档结构和内容完整性
+  - 确认功能需求描述的准确性和可执行性
+  - 验证非功能需求的合理性
+  - 验证AI功能体验要求的合理性（如适用）
+  - 只有在获得人工确认后，才继续执行后续流程
+- **参考模板**:
+  - [第一部分：产品定位与分析](./template/1_产品定位与分析.md)
+  - [第二部分：功能需求](./template/2_功能需求.md)
+    > **提示**：撰写需求文档时，请务必先读取这两个模板文档，了解具体的文档结构和内容要求
+
+#### 阶段三：方案细化与评审
+
+- **目标**: 协同设计和开发团队，将需求转化为具体的方案，并通过评审达成共识。
+- **对应执行流程**: 阶段三：方案细化与评审阶段
+- **核心活动**:
+  - **模板读取**: 读取 [第三部分：商业化策略](./template/3_商业化策略.md) 和 [第四部分：用户界面与体验](./template/4_用户界面与体验.md) 模板
+  - **商业化策略设计**: 设计商业化模式、IAA和IAP策略、定价策略、功能分层等。
+  - **用户界面设计**: 绘制信息架构图（使用Mermaid图表）、用户流程图，设计线框图和高保真原型，评估技术可行性。
+  - **AI交互设计**: 如果产品涉及AI功能，必须按照 [4.6 AI体验感标准](#46-ai体验感标准) 设计AI交互界面，确保输入简化、输出透明、支持迭代优化。
+  - **界面文案补充**: 为每个界面添加“界面文案 (Interface Copy)”小节，包含该界面所需的英文用户界面文案。可沿用现有需求文档模板中的写法，保持语调一致，尤其要覆盖 IAP 付费页面的文案要求。
+    > **提示**：请读取此模板文档，了解界面文案的具体格式要求和生成方法
+  - **组织评审**: 邀请所有利益相关者（产品、设计、开发、测试等）进行正式评审。详见 **第5节：需求文档评审**。
+- **关键产出**:
+  - 商业化策略与定价方案
+  - 交互原型与UI设计稿
+  - AI交互设计方案（如适用）
+  - 评审会议纪要
+  - 修订后的需求文档
+- **Review与确认**:
+  - **暂停执行，等待人工确认**
+  - 跨部门评审会议（产品、设计、开发、测试、业务）
+  - 确认技术可行性和资源需求
+  - 验证商业化策略的合理性
+  - 验证AI交互设计的合理性（如适用）
+  - 达成团队共识并记录决策
+  - 只有在获得人工确认后，才继续执行后续流程
+- **参考模板**:
+  - [第三部分：商业化策略](./template/3_商业化策略.md)
+  - [第四部分：用户界面与体验](./template/4_用户界面与体验.md)
+    > **提示**：请根据当前任务需要，读取相应的模板文档，了解具体的撰写要求和格式规范
+
+#### 阶段四：定稿与发布
+
+- **目标**: 完成最终版需求文档，并正式发布给项目团队。
+- **对应执行流程**: 阶段四：定稿与发布阶段
+- **核心活动**:
+  - 获取关键利益相关者的最终批准。
+  - 将文档归档，并通知所有团队成员。
+  - 制定并沟通后续的变更管理流程。详见 **第6节：需求变更管理**。
+- **关键产出**:
+  - 最终版产品需求文档 (PRD v1.0)
+- **Review与确认**:
+  - **暂停执行，等待人工确认**
+  - 产品负责人最终review和批准
+  - 确认文档完整性和准确性
+  - 正式发布并通知所有相关团队
+  - 只有在获得人工确认后，才完成最终发布
+
+## 4. 需求文档撰写原则
+
+### 4.1 清晰性
+
+- 使用简洁明了的语言，避免模糊和歧义的表述。
+- 使用标准化的术语，并在附录中提供术语表。
+- 提供具体的例子和场景。
+
+### 4.2 完整性
+
+- 覆盖所有必要的产品方面，包括边界条件和异常情况。
+- 明确说明约束和限制。
+
+### 4.3 可验证性
+
+- 需求应该是可测试的，提供明确的验收标准。
+- 避免主观和无法量化的描述，使用具体的指标和数值。
+
+### 4.4 一致性
+
+- 保持文档内部以及与其他产品文档的一致性。
+- 使用统一的格式和模板。
+
+### 4.5 可追溯性
+
+- 为每个需求分配唯一标识符，记录其来源和理由。
+- 建立需求之间的关联关系，并记录变更历史。
+
+### 4.6 AI体验感标准
+
+**重要提示**：当产品涉及AI功能时，必须遵循以下AI体验感标准，确保用户获得流畅、直观的AI交互体验。
+
+#### 4.6.1 用户输入简化原则
+
+- **最小化输入**：用户的输入要尽量简单、符合直觉，用户的输入越少越好，步骤越短越好
+- **智能预判**：基于用户历史行为和上下文，智能预判用户意图，减少用户输入需求
+- **渐进式输入**：采用渐进式输入方式，先收集核心信息，再根据需要进行补充
+
+#### 4.6.2 AI输出透明度原则
+
+- **过程可视化**：如果涉及到AI的输出，输出的过程应该尽量透明，清晰体现过程的步骤甚至中间结果（如果能有的话）
+- **实时反馈**：在AI处理过程中提供实时进度反馈，让用户了解当前处理状态
+- **中间结果展示**：在可能的情况下，展示AI处理的中间步骤和思考过程
+
+#### 4.6.3 迭代式改进原则
+
+- **支持迭代式改进**：用户可以在现有的结果基础上进行编辑、优化，编辑过程需要的用户的输入依然要尽量简单、符合直觉
+- **增量优化**：支持用户对AI输出结果进行增量式修改，而不是重新生成
+- **智能建议**：在用户编辑过程中，提供智能建议和优化选项
+
+#### 4.6.4 应用场景
+
+这些AI体验感标准应在以下文档部分中具体体现：
+
+- **用户旅程设计**：在用户旅程草稿和核心用户旅程中体现AI交互流程
+- **功能需求描述**：在功能需求文档中明确AI功能的交互要求
+- **界面设计规范**：在用户界面与体验设计中体现AI交互界面要求
+- **交互设计原则**：在交互设计部分详细说明AI交互的具体实现方式
+
+## 5. 需求文档评审
+
+需求文档评审是确保文档质量和团队共识的关键环节。关于详细的评审流程、标准和最佳实践，请参阅 [需求评审](../review/SKILL.md) 文档。
+
+> **提示**：该文档包含了完整的评审框架、检查清单、AI辅助评审方法等详细内容
+
+## 6. 工具和资源
+
+### 6.1 AI辅助工具
+
+- **Prompt生成工具**: [Prompt生成](../../tool_prompts/Prompt生成.md) - 用于生成高质量的AI Prompt
+- **文档更新标记工具**: [标记文档更新](../../tool_prompts/标记文档更新.md) - 自动标记文档中的更新内容
+- **图表生成工具**: [生成DrawIO文档](../../tool_prompts/生成DrawIO文档.md) - 自动生成DrawIO图表代码
+- **AI体验设计工具**: [AI体验设计指南](../../tool_prompts/AI体验设计指南.md) - 用户输入简单需求，生成符合AI体验标准的交互设计指导
+- **需求变动说明工具**: [需求变动说明工具](../changes/SKILL.md) (`@requirements-changes`) - 用于检查和记录需求文档的变化，生成变化日志文档
+
+### 6.2 模板和示例
+
+**需求文档模板**:
+
+- [需求文档模板索引](./template/index.md) - 包含快速草稿模板和四个模块化模板
+- [产品需求草稿模板](./template/Draft_产品需求草稿.md) - 用于快速确定产品方向的简化模板
+- [第一部分：产品定位与分析](./template/1_产品定位与分析.md)
+- [第二部分：功能需求](./template/2_功能需求.md)
+- [第三部分：商业化策略](./template/3_商业化策略.md)
+- [第四部分：用户界面与体验](./template/4_用户界面与体验.md)
+
+**需求迭代模板**:
+
+- [需求迭代模板](./template/需求迭代模板.md) - 完整的需求迭代模板
+- [需求迭代索引模板](./template/需求迭代索引.md) - 需求迭代索引模板
+
+**通用指南模板**:
+
+- [指南文档标准模板](../../../docs/guide_writing_standard/template/指南文档标准模板.md) - 用于撰写各类标准指南。
+- [工具使用指南模板](../../../docs/guide_writing_standard/template/工具使用指南模板.md) - 用于撰写工具类的使用说明。
+    > **提示**：如需撰写其他类型的指南文档，请参考这些标准模板
+
+### 6.3 文档输出规范
+
+#### 6.3.1 文档存储位置和版本管理
+
+**重要：需求文档的存储位置和版本管理规范**
+
+**存储位置要求**：
+
+- **优先选择**：如果项目中已存在 `docs` 文件夹，则在 `docs` 目录下创建 `requirements` 文件夹
+- **备选方案**：如果项目中没有 `docs` 文件夹，则在项目根目录下创建 `requirements` 文件夹
+- 在 `requirements` 文件夹下创建版本文件夹（默认为 `v1.0.0`）
+- 将所有需求文档文件放置在对应的版本文件夹下
+
+**文件夹结构初始化流程**：
+
+在开始生成需求文档前，必须完成以下文件夹结构检查和创建：
+
+1. **检查 requirements 文件夹**：
+   - 检查 `../requirements` 或项目根目录下的 `requirements` 文件夹是否存在
+   - 如果不存在，则创建对应的 `requirements` 文件夹
+
+2. **检查版本文件夹结构**：
+   - **⚠️ 重要：兼容性优先原则**：如果项目中已存在老结构（`requirements/versions/` 或 `requirements/Versions/`，忽略大小写），必须保持使用该结构，**不要迁移到新结构**
+   - **检查顺序**：
+     1. **首先检查老结构**：检查是否存在 `requirements/versions/` 文件夹（忽略大小写），且该文件夹下存在版本文件夹（格式：`vX.X.X`）
+        - 如果存在，则**必须使用老结构**，不要创建新结构，不要迁移文件
+     2. **然后检查新结构**：如果不存在老结构，检查 `requirements` 文件夹下是否存在版本文件夹（格式：`vX.X.X`）
+        - 如果存在，则使用新结构
+     3. **创建新结构**：如果两种结构都不存在，则创建新结构 `requirements/v1.0.0/`（默认版本）
+   - **需求池文件夹**：无论使用哪种结构，都必须创建 `v0.0.0` 文件夹作为需求池，用于存放暂未安排版本的需求文档
+   - 如果已存在版本文件夹，则使用最新的版本文件夹，或根据需求创建新版本
+
+3. **检查版本文件夹下的子文件夹**：
+   在每个版本文件夹下，必须确保存在以下子文件夹：
+   - **`draft/`**：存放草稿文档（如产品需求草稿、用户旅程草稿等）
+   - **`archived/`**：存放已废弃的文档（保留历史记录但不再更新）
+   - **`assets/`**：存放素材文件（包括图片、设计资产等）
+   - **`reference/`**：存放参考资料（主要是外部的文档、研究报告等）
+   - **`changes/`**：存放变化日志文档（记录需求文档的变更历史）
+   - 如果这些子文件夹不存在，则必须创建
+
+**目录结构示例**：
+
+**新结构（推荐）**：版本文件夹直接位于 `skills/aipk_requirements` 下
+
+**情况一：在 AI Product Kit 主仓库**
+
+```
+项目根目录/
+├── skills/
+│   └── aipk_requirements/
+│       ├── v0.0.0/                 # 需求池（暂未安排版本的需求）
+│       │   ├── draft/
+│       │   ├── archived/
+│       │   ├── assets/
+│       │   ├── reference/
+│       │   └── changes/
+│       └── v1.0.0/                 # 正式版本
+│           ├── draft/              # 草稿文档
+│           │   ├── Draft_产品需求草稿.md
+│           │   └── Draft_用户旅程草稿.md
+│           ├── archived/           # 已废弃的文档
+│           ├── assets/             # 素材文件（图片、设计资产等）
+│           ├── reference/          # 参考资料（外部文档、研究报告等）
+│           ├── changes/            # 变化日志（需求文档变更记录）
+│           │   └── YYYYMMDD_需求文档变动说明_版本范围.md
+│           ├── index.md
+│           ├── 1_产品定位与分析.md
+│           ├── 2_功能需求.md
+│           ├── 3_商业化策略.md
+│           └── 4_用户界面与体验.md
+└── 其他项目文件...
+```
+
+**情况二：在业务仓库中落地（无 `skills/` 目录）**
+
+```
+项目根目录/
+├── requirements/
+│   ├── v0.0.0/                     # 需求池（暂未安排版本的需求）
+│   │   ├── draft/
+│   │   ├── archived/
+│   │   ├── assets/
+│   │   ├── reference/
+│   │   └── changes/
+│   └── v1.0.0/                     # 正式版本
+│       ├── draft/                  # 草稿文档
+│       │   ├── Draft_产品需求草稿.md
+│       │   └── Draft_用户旅程草稿.md
+│       ├── archived/               # 已废弃的文档
+│       ├── assets/                 # 素材文件（图片、设计资产等）
+│       ├── reference/              # 参考资料（外部文档、研究报告等）
+│       ├── changes/                # 变化日志（需求文档变更记录）
+│       │   └── YYYYMMDD_需求文档变动说明_版本范围.md
+│       ├── index.md
+│       ├── 1_产品定位与分析.md
+│       ├── 2_功能需求.md
+│       ├── 3_商业化策略.md
+│       └── 4_用户界面与体验.md
+└── 其他项目文件...
+```
+
+**老结构（兼容）**：版本文件夹位于 `requirements/versions/` 下（仅当已存在此结构时使用）
+
+```
+项目根目录/
+├── skills/
+│   └── requirements/
+│       └── versions/
+│           ├── v0.0.0/            # 需求池（暂未安排版本的需求）
+│           │   ├── draft/
+│           │   ├── archived/
+│           │   ├── assets/
+│           │   ├── reference/
+│           │   └── changes/
+│           └── v1.0.0/            # 正式版本
+│               ├── draft/
+│               ├── archived/
+│               ├── assets/
+│               ├── reference/
+│               ├── changes/
+│               ├── index.md
+│               └── ...
+└── 其他项目文件...
+```
+
+**结构选择规则**：
+
+- **⚠️ 兼容性优先**：如果项目中已存在 `requirements/versions/` 结构（忽略大小写），**必须保持使用该结构**，不要迁移到新结构，不要改变已有的文件夹结构
+- **新结构使用**：只有在完全不存在任何版本文件夹的情况下，才创建新结构 `requirements/vX.X.X/`
+- **不混用**：同一项目中应统一使用一种结构，不要同时存在两种结构
+- **不迁移**：如果已存在老结构，不要将文件迁移到新结构，保持原有结构不变
+- **需求池文件夹**：无论使用哪种结构，都必须创建 `v0.0.0` 文件夹作为需求池，用于存放暂未安排版本的需求文档
+
+**⚠️ 重要注意事项**：
+
+- 根据项目中是否已存在 docs 文件夹来选择对应的存储位置，不要同时创建两个 requirements 文件夹
+- **兼容性要求**：如果项目中已存在 `requirements/versions/` 结构（忽略大小写），**必须保持使用该结构**，不要迁移到新结构，不要改变已有的文件夹结构
+- **结构检测**：检查时忽略大小写，`versions`、`Versions`、`VERSIONS` 都视为老结构
+- **新结构创建**：只有在完全不存在任何版本文件夹的情况下，才创建新结构 `requirements/vX.X.X/`
+
+**版本管理规范**：
+
+- 使用语义化版本号（如 v1.0.0、v1.1.0、v2.0.0）
+- **需求池版本**：`v0.0.0` 作为特殊版本号，用于存放暂未安排版本的需求文档
+- 重大变更时递增主版本号
+- 功能增加时递增次版本号
+- 错误修复时递增修订版本号
+- 每个版本创建独立的文件夹，保留历史版本
+- 每个版本文件夹必须包含完整的子文件夹结构（draft、archived、assets、reference、changes）
+
+**子文件夹用途说明**：
+
+- **`draft/`**：存放所有草稿文档，包括产品需求草稿、用户旅程草稿等未正式确定的文档
+- **`archived/`**：存放已废弃或不再使用的文档，保留历史记录但不再更新
+- **`assets/`**：存放所有素材文件，包括图片、设计资产、UI组件示例等
+- **`reference/`**：存放参考资料，包括外部文档、研究报告、竞品分析等参考资料
+- **`changes/`**：存放变化日志文档，记录需求文档的变更历史。可以使用 [需求变动说明工具](../changes/SKILL.md) 来检查和记录变化
+
+**变化日志管理**：
+
+- **工具使用**：使用 `@requirements-changes` 工具来检查和记录需求文档的变化
+- **文档生成**：参考 [需求变动说明生成指南](../changes/template/需求变动说明生成指南.md) 生成变化日志文档
+- **文档命名**：变化日志文档命名格式为 `YYYYMMDD_需求文档变动说明_版本范围.md`，保存在对应版本文件夹下的 `changes/` 子文件夹中
+- **文档内容**：变化日志应包含变动概述、Commit历史、文档级变动详情、功能维度变动分析、产品策略分析等
+
+#### 6.3.2 文档文件结构要求
+
+**重要：必须生成四个独立的文档文件，严格按照以下结构和命名规范：**
+
+1. **索引文件**：`index.md` - 提供各部分文档的导航和概览
+   - **作用**：通过 `index.md` 维护一个版本内的多个文档，作为版本文档的入口和导航中心
+   - **维护要求**：**必须保持更新**，当版本内添加、删除或修改文档时，需要同步更新 `index.md` 中的文档列表和链接
+   - **包含内容**：文档信息表格、修订历史、文档导航链接、文档概览说明
+   - **文档列表**：列出该版本下的所有文档，包括各部分文档、草稿文档、变化日志等
+2. **第一部分**：`1_产品定位与分析.md` - 基于研究报告的产品定位与市场分析
+3. **第二部分**：`2_功能需求.md` - 针对发现痛点的详细功能需求规格说明
+4. **第三部分**：`3_商业化策略.md` - 商业化模式、IAA和IAP策略、定价策略、功能分层
+5. **第四部分**：`4_用户界面与体验.md` - 符合用户洞察的界面与体验设计要求
+
+#### 6.3.3 文档信息表格规范
+
+**重要：文档信息表格和修订历史只在索引文档中包含**
+
+- **索引文档** (`index.md`) 必须包含完整的文档信息表格和修订历史
+- **索引文档维护**：`index.md` 是版本文档的管理中心，**必须保持更新**：
+  - 当添加新文档时，在 `index.md` 中添加文档链接和说明
+  - 当删除文档时，从 `index.md` 中移除对应条目
+  - 当文档状态变更时，更新 `index.md` 中的文档信息
+  - 当文档内容更新时，更新 `index.md` 中的修订历史
+- **各部分文档** (1-5部分) 不包含文档信息表格和修订历史
+- **文档信息表格格式**：
+
+```
+## 文档信息
+
+| 项目 | 内容 |
+|------|------|
+| 版本号 | v1.0 |
+| 作者 | [作者姓名] |
+| 状态 | [草稿/审核中/已批准] |
+
+## 修订历史
+
+| 版本 | 日期 | 描述 | 作者 |
+|------|------|------|------|
+| v0.1 | [日期] | 初稿 | [作者] |
+| v0.2 | [日期] | [修改内容摘要] | [作者] |
+| v1.0 | [日期] | 正式发布 | [作者] |
+```
+
+#### 6.3.4 文档导航要求
+
+- **索引文件** (`index.md`) 必须包含所有部分的链接和简要说明
+  - **文档列表维护**：`index.md` 应列出该版本下的所有文档，包括：
+    - 各部分正式文档（1-4部分）
+    - 草稿文档（位于 `draft/` 文件夹）
+    - 变化日志（位于 `changes/` 文件夹）
+    - 其他相关文档
+  - **保持更新**：当版本内文档发生变化时，**必须同步更新 `index.md`** 中的文档列表和链接
+- **各部分文档**必须在开头包含导航链接，能够链接到前后文档
+- **各部分文档**必须在结尾包含"上一部分"和"下一部分"的导航链接
+- **Draft模板**不包含导航链接，作为独立文档使用，但应在 `index.md` 中列出
+
+#### 6.3.5 UI草图要求
+
+在第四部分"用户界面与体验"中，**每个关键界面都必须包含UI草图**：
+
+- 使用ASCII艺术或文字描述的方式绘制界面布局
+- 包含主要界面元素的位置和功能说明
+- 标注重要的交互流程和用户操作路径
+- 确保草图与功能需求保持一致
+
+**UI草图示例格式：**
+
+```
+┌─────────────────────────────────────┐
+│              应用标题栏              │
+├─────────────────────────────────────┤
+│  [搜索框]                    [设置] │
+├─────────────────────────────────────┤
+│                                     │
+│        主要功能区域                  │
+│                                     │
+├─────────────────────────────────────┤
+│  [按钮1]  [按钮2]  [按钮3]          │
+└─────────────────────────────────────┘
+```
+
+**界面分组要求**：
+
+- 当界面数量超过5个时，建议按功能模块进行分组管理
+- 每个分组包含相关界面的设计说明和UI草图
+- 分组示例：引导页设计组（起始页、功能介绍页1-4）、主要功能界面组、设置界面组等
+- 引导页设计必须包含起始页和3-4个功能介绍页，每页聚焦一个核心功能
+
+#### 6.3.6 文档质量要求
+
+1. 符合团队协作标准的文档格式
+2. 确保需求文档与前期研究发现保持一致
+3. 基于提供的模板结构撰写完整内容
+4. 文档内容简洁明了，便于阅读和理解
+5. 前后内容保持统一，避免不一致情况
+6. 信息架构图使用Mermaid图表格式，确保清晰可读
+7. 界面文案使用英文，符合国际化要求
+8. 如果涉及AI功能，必须体现AI体验感标准，确保用户输入简化、输出透明、支持迭代优化
+
+## 7. 结语
+
+高质量的需求文档是成功产品开发的基础。通过遵循本指南中的原则和实践，产品团队可以创建清晰、完整且有价值的需求文档，为产品的设计和开发提供坚实的基础。记住，需求文档不仅仅是一份文档，它是团队共同理解和愿景的体现，是产品成功的关键要素之一。
+
+**使用总结**
+
+在使用本指南时，请记住以下关键原则：
+
+1. **主动读取模板**：不要仅依赖本指南的概述，要根据具体任务主动读取相关的模板文档
+2. **理解模板结构**：在开始撰写前，先理解模板的完整结构和内容要求
+3. **遵循格式规范**：严格按照模板中的格式要求进行文档撰写
+4. **参考最佳实践**：结合模板中的示例和说明，确保文档质量
+5. **持续学习**：通过阅读多个相关模板，建立对需求文档撰写的全面理解
+
+本指南中的所有模板链接都是可访问的，请充分利用这些资源来提升需求文档的质量和准确性。