把 MAI-Cyber-1-Flash 放进告警流程之前，先明确一件事：模型做的是「读字段、提证据、给初判标签」，人做的是「定性质、定处置、定对外口径」。误报率不是一个可以整体评估的数字，它按规则类型分布：单条日志就能定性的告警，模型初筛相对可靠；需要跨 EDR、认证、流量三四个系统才能拼出事实的告警，模型给的标签只能当线索。可行的顺序是先用近两周已有人工判定的告警做基线，按规则名切出「可初筛」和「必须人工」两类，再用历史回放逐条核对，最后才决定哪些规则允许模型改工单状态。

建议把 MAI-Cyber-1-Flash 放在「读原始字段、输出初判标签和证据指针」这一环，不放在「关单和对外定性」这一环。先按规则名和人工结论抽样近两周告警，把单数据源可判定的类型交模型，跨系统关联、涉及核心资产、证据不足的留在人工。误报率只能按规则逐条回放核对，不能用一个整体数字代替；上线初期模型结论只写评论、不改工单状态，人工复核开关保留。

按规则名和处置结果抽样近两周告警

这一步的目的是建立模型介入前的现状基线。没有「人工判定结论」这个字段，后面算不了误报，也算不了漏报，所以先确认 SIEM 或工单系统里是否存了处置结论和关单时间。抽样维度至少要覆盖四列：来源设备、规则名、人工判定结论（真实事件／误报／待定）、处置耗时。高频规则和高危规则都要取，不能只按条数排序取前几名，高危规则往往条数少但判定价值高。

-- 字段名按实际表结构替换，时间窗按日志留存调整
SELECT alert_id, src_device, rule_name, severity, asset_tag,
       human_verdict, handle_seconds, closed_at
FROM   alerts
WHERE  created_at >= now() - interval '14 days'
  AND  human_verdict IS NOT NULL
ORDER  BY rule_name, created_at;

导出后按 rule_name 分组，看每条规则下人工结论的分布和处置耗时中位数。处置耗时长的规则通常不是模型能直接替代的，而是缺上下文；这类规则优先补日志而不是交给模型。判定结论为「待定」的比例也要单独看，待定多说明规则描述本身含糊，模型再准也无法对齐。

逐类标注判定一条告警要跨几个系统

分类的判断方法很土但有效：写下「要回答哪几个问题才能给这条告警定性」，一个问题的答案来自一个系统，就记一个数据源。单条日志即可定性的类型可以先交模型；需要三个以上系统交叉印证的，模型输出只作线索整理。

表格里出现「部分可」的类型，处理方式是让模型只输出「需要哪些补充字段」，不输出最终定性。这样人工复核拿到的是一份待补清单，而不是一个可能误导处置的标签。

给模型输入划定字段白名单与脱敏范围

告警原文里常混着口令参数、Cookie、完整内网地址和员工信息。不要整条 JSON 直接送出去，先在采集侧按白名单裁剪，再对必须保留的字段做脱敏，最后在日志里留一份实际送出的 payload 便于回溯。

• 字段白名单：告警 ID、规则名与规则描述、设备类型、粗化到分钟的时间戳、进程名与父进程、文件哈希、命令行（脱敏后）、URI 路径与 HTTP 方法、状态码、DNS 查询名、发件域、用户标识（哈希或工号映射值）。
• 必须脱敏项：命令行中的 -p、`--password`、token 参数值，Authorization 与 Cookie 头，邮箱正文，完整内网 IP（按网段或掩码替代），手机号与证件号。
• 明确不送出的字段：账号口令与密钥、完整流量包、终端截图、员工个人信息明细、资产台账拓扑、其他业务线数据。

{
  "alert_id": "<占位>",
  "rule_name": "<占位>",
  "device": "edr|waf|ids",
  "ts_minute": "<粗化时间>",
  "process": {"name": "...", "parent": "...", "cmdline_masked": "..."},
  "network": {"uri": "...", "method": "...", "status": 0, "dns": "..."},
  "asset_tag": "<业务等级，不含主机名清单>"
}

同时约定输出结构：模型必须给出 verdict（真实／可疑／误报／证据不足）、引用的字段名、不确定点。任何引用了白名单之外字段的输出都视为不可用，这一条可以直接写成校验规则，用日志里的 payload 与输出做比对。

你是告警初筛助手。只能基于输入 JSON 中的字段判断，不得推测未提供的信息。
输出 JSON：{"verdict":"malicious|suspicious|benign|insufficient","evidence":["字段名"],"unknown":["缺失信息"]}
若命令行、路径或进程链不足以定性，verdict 必须为 insufficient。

写清人工复核的三个触发条件

触发条件要写成工单字段的必填校验，而不是靠值班同学记。任何一条命中，模型结论只能作为附件，不能直接把工单置为关闭。

三条之外，建议再保留一个兜底判断条件：人工对模型结论存疑时可以直接推翻，且推翻记录要能按规则名统计。这类记录是后续调整分工表最直接的输入。

用历史告警回放核对初筛结论

回放的作用是验证分工表站不站得住。样本按规则分层抽取，单条规则样本太少时不要下结论；更关键的是必须包含已知真实事件对应的告警，只抽已关单的误报样本，只能验证误报，验证不了漏报。样本量按存量决定，单条规则建议先取能覆盖各处置结论的条数，再逐步扩。

alert_id,rule_name,asset_tag,human_verdict,model_verdict,evidence_match,diff_reason,action,owner
<占位>,<占位>,<占位>,true_positive|false_positive|pending,malicious|suspicious|benign|insufficient,yes|no,<说明>,keep|manual_only|fix_fields,<处理人>

回放后回收三类规则：人工结论正确而模型判为 benign 的规则，不进自动初筛；evidence_match 为 no 的规则，先补白名单字段；涉及核心资产但模型常给确定结论的规则，强制走人工复核。判断依据只看回放记录本身，不看单次演示效果。

上线节奏建议先跑影子模式：模型结论只写工单评论，不改变状态与优先级，人工按原流程处置，两边结论都留档。运行一段时间后，只对回放中稳定、字段完整、不涉及核心资产的规则开放「合并同类告警」或「降为低优先级」这类可逆动作，关单和对外定性仍然留在人工手里。