---
name: prd-review
description: "PRD 内审 Skill，对齐《PRD 文档标准规范 v2.4》。支持从飞书文档自动读取内容，识别 A/B/C 类型，按分型检查清单逐项审核，输出评分+必填项校验+逻辑校验+补全建议的结构化评审报告。触发关键词：审核、审查、检查、评审、内审、review、帮我审、PRD。"
agent_created: true
---

# PRD 内审 Skill（v2.4 对齐版）

## Purpose

对跨境电商 SaaS 产品（ERP / SCM / WMS / LPS）的需求文档进行结构化内审。自动识别文档类型（A/B/C），按《PRD 文档标准规范 v2.4》对应检查清单逐项审查，输出包含必填项校验、评分、逻辑审查和补全建议的完整评审报告。

## When to Use

触发此 Skill 当用户消息中包含以下任一关键词且意图为审查 PRD 文档：

**触发关键词**（任意一个即可触发）：
- 中文：`审核`、`审查`、`检查`、`评审`、`内审`、`帮我审`
- 英文：`review`、`check`、`audit`

**典型触发语**：
- "帮我审核这个需求"
- "审一下这份 PRD"
- "review this PRD"
- "需求评审：xxx"
- "检查一下文档"
- "内审用一下"

## 输入方式

支持三种输入：

1. **飞书文档链接** — 自动通过 lark-mcp 读取内容（推荐）
2. **本地文件路径** — 直接 Read 读取
3. **粘贴文本** — 用户直接贴入文档内容

**二审模式额外输入**：
- 上次审核报告（飞书链接 / 文件路径 / 粘贴文本）— 用于对比修复情况
- 若未提供上次报告但 audit-history 中存在同文档记录，自动调取

## 审核流程

### Step 1: 读取文档内容

#### 1.1 飞书文档（通过 lark-mcp）

如果用户提供了飞书文档链接，需要通过 lark-mcp 读取内容。

**飞书 URL 格式识别：**
- 知识库文档：`https://xxx.feishu.cn/wiki/xxxxxx`
- 普通文档：`https://xxx.feishu.cn/docx/xxxxxx`
- 从 URL 提取 token（最后一个 `/` 后面的部分）

**读取方式（通过 Python 调用 lark-mcp）：**

使用以下 Python 代码读取飞书文档内容：

```python
import subprocess, json

LARK_MCP_CMD = ['/opt/homebrew/bin/lark-mcp', 'mcp',
    '-a', 'cli_a95bbdfcc4389cb2',
    '-s', '6AihWdJVTCUjCXoGjegVvhnzLqPJqdUI',
    '--token-mode', 'tenant_access_token',
    '-t', 'preset.doc.default,preset.base.default',
    '-l', 'zh']

def _call_lark(tool_name, arguments, timeout=15):
    """底层调用 lark-mcp，返回工具调用结果"""
    proc = subprocess.Popen(
        LARK_MCP_CMD,
        stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE
    )
    msgs = [
        json.dumps({"jsonrpc":"2.0","id":1,"method":"initialize",
            "params":{"protocolVersion":"2024-11-05","capabilities":{},
            "clientInfo":{"name":"prd-review","version":"2.3"}}}),
        json.dumps({"jsonrpc":"2.0","method":"notifications/initialized"}),
        json.dumps({"jsonrpc":"2.0","id":2,"method":"tools/call",
            "params":{"name": tool_name, "arguments": arguments}}),
    ]
    out, err = proc.communicate(input='\n'.join(msgs).encode() + b'\n', timeout=timeout)
    for line in reversed(out.decode().strip().split('\n')):
        try:
            r = json.loads(line)
            if r.get('id') == 2:
                content = r.get('result', {}).get('content', [])
                for c in content:
                    if c.get('type') == 'text':
                        return c['text']
                return r.get('result', r)
        except: pass
    return None

def read_feishu_doc(document_id):
    """读取飞书文档原始内容，返回结构化内容"""
    return _call_lark("docx_v1_document_rawContent",
        {"path": {"document_id": document_id}})

def resolve_wiki_node(wiki_token):
    """从知识库 token 解析出实际文档的 obj_token"""
    result = _call_lark("wiki_v2_space_getNode",
        {"params": {"token": wiki_token}})
    if isinstance(result, str):
        try:
            data = json.loads(result)
            return data.get('node', {}).get('obj_token', wiki_token)
        except: pass
    return wiki_token

def write_to_feishu(markdown_content, file_name="PRD内审报告"):
    """将 Markdown 导入为飞书文档"""
    return _call_lark("docx_builtin_import",
        {"data": {"markdown": markdown_content, "file_name": file_name}})
```

**URL 解析规则：**
- 知识库链接 `https://xxx.feishu.cn/wiki/ABCDEF` → `resolve_wiki_node("ABCDEF")` 获取 document_id
- 普通文档 `https://xxx.feishu.cn/docx/ABCDEF` → 直接用 `ABCDEF` 作为 document_id

#### 1.2 本地文件

直接使用 Read 工具读取文件内容。支持 .md、.txt、.docx（需 textutil 转换）。

#### 1.3 粘贴文本

用户直接贴入时，将文本内容作为审核对象。

### Step 2: 检测是否为二审

