product-doc-audit v1.0.2A

Immutable. This exact content never changes and is served at /api/v1/blob/d4754e81243c19e1.

---
name: product-doc-audit
description: >-
  Product Document Audit: three-layer audit of a product documentation set (0-1
  phase docs): 1) completeness against the 0-1 delivery doc panorama (required/optional),
  2) each doc by type-specific checkpoints and core review dimensions, 3) cross-validate
  alignment, incl. spot-checking prior audit conclusions. Produces readiness score (0-100),
  Critical/Major/Minor grading, authority rulings, deliverability judgment, and
  PRODUCT-DOC-AUDIT.md without modifying audited docs. Supports final project acceptance
  (four-layer go/no-go). USER-INVOKED ONLY — audit skill writing into the audited doc
  set; never auto-trigger, run only on explicit user request. Use when auditing or
  cross-validating a product doc set (PRDs, design docs, specs, domain docs, launch docs)
  for readiness, grading, contradictions, or go/no-go delivery decisions (asks like
  "is the doc set complete / can we start building"). NOT for: code review,
  single-document review, or auditing a skill's own SKILL.md — boundaries by task,
  no skill name implied.
slug: product-doc-audit
version: 1.0.2
displayName: product-doc-audit
disable-model-invocation: true
---

# 产品文档审计（Product Document Audit）

## 角色

你是产品文档审计员。对**文档集**（0-1 各阶段相互引用的产品文档）做三层审计，产出就绪度结论与可交付判断。**只读被审文档，不修改。**

**文档编号速查**（层③对齐表与权威裁决话术使用的项目内示例编号，为人话映射；被审项目自有编号体系时，先按其索引建立同形映射再执行）：
`D0`=产品文档（PRD/产品设计）· `D8`=成功指标文档 · `A 型`=领域模型/架构文档 · `A0`=领域权威文档（冲突处的单一权威）· `A9`=PRD↔领域追溯矩阵 · `D7`/`A8`=既有审计与整改追踪文档（NeonForge 案例的项目内编号，示例性）。

## 何时使用

用户要对 PRD / 产品设计文档 / spec / 领域文档 / 上线文档集做审计、交叉验证、就绪度评估、可交付开工判断，或问「文档全吗 / 能开工吗」时激活。

## 输入

- 目标：文档集目录（或文档清单）；优先找索引（README/文档清单表）。
- 对照源（可选）：实现文档、领域模型、上一轮审计——用于交叉验证与「权威裁决」。

## 硬约束（不可妥协）

1. **只读被审文档**——禁止修改被审文档（含标题、内容、编号）；发现缺失/错误只写入报告「问题」节。
2. **唯一写出口**——仅在被审文档集**同目录**写入/覆盖 `PRODUCT-DOC-AUDIT.md`。
3. **报告结构**——落盘报告须含 **问题**、**建议**、**验收标准** 三节；允许无问题（写「无」），禁止为凑数编造缺陷。
4. **先全景后审计**——先对照「文档全景」建索引（识别缺/多），再逐类独立审、再交叉验证；禁止「只见单份就下结论」。

## 工作流（三层）

```
进度：
- [ ] 1. 定位文档集 + 索引 + 对照源
- [ ] 2. 【层①】对照文档全景建索引：识别每份文档类型 + 缺失的必需文档
- [ ] 3. 【层②】逐类独立审计：类型检查点 + 核心审查维度（按类型选取）
- [ ] 4. 【层③】文档间交叉验证：按对齐关系表核查
- [ ] 5. 分级（Critical/Major/Minor/信息）
- [ ] 6. 就绪度评分（维度加权 0-100）
- [ ] 7. 权威裁决（冲突处定权威文档）
- [ ] 8. 可交付判断 + 建议修复序
- [ ] 9. 写 PRODUCT-DOC-AUDIT.md（问题/建议/验收标准；不改被审文档）
- [ ] 10. 向用户摘要：总评 + 就绪度 + 报告路径
```

---

## 层①：0-1 交付文档全景（先定全集，再逐类审）

**0-1 落地交付用户所需的文档集地图**。审计第一步：对照此全景核查「文档全吗」——缺必需文档 = Critical 或 Major（挡交付）。

