AI輔助研發的2024年的6個實踐感受與思考

2025-04-20 08:56 phodal

兩週前受彭鑫老師邀請，在《智慧化軟體開發微訪談·第三十四期 基於大模型的軟體智慧化開發實踐》分享了我們在 Thoughtworks 以及在客戶側的一些實踐和探索。 在其中分享了我的一些心得和感受，在這裡重新整理一下，並加上一些新的思考和想法。
在不考慮模型和算力，要在企業落地還是有比較大門檻：
第一，AI 提升效能效果有限。AI 工具並沒有企業想象中好用，存在大量的學習成本 ，很多開發容易放棄； 第二，普遍缺少 AI 軟體工程專家。。軟體智慧化開發依賴於 AI 融合到研發流程中，大量企業缺少 AI 人才去改善內部流程、規範和提煉知識； 第三，端到端難度還是比較大，研發的智慧化依賴於需求側。過去，DevOps 推不動，所以有了在 BizDevOps，希望更多的 Involve 業務人員參加。在 AI 時代，依舊存在同樣的問題。
最重要的還是有人持續在內部探索。

1：現階段 AI 工具不完善，對端到端提升比較有限

我們公司在在全球有 19 個國家，48個辦公室，涉及到大量不同的部門和團隊。在其它國家，我們看到國外對於 AI 遺留系統改造和遷移的需求，是遠大於輔助開發。在國內的交付部門裡，我們的嘗試主要覆蓋了需求、開發和測試、運維都有所覆蓋 ，另外一個是結合 Thoughtworks 內部的技術實踐和知識庫的工具，如 AskThoughtworks 或者輔助研發團隊 AI 助手 Haiven，融合軟體開發的內部知識庫，加速 SDLC 。
  • AI 輔助需求：公開可訪問的有 Boba AI，協助產品經理和業務分析師更好地理解需求並生成相關文件，支援前期需求分析的自動化；還有
  • AI 輔助開發：工具就比較豐富多彩了，除了可以使用 Cursor 和 GitHub Copilot 等工具，還有我們開源的 AutoDev IDE 外掛（https://github.com/unit-mesh/auto-dev)，也幫助了不少企業在內部落地 AI 輔助開發。
  • AI 輔助測試：我們比較推薦開發編寫測試和 TDD （測試驅動開發）的方式，所以在 AutoDev 結合靜態程式碼分析，做了一鍵精準單元測試生成、
  • API 測試資料生成等功能。 AI 輔助運維：我沒啥興趣，觀察比較少，傳統的 AI運維已經做得很好了，但是也看到了自身內部在實現 AI 輔助 Thoughtworks 的工單分類和管理。
從我們之前的統計和分析效果來看，我們在不同的開發環節中實現了 2% 到 13% 的交付效率提升，尤其是在專案初期體現得更為顯著。不過，對於大部分已有專案的提升會在 5% 以下，尋找變更點才是老系統的痛點。

2：治理 AI 程式碼以及程式碼質量是下一步的重點

只從 AI 輔助程式設計來看，內容的資料，以及和一些團隊聊過這個問題，結合個人的使用體驗，我現在的結論是：
  1. 開發環節效率提升不一。受限於程式語言、研發流程和團隊規範；
  2. 程式碼質量是下降的。
效率上的話主要有兩點：
  1. AI 工具，現有的 AI輔助研發方式對於增量程式碼提升比較有限，還是大量依賴於人來做分析，有一些環節缺乏工具配套，比如不熟悉程式碼庫、缺少領域知識不會提問。
  2. 2.流程角度，開發環節只是 SDLC 的一環節，如果我本身 DevOps 不成熟或者需求太少，缺少知識，這種提升就無從下手。
程式碼質量主要受：
  1. 團隊平均水平的程式碼質量。也就是，別人寫的程式碼的影響 —— AI 會參考當前程式碼檔案和相關程式碼。別人喜歡用 if-else，你喜歡用 when 或者 switch，給你生成的就是 if-else。
  2. 未經人工詳細 review 的程式碼。我自身的體驗是這樣的，我之前還和幾個 Tech Lead（技術負責人）聊過這個問題：“你們在 code review 有沒有發現，未經人工 review 的 AI 程式碼”，他們的回答是：有，偶爾。可以反推，如果經典的 Sonarlint、Code Review 質量環節缺少了，那麼質量就下滑更嚴重。
