代碼大模型與軟件工程的產品標品之路 | 新程序員

08月12日 18:11 新浪網 news-china-auto-hilite

【導讀】隨著人工智能的快速發展，代碼大模型逐漸成為軟件工程領域的研究熱點。代碼大模型利用大量數據進行訓練，可以在很大程度上提高開發人員的工作效率，降低開發成本。本文作者對代碼大模型在軟件工程領域的應用前景進行了深入探索，並帶來了落地及產品的標品化建設經驗。

本文出自2024 全球軟件研發技術大會中的演講，同時收錄於《新程序員 008》。《新程序員 008》聚焦於大模型對軟件開發的全面支撐，囊括 Daniel Jackson 和 Daniel Povey 等研發專家的真知灼見與「AGI 技術 50 人」欄目的深度訪談內容，歡迎大家點擊訂閱年卡。

作者 | 汪晟傑

責編 | 唐小引

出品丨新程序員編輯部

軟件開發中以編碼輔助、代碼溝通為最高頻的使用需求，有超過一半的開發者期望 AI 幫助寫單測的需求強烈。我們需要 AI 不僅能夠進行代碼補全，還能幫我們解決問題、絲滑接手祖傳「屎山」代碼。歸根結底都是 AI 究竟是否能夠理解我們的工程，這就對大模型提出了挑戰。

在本文中，我將重點圍繞以下幾個方面和大家探討我們對於代碼大模型和軟件工程的探索。

第一，軟件工程在 AISE 上碰到的坑，以及未來可能帶來的價值點。

第二，怎麼讓 AI 代碼助手類的產品去理解代碼工程。

第三，AI 是如何做到針對工程項目不同的場景和不同的角色。它不僅僅是理解我們的工程，還想要能感知到這個工程下現在、接下來要做什麼，能不能幫我做一下重構或者一些其他方面的事情，來幫助縮短 DevOps 生命週期，我們稱之為 SDLC 的優化。

最後，我們將討論老闆們關心的研發效率問題。研效可能有很多的工具在做，但畢竟還是工具，在管理者的層面上需要定義研效。那麼研效有沒有可能對 AI 輔助類工具落地並標準化指標，並建設出一系列的 AI 輔助類工具帶來的新的研效提升點。

軟件工程+AI 助手的挑戰

首先，我們需要明確什麼是 AISE？AISE（AI Software Engineering）可以理解為「軟件工程 3.0」，即基於大模型時代下的軟件工程。事實上，AISE 本質上是以 AI 為心臟的一套鏈路，它需要解決 DevOps 複雜度的問題。DevOps 的鏈路非常長，通過 AI 是否能夠優化升級敏捷，甚至未來拋棄敏捷？是否能以多智能體的方式，讓 DevOps 收穫全新的體驗？這就是對於 AISE 的定義。

當前，AISE 總體仍處在起步期，但我們可以看到越來越多的 AI 工具開始涉足到軟件開發的不同階段。從編寫代碼、測試到運維等 SDLC 軟件研發全生命週期中，越來越多的產品正在以 AI 為中心去重塑它的產品形態，其中尤以開發環節為甚。據信通院調查顯示，超過 70%的企業在軟件開發階段應用了大量的大模型等 AI 技術，其次是軟件測試、運維。我從產品角度認為，這幾項都是未來我們可以攻破的方向。

國內外主流的開閉源代碼大模型都在不斷提升其規模、參數，其實是想要讓代碼獲得更大的 Token、窗口，在有限的算力條件下能夠推出更多的內容、有更好的意圖識別。由於代碼大模型的入局，AISE 的應用場景正是百花齊放時。那麼，代碼大模型究竟有什麼特點？首先是具有秩序性，和人類閱讀不同；二是邏輯性，它必須有強大的推理能力，這本質上是有一套語法的前後邏輯調用鏈；第三是上下文的感知度，在當前代碼的類里是否能感知到別的類的存在、別的類的函數定義等。基於此，我們可以結合工程方式輔助來讓大模型更好地懂工程。