在识别文档类型前，先检查用户输入是否包含**上次审核报告**：

**触发条件**（满足任一即为二审模式）：
- 用户同时提供了 PRD 文档 + 上次审核报告（两个文件/链接/文本）
- 用户明确提到"二审""复审""修改后再审""重新审核""check fix"
- audit-history 目录中存在该文档的上次审核记录（通过文档标题匹配）

**如果是二审模式**：
1. 读取上次审核报告，提取所有已标记的问题列表（编号 + 级别 + 问题描述）
2. 对照本次 PRD 内容，逐条判定修复状态：

| 状态 | 标记 | 判定规则 |
|------|------|----------|
| 已修复 | ✅ | 原问题在本次文档中已不存在或已有明确修改 |
| 部分修复 | ⚠️ | 原问题有改善但未完全解决（如模糊词有补充但仍有个别遗漏） |
| 未修复 | ❌ | 原问题在本次文档中仍然存在且未做任何修改 |
| 变更较大 | 🔄 | 修复方向正确但引入了新的问题或改变了设计思路 |

3. 二审评分规则：仅对未修复（❌）和部分修复（⚠️）项继续扣分，已修复（✅）项恢复对应分数
4. 在报告顶部增加"二审对比"区块（见报告模板）
5. 同步更新 audit-history JSON 中的 `is_re_review: true`

### Step 3: 识别文档类型（A/B/C）

根据文档结构和内容特征自动判断：

| 特征 | B 型（综合优化） | A 型（新功能） | C 型（紧急） |
|------|-------------|---------------|-------------|
| 标题含"优化""修复""改进" | ✅ 常见 | | ✅ 常见 |
| 有"竞品分析"章节 | | ✅ 几乎必有 | |
| 有"状态机"章节 | | ✅ 常见 | |
| 有"用户场景"章节 | | ✅ 几乎必有 | |
| 有"目标上线时间"且紧急 | | | ✅ |
| 有"触发条件""来源"字段 | | | ✅ |
| 篇幅 | 1-2 页 | 8-15 页 | <1 页 |
| 有"业务流程"含流程图 | | ✅ | |

**判断优先级**：有"触发条件"+"来源"+"目标上线时间"且篇幅短 → C 型 → 有"竞品分析"或"用户场景" → A 型 → 其他 → B 型。拿不准时标注"疑似 X 型"并说明理由。

### Step 3.5: 类型分歧确认（有分歧时暂停）

**触发条件**（满足任一即暂停）：
1. 聚合文档中某些子节被判断为不同类型（如 B 型文档中检测到疑似 A 型/C 型子节）
2. 文档标题特征与内容特征不一致（如标题写"优化"但某节含完整状态机和跨单据同步）
3. 单节内容的信息密度明显超出所属类型的典型篇幅（如 B 型某节 >3 页）

**暂停后输出类型确认提示**：

```
⚠️ **类型确认提示**

在审核过程中发现以下内容可能存在类型归档差异：

| 子节 | Skill 判断 | 判断理由 |
|------|-----------|----------|
| 第 X 节 标题 | 疑似 A 型 | 理由：... |

请确认：
- 如果确实是 A 型需求，建议拆分为独立 A 型文档后重新提交审核
- 如果认为属于 B 型需求，Skill 将按 B 型标准审核该节（不检查竞品分析、用户场景等 A 型专属项）
- 跳过确认 → 先按当前判断输出审核报告，后续可在二审中调整
```

**等待用户确认后的处理逻辑**：
- 用户确认为 B 型 → 该子节按 B 型必检项审核，A 型专属项（A2-1~A2-4、A4、B1、B2）标记为 N/A
- 用户确认为 A 型 → 建议拆分，当前仍按 A 型标准继续审核
- 用户选择跳过 → 保持 Skill 初始判断继续审核

**无分歧时**：直接进入 Step 4，不输出此提示。

### Step 4: 加载对应检查标准

读取以下参考文件获取检查标准：
- `references/checklist.md` — v2.3 分型检查清单（严重 / 重要 / 建议 / 逻辑校验）+ 评分规则 + 质量红线
- `references/spec.md` — v2.3 规范的结构要求和写作规范
- `references/domain-knowledge.md` — 跨境电商领域知识（按需）

### Step 5: 执行分型审核

按文档类型执行对应检查，同时进行评分计算和逻辑校验。

#### 4.1 结构与规范检查（严重 / 重要 / 建议）

**严重级（必须修复，阻塞开发）：**
- A1 文档完整性：背景/现状、功能描述清晰、数值具体、无模糊词
  - **A1-1 背景检查 — 看内容不看标题**：以下任一情况均视为「背景/现状说明」已存在（✅）：
    - 有独立背景章节，标题含「背景」「需求背景」「业务背景」「项目背景」「现状」「现状与问题」「当前现状」「问题描述」「问题说明」等关键词
    - 无独立标题，但章节开头 2-3 句话描述了「当前什么表现 + 产生了什么问题/影响」
    - 内容中出现「目前」「当前」「现有」「现状」「由于」「为了解决」等表述，且有具体的问题描述
  - 仅以下情况判为 ❌：完全没有任何背景/现状相关内容，直接从方案、功能描述、技术实现开始写
  - **注意**：B 型聚合文档中，每个子需求不需要独立背景章节，文档开头或首个子节有总体背景即可。后续子节若直接描述方案但问题本身已在总体背景中涵盖，不扣分
  - **A1-4 模糊词检查需上下文判定**：发现模糊词（适当、合理、若干、等、类似、尽量、必要时、优化、完善）时，检查同一句或相邻两句（下文 2 句内）是否有量化补充。有则视为已解释（✅），无则标记为问题（❌）
  - 示例 — ❌ 裸模糊词："系统支持**合理的**并发量限制"（无具体值）
  - 示例 — ✅ 已有补充："系统支持**合理的**并发量限制，默认上限 1000 QPS，超过后进入等待队列"（后文有具体值，不扣分）
