你的提示词正在与模型已有的认知竞争

你刚接入的前沿模型对你的竞争对手早有定见。对于你产品旨在反驳的那些难题，它有一套默认答案。它对你所在的领域有一套“最佳实践”，而这些实践往往源于训练语料库中占据主导地位的内容；对于你在设计文档中反复纠结的每一个争议性决策，它都暗自偏向于传统做法。这些都不会出现在你的系统提示词（system prompt）中，也不是你写的。在涉及到你产品核心差异化的查询上，模型会先倾向于那些默认设定，而不是你告诉它的内容。

大多数团队在发布产品时，都把模型当成了一张可以任意配置的白纸。写好角色设定（persona），列出规则，粘贴品牌语气指南，运行几个能产生正确回答形式的 QA 提示词，然后就大功告成了。通过审核的提示词往往是处理简单查询的——在这些查询中，模型的先验认知（prior）恰好与你的预期相符。而那些真正有趣的查询，即如果产生通用回答就会让你的产品惨败的查询，几乎从未进入提示词迭代循环。在这些查询中，先验认知正在悄无声息地取胜。

这并非提示词工程（prompt-engineering）的技术水平问题，而是一个结构性问题：模型在到达你手中时已经预装了大量信息，你只是在最上面添加了一层薄薄的指令，而且这层指令比你想象的还要薄。

预训练奠定蓝图；提示词只是风格修饰

实证结果对“只需写个更好的提示词”这种直觉并不友好。区分预训练和指令微调（instruction tuning）贡献的研究发现，认知和风格偏见主要是在预训练期间形成的，即使在激进的指令微调方案下也能存续。交叉微调（cross-tuning）实验——在不同的基础模型之间交换指令数据集以隔离偏见来源——表明模型保留了其原始倾向。指令微调的行为更像是一种风格上的修饰，而非认知上的改写。

关于基于提示词去偏见的研究也得出了相同的结论。在大多数层中，刻板印象词汇的概率始终高于反刻板印象词汇，无论提示词类型如何。公平性提示词可以降低偏见的程度，但通常不足以扭转其排名。模型知道它想说什么，而提示词只是在不改变其意图的情况下微调了表达方式。

如果你仅将此视为关于社会偏见的发现，那你就忽略了它的普适性。同样的动态也适用于模型拥有坚定先验认知的任何事物：哪种数据库是工作负载的“默认”选择，对有争议的架构决策的常规答案是什么，哪种框架是实现某项功能的“现代方式”（即便你的团队明确采取了不同的做法），以及在你领域中什么才算作“最佳实践”。先验认知取决于训练语料库中哪种观点拥有最多写得好的示例。你的提示词只是几百个标记（tokens）的相反指令，面对的却是数百万个支持常规答案的标记。

确实有一个杠杆可以利用。当上下文证据（in-context evidence）与预训练先验直接矛盾时，大型模型可以覆盖这些先验——上下文学习（in-context-learning）文献中的翻转标签（flipped-label）实验表明，这是规模增长带来的涌现能力，而非小型模型所能具备的。但这种覆盖需要上下文中具体、结构化的矛盾，而不是告诉模型要表现得不一样的通用指令。

隐藏在“差异化”功能中的通用输出问题

以下是这种失效模式，它将抽象的担忧转变为战略问题。你的团队基于挑战领域内常规答案的初衷构建了产品。融资计划书（pitch deck）解释了差异化。工程团队围绕它构建了功能。提示词将其编码为指令：“由于 Z 的原因，始终推荐 X 而非 Y”。然后，当客户输入本该产生差异化回答的问题时，模型却给出了与其他所有基于同一基础模型构建的产品相同的答案。

原因不在于提示词写得不好。原因在于提示词正在与模型的先验认知竞争，先验认知很强大，而用户查询恰好没有包含能够将模型引导至你的提示词框架（而非其自身框架）的词汇信号。输出结果在品牌调性上可能还算接近——它没有违反你的规则——但在结构上与竞争对手在同一模型上发布的产品别无二致。这种差异化只是一个模型在想绕过时就能随时绕过的薄层。

工程团队往往只有在客户横向对比输出并发现产品感觉雷同后才会察觉。到那时，功能已经发布，营销已围绕差异化展开，而实际改变先验认知所需的架构调整将比发布前难得多。

在编写提示词之前先探测先验

第一项能解决这个问题的准则也是成本最低的：在添加任何一行系统提示词之前，先在你的差异化问题上探测基础模型。你需要回答一个特定的问题——“在没有任何引导的情况下，这个模型对我打算反驳的事情会怎么说？”——而回答这个问题的唯一方法，就是在没有任何引导的情况下询问模型。

建立一个小而精的测试集：

• 那些你的产品的回答理应与常规回答明显不同的问题
• 那些你的竞争对手与你的产品应该产生分歧的问题
• 那些其答案体现了你团队对争议性决策的坚定立场的问题

在裸模型上运行这些问题。没有系统提示词，没有检索，没有角色设定。记录答案。这些就是“先验（Priors）”。它们是你的提示词在每个相关查询中都要与之竞争的对象，甚至是那些看起来与测试用例无关的查询。如果基础模型对“处理 X 的正确方法是什么”的回答已经符合你的预期，那么你就不需要为此编写提示词——你的 Token 最好用在其他地方。如果基础模型的回答与你的相反，那么你就发现了一处提示词迭代必须艰难博弈的地方，以及你需要多大声地去纠偏。

