需求文档标准化

如果说AI协作分析和心理安全是需求阶段的“道”，那么需求文档标准化就是“术”。它将所有讨论、思考和决策固化为一套统一的、无歧义的格式，确保信息在传递过程中不失真。标准化的文档是DDAD（文档驱动AI开发）理念能够成功落地的根本保障。

为什么要标准化？

• 对人类而言：
  • 降低沟通成本：团队成员知道去哪里找什么信息，无需反复询问。
  • 确保信息完整：模板强制要求思考和填写所有关键维度，避免遗漏。
  • 便于审查和交接：统一的格式让审查更高效，也让新成员能快速上手。
• 对AI而言：
  • 提高理解准确性：AI擅长处理结构化、可预测的信息。标准化的文档是AI最喜欢的“食物”。
  • 实现流程自动化：基于标准化的文档，我们可以编写脚本，让AI自动完成任务拆解、测试用例生成等工作。

核心标准化内容

需求文档的标准化主要包括三个方面：模板、流程和变更管理。

1. 需求文档模板体系

我们不推荐用一份庞大而臃肿的文档来描述所有事情，而是采用一个模板“体系”，用不同粒度的文档来承载不同层面的信息。

a. PRD (产品需求文档) - 宏观视角

PRD关注的是“Why”和“What”，是需求的最高层视图。

PRD模板 (prd-template.md)

# [功能/项目名称] - 产品需求文档 (PRD)

### 1. 背景与问题 (Background)
- **要解决什么问题?** 描述当前用户或业务遇到的痛点。
- **为什么现在要做?** 阐述该需求的紧迫性和商业价值。

### 2. 目标与成功指标 (Goals & Metrics)
- **业务目标**: 希望达成什么业务成果 (如: 提升用户留存率5%)。
- **成功指标**: 如何量化地衡量目标是否达成 (如: 新功能次日留存率、用户满意度评分)。

### 3. 用户画像与故事 (User Personas & Stories)
- **目标用户**: 描述核心用户群体的特征。
- **核心用户故事**: 从用户视角描述最高阶的需求。
  - 作为 [用户角色], 我希望 [完成某件事], 以便 [达成某个目的]。

### 4. 功能范围 (Scope)
- **In-Scope**: 本次迭代明确要包含的核心功能列表。
- **Out-of-Scope**: 明确本次迭代**不**包含的功能，以防范围蔓延。

### 5. 核心业务流程 (Flowchart)
使用Mermaid图等工具，绘制核心的用户旅程或业务流程图。

b. Task-Doc (任务分解文档) - 微观视角

Task-Doc是PRD的进一步分解，是开发者可以直接用来执行的“施工图”。它关注的是“How”。（我们在“文档驱动的AI交互流程”一节已详细介绍过此模板）

Task-Doc模板 (task-doc-template.md)

### 1. 任务目标 (Goal)
### 2. 背景与上下文 (Context)
### 3. 功能需求 (Functional Requirements)
### 4. 技术约束 (Technical Constraints)
### 5. 验收标准 (Acceptance Criteria)

2. 需求文档评审流程

一份文档从草稿到最终确认，需要一个标准化的评审流程来保证质量。

graph TD
    A[起草 (Drafting)] --> B[团队内部预审];
    B --> C[正式评审会];
    C --> D{有重大修改?};
    D -- Yes --> B;
    D -- No --> E[最终确认 (Approved)];
    E --> F[归档 (Archived)];

    subgraph A [ ]
     A1["产品经理/需求提出者编写初稿"]
    end
    subgraph B [ ]
     B1["与核心开发/测试进行小范围沟通"]
     B2["使用AI进行完整性检查"]
    end
    subgraph C [ ]
     C1["所有相关方参与"]
     C2["主持人设定心理安全基调"]
    end

3. 需求变更管理 (Change Management)

在敏捷开发中，需求变更是不可避免的。关键不在于杜绝变更，而在于规范地管理变更，使其影响可控。

变更请求流程：

1. 提交变更请求 (CR)：任何人都可以提交CR，但必须使用标准模板，说明变更内容、原因和预期价值。
2. 影响分析：技术负责人和产品经理需要快速分析该变更对当前迭代的工作量、进度和风险的影响。
3. 决策：基于影响分析，产品负责人决定是“接受并纳入当前迭代”、“放入待办池”还是“拒绝”。
4. 文档更新：一旦变更被接受，必须立即更新所有相关的需求文档（PRD, Task-Doc等），并通知所有相关人员。文档是唯一事实来源。

变更请求模板 (change-request-template.md)

# 需求变更请求 (CR)

- **CR编号**: [自动生成]
- **提出人**:
- **日期**:
- **关联需求**: [链接到原始PRD或Task-Doc]

---

### 变更描述
(清晰描述要变更的内容)

### 变更原因
(为什么需要这个变更？)

### 影响分析 (由负责人填写)
- **工作量评估**:
- **进度影响**:
- **风险评估**:

### 决策结果 (由产品负责人填写)
- [ ] 接受
- [ ] 拒绝
- [ ] 放入待办池
- **决策理由**:

---

本节小结： 标准化是规模化、高质量协作的基石。通过建立一套从宏观PRD到微观Task-Doc的模板体系，执行严格的评审流程，并用规范的变更管理来应对变化，我们就能为团队和AI打造一个清晰、稳定、高效的协作框架，让“文档驱动”真正落到实处。

下一章： 第6章 多会话并行开发