模式比對與理解
統計模型 vs 人的智能
在上一篇，我利用 AI 來輔助軟體開發，開發過程中也遇上了 AI 因為波坦金理解，而無法透過模式比對來解決的問題，即 CBOR 函式庫該怎麼使用的問題。
這件事我總共做了兩個反省：
下次遇到這種情況，我要如何調整 prompt ，以增加模式比對的成功率。這就是上一篇的主要內容。
下次遇到這種情況，我要怎麼思考，才能更快地來掌握函式庫 (library) 的用法。換言之，要怎麼想，才能加快對於這類情況的模式理解。
窮舉與歸納
還是先從窮舉與歸納開始吧，根據我的經驗，95% 的函式庫 (library) 的用法大致如下：
只提供 API
提供 API ，且部分的 API 可以接受複雜的引數 (argument)，甚至是引數是函式 (function)。
這邊對第 2 項多加一些解釋。比方說，很多的程式語言都會有提供排序 (sort) 的函式庫。由於通常我們使用排序，有時候會需要「從小排到大」，有時又會需要「從大排到小」，甚至根據特殊條件來排序，排序函式通常會接受引數，讓你可以指定排序的依據。
然而，除了 1 與 2 ，還有少數 5% 的函式庫使用更進階的用法，而上一篇卡住 LLM 的 CBOR 函式庫的用法就是這種類別。這類型的函式庫它的特性如下：
此類函式庫本身採用「可延展的方式」設計，所以它的內部實作有一段是鬆耦合設計。
鬆耦合設計如果是在 Erlang ，會利用網路傳輸協定來實作，日後，如果要替換鬆耦合所接合的舊模組，我們只要開發新的模組且該新模組有實作相同的網路傳輸協定，新模組就可以順利替換舊模組。
鬆耦合設計如果是在物件導向程式語言，包含 Java, Lua ，則常會透過 Java 的 interface 或 Lua 的 metatable 來實作，日後，如果要替換鬆耦合所接合的舊模組，我們只要開發新的模組且該新模組有實作相同的 Java interface 或是註冊一樣的 Lua metatable 函式，新模組就可以順利替換舊模組。
面對這類的函式庫，如果恰好我們要使用的方式正好是該函式庫所不支援的功能，我們可以把自己想要的功能寫成新模組，並且在呼叫函式庫時，也把新模組傳入。
模式理解
有了前面的分析與探討之後，日後的思考順序應該是這樣子：
描述挑戰：「欲使用之功能，是否可能是函式庫的設計者最初沒有覆蓋到的情境。」
假設：「函式庫的設計者是否已經對這種情況，留下了鬆耦合設計，讓使用者日後可以做出修改？」
確認目前使用的程式語言，它的鬆耦合機制為何？
初步驗証假設，透過 README.md 或是原始碼。
顯然，一旦有了這樣子的思考，似乎又開啟了新的 prompt 的可能性？
結論
在 AI 輔助開發的情境中，模式比對和模式理解就像兩種不同的工具：前者擅長快速匹配既有的知識片段，後者則用來在陌生領域中建立新的理解架構。AI 在模式比對上的速度與廣度，無疑能讓我們節省大量搜尋與整理的時間，但若情境超出了既有範例的覆蓋範圍，就必須換上模式理解的思維，從系統設計與語言特性去推敲可行的解法。
CBOR 函式庫的經驗告訴我，當發現功能缺口時，不要一味讓 AI 重複嘗試，而是先停下來問自己：「這個函式庫的設計中，有沒有預留擴充的可能？」一旦找到鬆耦合的切入點，後續就能更精準地讓 AI 協助完成具體實作。
AI 不適合替代思考，而是適合用來加速正確的思考──用模式理解開路，用模式比對鋪路，兩者交替運作，才能讓開發過程真正地加速。