AI代码审查从30分到80分：AST+RAG架构核心难点全解析

李博！上周我们组刚上了个AI代码审查的工具，我体验了一下，怎么说呢…… 让我猜猜，是不是感觉它只能抓抓格式问题，稍微复杂点的逻辑就瞎说？ 哈哈哈你也太了解了吧。真的，感觉就是个高级lint工具，还不如我们组里实习生review得认真。 这太正常了。你搭的那种基础版本，用LangChain两三个小时就能弄出来，但它顶多解决30%的问题。真正的难点根本不在搭建，在于怎么让AI理解你整个项目的上下文。 对对对，这就是我最大的困惑。比如我们一个PR改了某个service层的方法，但AI完全不知道下游谁在调用它，给的建议就很离谱。 你说到点子上了。基础版有两个根本性问题。第一个是长上下文，一个大PR几千行代码，模型窗口可能装不下。但这个其实还好，规范开发流程里PR不会太大。 第二个才是致命的——代码依赖关系。一个项目几十万行代码，你只给AI看PR那几百行，它怎么可能理解这段代码在整个系统里的含义？ 等会儿让我想想……所以核心问题是，怎么让AI在审PR的时候，能看到整个项目的全貌？ Bingo。但你不可能把几十万行代码全塞进prompt里对吧？所以这里就需要AST出场了。 AST？抽象语法树？这不是编译原理的东西吗，大学学过但早还给老师了…… 哈哈别怕，我不考你编译原理。你就理解成——AST能把代码的结构用树状图表示出来，每个节点代表一种语法元素，比如类、方法、变量声明这些。 关键是它有个特别好的特性：信息压缩。一门语言的语法树规则也就一两千行，这个量级大模型完全能理解。 但我们又不是要让AI学语法啊，大模型本身就懂代码语法。 对！重点来了。我们用AST不是让AI学语法，而是用它对整个项目做提炼和摘要。 你想啊，十万行代码、一千个类、两千个方法，通过AST解析，把所有类名、方法签名、注释抽出来，形成结构化摘要，存到向量数据库里。 哦！我懂了！然后新PR来的时候，再用AST分析这个PR依赖了哪些外部的类和方法—— 然后通过RAG从向量数据库里把相关的摘要捞出来！ 拼成完整上下文再给大模型！这不就是Cursor干的事吗？！ 就是！Cursor、字节的Trae，底层都是这套机制。不断提取、不断摘要，审查时才能结合多文件上下文给建议。 等等，你说的RAG我大概知道，就是检索增强生成对吧。但在代码场景里具体怎么做检索？用关键词匹配吗？ 不是关键词，是语义检索。代码片段通过Embedding模型转成高维向量，语义相近的代码在向量空间里会靠得很近。查的时候做相似度搜索，毫秒级就能从几万个片段里找到最相关的。 所以整个系统其实是两条线并行——一条是PR来了实时审查，另一条是后台持续维护知识库？ 没错，你产品sense还是可以的嘛。 得了吧，这不是基本的系统设计思路嘛。那后台那条线具体干啥？ 后台程序定时扫描项目代码，AST解析出所有方法和类，然后AI智能体再加工一遍——文档写得烂的补文档，没文档的自动生成摘要，最后同步到向量数据库。 这套下来能到什么水平？ 从30%到50%-60%。但要到80%，还差两块——安全漏洞检测和知识更新。 安全检测不是大模型强项吗？它不是学了很多代码？ 浅层的可以，比如明显的SQL注入。但深层漏洞、零日漏洞？大模型根本不行。CVE数据库每天都有新漏洞披露，模型训练数据是有截止日期的。 那怎么办？ 业界的做法是双管齐下：一个持续更新的风险库做模式匹配，加上专门训练的风险分析模型。这块通常得用商业付费工具，别指望通用大模型。 嗯理解了。那知识更新呢？比如我们项目升级了框架版本，AI还按老版本的规则审，那不是乱套了。 这是最棘手的。两个路子：一是RAG知识库定期同步新框架文档，但维护成本高，塞太多上下文反而干扰模型判断。二是微调，用LoRA之类的方法把新知识编码进模型参数里。 但微调也有问题——每次新框架都得重新训练，还可能灾难性遗忘。所以务实的建议是，技术栈别老升级，把精力集中在高频高价值的审查场景上。 哈哈这个建议我们领导肯定爱听，'别升级就是最好的策略'。 你别笑，大厂真的是这么干的。字节内部已经在用自研的AI代码审核系统了，这条路径是验证过的。 所以总结一下，从30分到80分，核心就是三件事：AST加RAG解决项目级上下文、专有工具解决安全检测、再加上知识持续更新机制。 对，简单版两三小时能搞定，但真要做好，AST解析优化、向量数据库索引策略、RAG召回精度，每一块都值得深挖。 我回去得跟我们技术负责人好好聊聊这个架构了。李博，下次请你吃饭。 行，记得选贵的地方啊，毕竟我今天可是免费咨询。