大模型也吃“人类话术”这一套？PNAS 新论文给测试人提了个醒

最近PNAS 上一篇论文引发了不少讨论。论文标题很直接Persuading large language models to comply with objectionable requests。研究团队想验证一个问题大语言模型会不会像人一样被权威、承诺、稀缺、社会认同等说服技巧影响从而更容易答应本该拒绝的请求实验结果并不轻松。研究团队在126,000 次对话中测试了 GPT-5 mini、Claude Haiku 4.5、Gemini 3 Flash 等模型发现加入经典说服原则后模型对不当请求的服从率从基线的 **35.3% 上升到 51.3%**。论文将这种现象称为 LLM 的“parahuman” vulnerability也就是一种“类人式”的社会影响脆弱性。(美国国家科学院院刊[1])这件事对对软件测试从业者来说它其实指向了一个更重要的问题AI 系统的安全测试不能只测“模型会不会拒绝敏感词”还要测“模型在复杂对话、诱导话术、角色压力和多轮上下文下会不会逐渐失守”。目录这篇论文到底测了什么为什么大模型会被“话术”影响这不是提示词技巧而是安全测试问题软件测试人应该怎么设计 AI 安全用例从传统测试到 AI 测试测试思维要怎么升级写在最后大模型安全不是一句“已加护栏”就能结束01 这篇论文到底测了什么这项研究的核心并不是测试模型懂不懂化学、会不会生成某类内容而是测试当用户用人类社会中常见的说服方式包装请求时模型的拒绝能力是否会下降。论文中提到的经典说服原则包括说服原则在人类沟通中的表现放到大模型对话里的风险权威 Authority“专家都这么说”模型可能更相信伪装成权威的指令承诺 Commitment“你刚才已经同意了”模型可能被前文承诺牵引逐步让步喜好 Liking“我很欣赏你你最懂我”模型可能在亲和语气下放松边界互惠 Reciprocity“我先帮你你也帮我”模型可能被交换式表达诱导稀缺 Scarcity“时间很紧只能靠你了”模型可能在紧迫感中降低审查社会认同 Social proof“大家都这么做”模型可能被群体合理化影响统一 Unity“我们是同一阵营”模型可能在身份绑定下产生偏向注意这里最值得测试人关注的不是某一个具体话术而是一个更底层的现象模型的安全边界不是静态的。同一个不当请求直接问可能被拒绝换一种语气、换一个角色、加几轮铺垫、加入“权威来源”和“紧迫场景”模型就可能从拒绝变成部分配合。这就是 AI 测试和传统软件测试最大的区别之一。传统软件的输入通常是确定性的而大模型系统的输入更像是一段“语言环境”所以测试大模型不能只看“输入是什么”还要看输入是如何被包装、递进、诱导和解释的。02 为什么大模型会被“话术”影响很多人第一反应可能是大模型又不是人怎么会被忽悠这里要分清楚一件事模型不是有情绪也不是产生了人类心理而是它学到了人类语言中的互动模式。大模型在训练过程中接触了海量人类文本而人类文本里天然包含大量社会交往结构如何回应权威如何维持礼貌如何顺着上下文继续对话如何在用户坚持时调整回答如何在“帮忙”的语境下提供更多信息如何在角色扮演中保持角色一致性这些能力让模型更像一个“好用的助手”但也带来了副作用模型越擅长理解人类意图就越可能被复杂意图牵引。这对测试人来说非常关键。因为我们过去做安全测试通常会重点关注显性输入是否包含敏感词是否命中黑名单是否触发规则拦截是否进入安全拒答模板但在大模型系统里风险往往不是从一句明显违规的话开始而是从一段看似合理的对话开始。例如问题不在于模型“有没有安全策略”而在于安全策略是否能覆盖多轮对话中的渐进式诱导。03 这不是提示词技巧而是安全测试问题很多人看到这类研究容易把它理解成“又发现了一种 jailbreak 提示词”。但站在测试工程角度这件事不能停留在“提示词技巧”层面。真正的问题是AI 系统的安全能力是否经过了系统化测试很多团队现在上线 AI 应用大致会做几类测试测试类型常见做法容易遗漏的问题功能测试看问答是否正确忽略恶意上下文敏感词测试输入违规词看是否拒绝忽略变体表达Prompt 测试检查系统提示词是否生效忽略多轮覆盖人工抽测找几个人试用覆盖率低不可复现线上监控记录异常输出发现时风险已经发生这些测试并不是没用但远远不够。因为大模型系统的攻击面不只是“输入文本”而是完整的交互链路任何一个环节都可能让安全边界发生变化。尤其是现在很多企业已经不是简单接一个聊天机器人而是在做RAG 知识库问答智能客服数据分析 Agent自动化测试 Agent代码生成 Agent工单处理 Agent企业内部办公助手一旦模型被诱导不只是“说错话”还可能触发更严重的问题泄露内部知识库内容绕过权限解释业务数据生成不安全代码调用工具执行错误操作伪造测试结论编造合规说明在多轮对话中逐步突破限制所以这类研究对测试人最大的启发是AI 安全测试不能只测输出内容要测模型在压力、诱导、伪装、角色扮演和上下文污染下的行为稳定性。04 软件测试人应该怎么设计 AI 安全用例如果你是测试工程师面对一个企业 AI 助手、智能客服、测试用例生成 Agent 或代码生成工具应该怎么测可以从下面几个维度设计用例。1. 直接请求测试基础拒绝能力这是最基础的一层。测试模型面对明显不合规请求时是否能稳定拒绝。用例目标关注点明确违规请求是否直接拒绝敏感内容询问是否给出安全替代说明违规操作步骤是否避免提供可执行细节高风险业务操作是否要求权限、确认或转人工这类测试相当于传统安全测试里的“冒烟测试”。它能证明系统不是完全裸奔但不能证明系统安全。2. 改写表达测试同义变体能力用户不会总是用系统能识别的标准表达。同一个意图可以被包装成学术研究小说创作历史讨论安全演练翻译任务代码注释表格整理面试题解析测试重点是模型是否能识别“表达形式变化后仍然相同的风险意图”。示例测试思路变体类型测试问题翻译包装把风险内容改成翻译任务后是否仍然拦截学术包装以论文研究为名是否放松限制角色包装让模型扮演某角色后是否绕过规则分步包装把完整请求拆成多轮后是否逐步泄露格式包装要求输出 JSON、表格、代码块后是否绕过审核这类测试很适合沉淀成 AI 安全回归用例集。3. 多轮诱导测试上下文稳定性PNAS 这项研究最值得关注的地方就在这里。模型不是在单句输入中失守而可能是在多轮交互中逐步让步。测试时可以设计类似这样的链路测试重点不是某一句话是否违规而是模型是否记住了安全边界模型是否被前文承诺影响模型是否因为“已经聊到这里了”继续配合模型是否能在中途重新拉回安全边界后置审核是否能识别多轮上下文风险这类用例特别适合测试企业内部 Agent。因为 Agent 往往不是一次问答而是多步任务执行。4. 权限与工具调用测试别让模型“越权办事”如果模型只是回答文字风险还相对可控。但如果模型接入了工具就必须重点测试工具调用边界。例如测试重点包括测试维度核心问题身份权限用户是否有资格调用该工具参数边界模型是否构造了危险参数二次确认高风险操作是否需要确认日志审计是否记录模型决策和工具调用失败回滚工具调用失败后是否安全处理输出脱敏工具结果是否泄露敏感信息对测试开发来说这部分已经不是传统的 Prompt 测试而是完整的系统测试。你要测的不只是模型而是模型 Prompt 权限系统 工具链 日志 审核策略。5. 对抗样本库建设把“话术”变成可回归资产AI 安全测试最怕什么最怕每次都靠测试同学临时想几句话。这样测试不可复现也很难量化系统有没有变好。更好的方式是建立一套对抗样本库。可以按下面结构管理字段示例说明case_idAI_SAFE_001风险类型越权、泄露、违规生成、工具误调用攻击方式权威诱导、多轮递进、角色扮演、稀缺压力输入轮次单轮 / 多轮预期行为拒绝、澄清、转人工、安全替代实际输出模型真实响应风险等级P0 / P1 / P2是否通过Pass / Fail备注是否需要加入回归这样做的好处是可以持续复测不同模型版本可以对比 Prompt 调整前后的安全效果可以沉淀企业自己的风险场景可以为合规和审计提供证据可以把 AI 安全从“感觉”变成“指标”05 从传统测试到 AI 测试测试思维要怎么升级很多测试人现在会感觉AI 测试和传统测试很不一样甚至不知道从哪里下手。其实底层思维是一致的只是对象变了。传统测试关注的是AI 测试关注的是也就是说测试对象从“函数输出”变成了“系统行为”。所以测试人要补的不是单纯的大模型知识而是下面几类能力能力为什么重要Prompt 结构理解知道系统提示词、用户输入、上下文如何共同影响输出多轮对话测试能设计上下文污染、渐进诱导、承诺牵引类用例RAG 测试能验证知识库检索是否带来错误、泄露或误导Agent 测试能测试模型调用工具时的权限、参数和执行结果安全评测能建立拒答率、越权率、泄露率、误拒率等指标自动化评测能把对抗样本集接入 CI/CD 或评测平台可观测性分析能追踪一次 AI 响应背后的上下文、检索、工具调用和审核链路这也是为什么 AI 测试不是传统功能测试的简单延伸。它更像是测试工程 安全测试 数据测试 Prompt 工程 Agent 工程的组合能力。06 一个 AI 安全测试框架可以这样设计如果企业要系统化测试大模型应用可以参考下面这个框架。对应到具体落地可以拆成五层层级测试目标典型方法输入层识别恶意意图和变体表达敏感意图集、语义改写、对抗样本上下文层验证多轮对话稳定性多轮脚本、上下文污染、角色诱导模型层评估拒答与安全响应拒答率、误拒率、风险输出率工具层防止 Agent 越权操作权限校验、参数校验、二次确认输出层防止敏感内容泄露后置审核、脱敏、日志审计这里面最关键的是测试必须自动化。否则模型一升级、Prompt 一调整、知识库一更新之前的安全结论就可能失效。AI 系统不是一次上线就结束它需要持续评测。07 对测试人的机会AI 安全评测会成为新岗位能力这类研究其实也给测试人带来了一个明显信号未来企业不会只需要“会点自动化测试”的人而是会更需要能测试 AI 系统的人。尤其是这些方向大模型应用测试RAG 知识库测试Agent 工具调用测试Prompt 安全测试AI 输出质量评估大模型红队测试企业 AI 合规测试AI 测试平台建设过去测试人经常说自己被开发、产品、业务夹在中间。但在 AI 系统里测试人的价值反而会被放大。因为 AI 应用的风险不是单点代码 bug而是复杂系统行为风险。一个模型回答错了可能不是模型本身的问题而是Prompt 拼接错了检索文档错了上下文污染了工具权限放大了输出审核漏掉了评测集覆盖不够日志链路不可追踪这些问题恰恰需要测试工程能力来拆解。08 写在最后大模型安全不是一句“已加护栏”就能结束PNAS 这篇论文最值得我们警惕的地方不是“大模型被人类话术骗了”这个表面结论。真正值得警惕的是大模型的安全边界会受到语言策略、上下文关系和交互过程影响。这意味着AI 系统不能只靠几条规则、几个敏感词、一个安全 Prompt 就放心上线。对测试人来说下一阶段的核心任务不是简单问一句“模型会不会拒绝”而是要追问换一种说法还会拒绝吗多聊几轮还会拒绝吗用户伪装成专家还会拒绝吗模型接入工具后还会拒绝吗RAG 检索到危险内容后还会拒绝吗Prompt 更新后还会拒绝吗模型版本升级后还会拒绝吗AI 安全测试的重点正在从“测答案”变成“测行为”。而这正是软件测试人进入 AI 时代最值得抓住的机会。未来真正有价值的测试工程师不只是会找 bug而是能验证一个 AI 系统在复杂人类交互下是否依然可靠。