有贊AI研發全流程落地實踐

1. AI 時代的研發變革

1.1 AI編程的火爆

25年可以說是 AI 應用的元年，從最基礎的代碼補全到輔助編程，再到 AI 工程師，再到 AI 開發團隊，各種概念層出不窮。

編程工具迭代湧現，從老牌的 Github Copilot 到爆火的 Cursor，再到 Claude Code，和最新出的 Codex。

對應的用戶規模也爆發增長，Github Copilot 用戶超過 2000 萬，Cursor 用戶超過 230 萬，Claude Code 在短短 3 個月用戶增長 10倍，Github Copilot 年度 ARR 超過 3 億美元，而 Cursor 和 Claude Code 都超過了 5 億美元。

隨著編程工具的發展，編程門檻被大幅降低，氛圍編程(Vide Coding)開始興起，讓更多非專業開發者專注創意和結果。

在有贊內部有產品同學開始用代碼交付互動式的 PRD，在一些創新型項目中這會成為第一版代碼。

1.2 AI對企業研發的變革

我們開始思考，AI 對企業研發意味著什麼？

首先，傳統軟體研發生產要素，由人力、技術、資訊組成，核心邏輯是多招人，就能多做項目，就有更多產出。圍繞人這個要素存在一系列問題：好人才難招、新人要培養、人才會流失、個體的動性、人的協作效率。

AI 時代人力開始向算力轉移，增長邏輯編程多買顯卡，獲取更多算力，就能有更多產出。大部分體力工作向算力遷移，部分腦力工作可沉澱到算力中，算力能快速擴大。

最近看到一些新聞，矽谷的大廠一邊裁員，一邊爭相購買顯卡。

在這個過程中，人從直接產出轉為對算力的設計與編排。

“讓子彈飛”是一部經典的電影，這裡引用其中一張截圖，模糊度恰到好處。

遠看是火車即將超越馬，近看是馬在拉著火車，這很有意思。和我們目前落地 AI 有點相似，“朋友圈”看起來各種炫酷，實際落地需要大批人馬參與。

但這就意味著火車不如馬嗎？

顯然不是，我們都知道最終火車一定會超越馬，亦或，馬拉火車的方式本身就錯了。

1.3 有贊研發的AI+

出於對 AI 趨勢的堅信，在有贊研發內部，我們有大量的 AI 探索與實踐。

橫跨研發的完整流程，包括需求、設計、編碼、測試、上線的各個階段。

所有這些實踐可以，歸納為三類：AI Coding、AI Test、AI DevOps，以及圍繞 Agent 本身的研發與評測。

1.4 AI編程小案例

在 AI 探索的初期我們遇到了兩個很有意思的小故事。

1.4.1 一位產品的氛圍編程之路

第一個故事是，我們的一位產品同學用氛圍編程做了一個簡單的日常需求，他給了個反饋：嚴重缺乏安全感。

我們深入了解後發現來源於三點：

• 心理不可接受：由於企業級工程規模大、系統複雜度高，系統/功能間依賴關係較深。非專業人員面對生產穩定性和大量線上用戶壓力時，心理負擔急劇增加。本質是判斷力缺失；
• 效率不可持續：判斷力缺失也導致效率不可持續，導致需要頻繁的和開發者溝通，氛圍編程變成了 AI 和開發者之間的傳聲筒。編程的耗時被極大的轉換成了溝通確認的耗時，最終效率不升反降；
• 質量不可信賴：雖然 AI 做對了效果，但是實現方案不合理，最後返工。現代企業級軟體工程，除了完成需求外，還需考慮健壯性、可維護性、架構一致性等因素。AI 由於缺少上下文輸入，這方面做得並不好；

1.4.2 一位開發帶領的編程團隊

第二個故事是，五月 Claude Code 發布後，我們看到一些開發者編程模式的變化，如圖是一位同學的 CLI 工具：

左側是 4 個 Agent 分別在完成一個項目的 4 子需求，右側是他在驗證和提交代碼。

這種模式類似一位技術 Leader 帶領一個小團隊做項目，由 Leader 負責任務拆分、方案設計、過程把控和代碼 CR。

過去需要幾個人的小組，現在一位開發者加上多個 AI Agent 就可以做到了。

這給了我們不少啟發，我們開始思考如何把這種模式推廣到更多項目中。

1.5 企業級軟體工程四大特點

在經過了初步的觀察和嘗試後，我們總結了 AI Coding 落地需要解決的關鍵問題，歸納為四點：

