## 质量检查：为什么这些规则足够“充分检查”

`/vspec:qc` 的检查规则来自 `quality_standard.md`。它并不是某个行业的专用模板，而是一套把“高质量需求必须回答的问题”固化成可执行清单的规则集。

### 0）质量标准与落地方法（9 个维度）

质量检查不是“主观打分”，而是把质量拆成可检查的维度，并为每个维度设计：缺陷分类 → 检查问题 → 定位方式 → 修复动作 → 验收办法。

- 完整性：是否把必须覆盖的对象与分支覆盖齐
  - 典型缺陷分类：角色遗漏、场景遗漏、状态遗漏、异常/补偿遗漏、约束遗漏、产物遗漏（字段/日志/审计/报表）
  - 检查方法：先建立“覆盖清单”（角色×动作×数据范围×场景分支×状态变化），再逐项对照文档是否有明确描述与落地口径
  - 修复动作：补齐缺失项，并把缺失项绑定到场景与验收用例（避免补在“说明文字”里无法验证）
- 正确性：需求是否与事实/规则一致，逻辑是否自洽
  - 典型缺陷分类：业务规则互相矛盾、状态机不可达/不可退出、口径与现网/合同冲突
  - 检查方法：用“反例”推导（如果 A 成立会导致什么矛盾）、关键规则与数据源交叉校验、边界条件演算
  - 修复动作：明确权威口径（谁拍板、依据是什么），并在文档中给出一致的规则与示例
- 精确性：关键口径是否可度量、可落地
  - 典型缺陷分类：时间口径不清（时区/自然日/工作日）、上下限缺失、精度/四舍五入规则缺失、默认值不清
  - 检查方法：对每个核心字段/指标要求“定义 + 单位 + 精度 + 取值范围 + 默认值 + 示例”
  - 修复动作：把口径固化为字段表/规则表，并在验收用例里覆盖边界值
- 灵活性：是否具备响应变更的能力（范围变化、规则变化、策略变化）
  - 典型缺陷分类：缺少变更边界与策略、规则写死在流程里、缺少版本化口径、无法做灰度/回滚导致变更风险高
  - 检查方法：显式写清“可变点与不可变点”（哪些可配置、哪些需发版）、变更影响面（状态/数据/权限/外部依赖）、以及变更的验证与回滚策略
  - 修复动作：把可变点抽成规则表/配置/策略，补齐迁移与兼容方案，并把变更场景纳入验收与演练
- 复用性：描述是否能跨场景/跨团队复用，而不是一次性交付文本
  - 典型缺陷分类：规则散落在各处、同一概念多种叫法、缺少可引用的模型（RBAC/数据权限/资源日历/消息事件）
  - 检查方法：抽取可复用的“模型与清单”（概念表、规则表、权限点、事件 schema），并让具体场景引用它
  - 修复动作：把通用部分上收为工具模型或统一定义，场景文档只写差异点
- 易读性：读者能否快速理解并定位信息
  - 典型缺陷分类：结构混乱、缺少示意图/表格、关键定义埋在段落里、章节无可导航的层级
  - 检查方法：信息按“先结论后细节”、关键对象用表格呈现、每个模块都有入口图与输出清单
  - 修复动作：重排结构，增加小结与表格，确保“读者找到答案的路径”清晰
- 一致性：同一概念/字段/流程在全文是否保持一致
  - 典型缺陷分类：同名不同义、同义不同名、字段/状态在不同章节不一致、图与文不一致
  - 检查方法：建立术语表与字段表作为单一事实来源；逐段对齐图、表、接口与用例
  - 修复动作：统一命名与定义，并把变更记录到“术语/字段/状态”而不是只改正文
- 可实现性：工程上是否能做、是否能以合理成本做
  - 典型缺陷分类：缺少依赖边界（外部系统/数据来源）、缺少失败策略、缺少幂等/并发口径、缺少运维与可观测要求
  - 检查方法：对关键路径做“依赖清单 + 失败矩阵 + 状态机 + 数据流”，并写清降级/回滚/补偿
  - 修复动作：补齐边界与策略，必要时调整范围或拆分里程碑（先做可交付的最小闭环）
- 可测试性：是否能用验收/自动化验证，而不是“看起来差不多”
  - 典型缺陷分类：缺少可观察输出（事件/日志/状态/报表）、场景不可枚举、验收口径主观
  - 检查方法：每条核心规则都要对应至少一个可执行的验收用例；每个异常路径都要有可观测证据
  - 修复动作：把规则落到“Given/When/Then”的用例与断言，并补齐测试数据与权限/数据范围前置条件

特别说明：完整性通常无法从正面“证明已覆盖所有情况”，但可以把完整性拆成上面的缺陷分类（角色、场景、状态、异常、约束、产物等），再用覆盖清单去逼近与验证，从而形成可执行且有效的质检方案。

### 1）与行业无关：检查的是“结构与可验证性”

规则关注的不是业务名词本身，而是需求是否具备可落地的结构，例如：

- 目标与范围：目标/非目标是否明确，边界是否可辩论、可决策
- 角色与权限：谁能做什么、谁能看什么（访问权限与数据权限）是否可验证
- 状态与约束：状态机、前置条件、限制条件、异常与补偿是否闭环
- 一致性与口径：时间口径、上下限、公式精度、字段定义是否自洽且可追溯
- 验收与可测试：场景是否可枚举，验收用例是否能覆盖关键分支与关键约束
- 风险与外部依赖：失败策略、重试、幂等、回滚、审计与告警是否被显式化

这些维度不依赖行业；只要是“要交付的软件需求”，就必然要回答。

### 2）为何能“充分”：覆盖常见失效模式

质量检查的价值在于把交付中高频的失效模式前移到需求阶段识别出来，例如：

- 需求只有主链路，缺少取消/拒绝/撤回/失败补偿，导致上线后不可运营
- 权限只写一句话，缺少权限点与数据范围，导致越权或权限口径反复
- 缺少时间/精度/上限等口径，导致实现细节无法统一、验收争议不断
- 外部依赖失败策略缺失，导致异常时不可恢复、不可追责

因此，“充分”并不等于穷举所有业务细节，而是把最容易导致返工、事故、争议的关键维度系统化覆盖。

### 3）千锤百炼：从反复返工与事故中沉淀出来

这套规则并非一次性设计完成，而是来自大量需求评审、实现对齐、验收争议、线上问题复盘中的反复迭代：每一条规则都对应一种真实发生过的缺陷类型或争议点，并被改写为“可检查、可定位、可给出修复建议”的条目。

### 4）先方法论，再提示词：稳定输出的关键步骤

规则能发挥效果的前提是：先用抽象/思维方式把问题空间固定下来（边界、对称、约束、多样性），再用提示词把这些维度输出为可审阅的结构化结果。缺少方法论支撑的“随便分析”很难稳定覆盖关键维度，也很难复用到不同需求与不同团队。
