企业官网建设流程全解析

1. 项目概述：这不是又一个“AI写代码”玩具，而是一套可嵌入日常开发流的开源代码评审协作者

“open-code-review”这个名字乍看平平无奇，但拆开来看——open不是指“开源”，而是指“开放介入”；code review不是指人工走查那套流程，而是指把评审动作本身变成一个可编程、可配置、可审计的工程环节；review更不是终点，而是开发闭环里那个被长期忽视的“反馈加速器”。我从去年开始在三个不同规模的团队里落地这套实践，从最初用 shell 脚本硬套 LLM API，到后来自己写 CLI 工具链，再到如今把它沉淀为一个真正能进 CI/CD 流水线的轻量级评审代理（Agent），核心目标就一个：让每一次git commit之后，代码不是静默地躺在分支上，而是立刻触发一次结构化、上下文感知、带明确行动建议的自动初筛。它不替代人，但能提前拦住 60% 以上的低级错误——比如空指针未判、日志敏感信息硬编码、SQL 拼接、HTTP 状态码误用、单元测试覆盖率断崖式下跌等。它也不依赖某个大模型厂商的闭源服务，所有 prompt 工程、上下文裁剪、diff 解析逻辑都暴露在 CLI 参数里，你可以用 DeepSeek-Coder-32B 本地跑，也可以切到 Qwen2.5-Coder-7B 做轻量快评，甚至用 Ollama 拉个 Phi-3-mini 做 PR 标题合规性检查。关键词里的LLM Agent在这里不是玄学概念：它就是一段有状态、有记忆、能调用 git 工具链、能读取 .editorconfig、能解析 AST 片段、能按需生成 patch 的 CLI 进程。而git diffs是它的唯一输入源——不是整份文件，不是整个仓库，就是git diff HEAD~1 HEAD --no-color那几百行带+-的文本流。这决定了它极低的侵入性：你不需要改 IDE 插件，不需要配 Webhook，不需要动 Jenkinsfile，只要在 pre-commit hook 或 GitHub Action 的run:步骤里加一行open-code-review --diff-file - --model qwen2.5:7b，它就活了。

2. 整体设计思路与方案选型逻辑：为什么放弃“大而全”的平台化路径，选择 CLI + Agent 架构

2.1 拒绝“评审平台化”的根本原因：评审不是功能，是动作

市面上绝大多数代码评审工具，无论是商业 SaaS 还是开源项目，都默认把“评审”当成一个需要 UI、需要账号、需要权限体系、需要历史归档的“平台级功能”。但真实开发中，评审发生在哪里？就在你敲完git add . && git commit -m "fix: user profile image upload"回车之后，在你点下 GitHub “Create pull request” 按钮之前，在你把 MR 链接发到飞书群问“谁有空帮忙看下这个改动？”的那一刻。它是一个瞬时动作，不是持续服务。所以当我在第一个项目里试过把 CodeReviewBot 部署成 Kubernetes Service，再通过 webhook 接入 GitLab，结果发现：90% 的 PR 提交后没人点“触发评审”，因为多了一步操作；剩下 10% 触发的，平均等待 47 秒才出结果——这已经比人扫一眼 diff 还慢。于是我们彻底推翻重来：评审必须和 git 命令同生命周期。git commit成功，评审就该启动；git push完毕，评审报告就得写进 terminal。这就锁定了 CLI 作为主入口。CLI 不是妥协，而是精准匹配场景——它天然支持管道（pipe）、重定向（redirect）、环境变量注入、exit code 反馈，这些是任何 Web UI 都无法替代的工程能力。

2.2 为什么是 LLM Agent，而不是简单 Prompt + API 调用？

很多人看到热词里有 “LLM Agent”，第一反应是“哦，就是调 ChatGPT API”。错。真正的 Agent 必须满足三个硬性条件：状态记忆、工具调用、决策循环。open-code-review的 Agent 内核长这样：

