pm-spec-quality-audit

规格质量审查技能

此技能相较于默认行为的变化

默认情况下，Claude 会通过称赞规格说明的结构并建议润色措辞来进行审查——它很少测试某项要求按原文是否可实现、不同团队是否会有不同理解、文档是否悄然遗漏了范围之外的内容，或“已验证”的说法是否有任何证据支持。此审查会强制落实四件事：每项发现都指出违反的原则；对每项要求都提出“QA 能否据此编写通过／不通过检查，而无需询问你的意思？”；检查文档中缺少的内容（范围排除项、DCA、边界情况），而不只是已有内容；并根据对构建工作的影响评定发现的严重程度，同时给出具体改写建议。

这是一项评估型技能：每当审查规格说明、PRD 或需求文档时，它都会自动运行；pm-product-spec 生成文档后，它也会作为验证步骤运行。

范围纪律。 直接调用时（用户指定了此项审查），只审查这一项关注点——不要纳入同类审查。只有当 pm-product-review 编排器或生成式技能根据 docs/orchestration-policy.md 调用它时，它才会与其他审查视角一起运行；在该策略中，它属于针对特定产物的审查视角——适用于规格说明／PRD。明确指定的范围始终优先。

---

框架——检查内容及违规表现

1. 问题锚定与可追溯性

规格说明应以问题或机遇及其当下的重要性开篇——即使每个人都“已经知道”。每项要求都应追溯到用户或业务成果；始终将要求与意图关联起来的规格说明，能避免长期项目偏离方向，沦为互不相关的实现工作。

以下情况需标记： 文档以解决方案开篇；存在服务于任何既定问题或目标的要求；“为什么”只存在于作者脑中。

• ❌ 规格说明开篇：“在仪表板上构建一个带有三个邀请名额的推荐组件。”
• ✅ 规格说明开篇：“今年获客成本上升了 40%；推荐用户的留存率高出 2 倍。目标：构建一种推荐机制，使新注册用户中至少 15% 来自推荐。”

2. 层级正确——需求、功能规格与技术规格

三层层级：业务／用户需求（用户体验到什么——PRD）、功能规格（产品如何运作，即使没有 UI 也成立）、技术规格（代码如何实现——属于工程团队的职责）。混淆层级会导致两种典型问题：规格说明含糊不清，实际上只是在提需求；以及 PM 越权干预架构。

以下情况需标记： 功能规格规定了框架、数据模型或架构；“规格说明”只有结果愿望，却没有行为描述；PRD 目标与实现细节交织在同一部分中。

• ❌ “价格计算器必须使用 Node 微服务并通过 Redis 缓存来实现。”（出现在 PM 的功能规格说明中）
• ✅ “价格计算必须接受基础价格、折扣规则和可选的促销代码，并返回经过验证的最终价格——即使没有用于该计算的 UI，也必须如此。”

3. 每项要求的可测试性

当 QA 或任何人无需询问作者，就能据此编写通过／不通过检查时，这项要求才算完成。主观形容词是典型违规表现。可测试性适用于各种类型：功能（操作 → 响应）、可用性（任务完成情况）、性能（负载、错误率）、无障碍性（对比度、键盘、屏幕阅读器）。

以下情况需标记： 出现“快速”“直观”“用户友好”“无缝”等词，却没有定义衡量标准；成功标准没有数字、单位或条件；无法判断要求是否已满足。

• ❌ “页面应快速加载。”
• ✅ “在标准移动网络环境下，页面应在 3 秒内加载完成。”

4. 完整流程，而非理想路径

需求必须描述完整工作流——包括边缘情况、错误以及返回／部分完成状态，而不只是结果。“用户可以创建账户”掩盖了所有重要的实现决策。

**以下情况需标记：**只规定了成功路径；未定义错误、中断或回访用户的行为；多步骤流程被写成一句结果描述。

• ❌ “用户可以创建文档。”
• ✅ “点击‘创建文档’后，会创建草稿；用户可以编辑草稿，但只有在指定名称和文件夹后才会保存。如果用户在流程中途离开，草稿会保留 30 天。”

5. 如实界定范围——明确说明排除项

范围必须说明哪些内容不包含，而不只是列出包含项。未说明的排除项正是错位和范围蔓延的藏身之处。用例应注明哪些功能不包含，而不只是哪些功能包含在内。

**以下情况需标记：**任何地方都未列出排除项；“范围”只是功能清单，没有界定边界；规格说明默默未涵盖、但利益相关方有所期待的内容。

• ❌ 范围：“重新设计结账流程。”（是否包含访客结账？退款？移动应用的一致性？）
• ✅ “包含：网页结账、访客结账。不包含（本次发布）：移动应用结账、退款流程变更、忠诚度积分兑换。”

6. 依赖项、约束与假设（DCA）

这是最常缺失的部分，也是交付实际出问题的地方。依赖项需要明确负责人，并注明内部／外部分类；约束需要明确可调整的方面（时间、成本或范围——三者都固定就是失败计划）；假设必须表述为可测试的陈述，并注明验证状态和缓解措施，而不是模糊的信念。

**以下情况需标记：**没有 DCA 部分；依赖项没有负责人（“需要法务批准”——由谁负责，截止日期是什么？）；时间、成本和范围都被视为固定不变；假设被当作事实陈述（“用户会觉得入门流程很直观”）。

• ❌ 假设：“用户会更喜欢新流程。”
• ✅ 假设：“80% 的新用户会在两分钟内完成入门流程——由 UX 负责人在 3 月 15 日前通过可用性测试验证。如果验证不通过：恢复为两步式入口。”

7. 验证证据——评审 ≠ 验证