- A2 状态与数据（A 型重点）：状态机完整性、字段定义
  - **A2-4 触发前置判定**：检查 A2-4（新增核心字段有字段定义）前，必须先判断是否属于「新增字段」：
    - ✅ 触发检查：文档明确提到「新增字段」「新增列」「新建字段」且该字段在现有系统中不存在、需定义业务含义
    - N/A 不触发：数据同步/传输（已有字段从 A 推送到 B）、数据展示优化、数据格式调整、快照/缓存数据——这些场景没有新增字段，不要求字段定义表
  - 判断依据：看数据流向。如果是「已有数据换个地方展示/同步」→ N/A；如果是「系统原来没有这个维度，现在要记录」→ 触发检查
- A3 影响范围（C 型重点，A 型按需）：影响评估、存量数据、C 型后续需求判断
  - **B 型影响范围特殊规则**：B 型优化中影响范围为**建议项，不扣分**。当检测到涉及跨模块/跨系统/存量数据时，在报告「补全建议」中提示「建议补充影响范围」，但不计入评分。B 型规范原文标注「若不涉及可删除」，说明影响范围非 B 型必填结构
- A4 竞品分析（A 型有参考时）：是否完成、有无差异化说明

**重要级（应当修复）：**
- B1 业务流程（A 型）：主流程、分支、异常、回滚
- B2 用户场景（A 型重点）：角色、典型场景
  - **B2-2 特殊规则**：典型使用场景（时间线描述）为**建议项，不扣分**。缺失时在报告「补全建议」中提醒，不计入评分。B2-1（角色列出）和 B2-3（核心路径覆盖）仍为必检项
- B3 功能描述质量：动词开头、主语明确、异常场景
- B4 跨系统集成（按需）
- B5 数据迁移（按需）
- B6 非功能需求（按需）

**建议级（建议改进）：**
- C1 文档规范：术语统一、标题格式、原型链接
- C2 跨境电商领域专项：多币种、多平台、时区

#### 4.2 评分计算

根据检查结果计算评分：

- 起始分 100，扣到 0 为止
- ❌ Fail：严重 -8 / 重要 -4 / 建议 -1
- ⚠️ Partial：严重 -4 / 重要 -2 / 建议 -0.5
- ✅ Pass 和 N/A：不扣分
- 总分四舍五入取整

**通过判定（同时满足两个条件才通过）：**
1. 质量红线：零违反
2. 分数：≥ 80 通过 / 60-79 有条件通过 / < 60 不通过

#### 4.3 逻辑校验

对所有文档类型执行以下逻辑校验（D 级）：

| 编号 | 校验维度 | 关注点 |
|------|----------|--------|
| D1-1 | 前后一致性 | 前置条件与后续规则是否自洽 |
| D1-2 | 字段依赖 | 同一字段在不同章节的定义是否一致 |
| D1-3 | 流程闭环 | 操作流程是否有未处理的出口（缺少驳回/撤回路径等） |
| D1-4 | 状态可达性 | 是否有不可达的孤立状态 |
| D1-5 | 数据引用 | 引用的字段/枚举值是否有对应定义 |
| D1-6 | 条件互斥 | 多个条件规则间是否有逻辑冲突 |
| D1-7 | 边界值 | 数值/列表/分页是否定义了上下界和空值处理 |

**逻辑校验原则：**
- **不确定不给建议** — 如果业务背景不足以判断逻辑是否合理，标注"待确认"并说明需要向谁确认（如"需与业务侧确认该规则是否成立"），不猜测不做假设
- **区分结构问题与逻辑问题** — "缺少状态机"是结构问题（归 严重），"状态机中状态 A 无法到达状态 B 但文档声称可以"是逻辑问题（归 D 级）
- **给出具体矛盾点** — 不说"逻辑可能有矛盾"，说"第 3 章写'提交后不可修改'，第 5.2 节写'支持提交后修改字段 X'"
- **"待确认"项给出行动指引** — 标注建议确认方（如开发负责人/业务侧/测试）和具体确认问题（如"提交后是否允许修改字段？如允许则修正第 3 章，如不允许则删除第 5 章该场景"），让 PM 知道找谁、问什么、问完怎么改

#### 4.4 必填项校验清单

根据识别的文档类型，列出该类型所有**必检项**的逐项校验结果。目的：让 PM 一眼看到结构完整性的达标情况。

**输出格式**：仅列出标注为"必检"的项目，按章节顺序排列，标注 ✅/❌/N/A。

