产品说「要什么」，研发定「怎么做」。 简单需求敢写短——三行能说清的事写三页是对品鉴者的不尊重。
写 PRD 之前先问自己：这个需求几句话能说清楚？
| 档位 | 判断标准 | AoLi 写什么 | JOJO 审什么 | 篇幅 |
|---|---|---|---|---|
| 简单 | 单端、单场景、无新交互流程（改文案/删按钮/调样式/加入口） | 一句话摘要 + 变更列表 + 验收标准 | 第零关（规范检查）+ 验收标准是否合理 | ≤ 20 行 |
| 中等 | 有新交互流程，或多端/多角色，但模块内闭环、无跨模块依赖 | 一句话摘要 + 痛点验证 + 交互流程 + 关键边界 + 验收标准 | 第零关 + 资产/债务判断 + 整体和谐度 + 方向对齐 | ≤ 50 行 |
| 复杂 | 跨模块依赖、引入新概念、不可逆变更、需分阶段交付 | 一句话摘要 + 完整 PRD + 关联需求 + 分阶段计划 | 五关全走 | 按需 |
仲裁规则：档位就高不就低。 AoLi 判简单、JOJO 判中等 → 按中等写。审的人觉得信息不够，那就是不够。
所有档位共同要求：
- 第一行必须有「一句话」摘要
- 不写技术方案
- 不贴 L1 自检记录
一句话： [谁] 在 [什么场景] 遇到 [什么问题]，改成 [什么样]。
变更：
- 具体改动 1
- 具体改动 2
验收标准：
- 标准 1
- 标准 2
来源： pool #xx
注：以下代码块仅用于展示模板格式，PRD 正文中不应出现代码块。
# ✨ [模块] 功能名称
> **一句话：** [核心摘要]
## 痛点验证
（谁、什么场景、什么问题、影响多大）
## 交互流程（用户视角）
（用户操作 → 看到什么 → 得到什么反馈）
## 关键边界
（异常态、极端情况）
## 产品约束
（用户可感知的限制条件，可选）
## 验收标准
## 来源# ✨ [模块] 功能名称
> **一句话：** [核心摘要]
## 一、问题分析
### 痛点验证
### 真实案例
### 影响范围
### 现有替代方案
## 二、用户故事
## 三、方案设计
### 交互流程（用户视角）
### 边界条件
## 四、产品约束
## 五、验收标准
## 六、关联需求
列出依赖关系的 Issue 编号及前置条件。
## 七、分阶段计划| ❌ 不该出现 | ✅ 应该怎么写 |
|---|---|
| API 参数名、字段结构、代码块 | 用自然语言描述 |
| 内部实现组件名（Gateway、Adapter、Handler 等） | 用产品功能名 |
| 技术协议（file://、WebSocket 等） | 描述功能效果 |
| 性能数值（QPS、延迟 ms、50KB） | 产品语言：「3 秒内看到结果」 |
| 系统架构图、时序图 | 用户操作流程图或页面原型 |
| L1 自检记录 | 自检是工作底稿，不进 Issue 正文 |
- 一句话嗅探法：「这句话换成研发来写更合适吗？」→ 删
- 代码块红线：PRD 正文出现代码块 = 越界
- 用户感知原则：用户能感知的写，感知不到的不写
- 期望行为替代实现方式：写用户看到什么，不写系统怎么做
AoLi 整理、JOJO 评审、佳佳确认。2026-03-31。标准随团队磨合持续演进。