企业官网建设流程全解析

Continue 通用 PR 审查 Action（general-review）接入与实现深度解析

【免费下载链接】continueopen-source coding agent项目地址: https://gitcode.com/GitHub_Trending/co/continue

本文面向希望在 GitHub 仓库中部署 AI 驱动的自动化 Pull Request 审查流程的开发者与 DevEx 工程师。文章以仓库 actions/README.md 为骨架，完整继承其全部接入要素（工作流示例、Action 输入、权限配置、触发方式、输出内容、版本管理与排障），并逐一对应 action.yml 及其脚本 buildPrompt.js、writeMarkdown.js 的源码细节，帮助读者既能在 10 分钟内跑通，也能理解审查机器人每一步在底层到底做了什么。

仓库中的 Actions 总览

Continue 是一个开源 coding agent 项目，本仓库在其actions/目录下提供面向 GitHub Actions 生态的自动化能力。目前该目录内包含一份官方开箱即用的审查类 Action：

• General Review Action（通用 PR 审查）：在 actions/general-review 下实现，通过action.yml声明输入，通过两个 Node.js 脚本完成“构建审查提示词”与“写入兜底错误报告”，最终以 PR 评论形式给出宏观层面的代码审查结论。

它的核心定位是"高层级 PR 评估"——关注功能正确性、安全隐患、破坏性变更、真实性能影响与测试/文档缺失，而不是替代 linter 去做风格审查（这一分工在 buildPrompt.js 的提示词设计中有明确体现，下文会展开）。

Quick Start：10 分钟接入一个 PR 审查机器人

原文档给出了一个可直接复制的最小工作流。将下面的 YAML 保存到仓库的.github/workflows/下（例如code-review.yml）即可启用：

name: PR General Review on: pull_request: types: [opened, ready_for_review] issue_comment: types: [created] permissions: contents: read pull-requests: write issues: write jobs: review: runs-on: ubuntu-latest timeout-minutes: 10 steps: - uses: continuedev/continue/actions/general-review@main with: continue-api-key: ${{ secrets.CONTINUE_API_KEY }} continue-org: "your-org-name" continue-config: "your-org-name/review-bot"

结合 action.yml 源码，可以对这份工作流做如下关键注解：

• 事件（on）设计：pull_request事件只监听opened（PR 刚打开）与ready_for_review（草稿转正式评审）两种类型；issue_comment事件监听created，用于支持在评论中通过@continue-review手动触发。注意synchronize（提交更新）并没有列入自动触发条件，因此已有 PR 的后续提交不会无限触发重复评审。
• 权限（permissions）最小化：contents: read供 checkout 读取代码；pull-requests: write供机器人写入 PR 审查评论；issues: write供机器人响应评论触发。这些与源码中"Post Initial Comment / Update Comment with Review"两个github-script步骤所需的 REST 能力一一对应。
• uses复合 Action 自包含：该 Action 类型为composite（见 action.yml），内部自带actions/checkout@v4、actions/setup-node@v4（Node.js 20）、actions/github-script@v7、actions/upload-artifact@v4等步骤，因此使用者无需在 job 里重复准备 Node 环境与脚本——唯一需要自带的是 API Key 与组织配置。
• timeout-minutes: 10与内部超时互为兜底：job 层设 10 分钟整体上限，而源码在真正执行模型调用时还额外用timeout 360（6 分钟）包裹了cn命令（action.yml），双层防挂起。

Action 输入（Inputs）逐项说明

原文档的输入表是接入时的必填项清单，三者的实际声明位于 action.yml：

需要特别指出一个值得注意的细节：仓库根目录的 actions/README.md 示例中第三个输入写作continue-config，而 action.yml 中该输入的真实名称是continue-agent（description 为Agent path to use (e.g., "myorg/review-bot")）。实际行为以 action.yml 声明的输入名为准——配置agent/config路径时建议优先使用与当前所引用版本一致的输入键。由于版本之间 Action 定义可能调整，接入前最好核对目标分支上的 action.yml。

从字段语义上看，后两个输入本质上描述的是"要加载哪份评审 Agent/Assistant 配置"。这对应 Continue CLI 的--agent机制：在 extensions/cli/src/commands/BaseCommandOptions.ts 中可以找到该参数的类型定义（"Agent file slug from the hub (--agent)"），而 quickstart.mdx 中亦把cn --agent my-org/my-agent作为按 slug 加载 Agent 文件的入口。

Setup Requirements：三项前置配置

1. 配置 Continue API Key

审查全程由模型驱动，需要仓库内保存一个 Continue 平台签发的 Key：

1. 进入仓库Settings；
2. 选择Secrets and variables → Actions；
3. 点击New repository secret；
4. Name 填写CONTINUE_API_KEY；
5. Value 填入你的 Continue API Key。

对应到源码，action.yml 会把inputs.continue-api-key注入步骤环境变量CONTINUE_API_KEY，并在第 280-287 行显式检查该变量是否为空。若缺失，流程不会硬失败，而是调用writeMarkdown.js code_review.md missing_api_key写入一条 Markdown 兜底说明，再以SKIP_CLI=true跳过模型阶段——也就是说"Key 忘配"也会得到一条可读的 PR 评论提示，而不是在 workflow 里留下莫名报错。

