SSOT 不充分时，评审要降级而不是猜：三级证据与三种结论
2026-09-14，我提过一个流程问题：当 SSOT 等材料不足时，评审应该怎么降级？同时要求明确 LLM 在这个流程里“正确执行”的边界。当时附带的 PPCF/PCE 评审报告是粘贴材料，里面的缺陷和源码行号我并没有重新核验，所以这里不引用那些细节。
在我接触的评审里，材料不足更常见。需求只有一段聊天记录、schema 只有截图、验收标准只写在某个人脑子里，这些情况都会出现。问题不在于“材料不齐能不能评审”，而在于评审能给出什么级别的结论，以及哪些话不能说。
先定义 SSOT 包含什么
SSOT 不是某一个文件，而是一组能互相印证的依据。做评审时至少看五类：
| 类别 | 例子 | 缺了会怎样 |
|---|---|---|
| 需求 | 用户故事、范围、不做清单 | 无法判断“做的是不是对的事” |
| 契约 | API schema、字段类型、错误码 | 无法判断前后端是否对得上 |
| 验收 | 可执行的用例、边界条件 | 无法判断“完成”是否成立 |
| 实现 | 代码、迁移、配置 | 无法判断描述与实现是否一致 |
| 运行 | 日志、部署配置、回滚方式 | 无法判断上线后的行为 |
五类齐全不等于一定正确，但缺得越多，结论就越应该收缩。
三级证据
把材料完整度分成三级，评审开始时先标级：
- L1 完整：五类依据均可获得且能互相引用；仍需验证关键行为，完成后才可考虑通过。
- L2 部分：需求范围明确，部分非关键依据尚缺，但已有材料足以核对特定问题。只能就已核对范围形成有条件结论，不能推定整体正确。
- L3 不足：需求范围不清、关键契约缺失或现有材料不足以核对核心行为。暂停受影响的评审结论，先澄清和补证。
这里的等级是一套建议的工作约定，不是行业通用标准；判断应看缺失材料是否影响核心行为，不能只数文件数量。
分级不是给团队打分，而是决定评审记录的措辞。L2 不能写“功能正常”；只有缺失的验收标准不影响本次核心范围时，才能限定为“已核对部分与现有实现一致，其他验收标准未提供”。若核心验收标准缺失，应标记 BLOCKED。
三种结论
| 结论 | 适用条件 | 必须写清 |
|---|---|---|
| PASS | L1，关键行为已验证 | 验证项、证据位置、未覆盖范围 |
| CONDITIONAL | L2，本次核心范围可核对，非核心部分有缺口 | 缺什么、谁补、补之前哪些结论不成立 |
| BLOCKED | L3，或关键契约缺失 | 缺口的负责人、最晚补齐时间、暂停哪些动作 |
三种结论里，最容易滥用的是 CONDITIONAL。它常被写成“基本通过”，缺口却留在口头上。有效的 CONDITIONAL 必须带条件：例如“字段类型未提供，暂不判定兼容性；补齐 schema 后重跑第 3、4 条用例”。条件不写，结论就退化成了 PASS。
CONDITIONAL 还要有明确的关闭条件，否则会长期挂着。关闭至少满足三条：缺口材料已补齐并登记位置；原先列为“未核对”的用例已按记录重跑；评审人核对结果后在记录里签字或留下可追溯的确认。只补了文档但没有重跑用例，不能改成 PASS；只跑了用例但没有补契约，也不能改成 PASS。
评审记录模板
结论：CONDITIONAL
材料等级：L2
已核对：
- 需求范围：docs/requirements.md 第 12-28 行
- 实现：backend/orders/service.py 第 40-96 行
未核对：
- 非本次核心范围的订单状态 C 的 schema 定义（文件未提供；若影响核心范围则改为 BLOCKED）
- 非本次核心范围的并发取消验收用例（未提供）
依据边界：
- 仅核对静态代码，未运行服务
- 未访问生产库
风险：
- 若后续纳入状态 C 且未补齐规则，当前实现可能缺少相应处理
下一步：
- 由需求负责人在约定日期前补 schema
- 补齐后重跑取消与重复提交用例
模板的关键不是格式，而是每一行都能被另一个人复核。写“已核对”必须带路径和行号；写“未核对”必须说明缺什么；写“风险”必须说明触发条件，不能只写“可能有风险”。
四条降级规则
1. 缺验收标准，不评审“正确性”
没有验收标准时，评审只能回答“实现和描述是否一致”，不能回答“行为是否正确”。把这两句话分开写，能避免把“看起来对”写成“已验证”。
2. 缺 schema，不推断字段
字段名、类型、可空性、枚举值缺失时，不要从代码反推成契约。缺口影响核心行为或本次发布判断时，标记 BLOCKED 并要求负责人补齐；如果缺口不影响本次已核对范围，可以记录 CONDITIONAL，同时写明不能判断的事项和关闭条件。
3. 文档冲突，先停下来列冲突
两份文档对同一个状态的定义不一致时，不要自行选择“更新的一份”。先把冲突列出来，注明各自的位置和影响，再让负责人裁决。评审者的职责是暴露冲突，不是替业务做决定。
4. 缺源码位置，只给假设
没有文件路径和行号的判断，只能写成待核实的假设，不能登记为缺陷。把假设写成缺陷，会让修复者在一个不存在的问题上浪费时间。
LLM 在流程里的正确执行
LLM 可以做的：归纳材料、对照需求与代码、列出冲突、生成待核对清单、按模板起草记录。
LLM 不能做的：补写缺失的 schema、替业务选择口径、把“没找到”说成“不存在”、在没有依据时给出 PASS。
给 LLM 的指令里应该有一条硬约束：每个结论必须附依据位置；找不到依据时输出“未找到”，并把它放进未核对项。这样它的工作才是可审计的，而不是生成一段看起来很完整的评审意见。
一个构造示例
假设订单系统已提供本次 A、B 状态的需求、规则和验收材料及部分代码，未来状态 C 的规则尚未提供。代码里出现状态 A、B，需求文档提到 A、B、C。这时不能直接判定“代码漏了 C”，因为可能 C 尚未实现，也可能文档过期。
可写的结论是：
结论：CONDITIONAL（假设本次仅评审 A、B，C 不影响本次发布判断）
材料等级：L2
已核对：代码中存在 A、B 两个状态；需求文档提到 A、B、C。
未核对：C 的后续处理规则；状态迁移规则；并发变更时的约束。
风险：若后续版本纳入 C，当前实现可能需要增加对应分支。
下一步：由需求负责人明确后续范围；补齐状态机后再评审。
这个结论没有替任何人做决定，但它把“下一步该谁做什么”写清楚了。如果 C 属于本次核心范围，缺状态机将影响发布判断，应改为 BLOCKED。
把降级写进流程
评审开始前加一个材料检查：五类依据各有没有、在哪、谁负责。检查结果直接决定材料等级和可用的结论类型。评审结束后，把未核对项转成任务，带上负责人和期限；没有关闭的 CONDITIONAL 不能自动升级为 PASS。
材料不足时，最好的评审不是给一个模糊的“差不多”，而是明确告诉对方：现在能确认什么，不能确认什么，缺的部分由谁补。降级不是降低标准，而是把结论限定在证据支持的范围内。
本文由 AI 助手依据本人历史素材起草；2026-09-14 的降级问题是当时需求，未声称已在某个团队执行；PPCF/PCE 报告细节本轮未核验，订单状态示例为构造示例。
