一線落地AI輔助研發的實踐心得：從工程、工具到未來展望

在過去的一年裡，我大量的時間都花費在了 AI 輔助研發的調研、方案與落地實踐上：

年初，我們與國內大量網際網路大廠一起，調研國內外 AI 輔助研發的現狀，探討了 AI 輔助研發的現狀與未來。
我們新增了 AutoDev 的大量功能，如精準測試、自定義團隊提示詞、自定義智慧體等。
與公司前 AI 部門，一起協作在客戶側，落地了 AutoDev 自動補全。
年中，建立了全新的 AISE 知識站點 aise.phodal.com，以記錄我們的調研、實踐與心得。
建立了下一代 AI IDE 外掛 Shire，以探索 AI 輔助研發的新模式。
年末，在網際網路客戶側，探索和落地了我們在 AI 輔助團隊的方案 Team AI。

儘管，AI 輔助研發的現狀並不是那麼樂觀，但是我們仍然看到了 AI 輔助研發的巨大潛力。結合這一年的實踐中，我想分享自己的心得並吐槽一下國內的 AI 輔助研發工具的不上進。

1. 短期內，別指望 AI 輔助研發能帶來多大效果

商業化公司總是在一味鼓吹 AI 的短期效果，聲稱 AI 輔助研發可以提升 10%～30%+ 的效率。限於，我的開源工具和他們算是有利益衝突，這裡就不點名了。從個人的角度來說，在這些商業公司釋出裁員訊息之前，這些資料都是不可信的 —— 儘管我的觀點是 AI 會淘汰一部分程式，也會有新的 AI 開發機會。

一如我在先前的文章裡分享 Thoughtworks 之前的統計資料，AI 輔助研發的全鏈路提升在 2% 到 13% 之間，對於大部分已有專案的提升會在 5% 以下。原因不外乎，原有遺留知識不全、開發流程限制、自動化流程不成熟、AI 工具不成熟。但是，總體來說，如果我們還採取現有的流程，不限於需求流程、開發流程、釋出審批流程等。

但是，我們也要看到好的一方面：

減少重複性工作。AI 對於規範、重複性的工作，還是有很大的幫助的。比如，已有規範體系完整下，它可以大量減少重複性工作，諸如於規範化的開發文件、程式碼規範、測試用例等。
降低知識搜尋成本。對於採用內網的開發的公司，諸如金融、通訊等行業，模型內建的知識庫就是一個非常好的搜尋引擎。儘管它的準確性不高，但是也過去相比，仍然具備非常大的優勢。
提升開發幸福感。透過自動完成一些繁瑣的任務，AI 可以讓開發者更加專注於創造性的工作，從而提高工作的滿意度。
促進新技術學習。AI 可以作為一個學習工具，幫助開發者快速理解和掌握新的程式語言、框架和技術。
……

也因此，從成本的角度，能在內部跑上一個 70B+ 的模型，也能大大提升效率 —— 前提是配套上一些合適的 AI 外掛和工具。

2. 透過確定性提升準確性，是降低幻覺的關鍵

年初，我們在為某家商業銀行設計 AI 輔助單元測試方案時，結合的是遠端測試用例智慧體 + AutoDev 的精準測試能力來生成。作為一個經常寫測試的人，我發現 AI 生成的測試用例，有時候會有一些不準確的地方，諸如於：測試框架、資料準備、測試用例的邊界條件等。這也是為什麼在國內某商業 AI 輔助研發公司的競品調研中， AutoDev 的測試能力是國內這些工具裡最強的。在測試用例生成上，是基於確定性的開發框架、測試框架、函式輸入輸出來生成，以進一步降低 AI 生成的幻覺可能性 —— 儘管依然會有一些幻覺，但是與普通的聊天型 AI 相比，我們的幻覺要低很多，並且接受率更高，可以做到一鍵生成。

那麼，作為確定性的輸入應該包含哪些？

工具上下文知識。諸如於測試框架、開發框架、程式語言等。
業務知識。來自於實現開發功能前，我們已經有的業務知識，如需求文件、設計文件等。
領域知識。結合不同行業特點，包含一些特定的領域知識，如金融、電商等，以生成更加符合業務場景的內容。
規範性知識產出。諸如於在測試用例生成時，測試人員編寫的測試用例、測試資料等。

所以，與之對應的另外一個難點是，團隊過去沉澱過多少領域知識、規範性知識產出，以及如何將這些知識轉化為 AI 可以理解的知識。

3. “手動介入” 是不可避免的提升關鍵上下文手段

在國外流行的 AI 輔助工具裡，諸如於 Cursor、GitHub Copilot、Continue 等都支援了一些手工的上下文能力。使用者可以根據自己的場景，有選擇性地新增一些上下文資訊如檔案等，以這種方式來提升上下文的確定性，避免 AI 生成的幻覺。而在 AI 問答場景下，則往往會透過二次確認的方式，來讓使用者確認其意圖是否正確，以避免出現錯誤的意圖理解。

