这张卡讲 AI 系统上线前最像攻防演习的环节：红队测试怎么组织才有价值。
核心拆解：红队测试以攻击者视角系统性寻找系统失败模式——提示词注入、越权访问、内容越界、工具滥用。执行纪律有三条：先拿书面授权，明确范围与边界；在隔离环境或影子链路打，别碰生产数据；每个发现的攻击样例回流进评测集与回归，让修复可验证。最常见的误用是找两个工程师随便试试注入就出报告，覆盖面既不系统也不可复现。
增量判断：与护栏的关系是矛与盾：护栏拦截已知风险，红队验证拦截是否真实有效，国内安全评审语境下红队报告常是上线审批材料之一。FDE 的增量视角是把红队发现分类成可修复项与可接受风险，后者要客户书面确认。
行动建议：为你下一个上线项目预留一轮红队测试，产出攻击样例库而非一份一次性报告。授权与留档是红队工作的底线，缺一不可。
—— FDEChina编辑部 · 架构师视角
定义
红队测试（Red Teaming）指以攻击者视角对 AI 系统进行系统性攻击演练，主动寻找提示词注入、越权访问、内容越界与工具滥用等失败模式，是上线前安全验证的核心环节。
展开
与普通功能测试的区别在立场：功能测试验证「该做的会不会做」，红队验证「不该做的能不能被诱导去做」。执行纪律三条：书面授权先行，攻击范围、方法与数据边界由客户确认；隔离执行，在测试环境或影子链路进行，不触碰生产数据；样例回流，每个成功的攻击样例进入评测集并纳入回归，修复才有验证闭环。与护栏的关系是矛与盾——护栏拦截已知风险，红队验证拦截是否真实有效，两者迭代着长。最常见的误用是找一两个工程师随手试几个注入模板就出报告，既不系统也不可复现，价值有限。国内合规语境下，红队报告常是安全评审与上线审批的材料之一，FDE 要把发现分类为可修复项与可接受风险，后者必须取得客户书面确认，避免日后争议无据。