当我们谈论大语言模型的编程能力时，通常会想到 HumanEval、MBPP 这类基准 —— 它们测试模型能否根据自然语言描述写出可执行的 Python、JavaScript 代码。然而，这些基准有一个根本局限：它们依赖现代编程语言丰富的内置特性（数组索引、循环语句、显式状态），无法真正评估模型的形式化推理能力。Lambda 演算作为计算理论的基础模型，要求模型在没有任何外部依赖的情况下，仅通过 lambda 抽象和应用规则实现算法。这正是 LamBench（Lambda Calculus Benchmark for AI）想要量化评估的核心能力。
基准设计与任务格式
LamBench 由 Victor Taelin 构建，托管于 GitHub 仓库 VictorTaelin/LamBench，实时结果发布在 victortaelin.github.io/lambench/。该基准包含 120 道纯 Lambda 演算编程题，每道题要求模型用一种极简的 Lambda 演算方言 Lamb 编写程序。
每道题目提供三个核心组件：问题描述（用自然语言说明需要实现什么算法）、数据编码规范（说明如何用 Lambda 编码表示常用数据结构如列表、树、数字）、以及测试用例（输入输出对）。模型需要返回一段定义 @main 函数的 .lam 文件，程序被执行后若通过所有测试用例，则视为该题解决。值得注意的是，评测采用单次尝试（one-shot）模式：每个问题每个模型只运行一次，不允许重复提交或迭代调试。
这种设计有意模仿了「考试」场景 —— 模型需要在有限信息下一次性给出正确解答，而非像实际编程辅助中那样通过多轮对话逐步完善代码。正因为如此，LamBench 成为了区分模型在高压环境下推理能力的试金石。
Lamb 语言与数据编码
要理解 LamBench 的难度，需要先了解 Lamb 的极简特性。Lamb 是一种纯 Lambda 演算语言，语法仅包含变量、lambda 抽象（\x. t）和应用（t u），没有任何内置的数据类型或原语操作。这意味着模型必须自行用 Lambda 编码（Lambda Encoding）表示所有数据结构和运算。
以最基础的 Church 数为例，自然数 n 被编码为接受两个参数（一个函数 f 和一个初始值 x）的高阶函数：n = \f. \x. f (f (... (f x) ...))，即 f 被应用 n 次。列表则可以编码为 fold 操作：list = \c. \n. c head (c head2 (c head3 ... n))。这种编码方式虽然理论上是完备的，但实现具体算法时需要大量技巧 —— 例如在 Lambda 演算中实现「取列表第 n 个元素」需要遍历整个列表，时间复杂度从 O (n) 退化为 O (n²)。
基准中使用的编码方式包括 Church 编码、Scott 编码、以及平衡三进制数系统（Balanced Ternary Numerals）。任务难度差异很大：从简单的自然数加法、列表反转，到复杂的归并排序、快速傅里叶变换（FFT），乃至实现一个完整的 Lambda 演算求值器。FFT 任务尤其引人注目 —— 所有模型在此题上均告失败，原因是纯 Lambda 演算中没有显式的数组索引，必须用 Church 树编码配合特定的数系才能高效实现 Cooley-Tukey 算法，这超出了当前模型的能力边界。
评测指标与结果分析
LamBench 采用三个维度评估模型表现：
完成率（Completion Rate）是最核心的指标 —— 模型在 120 题中成功解决的数量占总题数的比例。这一指标直接反映模型的算法实现能力上限。截至 2026 年 4 月的公开结果显示，顶级模型（OpenAI 的 GPT-5 系列、Anthropic 的 Opus 系列）完成率约在 85% 至 95% 之间，而大多数开源模型完成率低于 50%。有趣的是，模型之间的差距主要体现在「难题」上 —— 简单题大多数模型都能完成，真正拉开差距的是那些需要创造性使用 Lambda 编码的复杂算法题。
解法优雅度（Elegance）通过解法程序的 Lambda 表达式大小衡量。在相同功能的前提下，更短的解法被认为更优雅。这一指标反映了模型对问题本质的理解深度 —— 能否找到最简的编码方式，而非机械地翻译既有代码。顶级模型不仅能解决问题，还能给出较为紧凑的解法。
求解速度记录模型生成解法并通过测试所需的时间。由于所有模型在单次尝试模式下运行，速度差异主要反映在生成 Token 数量的多少（更长的解法需要更长时间生成）和推理开销上。
从 Hacker News 的讨论中可以看到几个关键洞察。首先，模型之间的差距主要体现在复杂算法题上 ——FFT 实现、全排序、树遍历等任务将顶级模型与普通模型明显区分。其次，评测方式的微小变化会导致结果显著不同：最初使用 Codex 运行时，GPT-5.5 表现弱于 GPT-5.4，但切换到 API 运行时，GPT-5.5 反而登顶。这提示我们，底层执行环境的差异可能影响模型能力的呈现。此外，有评论者指出，对于非确定性的 LLM，单次尝试可能无法准确反映其真实能力 —— 运行 30 到 45 次可能更能逼近模型的能力上界。
工程化启示与参数配置
从系统构建的角度，LamBench 为我们提供了若干可复用的工程参数。首先是任务粒度设计：120 道题是一个平衡点 —— 足够覆盖多种算法类别，又不会因为题量过大而导致评测成本过高。每个类别的题目数量应保证至少 5 至 10 道，以便区分不同能力的模型。
编码规范的一致性至关重要。LamBench 明确规定了数据结构的编码方式，避免了歧义。如果要在其他领域构建类似的形式化推理基准，应在题目前半部分提供充分的编码示例，降低模型的试错成本。
测试框架的执行环境需要严格标准化。Lambda 演算的解释器必须行为一致，建议使用确定性求值策略（如正则序或应用序必须明确指定），并在评测文档中声明。当前 LamBench 的一个争议点在于不同运行方式（Codex vs API）导致了不同的结果，这提示我们在构建基准时需要明确指定执行环境，甚至考虑提供容器化的标准运行环境。
对于超时和资源限制，参考参数为：单题执行时间上限 30 秒、内存上限 512MB、Lambda 表达式求值步数上限 10 万步。这些阈值确保评测在可控成本内完成，同时不会因为过度宽松而遗漏真正的能力缺陷。
基准的局限性与改进方向
LamBench 当前的局限之一是单次尝试模式的合理性争议。LLM 本质上是概率模型，其输出具有方差。有研究者建议，每个问题应该运行 5 到 15 次，统计通过率而非仅看是否通过一次。这种方式更能反映模型的真实能力分布 —— 通过率 80% 意味着模型平均每 5 次能成功 4 次，而通过率 20% 则意味着模型极不稳定。
另一个改进方向是引入多步骤推理。当前的 one-shot 模式虽然考核了模型的最终代码能力，但无法观测其推理过程。如果允许模型输出推理步骤（如先实现辅助函数、再组合为最终解法），可以更好地分析模型在何处卡住，从而针对性地改进训练数据或架构。
此外，题目难度的动态调节也是值得探索的方向。目前的 120 题是固定，模型只能在此集合内表现。可以设计自适应机制 —— 模型如果在前几题表现优异，则展示更难的题目；表现一般则提供中等难度题目，从而更高效地探测模型的能力边界。
资料来源
基准官方 GitHub 仓库：https://github.com/VictorTaelin/LamBench
实时评测结果：https://victortaelin.github.io/lambench/
Hacker News 讨论：https://news.ycombinator.com/item?id=47900506