代码改了很多，AI 为什么只审了前面？

把 Git 修改交给 AI 审查时，输入很快就会超过一次请求能容纳的范围。一个直接的办法是截取 diff 的前 N 个字符，再让模型给出意见。

这会产生一个不太显眼的问题：第一个文件大一点，后面的修改就完全进不了输入，模型却仍能给出一份正常报告。读报告的人如果不知道截断发生过，就可能把它理解为整批修改已经审完。

先减输入，还是先确定要审什么？

需要先确定范围。审暂存区、整个工作区，还是两个提交之间的差异，对应的输入不同。把范围收错了，后面分得再细也没有用。

项目会收集已暂存、未暂存和未跟踪文件。未跟踪文件不在普通 diff 中，需要单独读取并按新增文件组织。同一文件既有暂存又有未暂存修改时，当前收集器组合的是两个阶段的差异，还不能把它当成某个基线到最终工作区的唯一补丁。

未跟踪项也可能是目录、嵌套仓库或二进制文件，不能假定每个路径都能按 UTF-8 文本读。

可以按字符硬切，简单，但容易切断文件头和修改上下文；也可以按文件分，每份输入比较完整，但单个大文件仍然可能超限。更细的一层是 hunk，也就是 diff 中带原始行号范围的连续修改片段。

项目采用文件优先、过大再拆 hunk 的方式。只有一个 hunk 本身仍然过大，才裁剪内容并标记截断：

文件 A 放得下     → 完整保留
文件 B 太大       → 按 B1、B2、B3 三个修改片段拆开
B2 本身仍然太大   → 截断 B2，并标明内容不完整
文件 C 放得下     → 继续保留 C

拆开的每块都附带文件头、文件名和原始行范围，方便定位。范围表示内容原来位于哪里；如果这块被裁过，并不代表范围内的每一行都已经交给模型。

这种拆法至少不会让第一个大文件吞掉后续所有文件，也能保留一部分局部上下文。

已有回归用例使用真实临时 Git 仓库，构造两个文件，让总 diff 超预算、每个文件各自不超，检查两个文件都能进入分块；另有用例检查未跟踪目录项。它们验证收集和分块，不验证模型是否善于发现缺陷。后者需要带已知问题的修改样本，另看漏报、误报、定位和调用成本。

这里的预算按字符串长度计算，没有经过 tokenizer。同样长度的中文、代码和符号，token 数可能不同。多个块加起来也会超过单块预算，重复文件头还会增加总输入。

如果要限制最终请求大小，需要在组装完系统提示、上下文和输出预留后计算；要限制整轮成本，还要统计所有调用。现有分块只负责组织输入，没有提供这两个硬保证。预算极小时，连文件头和截断标记都可能放不下，也需要单独定义处理方式。

拆分还会损失关联。例如文件 A 改了函数签名，文件 B 改调用，单看一块可能发现不了不一致。可以按符号、import 或调用关系补上下文，但这是后续能力。现有多个审查者及汇总环节，无法凭空补回从未收到的代码。

项目把分块中的截断状态汇总到审查输入，再带到最终报告。某个审查者调用失败，也与“审查成功但没有发现问题”分别记录。

目前一个截断布尔值还不能列出所有遗漏行和跨文件关系，但至少能提醒调用方：这份报告使用的输入并不完整。