實現AI輔助軟體工程：團隊如何量身打造AI4SE體系？

PS：本文節選自開源電子書《AI 輔助軟體工程：實踐與案例解析》第一部分《AI4SE 體系設計》（https://aise.phodal.com/design-aise.html）

受限於自身企業的規模與人員結構，AI 輔助軟體工程（AI4SE）的設計與實施過程會有所差異。諸如於：

研發外包型企業，對於 AI 輔助研發的需求並沒有特別強烈？（待進一步調研）
小型研發組織，生存是主要問題，因此對於資料敏感度不高，可以採用 SaaS 方案；當團隊中出現能力較強的人員時，會基於開源工具進行簡單的開發。
中大型研發組織，對於資料敏感度較高，因此會選擇自建 AI4SE 體系，以保證資料的安全性。

結合我們在其它組織的經驗，以及 ChatGPT 給我們的建議，可以得到以下的 AI4SE 體系設計流程：

初步明確 AI4SE 設計目標：確定透過 AI 實現的可落地目標，如提高開發效率和提升程式碼質量。
識別痛點和需求：評估當前軟體工程流程中的痛點和瓶頸。
選擇合適的AI技術：根據業務需求選擇合適的 AI 技術，如機器學習、深度學習、自然語言處理等。
構建跨學科團隊：組建包含資料科學家、AI 工程師、軟體工程師和業務專家的團隊，並提供AI相關培訓。
開發原型與整合：開發和測試 AI 應用的原型，並將有效模型整合到現有工具鏈中。
逐步實施與評估：採用小規模試點逐步擴大的策略，並定期評估體系績效，使用關鍵績效指標進行衡量。
持續改進與技術更新：收集使用者反饋，持續最佳化工具和指標，並跟蹤引入最新技術和工程方法。

除此，設計適合自身公司的 AI4SE 體系是一項複雜且難度極大的工作。這一過程需要綜合考慮公司的具體情況、業務需求以及現有的資源。

初步明確 AI4SE 設計目標

儘管生成式 AI 技術在軟體工程領域的應用已經取得了顯著進展，但在實際應用中，AI 技術的效果並不總是如人們所期望的那樣。諸如於：

環境適配問題。生成式 AI 可以根據一張圖片生成前端程式碼，但由於每個企業內部使用的前端框架、元件庫等不盡相同，生成的程式碼往往無法直接在實際專案中使用。這意味著，生成式 AI 必須考慮到不同組織的技術棧和環境需求，才能真正發揮其作用。
程式碼質量不穩定。由於生成式 AI 的固有限制，生成的程式碼質量並不總是穩定或符合最佳實踐標準。在實際應用中，人工稽核和質量保證仍然是必不可少的。這種人機協作的方式可以彌補 AI 的不足，確保程式碼的可維護性和可靠性。
能力限制。生成式 AI 更擅長生成新的程式碼，而不是修改現有的程式碼。這意味著在處理現有系統的維護和升級時，生成式 AI 的作用可能有限。因此，AI 需要具備與現有程式碼庫互動的能力，才能在實際應用中提供更大的價值。
上下文理解不足。生成式 AI 在生成程式碼時，常常無法充分理解專案的整體上下文或業務邏輯。這種上下文理解的不足，可能導致生成的程式碼與專案 AI 需要適當補充背景資訊，才能更好地滿足專案的實際需求。
複雜任務處理能力有限。儘管生成式 AI 在簡單的編碼任務上表現出色，但在處理複雜的系統設計、架構決策或多模組整合時，其能力仍然有限。面對這些高複雜度的任務，生成式 AI 可能需要更多的人工干預與支援。
……

除此，AI4SE 的設計目標還應該考慮到企業的具體情況和需求。例如，對於一家初創公司來說，提高開發效率和降低成本可能是首要目標；而對於一家傳統企業來說，提升軟體質量和可維護性可能更為重要。

小型研發團隊：提升開發人員體驗 or 改善流程規範？

對於小型研發規模的組織來說，ROI 是一個重要的考量因素 —— 與規模化提升效率相比，提升開發人員的體驗是一個更合適的目標。也因此，直接採用現有的 SaaS 服務是一個更為經濟的選擇，結合一些 “免費” 的 AI 工具，並提供一些內部的培訓和文件，就可以實現部分 AI4SE 的關鍵目標。

同時，在這一階段，我們可以透過分析現有的 AI4SE 相關工具，來了解市場上的最新技術和趨勢。諸如於，我們先前分析的一些工具鏈示例：

