雲端與IDE智慧體整合：解決工具碎片化，實現AI全流程自動編碼

2025-04-21 01:43 phodal

在那篇《2024 年 AI 輔助研發趨勢》裡，我們談及了未來的趨勢是：從輔助開發人員發展到涵蓋軟體開發的 整個生命週期。而軟體研發本身也是一個複雜的流程，涉及到需求分析、設計、開發、測試、部署等等。在開源的《AI 輔助軟體工程：實踐與案例解析》中，我們研究了國內公司的輔助研發工具，如 Google、GitHub、GitLab 等，以及對應的 Jira、Cursor、IBM Assistant Builder 等工具。
進而發現，現階段我們需要解決一個問題：如何去打通工具之間的壁壘，讓 AI 輔助研發工具更好地協同，以提高研發效率？

AI 輔助研發策略應該如何演進？

下圖是當前 AI 增強的研發工具、平臺的主要構建思路：
當前階段，我們主要透過在已有的 DevOps 工具平臺上，透過 AI 增強，來為端到端工作流、多角色協同場景提供場景化 Agents，提升協同效率。而從未來來看， 當前的 AI 輔助研發工具還存在一些問題。

問題 1：速贏和高槓杆領域已經被摘取

去年 5 月，我們在 QCon 上分享《探索軟體開發新工序：LLM 賦能研發效能提升》裡，其中我們建議企業應該關注：“速贏和高槓杆領域”，以得到更高的的投入產出比。
而在今年這些領域已經被摘取，如在輔助結構化需求、輔助程式碼生成、輔助程式碼審查等領域。大量的企業已經有一系列的“自研”工具，雖然可能缺少一些 最佳實踐，但是或多或少已經在試點中，有一些還取得不錯的效果。對於現有的開發流程而言，我們很難一一增強，我們還要面臨工作使用者缺乏相關的 AI 技能，提不出好的問題和需求。
儘管，我們可以更多地關注長尾領域，如輔助部署、輔助運維等領域。這些領域的 AI 輔助研發工具還處於初級階段，但是價效比不一定更高。

問題 2：AI 平臺與工具的碎片化加深

相似的，如先前的圖所示，企業已經購買了或者自建算力、模型平臺、模型編排等平臺的底層能力，以及大量的知識庫， 再到輔助研發的需求助手、架構助手、測試助手、程式碼助手等等。就當前而言，企業普遍缺乏優秀的 AI 工程師，因此主流的方式是外購或者基於開源軟體構建。
  • 購買方式。對不同的平臺、工具進行大量的前期試點或者評估，再選擇最適合自己的工具。如基於 GitHub Copilot、通義靈碼、CodeGeeX 等等。
  • 自建方式。如基於開源 AI 應用開發平臺 Dify、開源的 IDE 外掛 AutoDev、Continue、開源的各類輔助研發 ChatBot 等等。
在這種情況下，未貼合企業實際需求的碎片化工具大量存在各個團隊中，並且難以協同。碎片化的工具不僅會存在大量重複勞動，還會使得 AI 平臺或者工具束之高閣，無法發揮最大的價值。那麼，我們應該如何去打通這些壁壘呢？

什麼是雲端與 IDE 智慧體協同？

在過去的一年裡，我們看到了一些 IDE 智慧體的案例：
  • Bloop。可以使用自然語言提問，搜尋程式碼，並基於現有程式碼庫生成補丁。
  • Tabnine – Jira to code。開發團隊可以從 Jira 任務中自動生成功能完備的應用程式。
  • GitHub Copilot Workspace。結合 GitHub 平臺的需求功能（issue）、程式碼託管、構建、部署平臺，實現從需求到程式碼的自動生成與部署。
  • ……
這些智慧體的共同點是：透過結合工具鏈來獲取 IDE 的上下文資訊，再結合雲端的知識庫等，來處理對應的的任務需求。

IDE 智慧：如何最大化程式碼的價值？

在 IDE 側，與智慧體相關的能力通常有兩類：
  • 本地智慧體。直接從本地獲取所需上下文，直接與模型進行互動，如常用的 @workspace 功能，用於直接與程式碼庫進行問答。
  • 雲端智慧體整合/智慧體市場。即與雲端的智慧體進行互動，透過多輪資訊通訊，提供其所需要的上下文，諸如 AutoDev 自定義的智慧體、GitHub Copilot Extension 等。
