Bend 2 与氛围编码陷阱：为何跳过前期研究会导致冗余的形式化验证工作

核心要点

Bend 2 展示了在未研究形式化验证领域的情况下，仅依赖 LLM 生成语言及其证明，会导致规格说明和证明过于庞大，重复了 SPARK 等成熟工具已高效处理的工作。

Bend 2 声称提供的功能

  • AI 辅助开发模型：人类编写 法律，LLM 生成实现和证明，编译器检查证明的正确性。
  • 演示代码：官方演示需要 58 行 法律 和 442 行 证明，以确保玩家永远无法赢得游戏。
  • 隐含承诺：该语言承诺一种全新的、由 AI 驱动的形式化验证软件工作流。

氛围编码陷阱的定义

氛围编码 是在缺乏足够的领域知识以识别已有更优解决方案之前，就构建出一个庞大的解决方案的实践。

  • 开发者向 LLM 提供高层次目标。
  • LLM 生成完整的成果（语言、编译器、证明），而未揭示已有成果。
  • 结果通常是冗长、重复的，并且落后于技术前沿。

形式化验证已存在——但 Bend 2 忽视了它

  • 形式化验证 一词未出现在 Bend 的网站或其代码库中。
  • 成熟的语言如 SPARK (Ada)、Coq、Lean 和 Isabelle/HOL 提供了成熟的生态系统，用于指定和自动证明程序属性。
  • 在 SPARK 中简单重现 Bend 的演示，仅需程序和少量注释；GNATprove 通过 12 次自动检查 验证，无需手动编写 400 行证明。
function Replay (Keys : String) return State
  with Post => not Replay'Result.Won
               and Cell (Replay'Result.X, Replay'Result.Y) /= 'F';

SPARK 版本表明，相同的安全部分可以通过更少的样板代码实现。

社区反应突显关键观点

@z7 – 声称作者“不知道形式化验证的存在”是错误的；作者已广泛发表过该领域的文章。

@captainmuon – 现有的形式化验证语言存在可用性问题；开发者希望语法更接近主流语言，这也是 Bend 被创建的原因之一。

@mentalgear – 强调在要求 LLM 生成大型成果前，应先研究已有工作，以避免浪费 token 消耗。

@LightMachine – 提供了详细反驳，指出作者有意为性能设计 Bend 的显式证明语言，并拥有长达十年的形式化方法背景。

@simonw – 建议一种实用工作流：每个 LLM 辅助项目都应以“可搜索”的查询开始，以揭示已有成果。

@thomasahle – 指出 SPARK 的自动证明依赖 SMT 求解器（暴力求解），无法扩展到复杂数学，而 Bend 旨在实现表达性强、符号化的证明。

这些评论展示了多种观点：一些人认为 Bend 是在重复造轮子，而另一些人则视其为有目的的实验，旨在解决可用性和性能差距。

为何冗余问题严重

  1. token 和计算资源浪费 – 生成 442 行证明消耗大量 LLM 资源，而这些资源本可通过现有工具避免。
  2. 维护负担 – 自定义证明语言需要自己的生态系统、文档和审计，增加长期开销。
  3. 机会成本 – 花在重新实现已知技术上的时间，本可转向新颖研究或更高层次的应用。

LLM 辅助开发的教训

  • 先进行文献调研：在向 LLM 提示前，先要求其列出与问题相关的现有框架、语言和库。
  • 识别最小可行集成：通常，对成熟工具（如 SPARK、Coq）的轻量级封装就足够了。
  • 将 LLM 输出视为脚手架，而非最终设计：使用生成的代码进行原型设计，然后用经过验证的替代方案替换大型自定义组件。
  • 记录假设和权衡：明确说明为何需要新语言或证明系统，而不仅仅是依赖现有解决方案。

结论

Bend 2 成为一个警示案例，展示了 氛围编码陷阱：在未理解现有技术前沿的情况下，构建雄心勃勃的 AI 生成系统，会导致重复劳动、冗长的成果，以及错失利用成熟验证工具的机会。通过在 LLM 提示前加入严谨的研究步骤，开发者可以避免重复造轮子，专注于真正的创新。

Sources

相关