3.Prompt驅(qū)動評審：將經(jīng)過過濾和截?cái)嗪蟮拇a片段，與預(yù)設(shè)的評審規(guī)則Prompt組合，發(fā)送給通用大語言模型。

4.輸出評審意見：解析大模型的返回結(jié)果，通過coding平臺API將評審結(jié)果添加到MR中。

核心問題識別：

1.全局上下文缺失：其采用的“固定行數(shù)截?cái)唷辈呗允菍?dǎo)致問題的根本原因之一。這使得評審?fù)耆珕适Я隧?xiàng)目架構(gòu)、模塊依賴和完整業(yè)務(wù)邏輯的視野，如同“管中窺豹”，評審深度和準(zhǔn)確性受到嚴(yán)重制約。

2.提示詞天花板：所有評審規(guī)則與知識硬編碼于Prompt中，規(guī)則膨脹后極易觸及模型上下文長度上限，可維護(hù)性與擴(kuò)展性差。

3.知識無法沉淀：效果提升完全依賴于“更換更強(qiáng)的基礎(chǔ)模型”與“調(diào)整Prompt”，自身缺乏可持續(xù)積累、沉淀和復(fù)用領(lǐng)域知識的機(jī)制。

技術(shù)2：基于JoyAgent知識庫的RAG代碼評審

核心技術(shù)路徑： 在通過公共流程獲取代碼差異后，該方案的核心流程如下：

1.知識歸納：將格式化后的Diff內(nèi)容發(fā)送給JoyAgent，由LLM智能體對其進(jìn)行初步的“知識歸納”，以理解此次變更的核心意圖。

2.規(guī)則檢索：基于歸納出的知識，通過RAG機(jī)制從自定義知識庫中召回相關(guān)的代碼評審規(guī)則。此知識庫支持在線文檔（Joyspace）、離線文檔（PDF/Word）等多種格式。該方案的核心靈活性在于其“自定義知識庫綁定”機(jī)制。接入者可以在JoyAgent平臺上自定義智能體，通過工作流綁定自定義知識庫。這使得在召回評審規(guī)則時(shí)，系統(tǒng)能動態(tài)地查找并應(yīng)用接入者自定義的評審規(guī)則，從而實(shí)現(xiàn)了無需修改Prompt即可定制評審規(guī)則的能力。

3.行級評審：JoyAgent將代碼Diff與召回的具體規(guī)則相結(jié)合，再次調(diào)用LLM進(jìn)行精確評審。利用Git Diff信息中包含的代碼行信息，能夠?qū)⒃u審意見精準(zhǔn)關(guān)聯(lián)到具體的代碼行。

4.輸出結(jié)果：直接使用JoyAgent的輸出結(jié)果，通過coding平臺API將評審結(jié)果添加到MR中。

核心問題識別：

1.知識歸納失真：核心問題源于其“知識歸納”步驟。該步驟依賴底層大模型對Code Diff進(jìn)行總結(jié)，此過程不穩(wěn)定，經(jīng)常遺漏或曲解原始代碼變更的關(guān)鍵上下文，導(dǎo)致后續(xù)流程建立在一個(gè)不完整或失真的信息基礎(chǔ)之上。

2.檢索與生成聯(lián)動失效：基于失真的知識歸納結(jié)果進(jìn)行RAG檢索，導(dǎo)致召回的規(guī)則與真實(shí)代碼場景匹配度低。此外，檢索結(jié)果未經(jīng)有效的重排序，直接與不完整的代碼上下文一并送入大模型，這使得模型缺乏進(jìn)行準(zhǔn)確判斷的可靠依據(jù)，最終必然生成大量不可靠甚至錯(cuò)誤的評審意見。

從線上問題到技術(shù)突破

問題1：三方系統(tǒng)空值處理異常

示例：

// 問題代碼：三方系統(tǒng)地址編碼字段處理
request.setAddressCode(String.valueOf(address.getCode()));
// 當(dāng)address.getCode()為null時(shí)，String.valueOf(null)返回"null"字符串
// 導(dǎo)致三方系統(tǒng)Integer.parseInt("null")拋出NumberFormatException

技術(shù)1的問題：

