为何用 Common Lisp 进行 AI 代码生成？
Why Target Common Lisp for Code Generation?
有人问我，既然 AI 能轻松生成 Python 或 TypeScript 代码，为何我坚持用 Common Lisp 进行 Vibe Coding？答案很简单：语言流行度不等于实用性。作为资深 Lisp 程序员，我深知在 AI 辅助编程中，人类架构师的深度理解至关重要。Lisp 的同质性（Homoiconicity）让 LLM 直接操作抽象语法树（AST），而非纠结于繁琐的语法细节；其宏系统能极大压缩上下文窗口；而 REPL 环境则支持实时内省与无重启迭代。我不需要 AI 做代码搬运工，我要的是精英黑客，因此必须给它精英级的工具。
如果你期望你的 AI 达到精英水平，就应该给它精英级的工具，而不是代码搬运工语言。
HN 评论区
138- kukkeliskuu
过去一年，我编写了大量 Common Lisp 代码，包括一个 FoundationDB 客户端、构建在其之上的分布式系统原语、一个用于 CL 系统的可观测性与可运维性库，以及一个利用这些组件的大规模日志、指标和追踪平台——总计约 20 万行代码和测试。
抛开对语言的熟悉程度和个人偏好不谈，在 LLM 时代，我的观点如下：
1. 从“功能需求”的角度看，任何语言都能胜任。你可以用像 C 这样的低级语言，或者像 Python 或 Common Lisp 这样的高级语言来构建大型系统。
2. 从安全角度看，如果你使用 LLM 辅助生成代码，我认为用 C、Rust 还是 Common Lisp 其实差别不大——当前的模型已经能够生成安全的代码，未来的模型或许能力更强。
我的理解是，LLM 具有通缩效应，导致代码变成一种大宗商品（成本加成定价）。如果这一趋势成立，那么更低的 token 成本和更高的性能（尤其在我的案例中，良好的性能意味着更低的托管服务基础设施成本）将变得越来越重要。Common Lisp 代码库以“密度高”（褒义）著称，这意味着当 LLM 需要审查或修改代码时，token 成本可能更低（较小的代码库也有助于人类/小团队）。Common Lisp 的性能可以接近同等实现的 C 或 C++。
综合来看……
- fab13n
我最近在一个项目中使用了 cl，因为它拥有我想要的许多特性，尽管我不太熟悉它（虽然用过 elisp 和一点点 scheme），但用起来确实很合理。我发现它有些方面非常棒，但也有些痛点。SBCL 是一个 fantastic 的项目和编译器，一旦你习惯了它的调试方式，配合 slime 使用体验非常棒。诚然，它的灵活性非常出色，而 CLOS 对象系统一旦上手也非常好用。
关于 AI 辅助编程，我觉得效果喜忧参半。虽然 Claude 现在看起来相当不错，但本地模型表现往往较差，而且很多内容文档不全，社区代码存量也较少。
使用本地模型时需要注意的一点（可能前沿大模型也有这个问题，但因其参数量巨大，在我的使用中完全掩盖了这个问题）是：'(' 或 ')' 可能是某个 token 的一部分，例如 '))' 是一个独立的 token，'(*' 也可能是一个 token。也就是说，当模型生成代码时，块的结束和开始可能会出问题，导致你的括号不匹配。这是我在使用 omnicoder 9B 时遇到的主要问题。我不确定更新的本地模型表现如何，后来我部分切换到了 Claude，并且倾向于花更多时间自己手写代码。