AI代码审查工具Continue：将AI检查像单元测试一样代码化

1. 项目概述：什么是 Continue？

如果你和我一样，每天都要在 GitHub 的 Pull Request 海洋里游泳，那你肯定对“代码审查”这件事又爱又恨。爱的是它能帮你发现潜在问题，恨的是它耗时耗力，尤其是在面对海量、重复性的检查任务时——比如“有没有硬编码的密钥？”、“新增的 API 有没有做输入校验？”。这些检查至关重要，但手动去做，或者写一堆零散的脚本去自动化，维护成本又很高。

最近我在一个开源项目里发现了一个叫Continue的工具，它提出了一种非常有意思的思路：把 AI 驱动的代码检查（AI Checks）像单元测试一样，用源代码进行管理和强制执行。简单来说，你可以在项目根目录下创建一个.continue/checks/文件夹，里面放一些用 Markdown 或 YAML 写的“检查描述文件”。然后，Continue 会在每次 PR 提交时，自动运行一个 CLI 工具，调用配置好的大语言模型（比如 GPT-4、Claude 等），根据你的描述去审查代码变更。检查通过就是绿色勾，不通过则直接给出一个建议性的代码差异（Diff），告诉你哪里有问题、可以怎么改。

这不再是另一个孤立的 AI 代码补全插件，而是一个将 AI 能力深度集成到团队开发工作流和 CI/CD 管道中的基础设施。它的核心价值在于“可版本控制”和“可强制执行”，让 AI 审查从个人辅助工具，变成了团队共享、可迭代、可信任的质量关卡。

2. 核心设计思路与工作原理拆解

2.1 核心理念：AI as Code

Continue 最吸引我的地方是它的理念：AI as Code。我们习惯于将基础设施（Infrastructure as Code）、配置（Configuration as Code）进行代码化管理，现在它将“AI 审查逻辑”也进行了代码化。

1. 版本控制与协作：所有的检查规则都以纯文本文件（.md或.yml）的形式存放在.continue/checks/目录下。这意味着你可以用git来管理它们的变更历史，用 Pull Request 来讨论和更新检查规则，团队中的任何成员都可以清晰地看到当前生效的检查项是什么、为什么这么设置。这解决了传统 AI 工具配置散落、难以同步和审计的问题。
2. 强制执行与一致性：通过集成到 CI（如 GitHub Actions）中，这些 AI 检查不再是可选项，而是每次代码合并前必须通过的关卡。这确保了代码库在特定质量或安全标准上的一致性，无论提交者是谁。
3. 可解释性与迭代：检查失败后，Continue 不仅会说“不通过”，还会生成一个具体的代码 Diff 建议。这个建议本身就是对“为什么失败”的最佳解释。同时，由于规则是代码，你可以很容易地根据实际误报或漏报情况，去调整检查的描述，让 AI 的理解更精准，实现规则的持续迭代优化。

2.2 架构与工作流程

Continue 的架构非常清晰，主要由两部分组成：

1. Continue CLI (cn)：这是一个开源命令行工具，是执行 AI 检查的核心引擎。它负责读取项目中的检查定义文件，获取当前 PR 的代码差异，调用配置的 LLM API，解析模型的响应，并最终输出通过/失败的结果以及建议的修改。
2. 检查定义文件：位于.continue/checks/目录下，是用户编写的“任务说明书”。文件格式支持 YAML Frontmatter 的 Markdown，结构清晰易读。

其工作流程可以概括为以下几步，我画了一个简单的示意图来帮助理解：

[开发者提交PR] -> [CI 系统（如 GitHub Actions）触发] -> [运行 `cn` 命令] -> [CLI 读取 `.continue/checks/*.md` 文件] -> [CLI 获取 PR Diff，结合检查描述，构造 LLM 提示词] -> [调用 LLM API（如 OpenAI, Anthropic）] -> [解析 LLM 响应，判断通过与否] -> [通过：更新状态为成功] -> [不通过：生成建议 Diff，更新状态为失败并输出详情]

