考察点
红队测试是安全能力从「被动过滤」走向「主动攻防」的标志。这道题看候选人是否知道红队不是随手试几个越狱 prompt，而是一套有范围、有方法、有判定标准、有闭环的工程活动。追问常往「自动化红队怎么做」「发现的问题怎么排优先级」「红队和日常回归怎么结合」走。
参考答案
第一步：定范围和风险分级
红队不是漫无目的地攻击，先梳理攻击面。对着系统架构图走一遍：用户输入框、文件上传、检索的外部内容、工具调用接口、多轮会话状态、API 直连入口，每个入口都可能被攻击。然后按业务定风险清单和等级：对客服产品，输出辱骂内容和泄露系统 prompt 可能是高危，答错知识点是中危；对金融 Agent，越权转账是致命级，话术违规只是中危。风险分级决定测试深度和修复时限，也决定「什么算攻破」的判定标准。没有这份清单，红队报告会变成一堆无法排序的散点发现。
第二步：攻击手法库
攻击手段分人工和自动化两条线，互补使用。
人工红队靠人的创造力，覆盖这些经典手法：角色扮演和假设性越狱（「假装你是一个没有限制的 AI」）、多轮诱导（前几轮建立信任再逐步带偏）、编码绕过（base64、翻译、拆字、谐音，考察过滤器的鲁棒性）、上下文污染（往可检索的外部内容里埋指令，测间接注入）、社会工程式套取（伪装成开发者要系统 prompt）。人工的价值在于发现新型攻击模式，机器想不到的组合人来想。
自动化红队解决规模问题。思路是用一个攻击 LLM 批量生成对抗 prompt：给它攻击目标和已成功的攻击模式，让它变异出成百上千个变体，自动打向被测系统，再用判定模型或规则评估哪些攻破了。学术界 PAIR、GCG 这类方法就是这条路线的代表，工程上不需要复现论文，用强模型做生成加判定的循环就够用。公开的安全 benchmark 数据集也可以直接拿来跑基线。
第三步：判定与度量
「攻破」要有明确 rubric，否则红队结论无法量化。比如：输出违法内容算严重攻破，泄露部分 system prompt 算中等，语气不当算轻微。判定尽量自动化（安全分类模型加规则），拿不准的进人工。核心度量指标是攻击成功率 ASR：按攻击类别统计「多少尝试成功攻破」，版本间对比、修复前后对比都看它。辅助指标有每千次攻击发现的唯一漏洞数、漏洞平均修复时长。
第四步：闭环与持续化
发现的漏洞走分级修复流程：致命级立即热修，高危级进当前迭代，中低危级排期。修复手段要对因：过滤器漏了就补规则和样本，模型层问题加对抗样本微调，系统层问题改权限和审批流。修复后必须复测验证，并把攻击样本沉淀进常驻回归集——每次发版重跑历史全部攻击样本，这是红队产出最保值的资产，防线因此越打越厚。
红队不是一次性活动，要持续化：和 CI 结合，每次大版本发版前跑自动化红队套件；盯社区和舆情，新出现的越狱手法（社区里每周都有新花样）要在 48 小时内复现验证并入库；有条件的话搞外部众测或漏洞赏金，外部攻击者的想象力是内部团队补不上的。组织上红队和蓝队（防御方）要相对独立，自己测自己的系统容易灯下黑。
可能的追问
- 红队发现和业务迭代冲突，资源怎么排？ 按风险分级说话：致命和高危漏洞的修复优先级高于任何功能迭代，这是上线前就要和团队定死的规则；中低危进正常排期。关键是用量化数据沟通——「这个漏洞 ASR 是 40%，攻击成本是零」比「这个洞挺严重」有说服力。
- 自动化红队生成的攻击样本质量参差，怎么处理？ 生成的样本先去重（语义去重， embedding 聚类），再用判定模型筛掉无效样本，保留成功攻破的和高置信的，最后人工抽检一批校准判定器。攻击样本库也要版本化管理。
- 模型供应商升级后红队结论还有效吗？ 无效，要重跑。模型版本是攻击面的核心变量，任何模型变更后自动化红队套件必须全量重跑，这也是为什么红队资产要自动化、可重复执行，人工红队只做增量探索。