这次我们来看一个偏工程、也偏方法论的项目Lemmalog。从名字拆开看Lemma 是程序分析里的“引理”Log 是“日志”。合在一起Lemmalog 想做的事情很明确——把 LLM 在分析代码时产生的中间结论、记忆片段、验证结果统一沉淀成结构化的“引理日志”再用程序分析的方式去检查、复用和审计。换句话说它不是在做一个聊天机器人外壳而是试图把 LLM 的隐式记忆变成显式的、可查询的、可验证的分析数据。这个项目最值得关注的几个点第一它把“LLM 会忘事”这个痛点转化成工程问题让多轮分析的结果可以跨会话复用第二它借用了程序分析里“引理—证明—依赖”的思路给 LLM 输出增加了审计维度第三它符合当前 LLM Wiki 这类纯文本知识组织范式的方向分析结论直接落盘成 Markdown 或 JSON方便二次处理和团队共享。本文会从一个可落地的角度展开先讲 Lemmalog 的核心能力再看它适合放在什么场景里然后给出一套通用的部署、启动、测试、接口调用和批量分析流程。如果你关心 LLM Agent 怎么写才不丢上下文、代码分析结论怎么沉淀成知识库或者想把 LLM 输出变成可复核的分析报告这篇文章可以直接看到底。1. Lemmalog 核心能力速览先给一张规格表方便快速判断这个项目值不值得继续看。需要说明的是Lemmalog 目前公开可查的细节不算多下面这张表基于项目命名和同类 LLM 记忆管理方案推导具体能力要以你拿到的仓库 README 和实际运行版本为准。能力项说明项目类型LLM 记忆管理 程序分析方法论包含命令行工具和本地服务形态核心思想把 LLM 分析代码过程中的记忆片段沉淀为带依赖、带证据、带验证状态的“引理日志”主要功能代码分析记录、跨会话记忆复用、结论与代码位置绑定、结果审计、批量文件分析运行模式CLI 命令 / 本地 HTTP 服务 / 可接入自己的 Agent 链路LLM 接入取决于实现可接云端 API 模型也可接 Ollama、vLLM 等本地推理服务显存要求纯 API 模式下无显存压力本地模型取决于模型体积需要按实际环境测试批量任务支持按目录批量分析建议配合并发控制、日志和失败重试机制输出格式结构化 JSON / Markdown适合进 Git 做版本管理适合人群LLM Agent 开发者、程序分析研究人员、代码审计工程师、知识库维护者一句话总结Lemmalog 不是要替代静态分析工具它更像是 LLM 和程序分析工具之间的一层“记忆持久化和审计层”。2. 适用场景与使用边界2.1 适合做什么从实际工程角度看Lemmalog 最合适的场景有三类。第一类是代码审计。让 LLM 逐个函数、逐个文件分析把中间结论记录下来。普通聊天式分析的问题在于上下文一长模型会忘记前面到底判断了什么。Lemmalog 的方式是每分析完一段代码就把结论写进引理日志。后面再分析其他文件时可以直接引用之前的结论形成一条完整的分析链。第二类是 Agent 记忆管理。现在的 LLM Agent 在做工具调用、代码检索、多文件修改时经常会出现“前面说好的事后面忘了”的情况。Lemmalog 相当于给 Agent 加了一个外部记忆系统所有关键判断都落盘到结构化日志里Agent 下一步决策时可以读取这些日志作为输入而不是只依赖上下文窗口。第三类是知识库沉淀。把程序分析结论写成 Markdown 或 JSON 后可以直接放进团队知识库或者用 Obsidian 这类工具做二次整理。这跟 Karpathy 提出的 LLM Wiki 范式方向一致用纯文本、可读、可修改的文件组织知识让 LLM 和人都能维护同一份资料。2.2 不适合做什么Lemmalog 不适合替代形式化验证工具。LLM 输出的结论本质上仍是概率性内容即使有引理日志和验证字段也不能当作严格的程序证明。生产环境里的安全关键代码该用 CodeQL、Semgrep、形式化验证工具做检查的还是要用这些工具。它也不适合直接拿来处理高度敏感的代码。如果必须用 Lemmalog 分析未脱敏的商业代码、个人隐私数据建议优先接本地模型避免把代码内容发送到第三方 API 服务。2.3 合规与安全边界涉及代码分析、LLM 记忆存储有几点必须注意确认有权限分析对应代码尤其是他人开源或者公司内部的代码。使用云端 LLM API 时明确供应商是否有数据留存政策。涉及人脸、声音、个人隐私或商业机密的场景先脱敏再上传。分析结果如果用于发布或商用需要对 LLM 输出做人工复核。3. 为什么需要“LLM 记忆变成程序分析”3.1 LLM 做代码分析时最大的问题用 LLM 做代码分析最头疼的不是模型看不懂代码而是“分析到后面前面就忘了”。上下文窗口虽然有几十万甚至上百万 token但真正复杂项目的代码量远超窗口上限。你让 LLM 分析一个仓库它只能分文件、分模块读。读完文件 A 的结论在分析文件 B 时不一定能稳定记住多轮对话里用户补充了一个规则模型可能在下一次回答里就漏掉了。这种“记忆漂移”会让分析结果前后矛盾而且你很难定位矛盾出现在哪一步。更麻烦的是聊天式分析没有任何审计记录。你只知道模型给出了一个结论但不知道它依据的是哪个函数、哪一行代码也不知道这个结论是否被后续分析修正过。3.2 程序分析里可借鉴的成熟思路传统程序分析是怎么解决这个问题的编译器前端把源码转成抽象语法树语义分析阶段维护符号表数据流分析阶段记录每个变量的定义和使用点。每一步都有明确的输入、输出和中间表示任何结论都可以沿着依赖链追溯回去。其中最有价值的概念就是“程序验证”里的 Lemma。一个引理是一个已经证明的中间结论它依赖于一组前提后面的大定理建立在引理之上。一旦引理出错整个证明链都会有问题所以引理必须被记录、被检查、被复用。Lemmalog 就是想把这个机制搬进 LLM模型每次给出一个代码分析结论就把它当成一个候选 Lemma记录结论内容、证据位置、依赖关系、验证状态。这样以后不管谁来接续分析都能先查引理库而不是让模型重新读一遍代码。3.3 Lemmalog 的工作方式从设计思路上拆解Lemmalog 把一个完整的代码分析过程拆成五个阶段观察LLM 读取代码文件生成初步分析。假设模型给出对某个函数或变量的判断。引理将这个判断转换成结构化条目绑定文件名、函数名、代码行号。证据记录模型声称的依据比如“第 12 行处理了空字符串分支”。验证用静态分析工具、测试用例或人工复核给这个引理打上 verified 或 unverified 标记。这个流程看起来不复杂但价值在于从“聊完就忘”变成了“每条结论都有档案”。模型在解决复杂问题时的记忆不再是隐藏在权重和上下文窗口里的黑盒而是可以被程序追查的数据结构。4. 环境准备与前置条件如果你准备在自己的机器上跑一套 Lemmalog先从环境检查开始。下面是一份通用清单具体版本要求以项目文档为准。4.1 基础环境项目建议配置说明操作系统Linux / macOS / Windows WSL2工具链多在 Unix 环境更容易跑通Python3.10 或更高如果项目以 Python 实现为主Node.js18 或更高如果项目提供前端或 npm 包Git任意较新版本用于克隆代码仓库磁盘空间至少 5GB依赖安装和本地模型文件网络可访问 LLM API 或内网推理服务本地模型也要先下载模型文件4.2 LLM 推理服务Lemmalog 本身不承担推理能力它依赖一个可调用的 LLM。两条路线API 模式OpenAI、Anthropic、国内大模型服务都可以只要兼容 OpenAI Chat Completions 格式就能接。本地模式Ollama、vLLM、llama.cpp 都行。建议模型至少 7B 以上太小的话代码理解能力会明显下降。4.3 端口检查启动本地 HTTP 服务时先确认计划使用的端口没有被占用。常见冲突端口包括 8080、8000、7860、3000。# Linux / macOS lsof -i :8080 # Windows PowerShell netstat -ano | findstr :8080如果端口被占用启动参数里改掉即可不用纠结具体端口号。5. 安装部署与启动方式由于 Lemmalog 的仓库结构还没法确定具体细节下面给出一套通用安装模板。实际操作时把命令里的路径、项目名替换成你拿到的仓库信息。5.1 拉取代码并安装git clone lemmalog-repo-url cd lemmalog python -m venv .venv source .venv/bin/activate pip install -r requirements.txt如果项目已经发布到 PyPI 或 npm也可以直接安装pip install lemmalog # 或者 npm install -g lemmalog5.2 编写配置文件建议在项目根目录放一份lemmalog.yaml把 LLM 服务和分析路径集中管理。下面是通用模板字段名需要按实际实现调整。# lemmalog.yaml workspace: ./lemmas llm: provider: openai model: gpt-4o-mini base_url: https://api.openai.com/v1 api_key_env: LLM_API_KEY analysis: input_dir: ./src output_dir: ./out language: python batch_size: 5 max_retries: 2注意api_key_env的意思是密钥从环境变量LLM_API_KEY读取而不是直接写在配置文件里避免不小心提交到 Git。5.3 命令行启动# 单文件分析 lemmalog analyze --input ./src/parser.py --output ./lemmas # 目录批量分析 lemmalog batch --input ./src --output ./lemmas --workers 45.4 启动本地 HTTP 服务如果你希望把 Lemmalog 接入自己的工具链可以启动服务模式lemmalog serve --host 127.0.0.1 --port 8080启动后访问http://127.0.0.1:8080如果项目带 WebUI能看到一个简单的管理页面如果只有 API直接按接口文档请求即可。6. Lemmalog 核心概念与输出结构要把“LLM 记忆变成程序分析”核心是设计好引理日志的数据结构。下面是一个参考设计可以直接作为 Lemmalog 输出格式的理解基础。{ lemma_id: lemma-001, file: src/parser.py, function: parse_line, conclusion: parse_line 在空字符串输入时返回 None, confidence: 0.85, evidence: [ 第 12 行检查了空字符串分支, 第 15 行返回 None ], dependencies: [ parser.read_token ], verified: false, created_at: 2025-01-01T10:00:00Z }这个结构里最关键的是三块conclusion模型给出的结论必须可验证不能是模糊的“这段代码看起来有问题”。evidence模型判断的依据指向具体代码位置。dependencies这个结论依赖了哪些其他结论形成一张依赖图。有了这张依赖图后续就能做矛盾检测。如果两个引理在同一函数上给出相反结论系统可以自动标红提示需要人工复核。7. 功能测试与效果验证跑通安装只是第一步关键是验证“LLM 记忆真的变成了可查询的程序分析结果”。下面给出一套测试方案你可以在自己的环境里照着跑。7.1 测试一单文件分析测试目的确认 Lemmalog 能对一个代码文件生成结构化引理日志。准备一个简单 Python 文件sample.pydef divide(a, b): if b 0: return None return a / b def parse_int(text): try: return int(text) except ValueError: return None执行lemmalog analyze --input ./sample.py --output ./lemmas预期结果./lemmas目录下生成一个 JSON 或 Markdown 文件divide和parse_int各有一个引理条目。每个条目包含evidence和confidence字段。判断标准如果文件里只有结论、没有证据说明解析链路没通优先检查 LLM 输出的结构化格式是否符合预期。7.2 测试二跨会话记忆复用测试目的确认第二次分析能引用之前保存的记忆。先执行一次分析记录下parse_int的lemma_id。然后新开一个会话只问“之前分析过 parse_int 吗它的结论是什么”如果 Lemmalog 的设计生效系统应该先从引理库检索到对应条目而不是重新调用 LLM 读一遍代码。判断标准返回内容能关联到lemma_id和原始代码位置。如果查不到检查引理库路径是否配置正确以及检索逻辑是否覆盖到了该目录。7.3 测试三矛盾检测测试目的验证系统能否暴露 LLM 分析的矛盾。你可以用两种不同的 prompt 让 LLM 分析同一个文件比如一次让模型只关注边界条件一次让模型整体判断。两个结果如果对同一个函数给出相反结论Lemmalog 应该能把它们标记为“冲突引理”。判断标准日志中能看到冲突标记提示需要人工复核。没有这个功能的话就要靠人工去 diff 多份引理文件效率会低很多。7.4 测试四与静态工具交叉验证测试目的用传统程序分析工具校验 LLM 结论。# 用 pyflakes 检查语法和未使用变量 pyflakes sample.py # 用 semgrep 检查指定规则 semgrep scan --config auto sample.py对比 pyflakes、semgrep 的输出和 Lemmalog 的引理日志看两类工具是否发现了同一批问题以及结果是否互相印证。判断标准重合度越高说明 LLM 的分析结果越可信。差异大的地方需要单独看是 LLM 幻觉还是静态工具的规则覆盖不全。7.5 测试五批量任务测试目的验证批量分析多个文件的稳定性。lemmalog batch --input ./src --output ./lemmas --workers 4预期结果所有文件都被处理每个文件生成独立的引理条目workers参数控制并发数。失败排查重点批量任务中途卡住往往是因为某个文件触发了 LLM 的错误输出或者 API 限流。先看日志里有没有失败重试记录再确认max_retries配置是否生效。8. 接口 API 与批量任务接入如果 Lemmalog 以服务方式运行业务系统可以通过 HTTP 接口调用。这里给出一个通用调用模板你可以按实际项目接口路径调整。8.1 发起单文件分析请求import requests import os url http://127.0.0.1:8080/api/analyze payload { file: src/parser.py, language: python, save_lemma: True } r requests.post( url, jsonpayload, timeout300, headers{Authorization: fBearer {os.environ.get(LEMMALOG_TOKEN)}} ) print(r.status_code) print(r.json())如果请求正常返回值里一般包含lemma_id、conclusion、evidence和verified字段。如果项目没有做鉴权可以不用带 Authorization 头但上线部署时建议开启。8.2 批量任务设计批量分析不能简单理解为“循环调用接口”。更稳妥的方式是设计一个任务队列# 先生成待分析文件列表 find ./src -name *.py filelist.txt # 再逐批提交每批 20 个文件 lemmalog batch --input filelist.txt --output ./lemmas --batch-size 20有条件的话把任务丢进 Redis 队列或数据库任务表用 Worker 并发消费。每个任务记录开始时间、结束时间、重试次数、最终状态这样即使中途失败也能断点续跑。8.3 失败重试建议超时类的错误直接重试间隔指数退避比如 2 秒、4 秒、8 秒。LLM 输出格式错误的重试时换一个更明确的 prompt 模板。模型上下文溢出导致的失败要把输入文件拆小或者切到更大上下文的模型。9. 资源占用与性能观察9.1 API 模式API 模式下Lemmalog 的本地资源占用很低主要瓶颈在 LLM 服务的延迟和 token 消耗。观察指标单文件请求耗时。单文件消耗的 prompt token 和 completion token。引理日志文件增长速度。如果发现 token 消耗暴涨先检查是不是每次分析都把整个文件完整塞进 prompt。对于大文件应该只截取相关函数片段。9.2 本地模型模式本地模型的资源占用要重点看显存。# 持续观察显存占用 watch -n 1 nvidia-smi影响显存的主要因素模型参数量。量化精度比如 4bit 量化比 16bit 省显存。生成时的最大补全长度。并发请求数量。没有统一的显存标准因为模型版本和推理框架不同占用差异很大。第一次跑的时候把 batch size 和并发数调到最小先看单请求占用的峰值显存再逐步调大。9.3 日志增长与清理引理日志是增量落盘的长时间运行后会产生大量冗余条目。建议定期做两层清理删除测试过程中产生的低置信度条目。对同函数、同结论的重复条目做合并只保留最新一次验证状态。10. 常见问题与排查方法问题现象可能原因排查方式解决方案安装依赖失败Python 版本不匹配或网络问题查看报错信息检查 pip 源切换 Python 版本换镜像源重装启动后页面打不开端口被占用或服务未启动查看服务日志检查端口监听状态换端口或重启服务analyze 后没有生成引理解析 LLM 输出失败查看原始模型输出和日志调整 prompt 约束 JSON 格式增加重试引理库检索不到历史记录workspace 路径配置错误检查配置文件中的 workspace 目录修正路径确认 lemma_id 唯一API 请求长时间无响应模型服务过载或网络问题用 curl 单独测 LLM 接口延迟拉长 timeout降低并发批量任务中途卡死某个文件触发了异常输出查看任务日志定位具体文件跳过该文件或拆分输入本地模型显存不足模型过大或并发过高观察 nvidia-smi 的显存使用率换量化版本降低 batch 和并发结论互相矛盾模型在不同会话中理解偏差查看引理依赖链增加验证步骤人工复核或静态工具交叉检查11. 最佳实践与使用建议想把 Lemmalog 用到真正的项目中建议从下面几个习惯开始。先小后大。第一次只拿一个文件、一条函数跑通全流程确认输出格式、日志目录、API 调用都正常再扩展到整个仓库。不要一开始就批量分析几千个文件失败后排查成本会很高。每个引理必须绑定代码位置。没有file、function、line字段的结论没有任何追溯价值。拿到 LLM 输出后如果发现它没有给出具体行号宁可让它重新分析也不要容纳模糊结论。置信度要设阈值。LLM 的 confidence 字段不能只做展示应该参与流程控制。低于阈值的引理自动标记为“待复核”不进入最终结论。批量任务必须有日志。每个文件、每次重试、每次失败原因都要有记录。没有日志的批量任务等于在盲跑。敏感代码尽量走本地模型。如果分析对象是未公开的商业代码优先接 Ollama 或 vLLM数据不出内网。使用第三方 API 之前先确认协议里有没有数据留存条款。引理库要进 Git。这样每次修改都有历史版本谁改了什么、结论何时被验证过全部可追踪。Git 的 diff 功能本身就是一种审计手段。最后一件事是人工复核。LLM 的分析水平再高也不能完全替代人的判断。关键结论至少要过一遍代码评审再决定是否进入技术报告或安全工单。12. 总结与下一步Lemmalog 这个项目最值得关注的地方不是某个具体的 API 或模型而是它提供了一种思路把 LLM 会遗忘、会漂移的记忆改造成程序分析意义上的“引理库”。一旦分析结论变成可追溯、可验证、可复用的结构化数据LLM 就能从“聊天分析”升级成“带审计记录的工程分析工具”。如果你准备上手最先要验证的是两件事单文件分析能否生成包含证据的引理日志以及第二次会话能否正确引用之前的分析结果。这两个能力跑通Lemmalog 的核心价值就已经体现出来了。最容易踩的坑也很明确LLM 输出格式不稳定导致引理解析失败。对策是提前设计好 JSON 输出模板并把重试逻辑和格式校验写进流程不能指望模型每次都乖乖返回标准结构。下一步可以做的扩展方向很多对接 Semgrep、CodeQL 这类传统程序分析工具做自动校验把引理库接入向量检索按语义搜索历史分析结论甚至可以做成 VS Code 插件让开发者在编辑器里直接查看 LLM 对当前函数的历史判断。这套“LLM 引理日志 程序分析”的组合未来会成为代码分析工具链里值得重视的一环。
Lemmalog实战：用引理日志实现可审计的LLM代码分析记忆
这次我们来看一个偏工程、也偏方法论的项目Lemmalog。从名字拆开看Lemma 是程序分析里的“引理”Log 是“日志”。合在一起Lemmalog 想做的事情很明确——把 LLM 在分析代码时产生的中间结论、记忆片段、验证结果统一沉淀成结构化的“引理日志”再用程序分析的方式去检查、复用和审计。换句话说它不是在做一个聊天机器人外壳而是试图把 LLM 的隐式记忆变成显式的、可查询的、可验证的分析数据。这个项目最值得关注的几个点第一它把“LLM 会忘事”这个痛点转化成工程问题让多轮分析的结果可以跨会话复用第二它借用了程序分析里“引理—证明—依赖”的思路给 LLM 输出增加了审计维度第三它符合当前 LLM Wiki 这类纯文本知识组织范式的方向分析结论直接落盘成 Markdown 或 JSON方便二次处理和团队共享。本文会从一个可落地的角度展开先讲 Lemmalog 的核心能力再看它适合放在什么场景里然后给出一套通用的部署、启动、测试、接口调用和批量分析流程。如果你关心 LLM Agent 怎么写才不丢上下文、代码分析结论怎么沉淀成知识库或者想把 LLM 输出变成可复核的分析报告这篇文章可以直接看到底。1. Lemmalog 核心能力速览先给一张规格表方便快速判断这个项目值不值得继续看。需要说明的是Lemmalog 目前公开可查的细节不算多下面这张表基于项目命名和同类 LLM 记忆管理方案推导具体能力要以你拿到的仓库 README 和实际运行版本为准。能力项说明项目类型LLM 记忆管理 程序分析方法论包含命令行工具和本地服务形态核心思想把 LLM 分析代码过程中的记忆片段沉淀为带依赖、带证据、带验证状态的“引理日志”主要功能代码分析记录、跨会话记忆复用、结论与代码位置绑定、结果审计、批量文件分析运行模式CLI 命令 / 本地 HTTP 服务 / 可接入自己的 Agent 链路LLM 接入取决于实现可接云端 API 模型也可接 Ollama、vLLM 等本地推理服务显存要求纯 API 模式下无显存压力本地模型取决于模型体积需要按实际环境测试批量任务支持按目录批量分析建议配合并发控制、日志和失败重试机制输出格式结构化 JSON / Markdown适合进 Git 做版本管理适合人群LLM Agent 开发者、程序分析研究人员、代码审计工程师、知识库维护者一句话总结Lemmalog 不是要替代静态分析工具它更像是 LLM 和程序分析工具之间的一层“记忆持久化和审计层”。2. 适用场景与使用边界2.1 适合做什么从实际工程角度看Lemmalog 最合适的场景有三类。第一类是代码审计。让 LLM 逐个函数、逐个文件分析把中间结论记录下来。普通聊天式分析的问题在于上下文一长模型会忘记前面到底判断了什么。Lemmalog 的方式是每分析完一段代码就把结论写进引理日志。后面再分析其他文件时可以直接引用之前的结论形成一条完整的分析链。第二类是 Agent 记忆管理。现在的 LLM Agent 在做工具调用、代码检索、多文件修改时经常会出现“前面说好的事后面忘了”的情况。Lemmalog 相当于给 Agent 加了一个外部记忆系统所有关键判断都落盘到结构化日志里Agent 下一步决策时可以读取这些日志作为输入而不是只依赖上下文窗口。第三类是知识库沉淀。把程序分析结论写成 Markdown 或 JSON 后可以直接放进团队知识库或者用 Obsidian 这类工具做二次整理。这跟 Karpathy 提出的 LLM Wiki 范式方向一致用纯文本、可读、可修改的文件组织知识让 LLM 和人都能维护同一份资料。2.2 不适合做什么Lemmalog 不适合替代形式化验证工具。LLM 输出的结论本质上仍是概率性内容即使有引理日志和验证字段也不能当作严格的程序证明。生产环境里的安全关键代码该用 CodeQL、Semgrep、形式化验证工具做检查的还是要用这些工具。它也不适合直接拿来处理高度敏感的代码。如果必须用 Lemmalog 分析未脱敏的商业代码、个人隐私数据建议优先接本地模型避免把代码内容发送到第三方 API 服务。2.3 合规与安全边界涉及代码分析、LLM 记忆存储有几点必须注意确认有权限分析对应代码尤其是他人开源或者公司内部的代码。使用云端 LLM API 时明确供应商是否有数据留存政策。涉及人脸、声音、个人隐私或商业机密的场景先脱敏再上传。分析结果如果用于发布或商用需要对 LLM 输出做人工复核。3. 为什么需要“LLM 记忆变成程序分析”3.1 LLM 做代码分析时最大的问题用 LLM 做代码分析最头疼的不是模型看不懂代码而是“分析到后面前面就忘了”。上下文窗口虽然有几十万甚至上百万 token但真正复杂项目的代码量远超窗口上限。你让 LLM 分析一个仓库它只能分文件、分模块读。读完文件 A 的结论在分析文件 B 时不一定能稳定记住多轮对话里用户补充了一个规则模型可能在下一次回答里就漏掉了。这种“记忆漂移”会让分析结果前后矛盾而且你很难定位矛盾出现在哪一步。更麻烦的是聊天式分析没有任何审计记录。你只知道模型给出了一个结论但不知道它依据的是哪个函数、哪一行代码也不知道这个结论是否被后续分析修正过。3.2 程序分析里可借鉴的成熟思路传统程序分析是怎么解决这个问题的编译器前端把源码转成抽象语法树语义分析阶段维护符号表数据流分析阶段记录每个变量的定义和使用点。每一步都有明确的输入、输出和中间表示任何结论都可以沿着依赖链追溯回去。其中最有价值的概念就是“程序验证”里的 Lemma。一个引理是一个已经证明的中间结论它依赖于一组前提后面的大定理建立在引理之上。一旦引理出错整个证明链都会有问题所以引理必须被记录、被检查、被复用。Lemmalog 就是想把这个机制搬进 LLM模型每次给出一个代码分析结论就把它当成一个候选 Lemma记录结论内容、证据位置、依赖关系、验证状态。这样以后不管谁来接续分析都能先查引理库而不是让模型重新读一遍代码。3.3 Lemmalog 的工作方式从设计思路上拆解Lemmalog 把一个完整的代码分析过程拆成五个阶段观察LLM 读取代码文件生成初步分析。假设模型给出对某个函数或变量的判断。引理将这个判断转换成结构化条目绑定文件名、函数名、代码行号。证据记录模型声称的依据比如“第 12 行处理了空字符串分支”。验证用静态分析工具、测试用例或人工复核给这个引理打上 verified 或 unverified 标记。这个流程看起来不复杂但价值在于从“聊完就忘”变成了“每条结论都有档案”。模型在解决复杂问题时的记忆不再是隐藏在权重和上下文窗口里的黑盒而是可以被程序追查的数据结构。4. 环境准备与前置条件如果你准备在自己的机器上跑一套 Lemmalog先从环境检查开始。下面是一份通用清单具体版本要求以项目文档为准。4.1 基础环境项目建议配置说明操作系统Linux / macOS / Windows WSL2工具链多在 Unix 环境更容易跑通Python3.10 或更高如果项目以 Python 实现为主Node.js18 或更高如果项目提供前端或 npm 包Git任意较新版本用于克隆代码仓库磁盘空间至少 5GB依赖安装和本地模型文件网络可访问 LLM API 或内网推理服务本地模型也要先下载模型文件4.2 LLM 推理服务Lemmalog 本身不承担推理能力它依赖一个可调用的 LLM。两条路线API 模式OpenAI、Anthropic、国内大模型服务都可以只要兼容 OpenAI Chat Completions 格式就能接。本地模式Ollama、vLLM、llama.cpp 都行。建议模型至少 7B 以上太小的话代码理解能力会明显下降。4.3 端口检查启动本地 HTTP 服务时先确认计划使用的端口没有被占用。常见冲突端口包括 8080、8000、7860、3000。# Linux / macOS lsof -i :8080 # Windows PowerShell netstat -ano | findstr :8080如果端口被占用启动参数里改掉即可不用纠结具体端口号。5. 安装部署与启动方式由于 Lemmalog 的仓库结构还没法确定具体细节下面给出一套通用安装模板。实际操作时把命令里的路径、项目名替换成你拿到的仓库信息。5.1 拉取代码并安装git clone lemmalog-repo-url cd lemmalog python -m venv .venv source .venv/bin/activate pip install -r requirements.txt如果项目已经发布到 PyPI 或 npm也可以直接安装pip install lemmalog # 或者 npm install -g lemmalog5.2 编写配置文件建议在项目根目录放一份lemmalog.yaml把 LLM 服务和分析路径集中管理。下面是通用模板字段名需要按实际实现调整。# lemmalog.yaml workspace: ./lemmas llm: provider: openai model: gpt-4o-mini base_url: https://api.openai.com/v1 api_key_env: LLM_API_KEY analysis: input_dir: ./src output_dir: ./out language: python batch_size: 5 max_retries: 2注意api_key_env的意思是密钥从环境变量LLM_API_KEY读取而不是直接写在配置文件里避免不小心提交到 Git。5.3 命令行启动# 单文件分析 lemmalog analyze --input ./src/parser.py --output ./lemmas # 目录批量分析 lemmalog batch --input ./src --output ./lemmas --workers 45.4 启动本地 HTTP 服务如果你希望把 Lemmalog 接入自己的工具链可以启动服务模式lemmalog serve --host 127.0.0.1 --port 8080启动后访问http://127.0.0.1:8080如果项目带 WebUI能看到一个简单的管理页面如果只有 API直接按接口文档请求即可。6. Lemmalog 核心概念与输出结构要把“LLM 记忆变成程序分析”核心是设计好引理日志的数据结构。下面是一个参考设计可以直接作为 Lemmalog 输出格式的理解基础。{ lemma_id: lemma-001, file: src/parser.py, function: parse_line, conclusion: parse_line 在空字符串输入时返回 None, confidence: 0.85, evidence: [ 第 12 行检查了空字符串分支, 第 15 行返回 None ], dependencies: [ parser.read_token ], verified: false, created_at: 2025-01-01T10:00:00Z }这个结构里最关键的是三块conclusion模型给出的结论必须可验证不能是模糊的“这段代码看起来有问题”。evidence模型判断的依据指向具体代码位置。dependencies这个结论依赖了哪些其他结论形成一张依赖图。有了这张依赖图后续就能做矛盾检测。如果两个引理在同一函数上给出相反结论系统可以自动标红提示需要人工复核。7. 功能测试与效果验证跑通安装只是第一步关键是验证“LLM 记忆真的变成了可查询的程序分析结果”。下面给出一套测试方案你可以在自己的环境里照着跑。7.1 测试一单文件分析测试目的确认 Lemmalog 能对一个代码文件生成结构化引理日志。准备一个简单 Python 文件sample.pydef divide(a, b): if b 0: return None return a / b def parse_int(text): try: return int(text) except ValueError: return None执行lemmalog analyze --input ./sample.py --output ./lemmas预期结果./lemmas目录下生成一个 JSON 或 Markdown 文件divide和parse_int各有一个引理条目。每个条目包含evidence和confidence字段。判断标准如果文件里只有结论、没有证据说明解析链路没通优先检查 LLM 输出的结构化格式是否符合预期。7.2 测试二跨会话记忆复用测试目的确认第二次分析能引用之前保存的记忆。先执行一次分析记录下parse_int的lemma_id。然后新开一个会话只问“之前分析过 parse_int 吗它的结论是什么”如果 Lemmalog 的设计生效系统应该先从引理库检索到对应条目而不是重新调用 LLM 读一遍代码。判断标准返回内容能关联到lemma_id和原始代码位置。如果查不到检查引理库路径是否配置正确以及检索逻辑是否覆盖到了该目录。7.3 测试三矛盾检测测试目的验证系统能否暴露 LLM 分析的矛盾。你可以用两种不同的 prompt 让 LLM 分析同一个文件比如一次让模型只关注边界条件一次让模型整体判断。两个结果如果对同一个函数给出相反结论Lemmalog 应该能把它们标记为“冲突引理”。判断标准日志中能看到冲突标记提示需要人工复核。没有这个功能的话就要靠人工去 diff 多份引理文件效率会低很多。7.4 测试四与静态工具交叉验证测试目的用传统程序分析工具校验 LLM 结论。# 用 pyflakes 检查语法和未使用变量 pyflakes sample.py # 用 semgrep 检查指定规则 semgrep scan --config auto sample.py对比 pyflakes、semgrep 的输出和 Lemmalog 的引理日志看两类工具是否发现了同一批问题以及结果是否互相印证。判断标准重合度越高说明 LLM 的分析结果越可信。差异大的地方需要单独看是 LLM 幻觉还是静态工具的规则覆盖不全。7.5 测试五批量任务测试目的验证批量分析多个文件的稳定性。lemmalog batch --input ./src --output ./lemmas --workers 4预期结果所有文件都被处理每个文件生成独立的引理条目workers参数控制并发数。失败排查重点批量任务中途卡住往往是因为某个文件触发了 LLM 的错误输出或者 API 限流。先看日志里有没有失败重试记录再确认max_retries配置是否生效。8. 接口 API 与批量任务接入如果 Lemmalog 以服务方式运行业务系统可以通过 HTTP 接口调用。这里给出一个通用调用模板你可以按实际项目接口路径调整。8.1 发起单文件分析请求import requests import os url http://127.0.0.1:8080/api/analyze payload { file: src/parser.py, language: python, save_lemma: True } r requests.post( url, jsonpayload, timeout300, headers{Authorization: fBearer {os.environ.get(LEMMALOG_TOKEN)}} ) print(r.status_code) print(r.json())如果请求正常返回值里一般包含lemma_id、conclusion、evidence和verified字段。如果项目没有做鉴权可以不用带 Authorization 头但上线部署时建议开启。8.2 批量任务设计批量分析不能简单理解为“循环调用接口”。更稳妥的方式是设计一个任务队列# 先生成待分析文件列表 find ./src -name *.py filelist.txt # 再逐批提交每批 20 个文件 lemmalog batch --input filelist.txt --output ./lemmas --batch-size 20有条件的话把任务丢进 Redis 队列或数据库任务表用 Worker 并发消费。每个任务记录开始时间、结束时间、重试次数、最终状态这样即使中途失败也能断点续跑。8.3 失败重试建议超时类的错误直接重试间隔指数退避比如 2 秒、4 秒、8 秒。LLM 输出格式错误的重试时换一个更明确的 prompt 模板。模型上下文溢出导致的失败要把输入文件拆小或者切到更大上下文的模型。9. 资源占用与性能观察9.1 API 模式API 模式下Lemmalog 的本地资源占用很低主要瓶颈在 LLM 服务的延迟和 token 消耗。观察指标单文件请求耗时。单文件消耗的 prompt token 和 completion token。引理日志文件增长速度。如果发现 token 消耗暴涨先检查是不是每次分析都把整个文件完整塞进 prompt。对于大文件应该只截取相关函数片段。9.2 本地模型模式本地模型的资源占用要重点看显存。# 持续观察显存占用 watch -n 1 nvidia-smi影响显存的主要因素模型参数量。量化精度比如 4bit 量化比 16bit 省显存。生成时的最大补全长度。并发请求数量。没有统一的显存标准因为模型版本和推理框架不同占用差异很大。第一次跑的时候把 batch size 和并发数调到最小先看单请求占用的峰值显存再逐步调大。9.3 日志增长与清理引理日志是增量落盘的长时间运行后会产生大量冗余条目。建议定期做两层清理删除测试过程中产生的低置信度条目。对同函数、同结论的重复条目做合并只保留最新一次验证状态。10. 常见问题与排查方法问题现象可能原因排查方式解决方案安装依赖失败Python 版本不匹配或网络问题查看报错信息检查 pip 源切换 Python 版本换镜像源重装启动后页面打不开端口被占用或服务未启动查看服务日志检查端口监听状态换端口或重启服务analyze 后没有生成引理解析 LLM 输出失败查看原始模型输出和日志调整 prompt 约束 JSON 格式增加重试引理库检索不到历史记录workspace 路径配置错误检查配置文件中的 workspace 目录修正路径确认 lemma_id 唯一API 请求长时间无响应模型服务过载或网络问题用 curl 单独测 LLM 接口延迟拉长 timeout降低并发批量任务中途卡死某个文件触发了异常输出查看任务日志定位具体文件跳过该文件或拆分输入本地模型显存不足模型过大或并发过高观察 nvidia-smi 的显存使用率换量化版本降低 batch 和并发结论互相矛盾模型在不同会话中理解偏差查看引理依赖链增加验证步骤人工复核或静态工具交叉检查11. 最佳实践与使用建议想把 Lemmalog 用到真正的项目中建议从下面几个习惯开始。先小后大。第一次只拿一个文件、一条函数跑通全流程确认输出格式、日志目录、API 调用都正常再扩展到整个仓库。不要一开始就批量分析几千个文件失败后排查成本会很高。每个引理必须绑定代码位置。没有file、function、line字段的结论没有任何追溯价值。拿到 LLM 输出后如果发现它没有给出具体行号宁可让它重新分析也不要容纳模糊结论。置信度要设阈值。LLM 的 confidence 字段不能只做展示应该参与流程控制。低于阈值的引理自动标记为“待复核”不进入最终结论。批量任务必须有日志。每个文件、每次重试、每次失败原因都要有记录。没有日志的批量任务等于在盲跑。敏感代码尽量走本地模型。如果分析对象是未公开的商业代码优先接 Ollama 或 vLLM数据不出内网。使用第三方 API 之前先确认协议里有没有数据留存条款。引理库要进 Git。这样每次修改都有历史版本谁改了什么、结论何时被验证过全部可追踪。Git 的 diff 功能本身就是一种审计手段。最后一件事是人工复核。LLM 的分析水平再高也不能完全替代人的判断。关键结论至少要过一遍代码评审再决定是否进入技术报告或安全工单。12. 总结与下一步Lemmalog 这个项目最值得关注的地方不是某个具体的 API 或模型而是它提供了一种思路把 LLM 会遗忘、会漂移的记忆改造成程序分析意义上的“引理库”。一旦分析结论变成可追溯、可验证、可复用的结构化数据LLM 就能从“聊天分析”升级成“带审计记录的工程分析工具”。如果你准备上手最先要验证的是两件事单文件分析能否生成包含证据的引理日志以及第二次会话能否正确引用之前的分析结果。这两个能力跑通Lemmalog 的核心价值就已经体现出来了。最容易踩的坑也很明确LLM 输出格式不稳定导致引理解析失败。对策是提前设计好 JSON 输出模板并把重试逻辑和格式校验写进流程不能指望模型每次都乖乖返回标准结构。下一步可以做的扩展方向很多对接 Semgrep、CodeQL 这类传统程序分析工具做自动校验把引理库接入向量检索按语义搜索历史分析结论甚至可以做成 VS Code 插件让开发者在编辑器里直接查看 LLM 对当前函数的历史判断。这套“LLM 引理日志 程序分析”的组合未来会成为代码分析工具链里值得重视的一环。
