企业官网建设流程全解析

在评估AI模型安全扫描器时，如果只盯着F1分数，你很可能被一份好看的报告骗了。先说明一下，这里讨论的F1是机器学习里的F1-Score，也就是Precision和Recall的调和平均，不是键盘上那个需要按Fn才能触发的功能键。很多团队在选型模型安全扫描器时，习惯用F1判断“好不好用”，但安全扫描这个场景里，F1最多只回答了“检测准不准”，完全没有回答“该扫的东西扫到了没有”和“扫描器自己挂了怎么办”这两个更致命的问题。两个F1同为0.95的扫描器，一个可能覆盖了绝大多数攻击类型，另一个可能对某类投毒方式接近失明，甚至在扫描大模型文件时频繁OOM。换到真实上线环节，它们的表现会迅速拉开差距。

本文要讨论的是AI模型安全扫描器评估中容易被忽视的两个维度：覆盖率（Coverage）与故障恢复（Failure Recovery）。我会从F1指标的局限性讲起，然后给出一套可以落地的评估框架，包括覆盖率量化代码、故障注入测试脚本和恢复验证方法。如果你正在选型模型安全扫描器，或者正在建设团队内部的AI安全评测体系，这篇文章可以当作一份评估清单来用。

1. 这篇文章真正要解决的问题

AI模型安全扫描器，简单说就是用来检查模型文件、模型训练流程和推理服务是否存在安全风险的自动化工具。常见的检测对象包括：模型是否被投毒、是否被植入后门、是否对对抗样本缺乏鲁棒性、输出内容是否容易被诱导产生有害结果，以及模型依赖的第三方组件是否存在漏洞。随着生成式AI和开源模型大量进入业务系统，这类扫描器正从“可选工具”变成“上线前合规检查”的基础设施。

但问题在于，很多扫描器在演示环境看起来很强，一进真实业务就暴露出明显的盲区和脆弱性。我从大量真实项目中观察到的共性是：评估体系过于依赖F1，导致团队在选型时被“检测准确率”带偏，忽略了扫描器到底覆盖了多少攻击面，以及扫描器在异常情况下能否自愈。一个很典型的场景是，某扫描器在基准数据集上Recall达到92%，但对特定框架导出的模型文件完全没有解析能力，遇到这种文件会直接跳到“未检测到风险”。F1不会告诉你这些，覆盖率会。

读完这篇文章，你会得到三样东西：

• 一套比F1更完整的评估视角，知道Coverage和Failure Recovery分别解决什么问题；
• 一组可以直接复制运行的Python和Shell示例，用于计算覆盖率、进行故障注入和验证恢复；
• 一套落地建议，帮助你把“扫描器评估”从一次性的分数对比，变成可持续的评测机制。

2. 基础概念与核心原理

2.1 F1到底在衡量什么

F1的核心定义很简洁：

• 精确率（Precision）：在扫描器判为风险的所有样本中，真正有风险的样本占比；
• 召回率（Recall）：在所有真正有风险的样本中，扫描器成功找出来的样本占比；
• F1是两者的调和平均：F1 = 2 x Precision x Recall / (Precision + Recall)。

它用一个数字综合了误报和漏报两个方向的代价，适合分类任务的整体效果对比。但请注意，F1是在一个“给定的、已经标注好的测试集”上计算的。它衡量的是扫描器在这个静态测试集上的检测能力，而不是在真实动态威胁环境下的能力。安全扫描器面对的攻击类型是持续演变的，测试集覆盖面不足时，再高的F1也没有代表性。

2.2 为什么安全扫描场景需要超越F1

安全扫描场景与普通分类任务有几个显著差异，这些差异决定了只看F1会得出错误结论。

第一，类别极度不均衡。真实模型仓库中，恶意模型样本数量远少于良性样本。扫描器很容易通过“什么都报告为安全”获得很高的准确率，但这时Recall会很低。F1虽然能揭示部分问题，但很多人只看分数不看构成。

第二，漏报和误报的代价不对称。在分类任务里，误报和漏报可能同样影响用户体验。但在模型安全上线场景里，漏掉一个带后门的模型，可能意味着整个业务流程被外部控制；而误报一个良性模型，可能只是增加人工复核成本。F1把两者视为同等权重，没有体现安全场景的真实风险偏好。

