Continue 通用 PR 审查 Actiongeneral-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 生态的自动化能力。目前该目录内包含一份官方开箱即用的审查类 ActionGeneral Review Action通用 PR 审查在 actions/general-review 下实现通过action.yml声明输入通过两个 Node.js 脚本完成“构建审查提示词”与“写入兜底错误报告”最终以 PR 评论形式给出宏观层面的代码审查结论。它的核心定位是高层级 PR 评估——关注功能正确性、安全隐患、破坏性变更、真实性能影响与测试/文档缺失而不是替代 linter 去做风格审查这一分工在 buildPrompt.js 的提示词设计中有明确体现下文会展开。Quick Start10 分钟接入一个 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-reviewmain 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事件只监听openedPR 刚打开与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/checkoutv4、actions/setup-nodev4Node.js 20、actions/github-scriptv7、actions/upload-artifactv4等步骤因此使用者无需在 job 里重复准备 Node 环境与脚本——唯一需要自带的是 API Key 与组织配置。timeout-minutes: 10与内部超时互为兜底job 层设 10 分钟整体上限而源码在真正执行模型调用时还额外用timeout 3606 分钟包裹了cn命令action.yml双层防挂起。Action 输入Inputs逐项说明原文档的输入表是接入时的必填项清单三者的实际声明位于 action.yml输入说明是否必填源码中的约束与校验continue-api-keyContinue 服务的 API Key是作为CONTINUE_API_KEY环境变量传入若为空会跳过模型调用并输出missing_api_key兜底报告continue-orgContinue 组织名对应 org 级配置是运行时用正则^[a-zA-Z0-9_-]$校验防止命令注入continue-agent/continue-config评审 Agent/配置路径如myorg/review-bot是运行时用正则^[a-zA-Z0-9_/-]$校验以CONTINUE_ORG/CONTINUE_AGENT形式拼给cn --agent需要特别指出一个值得注意的细节仓库根目录的 actions/README.md 示例中第三个输入写作continue-config而 action.yml 中该输入的真实名称是continue-agentdescription 为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进入仓库Settings选择Secrets and variables → Actions点击New repository secretName 填写CONTINUE_API_KEYValue 填入你的 Continue API Key。对应到源码action.yml 会把inputs.continue-api-key注入步骤环境变量CONTINUE_API_KEY并在第 280-287 行显式检查该变量是否为空。若缺失流程不会硬失败而是调用writeMarkdown.js code_review.md missing_api_key写入一条 Markdown 兜底说明再以SKIP_CLItrue跳过模型阶段——也就是说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。逐一对齐如下Checkout Repository使用actions/checkoutv4拉取仓库代码action.yml。Check Authorization按上文鉴权逻辑计算SHOULD_RUN。Setup Node.js安装 Node.js 20。Install Continue CLI执行npm install -g continuedev/clilatestaction.yml确保 runner 上有最新的cn命令。Setup Action Scripts把buildPrompt.js与writeMarkdown.js就位。这里有一个很聪明的兼容处理action.yml如果 checkout 的是 Continue 仓库本身本地存在actions/general-review/scripts/两个文件就直接拷贝本地脚本如果是外部仓库则通过 curl 从 Continue 仓库 main 分支下载同名脚本随后校验两个文件都存在。Post Initial Comment先发一条“ Review In Progress”占位评论action.yml。该步骤会通过 marker!-- continue-agent-review --检索 PR 上既有的 Continue 评论若存在且创建不足 1 小时则更新这条旧评论否则新建——其意图是尽量保持单一“吸顶评论”的同时又避免无限覆盖历史审查记录。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.txtaction.yml。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生成对应兜底 Markdownaction.yml。Upload Review Results把code_review.md、review_prompt.txt、pr_diff.txt作为 artifact 上传保留 30 天供事后审计action.yml。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 / LowSuggestions改进建议可执行的优化建议Overall Assessment总体结论最终建议取值为APPROVE、REQUEST_CHANGES或COMMENT之一。这套结构的“原料”由 buildPrompt.js 拼装。细读其提示词buildPrompt.js可以发现审查被刻意约束在“高信号”范围要求聚焦会导致故障/错误行为的 Bug、安全漏洞泄露密钥、注入风险、破坏其他模块的 Breaking Change、有真实影响的性能问题内存泄漏、O(n²) 算法、新功能缺测试、API/复杂逻辑缺文档明确禁止刷屏不评论风格与格式化交给 linter、不评价“另一种写法更好”除非现方案确实坏了、不纠结次要命名、不给自解释代码配无关文档要求可落地反馈必须带上具体行号并解释“为什么这是问题”上下文输入提示词中会注入仓库名、PR 号与标题、变更文件数、作者、PR 描述以及完整 diff最后要求给出建设性反馈。异常兜底输出当任何环节失败时writeMarkdown.js 会根据失败类型写入对应摘要文案writeMarkdown.js方便读者对照排查场景触发条件message key提示内容CONTINUE_API_KEY未配置missing_api_key提示设置 secret、核对 org/configcn命令不存在CLI 未装上cli_install_failed/cli_not_found提示检查 npm 安装与continuedev/cli可用性模型返回空输出empty_output提示检查配置错误日志含config/assistantconfig_error提示核对 Assistant 是否存在于 Continue Hub错误日志含api/authauth_error提示检查 API Key其他通用失败generic_failure综合提示 Key、org/config、服务连通性这些兜底说明最终同样会以 PR 评论的形式出现因此运维人员即使不看 workflow 日志也能在 PR 页面上直接读懂“为什么这次没有 AI 审查”。版本策略Versioning原文档建议直接锁定main分支作为版本来源uses: continuedev/continue/actions/general-reviewmain即main始终使用 main 分支上的最新实现。这种方式适合希望第一时间获得审查逻辑改进的团队由于compositeAction 会随引用版本整体拉取包括内部的脚本下载逻辑与提示词工程若追求稳定复现也可以按需固定到具体的 commit SHA 或 tag避免上游变更导致审查行为漂移。Troubleshooting 排障指南问题一审查没有触发原文档给出的三条排查方向在源码中都能得到印证权限不足回顾上文鉴权闸门——PR 作者/评论者必须是admin、maintain、write之一或在 association 回退判定中属于OWNER/MEMBER/COLLABORATORaction.yml。外部协作者FIRST_TIME_CONTRIBUTOR、CONTRIBUTOR默认不会自动触发。Workflow 文件位置workflow 必须存在于仓库默认分支才会在 PR 事件中被正确解析执行。Secret 配置错误CONTINUE_API_KEY需作为 repository secret 存在若为空Check Authorization虽然放行但Run Continue CLI Review阶段会写入missing_api_key兜底报告。补充排查草稿 PRdraft: 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加载 Agentdocs/cli/headless-mode.mdx、docs/cli/quickstart.mdx接入完成后你可以先开一个测试 PR 观察审查评论出现再逐步把组织自身的编码规则沉淀进 Continue 的 review-bot 配置中让自动化审查从通用规范进化为团队专属规范。【免费下载链接】continueopen-source coding agent项目地址: https://gitcode.com/GitHub_Trending/co/continue创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Continue 通用 PR 审查 Action（general-review）接入与实现深度解析
Continue 通用 PR 审查 Actiongeneral-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 生态的自动化能力。目前该目录内包含一份官方开箱即用的审查类 ActionGeneral Review Action通用 PR 审查在 actions/general-review 下实现通过action.yml声明输入通过两个 Node.js 脚本完成“构建审查提示词”与“写入兜底错误报告”最终以 PR 评论形式给出宏观层面的代码审查结论。它的核心定位是高层级 PR 评估——关注功能正确性、安全隐患、破坏性变更、真实性能影响与测试/文档缺失而不是替代 linter 去做风格审查这一分工在 buildPrompt.js 的提示词设计中有明确体现下文会展开。Quick Start10 分钟接入一个 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-reviewmain 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事件只监听openedPR 刚打开与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/checkoutv4、actions/setup-nodev4Node.js 20、actions/github-scriptv7、actions/upload-artifactv4等步骤因此使用者无需在 job 里重复准备 Node 环境与脚本——唯一需要自带的是 API Key 与组织配置。timeout-minutes: 10与内部超时互为兜底job 层设 10 分钟整体上限而源码在真正执行模型调用时还额外用timeout 3606 分钟包裹了cn命令action.yml双层防挂起。Action 输入Inputs逐项说明原文档的输入表是接入时的必填项清单三者的实际声明位于 action.yml输入说明是否必填源码中的约束与校验continue-api-keyContinue 服务的 API Key是作为CONTINUE_API_KEY环境变量传入若为空会跳过模型调用并输出missing_api_key兜底报告continue-orgContinue 组织名对应 org 级配置是运行时用正则^[a-zA-Z0-9_-]$校验防止命令注入continue-agent/continue-config评审 Agent/配置路径如myorg/review-bot是运行时用正则^[a-zA-Z0-9_/-]$校验以CONTINUE_ORG/CONTINUE_AGENT形式拼给cn --agent需要特别指出一个值得注意的细节仓库根目录的 actions/README.md 示例中第三个输入写作continue-config而 action.yml 中该输入的真实名称是continue-agentdescription 为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进入仓库Settings选择Secrets and variables → Actions点击New repository secretName 填写CONTINUE_API_KEYValue 填入你的 Continue API Key。对应到源码action.yml 会把inputs.continue-api-key注入步骤环境变量CONTINUE_API_KEY并在第 280-287 行显式检查该变量是否为空。若缺失流程不会硬失败而是调用writeMarkdown.js code_review.md missing_api_key写入一条 Markdown 兜底说明再以SKIP_CLItrue跳过模型阶段——也就是说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。逐一对齐如下Checkout Repository使用actions/checkoutv4拉取仓库代码action.yml。Check Authorization按上文鉴权逻辑计算SHOULD_RUN。Setup Node.js安装 Node.js 20。Install Continue CLI执行npm install -g continuedev/clilatestaction.yml确保 runner 上有最新的cn命令。Setup Action Scripts把buildPrompt.js与writeMarkdown.js就位。这里有一个很聪明的兼容处理action.yml如果 checkout 的是 Continue 仓库本身本地存在actions/general-review/scripts/两个文件就直接拷贝本地脚本如果是外部仓库则通过 curl 从 Continue 仓库 main 分支下载同名脚本随后校验两个文件都存在。Post Initial Comment先发一条“ Review In Progress”占位评论action.yml。该步骤会通过 marker!-- continue-agent-review --检索 PR 上既有的 Continue 评论若存在且创建不足 1 小时则更新这条旧评论否则新建——其意图是尽量保持单一“吸顶评论”的同时又避免无限覆盖历史审查记录。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.txtaction.yml。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生成对应兜底 Markdownaction.yml。Upload Review Results把code_review.md、review_prompt.txt、pr_diff.txt作为 artifact 上传保留 30 天供事后审计action.yml。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 / LowSuggestions改进建议可执行的优化建议Overall Assessment总体结论最终建议取值为APPROVE、REQUEST_CHANGES或COMMENT之一。这套结构的“原料”由 buildPrompt.js 拼装。细读其提示词buildPrompt.js可以发现审查被刻意约束在“高信号”范围要求聚焦会导致故障/错误行为的 Bug、安全漏洞泄露密钥、注入风险、破坏其他模块的 Breaking Change、有真实影响的性能问题内存泄漏、O(n²) 算法、新功能缺测试、API/复杂逻辑缺文档明确禁止刷屏不评论风格与格式化交给 linter、不评价“另一种写法更好”除非现方案确实坏了、不纠结次要命名、不给自解释代码配无关文档要求可落地反馈必须带上具体行号并解释“为什么这是问题”上下文输入提示词中会注入仓库名、PR 号与标题、变更文件数、作者、PR 描述以及完整 diff最后要求给出建设性反馈。异常兜底输出当任何环节失败时writeMarkdown.js 会根据失败类型写入对应摘要文案writeMarkdown.js方便读者对照排查场景触发条件message key提示内容CONTINUE_API_KEY未配置missing_api_key提示设置 secret、核对 org/configcn命令不存在CLI 未装上cli_install_failed/cli_not_found提示检查 npm 安装与continuedev/cli可用性模型返回空输出empty_output提示检查配置错误日志含config/assistantconfig_error提示核对 Assistant 是否存在于 Continue Hub错误日志含api/authauth_error提示检查 API Key其他通用失败generic_failure综合提示 Key、org/config、服务连通性这些兜底说明最终同样会以 PR 评论的形式出现因此运维人员即使不看 workflow 日志也能在 PR 页面上直接读懂“为什么这次没有 AI 审查”。版本策略Versioning原文档建议直接锁定main分支作为版本来源uses: continuedev/continue/actions/general-reviewmain即main始终使用 main 分支上的最新实现。这种方式适合希望第一时间获得审查逻辑改进的团队由于compositeAction 会随引用版本整体拉取包括内部的脚本下载逻辑与提示词工程若追求稳定复现也可以按需固定到具体的 commit SHA 或 tag避免上游变更导致审查行为漂移。Troubleshooting 排障指南问题一审查没有触发原文档给出的三条排查方向在源码中都能得到印证权限不足回顾上文鉴权闸门——PR 作者/评论者必须是admin、maintain、write之一或在 association 回退判定中属于OWNER/MEMBER/COLLABORATORaction.yml。外部协作者FIRST_TIME_CONTRIBUTOR、CONTRIBUTOR默认不会自动触发。Workflow 文件位置workflow 必须存在于仓库默认分支才会在 PR 事件中被正确解析执行。Secret 配置错误CONTINUE_API_KEY需作为 repository secret 存在若为空Check Authorization虽然放行但Run Continue CLI Review阶段会写入missing_api_key兜底报告。补充排查草稿 PRdraft: 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加载 Agentdocs/cli/headless-mode.mdx、docs/cli/quickstart.mdx接入完成后你可以先开一个测试 PR 观察审查评论出现再逐步把组织自身的编码规则沉淀进 Continue 的 review-bot 配置中让自动化审查从通用规范进化为团队专属规范。【免费下载链接】continueopen-source coding agent项目地址: https://gitcode.com/GitHub_Trending/co/continue创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考