Cline PR 审查工作流规则实战：基于 gh CLI 的 Pull Request 评审全流程指南

本篇指南围绕 Cline 仓库内 .clinerules/workflows/pr-review.md 这一工作流规则展开，完整拆解 Cline Agent 从拉取 PR 信息、理解代码上下文、逐文件分析变更，到向用户确认评审意见、最终通过 gh pr review 提交 Approve / Request Changes 的完整闭环，并附上仓库源码级的佐证与可直接复制的命令、注释模板。

什么是 PR Review 工作流规则

在 Cline 项目中，.clinerules/ 目录存放"工作区规则"，它们作为持久化指令在每个会话中随上下文一起加载，帮助 Cline 理解项目语境、编码规范与特定工作流的执行方式（相关机制详见 docs/customization/cline-rules.mdx）。与承载通用技术背景的 .clinerules/general.md、.clinerules/cline-overview.md 不同，workflows/ 子目录下放的是按场景划分的可执行流程，例如：

• pr-review.md：审查指定 Pull Request（本文主题）；
• address-pr-comments.md：处理当前分支 PR 上收到的所有评审意见；
• 同目录下还有 find-pr-reviewers、git-branch-analysis、hotfix-release、release 等兄弟工作流，形成"提 PR → 找评审 → 审 PR → 回应评论"的完整协作链条。

pr-review.md 规则的开篇即点明了它的运行前提："You have access to the gh terminal command. I already authenticated it for you. Please review the PR that I asked you to review. You're already in the cline repo."（你已拥有经过认证的 gh 命令，且已位于 cline 仓库内）。也就是说，这条规则描述的是当用户要求 Cline 审查某个 PR 时，Agent 应当按顺序执行的一套标准动作——Cline 通过 CLI 工具执行 gh 命令获取 PR 元数据与 diff，通过文件读取/检索工具还原修改上下文，最后借助确认型交互工具让用户拍板，再由 gh pr review 落定评审结论。

六步标准审查流程

规则将整个 PR 评审过程编排为六个明确阶段，每一步都有具体的 CLI 命令与交互约定。下面按原文骨架逐段展开。

第一步：收集 PR 信息

向 gh 请求 PR 的标题、描述与评论，以及完整的差异内容：

# 获取 PR 标题、描述和评论
gh pr view <PR-number> --json title,body,comments

# 获取完整 diff
gh pr diff <PR-number>

--json 让 gh 输出机器可读的 JSON，便于 Cline 精确提取字段；gh pr diff 则返回该 PR 相对其目标分支的全部变更（additions/deletions/changedFiles 等信息），这是后续所有分析的原料。规则后续给出的"常用命令清单"中还补充了更多查询姿势：

# 获取当前分支对应的 PR 编号（用于"我当前就在这条分支上"的场景）
gh pr view --json number -q .number

# 一次性查看多个字段
gh pr view <PR-number> --json title,body,comments,files,commits

# 查看 PR 状态（打开/合并/关闭、CI 等）
gh pr status

# 查看 PR 的 checks / commits
gh pr checks <PR-number>
gh pr view <PR-number> --json commits

第二步：理解变更上下文

拿到 diff 后，先定位"动了哪些文件"，再回到基线分支阅读原文件，理解改动所处的真实上下文：

# 查看 PR 修改了哪些文件
gh pr view <PR-number> --json files

对于被修改文件的关键段落，用文件工具精读原实现（规则中以 XML 形式给出工具调用样例）：

<read_file>
<path>path/to/file</path>
</read_file>

对较大目录，则用正则检索缩小范围（规则样例限定只搜 *.ts）：

<search_files>
<path>path/to/directory</path>
<regex>search term</regex>
<file_pattern>*.ts</file_pattern>
</search_files>

这一阶段的目的是让 Cline 不只看到"diff 里写了什么"，还看到"它改动的代码原本是什么样、被谁调用、处于什么模块"。这也与仓库内 .clinerules/general.md 中"搜索时避开 out/、dist/、node_modules/ 等构建产物目录"的检索纪律相呼应——例如对大型 monorepo 目录应配合 *.ts 等 file_pattern 过滤，避免命中压缩产物造成噪声。

第三步：分析变更质量

规则要求对每个被修改文件追问四件事：

1. 改了什么（What was changed）；
2. 为什么改（Why，依据 PR 描述判断）；
3. 对代码库的影响（How it affects the codebase）；
4. 潜在副作用（Potential side effects）。

同时，审查者应系统性排查以下五类问题：

• 代码质量问题（Code quality issues）：命名、结构、可维护性、是否符合既有模式；
• 潜在缺陷（Potential bugs）：边界条件、时序问题、未处理的异常路径；
• 性能影响（Performance implications）：循环、请求量、UI 响应；
• 安全隐患（Security concerns）：权限、输入校验、密钥泄漏；
• 测试覆盖（Test coverage）：关键逻辑是否有单元/集成测试背书。

