大模型“防御性写作”的成因与治理实践

一、问题的提出：当回答开始“防御”

在日常使用大语言模型进行技术问答、资料整理或方案撰写时，许多开发者都会遇到一种令人困扰的现象：模型的回答本身未必错误，但充斥着大量与问题无关的铺垫、声明和免责话术。典型表现包括：

• 对比式框架：你问 A，模型先来一句“这不是 X，而是 Y”，而 X 和 Y 你都没有提及。
• 假想误用防御：你只想让它解释一个概念，它却在结尾补上一段“需要注意的是，这并不意味着……”，提前防范一种你从未提出的误读。
• 未请求的行为声明：你让它写一个方案，它开头先声明“我不会做某某事”，可你压根没让它做那件事。
• 来源自证：反复强调“这不是我临时编造的”，试图为信息的可靠性背书。

单看每一句，似乎都不算错，甚至可以说是“严谨”。但当这些句子堆叠在一起时，读者的体验就像面对一位随时准备免责的客服：我要的是信息，不是风险告知书。这种现象，可以统称为大模型的防御性写作（defensive writing）。

防御性写作的本质，是模型在训练与对齐过程中形成的过度保守倾向。它并非模型能力不足，而是行为策略偏离了用户的实际需求。本文将从成因分析入手，结合提示工程与行为约束的实践，探讨如何系统性地治理这一问题。

二、成因分析：防御性写作从何而来

要治理防御性写作，首先需要理解它的来源。从技术角度看，这一现象至少有以下几方面成因。

2.1 对齐训练的副作用

在大模型的对齐阶段，训练目标通常包含“有用性”和“无害性”两个维度。当无害性被过度强调时，模型会倾向于在任何可能产生风险的场景下主动添加限制性声明。这种策略在安全敏感场景中是必要的，但会被泛化到大量本不需要防御的普通问答中。

2.2 对比式框架的语言惯性

“不是 X，而是 Y”这类句式，在人类写作中本是一种强调手法。模型在预训练语料中大量接触此类表达后，会将其作为解释概念的默认模板。问题在于，这种句式引入了一个用户未提出的替代项 X，反而增加了认知负担。

2.3 假想风险的过度泛化

模型在生成回答时，会隐式预测“用户可能如何使用这个回答”。当预测到任何潜在的误用路径时，模型倾向于提前堵住漏洞。这种机制在开放域对话中会表现为大量“需要注意的是”“这并不意味着”之类的补充说明。

2.4 缺乏明确的输出风格约束

在许多应用场景中，开发者只给出了内容层面的指令，而没有对输出风格做出约束。模型在缺乏风格指引时，会退回到训练分布中最“安全”的表达方式，而这种方式往往就是防御性的。

三、治理策略：从提示约束到行为替代

针对上述成因，可以从提示工程层面设计一套约束与替代方案。核心思路是：不仅禁止防御性表达，还要给出明确的替代动作。仅仅禁止句式，模型可能会陷入不知所措或换一种方式防御；只有同时提供正向指引，才能真正改变输出行为。

3.1 直接陈述意图，避免预告否定

在系统提示或自定义指令中，应明确要求模型直接陈述将要执行的动作，而不是预告不会做什么。例如：

直接说明你要做什么；
不要预告你不做什么；
不要声明哪些内容将保持不变。

这一约束的作用，是切断模型“先声明边界、再给出内容”的默认路径。当模型不需要为未发生的风险负责时，回答会自然变得更紧凑。

3.2 禁止对比式框架，改用直接功能陈述

对比式框架的治理，需要给出明确的替代方案。推荐的做法是要求模型使用直接的功能性陈述，即描述某事物“是什么”，而不引用它“不是什么”。

不要使用“不是 X，而是 Y”这类引入用户未提问的替代项的框架；
改用直接的功能性陈述，描述某事物是什么，而不引用它不是什么。

例如，当用户问“什么是向量数据库”时，防御性回答可能是“向量数据库不是传统的关系型数据库，而是……”。而直接的功能性陈述则是“向量数据库是一类针对向量相似度检索优化的数据存储系统，其核心能力包括……”。后者的信息密度明显更高。

3.3 限制主动免责声明，明确补充边界

免责声明并非完全不能出现，关键在于设定触发条件。可以借鉴的思路是：只有当补充内容直接针对用户实际提出的内容、防止实质性事实错误或出于安全必要时，才允许添加。

除非补充内容直接针对我实际说过的内容、能防止实质性事实错误，
或出于安全必要，否则不要添加预防性免责声明、注意事项或纠正。
不要反驳我并未提出的假设。

这条约束的价值在于，它把“是否补充”的判断标准从模型的假想风险，转移到了用户的真实输入上。

3.4 约束的层次化设计

在实际工程中，建议将上述约束组织为层次化的提示结构：

层次	目标	示例约束
内容层	确保信息准确	基于事实回答，不确定时明确说明
风格层	去除防御性表达	直接陈述意图，禁止对比式框架
边界层	限定补充条件	仅在直接相关或安全必要时补充
替代层	提供正向模板	使用功能性陈述描述事物本身

这种分层设计的好处是，每一层职责清晰，便于在调试时定位问题。如果回答过于冗长，可以检查风格层；如果回答遗漏了必要警告，可以检查边界层。

四、工程落地：将约束融入对话系统

在真实的对话系统中，上述约束不应只写在一次性的提示里，而应作为可维护的配置项管理。

4.1 系统提示的模块化

建议将风格约束拆分为独立的提示模块，与角色设定、任务指令分离。这样在切换任务时，风格约束可以复用，避免重复维护。例如：

STYLE_CONSTRAINTS = """
- 直接陈述你要做什么，不要预告你不做什么。
- 不要使用“不是X，而是Y”的对比式框架。
- 除非直接相关或安全必要，不要添加免责声明。
- 使用功能性陈述描述事物本身。
"""
def build_system_prompt(role, task):
    return f"{role}\n{task}\n{STYLE_CONSTRAINTS}"

4.2 输出后处理与检测

除了提示约束，还可以在输出侧增加轻量检测。例如，对回答中出现的对比式框架、免责声明关键词进行统计，作为质量监控指标。当某类表达的出现频率超过阈值时，触发提示调优。

需要注意的是，后处理应避免简单粗暴的字符串删除，否则可能破坏语义。更稳妥的方式是将其作为反馈信号，用于迭代提示设计。

4.3 效果评估

治理防御性写作的效果，可以从以下维度评估：

• 信息密度：单位字数内有效信息的比例。
• 首句相关性：回答的第一句是否直接回应问题。
• 冗余声明比例：免责、自证、假想防御类句子的占比。
• 用户满意度：通过人工评估或反馈信号衡量。

这些指标可以帮助团队量化改进效果，避免仅凭主观感受判断。

五、总结与展望

防御性写作是大模型对齐过程中的一种典型副作用，其根源在于安全策略的过度泛化、对比式语言惯性以及缺乏明确的风格约束。治理这一问题的关键，不在于简单禁止某些句式，而在于同时提供正向的替代方案：直接陈述意图、使用功能性描述、限定补充边界。

从工程角度看，将风格约束模块化、可配置化，并结合输出侧检测与效果评估，是可持续的落地路径。随着大模型在开发辅助、技术问答等场景中的深入应用，输出风格的精细化控制将变得越来越重要。让模型回答得更直接、更可信，不仅是用户体验问题，也是提升信息获取效率的工程问题。