开头先给个结论：这个标题其实点出了一个非常实用的思路——很多人在调 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(email=request.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(email=request.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 记忆变成程序分析”这个思路，真正落地靠的不是某个神奇参数，而是一套稳定的、可重复的分析流程。先把单任务跑稳，再把记忆结构化，最后再上批量和自动化，这条路径比一开始就追求“全自动代码审计”要靠谱得多。
