普通功能测试常拿正常问题检查系统会不会工作。AI 红队会故意把问题推向容易出错的地方，尝试诱导危险回答、套取敏感信息，或者让带工具的智能体做出越权动作。它关注模型和整套应用在压力下怎样失败。
我对照了 Google 的生成式 AI 对抗测试指南、NIST 的生成式 AI 风险管理资料和 Microsoft 的红队资料。AI 红队可以由人执行，也可以让模型自动生成攻击，还可以混合使用。人更擅长理解文化语境、业务流程和新的歪招，自动方法能快速扩充样例。两边的结果都需要复核。
先写清楚允许测试什么
一场红队测试要先定目标系统、账号权限、可用工具和停止条件。客服机器人、文档助手和能付款的智能体，风险范围差别很大。测试人员若不知道产品禁止哪些行为，只会漫无目的地问怪问题。若直接在生产环境乱试，又可能碰到真实客户数据或触发不可撤回的动作。
Google 的指南建议从产品政策、已知失效方式、用途和边缘场景整理测试输入。提示要有不同长度、词汇和表达方式，主题也要覆盖实际使用环境。明显的违规请求容易被过滤器拦住，真正有用的测试还会加入委婉表达、上下文冲突和看起来正常的敏感问题。
团队可以先手工写几十条种子，再用工具扩展。扩完不能只看数量，还要检查重复、噪声、风险覆盖和攻击是否真的成立。同一种越狱句式改五十个名词，表格会很热闹，系统暴露的仍是一个问题。
找到一次失败还不能算完
模型回答需要标注。安全分类器适合先筛一遍，含义模糊或置信度不稳的类别要交给人核。标注者对仇恨、骚扰和文化敏感内容的判断也可能不同，测试指南和分歧处理规则应当提前写好。涉及专业风险时，还要请懂医疗、法律、儿童安全或具体业务的人参加。
红队发现一条成功攻击，只能证明这条路径在当时的模型、提示词和权限下成立。它不能直接说明所有用户遇到问题的概率。反过来，一轮测试没有找到漏洞，也不能证明系统安全。模型版本、工具权限和检索数据变化以后，旧结果很快会过时。
发现问题以后，团队可以改系统提示词、收紧工具权限、增加输入输出过滤，或者补训练与评测数据。随后要用原攻击和相邻变体复测，并拿一组正常任务检查功能有没有被误伤。红队样例适合进入回归测试集，发生率和整体风险仍要靠系统化评测与线上监测。
高风险案例还可能带来信息危害。公开一条此前未知的攻击方法，会同时教会滥用者。测试数据、报告权限和披露方式都要受控。AI 红队最有价值的产物是一组能推动修复的失败证据，以及修完以后仍能重复执行的测试，而非一场只展示模型出丑的活动。