我每週將 80% 的工作時間在 Gaiwan.co 工作，專注於後端 Web 開發，主要使用的程式語言是 Clojure。用 Clojure 語言做軟體開發，過去，我常常遇到一個難題：「不知道該如何選擇 library ？ 」
而很幸運的事情是，自從我在 Gaiwan 工作開始，這個就不再是我的問題，因為我的老闆都幫我選好了。在 Gaiwan 公司有一分內部文件，叫 Gaiwan Stack ，上頭記錄了各式各樣的 Clojure library ，哪些要用、哪些不用，理由是什麼。
近期，我負責了一個專案，其主要內容是分析客戶提供的 Excel 文件中的矩陣。該矩陣對應於客戶的資料庫，標示出需新增、刪除或合併的項目。我做的事情是：「利用 Clojure 去讀 Excel 檔，分析這個矩陣，並且生成對應的 SQL 語句。」
這個工作最複雜的部分在於，那個 Excel 檔裡的矩陣，客戶利用了儲存格背景色與儲存格字型顏色來表達語意 (semantic)，例如，紅色的字型表示要刪除之類的。因此，在使用 Clojure 的 Excel library Docjure 讀取 Excel 文件後，我還需解析儲存格的顏色資訊。還有，顏色也並不是只有 RGB 而已這麼單純，還有色度 (Tints) 也要考慮在內。
在完成專案之後，我突發奇想，有沒有可能這回我老闆對 Library 的選擇並非最佳選擇，我多試幾個其它的 Clojure Excel library ，說不定開發起來的感覺就會容易得多。因此，在某日下午，我嘗試了另外兩個 Clojure 的 Excel library，但最終根據實驗結果，我仍認為 Docjure 是最佳選擇。
實驗之後，我不禁思考：如果利用 LLM 模擬我老闆的決策過程，是否也能做出正確的 library 選擇？
於是，我先把 Gaiwan Stack 的內容丟進 LLM ，叫它做個總結，歸納出 Gaiwan 選擇 software library 的原則，然後，我再叫 LLM 基於前述歸納出來的原則從六個不同的 Excel library 裡去選出，最符合 Gaiwan 原則的 software library ，LLM 二話不說就選了 Docjure 。
看到這樣子的結果，我不由得心道：「我才不及卿，乃覺三十里」。居然叫 LLM 去模仿我老闆做高階技術決策，隨便模仿一下，都比我來得強。真是令人挫折啊！
以下是我使用的 prompt
考慮下列五個判斷基準
1. 簡單性（Simplicity）：減少抽象與隱式邏輯，強調工具的可理解性。
2. 一致性（Consistency）：跨平台與不同開發情境下，保持一致的開發經驗。
3. 最小主義（Minimalism）：避免不必要的引入與過度設計，回歸簡單直觀的工具。
4. 可擴展性（Extensibility）：選擇那些能適應多種情境且提供更強擴展性的工具。
5. 長期維護性（Maintainability）：工具選擇以長期穩定性與活躍社群支持為依據。
從下列的 Clojure library 之中，選出最有可能符合需求的 library
$$ library
...