理論上，可以通過在Prompt中硬編碼“三方接口地址編碼須為數(shù)字類型字符串” 的規(guī)則來識別此問題。然而，隨著業(yè)務(wù)場景增多，所有規(guī)則都被擠壓在有限的上下文窗口內(nèi)競爭。當(dāng)代碼變更觸發(fā)自動壓縮（如截?cái)嘀?0行）時(shí)，被保留的上下文具有極大的隨機(jī)性，與當(dāng)前評審強(qiáng)相關(guān)的評審規(guī)則很可能被其他無關(guān)規(guī)則擠掉或因自動壓縮而被截掉，導(dǎo)致其無法被穩(wěn)定觸發(fā)，從而漏報(bào)。

技術(shù)2的問題：

該方案雖然理論上能夠通過知識庫檢索到相關(guān)規(guī)則，但其不穩(wěn)定的知識歸納過程導(dǎo)致代碼上下文的理解時(shí)好時(shí)壞，使得規(guī)則檢索的準(zhǔn)確性波動較大。同時(shí)，未對檢索結(jié)果進(jìn)行重排序，進(jìn)一步放大了這種不確定性。最終，由于缺乏穩(wěn)定、可靠的上下文支撐，系統(tǒng)無法持續(xù)、準(zhǔn)確地識別此類問題，其評審結(jié)果表現(xiàn)出顯著的隨機(jī)性。

問題2：EDI項(xiàng)目中的語法錯(cuò)誤

示例：

 -->

EDI平臺介紹：

EDI（電子數(shù)據(jù)交換）是用來解決京東物流與多樣化商家系統(tǒng)間的對接難題的技術(shù)，其關(guān)鍵功能包括協(xié)議轉(zhuǎn)換、數(shù)據(jù)格式轉(zhuǎn)換、數(shù)據(jù)校驗(yàn)和流程編排。這意味著EDI配置文件必須嚴(yán)格遵守預(yù)定義的語法和標(biāo)準(zhǔn)，任何偏差都可能導(dǎo)致平臺的核心轉(zhuǎn)換與校驗(yàn)功能失效。

技術(shù)1的問題：

由于其缺乏對EDI配置語法與規(guī)范的領(lǐng)域知識，如果自定義規(guī)則，會遇到問題1一樣的提示詞天花板和上下文截?cái)嗟膯栴}。

技術(shù)2的問題：

除了上面提到的知識歸納過程的不穩(wěn)定問題，技術(shù)2也面臨一個(gè)更前置的的挑戰(zhàn)：它缺乏對項(xiàng)目身份的感知能力。系統(tǒng)在處理一個(gè)XML配置文件時(shí)，無法自動識別它隸屬于“EDI項(xiàng)目”而非普通Java應(yīng)用。因此，在后續(xù)的RAG檢索過程中，它極有可能使用通用的Java代碼評審規(guī)則，而無法精準(zhǔn)命中“EDI專用配置規(guī)范”這一關(guān)鍵上下文，導(dǎo)致檢索方向錯(cuò)誤，最終無法識別出必須使用字面常量這一特定于EDI領(lǐng)域的合規(guī)性要求。

解決方案：雙RAG架構(gòu)

1. 識別項(xiàng)目類型

?特征識別：基于文件擴(kuò)展名（.flow, .dt）進(jìn)行精準(zhǔn)判斷。

?優(yōu)先級設(shè)定：EDI項(xiàng)目識別優(yōu)先于普通JAVA項(xiàng)目，確保領(lǐng)域特殊性得到優(yōu)先處理。

?策略影響：項(xiàng)目類型直接決定后續(xù)評審規(guī)則的選擇與RAG知識庫的檢索策略，從源頭保障了評審的針對性。

2. 代碼分塊處理

2.1 Token估算算法

由于我們使用的底層大模型是JoyAI，并沒有公開tokenizer的細(xì)節(jié)，根據(jù)官網(wǎng)文檔提供的token計(jì)算API： http://api.chatrhino.jd.com/api/v1/tokenizer/estimate-token-count

測試了幾組數(shù)據(jù)：

推導(dǎo)過程

通過分析測試數(shù)據(jù)，我們發(fā)現(xiàn)了以下關(guān)鍵規(guī)律：

1.基礎(chǔ)系統(tǒng)開銷：所有請求都有63 tokens的固定開銷

2.英文單詞分級：

?1-5字符單詞 = 1 token（"a"、"hello"、"code"）

?6-10字符單詞 ≈ 2 tokens（推測值）

?11+字符單詞 = 3 tokens（"programming"）

3.中文分詞規(guī)則：每2個(gè)中文字符 = 1 token