**各类型必检项汇总：**

**B 型必检项：**
- A1-1 背景/现状说明
- A1-2 功能描述清晰无歧义
- A1-3 数值有具体值
- A1-4 无模糊词

**A 型必检项：**
- A1-1 背景/现状说明
- A1-2 功能描述清晰无歧义
- A1-3 数值有具体值
- A1-4 无模糊词
- A2-1 涉及状态流转已定义状态机
- A2-2 状态机包含完整字段
- A2-3 终态已标注
- A2-4 新增核心字段有字段定义
- A4-1 有参考时竞品分析已完成
- B1-1~B1-4 业务流程完整
- B2-1 目标用户/角色已列出
- B2-3 场景覆盖核心操作路径
- B3-1 功能描述动词开头
- B3-2 操作主语明确
- B3-3 异常场景已描述

**C 型必检项：**
- A1-1 背景/现状说明
- A1-2 功能描述清晰无歧义
- A1-3 数值有具体值
- A1-4 无模糊词
- A3-1 影响范围已评估
- A3-2 存量数据处理方式已说明
- A3-3 已判断是否有后续正式需求
- B3-4 触发条件/复现路径已写
- B3-5 来源已明确
- B3-6 目标上线时间是具体时间点

**严重/重要 项标注修复工作量：**

每个 ❌ Fail 的 严重 和 重要 项需标注预估修复工作量，帮助 PM 排序优先级：

| 工作量 | 标注 | 含义 |
|--------|------|------|
| 🟢 5分钟 | `轻量` | 替换词汇、补一句描述、删除冗余章节等 |
| 🟡 30分钟 | `中等` | 补写一段流程、完善字段定义表格、补充异常场景等 |
| 🔴 需协作 | `重度` | 需与开发/业务确认逻辑、需补充完整状态机、需跨团队对齐等 |

标注方式：在问题列表的修复建议列末尾追加 `[轻量]` / `[中等]` / `[重度]`。

#### 4.5 补全建议内容

对识别到的缺失项（❌ Fail），自动生成符合 v2.3 规范的补全文本，供 PM 直接复制使用。

**补全原则：**
- **仅补结构性内容** — 如缺少状态机时生成操作驱动型状态机表格模板、缺少字段定义时生成字段表格模板、缺少流程图时生成文字版流程描述
- **不补业务决策内容** — 具体的业务规则、字段取值范围、操作权限等业务判断不应由 AI 代写
- **标注插入位置** — 明确说明应插入到文档的哪个章节
- **使用占位符** — 业务相关内容用 `[待填写：具体值]` 标注，提醒 PM 补充

**补全建议增加工作量预估：**

在每条补全建议前标注预估工作量，并在补全区域开头给出总工作量汇总：

- `可直接复制` — 纯模板，无需填写业务内容（如已有的状态表格框架、章节标题结构）
- `需填写业务内容` — 模板中有占位符需 PM 补充（如字段定义的具体值、流程的具体步骤）
- `需协作确认` — 涉及业务判断或跨团队确认，需额外沟通（如数据迁移的回滚方案）

输出格式示例：
```
补全汇总：共 X 处，预计 Y 分钟（可直接复制 Z 处 / 需填写业务内容 N 处 / 需协作确认 M 处）
```

**可自动补全的内容示例：**

| 缺失项 | 补全内容 |
|--------|----------|
| 状态机 | 操作驱动型状态机表格（当前状态/执行操作/流转后状态/角色限制/说明），填入已知状态，未知用占位符 |
| 字段定义 | 字段定义表格（字段名/业务含义/数据类型/取值范围/数据来源/更新时机），已知字段填入 |
| 流程描述 | 基于功能描述推导的主流程文字版（步骤 1→2→3...），标注"需与业务确认"的部分 |
| 影响范围 | 影响范围四维检查清单模板（涉及模块/存量数据/数据迁移/其他影响），逐项留空供填写 |
| 异常场景 | 常见异常场景检查表（网络超时/权限不足/数据冲突/并发操作等），适配具体功能的模板 |

### Step 6: 生成审核报告

#### 报告分级输出规则

根据得分和红线状态调整报告**详略程度**（非删减区块）。核心评估信息（N/A 说明、逻辑校验、补全建议、亮点分析、总体建议）在任何级别均保留。

| 级别 | 条件 | 详略策略 | 适用场景 |
|------|------|----------|----------|
| **精简报告** | ≥90 分 且 零红线违反 | 评分明细合并进问题列表（不单独成章）；审核结论简化为一句话；二审对比仅展示修复率+分数变化 | 文档质量好，重点在确认 1-2 个遗留问题 |
| **标准报告** | 60-89 分 且 零红线违反 | 评分明细独立成章；审核结论含放行策略和分档建议 | 有问题但不严重，PO 需做评审决策 |
| **完整报告** | <60 分 或 有红线违反 | 所有区块完整输出，审核结论含打回理由；逻辑校验逐项展开；补全建议含完整模板 | 文档需大修，PO 需全面评估风险 |

**所有级别均保留的区块**：文档信息、30秒速览、必填项（含 N/A 说明）、问题列表（含评分）、修改指引、修复清单、逻辑校验、补全建议、亮点分析、总体建议。

