技術、認知與意圖債務

背景

隨著大型語言模型（LLM）在軟體開發中的普及，業界開始關注這類工具如何改變系統的健康狀態。Martin Fowler 引用了 Margaret-Anne Storey 的觀點，將系統債務劃分為技術債、認知債與意圖債三個層次，探討當開發者過度依賴 AI 生成代碼時，團隊可能失去對系統運作邏輯的理解，進而產生「認知投降」的風險。

社群觀點

在 Hacker News 的討論中，社群對於「意圖債」與「認知債」的定義展開了激烈的辯論。部分開發者認為，從組合語言演進到 Python 本身就是一種抽象化的過程，這同樣會讓人忽略底層硬體的運作細節，因此將 LLM 視為債務來源可能過於悲觀。然而，反對者指出，傳統程式語言是具備確定性的形式語言，將人類意圖轉化為形式語言的過程本身就是一種「思考工具」，能幫助開發者釐清邏輯中的模糊地帶；相比之下，AI 生成的代碼缺乏這種嚴謹的對應關係，若開發者只停留在非正式的自然語言層面，將無法發現潛在的架構缺陷。

針對 AI 是否具備「懶惰」這項美德，社群意見呈現兩極。Martin Fowler 認為 AI 傾向於生成大量重複代碼，缺乏尋求簡潔抽象的動力。但有資深工程師分享實務經驗指出，透過精確的提示詞工程（Prompt Engineering），例如要求 AI 遵循「不要重複自己」（DRY）或「你不會需要它」（YAGNI）原則，AI 其實能產出比一般開發者更符合架構規範的代碼。他們認為 AI 降低了實踐「正確架構」的成本，讓原本因為人類懶惰而跳過的介面設計或單元測試變得信手拈來。

此外，關於「驗證」是否會取代「編碼」成為核心工作，討論區也出現了深刻的反思。有觀點認為，當代碼生成的成本趨近於零，真正的價值將轉移到如何定義「正確性」。雖然測試驅動開發（TDD）被視為一種解決方案，但也有人警示，若系統的抽象層級從根本上就是錯誤的，那麼即便測試全數通過，也只是在錯誤的架構上越走越遠。最終，社群普遍達成一項共識：AI 並非一種新的抽象層，而是一種生成工具；開發者若放棄對形式化邏輯的掌握，將難以在 AI 出錯時進行有效的干預與修復。

延伸閱讀

在討論過程中，參與者提到了幾項值得參考的資源。首先是 Kahneman 的《思考，快與慢》，這是理解系統一與系統二認知模型的基礎。其次是 Shaw 與 Nave 在華頓商學院發表的論文，該研究將 AI 定義為「系統三」認知模式。此外，1996 年 Fast Company 報導 NASA 如何撰寫完美軟體的案例也被提及，用以說明形式化規範在軟體工程中的重要性。最後，針對 LLM 工作流的優化，有開發者推薦參考 Claude 的專案說明文件（claude.md）配置方式，以建立更穩定的 AI 協作規範。