除此，由於小團隊並沒有規範的流程，在關鍵環節上可能是缺乏的，到底是結合 AI 來引入流程，還是放棄某個流程，是一個需要考慮的問題。除此，由於過往缺少相關的規範，AI 並不定帶來很大的受益，還可能會帶來額外的成本。

中大型研發團隊：提升軟體質量 or 降低流程成本？

對於中大型研發規模的組織來說，由於企業已經有成功的商業運營模式，與提升開發效率相比，提升軟體質量和降低流程成本是更為重要的目標。畢竟，在過去的幾十年間，大量的企業在迭代自己的軟體工程，從瀑布、敏捷到 DevOps，形成了一系列經典的工具和流程方法。

對於質量要求高的組織來說，軟體質量遠比開發效率更為重要。
對於流程成本高的組織來說，流程才是限制開發效率的瓶頸。
對於大型系統來說，溝通成本和協作成本是更為重要的問題。
……

儘管，我們會統一來看待大型組織中的 AI4SE 體系設計，但是實際上，每個組織所考慮的首要問題是不同的。我們應該根據企業的具體情況和需求，來確定我們的目標？

服務型團隊：改善開發體驗 or 提降低遷移成本？

除此，我們還需要考慮到團隊的結構和組織文化帶來的影響。諸如於，團隊的拓撲結構會影響到團隊的目標：

團隊拓撲

對於諸如平臺型團隊、SaaS 企業、雲服務提供商等服務型團隊來說，他們的目標可能是：

降低使用者的遷移成本：諸如結合平臺的特性，構建結合 AI 的遷移工具，以降低使用者的遷移成本。
提升開發人員的體驗：構建輔助編碼、部署等相關的 AI 工具，以提升開發人員的體驗。
提供基於平臺的知識問答：降低使用者的學習成本、知識負載。
……

當然可能還存在其它型別的團隊，受限於筆者的經驗，這裡不再一一列舉。

識別痛點和需求

通常來說，目標是分為多級的，類似於 OKR 的自上而下的目標設定。在 “初步明確 AI4SE 設計目標” 中指的是由高層決策者確定的目標，而在這裡，通常是真正的痛點和需求，需要由組織的中層管理者，諸如研發效能/工程效能團隊等來確定。當然了，再往下，就是由團隊的一線開發人員來確定，諸如更詳細的實施細節和指標等。

基於軟體生命週期分析/DevOps 流程分析

當企業構建成熟的 DevOps 流程時，AI4SE 的實施會更加順利。下圖是，Thoughtworks 在 2023 年初對 AI 輔助軟體工程的流程分析，即在軟體開發的不同階段，AI 可以提供哪些輔助功能：

我們就可以探索如何在不同階段使用 AI 工具，而在這時需要不同的角色參與到這個過程中，以確保我們設計出來的體系符合不同角色的需求。例如：

產品經理：在需求分析和專案規劃階段，AI 可以幫助自動生成需求文件，或進行需求優先順序排序。
開發人員：在編碼和測試階段，AI 工具可以輔助程式碼生成、程式碼審查以及自動化測試。
運維人員：在部署和監控階段，AI 能提供智慧化的日誌分析、自動化故障排除和效能最佳化建議。
……

而隨著我們探索的進一步深入，可以建立多階段協同的 AI4SE 體系，如：AI 根因分析時能自動修復程式碼問題。

基於資料分析與識別

市面上已經有大量的關於軟體工程效率和 AI 相關的資料分析報告，諸如於 JetBrains 和 GitKraken 的 2024 State of Git Collaboration 年度報告，會指出：

較小的團隊通常在敏捷性和滿意度方面表現優於較大的團隊。
團隊成功的關鍵似乎在於團隊成員數量與任務管理之間的平衡。

而其中會發現團隊在上下文切換、不明確的優先事項和無效會議等方面存在問題，導致浪費時間和精力，真正在編碼的時間不到總工作時間的 40%。

Context Switch

除此，再加上不明確的優先事項，使開發人員不確定哪些任務需要立即關注，這些陷阱可能會創造一個充滿挑戰的工作環境。為了解決這些問題，團隊應實施清晰的溝通渠道，以減少上下文切換的需求，並簡化會議議程，以確保每次會議都有明確的目的和清晰的結果。

