1. 项目概述一个真正能落地的开源代码审查 CLI 工具“open-code-review”这个名字乍一听像某个 GitHub 上刚起步的玩具项目但如果你最近在团队里被 PR 堆得喘不过气、被“已阅”式人工 review 磨掉耐心、或者发现 junior 提交的代码里藏着三个未处理的空指针和一个硬编码的超时值——那你大概率已经站在了这个工具的真实需求入口。它不是另一个把 LLM 当万能胶水糊在 Git 上的 demo而是一个以工程交付为第一目标、以可嵌入 CI/CD 流程为设计原点、以最小心智负担完成高质量代码审查为最终效果的命令行工具。核心关键词 open-code-review、CLI、LLM、code review、git 全部不是装饰词它必须能通过npm install -g open-code-review或pipx install open-code-review一键安装必须支持ocr review --branch main --since 2024-05-20这类语义清晰的指令必须调用本地或远程 LLM如 Ollama 的 codellama:7b、Fireworks 的 CodeLlama-70b、或企业私有部署的 Qwen2.5-Coder完成结构化分析必须深度理解 Git 提交上下文不只是 diff 文本而是 commit message 语义、author 贡献历史、文件变更粒度、函数级 diff 范围最终输出必须是可被 IDE 解析的 SARIF 格式、可被 Jenkins/Jira 消费的 JSON 报告、或直接生成带行号锚点的 Markdown Review Comment。我去年在给一家做工业边缘网关的客户做 DevOps 咨询时亲眼见过他们用 Python 脚本 GPT-4 API 写了个“review bot”结果上线两周后就被叫停——不是因为不准而是因为每次 review 都要等 90 秒、报错信息全是“无法解析 JSON”、生成的 comment 里混着中英文、甚至把if (x ! null)错标成“建议改用 Optional”最后开发组长直接在 standup 里说“这玩意儿比我自己看还花时间。” 这就是为什么 open-code-review 的底层设计从第一天起就拒绝“LLM 优先”幻觉它把 LLM 当作一个高精度但高延迟的“专家顾问”而把 Git、AST 解析、规则引擎、上下文裁剪当作“项目经理”——前者只负责回答“这段逻辑是否可能引发竞态”后者负责提前准备好线程安全上下文、锁持有范围、相关单元测试覆盖率并把问题压缩到 300 字以内再喂给模型。它不追求“全代码理解”只确保“关键风险不漏判”。适合三类人一是中小型技术团队的 Tech Lead需要在不增加人力成本的前提下守住交付质量底线二是独立开发者想在 push 前自动拦截低级错误三是高校课程助教用一条命令批量扫描学生作业中的典型 bug 模式比如忘记 close Stream、SQL 注入点、硬编码密钥。它解决的从来不是“能不能用 LLM 做 code review”而是“怎么让 LLM 在真实工程流水线里不掉链子”。2. 整体架构与设计哲学为什么不做 Web UI也不搞 Agent 编排2.1 拒绝“大模型即平台”的陷阱当前很多所谓“AI Code Review”工具本质是把 ChatGPT 界面套个壳再加个“上传 diff”按钮。这种设计在 Demo 场景下很炫但在生产环境里是灾难。open-code-review 的第一原则是LLM 永远不作为主流程调度者只作为特定子任务的推理单元。举个具体例子当检测到一个新增的 HTTP 客户端调用时传统方案会把整个文件 diff 发给 LLM让它“自己判断是否有超时设置”。而 open-code-review 的流程是静态规则预筛用 Tree-sitter 解析 AST定位所有new OkHttpClient()或RestTemplate实例化节点上下文提取提取该实例化所在函数的全部参数、调用栈深度、是否在 try-catch 中、关联的配置类是否存在ConfigurationProperties注解结构化 prompt 构造生成类似这样的输入【任务】判断以下 OkHttpClient 初始化是否存在超时风险 【代码片段】 OkHttpClient client new OkHttpClient.Builder() .connectTimeout(10, TimeUnit.SECONDS) .readTimeout(30, TimeUnit.SECONDS) .build(); 【上下文】 - 所在方法fetchUserData(String userId) - 方法调用链Controller → Service → Dao → HTTP Client - 该方法 SLA 要求P99 800ms - 关联配置类AppConfig.java无 timeout 相关属性 【请仅返回 JSON字段{risk: true|false, reason: string, suggestion: string}】LLM 推理将此结构化输入发往模型超时阈值设为 8 秒失败则 fallback 到硬编码规则如“无 connectTimeout 默认值为 10s低于 SLA 要求”结果融合将 LLM 输出与静态规则结果合并生成 SARIF 条目包含ruleId: http-client-timeout、level: error、locations[0].physicalLocation.artifactLocation.uri: src/main/java/com/example/ClientService.java、locations[0].physicalLocation.region.startLine: 42。这个设计背后有三个硬性约束第一延迟可控——最慢环节是 LLM 推理但其他所有步骤都在毫秒级完成整条链路 P95 12s实测 Ollama codellama:7b 在 M2 Ultra 上平均 4.2s第二结果可验证——每个 SARIF 条目都标注了触发规则static-rule或llm-rule审计时可回溯是哪条正则匹配、哪个 AST 节点触发、还是哪次 LLM 调用生成第三故障隔离——LLM 服务宕机时静态规则仍正常工作只是部分高级检查如“是否违反领域特定业务规则”失效不影响基础质量门禁。提示不要试图让 LLM “理解整个系统”。我们做过对比实验把一个含 12 个类、3 个 Spring Bean、2 个 REST Controller 的微服务模块 diff 全量喂给 Qwen2.5-Coder准确率仅 63%且 40% 的 false positive 来自对 Spring AOP 代理机制的误判。而分层裁剪后针对 Controller 层的鉴权逻辑检查准确率达 98.7%因为上下文被严格限定在PreAuthorize注解及其 SpEL 表达式范围内。2.2 CLI 优先为什么命令行才是工程化的终极形态你可能会问为什么不做 VS Code 插件或 Web 控制台答案很现实真正的代码审查发生在提交前pre-commit、CI 流水线中post-merge、以及代码入库后on-demand这三个不可跳过的工程节点而 CLI 是唯一能无缝接入全部场景的载体。VS Code 插件只能覆盖 developer 本地场景却无法在 Jenkins Pipeline 里运行Web 控制台依赖服务器运维而很多金融/政企客户连内网都不允许开 HTTP 服务。open-code-review 的 CLI 设计遵循 Unix 哲学“do one thing and do it well”它只做三件事输入解析、审查执行、结果输出。所有输入源统一为 Git 仓库状态--commit,--branch,--pr-number所有输出格式可选--format sarif,--format markdown,--format json所有配置通过.open-code-review.yaml文件声明而非交互式问答。它的安装方式刻意避开复杂依赖macOSbrew install open-code-reviewHomebrew formula 已维护Linuxcurl -sSL https://get.open-code-review.dev | sh校验 SHA256 后安装二进制Windowswinget install open-code-reviewMicrosoft Store 兼容全平台pipx install open-code-reviewPython 3.9自动隔离虚拟环境最关键的是它完全兼容 Git 的 plumbing 命令。比如你想在 pre-commit hook 中强制检查只需在.git/hooks/pre-commit里写#!/bin/sh # 检查本次提交是否修改了 src/main/java/ 下的 Java 文件 if git diff --cached --name-only | grep -q ^src/main/java/.*\.java$; then if ! open-code-review review --staged --rules java-security --fail-on error; then echo ❌ open-code-review found critical issues. Please fix before commit. exit 1 fi fi这段脚本会在每次git commit时自动触发且只扫描实际变更的 Java 文件不碰 test 或 resources 目录。它不依赖任何后台服务不占用内存常驻进程git commit的体验和原来一模一样——这才是工程师愿意长期使用的工具该有的样子。2.3 Git 深度集成不是“读 diff”而是“懂提交意图”很多 CLI 工具把 Git 当作 diff 生成器git diff HEAD~1一跑完就不管了。open-code-review 则把 Git 视为代码意图的权威信源。它会主动解析以下 Git 元数据Commit message 结构化使用 Conventional Commits 规范如feat(auth): add JWT token refresh logic自动识别变更类型feature/fix/docs/chore、影响模块auth、操作动词add从而动态加载对应规则集auth-rules.yamlAuthor 历史画像查询该 author 过去 30 天内提交中高频出现的 bug 类型如某人 70% 的 PR 都漏写 null check在本次 review 中提升对应规则权重Branch lineage 分析若当前分支基于release/2.3.0则自动启用release-checklist规则组如禁止新增 debug log、强制检查降级开关File change context不只是看UserService.java的 diff还会检查本次提交是否同时修改了UserServiceTest.java测试覆盖率变化、application.yml配置项变更、pom.xml依赖升级构建跨文件影响图。举个实战案例当检测到pom.xml中spring-boot-starter-web从2.7.18升级到3.2.0工具会自动触发“Spring Boot 3 迁移检查”规则组扫描所有RestController类是否已替换ResponseEntity为ResponseEntityT泛型、所有WebMvcConfigurer是否已移除addInterceptors中的过时方法签名、所有Value(${prop})是否已迁移到ConfigurationProperties。这些检查不是靠 LLM 猜而是内置了 Spring Boot 官方迁移指南的结构化规则库JSON Schema 描述LLM 只在规则库未覆盖的边缘 case如自定义 Filter 的doFilter方法是否正确调用chain.doFilter才介入。这种设计让工具具备了“越用越懂你团队”的能力。我们给某电商客户部署后前三个月主要靠静态规则准确率 82%第六个月 LLM 辅助比例升至 35%但整体准确率反升至 94.3%——因为 LLM 不再被要求“从零理解”而是专注解决规则引擎无法覆盖的模糊地带。3. 核心模块拆解与实操细节3.1 规则引擎YAML 驱动的可编程审查逻辑open-code-review 的灵魂不在 LLM而在其规则引擎。所有检查逻辑都定义在.open-code-review/rules/目录下的 YAML 文件中格式高度结构化支持条件分支、上下文注入、LLM 回调。一个典型的 Java 空指针防护规则null-check.yaml如下id: java-null-check name: Java Null Pointer Protection description: Detect missing null checks before method calls or field access severity: error language: java scope: function # 作用域函数级 enabled: true conditions: - ast_type: MethodInvocation children: - ast_type: MemberSelectExpression children: - ast_type: Identifier name: method_name value: equals - ast_type: FieldAccess children: - ast_type: Identifier name: field_name value: id actions: - type: static pattern: if \\(.* null\\) \\{.*\\} message: Null check exists but may be insufficient for chained calls - type: llm prompt_template: | Analyze the following Java code snippet. Does it contain a safe null check before calling {{method_name}} on {{field_name}}? Code: {{code_snippet}} Context: - Method signature: {{method_signature}} - Caller class: {{caller_class}} - Is this in a Service bean? {{is_service}} Return JSON: {safe: true|false, reason: string} model: codellama:7b timeout: 5000 fallback: unsafe output: - sarif_rule_id: java-null-check - sarif_message: {{reason}} - sarif_level: {{error if not safe else warning}}这个规则的关键在于conditions和actions的分离conditions用 AST 匹配快速定位可疑节点如obj.equals(test)actions中的static分支用正则快速验证基础防护llm分支才启动模型进行深度语义判断。prompt_template里的{{method_name}}、{{field_name}}等变量由 AST 解析器在运行时注入确保 LLM 输入永远是精准裁剪后的上下文而非原始 diff。实操中我们发现规则编写有两大坑一是过度依赖 LLM 导致性能雪崩二是正则表达式太宽泛造成误报。解决方案是建立三层规则分级等级触发条件响应方式典型场景占比实测Level 0硬规则AST 精确匹配静态判定Thread.sleep(1000)在非测试代码中42%Level 1软规则AST 正则组合静态判定 置信度评分String sql SELECT * FROM user WHERE id id;35%Level 2智能规则Level 0/1 未覆盖的模糊 caseLLM 推理Optional.ofNullable(user).map(u - u.getName()).orElse(anonymous)是否可简化为user?.getName() ?: anonymous23%注意Level 2 规则必须配置fallback字段。我们曾遇到某客户私有 LLM 因 token 限制截断长方法体导致fallback: unsafe被误触发结果所有 Level 2 检查都报 error。后来改为fallback: review-manually并在 SARIF 输出中添加properties.reviewRequired: true字段强制人工复核避免误伤。3.2 LLM 集成不只是调 API而是构建可验证的推理管道LLM 在 open-code-review 中不是黑盒而是一个可监控、可回滚、可审计的推理组件。其集成设计包含四个核心层模型适配器层Model Adapter统一抽象不同 LLM 的 API 差异。目前支持Ollama本地http://localhost:11434/api/chatFireworks云https://api.fireworks.ai/inference/v1/chat/completionsTogether AIhttps://api.together.xyz/v1/chat/completions自定义 HTTP endpoint需符合 OpenAI 兼容协议每个适配器都实现generate(prompt: str, config: dict) - dict接口返回标准化结构{ text: model output, usage: {prompt_tokens: 120, completion_tokens: 85}, model: codellama:7b, latency_ms: 4210, raw_response: {...} // 原始 API 响应用于 debug }Prompt 工程层Prompt Engine拒绝“大段自然语言描述”。所有 prompt 都采用rolecontent/role标签结构化强制模型遵守 JSON Schema。例如 Java 安全规则的 promptsystemYou are a senior Java security engineer. Output ONLY valid JSON matching this schema: {vulnerable: true|false, cwe_id: CWE-79, evidence_line: 42, suggestion: Use HttpOnly flag}./system userCode snippet: Cookie cookie new Cookie(session, token); response.addCookie(cookie); /user这种格式让模型输出可被json.loads()直接解析避免了传统方案中用正则提取 JSON 的脆弱性。结果校验层Output Validator对 LLM 返回内容做三重校验语法校验json.loads()是否成功Schema 校验字段名、类型、必填项是否符合预期逻辑校验如evidence_line是否在代码片段行数范围内suggestion是否包含可执行动作动词use/add/remove/replace。任一校验失败立即触发 fallback 并记录validation_error事件到 audit log。缓存与重试层Cache Retry对相同代码片段 相同 prompt 的组合启用 LRU cache默认 1000 条。重试策略为首次失败后等待 1s第二次失败后等待 2s第三次失败直接 fallback。缓存 key 由sha256(prompt code_snippet model_name)生成确保内容一致性。实测数据显示这套设计让 LLM 调用成功率从裸 API 的 89.2% 提升至 99.7%平均延迟降低 37%因 cache 命中率 68%。更重要的是它让 LLM 的输出变得可预测——你可以写单元测试验证validate_output({vulnerable: true, cwe_id: CWE-79})是否通过这在传统“自由生成”模式下是不可能的。3.3 Git 上下文提取器从 diff 到意图的翻译器open-code-review 的 Git 集成不是调git diff就完事而是构建了一个完整的“提交意图翻译器”。它通过以下步骤将原始 Git 数据转化为结构化审查输入Step 1Diff 解析与文件分类使用git diff-tree -r --no-commit-id --name-only -z HEAD获取变更文件列表按后缀分类*.java,*.py,*.ts→ 交由对应语言的 AST 解析器Tree-sitter*.yml,*.json,*.xml→ 交由 Schema Validator如 Kubernetes YAML 用 kubeval*.md,*.txt→ 交由拼写与术语检查器Aspell 自定义术语表Step 2AST 构建与变更定位以 Java 为例用 Tree-sitter 加载java.so语法树对每个变更文件执行tree.rootNode().descendantsOfType(method_declaration)获取所有方法对比HEAD和HEAD~1的 AST定位新增/修改/删除的方法节点提取每个变更方法的startPosition,endPosition,type,name,parameters。Step 3语义上下文注入这是最关键的一步。工具会主动查询 Git 历史为每个变更节点注入语义标签git log -n 5 --prettyformat:%h %s --greprefactor -- src/main/java/com/example/UserService.java→ 若命中标记为refactor_intent: truegit blame -L 42,5 src/main/java/com/example/UserService.java→ 获取每行代码的 author 和 commit hash统计该 author 在同类文件中的 bug 率git show HEAD:pom.xml | xmllint --xpath //dependency[groupIdorg.springframework.boot]/version/text() - 2/dev/null→ 提取 Spring Boot 版本决定启用哪套规则Step 4上下文裁剪与打包最终生成的审查单元Review Unit是一个 Python dict{ file_path: src/main/java/com/example/UserService.java, change_type: modify, ast_node: { # Tree-sitter node 的序列化 type: method_declaration, start_point: [42, 0], end_point: [68, 2], children: [...] }, git_context: { commit_message: fix(user): prevent NPE in updateUser, author: aliceexample.com, author_bug_rate: 0.12, base_branch: develop, is_release_candidate: False }, language_context: { framework: spring-boot-3.2, jdk_version: 17, has_test_coverage: True } }这个结构体才是 LLM 真正接收的输入而不是原始 diff 文本。它让模型从“猜代码在干什么”变成“基于明确事实做推理”准确率提升显著。实操心得我们最初尝试直接喂 diff 文本给 LLM结果在处理 Kotlin 的data class时频繁误判——因为 diff 显示data class User(val name: String, val email: String)LLM 以为这是新增类实际是修改了现有类的构造函数。引入 AST 后通过node.type class_declaration and node.child_by_field_name(body).type data_class_body精准识别问题彻底解决。3.4 输出格式与集成SARIF 是底线不是终点open-code-review 的输出设计遵循“向后兼容向前扩展”原则。默认输出是 SARIF v2.1.0 格式这是 GitHub、Azure DevOps、SonarQube 等平台的标准输入确保开箱即用。但它的真正价值在于可编程的输出管道SARIF 模式--format sarif生成标准 SARIF包含runs[0].tool.driver.rules、runs[0].results、runs[0].artifacts支持partialFingerprints用于结果去重。Markdown 模式--format markdown生成可直接粘贴到 GitHub PR 的评论自动插入!-- open-code-review --HTML 注释作为标识方便后续自动化清理。JSON 模式--format json输出扁平化结构字段包括rule_id,file,line,message,severity,confidence0.0-1.0供自定义 Dashboard 消费。Custom Hook 模式--hook ./scripts/post-review.sh允许用户指定任意 shell 脚本在审查完成后执行如自动创建 Jira ticket、发送飞书通知、或触发修复 PR。一个典型的飞书集成脚本post-review.sh#!/bin/bash # $1 SARIF file path # $2 Git branch name # $3 Commit hash # 提取严重问题数 critical_count$(jq .runs[0].results | map(select(.level error)) | length $1) if [ $critical_count -gt 0 ]; then # 构造飞书卡片消息 payload$(cat EOF { msg_type: interactive, card: { elements: [ { tag: div, text: { content: open-code-review 发现 $critical_count 个严重问题\n分支$2\n提交$3, tag: lark_md } } ], header: { title: { content: 代码审查警报, tag: plain_text } } } } EOF ) # 发送飞书机器人 curl -X POST https://open.feishu.cn/open-apis/bot/v2/hook/xxx \ -H Content-Type: application/json \ -d $payload fi这种设计让工具不绑定任何特定平台。客户可以用它对接钉钉、企业微信、Slack甚至打印到物理打印机——只要你的 hook 脚本能处理 JSON 输入。4. 实操全流程从零部署到生产级使用4.1 环境准备与安装验证部署 open-code-review 的第一步不是写配置而是确认你的环境满足三个硬性条件Git 必须是 2.25 版本旧版 Git 的diff-tree输出格式不一致会导致文件分类错误。验证命令git --version # 应输出 git version 2.25.0 or higher git config --global core.autocrlf input # Windows 用户必须设置避免 CRLF 混乱Tree-sitter 运行时可用工具依赖 Tree-sitter 解析 AST需预装对应语言的 parser。一键安装脚本# macOS brew install tree-sitter npm install -g tree-sitter-cli tree-sitter build-wasm # 生成 WASM parser备用 # Ubuntu/Debian sudo apt-get install -y build-essential cmake pkg-config git clone https://github.com/tree-sitter/tree-sitter.git cd tree-sitter make sudo make install # 安装 Java parser其他语言同理 tree-sitter generate https://github.com/tree-sitter/tree-sitter-java tree-sitter buildLLM 后端就绪推荐从本地 Ollama 开始避免网络依赖。安装并拉取模型# macOS/Linux curl -fsSL https://ollama.com/install.sh | sh ollama run codellama:7b # 首次运行会自动下载 ollama list # 确认 codellama:7b 在列表中安装 open-code-review 本身极简# 全局安装推荐 pipx install open-code-review # 验证安装 open-code-review --version # 应输出 v0.8.3 open-code-review review --help # 查看完整命令选项 # 测试基础功能无需 LLM open-code-review review --staged --format json --rules java-basic # 若报错 No staged changes说明 Git 环境正常只是暂无暂存区变更注意pipx是关键。它会为 open-code-review 创建独立虚拟环境避免与项目依赖冲突。我们曾遇到客户用pip install全局安装结果因requests版本不兼容导致 Git API 调用失败排查耗时 3 小时。pipx的隔离性是生产环境稳定性的基石。4.2 首次审查用最小可行配置跑通流程不要一上来就配置 50 条规则。按以下三步走10 分钟内看到结果Step 1初始化配置文件在项目根目录创建.open-code-review.yaml# 最小配置仅启用 Java 基础规则 rules_dir: .open-code-review/rules models: default: codellama:7b fallback: llama3:8b git: base_branch: main output: format: markdown max_results: 50Step 2创建测试变更故意制造一个易检测的问题# 修改一个 Java 文件 echo public class Test { public void bad() { String s null; s.length(); } } src/test/java/Test.java git add src/test/java/Test.java git commit -m test: add null dereferenceStep 3执行审查open-code-review review --commit HEAD --rules java-basic预期输出是一段 Markdown包含问题定位src/test/java/Test.java:2:16规则 IDjava-null-dereference严重等级error建议Add null check before calling length()如果看到这个输出恭喜你的 pipeline 已打通。此时可以逐步增加规则# 添加安全规则 open-code-review review --commit HEAD --rules java-basic,java-security # 添加性能规则需额外安装 JVM profiler open-code-review review --commit HEAD --rules java-basic,java-security,java-performance4.3 生产级配置CI/CD 集成与质量门禁真正的价值体现在 CI 流水线中。以下是 Jenkins Pipeline 的标准集成模板pipeline { agent any stages { stage(Checkout) { steps { checkout scm } } stage(Code Review) { steps { script { // 安装 open-code-review仅首次运行 if (!fileExists(.open-code-review-installed)) { sh pipx install open-code-review sh touch .open-code-review-installed } // 执行审查失败时中断流水线 sh open-code-review review \\ --branch ${BRANCH_NAME} \\ --since ${GIT_PREVIOUS_COMMIT} \\ --rules java-security,java-performance \\ --fail-on error \\ --format sarif review-results.sarif } } } stage(Publish Results) { steps { // 上传 SARIF 到 SonarQube sh sonar-scanner -Dsonar.sarifReportPathsreview-results.sarif // 或上传到 GitHub需配置 GITHUB_TOKEN sh gh extension install github/gh-sarif gh sarif upload review-results.sarif --github-auth ${GITHUB_TOKEN} } } } }关键参数说明--since ${GIT_PREVIOUS_COMMIT}只审查本次构建引入的变更避免全量扫描拖慢流水线--fail-on error当发现error级别问题时open-code-review进程返回非零退出码Jenkins 自动标记 stage 失败--rules显式指定规则组避免加载无关规则浪费资源。对于 GitHub Actions.github/workflows/code-review.yml更简洁name: Code Review on: [pull_request] jobs: review: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 with: fetch-depth: 0 # 必须获取完整历史用于 git log 分析 - name: Install open-code-review run: pipx install open-code-review - name: Run code review run: | open-code-review review \ --pr-number ${{ github.event.number }} \ --rules java-security,java-performance \ --fail-on error \ --format sarif review.sarif - name: Upload SARIF uses: github/codeql-action/upload-sarifv2 with: sarif_file: review.sarif实操心得我们给某银行客户部署时发现他们的 Jenkins slave 节点内存只有 2GB而codellama:7b在 Ollama 中默认占用 3.2GB。解决方案是在 Jenkinsfile 中添加sh ollama run --num_ctx 512 codellama:7b预热模型再执行open-code-review并将--model参数设为codellama:7b。这样模型常驻内存后续调用无需重复加载单次审查内存峰值降至 1.8GB。4.4 规则定制从复制模板到编写专属规则open-code-review 内置 127 条通用规则Java/Python/TypeScript 各约 40 条但每个团队都有独特规范。定制规则分三步Step 1复制模板# 创建规则目录 mkdir -p .open-code-review/rules/my-team/ # 复制 Java 空指针规则作为起点 cp $(python -c import open_code_review; print(open_code_review.__path__[0]))/rules/java-null-check.yaml .open-code-review/rules/my-team/null-check-enhanced.yamlStep 2修改规则逻辑编辑null-check-enhanced.yaml强化对 SpringService类的检查# ... 原有条件保持不变 actions: - type: static pattern: Service.*public class.* message: Service class detected. Enhanced null check required. - type: llm prompt_template: | systemYou are a Spring Framework expert. Check if the following Service method handles null inputs safely./system userMethod: {{code_snippet}} Context: - Class has Service annotation: {{is_service}} - Method is transactional: {{is_transactional}} - Called by REST controller: {{is_rest_controller_caller}} Return JSON: {safe: true|false, missing_check: [param1, param2], suggestion: string}/user