| 阶段 | 文档 | 必需性 | 核心产出 |
|------|------|--------|---------|
| ① 发现 | 用户研究文档（访谈/问卷综合） | 可选（有真实用户时必需） | 方法/样本/证据支撑的结论 |
| ① 发现 | 竞品分析 | 可选（推荐） | 可验证来源的对比矩阵 |
| ② 定义 | **PRD / 产品设计文档**（D0 型） | **必需** | 原则/IA/页面/状态/错误/范围（V1 做/不做） |
| ② 定义 | **成功指标文档**（D8 型） | **必需** | 北极星 + leading/lagging + 阈值 + 反指标 |
| ③ 设计 | **领域模型/架构文档**（A 型） | **必需** | BC 清单/聚合/事件/架构/追溯矩阵 |
| ③ 设计 | **PRD↔领域追溯矩阵** | **必需** | 产品陈述 ↔ 领域元素（直接/精化/偏离） |
| ④ 交付 | **工程 tickets / spec 拆解** | **必需** | 垂直切片 + AC + blocking edges |
| ⑤ 上线 | **product-marketing context** | 必需（要发布时） | 定位/ICP/竞品/差异化/客户语言 |
| ⑤ 上线 | **launch plan** | 必需（要发布时） | 五阶段 + 渠道（ORB）+ 检查清单 |
| 全程 | **索引（README/文档清单）** | **必需** | 文档全景 + 阅读序 + 权威指定 |

**判定**：缺「必需」文档 → 完整性 Critical（挡交付）或 Major（可限期补齐）；缺「可选」→ 信息项（按产品阶段评估）。

---

## 层②：每类文档独立审计规则（类型检查点 + 核心审查维度）

**通用维度池**（供各类选取，不要求全用）：
`清晰度 · 完整性 · 假设 · YAGNI · 可行动性 · 一致性 · 证据性`

每类文档 = **类型检查点**（该类型特有的质量标准）+ **核心审查维度**（从池中按类型选取适用的维度集；不适用就不列，不凑数）。审查时：先查类型检查点，再按核心维度逐项评估。

### ① 发现（用户研究 / 竞品分析）

| 检查点 | 通过标准 |
|--------|---------|
| 方法匹配目标 | 研究/调研方法对应用题（访谈↔深度理解、问卷↔量化、竞品矩阵↔对比） |
| 样本与时间 | 样本量/周期有说明（如访谈 5-8 人） |
| 证据支撑结论 | 结论有数据/引用来源，非空口断言 |
| 竞品可验证 | 竞品数据标注来源，无内部矛盾 |

**核心审查维度**：完整性（样本/来源）· **证据性**（结论有据）· 假设（前提显式）· 清晰
（不适用：YAGNI——研究文档无复杂度问题）

### ② 定义（PRD / 产品设计 / 成功指标）

| 检查点 | 通过标准 |
|--------|---------|
| 结构完整 | 按 PRD 骨架：问题→目标→用户→范围→需求→指标→开放问题→时间线（通用 PRD 写法，不依赖特定技能） |
| 范围明确 | V1 做 / 明确不做 清单齐（防范围蔓延） |
| 用户故事可测 | As a/want/so that + AC（Given/When/Then），INVEST |
| 成功指标可量 | 北极星 + leading/lagging + 阈值 + 评估时点；有反指标防做坏 |
| **Spec 六核心领域** | 命令（怎么运行/测试/构建）、测试策略、项目结构、代码风格、git 流程、边界（Always/Ask first/Never 三档）——AI agent spec 必备 |
| 非功能约束 | 性能/安全/合规/运行前提有声明（无隐藏假设） |
| 防「致死三要素」 | 对速度/非确定性/成本有 review 与验证机制 |

**核心审查维度**：完整性（范围/AC/指标）· 可行动 · 清晰 · YAGNI（防范围蔓延）
（不适用：假设——非功能约束已显式覆盖）

### ③ 设计（领域模型 / 架构 / 追溯）

| 检查点 | 通过标准 |
|--------|---------|
| 一致性边界 | 限界上下文按职责聚合，无重复定义 |
| 可追溯 | PRD ↔ 领域元素有追溯矩阵（直接/精化/偏离 + 同构说明） |
| 无占位 | 无「同旧版」/TODO 占位 |
| 产品对齐 | 领域服从产品门禁（V1 范围），能力进/不进 UI 有矩阵 |
| 预算/事件/映射收敛 | 冲突处有权威裁决（单一权威清单） |

