Why Target Common Lisp for Code Generation? 为什么选择 Common Lisp 作为代码生成目标？

I’ve been asked twice now: if the generated code doesn't matter—if the AI is doing the heavy lifting of writing the syntax—why do I vibe code in Common Lisp?
我已经两次被问到：如果生成的代码并不重要——如果 AI 承担了编写语法的繁重工作——为什么我还要用 Common Lisp 编写代码？

Why not target Python, TypeScript, or Java? These are mainstream languages with massive training sets. The models can generate code in them with a high degree of statistical accuracy. So why do I choose to target a niche language like Common Lisp for code generation?
为什么不选择 Python、TypeScript 或 Java 作为目标语言呢？这些都是主流语言，拥有海量的训练数据集。模型可以用它们生成代码，并且统计准确率很高。那么，我为什么选择像 Common Lisp 这样的小众语言来进行代码生成呢？

There are a lot of reasons, and they all come down to the same age-old question. Why use Lisp when you could use a more popular language? The answer is that language popularity is a poor proxy for utility and expressiveness. The Lisp community has long known this - it is why we chose Lisp in the first place. Selecting for popularity is what middle managers do to ensure that they can always find a warm body to maintain the code. It is not what elite hackers do.
原因有很多，但归根结底都是同一个老生常谈的问题：既然可以选择更流行的语言，为什么还要用 Lisp 呢？答案是，语言的流行度并不能很好地代表其实用性和表达能力。Lisp 社区早就明白这一点——这也是我们当初选择 Lisp 的原因。选择流行度高的语言是中层管理者为了确保总能找到人来维护代码而采取的做法，而不是顶尖黑客的做法。

The Baseline of Expertise First, I have been programming in Common Lisp for decades. I know it intimately. Vibe coding requires a human architect to supervise the machine. When I look at the code generated by the model, I can tell in a fraction of a second whether it is any good, or if the model is hallucinating a dead-end. You cannot successfully orchestrate an AI in a language you don't deeply understand.
首先， 我的专业基础是： 我使用 Common Lisp 编程已有数十年，对它非常熟悉。Vibe 编码需要人类架构师来监督机器运行。当我查看模型生成的代码时，我只需不到一秒就能判断它是否优秀，或者模型是否陷入了死胡同。你不可能用自己不深入了解的语言成功地操控人工智能。
Abstraction over Implementation Most modern languages force you to describe exactly how a machine should shuffle bits around. Lisp was designed as a language for expressing high-level abstractions rather than expressing tedious implementation details. When I prompt the AI, I want it generating architectural logic, not fighting with boilerplate just to manage basic state.
抽象优于实现大多数现代语言都要求你精确描述机器应该如何操作数据位。Lisp 的设计初衷是表达高级抽象概念，而不是繁琐的实现细节。当我引导 AI 时，我希望它生成的是架构逻辑，而不是为了管理基本状态而编写大量样板代码。
Designed for the Elite Let’s be honest: Lisp is a language designed by and for elite hackers, not for the masses. It doesn't hold your hand, and it doesn't pander to lowest-common-denominator programming bootcamp patterns. When you use it as a target language, you are operating in an environment built for maximum expressiveness.
专为精英打造坦白说，Lisp 是一种由精英程序员设计并面向精英程序员的语言，而非面向大众。它不会手把手地教你，也不会迎合那些低级的编程训练营模式。当你使用 Lisp 作为目标语言时，你将置身于一个旨在最大限度发挥表达力的环境中。
Homoiconicity and the AST This is perhaps the biggest technical advantage. Lisp is homoiconic—the code is structured as the data it manipulates. When an LLM generates Python or Java, it has to predict surface syntax: whitespace, brackets, semicolons, and rigid class structures. When an LLM generates Lisp, it is operating directly at the level of the Abstract Syntax Tree (AST). It is predicting pure structure. Removing the syntactic friction is a massive advantage for AI code generation.
同像性和抽象语法树 (AST) 这或许是最大的技术优势。Lisp 具有同像性——代码的结构与它所操作的数据结构一致。当语言学习模型 (LLM) 生成 Python 或 Java 代码时，它必须预测表面语法：空格、括号、分号和严格的类结构。而当 LLM 生成 Lisp 代码时，它直接在抽象语法树 (AST) 层面上操作。它预测的是纯粹的结构。消除语法摩擦对于人工智能代码生成来说是一个巨大的优势。
Macros as Context Compression In vibe coding, the LLM's context window is your most precious resource. Lisp’s macro system allows for a highly effective form of context compression. Instead of the AI repeatedly generating verbose boilerplate, you can hide that boilerplate behind a macro. The AI learns the macro, uses it, and saves thousands of tokens, allowing you to maintain massive architectures within the model's memory constraints.
在 Vibe 编码中，LLM 的上下文窗口是最宝贵的资源。Lisp 的宏系统提供了一种高效的上下文压缩方式。与其让 AI 重复生成冗长的样板代码 ，不如将这些样板代码隐藏在宏之后。AI 会学习并使用该宏，从而节省数千个代码块，使你能够在模型的内存限制内维护庞大的架构。
Introspection in the REPL I do not operate the LLM in a sterile text editor. I operate it from within a Lisp REPL. This allows the LLM to introspect the program while it is under development. If we need to know the state of a specific object or function, the model can query the live environment. You are not writing dead text; you are conversing with a living system.
在 REPL 中进行内省： 我并非在静态文本编辑器中操作 LLM，而是在 Lisp REPL 中操作。这使得 LLM 能够在程序开发过程中进行内省。如果我们需要了解特定对象或函数的状态，模型可以查询实时环境。您编写的不是死板的文本，而是与一个鲜活的系统进行交互。
Superior Error Handling When the AI writes bad code (and it will), Lisp’s condition system provides superior error handling and debugging facilities. Instead of a hard crash that requires a full reboot, the error is caught, and the LLM can analyze the stack trace and debug the generated code interactively, right at the point of failure.
卓越的错误处理能力： 当人工智能编写出错误代码时（这种情况不可避免），Lisp 的条件系统提供了卓越的错误处理和调试功能。它不会像传统方式那样导致系统崩溃并需要完全重启，而是能够捕获错误，并且 LLM 可以分析堆栈跟踪，并在故障发生时以交互方式调试生成的代码。
No *Ab Initio* Restarts Using the REPL means you don't have to start your program ab initio (from the beginning) every time you want to test a change. In a compiled, mainstream language, a one-line AI fix requires a full rebuild and state reset. In Lisp, you just redefine the specific function and immediately test it in the REPL while the rest of the application's state remains perfectly intact. The iteration speed is unmatched.
使用 REPL 无需*从头开始*重启程序， 这意味着您无需每次测试更改时都从头开始运行程序。在主流的编译型语言中，一行 AI 修复需要完全重新编译并重置状态。而在 Lisp 中，您只需重新定义特定函数，即可立即在 REPL 中进行测试，而应用程序的其他状态将保持不变。迭代速度无与伦比。

You don't give an elite hacker a code monkey language. I want my AI to be an elite hacker, not simply a code monkey. If I expect my AI to work at an elite level, I should give it elite tools, not a code monkey language.
你不会给顶尖黑客一种只会写代码的语言。我希望我的 AI 成为顶尖黑客，而不仅仅是只会写代码的猴子。如果我期望我的 AI 达到顶尖水平，我就应该给它顶尖的工具，而不是只会写代码的猴子语言。