隨著 smartfunc（一個將文件字串轉換為LLM驅動函式的Python庫）的釋出，開發者們之間掀起了關於將大型語言模型整合到程式設計工作流程中的最佳方法的熱烈討論。這場辯論突顯了一個基本問題：LLM應該被視為高階規範的編譯器，還是開發過程中的協作助手？
編譯器與助手正規化之爭
社群討論顯示，許多開發者強烈傾向於將LLM視為編譯器而非初級開發人員。這種方法將LLM定位為將高階規範（如文件字串）轉換為功能程式碼的工具，而非透過對話生成程式碼的協作者。一位評論者清晰地表達了這種觀點，認為將LLM視為編譯器代表了一種比視其為開發助手更具可擴充套件性、可擴充套件性和可組合性的思維模型。
然而，正如 Simon Willison（為 smartfunc 提供支援的底層 llm 庫的建立者）指出的那樣，smartfunc 實際上並不像編譯器那樣運作。相反，它將函式轉換為每次執行時都呼叫LLM的函式，將文件字串作為提示傳遞。這一澄清引發了關於真正類似編譯器的實現可能是什麼樣子的進一步討論——也許是在首次呼叫時生成並快取Python程式碼，而不是重複進行API呼叫。
執行時靈活性和替代方法
幾位開發者強調的一個重要限制是在執行時使用不同LLM的同一函式的困難。smartfunc使用的裝飾器模式在匯入時鎖定了模型選擇，一些人認為這對生產環境來說過於限制。有人提到了像 think 這樣的替代庫，它透過顯式傳遞LLM物件提供了更多靈活性。
討論還涉及了不同語言中的類似實現，開發者們提到了JavaScript的類似工具，以及對Java版本的興趣。這種跨語言的興趣表明，對於將LLM整合到各種開發環境中的標準化模式的需求正在增長。
討論中提到的類似庫
- smartfunc：將文件字串轉換為 LLM 函式的 Python 庫
- Tanuki：與 smartfunc 功能類似
- promptic：包裝了 litellm，支援多種模型提供商
- think：採用傳遞 LLM 物件的替代方法，提供執行時靈活性
- llm-docsmith：為現有程式碼生成文件字串的外掛
- neuro-lingo：被提及具有"固定"函式結果的功能
- instructor：具有驗證支援的更多功能的替代方案
- marvin：另一個 LLM 函式庫
自然語言程式設計的未來
幾位評論者將當前的LLM整合努力與歷史上使程式設計透過自然語言更加易於訪問的嘗試進行了比較，例如20世紀60年代的COBOL。雖然COBOL代表了早期嘗試使用類似英語的語法，但現代LLM可能使我們更接近Jensen Huang的願景——自然語言成為一種程式語言。
討論還強調了工作流程中的一個有趣對比。雖然smartfunc使用文件字串生成功能，但一些開發者報告他們以相反的方向使用LLM——讓它們為註釋不足的程式碼生成全面的文件。程式碼和自然語言之間的這種雙向關係暗示了不斷發展的開發實踐，其中規範、實現和文件之間的界限變得越來越模糊。
快取和本地執行
展望未來的改進，開發者們對將LLM功能提煉為針對特定功能的更小、更專業的模型而非重複呼叫基礎模型API的方法表示了興趣。這可能會減少延遲和成本，同時提高可靠性。
快取已知良好輸出的概念也被討論為減輕LLM非確定性本質的一種方法。一些人建議在構建步驟中生成程式碼，根據測試或編譯要求驗證它，然後快取成功的結果——有效地沙盒化LLM可以更改的內容，同時保持開發者的控制權。
隨著LLM整合模式的不斷發展，社群似乎正在趨向於既保持程式設計師主導權又利用AI處理重複或冗長編碼任務的方法。無論是透過像smartfunc這樣的文件字串驅動的函式，還是更復雜的程式碼生成和快取系統，這些工具代表了朝向新程式設計正規化邁出的早期步伐，在這種正規化中，自然語言和程式碼存在更加共生的關係。
參考：smartfunc