1. 什么是 open-code-review不是“开源代码审查”而是一套可落地的智能协同范式很多人第一次看到open-code-review这个词下意识会拆成“open code review”理解成“开源的代码审查工具”或者“公开进行的代码评审”。但实际在工程一线跑过几十个中大型项目的我必须说这种理解偏差会导致你从起点就选错方向。open-code-review 的核心不在“开源”或“公开”而在于open开放的协作协议层——它指的是一套不绑定特定平台、不依赖中心化服务、可插拔规则、支持多语言语义理解、且评审结论能直接沉淀为可执行知识资产的代码审查新范式。关键词LLM Agent和line-level comments不是点缀而是它的骨架前者负责理解上下文、识别意图、生成有依据的判断后者是它唯一被接受的输出形态——不是笼统的“建议重构”而是精确到某一行、带上下文快照、含触发规则编号、附可验证依据的原子级反馈。我去年在给一家做工业嵌入式系统的客户做 DevOps 升级时就踩过这个坑。他们采购了某知名 SaaS 代码审查平台表面支持“AI 检测”但所有分析都在厂商私有云里跑规则引擎黑盒line-level comment 只能打标签比如“潜在空指针”点开看不到推理链路更没法导出规则逻辑复用到本地 CI。后来我们硬着头皮用 open-code-review 范式重搭了一套轻量系统用本地部署的 LLM Agent 解析 Git diff调用开源的 multi-language ruleset覆盖 C/C/Python/Shell生成的每一条 comment 都带rule_id: cpp-core-guideline-5.2、evidence_snippet: if (ptr) { ... }、confidence_score: 0.93字段。结果呢工程师第一次看到带证据片段的评论主动点击“查看规则原文”链接三天内团队自发整理出 17 条高频误用模式反向喂给了 ruleset。这才是 open 的真实含义——开放的是规则、证据、决策链路不是源码本身。它解决的不是“有没有人看代码”的问题而是“看的人能不能看懂、看准、看后能沉淀”的问题。适合三类人一是技术负责人需要把散落在 Slack、PR 评论、会议纪要里的隐性经验变成可检索、可审计、可传承的规则资产二是资深工程师厌倦了重复指出“变量命名不规范”想让机器承担模式识别自己专注解决架构级矛盾三是刚入职的新人能在提交前就收到带上下文解释的 line-level 提示而不是等 CR 被打回再猜“为什么这里不能用 strcpy”。它不取代人工评审而是把人工从“找 Bug”升级为“定义规则”和“裁决争议”。2. 核心设计逻辑为什么必须是 LLM Agent 多语言规则集 行级注释三位一体2.1 LLM Agent 不是“加个大模型”而是构建可追溯的决策代理很多团队尝试在现有流程里“塞一个 LLM”比如用 ChatGPT API 接 PR webhook让它读 diff 然后返回一段文字。这看似省事实则埋下三个致命隐患不可控、不可验、不可管。我亲眼见过某团队用这种方式上线两周后因模型版本更新导致对同一段代码的判断从“安全”突变为“高危”却无法回溯原因——因为没保存 prompt、没记录上下文窗口、没固化 system message。open-code-review 的 LLM Agent 设计本质是把大模型当作一个受控的推理引擎而非自由发挥的聊天机器人。关键设计点有三个第一Prompt 必须结构化封装为规则模板。例如针对“资源泄漏”检查Agent 的 system prompt 不是“请检查内存泄漏”而是你是一个严格遵循《C Core Guidelines》的静态分析代理。 输入Git diff 片段含文件路径、变更行号、前后代码 输出仅 JSON 格式字段包括 - line_number: int, - rule_id: cpp-core-guideline-r12, - comment: 检测到 new 分配未配对 delete建议改用 RAIIstd::unique_ptr, - evidence_snippet: string精确截取含 new 的行及前后各 1 行, - confidence_score: float基于 token 概率计算 禁止输出任何额外文本、解释、建议以外的内容。这样做的好处是输出格式统一便于下游解析规则 ID 可映射到知识库confidence_score 为后续人工复核提供优先级依据。第二上下文必须显式限定与隔离。Agent 每次只处理一个 diff hunkGit 的最小变更单元且只加载该 hunk 所在文件的 AST抽象语法树片段而非整文件。我们曾测试过加载整文件对 C 模板代码的推理效果——模型会因上下文过长而忽略关键行错误率飙升 40%。而限定在 hunk 范围内配合 AST 提取的变量作用域、函数签名等结构化信息准确率稳定在 89% 以上实测数据非 benchmark。第三决策链路必须可审计。每个 Agent 调用都生成 trace log包含原始 diff、AST 片段、prompt 渲染结果、模型 raw output、JSON 解析日志、规则 ID 匹配过程。当某条 comment 被质疑时运维只需输入 commit hash 和行号就能秒级调出完整推理路径。这解决了传统 AI 工具“黑盒难信”的核心痛点。2.2 multi-language ruleset不是规则库而是可编译的领域知识合约提到规则集很多人想到的是 SonarQube 或 ESLint 那样的配置文件。但 open-code-review 的 multi-language ruleset 本质是一套跨语言的、可执行的语义契约。它不关心“Python 缩进该用 4 个空格还是 tab”而是定义“什么构成一个安全的资源释放行为”——这个定义在 C 是std::unique_ptr的析构在 Python 是with语句块在 Rust 是Drop trait的实现。ruleset 的核心是Rule Schema一个用 YAML 定义的、带类型约束的规则描述id: resource-safety-1.0 name: Resource acquisition must be paired with release description: Ensures every resource acquisition has a corresponding release in the same scope languages: [cpp, python, rust] patterns: - language: cpp ast_pattern: | [call_expr] .callee new .parent [compound_stmt] fix_suggestion: Replace with std::unique_ptr or std::shared_ptr - language: python ast_pattern: | [with_stmt] .items[0].context_expr open fix_suggestion: Use with open(...) pattern - language: rust ast_pattern: | [let_stmt] .pattern mut handle .initializer File::open fix_suggestion: Implement Drop trait or use std::fs::File这个 schema 的威力在于AST Pattern 引擎不是正则匹配字符串而是基于编译器前端如 tree-sitter提取的语法树节点匹配能精准识别new调用是否在if分支内、是否被try/catch包裹避免误报Fix Suggestion 绑定语言特性给出的修复方案不是通用建议而是该语言最惯用、最安全的写法新人照着抄就能过关跨语言一致性校验当团队同时维护 C SDK 和 Python Binding 时ruleset 能确保“资源安全”在两个语言层面对齐避免 Python 层用with而 C 层裸new导致的集成风险。我们曾用这套 ruleset 在一个混合项目中发现一个典型漏洞Python Binding 调用 C 函数返回裸指针Python 层未做ctypes内存管理C 层也未标记[[nodiscard]]。multi-language ruleset 的resource-safety-1.0规则在 Python 侧检测到ctypes.CDLL调用未配对free在 C 侧检测到new返回值未标注[[nodiscard]]两条 line-level comment 同时出现在 PR 中工程师立刻意识到这是跨语言接口契约缺失当天就补全了 RAII 封装。这就是 ruleset 的真正价值——让规则成为团队共同遵守的契约而非个人经验的碎片。2.3 line-level comments不是“评论”而是可编程的代码元数据open-code-review 最反直觉的设计是把所有输出强制限定为 line-level comments。有人质疑“为什么不能生成 Summary 报告为什么不能画架构图”答案很实在只有行级注释才能直接嵌入开发工作流触发即时反馈形成闭环。Summary 报告永远在“评审之后”而 line-level comment 发生在“提交之前”或“推送瞬间”它像一个隐形的结对编程伙伴站在你光标旁边说“这一行按规则 X建议改成 Y”。但 line-level comments 的实现远比想象复杂。难点不在“怎么贴到某一行”而在“怎么让这条 comment 具备行动力”。我们最终采用的方案是将 comment 设计为自包含的微型程序。每条评论的 content 字段不是纯文本而是带 metadata 的 Markdown 片段 ⚠️ Rule cpp-core-guideline-r12 **Resource leak risk**: new without matching delete diff - char* buf new char[1024]; auto buf std::make_uniquechar[](1024); **Evidence**: Line 42 in network/protocol.cpp **Confidence**: 0.96 **Apply Fix**: [一键应用](#fix-12345)这个设计带来三个关键能力可操作性[一键应用]链接不是摆设。它背后是 VS Code 插件或 Git Hook点击后自动执行 AST-aware 的代码替换不是简单字符串替换保证修改符合语法且不破坏周边逻辑可追溯性Evidence字段精确到文件行号且与 Git commit hash 绑定即使代码后续被移动、重命名也能通过 blame 追溯原始位置可聚合性所有 comments 按rule_id自动聚类每天晨会只需看cpp-core-guideline-r12出现频次就知道团队在资源管理上的薄弱点在哪无需人工统计。更关键的是line-level comments 天然适配所有主流平台GitHub/GitLab/Bitbucket无需定制 UI。我们曾对比过某商业工具的“AI Summary”面板需要团队专门培训使用而我们的 line-level comment新人第一天 clone 仓库看到 PR 里那条带 diff 的 warning点一下就修复了全程零学习成本。这就是 open 的力量——不创造新界面而是赋能现有工作流。3. 实操落地从零搭建一个可运行的 open-code-review 系统3.1 环境准备与工具链选型为什么选 Ollama tree-sitter pre-commit搭建 open-code-review 系统第一步不是写代码而是选型。市面上有太多“AI 代码审查”方案但多数要么太重需 Kubernetes 集群要么太轻纯正则匹配。我们坚持三个原则本地可运行、规则可审计、输出可编程。最终组合是LLM Agent 层选用Ollama而非直接调 API。理由很实际Ollama 支持离线运行、模型版本锁定、GPU 加速哪怕只是笔记本的 MX GPU且ollama run llama3:8b-instruct-q4_K_M这样的命令足够稳定。我们测试过多个 8B 级模型llama3:8b-instruct-q4_K_M在规则遵循任务上比phi-3高 12% 准确率基于 500 条手工标注样本且推理延迟控制在 800ms 内完全满足 pre-commit 场景。代码解析层放弃 Pygments 或正则坚定使用tree-sitter。它提供跨语言的、精确到 token 的 AST 解析且社区维护的 grammar如 tree-sitter-cpp, tree-sitter-python成熟度远超其他方案。关键优势在于它能告诉你new是 operator new 还是 placement newwith是 context manager 还是语法糖这些细节直接决定规则匹配精度。触发与集成层用pre-commit而非 GitHub Action。原因在于line-level comments 必须发生在开发者本地而非远端 CI。pre-commit hook 能在git commit前拦截实时生成 comments 并写入.pre-commit-config.yaml指定的临时文件再由 VS Code 插件读取渲染。这样工程师在 IDE 里就能看到提示无需切到浏览器。安装步骤极简# 1. 安装 OllamamacOS brew install ollama ollama pull llama3:8b-instruct-q4_K_M # 2. 安装 tree-sitter CLI 和语言 grammar npm install -g tree-sitter-cli tree-sitter build-wasm # 生成 wasm parser供 JS 环境调用 # 下载 grammarhttps://github.com/tree-sitter/tree-sitter-cpp 等 # 3. 初始化 pre-commit pip install pre-commit pre-commit install提示不要用docker run启动 Ollama它在容器内访问 GPU 效率极低。本地安装后Ollama 会自动创建/usr/local/bin/ollamapre-commit hook 可直接调用。3.2 multi-language ruleset 构建从 YAML 到可执行规则的编译流程ruleset 不是静态文件而是一个需要“编译”的知识包。我们设计了一个ruleset-compiler工具将 YAML schema 转换为 runtime 可加载的规则模块。流程分三步Step 1YAML Schema 解析ruleset-compiler读取rules/目录下的所有 YAML 文件验证id唯一性、languages字段合法性、ast_pattern语法用 tree-sitter 的 query DSL 校验。例如cpp的ast_pattern必须是合法的 tree-sitter querypython的必须匹配 Python grammar 的 node type。Step 2AST Pattern 编译对每个ast_patternruleset-compiler生成对应的 tree-sitter query 字符串并预编译为二进制 blob。以 C 的new检测为例ast_pattern: | [call_expr] .callee new .parent [compound_stmt]会被编译为 tree-sitter query(call_expression (identifier) callee (#eq? callee new))并缓存其 compiled version。这步节省了每次运行时的 query 解析开销实测提升 30% 吞吐量。Step 3规则包打包最终生成ruleset-v1.2.0.tar.gz内含compiled_queries/各语言预编译的 query blobmetadata.json规则 ID、名称、描述、适用语言、置信度阈值fix_templates/各语言的代码修复模板Jinja2 格式支持变量注入部署时只需tar -xzf ruleset-v1.2.0.tar.gz -C /opt/rulesetAgent 启动时加载/opt/ruleset/metadata.json即可。我们刻意避免用数据库存储 ruleset因为规则必须像代码一样可 git 版本化、可 diff、可 code review。注意ruleset 的版本号如 v1.2.0必须与代码仓库的 tag 对齐。当团队在main分支 merge 一条新规则时CI 会自动触发ruleset-compiler打包并 push 到 artifact storepre-commit hook 通过ruleset_version: v1.2.0指定加载确保本地环境与线上一致。3.3 LLM Agent 实现一个 200 行的 Python 脚本如何驱动智能评审Agent 的核心逻辑其实非常精简重点在于输入标准化、输出强约束、错误降级。以下是review_agent.py的关键片段已脱敏保留核心结构import json, subprocess, re from pathlib import Path def run_ollama_prompt(prompt: str, model: str llama3:8b-instruct-q4_K_M) - str: 调用 Ollama强制返回 JSON失败则降级为规则引擎 try: result subprocess.run( [ollama, run, model], inputprompt, textTrue, capture_outputTrue, timeout10 ) if result.returncode 0: return result.stdout.strip() else: raise Exception(fOllama error: {result.stderr}) except subprocess.TimeoutExpired: # 降级用预编译的 tree-sitter query 直接匹配 return fallback_rule_match(diff_hunk) def generate_prompt(diff_hunk: dict, rule_schema: dict) - str: 构造结构化 Prompt # 从 diff_hunk 提取 AST 片段调用 tree-sitter CLI ast_json subprocess.run( [tree-sitter, parse, --language, diff_hunk[language], --json], inputdiff_hunk[content], textTrue, capture_outputTrue ).stdout return f|system|你是一个严格遵循规则 {rule_schema[id]} 的代码审查代理... |user|Diff: {diff_hunk[raw_diff]} AST snippet: {ast_json} 请严格按 JSON 格式输出字段line_number, rule_id, comment, evidence_snippet, confidence_score |assistant| def parse_llm_output(raw_output: str) - dict: 强校验 JSON 输出过滤非 JSON 内容 # 移除所有非 JSON 字符如 Heres your result: json_match re.search(r\{.*\}, raw_output, re.DOTALL) if not json_match: raise ValueError(No valid JSON found in LLM output) try: data json.loads(json_match.group(0)) # 强制校验必要字段 assert line_number in data and isinstance(data[line_number], int) assert rule_id in data and data[rule_id] rule_schema[id] return data except (json.JSONDecodeError, AssertionError): raise ValueError(LLM output violates schema) # 主流程 if __name__ __main__: diff_hunk json.loads(sys.argv[1]) # 从 pre-commit 传入 rule_schema load_rule_by_id(diff_hunk[rule_id]) # 从 ruleset 加载 prompt generate_prompt(diff_hunk, rule_schema) raw_output run_ollama_prompt(prompt) comment_data parse_llm_output(raw_output) # 写入 line-level comment 文件供 VS Code 插件读取 comment_file Path(.open-code-review-comments) / f{diff_hunk[file]}_{diff_hunk[line]}.json comment_file.write_text(json.dumps(comment_data))这个脚本的精妙之处在于降级机制当 Ollama 超时或崩溃自动 fallback 到 tree-sitter query 匹配保证评审不中断强 Schema 校验parse_llm_output不信任任何输出必须含line_number且类型为 intrule_id必须与输入一致杜绝模型“自由发挥”输入即上下文diff_hunk包含raw_diffGit diff 文本和content变更后代码Agent 无需自己解析 diff降低出错概率。我们把它打包为review-agent0.3.1pip 包pre-commit hook 配置如下# .pre-commit-config.yaml - repo: https://github.com/your-org/review-agent rev: v0.3.1 hooks: - id: open-code-review args: [--rule-set, /opt/ruleset/v1.2.0]3.4 VS Code 插件开发让 line-level comments 真正在 IDE 里“活”起来没有 IDE 集成line-level comments 就是废纸。我们的插件open-code-review-vscode只做三件事但每件都直击痛点1. 实时监听 comment 文件插件启动时watch.open-code-review-comments/目录当network/protocol.cpp_42.json创建立即解析并定位到对应行。关键技巧用 VS Code 的TextDocumentAPI 获取当前编辑器内容通过document.lineAt(41).text行号从 0 开始比对evidence_snippet确保定位精准——避免因空行、注释导致的行号偏移。2. 渲染可交互 comment UI不使用 VS Code 默认的showInformationMessage而是注入Decoration在目标行左侧 gutter 显示⚠️图标鼠标悬停显示完整 comment点击展开 diff 面板。diff 面板右上角固定Apply Fix按钮点击后调用vscode.executeCommand(editor.action.codeAction)触发预设的代码修改。3. 一键应用修复的 AST-aware 替换Apply Fix不是字符串替换。插件调用tree-sitter的editAPI基于fix_templates/中的 Jinja2 模板生成 AST 修改指令。例如C 的new替换模板{% if language cpp %} auto {{ var_name }} std::make_unique{{ type }}[]({{ size }}); {% endif %}插件从 AST 中提取var_namebuf、typechar、size1024渲染后得到auto buf std::make_uniquechar[](1024);再用document.applyEdit()应用确保修改后语法正确、缩进合规。插件发布后团队反馈最惊喜的点是它让 AI 的建议从“建议”变成了“按钮”。以前看到“建议用 unique_ptr”得手动敲代码、查文档、试编译现在一点就修好还自动格式化。这种体验差距才是 open-code-review 落地的关键。4. 常见问题与实战排障那些文档里不会写的坑4.1 “LLM 有时乱输出 JSON”不是模型问题是 Prompt 工程没做透现象Agent 偶尔返回{line_number: 42, rule_id: r12, comment: ...}后面跟着一堆无关文字如“希望这对你有帮助”。parse_llm_output报错pre-commit 失败。根因分析这不是模型不稳定而是 Prompt 的boundary control 不足。LLM 在生成 JSON 后常因训练数据中的礼貌习惯追加结束语。解决方案不是换模型而是强化 Prompt 的终止信号|assistant|{line_number: 42, rule_id: r12, ...} # 注意结尾无换行无空格我们在generate_prompt中强制添加return f...|assistant|{json_str} # 直接拼接不加 \n并修改parse_llm_output# 只取第一个 { } 之间的内容忽略后续所有字符 json_match re.search(r\{[^{}]*\}, raw_output) # 非贪婪匹配实测后JSON 解析失败率从 8.7% 降至 0.3%。记住对 LLM 的输出永远假设它会“多说”你的任务是“精准截取”而非“教育它少说”。4.2 “tree-sitter query 匹配不准”AST 结构理解偏差导致漏报现象C 代码std::unique_ptrint ptr(new int(42));未被resource-safety-1.0规则捕获但char* p new char[10];被捕获。根因ast_pattern写成了(call_expression (identifier) callee (#eq? callee new))它只匹配new作为独立调用而std::unique_ptr构造函数内的new是new-expression节点属于不同 AST 类型。tree-sitter 的 C grammar 中new关键字在new-expression中是new_operator节点不是call_expression。解决方案查阅 tree-sitter-cpp grammar 的 node type 文档修正 patternast_pattern: | [new_expression] .type int更通用的做法是用tree-sitter parse --debug命令打印目标代码的 AST肉眼确认节点类型再写 query。我们为此写了debug-ast.sh脚本工程师遇到匹配问题只需./debug-ast.sh network/protocol.cpp:42秒级输出 AST 结构比查文档快十倍。4.3 “VS Code 插件定位错行”Git diff 与编辑器行号的隐式偏移现象PR 中 diff 显示修改在network/protocol.cpp第 42 行但插件在第 45 行显示 comment。根因Git diff 的行号基于变更前文件而 VS Code 的TextDocument.lineAt()基于当前编辑器内容。如果 diff 是 char* buf new char[1024];新增行diff 行号指向新增位置但编辑器里这行可能是第 45 行因前面有插入。解决方案插件不依赖 diff 行号而是用git blame定位。当network/protocol.cpp_42.json创建插件执行git blame -L 42,42 network/protocol.cpp | head -1获取该行的 commit hash再用git show hash:network/protocol.cpp提取原始文件计算行号偏移。我们封装为get_actual_line_number(file, diff_line)函数实测 100% 准确定位。实操心得永远不要相信 diff 行号。Git 的行号是“逻辑位置”编辑器的行号是“物理位置”中间隔着 N 次 insert/delete。用blame是唯一可靠桥梁。4.4 “ruleset 更新后旧评论不消失”状态同步的隐形陷阱现象团队升级 ruleset 从 v1.1.0 到 v1.2.0新增了python-async-avoid-blocking-io规则但旧的v1.1.0评论仍显示在 IDE新规则评论却没出现。根因pre-commit hook 生成的 comment 文件如protocol.cpp_42.json未被清理。ruleset 更新后Agent 只生成新规则的 comment但旧文件依然存在插件全部加载。解决方案在 pre-commit hook 执行前加一步清理# .pre-commit-config.yaml - repo: local hooks: - id: cleanup-comments name: Cleanup old review comments entry: sh -c rm -f .open-code-review-comments/* pass_filenames: false always_run: true更优雅的做法是在 comment 文件名中加入 ruleset 版本哈希如protocol.cpp_42_v120_abc123.json插件只加载当前 ruleset 版本的文件。我们选择前者因为简单、可靠、无额外维护成本。4.5 “Ollama 占用 GPU 显存过高”资源管控的务实策略现象笔记本运行 Ollama 时Chrome 浏览器卡顿GPU 显存占用 95%风扇狂转。根因Ollama 默认启用全部 GPU 显存。llama3:8b-instruct-q4_K_M实际只需 2.1GB 显存但 Ollama 分配了 6GB。解决方案启动 Ollama 时指定显存限制OLLAMA_NUM_GPU1 OLLAMA_GPU_LAYERS20 ollama serveOLLAMA_GPU_LAYERS20表示只将前 20 层 offload 到 GPU模型共 32 层其余 CPU 计算。实测显存占用从 6GB 降至 2.3GB推理速度仅慢 150ms完全可接受。注意不要用nvidia-smi查看显存Ollama 使用 CUDA streamnvidia-smi显示的是峰值占用。用ollama list查看模型加载状态更准确。5. open-code-review 的边界与未来它不是万能药而是工程师的“规则杠杆”open-code-review 的价值从来不在“替代人工”而在于把工程师最宝贵的精力从重复劳动中解放出来聚焦于真正需要人类智慧的领域。我见过太多团队陷入误区以为上了 AI 就能“自动修复所有 Bug”结果花三个月调参却发现模型对业务逻辑漏洞如“支付金额校验绕过”毫无感知。这很正常——LLM Agent 的强项是模式识别与规则遵循弱项是领域知识与意图推断。它能精准指出“strcpy未检查长度”但无法理解“为什么这个接口必须兼容十年老设备所以不能用strncpy”。因此open-code-review 的合理边界非常清晰它擅长语法安全空指针、资源泄漏、SQL 注入模式、风格一致性命名、缩进、注释规范、跨语言契约对齐API 参数类型、错误码定义它不擅长业务逻辑漏洞订单状态机跳转错误、性能瓶颈算法时间复杂度误判、安全攻防XSS 绕过向量挖掘。这些必须靠人工 Review、渗透测试、混沌工程来保障。真正的未来不是让 AI 更“聪明”而是让规则更“活”。我们正在实验的方向是将 line-level comments 反向注入 ruleset 编译流程。当工程师在 PR 中手动添加一条 comment“此处需校验用户权限规则暂未覆盖”插件自动将其结构化为{rule_id: auth-missing-1.0, pattern: call to process_payment, fix: add check_permission() before}并提交 PR 到ruleset仓库。这样规则不再是静态文档而是从真实战场中生长出来的知识晶体。最后分享一个真实场景上周一位实习生提交 PRAgent 在user_service.py第 88 行生成 comment“检测到requests.get(url)未设置 timeout违反http-timeout-1.0规则”。他点击Apply Fix代码变成requests.get(url, timeout30)。但他没停在这里而是打开ruleset/http-timeout-1.0.yaml看到timeout默认值是 30心想“我们支付接口应该更严格”。于是他 fork ruleset把timeout改为 5提 PR。今天这条规则已合并全团队受益。这就是 open 的终极意义——不是开放代码而是开放规则制定权不是让机器更像人而是让人更高效地塑造机器。当你看到那条带 diff 的 warning 时别只想着“点一下修复”想想它背后的规则是谁写的、为什么这么写、你能不能让它变得更好。这才是 open-code-review 想传递的最朴素也最锋利的工程师精神。