这个流程将一次性的、模糊的“让 AI 看看代码”，变成了一个结构化的、可重复的、结果可预期的自动化检查任务。

2.3 与现有工具链的对比

你可能用过 GitHub Copilot 或者 Cursor，它们擅长在编码时实时提供建议。你也可能用过 SonarQube 或 Semgrep 这类静态分析工具，它们基于固定的规则进行模式匹配。

Continue 处在两者之间一个独特的位置：

• vs. 实时 AI 辅助工具：Continue 是“异步”和“批处理”的。它不在你写代码时打扰你，而是在代码提交、准备合并这个关键节点进行集中审查。它的目标是保障合并到主分支的代码质量，而非辅助编写过程。
• vs. 传统静态分析：静态分析工具规则强大但相对僵化，对于需要理解代码语义、上下文和意图的复杂检查（例如“这个错误处理是否用户友好？”、“这个函数命名是否清晰反映了其职责？”）往往力不从心。Continue 利用 LLM 的自然语言理解能力，可以处理这类更抽象、更基于语义的检查，其规则用人类语言编写，灵活度极高。

简单说，Continue 用 AI 填补了那些“重要但用传统自动化手段难以实现”的代码审查空白。

3. 从零开始上手：安装与基础配置

3.1 安装 Continue CLI (cn)

Continue CLI 是这一切的基础。官方提供了几种安装方式，都非常简单。

macOS / Linux 用户：推荐使用一键安装脚本，这通常是最快最省事的方式。打开你的终端，执行以下命令：

curl -fsSL https://raw.githubusercontent.com/continuedev/continue/main/extensions/cli/scripts/install.sh | bash

这个脚本会自动下载适合你系统的最新版cn可执行文件，并将其放到你的系统路径下。

Windows 用户：在 PowerShell（建议以管理员身份运行）中执行：

irm https://raw.githubusercontent.com/continuedev/continue/main/extensions/cli/scripts/install.ps1 | iex

通过 npm 安装：如果你已经安装了 Node.js (版本 20 或以上)，也可以使用 npm 进行全局安装：

npm i -g @continuedev/cli

安装完成后，在终端输入cn --version或直接输入cn，如果看到帮助信息，说明安装成功。

注意：安装脚本可能会请求权限将二进制文件写入/usr/local/bin或类似目录。如果你在非管理员权限环境下，或者更喜欢手动管理，也可以从项目的 GitHub Releases 页面直接下载对应平台的二进制文件，然后手动将其移动到你的 PATH 环境变量包含的目录中。

3.2 初始化项目与编写第一个检查

安装好 CLI 后，我们不需要在全局做复杂配置。所有的配置都是基于项目的。让我们在一个现有的 Git 仓库中开始。

1. 创建检查目录： 在你的项目根目录下，创建.continue/checks/目录。这个点号开头的文件夹通常是隐藏的，用于存放配置。

   mkdir -p .continue/checks

2. 编写第一个检查文件： 让我们创建一个最基本的安全检查。在.continue/checks/目录下，新建一个名为security-basics.md的文件。

   检查文件的基本结构是：顶部的 YAML Frontmatter 用于元数据，后面跟 Markdown 格式的检查指令。一个最简单的例子如下：

   --- name: Security Basics Scan description: 检查本次变更中是否存在基础安全漏洞 --- 请仔细审查本次代码提交的差异（Diff），并检查： - 是否有任何硬编码的密码、API密钥、令牌或密钥？如果有，请指出并建议使用环境变量或安全的密钥管理服务。 - 新增的数据库查询是否使用了参数化查询或ORM的安全方法，以防止SQL注入？ - 新增的API接口是否对用户输入进行了验证或清理？

   这就是一个完整的检查定义。name和description会在 CI 状态中显示，方便识别。而---之后的内容，就是发给 AI 模型的“任务指令”。