# 伪代码示意，实际是 Rust 实现 loop { state = load_state() # 从 .open-code-review/state.json 读当前评审阶段 if state.phase == "parse_diff" { diff_content = parse_git_diff(stdin) # 提取变更行、文件路径、hunk 位置 state.context_files = identify_related_files(diff_content) # 基于 import/require 关系找关联文件 save_state(state.next_phase("extract_context")) } else if state.phase == "extract_context" { context_snippets = extract_relevant_code_blocks(state.context_files, diff_content) state.prompt = build_review_prompt(diff_content, context_snippets, config.rules) save_state(state.next_phase("call_llm")) } else if state.phase == "call_llm" { response = call_local_ollama(state.prompt, model=state.model) state.review_result = parse_llm_output(response) save_state(state.next_phase("generate_patch")) } else if state.phase == "generate_patch" { patch = generate_suggested_fix(state.review_result, diff_content) print_terminal_report(state.review_result, patch) exit_code = decide_exit_code(state.review_result) exit(exit_code) } }

看到区别了吗？它不是“扔一个 prompt 过去，拿回一串 JSON 就完事”。它会主动去git show HEAD:src/utils/logger.ts把被修改文件的原始版本拉出来，对比 diff 里的+ console.log(user.id)判断是否属于敏感日志；它会扫描package.json里的devDependencies，确认你新加的zod版本是否与现有@types/zod兼容；它甚至会在state.review_result.severity == "critical"时，自动执行git stash并提示⚠️ 检测到潜在 NPE，请修复后重试：open-code-review --resume。这种基于状态机的渐进式推理，才是 Agent 的价值所在。而所谓 “DeepSeek 是哪个”、“Codex CLI 是什么”，本质上都是在问：你用的这个 Agent，底层调度的是哪家的模型能力？DeepSeek-Coder 是模型，Codex CLI 是微软早期的一个命令行封装工具（已停更），而open-code-review是一个独立的 Agent 框架——它不绑定模型，只定义接口。你可以用--model deepseek-coder:32b调本地 GGUF，也可以用--model https://api.fireworks.ai/inference/v1接 Fireworks 的托管服务，只要返回格式符合ReviewResultSchema 即可。

2.3 CLI 设计的四个不可妥协原则

我们在设计 CLI 参数时，立下四条铁律，至今没破过：

1. 零配置启动：open-code-review --diff-file -必须能直接跑通，哪怕只输出{"status":"success","issues":[]}。所有高级功能（规则集、模型切换、上下文深度）都必须是显式 opt-in，不能有隐藏默认值。
2. Git 原生集成：必须支持git diff | open-code-review --diff-file -和open-code-review --git-ref HEAD~1..HEAD两种模式。前者适配 pre-commit，后者适配 CI 场景。不接受--repo-path /path/to/repo这种反模式——git 本身就能定位工作区。
3. Exit Code 语义化：0= 无问题或仅 warning；1= 有 error 级别问题（如安全漏洞、编译失败风险）；2= 工具链异常（模型加载失败、网络超时）。CI 流水线靠这个做if [ $? -eq 1 ]; then echo "Blocking PR"; exit 1; fi。
4. 输出可管道化：--format json输出标准 JSON，--format markdown输出带 emoji 的终端友好 Markdown，--format sarif输出 VS Code 能直接解析的 SARIF 格式。绝不搞自定义二进制协议。

这四条原则直接决定了它能在飞书机器人、Jenkins、GitLab CI、甚至 Windows PowerShell 里无缝运行。我们试过在某客户现场，运维同学用deveco cli（华为 DevEco Studio 的命令行工具）打包鸿蒙应用时，在build命令后加了一行open-code-review --git-ref HEAD --format sarif > review.sarif，然后把review.sarif丢给 SonarQube 插件——全程没动一行构建脚本。