對於本地智慧體來說，其主要的優勢是：速度快，可以直接快速獲取本地的上下文資訊，不需要網路傳輸。但是，其缺點是：*無法獲取雲端的知識庫 *，無法獲取更多的領域知識。所以，對於一些需要大量領域知識的任務，如需求生成程式碼、程式碼審查等，我們需要透過雲端智慧體來獲取更多的知識。
因此，對於 IDE 側來說，我們需要能動態地提供雲端所需要的上下文資訊，並提供對應的智慧體介面，以支援雲端智慧體的呼叫。

雲端智慧體：內部資產與研發知識的整合

如圖 1 所示，我們在過去已經構建了一系列的智慧體，它們都基於各自領域的特點，提供了所需要的知識與最佳實踐。諸如，我們會在需求助手中，新增所屬領域的 知識庫，需求編寫的最佳實踐等等。而事實上，對於這一類需求助手只有這一些是不夠的，程式碼的現有實現邏輯，會影響新功能的設計。
進而我們會發現：軟體研發的各類智慧體是你中有我，我中有你的。只是單獨的一個智慧體是無法完成整個研發流程的，我們需要將這些智慧體進行整合，以支援 整個研發流程。

雲端與 IDE 智慧體協同的實現

在雲端，大量企業已經構建了類似於 Dify 的 AI 應用平臺，在這些應用平臺上，已經可以支援對智慧體的編排，因此實現上起來並不困難。但是，對於 IDE 側來說，我們還需要構建一個類似的智慧體編排系統，以支援 IDE 側智慧體的呼叫。

IDE 智慧體編排系統

在 IDE 側，我們需要構建一個智慧體編排能力，以支援 IDE 側智慧體的呼叫。它需要支援：
  • 快速獲取 IDE 上下文資訊。如當前的程式碼庫、當前的程式碼、當前的需求等等。
  • 輕量級的上下文處理。諸如對於程式碼庫的搜尋、靜態程式碼分析等等。
  • 與雲端智慧體的互動。透過 API 呼叫，獲取雲端智慧體的結果。
  • 與三方工具的整合。如與 Sonarqube、GitHub、Git 等工具的整合，以支援對應的需求、程式碼庫的獲取。
  • 資料的安全性。對於程式碼庫、需求等敏感資訊，需要進行加密處理。
讓使用者能夠為他們自己的 IDE 建立定製的 AI 智慧體，從而構建個性化的 AI 驅動開發環境。

雲端與 IDE 智慧體協同實現：Shire 示例

Shire 提供了一種簡便 AI 編碼智慧體語言，能夠讓大型語言模型（LLM）與控制整合開發環境（IDE）之間自由對話，以實現自動化程式設計。在 Shire 中，你可以 透過程式語言的方式，來定義與 IDE 的互動資訊處理，以及與遠端智慧體的互動。
PS：安裝方式，Intellij  等 IDE  在外掛市場搜尋 Shire
如下是一個簡單的 Shire 結合資料庫資訊，與遠端智慧體生成 SQL 的示例：
  1. ---
  2. name:"設計資料庫"
  3. variables:
  4. "requirement":/any/{ thread(".shire/shell/dify-epic-story.curl.sh")| jsonpath("$.answer",true)}
  5. afterStreaming:{
  6. case condition {
  7. default{ execute("gen-sql.shire", $requirement, $output)}
  8. }
  9. }
  10. ---
  11. [相關的資料庫設計庫提示詞]
  12. —Useruse database: $databaseInfo
  13. -User tables: $tables
  14. Here are the User requirements:
  15. $requirement
在這個示例中，我們透過 thread 函式，呼叫了一個部署於 Dify 上的遠端智慧體，獲取了相關業務的需求。在 AI 分析完需求後，再透過 execute 函式， 再呼叫了一個本地的智慧體（即 gen-sql.shire），生成了 SQL。在 gen-sql.shire 中，我們定義了基本的 SQL 規範，以讓 AI 生成的 SQL 更符合 企業規範。
你可以在我們的 GitHub 上找到更多的示例：Shire 示例 （ https://github.com/shire-lang/shire-spring-java-demo ） 。

小結

去年，我們在設計開源 IDE 外掛 AutoDev 時，構建了一個 AutoCRUD 的智慧體。這個智慧體可以獲取 GitHub、GitLab 上的 issue 作為需求，再結合本地的程式碼庫，自動對程式碼進行修改。
我們相信，未來的 AI 輔助研發工具應該是：雲端與 IDE 智慧體協同。即透過 IDE 側的智慧體編排系統，與雲端智慧體進行協同，以支援整個研發流程的 自動化。


相關文章