3. 本地试运行： 在提交到 CI 之前，我们可以先在本地模拟运行，看看效果。首先，你需要设置 LLM 的 API 密钥。Continue 默认支持 OpenAI，也支持其他如 Anthropic 的模型。

   设置环境变量（以 OpenAI 为例）：

   export OPENAI_API_KEY='你的-sk-...密钥'

   或者，更安全的方式是使用cn的配置命令。首次运行cn时，它可能会引导你进行配置。你也可以手动创建或编辑~/.continue/config.json文件来配置模型和密钥。

   然后，在项目根目录下，运行：

   cn --local

   这个--local参数会让cn分析你当前 Git 工作区与最新提交之间的差异（即你尚未暂存或提交的修改），并应用所有.continue/checks/下的检查。它会输出每项检查的结果，如果发现问题，会给出建议的代码修改。

3.3 核心配置详解：模型与上下文

要让cn正确工作，关键在于配置它如何与 LLM 对话。这主要通过配置文件完成。配置文件可以放在两个位置：

• 用户全局配置：~/.continue/config.json
• 项目本地配置：项目根目录/.continue/config.json

项目本地配置的优先级更高。一个典型的配置示例如下：

{ "models": [ { "title": "GPT-4", "provider": "openai", "model": "gpt-4-turbo-preview", "apiKey": "${OPENAI_API_KEY}" } ], "contextProviders": [ { "name": "diff", "params": {} }, { "name": "github", "params": { "repo": "你的用户名/你的仓库名" } } ] }

• models：定义可用的模型。provider可以是openai,anthropic,ollama(本地模型) 等。apiKey可以直接写（不安全），更推荐用"${ENV_VAR_NAME}"的格式引用环境变量。
• contextProviders：这是 Continue 非常强大的一个特性。它定义了在执行检查时，除了 PR Diff 本身，还要给模型提供哪些上下文信息。
  • diff：这是默认且必须的，提供本次提交的代码差异。
  • github：提供 GitHub Issue、PR 描述、相关评论等上下文。这对于让 AI 理解本次修改的“目的”至关重要，能极大提升审查的准确性。例如，AI 知道这个 PR 是为了修复某个特定的 Bug，它就会更关注修改是否真正解决了问题，而不会对重构代码提出无关的“风格建议”。

实操心得：在配置githubcontext provider 时，你需要在 CI 环境中提供 GitHub Token（通常通过GITHUB_TOKEN环境变量自动提供，或在 GitHub Actions 中通过secrets.GITHUB_TOKEN传递）。确保你的 CI 工作流文件中有正确的权限设置，允许读取仓库内容。

4. 深入实战：编写高效的 AI 检查规则

编写检查规则文件，本质上是“提示词工程”在代码审查领域的应用。写得好，AI 就是火眼金睛；写得模糊，就可能产生大量误报或漏报。

4.1 检查文件的结构与语法进阶

除了基本的name和description，Frontmatter 还支持更多参数来精细控制检查行为：

--- name: Code Style & Clarity Review description: 检查代码风格、命名清晰度和函数复杂度 model: gpt-4-turbo-preview # 可选：为此检查指定特定模型，覆盖全局配置 context: - diff - github # 指定此检查需要的上下文提供者 temperature: 0.1 # 可选：控制模型输出的随机性，审查任务建议调低（如0.1-0.3）以获得更确定的结果 --- ### 审查目标 请扮演资深代码审查员的角色，专注于代码的可读性和可维护性。 ### 审查规则 1. **命名检查**： - 变量、函数、类名是否清晰描述了其目的？ - 避免使用 `data`, `info`, `temp` 等模糊名称。 - 布尔变量名是否以 `is`, `has`, `can` 等开头？ 2. **函数复杂度**： - 新增或修改的函数是否过长（建议超过50行需警惕）？ - 函数的圈复杂度是否过高？一个函数是否做了太多事情？ 3. **注释与文档**： - 新增的复杂逻辑是否有必要的注释解释“为什么”这么做？ - 公共API（函数、类）的文档字符串是否更新？ ### 输出要求 - 如果发现问题，**必须**在回复中首先以“**问题：[简短标题]**”的格式列出。 - 对于每个问题，**必须**提供具体的代码行引用（例如：`文件:行号`）和清晰的解释。 - 最后，**必须**提供一个完整的、可直接应用的代码 Diff 建议，用于修复所有已发现问题。

