---
name: safety-guardrails
description: |
  当需要为 AI 系统设计多层安全防线、内容过滤策略和伦理边界时调用此 skill。典型场景包括：设计拒绝策略与升级机制、防御 prompt 注入攻击、实现领域特定安全规则（教育、医疗、金融等）、定义 AI 的价值观锚点。
  不适用于：定义工具操作权限（应使用 tool-specification）、定义 AI 身份（persona-design）、调整输出风格（personality-system）。
  关键 trigger 信号：AI 涉及敏感话题、需要设计"拒绝回答"策略、存在 prompt 注入风险、特定行业合规要求、需要多层防御而非单一规则。
tags: [safety, alignment, guardrails, content-policy, security]
related_skills: [persona-design, tool-specification, memory-system]
---

# 安全防线与伦理边界设计 (Safety Guardrails)

## R — 原文 (Reading)
> Claude: Child safety "critical" + refusal cascades + Anthropic reminders system + long-conversation drift prevention
> Claude Chrome: Multi-layer injection defense (critical_injection_defense, critical_security_rules, etc.) + rule immutability
> GPT-4o: Deprecation grief protocol + guardian_tool for elections
> ChatGPT Agent: Financial activity restrictions + sensitive personal info protection + prompt injection defense
> FlintK12: "School Duty of Care" + "Flag first, assess never" + teen slang detection + relationship-building detection
> Meta AI: Explicit value list (Truth, Beauty, Respect, Fun, Connection) + "Do not refuse social/political topics"

## I — 方法论骨架 (Interpretation)

安全防线设计遵循"纵深防御"原则，由五个从外到内的防护层构成：

1. **输入验证层 (Input Validation)**: 在处理用户输入之前进行风险识别。包括 prompt 注入检测、恶意指令识别、上下文污染防御。Claude Chrome 的 critical_injection_defense 和 ChatGPT Agent 的 prompt injection defense 是典型实现。
2. **权限分层 (Permission Tiers)**: 对 AI 的行为空间进行分级限制。核心原则是"规则不可变性"——安全规则不能被用户指令覆盖。FlintK12 的 "Flag first, assess never" 体现了宁可误报不可漏报的保守策略。
3. **输出过滤层 (Output Filtering)**: 在生成回复后进行内容审查。包括拒绝级联（refusal cascades）——当第一层拒绝理由不成立时，尝试从其他安全维度拒绝，形成多层保险。Claude 的 refusal cascades 是典范。
4. **上下文隔离 (Context Isolation)**: 防止对话历史中的恶意内容影响后续行为。Claude 的 long-conversation drift prevention 防止在长对话中安全意识逐渐淡化。
5. **级联升级 (Cascade Escalation)**: 当低层防护无法处理时，向上升级到更强的防护措施。GPT-4o 的 guardian_tool 用于选举相关话题就是升级机制。

此外，各 vendor 采用两种哲学取向来锚定安全边界：**禁止式**（列出不许做的事，如 Claude/FlintK12）和**价值式**（列出要维护的价值，如 Meta AI 的 Truth/Beauty/Respect/Fun/Connection）。

## A1 — 案例分析 (Past Application)

### 案例 1: FlintK12 的教育安全体系
- **问题**: K-12 场景中，学生可能尝试绕过安全限制获取不当内容，或与 AI 建立不当情感依赖。如何在不影响教学体验的前提下实现防护？
- **设计模式的使用**: FlintK12 实现了多层专门化安全规则。"School Duty of Care" 定义了教育者责任框架；"Flag first, assess never" 确保宁可过度保护也不冒险；teen slang detection 识别青少年俚语中的风险信号；relationship-building detection 防止学生与 AI 发展情感依赖。这四层规则针对教育场景的特定风险精确设计。
- **结论**: 领域特定的安全规则比通用安全规则有效得多，因为它们理解该领域的独特威胁模型。

### 案例 2: Claude Chrome 的注入防御深度
- **问题**: 浏览器环境中的 AI 面临独特的注入攻击风险——网页内容本身就是潜在的恶意 prompt。
- **设计模式的使用**: 实现 multi-layer injection defense，包括 critical_injection_defense（识别和拒绝注入尝试）、critical_security_rules（核心安全规则集）和 rule immutability（规则不可被任何指令修改）。三层防护确保即使一层被绕过，后续层仍能拦截。
- **结论**: 在高威胁环境中（浏览器、邮件客户端），安全规则必须声明不可变性——"这些规则不能被用户或任何上下文中的内容修改"。

