一篇叫《Why vibe code in Lisp?》的博客最近被小范围转发,作者是一位写了几十年Common Lisp的老程序员。他给出八条理由,说明用AI辅助编程时,该把生成目标定在Common Lisp而不是Python、TypeScript或Java。这套说法听起来很硬核:同像性、宏系统、REPL、条件系统,每个词都能唤起老Lisp黑客的骄傲。但翻遍能查到的资料,没有一份严格的跨语言基准测试验证过这些理由——支持这套论断的,目前只有经验和信念。
八条理由,一个共同漏洞
压缩一下原文核心主张:作者数十年经验能一眼判断AI是否在瞎写;Lisp是高层抽象语言,AI不用跟样板代码搏斗;同像性让LLM直接操作AST而不是表面语法;宏系统把重复样板压进宏里省token;REPL让AI能实时内省、活体调试;条件系统比崩溃重启更优雅;改一行代码不用重启整个程序。
每条听着都成立,问题是没有一条被验证过。已有的跨语言基准(比如MultiPL-E)确实发现不同语言下模型表现差异明显,Python也不总是最优语言——但这些研究从没把"同像性"单独拆出来当变量测过。原文的八条理由,是一套逻辑自洽的假设,不是被证明的结论。
同像性没有那么神
最有分量的一条,是"LLM操作Lisp时直接预测AST结构,不用管样板语法"。这句话拆开看有个漏洞:LLM本质上在预测token序列,不是直接操作语法树对象。同像性想变成真优势,前提是有reader、宏展开器、编译器这些工具接入智能体,让模型输出真正落到结构层面,而不只是"括号比大括号好猜"的表面便利。
这层前提原文完全没提。更麻烦的是,Python和TypeScript早有功能相近的东西:Python的ast模块能把源码解析成AST对象、做变换、再编译回去;TypeScript的编译器API能暴露AST节点、符号和类型信息,给仓库级代码修复提供比语法一致性更有用的信号。结构级编辑不是Lisp的专利,只是Lisp把它内建在语言本身,Python、TypeScript要靠额外工具补上。
语料稀缺,才是被回避的那部分
原文没说的另一件事:Common Lisp在主流大模型的训练语料里,token出现频率明显低于Java、Python、TypeScript。这不是语言设计问题,是资源问题。一份基准调查发现,被考察的代码生成基准里超过九成涉及Python——训练和评测资源几乎全堆在几门主流语言上。这直接决定了同一个模型在"开箱即用"场景下,生成Python代码的准确率天然高于生成Common Lisp代码,跟语言优雅与否没关系。
语言设计的优越,兑现不了训练数据的稀缺。
原文说的"宏是上下文压缩",方向没错,但只讲了一半。宏能把重复样板隐藏起来省token,前提是模型得先学会这个宏——需要额外看到宏定义、展开示例,或者能调用macroexpand工具去查。配套没跟上,宏密集的Lisp代码对模型反而比写清楚的Python更难猜,省下的token变成藏起来的语义债务,迟早要还。
- 风险.宏省的是生成时的token,欠的是理解时的确定性,工具没跟上就是隐性成本。
REPL改善的是反馈通道,不是判断力
原文说条件系统比崩溃重启更优雅,这个判断站得住。Common Lisp的开发环境SLIME集成了REPL、编译器、检查器、调试器和交叉引用工具,调试器能展示当前条件、可选的重启路径(continue、use-value、store-value、retry)和调用栈——这些重启不只是调试便利,是程序运行时对外暴露的动态接口。出了错,AI能看清错误的具体形态,选一个修复方式,不用推倒重来。
但这只是改善了反馈质量,不保证AI判断正确。模型照样可能选错重启选项、误改不该改的对象、或压制掉一条本该重视的警告。REPL让AI能对话,不代表AI说话就靠谱。
最值得琢磨的一点,是"vibe coding"这个词本身的定义:围绕迭代反馈构建工作流,重点看AI写出的东西表现对不对,不是逐行审查代码。这和Lisp传统里"深入理解、实时内省、活体镜像开发"的文化,方向其实相反。原文作者说自己在REPL里跟AI对话、随时查对象状态、逐个重启调试——这已经不是"看行为不看代码"的盲目委托,更接近一种引导式活体编程。他实际践行的方法,比他给的理由更站得住脚,只是功劳全记在了语言头上,没记在自己几十年攒下的调试直觉上。
如果把同像性、宏展开、结构化条件反馈这些优势真正兑现所需要的工具搭起来——给Python配一套同样能查AST、能结构化报错、能实时重启的智能体基础设施——那么"语言该选哪个"这个问题,可能会变得没那么重要。目前没人做过这组对照实验,这才是这场争论里最该盯着看的开放问题。