当 AI 开始“挑语言”：一位程序员写 Lisp 受挫，戳中了生成式编程的隐秘偏见
生成式 AI 正在改写写代码这件事，但它改写的方式，未必像很多人想象得那样“中立”。
最近，开发者 Dan Haskin 在博客里写下一段颇有点失落的经历：他用 AI 辅助开发时发现，自己心爱的 Lisp，居然成了一种对 AI “不友好”的语言。更准确地说，不是 Lisp 不能写，而是 AI 写起来效率极低、成本极高、噪音极多；反过来，同样的任务换成 Python，AI 却像打通任督二脉，代码和测试都能大段生成，便宜模型也能凑合干活。
这篇文章打动人的地方，不只是“AI 不擅长 Lisp”这个结论，而是它背后那种很现实的落差：程序员原本因为热爱、优雅、表达力而选择一门语言，现在却可能因为 AI 的训练数据密度和工具链习惯，被迫朝另一边妥协。听起来有点伤感，甚至有点讽刺。
AI 会写代码，但它其实很“势利”
Dan 的工作身份是 DevOps 工程师，平时已经大量使用 agentic AI，也就是那种不仅会回答问题、还能调用工具、执行命令、完成任务链的 AI 代理。他用 OpenRouter 配合 Goose CLI，在工作里已经把这套流程磨得相当顺手。后来他开始写一个 RSS 阅读器格式转换工具，语言选的是 Lisp——理由也非常简单，因为这是他最喜欢的语言。
问题从这里开始。Lisp 世界里，REPL 是核心体验之一。很多 Lisp 程序员真正的开发方式，并不是“写一大坨代码再统一编译运行”，而是边写边在 REPL 里试，快速反馈、快速修正。这种交互式工作流对人类非常友好，像是边和语言聊天边把程序长出来。但到了 AI 身上，这种低延迟、细颗粒度的开发方式，反而变成了高延迟 API 调用里的负担。
Dan 一开始让 AI 通过 tmux 去操作 REPL，比如抓终端输出、等待执行结果、解析 pane 里的内容。能用，但很笨重。结果就是 Claude 这种相对强一点的模型也会“空转”——不停生成、试错、消耗 token，却推进不了多少实质进展。便宜一点的模型，比如 DeepSeek、Qwen，表现就更不理想。短短几分钟，十几美元就烧没了，留下的是一堆“勉强能看”的 Lisp 代码，最后还得人手重写。
这件事很说明问题：AI 写代码不是纯粹靠“理解能力”在工作，它极度依赖已有模式、现成惯例和低摩擦工具链。语言越主流、网上样本越多、默认路径越明确，AI 就越像一个熟练工。语言越依赖互动式探索、越强调个性化实践、越缺乏统一俗成的“标准写法”，AI 就越容易迷路。
Lisp 的问题，不只是“小众”，而是它和 AI 的节奏天生拧巴
为了改善 AI 使用 REPL 的体验，Dan 还专门写了一个工具：tmux-repl-mcp。这个工具本质上是给 AI 开一条更直接的路，让它不用反复执行 shell 命令、sleep、抓取 tmux 输出，而是可以直接调用 execute_command 跟 REPL 交互。这其实已经很像在给 AI 修高速公路了。
有意思的是，这个辅助工具他是用 Python 写的。原因一点都不玄学：他的 AI 工具链本来就围绕 Python 生态里的 uvx 搭好了，MCP Server 的官方示例也主要是非 Lisp 语言。结果非常戏剧化——AI 写 Python 版本时，几乎顺风顺水，代码和测试都能大部分自动生成，开发者只需要半手工调试一下，一两天就把“能用的东西”拼出来了，而且用的还是便宜模型。
这才是最让人五味杂陈的地方。Dan 说，自己在两种语言里扮演的角色其实差不多，都是一个“穷人版产品经理”——不停告诉 AI 该做什么、哪里不对、怎么改。但 Python 场景下，这种方式是高效协作；到了 Lisp 场景，就像带一个总是抓不住重点的实习生。语言本身带来的快乐感，也在 AI 中介下被稀释了。
这里有个非常值得玩味的判断：Lisp 对 AI 的“不友好”，并不只是训练数据少那么简单。还有开发范式的问题。REPL 之所以伟大，是因为它让人类程序员可以用极低延迟探索问题；但 AI 接口本身已经是高延迟的请求-响应模型，来回折返的成本太高。于是 AI 更适合那种“一次吐出几百行、批量测试、批量修正”的语言和工作流，而不是 Lisp 这种强调动态试验、细腻互动、逐步塑形的开发方式。
换句话说，AI 偏爱的未必是“更好的语言”，而是“更适合它统计生成和批处理习惯的语言”。这和程序员传统意义上的语言审美，根本不是一回事。
从 QuickLisp 到 Go：AI 正把技术选择变成经济学问题
Dan 还提到一个很多程序员看了会会心一笑、又有点无奈的细节：他明明更喜欢用 OCICL 而不是 QuickLisp，但 AI 几乎每个会话都默认给他上 QuickLisp，好像这件事已经写进模型基因里了。这个细节非常小，却非常有代表性。
因为 AI 生成代码，本质上常常是在走“阻力最小的路径”。什么东西在网上资料最多、教程最密、Stack Overflow 和 GitHub 里出现频率最高，它就更容易往哪里滑。于是，QuickLisp 不一定是当前开发者最想用的方案，但它是 AI 最熟悉、最保险、最容易预测下一步的方案。模型不会天然偏爱你的个性化选择，它会偏爱互联网的统计平均值。
这意味着什么？意味着过去程序员在语言选择上讨论的那些维度——优雅不优雅、类型系统美不美、宏强不强、抽象能力够不够——如今多了一个非常俗、但非常致命的新变量：AI 成本。
Dan 甚至认真考虑把自己的项目改写成 Go，因为“有了 AI，代码变便宜了——前提是你用的是 AI 熟悉的语言”。这话听上去有点刺耳，但恐怕越来越真实。以前我们说一门语言流行，意味着更容易招人、更容易找库、更容易维护；现在流行还多了一层含义：更省 token，更省调试轮数，更省模型费用。
程序员圈常讲一句话，叫“Worse is Better”——有些方案并不优雅，甚至有点粗糙，但因为足够简单、足够普及、足够容易传播，最后赢了。互联网时代，很多 Lisp 理想主义者已经见识过这套逻辑；而在 AI 时代，这种逻辑被进一步货币化了。流行度不再只是口碑和生态，它直接体现在账单上。
这不是 Lisp 一家的烦恼，而是 AI 编程的价值观正在成形
如果把这件事看得更大一点，它其实不只是 Lisp 的困境，而是一个关于“AI 将放大什么、压缩什么”的问题。
今天的 AI 编程工具，表面上在降低门槛，实际上也在悄悄塑造新的技术共识。它们会鼓励开发者使用训练语料最丰富的语言、最主流的框架、最常见的项目结构、最标准化的工具链。对企业来说，这往往是好消息：更稳定、更可预测、更容易复制，生产率也更高。但对技术多样性来说，这未必是福音。
小众语言、实验性范式、强调交互和探索的开发文化，可能会越来越像逆流而上的选择。它们不会消失，就像 Lisp 在互联网浪潮里也没消失，但使用它们的人，可能不得不承受更高的 AI 摩擦成本。某种意义上，这有点像自动驾驶系统只熟悉高速公路，却不擅长穿梭老城区的小巷。不是小巷没有价值，而是系统从一开始就不是为那种路线长出来的。
Dan 在文中讲了一个家乡的故事：当年美国小镇 Naperville 有一条木板路，走起来比泥路舒服得多，于是投资人靠它收过路费赚得不错。后来铁路想经过这里，却被拒绝了，因为大家觉得木板路已经够赚钱。结果铁路绕道别处，人们最终都去了更高效率的轨道系统，木板路只剩下名字。这是个很好的比喻。Lisp 像那条走起来更舒服、更有乐趣的木板路，而 AI 也许就是那条正在重塑交通规则的铁路。
但我不觉得结论会是“Lisp 输了”。更准确地说，AI 暂时还没学会如何真正进入 Lisp 的语境。今天的模型擅长复述主流互联网的编程习惯，却还不擅长适应那些依靠 REPL、宏系统、动态探索和强个人风格运转的语言文化。未来如果 MCP、工具调用、长上下文、持续会话状态管理继续成熟，AI 未必不能成为更合格的 Lisp 搭档。只是现在，它还明显偏科。
这也是为什么这篇博客会让很多老程序员共鸣：大家失落的不是“AI 不能写 Lisp”，而是“AI 让我们更容易为了效率放弃热爱”。当开发语言从审美选择逐渐变成成本函数，软件行业会不会越来越趋同？程序员会不会越来越像给模型喂任务的产品经理，而不是亲手雕刻程序的人？
这些问题，今天还没有答案。但至少 Dan 的经历提醒了我们一件事：AI 编程不是单纯的效率革命，它也是一场关于技术文化权力重新分配的过程。谁的数据多，谁的默认路径清晰，谁就更容易成为 AI 时代的新“普通话”。而那些更讲究、更古怪、也更有趣的语言，可能需要找到属于自己的新适应方式，才能不被时代的噪音淹没。