第三，F1不衡量扫描范围。扫描器报告高F1，可能仅仅是因为它对测试集里出现过的攻击类型很敏感，而面对测试集之外的攻击变种，能力几乎为零。这里的差距，需要覆盖率指标来体现。

第四，F1不衡量扫描器自身可靠性。扫描器是一个软件系统，会崩溃、会超时、会因资源耗尽卡死。一个F1很高但每秒只能扫两个文件、一遇到大模型就崩溃的扫描器，在工程上基本不可用。

2.3 Coverage：扫描器到底覆盖了多少风险面

覆盖率是一个能力范围的度量，具体在AI模型安全扫描器中，我建议从四个层面理解。

• 样本覆盖率：在给定的有效测试样本集中，扫描器成功完成扫描并且给出有效结果的样本占比。如果大量样本扫描超时、报错或跳过，样本覆盖率就会下降。
• 攻击类型覆盖率：扫描器能够有效识别的攻击类型占已知攻击类型总数的比例。比如已知的后门攻击、数据投毒、对抗样本攻击、模型窃取、越狱提示词等，扫描器支持哪些，各支持到什么程度。
• 模型格式覆盖率：扫描器能正常解析和检测的模型格式数量，比如常见的TensorFlow、PyTorch、ONNX、Safetensors等格式是否都支持，以及对不同格式的解析是否稳定。
• 行为场景覆盖率：扫描器在训练前、训练中、上线后、推理时这些不同阶段，是否都能发挥作用。有的扫描器只覆盖离线检测，无法覆盖推理期实时监测。

可以类比成一次消防检查：F1相当于“报警器对烟雾是否敏感”，覆盖率相当于“报警器装了多少个房间、覆盖了哪些火灾风险点”。前者再准，如果只装在会议室，厨房起火它照样不知道。

2.4 Failure Recovery：扫描器挂了以后能不能自愈

故障恢复能力是指扫描服务在遭受异常之后，能否自动恢复到一个可用状态，并尽可能不丢失已经完成的扫描进度。

我在评估扫描器稳定性时，主要关注四个能力：

• 崩溃恢复：进程因超时、内存溢出、未知输入崩溃后，能否由守护进程或编排系统自动拉起。
• 任务续跑：崩溃前正在执行的大模型扫描任务，能否从断点恢复，或者至少重新排队，而不是静默丢失。
• 超时降级：面对超大模型或异常样本，能否主动降级、做局部扫描或返回可解释的“超时”，而不是无限卡死。
• 数据一致性：恢复后，已经生成的检测结果、审计日志、告警记录是否完整。

工程上通常用两个量化指标衡量故障恢复：

• RTO（Recovery Time Objective）：从故障发生到服务恢复可用，最长可接受的时间。
• RPO（Recovery Point Objective）：故障发生时可以容忍丢失的数据量，在扫描场景中可以理解为允许丢失的已扫描进度。

这里要强调，故障恢复能力测试必须在隔离环境、测试授权范围内进行，绝不能直接在生产环境做崩溃注入。后面给出的示例脚本，都建议先在临时沙箱里验证。

3. 从“分数”到“能力”：评估框架设计

要真正把Coverage和Failure Recovery纳入评估，第一步是设计一套结构化指标。我建议把评估维度分成三层：检测能力、覆盖能力、稳定与恢复能力。

检测能力层，继续使用Precision、Recall、F1、AUC这些分类指标。它们不是没用，而是作为能力基线存在。任何一个扫描器，先要证明它在标准测试集上具备基本检测能力。

覆盖能力层，使用样本覆盖率、攻击类型覆盖率、模型格式覆盖率、行为场景覆盖率。这一层回答“能扫的范围有多大”。

稳定与恢复能力层，使用任务成功率、平均扫描耗时、崩溃次数、恢复成功率、平均恢复时间、数据丢失率。这一层回答“在真实负载下到底可不可靠”。

测试集建设是整个评估框架里最耗时的一环。没有标注准确、结构清晰的恶意样本库，覆盖率指标就是空中楼阁。从实践看，一个可用的模型安全测试集至少包含三类样本：

• 公开的恶意模型样本或开源攻击工具生成的样本，需要在隔离环境中生成，防止样本扩散；
• 由安全团队根据业务模型定制构造的投毒、后门、对抗样本；
• 大量良性模型样本，用于检验误报率和扫描稳定性。