在智能編碼方面，我們很早就開始和企業客戶進行溝通，基於國內行業客戶的普遍訴求，我們總結出了企業智能編碼的「SMAFe」原則，即：

Security（代碼安全）：保證基礎模型里用於訓練的代碼是安全的，保障補全出來的代碼是安全的。
MaaS（多模能力）：由於各部門的業務特性不同，可能需要多個個性化的行業模型。並且，根據不同業務特性，需要進行二次訓練，補全模型。
Analysis（數據看板）：保障二次訓練以及行業代碼的訓練效果，同時有哪些效能指標可以幫助管理者觀察工具對開發工作的提升。
Full（豐富場景）：代碼補全是高頻場景，優先度最高。在此之外，還有代碼掃瞄、評審以及 DevOps 上下遊規劃。
extension（擴展機制）：在對話平台之上構建自定義的 Agent 能力；能夠自定義開發，通過自定義提示詞和 Function call 等接入業務系統（註：e 是特別小寫的能力，如大寫則為企業在已有的標品上進行擴展）。

代碼大模型有很強的推理能力，可能會使用 C++、C#、Rust 等各種語言，但如果讓它去做企業級的工程，還是需要學習工程結構、研發規範等。如何讓代碼大模型「理解工程」？這就需要從三個維度來著手，分別是：準度/評測：讓模型做紅藍對抗，比如讚踩、打分的反饋系統。將 Bad Case 進行持續收集，繼而反哺系統並進行有效性驗證，從而打磨迭代出新模型；成本/算力；質量/安全。

總體來看，成本和體驗會極限拉扯，準度評測保證模型質量，安全保護資產，這是代碼大模型不會消停的挑戰。對此，如何確保代碼大模型實現「好、快、準」？這就涉及到了三大要素：

「數據安全 = 好」：可以用大模型對抗大模型，用大模型來感知生成的代碼是安全的，其次可以用大模型進行監督。比如開源的大模型安全工具包 LLM Guard，通過提供開箱即用的所有必要工具來簡化公司安全採用 LLM 的過程。
「IDE + 編碼效能 = 快」：天下武功唯快不破，我們內部的代碼補全平均耗時在 500 毫秒左右。
「對話 + 工程理解 = 準」。

基於大模型成本與體驗的極限拉扯，我們在深入思考怎樣才能讓 AI 代碼助手能夠達成高用戶價值，如圖 1 的框架。我們通過代碼模型精調訓練，在代碼補全、技術對話上給開發者提高效率。這點也已在內部進行了多次論證：當產品處於非常好的體驗時，會獲得非常高的用戶留存率。這裏提到的代碼生成的體驗，更關注在補全性能、產品交互、以及用戶開發習慣等方面。

圖 1 大模型成本與體驗的極限拉扯

在高留存率目標驅動的同時，還必須控制優化好成本，防止高頻訪問導致速度下降與成本上升而劣化產品體驗。需要重視 Bad Case 反饋與處理閉環、針對性專題性能調優、採取批量計算等策略；通過用戶看板觀察總結模型版本升級帶來的能力增益。最終通過一系列平衡手段，實現 AI 代碼助手在補全場景下的產品價值。

懂工程的 AI 輔助工具的最佳路徑

那麼對於一個懂工程的 AI 代碼助手，怎樣才能做到最佳使用範式？用好 Coding Copilot 有幾個關鍵的點：

首先是 IDE 的深度體驗，我們的代碼助手在起步之初便定位要做 GitHub Copilot 的平替，因為這能夠讓開發門檻大幅降低，對於開發者而言，切換成本很低。
通過 Agent 擴展實現 Prompt as Code，靈活地在工程、倉庫、版本管理、流水線等都進行 Agent 擴展。
Life of a Completion 是 GitHub Copilot 定義的一套範式，它並不關心你的代碼是什麼樣子，會通過一種策略感知持續性地從源碼中提取有用的提示詞，並組裝給模型最終產生想要的效果。
程序員的編程習慣——Tab 與 Backspace 之爭由來已久，我們也對智能編碼習慣進行了定義，希望能夠實現 3TNB 的目標，即「Tab Tab Tab No Backspace」，根據註釋生成代碼，根據函數定義生成函數體實現，根據上文生成下文代碼，根據當前代碼行輸入，補全整行代碼。