这个例子展示了如何通过更结构化的提示词，来引导模型进行更聚焦、更一致的审查。temperature参数调低可以让模型的输出更稳定，减少“这次通过，下次不通过”的随机性。

4.2 不同场景的检查规则示例

让我们看几个针对不同场景的、更具体的检查规则示例。

示例一：面向特定框架的检查（如 React Hooks）

--- name: React Hooks Rules Check description: 确保 React Hooks 使用符合规则 --- 你是一个 React 专家。请检查本次代码变更中所有与 React 组件相关的部分，确保： 1. **规则检查**：Hooks 只能在函数组件顶层或其他 Hooks 中调用，不能在循环、条件或嵌套函数中调用。 2. **依赖数组**：`useEffect`, `useCallback`, `useMemo` 的依赖数组是否完整列出了所有在回调中使用的外部变量？是否有不必要的依赖导致重复渲染？ 3. **状态更新**：对于基于前一个状态更新的情况，是否使用了函数式更新（例如 `setCount(prev => prev + 1)`）？ 4. **清理副作用**：`useEffect` 中创建的订阅、定时器等，是否返回了清理函数？ 如果发现任何违反上述规则的情况，请明确指出文件、行号和具体问题，并提供修正后的代码 Diff。

示例二：数据库迁移或数据模型变更审查

--- name: Database Migration Review description: 审查数据库迁移脚本和数据模型变更 context: - diff - github # 特别需要PR描述来理解变更背景 --- 请结合本次 PR 的描述和代码变更，审查所有 `.sql` 迁移文件或 ORM 模型定义文件的更改： **安全性检查**： - 是否有删除大量数据的 `DELETE` 或 `DROP` 语句？是否提供了回滚方案或已在 PR 描述中明确说明？ - 新增的列是否有合理的默认值或设置为 `NULLABLE`，以避免在已有数据上执行失败？ - 是否添加了必要的索引？特别是对用于查询条件（WHERE）或连接（JOIN）的列。 **性能检查**： - 新增的索引是否过多？是否可能影响写性能？ - 对大数据表执行的 `ALTER TABLE` 操作，是否考虑了锁表时间和对线上服务的影响？（如果 PR 描述未提及，请提出疑问） **一致性检查**： - 模型定义（如 Prisma Schema、SQLAlchemy 类）的变更是否与迁移脚本同步？ - 枚举类型的变更是否考虑了已有数据的兼容性？ 请将发现的问题分为【阻塞性问题】（必须修复）和【建议性问题】两类。

示例三：API 变更兼容性审查

--- name: Public API Compatibility description: 检查对公共API的变更是否破坏向后兼容性 --- 你负责维护一个面向外部用户的 API 的向后兼容性。请检查本次变更： 1. **破坏性变更识别**： - 是否**删除**了任何公开的 API 端点、字段、枚举值或参数？ - 是否**重命名**了任何公开的类、方法、属性或参数名？ - 是否**改变**了现有 API 端点、方法的请求/响应结构或数据类型（例如，将字符串字段改为整数）？ - 是否**收紧**了输入验证（例如，原来可选的参数变为必填，或允许的字符串长度变短）？ 2. **如果存在破坏性变更**： - 检查 PR 描述或关联的 Issue 中，是否明确声明这是一次破坏性变更（Breaking Change）？ - 是否提供了迁移指南或替代方案？ - 如果这是一个库，版本号是否按照语义化版本（SemVer）规则进行了主版本号升级？ 请列出所有识别的潜在破坏性变更，并评估其影响程度。

4.3 编写技巧与注意事项

