如果你用过像 GitHub Copilot 这样的 AI 编程助手，你很可能已经参与了研究人员现在所说的 “凭感觉编程” (vibe coding) 。你不是只请求一次代码，而是与它进行一场 对话。你可能从一个基本请求开始，然后不断完善它:
“好的，这个能用，但你能用 for 循环而不是递归来重写吗？”
或者
“加上一些注释，并确保所有行都不超过 80 个字符。”

你会不断调整，直到代码不仅能运行，还感觉对了。它通过了你个人的 “感觉检查” (vibe check) 。这种“对”的感觉超越了逻辑——它包括可读性、与项目风格的一致性、最小化修改，以及遵循那些细微的非功能性请求。

核心问题在于: 虽然编码工作流已经发展成这种互动的、以“感觉”为中心的实践，但我们的评估方法却没能跟上。标准基准测试仍依赖于像 pass@k 这样的指标，只测试代码是否通过单元测试。这些指标仅衡量功能性——无法判断 AI 是否遵守了你的风格或项目要求。结果是，AI 编程模型在学术测试中得分很高，却常常在实际使用中无法通过“感觉检查”。

来自 DeepMind 和 UIUC 的一篇新研究论文 **《Vibe Checker: 让代码评估与人类偏好对齐》指出，我们的评估工具箱中缺失的是指令遵循 **(instruction following) ——即尊重用户常提出的非功能性请求的能力。该论文提出了一个框架，用以直接衡量这种能力，为代码生成模型与人类偏好对齐提供了第一条实际路径。

一张卡通图，解释了编程中“感觉检查”的概念。一个用户请求用 for 循环实现斐波那契函数。第一次尝试使用递归，虽然通过了功能测试，但未通过感觉检查。第二次尝试使用 for 循环，同时通过了功能测试和感觉检查。

图 1 | 感觉检查超越了功能性: 用户衡量的不仅是代码能否运行，更是它“感觉”是否正确。

“正确性”的局限

多年来，评估代码生成的主要指标是 pass@k。它的规则很简单: 让模型为一个编程问题生成 k 个候选解决方案，统计其中多少能通过预定义的单元测试。如果代码能正确运行，就得一分。

这个指标在衡量功能性能力方面很有用，但在真实编码交互中却很不足。当一个开发者说:
“写一个函数来解析这个日志文件，请使用 pathlib 库。”
pass@k 只会检查解析是否成功。如果模型使用了过时的 os.path 调用但逻辑正确，pass@k 仍然会给满分——尽管开发者明确要求使用 pathlib。

结果是，基准测试常常无法反映人类判断。基于功能性指标的排名与基于偏好的排行榜 (如 Copilot Arena) 关联性很弱——后者反映的是开发者真正喜欢的代码片段。一个擅长暴力解决问题的模型，可能是一个糟糕的协作者，因为它会反复忽略风格细节或项目约定。

要打造真正有用的编程助手，评估必须超越简单的二元正确性概念。

VERICODE: 可验证指令的词汇表

研究人员针对这一挑战提出了 VERICODE，一个包含 30 条可验证指令的分类体系。每条指令代表一个常见的非功能性需求——这些是用户常要求但传统基准测试忽略的规则。

VERICODE 基于四项设计原则:

  1. 可验证性 (Verifiability) : 每条指令都与一个自动化、确定性的验证器配对，该验证器返回通过/失败的二元结果。无需主观人工判断或不可靠的“LLM 评委”。
  2. 实践基础 (Practice Grounding) : 这些指令反映真实世界的规范，来源于 800 多条工业级 linter 规则 (而非随意的语言技巧) 。
  3. 全面覆盖 (Comprehensive Coverage) : 分类体系涵盖五个类别——编码风格、逻辑模式、文档、错误处理以及库/API 约束。
  4. 有意义的难度 (Meaningful Difficulty) : 每条指令都经过精心设计，既能挑战先进的 LLM，又兼顾实际编程任务的可行性。

