Shire智慧體市場：IDE一鍵安裝多智慧體，協同打造集體智慧Copilot

2025-05-29 11:58 phodal

太長不看版：在新版本（0.8）的 Shire 中，你可以透過 Shire 智慧體市場，一鍵下載和安裝多個智慧體，並直接在你的當前專案中使用。與此同時，你還可以 將你的 Shire 程式碼段或者智慧體上傳到 Shire 智慧體市場。
詳細見影片：

WHY：AI 智慧體應用於真實世界軟體開發的挑戰？

在軟體開發中，確定性是非常關鍵的，特別是在像例項化需求、格式化測試用例等環節，開發人員需要完全可控、精確的結果。然而，生成式 AI 的特點是不確定性帶來的”創新“。受限於此，當前 AI 輔助研發的主要場景還是在補全程式碼、生成註釋等有一定確定性的場景。
在其他更復雜或更精確的開發環節中，AI 智慧體的自動化能力尚未成熟，通常仍需要大量的人工干預。這表明，若要真正提高軟體開發的效率， 開發人員需要引入更多型別的智慧體，以適應不同的場景需求，從而覆蓋各種開發任務。

軟體工程不是紙上談兵

在應用 AI 輔助研發時，透過會分為兩類場景考慮：新功能開發與現有功能維護。新功能開發通常是從 0 開始，而現有功能維護則需要考慮到現有程式碼庫、 現有程式碼風格等。在我們構建各種智慧體原型時，通常會從新功能開發開始 PoC。
哪怕是全新功能，現實中的 AI 輔助研發，遠比簡單的“AI 自動生成 API”的設想要複雜。常見的誤解是：生成一個 API 只需要 AI 生成一個 prompt 即可完成。在實際的軟體開發過程中， 完成一個 API 開發到上線通常需要經過 10 個步驟，或者由 10 個不同的智慧體來協同完成。（詳細等我們下篇文章 詳細介紹）。
每個步驟背後可能涉及不同的團隊、工具與資源，諸如於：API 設計規範、資料庫結構、mock 服務、單元測試、API 測試等。實現一個 API 的自動化開發， 需要考慮到這些步驟的協同與整合。

團隊固有開發正規化

再回到軟體開發的現實場景，每個團隊受限於團隊能力變遷以及歷史的遺留問題，都有自己的開發正規化。再受限於組織的歷史規範與線上問題影響，在一個團隊中， 可能會有多種開發正規化並存：
  • 舊的系統中，API 永遠只返回 200 狀態碼，成功與失敗透過返回值區分。
  • 不舊不新的系統中，API 可能不能用 delete 方法，只能用 post 方法。
  • 新的系統中，API 透過返回狀態碼來區分成功與失敗。
除此，不同的團隊可能有不同的開發正規化：有的團隊更傾向於敏捷開發，快速迭代；有的團隊則更加註重嚴格的需求分析和架構設計。你可能在 A、 B 團隊之間需要一個 API 文件、 API 契約作為 mock 服務來作為中間層，而在 C 團隊中，你可能 API 的提供者和消費者都是你自己，所以你並不需要詳細的 API 文件、mock 服務等。
在這種情況下，未貼合企業實際需求的碎片化工具大量存在各個團隊中，並且難以協同。碎片化的工具不僅會存在大量重複勞動，還會使得 AI 平臺或者工具束之高閣， 無法發揮最大的價值。那麼，我們應該如何去打通這些壁壘呢？

WHAT：集體智慧 Copilot = Team + AI + IDE

集體智慧 Copilot 的核心是透過 AI 與開發團隊深度結合，實現一種團隊與 AI 智慧體共同合作的程式設計體驗。IDE 不再只是一個被動的程式碼編寫環境，而是一個智慧體之間協同工作的平臺。
集體智慧 IDE 是將開發團隊的協作模式與 AI 緊密結合，使開發者與 AI 形成一種雙向學習、協同合作的關係。這種關係不僅僅是單向的自動化工具使用，而是把 AI 當作一個動態的、不斷學習和成長的團隊成員。AI 的職責不再只是自動化程式碼生成或測試，而是透過協作的方式，促進團隊整體能力的提升。

團隊如何分享智慧？

透過觀察大量團隊的開發過程，我們發現：團隊整體能力往往受到精英開發者與普通開發者之間能力差距的制約。
團隊的集體智慧往往體現在資深開發者的經驗積累和知識共享機制中。透過經驗豐富的成員與普通開發者之間的交流，知識得以在團隊中傳遞。然而， 這種機制存在侷限性：知識傳遞的效率可能不高，特別是在複雜或大規模專案中，個別開發者的知識可能被封閉在小組中，難以在整個團隊中流動。在現有的開發模式之下，我們往往會透過：
  • 技術分享會議，來分享優秀的團隊成員的經驗。
  • 程式碼評審、程式碼規範等方式，來提高團隊整體程式碼質量。
  • 程式碼庫、文件庫等方式，來提高團隊整體知識共享。
  • 程式碼生成工具、程式碼模板等方式，來提高團隊整體開發效率。
而如果 AI 將上述的行為自動化之後，我們可能會失去這些優勢。又或者是，我們可以考慮將 AI 作為一個團隊成員，來協同工作，將大量的團隊經驗賦予 AI？

輔助團隊核心：隱性知識的顯性化