4.空格處理：空格作為分隔符，不增加額外token

5.混合內(nèi)容：按字符類型分段計(jì)算后求和

基于上述規(guī)律，我們構(gòu)建了以下估算公式：

總Tokens = 63 + ∑(單詞token)

單詞token計(jì)算：
- 單字符單詞: 1 token
- 英文單詞(≤5字符): 1 token  
- 英文單詞(6-10字符): 2 tokens
- 英文單詞(≥11字符): 3 tokens
- 中文文本: (字符數(shù) + 1) / 2 tokens
- 混合內(nèi)容: 分段計(jì)算后求和

2.2 分塊閾值與安全設(shè)計(jì)

?觸發(fā)閾值：當(dāng)預(yù)估Token數(shù) > 100,000時(shí)，自動觸發(fā)分塊處理流程。

?JoyAI的上下文窗口是128K，由于JoyAI沒說明1K是1024還是1000，保守估計(jì)使用1000

?128K = 128000，為了避免超過上下文窗口，留個(gè)富余量，使用80%，12800*0.8=102400 ≈100000

?單塊容量：設(shè)定 MAX_TOKENS_PER_CHUNK = 60000，為模型輸出及上下文預(yù)留40%的安全余量。

?設(shè)計(jì)理念：通過嚴(yán)格的容量控制，確保單次處理負(fù)載均在模型窗口的安全范圍內(nèi)。

2.3 智能分塊策略

系統(tǒng)采用兩級分塊策略，確保代碼語義的完整性：

2.3.1 文件級分割

通過git diff指令識別文件邊界，確保單個(gè)文件的代碼完整性，避免跨文件分割。

Pattern.compile("diff --git a/(.+?) b/(.+?)n") 

2.3.2 代碼結(jié)構(gòu)感知分割

利用方法簽名模式識別代碼結(jié)構(gòu)邊界：

Pattern methodPattern = Pattern.compile(
 "([+-]\s*((public|private|protected)\s+)?(\w+\s+)?\w+\s*\([^)]*\)\s*\{)",Pattern.MULTILINE);

在方法或類的自然邊界處進(jìn)行分割，最大限度保持代碼塊的語義完整性。

3. RAG增強(qiáng)與重排序機(jī)制

3.1 基于知識工程的代碼片段、業(yè)務(wù)上下文的檢索

在 RAG增加服務(wù)中實(shí)現(xiàn)多維度檢索增強(qiáng)：

?業(yè)務(wù)領(lǐng)域識別：基于代碼內(nèi)容識別是倉業(yè)務(wù)（WMS）、倉配接入業(yè)務(wù)（ECLP）、轉(zhuǎn)運(yùn)中心業(yè)務(wù)（TC）等。

?關(guān)鍵詞提取與過濾：從變更文件中提取并凈化關(guān)鍵術(shù)語。

?通過執(zhí)行語義搜索。

重排序優(yōu)化：對檢索結(jié)果使用BGE模型進(jìn)行重排序，提升相關(guān)性。

3.2 重排序

在RAG系統(tǒng)中，檢索（召回）這一步通常使用向量相似度搜索。這種方法追求的是高召回率——即盡可能不遺漏任何可能相關(guān)的文檔。但這就帶來了一個(gè)問題：

?數(shù)量過多：可能會返回大量候選文檔，全部送入大模型會導(dǎo)致超過上下文窗口限制，成本高昂且速度慢。

?質(zhì)量不均：向量搜索是基于語義相似度，但“相似”不一定等于“有用”。它可能會召回一些：

?主題相關(guān)但內(nèi)容泛泛的文檔。

?包含關(guān)鍵詞但邏輯不匹配的文檔。

?相關(guān)性排名不高但實(shí)際至關(guān)重要的“珍寶”文檔。

例如檢索“如何做番茄炒蛋”，向量相似度查詢結(jié)果可能會找到：

?《番茄炒蛋的最正宗做法》 （極度相關(guān)，排名第一）

?《100道家常菜譜》 （相關(guān)，但范圍太廣）

?《雞蛋的營養(yǎng)價(jià)值》 （部分相關(guān)）

?《番茄種植指南》 （僅關(guān)鍵詞相關(guān)，實(shí)際無用）

如果不經(jīng)處理，把這四篇文檔塞給大模型，模型需要費(fèi)力地從大量文本中辨別哪些是真正有用的信息，不僅增加了Token消耗，更嚴(yán)重的是，無關(guān)信息會形成“噪聲”，干擾模型的判斷，導(dǎo)致生成質(zhì)量下降——模型幻覺。

