Kimi Code 仓库 PR 审查技能实战：用 review-pr 输出结构化中文评审报告-平芜编程栈

AI Agent
代码智能体
人工智能
大模型
CLI

【免费下载链接】kimi-code

Kimi Code CLI — The Starting Point for Next-Gen Agents

项目地址：https://gitcode.com/gh_mirrors/ki/kimi-code

导读

review-pr 是 Kimi Code 仓库内置的 Agent Skill，用于在本仓库内审查 Pull Request：它会先拉取 PR 描述与完整 diff，再对照模板结构与实际代码改动逐项评估，最终输出一份中文的结构化评审摘要。本文以该 Skill 为骨架，完整展开其五个审查步骤、模板章节中英文对照表与六类评审标准，并对照仓库中的 PR 模板、write-pr 技能与 Skills 机制文档，说明评审标准背后的仓库约定。读完你既能照章完成一次高质量 PR 评审，也能理解这些标准从何而来。

Skill 定位与适用场景

review-pr在仓库中位于 .agents/skills/review-pr/SKILL.md，属于项目级 Skill——按 Skills 存放位置的规则，项目根目录下的.agents/skills/会被 CLI 扫描注册。它的 frontmatter 声明了用途：

--- name: review-pr description: Use when reviewing a pull request in the kimi-code repository — translate the PR template sections into Chinese and evaluate the change against the template structure. disable-model-invocation: true ---

两个字段值得注意：

description：告诉模型“何时该用”——仅在审查本仓库 PR 时触发，不会扩散到其他场景；
disable-model-invocation: true：按 Frontmatter 字段表的定义，此开关设为 true 会禁止模型根据 description 自动调用，只能由用户通过/skill:review-pr主动触发。这也解释了为什么它是典型的人工主导流程：审查需要核对 diff 与描述的一致性，由用户显式指定 PR 编号最稳妥。

审查工作流：五步闭环

Skill 定义了一套固定操作顺序，确保“先取证、后评判”：

拉取 PR 描述与元数据
```
gh pr view <number> --json title,body,url,files,additions,deletions,baseRefName,headRefName
```
这一步用 GitHub CLI 一次性取回标题、正文、URL、变更文件列表、增删行数以及 base/head 分支名，作为后续评估的元数据底稿。
读取完整 diff
```
gh pr diff <number>
```
只凭描述无法判断真伪，必须通读全部变更。
阅读足够的周边代码，验证 PR 描述中的每个论断。
对照下文标准逐节评估。
用中文撰写评审摘要。

这五步与 write-pr 技能形成对照：写 PR 时（git diff main...HEAD取证、按模板填写、gh pr edit --body-file发布），审 PR 时（gh pr diff取证、按模板逐节核对、中文总结）——两个 Skill 共享同一套模板结构作为对齐基准。

模板章节中英对照

本仓库每个 PR 都以 .github/pull_request_template.md 开头，评审摘要必须使用对应的中文章节名：

English	中文
Requirement or Bug	需求或 Bug
Bug Reproduction Steps	Bug 复现步骤
Root Cause	根本原因
Code Changes	代码变更
Impact Scope	影响范围
Checklist	检查清单

对照模板原文可以看到这些章节的填写约定：Requirement or Bug若有 issue 写Resolve #(issue_number)，否则用 100 字以内平实语言描述；Bug Reproduction Steps仅 Bug PR 必填，feature PR 写N/A；Root Cause需说明是根本修复还是临时 workaround；Code Changes用易读语言向 reviewer 描述；Impact Scope说明受影响的模块/功能路径与测试覆盖；Checklist逐项勾选。

六类评审标准详解

Skill 对每个模板章节给出了明确的“合格线”，以下逐条展开。

需求或 Bug

关联的 issue 是否有效且相关？
若无 issue，需求是否用一两句话表述清楚？

仓库对此有更严的外部门槛：CONTRIBUTING.md 规定外部 PR 仅接受获批准的 bug 修复，必须先开 issue 并等待维护者以/approve评论批准，再在 PR 中链接该 issue；未经批准的 PR 可能被直接关闭。模板头部注释也双语重申了这一点。因此评审时若发现“需求或 Bug”一节引用了未获/approve的 issue 或根本没有 issue，应作为阻塞项提出。

Bug 复现步骤

对 Bug PR：步骤是否清晰、可复现？
是否真能按步骤在 base 分支上确认 bug 存在？

评审者不能只看结论，要亲手验证“bug 确实存在于改动之前”——这决定了 PR 是否真的在修复一个真实问题。模板建议把复现步骤写在 issue 里并在 PR 中链接，没有 issue 时才直接写在 PR 中；Skill 的评审标准与之对应：链接存在且步骤可复现即为合格。