3. 核心细节解析与实操要点：从 diff 解析到评审结论生成的完整链路

3.1 Git Diffs 不是纯文本，而是结构化变更指令流

很多人以为git diff输出就是一堆+-行，直接喂给 LLM 就行。这是最大误区。真实的 diff 包含三层结构：

• 元数据层：diff --git a/src/api/user.ts b/src/api/user.ts、index abc123...def456 100644—— 告诉你改的是哪个文件、什么类型、hash 值；
• 头信息层：--- a/src/api/user.ts、+++ b/src/api/user.ts、@@ -123,5 +123,8 @@ export const getUser = async (id: string) => {—— 告诉你旧文件名、新文件名、变更起始行号、增删行数；
• 内容层：+ if (!id) throw new Error('User ID is required');、- return await db.query('SELECT * FROM users WHERE id = ?', [id]);—— 真正的代码变更。

open-code-review的 diff 解析器（用 Rust 的git-diff-parsercrate 实现）会把这三层全部提取成结构化对象：

struct DiffHunk { old_file: String, new_file: String, old_start: u32, old_lines: u32, new_start: u32, new_lines: u32, additions: Vec<DiffLine>, // 每行带 content, line_number, is_conflict deletions: Vec<DiffLine>, } struct DiffLine { content: String, line_number: u32, // 在新文件中的绝对行号 is_conflict: bool, // 是否处于 merge conflict 区域 }

为什么必须结构化？因为 LLM 需要精确上下文。比如你新增了一行console.error(e.stack)，如果只给+ console.error(e.stack)，LLM 不知道这行在函数体里还是在 try-catch 外层；但有了new_start: 45,old_lines: 3,new_lines: 4，我们就能从原文件src/api/user.ts的第 42 行开始，向上取 5 行（函数签名、参数解构），向下取 8 行（return 语句、后续逻辑），拼成一个 13 行的上下文块喂给模型。实测下来，上下文精度每提升 1 行，关键问题检出率提高 11.3%，而盲目扩大上下文（比如给整个文件）会导致模型注意力稀释，漏掉 37% 的边界 case。

3.2 上下文裁剪不是“越多越好”，而是“恰到好处”

open-code-review默认的上下文策略叫3-5-3 Rule：

• 3 行前置：变更块上方最近的 3 行非空、非注释代码（通常是函数签名或 if 条件）；
• 5 行后置：变更块下方最近的 5 行非空、非注释代码（通常是 return 或后续调用）；
• 3 个关联文件：基于 AST 分析，找出被修改文件 import/require 的、且本次 diff 中也发生了变更的最多 3 个文件（比如改了user.service.ts，又改了user.dto.ts，那就把 dto 文件也纳入上下文）。

这个规则不是拍脑袋定的。我们用 127 个真实 GitHub PR 做了 A/B 测试：固定模型和 prompt，只变上下文长度。结果发现：

峰值就在 30 行左右。超过这个值，模型开始“顾此失彼”——它会过度关注上下文里某个无关的工具函数，反而忽略 diff 本身的关键风险。所以open-code-review的--context-lines参数默认是30，且强制要求用户必须显式设置才能突破上限，避免误用。

3.3 Review Prompt 的工程化设计：不是写作文，是写编译器

Prompt 不是“请帮我检查这段代码”，而是像写编译器规则一样严谨。open-code-review的核心 prompt 模板包含五个强制 section：

1. Role Definition：You are a senior backend engineer at a fintech company, reviewing production code for security, correctness, and maintainability. You never suggest stylistic changes unless they impact safety.
   → 锁定角色、领域、优先级，杜绝“这个变量名不够语义化”这类无效反馈。

2. Input Schema：明确定义输入格式，包括diff_hunk、file_path、context_before、context_after、related_files的 JSON 结构，要求模型必须严格按 schema 输出。

3. Rule Set：内嵌一个 YAML 规则库，例如：

   - id: "security-sql-injection" severity: "critical" description: "Detects direct string concatenation in SQL queries" pattern: "query\\s*\\+\\s*['\"].*['\"]" fix_suggestion: "Use parameterized queries or an ORM method"

   规则可动态加载，支持--rules ./my-rules.yaml覆盖。

4. Output Schema：强制要求 JSON 输出，字段包括issues: [{id, file, line, message, severity, suggestion, patch}]，其中patch字段必须是标准 unified diff 格式，能被git apply直接消费。

5. Failure Mode Guardrails：If you cannot determine the programming language from the diff, output {"issues": []}. If the diff contains binary files or non-text content, skip this hunk.
   → 防止模型胡说八道，保证输出稳定。

这套设计让open-code-review在接入 Qwen2.5-Coder-7B 时，JSON 输出合规率达到 99.2%（测试 5000 次），远高于裸调 API 的 73.5%。因为模型不是在“自由发挥”，而是在“填空答题”。

3.4 Patch 生成：不是代码补全，是语义对齐的 diff 逆向工程

最常被问的问题是：“它真能修 bug 吗？”答案是：它不修 bug，它修 diff。open-code-review从不尝试生成完整函数，它只做一件事：基于diff_hunk和suggestion，生成一个最小化的、语义正确的、能被git apply应用的 patch。

举个真实例子。diff 是：

+ const user = await db.get(id); + if (!user) throw new Error('User not found'); + return user; - return await db.get(id);

模型 suggestion 是：“添加空值检查，避免调用方收到 undefined”。

open-code-review的 patch 生成器会：

1. 解析原 diff 的old_start=123,old_lines=1,new_start=123,new_lines=3；
2. 从原文件src/api/user.ts第 123 行读取return await db.get(id);；
3. 根据 suggestion，构造三行新代码；
4. 生成标准 patch：

--- a/src/api/user.ts +++ b/src/api/user.ts @@ -122,1 +122,3 @@ - return await db.get(id); + const user = await db.get(id); + if (!user) throw new Error('User not found'); + return user;

注意：它没有碰第 122 行之前的代码，也没有动第 126 行之后的逻辑。这就是“语义对齐”——patch 必须精确对应 diff 的变更范围，否则git apply会失败。我们为此写了专门的 patch 校验模块，每次生成后自动执行echo "$PATCH" | git apply --check --verbose，失败则降级为纯文本 suggestion。

4. 实操过程与核心环节实现：从安装到嵌入 CI 的完整流水线

4.1 安装与本地验证：5 分钟跑通第一个评审

open-code-review支持三种安装方式，按推荐顺序排列：

1. Ollama 一键部署（最推荐，适合新手）：

   # 1. 安装 Ollama（macOS） brew install ollama # 2. 拉取轻量模型（30秒） ollama pull qwen2.5-coder:7b # 3. 安装 CLI（Rust 编译版，跨平台） curl -fsSL https://raw.githubusercontent.com/open-code-review/install/main/install.sh | sh # 4. 验证安装 open-code-review --version # 5. 本地跑一个 demo（用当前 repo 的最新 commit diff） git diff HEAD~1 HEAD | open-code-review --diff-file - --model qwen2.5-coder:7b --format markdown

2. Docker 运行（适合隔离环境）：

   docker run -it --rm \ -v $(pwd):/workspace \ -v ~/.ollama:/root/.ollama \ --network host \ ghcr.io/open-code-review/cli:latest \ --git-ref HEAD~1..HEAD \ --model deepseek-coder:32b \ --format json

3. 源码编译（适合定制开发）：

   git clone https://github.com/open-code-review/cli.git cd cli cargo build --release cp target/release/open-code-review /usr/local/bin/

提示：首次运行会自动下载qwen2.5-coder:7b模型（约 4.2GB），建议在~/.ollama/models/目录下预置好模型文件，避免重复下载。如果遇到unable to locate the codex cli binary类错误，99% 是因为 PATH 没配对，用which open-code-review确认路径，然后export PATH="$PATH:/usr/local/bin"加到~/.zshrc。

4.2 配置文件.open-code-review.yaml：让评审规则真正落地

CLI 支持全局配置文件，放在项目根目录，内容示例：

# .open-code-review.yaml model: "qwen2.5-coder:7b" # 默认模型，可被 --model 覆盖 timeout: 120 # LLM 调用超时（秒） rules: - id: "security-hardcoded-secret" severity: "critical" pattern: '["\'](?i)(api[_-]?key|token|password|secret)["\']\s*[:=]\s*["\'].*["\']' - id: "best-practice-missing-test" severity: "warning" pattern: 'export\s+function\s+(\w+)\s*\(' check_file: "test/**/*.test.ts" missing_message: "Function {{func_name}} has no unit test coverage" output: format: "markdown" # 默认输出格式 show_patch: true # 是否显示建议 patch max_issues: 10 # 单次最多报告 10 个问题 git: ignore_patterns: # git diff 时忽略的文件 - "**/*.md" - "**/node_modules/**" - "**/dist/**"

这个文件是团队协作的核心。它把“代码规范”从口头约定变成了可执行的机器规则。我们有个客户把rules里加了一条：

- id: "compliance-gdpr-email" severity: "critical" pattern: '\.sendEmail\([^)]*email[^)]*\)' fix_suggestion: "Use anonymized email hash or obtain explicit consent per GDPR Article 6"

结果上线第一天就拦住了 3 个 PR 里硬编码用户邮箱的发送逻辑。

4.3 嵌入 pre-commit hook：让评审成为提交前的肌肉记忆

在.pre-commit-config.yaml里加入：

repos: - repo: local hooks: - id: open-code-review name: Open Code Review entry: bash -c 'git diff --cached | open-code-review --diff-file - --format markdown || exit 1' language: system types: [python, javascript, typescript] pass_filenames: false

然后执行：

pre-commit install

从此，每次git commit，都会先跑一遍评审。如果检测到 critical 问题，commit 会被中断，并在 terminal 显示：

❌ CRITICAL: security-hardcoded-secret in src/config/index.ts:15 Hardcoded API key detected: 'sk-xxxxx' Suggestion: Load from environment variable process.env.API_KEY Patch: - const API_KEY = 'sk-xxxxx'; + const API_KEY = process.env.API_KEY || '';

注意：pre-commit 里git diff --cached是关键，它只检查暂存区（staged）的变更，避免评审未git add的脏文件。我们实测发现，83% 的低级错误都在暂存区阶段被拦截，根本不会进远程分支。

4.4 接入 GitHub Actions：让评审成为 PR 的第一道门禁

在.github/workflows/code-review.yml里：

name: Code Review on: [pull_request] jobs: review: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: fetch-depth: 2 # 必须 fetch 至少 2 个 commit，才能算出 diff - name: Setup Ollama uses: jetify-com/ollama-github-action@v2 with: version: "0.3.1" - name: Pull Model run: ollama pull qwen2.5-coder:7b - name: Run Open Code Review id: review run: | # 生成 PR diff git diff ${{ github.event.pull_request.base.sha }} ${{ github.event.pull_request.head.sha }} > pr.diff # 执行评审 open-code-review --diff-file pr.diff --model qwen2.5-coder:7b --format sarif > review.sarif # 输出为 GitHub Annotation cat review.sarif | jq -r '.runs[0].results[] | "\(.locations[0].physicalLocation.artifactLocation.uri):\(.locations[0].physicalLocation.region.startLine):\(.message.text)"' | while read line; do echo "::error $line" done - name: Upload SARIF Report uses: github/codeql-action/upload-sarif@v3 with: sarif_file: review.sarif

这个 workflow 的精妙之处在于：它用git diff base..head精确获取 PR 范围内的变更，而不是git diff HEAD~1（可能拿到 merge commit）。同时，jq解析 SARIF 并转成::error，能让问题直接标在 GitHub PR 的代码行上，点击就跳转，体验媲美 CodeQL。

4.5 飞书机器人接入：让评审结论直达协作现场

飞书不支持直接执行 CLI，但我们用了一个巧妙的 Webhook 方案：

1. 在服务器上起一个轻量 HTTP 服务（用 Python Flask）：

   from flask import Flask, request, jsonify import subprocess import tempfile import os app = Flask(__name__) @app.route('/review', methods=['POST']) def trigger_review(): data = request.json diff_content = data.get('diff') with tempfile.NamedTemporaryFile(mode='w', delete=False) as f: f.write(diff_content) f.flush() # 调用 CLI result = subprocess.run( ['open-code-review', '--diff-file', f.name, '--model', 'qwen2.5-coder:7b', '--format', 'json'], capture_output=True, text=True ) os.unlink(f.name) return jsonify({"review_result": json.loads(result.stdout)})

2. 在飞书群机器人设置里，把 Webhook URL 指向这个服务；

3. 开发者在飞书发消息@机器人 review https://github.com/org/repo/pull/123，机器人自动抓取 diff 并返回结构化报告。

我们客户用这个方案，把平均 PR 评审等待时间从 2.3 小时（等人工）降到 47 秒（自动），而且所有报告都留痕在飞书，可追溯。

5. 常见问题与排查技巧实录：那些文档里不会写的坑和解法

5.1 模型加载失败：failed to start. unable to locate the codex cli binary

这个错误信息极具迷惑性，它其实和 Codex CLI 完全无关。真实原因是open-code-review在启动时，会按顺序查找以下路径的模型文件：

1. --model指定的路径（如--model /models/deepseek-32b.Q4_K_M.gguf）；
2. OLLAMA_MODELS环境变量指向的目录；
3. ~/.ollama/models/（默认）；
4. /usr/share/ollama/.ollama/models/（系统级）。

如果所有路径都找不到，它会尝试调用ollama list，如果ollama命令不存在或返回空，则报这个错。解决方案分三步：

1. 确认 Ollama 正在运行：systemctl --user status ollama（Linux）或活动监视器里找ollama进程（macOS）；
2. 确认模型已拉取：ollama list应该显示qwen2.5-coder 7b latest；
3. 如果用的是自定义模型路径，必须加file://前缀：--model file:///path/to/model.gguf。

实操心得：我们曾在一个客户现场卡了 3 小时，最后发现是他们的 macOS 系统启用了 SIP（System Integrity Protection），阻止了 Ollama 写入~/Library/Application Support/Ollama。解决方案是sudo chown -R $(whoami) ~/Library/Application\ Support/Ollama。

5.2 评审结果为空：{"issues":[]}但明明有 bug

这是最常被质疑的点。根本原因有三个：

• 上下文不足：模型没看到关键 import。用--debug-context参数重新运行，它会输出实际传给模型的上下文块。我们发现 68% 的空结果是因为package.json里type: "module"没被识别，导致 AST 解析失败，关联文件为空。
• 规则 pattern 写错：正则表达式没转义。比如想匹配console.log(，写成console\.log\(才对，写成console.log(会被当作字面量。
• 模型能力天花板：Qwen2.5-Coder-7B 对 Rust 的 lifetime 错误识别率只有 22%，但对 TypeScript 的 optional chaining 识别率达 94%。这时要换模型：--model deepseek-coder:32b。

快速诊断命令：

# 查看实际传入的上下文 git diff HEAD~1 | open-code-review --diff-file - --debug-context # 强制用最大上下文（调试用） git diff HEAD~1 | open-code-review --diff-file - --context-lines 100 --model qwen2.5-coder:7b # 检查规则是否生效 echo '+ console.log("API KEY:", process.env.API_KEY)' | open-code-review --diff-file - --rules ./rules.yaml --debug-rules

5.3 Patch 应用失败：git apply: corrupt patch at line X

这是因为open-code-review生成的 patch 和当前工作区代码不匹配。常见于：

• 你在git diff后又手动改了文件，但没git add；
• 模型 suggestion 要求修改的行，在当前文件里已经不存在（比如你 rebase 了）；
• patch 里引用了不存在的文件（--- a/nonexistent.ts）。

终极解法：永远用--dry-run先测试：

git diff HEAD~1 | open-code-review --diff-file - --model qwen2.5-coder:7b --dry-run > patch.diff git apply --check patch.diff # 检查是否能应用 git apply patch.diff # 确认无误后应用

注意：--dry-run不会真的调用模型，它只是模拟 patch 生成逻辑，速度极快，适合集成到编辑器快捷键里。

5.4 性能瓶颈：评审一次要 8 秒，CI 等不及

open-code-review的耗时主要在三块：diff 解析（<0.1s）、上下文提取（0.3s）、LLM 推理（占 95%）。优化方向很明确：

• 换小模型：qwen2.5-coder:1.5b比7b快 4.2 倍，关键问题检出率只降 6.3%；
• 量化模型：用qwen2.5-coder:7b-q4_k_m（4-bit 量化），内存占用从 14GB 降到 5.2GB，速度提升 2.1 倍；
• 缓存机制：对相同 diff hash，缓存 LLM 输出 10 分钟（--cache-ttl 600）；
• 并发限制：CI 里用--max-concurrent 2防止 Ollama 被打爆。

我们有个客户在 32 核服务器上，用--model qwen2.5-coder:1.5b-q4_k_m --max-concurrent 4，把平均评审时间压到 1.7 秒，完全满足 CI 的 3 秒 SLA。

5.5 与现有工具链冲突：trae cli、zcode cli、claude cli同时存在

这些 CLI 工具本质都是 LLM 的命令行封装，它们冲突的根源是都试图接管 stdin/stdout 和 exit code 语义。解决方案是进程隔离：

• trae cli专注代码解释，用--format plain；
• zcode cli专注代码生成，用--mode generate；
• open-code-review专注评审，用--mode review（默认）；

在 CI 脚本里明确分工：

# 先用 trae 解释变更意图 git diff HEAD~1 | trae explain --format json > intent.json # 再用 open-code-review 评审 git diff HEAD~1 | open-code-review --diff-file - --intent-file intent.json # 最后用 zcode 生成测试 zcode generate-test --file src/api/user.ts --intent "$(cat intent.json | jq -r '.intent')"

实操心得：不要试图让一个 CLI 做所有事。open-code-review的哲学是“做深不做广”——它不生成代码，不解释代码，不画架构图，就死磕评审这一件事。把这件事做到 99 分，比做个 60 分的“全能选手”有用得多。

6. 进阶扩展与未来演进：从 CLI 工具到团队评审基础设施

6.1 评审数据湖：把每次评审变成可分析的资产

open-code-review的--format jsonl模式，会为每个 diff hunk 输出一行 JSON，天然适配大数据分析。我们帮一个客户搭建了评审数据湖：

# 每次 PR 评审结果存入 S3 open-code-review --git-ref $PR_BASE..$PR_HEAD --format jsonl > s3://my-bucket/reviews/$(date +%s).jsonl # 用 Athena 查询高频问题 SELECT issue_id, COUNT(*) as cnt FROM reviews WHERE issue_severity = 'critical' GROUP BY issue_id ORDER BY cnt DESC LIMIT 10;

结果发现security-hardcoded-secret占所有 critical 问题的 41%，于是他们立刻在入职培训里加了“密钥管理”专项，两周后该问题下降 76%。

6.2 模型微调：用团队自己的代码训练专属评审模型

`open-code