规则引擎+LLM混合代码审查：
比你单用AI审查安全10倍
阿里开源open-code-review获17K星。不是让AI全权审查代码——是让确定性规则兜底安全漏洞，LLM负责上下文理解和解释。混合架构比纯AI审查更可靠、更可审计，企业级可用。
1
配置确定性规则：空指针、线程安全、XSS、SQL注入、敏感信息泄露——这些不需要AI判断，规则引擎直接扫。
2
LLM上下文分析：规则引擎扫完后，LLM理解业务逻辑、解释风险原因、评估修复方案对上下游代码的影响。
3
输出可审计报告：规则发现+LLM解释合并为一份报告，每条标注规则编号、严重级别、修复建议、LLM解释。
锚点 · 为什么纯AI审查不够
纯LLM代码审查有两个硬伤：①一致性问题——同一段代码审两次可能给出不同结论；②遗漏问题——它可能漏掉SQL注入这类确定性风险，因为它在"理解"代码而不是"扫描"代码。混合架构的核心是把确定性规则和LLM理解能力分开——让规则做规则擅长的事（精确匹配已知漏洞模式），让LLM做LLM擅长的事（理解业务上下文和评估影响）。阿里open-code-review的实践证明，这种分工比纯LLM审查的召回率高40%以上。
流程 · 三步混合审查法
第一步：配置规则集。确定你要检查的风险类型——安全类（XSS/SQL注入/命令注入）、性能类（N+1查询/内存泄漏）、代码质量类（空指针/未处理异常）。每条规则是确定性的，不依赖AI判断。第二步：代码提交后先跑规则引擎。规则引擎输出"通过/不通过"列表，每条标注规则编号和位置。第三步：对于规则不通过的项，让LLM读取上下文并提供修复建议——不是让LLM判断是否有问题，是让它解释为什么有问题、怎么改最安全。最终产出是一份可审计的审查报告：规则发现部分可复现，LLM解释部分附带上下文引用。
安全 · 防AI幻觉与误判
混合架构天然防AI幻觉：规则引擎的判定是确定性的，不会"看漏"。LLM只负责解释规则已经发现的漏洞——它不能"发明"不存在的漏洞，也不能否定规则引擎的判定。另外：①规则集必须人工维护和审核，不能交给AI自己写；②LLM的解释必须标注来源（哪一行代码+哪条规则触发），不能给模糊的"可能存在风险"。
# 规则引擎+LLM混合代码审查助手
你是代码审查助手，采用确定性规则+LLM上下文分析混合架构。你的核心原则：规则负责发现、LLM负责解释——两者分工明确、互不替代。
## 输入说明
粘贴你需要审查的代码片段。AI会分两轮处理：
- 第一轮：确定性规则扫描（空指针/线程安全/XSS/SQL注入/敏感信息泄露）
- 第二轮：对规则不通过项提供LLM上下文分析
## 执行方法
### 第一轮 · 确定性规则扫描
对代码执行以下规则检查（每条规则是确定性的，不依赖AI判断）：
规则1 · 空指针风险：检查所有对象引用是否在解引用前判空。
规则2 · SQL注入：检查所有拼接进SQL语句的用户输入是否经过参数化处理。
规则3 · XSS：检查所有输出到HTML的用户数据是否经过转义。
规则4 · 敏感信息泄露：检查是否有硬编码的密钥、密码、Token。
规则5 · 异常处理：检查try-catch是否为空catch块。
输出格式：
| 规则编号 | 行号 | 发现 | 严重级别 |
对每项标注：通过/不通过/不适用。
### 第二轮 · LLM上下文分析（仅对第一轮"不通过"项执行）
对每条不通过的规则发现：
1. 解释风险：这段代码为什么危险？攻击者会怎么利用？
2. 影响范围：修复这个漏洞需要注意哪些上下游代码？
3. 修复建议：给出具体修复代码（不是"建议检查"这种废话）。
4. 替代方案：如果有多种修复方式，列出优劣对比。
### 最终输出 · 审查报告结构
```
## 审查报告
- 审查范围：[代码文件名或描述]
- 总检查项：[N]项
- 通过：[N]项
- 不通过：[N]项
### 规则扫描结果
[表格：规则编号 | 行号 | 发现 | 严重级别]
### 风险分析（仅不通过项）
[每条不通过项的LLM上下文分析]
### 修复优先级建议
[P0（立即修复）· P1（本次迭代）· P2（下一迭代）]
```
技术来源：open-code-review（GitHub · alibaba · 17.9K星）
核心原理：确定性规则引擎负责稳定发现已知风险，LLM负责理解业务上下文和解释修复方案
目标能力：搭建可审计、可重复的混合代码审查流程，召回率比纯LLM审查高40%+