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 代码读取飞书文档内容：

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='\
'.join(msgs).encode() + b'\
', timeout=timeout)
    for line in reversed(out.decode().strip().split('\
')):
        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）

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

判断优先级：有"触发条件"+"来源"+"目标上线时间"且篇幅短 → 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 有条件通过 / \x3C 60 不通过

4.3 逻辑校验

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

逻辑校验原则：

• 不确定不给建议 — 如果业务背景不足以判断逻辑是否合理，标注"待确认"并说明需要向谁确认（如"需与业务侧确认该规则是否成立"），不猜测不做假设
• 区分结构问题与逻辑问题 — "缺少状态机"是结构问题（归 严重），"状态机中状态 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 排序优先级：

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

4.5 补全建议内容

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

补全原则：

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

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

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

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

输出格式示例：

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

可自动补全的内容示例：

Step 6: 生成审核报告

报告分级输出规则

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

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

精简报告的变化不是删区块，而是：

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

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

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

# 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 分钟

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

八、亮点分析

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

亮点 1：[一句话标题]

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

亮点 2：[一句话标题]

[同上格式]

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

九、总体建议

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

十、修复清单

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

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

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

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

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

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

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

References

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