在建设过程中要注意合规性。如果测试样本来自真实业务，就需要完成脱敏处理，不能把含敏感信息的模型文件随意复制到外部评测环境。

有了测试集和指标定义，评估流程可以按三步进行：

1. 基线评估：在标准测试集上运行扫描器，记录F1、样本覆盖率、攻击类型覆盖率、模型格式覆盖率；
2. 故障演练：注入进程崩溃、网络抖动、资源限制、超时等故障，观察扫描服务能否自动恢复；
3. 回归评测：定期重复前两步，观察指标趋势，确认新版本没有引入能力回退。

4. 覆盖率量化：一个可落地的Python示例

覆盖率计算并不复杂，难的是确定“有效样本”的边界。下面用一个Python脚本演示如何从扫描结果文件聚合覆盖率指标。这个脚本不依赖某个具体扫描器，只假设扫描结果会被统一输出成JSON Lines格式。

首先定义一种结果格式。一行JSON代表一个样本的扫描结论：

{"sample_id": "attack-001", "attack_type": "backdoor", "model_format": "onnx", "is_malicious": true, "detected": true, "scan_ok": true, "time_ms": 1820} {"sample_id": "attack-002", "attack_type": "data_poisoning", "model_format": "tensorflow", "is_malicious": true, "detected": false, "scan_ok": true, "time_ms": 2540} {"sample_id": "normal-001", "attack_type": "none", "model_format": "pytorch", "is_malicious": false, "detected": false, "scan_ok": true, "time_ms": 1350}

在这个格式里：

• scan_ok表示扫描器是否成功完成对该样本的扫描；
• detected表示扫描器是否判定该样本为恶意；
• is_malicious表示样本的真实标注。

然后写一个聚合统计脚本：

# 文件路径：examples/coverage_metrics.py import json from collections import Counter, defaultdict SUPPORTED_FORMATS = {"tensorflow", "pytorch", "onnx", "safetensors"} KNOWN_ATTACK_TYPES = { "backdoor", "data_poisoning", "adversarial_patch", "model_inversion", "prompt_injection" } def load_results(file_path): results = [] with open(file_path, "r", encoding="utf-8") as f: for line in f: line = line.strip() if not line: continue results.append(json.loads(line)) return results def compute_coverage(results): total_valid = len(results) scanned_ok = [r for r in results if r.get("scan_ok", False)] sample_coverage = len(scanned_ok) / total_valid if total_valid else 0.0 detected_attack_types = set() for r in scanned_ok: if r.get("is_malicious") and r.get("detected"): detected_attack_types.add(r.get("attack_type", "unknown")) if KNOWN_ATTACK_TYPES: attack_type_coverage = len(detected_attack_types) / len(KNOWN_ATTACK_TYPES) else: attack_type_coverage = 0.0 format_counter = Counter() success_counter = Counter() for r in results: fmt = r.get("model_format", "unknown") format_counter[fmt] += 1 if r.get("scan_ok"): success_counter[fmt] += 1 format_detail = {} for fmt in SUPPORTED_FORMATS: total_fmt = format_counter.get(fmt, 0) ok_fmt = success_counter.get(fmt, 0) format_detail[fmt] = { "total": total_fmt, "scan_ok": ok_fmt, "format_sample_coverage": ok_fmt / total_fmt if total_fmt else 0.0 } supported_with_samples = [fmt for fmt in SUPPORTED_FORMATS if format_counter.get(fmt, 0) > 0] format_coverage = len(supported_with_samples) / len(SUPPORTED_FORMATS) if SUPPORTED_FORMATS else 0.0 return { "sample_coverage": round(sample_coverage, 4), "attack_type_coverage": round(attack_type_coverage, 4), "format_coverage": round(format_coverage, 4), "format_detail": format_detail } if __name__ == "__main__": import sys file_path = sys.argv[1] if len(sys.argv) > 1 else "scan_results.jsonl" stats = compute_coverage(load_results(file_path)) print(json.dumps(stats, ensure_ascii=False, indent=2))

这个脚本的核心逻辑有三个：

• sample_coverage统计的是“成功完成扫描的样本比例”，体现扫描过程有没有大量跳过和超时；
• attack_type_coverage关注“检测能力覆盖了多少已知攻击类型”，即使某个攻击类型只有一个样本被检出，也认为该类型没有被盲区覆盖；
• format_coverage统计的是“在当前测试集中，被成功扫描的模型格式占支持格式的比例”，用来看解析器是否稳定。

