开头先给个结论这个标题其实点出了一个非常实用的思路——很多人在调 LLM 的时候只把“记忆”理解成上下文窗口或缓存但一旦把这段记忆当作可操作的分析工作区它就能变成一种程序分析工具。也就是说你不需要一开始就去搭复杂的静态分析框架也不用先训练一个专门的代码模型只要把 LLM 的上下文管理、提示词结构和输出约束想清楚就能用它完成不少代码检查、依赖梳理、风险排查和逻辑分析任务。这篇文章适合几种人看正在做代码审计但想提效的开发者负责内部工具链建设的技术负责人还有想把 LLM Agent 接到代码分析场景里的初学者。最值得关注的不是某个现成产品而是一套可以从零搭起来的操作流程怎么把代码拆进 LLM 的上下文怎么让它记住前面的结论怎么把“分析记忆”变成可复用的中间结果以及批量执行时怎么判断结果到底靠不靠谱。我会按实际落地顺序拆先讲清楚 LLM 内存和程序分析之间的关系再给出最小可行流程然后做结构化记忆最后补参数、调试和排错经验。整个过程基于常见的本地或 API 环境不限定具体厂商。1. 先理解LLM 的“内存”为什么能当程序分析用1.1 LLM 的内存并不是缓存而是分析工作区很多人第一次接触 LLM 时会把上下文窗口理解成“模型能记住多长的对话历史”。这个说法没有错但它漏掉了更关键的一点上下文窗口不只是存储空间它实际上承担着“分析工作区”的功能。就好比一个人做代码审查的时候不会把整个代码库全都背下来而是会把相关文件、函数调用链、报错信息、需求说明放到手边一边看一边推断。LLM 的上下文窗口就是这个手边工作区。你把哪些代码、哪些规则、哪些历史结论放进去它就在这个范围内做推理。这就是“把 LLM 内存变成程序分析”的第一层含义你不需要让它记住所有代码而是要教会它把注意力放在最关键的代码片段和分析任务上。与其说这是“让模型记住项目”不如说是“让模型在指定范围内做分析”。窗口里的内容就是分析输入模型输出就是分析结果。1.2 为什么“意外”会从内存走到程序分析这个标题里有个词很关键accidentally。回想一下实际使用过程你会发现从内存管理到程序分析确实是一步步“踩”出来的。最开始你可能只是在处理长任务比如让模型总结一段长文档或者让它根据多轮对话回答问题。这时你会发现上下文不够用了或者模型突然忘了前面的结论。于是你会开始做截断、摘要、分段、缓存这就是典型的“记忆管理”。但接着会出现一个新问题如果你处理的不是普通聊天记录而是一段代码那么“记忆管理”自然就变成了“代码分析”。因为你要决定哪些代码放进上下文哪些变量和函数需要在多轮里保留哪些历史判断不能丢。这本质上就是在做程序分析只是没有用传统编译器或静态分析工具的方式去做。所以这个“意外”其实是合理的程序分析本来就是高密度的上下文任务。你一旦认真处理了 LLM 的上下文记忆就会被迫去考虑代码之间的依赖关系、符号引用、函数调用链、Bug 特征、输出规范这些全是程序分析的核心问题。1.3 用 LLM 做程序分析和传统静态分析有什么差异传统静态分析工具的行为方式比较确定给定语法规则它会把所有符合规则的地方标记出来。优点是稳定、可重复缺点是写规则的成本高而且很多深层逻辑问题很难用规则覆盖。LLM 做程序分析的方式完全不同。它更像一个理解语义的协作者你告诉它“这段代码里可能有什么风险”它会根据命名、调用关系、异常处理、业务上下文给出推断。它不保证百分之百准确但能处理很多非规则类问题比如“这里为什么可能产生死锁”或者“这段 SQL 拼接存在什么问题”。所以不要把 LLM 版程序分析当成传统分析器的替代品而要把它看成一个补充层。判断标准也很简单规则明确、需要全量扫描、对结果一致性要求极高的场景用传统工具需要理解语义、处理跨文件逻辑、解释问题成因的场景更适合用 LLM。两者同时跑效果通常更好。2. 最小可行流程第一次把 LLM 用在代码分析上2.1 环境准备本地模型还是 API先决定运行方式。如果你只是在自己的笔记本上做试验用 API 的方式最省事。你不需要下载模型只需要准备一个 API Key 和一个支持代码的模型。如果你有比较完整的代码环境也可以使用本地推理服务这样数据不用出本机长期跑更可控。要不要上本地模型看三个条件显存和内存常见的 7B 到 14B 模型在量化后需要 8GB 到 16GB 显存如果是 32B 以上模型建议 24GB 起步。任务规模偶尔分析几百行代码API 就够了每天要跑几百个文件本地服务更经济。数据敏感性代码如果涉及内部业务逻辑优先本地部署。这里有个经验不要一上来就选最大模型。第一次跑通流程优先选能力中等、速度快的模型。因为你要调试的是输入格式、上下文管理、输出解析这些环节而不是模型能力。2.2 把代码放进上下文的三种方式要让 LLM 分析代码你得先把代码变成它可读的输入。常见的做法有三种按复杂度从低到高排列。第一种是直接拼接。把目标文件内容原样放到提示词里适合小文件。简单直接但文件一大就会占满上下文。第二种是按函数或类切片。只提取关键函数、关键类避免把无关代码全部塞进去。这种方式适合做局部 Bug 检测也是我建议新手先用的方式。第三种是带标签地组织代码。比如文件auth_service.py 功能点处理用户登录调用 token_utils.py 生成令牌 代码片段 def login(request): user db.query(User).filter_by(emailrequest.email).first() if user and user.check_password(request.password): token TokenGenerator().generate(user.id) return ok(token) return error(invalid email or password)给模型标明文件、功能点、代码片段比直接丢一整段代码更容易得到高质量分析。因为它可以借助文件信息和注释理解上下文而不是靠猜。2.3 最小示例分析一个函数可能存在的风险下面给一个最简单的提示词模板。假设我要分析一个 Python 登录函数你现在是一个代码审查助手。请分析下面这段代码重点检查 1. 是否存在空指针或空对象风险 2. 是否存在逻辑漏洞 3. 异常处理是否合理 4. 可读性和命名问题 代码 def login(request): user db.query(User).filter_by(emailrequest.email).first() if user and user.check_password(request.password): token TokenGenerator().generate(user.id) return ok(token) return error(invalid email or password) 请用下面的格式输出 风险等级高/中/低 问题列表 - 问题描述 - 可能触发条件 - 改进建议这个模板看起来简单但实际效果比“帮我看看这段代码有没有问题”要好得多。原因在于你限制了分析范围也限制了输出结构。模型不需要泛泛而谈而是按你的规则逐项排查。跑通这一步之后你再去做复杂场景。先单条任务能跑通再批量。不要一开始就把整个项目丢进去。2.4 成功结果长什么样判断结果是否成功不能只看它有没有输出。我一般会检查三件事输出是否按指定格式组织、问题点是否命中代码中的真实逻辑、建议是否具体到能改代码。比如上面这个登录函数好的分析结果应该能提到“request.email 可能为 None这里没有做参数校验”“db.query().first() 可能返回 None但后面直接访问了 user.id”“密码错误和邮箱不存在返回相同的提示可能有利于防止用户枚举”。如果模型只说了“这段代码总体不错但建议增加异常处理”这种话说明输入格式或提示词还是太泛需要加限定条件。3. 把“临时记忆”变成可复用的分析记忆3.1 为什么单轮分析不够单次分析可以处理一个函数、一个文件但真实项目基本都是跨文件、跨模块的。你在分析 A 文件时可能要看 B 文件里的工具函数还要参考 C 文件里的数据结构定义。这时候如果每次都是独立调用模型看不到其他文件的信息分析质量会明显下降。更麻烦的是你每次问同一个问题它都像第一次看到代码一样没有历史积累。所以要从“单次提示词”转向“结构化记忆”。这个记忆不是模型天然保存的而是你自己维护的通常就是项目知识库、历史分析结果、代码依赖索引。你把这些内容按需取出并拼进提示词让模型的分析始终基于同一套事实基础。3.2 用知识库保存历史分析结论比较实用的做法是把历史分析结果保存成文档或 JSON 文件。每次分析完一个文件就把结论、问题点、修复建议、文件路径、时间信息存下来。下次分析相关文件时把上一条结论也放进上下文里。比如你可以维护一个analysis_history.json{ files: { auth_service.py: { last_analysis: 2025-06-01, risks: [request.email may be None, user may be None], fixed: [add parameter validation], related_files: [token_utils.py, db.py] } } }这样做的价值是后续分析不再完全从零开始。你可以把相关历史问题附在提示词里让模型知道“这个文件之前被指出过这些问题现在重点看有没有新增风险”。如果你用的是支持外部工具的平台还可以把历史结论放到向量检索里按文件名或问题类型查找。但不必一上来就搭完整知识库先用 JSON 或 Markdown 文件就能跑通。3.3 用上下文拼接处理跨文件分析跨文件分析的关键是控制信息密度。你不能把整个项目都塞进去而是要先搞清楚文件之间的依赖关系。一个我经常用的流程是先让模型看主入口文件让它列出它认为需要进一步分析的依赖函数。再根据模型列的依赖把对应的函数片段补充进来。拼接成一份带索引的分析材料再让模型做第二轮综合分析。比如你分析auth_service.py模型说它需要看token_utils.py的generate方法和db.py的query方法。你就把这两个方法的代码片段取出来和分析材料拼到一起再次提问。这个“先看主文件再看依赖”的流程很像程序分析里的调用图遍历。它不一定完美但能避免直接把整个项目塞进上下文导致的注意力分散和 token 浪费。3.4 进阶让模型自己决定看哪些文件如果项目较大你还可以让模型扮演一个“分析调度器”让它先只读文件名、目录结构、函数导出一览然后由它自己判断下一步需要看哪些文件。这其实就是轻量级 Agent 的思路。你可以维护一个文件清单让模型选择候选文件你再从仓库中取出对应内容继续追问。示例提示词项目结构如下 - app/main.py - app/services/auth_service.py - app/services/token_utils.py - app/db.py 我现在要分析认证流程中的潜在安全风险。 请先告诉我你必须读取哪几个文件以及你准备重点检查哪些函数。这一步可以让模型输出需要读取 1. app/services/auth_service.py 的 login 函数 2. app/services/token_utils.py 的 generate 函数 3. app/db.py 的 query 函数 重点检查 - 用户输入是否被校验 - token 生成是否有随机数弱化问题 - 数据库查询是否可能存在注入然后你根据这个回答去取代码再进入第二轮分析。这样做的好处是每次进入上下文的代码都是被精挑细选的不会浪费大量 token 在无关文件上。4. 批量分析时的关键参数和判断标准4.1 上下文长度、重叠和切片策略当你开始批量分析一个项目时不能只是循环调用。你要先把文件切片策略定好。常见的做法是按函数切片或者按代码块切片。每个文件最好保留一份头部信息和依赖信息这样模型知道自己在看哪个文件、这个文件和其他文件的关系。切片时的几个参数最大输入长度建议不要超过模型上下文窗口的 70%。因为你要给输出留空间还要给历史结论和规则模板留空间。切片重叠如果你按函数切片建议相邻切片之间保留 5 到 10 行重叠。避免函数调用边界被硬生生切断。单批文件数新手上路建议一次只分析一个文件。跑通后再尝试一次分析 3 到 5 个相关文件。我这里给的是通用经验。实际参数要结合你用的模型、任务复杂度和成本承受能力来调。4.2 如何判断分析结果到底可不可信这是整个方案里最容易翻车的地方。LLM 的输出看着很有道理但不代表它真的抓住了问题。我一般会用四个维度判断可复现性同一个输入跑两次如果结果差异很大说明模型对代码理解不够稳定需要补充上下文或降低温度。命中率拿一批已知有问题的代码做测试看模型能不能识别出预设问题。这一步最有用花半小时准备几个故意埋了 Bug 的样例就能判断工具思路是否可行。误报率模型可能会把正常代码说成有风险。误报太多说明提示词里缺少“只报告确定问题”的约束。可执行性建议是否具体到能直接改。如果只会说“提高安全性”这种话价值很低。更实用的做法是在一个小测试集上跑一轮人工检查结果把成功和失败样例记录下来再调整提示词。这个流程和训练一个代码质量模型没有本质区别只是不需要真的跑训练。4.3 批量运行时的成本、日志和失败重试如果你要用大量代码做分析需要考虑三个实际问题成本、日志、失败重试。成本方面建议先算一笔 token 账。每次分析一个函数大概会消耗多少输入 token 和输出 token乘以你要分析的函数数量就能预估出总成本。做过一次预估后你才会发现“把所有代码原样塞进去”有多么烧 token。日志方面不要把输出只留在控制台。我建议把每次分析的输入摘要、输出结果、耗时、token 消耗、模型名称都记录到一个文件里。这样后期排查问题才不用重新跑一遍。失败重试方面不要把所有文件都放在一个超长请求里。一旦某个请求超时或返回异常整个任务都可能失败。比较稳妥的做法是按文件拆任务每个任务独立记录状态。能重试的单独重试失败的单独查看原因。注意批量任务最怕的不是模型回答错而是你无法定位是哪一次输入、哪一次输出导致了问题。先写好任务编号和日志再开批量。4.4 是否需要微调很多人问到微调。以我实际经验看如果你只是用 LLM 做程序分析先不要微调。原因很简单程序分析的质量主要取决于你能不能把代码、规则、历史结论合理放进上下文。提示词和上下文管理带来的收益往往比微调更直接。微调更适合以下几类情况你有一个固定风格的代码库希望模型默认输出某种格式你频繁处理某些专用框架或语言通用模型对语法不熟你希望降低提示词长度把常用分析规则内化到模型里。如果你刚开始接触建议先把提示词和上下文管理做好。等到你发现自己反复把同一套规则写进提示词且模型输出格式仍然不稳定时才考虑微调。5. 常见问题排查不是模型不够强而是上下文和输入没处理好5.1 输出结果太笼统怎么收紧这是最常遇到的问题。模型说“这段代码需要完善异常处理”但你没法直接改成代码。这种情况一般不是模型能力问题而是提示词里缺少约束。你可以加几条硬性要求每个问题必须对应具体代码行或函数名。每个建议必须给出可修改的示例。禁止输出“增强安全性”“优化性能”这类空泛描述。按固定模板输出例如“问题xxx触发条件xxx修复示例xxx”。如果模型仍然输出笼统可以再加一层“如果没有发现能输出的具体问题请直接写未发现具体问题”。这能减少无意义输出。5.2 跨文件分析时漏掉重点怎么办模型经常犯一个毛病你给了 A 文件它只分析 A 文件完全没有考虑依赖函数的问题。这不能全怪模型因为你的上下文里本来就没有依赖信息。解决办法是把依赖文件的关键函数以“参考材料”的形式放进去同时在提示词里写明以下代码是当前目标文件依赖的函数。分析 target.py 时需要同时检查依赖函数是否可能导致 target.py 出现问题。这一步能明显减少漏重点的情况。如果还是漏就检查你的文件收集逻辑看是不是某些依赖文件根本没被找到。5.3 结果不稳定和哪些参数有关同一个输入跑两次结果不一样这是 LLM 常见问题。主要原因有两个采样温度和上下文长度。温度是最直接的参数。程序分析这类任务我一般建议把温度调到比较低的档位比如常见的 0 到 0.3 区间。温度越低输出越倾向于确定性的内容但太低也可能让模型显得机械。上下文长度也会影响稳定性。如果你把上下文顶到边界模型可能会丢掉前面的部分信息导致结果抖动。留出至少 30% 的冗余空间稳定性会好很多。如果两次结果差异确实很大建议先做差异对比。看看模型第二次是不是遗漏了某个文件或某条规则。如果是优先补充上下文而不是继续改提示词。5.4 启动报错、内存不足和依赖问题运行本地模型时常见的坑是启动阶段就失败。启动失败不一定和代码逻辑有关系很多时候是环境问题。排查顺序建议如下先看模型加载时的日志。日志是否显示显存不足是否是二进制文件损坏是否是量化文件不匹配。再确认依赖版本。Python 版本、CUDA 版本、推理框架版本是否匹配。不同的推理框架对 CUDA 的要求不一样底层不匹配会出现难以理解的错误。然后看输入和文件路径。模型文件路径、配置文件路径是否存在有没有使用相对路径导致找不到文件。最后确认参数。上下文长度不能超过模型真实支持的范围量化方式是否与推理框架兼容。我遇到过很多次“模型看起来加载了但总是崩溃”的情况最后发现是推理框架和模型格式不兼容。所以建议在正式跑批量前先跑一个单条测试确认环境稳定性。5.5 调用 API 时的超时、限流和输出截断如果你使用 API还会遇到几类新问题。超时问题代码分析通常比普通问答耗时更长。尤其是输入很长时API 响应时间会增加。建议把超时时间设得比默认值更大比如 60 秒到 120 秒。限流问题批量请求时不要直接把并发开到最大。可以先按 1 到 3 个并发测试一次逐步增加。注意观察返回状态码如果出现限流提示就降低并发或加入重试逻辑。输出截断问题模型可能在回复中途停止原因是最大输出 token 设置不够。分析代码问题时输出建议要比较长一定要预留足够的 max_tokens。否则模型只说了问题描述还没来得及给修复代码就被截断分析价值就会大打折扣。6. 把 LLM 程序分析真正落地的几个建议6.1 先做小范围验证再决定投入一个工具方案值不值得投入不要看演示效果要看小范围验证结果。我建议你选一个真实的项目目录挑 10 到 20 个文件先按这篇文章的流程跑一遍。记录四个数据分析耗时、token 消耗、人工确认的问题数、误报数。这些数据能帮你判断后续要不要扩大使用范围。如果每 10 个问题里有 7 个是真正的问题这个方案就很有价值。如果大多数输出都需要人工重新审查说明提示词和上下文管理还需要打磨。6.2 把分析流程脚本化不要总是手动拼提示词手动复制粘贴代码写提示词只适合试验。真正要长期使用建议写成脚本至少做成半自动化。一个最简单的脚本流程是输入一个文件路径。读取文件按函数或类切片。拼接提示词模板。调用模型接口。解析输出保存到结果文件。只要跑通这个流程你就可以把它扩展到整个项目目录。再进一步还能整合到 CI 流程中在代码合并前自动跑一轮基础风险分析。6.3 同时保留传统分析工具形成交叉验证用 LLM 做程序分析最大的风险是误报和漏报。所以我不建议把所有分析任务都交给 LLM更适合的做法是让 LLM 和传统静态分析工具并行工作。传统工具负责规则类检查未使用变量、空函数、明显越界、配置错误。LLM 负责语义类分析函数调用意图、安全漏洞成因、异常处理逻辑、跨模块影响。两者并行后把结果交给人来做最终判断。这样既能利用 LLM 的语义理解能力又不会丢失传统工具的稳定性和可重复性。6.4 后续可以想的方向一旦你把这个流程跑通后面可以做的事情还有很多。比如让模型根据历史分析结果生成一份代码改进建议文档自动发给开发者。比如把分析结果汇总成趋势报告找出哪些模块的问题最多。再比如让模型定期对新提交代码做增量分析而不是每次都全量扫描。这些都属于从“单次分析”走向“持续分析”的方向。核心思路都一样把 LLM 的上下文记忆当作分析工作区用结构化记录和流程控制把分析能力稳定下来。7. 最后留几个排查时优先看的点这个方案真正落地时最该盯住的不是模型有多强而是输入格式、资源占用和任务日志。我自己排查问题时通常会按这个顺序来先看输入内容。是不是代码切片错误是不是文件路径不对是不是依赖文件没找到。代码分析很多看起来是模型问题实际是输入问题。再看输出格式。模型有没有按模板输出有没有截断有没有输出与问题无关的内容。再看资源占用。本地模型的话显存、内存、磁盘有没有异常占用调用 API 的话看请求延迟和 token 消耗。最后看上下文长度。有没有顶到上限有没有因为过长导致模型丢失关键信息。如果你发现一个问题反复出现不要急着换更大模型。先做一个对比实验用同一段输入换一种提示词模板看看结果是否有变化再补入更多依赖代码看看结果是否有提升。大部分时候问题出在上下文组织上而不是模型能力上。踩过几次之后我的感受是“把 LLM 记忆变成程序分析”这个思路真正落地靠的不是某个神奇参数而是一套稳定的、可重复的分析流程。先把单任务跑稳再把记忆结构化最后再上批量和自动化这条路径比一开始就追求“全自动代码审计”要靠谱得多。
把LLM记忆变成程序分析工具：上下文管理驱动的代码审查实践
开头先给个结论这个标题其实点出了一个非常实用的思路——很多人在调 LLM 的时候只把“记忆”理解成上下文窗口或缓存但一旦把这段记忆当作可操作的分析工作区它就能变成一种程序分析工具。也就是说你不需要一开始就去搭复杂的静态分析框架也不用先训练一个专门的代码模型只要把 LLM 的上下文管理、提示词结构和输出约束想清楚就能用它完成不少代码检查、依赖梳理、风险排查和逻辑分析任务。这篇文章适合几种人看正在做代码审计但想提效的开发者负责内部工具链建设的技术负责人还有想把 LLM Agent 接到代码分析场景里的初学者。最值得关注的不是某个现成产品而是一套可以从零搭起来的操作流程怎么把代码拆进 LLM 的上下文怎么让它记住前面的结论怎么把“分析记忆”变成可复用的中间结果以及批量执行时怎么判断结果到底靠不靠谱。我会按实际落地顺序拆先讲清楚 LLM 内存和程序分析之间的关系再给出最小可行流程然后做结构化记忆最后补参数、调试和排错经验。整个过程基于常见的本地或 API 环境不限定具体厂商。1. 先理解LLM 的“内存”为什么能当程序分析用1.1 LLM 的内存并不是缓存而是分析工作区很多人第一次接触 LLM 时会把上下文窗口理解成“模型能记住多长的对话历史”。这个说法没有错但它漏掉了更关键的一点上下文窗口不只是存储空间它实际上承担着“分析工作区”的功能。就好比一个人做代码审查的时候不会把整个代码库全都背下来而是会把相关文件、函数调用链、报错信息、需求说明放到手边一边看一边推断。LLM 的上下文窗口就是这个手边工作区。你把哪些代码、哪些规则、哪些历史结论放进去它就在这个范围内做推理。这就是“把 LLM 内存变成程序分析”的第一层含义你不需要让它记住所有代码而是要教会它把注意力放在最关键的代码片段和分析任务上。与其说这是“让模型记住项目”不如说是“让模型在指定范围内做分析”。窗口里的内容就是分析输入模型输出就是分析结果。1.2 为什么“意外”会从内存走到程序分析这个标题里有个词很关键accidentally。回想一下实际使用过程你会发现从内存管理到程序分析确实是一步步“踩”出来的。最开始你可能只是在处理长任务比如让模型总结一段长文档或者让它根据多轮对话回答问题。这时你会发现上下文不够用了或者模型突然忘了前面的结论。于是你会开始做截断、摘要、分段、缓存这就是典型的“记忆管理”。但接着会出现一个新问题如果你处理的不是普通聊天记录而是一段代码那么“记忆管理”自然就变成了“代码分析”。因为你要决定哪些代码放进上下文哪些变量和函数需要在多轮里保留哪些历史判断不能丢。这本质上就是在做程序分析只是没有用传统编译器或静态分析工具的方式去做。所以这个“意外”其实是合理的程序分析本来就是高密度的上下文任务。你一旦认真处理了 LLM 的上下文记忆就会被迫去考虑代码之间的依赖关系、符号引用、函数调用链、Bug 特征、输出规范这些全是程序分析的核心问题。1.3 用 LLM 做程序分析和传统静态分析有什么差异传统静态分析工具的行为方式比较确定给定语法规则它会把所有符合规则的地方标记出来。优点是稳定、可重复缺点是写规则的成本高而且很多深层逻辑问题很难用规则覆盖。LLM 做程序分析的方式完全不同。它更像一个理解语义的协作者你告诉它“这段代码里可能有什么风险”它会根据命名、调用关系、异常处理、业务上下文给出推断。它不保证百分之百准确但能处理很多非规则类问题比如“这里为什么可能产生死锁”或者“这段 SQL 拼接存在什么问题”。所以不要把 LLM 版程序分析当成传统分析器的替代品而要把它看成一个补充层。判断标准也很简单规则明确、需要全量扫描、对结果一致性要求极高的场景用传统工具需要理解语义、处理跨文件逻辑、解释问题成因的场景更适合用 LLM。两者同时跑效果通常更好。2. 最小可行流程第一次把 LLM 用在代码分析上2.1 环境准备本地模型还是 API先决定运行方式。如果你只是在自己的笔记本上做试验用 API 的方式最省事。你不需要下载模型只需要准备一个 API Key 和一个支持代码的模型。如果你有比较完整的代码环境也可以使用本地推理服务这样数据不用出本机长期跑更可控。要不要上本地模型看三个条件显存和内存常见的 7B 到 14B 模型在量化后需要 8GB 到 16GB 显存如果是 32B 以上模型建议 24GB 起步。任务规模偶尔分析几百行代码API 就够了每天要跑几百个文件本地服务更经济。数据敏感性代码如果涉及内部业务逻辑优先本地部署。这里有个经验不要一上来就选最大模型。第一次跑通流程优先选能力中等、速度快的模型。因为你要调试的是输入格式、上下文管理、输出解析这些环节而不是模型能力。2.2 把代码放进上下文的三种方式要让 LLM 分析代码你得先把代码变成它可读的输入。常见的做法有三种按复杂度从低到高排列。第一种是直接拼接。把目标文件内容原样放到提示词里适合小文件。简单直接但文件一大就会占满上下文。第二种是按函数或类切片。只提取关键函数、关键类避免把无关代码全部塞进去。这种方式适合做局部 Bug 检测也是我建议新手先用的方式。第三种是带标签地组织代码。比如文件auth_service.py 功能点处理用户登录调用 token_utils.py 生成令牌 代码片段 def login(request): user db.query(User).filter_by(emailrequest.email).first() if user and user.check_password(request.password): token TokenGenerator().generate(user.id) return ok(token) return error(invalid email or password)给模型标明文件、功能点、代码片段比直接丢一整段代码更容易得到高质量分析。因为它可以借助文件信息和注释理解上下文而不是靠猜。2.3 最小示例分析一个函数可能存在的风险下面给一个最简单的提示词模板。假设我要分析一个 Python 登录函数你现在是一个代码审查助手。请分析下面这段代码重点检查 1. 是否存在空指针或空对象风险 2. 是否存在逻辑漏洞 3. 异常处理是否合理 4. 可读性和命名问题 代码 def login(request): user db.query(User).filter_by(emailrequest.email).first() if user and user.check_password(request.password): token TokenGenerator().generate(user.id) return ok(token) return error(invalid email or password) 请用下面的格式输出 风险等级高/中/低 问题列表 - 问题描述 - 可能触发条件 - 改进建议这个模板看起来简单但实际效果比“帮我看看这段代码有没有问题”要好得多。原因在于你限制了分析范围也限制了输出结构。模型不需要泛泛而谈而是按你的规则逐项排查。跑通这一步之后你再去做复杂场景。先单条任务能跑通再批量。不要一开始就把整个项目丢进去。2.4 成功结果长什么样判断结果是否成功不能只看它有没有输出。我一般会检查三件事输出是否按指定格式组织、问题点是否命中代码中的真实逻辑、建议是否具体到能改代码。比如上面这个登录函数好的分析结果应该能提到“request.email 可能为 None这里没有做参数校验”“db.query().first() 可能返回 None但后面直接访问了 user.id”“密码错误和邮箱不存在返回相同的提示可能有利于防止用户枚举”。如果模型只说了“这段代码总体不错但建议增加异常处理”这种话说明输入格式或提示词还是太泛需要加限定条件。3. 把“临时记忆”变成可复用的分析记忆3.1 为什么单轮分析不够单次分析可以处理一个函数、一个文件但真实项目基本都是跨文件、跨模块的。你在分析 A 文件时可能要看 B 文件里的工具函数还要参考 C 文件里的数据结构定义。这时候如果每次都是独立调用模型看不到其他文件的信息分析质量会明显下降。更麻烦的是你每次问同一个问题它都像第一次看到代码一样没有历史积累。所以要从“单次提示词”转向“结构化记忆”。这个记忆不是模型天然保存的而是你自己维护的通常就是项目知识库、历史分析结果、代码依赖索引。你把这些内容按需取出并拼进提示词让模型的分析始终基于同一套事实基础。3.2 用知识库保存历史分析结论比较实用的做法是把历史分析结果保存成文档或 JSON 文件。每次分析完一个文件就把结论、问题点、修复建议、文件路径、时间信息存下来。下次分析相关文件时把上一条结论也放进上下文里。比如你可以维护一个analysis_history.json{ files: { auth_service.py: { last_analysis: 2025-06-01, risks: [request.email may be None, user may be None], fixed: [add parameter validation], related_files: [token_utils.py, db.py] } } }这样做的价值是后续分析不再完全从零开始。你可以把相关历史问题附在提示词里让模型知道“这个文件之前被指出过这些问题现在重点看有没有新增风险”。如果你用的是支持外部工具的平台还可以把历史结论放到向量检索里按文件名或问题类型查找。但不必一上来就搭完整知识库先用 JSON 或 Markdown 文件就能跑通。3.3 用上下文拼接处理跨文件分析跨文件分析的关键是控制信息密度。你不能把整个项目都塞进去而是要先搞清楚文件之间的依赖关系。一个我经常用的流程是先让模型看主入口文件让它列出它认为需要进一步分析的依赖函数。再根据模型列的依赖把对应的函数片段补充进来。拼接成一份带索引的分析材料再让模型做第二轮综合分析。比如你分析auth_service.py模型说它需要看token_utils.py的generate方法和db.py的query方法。你就把这两个方法的代码片段取出来和分析材料拼到一起再次提问。这个“先看主文件再看依赖”的流程很像程序分析里的调用图遍历。它不一定完美但能避免直接把整个项目塞进上下文导致的注意力分散和 token 浪费。3.4 进阶让模型自己决定看哪些文件如果项目较大你还可以让模型扮演一个“分析调度器”让它先只读文件名、目录结构、函数导出一览然后由它自己判断下一步需要看哪些文件。这其实就是轻量级 Agent 的思路。你可以维护一个文件清单让模型选择候选文件你再从仓库中取出对应内容继续追问。示例提示词项目结构如下 - app/main.py - app/services/auth_service.py - app/services/token_utils.py - app/db.py 我现在要分析认证流程中的潜在安全风险。 请先告诉我你必须读取哪几个文件以及你准备重点检查哪些函数。这一步可以让模型输出需要读取 1. app/services/auth_service.py 的 login 函数 2. app/services/token_utils.py 的 generate 函数 3. app/db.py 的 query 函数 重点检查 - 用户输入是否被校验 - token 生成是否有随机数弱化问题 - 数据库查询是否可能存在注入然后你根据这个回答去取代码再进入第二轮分析。这样做的好处是每次进入上下文的代码都是被精挑细选的不会浪费大量 token 在无关文件上。4. 批量分析时的关键参数和判断标准4.1 上下文长度、重叠和切片策略当你开始批量分析一个项目时不能只是循环调用。你要先把文件切片策略定好。常见的做法是按函数切片或者按代码块切片。每个文件最好保留一份头部信息和依赖信息这样模型知道自己在看哪个文件、这个文件和其他文件的关系。切片时的几个参数最大输入长度建议不要超过模型上下文窗口的 70%。因为你要给输出留空间还要给历史结论和规则模板留空间。切片重叠如果你按函数切片建议相邻切片之间保留 5 到 10 行重叠。避免函数调用边界被硬生生切断。单批文件数新手上路建议一次只分析一个文件。跑通后再尝试一次分析 3 到 5 个相关文件。我这里给的是通用经验。实际参数要结合你用的模型、任务复杂度和成本承受能力来调。4.2 如何判断分析结果到底可不可信这是整个方案里最容易翻车的地方。LLM 的输出看着很有道理但不代表它真的抓住了问题。我一般会用四个维度判断可复现性同一个输入跑两次如果结果差异很大说明模型对代码理解不够稳定需要补充上下文或降低温度。命中率拿一批已知有问题的代码做测试看模型能不能识别出预设问题。这一步最有用花半小时准备几个故意埋了 Bug 的样例就能判断工具思路是否可行。误报率模型可能会把正常代码说成有风险。误报太多说明提示词里缺少“只报告确定问题”的约束。可执行性建议是否具体到能直接改。如果只会说“提高安全性”这种话价值很低。更实用的做法是在一个小测试集上跑一轮人工检查结果把成功和失败样例记录下来再调整提示词。这个流程和训练一个代码质量模型没有本质区别只是不需要真的跑训练。4.3 批量运行时的成本、日志和失败重试如果你要用大量代码做分析需要考虑三个实际问题成本、日志、失败重试。成本方面建议先算一笔 token 账。每次分析一个函数大概会消耗多少输入 token 和输出 token乘以你要分析的函数数量就能预估出总成本。做过一次预估后你才会发现“把所有代码原样塞进去”有多么烧 token。日志方面不要把输出只留在控制台。我建议把每次分析的输入摘要、输出结果、耗时、token 消耗、模型名称都记录到一个文件里。这样后期排查问题才不用重新跑一遍。失败重试方面不要把所有文件都放在一个超长请求里。一旦某个请求超时或返回异常整个任务都可能失败。比较稳妥的做法是按文件拆任务每个任务独立记录状态。能重试的单独重试失败的单独查看原因。注意批量任务最怕的不是模型回答错而是你无法定位是哪一次输入、哪一次输出导致了问题。先写好任务编号和日志再开批量。4.4 是否需要微调很多人问到微调。以我实际经验看如果你只是用 LLM 做程序分析先不要微调。原因很简单程序分析的质量主要取决于你能不能把代码、规则、历史结论合理放进上下文。提示词和上下文管理带来的收益往往比微调更直接。微调更适合以下几类情况你有一个固定风格的代码库希望模型默认输出某种格式你频繁处理某些专用框架或语言通用模型对语法不熟你希望降低提示词长度把常用分析规则内化到模型里。如果你刚开始接触建议先把提示词和上下文管理做好。等到你发现自己反复把同一套规则写进提示词且模型输出格式仍然不稳定时才考虑微调。5. 常见问题排查不是模型不够强而是上下文和输入没处理好5.1 输出结果太笼统怎么收紧这是最常遇到的问题。模型说“这段代码需要完善异常处理”但你没法直接改成代码。这种情况一般不是模型能力问题而是提示词里缺少约束。你可以加几条硬性要求每个问题必须对应具体代码行或函数名。每个建议必须给出可修改的示例。禁止输出“增强安全性”“优化性能”这类空泛描述。按固定模板输出例如“问题xxx触发条件xxx修复示例xxx”。如果模型仍然输出笼统可以再加一层“如果没有发现能输出的具体问题请直接写未发现具体问题”。这能减少无意义输出。5.2 跨文件分析时漏掉重点怎么办模型经常犯一个毛病你给了 A 文件它只分析 A 文件完全没有考虑依赖函数的问题。这不能全怪模型因为你的上下文里本来就没有依赖信息。解决办法是把依赖文件的关键函数以“参考材料”的形式放进去同时在提示词里写明以下代码是当前目标文件依赖的函数。分析 target.py 时需要同时检查依赖函数是否可能导致 target.py 出现问题。这一步能明显减少漏重点的情况。如果还是漏就检查你的文件收集逻辑看是不是某些依赖文件根本没被找到。5.3 结果不稳定和哪些参数有关同一个输入跑两次结果不一样这是 LLM 常见问题。主要原因有两个采样温度和上下文长度。温度是最直接的参数。程序分析这类任务我一般建议把温度调到比较低的档位比如常见的 0 到 0.3 区间。温度越低输出越倾向于确定性的内容但太低也可能让模型显得机械。上下文长度也会影响稳定性。如果你把上下文顶到边界模型可能会丢掉前面的部分信息导致结果抖动。留出至少 30% 的冗余空间稳定性会好很多。如果两次结果差异确实很大建议先做差异对比。看看模型第二次是不是遗漏了某个文件或某条规则。如果是优先补充上下文而不是继续改提示词。5.4 启动报错、内存不足和依赖问题运行本地模型时常见的坑是启动阶段就失败。启动失败不一定和代码逻辑有关系很多时候是环境问题。排查顺序建议如下先看模型加载时的日志。日志是否显示显存不足是否是二进制文件损坏是否是量化文件不匹配。再确认依赖版本。Python 版本、CUDA 版本、推理框架版本是否匹配。不同的推理框架对 CUDA 的要求不一样底层不匹配会出现难以理解的错误。然后看输入和文件路径。模型文件路径、配置文件路径是否存在有没有使用相对路径导致找不到文件。最后确认参数。上下文长度不能超过模型真实支持的范围量化方式是否与推理框架兼容。我遇到过很多次“模型看起来加载了但总是崩溃”的情况最后发现是推理框架和模型格式不兼容。所以建议在正式跑批量前先跑一个单条测试确认环境稳定性。5.5 调用 API 时的超时、限流和输出截断如果你使用 API还会遇到几类新问题。超时问题代码分析通常比普通问答耗时更长。尤其是输入很长时API 响应时间会增加。建议把超时时间设得比默认值更大比如 60 秒到 120 秒。限流问题批量请求时不要直接把并发开到最大。可以先按 1 到 3 个并发测试一次逐步增加。注意观察返回状态码如果出现限流提示就降低并发或加入重试逻辑。输出截断问题模型可能在回复中途停止原因是最大输出 token 设置不够。分析代码问题时输出建议要比较长一定要预留足够的 max_tokens。否则模型只说了问题描述还没来得及给修复代码就被截断分析价值就会大打折扣。6. 把 LLM 程序分析真正落地的几个建议6.1 先做小范围验证再决定投入一个工具方案值不值得投入不要看演示效果要看小范围验证结果。我建议你选一个真实的项目目录挑 10 到 20 个文件先按这篇文章的流程跑一遍。记录四个数据分析耗时、token 消耗、人工确认的问题数、误报数。这些数据能帮你判断后续要不要扩大使用范围。如果每 10 个问题里有 7 个是真正的问题这个方案就很有价值。如果大多数输出都需要人工重新审查说明提示词和上下文管理还需要打磨。6.2 把分析流程脚本化不要总是手动拼提示词手动复制粘贴代码写提示词只适合试验。真正要长期使用建议写成脚本至少做成半自动化。一个最简单的脚本流程是输入一个文件路径。读取文件按函数或类切片。拼接提示词模板。调用模型接口。解析输出保存到结果文件。只要跑通这个流程你就可以把它扩展到整个项目目录。再进一步还能整合到 CI 流程中在代码合并前自动跑一轮基础风险分析。6.3 同时保留传统分析工具形成交叉验证用 LLM 做程序分析最大的风险是误报和漏报。所以我不建议把所有分析任务都交给 LLM更适合的做法是让 LLM 和传统静态分析工具并行工作。传统工具负责规则类检查未使用变量、空函数、明显越界、配置错误。LLM 负责语义类分析函数调用意图、安全漏洞成因、异常处理逻辑、跨模块影响。两者并行后把结果交给人来做最终判断。这样既能利用 LLM 的语义理解能力又不会丢失传统工具的稳定性和可重复性。6.4 后续可以想的方向一旦你把这个流程跑通后面可以做的事情还有很多。比如让模型根据历史分析结果生成一份代码改进建议文档自动发给开发者。比如把分析结果汇总成趋势报告找出哪些模块的问题最多。再比如让模型定期对新提交代码做增量分析而不是每次都全量扫描。这些都属于从“单次分析”走向“持续分析”的方向。核心思路都一样把 LLM 的上下文记忆当作分析工作区用结构化记录和流程控制把分析能力稳定下来。7. 最后留几个排查时优先看的点这个方案真正落地时最该盯住的不是模型有多强而是输入格式、资源占用和任务日志。我自己排查问题时通常会按这个顺序来先看输入内容。是不是代码切片错误是不是文件路径不对是不是依赖文件没找到。代码分析很多看起来是模型问题实际是输入问题。再看输出格式。模型有没有按模板输出有没有截断有没有输出与问题无关的内容。再看资源占用。本地模型的话显存、内存、磁盘有没有异常占用调用 API 的话看请求延迟和 token 消耗。最后看上下文长度。有没有顶到上限有没有因为过长导致模型丢失关键信息。如果你发现一个问题反复出现不要急着换更大模型。先做一个对比实验用同一段输入换一种提示词模板看看结果是否有变化再补入更多依赖代码看看结果是否有提升。大部分时候问题出在上下文组织上而不是模型能力上。踩过几次之后我的感受是“把 LLM 记忆变成程序分析”这个思路真正落地靠的不是某个神奇参数而是一套稳定的、可重复的分析流程。先把单任务跑稳再把记忆结构化最后再上批量和自动化这条路径比一开始就追求“全自动代码审计”要靠谱得多。