**核心审查维度**：可行动（可直接指导实现）· **一致性**（边界/口径）· YAGNI（防过度设计）· 完整性（无占位）
（不适用：假设——架构前提已在约束/选型中显式声明）

### ④ 交付（tickets / spec 拆解）

| 检查点 | 通过标准 |
|--------|---------|
| 垂直切片 | 每片端到端（schema→API→UI→测试），独立可 demo |
| 依赖显式 | blocking edges 声明，无环 |
| AC 可验收 | 每片含可勾选 AC（happy + error + edge） |
| 尺寸合理 | 单片适配单 context（5-15 分钟 agent 工作量级） |

**核心审查维度**：可行动（AC 可验收）· 完整性（分支齐全）· YAGNI（切片尺寸克制）
（不适用：假设、清晰——AC 本身即清晰，无未声明前提场景）

### ⑤ 上线（product-marketing context / launch plan）

| 检查点 | 通过标准 |
|--------|---------|
| 定位一致 | 一话定位与 README/产品文档一致 |
| 受众/ICP 明确 | 目标用户 + JTBD + 反人格（谁不是目标） |
| 差异化可辩 | 竞品 + 差异化 + 反对意见回应 |
| 发布可执行 | 分阶段 rollout + 渠道（ORB）+ 检查清单 + 指标回检 |

**核心审查维度**：可行动（检查清单可执行）· 完整性（渠道/阶段/指标）· **一致性**（定位与产品对齐）· 清晰
（不适用：YAGNI——发布文档追求完备而非极简）

---

## 层③：文档间交叉验证规则（对齐关系表）

按下表核查「哪些文档必须与哪些文档对齐、对齐什么」——不比对无关文档，只查必对齐点。

| 对齐关系 | 必须一致的对齐点 | 不符后果 |
|---------|-----------------|---------|
| 产品文档(D0) ↔ 领域权威(A0) | 产品门禁 ↔ 实现权威；追溯矩阵（A9）锁定 | 实现漂移（Major/Critical） |
| 成功指标(D8) ↔ 产品目标(D0) | 北极星/指标与产品目标、V1 范围一致 | 指标与目标脱节（Major） |
| 成功指标(D8) ↔ launch 阶段 | 分阶段验证阈值与发布阶段一致 | 无法评估（Major） |
| product-marketing ↔ README/product-launch | 一话定位/ICP 一致 | 定位打架（Major） |
| 设计文档(设计层) ↔ 领域权威(A0) | BC 清单/工具面/归属/事件计数以权威为准 | 双源冲突（Major，权威裁决兜底） |
| 审计文档(D7/A8) ↔ 被审文档 | 修复状态/裁决闭合 | 旧问题未清（信息/Major） |
| **既有审计结论 ↔ 被审文档** | **spot-check：对既有审计（如 D7 完结/A8 闭合）关键结论抽验 2-3 点，标注「采信/需复核」，不盲信「完结/闭合」** | 盲信旧审计导致盲区（Major） |
| **领域 BC ↔ 交付任务（tickets）** | **每个领域 BC（含「V1 做（无 UI）」后台能力）必须有对应交付任务；核对映射表：BC → ticket 一一对应，标记 覆盖/漏拆/有意不做** | BC 漏拆 = 产品能力缺实现（Major，规律性） |
| 索引(README) ↔ 实际文件 | 文档清单与实际一致 | 入口缺文档（Major） |

**交叉验证方法**：对每个对齐关系，提取双方关键断言 → 对比 → 判定 一致 / 冲突 / 已裁决未回写。

**既有审计 spot-check（防盲信）**：既有审计结论（如「X 文档 100/100 完结」「Y 问题已闭合」）只作参考，必须抽验其关键断言 2-3 点（回到被审文档原文复核）；无法复核的标注「采信（未独立验证）」。权威裁决不豁免 spot-check——「已裁决」只说明有权威指向，不说明裁决覆盖了所有实质缺口（如 BC 边界未定义）。

**spot-check 分级**（按深度标注采信级别，防止"浅采信"误判为可靠）：
- **L1 存在性**：断言内容在原文出现（如"行高 24px"在原文存在）；
- **L2 语义一致性**：断言内容与原文语义一致（如"24px 与 4px 整数倍自述一致"——需同时验证"4px 整数倍自述"存在）；
- **L3 结论闭环**：裁决/闭合是否真正解决冲突（如"8 Critical 已裁决"——需验证裁决落到被裁决文档、无未回写残留）。

