背景

隨著 AI 編碼代理（Coding Agents）的興起，文學本編程（Literate Programming）這項歷史悠久的構想重新受到關注。該理念主張程式碼應與敘事性散文交織，使讀者能像閱讀故事般理解軟體邏輯，然而過去因維護成本過高而難以普及。本文探討在大型語言模型具備強大總結與轉譯能力的當下，是否能由 AI 承擔同步文檔與代碼的繁重工作，進而實現開發流程的典範轉移。

社群觀點

Hacker News 社群對於文學本編程的復興抱持兩極但富有洞察力的看法。反對者主要針對「文檔腐爛」的宿疾提出質疑，認為文字敘述往往無法準確反映代碼現狀，且散文本身無法像代碼一樣進行自動化測試，這導致文學本編程容易變成充滿誤導性的「謊言」。更有評論者指出，工程師的核心職責本就是閱讀而非寫作，過多的敘事性文字反而可能增加資訊噪音。他們主張良好的命名規範、類型簽名與簡潔的架構設計，本身就是最有效的溝通方式，無需刻意追求文學化的形式。

然而，支持者則從 AI 的特性出發，認為代理時代確實改變了賽局。過去維護雙重敘事（代碼與散文）是人類的負擔，但對 LLM 而言，這正是其擅長的翻譯與總結任務。有開發者分享經驗指出，當文檔被視為 AI 執行的指令來源時，開發者會更有動力保持其準確性，因為這直接影響到 AI 產出的品質。這種「以文檔驅動開發」的模式，讓散文從裝飾性的註釋轉變為可驗證的聲明。此外，社群中也出現了折衷的觀點，認為不需要追求完全的文學本編程，而是應利用 AI 來偵測註釋與代碼之間的失真，或是將其應用於測試手冊與架構決策紀錄，解決跨檔案的邏輯理解難題。

討論中亦觸及了編程本質的轉變。部分資深開發者認為，文學本編程的失敗往往源於人類逃避溝通的天性，而非工具限制。如果 AI 能自動化處理「糾錯」與「同步」的工作，或許能讓開發者重新專注於表達意圖而非僅僅是實現細節。儘管有人擔心這會導致代碼膨脹，但也有人反駁，透過如 Jupyter Notebook 或 Org Mode 等工具實現的重現性科學計算，已經證明了代碼與敘事結合在特定領域的巨大價值。

延伸閱讀

在討論中，參與者提到了多項實踐文學本編程與 AI 協作的工具。其中 nbdev 與其衍生的 Solveit 被視為將筆記本環境應用於軟體工程與企業流程的成功案例。針對 Raku 語言設計的 Rakudoc 則展示了如何將文檔深度嵌入源碼。此外，針對 AI 時代的文檔維護，已有如 Promptless 等新創工具嘗試利用模型自動標記過時的註釋。對於偏好 Rust 的開發者，Figment 則被提及作為處理分層配置的一種優雅實踐。