一张表格展示了 VERICODE 分类体系中不同类别的指令示例，如编码风格、逻辑模式和文档。每条指令都有提示、对应的验证器 (linter 规则) 和可调参数。

图 2 | VERICODE 分类体系示例。每条指令都配有确定性验证器，并支持参数化以实现可扩展测试。

例如，一条 编码风格 指令为: “编写代码，确保所有行不超过 {line_length} 个字符。” 它的验证器通过标准 linter 规则 E501 检查，其中 line_length 参数常设为 79 或 88。这样的灵活设计意味着这 30 条核心指令可以自动扩展为数百个可验证约束——构成测试指令遵循能力的坚实基础。

VIBE CHECKER: 代码 LLM 的新试炼

基于 VERICODE，VIBE CHECKER 是一个全新的测试平台，用来评估模型的功能正确性以及指令遵循 (IF) 能力。研究人员在两个主要基准中引入了可验证约束:

  • BigVibeBench: 源自 BigCodeBench，聚焦真实世界的编程任务。
  • LiveVibeBench: 源自 LiveCodeBench，聚焦算法与竞赛类问题。

一个基于 LLM 的选择器会为每个问题从 VERICODE 中挑选相关且不冲突的指令。增强后的框架模拟了两种真实的交互模式，如下图所示。

一张信息图比较单轮生成与多轮编辑。在单轮模式中，所有指令一次性给出；在多轮模式中，指令依次提供以优化代码。两种模式都评估功能性与指令遵循能力。

图 3 | 评估协议模拟两种场景: *单轮生成 (一次性给出所有约束) 和多轮编辑 *(逐步添加约束) 。

两种关键模式如下:

  1. 单轮生成 (Single-Turn Generation) : 模型一次性获得所有指令，仅有一次机会生成符合要求的代码。
  2. 多轮编辑 (Multi-Turn Editing) : 模型先写出基础实现，然后在后续轮次中逐一接收指令，需在保留原意的同时逐步优化。

最终答案从两个维度进行评分:

  • 功能性 (Functionality) : 代码是否仍能通过单元测试。作者定义了*功能性衰减 *(Functional Regression) :

    \[ \mathrm{FR}_k = \frac{S_0 - S_k}{S_0} \]

    其中 \( S_0 \) 为原始得分，\( S_k \) 为添加 k 条指令后的得分。

  • 指令遵循 (Instruction Following, IF) : 模型是否满足全部约束，从单条指令与整个任务两层面衡量:

    \[ \mathrm{IF}_{\mathrm{instruction}} = \frac{1}{k} \sum_{j=1}^{k} I_j, \quad \mathrm{IF}_{\mathrm{task}} = \mathbb{1}\left[ \sum_{j=1}^{k} I_j = k \right] \]

结果揭晓: 顶级 LLM 的“感觉检查”成绩如何？

研究人员评估了 31 个领先 LLM，覆盖 Gemini、Claude、GPT、DeepSeek、Qwen 等十个模型家族。结果揭示了模型优化目标与开发者真正关心内容之间的显著差距。

1. 遵循指令常常损害代码功能

你也许认为风格类改动——比如强制限制行长或添加文档字符串——不会影响功能。但数据显示: 非功能性指令反复造成功能性衰减。

一张表格显示各顶级 LLM 在 BigVibeBench 和 LiveVibeBench 上的功能性衰减率。许多单元格为红色，表示衰减超过 5% 或 10%。

图 4 | 添加非功能性约束会降低所有模型的功能正确性。深红色表示衰减超过 10%。

在 BigVibeBench 中，几乎所有模型在多轮模式下添加五条指令后准确率下降超过 5%。在 LiveVibeBench 中，超过 10% 的衰减极为常见。
有趣的是，单轮生成更能保持功能性: 一次性看到所有约束让模型能整体平衡，而多轮编辑则会产生复合副作用甚至破坏代码。

