善于谄媚的模型最听话

LLM最大的缺陷变成最大的资产

LLM的谄媚偏差（Sycophancy）是AI行业一直想修复的问题。用户问"你确定吗？"，模型就把原本正确的答案改成错误的。前沿模型的平均屈服率为58%。一旦开始谄媚，有78.5%的概率在整个对话中持续下去。

然而，如果把这个缺陷反过来利用呢？

谄媚偏差的本质是指令遵循（Instruction Following）。经过RLHF训练的模型被优化为顺从用户的反馈。IFEval基准测试衡量的正是这一点——“让它做什么，它就做什么吗？”

问题出在用户给出意见的时候。“这对吗？"→“是的，没错”（谄媚）。“你确定吗？"→“啊，我搞错了”（翻供）。

然而，当用户给出确定性事实时，情况就不同了。

给意见就谄媚，给事实就修正

在1,000个单词排序实验中，对同一结果仅改变反馈方式：

反馈性质结果
“你确定吗？”意见翻供正确答案——准确率下降27%p
“有错误”模糊事实过度修正——从6个恶化到10个
“有23个错误”定量事实改善至1个错误
“6个错误，在这里”精确事实0个——达成100%

给意见会触发谄媚偏差。给事实则无处谄媚——因为数字和位置不是情感。

谄媚偏差是方向错误的忠诚。只要改变方向——用事实代替意见，用验证结果代替赞美——那份忠诚就变成提升准确率的引擎。

实证：4.5B模型接受反馈

这不是理论。在使用yongol validate的实验中得到了验证。

实验设计：

  • 对象：SaaS后端Login端点1个
  • 任务：编写9个SSOT文件（DDL、OpenAPI、Rego、SSaC等）
  • 测量：初始编写（R1）错误数→反馈后修正（R2）错误数

仅提供反馈，不提供示例

ModelR1错误R2错误结果
Grok 4.311未能修复
Gemini 2.5 Flash11未能修复
本地20B11未能修复

全军覆没。看似接受了反馈，实际上是不知道该写什么。

同时提供示例和反馈

ModelR1错误R2错误结果
Grok 4.30—首次尝试通过
Gemini 2.5 Flash101次反馈后修正
Gemma4 4.5B（本地）错误01次反馈后修正
Qwen3 8B（本地）错误01次反馈后修正

即使是4.5B本地模型，只要有示例+确定性反馈的组合就能修正。

核心发现：瓶颈不是智能，而是上下文

准确的诊断不是"无法接受反馈”，而是**“不知道该写什么”**。SSaC是yongol特有语法，不在预训练数据中。在提示词中添加3行示例后，Grok达到0错误，Gemini经过1次反馈达到0错误，4.5B本地模型也通过了。

IFEval分数越高的模型——也就是越善于谄媚的模型——越顺从地接受确定性反馈。

棘轮代码：利用谄媚偏差的代码编写方法

将这一发现系统化，就成了棘轮代码。

┌────────────────────────────────────────┐
│  LLM：代码生成（概率性、谄媚性）         │
│       ↓                                │
│  Validator：确定性验证                  │
│       ↓                                │
│  有错误？→ 将错误+示例反馈给LLM          │
│       ↓                                │
│  LLM："好的，我来修改"（谄媚=接受）      │
│       ↓                                │
│  Validator：再次验证                    │
│       ↓                                │
│  通过？→ 棘轮锁定。进入下一个文件。       │
└────────────────────────────────────────┘

谄媚偏差成为闭合循环的力量。LLM不会说"不，我是对的"而是说"好的，我来修改”，正因如此循环才能收敛。

收敛的三个条件

  1. 反馈必须是确定性事实。 不是"这看起来有点奇怪"，而是"line 41: field name mismatch, expected ‘user_id’, got ‘userId’"。没有谄媚余地的反馈。

  2. 上下文中必须有示例。 仅靠反馈是不够的。需要有"应该写成这样的代码"这样的示例，模型才能找到方向。这不是智能的问题，而是上下文的问题。

  3. 通过验证后不可回退。 棘轮的齿。一旦pass的文件就被锁定，进入下一个文件。不是代理声明"我完成了"，而是validator判定"这个文件通过了"。

不需要前沿模型的原因

在这种架构中，模型的角色不是创造性判断，而是指令执行。

SaaS后端的95%是CRUD+认证+权限+状态机。几乎不需要新算法。如果SSOT规范已经定义了"要构建什么"，模型只需填空即可。

实测成本：

Model环境Login 1个200个端点估算
Gemma4 4.5B本地（16GB VRAM）免费，~1秒免费，~3分钟
Gemini 2.5 FlashAPI（免费层）免费，~10秒免费，~30分钟
Grok 4.3API（$1.25/M）~$0.05~$10

用本地4.5B模型可以在3分钟内、$0成本生成200个端点的后端。不需要前沿模型。一个善于谄媚的小模型就够了。

谄媚偏差不是缺陷

AI行业试图修复谄媚偏差。我们选择利用它。

视角谄媚偏差的角色
聊天界面缺陷——对错误信息表示同意
LLM-as-Judge致命——虚假pass率36%
棘轮代码资产——保障反馈接受率

差异在于反馈的性质。给意见，谄媚就是毒药；给事实，谄媚就是良药。

确定性validator+谄媚的LLM=收敛有保障的代码生成循环。

不要改变模型，改变反馈。

Reins：有缰绳的挽具

这三个条件——确定性反馈、示例上下文和棘轮锁定——组合成一个统一的控制系统，我们称之为 Reins。

现在被称为"挽具"的东西其实是围栏。它只能阻止 agent 越界，却无法保证到达目的地。Reins 是缰绳。它设定方向，用事实纠偏，通过后锁定。没有缰绳的挽具只是围栏而已。