continue

当 AI 审查员走进代码评审：Continue 如何用 Markdown 定义代码质量

场景切入：一个深夜的 Pull Request

凌晨两点，某开发团队的代码仓库里，一个新的 Pull Request 被推送了上去。往常这个时候，至少需要等待人工 review——检查是否硬编码了 API Key、SQL 是否存在注入风险、新接口有没有做输入校验。但这一次，等待时间从几小时缩短到了几分钟。

GitHub 上出现了一个新的 Status Check：continue-security-review。几秒钟后，检查结果显示为红色，并附带了一条修复建议："Consider using environment variables instead of hardcoding the API key." 开发者点击"Apply suggestion"，问题直接被修复。

这就是 Continue 正在做的事情——用声明式的 Markdown 文件，将 AI 代码审查变成可复用、可审计、可在 CI 中自动执行的标准化流程。

项目背景：从 IDE 插件到 CI 安全网

Continue 最初以 VS Code 和 JetBrains 的 AI 代码助手插件 闻名，提供了 Chat、Edit、Agent、Autocomplete 四大功能，累计安装量超过 300 万次。其核心开发者团队 Continue Dev, Inc. 获得了 Andreessen Horowitz（a16z）等顶级 VC 的投资。

但 Continue 的野心不止于此。随着 AI Coding Agent（如 Cursor、GitHub Copilot Agent）大规模落地，一个核心矛盾浮现出来：AI 生成代码的质量谁来保证？ Continue 给出的答案是——把 AI 代码审查变成 GitHub Status Check，让它像单元测试一样成为 CI 流程中不可跳过的环节。

核心机制：checks 即代码

Continue 的检查规则以 Markdown + YAML frontmatter 格式定义，存放在仓库的 .continue/checks/ 目录中。每个文件本质上是一个 AI prompt，描述了审查的意图和标准：

---
name: Security Review
description: Review PR for basic security vulnerabilities
---
Review this PR and check that:
  - No secrets or API keys are hardcoded
  - All new API endpoints have input validation
  - Error responses use the standard error format

当 PR 打开时，Continue CLI (cn) 会读取所有 checks 文件，结合 PR 的 diff 内容，调用指定的 LLM 执行审查，并通过 GitHub Checks API 将结果报告回去。绿色通过、红色失败，并附带修复建议——与传统的单元测试行为完全一致。

类比解释：把"代码规范"变成"可执行的检查"

如果把传统的手动 Code Review 比喻为"靠人工巡逻保障安全"，那么 Continue 的 checks 机制就是"给代码仓库装上了智能摄像头和自动门禁"——你定义好规则（Markdown），系统自动执行并给出报告。

这套设计有几点很聪明的地方：

1. 检查即文档：Markdown 文件既是检查规则，也是团队的安全规范文档，新成员可以直接从 .continue/checks/ 理解项目的质量要求。
2. 可版本控制：checks 文件随代码一起 PR，无需额外配置管理工具，review 历史完整可查。
3. 可扩展：不限制 LLM 后端，可以是 Claude、GPT-4、DeepSeek 等任何兼容 API 的模型。

技术架构：TypeScript monorepo + 插件化设计

从代码结构来看，Continue 采用 TypeScript monorepo 架构，主要模块包括：

• core/：核心逻辑包（@continuedev/core），包含配置管理、上下文处理、代码索引、diff 分析等，供 VS Code/JetBrains/CLI 共享。
• gui/：基于 Vite + TypeScript 的前端界面，使用 Tailwind CSS 构建响应式 UI。
• extensions/vscode/ 和 extensions/intellij/：对应 IDE 的插件代码。
• extensions/cli/：命令行工具 cn，负责 CI 环境中的 checks 执行。
• binary/：二进制打包配置，使用 pkg 工具将 Node.js 应用打包为可执行文件。

关键依赖包括：

• esbuild：高速 TypeScript 编译
• vectordb (LanceDB)：本地向量数据库，用于代码索引和语义搜索
• tree-sitter：代码解析和语法分析
• ONNX Runtime：部分模型推理的本地化支持

上手门槛：CLI 环境 vs IDE 插件

CLI 提供了最通用的使用方式——无论是 GitHub Actions 还是自建 CI，都可以通过一行脚本完成安装和执行。

争议与局限

1. LLM 调用成本：每次 PR review 都需要调用 LLM API，大型项目的 check 文件多了之后，成本不可忽视。
2. 误报问题：AI 审查存在一定误报率，复杂的业务逻辑判断仍需要人工介入，不宜完全依赖。
3. IDE 插件 vs CLI 定位混淆：项目同时维护 IDE 插件和 CLI 工具，两者的功能边界和优先级对外不够清晰。
4. 非 Web UI：无法通过浏览器直接使用，限制了纯 Web 场景的接入。

行业意义：AI 审查的新范式

Continue 的最大贡献在于，它将 AI 代码审查从"一次性的 Chat 对话"变成了"可复现的质量门禁"。在 AI 生成代码占比越来越高的当下，这种"checks 即代码"的思路代表了一个重要趋势：AI 工具不仅要能写代码，也要能审查代码，而审查结果必须像测试一样可验证、可追溯。

该项目目前已有 33,000+ stars，4,500+ forks，805 个 open issues，说明社区活跃度很高。作为 Apache 2.0 开源项目，它为企业在 CI 中引入 AI 审查提供了一个低成本、可控的落地方案。