终端里的 git blame：AI 辅助仓库的归属与省钱账本
先查 git blame，再决定让 AI 改哪里
我每天在编辑器里接受 AI 补丁，真正贵的却常常不是第一次生成，而是合并后没人解释得清：这段逻辑为什么存在，谁确认过边界，出了问题该找谁。于是下一位开发者把整个目录重新喂给模型，再买一次已经做过的分析。
我的省钱起点不是换便宜模型，而是在开工前运行 git log -- 路径，再看 git blame -w 路径。先找到相关提交、测试和维护者，只把当前问题需要的上下文交给 AI。blame 是寻找线索的索引，不是追责排行榜；最后修改一行的人，也不一定做过最初的设计。
用 CODEOWNERS 指定人，不把责任交给模型
AI 可以写补丁，但不能承担发布责任。我把三个角色写进任务：提出需求的人、确认业务行为的人、负责合并的人。小团队可以由同一个人兼任，但不能全部填成“AI 已检查”。
- 在 .github/CODEOWNERS 中按目录指定实际维护者，并为无人认领的路径设置默认负责人。
- 在分支保护或规则集中要求负责人审查，不把配置文件本身误认为强制审批机制。
- 在任务描述里写明验收条件和禁止修改的范围，让模型停止猜测隐藏需求。
例如修改支付重试时，任务只允许触碰重试模块与对应测试，不顺手重构整个支付目录。负责人确认幂等性，合并者确认测试结果。边界越清楚，生成、审查和回滚的账单越小。
把 AI 修改拆成能够单独撤回的提交
我不会把重命名、格式化和行为变化塞进同一次提交。先做机械修改，再提交逻辑变化，最后补必要的说明。每个补丁只回答一个问题，审查者不用花时间从几百行缩进变化里寻找真正的条件判断。
提交说明记录修改原因、验证命令和未覆盖风险；合并请求补充 AI 参与范围及使用的模型即可。不必粘贴整段对话，更不要提交密钥、客户数据或含敏感内容的提示词。需要保存的是决策证据，而不是一份昂贵又难搜索的聊天备份。
让 git blame 跳过纯格式化噪声
仓库统一格式后，我会把经过确认的纯机械提交哈希写入 .git-blame-ignore-revs，再运行 git config blame.ignoreRevsFile .git-blame-ignore-revs。这个配置通常需要每位开发者设置，不能假设提交文件后所有人的终端都会自动生效。
遇到代码移动，可以再用 git blame -w -M -C 路径辅助追踪，但仍要打开原始提交核对。不要把修复缺陷或改变行为的提交放进忽略列表。省下查历史的时间很重要，抹掉真实语义变化则会让下一轮调查更贵。
按风险分配模型，按失败次数停止重试
我会先让 Claude Haiku 4.5 处理范围明确的测试补充或局部修改；涉及跨模块约束，再考虑 Claude Sonnet 5.5。模型选择只是起点，最终仍由测试和负责人判断，不能把更高成本当成正确性的保证。
- 每次请求都给出目标文件、失败测试和验收条件，不默认附上整个仓库的内容。
- 同一问题连续两轮没有取得进展时，暂停生成并检查假设、依赖和复现步骤。
- 达到任务预算上限时先由人重新定界，而不是让自动重试继续消耗令牌。
例如给一次普通修复设定五元实验预算，这只是团队的支出上限，不是模型报价。预算耗尽仍未定位问题，就先写最小复现。一次准确的复现，往往比十轮“再试一种写法”更省钱。
把缓存费用和返工时间记在同一本账上
在 Claude Code、Codex、Gemini CLI 或使用 OpenAI SDK 的脚本之间切换时，我用 Fluxo 的一个密钥和统一入口 https://api.fluxorelay.com 管理模型调用；具体工具仍需按各自配置方式设置。它按实际令牌用量计费，缓存读取与写入也计费，没有月费，因此适合按任务观察成本，但不能把缓存命中理解成免费。
我的任务账本只记几项：调用费用、缓存读写用量、人工审查分钟数，以及合并后是否返工。固定说明尽量保持稳定以争取缓存复用，变化内容放在后面；是否真正命中以及节省多少，要以实际用量记录为准。
如果你也想给这套流程建立独立账本，可以创建一个 Fluxo 账户，从一个小修复开始记录。邀请他人后，对方付费可带来推荐分成，但这项收入应单独记账，不要拿它掩盖项目真实的调用成本。
用可解释的补丁降低下一次修改成本
合并前，我最后检查三件事：负责人是否明确，行为变化是否有测试，后来的人能否从提交记录理解取舍。AI 辅助仓库里最划算的代码，不一定是生成时最便宜的代码，而是下次打开编辑器时，不需要再付费猜一遍的代码。