用 diff 替代整文件，减少 AI 编辑器令牌消耗
为什么整文件会让令牌账单失控
每天在编辑器和终端里写代码时，我最容易浪费令牌的动作，是把整个文件直接丢给模型。一个 800 行的组件，即使只要改一处空状态文案，也会携带大量未变的类型、样式、测试和历史包袱。模型需要重新理解全部内容，你也要为这些重复上下文付费。更糟的是，整文件输入会掩盖真正的问题：模型往往开始重构无关代码，而不是完成那一个明确修改。
更稳妥的原则是：把任务描述、当前 diff、相关函数附近的少量上下文一起发送。diff 告诉模型已经发生了什么，局部上下文告诉它改动处如何运行，任务描述则定义边界。对于 Claude Code、Codex、Gemini CLI 或任意 OpenAI SDK，这个输入结构都成立。
先用 Git 确认工作区只包含目标改动
开始前先清理思路，而不是马上调用模型。在仓库根目录执行下面两条命令： — git status --short
git diff --stat — 第一条命令让我确认没有把无关实验文件带进去；第二条命令快速显示改动规模。如果统计结果远超预期，我会先拆分任务或暂存无关修改。接着生成可读的补丁：
git diff -- src/auth/session.ts — 文件路径一定要收窄到当前问题涉及的文件。若你正在修复一个跨文件缺陷，可以显式列出两个或三个路径，而不要使用没有参数的 git diff。这样得到的上下文既足以分析控制流，也不会混进整个工作区的噪声。
- 每次提交给模型的补丁都应该对应一个明确问题。
- 未完成的重构改动应当先暂存或临时撤出工作区。
- 二进制文件和生成文件不应进入任何代码分析提示词。
用零上下文差异定位真正需要解释的代码
默认 diff 带有三行上下文，通常适合小修改；但在大型文件中，我会先看最小变化集： — git diff -U0 -- src/auth/session.ts
这条命令只显示新增和删除的行，适合快速询问模型“这段改动可能破坏了什么”。随后再围绕变更行提取必要上下文。例如改动在 142 行附近，可以执行： — sed -n '110,180p' src/auth/session.ts
现在提示词只需要包含任务、git diff -U0 的输出和 sed 输出。不要让模型猜测文件其余部分；如果它需要额外定义，再按它指出的符号补一小段。这个两阶段方式比一开始发送完整文件更容易发现缺失信息，也更便于控制输入长度。
把补丁和约束写成可执行的终端提示词
我通常先把上下文写入临时文本，再交给命令行代理。下面的命令不会修改代码，只生成一个可检查的提示词文件：
{ echo '任务：审查以下会话续期改动，找出潜在的空值、并发和测试缺口。不要建议无关重构。'; echo; git diff -U0 -- src/auth/session.ts; echo; sed -n '110,180p' src/auth/session.ts; } > /tmp/session-review.txt
然后把 /tmp/session-review.txt 的内容粘贴给代理，或通过你常用 CLI 的标准输入传入。关键不是某个命令格式，而是提示词始终要求模型基于给定材料回答，并在信息不足时先提出具体文件和行号。若模型建议修改，再要求它返回 unified diff，而不是重贴完整文件。
对于需要统一 API 配置的团队，我会把 Fluxo 的基础地址设为 https://api.fluxorelay.com，并使用同一把密钥切换模型。它可用于 Claude Code、Codex、Gemini CLI 和 OpenAI SDK；例如先用 Claude Sonnet 5.5 做补丁审查，再用 DeepSeek V4 Pro 复核边界条件，而无需为每个提供方重复配置。
让模型只返回可应用的 unified diff
收到分析后，下一轮请求要足够严格：仅返回 unified diff；只改指定文件；不修改格式化无关行；为每个行为变化补测试。拿到补丁后，不要直接相信它，先保存并检查： — git diff --check
如果代理输出保存为 /tmp/fix.patch，可以在单独分支或干净工作区预览应用效果： — git apply --check /tmp/fix.patch
通过检查后再执行 git apply /tmp/fix.patch，并立即运行项目的目标测试命令。这个流程把模型输出限制为小而可验证的变更，也避免整文件回写覆盖你尚未保存的工作。
- 统一 diff 可以被 Git 检查、审阅和精确回滚。
- 补丁中的每一处修改都应能对应原始任务。
- 测试失败时应只发送失败输出及相关测试片段。
按真实令牌计费时，diff 工作流更容易预测成本
差异化输入不仅更快，也让用量更可控。Fluxo 按真实令牌计费，包含缓存读取和写入，没有月费；因此减少无关文件内容会直接减少每次请求携带的信息量。缓存适合反复出现的项目规则和稳定依赖，但当天刚改过的业务文件仍应优先发送 diff。养成这个习惯后，模型看到的是明确问题，而不是整个仓库的快照。
如果你想把这套终端工作流接入现有工具，可以创建一个 Fluxo 账户后用同一密钥试运行几次小补丁任务；邀请的开发者付费时也能获得推荐分成。先从一次真实的 bug 修复开始，记录整文件与 diff 输入的令牌差异，再把有效模板放进团队脚本中。