运行方式很简单：

python examples/coverage_metrics.py scan_results.jsonl

预期输出类似这样：

{ "sample_coverage": 0.96, "attack_type_coverage": 0.8, "format_coverage": 0.75, "format_detail": { "tensorflow": {"total": 12, "scan_ok": 12, "format_sample_coverage": 1.0}, "pytorch": {"total": 10, "scan_ok": 10, "format_sample_coverage": 1.0}, "onnx": {"total": 10, "scan_ok": 9, "format_sample_coverage": 0.9}, "safetensors": {"total": 4, "scan_ok": 0, "format_sample_coverage": 0.0} } }

如果看到这种结果，就需要警惕：虽然F1可能不低，但攻击类型覆盖率只有80%，Safetensors格式完全无法解析。这个扫描器显然不适合放在大量使用Safetensors模型的业务线上。

这里真正容易踩坑的地方在于，不同团队对“攻击类型”的划分标准不一致。比如对抗样本，有的团队细分为FGSM、PGD、CW等十几种，有的团队只算一种。划分粒度不同，覆盖率数值就没有可比性。所以，覆盖率数据必须和攻击类型清单一起发布，否则孤立的数值没有意义。

5. 故障恢复测试：从故障注入到自动验证

F1和覆盖率都能通过静态测试集完成，但故障恢复能力必须通过主动制造故障来验证。下面给出一个相对通用的故障注入流程，适用于以本地服务方式运行的扫描器。

5.1 故障注入脚本示例

假设扫描器对外暴露了一个健康检查接口，例如/healthz，并且由systemd负责自动拉起。那么可以做一次最简单的崩溃恢复测试：

#!/usr/bin/env bash # 文件路径：scripts/fault_injection_test.sh set -euo pipefail SERVICE_NAME=${1:-ai-scanner} HEALTH_URL=${2:-http://127.0.0.1:8900/healthz} TIMEOUT_SECONDS=${3:-120} echo "[1/4] 确认扫描服务当前健康状态" curl -fsS "$HEALTH_URL" || { echo "服务当前不可用，无法开始故障注入"; exit 1; } echo "[2/4] 记录当前扫描器进程PID" SCANNER_PID=$(pgrep -f "ai-scanner-server" | head -n 1) if [ -z "$SCANNER_PID" ]; then echo "未找到扫描器进程，请检查进程匹配规则" exit 1 fi echo "scanner pid: $SCANNER_PID" echo "[3/4] 发送SIGKILL模拟进程崩溃" kill -9 "$SCANNER_PID" echo "已发送SIGKILL，等待systemd自动拉起..." echo "[4/4] 轮询健康检查接口，等待服务恢复" START_TIME=$(date +%s) RECOVERED=false while [ $(( $(date +%s) - START_TIME )) -lt "$TIMEOUT_SECONDS" ]; do if curl -fsS "$HEALTH_URL" > /dev/null 2>&1; then END_TIME=$(date +%s) RECOVERY_SECONDS=$(( END_TIME - START_TIME )) echo "服务已恢复，恢复耗时约 ${RECOVERY_SECONDS} 秒" RECOVERED=true break fi sleep 1 done if [ "$RECOVERED" = false ]; then echo "服务在 ${TIMEOUT_SECONDS} 秒内未恢复，测试失败" exit 1 fi

这个脚本的思路很直白：先确认服务健康，再找到关键进程，发送kill -9模拟最严重的崩溃，最后轮询健康检查接口。注意脚本中pgrep -f "ai-scanner-server"这一句需要根据实际进程名调整，不能在未确认进程规则的情况下直接照搬。

5.2 恢复结果自动记录脚本

上面的脚本只输出了恢复耗时，如果要做回归对比，最好把每次故障演练的结果落盘。下面这个Python脚本负责记录故障注入前后的关键指标：