• 大規模：這對 LLM 的多倉庫理解、上下文窗口提出了要求；
• 高複雜：通常涉及多個業務系統、歷史兼容等，需要解決 LLM 的注意力缺失問題、準召率低問題；
• 多協作：一個項目往往涉及多職能、多部門的協作，不同團隊間對 AI 的理解和應用有深淺，如何協同？以及，人在哪些環節以怎樣的力度監督 AI？需要合理地規劃 AI 落地的節奏以及人機協作模式；
• 私有化：企業內部有大量分散在各處的信息，不透明、不標準，難以被 AI 檢索，需要建設內部知識庫、對接內部工具；

1.6 AI落地的三個階段

明確關鍵問題後，我們將 AI 落地劃分為三個階段：

• AI 增強階段：人主導 AI 輔助，此階段重點聚焦用 AI 做單點提效；
• AI 驅動階段：AI 主導人監督，此階段 AI 有能力接管單一研發環節；
• AI 自主階段：AI 自主人少量介入；

對於不同的場景應該匹配適合的階段，過度追求 AI 反而適得其反，我們踩過不少坑，AI 的落地無法一蹴而就，需要循序漸進。

目前我們的實踐大量在 AI 增強階段，有少量能到 AI 驅動階段。

2. AI Coding：從個人助手到規模協同

2.2 設計路線

首先，是關於 AI Coding 的設計路線，我們有兩個選擇：以人為主 Agent 為輔、以 Agent 為主人監督。

我們觀察了一些開發者的輔助編程模式，我們發現以人為主的模式存在一些問題：

• 協作還是以人為中心，相互溝通靠聲音、工具調用靠手速，信息傳遞效率低；
• 個人經驗內化不共享，Agent 配置沒有復用，信息分布式存儲；
• 另外，人的規模化需要時間；

因此，我們選擇了第二條路線，其可以系統化解決以上三個問題，並且“天花板”更高。

2.3 構建框架

明確了設計路線後，讓我們開始構建 Coding Agent，這個過程類似從 0 到 1 搭建一個開發團隊：

• 它們都需要有好用的工具，無論是硬體、軟體還是技術選型；
• 它們都由專業的個體組成；
• 並且這些個體能高效協同完成複雜的任務；

讓我們先從設計一個專業的 Agent 開始！

2.4 設計演進

通用 AI Agent 和計算機很相似：

• 它們都有計算單元，一個是 CPU，一個是 LLM；
• 它們都有短期存儲，一個是記憶，一個是上下文；
• 它們都需要獲取外部信息，一個通過網路，一個通過搜索工具；
• 它們也都可以多節點進行協同，完成複雜任務；

當我們把通用 AI Agent 細化到 Coding Agent，一些選型會更具體：

• LLM 需要選用垂直的編程 LLM；
• 上下文需要引入企業的開發規範/約束；
• 長期存儲需要對接企業內部知識庫；
• 搜索工具聚焦在代碼倉庫的搜索和理解；
• 工具需要對接企業內部的工具鏈和平台；
• 協同系統的拆分應該以企業內部的協作流程或領域分工來拆分；

2.4.1 選型與選擇

在明確了核心模塊後，需要先回答兩個問題：方案的選型、自研的選擇。

在 AI 時代行業解決方案百花齊放，無論是大模型還是配套的技術，且迭代速度極快，比如近期的 Gemini3（11月18日）、Nano Banana Pro（11月20日）。

做的越多越容易陷入追趕的局面，最大程度的借助行業能力，並將其與企業內部資源串聯是關鍵。

我們的核心策略是將通識的交給行業，集中資源做私有部分，通過行業迭代來提升底層能力。

2.4.2 Base Agent & System Prompt

明確策略之後，首先是基礎模型的選擇，在25年初時我們基本有共識，LLM 應該交給大廠，我們則專注於應用。

到了 5 月份我們發現 Agent 系統也有不錯的行業實踐，因此問題被延展成了選擇基礎模型還是選擇基礎 Agent？ 也就是 Claude 還是 ClaudeCode？

圍繞這個問題我們做了一些研究，發現 Claude Code 作為通用編程 Agent，在子 Agent 調度、MCP 集成、通用開發工具、上下文壓縮方面已經做得不錯了。

因此，我們選擇了 Claude Code 作為基礎 Agent 的底座，通過其強大的擴展能力，將其連接到我們內部的研發體系。

