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