2. 配置 Continue 组织与评审 Agent

在你的 Continue 组织下准备一份用于代码评审的 Agent/Assistant 配置（README 中建议形如your-org-name/review-bot），随后记录组织名与 Agent 路径。仓库对这类"评审机器人配置"的生态支撑可见 docs/guides/github-pr-review-bot.mdx，该指南展示了如何为评审机器人配置自定义规则（团队标准、安全清单、测试要求等）。

3. 声明工作流权限

工作流顶部必须按需声明以下权限：

• contents: read—— checkout 并读取仓库代码；
• pull-requests: write—— 在 PR 上发布/更新审查评论；
• issues: write—— 响应评论触发的（PR 审查场景中 GitHub 将 PR 评论视为 issue comment）。

权限声明位于 action.yml 中的 workflow 示例之上，与 README 的要求完全一致。

触发方式：自动触发与手动触发

该 Action 存在两条触发路径，两者最终都会经过同一套鉴权闸门。

自动触发

• 团队成员（OWNER、MEMBER、COLLABORATOR）新开一个 PR；
• 团队成员将 PR从 Draft 标记为 Ready for review。

手动触发

任何团队成员都可以在任何 PR 下评论：

@continue-review

评论被识别后即触发一次审查，适合"PR 打开时跳过、现在补审"或针对新提交重审的场景。

底层的鉴权闸门（源码级）

从 action.yml 的Check Authorization步骤可以看到，自动与手动触发都不仅仅是“事件到了就跑”，而是先通过github-script执行一段鉴权逻辑，并用SHOULD_RUN环境变量控制后续所有步骤是否执行（后续每个步骤都带if: env.SHOULD_RUN == 'true'条件）。其判定规则可以概括为：

• pull_request事件：若pull_request.draft为 true 直接跳过（草稿不审）；否则先调用repos.getCollaboratorPermissionLevel检查 PR 作者的协作权限，允许的权限集合为admin、maintain、write；若该 API 调用失败（例如 token 权限不足），则回退到pull_request.author_association字段，允许OWNER、MEMBER、COLLABORATOR。
• issue_comment事件：仅当评论内容包含@continue-review且该 issue 确实挂在一个 PR 上（context.payload.issue.pull_request存在）才继续；对评论者执行与上面相同的双重权限判定（API 优先、association 兜底）。
• 其他事件类型：一律跳过并给出Unsupported event type提示。

这一设计意味着越权用户无法通过@机器人来消耗组织的模型配额，同时也解释了原文档 Troubleshooting 中"Review not triggering"部分为什么会反复强调权限检查。

一次完整的审查是如何发生的

原文档给出了五步流水线概述，而 action.yml 将全过程拆成了十个相互衔接的 step。逐一对齐如下：

1. Checkout Repository：使用actions/checkout@v4拉取仓库代码（action.yml）。
2. Check Authorization：按上文鉴权逻辑计算SHOULD_RUN。
3. Setup Node.js：安装 Node.js 20。
4. Install Continue CLI：执行npm install -g @continuedev/cli@latest（action.yml），确保 runner 上有最新的cn命令。
5. Setup Action Scripts：把buildPrompt.js与writeMarkdown.js就位。这里有一个很聪明的兼容处理（action.yml）：如果 checkout 的是 Continue 仓库本身（本地存在actions/general-review/scripts/两个文件）就直接拷贝本地脚本；如果是外部仓库，则通过 curl 从 Continue 仓库 main 分支下载同名脚本，随后校验两个文件都存在。
6. Post Initial Comment：先发一条“🔄 Review In Progress”占位评论（action.yml）。该步骤会通过 marker<!-- continue-agent-review -->检索 PR 上既有的 Continue 评论：若存在且创建不足 1 小时则更新这条旧评论，否则新建——其意图是尽量保持单一“吸顶评论”的同时，又避免无限覆盖历史审查记录。
7. Build PR Review Prompt：用gh pr diff拉取 diff 到pr_diff.txt，用gh pr view --json title,author,body,files拉取 PR 元数据到pr_data.json，然后调用node buildPrompt.js "$PR_NUMBER"生成review_prompt.txt（action.yml）。
8. Run Continue CLI Review：校验输入合法性后，把提示词写入临时文件，执行cn --agent "$CONTINUE_ORG/$CONTINUE_AGENT" -p "@$PROMPT_FILE" --allow Bash（带 360 秒 timeout），输出经sed清理 ANSI 颜色码后存为code_review.md。任何失败（CLI 未装、配置错、鉴权失败、空输出等）都会由writeMarkdown.js生成对应兜底 Markdown（action.yml）。
9. Upload Review Results：把code_review.md、review_prompt.txt、pr_diff.txt作为 artifact 上传（保留 30 天），供事后审计（action.yml）。
10. Update Comment with Review：把最终审查结果更新进第 6 步创建的评论，形成✅ Review Complete吸顶评论；若更新失败则按“按 marker 搜索旧评论→更新/新建”的顺序兜底（action.yml）。