1. 具体化、场景化：避免“检查代码质量”这种模糊指令。要具体，如“检查函数长度是否超过50行”、“检查是否有未处理的Promise拒绝”。
2. 提供正面范例：如果可能，在指令中给出“好代码”的例子，这比单纯说“不要怎么做”更有效。例如：“错误信息应该帮助用户解决问题，例如‘文件未找到，请检查路径 XXX’，而不是简单的‘操作失败’。”
3. 分步骤、结构化：像上面的例子一样，用列表、分类来组织你的审查要点，这有助于模型系统性地思考。
4. 明确输出格式：严格要求模型以特定格式（如“问题：...建议：...”）输出，这便于 CLI 解析结果并生成报告。Continue CLI 依赖模型输出中的特定标记来识别“通过”或“失败”以及建议的 Diff。
5. 迭代与优化：第一批规则上线后，肯定会遇到误报（False Positive）和漏报（False Negative）。不要气馁，这是正常过程。将出错的案例记录下来，回头优化你的检查描述。例如，如果 AI 总是误判某个特定模式，你可以在指令中加入例外说明：“注意：在utils/legacy/目录下的old_*.js文件中的getData函数调用可以忽略，这是待重构的遗留代码。”

踩坑记录：初期我们曾写过一个检查：“确保所有错误都被妥善处理”。结果 AI 对很多仅仅打印日志的try-catch也报错，认为“打印日志不是处理”。后来我们将指令修改为：“检查是否有同步函数中未捕获的异常抛出，或异步操作中未处理的 Promise 拒绝（.catch或await在try中）。对于已记录日志的错误，视为已处理。” 误报率大大降低。

5. 集成到 CI/CD：实现自动化强制执行

本地测试通过后，下一步就是将其集成到团队的协作流程中，通常是 GitHub Actions（其他 CI 如 GitLab CI、Jenkins 原理类似）。

5.1 配置 GitHub Actions 工作流

在你的项目.github/workflows/目录下，创建一个新的 YAML 文件，例如continue-checks.yml。

name: Continue AI Checks on: pull_request: types: [opened, synchronize, reopened] # PR创建、新推送、重新打开时触发 push: branches: [main, master] # 也可在直接推送主分支时进行检查（作为额外保障） jobs: continue-checks: runs-on: ubuntu-latest permissions: contents: read pull-requests: write # 需要此权限以发布检查状态和评论 statuses: write steps: - name: Checkout code uses: actions/checkout@v4 with: fetch-depth: 0 # 获取完整历史，`cn`可能需要 - name: Setup Node.js (if installing via npm) uses: actions/setup-node@v4 with: node-version: '20' - name: Install Continue CLI run: npm install -g @continuedev/cli - name: Run Continue Checks env: OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }} # 在仓库Settings/Secrets中配置 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # 由GitHub自动提供，用于读取PR信息 run: | cn --github-pr ${{ github.event.pull_request.number }} --github-repo ${{ github.repository }}

这个工作流做了以下几件事：

1. 在 PR 相关事件触发时运行。
2. 获取代码。
3. 通过 npm 安装cnCLI。
4. 运行cn并传递两个关键参数：
   • --github-pr: 指定要检查的 PR 编号。
   • --github-repo: 指定仓库全名（如owner/repo）。
5. 通过环境变量传递必要的密钥：OPENAI_API_KEY需要你在仓库的 Settings -> Secrets and variables -> Actions 中手动添加；GITHUB_TOKEN是 GitHub 自动为工作流生成的，具有访问当前仓库的权限。

5.2 理解检查状态与结果

工作流运行后，cn会为.continue/checks/目录下的每个检查文件单独创建一个状态检查（Status Check）。

• 成功（绿色勾）：表示该检查项下未发现任何问题。
• 失败（红色叉）：表示 AI 根据检查规则发现了问题。点击详情，你可以看到：
  1. 问题摘要：AI 列出了它发现的所有问题点。
  2. 建议的 Diff：这是最实用的部分！Continue 会尝试生成一个修复这些问题的代码补丁。在 GitHub 的检查详情页面，这个 Diff 通常可以直接被应用或作为进一步修改的参考。

分支保护规则：你可以在仓库的 Settings -> Branches -> Branch protection rules 中，为主分支（如main）设置保护规则，要求必须通过“Continue AI Checks”中的所有状态检查，才能合并 PR。这是实现“强制执行”的关键一步。

