在 day01 中，我們討論了 AI 時代的軟體開發，並提到了 Lisp 和 FP 如何透過減少測試與除錯時間，來提升軟體開發效率。它們之所以重要，是因為 AI 雖然加速了編碼，卻讓「測試與除錯」成為了更顯著的瓶頸。

然而，AI 的影響遠不止於此。當一個瓶頸被解決後，新的瓶頸就會浮現。那麼，我們該如何從更高層次的角度來辨別，哪些知識在 AI 時代依然重要，甚至價值更加提升呢？我認為，制約理論這個簡單的框架，就足以帶來許多的啟發。

制約理論

制約理論 (Theory of Constraints, ToC)，是由以色列物理學家高德拉特 (Eliyahu M. Goldratt) 所提出的一套管理哲學。它的核心思想很簡單，就是任何一個系統的表現，都是由系統中最弱的那個環節所決定。

想像一下一條生產線由三種不同的機器串連而成。如果其中一個機器每小時只能生產 100 個零件，而其他機器每小時都能生產 200 個零件，則整條生產線最多每小時也只能生產 100 個零件。這個每小時生產 100 個零件的機器，就是這個系統的「制約」(constraint)。

ToC 認為，如果想提升整個系統的效率和產出，必須集中所有資源和精力，去找出並解決那個最關鍵的制約。

AI 時代最大的制約

回顧一下之前利用 AI 的例子：

• 在 WebSocket 篇，使用了 AI 來移植 (Port)，雖然有先用人工來釐清依賴關系。
• 在 CBOR 篇，使用了 AI 推論函式庫的用法，雖然必須搭配結構化思考 prompt 才能成功。
• 在跳轉定義篇，使用了 AI 來做架構設計，雖然後來以人工做了大幅的簡化。
• 在 Tree-sitter 篇，使用了 AI 來生成查詢。

AI 其實不太像是一種工具，它更像是工具的素材，視使用者的 prompt 而定，可以變成多種不同的工具。

如果我們把軟體開發視為一個系統，那麼其最終產出是功能完整的應用程式。在 AI 時代，許多傳統的瓶頸，例如程式碼撰寫、單元測試生成、甚至初步的除錯，都因為 AI 的輔助而得到了顯著的改善。

然而，根據制約理論，當一個瓶頸被解決後，新的瓶頸就會浮現。這正是 AI 時代軟體開發的核心挑戰。

我認為，對於開發者而言，軟體開發最大的限制，已經不再是單純的「開發速度」「技術實現能力」，而是「持續識別並適應生產力瓶頸的能力」。

一個能準確識別「當前最重要瓶頸」的開發者或團隊，更有機會能將 AI 這把萬用工具，集中火力用在最關鍵的環節，從而帶來最大的效益。這也解釋了為何像是 Lisp 和 FP 這些更偏向抽象思維與架構設計的知識，其重要性在 AI 時代反而更加提升，因為它們訓練的正是我們識別系統性瓶頸的能力，而非單純的程式碼撰寫技巧。

小結

在 AI 時代，軟體開發生產力瓶頸變動的速度比過去更快了，也因此更需要培養持續識別並適應生產力瓶頸的能力。

在接下來的篇章，我們會來討論一些常見的挑戰，因為這些挑戰如果處理不好，很容易就會變成生產力瓶頸。還有，接下來的篇章，由於探討的是一般性的挑戰，將不再綁定程式語言或應用平台。