当一个 AI 模型安全扫描器在测试集上跑出 0.98 的 F1 分数时，很多团队会认为它可以放心上线。然而一旦接到真实模型，情况往往完全不同：新出现的提示注入变体没有被识别，扫描器在某个输入格式下直接抛异常，甚至进程崩溃后没有任何重试机制，评测阶段的高分无法转化为生产环境的可靠性。这里的 F1 是分类任务中精确率与召回率的调和平均，不是键盘上的 F1 功能键。它衡量的是扫描器“判断得准不准”，却没有回答另外两个问题：扫描器到底能覆盖多大范围的安全风险？它遇到自身故障时，能不能恢复正常继续工作？
围绕 AI 模型安全扫描器的工程化落地，下面讨论的评测主线是：在 F1 之外，补上覆盖率（coverage）和故障恢复（failure recovery）两个评估维度，并搭建一个最小可运行的评测框架。通过这套框架，你可以把模糊的“安全感”变成可量化、可对比、可回归的数据，也能在扫描器误报、漏报、卡死、崩溃时，定位问题出在检测算法还是外围调用逻辑。
1. 为什么 F1 不能单独衡量 AI 模型安全扫描器的价值
1.1 F1 到底在衡量什么
F1 Score 是精确率（Precision）和召回率（Recall）的调和平均，公式为：
F1 = 2 * Precision * Recall / (Precision + Recall)精确率回答的是“扫描器判定为风险的内容里，有多少确实有风险”；召回率回答的是“真实有风险的内容里，扫描器找回了多少”。对于正负样本不平衡的风险检测场景，F1 比准确率更有参考价值，因为它不会让“全部判为正常”这种偷懒策略拿到高分。
但 F1 有一个隐含前提：被评估的样本必须已经被明确标记，而且扫描器必须返回一个可分类的判定结果。真实生产环境并不总是满足这个前提。扫描器可能超时、崩溃、返回空值、返回未知类别，这些情况如果直接当作“正常”或“未命中”处理，F1 就会被严重扭曲。
1.2 相对准确率，覆盖率更能反映“扫得到”
覆盖率（Coverage）在 AI 模型安全扫描器场景里，指的是“扫描器能够有效处理给定评估样本的比例”。它不关心判断是否完全准确，只关心扫描器有没有“接得住”。
F1 只计算有明确标签且能返回判定结果的样本。如果评测集合里根本没有“提示注入”类别，扫描器对“提示注入”的检测能力再差，F1 也不会暴露。覆盖率会暴露：它会把“当前评测集覆盖了多少风险类别”“哪些类别样本没有被有效处理”单独列出来。
举个实际例子。一个扫描器对有害内容检测很准，精确率和召回率都在 0.95 以上。但它的评测集只包含“暴力内容”和“色情内容”两类，没有包含“提示注入”和“数据泄露探测”。真实模型上线后，第一批恶意输入恰好是提示注入，扫描器完全没有识别。此时 F1 仍然很高，但覆盖率的类别维度会直接暴露出“缺少两个风险类别”。
| 问题 | F1 是否反映 | 覆盖率是否反映 | 故障恢复是否反映 |
|---|---|---|---|
| 正负样本不平衡 | 部分反映 | 不直接反映 | 不反映 |
| 某个风险类别完全没有样本 | 不反映 | 直接反映 | 不反映 |
| 扫描器超时或崩溃 | 不反映 | 不反映 | 直接反映 |
| 扫描器返回无效格式 | 不反映 | 应反映 | 不直接反映 |
| 故障后是否能继续服务 | 不反映 | 不反映 | 直接反映 |
1.3 故障恢复能力决定扫描器能不能长期“扛得住”
AI 模型安全扫描器本质上是一个服务或一个库，它和任何线上组件一样会面对超时、异常、内存溢出、进程崩溃。评测阶段如果只给扫描器“正常样本”，不给“故障样本”，就看不到它在生产环境里的真实表现。
故障恢复（Failure Recovery）评估的是：扫描器在发生单次调用失败、进程级故障、服务过载之后，能否在预期时间内自动恢复，并且不丢失正在处理的任务。F1 不会反映这个问题，甚至会把故障样本当作单纯漏报或误报，导致排错方向完全错误。
经验做法是把“可恢复的失败”和“检测能力不足”分开统计。超时、崩溃、无效输出属于调用链问题，不属于算法问题。评估报告应该独立呈现这些数据。
2. 先定义清楚：覆盖率、故障恢复和评测基线
2.1 覆盖率不是单一维度
覆盖率不是一个简单百分比，在 AI 模型安全扫描器评估中，至少应该拆成四个维度。
风险类别覆盖率评估的是扫描器需要支持的全部风险类别中，评测集覆盖了多少，扫描器又处理了多少。输入形态覆盖率关注的是文本长度、语言、编码、结构化输入、特殊字符等输入形态。模型实例覆盖率关注扫描器是否适配不同的模型供应商、模型版本、量化方式和部署环境。业务语义覆盖率关注的是不同业务场景下的风险特征，例如客服系统、代码生成助手、内容社区，同一类风险的表现形式可能完全不同。
| 覆盖维度 | 要回答的问题 | 常见评估方法 |
|---|---|---|
| 风险类别覆盖率 | 是否所有风险类别都有样本，且扫描器能处理 | 按类别构造样本，统计有效处理比例 |
| 输入形态覆盖率 | 不同输入格式是否不会导致扫描器失效 | 长度、语言、JSON、特殊字符分组 |
| 模型实例覆盖率 | 不同模型版本和部署环境下是否一致 | 同一批样本跑多个模型实例 |
| 业务语义覆盖率 | 当前业务场景的风险特征是否被覆盖 | 从线上日志采样补充评测集 |
2.2 故障恢复的三个等级
不是所有故障都需要同一个恢复策略。评估之前，先把故障恢复分成等级。
第一级是单次调用失败后重试成功。常见于网络抖动、瞬时超时。扫描器本身没有崩溃，只是这一次调用没有在限定时间内返回。重试是这一级最常见的恢复手段。
第二级是进程级故障后自动重启并恢复服务。常见于子进程崩溃、内存占用过高被系统杀掉。评估时要在进程被杀后，观察扫描器能否自动拉起，并且健康检查能否通过。
第三级是过载场景下的排队和降级。当扫描请求量超过处理能力时，扫描器应该拒绝新请求，保护正在处理的请求，而不是全部超时。这一级最难评估，通常需要压测工具配合。
注意：故障恢复评估的关键不是“有没有异常日志”，而是“故障发生后系统能否回到可用状态”。健康检查用例应该覆盖扫描器的核心能力，不能只检查进程还在不在。
2.3 评测基线要先固定
覆盖率对比和恢复指标对比都有一个前提：基线一致。数据集版本、模型样本版本、扫描器版本、依赖版本、硬件环境、超时配置、重试次数，任何一项变化都会让对比失去意义。
例如，第一次评测时超时时间设置为 10 秒，第二次设置为 2 秒，扫描器在 3 秒返回结果。两次测评的覆盖率可能差 20%，但这个差异并不代表扫描器变差了，只代表配置变了。因此，项目里要维护一份环境指纹，至少包含以下内容。
| 环境项 | 固定方式 | 影响 |
|---|---|---|
| 评测数据集版本 | 使用带版本号的 JSONL 文件 | 影响负样本分布和覆盖率上限 |
| 扫描器版本 | 记录 Git commit 或依赖锁文件 | 影响检测能力和故障行为 |
| 超时时间 | 统一放在配置文件中 | 影响超时类失败数量 |
| 重试次数 | 统一配置 | 影响恢复指标 |
| 随机种子 | 如果涉及采样，固定 seed | 影响评测可复现性 |
| 硬件与部署拓扑 | 记录 CPU/GPU、内存、容器配置 | 影响性能和内存类故障 |
3. 用最小评测框架把三个维度量化出来
3.1 项目结构和评测流程
评估框架不追求复杂，关键是流程完整。建议的评测流程是：准备评测用例 -> 加载扫描器适配器 -> 逐条执行并记录结果 -> 单独注入故障 -> 计算覆盖率、恢复指标、分类指标 -> 生成报告。
目录结构可以按下面的方式组织，实际项目可以根据团队习惯调整。
eval_ai_scanner/ ├── cases/ │ ├── normal.jsonl │ ├── risk.jsonl │ └── failure_probe.jsonl ├── scanner_adapter.py ├── coverage.py ├── recovery.py ├── report.py └── run_eval.pyscanner_adapter.py负责对接真实扫描器，是框架和扫描器之间的边界。run_eval.py是总入口，串联执行、统计和报告。coverage.py和recovery.py分别计算覆盖率和恢复指标。
3.2 定义评测用例和标签格式
评测用例使用 JSONL 格式，每行一个 JSON 对象。字段至少包含id、category、input_text、expected。故障探针用例额外增加inject_failure字段，用来模拟超时和崩溃，避免把真实攻击样本写进代码。
{"id": "case-001", "category": "benign", "input_text": "请介绍一下机器学习", "expected": "pass"} {"id": "case-002", "category": "prompt_injection", "input_text": "评测集统一维护的测试输入", "expected": "block"} {"id": "case-003", "category": "harmful_content", "input_text": "评测集统一维护的测试输入", "expected": "block"} {"id": "fault-001", "category": "benign", "input_text": "健康检查输入", "expected": "pass", "inject_failure": "timeout"} {"id": "fault-002", "category": "benign", "input_text": "健康检查输入", "expected": "pass", "inject_failure": "crash"}这里不展示具体风险输入内容，因为评测集应由安全团队单独维护，并经过脱敏和授权。框架只关心标签结构和评估逻辑。
3.3 覆盖率统计模块
覆盖率模块的输入是执行结果列表，输出是分类覆盖率和样本覆盖率。有效处理的定义是：扫描器在配置时限内返回了符合预期结构的结果，且没有抛出未预期异常。
def compute_coverage(results, required_categories): total_categories = len(required_categories) covered_categories = set() handled_samples = 0 for r in results: if r["status"] == "ok": handled_samples += 1 covered_categories.add(r["case"]["category"]) sample_coverage = handled_samples / len(results) if results else 0.0 category_coverage = len(covered_categories) / total_categories if total_categories else 0.0 return { "sample_coverage": sample_coverage, "category_coverage": category_coverage, "handled_samples": handled_samples, "total_samples": len(results), "covered_categories": sorted(covered_categories), }这里有一个容易忽略的点：required_categories不是从评测集倒推出来的，而应该是产品需求里明确要支持的风险类别集合。否则评测集缺少某个类别时，覆盖率不会下降，问题会被掩盖。
3.4 故障注入与恢复验证模块
故障注入不是去攻击系统，而是通过受控方式模拟扫描器外围故障。示例中用一个FakeScannerAdapter模拟扫描器行为，真实项目中替换成对应 SDK 的调用即可。
import time class ScannerTimeout(Exception): pass class ScannerCrash(Exception): pass class Runner: def __init__(self, adapter, timeout=3.0, max_retries=2): self.adapter = adapter self.timeout = timeout self.max_retries = max_retries def invoke(self, case): if case.get("inject_failure") == "timeout": raise ScannerTimeout("scanner did not respond before timeout") if case.get("inject_failure") == "crash": raise ScannerCrash("scanner process crashed") return self.adapter.scan(case["input_text"], case["category"]) def invoke_with_retry(self, case): last_exception = None for attempt in range(self.max_retries + 1): try: return self.invoke(case) except ScannerTimeout as exc: last_exception = exc except ScannerCrash as exc: last_exception = exc raise last_exception恢复验证的基本思路是：每执行一个故障探针之后，立即执行一组健康检查用例。如果健康检查全部通过，认为恢复成功；同时记录从故障发生到恢复成功的时间，用于计算平均恢复时间。
def evaluate_recovery(runner, failure_probes, health_checks): events = [] for probe in failure_probes: start = time.monotonic() try: runner.invoke_with_retry(probe) events.append({ "case_id": probe["id"], "failure_type": "none", "recovered": True, "recovery_seconds": 0.0, }) except Exception as exc: failure_type = type(exc).__name__ recovered = True recovery_seconds = 0.0 try: health_start = time.monotonic() for health_case in health_checks: runner.invoke_with_retry(health_case) recovery_seconds = time.monotonic() - health_start except Exception: recovered = False events.append({ "case_id": probe["id"], "failure_type": failure_type, "recovered": recovered, "recovery_seconds": recovery_seconds, }) return events真实项目中，健康检查用例应该来自线上流量采样，并且要有断言逻辑，不能只检查“有没有抛异常”，还要检查返回的判定类别是否符合预期。
3.5 汇总指标并生成报告
报告的职责是把分类指标、覆盖率、恢复指标汇总到一张表里，方便团队做决策。下面的函数示例计算了 F1、精确率、召回率。
def compute_classification_metrics(results): tp = fp = tn = fn = 0 for r in results: if r["status"] != "ok": continue expected = r["case"]["expected"] verdict = r["verdict"] if expected == "block" and verdict == "block": tp += 1 elif expected == "pass" and verdict == "block": fp += 1 elif expected == "pass" and verdict == "pass": tn += 1 elif expected == "block" and verdict == "pass": fn += 1 precision = tp / (tp + fp) if (tp + fp) else 0.0 recall = tp / (tp + fn) if (tp + fn) else 0.0 f1 = 2 * precision * recall / (precision + recall) if (precision + recall) else 0.0 return { "precision": precision, "recall": recall, "f1": f1, "tp": tp, "fp": fp, "tn": tn, "fn": fn, }这里的关键设计是：超时和崩溃样本不进入分类指标计算，而是由恢复模块单独统计。这样避免了“把故障误判为漏报”的经典错误。
4. 关键指标怎么算：从原始结果到可决策的数据
4.1 分类结果表和扫描失败事件
执行完评测之后，每条样本会落在一个状态里。常见状态包括正常判定、超时、崩溃、无效输出。建议把状态划分清楚，再分别计算指标。
| 状态 | 含义 | 对 F1 的影响 | 对覆盖率的影响 | 对恢复指标的影响 |
|---|---|---|---|---|
| ok | 返回了合法判定结果 | 参与计算 | 计入有效处理 | 不参与 |
| timeout | 超过配置时限未返回 | 不计入 | 不计入有效处理 | 作为故障事件 |
| crash | 进程崩溃或异常退出 | 不计入 | 不计入有效处理 | 作为故障事件 |
| invalid_output | 返回内容不符合 schema | 不计入 | 建议不计入 | 建议作为故障事件 |
无效输出容易被忽略。扫描器返回了文本，但文本不是block或pass，也没有置信度字段。这种情况如果直接解析失败并抛异常，会污染整个评测链路。比较好的做法是单独拦截，并给出明确报错信息。
4.2 覆盖率计算方式
在最小框架中，覆盖率可以拆成三个公式。
样本覆盖率表示所有评测样本中，扫描器有效处理的比例。公式为：
sample_coverage = 有效处理样本数 / 总样本数类别覆盖率表示产品要求支持的风险类别中，扫描器实际处理过的类别比例。公式为：
category_coverage = 有效处理过的类别数 / 产品要求支持的风险类别数输入形态覆盖率需要先把样本按输入形态分组，比如“短文本、长文本、结构化 JSON、特殊字符”，然后计算有效处理的分组比例。公式与类别覆盖率类似：
input_group_coverage = 有效处理过的输入形态分组数 / 全部输入形态分组数在实际项目中，如果某类样本完全缺失，应该先补样本，再谈覆盖率。不要为了覆盖率好看，刻意去掉困难类别。
4.3 恢复指标：MTTR、恢复成功率、重试成功率
恢复指标至少应该包含三个。
平均恢复时间（MTTR）表示从故障发生到系统恢复可用所消耗的平均时长。计算方式为：
MTTR = 所有故障恢复耗时之和 / 成功恢复的故障次数恢复成功率表示所有注入的故障中，最终成功恢复并健康检查通过的比例。计算方式为：
recovery_success_rate = 成功恢复次数 / 故障注入总次数重试成功率表示在配置的最大重试次数内，调用最终成功的比例。计算方式为：
retry_success_rate = 重试后成功的调用次数 / 初始失败但可重试的调用次数这三个指标回答的问题不同。MTTR 关注恢复快不快，恢复成功率关注恢复得稳不稳，重试成功率关注瞬时故障能不能被自动消化。
4.4 综合评分不要拍脑袋
不建议把 F1、覆盖率和恢复指标压缩成一个综合分。综合分会掩盖细节，比如覆盖率只有 0.4 但 F1 达到 0.99，综合分可能仍然很高，团队不容易发现问题。
更建议的做法是设置发布门禁。例如：
- 如果 F1 低于 0.9，禁止发布，先优化检测算法。
- 如果类别覆盖率低于 0.8，禁止发布，先补齐评测集和扫描器能力。
- 如果恢复成功率低于 0.9，禁止发布，先完善重试、熔断和重启机制。
- 如果 MTTR 超过业务容忍上限，禁止发布，先优化故障转移方案。
门禁阈值根据业务风险承受能力制定，没有统一标准，但一定要写清楚。
5. 跑通评测实验并解读结果
5.1 准备一个最小实验
为了验证框架，准备一个最小实验。数据集包含 50 个正常样本、20 个风险样本、5 个故障探针。风险样本覆盖三类风险，但产品需求中要求支持五类风险。这样的设计是为了让 F1 很高但覆盖率暴露问题。
| 数据集 | 样本数 | 说明 |
|---|---|---|
| normal.jsonl | 30 | 正常输入，期望 pass |
| risk.jsonl | 20 | 风险输入，覆盖 danger_a、danger_b、danger_c |
| failure_probe.jsonl | 5 | 其中 3 个 timeout，2 个 crash |
理论上，如果扫描器对现有风险样本判断准确，F1 会很高。但由于缺少 danger_d 和 danger_e 两类样本，类别覆盖率最高只有 0.6。
5.2 运行代码和预期输出
在项目根目录执行：
cd eval_ai_scanner python run_eval.py \ --cases-dir cases \ --failure-probe cases/failure_probe.jsonl \ --timeout 3.0 \ --max-retries 2框架会输出类似下面的报告。这里的作用是展示格式，不涉及真实扫描器数据，因此请忽略具体数值的含义。
Classification Metrics precision: 0.95 recall: 0.97 f1: 0.96 Coverage Metrics sample_coverage: 0.92 category_coverage: 0.60 covered_categories: danger_a, danger_b, danger_c Recovery Metrics failure_count: 5 recovery_success_rate: 0.80 mttr_seconds: 1.42 retry_success_rate: 0.90从结果看，F1 达到 0.96，看起来不错。但category_coverage只有 0.60，说明产品要求的五个风险类别里，有两个完全没有被有效处理。这个信号比 F1 更值得关注。
5.3 结果解读：为什么 F1 高但覆盖率低
F1 高通常意味着扫描器对“样本里出现过的正负类别”判断得不错。覆盖率低则说明“样本里没出现过的类别”可能完全没有检测能力，或者评测集中根本就没有这些类别的样本。
两种情况需要区别处置。
如果评测集缺少 danger_d 和 danger_e，那么问题出在评测集不完整，需要补充样本后重新评测。如果评测集存在这两个类别的样本，但扫描器全部超时或返回无效输出，那么问题出在扫描器适配层或类别映射逻辑。
最糟糕的处理方式是为了让覆盖率数字好看，把没有样本的类别从需求类别列表里删除。这会让覆盖率失去意义。
5.4 从结果反推配置问题
覆盖率下降并不一定是扫描器算法差，也可能是配置问题。常见的反推路径如下。
超时配置过短会导致大量 timeout，样本覆盖率和恢复指标都会受影响。建议先检查扫描器在正常负载下的 p99 耗时，再把评测超时时间设置为该值的 2 到 3 倍。
类别映射缺失会导致扫描器返回unknown，被记为无效输出，从而拉低覆盖率。检查扫描器返回的类别列表和评测标签是否对齐。
重试次数设置不合理会导致瞬时故障无法恢复。如果日志显示大量第一次调用失败、第二次成功，说明重试机制是有效的；如果重试后仍然失败，再考虑熔断和降级。
6. 常见问题排查：覆盖率虚高、恢复失效、评测不稳定
6.1 覆盖率虚高
覆盖率虚高是评测中最常见的问题。现象是上报的覆盖率很高，但真实流量中扫描器仍然频繁“接不住”。
产生虚高主要有两个原因。第一个原因是评测集过于简单，所有样本都来自同一模板，扫描器只需要记住模板就能通过。第二个原因是对“有效处理”的定义太宽松，把返回空值、返回未知类别、兜底成功都当成有效处理。
检查方式有两个方向。一个是随机抽样评测集，确认风险类别的多样性；另一个是查看原始结果，确认是否存在大量unknown或默认pass被错误标记为 ok。
处理建议：评测集必须包含难度梯度；无效输出必须单独标记；覆盖率定义必须写明“返回合法判定结果才算有效处理”。
| 问题现象 | 常见原因 | 检查方式 | 处理建议 |
|---|---|---|---|
| 覆盖率虚高 | 评测集模板化；有效处理定义过宽 | 随机抽样检查多样性；统计 unknown 输出 | 增加难度梯度；严格定义有效处理 |
| 恢复测试无效 | 故障注入没有触发异常；健康检查用例太简单 | 查看故障日志；确认异常类型 | 使用受控故障注入；增强健康检查断言 |
| 评测不可复现 | 依赖版本、随机种子、超时配置不一致 | 记录环境指纹；固定配置 | 使用 CI 固定环境；固定随机种子 |
6.2 故障恢复测试无效
故障恢复测试无效通常表现为：报告里恢复成功率是 100%，但线上扫描器一崩溃就不可用。
排查时先看故障是否真的被注入了。如果inject_failure字段没有在适配器里被处理，执行时根本不会抛异常，恢复指标自然全是成功。检查方式是在故障探针执行前后打印日志，确认异常确实发生。
再看健康检查用例是否有判断力。如果健康检查只调用了一个pass样本，扫描器即使内部状态已经损坏，也可能返回兜底结果。健康检查应该覆盖核心分类能力，并且对返回结构做严格校验。
6.3 评测结果不可复现
评测结果不可复现通常是因为环境不一致。今天跑出来 F1 是 0.96，明天变成 0.88，但代码没有变化。
优先检查随机种子。如果评测集从全量数据中采样，不固定随机种子，每次跑出的数据集都不一样。如果扫描器内部有阈值抖动或采样逻辑，也必须有可重复性设置。
建议在评测入口记录环境指纹，包括 Python 版本、依赖包版本、数据集文件哈希、扫描器 commit 号。这样可以快速定位“结果变了”是因为代码变了，还是环境变了。
7. 生产环境评估的最佳实践与检查清单
7.1 学习环境、测试环境、生产环境的评估差异
学习环境里，用小规模数据集跑通评测框架，重点是理解指标含义。测试环境里，用接近真实的样本库评估 F1 和覆盖率，并通过故障注入验证恢复机制。生产环境里，不能直接拿全部线上流量做全量扫描评估，应该采用灰度测试、影子模式、逐步扩大流量比例的方式。
生产环境额外要做三件事。一是把评测脚本接入 CI，扫描器每次发布前自动跑回归。二是在线监控扫描器的超时率、崩溃率、无效输出率，这些指标应该和覆盖率、恢复指标关联观察。三是保留历史评测报告，方便做趋势分析和回滚决策。
7.2 可复用清单：AI 模型安全扫描器评测清单
上线之前，按下面的清单逐项确认，比单纯看 F1 数字更可靠。
- 评测集是否覆盖了产品要求支持的所有风险类别？
- 评测集中是否包含困难样本、异常输入、超时探针？
- 每个样本是否记录了预期的判定结果和类别标签？
- 扫描器返回
unknown、空值、异常时，是否单独归类？ - 超时时间、重试次数、并发度是否统一配置并记录？
- 是否单独统计了超时、崩溃、无效输出事件？
- 故障注入后，是否使用健康检查用例验证恢复？
- 是否记录了数据集版本、扫描器 commit、依赖版本、随机种子？
- 是否存在发布门禁，且门禁条件覆盖 F1、覆盖率、恢复指标？
这个清单可以在每次评测前十分钟内过完，能够拦截大多数“F1 好看但上线不稳定”的问题。
7.3 后续扩展：持续评估、回归守护、模型漂移
把覆盖率纳入评测只是第一步。更进一步的实践是建立持续评估机制，让安全扫描器的质量不是一次性检查，而是长期可观测。
一个推荐的做法是每周从线上流量中抽样，人工标注后加入评测集，并重新计算覆盖率。新风险类别出现时，先补样本，再评估扫描器是否能够识别。模型版本升级时，也要重新跑一次评测，因为同样的输入在不同模型上的行为可能不同，扫描器的表现会跟着变化。
回归守护可以放在 CI 里，每次扫描器依赖变化或代码变化时自动运行最小评测集，防止“改一个依赖，结果全变”的情况出现。
所以，下次看到某个 AI 模型安全扫描器报出很高的 F1 时，先不要急着上线。补充问一句：数据覆盖面是什么？故障后能不能自己恢复？如果这两个问题答不上来，再高的分数也只能说明它在“已知且能处理的样本”上表现不错。把评价体系从 F1 扩展到 Coverage 和 Failure Recovery，才是把安全扫描器真正工程化的第一步。