那麼，有哪些高效地手動介入方式呢？

使用註釋或特定的標記語言，在程式碼中新增上下文資訊。如：在 AutoDev 中的聊天輸入框使用變數，如: $selection, language 等方式。
透過互動式介面，即時提供反饋和修正，以引導 AI 生成更準確的內容。如：在輸入區域中，可以選擇相關的檔案，或者額外加入檔案等。
建立模板或模式，讓使用者可以根據特定的場景選擇和應用。如：在 JetBrains AI 外掛中，可以選擇提交資訊、測試等的模板，以生成更加符合場景的內容。
自定義提示詞，以讓團隊加入特有上下文資訊。如：在 Continue 中，使用者可以自定義一些提示詞和 action 等，來生成更加符合團隊的內容。
……

與之相匹配的是，這些手動介入的方式存在大量的學習成本，以及如何讓使用者更好地理解這些手動介入的方式，以提升使用者的使用體驗。

4. 構建統一的領域語言，依舊是 AI 輔助複雜應用的必經之路

四月，我們開始構建 AutoDev 的 VSCode 版本，在這個版本中我們加入了兩個 @workspace 似的聊天問答策略，以幫助使用者更好地理解 AI 的生成內容。策略一參考的是輔助知識理解的 Bloop 專案，它採用的是假設性程式碼生成的檢索方式；策略二參考是 GitHub Copilot 的關鍵詞生成方式，將使用者的問答轉換為關鍵詞來進行檢索。不論是哪種方式最後都會遇到挑戰，一個專案的過去和現在的開發人員，並沒有對如何命名達到一致的標準。這也就導致了 AI 並不總能很好地檢索到相關的內容。

團隊協作是靠共識來推動的，而共識是 AI 輔助團隊的一個基礎。在採用經典的軟體工程方法，如領域驅動設計（DDD）等，我們是透過：

定義領域模型。透過領域模型，將業務領域中的概念和規則抽象出來，形成一致的語言和概念體系。
建立統一的語言。確保團隊成員在溝通和開發過程中使用統一的語言和術語，減少誤解和溝通成本。
應用領域驅動設計原則。透過劃分 bounded context（限界上下文），明確不同部分的職責和互動，構建清晰的應用架構。

這也就意味著，我們需要透過工程的方式告知 AI 工具，模型、語言和上下文邊界，避免長上下文導致 AI 迷失的問題。

構建統一領域語言的過程並非一帆風順，它需要團隊的共同努力和持續的維護更新。反向的，這就意味著，我們需要藉助 AI 進行知識的重構，諸如於生成合乎命名的程式碼、重構出更好的領域語言等。

5. 領域知識的檢索是條條大路通羅馬

七月，當我在休長期服務假時，我建立了全新的開源專案《AI輔助軟體工程：實踐與案例解析》：https://aise.phodal.com/。在這個專案中，我收集了國內外的大量 AI 輔助研發工具，並進行了大量的調研與案例分析。在這個過程中，我發現了一個有趣的現象：AI 輔助研發工具的領域知識檢索方式是多樣的，對於不同的工具團隊，採納的方式也是不同的。

通常來說，羅馬不是一天建成的，我們可以簡單地把 AI 輔助廠商分為兩類 —— 基於已有的開發工具增強的，如 SourceGraph、JetBrains 等；基於新的 AI 工具增強的，如 Cursor 等。在歷史包袱不同的情況下，它們的領域知識檢索方式也是不同的。

結構化知識依舊是首選。儘管有大量的工具可以將你的 PDF、Word 等轉換為 markdown，再去拆分 chunk，但是這並不是最好的方式。不同文件的結構化方式不同，你需要根據不同的文件型別，採用不同的結構化方式。結合 AI 先進行初步的清洗，是值得去嘗試的一條路徑。
充分利用數字化工具是不可或缺的。諸如 SourceGraph Codey 就可以藉助已有儲存的程式碼搜尋能力進行檢查。而諸如於如果你的目標更為宏大，諸如於基於 Gitlab 或者 Confluence 構建統一的內部 API 市場與查詢，那麼你得考慮先進行數字化的 API 管理，其次再進行 AI 的檢索。
不同環節考慮不同向量化模型。如果只是簡單的程式碼檢索，可以考慮直接使用本地的模型。而如果是需要跨團隊、跨專案的檢索，那麼你需要考慮使用雲端的模型。

在沒有進行結構化之前，向量化是效率最低、效果最低的一種方式，但是實踐成本最低的一種方式。實踐成本最低，並不意味著成本最低，只是上手成本最低。