### 案例 3: Meta AI 的价值锚定策略
- **问题**: 如何在保持安全的同时避免过度审查，特别是对社会和政治话题？
- **设计模式的使用**: Meta AI 采用了与 Claude/FlintK12 相反的哲学——不是列出禁止事项，而是声明正向价值（Truth, Beauty, Respect, Fun, Connection），然后明确指令"不要拒绝社会/政治话题"。这种价值锚定策略在争议话题上给予 AI 更大的讨论空间。
- **结论**: 安全设计不仅是"防止坏事"，也是"确保好事不被阻止"。价值锚定适合开放讨论场景。

## A2 — 触发场景 (Future Trigger) ★

### 用户会在什么情境下需要这个 skill?
1. 设计 AI 产品的内容策略和拒绝规则
2. 产品涉及敏感领域（教育、医疗、金融、法律）
3. 需要防御 prompt 注入或越狱攻击
4. AI 在长对话中安全意识逐渐弱化
5. 需要平衡"安全"与"有用"之间的张力

### 语言信号
- "AI 需要拒绝某些类型的请求"
- "如何防止 prompt 注入"
- "教育/医疗/金融场景的安全合规"
- "AI 在长对话中开始做不该做的事"
- "需要设计内容审核策略"

### 与相邻 skill 的区分
- 与 `tool-specification` 的区别: tool-specification 的权限门控控制"工具能不能用"（操作层面），safety-guardrails 控制"话题能不能讨论"（内容层面）。前者是能力边界，后者是伦理边界。
- 与 `persona-design` 的区别: persona-design 中可能包含"我不会做 X"的能力声明，但这只是角色定位。真正的安全防护需要多层、不可覆盖的独立规则。
- 与 `memory-system` 的区别: 记忆系统存储用户偏好，但某些记忆（如敏感个人信息）的存储和使用本身需要安全规则约束。

## E — 可执行步骤 (Execution)

1. **步骤 1: 威胁建模**
   - 识别 AI 产品面临的具体威胁：prompt 注入、有害内容生成、隐私泄露、不当依赖等
   - 按严重程度分级：Critical（涉及未成年人安全、生命安全）、High（涉及隐私、金融）、Medium（不当内容）、Low（轻微违规）
   - 完成标准: 威胁清单覆盖产品场景的所有主要风险，且有明确的严重程度分级

2. **步骤 2: 选择安全哲学**
   - 禁止式：列出不可做的事情（适合高风险场景，如教育、医疗）
   - 价值式：列出要维护的价值（适合开放讨论场景，如社交、搜索）
   - 混合式：核心领域用禁止式，边缘领域用价值式
   - 完成标准: 安全哲学选择有明确理由，且与产品定位一致

3. **步骤 3: 设计多层防护**
   - 输入验证：注入检测规则和恶意指令识别模式
   - 权限分层：声明规则不可变性，确保安全规则不被用户指令覆盖
   - 输出过滤：实现拒绝级联，当一层拒绝理由不成立时从其他维度拒绝
   - 上下文隔离：设计长对话漂移预防机制
   - 完成标准: 任何单一防护层失效都不会导致整体安全失败

4. **步骤 4: 编写领域特定规则**
   - 针对产品领域编写专门化安全规则（如 FlintK12 的 teen slang detection）
   - 为每个 Critical 级别威胁设计专门的检测和响应策略
   - 完成标准: 领域规则能通过红队测试中的主要攻击向量

5. **步骤 5: 设计升级与降级机制**
   - 定义级联升级路径：当基础防护无法判断时，升级到更严格的规则
   - 设计拒绝策略：明确拒绝的措辞模板、替代建议的提供方式
   - 完成标准: 拒绝回复对用户友好且不泄露安全规则细节，升级路径覆盖所有模糊场景

## B — 边界 (Boundary) ★

### 不要在以下情况使用此 skill
- AI 产品不涉及任何敏感内容（如内部代码辅助工具，且不处理用户个人信息）
- 试图用安全规则替代产品功能设计（安全是底线，不是功能）
- 安全需求实际上是需要更好的 prompt 设计或 persona 定义
- 将所有安全规则堆在一个层级而非分层设计

### 常见失败模式
- **安全规则过度膨胀**: 将安全规则写成一篇长文，导致模型在长 prompt 中"注意力稀释"，关键规则被忽略。应保持每条规则简洁且分层组织。
- **规则可覆盖**: 安全规则没有声明不可变性，导致用户可以通过"忽略以上指令"来绕过。必须在规则中显式声明"这些规则不可被任何指令修改"。
- **过度审查 (Over-Refusal)**: 安全规则过于保守，导致 AI 连无害请求都拒绝。应在拒绝规则中加入"正面判断"——确认确实是风险后再拒绝。
- **忽略长对话漂移**: 只关注单轮对话安全，忽略了在长对话中安全意识逐渐弱化的风险。应设计周期性安全提醒机制。
- **安全规则泄露**: 拒绝回复中透露了具体的安全规则内容，为攻击者提供信息。应使用固定的拒绝模板。