前言

大語言模型（以下簡稱大模型或 LLM） 真正意義上火出圈，應該算是 OpenAI 發布 ChatGPT 后（22 年底）。從這個時間開始，到現在為止，已經過了很長一段時間了，市面上也出現了一些編程工具，比如 MarsCode、Copilot 或者 Cursor 等比較火的結合 IDE 的插件和工具。而實際上：經過了這么長時間的 LLM 產品發展，大家的編程方式真的被改變了嗎？

近一年多以來，我們在 LLM 編程領域做了比較多的落地嘗試，有一些成果，也發現了一些問題，可以把它們簡單歸納為三個方面：

• 意圖識別不準。尤其對于復雜編程問題的描述和傳遞，在編程領域對于大模型來說是一個比較大的問題。
• 復雜任務無從下手。工程化的編程任務相對復雜或具備一定的理解成本，大模型無法準確、完備地把這類問題系統地做出來。簡單來說，其實是大模型本身缺乏了一些處理編程任務的標準流程，也就是所謂的 SOP。
• 生成效果不理想。有些工具能夠識別到意圖，也能夠做到 SOP 的拆解，但整個大模型或者結合大模型的一些應用，它帶來的一些生成效果往往達不到我們的預期。原因可能在于其解決問題或者編程相關的一些上下文缺失或者模型本身的局限。

ABCoder Show

基于此，我們圍繞 LLM 解決編程問題做了一些探索，將這個過程中的思考和實踐沉淀成了 ABCoder 這個項目，也是我們今天分享的主角。嘗試通過 ABCoder 來彌補或者解決前言中提到的一些問題，提升 LLM 在編程領域的表現能力。接下來我將會通過一個實機演示來具體說明。(可通過文末視頻鏈接觀看 demo 內容)

這條鏈路是從需求溝通到對應的 IDL 生成，到項目生成，這幾個標高亮的部分都是通過 ABCoder 進行輔助增強的一個流程。

當項目正式部署起來之后，繼續根據新的需求進行調整，我們通過 ABCoder 理解存量項目，更新它，然后部署新的更新后的項目?？梢钥吹剑詈蟮捻椖恳才芷饋砹恕Ｖ?，我們將這個項目通過 ABCoder 進行項目的拆解。使用 ABCoder 對其進行理解和壓縮，對應生成了高質量項目文檔。

ABCoder 簡介

ABCoder 背景

ABCoder 出現的背景來自于我們對大模型在語義化場景下的一些能力涌現的觀察，大模型在一定程度上具備理解問題、解答問題的能力。這為我們開啟了一條充滿希望的道路，我們期望借助大模型的能力，在這條道路上實現一些與編程領域相關的應用。

但實際上，在我們落地的過程中也發現了一些問題，包括大模型在處理多層次邏輯，或者涉及到復雜的一些算法設計，亦或是在大型的系統架構時，大模型的表現都沒有達到我們最初的預期。時間線回到去年年底，為了嘗試優化、解決我們遇到的問題，我們發起了 ABCoder 項目。

什么是 ABCoder

ABCoder 的命名來源于 AI-Based Coder 的縮寫。核心是圍繞 LLMs 構建一套編程增強的解決方案。它能夠通過彌補模型缺乏的編程經驗和復雜邏輯思維能力，在編程和算法設計以及大型系統構建中穩定發揮 LLM 的涌現能力。

從左邊的架構圖可以看到，它一共分了四層：