仓库的配套文档 docs/cli/samples/github-pr-review.mdx 给出了自动化场景下同等的"深度评审清单"（逻辑错误与边界情况、安全漏洞、性能问题、与代码库既有模式的符合性），说明这套检查维度既适用于交互式人工审查，也适用于 CI 中完全无人值守的审查。

第四步：先征求用户确认，再做评审决定

审查不是"直接下结论"，而是先把评估结果摆给用户，由用户决定 approve 还是 request changes：

<ask_followup_question>
<question>Based on my review of PR #<PR-number>, I recommend [approving/requesting changes]. Here's my justification:

[Detailed justification with key points about the PR quality, implementation, and any concerns]

Would you like me to proceed with this recommendation?</question>
<options>["Yes, approve the PR", "Yes, request changes", "No, I'd like to discuss further"]</options>
</ask_followup_question>

ask_followup_question 并非虚构的工具，它在 Cline 源码中真实存在并被多处引用，例如 apps/cli/src/runtime/tool-policies.ts（工具策略定义）及其测试 apps/cli/src/runtime/tool-policies.test.ts，CLI 的 TUI 层也有对应的审批弹窗实现（如 apps/cli/src/tui/components/dialogs/tool-approval.tsx）。它允许 Agent 以受限选项的形式向用户提问并等待结构化回答，从而把"最终裁决权"保留在用户手中。

第五步：询问是否需要起草评论

用户拍板之后，规则还要求再问一次是否需要 Cline 代笔一条可复制粘贴的评论：

<ask_followup_question>
<question>Would you like me to draft a comment for this PR that you can copy and paste?</question>
<options>["Yes, please draft a comment", "No, I'll handle the comment myself"]</options>
</ask_followup_question>

若需要，则产出一段结构化文本：先感谢作者，再给出评审要点（代码质量、功能实现、测试情况），最后附上具体建议。

第六步：用 gh pr review 落定结论

审批通过（Approve）或请求修改（Request changes）都用 gh pr review 完成，规则同时给出单行与多行两种写法：

# 单行审批
gh pr review <PR-number> --approve --body "Your approval message"

# 多行审批（保留全部空白与换行格式，无需临时文件）
cat << EOF | gh pr review <PR-number> --approve --body-file -
Thanks @username for this PR! The implementation looks good.

I particularly like how you've handled X and Y.

Great work!
EOF

请求修改的写法结构一致，只是把 --approve 换成 --request-changes：

# 单行
gh pr review <PR-number> --request-changes --body "Your feedback message"

# 多行（示例包含编号问题清单与总结）
cat << EOF | gh pr review <PR-number> --request-changes --body-file -
Thanks @username for this PR!

The implementation looks promising, but there are a few things to address:

1. Issue one
2. Issue two

Please make these changes and we can merge this.
EOF

规则特别解释了 cat << EOF | ... --body-file - 的技巧：--body-file - 中的 - 表示从标准输入读取正文，cat 的 heredoc 能原样保留换行、缩进与空行——比用 --body 传引号包裹的多行字符串更不容易被 shell 转义破坏，也避免了创建临时文件。

一条真实示例：审查 PR #3627 的思考模式预算修复

规则内置了一段"走一遍真实示例"的演示：PR #3627 修复 Claude 3.7 模型的 thinking mode 计算。这段示例的价值在于它把六个抽象步骤落到具体项目语境中：

# Step 1：收集 PR 信息
gh pr view 3627 --json title,body,comments
gh pr diff 3627

# Step 2：阅读被修改的原始文件，理解上下文
<read_file>
<path>src/shared/api.ts</path>
</read_file>
<read_file>
<path>webview-ui/src/components/settings/ThinkingBudgetSlider.tsx</path>
</read_file>

# 检索各 API provider 目前如何处理 thinking 开关
<search_files>
<path>src/api/providers</path>
<regex>reasoningOn</regex>
<file_pattern>*.ts</file_pattern>
</search_files>

Step 3 的分析结论则是一条教科书式的技术判断链：

1. 该 PR 修复了 Claude 3.7 思考模式预算的计算错误；
2. 现状是思考预算被错误地按 maxTokens（8192）的 80% 计算，得出 6553 tokens；
3. Claude 3.7 实际支持大得多的思考预算（最高 64000 tokens）；
4. PR 在模型定义中新增 thinkingConfig 属性，其 maxBudget 设为 64000；
5. API handler 在启用推理模式时改用该值；
6. 滑杆组件根据模型专属百分比计算最大值；
7. 配套补充了覆盖计算逻辑的完整单测。

把这段示例映射到当前仓库的真实源码，可以确认 thinkingConfig/maxBudget 正是项目模型目录体系的正式字段：在 sdk/packages/shared/src/llms/model-info.ts 中，ThinkingConfigSchema 定义了 maxBudget、outputPrice、thinkingLevel（枚举 low | high）等可选字段，并在 ModelInfoSchema（同文件）里以 thinkingConfig: ThinkingConfigSchema.optional() 接入每个模型的定义结构。换言之，"为某个模型声明最大思考预算 → 由推理选项路由逻辑消费"是一套已落地的实现模式（相关消费逻辑见 sdk/packages/llms/src/providers/routing/reasoning-options.ts 与 provider-option-rules.ts，UI 层在 apps/vscode/webview-ui/src/components/settings/common/ModelInfoView.tsx 展示模型信息）。审查这类 PR 时，按示例的做法先读模型 schema、再检索消费方、最后核对测试覆盖，就能对"预算上限从哪来、被谁用、百分比怎么算"形成闭环证据。