# 文件路径：tools/recovery_check.py import json import time import argparse from urllib.request import urlopen, Request from urllib.error import URLError def check_health(url, timeout=3): req = Request(url, headers={"User-Agent": "recovery-check"}) try: with urlopen(req, timeout=timeout) as resp: return resp.status == 200 except (URLError, TimeoutError): return False def main(): parser = argparse.ArgumentParser(description="扫描器恢复检查器") parser.add_argument("--health-url", default="http://127.0.0.1:8900/healthz") parser.add_argument("--interval", type=float, default=1.0) parser.add_argument("--timeout", type=int, default=120) parser.add_argument("--output", default="recovery_report.json") args = parser.parse_args() crash_start = time.time() total_downtime = 0.0 recovered = False while time.time() - crash_start < args.timeout: if check_health(args.health_url): total_downtime = time.time() - crash_start recovered = True break time.sleep(args.interval) if not recovered: total_downtime = args.timeout report = { "timestamp": time.strftime("%Y-%m-%dT%H:%M:%S%z"), "health_url": args.health_url, "recovered": recovered, "downtime_seconds": round(total_downtime, 2), "rto_seconds_alias": round(total_downtime, 2) } with open(args.output, "w", encoding="utf-8") as f: json.dump(report, f, ensure_ascii=False, indent=2) print(json.dumps(report, ensure_ascii=False, indent=2)) if not recovered: raise SystemExit(1) if __name__ == "__main__": main()

这个脚本对最常见的“健康检查恢复”做了量化。通过多次故障演练，可以统计出平均恢复时间、恢复成功率等指标，再加入监控系统的告警曲线。

5.3 进阶故障场景

除了kill -9，故障注入还可以覆盖更接近真实生产的问题：

• 网络抖动：使用流量控制工具模拟丢包、延迟，观察扫描任务是否会重试；
• 资源耗尽：用容器或systemd限制内存，观察扫描大模型时是否OOM，以及OOM后是否自动退出重启；
• 无效输入：往扫描接口提交损坏的模型文件、超大文件、空文件、非模型格式文件，观察扫描器会不会抛异常甚至卡死；
• 磁盘写满：在沙箱环境中用临时文件占满磁盘，观察日志和结果能否落盘。

每种故障类型都要单独记录“是否自愈”“是否丢任务”“是否产生脏数据”。这些结果汇总起来，才是对故障恢复能力的完整回答。如果只是在演示环境跑一遍健康检查，很难发现真实故障下的恢复短板。

6. 如何判断扫描真的成功：验证与预期输出

很多团队在做扫描器评估时，只看报告里那一行F1，却不问报告本身是怎么生成的。这里有一个关键区别需要区分：扫描完成不等于检测正确，检测正确不等于扫描器可靠。我们需要一套明确的判定标准。

一次“合格”的评估至少需要同时满足三个条件：

• 覆盖率达标：有效样本的扫描完成率高于约定阈值，比如95%以上；
• 检测能力达标：在“扫描成功”的样本上计算F1，排除掉那些因为扫描器报错而跳过的样本；
• 恢复能力达标：在故障注入后，服务能在约定RTO内恢复，并且不丢失审计日志和已完成结果。

下面是一份示意性的评估报告JSON。它把检测、覆盖率、恢复三部分分开呈现，避免只用F1掩盖问题：

{ "scanner_id": "ai-scanner-demo", "assessment_round": "2025-07", "detection": { "precision": 0.96, "recall": 0.91, "f1": 0.934, "base_dataset": "internal-model-security-v3" }, "coverage": { "sample_coverage": 0.95, "attack_type_coverage": 0.78, "format_coverage": 0.75, "skipped_samples": 12 }, "recovery": { "crash_count": 3, "recovery_rate": 0.67, "avg_rto_seconds": 18.5, "max_rto_seconds": 47.3, "data_loss_rate": 0.0 } }

在这个示例里，F1有0.93，看起来不错，但恢复成功率只有67%，说明三次崩溃中有一次没有自动恢复。攻击类型覆盖率只有78%，说明有三个已知攻击类型没有有效检出能力。如果团队只看F1选型，后面上线时会频繁遇到卡死和漏检。

要运行这样一份评估，工程流程可以分成四步：

1. 准备测试环境和测试集，确保所有样本已经在隔离沙箱中完成恶意性标注；
2. 运行覆盖率统计脚本，得到样本覆盖率、攻击类型覆盖率和格式覆盖率；
3. 执行故障注入脚本和恢复检查脚本，得到恢复时间与恢复率；
4. 汇总所有指标，生成统一格式的评估报告，并和上一轮结果做对比。

