Twinny 代码审查机制深度解析：Diff 过滤、分块策略与上下文预算
Twinny 作为一款强大的 AI 代码审查工具，其核心功能之一是通过侧边栏的 Review Tab 实时分析工作区、分支或 Pull Request 的变更。然而，从按下审查按钮到模型开始生成反馈，中间经历了一个复杂的处理管道。官方最新博客《A review in parts》深入剖析了这一过程，揭示了 Twinny 如何筛选、切割并打包 Diff 数据，以适配不同模型的上下文窗口限制。
核心处理流程：从 Git Diff 到模型输入
Twinny 的审查逻辑主要分布在 src/extension/review/ 目录中，其中 diff.ts 是纯逻辑层，不依赖 VS Code 或 Git 客户端，专注于解析数据。
1. Diff 来源的标准化
无论审查的是工作区（git diff HEAD）、分支（git diff base...HEAD）还是 GitHub Pull Request，最终输入模型的数据形态高度统一：一个标题加一段统一 Diff 文本。
- 工作区审查：遵循 Git 标准，未暂存的新文件不会出现在 Diff 中。
- 分支审查：自动检测 Base Branch（优先使用远程默认分支，如
origin/main），确保只对比增量变更。 - PR 审查：直接请求 GitHub 的 raw unified diff，仅进行两次 GET 请求，无后端转发。
2. 噪声过滤：What is thrown away
为了节省 Token 并提高审查效率，Twinny 的 parseUnifiedDiff 和 noiseReason 函数会主动丢弃大量无意义的文件内容。被过滤的类别包括：
- 锁文件与构建产物：
package-lock.json,yarn.lock,Cargo.lock等所有*.lock文件，以及.min.js,.snap等编译输出。 - 依赖目录：
node_modules,vendor,dist,build,out,.next,target等目录下的所有内容。 - 二进制与媒体文件：通过
diff --git头部的Binary files标记识别的文件，以及图片、字体、压缩包等。 - 空变更：完全没有
@@Hunk 的文件（如纯模式变更或空文件）。
值得注意的是，过滤后的文件会在聊天界面中以“[原因]”形式列出（最多 12 个），若所有文件均为噪声，则直接提示用户而非发起无效请求。
3. 分块策略与上下文预算
这是 Twinny 最精妙的部分。由于模型无法预知 Tokenizer 的具体参数，Twinny 使用字符数作为预算单位。
- 单文件切割：默认单份请求限制为 16,000 字符。若单文件过大，会在 Hunk 边界处进行切割，保留前 8,000 字符，并在文末注明省略行数。即使整个文件是一个巨大的 Hunk，Twinny 也会保留第一部分以确保审查不丢失关键上下文。
- 整体打包：文件按顺序填入当前部分，直到下一个文件不匹配为止。最多分为 8 个部分（Parts）。
- 总容量上限：在默认设置下，单次审查的总 Diff 字符数上限为 128,000 字符（8 部分 × 16,000 字符）。超过此限制的部分将被标记为“未审查（过大）”。
4. 配置项：平衡精度与效率
唯一的关键配置是 twinny.reviewMaxDiffChars（默认 16,000）。
- 小上下文模型：建议调低此值。较小的窗口意味着更少的 Token 消耗，审查反馈能更快生成，且模型不易遗忘前文。
- 大上下文模型：建议调高此值。更大的窗口允许一次性审查更多文件，保持审查结果的连贯性和完整性，避免模型在多次请求中丢失早期信息。
实际价值
Twinny 的这种设计哲学体现了“按需审查”的理念。它并非盲目地将所有代码丢给大模型，而是通过严格的规则过滤噪声，通过智能的分块策略适配不同硬件环境下的模型能力。对于开发者而言，这意味着在复杂的代码库中，即使面对数千行的变更，也能获得结构清晰、重点突出的 AI 反馈，而无需担心上下文溢出或 Token 成本失控。
通过深入理解这一机制，开发者可以更灵活地配置 Twinny，使其在不同开发场景（如快速迭代 vs 大型重构）下发挥最大效能。
