改一个计价函数，只看它自己的 diff 往往不够。调用方是否接受新的异常？旧测试有没有覆盖新增分支？如果项目有几百个文件，审查者需要先找出值得一起读的那几处代码。
Code Review Graph 会解析仓库中的符号与关系，保存一份可查询的图谱。你可以从改动出发，查函数调用、相关文件和测试线索，再回到源码判断行为。本文以 2026 年 9 月 23 日查阅的官方资料和一个本地小实验说明用法，不把项目展示的 token 节省比例当作实际项目的承诺。项目仓库
先看它能替审查者找什么
普通文本搜索能找到函数名出现的位置，但同名函数、导入别名和注释会混在结果里。图谱尝试把文件、函数、类及其关系组织起来，让查询带上“谁调用谁”“哪个测试引用它”这些信息。
这对跨文件修改有帮助。例如底层函数开始抛出异常，调用者没有改动，所以不会出现在本次 diff 中；沿调用关系查找，可以把它带回审查范围。审查者随后检查异常是否向用户泄漏、是否造成事务中断，或者是否已有统一处理。
不过，图上的连线只表示工具解析出的关系。动态导入、运行时注册、框架约定和配置文件中的依赖，未必都能完整反映。查询结果适合作为阅读路线，不能据此认定其他文件一定不受影响。
用三个 Python 文件验证最小流程
本次验证在 macOS 的 arm64 环境、Python 3.12.14 下进行，使用隔离环境中的 code-review-graph==2.3.9。测试没有注册全局 MCP，也没有接入云端嵌入服务。
仓库只有三个文件。pricing.py 定义计价函数：
def total(price, quantity):
return price * quantity
checkout.py 调用它生成结果：
from pricing import total
def checkout(price, quantity):
return {"amount": total(price, quantity)}
test_pricing.py 包含一个现有测试：
from pricing import total
def test_total():
assert total(12, 3) == 36
把这三个文件提交到一个独立 Git 仓库，然后从仓库根目录建立图谱：
code-review-graph build --repo .
本次构建报告解析了 3 个文件，得到 6 个节点、8 条边。这个结果只说明小样本解析成功，没有测量大型仓库的构建速度。
接着修改 total，在乘法前增加数量检查：
def total(price, quantity):
if quantity < 0:
raise ValueError("quantity must be nonnegative")
return price * quantity
此时改动留在工作区，Git 的 HEAD 仍是最初的三个文件。运行：
code-review-graph detect-changes --repo . --base HEAD
code-review-graph impact --repo . --files pricing.py
第一条识别出 total 的修改，并列出从 checkout 到 total 的受影响流程；第二条结果包含 checkout.py，还展示了与 test_total 的测试关系。这正是审查时需要补读的上下文。
“找到测试”与“测试了新行为”有多远
这次输出里的 test gap 数量是零，但现有测试只计算了正数数量。它没有检查负数是否抛出异常，也没有验证调用方怎样处理异常。因此，审查者仍然需要提出两个具体问题。
首先，负数在业务上究竟表示非法输入，还是退货数量？如果系统原来允许负数来冲减金额，新增检查可能破坏已有流程。这个答案要查业务规则和真实调用，单凭函数名无法确定。
其次，如果负数确实非法，检查应该放在哪一层？底层函数抛错以后，接口是否返回合适的状态和提示？批量结算会不会因此整批中止？测试应跟着这些预期补充，而不只是断言“抛出了某个异常”。
图谱帮我们找到了测试文件，却没有替我们评价断言是否充分。把这两件事分开，才能避免看到绿色或零缺口就提前结束审查。
图谱的更新时间要与阅读目标一致
detect-changes 在该版本中读取现有图谱，不会重新解析文件。这次输出仍展示了原先函数的行号范围，虽然工作区里已经增加了几行。沿结果跳转时，应以当前源码为准。
如果希望图谱反映新结构，需要使用增量更新或重新构建。尤其在重命名、移动文件、删除函数之后，旧索引可能把人带到已经失效的位置。官方命令文档区分了构建、增量更新和查询用途，接入编辑器前值得先读这一部分。命令说明
可以为团队约定两个时点：审查前确认比较基线与索引状态，修改完成后更新图谱。比较分支时，还要理解工具采用的 Git 基线，避免把别人的提交混进本次影响范围。输出显示的改动数量与 git diff 明显不符时，先查基线，不要继续解释风险分数。
token 节省比例应该怎样看
“把全仓库塞给模型”与“只取少量相关节点”相比，后者当然可能短很多。但真实工作中，开发者可能原本就用搜索、语言服务器和手工选择文件。换一个基线，节省比例就会改变。
项目的复现说明列出了不同比较口径，包括整库上下文、搜索结果以及多次工具调用。阅读结果时至少核对仓库、任务、返回数量和计算方式。不能把一个大仓库上的比例搬到只有几个文件的小项目里。基准复现说明
本次小实验报告的估算节省比例是零。它仍然找到了有用的调用关系，说明“少读了多少 token”与“是否找到审查线索”需要分别评估。更有用的团队指标可以是遗漏调用方的次数、审查者找到依据所需的时间，以及最终发现的问题是否真实。
把查询结果写成一份可复核的审查记录
可以把本次例子的审查记录分成三段。第一段说明修改：数量小于零时，计价函数新增异常。第二段列出证据：调用位置在结算模块，现有测试只覆盖正常乘法。第三段列出待确认事项：退货是否允许负数、接口层如何处理，以及需要补充哪些测试。
记录中保留提交标识与源码位置，比只保存一次聊天结果更方便复查。后续代码移动了，审查者仍能回到当时的版本。若模型提出一个问题，却找不到对应调用或行为变化，就应先核实，不把它直接转成阻塞合并的缺陷。
对自动化接入，可以先让工具生成待阅读文件清单，由开发者选取必要片段。等几次回放确认范围合适，再让模型补充审查建议。一次返回过多节点时，优先围绕本次行为变化缩小问题，例如只查新增异常的调用路径，而不要求模型评价整个模块。
团队也应保留工具遗漏的例子。框架通过字符串注册处理函数时，文本搜索可能比调用图更有效；数据库字段名改变时，还要搜索迁移与查询。把这些补充步骤写进项目审查说明，能让下一位使用者知道何时需要换一种查法。
接入日常工作前，拿旧修改做一次回放
选择几笔已经知道影响范围的历史提交：一个普通函数修改、一次跨文件重命名，以及一个依赖框架注册的修改。先自己列出应检查的调用者和测试，再看工具返回什么。
把缺失结果分成两类。若源码关系本身能解析却未出现，检查语言支持、忽略规则和索引状态；若依赖来自运行时配置，则需要补充配置搜索、集成测试或人工说明。不要通过扩大返回数量掩盖关系提取的问题。
还要检查返回内容是否过长。包含几十个间接调用者的输出，可能让模型忽略真正关键的入口。限制深度和结果数后，保留被截断的提示，让审查者知道仍有未展开的部分。
默认的本地图谱与可选嵌入功能也应分别评估。启用云端提供商之前，要确认会发送哪些源码衍生内容、使用哪个账号，以及是否产生调用费用。先用普通构建与查询判断价值，没有必要为了试用一次就打开所有功能。
当工具能把一次改动带回具体的调用位置、相关测试和可核对的代码行时，它就有了明确用途。最终审查意见仍应写出行为变化与证据，例如“新增异常会从结算入口向上传播，当前只测试正数数量”，而不是引用一个风险分数代替判断。