**精简报告的变化不是删区块，而是**：
- 评分明细**并入**问题列表表格中（加一列「扣分」），不另起「评分详情」章节
- N/A 说明不压缩，每条 N/A 都注明具体原因（如「无状态流转，非审批流程」）
- 补全建议、逻辑校验、亮点分析、总体建议缩减到必要维度但仍独立成章

> **设计原则**：精简的是「重复信息」（如评分明细独立成章再和问题列表重复），而非「评估信息」（如 N/A 原因、逻辑待确认项、结构缺失模板）。评估信息是 PO 和 PM 决策的依据，不能减。

#### 输出格式（完整版模板，实际按分级规则裁剪）：

```markdown
# PRD 内审报告

## 文档信息
- 文档标题：
- 文档类型：☐ B 型  ☐ A 型  ☐ C 型
- 所属系统：ERP / SCM / WMS / LPS
- 审核日期：
- 审核依据：PRD 文档标准规范 v2.4

> [类型分歧提示（仅存在分歧时显示）：本文档中第 X 节被识别为疑似 A 型需求（理由：...），已与用户确认为 B 型需求，按 B 型标准审核该节。]

---

## 〇、30 秒速览

> 一句话结论：[ ✅ 通过 / ⚠️ 有条件通过（XX 分）/ ❌ 不通过 ]

**得分：XX 分** | **严重 X 项** | **重要 X 项** | **建议 X 项** | **逻辑问题 X 项**

**[低置信度提示（如有）：⚠️ 有 X 项低置信度问题，建议人工复核（编号列表）]**

**必须修复（按优先级）：**
1. [编号] 一句话描述 — 第X章 — [轻量/中等/重度]
2. [编号] 一句话描述 — 第X章 — [轻量/中等/重度]
3. ...

**放行建议：**
- 🚫 开发前必修：X 项 [列出编号]
- ⚠️ 提测前补齐：Y 项 [列出编号]
- ✅ 可后补：Z 项 [列出编号]

**补全工作：共 X 处，预计 Y 分钟**

**[质量红线违反提示（如有）：❌ 红线项名称 — 说明]**

---

## 二审对比（仅二审模式显示）

> 本次为二审，对比上次审核报告，检查修复情况。

**上次得分：XX 分 → 本次得分：XX 分（+X / -X）** | **修复率：X%（已修复 X / 总问题 X）**

> 修复率 = 已修复 / (已修复 + 部分修复 + 未修复 + 变更较大) × 100%

**修复明细：✅ 已修复 X 项 | ⚠️ 部分修复 X 项 | ❌ 未修复 X 项 | 🔄 变更较大 X 项**

| 编号 | 级别 | 上次问题描述 | 修复状态 | 本次情况说明 |
|------|------|-------------|----------|-------------|
| A1-1 | 严重 | 缺少背景说明 | ✅ 已修复 | 第1章已补充背景与目标 |
| A2-1 | 严重 | 状态机缺少终态标注 | ⚠️ 部分修复 | 已增加"已关闭"终态，但"已取消"状态仍缺少 |
| B3-1 | 重要 | 功能描述未动词开头 | ❌ 未修复 | 第5.2节仍有 3 处名词短语开头 |
| B1-3 | 重要 | 异常处理方案缺失 | 🔄 变更较大 | 已补充异常方案但改为"返回错误码"，需确认是否覆盖所有异常类型 |

**二审结论：** [如：修复率 50%，分数提升 15 分。剩余 2 项建议在本周内补齐后可进入开发 / 修复率 80%，文档质量明显提升，建议放行]

---

## 审核范围

> 说明本报告覆盖的审核区域，避免争议。

| 区域 | 状态 | 说明 |
|------|------|------|
| 第 1 章 背景与目标 | ✅ 已审核 | |
| 第 2 章 用户场景 | ✅ 已审核 | |
| 第 3 章 竞品分析 | ✅ 已审核 / N/A 无此章节 | |
| 第 4 章 业务流程 | ✅ 已审核 | |
| 第 5 章 功能描述 | ✅ 已审核 | |
| 第 6 章 权限 | ✅ 已审核 | |
| 第 7 章 其他模块 | ✅ 已审核 / N/A 无此章节 | |
| 附录/参考文档 | ⏭ 跳过 | 非 PRD 正文，不计入审核 |

**说明**：文档共 X 章，已审核 Y 章，跳过 Z 章（非正文内容）。

---

## 一、必填项校验清单

> 按文档类型列出所有必检项的结构完整性检查结果。

| 序号 | 编号 | 必填项 | 结果 |
|------|------|--------|------|
| 1 | A1-1 | 背景/现状说明 | ✅ |
| 2 | A1-2 | 功能描述清晰无歧义 | ✅ |
| ... | ... | ... | ... |

**必填项通过率：X / Y（Z%）**

---

## 二、评分详情

### 扣分明细

| 编号 | 级别 | 检查项 | 结果 | 扣分 | 原文 | 问题说明 | 置信度 |
|------|------|--------|------|------|------|----------|--------|
| A1-2 | 严重 | 功能描述清晰无歧义 | ⚠️ | -4 | > 支持多币种结算 | 第3章未明确具体币种 | 高 |
| B3-1 | 重要 | 功能描述动词开头 | ❌ | -4 | > 汇率的查看和导出 | 第5.2节使用名词短语 | 高 |
| C1-1 | 建议 | 术语全文统一 | ⚠️ | -0.5 | > 运费明细...物流费合计 | "运费"和"物流费"混用 | 高 |

### 同类问题聚合

> 将分布在多个章节的同类型问题合并展示，方便批量修改。

| 检查项 | 出现次数 | 涉及位置 | 扣分合计 |
|--------|----------|----------|----------|
| A1-4 模糊词 | 3 处 | 第2章"适当"、第3章"合理"、第5章"尽量" | -24 |
| ... | ... | ... | ... |

### 分数汇总

| 项目 | 分值 |
|------|------|
| 起始分 | 100 |
| 严重 扣分 | -X（N Fail + M Partial） |
| 重要 扣分 | -X（N Fail + M Partial） |
| 建议 扣分 | -X（N Fail + M Partial） |
| **最终得分** | **XX 分** |

### 质量红线检查

> 红线按文档类型不同：B 型不包含影响范围，A 型不包含影响范围，C 型包含影响范围。

| 红线项 | 结果 |
|--------|------|
| 不缺少背景/现状说明 | ✅ / ❌ |
| 功能描述清晰无歧义 | ✅ / ❌ |
| ... | ... |

---

## 三、审核结论

**[ ✅ 通过 / ⚠️ 有条件通过（XX 分）/ ❌ 不通过 ]**

[具体理由，1-2 句话说明。]

### 放行策略

将所有问题按阻塞程度分为三档，帮助审核人判断哪些修完即可放行：

| 档位 | 含义 | 分类规则 |
|------|------|----------|
| 🚫 开发前必修 | 直接阻塞开发启动 | 所有 严重 ❌ Fail 项 + 质量红线违反项 |
| ⚠️ 提测前补齐 | 不阻塞开发，但阻塞测试 | 严重 ⚠️ Partial 项 + 重要 ❌ Fail 项中影响测试用例的部分（如异常场景缺失、字段定义不清） |
| ✅ 可后补 | 不阻塞当前迭代 | 重要 ⚠️ Partial 项 + 所有 建议 项 + 重要 中不影响核心逻辑的部分 |

**放行建议：**

| 档位 | 项数 | 编号 |
|------|------|------|
| 🚫 开发前必修 | X | A1-1, A2-1, ... |
| ⚠️ 提测前补齐 | Y | B1-3, B3-1, ... |
| ✅ 可后补 | Z | C1-1, B2-2, ... |

**结论：** [如：修复 A1-1 和 A2-1 后即可进入开发，其余可在开发期间补齐 / 该文档不通过，需全面修订后重新提交]

---

## 四、问题列表（按严重程度）

### 严重级（必须修复）
| 编号 | 检查项 | 原文 | 问题描述 | 位置 | 修复建议 | 关联影响 | 工作量 |
|------|--------|------|----------|------|----------|----------|--------|
| A1-1 | ... | > 原文片段 | ... | 第X章 | ... | 需同步检查第X.X节 | 🟢 轻量 |
| A2-1 | ... | > 原文片段 | ... | 第X章 | ... | 需同步检查第X.X、X.X节 | 🔴 重度 |

### 重要级（应当修复）
[同上格式，关联影响列可选，仅跨章节联动时填写]

### 建议级（建议改进）
[同上格式，建议级不标注工作量和关联影响，原文列可选]

---

## 五、修改指引（按章节分组）

> 按文档章节汇总所有问题，打开对应章节一次性修完。

### 第 1 章 背景（X 个问题）
| 编号 | 级别 | 原文 | 问题 | 修复建议 |
|------|------|------|------|----------|
| A1-4 | 严重 | > 系统会对前若干条数据进行... | 使用"若干"未量化 | 改为具体数值，如"前 100 条" |
| ... | ... | ... | ... | ... |

### 第 3 章 业务流程（X 个问题）
| 编号 | 级别 | 原文 | 问题 | 修复建议 |
|------|------|------|------|----------|
| B1-3 | 重要 | > （此处无原文，结构缺失） | 缺少异常处理方案 | 补充 API 超时和并发冲突的处理方案 |
| ... | ... | ... | ... | ... |

### 第 5 章 功能描述（X 个问题）
[同上格式]

---

## 六、逻辑校验

| 编号 | 校验维度 | 校验结果 | 说明 | 行动指引 |
|------|----------|----------|------|----------|
| D1-1 | 前后一致性 | ⚠️ 待确认 | 第3章"提交后不可修改"与第5.2节"支持提交后修改字段X"可能矛盾 | → 确认方：开发负责人。确认问题：提交后是否允许修改？如允许则修正第3章，如不允许则删除第5章该场景 |
| D1-3 | 流程闭环 | ❌ 有遗漏 | 第4章"审核通过"路径完整，但缺少"审核驳回"后的数据归置说明 | → 直接补充第4章：驳回后数据回退到待提交状态，已填写的表单数据保留 7 天 |
| ... | ... | ✅ / ⚠️ 待确认 / ❌ | ... | ... |

---

## 七、补全建议内容

> 以下内容可直接复制到 PRD 文档中使用，占位符 `[待填写：...]` 需替换为实际内容。
>
> **补全汇总：共 X 处，预计 Y 分钟（可直接复制 Z 处 / 需填写业务内容 N 处 / 需协作确认 M 处）**

### 补全项 1：状态机（插入位置：第 4.2 节）| 需填写业务内容 | 约 15 分钟

```markdown
| 当前状态 | 执行操作 | 流转后状态 | 角色限制 | 说明 |
|----------|----------|------------|----------|------|
| [待填写] | [待填写] | [待填写] | [待填写] | [待填写] |
```

### 补全项 2：字段定义（插入位置：第 4.3 节）| 需填写业务内容 | 约 10 分钟

```markdown
| 字段名 | 业务含义 | 数据类型 | 取值范围 | 数据来源 | 更新时机 |
|--------|----------|----------|----------|----------|----------|
| [待填写] | [待填写] | [待填写] | [待填写] | [待填写] | [待填写] |
```

---

## 八、亮点分析

> 识别文档中值得推广的优秀实践，帮助团队沉淀方法论。

### 亮点 1：[一句话标题]

**位置**：第 X 章
**好在哪里**：[具体说明该做法为什么好，解决了什么问题]
**适用场景**：[该做法适用于什么类型的 PRD / 什么业务场景]
**推广建议**：☑ 建议作为团队最佳实践 / ☐ 可作为参考 / ☐ 仅本次文档适用

### 亮点 2：[一句话标题]

[同上格式]

[如果没有值得推广的亮点，写"本文档未发现突出亮点"即可，不强行凑数]

---

## 九、总体建议

[综合改进方向，最多 3 条，按优先级排列]

---

## 十、修复清单

> 按编号逐项检查，修完一个勾一个。☐ = 未修复，☑ = 已修复。

| 状态 | 编号 | 级别 | 问题 | 章节 | 工作量 |
|------|------|------|------|------|--------|
| ☐ | A1-1 | 严重 | 缺少背景说明 | 第1章 | 🟡 中等 |
| ☐ | A1-4 | 严重 | "适当"未量化 | 第2章 | 🟢 轻量 |
| ☐ | B1-3 | 重要 | 缺少异常处理 | 第4章 | 🟡 中等 |
| ☐ | C1-1 | 建议 | 术语不统一 | 全文 | 🟢 轻量 |
```

