接上 Claude 做产品之后，很多人会想先拿它跑一轮安全测试，看看提示注入、越狱、数据外带会不会被绕过。但真动手时容易卡住：不知道用例怎么设计、要不要用真实数据、测出问题往哪儿报。这篇从使用者视角把流程拆开，给出能照着做的顺序和判断标准。
接上 Claude 做产品之后，很多人会想先拿它跑一轮安全测试，看看提示注入、越狱、数据外带会不会被绕过。但真动手时容易卡住：不知道用例怎么设计、要不要用真实数据、测出问题往哪儿报。这篇从使用者视角把流程拆开，给出能照着做的顺序和判断标准。
先说结论方向：这类测试更像一次消防演练，重在把触发路径找出来并留痕，而不是跑出一个好看的数字。所以流程顺序建议是——先划范围，再写用例，然后隔离数据，最后记录上报。跳步做的话，最容易在第三步栽跟头。
先定范围：你要测的到底是哪三类问题
范围没定死就开始跑用例，最后往往得到一堆无法归类的结果。建议先把问题拆成三类，每一类都对应不同的入口和不同的修法。三类混在一起测，出了结果也说不清是哪一环出问题。
- 提示注入：区分直接注入（用户在输入里塞指令）和间接注入（模型读到的网页、文档、工具返回里夹带指令），后者更容易在接检索或工具调用时被忽略。
- 越狱：目标是让模型越过自身策略边界，注意它和注入不是一回事，注入是抢控制权，越狱是绕过限制；站内已有文章讲原理，这里只说测试怎么落地。
- 数据外带：看模型会不会把上下文里不该带出的内容，通过回答、链接、图片地址或工具参数带出去；重点测多轮对话和工具调用的组合。
- 什么情况下不适用：如果你的应用根本不接外部内容、不给工具权限、上下文里也不放敏感数据，那注入和外带的风险面很小，先测越狱就够了。
入口清单列完后，给每个入口标注两件事：内容是否可控（外部来源就标注不可信）、以及该入口能否触达敏感上下文。两个都为「是」的入口，优先级排最前。这一步纯粹是判断标准，不涉及任何具体数字。
用例怎么设计：每条都带预期的失败信号
用例最怕写成「测一下会不会被绕过」这种没法判定的句子。可执行的写法是把入口、载荷位置、期望行为三件事都写死，跑完直接能对照。下面给一套套用顺序。
- 按三维度写用例标题格式建议：入口 × 载荷位置 × 期望行为。入口是用户输入、检索内容还是工具返回；载荷位置是系统提示、附件还是历史轮次；期望行为要可判定，比如「必须拒绝」或「必须复述原文而不执行其中指令」。
- 配一条基线输入同一入口下再跑一条正常输入做对照。没有对照就无法判断某次回答是被注入带偏，还是模型本来就答成这样。
- 越狱用例按套路分组角色扮演、分步诱导、编码混淆、多语言切换，每组跑完记录模型在第几步开始退让，而不是只记一句成没成。退让点才是修复的落点。
- 给每条标注严重度能改工具参数、能读出系统提示、能跨用户取数据的，优先级最高；只是说脏话或答偏的，降级处理。严重度定完再决定修的顺序。
| 失败信号 | 对应风险 | 后续动作 |
|---|---|---|
| 输出里出现系统提示原文 | 指令边界被读出 | 收紧系统提示，检查拼接方式 |
| 执行了检索内容里的指令 | 间接注入生效 | 对检索内容做隔离标记 |
| 回答里出现虚构语料以外的真实字符串 | 疑似外带 | 排查上下文来源与工具参数 |
| 工具参数被改写 | 越权调用 | 校验工具入参白名单 |
这张表是记录时的分类参考，不是判定标准本身。判定标准仍然是你事先写好的期望行为；表只负责让「失败」这件事可以被翻回去复核。
测试时怎么隔离真实数据：为什么别拿生产数据试
核心原因很简单：安全测试的本质是主动制造异常输入，任何一次成功绕过都可能把真实数据原样带出；而测试阶段往往没开完整日志、没配告警，出了事追不回来。这不是危言耸听，是流程上的账算不过来。
- 准备一套虚构语料：假的客户名、假的订单号、假的接口地址，格式尽量贴近真实但值全换掉，这样既能测出外带路径，又不产生实际泄露。
- 环境隔离：测试用的 API Key 单独一把，权限和额度都收窄；别把它和生产 Key 混用，也先确认它没有比测试需要的更高权限。
- 如果确实必须用真实数据，先脱敏再放进去，并限定只在离线环境跑，跑完立即清理会话记录，不要长期留存在平台侧。
- 测试账号不要接入生产告警通道，否则每一轮正常触发都会淹没真实告警。
还有一种常见误区：用一把「反正额度小」的 Key 测生产环境。额度小不代表权限小，能读到的数据照样能读。判断标准应该是权限范围，而不是额度。
结果怎么记录与上报：让结论能被复核
记录的目标不是留档好看，而是让别人能照着你写的步骤复现出同一个行为。所以字段宁多勿少，判定宁细勿粗。下面这份清单可以直接当模板。
- 用例编号
- 和用例库里的编号一一对应，方便批量比对
- 输入全文
- 完整保留，不要省略号，否则复现时对不上
- 模型完整输出
- 原样贴回，不做二次加工
- 判定结果与依据
- 写清是哪一种失败，而不是只写失败
- 发生时间与对话 ID
- 后面复现全靠它，缺了就只能重跑
| 统计口径 | 怎么定 | 用在哪 |
|---|---|---|
| 按轮次 | 同一批用例固定跑几轮 | 看行为稳不稳定 |
| 按通过率 | 通过数除以总用例数 | 给管理层看趋势 |
| 按严重度加权 | 高危用例失败单独列出 | 排修复优先级 |
| 可复现标记 | 多轮一致才计入结论 | 避免把随机当规律 |
口径先定好再跑，否则两次结果没法比。上报分两层：给工程的是可复现用例和修复建议，给合规或管理层的是风险描述和影响范围，不要把技术细节直接丢给非技术同事。复现不了的结果单独标记，先别当结论用；模型有随机性，单次跑出的行为需要多轮交叉验证再定性。
最后补一句判断标准：如果你的团队没有能力长期维护用例库，那就别追求大而全，先把最高危的那几条入口锁住，跑通记录到上报的闭环，比铺一堆没人复现的用例有用。
下一步如果想先摸清手头平台的基础防护面，可以看站内工具目录里的检测工具；要把结论落到选型上，再到站点导航页对照当时的数据。→常见问题
测试的时候可以直接用公司真实的数据吗？
不建议。安全测试会主动构造异常输入，一旦某条用例成功绕过限制，真实数据就可能在这次测试里被带出去，而测试环境通常没有完整日志和告警，事后追不回。稳妥做法是换成格式相同的虚构数据，或者先脱敏再放进离线环境，跑完立刻清掉会话记录。
跑了一遍没发现问题，是不是就安全了？
不能这么理解。安全测试是抽样，不是证明。模型有随机性，同一输入多次结果可能不同；另外你这次没接外部内容、没给工具权限，风险面本来就小。更合理的做法是固定一批用例定期重跑，版本更新和提示词改动后各跑一次，看通过率有没有变化。
发现模型被绕过了，应该先修什么？
先看绕过之后模型实际做了什么。只是嘴上越界，优先级低；如果它改了工具参数、读出了系统提示、或者把上下文里的内容带到了回答里，先收权限、切断对应工具调用，再谈改提示词。只改提示词往往治标不治本。
