开源代码审查方法论：行级批注与跨语言规则集实践

1. 项目概述这不是一个工具而是一套可落地的开源代码审查方法论“open-code-review”这个词乍一听像某个新发布的开源项目名但其实它代表的是一种正在快速演进的工程实践范式——把代码审查这件事从过去依赖人工经验、团队默契、甚至个人风格的黑箱过程变成一套可定义、可配置、可复现、可审计的开放系统。我做后端架构和代码质量体系建设有十二年带过七支不同技术栈的团队从早期用 Gerrit 手动打钩到后来接入 SonarQube 做静态扫描再到近两年全面转向 LLM 辅助的细粒度审查踩过的坑比写过的代码还多。今天说的 open-code-review核心不是“用哪个大模型”而是“怎么让模型真正嵌入开发流且不被当成摆设”。它必须同时满足三个硬约束能对line-level comments行级批注精准定位、支持multi-language ruleset跨语言规则集统一管理、审查逻辑本身是open的——即规则可读、可改、可验证、可版本化。这直接决定了它能不能在真实项目里活过两周。比如你用 DeepSeek-Coder-32B 做 Python 审查很稳但切换到 Rust 就报错或者规则写在 prompt 里根本没法 diff 和 review那它就只是个玩具。真正的 open-code-review应该像 CI 配置一样放在 .github/workflows/ 下像 ESLint 规则一样存在 .eslintrc.js 里像单元测试一样能跑出明确的 pass/fail。它解决的不是“有没有 AI”而是“AI 的判断能不能被工程师信任、质疑、修正和传承”。这个内容适合三类人一是技术负责人或质量工程师需要构建可持续的代码质量防线二是资深开发者想摆脱低效的 PR 评论疲劳把精力聚焦在架构决策上三是刚接触 LLM 工程化的同学需要避开“调 API 就完事”的认知陷阱。它不教你怎么调用 OpenAI 接口而是告诉你当一行 Go 代码被标记为“潜在竞态风险”时背后触发的是哪条规则这条规则的判定依据是 AST 解析、数据流追踪还是纯文本 pattern 匹配它的置信度阈值是多少误报时如何快速降权这些细节才是 open-code-review 的真实战场。2. 整体设计思路为什么必须放弃“LLM 单点替代人工”的幻想2.1 核心误区把 LLM 当成“更聪明的 linter”很多团队一上来就搞“AI Code Review Bot”结果三个月后全部停用。原因很直接他们把 LLM 当成了升级版的 ESLint 或 Checkstyle。但 LLM 和传统静态分析器有本质区别。ESLint 是确定性系统——你给它一条规则no-console它遍历 AST 找console.log调用找到就报错没找到就不报结果 100% 可复现。而 LLM 是概率性系统——同一段代码同个 prompt两次调用可能给出完全不同的 line-level comments一次说“这里缺少空指针检查”另一次说“命名不符合规范”。这不是模型不稳定而是其底层机制决定的它输出的是 token 概率分布采样结果。我实测过 DeepSeek-Coder-32B 在相同硬件、相同 temperature0.1 下对同一段 Java 代码做 10 次审查comment 位置重合率只有 63%关键建议分歧率达 28%。这意味着如果直接把 LLM 输出当最终结论PR 流程会陷入“这次 AI 说要改下次又说不用改”的信任危机。所以 open-code-review 的第一设计原则是LLM 不是裁判而是协审员。它的角色是生成“待验证线索”而非下达“终审判决”。真正的决策权必须保留在工程师手中而系统要做的是把线索组织得足够清晰、可追溯、可证伪。比如当 LLM 提示“第 47 行变量userCache可能引发内存泄漏”系统必须同步给出① 这条线索对应的规则 ID如rule-java-memory-leak-003② 触发该规则的原始上下文前 5 行 后 5 行代码 对应 AST 片段③ 该规则的历史误报率统计过去 30 天同类提示被人工驳回的比例④ 快速验证按钮点击自动运行jstack抓取当前线程堆栈或启动内存分析器采样。没有这些支撑再准的 LLM 提示也只是噪音。2.2 架构分层从“模型即服务”到“规则即代码”我们团队落地 open-code-review 时彻底放弃了“LLM-as-a-service”模式转而采用四层解耦架构规则层Ruleset所有审查逻辑以代码形式存在用 TypeScript 编写每个规则导出id、name、description、languages支持的编程语言数组、severity严重等级、match匹配函数接收 AST 节点和源码字符串返回 boolean、suggest建议生成函数接收匹配节点返回结构化 comment 对象。例如一条 Python 规则检测未处理的异常export const rule_py_unhandled_exception { id: py-unhandled-exception-001, name: 未捕获的异常, description: except 子句中仅包含 pass未做任何错误处理, languages: [python], severity: high, match: (node: any, code: string) { return node.type ExceptHandler node.body.length 1 node.body[0].type Pass; }, suggest: (node: any) ({ line: node.lineno, message: 空 except 子句会吞掉所有异常建议记录日志或重新抛出, suggestion: logger.error(Exception caught, exc_infoTrue) }) };这些规则文件统一存放在rules/目录下和业务代码一起 Git 管理每次 PR 都触发规则 diff 检查。代理层Agent这里的 Agent 不是“智能体”而是规则调度器。它不生成任何自然语言只做三件事① 根据 PR 修改的文件后缀加载对应 language 的规则子集② 对每个修改行调用所有匹配规则的match函数③ 对命中的规则调用其suggest函数生成结构化建议。Agent 的输出是纯 JSON 数组格式固定[ { ruleId: py-unhandled-exception-001, file: src/auth.py, line: 89, message: 空 except 子句会吞掉所有异常..., suggestion: logger.error(\Exception caught\, exc_infoTrue) } ]增强层LLM Augmentation这才是 LLM 真正发力的地方。它只接收 Agent 输出的结构化 JSON不做任何代码解析。任务非常明确① 把message和suggestion翻译成符合团队语境的自然语言比如把“空 except 子句”改成“当前捕获异常后直接 pass线上无法感知故障”② 补充上下文解释如“该异常来自上游 service 调用若不处理会导致用户请求静默失败”③ 生成 1~2 行可直接粘贴到 GitHub 评论框的 Markdown 格式文本。关键点在于LLM 的输入是确定性的JSON输出是受控的长度限制、模板约束且全程可审计——你可以回溯某条评论精确知道它由哪条规则触发、经哪个 LLM 模型润色、用了什么 prompt 版本。集成层CI/CD Orchestration通过 GitHub Actions 工作流串联。pull_request事件触发后先运行 Agent 扫描生成结构化报告再并行调用 LLM 服务我们用本地部署的 Qwen2.5-7B处理报告最后将增强后的 comments 注入 PR。整个流程耗时控制在 90 秒内超时自动降级为只显示 Agent 原始建议。这种设计让每个组件各司其职规则层保证逻辑可验证Agent 层保证执行可复现LLM 层专注表达优化集成层保障流程可靠。比起“一个大模型包打天下”它更像一支分工明确的特种部队——规则是侦察兵Agent 是指挥官LLM 是战地记者CI 是运输机。2.3 为什么选择 multi-language ruleset 而非单语言模型微调热搜词里反复出现 “multi-language ruleset”这绝非噱头。我们曾尝试为每种语言单独微调一个 LLM用 CodeLlama 微调 Python 版用 StarCoder 微调 Java 版结果发现三个致命问题第一维护成本爆炸——7 种语言意味着 7 套训练 pipeline、7 个模型仓库、7 种 prompt 工程第二规则迁移困难——Python 的“未处理异常”规则很难直接迁移到 Go 的defer recover()场景因为 AST 结构和错误处理范式完全不同第三知识割裂——当一个 PR 同时修改 Python 后端和 TypeScript 前端时两个模型各自输出缺乏跨语言上下文关联比如前端调用的 API 在后端是否存在未校验参数。而 multi-language ruleset 的解法是“规则抽象 语言适配器”。我们定义了一套通用规则元模型Rule Schema包含trigger触发条件、context所需上下文范围、impact影响范围、remedy修复建议模板四个核心字段。然后为每种语言编写轻量级适配器Adapter负责把元模型映射到具体 AST。例如trigger: unhandled exception在 Python 适配器里匹配ExceptHandler节点在 Go 适配器里匹配recover()调用缺失在 TypeScript 适配器里匹配catch块为空。适配器代码不到 200 行却让同一套规则逻辑覆盖所有语言。目前我们的 ruleset 已支持 Python、Java、Go、TypeScript、Rust、Shell、SQL 七种语言新增语言只需实现一个适配器无需改动规则本身。这正是 open 的本质——规则开放而非模型开放。提示不要试图用一个大模型覆盖所有语言。模型擅长理解规则擅长定义。把定义权交给工程师把理解权交给模型这才是可持续的协作模式。3. 核心细节解析line-level comments 的精准锚定与可信度建设3.1 行级批注的三大陷阱与破解方案line-level comments 是 open-code-review 的用户体验核心但也是最容易翻车的环节。我见过太多团队的 AI Review Bot 在 PR 里乱标一气把注释打在离问题代码十行远的地方或者对同一行重复标注五次不同建议。根源在于没处理好三个底层问题陷阱一AST 节点与源码行号的映射漂移LLM 或静态分析器通常基于 AST 节点定位但 AST 节点的lineno字段在代码格式化、注释增删、空行调整时极易失准。比如一段 Python 代码def process_user(user): if user is None: return None # ← 这里是第 3 行 # 新增一行注释 data fetch_data(user.id) # ← 实际业务逻辑在第 5 行当开发者在第 3 行后插入注释fetch_data调用的 AST 节点lineno可能仍指向旧的第 4 行导致评论锚定到空白行。我们的解法是引入双坐标校验机制Agent 在生成建议时不仅记录 AST 节点的lineno还计算该节点在源码中的字符偏移范围start_pos/end_pos。提交到 GitHub 时API 要求提供line绝对行号和sidediff 上的相对位置我们通过比对 PR diff 内容动态将字符偏移映射到 diff 中的新行号。实测将锚定准确率从 72% 提升至 99.4%。陷阱二上下文截断导致建议失焦LLM 输入窗口有限常把“只给 20 行上下文”当成金科玉律。但很多问题需要跨函数、跨文件理解。比如一个 Go 函数里db.QueryRow调用未检查 error单纯看这行代码LLM 可能建议“加 err ! nil 判断”但实际该函数已用defer func() { if r : recover(); r ! nil { ... } }()全局兜底加判断反而冗余。我们的方案是Agent 在匹配规则时主动提取三级上下文——一级当前行 ±3 行、二级所在函数体全量、三级调用栈上游 2 层函数签名。LLM 增强阶段按优先级依次注入先塞一级上下文若 token 不足则丢弃三级保留二级。这样既控制成本又保障关键信息不丢失。陷阱三建议泛化导致可操作性归零最典型的例子是 LLM 评论“此处代码可读性较差建议重构”。这等于没说。open-code-review 要求每条 line-level comment 必须包含可执行动作Actionable Item。我们强制规定 comment 结构message问题本质≤15 字如“空 defer 可能掩盖 panic”reason技术依据≤30 字如“defer 语句未绑定函数调用panic 不会被捕获”suggestion具体修改精确到 token如“将defer fmt.Println()改为defer func(){...}()”reference权威依据链接如 Go 官方文档 defer 章节这套结构由 Agent 的suggest函数生成LLM 只负责把suggestion翻译成自然语言绝不允许它自由发挥。上线后工程师采纳建议的平均耗时从 8.2 分钟降至 1.7 分钟。3.2 可信度引擎让每条评论自带“可信分”光有精准锚定还不够。工程师看到 AI 评论的第一反应是“这建议靠谱吗” 我们在系统里内置了可信度引擎Trust Score Engine为每条评论动态计算 0~100 的可信分并在 GitHub 评论区显眼位置展示。计算逻辑融合四维信号规则历史置信度权重 40%统计该规则过去 30 天在同类代码场景下的采纳率。例如py-unhandled-exception-001在 Django 项目中采纳率 92%在 Flask 项目中仅 65%因 Flask 常用装饰器全局处理异常引擎会根据 PR 中的框架依赖自动加权。上下文完整性权重 25%检测 LLM 增强时是否获取了完整三级上下文。若因 token 限制丢失二级上下文可信分自动扣 15 分。模型稳定性权重 20%对同一条规则建议用同一模型做 3 次重试统计建议文本的编辑距离相似度。低于 80% 则降权。团队偏好校准权重 15%记录工程师对某类建议的驳回习惯。比如团队明确要求“禁止在 controller 层做数据库查询”则所有违反此约定的建议无论模型多准可信分上限 50。可信分不是装饰而是决策辅助。当分数 60 时评论自动折叠需手动展开当分数 85 时评论顶部显示绿色盾牌图标并附带“该建议已被团队采纳 23 次”的提示。这显著降低了工程师的认知负荷——他们不再需要逐条判断而是聚焦于中等可信度60~85的灰色地带那里才是真正需要专业判断的战场。注意可信分必须透明可查。我们在每条评论末尾添加小字链接“查看可信分详情”点击后弹出 modal清晰列出四项得分及计算依据。隐藏算法只会加速信任崩塌。3.3 multi-language ruleset 的实战落地以“资源泄漏”为例“资源泄漏”是跨语言高频问题但各语言实现机制差异巨大。我们用同一套规则元模型为不同语言编写适配器效果远超单模型方案。以rule-resource-leak为例Python 适配器监听with语句块外的open()、socket.socket()调用检查是否在finally或__exit__中关闭。关键逻辑是遍历 AST 的Call节点匹配func.id in [open, socket]再向上查找最近的Try节点验证finalbody是否包含close()调用。Go 适配器重点监控os.Open、sql.Open返回的*os.File、*sql.DB类型变量检查其作用域结束前是否调用Close()。利用 Go 的 SSAStatic Single Assignment中间表示追踪变量生命周期比纯 AST 分析准确率高 37%。TypeScript 适配器针对fetch()、XMLHttpRequest等网络请求检查then().catch()链是否完整或async/await函数是否包裹在try/catch中。特别处理AbortController场景验证signal是否被正确传递。有趣的是这三条适配器共用同一个remedy模板“请确保资源在使用后显式释放避免长时间占用系统句柄”。但具体实现建议天差地别Python 推荐with open(...) as f:Go 推荐defer file.Close()TypeScript 推荐controller.abort()。这种“规则统一、实现分离”的模式让规则库维护效率提升 5 倍——新增一种语言只需写适配器不用重写规则逻辑。我们还做了个压力测试用同一份含 127 处资源泄漏的混合代码库Python/Go/TS 各约 40 行分别跑单语言模型微调方案和 multi-language ruleset 方案。结果 ruleset 方案检出率 98.3%误报率 1.2%而三个微调模型平均检出率 86.7%误报率 8.9%。差距主要来自规则对语言特性的深度建模能力——模型再大也学不会 Go 的 defer 语义但规则可以。4. 实操过程详解从零搭建可运行的 open-code-review 系统4.1 环境准备与依赖安装整个系统基于 Node.js 18 构建核心依赖极简避免技术债。以下是生产环境实测有效的最小化配置运行时Node.js 18.18.2LTS 版本V8 引擎对 AST 解析优化最佳AST 解析器babel/parserJavaScript/TypeScript、tree-sitterPython/Go/Rust性能比 Babel 高 4 倍规则引擎自研轻量级rule-runner 300 行代码无外部依赖LLM 接口huggingface/inference对接本地 Hugging Face 模型或openai对接 OpenAI API需配置OPENAI_API_KEYCI 集成GitHub Actions使用actions/checkoutv4和actions/setup-nodev4安装命令所有操作在项目根目录执行# 初始化 npm npm init -y # 安装核心依赖 npm install babel/parser tree-sitter huggingface/inference openai # 安装开发依赖用于测试和 lint npm install --save-dev jest ts-jest types/jest # 创建必要目录结构 mkdir -p rules/{python,go,typescript} src/{agent,enhancer,utils} test关键点说明我们刻意避开 Webpack/Vite 等打包工具所有代码直接node src/index.js运行。原因很简单——CI 环境资源有限启动时间每多 1 秒PR 审查延迟就增加 1 秒。实测裸 Node 启动耗时 120msWebpack 打包后首次启动 850ms。对于高频触发的 PR 检查这点差异就是体验分水岭。实操心得不要在 CI 环境里做任何“构建”动作。所有依赖必须npm install一次性搞定代码必须开箱即用。我们曾因一个tsc --build步骤导致平均审查延迟飙升至 4.2 秒砍掉后回落到 0.8 秒。4.2 规则编写与管理让规则像代码一样被对待规则是 open-code-review 的心脏必须遵循严格规范。我们规定所有规则文件存放在rules/目录下按语言分组文件名格式为rule-{id}.ts如rule-py-unhandled-exception.ts。每个文件导出一个符合RuleSchema接口的对象// types/rule.ts export interface RuleSchema { id: string; // 全局唯一格式{lang}-{domain}-{seq} name: string; // 中文名称用于 UI 展示 description: string; // 详细描述含触发场景和危害 languages: string[]; // 支持的语言列表如 [python, typescript] severity: low | medium | high | critical; // 严重等级 match: (node: any, code: string, filePath: string) boolean; // 匹配函数 suggest: (node: any, code: string, filePath: string) Suggestion; // 建议生成函数 } export interface Suggestion { line: number; // 锚定行号基于文件绝对行号 message: string; // 问题本质 reason: string; // 技术依据 suggestion: string; // 具体修改精确到 token reference: string; // 权威链接 }以 Python 的“未处理异常”规则为例rules/python/rule-py-unhandled-exception.tsimport { RuleSchema, Suggestion } from ../../types/rule; export const rule_py_unhandled_exception: RuleSchema { id: py-unhandled-exception-001, name: 未捕获的异常, description: except 子句中仅包含 pass会静默吞掉所有异常导致故障不可见, languages: [python], severity: high, match: (node, code) { // 检查是否为 ExceptHandler 节点 if (node.type ! ExceptHandler) return false; // 检查 body 是否只有一行 pass if (node.body.length ! 1) return false; if (node.body[0].type ! Pass) return false; // 额外验证父节点是否为 Try 语句排除语法错误情况 const parent node.parent; return parent parent.type Try; }, suggest: (node, code) { const lines code.split(\n); const currentLine lines[node.lineno - 1] || ; // 生成具体建议替换 pass 为 logger.error const newLine currentLine.replace(/pass/i, logger.error(Exception caught, exc_infoTrue)); return { line: node.lineno, message: 空 except 子句会吞掉所有异常, reason: Python 中空 except 会捕获 BaseException 及其所有子类包括 KeyboardInterrupt、SystemExit导致程序无法正常退出, suggestion: 将 ${currentLine.trim()} 替换为 ${newLine.trim()}, reference: https://docs.python.org/3/tutorial/errors.html#handling-exceptions }; } };规则管理的关键实践版本化所有规则文件纳入 Git每次修改必须提交 commit message如feat(rules): add py-unhandled-exception-001 for Django projects。测试驱动每个规则必须配test/rules/python/rule-py-unhandled-exception.test.ts用 Jest 验证match和suggest函数。测试用例覆盖正例应匹配、反例不应匹配、边界例空 try 块、嵌套 except。禁用机制在rules/config.json中维护全局开关格式为{ py-unhandled-exception-001: true, go-resource-leak-002: false }。CI 流程启动时读取此文件动态加载启用的规则。4.3 Agent 调度器开发规则执行的核心引擎Agent 是整个系统的中枢代码必须极致简洁、高可靠。我们将其封装为src/agent/index.ts核心逻辑仅 120 行import * as fs from fs; import * as path from path; import { RuleSchema } from ../../types/rule; import { parse as babelParse } from babel/parser; import { Parser, Language } from tree-sitter; import { getLanguage } from tree-sitter-python; // 各语言导入 // 加载所有启用的规则 export function loadRules(lang: string): RuleSchema[] { const rulesDir path.join(__dirname, ../../rules, lang); if (!fs.existsSync(rulesDir)) return []; const config JSON.parse(fs.readFileSync(path.join(__dirname, ../../rules/config.json), utf8)); const ruleFiles fs.readdirSync(rulesDir).filter(f f.endsWith(.ts)); return ruleFiles .map(file { const ruleModule require(path.join(rulesDir, file)); const rule Object.values(ruleModule)[0] as RuleSchema; return config[rule.id] ? rule : null; }) .filter(Boolean) as RuleSchema[]; } // 主执行函数 export async function runAgent( filePath: string, code: string, lang: string ): PromiseSuggestion[] { const rules loadRules(lang); if (rules.length 0) return []; // 根据语言选择 AST 解析器 let ast: any; if (lang typescript || lang javascript) { ast babelParse(code, { sourceType: module, plugins: [typescript] }); } else { // 使用 tree-sitter 解析其他语言 const parser new Parser(); const language getLanguage(lang); // 从 tree-sitter-* 包导入 parser.setLanguage(language); const tree parser.parse(code); ast tree.rootNode; // 获取根节点 } const suggestions: Suggestion[] []; // 遍历所有规则 for (const rule of rules) { if (!rule.languages.includes(lang)) continue; // 递归遍历 AST 节点对每个节点调用 match const traverse (node: any) { if (rule.match(node, code, filePath)) { const suggestion rule.suggest(node, code, filePath); suggestions.push(suggestion); } // 递归子节点 if (node.children) { node.children.forEach((child: any) traverse(child)); } }; traverse(ast); } return suggestions; }Agent 的设计哲学是“宁可少不可错”。它不做任何 LLM 调用不处理网络请求不写磁盘只做纯内存计算。所有 I/O 操作读文件、调 LLM、写评论均由上层集成层完成。这种隔离让 Agent 可以在 100ms 内完成万行代码扫描且 100% 可单元测试。4.4 LLM 增强层用最小 prompt 实现最大表达力LLM 层的目标很明确把结构化Suggestion对象翻译成工程师愿意读、能立刻执行的自然语言评论。我们发现越复杂的 promptLLM 越容易失控。经过 37 轮 A/B 测试最终采用极简三段式 prompt你是一名资深软件工程师正在为团队代码审查提供辅助评论。请严格按以下要求处理输入 【输入】 { message: 空 except 子句会吞掉所有异常, reason: Python 中空 except 会捕获 BaseException 及其所有子类包括 KeyboardInterrupt、SystemExit导致程序无法正常退出, suggestion: 将 \pass\ 替换为 \logger.error(\\\Exception caught\\\, exc_infoTrue)\, reference: https://docs.python.org/3/tutorial/errors.html#handling-exceptions } 【要求】 1. 用中文输出语气专业、简洁、无废话 2. 第一行必须是 message 内容加粗 3. 第二行开始解释 reason用“这是因为”开头 4. 第三行给出 suggestion用“建议改为”开头 5. 最后一行附 reference 链接格式为“参考[链接文字](URL)” 6. 总长度不超过 120 字禁止添加任何额外信息。 【输出】实测对比复杂 prompt含角色设定、多轮示例、格式约束平均输出长度 187 字32% 的评论包含无关建议而上述极简 prompt 平均输出 98 字100% 符合格式且工程师采纳率高出 22%。关键洞察是LLM 不需要被“教育”它需要被“约束”。给它清晰的输入结构、明确的输出模板、严格的长度限制比灌输一堆“你应该怎样”有效得多。增强层代码src/enhancer/index.ts同样简洁import { Inference } from huggingface/inference; import { Suggestion } from ../../types/rule; const inference new Inference(process.env.HF_TOKEN); export async function enhanceSuggestion( suggestion: Suggestion ): Promisestring { const prompt 你是一名资深软件工程师正在为团队代码审查提供辅助评论。请严格按以下要求处理输入 【输入】 { message: ${suggestion.message}, reason: ${suggestion.reason}, suggestion: ${suggestion.suggestion}, reference: ${suggestion.reference} } 【要求】 1. 用中文输出语气专业、简洁、无废话 2. 第一行必须是 message 内容加粗 3. 第二行开始解释 reason用“这是因为”开头 4. 第三行给出 suggestion用“建议改为”开头 5. 最后一行附 reference 链接格式为“参考[链接文字](URL)” 6. 总长度不超过 120 字禁止添加任何额外信息。 【Output】 ; try { const response await inference.textGeneration({ model: Qwen/Qwen2.5-7B-Instruct, inputs: prompt, parameters: { max_new_tokens: 120, temperature: 0.1 } }); return response.generated_text; } catch (error) { // 降级策略返回原始 suggestion 的 message return **${suggestion.message}**\n建议参考规则说明${suggestion.reference}; } }4.5 GitHub Actions 集成让审查成为 PR 的默认流程最后一步是把所有模块串起来接入 GitHub。我们在.github/workflows/code-review.yml中定义工作流name: Open Code Review on: pull_request: types: [opened, synchronize, reopened] jobs: review: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 with: fetch-depth: 0 # 获取完整 git history用于 diff 分析 - name: Setup Node.js uses: actions/setup-nodev4 with: node-version: 18 - name: Install dependencies run: npm ci - name: Run Open Code Review env: HF_TOKEN: ${{ secrets.HF_TOKEN }} # 本地 Hugging Face 模型 token OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }} # 备用 OpenAI key run: | # 1. 解析 PR diff提取修改的文件及语言 CHANGED_FILES$(git diff --name-only origin/main...HEAD -- *.py *.go *.ts *.js *.java *.rs *.sh *.sql | head -50) # 2. 对每个文件运行 Agent Enhancer for file in $CHANGED_FILES; do if [ -f $file ]; then LANG$(echo $file | awk -F. {print tolower($NF)}) case $LANG in py) RULE_LANGpython ;; go) RULE_LANGgo ;; ts|js) RULE_LANGtypescript ;; java) RULE_LANGjava ;; rs) RULE_LANGrust ;; sh) RULE_LANGshell ;; sql) RULE_LANGsql ;; *) continue ;; esac # 读取文件内容 CONTENT$(cat $file) # 调用 Node.js 脚本执行审查 npx ts-node src/index.ts \ --file $file \ --code $CONTENT \ --lang $RULE_LANG \ --pr-number ${{ github.event.number }} \ --github-token ${{ secrets.GITHUB_TOKEN }} fi done关键细节diff 分析用git diff --name-only精确获取本次 PR 修改的文件避免全量扫描浪费资源。语言映射通过