评审检查内部质量（清晰、一致、可行——由工程、UX 和业务团队完成）；验证则检查方案对真实用户是否有效（原型测试、用户访谈——应在规格说明定稿之前完成，以便将洞察纳入其中）。规格说明若声称已完成验证，就需要提供证据链：将测试结果关联到因此而修改的需求。

**以下情况需标记：**出现“已通过用户验证”，但未说明方法、参与者人数或关联结果；用户验证安排在开发之后，沦为打勾流程；被证伪的假设没有促使规格说明发生变化；规格说明定稿前未与依赖项负责人进行评审。

• ❌ “该流程已通过验证。”（由谁验证？依据是什么？）
• ✅ “原型测试，共 5 位参与者（3 月 3 日）：其中 3 位未注意到‘以访客身份继续’→ 更新需求 4.2，将访客结账设为主要操作。”

8. 受众匹配与全局视角

只涵盖某个团队工作范围的规格说明，会产出只能独立运行、集成后却无法正常工作的功能——应始终先呈现全局视角，再说明各团队的细节。格式必须适合读者：前端使用带注释的设计文件，后端使用工作流／数据流图，业务相关方查看高层级成果；内部文档可以包含专有细节，对外文档则只能包含安全的承诺。

标记条件： 规格说明只涵盖某个团队的工作，没有系统上下文；仅通过 UI 模型图说明后端行为；向业务相关方提供 API 级别的细节（或只向工程师提供愿景描述）；一份文档试图同时满足内部和外部受众，导致内容难以兼顾。

• ❌ 一份结账规格说明记录了新的支付 UI，却完全没有提及其依赖的订单服务和邮件收据变更。
• ✅ 先概述完整流程，再按团队划分章节——前端使用带注释的 Figma，支付后端使用数据流图。

权衡说明： 完整性与聚焦——充斥实现噪音的臃肿规格说明，和过于单薄的规格说明一样有问题；应标记缺失的决策，而不是缺少填充内容。删去属于设计／技术文档的细节是改进，不是缺陷。此外，还要权衡稳定性与适应性——PRD 应保持灵活，而规格说明应在开发开始后趋于稳定；不要因为 PRD 不如规格说明精确就标记问题。

---

严重程度评级

根据构建损害为每项发现评级——也就是文档保持原样时，会导致团队构建什么：

严重程度	含义
Critical	团队会构建错误的东西或彼此不同的东西（核心需求无法测试、主要流程未定义、有争议领域的范围边界未说明、只有解决方案却没有问题）
Major	交付会失败或偏离目标（缺少 DCA、外部依赖没有负责人、流程只覆盖顺利路径、未经验证的假设推动重大决策、只关注单一团队）
Minor	文档规范问题降低了信任度（术语不一致、次要需求缺少验收标准、章节内容过时）
Cosmetic	措辞润色；不要用这类问题凑数

范围重叠：成功指标本身是否有效（虚荣指标、可操纵、无法证伪）属于 pm-okr-metric-validity-audit——本审计检查指标是否存在且具体，该审计检查指标是否值得达成。纳入范围的优先级纪律属于 pm-prioritization-rigor-audit。更深入的假设测试方法——是否测试了风险最高的假设、是否采用恰当保真度的方法，以及证据是否诚实——属于 pm-assumption-rigor-audit。

---

输出格式

## Spec Quality Audit — [Document]
Context: [doc type (PRD/functional/technical) · audience · development stage, if known]

### Critical
- [Issue] — what's wrong → concrete rewrite or addition. (Principle)
### Major
- …
### Minor
- …
### Working well ✓
- …

**Top 3 priorities:** the highest build-damage fixes, with suggested rewrites.

始终以按优先级排列的首要问题结尾——平铺列表无法帮助任何人采取行动。

---

如何做好审计

1. 先了解上下文——这是哪种文档（PRD、功能规格说明还是技术规格说明）？应根据该文档所属层级的职责进行审计，而不是拿其他层级的职责来衡量。它处于生命周期的哪个阶段（供审阅的草稿，还是已批准并进入开发阶段——批准后再变更的成本更高）？
2. 检查缺失项，而不只是缺陷——最严重的规格说明缺陷往往是缺少章节（范围排除项、DCA、错误流程），只通读现有内容无法发现这些问题。请逐项检查清单。
3. 只标记会造成实际代价的问题——针对小型、可逆功能的精简规格说明，不需要合规章节。应根据风险和项目规模调整严谨程度。
4. 确定优先级，不要罗列过多——三个会损害构建的问题，胜过十五个吹毛求疵的问题。
5. 明确说明如何修复——重写需求、指出缺少的负责人、拟定范围排除条款。不要只说“让它更容易测试”。

---

常见的应做与不应做模式

❌ 不应做	✅ 应做
夸赞结构和措辞润色	逐项测试每条要求：QA 能否据此编写通过／失败检查？
只审查已写出的内容	按清单检查缺少的内容——排除项、DCA、错误流程
对“已与用户验证”照单全收	询问验证方法、参与者，以及研究发现改变了哪些要求
将评审和验证视为同一步骤	评审 = 内部质量；验证 = 在规格定稿前收集真实用户证据
接受“快速／无缝／直观”作为要求	用数字、单位和条件重写
因 PRD 缺少规格精度而指出问题	根据每份文档所属层级的职责进行审查
要求所有地方都增加更多细节	指出缺失的决策；删去应放在技术／设计文档中的实现细节
重新审查成功指标是否有效	交由 pm-okr-metric-validity-audit 处理；在此检查指标是否存在且具体
提交未排序的问题清单	按对构建的损害程度划分严重性，并列出前三项优先事项及重写建议

---

来源课程（Uxcel）

• 评审和验证规格说明
• 理解产品规格说明
• 产品规格说明的类型
• 产品规格说明与产品需求文档的区别
• 依赖项、约束和假设