接著是大家熟知的提示詞工程，提示工程的基本原理，可以總結為 3 個 S，核心規則是創建有效提示的基礎。

單個 Single：始終將提示集中在單個、定義明確的任務或問題上。
具體 Specific：確保說明明確且詳細，最好能附帶一個示例或者模擬信息結構。具體且具像帶來理解會帶來更精確的代碼建議。
簡短 Short：在具體的同時，保持提示簡明扼要。這種平衡確保了清晰度，而不會使騰訊雲 AI 代碼助手超載或使交互複雜化。

我們在使用大模型時，在 Prompt 中注入給大模型的 N 個提示樣例數據，幫助大模型輸出結果。N 指的是樣本的數量，根據 N 的個數不同，在代碼大模型中就相應地有這樣幾種說法：Zero-shot：對話總結、下輪對話建議；One-shot：一次新會話，一次當前上下文補全；Few-shot（少量樣本）。

AI 對工程項目的探索思路

單元測試是軟件工程 3.0 中要解決的「難啃骨頭」，更偏向代碼重構，測試是個專項領域，而重構這件事是軟件的最高峰。單元測試與 AI 的結合面臨三個問題：測試方法種類多、框架多；項目本身不具備可單測功能，難以 Mock；生成質量難以運行，無標準最佳實踐。

針對單元測試+AI 的挑戰，我們有一些可行性的探索，包括：增加示例代碼，感知框架；語法樹找相關跨文件，依賴文件的調用鏈；策略感知 Mock 對象，生成完成可執行單測。不同語言、不同框架對應不同的單測模型，是目前模型層面上的可探索之路，同時也需要給大模型更多的提示詞來幫助大模型理解。對於軟件工程 3.0，智能體也將會發揮巨大的單元，並以 AI 為驅動力，與各個環節發生協同、推理、反思。

研效+AI+標品化建設

本質上來說，AI 輔助類工具與 DevOps 一樣，都是研效工具且是強運營產品。但 AI 代碼助手這類產品不同於人們已經熟知的 DevOps，它還很新，因此如何讓產品變得標品化至關重要。

對於老闆們一直關注的指標問題，國外有開發者總結了利用 25 個指標提高開發者的工作效率，其中較為關鍵的是：

編寫代碼總行數（TLOC）：用於衡量代碼行總數，包括手動和 Copilot 生成的貢獻。
每份貢獻的平均代碼行數（ALOCC）：用於評估每次開發工作貢獻的平均代碼行數，展示每次貢獻的粒度。
使用 Copilot 的代碼貢獻百分比：量化 Copilot 貢獻的代碼比例，展示其在開發過程中的集成。
Copilot 建議後代碼更改的百分比：通過追蹤開發者修改生成的代碼評率來衡量 Copilot 建議的有效性。
代碼變更：測試一段時間內對代碼庫所做的更改的頻率和程度。

總體而言，所謂標品，就是希望這個軟件是一個單純乾淨的軟件，尤其工具類軟件更要做到足夠小而美。例如，輔助類工具就只是輔助類工具，無需連通別的系統或把 DevOps 串起來之類的，這樣無論在什麼環境下它都能運行。對於產品而言，能夠實現一鍵部署、擴展業務能力簡單、接入系統簡單、企業易於定製、支持信創環境、無其他耦合系統；對於運營而言，還能夠賦能老闆彙報，為什麼要用 AI 代碼助手。

結語

AISE 已來，下一個 AI 時代改變了編碼習慣和過程，我們需要在代碼大模型的極限拉扯下對產品與體驗進行權衡。深度探索提示工程（N Shot、3S 等）、代碼模型能力和 AI 應用框架是 AI 產品的重要組成部分，它們可以幫助我們更好地定義新的軟件模式，而產品開髮指標會作為新的研效指標。多智能體的協同戰局已經拉開序幕，未來，AI+CDE，即通過多智能體的有機結合，可以在雲開發環境中利用 AI 自主完成全套開發流程直至最終上線。