---
spec_id: YYYY-MM-DD-NNN-<slug>
artifact_kind: prd-requirements
target_surface: generic   # app | h5-pc | admin | backend | cli | mixed | generic
status: draft             # draft | in-review | ready-for-planning
evidence_grade: mixed     # primary | mixed | advisory
author: <作者>
created: YYYY-MM-DD
---

# <需求名称> 通用增量需求文档

> 本模板是 `spec-prd` 的通用增量 PRD 骨架，适配已有系统上的 80% 需求场景。行业、团队或合规 overlay 由项目本地模板 by-reference 叠加，不在本 packaged 模板中内置。
>
> **WHAT not HOW**：本文只写产品行为、业务规则、范围、验收、证据和约束。数据库 schema、接口字段设计、文件改动计划、任务拆解、技术选型一律不写，留给 `spec-plan`。

---

## PRD 元数据 [core]

| 项 | 内容 |
| --- | --- |
| 需求名称 | |
| 需求编号 / spec_id | |
| 业务域 | |
| 目标 surface | App / H5-PC / Admin / Backend / CLI / Mixed / Generic |
| 目标用户 / 角色 | |
| 是否触及权限、敏感数据、资金、审计或合规 | 是 / 否（若是，写明影响点与待确认方） |
| 相关文档 | 原型 / 设计稿 / 现有需求 / 运营规则 / 第三方规则 / 项目本地 overlay |

## Summary [core]

用一句话讲清「给谁、在什么场景、解决什么问题、做成什么样」。

> 例：为 CRM 运营提供统一的入金审核备注能力，在处理入金单据时记录沟通、复核意见和后续追溯依据。

## Change Delta [core]

> 增量需求的核心。说清这次相对现有系统**改了什么**，把新需求和现有能力分清楚。

| 变化类型 | 内容 | 涉及现有能力 | 风险/权限/数据影响 | 证据 tag |
| --- | --- | --- | --- | --- |
| keep（保持不动） | | | | |
| extend（在现有上扩展） | | | | |
| replace（替换现有行为） | | | | |
| remove（下线/移除） | | | | |
| unknown（待确认） | | | | |

证据 tag 取值：`confirmed-source`（已读源码/测试/文档确认）/ `user-stated`（用户明确）/ `gitnexus-pointer`（图谱线索，未经源码确认）/ `external-research`（外部资料，需标日期与来源）/ `assumption`（推断）。

涉及历史逻辑时，不得写「沿用历史逻辑」或「与之前一致」作为唯一说明；必须写清差异、保留点和影响范围。

> **写好示例（增量风格）**：
> ✗ 模糊：`extend｜优化用户列表`
> ✓ 具体：`extend｜用户列表增加"批量禁用"｜复用现有列表筛选与分页(confirmed-source: admin/user_list)｜涉及操作审计｜confirmed-source`
> 关键差别：替换了哪条现有行为、复用了什么、不碰什么，要让 plan 不必猜。

## Requirements [core]

> 一条需求 = 一个可独立验收的最小行为。用编号 + EARS 句式：「当 <触发条件> 时，<角色/系统> 应 <可观察的行为>」。

| 编号 | 触发条件 | 角色 | 系统行为 | 用户可见结果 | 对应关注点 |
| --- | --- | --- | --- | --- | --- |
| R-01 | | | | | |
| R-02 | | | | | |

业务规则单独编号（避免散落在截图/口头说明）：

- BR-001：<一条规则，"当 X 时应 Y">
- BR-002：

> **写好示例（增量风格 + 反模糊词）**：
> ✗ 模糊：`支持批量操作，体验更好`
> ✓ 具体：`R-01｜当管理员在用户列表勾选 >=1 行并点"批量禁用"时，系统应弹二次确认、确认后将选中用户置为已禁用并写审计日志，列表实时刷新被禁用状态`
> 反模糊词：不写"等/相关/合适的/更好/优化体验"；数量、状态、边界都要可验收。