為了節(jié)省成本，我們使用了本地重排序方案：

?模型文件: bge-reranker-base.onnx (BGE重排序模型)

?分詞器: HuggingFaceTokenizer

?運(yùn)行時(shí): ONNX Runtime Java API

// 核心流程
public List> rerankBatch(String query, List documents) {
 // 1. 文本預(yù)處理和分詞
 // 2. 構(gòu)建查詢-文檔對
 // 3. ONNX模型推理
 // 4. 相關(guān)性評分計(jì)算
 // 5. 按分?jǐn)?shù)降序排序
 // 6. 返回排序結(jié)果
}

示例：

4. 實(shí)際應(yīng)用效果驗(yàn)證

案例1：成功預(yù)防空值處理事故

案例2：EDI配置規(guī)范檢查

?

總結(jié)與展望

我們探索出的雙RAG架構(gòu)，其價(jià)值核心并非追求極致的簡單或敏捷，而是它既能像資深的一線研發(fā)一樣，深度理解業(yè)務(wù)及代碼變更的具體語境與潛在影響，又能像嚴(yán)謹(jǐn)?shù)募軜?gòu)師一樣，嚴(yán)格遵循成文的規(guī)范與最佳實(shí)踐。

通過結(jié)構(gòu)化的協(xié)同機(jī)制，系統(tǒng)將兩種不同質(zhì)、不同源的知識（深度的代碼語義與精準(zhǔn)的評審規(guī)則）進(jìn)行融合，實(shí)現(xiàn)了 “1+1 > 2” 的智能涌現(xiàn)，從而具備了識別并預(yù)防那些復(fù)雜、隱蔽代碼缺陷的深度推理能力。這正是我們在高并發(fā)、高可用要求極為嚴(yán)苛的大促等場景下，為夯實(shí)系統(tǒng)穩(wěn)定性基石所做出的關(guān)鍵性架構(gòu)決策。

這一成功實(shí)踐，為我們奠定了代碼評審工作中堅(jiān)實(shí)的技術(shù)基石，并清晰地指明了未來的演進(jìn)路徑：

1.邁向多模態(tài)代碼理解：從純文本代碼評審，擴(kuò)展至對架構(gòu)圖、時(shí)序圖等非結(jié)構(gòu)化設(shè)計(jì)產(chǎn)物的理解與合規(guī)性檢查。

2.構(gòu)建全域業(yè)務(wù)知識庫：自動抓取并融合產(chǎn)品經(jīng)理的歷史PRD、設(shè)計(jì)文檔等非技術(shù)知識，將其轉(zhuǎn)化為知識工程中的關(guān)鍵上下文。這使得AI在評審時(shí)，不僅能理解“代碼怎么寫”，更能判斷“代碼為何而寫”，實(shí)現(xiàn)對業(yè)務(wù)意圖的精準(zhǔn)校驗(yàn)，從源頭規(guī)避偏離產(chǎn)品設(shè)計(jì)的實(shí)現(xiàn)。

3.實(shí)現(xiàn)需求上下文的自動關(guān)聯(lián)：通過規(guī)范研發(fā)流程，約束在提交代碼時(shí)于commit信息中嵌入需求編號。系統(tǒng)在評審時(shí)自動提取該編號，并主動獲取對應(yīng)的PRD詳情。這使得每一次代碼評審都能夠在完整的業(yè)務(wù)背景中進(jìn)行，AI能夠直接對照需求文檔，判斷代碼實(shí)現(xiàn)是否完整、準(zhǔn)確地滿足了所有功能點(diǎn)與業(yè)務(wù)規(guī)則，提供前更加精準(zhǔn)的上下文。

雖然探索的道路并非坦途，我們曾在具體的技術(shù)細(xì)節(jié)中陷入困境，例如，為了在 CentOS 7.9 的環(huán)境中支持高版本 ONNX 運(yùn)行時(shí)以啟用重排序功能，不得不手動編寫docker腳本從源碼編譯高版本的cglib依賴。這段經(jīng)歷，恰恰印證了弗雷德里克·布魯克斯在《人月神話》中所揭示的那句箴言：

The only way to accelerate software work is to simplify the product and the process, and to face the essential complexity of the software task itself with courage and skill.

審核編輯 黃宇