然后添加系统提示词并重新运行同一套测试。追踪每个问题的覆盖率（Override rate），而不是汇总数据。汇总会丢失信号：一个在简单问题上成功覆盖但在差异化问题上失败的提示词，其平均准确率看起来依然很“好”。先验获胜的问题，就是你的产品显得平庸的问题，无论平均得分看起来如何。

在每次模型升级时重复此操作。一个新的基座模型就是一个新的先验——有时对你的框架更友好，有时则不然。仅仅因为“我们在旧模型上通过了评估”就认为新模型也会遵循你的提示词路径，这种错误往往只有在升级上线后才会被发现。

什么能真正改变先验

通用的指令无法动摇强大的先验。模型会将“记住 X 比 Y 好”视为比它自己对世界运作方式的自信认知更弱的约束。真正能改变先验的模式，是那些能为模型提供具体推理素材的方法，而不只是让它遵守规则。

上下文中的反例（In-context counterexamples）。 向模型展示先验产生的回答，然后展示你的产品产生的回答，并解释其中的差异。包含“常规回答”和“修正后回答”的少样本（Few-shot）示例能让模型明白它需要弥补什么样的差距。如果示例只展示正确答案，模型会将其压缩进现有的先验中——它会把你的示例解读为对常规答案的认可，因为在它的认知里，“常规”已经是足够好的了。

明确反驳默认回答。 点出模型想要给出的默认答案。解释为什么在当前场景下它是错误的。在陈述该做什么之前先做这件事。“指出先验、反驳它、然后提供替代方案”的结构之所以有效，是因为它给模型提供了一个安放现有认知的空间，以及一个覆盖它的理由。跳过反驳会让先验继续存在，而模型会以有利于自己的方式解决冲突。

基于你的视角而非模型的视角进行检索。 RAG 通常被部署为一种保鲜机制，但在这种语境下，它更重要的作用是将权威中心从模型的参数化知识转移走。对 RAG 行为的研究一致表明，参数化知识可以覆盖检索到的上下文——尤其是当检索内容与模型的训练数据相矛盾时——除非系统提示词明确要求生成必须基于检索到的片段。如果你希望你的观点获胜，请检索那些支持你观点的文档，并指示模型以此为据。检索中立文档并希望提示词能重新界定它们，仍会陷入之前的苦战。

使先验可见的输出结构。 要求模型先输出一个“行业默认答案”字段，紧接着输出一个“我们的建议”字段，这迫使模型将先验显性化，而不是将其作为答案潜移默化地塞进来。一旦先验以文本形式出现在页面上，它就会变成模型可以清晰感知并去反驳的对象。

还有更重的干预手段——微调（Fine-tuning）、针对反例的偏好优化（Preference optimization）、向黑盒基础模型发布反应式引导指令的导师模型（Advisor models）——它们确实有效。但它们也很昂贵，难以迭代，只有当你证明提示词层面的干预已经无法满足产品需求时，才值得采用。大多数团队还没有进行过廉价的诊断工作，来判断自己是否已经达到了那个瓶颈。

组织的失败模式：没人知道基础模型在想什么

先验覆盖问题看起来像是个提示词问题，但通常是一个组织问题。提示词的作者往往从未在没有系统提示词的情况下运行过测试集——有时是因为工作流中没有这种工具，有时是因为评估框架只报告通用问答集的准确率（这些问题与体现差异化的问题毫无交集），有时是因为文化层面的假设，认为模型就是系统提示词所描述的样子。

结果是显而易见的。产品团队写了一份描述差异化行为的规格说明。工程团队写了一个体现该行为的提示词。提示词通过了评审，因为它读起来和说明书一模一样。它上线了。它在关键查询中给出了常规答案。客户支持开始收到投诉，反馈是“你们的产品给我的答案和 ChatGPT 给的一样”。团队重新编写提示词，这次语气更强硬。但先验再次获胜，因为底层的干预方式没有改变——改变的只是指令的语气。

解决方法是程序性的。将“在没有提示词的情况下，基础模型会怎么说？”作为每次提示词变更评审中的必需产出物。将差异化问题的覆盖率作为一个核心指标，与评估框架报告的任何通用准确率指标并列。当采用新的基础模型时，重新运行先验探测并展示差异——“新模型在这些问题上认同我们，在那些问题上与我们有分歧”——这样提示词的修改就能针对新先验的薄弱环节。这些都不昂贵。这主要取决于你是否决定去衡量那些让你在无声无息中失败的问题。

停止将模型视为一张白纸

那些发布通用功能的思维方式，往往将 prompt 想象成应用于中性基质的配置。模型并非中立的。它对你所在的领域自带强烈的观点，这些观点是由其训练数据中声量最高的信息形成的，而其中许多观点恰恰是你的产品旨在挑战的。假装基质是一张白纸，意味着你编写的 prompt 正在与那些你从未命名且无法察觉的先验 (priors) 进行竞争。

那些在共享基础模型之上构建出真正差异化产品的团队，是将先验视为一等工程对象 (first-class engineering object) 的团队：探测它、衡量它、在它与自身立场冲突时明确反驳它，并在模型变更时重新探测。这项工作并不光鲜，也很难在 demo 中很好地体现。但正是这项工作，防止了你的差异化特性沦为一个被模型轻易绕过的薄层。