"上下文切換、不明確的優先事項和那些永無止境的會議。它們感覺像是煩惱，而 GitKraken 的這份報告有資料證實它們確實是煩惱。作為開發人員和開發團隊，是時候尋找匹配我們需求的工具和工作流程，消除讓我們不開心的噪音。進入狀態，構建出色的軟體！" —— GitKraken CEO：Matt Johnston

透過識別這些痛點並針對性地引入 AI4SE 工具和流程最佳化，團隊可以顯著提升工作效率和滿意度，為構建更高質量的軟體奠定基礎。

選擇合適的 AI 技術

在原型開發階段，可以嘗試不同的 AI 技術，如機器學習、深度學習、自然語言處理等，以確定最適合公司需求的技術。而在實際應用中，需要考慮 AI 模型與基礎設施的整合、資料安全性、模型解釋性等因素。

結合內部技術棧

由於，大量的 AI 科研人員使用的是 Python 語言，已經有大量的 AI 開發框架和基礎設施，因此人們喜歡優先考慮 Python 作為 AI 開發語言。這種趨勢也從科研和一些基礎設施影響到了應用層。如在 2023 年，Python 生態下的 LangChain 和 LlamaIndex 是人們構建生成式 AI 的兩個主要框架。

回到企業應用開發時，可能更傾向於使用 Java、C++ 或其他語言。諸如於我們在設計 Unit Mesh 相關開源方案時，由於內部大量的基礎設施是建立在 JVM 上，因此我們選擇了 Kotlin 作為主要的開發語言，開發了對應的 LLM 開發框架 ChocoBuilder，以支援 AI 模型的快速構建。如今不同的語言也有不同的 LLM 開發框架，如：Spring AI 等。

在典型的向量資料庫層面，沒有技術棧限制的組織，可以靈活地選擇新的向量資料庫，如：Milvus、Qdrant 等，以支援 AI 模型的快速檢索。而有技術棧限制的組織，往往會結合過往的技術棧，如支援向量搜尋的 ElasticSearch 版本，PostgreSQL + pgvector 等。

採用主流 AI 工具的技術棧

在另一方面，我們注意到，國內的AI輔助程式設計工具，早期大多采用與 GitHub Copilot 類似的技術棧、演算法和互動方式。許多領先的AI輔助編碼工具，在程式碼分層、檔案命名以及變數命名等方面，都展現出高度的相似性，其精細程度，宛如天工。

考慮到在這些 AI 輔助研發領域，諸多東西都是相似的，我們可以參考主流的技術棧實現與實現思路：

結合 TF/IDF 或者 BM25 演算法改進程式碼檢索的效果，提高程式碼檢索的準確性。
採用 Jaccard 相似度演算法，提高程式碼相似性檢測的效果。
使用 TreeSitter 或者 AST 技術，進行語法分析，以構建更好的互動體驗。
……

只是呢，演算法、工具和技術棧等都存在學習成本，還需要結合團隊的實際情況，選擇合適的 AI 技術。諸如：Continue.Dev 採用 JavaScript + WASM + LanceDB 作為本地向量技術棧，而通義靈碼採用的是 RocksDB 作為本地向量技術棧。

構建跨學科團隊

在構建 AI4SE 體系時，跨學科團隊的協作至關重要。AI 工程師與資料工程師通常在演算法設計、模型訓練和資料處理方面具有專長，但他們可能不熟悉軟體工程的最佳實踐、架構設計和程式碼維護。而軟體工程師則在構建可靠、高效的軟體系統方面有豐富的經驗，但在 AI 模型的開發和調優方面可能缺乏深入的瞭解。

跨學科團隊

建立一個跨學科團隊，結合兩者的優勢，是成功實施 AI4SE 體系的關鍵。：

互補能力：透過培訓和知識共享，讓團隊成員瞭解彼此的工作領域。AI 工程師可以學習基本的軟體工程原則，而軟體工程師可以學習如何利用 AI 工具和模型。
協作工具：使用協作工具和平臺，如知識庫和即時協作軟體，幫助團隊成員共享資訊和進展。
定期溝通：定期組織團隊會議，確保每個成員都能瞭解專案的整體進展，及時解決跨學科合作中的挑戰。

當然了，如果能定期與其它團隊進行交流，也是非常有幫助的。諸如於我們在 Thoughtworks 的開源專案中，我們會定期與其它團隊進行交流，以瞭解其它團隊的 AI4SE 體系設計，以及其它團隊的 AI4SE 體系設計的優勢和不足。

相似的，構建這種跨團隊的激勵機制和協作，也是另外一個非常大的挑戰。

