一周代码合并之后，算一次真正的调用成本

让编程助手修改一个函数，账单可能很小。但同一个任务经过几次补充说明、测试失败和重新修改，最终花了多少，通常没有第一次调用那么直观。把观察单位从“一次提问”换成“一个已合并的拉取请求”，更接近实际交付：代码不仅生成了，还经过检查，进入了项目。

这个指标可以叫作每个已合并拉取请求的成本。它不负责判断代码是否优秀，也不是给开发者排名的工具。它只是帮助你回答一个具体问题：这段时间花在编程助手上的费用，换来了多少项真正完成的修改。

§ 先约定什么算完成

拉取请求是提交代码修改、等待审查的一种方式，常简称为 PR。对于刚开始记录成本的人，可以把“已经合并到目标分支”作为完成标准。只创建了分支、生成了补丁，或者提交后被关闭，都不计入已合并数量。

不过，没有合并的尝试不能从费用里消失。它们同样消耗了预算。为了避免账期错位，建议先选取同一批任务，等它们合并或明确终止后，再汇总这批任务的全部调用费用。尚未结束的任务单独保留，不要提前当作失败，也不要当作交付。

每个已合并 PR 的模型调用成本＝这批任务的全部模型调用费用÷其中已合并的 PR 数量。分子应包含成功修改、失败尝试、重新生成以及助手参与审查的调用，而不是只统计最后一次成功运行。

假设一批任务累计产生了 48 元调用费用，最后有 12 个 PR 合并，另外 4 个关闭，那么平均调用成本是每个已合并 PR 4 元。这只是演示算法的假设数字，不是任何模型或平台的报价。如果没有任何 PR 合并，就记录“本批次尚无合并产出”，不要把除法结果写成零。

开始时不必搭建复杂系统。一张表就够了，每项任务保留几个字段：

如果调用记录提供输入、输出或缓存用量，可以一并保存。但计算金额时，应以适用计费规则和实际账单为准，不要默认所有令牌都按同一个单价收费。一次会话如果服务于多个任务，也要约定分摊方式，并标明这是估算。

Vana API 提供统一接入地址，可用于支持相应接口的开发工具；使用 OpenAI SDK 时，官网列出的地址带有 /v1 路径。统一接入可以减少配置上的重复，但不会自动替你定义哪次调用属于哪个 PR。([vanaapi.com](https://vanaapi.com/))

实际记录时，仍应保留任务编号、调用时间和账单金额。你可以创建一个 Vana API 账户，从一批范围清楚的小任务开始记录；首次练习的重点是把费用与任务对应起来，而不是急着寻找一个最低数字。

只看模型调用费用，适合观察接口支出；如果你关心完整交付成本，就需要另算人工复核与返工。同样是前面的假设案例，若人工共花费 120 分钟，内部按每分钟 1 元计入，那么总成本就是 168 元，平均每个已合并 PR 14 元。人工费率是自己的核算假设，应明确标注。

这两种口径最好并列保留。不要本周只算调用，下周又加入人工，然后把差额解释成模型表现变化。如果还有测试环境等费用，也可以纳入，但应持续使用同一套边界。

修改一句文档和修复跨模块缺陷，都可能只产生一个 PR，所以它们不适合直接混算后评价效率。可以先按任务类型分组，再看平均成本、合并比例和复核时间。也不要为了让数字下降，把一次自然的修改拆成多个小 PR。

每周复盘时，先找成本偏高的几项，看看是否存在重复发送大段上下文、验收要求不清楚，或测试反馈迟迟没有进入下一轮修改。这个指标最有用的地方，不是证明某个工具便宜，而是让你知道下一次应该改进哪一步。