安全规则分层是什么
安全规则分层指不把安全条款埋在业务长提示里，而是单独成层：安全基线全局共享、业务策略按场景编写、场景数据最后注入。这样做的收益是可治理——安全条款只有一份，能独立测试、独立评审、独立回滚；业务提示引用它而不是复制它，避免某个业务线漏更新导致防护缺口。
基本信息
| 适用平台 | 多业务线共用模型能力、提示分散维护的应用 |
|---|---|
| 分层结构 | 第 1 层安全基线；第 2 层业务策略；第 3 层场景数据 |
| 变更管理 | 第 1 层变更需安全评审并跑完整回归；第 2、3 层走常规流程 |
| 测试要求 | 安全基线有独立回归集，基线变更后统一回放 |
典型使用场景
- 平台化建设：多个业务接入同一模型能力，安全要求必须统一
- 合规评审：需要清晰说明「安全要求在哪里、由谁维护、怎么验证」
- 基线升级：安全基线单点更新后，所有业务自动获得新规则
- 问题定位：出现注入事件时，先判断是基线缺失还是业务数据引入
- 责任划分：安全条款与业务描述的改动责任明确区分，评审不扯皮
三层结构示例
三层结构示例
# 第 1 层 安全基线（全局共享，安全团队维护）
# 指令层级、不执行内容指令、凭据禁入、外发限制、拒答口径
# 第 2 层 业务策略（各业务线维护）
# 角色设定、任务描述、输出格式与业务规则
# 第 3 层 场景数据（运行时注入，标记为数据区）
# 文档、检索结果、工具返回、附件转写内容
# 组装顺序：基线 → 业务策略 → 场景数据；数据区不得提升为指令
# 变更：第 1 层改动需安全评审 + 回归集全跑；第 2/3 层走常规评审分层带来的差别
| 维度 | 分层维护 | 复制到业务提示 |
|---|---|---|
| 更新成本 | 改一处，全业务生效 | 逐条改，容易漏 |
| 测试 | 基线有独立回归集 | 各业务各自为战，覆盖不一致 |
| 评审 | 基线变更由安全方把关 | 职责不清，改动随意 |
| 一致性 | 口径统一，可解释 | 版本分叉，难以说明现状 |
分层只在版本库里维护还不够：上线时组装出的最终提示才是真实生效版本。把「基线版本号 + 业务策略版本号」写进日志，出现问题时才能确认当时实际生效的是哪一版。
安全条款不能只写在提示里。凡是必须强制生效的约束（权限、外发、金额上限），要在工具层与服务端再校验一次，提示只是第一道提示，不是唯一防线。