07 · 设计评审规范（Design Review · 集成评审）
📦 来源：
wl-skills-designv0.11.1 ·standards/07-design-review.md· 可判定条目由verify（[M] 机械项）自动执行。
定位：本规范定义跨域集成评审——把需求设计（spec）、数据库设计（DB）、接口设计（IF）三份产物聚合成一份评审报告，给出量化评分、跨文档一致性结论、按优先级排序的问题清单与修复任务。 它是第二层报告：不重新发明各产物自身的检查项，而是复用各产物 validate 的结论（spec/DB/IF 各自的验证清单），叠加「三角联动」校验与「综合评分」。 工具无关：报告以 Markdown 输出，适用于任何文档来源。
§零 为什么需要集成评审
各产物自己的 review（DB 34 项、IF 38 项、spec 验证）解决的是纵向质量（单文档是否规范）。但复杂项目里最容易出事的是横向一致性：
- spec 的 IPO 输出字段，数据库没有建表/建字段
- 接口报文字段的英文名，在数据库数据字典里找不到对应
- spec 的某个功能编码，没有任何接口承载
- 三份文档对同一业务对象命名/口径不一致
集成评审的价值 = 一眼看清整体健康度（仪表盘）+ 揪出跨文档断点 + 告诉评审者「该补哪些信息、按什么顺序修」。
§一 评审对象与范围
| 维度代码 | 维度名称 | 数据来源 | 是否重新打分 |
|---|---|---|---|
| D1 | 需求设计（SPEC） | SPEC_REVIEW_*.md（43 项）/ 06-spec-doc.md §十一 | 引用结论，不重算逐项 |
| D2 | 数据库设计（DB） | DB_REVIEW_*.md（34 项）/ 03-database.md §八 | 引用结论 |
| D3 | 接口设计（IF） | IF_REVIEW_*.md（38 项）/ 04-api-design.md §十 | 引用结论 |
| D4 | 跨文档联动一致性（三角） | 本规范 §四 新增校验（18 项） | 本报告新算 |
原则：集成评审至少覆盖两个不同设计域，只有单一领域时退回对应领域 Skill。D1/D2/D3 直接采集各 artifact 报告的「通过/失败/暂挂」计数与失败明细；若某份 artifact 报告缺失，则只读执行对应 review（或标「未提供」），不得自动修复或写入报告。D4 是集成评审独有、必须现场计算的部分。
§二 评分模型
2.1 维度得分
维度得分 = 通过项 / (总项 − 暂挂项 − 不适用项) × 100%暂挂项（跨文件暂挂 / 待补充调研）和有证据的不适用项均不计入分母。两类必须分列：暂挂需要后续补证，不适用必须说明 profile 或范围依据。
2.2 综合得分
综合得分 = Σ(各维度通过项) / Σ(各维度 总项 − 暂挂项 − 不适用项) × 100%2.3 等级阈值
| 得分 | 等级 | 含义 |
|---|---|---|
| ≥ 90% | 🟢 优秀 | 可直接进入开发 |
| 75–89% | 🟡 良好 | 修复 P1 后进入开发 |
| 60–74% | 🟠 待改进 | 修复 P0 + P1 后复评 |
| < 60% | 🔴 不合格 | 重新设计后复评 |
2.4 P0 一票否决（强制）
只要存在任何 1 个 P0 问题，综合等级最高只能评定为 🟠 待改进，无论得分多高。 理由：P0 影响系统正确性，得分再高也不能进入开发。这是评审的「闸门」。
§三 问题分级（严重度）
| 等级 | 定义 | 典型示例 | 处理要求 |
|---|---|---|---|
| P0 阻断 | 影响系统正确性 / 数据丢失 / 集成断裂 | 主键缺失；接口字段名与 DB 不一致；核心功能无接口；spec 输出对象无对应表 | 必须修复，阻断进入开发 |
| P1 严重 | 违反已声明的设计画像或影响可维护性底线 | 缺画像要求的审计字段；关键查询无索引；接口编码重复 | 本轮评审通过前修复 |
| P2 一般 | 影响规范一致性 | 命名风格不统一；缺字段注释；中文口径小差异 | 下一轮迭代修复 |
| P3 建议 | 优化项 | 可加复合索引；可补幂等说明 | 可选 |
严重度映射规则（从各验证清单组推导）
| 来源检查组 | 默认严重度 |
|---|---|
| DB-X / IF-X（联动）、D4 三角断点 | P0 |
| DB-B（画像要求的系统字段）、IF-B（画像要求的报文结构）、IF-A 编码唯一 | P1 |
| DB-C（有证据的关键索引）、IF-C（画像要求的安全/幂等） | P1 |
| DB-A / IF-A（命名）、DB-D / IF-D（文档完整性） | P2 |
| 优化建议 | P3 |
画像与证据约束（强制）
- 先读取数据库画像和接口画像，再判断系统字段、分页、响应包装、认证、幂等、版本与并发策略；画像未声明时应澄清或标暂挂，不得直接判失败。
- 上表是默认严重度，不是关键词映射。每个问题必须给出规则来源、文档位置和实际影响证据。
- 只有能够证明会导致系统错误、数据丢失、安全边界失效或集成链路中断时才能升级为 P0；缺少某种可选实现技术本身不得判 P0。
- 暂挂项和不适用项不得伪装成通过项，也不得计入失败数；不适用必须有范围或 profile 证据，暂挂补齐证据后再重新计算。
§四 跨文档联动一致性（D4，18 项，集成评审独有）
这是集成评审的核心。按三角关系
spec → DB、spec → IF、IF → DB逐项比对。 集合定义沿用03-database.md §九与04-api-design.md §十一。
集合定义
SET_SPEC_OUT = { spec IPO Output 涉及的持久化对象 }
SET_SPEC_FLD = { spec IPO 需持久化字段（中文名）}
SET_SPEC_FUNC = { spec 功能编码 }
SET_DB_TABLE = { DB 业务表实体 }
SET_DB_FLD_CN = { DB 数据字典字段中文名 }
SET_DB_FLD_EN = { DB 数据字典字段英文名 }
SET_IF_LIST = { 接口清单中的接口 }
SET_IF_FLD_EN = { 接口报文字段英文名 }
SET_IF_FUNC = { 接口覆盖的功能编码 }D4 检查项
A 组 · spec → DB（持久化覆盖）
| 项 | 校验 | 失败严重度 |
|---|---|---|
| V01 | SET_SPEC_OUT ⊆ SET_DB_TABLE（每个输出对象都有表） | P0 |
| V02 | SET_SPEC_FLD ⊆ SET_DB_FLD_CN（每个持久化字段都有列） | P0 |
| V03 | 匹配字段中文口径一致（无同义异名） | P2 |
| V04 | DB 无 spec 未提及的「孤儿业务表」（或有说明） | P2 |
B 组 · spec → IF（功能承载）
| 项 | 校验 | 失败严重度 |
|---|---|---|
| V05 | SET_SPEC_FUNC ⊆ SET_IF_FUNC（每个功能都有接口承载） | P0 |
| V06 | 每个「对外集成/数据交换」类功能都有集成接口 | P0 |
| V07 | 接口数量与功能复杂度匹配（无 1 接口扛多功能的超载） | P2 |
| V08 | IF 无 spec 未提及的「孤儿接口」（或有说明） | P2 |
C 组 · IF → DB（报文字段落库）
| 项 | 校验 | 失败严重度 |
|---|---|---|
| V09 | SET_IF_FLD_EN ∩ 持久化字段 ⊆ SET_DB_FLD_EN（接口字段英文名能在 DB 找到） | P0 |
| V10 | 接口字段类型与 DB 字段类型兼容 | P1 |
| V11 | 接口字段中文描述与 DB 字段中文名一致 | P2 |
D 组 · 三方命名与口径
| 项 | 校验 | 失败严重度 |
|---|---|---|
| V12 | 同一业务对象在 spec/DB/IF 命名一致（如「订单」不混用「工单」） | P1 |
| V13 | 同一字段英文名在 DB/IF 拼写一致 | P1 |
| V14 | 模块码 / 领域码在三份文档一致 | P2 |
| V15 | 状态码 / 枚举值定义在三份文档一致 | P1 |
E 组 · 可追溯性
| 项 | 校验 | 失败严重度 |
|---|---|---|
| V16 | 存在 spec功能 → 接口 → 表 的可追溯链路（追溯矩阵） | P1 |
| V17 | 每条 P0/P1 问题都能定位到具体文档位置 | P1 |
| V18 | 追溯矩阵行数 == ` | SET_SPEC_FUNC |
缺对端文档（如工作区只有 DB 没有 IF）：相关项标「跨文件暂挂」，不计入分母，但在报告显著标注「⚠️ 缺 {文档}，N 项联动未校验」。
§五 追溯矩阵（必出）
集成评审报告必须包含一张正向追溯矩阵，让人一眼看到「需求 → 接口 → 数据落点」是否闭环：
| spec 功能编码 | 功能名称 | 对应接口 | 落库表 | 状态 |
|---|---|---|---|---|
| DEMO-OM-001 | 创建订单 | order_create | ordr_order_main | ✅ 闭环 |
| DEMO-OM-002 | 订单查询 | order_query | ordr_order_main | ✅ 闭环 |
| DEMO-OM-003 | 订单作废 | —（缺接口） | ordr_order_main | ❌ 断点(V05/P0) |
状态取值：
✅ 闭环/❌ 断点(项号/等级)/⚠️ 暂挂(缺对端)。
§六 报告结构（六部分，固定顺序）
1. 评审摘要（仪表盘表） ← 一眼看健康度
2. P0 问题清单（阻断项） ← 必须先修的
3. 各维度详细分析（D1~D4）
4. 追溯矩阵（spec→IF→DB）
5. 修复任务清单（按 P0→P1→P2 排序）
6. 评审结论与下一步详见 §十 模板。
§七 评审执行流程
Step 1 采集：读取/触发 spec、DB、IF 三份 validate 结论（通过/失败/暂挂/不适用计数 + 失败明细）
Step 2 联动：按 §四 计算 D4 的 18 项三角校验
Step 3 评分：按 §二 算各维度得分 + 综合得分 + 等级（含 P0 一票否决）
Step 4 分级：按 §三 给每条问题打 P0/P1/P2/P3
Step 5 追溯：构建 §五 追溯矩阵
Step 6 出报告：按 §十 模板在对话中返回；仅在用户明确要求保存时写入 docs/review/DESIGN_REVIEW_{模块}_{日期}.md
Step 7 结论：给出「可进入开发 / 修复后复评 / 重新设计」与下一步行动§八 评审执行清单（RV，12 项 — 保证评审本身做到位）
这些是「评审报告自身的质量门」，避免出一份漏项、不可执行的评审。
RV-A 数据采集（3）
- [ ] R01 三个维度（spec/DB/IF）都有数据来源（报告 / 现场触发 / 明确标「未提供」）
- [ ] R02 各维度的「通过/失败/暂挂/不适用」计数完整且总和守恒
- [ ] R03 缺失的对端文档已显著标注
RV-B 评分（3）
- [ ] R04 各维度得分按 §2.1 公式计算（暂挂和不适用项已排除分母）
- [ ] R05 综合得分与等级已给出
- [ ] R06 P0 一票否决规则已应用（有 P0 则等级 ≤ 🟠）
RV-C 联动与追溯（3）
- [ ] R07 D4 全部 18 项已校验或标暂挂
- [ ] R08 追溯矩阵已生成，覆盖所有 spec 功能编码
- [ ] R09 每条 P0/P1 问题已定位到文档位置
RV-D 报告完整性（3）
- [ ] R10 六部分结构齐全（§六）
- [ ] R11 修复任务按 P0→P1→P2 排序，每条有修复建议
- [ ] R12 给出明确评审结论与下一步行动
§九 闭环与复评协议
出报告 → 团队按修复任务修改 spec/DB/IF
→ 触发受影响产物的 validate（DB/IF/spec）
→ 重新运行集成评审（复评）
→ P0=0 且综合 ≥ 阈值 → 评审通过（记录「复评 N 轮通过」）| 规则 | 说明 |
|---|---|
| 复评最小范围 | 仅重跑受问题影响的维度 + D4，其余维度沿用上轮结论 |
| 通过条件 | P0 == 0 且 综合得分 ≥ 75%（🟡 以上） |
| 轮次记录 | 报告头部记录「第 N 轮评审」与上轮对比（得分变化、P0 关闭数） |
§十 报告模板
markdown
# 设计评审报告 — [项目名][模块名]
- 评审时间：YYYY-MM-DD
- 评审轮次：第 N 轮（上轮 75% → 本轮 88%，关闭 P0 ×3）
- 评审范围：需求设计 / 数据库设计 / 接口设计 / 跨文档联动
- 数据来源：SPEC_REVIEW（…）/ DB_REVIEW（…）/ IF_REVIEW（…）
## 一、评审摘要
| 维度 | 检查项 | 通过 | 暂挂 | 不适用 | 得分 | 等级 | P0 | P1 | P2 |
|------|-------|------|------|--------|------|------|----|----|----|
| D1 需求设计 | 43 | 40 | 1 | 0 | 95% | 🟢优秀 | 0 | 2 | 0 |
| D2 数据库设计 | 34 | 30 | 1 | 0 | 91% | 🟢优秀 | 1 | 2 | 0 |
| D3 接口设计 | 38 | 34 | 1 | 0 | 92% | 🟢优秀 | 1 | 2 | 0 |
| D4 跨文档联动 | 18 | 16 | 0 | 0 | 89% | 🟢优秀 | 1 | 1 | 0 |
| **综合** | **133** | **120** | **3** | **0** | **92%** | 🟠**待改进** | **3** | **7** | **0** |
> ⚠️ 综合等级因存在 3 个 P0 被一票否决为「🟠 待改进」。
> ⚠️ D1/D2/D3 各有 1 项暂挂：缺少对端证据。
## 二、P0 问题清单（阻断项，必须修复）
| ID | 维度 | 位置 | 问题 | 影响 | 修复建议 |
|----|------|------|------|------|---------|
| P0-1 | D2 | ordr_order_main | 缺主键 | 数据无法唯一定位 | 增加雪花 id 主键 |
| P0-2 | D4/V05 | spec DEMO-OM-003 | 「订单作废」功能无接口 | 功能无法实现 | 补 order_cancel 接口 |
| … | | | | | |
## 三、各维度详细分析
### 3.1 需求设计（D1）
- 得分 92% 🟢；问题：[P1] … / [P1] …
### 3.2 数据库设计（D2）
- 得分 75% 🟡；P0：…；P1：…
### 3.3 接口设计（D3）
- 得分 75% 🟡；P0：…；P1：…
### 3.4 跨文档联动（D4）
- 得分 78% 🟡；断点：V05（功能无接口）…
## 四、追溯矩阵
| spec 功能 | 功能名 | 接口 | 落库表 | 状态 |
|----------|-------|------|--------|------|
| DEMO-OM-001 | 创建订单 | order_create | ordr_order_main | ✅ 闭环 |
| DEMO-OM-003 | 订单作废 | — | ordr_order_main | ❌ 断点(V05/P0) |
## 五、修复任务清单（按优先级）
| # | 等级 | 任务 | 关联问题 | 负责 | 状态 |
|---|------|------|---------|------|------|
| 1 | P0 | 为 ordr_order_main 增加主键 | P0-1 | DBA | 待处理 |
| 2 | P0 | 补 order_cancel 接口 | P0-2 | 后端 | 待处理 |
| … | P1 | … | | | |
## 六、评审结论
- **结论**：🟠 待改进 — 存在 3 个 P0，暂不可进入开发。
- **下一步**：完成全部 P0 + P1（共 10 项）后触发第 2 轮复评。
- **待补充信息**：xxx 文档缺失，建议补齐后校验 D3/D4 的 6 个暂挂项。§十一 与其他规范的关系
01 流程图 ┐
06 说明书 ┼→ D1 需求设计 ┐
02 原型 ┘ │
03 数据库 ───→ D2 数据库 ┼→ 07 集成评审（本规范）→ 评审报告
04 接口 ───→ D3 接口 │
D4 联动 ───┘- 本规范不替代 03/04/06 各自的 validate，而是消费它们的结论再叠加 D4 + 评分。
- 各产物 validate 输出的报告（
SPEC_REVIEW_*/DB_REVIEW_*/IF_REVIEW_*）是本规范 D1/D2/D3 的标准输入。 - 与 08 词典的关系：
08-glossary.md是字段对齐的中央锚点。当工作区存在词典时，D4 的 V02/V09/V13/V15（字段/枚举一致性）应以「三方各自 ⊆ 词典」为比对基准（O(N)），而非 spec/DB/IF 两两互比（O(N²)）；词典缺失时回退到两两互比。