**优先级分级（必填）**：每条需求标 P0/P1/P2 或 MoSCoW（Must/Should/Could/Won't）。回答"排期被砍时先砍哪些、哪些可降级、哪些阻塞上线"。

| 编号 | 优先级 | 可降级方案 | 是否阻塞上线 |
| --- | --- | --- | --- |
| R-01 | P0 / Must | | 是 / 否 |
| R-02 | | | |

业务规则建议按主题分组：

| 规则主题 | 应写清的问题 |
| --- | --- |
| 权限 / 准入 | 哪类用户可见、可申请、可操作；不匹配时拦截还是提示确认 |
| 状态 / 流程 | 状态含义、可逆性、终态、人工介入、异常恢复 |
| 数据 / 展示 | 数据来源、展示口径、脱敏、导出、刷新时机 |
| 审计 / 追溯 | 哪些关键操作留痕、谁能查、保留口径待谁确认 |
| 异常 / 降级 | 输入异常、状态冲突、重复提交、部分成功、第三方失败 |

## Scope Boundaries [core]

### 本期做

- <待填写>

### 本期不做（Non-Goals）

- <待填写>

### 与其它模块/需求的关系

> 依赖或关联的其它模块，用明确文档名 + 章节引用，不写「见上文」「见大需求」。

- <待填写>

### 跨 surface / 区域 / 客群边界

| 差异项 | 默认规则 | 场景 A | 场景 B | 是否本期覆盖 |
| --- | --- | --- | --- | --- |
| 用户准入 | | | | 是 / 否 |
| 可见范围 | | | | 是 / 否 |
| 操作权限 | | | | 是 / 否 |
| 数据展示 | | | | 是 / 否 |
| 风险提示 | | | | 是 / 否 |

## Acceptance Examples [core]

> 一条核心需求至少 1 条正向 + 1 条异常验收。用 Given/When/Then 或 EARS 等价。每条标注覆盖的 R 编号。

```text
AC-01（对应 R-01）
Given <前置状态>
When <用户动作>
Then <可观察结果>

AC-02（对应 R-02，异常）
Given <前置状态>
When <异常输入/操作>
Then <系统拒绝并提示，且不产生非预期业务副作用>
```

高风险操作必须覆盖：重复提交、状态冲突、弱网/超时、部分成功、用户取消、低权限用户、数据不同步。

## Evidence And Assumptions [core]

> 无证据的 metrics、客户反馈、业务规则、文案、政策口径，必须进这里，不得写成系统事实。

| 主张 | 类型 | 证据来源 / 为何是假设 | 需要谁确认 |
| --- | --- | --- | --- |
| | confirmed-source / user-stated / assumption | | |

涉及权限、用户数据、资金、审计、合规或安全时，在此显式标注涉及的边界；无法确认的进 Outstanding Questions。

## Project-Local Overlay Checks [conditional]

> 只有当项目本地存在行业、团队、合规、术语或模板 overlay，或 owner 明确要求叠加时填写。记录 overlay 来源，并只把它当作待确认产品约束，不当作通用事实。

| Overlay 来源 | 适用项 | 影响/展开位置 | 证据 tag |
| --- | --- | --- | --- |
| | | | |

---

## Problem Frame [conditional]

为什么做。业务现状、用户问题、运营问题或外部变化。不写实现。

## Goals / Success Metrics [conditional]

> 只在本需求确实需要论证价值/成效时填。小增量（加个开关、改个文案）无需 SMART 目标。
> 一旦填写：目标必须可衡量——指标 + 目标值 +（可得时）当前值基线 + 衡量时间。
> 模糊动词（提升 / 改善 / 优化 / 更好）替换为可观测口径。

| 目标类型 | 目标描述 | 指标类型 | 衡量指标 | 当前值（baseline） | 目标值 | 衡量时间 | 数据来源 / 证据 tag |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 业务目标 | | leading / lagging | | | | 上线后 X 天 | |
| 用户目标 | | | | | | | |
| 运营效率目标 | | | | | | | |
| 风险控制目标 | | | | | | | |

