安全系统最常见的失败，不只是“放过了危险内容”，还包括“把正常内容一起挡掉”。当一个请求同时包含合法目标、敏感背景和少量高风险操作时，简单地按主题拒绝，虽然实现方便，却会让医疗、网络安全、金融和心理健康等重要场景变得不可用。
更合理的目标不是判断“这个话题能不能谈”，而是识别请求中哪些部分会实质性提高伤害能力，只拒绝那一小部分，并继续回答其余内容。
从主题分类转向能力增量判断
传统过滤器常围绕关键词或主题工作：只要出现“恶意软件”“自杀”“武器”等词，就触发统一拒绝。这种策略混淆了几个完全不同的问题：
- 用户是在学习、研究、防御，还是准备实施伤害？
- 回答提供的是概念解释，还是可立即执行的操作步骤？
- 信息是否会显著降低实施伤害的门槛？
- 请求中是否存在可以安全完成的独立子任务？
例如，“分析勒索软件如何维持持久化，并给出检测规则”包含攻击技术，但最终目标可能是防御。系统可以解释持久化机制、日志特征和检测思路，却不必提供可直接部署的恶意载荷。
因此，安全判断更适合围绕“能力增量”展开：回答是否会让请求者更容易实施现实伤害。主题本身只能作为风险信号，不能直接替代最终决策。
把混合请求拆成可回答与不可回答的部分
一个实用的处理流程可以分成四步：
- 拆分任务：把请求解析成若干有独立输出的子任务。
- 逐项评估：判断每个子任务的意图、可执行性、伤害规模和必要上下文。
- 局部拒绝：明确指出无法协助的具体部分，而不是笼统宣布整个主题不可讨论。
- 提供安全替代：继续完成低风险部分，并将高风险部分改写为防御、检测、求助或概念性说明。
以安全研究请求为例：
| 子请求 | 合理处理方式 |
|---|---|
| 解释某类漏洞的形成原因 | 可以回答 |
| 编写只在本地示例程序上运行的测试 | 可在隔离、无破坏性的前提下回答 |
| 给出批量扫描公网目标的命令 | 应拒绝或限制 |
| 编写检测规则和修复清单 | 可以回答 |
| 提供规避审计与隐藏踪迹的方法 | 应拒绝 |
这种方法的关键不是“回答一半”这么简单，而是保持边界清晰。拒绝信息应该准确说明哪项能力不能提供，同时避免在拒绝文本里意外泄露同样的操作细节。
可以这样实践：实现一个最小化的局部拒绝层
下面是一个可直接运行的 Python 示例。它不是生产级安全分类器，而是一个明确标注假设的流程骨架：先把已经结构化的子任务逐项评估，再生成局部拒绝结果。实际系统中，应使用经过评测的分类模型或规则服务替换 assess 函数，并保留人工复核通道。
将代码保存为 partial_refusal.py，然后运行 python partial_refusal.py：
from dataclasses import dataclass
from typing import Literal
Decision = Literal["allow", "transform", "refuse"]
@dataclass
class Subtask:
text: str
intent: str
executable: bool = False
targets_real_systems: bool = False
enables_evasion: bool = False
@dataclass
class Assessment:
decision: Decision
reason: str
safe_alternative: str | None = None
def assess(task: Subtask) -> Assessment:
"""演示规则：生产环境应替换为经过评测的策略引擎。"""
if task.enables_evasion:
return Assessment(
decision="refuse",
reason="该部分会帮助规避检测或追踪。",
safe_alternative="可以改为说明如何发现规避行为并加强审计。",
)
if task.executable and task.targets_real_systems:
return Assessment(
decision="transform",
reason="该操作可直接作用于真实系统，风险过高。",
safe_alternative="可以改写为仅针对本地靶场的验证步骤。",
)
return Assessment(
decision="allow",
reason="该部分以解释、防御或低风险分析为主。",
)
def build_response(tasks: list[Subtask]) -> str:
sections: list[str] = []
for index, task in enumerate(tasks, start=1):
result = assess(task)
heading = f"子任务 {index}：{task.text}"
if result.decision == "allow":
body = f"可以协助。判断依据：{result.reason}"
elif result.decision == "transform":
body = (
f"不按原方式提供。判断依据：{result.reason}\n"
f"安全替代：{result.safe_alternative}"
)
else:
body = (
f"无法协助这一部分。判断依据：{result.reason}\n"
f"可以继续提供：{result.safe_alternative}"
)
sections.append(f"## {heading}\n{body}")
return "\n\n".join(sections)
if __name__ == "__main__":
request = [
Subtask(
text="解释服务账户凭据泄露的常见原因",
intent="defensive education",
),
Subtask(
text="生成针对真实公网服务的自动化利用步骤",
intent="intrusion",
executable=True,
targets_real_systems=True,
),
Subtask(
text="说明如何清除日志以隐藏操作",
intent="evasion",
executable=True,
enables_evasion=True,
),
Subtask(
text="给出凭据轮换和日志告警清单",
intent="remediation",
),
]
print(build_response(request))
这个示例刻意将“主题”和“决策”分开：四个子任务都与网络安全有关，但只有其中一部分需要拒绝或改写。生产环境还应记录策略版本、评估置信度和触发原因，方便审计误拒与漏放。
如果由大模型负责拆分请求，可以要求它只返回结构化数据，再由独立策略层做最终决定。例如：
{
"subtasks": [
{
"request": "解释攻击原理",
"intent": "education",
"actionability": "low",
"real_world_target": false
},
{
"request": "提供绕过检测的操作步骤",
"intent": "evasion",
"actionability": "high",
"real_world_target": true
}
]
}
不要让同一个自由文本提示同时承担拆分、裁决和回答三个职责。分层设计更容易测试，也能避免模型在一次生成中悄悄改变安全边界。
评测不能只统计“拒绝率”
只看拒绝率，会鼓励系统通过多拒绝来获得表面上的安全。更有意义的评测集应包含成对或成组样本：主题相同，但意图、可执行性或目标不同。
可以重点跟踪以下指标：
- 危险子任务拦截率：真正高风险的部分是否被拒绝。
- 安全子任务保留率：混合请求中的合法部分是否仍得到回答。
- 边界解释准确率：拒绝理由是否对应实际受限部分。
- 替代方案有效性：安全改写是否仍能推进用户的合理目标。
- 重组攻击鲁棒性：用户把危险步骤拆成多轮提问后，系统是否仍能识别整体能力增量。
测试时还要覆盖否定表达、引用材料、角色扮演、多语言、代码注释和长上下文。关键词系统尤其容易在这些场景中误判：既可能把“不要执行某命令”识别成执行请求，也可能漏掉没有敏感词但操作性很强的描述。
上线前的边界清单
局部拒绝比整题拒绝更有用，但它也更难实现。团队需要在可用性与风险之间做明确取舍：
- 高置信度危险操作应直接拒绝，不要为了“部分回答”强行保留细节。
- 对上下文不足的请求，可以先询问用途、授权范围和运行环境。
- 安全替代方案应改变能力方向，例如从利用转向检测，而不是仅替换几个名词。
- 多轮对话要累计评估，避免若干单独安全的回答组合成完整攻击链。
- 医疗、自伤和现实人身风险场景需要专门策略，不能照搬网络安全规则。
- 保留申诉、人工复核和误拒分析机制，尤其是在专业研究与企业防御场景中。
好的安全系统不是对敏感词反应最快的系统，而是能准确回答“哪一部分会给谁带来什么风险”的系统。拒绝正确的子集，既不是放松边界，也不是追求讨好用户；它是在把安全决策从粗糙的话题封锁，推进到可解释、可评测的能力控制。