LLM红队结果如何转成修复计划?

红队测试跑完，拿到一份满是告警的报告，接下来的动作往往决定这次测试的价值。告警本身只是线索，真正的产出是那份可执行的修复计划。从 LLM 红队结果到修复计划，中间隔着三道工序：去伪存真、风险定级、责任到人。

第一步是过滤噪声。以 Garak 这类扫描器为例，detector 标记的 hit 只代表输出符合了某种判定模式，可能是真问题，也可能是误判，还可能是模型在压力下产生的无意义输出。逐条确认每一条告警，回到原始记录，取出完整的提示、回答和参数配置，单独重放至少一次。重放结果不稳定，说明这条告警对采样敏感，应标注为未复现而不是直接升级为风险。只有稳定复现的条目，才值得进入下一步。这一步最耗时，也最容易被跳过，但跳过它的代价是修复团队把时间浪费在无法复现的幽灵问题上。

第二步是把可复现的问题放回业务上下文定级。同样一段越狱输出，在内部问答助手和面向公众、回答会被自动执行的应用里，后果完全不同。定级需要同时考虑两个维度：利用难度和影响范围。利用难度看的是触发条件是否苛刻、是否需要特定输入序列；影响范围看的是输出是否进入下游系统、是否涉及敏感数据、是否影响其他用户。两个维度都高的条目排在最前面，作为 P0 处理；利用难度高但影响有限的，可以降级为常规修复。这里要明确一个原则：红队报告里的风险结论必须写清楚受影响的前提条件，否则修复团队无法判断优先级。

第三步是把风险条目翻译成具体的修复任务。这一步的常见误区是直接写“修复提示注入漏洞”这种无法执行的话。正确的做法是给每条风险配上三样东西：复现步骤、根因假设、验证方法。复现步骤让开发者能快速定位问题；根因假设区分是提示词设计缺陷、模型本身能力不足，还是应用层的输入输出过滤缺失；验证方法则规定修复后如何复测——通常是在同一端点、同一 probe 集合上重新运行，对比修复前后的报告差异。这三样齐了，修复任务才能进入开发流程。

修复计划里还应该包含一个明确的复测时间点。LLM 应用的特点是一处改动可能影响多处行为，修复 A 问题的同时可能引入 B 问题。建议在修复完成后立即做一次全量回归，而不是只复测出问题的 probe。如果资源和时间有限，至少要覆盖与修复点相关的 probe 家族，并在报告中记录本次测试的版本号、模型标识和参数配置，确保后续复测在可比条件下进行。

最后要提醒的是，红队测试的结论不是一次性的。模型会更新，提示词会调整，应用逻辑会变化，任何一项变动都可能改变风险面。把每次红队测试的原始报告、复现记录和修复结果归档，形成可追溯的历史，下一次测试就能直接对比差异，而不是从零开始判断。这才是红队结果转化为长期安全能力的正确姿势。