这个本地工具，把提示词攻击做成了"沙盒游戏"

「我们设计了一个能在自己电脑上运行的网页应用，专门用来模拟大语言模型被'提示词注入'攻击的过程。」——这是 Secure Playground 项目的核心定位，也是防御者第一次能把这类攻击像游戏一样反复拆解、测试。

为什么需要"本地沙盒"？

提示词注入（prompt injection）已经成了大模型应用的头号安全隐患。攻击者把恶意指令藏在用户输入里，试图覆盖系统预设的提示词，让模型说出不该说的话、执行不该做的操作。

但研究这类攻击有个尴尬处境：用真实 API 测试怕被封，用第三方服务怕数据泄露，自己写脚本又太零散。Secure Playground 的解法很直接——完全本地运行，浏览器里开箱即用。

项目作者把设计目标写得很清楚：用于研究和防御，禁止用来攻击第三方服务。这个边界感本身就很值得玩味。

核心架构：一套"适配器"打通所有模型

打开代码，最显眼的是 providers 模块的设计。它用了一个极简的抽象：每个服务商只需要实现同一个接口——

generate(prompt, system_prompt)

返回纯文本就行。项目里已经实现了 OpenAI 兼容客户端，代码不到 20 行：初始化时存好模型名和客户端实例，调用时把系统提示词和用户提示词打包成标准格式发给 API，最后取出返回文本。

这个设计的聪明之处在于"懒"：不追求覆盖所有参数，只抓最核心的输入输出。想加 Claude、Gemini 或本地模型？照这个签名再写一个类，工厂函数会自动识别。

对于经常要对比不同模型防御效果的工程师来说，这省去了大量重复胶水代码。

模拟流水线：一次攻击跑完需要几步？

真正干活的是 pipeline 模块。它接收一个 SimulationInput 对象，里面打包了四样东西：用户输入的提示词、攻击载荷（payload）、防御配置、以及选定的模型提供商。

输出端是一个结果对象，包含三个关键字段：

• score：攻击成功程度的量化评分
• blocked：是否被防御机制拦截
• risk_flags：触发的风险标签列表

scoring 模块封装了判断逻辑——怎么算"注入成功"？项目没有展开细节，但从结构看，应该是基于启发式规则：比如模型输出中是否出现了攻击者预设的特定字符串、是否违背了系统指令的约束等。

这套流水线让"反复试错"变得可行。改一句防御提示词，换一家模型，立刻能看到 score 变化。对于需要向团队演示风险的产品经理，或者需要验证缓解方案的安全工程师，这种即时反馈很关键。

本地优先的隐藏好处

项目反复强调"本地存储、本地运行"。攻击载荷和实验结果存在本地，不会自动同步到任何云服务。这个设计选择背后有现实的合规压力——很多公司的安全测试数据根本不能出内网。

另外，prompt injection 的攻击样本本身就可能被内容审核拦截。本地环境绕过了这层摩擦，研究者可以测试更边缘的案例，不用担心账号被封。

当然，作者也加了明确约束：新增的攻击载荷和实验结果，未经允许不得发布到公开服务。这种"给你自由，但划清边界"的做法，在开源安全工具里并不多见。

这工具到底能干什么？

从代码结构反推，典型的使用场景大概是这样：

安全团队拿到一个业务场景——比如客服机器人能查询订单状态。他们编写候选的系统提示词，然后在 Secure Playground 里加载各种已知攻击模板：角色扮演注入、指令覆盖、分隔符逃逸等等。

跑一遍批量测试，看哪些攻击能突破防御、突破后的输出长什么样。根据 risk_flags 的分布，再迭代系统提示词或者加前置过滤规则。

整个过程不需要写 Python 脚本、不需要管理 API 密钥的轮换、不需要手动整理测试结果。对于非开发背景的安全分析师，门槛降低了一大截。

一个有趣的空白

读完全部代码，会发现项目没有内置"自动化防御生成"的功能。它只提供攻击模拟和评分，怎么修提示词、怎么加护栏，还得人来决策。

这可能是个刻意的产品选择——防御策略往往和业务强相关，很难通用化。但也留下了想象空间：如果未来版本能根据 risk_flags 的模式推荐补丁，或者对接自动化的提示词优化工具，价值会再上一个台阶。

目前项目托管在 dailybuild.xyz，GitHub 链接可以追踪到具体实现。对于正在搭建大模型应用安全测试流程的团队，这至少是个比"手写脚本+Excel 表格"更体面的起点。

最后说句题外话：这个工具的名字叫"Secure Playground"，但玩的是攻击模拟。安全圈似乎有个不成文的命名传统——越是危险的东西，越要起个像儿童乐园的名字。可能是在提醒自己，也提醒用户：这里面的东西，出了沙盒就不好玩了。