如果任何一步失败，先不要急着下结论。最常见的问题是测试集标注不准确，导致恶意样本被标记为良性，或良性样本被误标记为恶意。这种情况下，F1和覆盖率都会失真。所以，评估报告里最好附带样本清单版本和标注说明，方便回溯。

7. 常见问题与排查思路

把这几套指标落到实际项目中，会遇到不少问题。下面用表格整理高频问题，方便遇到时快速定位。

在这些问题中，最容易被忽视的是“无效输入导致卡死”。很多扫描器在正常样本上表现出色，一旦遇到一个格式损坏但扩展名正常的模型文件，就可能陷入死循环或内存暴涨。评估时建议专门准备一批非法样本，测试扫描器的容错上限。

此外，故障注入类的测试建议做成一个独立测试套件，而不是临时手工操作。因为只有可重复的故障演练，才能形成有效的回归指标。通过持续集成定期执行，可以尽早发现新版本引入的稳定性回退。

8. 最佳实践与工程建议

8.1 建立基线与回归机制

不要用一次评测结果给扫描器“判死刑”，也不要因为一次评测通过就放松后续关注。正确做法是建立基线版本，每次扫描器升级、攻击样本库更新、模型格式新增时，都重新跑一遍完整评估，并对比F1、覆盖率、恢复指标的变化。只有基线稳定，后续调优才有参照。

8.2 维护可更新的攻击样本库

覆盖率指标的可信度完全依赖样本库。建议把攻击样本库当代码一样管理，记录版本、来源、标注人、验证结果。每隔一段时间引入新的攻击样本，避免扫描器在固定样本集上过拟合。样本库更新后，要同步更新覆盖率指标，不能让旧指标一直挂在报告里。

8.3 把故障演练融入持续集成

故障恢复不是上线前演练一次就结束的功能。每次代码变更都可能影响异常处理逻辑、资源清理逻辑或任务队列行为。建议把轻量级的故障注入测试加入CI流程，每次提交后自动执行一次进程崩溃恢复测试。重量级的资源耗尽测试可以放到夜间构建或独立流水线中。

8.4 监控与告警

所有恢复指标最终都要落到运行时监控。扫描服务的健康检查、任务积压数、处理耗时、崩溃次数、OOM次数应该全部上报监控系统。设置告警规则时，不仅要盯“服务挂了”，还要盯“服务没挂但任务一直不推进”这类容易被忽略的问题。

8.5 安全边界与最小权限

AI模型安全扫描器本身就有较高权限，因为它要解析模型文件、执行检测逻辑、访问样本库。务必遵守最小权限原则：

• 扫描器运行在独立沙箱或容器中，不能直接访问生产模型仓库；
• 恶意样本的存储和传输要加密，处理完后及时清理；
• 扫描指令和测试脚本必须经过评审，避免把恶意样本带出隔离环境；
• 故障注入脚本默认只在测试环境执行，并增加明显的环境检查。

8.6 报告标准化

建议所有评估报告统一包含三个区块：检测能力（F1、Precision、Recall）、覆盖率（样本覆盖率、攻击类型覆盖率、格式覆盖率）、恢复能力（恢复成功率、平均恢复时间、数据丢失率）。报告还要写明测试集版本、运行环境、执行时间，保证他人可以复现。

9. 总结与后续方向

回到标题：为什么要超越F1?因为F1回答的是“检测准不准”，而AI模型安全扫描器能否在真实业务中发挥作用，还取决于它“扫描范围广不广”和“自身稳不稳”。覆盖率把静态测试里的检测能力映射到真实攻击面，故障恢复则把扫描器从“一个算法模型”重新拉回到“一个需要长期稳定运行的服务系统”。

如果你正在做AI模型安全扫描器的选型或评测，建议从下一份评估报告开始，同时关注三组数字：F1、覆盖率、恢复成功率。这三组数字合在一起，才勉强算得上一份可信的扫描器体检报告。推荐的做法是先把本文的覆盖率脚本和故障注入脚本跑通，建立你自己的基线数据，再根据业务模型格式和攻击类型，逐步完善测试集。后续值得深入的方向包括自动化生成对抗样本、扫描结果可解释性、多扫描器横向对比，以及把评估能力做成平台化的工具，让每次模型上线前的安全检查都有据可依。