- 指标类型：`leading`（领先，快反馈，如功能使用率/7天）/ `lagging`（滞后，业务结果，如留存/满意度/30天）。核心目标建议至少各一。
- 当前值与目标值必须有证据来源或用户给出；**无可信指标时，不要编造目标值**——写成可观察口径，或把待证指标移入 Assumptions / Outstanding Questions。

## Current System Snapshot [conditional]

> 写 PRD 前对齐的现状摘要。覆盖相关现有能力、流程、页面/路由、权限/角色、状态/异常、配置。每条标 evidence tag。现状只用于约束需求、提示复用、暴露风险，**不得反向扩大产品范围**。

| 现状项 | 当前行为 | 证据 tag |
| --- | --- | --- |

## Glossary [conditional]

| 术语 | 定义 | 来源 |
| --- | --- | --- |

## 领域模型 / 核心实体 [conditional]

> 当需求涉及多个相互关联的业务对象时填写。写**产品视角的实体含义与关系**，不写数据库表结构、字段类型、外键。

| 实体 | 业务含义 | 关键属性（产品视角） | 与其它实体的关系 |
| --- | --- | --- | --- |
| | | | |

## Actors [conditional]

| 角色 | 使用场景 | 用户目标 | 权限/边界 |
| --- | --- | --- | --- |

## Use Cases [conditional]

### UC-01 <用例名>

- Actor：
- Trigger：
- Precondition：
- Main path：1. … 2. …
- Alternative / Error path：
- Outcome：
- Covers：R-0x

## Interaction Requirements [conditional]

涉及用户交互时填写。说明入口、状态、反馈文案、确认/取消、空态、加载态、错误态、可访问性或国际化需求。

## Data / Compliance Boundaries [conditional]

> 触及个人信息、敏感数据、审计、导出、政策或监管记录时必填。

| 数据 / 记录 | 类型 | 使用场景 | 可见角色 | 脱敏/留存/导出要求 | 待确认 |
| --- | --- | --- | --- | --- | --- |

## Exception Handling [conditional]

| 场景 | 系统表现 | 用户提示 | 是否可重试 | 是否产生业务副作用 |
| --- | --- | --- | --- | --- |
| 权限不足 | | | 否 | |
| 输入不合法 | | | 是 / 否 | |
| 状态冲突 | | | 是 / 否 | |
| 重复提交 | | | 否 | |
| 第三方不可用 | | | 是 / 否 | |

## Release / Operation Readiness [conditional]

| 项 | 状态 | Owner | 是否阻塞上线 |
| --- | --- | --- | --- |
| 运营/客服口径 | 已确认 / 待确认 / 不涉及 | | 是 / 否 |
| 风险/合规审阅 | 已通过 / 待审 / 不涉及 | | 是 / 否 |
| 灰度/回滚 | 已确认 / 待确认 / 不涉及 | | 是 / 否 |
| 数据/配置准备 | 已就绪 / 待确认 / 不涉及 | | 是 / 否 |

## Dependencies / Constraints / Risks [conditional]

| 类型 | 依赖/约束 | 影响 | 是否阻塞 | 当前状态 |
| --- | --- | --- | --- | --- |
| 内部系统 | | | 是 / 否 | |
| 第三方 / 其它团队 | | | 是 / 否 | |
| 规则 / 政策 | | | 是 / 否 | |

## Outstanding Questions [conditional]

> 只记当前无法决定、必须确认的问题。确认后回填正文对应章节。

| 编号 | 问题 | 为什么阻塞 | 建议确认人 | 默认建议（如有） |
| --- | --- | --- | --- | --- |

## 变更记录 / Handoff

| 日期 | 版本 | 变更 | 作者 |
| --- | --- | --- | --- |

Handoff 给 `spec-plan` 前，补充：

- Sections included：
- Requirement count：
- Acceptance example count：
- Priority distribution：
- NFR / assumption / outstanding count：
- Trace gaps：
