全绿为什么可能是假象
检查模式依靠每个步骤「是否支持检查」来决定行为。不支持检查的命令会被跳过，条件未命中的步骤也会被跳过，而这两种情况在摘要里往往和「通过」混在一起显示。于是出现最危险的判读错误：报告全绿，实际上关键项根本没被执行。另一个方向是误报，阈值过松或判定规则不合理导致的频繁告警，会让人逐渐忽略真实问题。两个方向都要治理，漏报优先。
基本信息
| 核心局限 | 不支持检查的步骤被跳过，结果不可作为通过依据 |
|---|---|
| 常见假象 | 全绿但未实际检查，跳过项被计入通过 |
| 误判方向 | 漏报（危险）与误报（成本）两类要分别治理 |
| 缓解手段 | 优先用只读检查、显式标注跳过项、关键项做真实执行抽样 |
| 判读原则 | 跳过与未知都不等于通过 |
典型使用场景
- 配置基线检查：确认哪些项真正读到了配置，哪些被跳过
- 网络设备状态检查：设备命令回显格式差异大，需显式解析与判定
- 依赖与版本检查：包管理命令在不同系统表现不同，跳过项要单独列出
- 迁移与演练脚本：检查模式下大量步骤被跳过，不能据此判断可迁移
- 合规自查：报告需能区分通过、失败、跳过、未知四类结果
现象、含义与风险
| 现象 | 含义 | 风险 |
|---|---|---|
| 全绿但输出很少 | 多数步骤被跳过未真正检查 | 漏报，问题被掩盖到下个周期 |
| 步骤被跳过 | 命令不支持检查或条件未命中 | 不能视为通过，需单独登记 |
| 结果未知 | 无法判定，需人工确认 | 计入合格会形成长期盲区 |
| 频繁误报 | 阈值过松或规则不合理 | 告警疲劳，真实问题被忽略 |
| 检查通过执行失败 | 检查与执行走不同逻辑路径 | 两套判定分叉，结论不可用 |
把跳过与未知显式化
把跳过与未知显式化
result_classes: [pass, fail, skipped, unknown] # 四类分开统计，禁止合并
rules:
- 只读检查优先 # 读配置、读状态类检查可在检查模式可靠运行
- 关键项必须真实抽样 # 涉及权限与依赖的项在小范围真实执行后再判定
- skipped 不计入 pass # 报告里单列，并给出跳过原因
report:
headline: 通过率 # 通过率分母必须排除 skipped 与 unknown
detail: 附原始证据与采集时间 # 布尔值不足以支撑复核与审计关键检查项要能给出可核验的原始证据（配置片段、命令回显、采集时间），而不是一个布尔值。只有结论没有证据的检查，在复核与审计中无法立足。
把跳过项计入通过是合规检查里最常见的假象。一旦审计要求复核原始结果，报告会被整体否定，此前的周期结论也要重做。