根本原因

对 Bug PR：根因解释是否有说服力？
所述根因是否与 diff 中看到的一致？
是否说清这是根本修复还是workaround？

模板要求作者明确标注“fundamental fix or a workaround”，评审者的任务是交叉验证：diff 的改动方式是否与描述相符，若只是绕过表象而未触及根因，应在评审中指出。这一条与 write-pr 技能中“Root Cause — 说明原因并注明是根本修复还是 workaround”的要求一一对应。

代码变更

描述是否与实际 diff 一致？
视觉化提纲（diff 块、调用树、文件树）是否准确且有帮助？
方案是否合理？是否存在更简单的替代？
作者是否遗漏了边界情况？

这里特别值得展开的是“视觉化提纲”。write-pr 技能的 “Visual Outline for Code Changes” 一节给出了本仓库偏好的表达方式：能用结构视图就不用散文，按变更性质选用最小组合：

逻辑/算法变更 → 伪代码 diff 块；
运行时控制流 → 调用树 diff；
文件职责变更 → 浅层文件树 diff；
组件/UI 结构 → 组件树 diff；
交互/数据流（尤其解释 bug 机制）→ Mermaid 时序图；
关键数据结构/类型变更 → 语言特定代码块。

评审者拿到这类视觉提纲时，重点核对“形状是否真实”：diff 块里的+/-是否与真实改动吻合、调用树里新增的调用是否存在、文件树增删的路径是否对应实际文件。Skill 将其列为评审要点，正是因为结构视图比散文更容易被肉眼快速校验。

影响范围

是否识别出所有受影响模块？与 diff 文件清单交叉核对。
测试覆盖是否与声称的范围一致？
是否存在未测试且带风险的路径？

评审者应把 PR 描述中的模块列表与gh pr view返回的files清单逐一对照，并用本仓库的包结构验证归属——例如 CLI/TUI 改动应落在 apps/kimi-code，Agent 引擎在 packages/agent-core-v2，VS Code 扩展在 apps/vscode，这些入口在 CONTRIBUTING.md 的 Project Layout 一节有完整说明。同时结合仓库的变更记录约定：gen-changesets 技能规定“用户不可感知的改动不写 changeset”，而 CONTRIBUTING.md 要求影响发布产物的 PR必须带 changeset——评审时若发现用户可见的行为变更缺少 changeset，应作为遗漏项标记。

检查清单

所有适用项是否都已勾选？
对标记为“不需要”的项，你是否同意？

模板的 Checklist 目前包含五项：已读 CONTRIBUTING；已链接相关 issue（外部 PR 需维护者/approve）；已添加证明功能可用的测试；已运行gen-changesets或本 PR 无需 changeset；已运行gen-docs或本 PR 无需文档更新。评审者的工作不是数勾选个数，而是判断每一项的“不需要”是否站得住脚——例如一个修改了docs/下用户文档的 PR 声称“无需文档更新”，就属于需要挑战的声明。

输出规范：中文结构化评审摘要

最终产出是中文评审摘要，对每个章节要求：

说明该节是否填写充分；
标记缺失、不准确或与 diff 不一致之处；
若 PR 已就绪则明说；若需改动，则列出可执行的修改项。

这种“逐节判定 + 行动清单”的结构，与 docs/zh/customization/skills.md 完整示例中 review 报告的四段式（总体结论 approve / request changes / comment、阻塞项 blocking、非阻塞建议、值得肯定之处）思路一致，可互为补充。

扩展：把它变成你自己的可复用 Skill

review-pr的目录形式本身就是一个范本。若想在自己维护的仓库里复用这套流程，可参考 docs/zh/customization/skills.md 的完整示例：在$KIMI_CODE_HOME/skills/review-pr/（未设置KIMI_CODE_HOME时为~/.kimi-code/skills/review-pr/）创建SKILL.md，声明name: review-pr与带pr_ref的arguments，正文用$pr_ref占位符接收 PR 编号，检查清单放同目录references/checklist.md，重开会话后即可/skill:review-pr #1234调用。Kimi Code 会在发送给模型前展开$<name>、$0、$ARGUMENTS等占位符（详见正文占位符）。

小结

review-pr的价值在于把“PR 审查”从凭感觉的漫谈，变成可执行的五步取证流程与六类可核对的标准：先gh pr view+gh pr diff取证，再对照本仓库 PR 模板的六个章节逐项验证，最后用中文输出带行动项的结构化结论。它与 write-pr 一写一审、共享同一套模板基准，配合 CONTRIBUTING.md 的外部 PR 准入规则（issue 需维护者/approve）、gen-changesets 的变更记录约定，构成了 Kimi Code 仓库完整的 PR 质量闭环。