前言

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

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

• 意圖識別不準(zhǔn)。尤其對于復(fù)雜編程問題的描述和傳遞，在編程領(lǐng)域?qū)τ诖竽Ｐ蛠碚f是一個比較大的問題。
• 復(fù)雜任務(wù)無從下手。工程化的編程任務(wù)相對復(fù)雜或具備一定的理解成本，大模型無法準(zhǔn)確、完備地把這類問題系統(tǒng)地做出來。簡單來說，其實是大模型本身缺乏了一些處理編程任務(wù)的標(biāo)準(zhǔn)流程，也就是所謂的 SOP。
• 生成效果不理想。有些工具能夠識別到意圖，也能夠做到 SOP 的拆解，但整個大模型或者結(jié)合大模型的一些應(yīng)用，它帶來的一些生成效果往往達(dá)不到我們的預(yù)期。原因可能在于其解決問題或者編程相關(guān)的一些上下文缺失或者模型本身的局限。

ABCoder Show

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

這條鏈路是從需求溝通到對應(yīng)的 IDL 生成，到項目生成，這幾個標(biāo)高亮的部分都是通過 ABCoder 進(jìn)行輔助增強(qiáng)的一個流程。

當(dāng)項目正式部署起來之后，繼續(xù)根據(jù)新的需求進(jìn)行調(diào)整，我們通過 ABCoder 理解存量項目，更新它，然后部署新的更新后的項目?？梢钥吹剑詈蟮捻椖恳才芷饋砹?。之后，我們將這個項目通過 ABCoder 進(jìn)行項目的拆解。使用 ABCoder 對其進(jìn)行理解和壓縮，對應(yīng)生成了高質(zhì)量項目文檔。

ABCoder 簡介

ABCoder 背景

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

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

什么是 ABCoder

ABCoder 的命名來源于 AI-Based Coder 的縮寫。核心是圍繞 LLMs 構(gòu)建一套編程增強(qiáng)的解決方案。它能夠通過彌補(bǔ)模型缺乏的編程經(jīng)驗和復(fù)雜邏輯思維能力，在編程和算法設(shè)計以及大型系統(tǒng)構(gòu)建中穩(wěn)定發(fā)揮 LLM 的涌現(xiàn)能力。

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

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

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

ABCoder 的實現(xiàn)

為了更好地讓大家快速地理解 ABCoder 的本質(zhì)，我們隨著核心的實現(xiàn)來進(jìn)一步闡述。熟悉 RAG 架構(gòu)的同學(xué)其實很清楚了，為了實現(xiàn) RAG，我們有兩條具體的實現(xiàn)路徑。

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

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

離線路徑

在離線實現(xiàn)側(cè)，核心是上圖中的第三點(diǎn)，即編程項目離線知識的制作，對應(yīng)的是我們開發(fā)的 LLM 原生解析器，負(fù)責(zé)處理編程項目。憑借這個能力，我們將編程項目自身作為一個知識來源，結(jié)合 LLM 來主動生成和豐富用戶文檔，作為用戶文檔的補(bǔ)充。

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

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

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

在線路徑

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

應(yīng)用落地

接下面我們來看看在應(yīng)用側(cè)是怎樣的狀態(tài)?；氐秸w架構(gòu)圖。有人說過這么一句話：不會做飯的廚子不是好的程序員，我覺得這句話很有意思，順著這個邏輯，我嘗試將我們的架構(gòu)做了一個形象的拆解，左邊是我們的架構(gòu)，右邊映射到的是如果將做飯這個過程映射到這套架構(gòu)中，看看每一層究竟對應(yīng)的是什么樣的角色？

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

通過 Tools、Workflows 以及知識庫進(jìn)行有機(jī)組合我們就能夠嘗試構(gòu)建出一系列的應(yīng)用。上圖是我們內(nèi)部目前正在嘗試的三大應(yīng)用落地方向。

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

應(yīng)用落地的里程碑

以上提到的三大應(yīng)用制定了近期和遠(yuǎn)期的里程碑。當(dāng)前，三大應(yīng)用方向近期的里程碑已經(jīng)陸陸續(xù)續(xù)達(dá)成。在遠(yuǎn)期上，SmartComment 將在半年到一年的時間內(nèi)，探索出一套文檔工程相對應(yīng)的實現(xiàn)，即 Code2Wiki，就是通過源碼的方式去補(bǔ)充用戶文檔的數(shù)量以及質(zhì)量。在 Wiseman 側(cè)，遠(yuǎn)期是希望實現(xiàn)從需求溝通到全自動化研發(fā)流程的構(gòu)建。語言翻譯側(cè)，不僅僅要做到項目本身的翻譯，遠(yuǎn)期將實現(xiàn)的是一套漸進(jìn)式的翻譯流，包括項目以及研發(fā)人力的 A2B 轉(zhuǎn)換，共同成長。

未來規(guī)劃與展望

關(guān)于開源

在開源方面，ABCoder 將會以圍繞 CloudWeGo 構(gòu)建 AI 驅(qū)動的微服務(wù)生態(tài)體系作為我們的核心目標(biāo)。

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

關(guān)于展望

在內(nèi)部，ABCoder 提供的是編程語言結(jié)合 LLM 的一套解決方案，其終極理想形態(tài)被稱為「空」?！缚铡故且惶渍Z言中立的編程范式，它是完全 LLM 原生的一套編程模式，期望能夠為整個生產(chǎn)流程以及后面的發(fā)布流程，打通整個相關(guān)生態(tài)。

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