大模型安全实验的失败记录

讨论大模型安全：Prompt 注入、越狱攻击与防御评估实践时，典型线上故障的定位证据链常被写成一串工具或原则，读完仍不知道该先检查什么。更实用的起点是把当前任务限定下来：提示词、检索内容和工具返回值都可能是不可信输入。本文只谈可在授权范围内复核的做法。

先保全一次请求的因果链

把涉及的对象列成清单：不可信文本、工具权限、模型输出和外部数据源。对每项补上来源、修改者、依赖关系和失败后的影响。这里不追求面面俱到；先选一条真实流程，才能分清哪些观察是事实，哪些只是猜测。

用版本与策略记录排除假设

故障定位先固定时间范围和影响面，再收集请求标识、错误类型、版本和配置快照。没有这些事实，日志里再多的异常也只能产生猜测。

按调用链逐段排除：入口是否收到请求、策略是否命中、下游是否超时、重试是否放大了负载。每一步只验证一个假设，并记录反证。

修复后回到同一类输入和相近条件复测。复盘应区分直接原因、放大因素和未生效的防线，避免把一次偶然现象写成普遍规律。

留下能复查的记录

记录至少应包含：本次范围与授权前提、输入或样本的来源、环境和版本、预期结果、实际观察，以及下一步由谁处理。还要核对：模型是否被允许调用工具以及调用参数是否经过校验。对于大模型安全：Prompt 注入、越狱攻击与防御评估实践，可保留的证据包括：策略决策、工具调用记录、拒绝原因与脱敏后的请求关联标识。

失败记录如何回到防线

不应把模型生成的文字直接当作执行指令。如果材料不足，结论可以停在“尚待验证”；把未知项列出来，比用概括性的成功或失败更诚实。下一次变更时，沿用同一份记录即可判断原来的前提是否还成立。

用失败样本检查隔离是否真的存在

安全实验里最容易被忽略的是拒绝请求之后发生了什么。把经过授权和脱敏的注入样本放进同一条链路，分别观察检索片段是否被引用、工具计划是否生成、权限层是否拦截，以及最终响应是否泄露内部说明。模型拒答不能代替这些检查；若下游已经收到污染参数，问题只是没有在这一轮显现。

记录时把策略版本和工具白名单并列保存。策略改动后重新跑同一批样本，比较调用次数、拒绝位置和人工接管比例。差异较大时先回看输入拼接与上下文裁剪，不急着把原因归到模型本身。这样的记录能指出防线断在哪一层，也避免团队只保存成功拦截的截图。

若样本触发了人工审核，审核意见也应回写到记录中。它能说明拦截是合理保守，还是规则误伤。后续调整时按意见缩小修改面，不能为了降低拒绝率直接撤掉整条限制。

审计日志保留周期、访问者和脱敏规则也要写明。否则问题跨周期重现时，团队只能凭记忆还原上下文，判断会越来越不可靠。

记录的价值在于让后续判断有证据可查。

每次实验结束后，用一个简短结论标出“已验证”“未验证”和“因授权限制未测试”的部分。三者不能混写。前两项可以指导后续修复，第三项只能说明范围尚未覆盖。若需要复现，应在同等授权和隔离条件下进行，避免把实验材料带到无关环境。把边界写清楚，也能防止后来的人把一次受限测试误读为完整安全结论。