當我們開始構建 Team AI 這一類的工具時，我們做的大部分工作知識管理，諸如於將隱性知識轉化為顯性知識。
顯性知識是團隊中明確文件化或口頭傳授的知識，如程式碼規範、最佳實踐等，通常我們會透過程式碼庫、文件庫等方式來傳遞。在 AI 輔助研發的當前階段， 大量的組織熱衷於透過構建知識庫 + 問答機器人的方式來傳遞顯性知識。
隱性知識是團隊中沒有明確文件化或口頭傳授的經驗、技巧和決策邏輯。這種知識通常隱藏在資深開發者的腦海中，或者潛伏在程式碼的歷史和修訂記錄中。在結合 AI 輔助程式設計的過程中，我們發現：AI 的提示詞往往是隱性知識的顯性化。即透過 AI 的提示詞，我們將隱性知識轉化為顯性知識，諸如於各類約定俗成的 模式、最佳實踐等。這種顯性化的過程，不僅可以幫助團隊成員更好地理解程式碼，還可以幫助團隊成員更好地學習、成長。

集體智慧 Copilot

因此，當團隊以上述的方式來分享智慧，並將其結合到 IDE 裡時，它就變成了一個集體智慧 IDE。你可以在這個 IDE 裡：
  • 透過遠端智慧體來獲取團隊的顯性知識，如程式碼規範、最佳實踐等。
  • 透過本地智慧體來獲取程式碼庫中的隱性知識，如程式碼歷史、程式碼風格等。
  • 基於團隊的流程、規範，來編寫生成程式碼、生成測試用例等智慧體。
  • 透過智慧體市場，來下載、安裝、使用團隊的智慧體。
透過將團隊的知識與程式碼庫、團隊上下文等緊密結合，我們可以實現更高效的軟體開發。

HOW：如何實現集體智慧 Copilot？

在 IDE 中實現集體智慧 Copilot，我們可以透過 Prompt 即程式碼的方式來實現，將團隊的知識、經驗、規範等轉化為 prompt，再透過 AI 智慧體來執行。Shire 便可以作為一個實現集體智慧 Copilot 的工具。
Shire 是一個簡便 AI 編碼智慧體語言，它能夠讓大型語言模型（LLM）與控制整合開發環境（IDE）之間自由對話，以實現自動化程式設計。安裝方式：在 IDE 中安裝 Shire 外掛，即可開始使用 Shire。

方式 1：Prompt 即程式碼

舉個例子，假設我們有一個智慧體，用於 Swagger API 文件生成。那麼，我們可以透過 Shire 程式碼來定義這個智慧體的功能：
  1. ---
  2. name:"Swagger Doc to Yaml"
  3. variables:
  4. "code":/any/{ cat($input)}
  5. onStreamingEnd:{ parseCode | saveFile($input, $output)}
  6. ---
  7. 為如下的程式碼，生成SwaggerDoc。不修改任務程式碼，只新增對應的註解。
  8. 檔案路徑：$input
  9. 程式碼：$code
  10. 只返回最後的程式碼，方便我使用。
我們只需要定義好這個智慧體的功能，將其儲存到程式碼庫中，便可以提供給團隊成員使用。

方式 2：Shire 智慧體市場

Shire 智慧體市場本質是利用 Shire 抽象 IDE 的底層能力，將與 IDE 互動、軟體開發的操作，提取為一個個原子能力，諸如於：函式、變數、程式碼模型等。隨後，再讓使用者透過 Shire 程式碼來組織這些原子能力，以實現對應的功能。最後，使用者可以將這些 Shire 程式碼上傳到 Shire 智慧體市場，以供他人下載、安裝、使用。
使用者只需要在 Shire 智慧體市場中，選擇對應的智慧體，點選安裝，便可以直接在 IDE 中使用。諸如於，使用者可以選擇”API 設計、生成與文件“這個智慧體包， 便可以直接在 IDE 中使用這這些智慧體。

其它 Shire 新功能

在新版本（0.8）的 Shire 中，你還將體會到：
  • model 引數，用於在 Shire 程式碼中指定模型的名稱，以支援多模型的呼叫。詳細見：https://shire.phodal.com/shire/shire-env.html 。
  • beforeStreaming 生命週期鉤子，用於啟動應用或者 mock 服務。
  • Git 函式： commit、 push 用於支援 Git 操作。
新的函式：
  • mock 函式，用於與 WireMock 整合，以支援 Mock 服務的啟動。
  • execute 函式，現在可以直接執行 Gradle 任務、Python 指令碼、Shell 指令碼等。
  • batch 函式，用於批次執行多個 Shire 程式碼，可以用於批次添加註釋等。
新語言支援：JavaScript、Go 的語言語法樹（PsiVariable）解析支援。

總結

AI + IDE 是當前前沿的熱門趨勢，人們對於 GitHub Copilot、Cursor、Tabnine 等工具來提高開發效率，已經達成了共識。但是，這些工具的侷限性在於：無法滿足不同團隊、不同專案的需求。我們在過去的一年多時間裡，一直在探索合適的方式來讓 AI 與團隊協同工作，以實現更高效的軟體開發。
在我們構建 AutoDev 時，是個人都想修改 AutoDev 的 prompt。即便，我們不斷開放出 AutoDev 的能力，過於靈活也會使得 AutoDev 變得不堪重負。因此，我們希望透過 Shire 智慧體市場，讓使用者可以自由地選擇、安裝、使用智慧體，以實現集體智慧 IDE 的目標。


相關文章