用 AI 寫 Lisp 困難重重讓我感到悲傷

背景

這篇由 Dan 撰寫的文章探討了 Lisp 語言在 AI 輔助開發時代所面臨的困境。作者發現，儘管 Lisp 是他最喜愛的語言，但在使用 Claude 或 DeepSeek 等 AI 工具進行開發時，AI 在 Lisp 上的表現遠遜於 Python 或 Go，不僅容易產生語法錯誤，更難以適應 Lisp 核心的 REPL 開發流程，導致開發成本高昂且效率低下。

社群觀點

Hacker News 的討論呈現出兩極化的觀點，反映了開發者在使用 AI 處理 S-expression 語法時的真實掙扎與突破。許多留言者共鳴了作者對「括號地獄」的觀察，指出 LLM 在處理大量嵌套括號時存在先天缺陷。這並非單純的邏輯問題，而是與 AI 的 Tokenization 機制有關。當多個括號被組合成單一 Token 時，AI 難以精確計數，導致輸出的代碼經常出現括號不匹配的情況。甚至有開發者提到，目前已有專門為 Clojure 設計的 MCP 工具，其核心功能之一竟然就是為了修正 AI 產生的括號錯誤。

然而，另一派開發者則持相反意見，認為 Lisp 其實非常適合 AI。支持者指出，如果放棄強求 AI 模仿人類的 REPL 互動模式，轉而讓 AI 遵循其擅長的「批次寫作」邏輯，效果往往出奇地好。有評論者分享了使用 Claude 成功構建 Common Lisp 專案的經驗，甚至有人利用 AI 從零開始寫出了一個高效能的 eBPF 編譯器。他們認為，Lisp 語法結構簡單且規律，只要提供足夠的上下文與明確的指令，AI 產出的代碼質量其實很高。這引發了一個有趣的爭論：究竟是 Lisp 本身抗拒 AI，還是人類試圖將「減少錯誤、即時反饋」的 REPL 工作流強加給 AI，反而限制了 AI 一次產出數百行代碼的能力。

此外，社群也對「語言多樣性」的消亡表達了憂慮。隨著 AI 成為開發主力，開發者為了節省 Token 成本與除錯時間，會傾向選擇 Python 或 Go 等訓練數據極其豐富的熱門語言。這種「路徑依賴」可能導致像 Lisp 這樣優雅但小眾的語言逐漸邊緣化，甚至演變成一種「技術債」。但也有樂觀的聲音認為，Lisp 經歷過多次技術浪潮依然存續，其強大的元編程能力與宏系統，或許在未來能發展出更適合 AI 讀寫的結構化接口，而非僅僅停留在模仿人類輸入字符的層次。

延伸閱讀

在討論中，開發者們分享了數個能優化 Lisp AI 開發體驗的工具。針對 Common Lisp，有 cl-mcp 伺服器可供使用，而 icl 則提供了改進的 TUI 與瀏覽器界面。在 Clojure 領域，Datalevin 資料庫的作者也現身說法，提到即將推出的版本將內建 MCP 支援。對於 Scheme 愛好者，Schematra 框架與其配套的啟動套件被認為是提升 AI 協作效率的有效方案。此外，也有人推薦使用 ast-grep 進行結構化的代碼替換，以規避 AI 處理純文字語法時的括號計數錯誤。