值得一提的安全细节在第 8 步：continue-org与continue-agent在拼进 shell 命令前分别用白名单正则做了校验（action.yml），并且提示词通过@文件路径的方式传给cn而不是直接内联到命令行，规避了提示词内容被 shell 二次解释的风险。

审查输出：结构化评论与异常兜底

正常输出的结构

General Review 的产出是一段结构化 PR 评论，README 明确其包含四类信息：

• Strengths（亮点）：这个 PR 做得好的地方；
• Issues Found（发现的问题）：按严重程度分级（Critical / High / Medium / Low）；
• Suggestions（改进建议）：可执行的优化建议；
• Overall Assessment（总体结论）：最终建议，取值为APPROVE、REQUEST_CHANGES或COMMENT之一。

这套结构的“原料”由 buildPrompt.js 拼装。细读其提示词（buildPrompt.js）可以发现审查被刻意约束在“高信号”范围：

• 要求聚焦：会导致故障/错误行为的 Bug、安全漏洞（泄露密钥、注入风险）、破坏其他模块的 Breaking Change、有真实影响的性能问题（内存泄漏、O(n²) 算法）、新功能缺测试、API/复杂逻辑缺文档；
• 明确禁止刷屏：不评论风格与格式化（交给 linter）、不评价“另一种写法更好”（除非现方案确实坏了）、不纠结次要命名、不给自解释代码配无关文档；
• 要求可落地：反馈必须带上具体行号并解释“为什么这是问题”；
• 上下文输入：提示词中会注入仓库名、PR 号与标题、变更文件数、作者、PR 描述，以及完整 diff，最后要求给出建设性反馈。

异常兜底输出

当任何环节失败时，writeMarkdown.js 会根据失败类型写入对应摘要文案（writeMarkdown.js），方便读者对照排查：

这些兜底说明最终同样会以 PR 评论的形式出现，因此运维人员即使不看 workflow 日志，也能在 PR 页面上直接读懂“为什么这次没有 AI 审查”。

版本策略（Versioning）

原文档建议直接锁定main分支作为版本来源：

uses: continuedev/continue/actions/general-review@main

即@main始终使用 main 分支上的最新实现。这种方式适合希望第一时间获得审查逻辑改进的团队；由于compositeAction 会随引用版本整体拉取（包括内部的脚本下载逻辑与提示词工程），若追求稳定复现，也可以按需固定到具体的 commit SHA 或 tag，避免上游变更导致审查行为漂移。

Troubleshooting 排障指南

问题一：审查没有触发

原文档给出的三条排查方向在源码中都能得到印证：

• 权限不足：回顾上文鉴权闸门——PR 作者/评论者必须是admin、maintain、write之一，或在 association 回退判定中属于OWNER/MEMBER/COLLABORATOR（action.yml）。外部协作者（FIRST_TIME_CONTRIBUTOR、CONTRIBUTOR）默认不会自动触发。
• Workflow 文件位置：workflow 必须存在于仓库默认分支才会在 PR 事件中被正确解析执行。
• Secret 配置错误：CONTINUE_API_KEY需作为 repository secret 存在；若为空，Check Authorization虽然放行，但Run Continue CLI Review阶段会写入missing_api_key兜底报告。
• 补充排查：草稿 PR（draft: true）与ready_for_review之外的状态变化不会触发自动审查，可改用评论@continue-review手动触发。

问题二：没有生成审查输出

原文档建议按如下顺序排查：

• 查看 Action 日志：日志中会打印cn --version、CLI 执行命令、原始输出长度、报错日志cli_error.log内容等中间状态（action.yml），并会依据错误关键字归类；此外第 9 步上传的 artifact（含review_prompt.txt与pr_diff.txt）可离线核对“提示词与 diff 是否正常生成”。
• 核对 Continue 配置：continue-org/Agent 路径须真实存在于 Continue 平台，配置错误会命中config_error兜底。
• 确认 API Key 有效：Key 过期或失效会命中auth_error，评论会直接给出提示。

如果输出为空但流程"成功"，请检查第 8 步对空输出的处理（action.yml）——它会把空结果替换为empty_output兜底文案，因此"无任何评论"本身就是一个需要进一步查日志的信号。

延伸参考

• 该 Action 在仓库中的完整定义：actions/general-review/action.yml
• 提示词构建脚本：actions/general-review/scripts/buildPrompt.js
• 兜底错误报告脚本：actions/general-review/scripts/writeMarkdown.js
• 面向“从零自建 PR 审查机器人”的完整教程（含自定义规则、按文件类型过滤、PR 规模上限等进阶做法）：docs/guides/github-pr-review-bot.mdx
• 该 Action 依赖的 Continue CLI 运行形态（headless 模式cn -p、--agent加载 Agent）：docs/cli/headless-mode.mdx、docs/cli/quickstart.mdx

接入完成后，你可以先开一个测试 PR 观察审查评论出现，再逐步把组织自身的编码规则沉淀进 Continue 的 review-bot 配置中，让自动化审查从"通用规范"进化为"团队专属规范"。

【免费下载链接】continueopen-source coding agent项目地址: https://gitcode.com/GitHub_Trending/co/continue