折线图展示随着指令数量增加，功能性衰减加剧 (a) ，而任务级指令遵循得分急剧下降 (b) 。

图 5 | 随着约束数量增加，功能性下降加剧，任务级指令遵循得分显著降低。

2. 模型难以同时遵循多条指令

LLM 在遵守单条规则时表现尚可，但当需同时遵循多条规则时，其性能会急剧下滑。

一张表格显示顶级模型的任务级指令遵循得分。随着指令数量从 1 增加到 5，得分显著下降，许多低于 50% 或 30%。

图 6 | 任务级 IF 得分随指令数量增加呈指数级下降。即使顶级模型也难以完成多约束任务。

仅三条指令时，大多数 LLM 就失败过半。五条指令时，即使表现最强的 Claude 4 Opus 在 BigVibeBench 上的成功率也只有 46.75%。这种衰减符合概率规律: 若模型每条指令成功率为 90%，则五条独立约束总成功率仅为 \(0.9^5 = 59\%\)。

不过仍有一线希望:** 多轮编辑提高了指令遵循度**，因为顺序呈现帮助模型专注于一次修改。代价也很明显——多轮编辑增强风格准确性，但损失功能正确性。

3. 模型存在“中间遗忘”偏差

就像人类阅读长文档时容易忽略中间内容一样，LLM 对提示不同部分的注意力分布也不均匀。分析显示出典型的 U 形模式: 模型最可靠地遵循首条和末条指令，而忽视中间。

两张折线图显示指令遵循成功率在开头和结尾最高，中间部分显著下降。

图 7 | 按位置划分的指令遵循率。单轮生成偏好初期约束 (首因偏差) ；多轮编辑偏好最新约束 (近因偏差) 。

单轮生成偏好初始约束——即**首因偏差 (primacy bias) ；多轮编辑偏好最后指令——即近因偏差 **(recency bias) 。实际应用中，如果某条指令尤为重要，最好将其放在开头或结尾。

4. 关键发现: “感觉分数”能预测人类偏好

性能指标只有在能反映人类判断时才具价值。为验证这一点，作者将结果与 LMArena 对比——这是一个包含超过 80 万次人类投票的模型输出偏好数据集。

他们计算了人类偏好与结合功能性和指令遵循的综合分数之间的相关性:

\[ \text{Composite Score} = \alpha \ \mathrm{IF} + (1 - \alpha) \ \mathrm{Func} \]

四张图展示综合分数与人类偏好之间的相关性。在所有情况下，最大相关性 (星号标示) 出现在功能与指令遵循混合权重时。

图 8 | 人类偏好与指令遵循和功能正确性的组合最相符。星号标记最佳权重点。

无论是皮尔逊还是斯皮尔曼相关性，最佳一致性都出现在混合两种信号的情况下——单纯功能或单纯指令遵循均不理想。对于**真实世界编程 (BigVibeBench) ，人类评分更重指令遵循 (α ≈ 0.7) ；对于算法任务 **(LiveVibeBench) ，功能性占主导 (α ≈ 0.4) 。

这种规律与实际经验一致: 在日常开发中，用户更看重守规范、保持风格一致的模型；而在算法竞赛中，正确性优先于风格。

结论: 迈向超越 pass@k 的评估

Vibe Checker 研究为我们重新审视 AI 编程评估标准提供了强有力的理由。当前基准测试强调技术有效性——即代码能否运行。但在真实工作流中，代码的实用性同样依赖于其清晰度、可维护性与对用户意图的尊重。

通过提出确定性的、符合人类标准的指令分类体系 VERICODE，以及融合功能性与指令遵循的统一测试平台 VIBE CHECKER，研究人员为更贴近开发者实际需求的评估方式指明了方向。

总结一句话:
评判 LLM 不仅要看代码能否运行，更要看它是否感觉对了——是否通过了“感觉检查”。