• 第一層 Sources 層，是 ABCoder 將要處理的知識源，包括 Wikis——編程項目相關的一些用戶文檔，Grammar ——對應的編程語言，自身的語法、規則以及對應配套的工具鏈。最為重要的是 Repos，在 ABCoder 里，Repos 是我們第一優先級（first class）處理的知識，是我們圍繞著 LLM、幫助 LLM 去理解所有編程任務的一個最核心的知識來源。
• 在幫助我們理解和解析 Repos 的過程中，我們做了第二層 Parsers 層。這一層我們做了大量的實踐，包括實現了基于 AST 和 LSP 的 Parsers，能夠將對應的 Repos，也就是語言的整個項目打包解析為面向 LLM 的更加親和的知識原料。
• 第三層是工具層，主要是一些基礎能力的封裝，包括數據加載的工具 Loaders，Indexing 或 Retrieval 等相似度檢索相關的工具封裝。
• 最后是 Workflows 層和 LLMs 層，Workflows 層承載的是幫助模型構建 SOP 的角色，它有機的將  LLMs 結合進來，驅動整個模型正常運轉。Workflows 層有三個圖例，最左邊是 sequence 的 workflows，它是一條串型的執行鏈路；中間是分支或者并行的 workflows；最后有一個 circle，這是 circle 范式的應用，目前主流的一些 Agent 都基于 circle 這樣的方式來呈現。在這個基礎上，我們通過結合大量的 workflows 和 LLMs 進行有機的交互，實現它對上面整個的應用支持。

回到真正內核的部分，整個 ABCoder 沒有太多復雜的概念，主要是兩個詞，RAG 和慢思考。這套系統就是為了去彌補模型在處理編程任務時缺乏的一些編程經驗，我們通過 RAG 的方式去彌補編程經驗的缺失，通過 workflows 彌補多級流轉，讓模型的生成慢下來，也就是經過多輪的迭代來嘗試逼近一個更為準確的答案。

ABCoder 的實現

為了更好地讓大家快速地理解 ABCoder 的本質，我們隨著核心的實現來進一步闡述。熟悉 RAG 架構的同學其實很清楚了，為了實現 RAG，我們有兩條具體的實現路徑。

第一條是離線路徑，是對于存量知識（綠框）的處理，包括用戶文檔、編程語言，以及編程項目都是我們核心需要處理的單位。我們將它們在離線路徑上進行一些處理，轉化為藍色部分離線知識庫的內容。

第二條是在線路徑，我們運用知識進行工具化以及 Workflows 的封裝，實現在線路徑上的問答或者插件封裝，以及 IDE 上的輔助能力。

離線路徑

在離線實現側，核心是上圖中的第三點，即編程項目離線知識的制作，對應的是我們開發的 LLM 原生解析器，負責處理編程項目。憑借這個能力，我們將編程項目自身作為一個知識來源，結合 LLM 來主動生成和豐富用戶文檔，作為用戶文檔的補充。

舉例說明，圖中左側列出來的是一個典型的 Hertz 項目的 Layout。我們現在要將這個項目輸入到 LLM 里，如果單純地去輸入這個項目本身，那將有若干個文件；如果將這些文件一股腦灌給 LLM，它也并不能很好地去理解這些文件集合。但實際上我們的編程項目有一個內在的關聯性，這個關聯性是什么呢？可以看到這里有一個例子，我們通過解析-壓縮-結構化，得到了上圖右側部分看起來像是一棵樹的結構，這個樹的結構就是我們在項目里函數調用的一棵樹。main 對應的是 main 函數，它同時依賴 register 以及 server.Default 這兩個函數節點，它們可能也有額外的子依賴。這個樹狀的依賴關系其實就是項目中函數調用的關系的呈現。

上圖左下側可以看到，在這棵樹下列出了五個函數和它的描述所對應的列表。這里有一個小細節，就是 1、2、3、4、5 的順序是從這棵樹葉子節點開始反向往上去理解，直到最上層的 main 函數。原因非常簡單，我們在做 ABCoder 理解時，就是按照這樣的順序一步一步將整個項目進行拆解，最終達到 main。因此，每一個函數只需要關注自己所調用的函數以及本身內在的邏輯就夠了，這樣可以一定程度減少我們在理解函數節點時模型本身的上下文發散，或者說避免一股腦輸入的信息超過了我們希望讓它生成或者聯想的上下文限制的問題，來保證信息準確、聚焦，達到很好的理解和壓縮的效果。

以上是我們用函數作為一個示例。在處理編程項目時，除了函數以外，同時還包括對類型以及變量的處理。通過這套語言無關的 Schema 抽象，最終得到的就是將編程語言或源代碼作為最后在線路徑上用到的 knowledge，整個過程概括為一句話，即圖中紅色框所示 —— Source code as knowledge。

在線路徑