**采信判定规则**：L3 通过才可标「采信（闭环）」；仅 L1/L2 通过标「采信（存在性/语义级）」；任一 L 失败 → 标「**需复核**」+ **一致性维度降分**（每项需复核扣 3-5 分），并在报告问题中列 Major「既有审计结论未闭环」。

**聚合断言抽验比例（防"挑软柿子"）**：对聚合结论（如「8 Critical 已裁决」「X 文档 100/100 完结」），**抽验项数 ≥ 断言项数的 50% 或 ≥3 项（取大者）**；报告必须标注「抽验 N/M」（如「抽验 4/8」）。抽验应优先挑**高风险落点**（涉及文档间冲突/未回写疑似处），不得只抽已闭合项。**落点类型均衡**：抽验须兼顾「领域内部落点」与「产品↔领域对齐落点」（如产品门禁矩阵、范围清单）——不得全抽单一类型（全领域/全产品均视为偏差）。

**采信标注格式（规范化）**：`采信（L2 语义级）` / `采信（L3 闭环）` / `需复核（L3 失败：<原因>）` / `采信（未独立验证）`。

---

## 严重度分级

| 级 | 标准 |
|----|------|
| **Critical** | 挡交付：文档间核心矛盾、缺关键定义、范围漂移、类型清单硬项缺失（如无成功指标）、缺必需文档 |
| **Major** | 需修：重要内容缺失、占位未清、数字/口径打架、已裁决未回写 |
| **Minor** | 打磨：措辞、链接、命名、格式 |
| **信息** | 非缺陷备忘：版本未 bump、旧引用、可接受省略、缺可选文档 |

## 就绪度评分（0-100，维度加权）

| 维度 | 建议权重 | 满分含义 |
|------|---------|---------|
| 一致性 | 25 | 文档间无冲突，同主题口径统一（对齐关系全绿） |
| 完整性 | 25 | 全景必需文档齐、无空壳/占位/缺列/缺分支 |
| 可实现性 | 20 | 产出可直接指导实现（无歧义/无缺失） |
| 产品对齐 | 20 | 领域/设计服从产品门禁，无越界 |
| 参考输入 | 10 | 竞品/参考分析可用（内部瑕疵不扣核心） |

- **可交付完结水位 = 100**：Critical/Major 清零 + Minor 无阻塞项；
- 参考锚点：产品文档完结 100（多轮审计）；领域文档 42（8 Critical 挡开工）——用实际案例校准描述。

## 权威裁决

冲突处必须**指定权威**（如「实现以 A0 为准」「产品门禁以 product/00 为准」），并在报告中明确「被审文档冲突处降级/以权威为准」，避免实现期两难。已裁决未回写的冲突：不升 Critical，标 Major + 建议回写标注。

## 项目最终验收（整体 go/no-go——产品交付用户前）

文档就绪度（层①-③）之外，**项目最终验收 = 四层整合的 go/no-go 判断**（借鉴 release readiness + AI agent readiness）：

| 验收层 | 检查 | 工具/方法 |
|--------|------|----------|
| ① 定义就绪 | 文档就绪度（本审计层①-③）——Critical/Major 清零 | product-doc-audit |
| ② 质量就绪 | 全链测试通过（DoD：确定性断言 + 概率性样本/阈值） | 质量验证链（项目自有测试栈：单元/契约/组件/E2E/视觉回归） |
| ③ 发布就绪 | 缺陷清零 + 测试全过 + 发布条件（上线清单/回滚预案） | release readiness 清单 |
| ④ AI 就绪（AI 应用） | observability（追踪工具调用/推理）+ evals（回归基准）+ guardrails（输入/输出护栏）+ 明确归属 | AI agent readiness 清单 |

**最终判断**：
- **Go**：四层全过 → 可交付用户（附验收证据链：文档就绪度 + 测试报告 + 发布清单）
- **No-Go**：任一失败 → 列出挡交付项 + 修复序（不交付——防"看起来能用了"）

**产出**：验收报告（四层证据 + Go/No-Go 结论 + 残留风险）——与 PRODUCT-DOC-AUDIT.md 同目录（或追加到审计报告）。

## 可交付判断

