“你有沒(méi)有遇到過(guò)這樣的場(chǎng)景接手一個(gè)維護(hù)了三年的老項(xiàng)目需求排下來(lái)你需要評(píng)估改一個(gè)底層工具函數(shù)會(huì)影響多少上層業(yè)務(wù)。你打開 IDE沿著調(diào)用鏈跳來(lái)跳去跳了二十分鐘只能確定一部分直接調(diào)用方再用全局搜索搜一遍結(jié)果查出來(lái)一堆日志框架里的同名方法。你最后只能憑經(jīng)驗(yàn)告訴產(chǎn)品經(jīng)理可能要改 5 個(gè)模塊但我不確定。”這不是你的能力問(wèn)題而是傳統(tǒng)程序分析工具和“業(yè)務(wù)語(yǔ)義理解”之間一直存在一條巨大的鴻溝。這兩年大語(yǔ)言模型LLM給這條鴻溝帶來(lái)了一個(gè)新的可能。很多人第一反應(yīng)是把整個(gè)代碼庫(kù)塞給 ChatGPT 或 Claude讓它直接幫忙分析。試過(guò)的人都知道小項(xiàng)目上效果不錯(cuò)一旦代碼庫(kù)超過(guò)幾萬(wàn)行模型就開始“失憶”要么上下文不夠用要么它給出的結(jié)論經(jīng)常張冠李戴。問(wèn)題不在模型不夠強(qiáng)而在于我們讓模型在一個(gè)沒(méi)有結(jié)構(gòu)化記憶的環(huán)境里做分析。Lemmalog 的核心思路是把代碼庫(kù)先轉(zhuǎn)成一張清晰的“記憶地圖”讓 LLM 先在記憶地圖上做推理而不是直接讀原始代碼。這個(gè)過(guò)程不是簡(jiǎn)單地把代碼轉(zhuǎn)換成 embedding 存進(jìn)向量庫(kù)而是把程序分析需要的符號(hào)、調(diào)用關(guān)系、模塊職責(zé)、業(yè)務(wù)語(yǔ)義組織成 LLM 能讀懂、能校驗(yàn)、能持續(xù)更新的結(jié)構(gòu)化文檔。本文會(huì)從設(shè)計(jì)動(dòng)機(jī)、核心概念、架構(gòu)、流程、代碼實(shí)現(xiàn)、驗(yàn)證方式到落地建議完整拆解 Lemmalog 的思路。1. 這篇文章真正要解決的問(wèn)題為什么代碼分析這么難傳統(tǒng)程序分析并不是沒(méi)有工具。IDE 里有“查找所有引用”命令行里有 grep、ctags、cscope工程化一點(diǎn)還有 SonarQube、CodeQL、Soot 等靜態(tài)分析框架。它們能解決“誰(shuí)調(diào)用了這個(gè)函數(shù)”“這個(gè)變量在哪里被修改”這類精確問(wèn)題但面對(duì)下面幾類需求時(shí)往往力不從心變更影響評(píng)估我改了某個(gè)底層函數(shù)哪些業(yè)務(wù)模塊會(huì)受影響影響范圍是什么業(yè)務(wù)語(yǔ)義溯源這段看起來(lái)奇怪的代碼當(dāng)初是為了滿足什么業(yè)務(wù)規(guī)則才寫出來(lái)的注釋沒(méi)寫文檔也沒(méi)有。跨語(yǔ)言/跨服務(wù)調(diào)用鏈一個(gè)請(qǐng)求從 API 入口進(jìn)來(lái)經(jīng)過(guò)網(wǎng)關(guān)、服務(wù) A、消息隊(duì)列、服務(wù) B最后落庫(kù)。這中間的數(shù)據(jù)流和異常傳播關(guān)系靜態(tài)分析工具很難一句話說(shuō)清楚。架構(gòu)一致性審查代碼實(shí)際結(jié)構(gòu)是不是符合團(tuán)隊(duì)規(guī)定的分層規(guī)范有沒(méi)有人繞過(guò)了 Service 層直接操作 Repository這些問(wèn)題的共同點(diǎn)是答案不在代碼本身的語(yǔ)法結(jié)構(gòu)里而在代碼與業(yè)務(wù)意圖的對(duì)應(yīng)關(guān)系中。傳統(tǒng)靜態(tài)分析擅長(zhǎng)提取“程序事實(shí)”比如函數(shù)定義、調(diào)用邊、數(shù)據(jù)依賴但它不懂“為什么”。人到是能理解業(yè)務(wù)但面對(duì)幾百萬(wàn)行代碼沒(méi)有人能把所有調(diào)用鏈都記在腦子里。LLM 的出現(xiàn)補(bǔ)上了“語(yǔ)義理解”這塊拼圖。它能讀懂注釋、變量名、模塊命名背后的意圖能根據(jù)上下文推斷一段代碼是做什么的。但 LLM 也有它自己的問(wèn)題記不住大代碼庫(kù)的全貌。上下文窗口再大也塞不下一個(gè)中大型項(xiàng)目的全部源碼即使塞下了注意力機(jī)制也會(huì)讓模型在大量無(wú)關(guān)代碼中迷失給出看似合理、實(shí)則經(jīng)不起推敲的結(jié)論。Lemmalog 要解決的就是這個(gè)問(wèn)題能不能設(shè)計(jì)一個(gè)系統(tǒng)讓傳統(tǒng)程序分析工具負(fù)責(zé)“提取事實(shí)”讓 LLM 負(fù)責(zé)“基于事實(shí)做推理”然后把模型產(chǎn)出的結(jié)論變成可復(fù)用的記憶持續(xù)積累讀完這篇文章你可以得到三條具體收益理解如何把 LLM 的上下文管理能力改造成程序分析的“記憶層”。拿到一套可以落地的流程符號(hào)提取、模塊地圖生成、LLM 分析、程序化校驗(yàn)。知道哪些場(chǎng)景適合用 LLM 做程序分析哪些場(chǎng)景必須回到傳統(tǒng)工具避免被“幻覺(jué)”誤導(dǎo)。2. 核心概念LLM 記憶與程序分析的交叉點(diǎn)在深入 Lemmalog 之前需要先統(tǒng)一幾個(gè)概念。2.1 什么是 LLM 的記憶LLM 本身沒(méi)有持久記憶。你每次調(diào)用它它只根據(jù)你當(dāng)前提供的上下文生成回復(fù)。所謂“讓 LLM 記住”本質(zhì)上是在當(dāng)前請(qǐng)求里提供足夠多、足夠有效的相關(guān)信息。常見(jiàn)的做法有幾類上下文窗口直接塞入把相關(guān)代碼片段、文檔全部拼進(jìn) prompt。適合小項(xiàng)目不適合大倉(cāng)庫(kù)。向量檢索RAG把代碼切塊做 embedding用戶提問(wèn)時(shí)檢索最相關(guān)的塊再交給模型。適合“搜索式”問(wèn)答但檢索召回質(zhì)量直接決定分析質(zhì)量而且它更適合“定位知識(shí)”不太適合“沿調(diào)用鏈推理”。結(jié)構(gòu)化外部記憶先對(duì)原始材料做一次預(yù)處理提取出符號(hào)、結(jié)構(gòu)、摘要組織成模型容易消費(fèi)的文檔或 JSON。模型看到的是經(jīng)過(guò)提煉的“知識(shí)”而不是原始噪聲。Karpathy 在 LLM wiki 方法里提到的思路本質(zhì)上屬于第三類與其讓模型每次從頭閱讀原始資料不如先維護(hù)一份高質(zhì)量的外部文檔讓模型在文檔之上工作。Lemmalog 的記憶層設(shè)計(jì)和這個(gè)思路高度一致只不過(guò)我們記憶的對(duì)象從“通用知識(shí)”變成了“代碼庫(kù)的程序分析事實(shí)”。2.2 程序分析需要什么樣的記憶程序分析工具輸出的信息大致可以分成兩類第一類是程序事實(shí)。事實(shí)是確定的某個(gè)類有哪些方法某個(gè)函數(shù)在哪個(gè)文件第幾行定義某個(gè)函數(shù)調(diào)用了哪些其他函數(shù)某個(gè)變量在哪些路徑上被寫入。這類信息適合用語(yǔ)法解析器如 tree-sitter或編譯器前端提取精確度高幾乎不會(huì)出錯(cuò)。第二類是語(yǔ)義推斷。語(yǔ)義是概率性的這個(gè)模塊的職責(zé)是什么這段 catch 是不是在兜底某個(gè)外部依賴異常這個(gè)設(shè)計(jì)模式是不是為了后續(xù)擴(kuò)展插件。語(yǔ)義推斷需要結(jié)合命名、注釋、代碼結(jié)構(gòu)、甚至團(tuán)隊(duì)歷史傳統(tǒng)工具做不好但 LLM 恰好擅長(zhǎng)。Lemmalog 的基本判斷是程序事實(shí)和語(yǔ)義推斷不應(yīng)該混在一起。事實(shí)交給規(guī)則和解析器保證正確性推斷交給 LLM 給出候選最后由人工或自動(dòng)校驗(yàn)兜底。記憶層里裝的是“事實(shí) 經(jīng)過(guò)校驗(yàn)的推斷”而不是一堆未經(jīng)處理的原始代碼 embedding。2.3 兩者結(jié)合后會(huì)發(fā)生什么當(dāng) LLM 拿到的不再是原始代碼而是一張“程序事實(shí)地圖”時(shí)它的推理質(zhì)量會(huì)明顯提升。原因很直接模型不需要在幾萬(wàn)行代碼里去猜調(diào)用關(guān)系它可以專注在“由工具保證正確的調(diào)用鏈”上做它擅長(zhǎng)的高層推理。舉個(gè)例子傳統(tǒng)靜態(tài)分析告訴你函數(shù) A 調(diào)用了 BB 調(diào)用了 C。但 A 調(diào)用 B 是正常業(yè)務(wù)路徑還是僅在異常時(shí)觸發(fā)工具不知道。如果記憶層里有一條語(yǔ)義標(biāo)注“B 只在 A 的異常處理塊中被調(diào)用作用是記錄審計(jì)日志”那么 LLM 在做變更影響分析時(shí)就不會(huì)把 B 的錯(cuò)誤理解為一條高頻主鏈路。記憶的作用是把“代碼長(zhǎng)什么樣”和“代碼為什么這樣寫”拼在一起讓程序分析從“看語(yǔ)法”升級(jí)為“看語(yǔ)義”。3. Lemmalog 的整體架構(gòu)設(shè)計(jì)Lemmalog 不是一個(gè)單一腳本而是一個(gè)分層系統(tǒng)。整個(gè)架構(gòu)可以分成三層記憶層、分析層、應(yīng)用層。3.1 記憶層代碼事實(shí)庫(kù)記憶層是 Lemmalog 的地基負(fù)責(zé)把代碼庫(kù)轉(zhuǎn)成一系列結(jié)構(gòu)化產(chǎn)物符號(hào)表每個(gè)文件里定義了哪些函數(shù)、類、變量行號(hào)范圍是多少。調(diào)用圖函數(shù)與函數(shù)之間的調(diào)用邊文件與文件之間的依賴邊。模塊地圖按目錄或模塊組織描述每個(gè)模塊的職責(zé)、關(guān)鍵入口、暴露給外部的接口。語(yǔ)義標(biāo)注人工或 LLM 撰寫的模塊說(shuō)明解釋代碼背后的業(yè)務(wù)規(guī)則、異常處理邏輯、設(shè)計(jì)意圖。記憶層推薦的存儲(chǔ)形式是“主文件用 Markdown JSON輔助檢索可以加向量索引”。第一版建議直接用 Markdown 文件配合 Git 管理原因有三可讀性強(qiáng)團(tuán)隊(duì)里每個(gè)人都能 review?？梢?diff代碼變更后記憶的變更一目了然。不需要額外基礎(chǔ)設(shè)施啟動(dòng)成本極低。3.2 分析層LLM 推理引擎分析層接收三類輸入用戶提出的分析任務(wù)、記憶層提供的相關(guān)事實(shí)、程序化約束比如輸出必須符合某個(gè) JSON Schema。分析層的主要工作是把這些輸入組織成結(jié)構(gòu)化的 prompt調(diào)用 LLM得到候選結(jié)論。分析層不直接讀源碼這是一個(gè)原則。所有源碼層面的事實(shí)必須先經(jīng)過(guò)記憶層提煉再交給模型。這樣做的最大好處是控制模型的輸入規(guī)模把注意力集中在與分析任務(wù)相關(guān)的信息和知識(shí)上。3.3 應(yīng)用層面向開發(fā)者的交互入口應(yīng)用層是開發(fā)者實(shí)際接觸的部分形態(tài)可以是CLI 工具執(zhí)行“影響分析”“模塊掃描”“語(yǔ)義檢索”等命令。CI 集成提交 PR 時(shí)自動(dòng)分析變更影響范圍把結(jié)果評(píng)論到 MR 中。交互式問(wèn)答讓開發(fā)者在終端或網(wǎng)頁(yè)里針對(duì)代碼庫(kù)發(fā)問(wèn)例如“支付超時(shí)重試邏輯在哪里實(shí)現(xiàn)”。應(yīng)用層本身不包含復(fù)雜的分析邏輯它負(fù)責(zé)拆解用戶請(qǐng)求、調(diào)度分析層、收集結(jié)果、并最終展示。4. 環(huán)境準(zhǔn)備與前置條件在開始實(shí)現(xiàn) Lemmalog 之前需要準(zhǔn)備以下環(huán)境。版本號(hào)請(qǐng)以實(shí)際安裝為準(zhǔn)本文的重點(diǎn)是打通思路。4.1 基礎(chǔ)環(huán)境操作系統(tǒng)macOS / Linux / WindowsWSL 也可。Python3.10 或以上用于編寫分析腳本。Git用于管理代碼庫(kù)和記憶文檔。LLM API一個(gè)支持 OpenAI 兼容接口的模型服務(wù)或者本地部署的模型。建議選擇輸出 JSON 能力較強(qiáng)的模型便于程序化解析。tree-sitter多語(yǔ)言增量解析庫(kù)用于提取代碼符號(hào)和調(diào)用關(guān)系。4.2 安裝依賴以 Python 環(huán)境為例python -m venv .venv source .venv/bin/activate pip install tree-sitter openai注意tree-sitter 對(duì) Python 的版本要求可能隨版本變化如果安裝失敗優(yōu)先檢查 Python 版本和 tree-sitter 版本是否兼容。如果要解析多種語(yǔ)言需要提前編譯對(duì)應(yīng)語(yǔ)言的 grammar 文件這部分官方文檔有詳細(xì)說(shuō)明。4.3 選擇一個(gè)合適的試點(diǎn)項(xiàng)目不建議一上來(lái)就對(duì)超大型微服務(wù)倉(cāng)庫(kù)做全量掃描。建議找一個(gè)自己熟悉的中小型項(xiàng)目代碼量在 1 萬(wàn)到 20 萬(wàn)行之間有清晰的目錄結(jié)構(gòu)最好是你正在維護(hù)的項(xiàng)目。這樣你可以對(duì)照真實(shí)代碼驗(yàn)證 Lemmalog 產(chǎn)出的符號(hào)表和調(diào)用圖是否正確。從設(shè)計(jì)到落地這條路最大的風(fēng)險(xiǎn)不是“LLM 不夠聰明”而是“記憶層本身是否準(zhǔn)確”。如果符號(hào)表、調(diào)用圖錯(cuò)了LLM 再聰明也會(huì)在錯(cuò)誤的地圖上做出錯(cuò)誤的分析。所以小項(xiàng)目、可控范圍、人工抽查是第一版最重要的原則。5. 核心流程拆解從代碼庫(kù)到“記憶”再到“分析”這一節(jié)是全文的主干。Lemmalog 的運(yùn)行流程可以拆成六個(gè)步驟。5.1 掃描提取符號(hào)表第一步是用 tree-sitter 解析源碼提取每個(gè)文件里的函數(shù)、類、方法定義。這一步的目標(biāo)是建立“文件名 → 符號(hào)列表 → 行號(hào)區(qū)間”的映射。這一步為什么不能交給 LLM因?yàn)?LLM 提取符號(hào)會(huì)漏、會(huì)錯(cuò)、會(huì)對(duì)不齊行號(hào)。行號(hào)一旦錯(cuò)了后續(xù)所有分析都會(huì)錯(cuò)。符號(hào)表必須由確定性工具生成零誤差是唯一標(biāo)準(zhǔn)。5.2 構(gòu)建調(diào)用圖在符號(hào)表的基礎(chǔ)上繼續(xù)用 tree-sitter 分析每個(gè)函數(shù)體內(nèi)部找出函數(shù)調(diào)用表達(dá)式把“調(diào)用方函數(shù)名 → 被調(diào)用方函數(shù)名”的關(guān)系提取出來(lái)。同時(shí)把同目錄文件、同包文件的依賴關(guān)系一并記錄。調(diào)用圖是記憶層里最有價(jià)值的資產(chǎn)。它比文本檢索更精確如果一個(gè)函數(shù)被 20 處調(diào)用調(diào)用圖能列出這 20 處的完整上下文。但要注意tree-sitter 只能識(shí)別語(yǔ)法層面的直接調(diào)用對(duì)于反射、動(dòng)態(tài)派發(fā)、通過(guò)框架注冊(cè)的回調(diào)靜態(tài)分析會(huì)漏掉。這一部分需要在后續(xù)語(yǔ)義標(biāo)注時(shí)人工補(bǔ)充。5.3 生成模塊地圖模塊地圖是給 LLM 看的“知識(shí)提綱”相當(dāng)于一本書的目錄。它按模塊或目錄組織描述每一層有什么、入口在哪里、核心函數(shù)是哪些。模塊地圖不需要覆蓋每一個(gè)函數(shù)它只需要讓模型知道“如果你想深入分析某個(gè)模塊應(yīng)該去查哪一段記憶”。模塊的粒度一般按源碼目錄劃分配合 README 和核心文件注釋生成。5.4 語(yǔ)義增強(qiáng)補(bǔ)充代碼背后的業(yè)務(wù)規(guī)則符號(hào)表和調(diào)用圖是“死”的它們描述代碼的結(jié)構(gòu)但不解釋意圖。語(yǔ)義增強(qiáng)是讓記憶“活”起來(lái)的關(guān)鍵步驟。具體做法有兩個(gè)層面人工標(biāo)注對(duì)核心模塊補(bǔ)充業(yè)務(wù)規(guī)則例如“本模塊訂單狀態(tài)流轉(zhuǎn)遵循狀態(tài)機(jī)禁止跳過(guò) TO_PAY 直接進(jìn)入 COMPLETED”。LLM 輔助總結(jié)讓 LLM 讀取某個(gè)模塊的代碼輸出職責(zé)摘要和關(guān)鍵邏輯說(shuō)明。重點(diǎn)是LLM 產(chǎn)出的是草稿必須由熟悉該模塊的工程師 review 后才允許寫入記憶層。很多團(tuán)隊(duì)會(huì)跳過(guò)這一步直接進(jìn)行第 5 步分析。結(jié)果就是 LLM 只能從代碼字面推斷語(yǔ)義容易把異常路徑當(dāng)成主路徑把兼容性代碼當(dāng)成核心邏輯。語(yǔ)義標(biāo)注的質(zhì)量決定了 Lemmalog 分析結(jié)果的天花板。5.5 分析用結(jié)構(gòu)化 Prompt 驅(qū)動(dòng) LLM當(dāng)記憶層就緒就可以執(zhí)行具體的分析任務(wù)了。以“變更影響分析”為例分析層會(huì)加載模塊地圖和調(diào)用圖。提取變更文件涉及的函數(shù)以及這些函數(shù)在調(diào)用圖中的上下游。把上述信息連同變更 diff一起組織進(jìn) prompt。要求 LLM 輸出結(jié)構(gòu)化結(jié)論受影響函數(shù)、風(fēng)險(xiǎn)等級(jí)、推理依據(jù)。這里的關(guān)鍵是prompt 里給的是“提煉后的信息”而不是數(shù)百行原始代碼。模型不用大海撈針?biāo)梢粤⒖涕_始推理。5.6 校驗(yàn)與回流讓記憶滾動(dòng)起來(lái)LLM 輸出的結(jié)論不能直接信。Lemmalog 在分析層之后加了一個(gè)自動(dòng)校驗(yàn)步驟檢查 LLM 輸出的函數(shù)名、類名是否真實(shí)存在于符號(hào)表。檢查它聲稱的調(diào)用關(guān)系是否匹配調(diào)用圖。檢查文件路徑是否存在。校驗(yàn)通過(guò)的結(jié)果可以寫回記憶層作為后續(xù)分析的知識(shí)沉淀。比如這一次影響分析發(fā)現(xiàn)了“A 模塊在異常時(shí)會(huì)調(diào)用 B 模塊的審計(jì)方法”這條語(yǔ)義標(biāo)注就可以保存下來(lái)下次分析 A 模塊時(shí)直接復(fù)用。這一步是把“一次性問(wèn)答”升級(jí)為“可積累的程序分析資產(chǎn)”的關(guān)鍵。6. 完整示例代碼實(shí)現(xiàn)下面用一個(gè)最小示例演示 Lemmalog 從符號(hào)提取到影響分析的完整鏈路。示例項(xiàng)目結(jié)構(gòu)如下lemmalog_demo/ ├── memory_builder/ │ ├── build_symbols.py │ └── build_map.py ├── analyzer/ │ ├── impact_analyzer.py │ └── validator.py └── sample_project/ ├── core/ │ ├── order.py │ └── payment.py └── api/ └── order_api.py6.1 用 tree-sitter 提取 Python 函數(shù)定義文件路徑lemmalog_demo/memory_builder/build_symbols.py# 示例用 tree-sitter 提取 Python 文件中的函數(shù)定義 from pathlib import Path import tree_sitter from tree_sitter import Language, Parser # 根據(jù)你本地安裝的 tree-sitter-python 進(jìn)行加載 # 不同版本加載方式略有差異建議參考官方文檔 PY_LANGUAGE Language(build/my-languages.so, python) parser Parser() parser.set_language(PY_LANGUAGE) def extract_functions(file_path: Path) - list[dict]: source_code file_path.read_text(encodingutf-8) source_bytes source_code.encode(utf-8) tree parser.parse(source_bytes) root_node tree.root_node functions [] def walk(node): if node.type function_definition: name_node node.child_by_field_name(name) if name_node: functions.append( { name: name_node.text.decode(utf-8), start_line: node.start_point[0] 1, end_line: node.end_point[0] 1, } ) for child in node.children: walk(child) walk(root_node) return functions if __name__ __main__: demo_file Path(sample_project/core/order.py) for func in extract_functions(demo_file): print(func)這段代碼做了三件事解析 Python 源文件、遍歷語(yǔ)法樹查找function_definition節(jié)點(diǎn)、提取函數(shù)名和行號(hào)范圍。輸出結(jié)果是一個(gè)簡(jiǎn)單的 JSON 列表后續(xù)可以寫入符號(hào)表文件。6.2 生成模塊地圖 Markdown文件路徑lemmalog_demo/memory_builder/build_map.py# 示例生成模塊地圖 Markdown from pathlib import Path from memory_builder.build_symbols import extract_functions def generate_module_map(project_root: Path) - str: lines [ # Project Map, , 本文件由 Lemmalog 記憶構(gòu)建器自動(dòng)生成建議納入版本管理。, , ] for py_file in sorted(project_root.rglob(*.py)): relative_path py_file.relative_to(project_root) functions extract_functions(py_file) if not functions: continue lines.append(f## {relative_path}) lines.append() for func in functions: lines.append( f- {func[name]} at line {func[start_line]}-{func[end_line]} ) lines.append() return \n.join(lines) if __name__ __main__: root Path(sample_project) map_text generate_module_map(root) output_path Path(memory/project_map.md) output_path.parent.mkdir(exist_okTrue) output_path.write_text(map_text, encodingutf-8) print(output_path)模塊地圖不是簡(jiǎn)單的文件列表它面向的核心讀者是“后續(xù)的 LLM 分析”。每一步生成的 Markdown 應(yīng)該保持結(jié)構(gòu)化、可 diff、可追溯。6.3 調(diào)用 LLM 做變更影響分析文件路徑lemmalog_demo/analyzer/impact_analyzer.py# 示例基于模塊地圖讓 LLM 做變更影響分析 import json from openai import OpenAI # openai1.0 的用法如果你用的是 0.x 老版本API 會(huì)不同 client OpenAI( base_urlyour-api-endpoint, # 替換為你的服務(wù)地址 api_keyyour-api-key, # 生產(chǎn)環(huán)境請(qǐng)使用環(huán)境變量 ) def analyze_impact(module_map: str, changed_files: list[str]) - dict: prompt f 你是一個(gè)代碼評(píng)審助手。下面是一個(gè)項(xiàng)目的模塊地圖 module_map {module_map[:12000]} # 控制輸入長(zhǎng)度截取核心部分 /module_map 本次變更涉及的文件如下 changed_files {json.dumps(changed_files, ensure_asciiFalse)} /changed_files 請(qǐng)分析變更的影響范圍并嚴(yán)格輸出 JSON {{ affected_functions: [函數(shù)名], risk_level: high|medium|low, reason: 影響分析依據(jù) }} response client.chat.completions.create( modelyour-model-name, messages[ {role: system, content: 你是一個(gè)嚴(yán)謹(jǐn)?shù)某绦蚍治鲋?。}, {role: user, content: prompt}, ], response_format{type: json_object}, ) content response.choices[0].message.content return json.loads(content)這里有一個(gè)值得注意的設(shè)計(jì)prompt 中先給模塊地圖再給變更文件最后要求結(jié)構(gòu)化輸出。順序?yàn)槭裁粗匾驗(yàn)槟Ｐ蜁?huì)優(yōu)先理解前置信息再結(jié)合任務(wù)做推理。如果把變更文件放在前面、模塊地圖放在后面模型容易“帶著任務(wù)找答案”忽略全局結(jié)構(gòu)影響分析結(jié)果的整體性。6.4 校驗(yàn) LLM 輸出結(jié)果文件路徑lemmalog_demo/analyzer/validator.py# 示例校驗(yàn) LLM 輸出的函數(shù)名是否真實(shí)存在于符號(hào)表 def validate_affected_functions( affected_functions: list[str], symbol_table: set[str] ) - dict: invalid_names [ name for name in affected_functions if name not in symbol_table ] return { valid: len(invalid_names) 0, invalid_names: invalid_names, message: 校驗(yàn)通過(guò) if not invalid_names else 以下名稱未在符號(hào)表中找到需要人工復(fù)核, } if __name__ __main__: # 實(shí)際使用時(shí)symbol_table 由符號(hào)表構(gòu)建階段生成 fake_symbol_table {create_order, pay_order, cancel_order} llm_output [create_order, pay_order, non_exist_function] print(validate_affected_functions(llm_output, fake_symbol_table))校驗(yàn)邏輯不復(fù)雜但它是整個(gè)系統(tǒng)可信賴的基礎(chǔ)。只要 LLM 輸出中出現(xiàn)符號(hào)表里不存在的函數(shù)名就必須攔截下來(lái)交給人工不能讓錯(cuò)誤結(jié)論流向后續(xù)流程。7. 運(yùn)行結(jié)果與效果驗(yàn)證按照上面的代碼運(yùn)行順序如下cd lemmalog_demo python -m memory_builder.build_symbols python -m memory_builder.build_map python -m analyzer.impact_analyzer python -m analyzer.validator預(yù)期第一步會(huì)輸出一行行函數(shù)信息{name: create_order, start_line: 12, end_line: 30} {name: pay_order, start_line: 32, end_line: 55}第二步會(huì)生成memory/project_map.md文件內(nèi)容大致如下## core/order.py - create_order at line 12-30 - pay_order at line 32-55 ## api/order_api.py - create_order_api at line 8-20如何判斷成功有一個(gè)非常直接的標(biāo)準(zhǔn)符號(hào)表里的函數(shù)行號(hào)在 IDE 里跳轉(zhuǎn)后能與真實(shí)代碼對(duì)齊。如果行號(hào)對(duì)不上符號(hào)表就是廢的后面的分析都不值得信任。建議做一次抽樣驗(yàn)證隨機(jī)挑 10 個(gè)函數(shù)檢查函數(shù)名和行號(hào)是否一致。如果第三步調(diào)用 LLM 時(shí)報(bào)錯(cuò)第一步應(yīng)該檢查網(wǎng)絡(luò)或 API 服務(wù)配置如果返回的不是合法 JSON優(yōu)先調(diào)整提示詞中的輸出格式要求或更換對(duì) JSON 支持更好的模型。第四步如果校驗(yàn)失敗不要直接修改 LLM 的 prompt 讓它“再試一次”而是先人工確認(rèn) LLM 輸出的函數(shù)名是否真的存在——有時(shí)候是 LLM 幻覺(jué)有時(shí)候是符號(hào)表本身漏掉了通過(guò)裝飾器或動(dòng)態(tài)方式注冊(cè)的函數(shù)。一次完整的效果驗(yàn)證建議覆蓋下面四個(gè)指標(biāo)符號(hào)提取準(zhǔn)確率抽樣比對(duì)函數(shù)名和行號(hào)目標(biāo) 100%。調(diào)用圖覆蓋率選擇 5 個(gè)核心函數(shù)人工確認(rèn)調(diào)用關(guān)系是否完整。LLM 結(jié)果可復(fù)核性影響分析結(jié)果中的每個(gè)函數(shù)都能在調(diào)用圖中找到路徑。結(jié)論可解釋性LLM 輸出的推理依據(jù)工程師能看懂且認(rèn)可。這四個(gè)指標(biāo)不要求一次滿分但可以作為每一次迭代的驗(yàn)收標(biāo)準(zhǔn)。8. 常見(jiàn)問(wèn)題與排查思路問(wèn)題現(xiàn)象可能原因排查方式解決方案tree-sitter 解析失敗語(yǔ)言 grammar 未正確加載檢查 grammar 文件版本和加載路徑重新編譯 grammar或升級(jí) tree-sitter符號(hào)表行號(hào)與 IDE 不一致解析器版本與代碼格式不兼容抽查 10 個(gè)函數(shù)比對(duì)行號(hào)確認(rèn)解析器使用的語(yǔ)言版本必要時(shí)調(diào)整解析參數(shù)LLM 輸出不是合法 JSON模型對(duì)輸出格式約束不敏感查看模型返回的原始內(nèi)容改用支持 JSON mode 的模型或在 prompt 中給出更嚴(yán)格的 schema 示例影響分析遺漏關(guān)鍵模塊語(yǔ)義標(biāo)注不完整或調(diào)用圖存在動(dòng)態(tài)調(diào)用漏洞人工檢查遺漏模塊是否在調(diào)用圖中有邊增加人工語(yǔ)義標(biāo)注或補(bǔ)充動(dòng)態(tài)調(diào)用場(chǎng)景的規(guī)則分析結(jié)果包含不存在的函數(shù)名LLM 幻覺(jué)校驗(yàn)層如何攔截查看校驗(yàn)日志增加符號(hào)表校驗(yàn)必要時(shí)對(duì)幻覺(jué)名稱做二次確認(rèn)記憶文檔過(guò)大項(xiàng)目規(guī)模增長(zhǎng)Markdown 全量加載檢查模塊地圖文件大小按模塊拆分文件分析時(shí)按需加載相關(guān)模塊記憶每次分析都重新構(gòu)建全量記憶沒(méi)有增量更新機(jī)制檢查構(gòu)建流程是否全量重跑基于 Git diff 做增量更新只重建變更模塊代碼上傳第三方 API 存在合規(guī)風(fēng)險(xiǎn)數(shù)據(jù)脫敏不足或使用外部云模型檢查發(fā)送給 API 的 prompt 內(nèi)容優(yōu)先使用私有化部署模型脫敏敏感字段或嚴(yán)格按合規(guī)流程審批這其中的“LLM 幻覺(jué)”問(wèn)題是最值得強(qiáng)調(diào)的。程序分析里不能接受“大概”“可能”的結(jié)論所以校驗(yàn)層不是可選項(xiàng)而是必需項(xiàng)。凡是沒(méi)有符號(hào)表支撐的結(jié)論一律標(biāo)記為“待確認(rèn)”而不是直接采納。9. 最佳實(shí)踐與工程邊界9.1 把記憶文檔納入版本管理建議在項(xiàng)目倉(cāng)庫(kù)或獨(dú)立文檔倉(cāng)庫(kù)中專門建立一個(gè)memory/目錄存放模塊地圖、符號(hào)表 JSON、語(yǔ)義標(biāo)注 Markdown。每次代碼變更后有增量任務(wù)重建相關(guān)模塊的記憶并把變更記錄提交到 Git。這樣團(tuán)隊(duì)的每個(gè)人都能 diff 記憶的變化及時(shí)發(fā)現(xiàn)記憶與代碼脫節(jié)的情況。9.2 建立“人工審核”的最終防線LLM 生成的語(yǔ)義標(biāo)注、影響分析結(jié)論在寫入記憶層之前必須經(jīng)過(guò)至少一名熟悉項(xiàng)目的工程師確認(rèn)。實(shí)踐中可以約定自動(dòng)生成的內(nèi)容標(biāo)為draftreview 通過(guò)后改為approved。分析層優(yōu)先使用approved狀態(tài)的記憶draft狀態(tài)只能作為參考。9.3 先小后大用真實(shí)項(xiàng)目迭代第一版不要追求覆蓋所有語(yǔ)言、所有動(dòng)態(tài)特性。先選一種語(yǔ)言比如 Python 或 Java選一個(gè)模塊把符號(hào)提取、調(diào)用圖、模塊地圖、LLM 分析這一條鏈路跑通。跑通后再擴(kuò)展語(yǔ)言支持、增加動(dòng)態(tài)調(diào)用處理、優(yōu)化增量構(gòu)建。這個(gè)路徑看起來(lái)慢實(shí)際是最快的——因?yàn)槊恳徊蕉寄鼙或?yàn)證不會(huì)在錯(cuò)誤的基礎(chǔ)上越走越偏。9.4 區(qū)分“事實(shí)”和“推斷”寫入不同的記憶層記憶層里可以再分成兩個(gè)子區(qū)facts/和inferences/。facts/存放符號(hào)表、調(diào)用圖、文件結(jié)構(gòu)由工具生成保證正確inferences/存放 LLM 和人工產(chǎn)出的語(yǔ)義標(biāo)注帶置信度、審核狀態(tài)、創(chuàng)建時(shí)間。分析時(shí)先把兩份記憶都加載給模型但在 prompt 中明確標(biāo)注哪些是確定性事實(shí)、哪些是推斷模型就能更合理地權(quán)衡信息權(quán)重。9.5 數(shù)據(jù)安全與合規(guī)邊界如果代碼庫(kù)涉及未公開的商業(yè)邏輯、生產(chǎn)環(huán)境配置、用戶數(shù)據(jù)相關(guān)代碼直接把完整代碼或模塊地圖發(fā)送給外部 LLM API存在合規(guī)風(fēng)險(xiǎn)。更穩(wěn)妥的做法有三種優(yōu)先使用私有化部署的開源模型例如在本地或內(nèi)網(wǎng) GPU 服務(wù)器運(yùn)行。如果必須使用外部 API需要先做敏感信息脫敏并經(jīng)過(guò)數(shù)據(jù)安全審批。代碼摘要、函數(shù)名、調(diào)用關(guān)系等元數(shù)據(jù)可能比源碼本身更敏感在發(fā)送前也要評(píng)估。在合規(guī)這一點(diǎn)上技術(shù)方案做得再好也無(wú)法替代制度和流程上的把關(guān)。9.6 不要用 LLM 替代所有傳統(tǒng)靜態(tài)分析明確 Lemmalog 的邊界它適合做“語(yǔ)義關(guān)聯(lián)分析”比如變更影響、模塊職責(zé)梳理、代碼為何這樣寫的解釋性問(wèn)答。但是在需要窮舉可達(dá)路徑、數(shù)據(jù)流精確分析、安全漏洞模式匹配的場(chǎng)景傳統(tǒng)靜態(tài)分析工具如 CodeQL、Soot、SpotBugs仍然是不可替代的。更合理的策略是混用CodeQL 負(fù)責(zé)精確的污點(diǎn)分析Lemmalog 負(fù)責(zé)解釋“污染的根源在哪里、為什么這里會(huì)成為入口”。工具之間互補(bǔ)而不是互相取代。9.7 建立增量更新機(jī)制代碼倉(cāng)庫(kù)每天都在變?nèi)绻看畏治龆贾亟ㄈ坑洃洸粌H慢還會(huì)產(chǎn)生大量噪聲。增量更新的思路是監(jiān)聽 Git 提交記錄或文件變更事件。對(duì)變更文件重新提取符號(hào)并更新模塊地圖對(duì)應(yīng)段落。只重建受影響模塊的語(yǔ)義標(biāo)注推薦使用 LLM 對(duì)比舊標(biāo)注和變更 diff判斷是否需要修改。增量更新能顯著降低使用成本也讓“記憶庫(kù)”保持新鮮。沒(méi)有增量機(jī)制的 Lemmalog本質(zhì)上還是實(shí)驗(yàn)玩具很難進(jìn)入日常開發(fā)流程。10. 邊界與風(fēng)險(xiǎn)LLM 程序分析不等于自動(dòng)駕駛這一部分非常重要。很多團(tuán)隊(duì)看到“LLM 做程序分析”就興奮以為以后可以不用看代碼了。這是一個(gè)危險(xiǎn)的想法。LLM 擅長(zhǎng)的是模式識(shí)別和語(yǔ)言關(guān)聯(lián)它不是在“驗(yàn)證”程序性質(zhì)而是在“猜測(cè)”一段代碼可能的行為。只有當(dāng)它被約束在正確的、足夠細(xì)粒度的事實(shí)之上它的猜測(cè)才有價(jià)值。所以 Lemmalog 的定位是“輔助分析工具”不是“自動(dòng)決策系統(tǒng)”。以下幾點(diǎn)需要反復(fù)強(qiáng)調(diào)調(diào)用圖是靜態(tài)識(shí)別的不是必然路徑。函數(shù) A 調(diào)用了 B不代表 A 的所有調(diào)用路徑都會(huì)執(zhí)行到 B。LLM 的置信度不等同于正確率。模型可能用一種非常自信的語(yǔ)氣說(shuō)出一個(gè)完全錯(cuò)誤的結(jié)論。人工審查是最終防線。任何影響線上系統(tǒng)的變更評(píng)估都必須有人類工程師簽字負(fù)責(zé)。記憶庫(kù)也會(huì)有偏差。代碼更新了但記憶沒(méi)更新LLM 就會(huì)基于過(guò)時(shí)信息做判斷。一個(gè)合格的落地方式是讓 Lemmalog 輸出帶證據(jù)鏈的分析報(bào)告報(bào)告中每個(gè)關(guān)鍵結(jié)論都附上“對(duì)應(yīng)的函數(shù)名、行號(hào)、調(diào)用圖路徑”工程師可以順著證據(jù)鏈快速核對(duì)。沒(méi)有證據(jù)鏈的結(jié)論默認(rèn)不可信。11. 總結(jié)與下一步實(shí)踐Lemmalog 這個(gè)項(xiàng)目的核心價(jià)值不是發(fā)明了一種新的程序分析算法而是重新組織了一整套工作流用確定性工具保障程序事實(shí)的正確性用 LLM 補(bǔ)足業(yè)務(wù)語(yǔ)義推理能力用記憶層把一次性的分析沉淀成可復(fù)用的資產(chǎn)。如果你也想在自己的項(xiàng)目里嘗試這條路線我的建議是從下面四步開始選一個(gè)自己熟悉的、規(guī)模不大的代碼庫(kù)。用 tree-sitter 或其他解析器生成準(zhǔn)確的符號(hào)表和模塊地圖。用今天給出的示例代碼跑通一次“變更影響分析”的 demo。人工核驗(yàn)分析結(jié)果記錄失敗案例逐步增加語(yǔ)義標(biāo)注和程序化校驗(yàn)規(guī)則完善校驗(yàn)層。這期間你會(huì)遇到很多看起來(lái)很麻煩的細(xì)節(jié)動(dòng)態(tài)調(diào)用怎么識(shí)別、語(yǔ)義標(biāo)注誰(shuí)來(lái)寫、增量構(gòu)建怎么設(shè)計(jì)、幻覺(jué)怎么攔截。但這些細(xì)節(jié)恰恰是 Lemmalog 的價(jià)值所在——不是模型本身多強(qiáng)而是我們把“讓 LLM 可靠地工作”這件事認(rèn)真對(duì)待了。程序分析的未來(lái)大概率不是哪個(gè)工具單獨(dú)勝出而是靜態(tài)分析、LLM、人工 review 三者各司其職。Lemmalog 只是這個(gè)方向的一個(gè)早期實(shí)踐。如果你也在這個(gè)方向上有想法不妨從一個(gè)最小的模塊地圖開始把記憶層建起來(lái)之后再逐步擴(kuò)展。代碼會(huì)變業(yè)務(wù)會(huì)變但一套能夠隨代碼演進(jìn)、持續(xù)積累語(yǔ)義的程序分析記憶系統(tǒng)會(huì)成為整個(gè)研發(fā)團(tuán)隊(duì)真正的長(zhǎng)期資產(chǎn)。