To PRD

将当前对话上下文和代码库理解合成为一份 PRD，存放在 docs/scratch/<NN>-<中文需求名称>/PRD.md。NN 记录需求进入仓库的先后顺序；中文需求名称使用 CONTEXT.md 中的统一术语。

PRD 按实际交付单元组织，不预设数量或类型。交付单元使用项目已有的边界名称。

流程

1. 加载项目上下文

按项目知识协议使用相关 CONTEXT 与适用 RULE；已有知识足够时复用，知识不可用时说明缺口并继续。

2. 确认需求依据

复用当前会话和需求材料中已确认的结论；信息足够时直接成稿。只有缺失信息会改变业务范围、规则或验收结果时才定向提问。用户要求深入压力测试，或关键取舍相互依赖时，围绕这些问题调用 ask-me。

业务规则来自需求材料、用户确认和当前适用的 RULE。代码用于查证现状；未确认内容标为未决，不把惯例或模板占位写成新需求。

3. 确定并贯彻交付范围

交付单元是本次需求中承担独立职责且会发生改动的产品端、系统、服务或渠道。根据需求目标、业务流程、代码入口和仓库布局识别；事实足以确定时直接采用，无法可靠判断且不同选择会显著改变范围时，提问确认。

4. 落地 PRD 文件

新建 PRD 时写入 docs/scratch/<下一个两位序号>-<中文需求名称>/PRD.md；更新已有 PRD 时沿用原路径。

PRD 模板

# <功能名称> PRD

## Solution
<用一个段落从用户视角概括整体解决方案，不展开各交付单元的实现细节>

## Scope

### <交付单元 1>范围
- <该交付单元的交付内容与职责>

### <交付单元 N>范围
- <该交付单元的交付内容与职责>

### 涉及角色
- <使用或办理本功能的角色>

## Out of Scope
<本次明确不做的内容>

## User Stories
1. As a <角色>, I want <功能>, so that <收益>
2. ...

## Requirements
<!-- 先按业务能力分节，再在能力内展开实际涉及的交付单元。 -->

### <能力项 1>

#### <交付单元 1>逻辑
- <按该单元职责写清交互、业务规则、状态、数据、权限、接口或流程边界>

#### <交付单元 N>逻辑
- <按该单元职责写清交互、业务规则、状态、数据、权限、接口或流程边界>

#### 协作契约
- <仅在多个交付单元存在调用顺序、数据交换或失败处理时保留>

### <能力项 2>

...

## Implementation Decisions
### 锁定决策
| 决策项 | 决策值 | 来源 |
| --- | --- | --- |
| ... | ... | 用户确认 / RULE/ <其他>  |

写法

• 完整可评审：只读本文就能判断要解决什么问题、由谁使用、交付哪些业务结果，以及明确不做什么。缺少后会改变实现分支、数据口径、状态变化、权限范围或接口契约的规则全部保留。
• 规则可执行：每条规则能单独判断对错：谁、在什么条件、做什么、结果是什么。字段、日期、状态、数量、权限有口径时写到值。
• 边界一起写：每个能力覆盖已确认的主流程与边界行为。缺失且会改变交付结果的边界作为问题收口，不为填满模板自行补规则。
• 合成而非转录：正文是收口后的需求，不是对话、选项或推理过程的摘录。
• 锁定即契约：Implementation Decisions 只收已确认且会改变交付的选择，并标明来源。
• 产品层表达：Requirements 写业务行为和规则。具体文件、代码结构、模块改造、实现步骤和代码库能力缺口留给后续实现过程。