### Step 7: 可选 — 回写飞书

如果需要将审核报告写回飞书文档，调用已定义的 `write_to_feishu(markdown_content, file_name)` 函数即可。

**飞书 Markdown 兼容性规则（回写时自动处理）：**

飞书 Markdown 渲染与标准 Markdown 有差异，写回飞书时需做以下转换：

| 标准语法 | 飞书兼容 | 说明 |
|----------|----------|------|
| `> 引用块` | ✅ 支持 | 单行引用正常；嵌套引用不保证样式 |
| `\| 表格 \|` | ✅ 支持 | 列宽不可控，长文本自动截断。列数建议 ≤ 6 |
| `` ```代码块``` `` | ⚠️ 有限 | 需指定语言（如 `` ```markdown ``），不指定可能无语法高亮 |
| `# ~###### 标题` | ✅ 支持 | 最多支持 H3 层级（###），H4 以下不渲染为标题样式 |
| `- 无序列表` | ✅ 支持 | 嵌套不超过 3 层，4 层以上可能样式异常 |
| `1. 有序列表` | ✅ 支持 | 同上 |
| `**加粗**` / `*斜体*` | ✅ 支持 | |
| `~~删除线~~` | ⚠️ 不支持 | 改为 `~~` 文本前加 `（已删除）` 标注 |
| `<details><summary>` | ❌ 不支持 | 不使用 HTML 折叠，改为标题 + 说明文案 |
| `[链接](url)` | ✅ 支持 | |
| 表格内 `>` 引用 | ⚠️ 异常 | 原文列改为加粗引用前加 `「` 后加 `」`，如 **「原文片段」** |