首先是系統提示詞，這方面 Claude Code 已經做得不錯了，我們僅做了少量擴展，總共不到 200 行，主要是一些內部的編程規範、特定約束。

2.4.3 Dev Tools

接著是工具，和人一樣，Agent 也需要開發工具。比如，當開發者讓其參考歷史需求，它需要能訪問需求管理平台查看。又比如，它可以通過飛書文檔創建一篇技術方案給開發者審閱。

這些工具散落在內部的各個系統、平台，有些在外部，我們通過 MCP 將這些工具集成到一起，交由 Agent 決策使用。

2.4.4 Codebase Search

有了工具後，接著是代碼理解能力，這也是 Coding Agent 的關鍵能力之一。

我們將其分為三層：目標倉庫定位、跨倉庫依賴代碼召回、工作區代碼理解。目標倉庫定位比較簡單，我們用的是知識庫 RAG 的方案。

在代碼理解上，業內常見的方案有：向量索引檢索（RAG）、抽象語法樹（AST）、文本搜索（grep）、預生成文檔（deepWiki），在實際應用中有不少組合的情況。

Cursor 選擇的是 RAG 方案，好處是速度快，適合大的單體倉庫，缺點是精度丟失（向量化），實時性不高。

Claude Code 則選擇比較純粹的文本搜索方案，和人很像，好處是精度高、實時性強，但性能會差一些。

在有贊對於跨倉庫依賴代碼，由於倉庫數量龐大，採用的是 RAG 方案，同時更新頻率沒有 Cursor 這麼高，我們基於 Git 的提交記錄進行增了更新。對於工作區代碼理解，由於基礎 Agent 是 Claude Code，直接採用它的文本搜索。

另外，代碼安全也十分重要，無論是發送給向量嵌入模型還是大模型的代碼片段，都通過安全掃描進行脫敏。

2.4.5 Knowledge Base

有了代碼，接著是內部知識，和開發者一樣 Agent 需要理解業務知識，比如產品模組有哪些、業務術語是什麼意思。也需要理解專業知識，比如技術選型用了什麼、編程規範是怎樣的，以及工程現狀。

這些額外的上下文可以讓 Agent 的編碼更符合預期，避免寫出“與眾不同”的代碼。

過往企業知識庫建設有兩大痛點，一是信息孤島（無法統一檢索/重複建設嚴重），二是內容老舊（因為缺少審核/運營機制，大量過期/錯誤內容）。

為此，我們內部成立了專門做知識工程的團隊，由他們推動知識透明和更新。他們圍繞知識增長、內容質量、知識使用進行建設，為上層應用提供高質量的知識。

至此，一個 MVP 版本的 Coding Agent 完成了。我們拿去做了一些需求，發現效果並不好，原因是還有大量經驗在開發者的頭腦中。

2.4.6 Long-term Memory

為此，我們會 Agent 打造了基於長期記憶的學習系統。簡單說，就是將開發者和 Agent 的監督對話提取為長期記憶，後續遇到類似場景時進行召回使用，這也可以實現跨會話的複用。

這就如同一個經驗豐富的老員工手把手帶教實習生，整個過程分為：

• 記憶提取，該階段重點關注符合事實、保留細節、不歸納泛化。
• 記憶儲存，我們採用自然語言+標籤的形式儲存而非結構化，並且保留了原文引用。
• 記憶合併，定期將類似記憶歸納合併。
• 記憶檢索，業內根據場景不同常見的有：向量數據庫、知識圖譜、分層儲存，我們採用的是向量數據庫。
• 記憶遺忘，隨著記憶數量的增加，根據時間和使用頻次進行遺忘。對於高頻使用的記憶經過泛化後轉化為知識。

雖然設定了很多提取規則和後處理，但在實際應用中，通過人工標註及修正的方式，可以較快加速記憶的可用性。

我們在 AI Coding 做了測試，同類任務未接入記憶需要 5-10 輪對話修正，接入記憶後僅需 1-3 輪，有較大提升。

2.4.7 Cloud Sandbox

Agent 構建完成後，無論是運行、調用工具、拉取代碼等等，都需要一個環境，如同為開發者配置一台電腦一樣。

通過對本地輔助編程的觀察，我們發現本地運行存在一些問題：複雜環境導致額外上下文、工程化適配問題、安全與監管難解決。

因此，我們選擇了雲端部署的方案，為每個 Agent 的每次會話分配了獨立且標準化的沙箱（Sandbox），其中包含了開發環境，以實現交付結果預覽。

