1. 项目概述一个真正能落地的开源代码审查 CLI 工具“open-code-review”这个名字乍一听像某个 GitHub 上刚建的空仓库但如果你最近在团队里被 PR 堆得喘不过气、被“请 review 这段代码”钉在 Slack 里反复艾特、或者自己提完 MR 就开始焦虑地刷新页面等反馈——那你大概率已经站在了这个工具的真实需求入口。它不是另一个包装精美的 LLM 玩具而是一个以 Git 为输入源、以 CLI 为唯一交互界面、以可复现的结构化输出为目标的轻量级自动化代码审查系统。核心关键词 open-code-review、CLI、LLM、code review、git 全部不是装饰词open 指的是整个流程链路透明从 diff 提取到 prompt 构造再到结果解析全部可 inspectcode-review 是它唯一且明确的职能边界不做测试、不跑构建、不发部署CLI 是它的呼吸方式不依赖 GUI、不嵌入 IDE、不绑定某家云平台LLM 是它的推理引擎但绝非黑盒调用而是带约束、有 fallback、可审计的调用git 是它的数据源头只认 commit、branch、diff不碰文件系统直读不连远程 API。我从去年底开始在三个不同规模的团队中落地这套方案一个 5 人初创团队用它替代每日 standup 中的“代码走查”环节一个 20 人中台组把它集成进 pre-commit hook拦截明显低级错误还有一个外包交付项目客户要求所有 PR 必须附带机器初审报告我们直接用它生成 PDF 附件提交。实测下来它不能替代资深工程师的深度设计评审但能把 60% 的 trivial 问题空指针隐患、日志敏感信息、硬编码密钥、未处理异常分支、违反团队命名规范在开发者本地就卡住平均每个 PR 节省 12–18 分钟人工 review 时间。最关键的是——它不依赖任何外部服务账户、不上传代码到第三方、不强制使用某家大模型 API所有逻辑都在本地运行模型权重可选 HuggingFace 开源模型如 CodeLlama-7b、StarCoder2-3b甚至支持纯 CPU 推理牺牲速度换绝对可控。这不是“用 LLM 做 code review”的概念演示而是“如何让 LLM 在真实工程流水线里老实干活”的实操手册。2. 整体架构设计与关键决策逻辑2.1 为什么必须是 CLI而不是 VS Code 插件或 Web UI这个问题我被问过至少 17 次。答案很直白工程协作的最小可靠单元是命令行不是编辑器更不是浏览器。你可能今天用 VS Code明天换 Vim后天 CI 流水线跑在 Ubuntu Docker 容器里——但只要git和bash在open-code-review就能工作。我们做过对比实验同一套 prompt 和模型在 VS Code 插件里调用 OpenAI API平均响应延迟 2.3s在本地 CLI 调用 Ollama CodeLlama延迟 8.7s但在 Jenkins pipeline 里执行open-code-review --commit HEAD~1 --target main它稳定运行了 47 天零超时。GUI 插件天然绑定用户会话Web UI 需要维护 session 和 auth而 CLI 只做三件事解析 git diff → 格式化 prompt → 调用本地 LLM → 输出结构化 JSON。没有状态、没有会话、没有后台进程——它像grep或jq一样用完即走。更重要的是CLI 天然支持管道pipe和重定向你可以git diff HEAD~1 | open-code-review --format markdown review.md也可以open-code-review --branch feature/login --output json | jq .issues[] | select(.severity critical)。这种组合能力是任何图形界面无法提供的底层灵活性。提示不要试图给 CLI 加 GUI 包装。我们曾试过用 TUIText-based UI库做个进度条结果发现用户根本不需要——他们更关心review.json文件是否生成成功而不是动画效果。删掉 TUI 后二进制体积减少 42%启动时间从 320ms 降到 89ms。2.2 为什么坚持“Git 为源”而非直接读取文件或监听 IDE 事件很多同类工具号称“实时分析”实际是 hook 到 VS Code 的 onSave 事件读取当前打开的 .java 文件。这带来三个致命缺陷第一它只看到单个文件看不到跨文件的耦合问题比如 A.java 新增了方法B.java 却没调用第二它无法感知上下文变更比如你刚 revert 了一个 commitIDE 不知道第三它完全脱离团队协作语境PR 是基于 branch diff 的不是单文件快照。open-code-review的设计哲学是代码审查的本质是评估变更change不是检查静态文件file。所以它只接受三种输入模式--commit hash分析单次提交、--branch name分析分支相对于 main 的全部 diff、--pr url解析 GitHub/GitLab PR URL 获取 diff。所有输入最终都归一化为标准 git diff 输出git diff --no-prefix -U0 origin/main...HEAD再由内部 diff parser 提取变更行、文件路径、语言类型。我们甚至刻意禁用了--file path/to/xxx.java这种参数——不是技术做不到而是原则问题如果允许直读文件就会诱使用户绕过 Git 流程导致审查结果与实际合并内容脱节。2.3 LLM 如何“可控”不是扔个 prompt 就完事这是整个项目最耗精力的部分。我们早期版本用llama.cpp直接跑 CodeLlama-13bprompt 是“Review this Java code diff and list issues. Output JSON with keys: file, line, severity, message, suggestion.” 结果发现模型经常伪造行号输出line: 999但文件只有 50 行、混淆 severity 级别把warning写成critical、JSON 格式错乱少逗号、多引号。后来我们彻底重构了 LLM 交互层形成三层约束机制Schema 强约束使用jsonformer库非pydantic因其支持流式解析定义严格 Pydantic Modelclass ReviewIssue(BaseModel): file: str Field(..., descriptionRelative file path, e.g., src/main/java/com/example/Service.java) line: int Field(..., ge1, le10000, descriptionExact line number in the diff hunk) severity: Literal[critical, high, medium, low] Field(...) message: str Field(..., max_length200) suggestion: str Field(..., max_length500) class ReviewResult(BaseModel): issues: List[ReviewIssue] summary: str Field(..., max_length300)Prompt 结构化分段不再用长文本 prompt而是拆解为Context Section固定模板You are a senior Java developer reviewing production code. Focus on security, correctness, and maintainability. Ignore style-only issues (e.g., whitespace).Diff Section动态注入--- a/src/main/java/com/example/Service.java\n b/src/main/java/com/example/Service.java\n -23,0 24,5 public class Service {\n public void process(String input) {\n if (input ! null) {\n String decoded Base64.getDecoder().decode(input);\n // TODO: validate decoded length\n }\n }Instruction Section精确指令Output ONLY valid JSON matching the schema. Do NOT add explanations, markdown, or extra text. If no issues found, return {issues: [], summary: No critical issues detected.}Fallback 与校验机制当 LLM 返回非 JSON 或 schema 校验失败时不报错退出而是自动提取文本中疑似 JSON 的片段正则\{.*?\}用jsonrepair库尝试修复实测修复成功率 83%若仍失败则降级为规则引擎扫描基于semgrep规则集匹配常见漏洞模式这套机制让 LLM 输出有效 JSON 的成功率从 41% 提升到 99.2%且 92% 的 issue 行号准确率经人工抽样验证。2.4 “Open”到底开在哪里不是开源代码就叫 open很多人以为“open-code-review”只是 MIT License 的开源项目。但我们的“open”有四层含义全部可验证Open Input所有输入数据git diff完全透明用户可用open-code-review --debug-diff查看 CLI 实际传给 LLM 的原始 diff 文本Open Prompt内置 12 种语言的 prompt 模板Java/Python/Go/TypeScript 等全部存于prompts/目录用户可直接修改、覆盖、新增Open Model支持--model-path /path/to/gguf指向本地 GGUF 模型也支持--api-base http://localhost:11434/api/chat对接 Ollama不绑定任何商业 APIOpen Output默认输出 JSON但提供--format markdown、--format sarif兼容 GitHub Code Scanning、--format checkstyle对接 SonarQube三种格式且所有格式转换逻辑开源无隐藏逻辑。真正的“open”不是许可证声明而是让用户在任意环节都能介入、审计、替换。比如某金融客户要求所有 prompt 必须经过法务审核他们直接 fork 项目修改prompts/java.jinja2添加合规声明前缀重新 build 二进制——全程无需我们参与。3. 核心模块实现与实操细节拆解3.1 Git Diff 解析器从 raw diff 到结构化变更描述open-code-review的第一道工序是把git diff的原始输出变成 LLM 能理解的“变更故事”。这不是简单按行分割而是要还原出人类 reviewer 的阅读路径。我们采用三阶段解析第一阶段hunk 提取git diff -U0输出中每个 -X,Y A,B 标记一个 diff hunk。我们用正则r -(\d),?(\d)? \(\d),?(\d)? 提取起始行号和行数但注意-23,0表示删除 0 行即新增24,5表示从第 24 行开始新增 5 行。这里有个坑Git 的行号是“新文件视角”而 LLM 需要知道“这段代码在原文件中的位置”。所以我们记录original_start_line 23new_start_line 24hunk_lines 5。第二阶段变更分类对 hunk 内每一行按符号分类行新增代码LLM 重点审查对象-行删除代码需检查是否误删关键逻辑行空格开头上下文行提供语义锚点但不作为审查主体我们特别处理一种高频场景方法签名变更。例如- public String getName() { public OptionalString getName() {单纯标记行会丢失“返回类型从 String 变为 Optional”这一语义。因此我们增加 AST 辅助解析对 Java/Python 等语言用tree-sitter加载对应语言 grammar对行做轻量 AST 构建提取return_type、method_name、parameters等节点注入到 prompt 的 Context Section 中。实测对 Java 方法签名变更的识别准确率达 98.7%。第三阶段语言智能路由不是所有 diff 都交给同一个 LLM。我们内置语言检测器基于文件扩展名 shebang 关键字统计并为每种语言配置专属 prompt 模板和规则权重。例如Python强调None检查、with语句资源释放、f-string安全性Java聚焦Optional使用、try-with-resources、Nullable注解一致性TypeScript检查any类型滥用、strictNullChecks影响、Promise链式调用错误处理。这个路由机制让 LLM 的领域专注度提升避免通用模型在特定语言上“泛泛而谈”。3.2 Prompt 工程实战如何让 LLM 不瞎编、不漏判、不乱标Prompt 不是写作文而是工程接口协议。我们为每种语言设计的 prompt 模板Jinja2 格式包含四个强制区块1. Role Constraint Block角色与约束You are {{role}}, reviewing code for {{team}}. Your output MUST be valid JSON matching the schema. You MUST NOT: - Invent line numbers outside the diff hunk range - Suggest fixes that break backward compatibility - Flag issues already covered by static analyzers (e.g., unused imports) - Use severity critical for non-security issues2. Context Block上下文注入动态插入当前 diff 的文件路径、语言、变更类型新增/修改/删除该文件在 Git 历史中的最近三次 commit message判断开发意图团队自定义规则如config/rules.json中的no-hardcoded-passwords: true3. Diff Block变更内容严格按git diff -U0格式注入保留/-符号不美化、不缩进。因为 LLM 训练数据中大量 diff 就是这种格式强行转成“自然语言描述”反而降低准确率。我们做过 AB 测试用自然语言描述 diff“开发者新增了一个 process 方法接收 String 参数…”vs 原始 diff 格式后者在 issue 发现率上高出 22%。4. Instruction Block精确指令Output ONLY JSON with these keys: - issues: array of objects with file, line, severity, message, suggestion - summary: one-sentence overall assessment Do NOT include any other text, markdown, or explanations. If no issues found, return {issues: [], summary: No issues requiring immediate attention.}最关键的技巧是severity 分级的显式定义避免 LLM 主观判断Severity definitions: - critical: Security vulnerability (e.g., SQLi, XSS, hardcoded secrets) or crash risk - high: Logic error causing incorrect behavior (e.g., off-by-one, null dereference) - medium: Maintainability issue (e.g., duplicated code, missing unit test coverage) - low: Style or documentation (e.g., missing Javadoc, inconsistent naming)这个定义直接写进 prompt比在 post-process 中映射更可靠。3.3 本地 LLM 运行时Ollama GGUF 模型的极简部署我们放弃所有需要pip install大量依赖的 Python LLM 框架如 llama-cpp-python选择 Ollama 作为运行时原因有三零依赖安装macOSbrew install ollamaLinuxcurl -fsSL https://ollama.com/install.sh | shWindows 直接下载.exe无 Python 环境要求内存友好Ollama 的llama.cpp后端对 GGUF 模型做量化加载CodeLlama-7b.Q4_K_M.gguf 仅占 3.8GB RAMM2 Mac 16GB 内存可流畅运行API 兼容POST http://localhost:11434/api/chat接口与 OpenAI 兼容open-code-review无需为不同模型写多套 client。模型选型实测对比在 M2 Max 32GB 上模型参数量量化格式加载内存平均 token/sJava diff 审查准确率*CodeLlama-7b7BQ4_K_M3.8GB4278.3%StarCoder2-3b3BQ5_K_M2.1GB6871.5%DeepSeek-Coder-1.3b1.3BQ6_K1.4GB9564.2%Phi-3-mini-4k-instruct3.8BQ4_K_M2.7GB5575.1%*准确率定义人工抽样 100 个 issue确认是否真实存在且描述准确。结论CodeLlama-7b 是性价比最优解。它在 7B 模型中对 Java 语法理解最深训练数据含大量 GitHub Java 仓库且 Q4_K_M 量化在精度和速度间取得最佳平衡。我们提供一键安装脚本# 自动下载并 tag 为 codereview ollama run codellama:7b-q4_K_M ollama tag codellama:7b-q4_K_M codereview之后open-code-review --model codereview即可调用。注意不要用--num_ctx 4096这类参数强行扩大上下文。实测发现diff 超过 200 行时LLM 更易丢失全局结构。我们的策略是单次调用最多处理 150 行 diff超限时自动分片按文件切分并确保跨文件 issue 能关联如 A.java 新增方法B.java 调用处提示“未处理异常”。3.4 输出格式化与集成从 JSON 到可行动报告open-code-review默认输出是严格校验的 JSON但这只是中间产物。真正价值在于下游集成Markdown 报告--format markdown生成带 GitHub Flavored Markdown 的可读报告关键设计每个 issue 渲染为折叠区块detailssummary⚠️ medium: Missing null check/summary...避免长报告淹没重点自动插入代码片段diff --git a/src/Service.java b/src/Service.java→src/Service.java#L24-L28点击跳转到 GitHub 行号severity 用颜色标识span stylecolor:redcritical/span但导出 PDF 时自动转为加粗【CRITICAL】前缀。SARIF 格式--format sarif完全兼容 OASIS SARIF v2.1.0 标准可直接导入 GitHub Code Scanning{ version: 2.1.0, runs: [{ tool: { driver: { name: open-code-review, version: 0.8.2 } }, results: [{ ruleId: null-deref, level: error, message: { text: Potential null pointer dereference }, locations: [{ physicalLocation: { artifactLocation: { uri: src/Service.java }, region: { startLine: 25, endLine: 25 } } }] }] }] }这样GitHub Actions 中只需- name: Run open-code-review run: open-code-review --branch ${{ github.head_ref }} --format sarif review.sarif - name: Upload SARIF uses: github/codeql-action/upload-sarifv2 with: sarif_file: review.sarif即可在 PR 页面显示原生代码扫描警告。Checkstyle XML--format checkstyle适配 SonarQube/Jenkins Warnings NG Plugin字段映射file→file name...line→error line... message... sourceopen-code-review.null-deref/severity→priority1critical, 2high, 3medium, 4low这种设计让open-code-review不是孤立工具而是能无缝融入现有 DevOps 工具链的齿轮。4. 实操全流程与典型场景配置4.1 本地开发环境快速启动5 分钟假设你已安装 Git 和 Ollama以下是零配置启动流程步骤 1安装 open-code-review CLI# macOS/Linux curl -fsSL https://github.com/open-code-review/cli/releases/download/v0.8.2/open-code-review-$(uname -s)-$(uname -m) -o /usr/local/bin/open-code-review chmod x /usr/local/bin/open-code-review # WindowsPowerShell Invoke-WebRequest -Uri https://github.com/open-code-review/cli/releases/download/v0.8.2/open-code-review-Windows-x86_64.exe -OutFile $env:ProgramFiles\open-code-review.exe # 添加到 PATH步骤 2准备模型# 下载并量化 CodeLlama-7b自动选择最优 GGUF ollama run codellama:7b-q4_K_M # 创建别名便于 CLI 调用 ollama tag codellama:7b-q4_K_M codereview步骤 3首次运行审查# 审查最近一次 commit open-code-review --commit HEAD # 审查当前分支相对于 main 的所有变更 open-code-review --branch HEAD --target main # 输出为 Markdown 报告 open-code-review --branch HEAD --format markdown review.md首次运行会自动创建~/.open-code-review/config.yaml内容如下model: codereview language_rules: java: prompt_template: prompts/java.jinja2 severity_threshold: high # 只报告 high 及以上级别 python: prompt_template: prompts/python.jinja2 severity_threshold: medium output: format: json show_summary: true你可以直接编辑此文件调整全局行为。4.2 团队标准化配置.reviewrc文件驱动为避免每个成员手动配置我们在项目根目录支持.reviewrc文件YAML 格式优先级高于全局 config# .reviewrc model: /models/codellama-7b.Q5_K_M.gguf # 绝对路径指向团队统一模型 rules: - id: no-hardcoded-secrets enabled: true severity: critical - id: missing-javadoc enabled: false # 禁用低优先级规则 prompt_overrides: java: context: | Team policy: All public methods must have throws javadoc. Security requirement: No Base64.decode without length validation. # 自定义检查项不依赖 LLM static_checks: - language: java pattern: System\.out\.println\( message: Use SLF4J logger instead of System.out severity: medium当open-code-review执行时会自动加载.reviewrc覆盖全局配置。这样新成员 clone 仓库后open-code-review --branch HEAD就能获得团队一致的审查标准无需额外学习成本。4.3 CI/CD 集成GitHub Actions 自动化流水线在.github/workflows/code-review.yml中配置name: Code Review on: pull_request: types: [opened, synchronize, reopened] jobs: review: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 with: fetch-depth: 0 # 必须获取完整历史以计算 diff - name: Install open-code-review run: | curl -fsSL https://github.com/open-code-review/cli/releases/download/v0.8.2/open-code-review-Linux-x86_64 -o /tmp/ocr chmod x /tmp/ocr sudo mv /tmp/ocr /usr/local/bin/open-code-review - name: Run code review id: review run: | # 生成 SARIF 报告 open-code-review \ --pr ${{ github.event.pull_request.html_url }} \ --format sarif \ --model codereview \ review.sarif # 输出 summary 供后续步骤使用 echo report_pathreview.sarif $GITHUB_OUTPUT - name: Upload SARIF uses: github/codeql-action/upload-sarifv2 with: sarif_file: ${{ steps.review.outputs.report_path }} category: code-review - name: Post comment if critical issues if: always() fromJSON(steps.review.outputs.report).issues | length 0 run: | # 提取 critical issues 生成评论 critical_issues$(jq -r .runs[0].results[] | select(.levelerror) | \(.message.text) at \(.locations[0].physicalLocation.artifactLocation.uri)#\(.locations[0].physicalLocation.region.startLine) review.sarif | head -5) if [ -n $critical_issues ]; then echo Found critical issues: comment.md echo $critical_issues comment.md gh pr comment ${{ github.event.pull_request.number }} --body-file comment.md fi env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}这个 workflow 实现PR 创建/更新时自动触发生成 SARIF 报告并上传至 GitHub Code Scanning显示在 Security 标签页若发现error级别 issue自动在 PR 下评论提醒避免 reviewer 漏看全流程无需维护服务器纯 GitHub 托管。4.4 高级技巧自定义规则与模型微调当开箱即用规则不够用时有两种深度定制方式方式一Prompt 层微调推荐新手编辑prompts/java.jinja2在 Context Block 中添加Team-specific constraints: - All database queries must use parameterized statements (no string concatenation) - All REST endpoints must return ResponseEntityT, never raw T - Log messages must include correlation ID: correlationId{}然后open-code-review --prompt prompts/my-java.jinja2指定模板。我们提供--debug-prompt参数可输出实际发送给 LLM 的完整 prompt 文本方便调试。方式二模型层微调适合团队使用 LoRA 微调 CodeLlama-7b数据集来自团队历史 PR review comments清洗后约 2000 条# 数据格式JSONL {prompt: Review this Java diff..., response: {issues: [{file: ...}]}} # 使用 Unsloth 微调1 小时内完成 from unsloth import is_bfloat16_supported from unsloth import load_model, get_peft_model model, tokenizer load_model( model_name codellama/CodeLlama-7b-Instruct-hf, max_seq_length 2048, dtype None if is_bfloat16_supported() else float16, ) model get_peft_model(model, r 16, lora_alpha 16, target_modules [q_proj, k_proj, v_proj, o_proj]) # 导出为 GGUF 供 Ollama 使用微调后模型在团队特有代码模式如内部 RPC 框架调用规范上的 issue 发现率提升 35%且 false positive 减少 62%。5. 常见问题排查与避坑指南5.1 LLM 返回 JSON 格式错误90% 的问题在这里这是用户反馈最多的痛点。我们整理了真实发生过的 7 类错误及对应解法错误现象根本原因解决方案json.decoder.JSONDecodeError: Expecting property name enclosed in double quotesLLM 用单引号包裹 key如file: a.java启用jsonrepair库自动修复已在 v0.8.0 默认开启ValidationError: 1 validation error for ReviewResult issues - 0 - line value is not a valid integerLLM 输出line: 25字符串而非整数在 Pydantic Model 中添加field_validator(line) def line_must_be_int(cls, v): return int(v)Response contains extra text before/after JSONLLM 在 JSON 前加了“Here is the review:”后加了“Let me know if you need more details!”在 prompt 中强化指令“Output ONLY valid JSON. Do NOT add any other text.” 并在 CLI 中用正则r\{.*?\}提取首个 JSON 片段issues数组为空但summary字段缺失LLM 未按 schema 输出summary在 Pydantic Model 中设summary: str Field(defaultNo issues found.)line值超出文件实际行数如文件 50 行LLM 输出line: 999LLM 误读 diff hunk 行号在 diff parser 中记录hunk_start_line和hunk_end_lineLLM 输出后校验line是否在[hunk_start_line, hunk_end_line]范围内越界则丢弃该 issuefile路径包含绝对路径如/home/user/project/src/a.javaGit diff 在某些环境下输出绝对路径CLI 启动时自动cd到 git root并用git rev-parse --show-toplevel获取项目根路径所有file字段强制转为相对路径severity值为blocker或info非预设值LLM 自由发挥在 Pydantic Model 中用Literal[critical, high, medium, low]严格限定非法值触发ValidationError并 fallback 到medium实操心得不要指望 LLM 一次输出完美 JSON。我们的经验是——设计 robust fallback 比追求 100% 正确率更重要。v0.7.0 版本曾强依赖 LLM 输出结果 12% 的请求失败v0.8.0 引入三层 fallbackJSON repair → schema default → rule engine失败率降至 0.3%且用户无感知。5.2 审查结果“不准”如何区分真问题与幻觉LLM 幻觉在 code review 中表现为虚构 issue指出某行有空指针但该行变量已明确初始化遗漏 issue对明显 SQL 注入漏洞视而不见过度解读将list.size() 0标记为“性能问题”建议改用!list.isEmpty()虽正确但非 critical。我们的应对策略是双轨验证机制轨道一规则引擎兜底内置 47 条基于semgrep的静态规则如java.lang.security.audit.hardcoded-credentials对每个 diff 文件并行扫描。当 LLM 报告 issue 时检查是否被规则引擎覆盖若规则引擎也报告相同 issue → 置信度 30%若规则引擎未报告 → 标记为“LLM-only”在报告中用 ⚠️ 图标提示“此问题未被静态分析器捕获请人工确认”若规则引擎报告 issue 但 LLM 未报告 → 触发--strict-mode警告提示“LLM 可能漏判建议检查模型能力”。轨道二置信度评分在 prompt 中要求 LLM 为每个 issue 输出confidence: 0.0-1.0例如{ file: Service.java, line: 25, severity: high, message: Possible null dereference on input, suggestion: Add null check before calling input.length(), confidence: 0.92 }CLI 自动过滤confidence 0.7的 issue并在报告中注明“低置信度建议人工复核”。实测将 false positive 率从 28% 降至 9%。5.3 性能瓶颈大 diff 卡死或超时当 PR 包含 50 文件、2000 行变更时LLM 推理可能超时。我们的优化方案分片策略按文件粒度切分每个文件独立调用 LLM超时阈值设为 60sOllama 默认超时则跳过该文件并记录 warning优先级调度对*.java、*.py等主语言文件优先审查*.md、*.xml等跳过可配置缓存机制对相同 diff hashSHA256的结果缓存 24 小时避免重复审查CPU 亲和性在 Linux 上用taskset -c 0-3 open-code-review ...绑定 CPU 核心防止与其他进程争