**回写时的格式调整策略**：
1. 报告标题保持 H1（`#`），章节标题用 H2（`##`），子节用 H3（`###`），避免 H4+
2. 表格列数 ≤ 6，超宽内容拆分到下一行或缩写
3. 原文列（`>` 引用格式）改为 `「原文」` 加粗格式
4. 删除线改为文字标注
5. 代码块统一使用 `markdown` 语言标记
6. 补全建议中的代码块（状态机/字段模板）使用 `markdown` 语言标记，确保表格在飞书中正确渲染

**注意事项：**
- Markdown 导入大小限制 20MB
- 导入后生成的文档需要手动授权给相关人员查看

### Step 8: 审核记录留存

每次审核完成后，将审核结果以 JSON 格式保存到 `{workspace}/.workbuddy/audit-history/` 目录，便于后续追踪 PM 质量趋势和文档迭代质量。

**文件命名**：`{文档标题简称}_{审核日期}.json`（如 `其他费用模块_2026-05-20.json`）

**JSON 结构**：

```json
{
  "meta": {
    "doc_title": "文档标题",
    "doc_type": "A/B/C",
    "system": "ERP/SCM/WMS/LPS",
    "review_date": "2026-05-20",
    "review_version": "v2.4",
    "is_re_review": false
  },
  "score": {
    "total": 82,
    "critical_fail": 1,
    "critical_partial": 0,
    "major_fail": 2,
    "major_partial": 1,
    "minor_fail": 3,
    "minor_partial": 0
  },
  "mandatory": {
    "total": 10,
    "pass": 8,
    "rate": "80%"
  },
  "quality_redline": {
    "violated": false,
    "items": []
  },
  "issues_summary": [
    {
      "id": "A1-1",
      "level": "严重",
      "result": "Fail",
      "deduction": 8,
      "chapter": "第1章",
      "confidence": "高",
      "summary": "缺少背景说明"
    }
  ],
  "highlights": [
    {
      "location": "第5章",
      "title": "异常场景覆盖全面",
      "recommendation": "团队最佳实践"
    }
  ],
  "release_strategy": {
    "before_dev": ["A1-1"],
    "before_test": ["B1-3", "B3-1"],
    "later": ["C1-1", "C1-2"]
  }
}
```