軟體工程是 AI4SE 的基礎

筆者作為一個典型的工程師，會更傾向於認為軟體工程是 AI4SE 的基礎。理解軟體工程的基本原則和最佳實踐，是這個團隊必須要具備的能力。諸如，你需要理解

開發人員如何編碼測試，才能設計好 AI 生成測試。
團隊中的人員能力差異，以設計適合不同梯隊的功能需求。
軟體開發的編碼規範與習慣，以設計出規範化的程式碼生成。
理解如何編碼，以在 IDE 的不同觸點上提供 AI 功能。
……

諸如此類的還有開發人員的日常工作流程、程式碼審查、程式碼合併、程式碼測試等是如何進行的，這些都是 AI4SE 體系設計的基礎。儘管，你可以透過對開發人員進行訪談、觀察開發人員的日常工作流程等方式，來了解這些基礎知識，但是，如果你自己不具備這些基礎知識，那麼你很難設計出一個符合實際需求的 AI 工具。

開發原型與整合

一個早期可工作的原型是整個體系的關鍵，它可以幫助團隊快速驗證可行性，並決定下一步的發展方向與資源的多少。通常來說，在當前階段，我們可以看到諸多企業會基於市面上開源的成熟或者半成熟的 AI4SE 工具，進行原型開發。

基於開源軟體構建原型：AutoDev 示例

我們在 2023 年的早期構建了開源的 AI 輔助研發工具 AutoDev，作為國內首個開源的 AI 輔助研發方案。透過 GitHub 的 issue，我們看到了大量的企業和團隊基於其進行原型開發：

結合免費的 SaaS/MaaS 服務，以讓自己有一個 “免費” 的 AI 編碼助手。
使用 Ollma 在本地執行 LLM，以探索 AutoDev 的能力。
在企業內部部署 One API 服務，以試驗不同的模型在實際專案中的效果。
基於 AutoDev 定製，以滿足特定的業務需求。
……

類似的，我們也可以在企業內部以相似的方式，基於市面上的開源工具，進行原型開發。

構建適合原型開發的 SDK

我們在設計 LLM 開發框架 ChocoBuilder 時，構建了一系列幫助開發人員快速構建原型的能力，以驗證 AI 模型在實際專案中的應用效果。如下是 ChocoBuilder 構建 RAG 的示例：

@file:DependsOn("cc.unitmesh:rag-script:0.4.6")
import cc.unitmesh.rag.*
rag {
indexing {
val chunks = document("README.md").split()
store.indexing(chunks)
}
querying {
store.findRelevant("workflow dsl design ")
.lowInMiddle()
.also {
println(it)
}
}
}

在這個示例中，我們使用 RAG 指令碼將文件內容分塊並進行索引，然後透過查詢相關內容，展示瞭如何在開發環境中快速測試和整合 AI 功能。

逐步實施與評估

在企業中，由於多數工具團隊在過往有失敗的工具推廣經驗，所以在推廣工具時，往往會採用漸進式的策略，以有效降低風險，並使團隊能夠逐步適應新技術。也因此，如何設計合理的度量體系來監控和評估 AI4SE 的效果是至關重要的。

通常來說，我們會關注於以下幾個方面：

開發效率：評估引入 AI 工具後，編碼速度是否得到了提高，例如，程式碼接受率、程式碼入庫率、響應時間等。
程式碼質量：使用靜態分析工具和程式碼審查來衡量 AI 生成程式碼的質量，評估 AI 生成質量和程式碼可維護性。
使用者滿意度：收集開發團隊對 AI 工具的使用反饋，分析其在實際工作中的體驗和效果。
功能使用頻次：監控不同 AI 功能的使用頻次，瞭解團隊對 AI 工具的偏好和需求。
業務指標：透過業務關鍵績效指標（KPI）來衡量其對整體專案進展和成功率的影響。
……

需要注意的是，由於統計口徑上的差異，會導致不同的度量體系下的同一個指標有不同的結果。諸如於，AI 程式碼入庫率可能會涉及到 3、 5、10 分鐘內的程式碼變更，又或者是使用者無操作等不同口徑；程式碼接受率會受到語言因素影響較大，如有的模型 Python 程式碼接受率可能會高於 Java 程式碼接受率，而靜態型別語言的程式碼接受率遠高於動態型別語言。

這些指標都需要在初步執行後，根據團隊的實際情況進行調整，以確保度量體系的有效性和可靠性。