change-review

使用 Repowise 审查变更

有了 diff 后，Repowise 会把“哪些文件发生了变化”转化为“此次变更带来了哪些风险”——将 git 历史（变更频率、代码所有权、共同变更）与图拓扑（依赖项、影响范围）、测试缺口、安全信号，以及约束受影响代码的架构决策结合起来。

两种互补的风险信号，请结合使用：

• get_change_risk(revspec=…) (MCP) 会将整个变更作为一个整体评分（一个提交或一个 base..head 范围）。不使用 LLM，也不联网。优先使用这个 MCP 工具；它接收 revspec 并在服务端执行 diff，因此无需调用 shell。先看 directive 和 health_delta——了解变更实际造成了哪些恶化。由变更引入的问题排在仅被变更触及的既有问题之前。接着看 risk_percentile（根据 diff 大小和分布，将此次变更与近期抽样提交进行比较排名，并非 bug 预测器）；diff_shape 会用一行说明。include=["scales"] 会补充其 review_priority 三分位和 classification 标签。原始 0-10 的 score 与新增行数的相关性高达 0.99，因此不会直接展示，而是放在 include=["diagnostics"] 中。 省略 revspec 可为未提交的工作评分。这是合并前的关卡： “整体而言，这次变更的风险有多高？”如果你已经在终端中，repowise risk <revspec> CLI 使用相同的评分器。
• get_risk(changed_files=…) (MCP) 按文件逐个处理，并返回 directive 区块，指出 diff 中需要检查的具体内容。

先为整个变更评分

get_change_risk(revspec="main..HEAD")   # HEAD, a commit SHA, or base..head

先阅读 directive：其中包含 status、指出恶化情况的 headline、背后的 reasons，以及要执行的 next_actions。health_delta 列出变更引入或解决的问题。然后查看 risk_percentile 和主要影响因素：高分若源于大范围扩散（涉及许多目录或子系统）或作者对代码不熟悉，就能指引你重点查看哪里。extensions=[".py", ".ts"] 只统计指定文件类型；exclude_patterns=["tests/"] 会排除相应路径。若出现 warning 字段，或 directive.status 为 unknown，就表示 revspec 或筛选条件未匹配到任何文件，因此全零评分并不代表状态良好。终端中的等效命令是 repowise risk <revspec>（可添加 --ext .py,.ts 或 --format json）。

接着深入了解逐文件指令

传入已更改的文件，以 PR 模式调用 get_risk：

get_risk(targets=<changed files>, changed_files=<same changed files>)

响应会附带自己的 directive 块，按文件而非按更改列出（与 get_change_risk 的结果不同）——请先查看，其中包含几个简短列表：

• may_break — 通过导入链关联到已更改内容、但不在 diff 中的文件／符号。这表示可达关系，而非 diff：它说明这些文件依赖于已更改的文件，并不表示它们使用的内容发生了变化。请逐一检查。
• missing_cochanges — 历史上常与已更改文件一起变更、但这次未动的文件。通常是被遗忘的更新。
• missing_tests — 存在测试缺口的已更改代码。请指出需要新增／更新测试。
• tests_to_run：此次更改需要运行的测试，来自与 repowise impacted-tests 相同的选择结果；tests_to_run_why 会说明每项测试的原因（已更改文件及其证据，或“每个子集都会运行”）。请先检查 tests_run_all：当它为 true 时，无法保证更小的测试集足够；tests_run_all_reasons 会说明原因，而列表仅表示应优先运行的测试；请建议运行整个测试套件。当它为 false 时，列表就是应运行的测试集。若存储的逐测试覆盖率决定了某个已更改文件的测试，则 tests_to_run_basis 为 measured；若仅依据依赖关系图或规则，则为 inferred。仅当无法做出选择时才会出现 tests_status（timeout、config_invalid、unknown 等）；此时必须运行所有测试。

get_change_risk 会通过 impacted_tests 返回相同的结果：status（selected 或 run_all，或者未选择任何测试的原因）、run_all、reasons、tests_to_run 和 why。对 get_risk 使用 include=["blast"] 会添加 pr_blast_radius，其中包含指令列表背后的完整详情。

如需在终端获取精确到行的版本，repowise impacted-tests <revspec> 会将每个已更改行映射到记录的覆盖范围涉及它的测试，然后输出测试 ID（--format list | xargs pytest 可精确运行这些测试）。它会如实呈现缺口：没有覆盖率记录的已更改文件会标记为文件名猜测；全新文件则会标记为“未知，请运行完整测试套件”，绝不会说“无需测试”。

接着深入探查关键之处

1. 这段代码为何存在？ 对于任何非简单的已更改文件，调用 get_why(query="<file>")——不要让更改悄然违背已记录的架构决策。指出 conflicts_with／supersedes 命中项。
2. 此次更改是否导致健康状况变差？ 调用 get_health(targets=<changed files>, include=["biomarkers"])——指出 diff 引入的复杂度增加、嵌套加深或重复代码。
3. 谁应该审查？ get_risk 的所有权信息和协同更改信号，可帮助找出最了解受影响代码的人。

获取 diff

• GitHub PR：gh pr diff <number>（或 gh pr view <number> --json files）。
• 分支：git diff --name-only main...HEAD。
• 工作树：git status --porcelain。
• 用于比较范围的 CLI 快捷命令：repowise risk main..HEAD 可直接评估分支／PR 范围的缺陷风险。

以证据为依据撰写审查意见

先说明风险级别和 directive 发现的问题，并将每项问题关联到具体文件。区分**“可能导致问题”（diff 外的依赖项）和“值得关注”**（协同更改或健康状况退化）。不要罗列工具无法支持的发现。

错误处理

如果 get_risk 出错或未返回结果，MCP 服务可能已停机，或者仓库尚未建立索引——请说明这一点，并根据原始 diff 进行审查，同时指出 Repowise 上下文不可用。如果仓库尚未建立索引，建议使用 /repowise:init。