终端里只交补丁：2026 年用差异替代整份文件的省词元实践

改了六行，就别默认发送六百行

每天在编辑器里修接口，最容易浪费词元的动作，是把整个文件重新贴给模型。明明只改了超时处理，却让它再次阅读导入、类型定义和旧逻辑。2026 年值得养成的习惯，不是永远只发差异，而是把变更作为默认入口，在证据不足时再补上下文。

这也不是要求模型凭空猜测。差异说明哪里变了，基线说明原来是什么，测试说明预期是什么。三者配齐，通常比一份没有任务边界的完整文件更实用。

先固定基线，再生成可复现差异

我会先记录 git rev-parse HEAD，再运行 git diff --unified=3 HEAD -- src/client.ts tests/client.test.ts。这会展示指定路径中相对当前提交的已跟踪改动，包括暂存与未暂存部分。若只审查即将提交的内容，就改用 git diff --cached --unified=3。

• 每次请求都要附上基线提交标识，并且说明差异覆盖哪些文件与变更范围。
• 首次请求需要提供相关函数或工具读取权限，不能假定模型已经见过仓库基线。
• 新建但尚未跟踪的文件不会自动进入上述差异，需要检查后另行加入请求。

重命名可以增加 --find-renames；锁文件、生成代码和格式化噪声则应单独处理。不要为了缩短输入，直接删掉可能影响行为的依赖变化。

保留三行上下文，不够时按符号补齐

零上下文差异看起来最省，却经常让模型误判作用域。三行只是起点：涉及异常传播，就补调用者；涉及权限判断，就补鉴权入口；涉及返回结构，就补类型定义。按函数和依赖补充，比随手截取文件前两百行更靠谱。

例如让 Claude Sonnet 5.5 检查重试逻辑时，可以提供变更差异、请求函数、错误类型和两个相关测试，再明确要求：只检查重复请求与超时语义；缺少证据时列出需要读取的符号，不要自行补全仓库事实。

把模型输出也限制为补丁

只压缩输入还不够。如果模型最后重写整份文件，输出词元和人工核对成本照样上涨。我通常要求返回统一差异格式，限制修改路径，禁止无关重排，并且把解释控制在必要范围。

如果由 GPT-6.1 Sol 生成修复，可以明确写出：仅修改 src/client.ts 与对应测试；保留现有公开接口；输出可应用补丁，不复述未修改代码。工具型客户端若支持结构化编辑操作，优先使用其原生编辑能力，不必强迫所有工具输出文本补丁。

应用补丁前先校验，失败时别强行拼接

文本补丁不是执行结果。保存后先运行 git apply --check patch.diff，确认能匹配当前工作区，再应用、运行类型检查与相关测试，最后查看 git diff，确认没有误删代码或夹带额外修改。

• 补丁无法应用时应重新获取当前差异，并且检查文件是否已经被其他工具修改。
• 测试通过以后仍要检查修改范围，因为测试无法覆盖全部副作用与安全边界。
• 涉及密钥和真实用户数据的上下文必须先脱敏，不能把省词元当成安全措施。

多轮修改要同步状态，不要无限叠加差异

第一轮补丁应用后，第二轮应该基于新的工作区状态。明确告诉模型上一轮哪些修改已落盘、哪些测试失败，以及当前差异对应哪个基线。不要只说“继续修”，然后期待它准确记住所有中间版本。

对话压缩、切换模型或恢复会话后，尤其要重新建立状态。当差异已经比相关函数更长，或者跨文件重构让局部片段失去意义时，直接发送相关完整文件更合适。省词元不是禁止全文，而是避免无价值的重复。

缓存命中与差异压缩要一起算账

稳定的项目规则和接口约定适合放在请求前部，频繁变化的差异放在后部；但缓存是否命中，仍取决于模型、接口与客户端的具体机制。已缓存的长上下文可能比反复重组的短输入更划算，不能只比较请求字符数。

我会记录输入、输出、缓存读取、缓存写入和重试次数，再比较完成同类任务的总成本。Fluxo 使用一个密钥和 https://api.fluxorelay.com 这个基础地址接入 Claude、GPT、Gemini、DeepSeek、Kimi、GLM、Qwen、Grok 等系列，按实际词元计费，包含缓存读取与写入，没有月费；因此复盘时要把这些项目一起看。

在现有终端工具里落地差异工作流

Fluxo 可用于 Claude Code、Codex、Gemini CLI，以及任何使用 OpenAI SDK 的客户端。接入后仍需检查工具实际发送了什么：提示里写着“只看差异”，不代表客户端不会自动读取整个文件。先查看可用日志，再决定限制读取范围还是保留必要上下文。

如果想在自己的仓库里验证这套流程，可以创建一个 Fluxo 账户，从一次小范围修复开始。邀请他人后，对方付费时还可获得推荐分成；评估开发成本时，建议把它与请求开销分开记录。需要帮助，可以登录后在联系页面留言。