6. 智慧體的規劃應該是基於模式拆解而來的

AutoCRUD 是我們探索 AI 編碼能力極限的第一個嘗試。在這個試驗裡，我們將 AI 與編碼的 CRUD 模式相結合，從而讓 AI 實現自動的編碼流程。儘管，這並非主流的 AI 自動編碼方式，現今的智慧體都是基於 AI 來進行規劃的。而 AI 規劃是基於通用的知識庫，也就是在你這個場景之下，Controller-Service-Repository 分層之下，它的編碼方式應該就是這麼去修改的。當你新增新的功能時，也應該採用類似的方式。

而當你在利用 AI 來進行任務拆解的時候，它也是基於已有學習到的模型進行的拆解。而一旦你的程式碼中有一些不符合模式的時候，它就會出現問題，比如你的程式碼中可能同時存在多種程式設計正規化。

模式應用到規則化提示詞。模型理解主流的各種程式設計正規化，自然而言，我們只需要根據不同的語言，動態生成適用於不同語言的模式即可。
清晰的任務描述是規劃的基礎。我曾經大量使用 GitHub Copilot CodeSpaces 來進行程式碼生成，它可以結合我在 GitHub issue 的描述，來生成程式碼。當你的任務描述不清晰時，它就會出現問題；而當你的任務描述清晰時，它的問題就會減少，但是也寫不出可執行的程式碼。
整合環境依然是智慧體的最好介質。儘管有大量的雲端 AI 編輯器，但是缺少 IDE 中的 I（Integration 整合）能力，AI 就難以自動化進行任務，諸如於語法修復、執行測試、輔助進行 debug 等。

也因此，它需要拿到足夠的上下文才能做好任務的拆解，而如我們所知的它總是拿不到足夠的上下文。

7. 面向 AI 的知識重構，是不可避免的路徑

Unblocked 是我看到一個非常有創意的 AI 知識管理和消費工具 —— 它可以上你在 Web、macOS、JetBrain IDEs、VSCode、IM（如 Slack）上管理和運用你的知識。簡單來說，它通常將來自 GitHub、Slack、Confluence、Linear 等平臺的內容上下文整合進來，幫助您找到關於應用程式的準確答案。對於企業來說，這就是一個非常值得參考的點：將 Jira、Gitlab.com/碼雲、Confluence、IM 等平臺的內容整合進來，幫助團隊更好地管理和運用知識。再透過智慧體或者 API 的方式，提供給 AI 工具，以幫助 AI 更好地理解團隊的知識。諸如於 AutoDev 的智慧體，就可以透過這種方式來應用企業提供的內部知識庫。

十月，我們在探索 AI 輔助需求時，同樣也遇到類似的知識挑戰。知識工程是進一步提升 AI 輔助研發質量的關鍵，你需要考慮：

開發 AI 工具原型是基礎。知識工程需要考慮到消費端的需求，進而設計出合適的知識庫結構、工具與 API 體系。當然，自上而下規劃也是一個不錯的選擇。
持續知識的運營與管理是不可或缺的。高質量的語料、高質量的知識固然很重要，但是人們缺的並不是這些，而是如何構建反饋迴路的執行機制，來讓知識不斷地更新。

不過，在你進一步重構之前，你需要考慮，什麼才是知識？

8. 互動的最佳化並不一定能解決模型的極限問題

在最近的模型釋出中，我們可以看到模型似乎已經到了一個瓶頸，無法再繼續大幅提升。這也就意味著，我們需要透過其他方式來提升效果，而不僅僅是依賴模型的提升。

諸如於：StreamDiff 是當前階段主流的問答程式碼生成方式，即根據問題，從頭生成程式碼，再以類似於 patch 的方式展現給使用者。AI 每次總是儘可能的從頭生成一遍程式碼，而不是透過真正的 patch 方式來生成。儘管，我們相信 patch 的計算方式終會實現，但是目前的 AI 模型還無法做得很好。

依賴於生成式 AI 的機率機制，它總是會有一些不確定性，而這種不確定性是無法透過互動來解決的。

非普適式的問題難以解決。諸如於 Intellij IDEA 外掛程式碼，模型很難得到準確的答案 —— 10 個裡有 9 個是錯的；而類似於這一類的問題，又特別的多。
程式碼中的數值問題。模型很難得到準確的數值，諸如於你呼叫 AI 來對你的演算法生成測試，它可以實現邏輯上的正確，但是數值上的正確需要你自己來驗證。
顧尾不顧頭的問題。典型的問題是，在 Java 程式碼中 AI 會無意多或者少 import 一些包，導致程式碼無法執行。
……

而這樣的 corner case 問題，特別特別的多，大量的這一類問題都需要透過規則來解決，而不是透過模型來解決。又或者是諸如於 StreamDiff 換一種新的方式來解決。