如何治理 AI 程式碼會成為未來的一個重要問題。結合程式碼質量工具，如 Sonarlint、Code Review 等是一個不錯的方案，結合 ArchGuard 之類的架構治理平臺，也是一個不錯的方案。

3：高效校驗 AI 內容是工程化落地的最大挑戰

工程是 1，AI 是 0，沒有工程化，AI 發揮不了價值。在經歷了大量的調研和探索之後，從生成式 AI 能力上來說，我們更需要是傳統 AI 和工程能力 —— 生成測試用例之前，生成準確的測試資料。
生成式 AI 一次生成大量程式碼，幾十行、幾百行，我們就需要有效的方式來校驗這些程式碼。我們在實踐中會發現，AI 生成的程式碼，很難透過單元測試來校驗。在 生成一些架構知識，也會出現一些明顯錯誤。除此，由於人提供的時候，問題本身也是有些便向性，AI 生成的答案也是有 些偏向性。
最近，我們探索的方向是結合流程 Shire 程式設計場景智慧體語言，可以自由和不同內部工具、IDE 外掛做整合。 除此，我們最近一直在研究的點是， 如何挖掘流程中的隱性知識？比如，你編寫測試用例，要挖掘出用例的策略，什麼情況下關注什麼？需要如何準備測試資料？ 然後才是，如何透過 AI 技術簡化這些知識提煉的成本。在需求和開發等領域也是類似的作用，先從流程模擬人如何思考，再去結合 AI 技術。

4：新人會面臨更多的生成式 AI 挑戰

當前，階段普通開發人員面臨一個非常大的挑戰：如何判斷 AI 生成程式碼、設計是否正確？
上個月，有個畢業生拿 ChatGPT 回答的領域驅動設計（DDD）問題來找我，說這個 AI 和他們 TL 回答的結果不一樣。他們這種相當於是，一個意圖， 但是問法相近，結果卻不一樣了。對於資深開發人員來說，我就是對的，GPT 只需要按我的結果執行就行了。
結論會變成，如何獲取可信的“軟體工程知識”嗎？要知道，其實傳統的軟體工程知識也是並不可信的 —— 同樣的領域驅動設計的解釋，在不同作者眼裡是不一樣的。所以，最後架構設計還是會變成 by experience。
相似的，對於新人來說，需要尋找快速校驗的方式，來檢驗 AI 內容正確性。比如架構設計，可以快速生成 API、程式碼校驗；生成業務程式碼時，可以快速生成個測試試試等等。 更簡單的方式，可能是直接問 TL 或者更有經驗的同事。

5：生成式 AI 或更適合改善流程規範化

當前階段，我比較看好的企業智慧化場景是：藉助生成式 AI 把 DevOps 流程標準化、規範化，做好研發數字化。比較理想的情況是，剛好抵消標準化的成本。 從結果來看，企業可以：
  1. 小範圍構建原型並去小範圍試點，以培養 AI 人才。
  2. 建立基本的規範，規範化開發流程
  3. 有意識的改進現有的知識管理方式
因此，對於流程繁瑣的企業，AI 生成式工具是一個不錯的機會。既然涉及到流程重塑，這就不會是一件簡單的事。

6：領域知識的汲取是落地團隊級 AI 的關鍵

隨著，越來越多團隊的進一步深入構建團隊級 AI 助手，會發現構建 Team AI 的門檻並非在構建 AI 平臺本身，而是在於如何將領域、知識等提煉出來， 以用於強化自身的流程。從模式和解決方案來說，圍繞 DDD（領域驅動設計）思想的 AI 輔助工具，是一個不錯的方向：
  • 構建業務與技術的統一語言，實現需求、設計、開發、測試、運維等環節的無縫銜接；
  • 提取團隊成員的思考模式，轉換為 AI 工具的流程與提示詞，無縫融入團隊的日常工作；
當然了，其它的還有諸如從資料打通團隊內部的知識壁壘，實現關鍵資料的共享。

總結

生成式 AI 並非銀彈，要與現有的體系結合，並非一蹴而就。


相關文章