- **Yes**：无 Critical、Major 可限期闭合 → 附建议修复序 + 实现阅读序；
- **No**：存在 Critical → 列出挡交付项 + 裁决建议，待闭合后开下一轮复审。

## 报告（唯一产出）

模板见下。语言与用户一致（默认中文）。三节要求：

| 节 | 要求 |
|----|------|
| **问题** | 按严重度列出（含证据+影响）；无缺陷写「无」 |
| **建议** | 回指问题编号；给行动（裁决/修复序/维持现状）+ 权威裁决；不改被审文档 |
| **验收标准** | 可勾选清单：何种状态算通过（如「#N 裁决后 C 清零」「采纳后就绪度 ≥85」） |

## 报告模板

```
## 产品文档审计报告：<文档集名>

- 审计对象：`<文档集目录>`（N 份：…）
- 审计日期：YYYY-MM-DD
- 审计方式：三层审计（文档全景 → 独立规则 → 交叉验证）+ 就绪度评分
- 结论：<一句话总评 + 就绪度 X/100 + 可交付 Yes/No>

## 一、文档全景核查（层①）
| 文档 | 阶段 | 必需性 | 现状 | 判定 |
|------|------|--------|------|------|
| … | … | 必需/可选 | 有/缺 | ✓/部分/✗ |

## 二、逐类独立审计（层②）
| 文档 | 类型检查点 | 核心审查维度（高维判据） | 速评 |
|------|-----------|--------------------------|------|

## 三、交叉验证矩阵（层③）
| 对齐关系 | 文档 A 说法 | 文档 B 说法 | 判定 |
|---------|-----------|-----------|------|

## 四、问题
1. **[Critical/Major/Minor/信息]** <标题>
   - 现象 / 证据 / 影响
2. …
（无缺陷则写「无」）

## 五、建议
- 对应问题：#1/#2… 或「无问题，无需改动」
- 行动：裁决 / 修复序 / 维持现状
- 权威裁决：<冲突处权威指定>

## 六、验收标准
- [ ] 就绪度 ≥X / Critical 清零 等可勾选项

## 七、备注
- 本次审计未修改被审文档；报告路径：…
```

## 反模式

- 修改被审文档「顺手修好」
- 无全景硬审：不看缺哪些必需文档，只审已有文档
- 不识别文档类型，用一套模板审所有（PRD 与 launch 检查点不同）
- **硬套通用维度凑数**（每类都列 5 维，给不适用维度硬标低权重）
- 交叉验证比对无关文档，漏掉必对齐点（D8↔D0、design↔权威）
- **盲信既有审计结论**（「已完结/已闭合」不 spot-check，放过实质缺口）
- 无就绪度、无分级、只有空泛「看起来不错」
- 为凑数编造问题；把 Minor 当 Critical 吓人
- 冲突处不定权威裁决，把两难留给实现期
- 报告写到其他目录了事

## 完成标准

- [ ] 未修改被审文档
- [ ] 同目录存在 `PRODUCT-DOC-AUDIT.md`
- [ ] 文档全景核查 + 逐类独立审计 + 对齐关系交叉验证 三层齐全
- [ ] 核心审查维度按类型选取（无凑数维度）
- [ ] 报告含 **问题**、**建议**、**验收标准** 三节
- [ ] Critical/Major/Minor 分级 + 权威裁决 + 可交付判断
- [ ] 用户收到总评 + 就绪度 + 报告路径
- [ ] （产品交付前）项目最终验收：四层 go/no-go 判断产出

## 方法论来源（2026-07 调研）

- Addy Osmani《How to write a good spec for AI agents》：Spec 六核心领域、三档边界、致死三要素
- write-spec（Anthropic）：PRD 骨架、Goals/Non-Goals、成功指标、AC（Given/When/Then）、MoSCoW
- NeonForge D7/A8 实践：就绪度评分、Critical/Major/Minor、权威裁决、可交付判断、防漂移
- Document Review（EveryInc）：单文档 clarity/specificity/假设/YAGNI 打分
- Critique Review（critique.sh）：先验证声明再报告（防假阳性）
- launch/product-marketing（coreyhaines31）：上线文档检查点、ORB 渠道、五阶段
- 三层方法论：0-1 交付文档全景 → 独立审计规则（维度按类型选取）→ 交叉验证对齐关系（2026-07 重构）