5.3 高级 CI 配置与优化

1. 缓存与性能：安装@continuedev/cli可能会成为工作流中耗时的一步。可以考虑使用 GitHub Actions 的缓存功能来缓存 npm 全局安装目录。

   - name: Cache Continue CLI uses: actions/cache@v3 with: path: ~/.npm key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }} restore-keys: | ${{ runner.os }}-node-

2. 选择性运行：如果项目检查很多，或者模型调用成本较高，你可能希望只在某些情况下运行检查。可以通过路径过滤或标签过滤来实现。

   on: pull_request: paths: - 'src/**' # 只当 src 目录下的文件有变更时才运行 - '.continue/checks/**' # 或者检查规则本身有更新时也运行

3. 使用更快的模型或本地模型：对于早期、快速的检查，可以使用 GPT-3.5-Turbo 等更快、更便宜的模型。对于关键、复杂的审查，再用 GPT-4。这可以在项目级的.continue/config.json中，为不同的检查文件指定不同的model参数来实现。对于追求零成本和隐私的团队，可以配置ollamaprovider 来使用本地运行的 Llama 2、CodeLlama 等模型。

4. 处理大 Diff：如果 PR 变更非常大，可能会超出模型的上下文长度。Continue 的策略通常是会将大 Diff 分块处理。但在 CI 中，你可能需要设置超时时间，并为cn命令添加--max-tokens或--timeout参数来控制单次检查的规模。

6. 常见问题排查与实战技巧

在实际部署和使用 Continue 的过程中，我遇到并总结了一些典型问题和解决方案。

6.1 模型相关问题

6.2 CI/CD 集成问题

6.3 检查规则效果优化

6.4 成本控制与监控

使用商业 LLM API 会产生费用。以下是一些控制成本的技巧：

1. 选择性运行：如前所述，通过路径过滤，只在关键目录变更时触发检查。
2. 模型分级：为不同重要性的检查配置不同价位的模型。例如，“代码风格”检查用便宜的模型，“安全审查”用贵的模型。
3. 设置预算与告警：在 OpenAI 或 Anthropic 的控制台设置每月使用预算和告警。
4. 本地模型替代：对于内部项目或对延迟不敏感的场景，强烈考虑使用 Ollama 部署本地模型（如 CodeLlama）。在.continue/config.json中配置provider: "ollama",model: "codellama:13b"，并将baseUrl指向本地服务地址。这可以实现零 API 成本审查，虽然效果可能略逊于顶级商业模型，但对于许多规则明确的检查已经足够。

7. 扩展与生态：不只是 GitHub Checks

Continue 的核心是 CLI 和“AI as Code”的理念，这使其应用场景不止于 GitHub PR 检查。

1. VS Code / JetBrains 插件：Continue 也提供了 IDE 插件。在 IDE 中，它可以基于你项目中的.continue/checks/规则，在你编写代码时提供实时、上下文相关的建议。这相当于将 CI 中的“事后检查”部分能力前置到了“事中编写”，形成了开发流程的闭环。你可以在编辑器中快速得到类似“你这里可能漏了错误处理”的提示。
2. 自定义工作流：cnCLI 可以集成到任何你能运行命令的地方。比如，你可以创建一个预提交钩子（pre-commit hook），在本地git commit前运行快速检查；或者集成到你的内部代码评审平台中。
3. 规则共享与社区：由于检查规则是简单的文本文件，团队之间、甚至开源社区之间可以很容易地分享和复用那些被验证有效的检查规则。你可以想象未来会出现一个“最佳实践 AI 检查规则库”。

在我个人的使用体验中，Continue 最大的价值在于它将 AI 能力工作流化、标准化了。它不再是一个黑盒魔法，而是一个你可以精确控制、持续改进的工程组件。初期投入时间去打磨检查规则是值得的，一旦这套体系运转起来，它能像一个不知疲倦的资深同事一样，帮你守住代码库质量的底线，让团队成员可以更专注于更有创造性的逻辑构建。