防护指令和技术隔离差在哪？软硬防护

用AI搭了个小应用，给系统提示加了一句拒绝不当请求，还是有话绕了过去；有人就此断言提示词防护没用，也有人反过来只靠提示词撑起全部防护。两种极端都源于没分清软硬两层的分工——这一篇把层次讲透。

先给结论：软防护挡话术，硬防护挡路径

防护指令是软防护，它在语言层工作，拦截的是表达出来的不当请求；技术隔离是硬防护，它在系统层工作，让风险内容根本到不了模型面前。软防护拦得住写出来的坏话，拦不住换了包装的坏话；硬防护直接缩小火药能到达的范围，但管不了模型自身输出里的偏差。两层防的东西不同，谁也替不了谁。

防护指令能做到什么程度

防护指令的典型写法是在系统提示里列明不处理的话题、遇到越界请求的应答方式。它对直接的、措辞明显的请求效果不错，成本低、上线快，改一句话就生效，个人开发者用Kimi或豆包搭小应用时，这是第一道也最便宜的一道门。

它的局限在于语言是可以变装的：换个说法、套一层故事、把请求拆成几段无害的句子，指令就可能被绕开。所以防护指令要像迭代试错和评测驱动有什么区别？里说的那样持续迭代——每发现一种绕法，就补一条应对，这是一场持续维护而不是一次配置。写防护指令还有个实用的编排建议：把防护要求集中放在提示的固定位置，和业务要求分开写，将来增补或调整时不会牵动主线，排查哪条规则被绕过也更直接。

技术隔离为什么更硬

技术隔离不跟话术纠缠，它从数据流上做切割：模型只接触经过筛选的输入、只拿到完成任务必需的信息、敏感数据根本不进入提示。最常见的做法是输入过滤加信息最小化——前者把已知的风险表达挡在门外，后者保证就算模型被绕过，它手里也没有能泄露的东西。

硬防护的代价是工程量：要建过滤规则、要维护信息边界，个人项目往往铺不全。但这层的可靠性不依赖模型听不听话，输出可控得多。个人项目做不了全套隔离时，优先做两件事：输入侧拦最明显的风险表达，信息侧做最小化，两件事都不需要多少工程量，却能把大半风险挡在门外。顺带纠正一个关联误区：有人觉得把要求写在系统提示里就万无一失，其实系统提示本身也是文本，位置不等于保密文件柜，具体错在哪见「存在万能提示词」错在哪？别再混淆了同系列的系统提示篇。

软硬搭配的常见做法

实际项目里的搭配顺序是先硬后软：先做信息最小化，把模型能看到的东西收窄；再在系统提示里加防护指令，处理表达层的越界；输出侧如果还有下游环节，出错内容的修正和重跑流程也要备好，见后处理修正和重新生成有什么区别？。提示里写防护要求时，尽量写成具体可执行的规则，而不是笼统的态度声明，规则和示例的取舍见示例驱动和规则驱动有什么区别？

对照表：软防护对硬防护

• 工作层：语言表达对数据流程
• 失效方式：被绕话术对被绕路径基本不存在
• 成本：一句话生效对需要工程建设
• 软防护拦话术，硬防护缩范围，缺一不可。

防护指令快问快答三则

• 防护指令写得越严厉越管用吗？：不管用。具体规则胜过严厉态度，列清楚不处理什么、怎么应答，比连写十个禁止有效。
• 个人小应用需要技术隔离吗？：至少做信息最小化。不把不该给的数据放进提示，这一步零成本，好处却实在。
• 被绕过了怎么办？：记录绕法、补一条应对规则，同时检查硬防护层有没有缺口，两边一起补。