Step 4-6 的执行则照搬标准交互：先给出"建议通过，理由包括：正确引入 thinkingConfig.maxBudget（64000）、滑杆按 50% 计算合理、配套单测完善、实现干净且符合项目规范"，让用户在三个选项中确认；随后询问是否需要代笔评论；最终用 --approve 落定，并在多行正文中点名"特别欣赏 maxBudget 属性与 50% 百分比的处理、完整的单测、贴合编码规范"。

评审沟通的软性规范

规则后半部分专门约定了"评审者该怎么说话"：

• 像友好的 reviewer 一样正常交流，保持简短，开篇先感谢 PR 作者并 @ 提及对方；
• 无论是否通过，先给一段简短、不武断的变更概述，语气保持谦逊，像"这是我目前的理解"；
• 有任何建议或必须修改之处，就 request changes 而不是 approve；
• 行内评论（inline comments）是好习惯，但只在确有具体可说的点时才留下；且应先留行内评论，再以一段简短评论概括修改主题并正式 request changes。

规则还沉淀了若干真实评审评论样例，涵盖"简短通过"与"请求修改"两种典型形态，可以直接复用为语气模板：

• 简短通过型："Looks good, though we should make this generic for all providers & models at some point"（整体没问题，但将来应把它推广到所有 provider / model）；
• 完整通过型：先点出最喜欢的实现（如把全局端点能力做成 ModelInfo 上的能力标志、用过滤模型列表替代硬编码、升级 genai 依赖），再感谢作者补充了关于限制的文档说明；
• 请求修改型：即便整体认可（"This is awesome. Thanks @scottsus."），仍明确主要顾虑（如是否适配所有 VS Code 主题，要求在不同主题下测试并附截图后才能合并），或委婉拒绝合并（如逐条列出环境变量会被拼进每条消息、设置项应保持简洁、等设置页重构后再议，最后以"Please bear with us."收尾）。

可复用的 GitHub CLI 命令速查

规则末尾汇总了整条工作流会用到的高频 gh 命令，按用途整理如下。

基础 PR 命令

gh pr view --json number -q .number        # 当前分支对应的 PR 号
gh pr list                                  # 列出打开的 PR
gh pr view <PR-number>                      # 查看单个 PR
gh pr view <PR-number> --json title,body,comments,files,commits  # 多字段视图
gh pr status                                # 查看 PR 状态

Diff 与文件命令

gh pr diff <PR-number>          # 完整 diff
gh pr view <PR-number> --json files   # 变更文件列表
gh pr checkout <PR-number>      # 本地检出该 PR 分支

评审命令（approve / request-changes / comment 三种形态，单行与 heredoc 多行两种写法均已在上文展开）

gh pr review <PR-number> --comment --body "Your comment message"

补充命令

gh pr checks <PR-number>              # CI 状态
gh pr view <PR-number> --json commits # 提交列表
gh pr merge <PR-number> --merge       # 有权限时合并

从交互式审查延伸到自动化 CI 评审

交互式规则之外，仓库还提供了把同一套审查能力推入 GitHub Actions 的完整示例文档 docs/cli/samples/github-pr-review.mdx。两处内容形成互补：交互式规则依赖"已认证的 gh + 用户实时确认"，CI 方案则用 cline auth --provider anthropic --apikey "${{ secrets.ANTHROPIC_API_KEY }}" 完成非交互认证，用 cline --auto-approve true '<系统提示词>' 进入自主执行，并以 CLINE_COMMAND_PERMISSIONS 环境变量把 Cline 能运行的命令白名单化——只放行 gh pr diff/view/checks/list、gh issue list/view、git log 以及针对该 PR 的 gh pr comment 与 gh api .../pulls/.../comments|reviews，在"能读代码、能写评审"与"不能动系统"之间划出安全边界。其工作流事件与交互式规则中的命令骨架高度一致，说明无论人工驱动还是 CI 驱动，"用 gh 收集上下文 → 深度分析 → 提交综合评审"都是同一条流水线。

小结

.clinerules/workflows/pr-review.md 是一份把"PR 审查"这一高频协作任务标准化、可复现化的工作流规则：以 gh 为信息通道、以文件检索与源码精读为分析手段、以"先确认后行动"为交互原则、以 gh pr review --approve/--request-changes 为收尾动作，并辅以友好的沟通语气模板与命令速查。把它与 address-pr-comments.md（回应评审意见）、docs/cli/samples/github-pr-review.mdx（CI 自动化）放在一起，就构成了一套覆盖"评审他人 PR"与"处理自己 PR 评论"的完整 Cline 协作工作流。