同時對會話及沙箱做了無狀態化，實現水平擴容能力。我們將會話存儲在共享存儲中，當開發者開啟或繼續一個會話時，會動態分配隨機沙箱，並從共享存儲中恢復會話。

這一切都需要通過統一網關，以解決安全和監管問題。

2.4.8 Multi Agents System

隨著接入環節的增加，我們發現單一 Agent 面對多個環節，由於 LLM 上下文長度導致了遺忘、性能等問題。

為此，我們引入了多 Agent 系統，將這些複雜度分而治之。

• 在 Agent 的編排上有 Workflow 和 Agentic 兩種方式。由於企業級工程對穩定性、觀測性的要求較高，我們採用 Workflow 串聯多個 Agent。在部分 Agent 內部通過 ReAct 模式發揮 LLM 的自規劃能力。
• 在 Agent 的拆分上有流程拆分和領域拆分兩種方式。我們都做了嘗試，從落地情況看按流程拆分基本可以解決大部分問題。

同時，我們為每個 Agent 做了差異化的基模選擇，主要根據 Agent 的任務特點、LLM 的優劣勢以及成本。

• 需求解析和倉庫定位較簡單用 GPT-4o；
• 代碼定位用向量嵌入模型 voyage-code-3 並配合 deepseek-v3 做一些後處理；
• 方案和編碼則用 Claude-sonnet-4.5，其中記憶用 GPT-5 效果出色；
• 代碼審查則用 Gemini 2.5 它的上下文窗口較大，可以把更多代碼片段給到 LLM；

2.4.9 人工監督(HITL)

整個 Agent 系統的運行離不開人工監督（Human in the loop），我們面向開發者、管理者分別設計了兩套監督系統。

• 面向開發者的監督系統主要基於飛書 IM，它是一個天然的對話流，同時結合飛書文檔、GitLab。開發者可以在 Agent 的每個階段對產物進行審核，包括：需求清單、技術方案、改動代碼、實際效果等，並通過多輪對話進行修正；
• 面向控制者的監督系統主要基於多維表格及其儀表盤，管理者對每個需求的情況一目了然，包括：交付率、對話輪次、Token 消耗、對話明細等；

其中，對話明細可以轉化為評測集，用於後續 Agent 的評測。

2.4.10 對接發布系統

最後，我們通過部署發布 Agent，打通了發布系統。如圖所示，通過對話就可以很方便的部署到預發，或發布至生產：

2.5 產品形態

這就是我們最終的產品形態，已經交付了不少需求。當然實際落地中，這種人機交互模式也有局限性，因此我們正在開發 Web 端，類似 manus 的效果。

2.6 需求選擇與落地

在 AI Coding 落地的需求選擇上，我們分了三個維度：多職能、多倉庫、需求規模，和新人一樣在 Agent 能力還不夠時，先從單職能單倉庫的日常需求開始。通過做小需求驗證 Agent 並積累數據，同時小需求因優先級不高而積累，用 AI 來做具有提效價值。

在我們將 AI Coding 推廣到兄弟團隊時，發現大家對 AI 期望很高，大家會給它做非常有挑戰的需求，我們需要理解 AI 不是萬能的，人做不了的它也是。

目前我們的 AI Coding 已經可以實現單職能多倉庫的日常需求，已交付近百個需求。綜合提效 30%，包括人工監督的耗時，單個需求 Token 費用不到 100 人民幣。

接下來我們會重點向多職能多倉庫、項目級需求兩個方向迭代。

2.7 實踐案例

2.7.1 翻譯型事務

在落地過程中，我們也發現了一些特別適合 AI 做的共性需求。

第一類我們稱之為：翻譯型任務。已經有明確方案且較為簡單的任務，AI 可以快速完成，且質量還不錯。比如：技術債務治理。

有一個基礎庫升級的案例，涉及基礎庫、業務庫和23個業務應用的升級，原本需要超過50人日，通過 AI 幾十分鐘就好了。

2.7.2 降低開發門檻

第二類是跨域編程，我們工作中經常會需要跨團隊、跨領域支援，過往人的學習和熟悉過程會有額外的時間。通過 AI Coding 我們的開發者進行了不少的跨域編程，這部分時間幾乎被抹平。

2.7.3 小插曲：移動編程

另外有個比較有意思的小插曲分享一下：

相信程序員都有共鳴，隨身攜帶電腦是大家的痛點之一。在我們落

原文出處：https://juejin.cn/post/7592094358658138146