相對離線路徑，在線路徑方面的實現非常簡單。我們將經過 ABCoder 處理并消化后的知識，結合 Retrieval & Augment（檢索&增強）來實現工具化以及 Workflows 的構建和調用，最終在在線鏈路上就能夠很好地去用到剛剛在離線階段處理的這些源碼知識了。

應用落地

接下面我們來看看在應用側是怎樣的狀態。回到整體架構圖。有人說過這么一句話：不會做飯的廚子不是好的程序員，我覺得這句話很有意思，順著這個邏輯，我嘗試將我們的架構做了一個形象的拆解，左邊是我們的架構，右邊映射到的是如果將做飯這個過程映射到這套架構中，看看每一層究竟對應的是什么樣的角色？

首先，最上面綠色的部分對應的是知識庫，它就是我們做飯的食材。Repo parsers 對應的是刀具，我們需要將食材通過 Repo parsers 進行一些拆解、分割，把它做到適合去炒、蒸或者煮的形態。之后，結合大量的 Tools，對應的就是鍋鏟類似的烹飪工具，幫助我們去處理不同形態的食材，或者在不同的階段去處理食材。最下面這層就是 Workflows 菜譜加上 LLMs 廚子，有了菜譜，加上廚子，結合上面的烹飪工具就能夠做出一鍋好菜了?；剡^頭來看 ABCoder 的這套架構，聰明的小伙伴可能已經發現，ABCoder 對應的并不是具體的某一個應用，而是一系列的應用，或者說其實是孵化應用的基座。

通過 Tools、Workflows 以及知識庫進行有機組合我們就能夠嘗試構建出一系列的應用。上圖是我們內部目前正在嘗試的三大應用落地方向。

第一個方向是 SmartComment，它也是 ABCoder 能力最直接的應用嘗試，它的目標是產出高質量的注釋以及相關的用戶文檔，核心的 workflows 以及 Tools 如圖表中所示，對應的知識庫就是 ABCoder 解析完之后的倉庫語料。其他幾個方向也可以在圖表中看到。

應用落地的里程碑

以上提到的三大應用制定了近期和遠期的里程碑。當前，三大應用方向近期的里程碑已經陸陸續續達成。在遠期上，SmartComment 將在半年到一年的時間內，探索出一套文檔工程相對應的實現，即 Code2Wiki，就是通過源碼的方式去補充用戶文檔的數量以及質量。在 Wiseman 側，遠期是希望實現從需求溝通到全自動化研發流程的構建。語言翻譯側，不僅僅要做到項目本身的翻譯，遠期將實現的是一套漸進式的翻譯流，包括項目以及研發人力的 A2B 轉換，共同成長。

未來規劃與展望

關于開源

在開源方面，ABCoder 將會以圍繞 CloudWeGo 構建 AI 驅動的微服務生態體系作為我們的核心目標。

在關鍵路徑上，我們后續將對 CloudWeGo 所有的組件進行 ABCoder 索引化，剛剛在 demo 里看到的處理 Hertz 的這套流程，將會無縫應用到 CloudWeGo 下的所有組件。之后，ABCoder 的應用將走進 CloudWeGo 社區，包括在研發行為以及社區生態上，為研發社區賦能。最后，當應用成熟度打磨到一定階段，將在 CloudWeGo 上完成正式開源，之后以社區的方式進行持續迭代和演進。

關于展望

在內部，ABCoder 提供的是編程語言結合 LLM 的一套解決方案，其終極理想形態被稱為「空」。「空」是一套語言中立的編程范式，它是完全 LLM 原生的一套編程模式，期望能夠為整個生產流程以及后面的發布流程，打通整個相關生態。

在外部，ABCoder 的表現在一定程度上依賴模型本身的能力。外部陸續發布的一些模型，也讓我們看到了一些眼前一亮的突破，包括模型本身在深度和廣度上的突破。近期一個叫做 OpenAI O1 的模型發布是一個比較好的例子。它通過引入類似強化學習的方式，在模型中內置一條思維鏈，主動將模型的生成降速，結合多輪思考和評估能夠有效解決更加復雜的問題，其表現出的能力也是之前其他的模型未曾帶來的。結合這類模型，或許在未來也會持續突破目前LLM 在編程領域的一些能力邊界。