**用途说明**（供后续扩展，当前仅留存）：
- 按 PM 统计平均分和趋势，识别需要重点辅导的 PM
- 按文档类型统计常见问题分布，优化检查清单权重
- 对比同一文档多次审核的分值变化，评估迭代质量

## 审核原则

1. **引用原文** — 每个问题必须附上原文片段（使用 `> 引用格式`），审核人无需切换文件即可验证问题是否真实存在。原文过长时引用关键句，不超 3 行
2. **具体不笼统** — 不说"需补充细节"，说"第 3 章缺少异常处理场景：当 API 调用超时时系统的行为未定义"
3. **引用位置** — 每个问题标注对应章节位置
4. **给修复建议** — 不只说问题，给出具体的改法
5. **尊重约束** — C 型文档篇幅本身就短，不要按 A 型标准要求
6. **领域专业** — 充分利用跨境电商领域知识识别业务逻辑漏洞
7. **正面反馈** — 好的地方也要指出来，不只是挑错
8. **评分客观** — 每个扣分项必须有明确理由，不因主观感受扣分
9. **逻辑审慎** — 不确定的问题标注"待确认"并说明需向谁确认，不做猜测不做假设
10. **补全有边界** — 只补结构性模板，不代写业务决策内容
11. **PM 效率优先** — 同类问题聚合展示减少翻找、按章节分组方便批量修改、标注修复工作量帮助排优先级、补全内容可直接复制减少重复劳动
12. **模糊词需上下文判定** — 检查模糊词时，同一句或相邻两句（下文 2 句内）若已有具体数值、限定范围、操作条件等量化说明，则视为已解释，不标记为问题。只对"裸模糊词"（无任何量化补充）扣分
13. **标注关联影响** — 严重 和 重要 的修复可能引发其他章节的联动修改，必须在修复建议末尾标注"关联影响：需同步检查第 X.X 节"。例如"补充状态机"后，功能描述中引用状态流转的部分可能需要同步调整
14. **标注置信度** — 每个问题标注判断置信度：
  - **高** — 原文明确缺失或明显违规，无需业务背景即可确认
  - **中** — 基于规范判断，需结合上下文理解，但大概率准确
  - **低** — 涉及业务逻辑合理性判断，需人工复核确认
  - 低置信度项须在问题说明末尾标注"⚠️ 建议人工复核"，帮助审核人聚焦精力
15. **类型分歧先确认** — 当检测到子节内容特征与文档主类型不一致时（如 B 型聚合文档中某节含完整状态机），暂停审核先请用户确认该节的实际类型归属。用户确认为当前类型后，仅按当前类型标准审核，不混用其他类型的检查项

## Key Design Decisions (v2.4)

以下决策影响审核判断标准，必须严格遵守：

| 编号 | 决策 | 审核含义 |
|------|------|----------|
| D-1 | 不单独写验收标准（AC） | **不要**检查 AC 章节，不要建议"应补充验收标准" |
| D-2 | 功能清单是条件子模块（A 型） | 功能点 ≤5 个时不要求有功能清单 |
| D-3 | 竞品分析无参考可删除 | 没有参考对象时，该章节应删除而非留空 |
| D-4 | C 型极简但保留影响范围 | C 型不要求竞品分析、状态机，但影响范围必须评估 |
| D-5 | B 型支持聚合 | 多个优化点可合并文档，不影响质量 |
| D-6 | 写作规范内嵌模板 | 检查写作规范（动词开头、主语明确、可量化） |
| D-7 | B 型影响范围不扣分 | B 型优化影响范围为建议项，检测到风险时提示但不扣分（规范原文「若不涉及可删除」） |
| D-8 | 类型分歧先确认再审核 | 检测到子节类型与文档主类型不一致时，暂停审核请用户确认，避免误报 |
| D-9 | B2-2 典型使用场景不扣分 | A 型用户场景中「典型使用场景」为建议项，缺失时在补全建议中提醒，不计入评分 |

## References

- `references/checklist.md` — v2.3 分型检查清单（严重 / 重要 / 建议 / 逻辑校验）+ 评分规则 + 质量红线
- `references/spec.md` — v2.3 规范结构要求和写作规范
- `references/domain-knowledge.md` — 跨境电商 SaaS 领域知识库