只比较每次模型调用的输入和输出费用，容易得出错误结论：一次调用便宜的方案可能需要多轮重试，单次调用昂贵的方案也可能在人工审查时失败。AI 编程的成本单位应是“达到验收标准的一次任务”，而不是一条消息。为此，需要把模型调用、工具执行、测试结果和人工返工关联到同一个任务标识。本文说明如何定义任务成功、设计最小日志字段并进行前后对照，使成本问题能够定位到上下文、重试或验证环节。
先定义什么叫成功任务
不同任务的完成条件不同。可以按类型定义：
缺陷修复：原回归测试从失败变为通过，相关测试集没有新增失败
小功能：约定输入、输出和错误条件均由测试覆盖
代码审查：每条发现能定位到代码并经人工确认
文档更新：命令、配置和链接通过人工核对，构建无错误
代码理解：引用的文件和调用关系均可在仓库验证
没有验收证据的任务不能记为成功。Agent 自行报告“完成”只能作为状态，不能作为统计结果。
让一次任务拥有稳定标识
从收到任务到最终验收，所有调用共享 task_id。若任务范围实质改变，应创建新任务，而不是继续累积在旧标识下。
每条模型调用可以记录：
request_id
task_id
project_id
task_type
model_id
prompt_version
input_units
output_units
latency_ms
retry_index
error_category
每次验证记录：
task_id
validation_command
exit_code
passed_count
failed_count
executed_at
字段应来自实际接口和测试工具。不同供应商如何报告用量可能不同，不要把缺失字段估算成精确值。
单位成功任务成本如何计算
在一个固定观察窗口内，可以使用：
单位成功任务成本 = 已纳入统计的总任务成本 / 验收通过的任务数
总任务成本可拆成：
模型调用费用
工具或执行环境费用
失败重试费用
人工审查与返工时间
如果人工时间暂时无法货币化，可以单独报告分钟数，不要随意指定单价。这样仍能看出“调用费用下降但返工增加”的变化。
给失败分配可行动的类别
仅记录 failed=true 无法指导改进。建议区分：
| 类别 | 典型信号 | 优先检查 |
|---|---|---|
input_missing |
需求或复现信息不足 | 任务模板 |
context_noise |
重复读取无关文件或日志 | 上下文构造 |
tool_error |
命令、权限或环境失败 | 工具接口与环境 |
wrong_scope |
修改任务外文件或接口 | 计划与范围闸门 |
validation_failed |
目标或回归测试失败 | 实现与测试 |
format_invalid |
结构化输出无法解析 | Schema 与校验 |
human_rejected |
人工审查确认结果不可用 | 任务适配与质量 |
错误类别应由测试、工具状态和人工判定共同生成，不能只让执行模型评价自己。
比较方案时控制变量
要评估提示词、模型或上下文策略中的一项变化，应保持其他条件尽量一致：
- 从同一仓库提交创建测试副本；
- 使用同一组任务合同和验收命令；
- 固定工具权限和运行环境；
- 一次只改变一个变量；
- 保存每个任务的原始验证结果；
- 分别报告成功率、调用成本和人工返工。
样本少时只描述本次条件下的观察，不把结果推广到所有项目。
从任务漏斗定位浪费
按状态统计任务数：
started
→ reproduced
→ change_created
→ target_validation_passed
→ full_validation_passed
→ human_accepted
若大量任务停在 reproduced 之前，问题可能是输入或环境；若目标测试通过但全量验证失败，应检查范围和回归；若自动验证通过却经常被人工拒绝，需要检查验收标准是否遗漏业务边界。
成本也按漏斗阶段聚合。这样可以发现资金花在有效实现上，还是消耗在无法复现、重复重试或无关解释上。
预算阀门应绑定停止条件
预算不是到达阈值后静默换方案。可设置：
单任务最大调用次数
同类错误最大重试次数
单次输入或输出上限
达到上限后的人工接管状态
具体数字由历史样本和任务风险决定。高风险任务到达阀门后应保留证据并停止，不能为了完成率而自动降低验证标准。
不要把敏感内容写进成本日志
成本分析通常只需要标识、类型、用量、时间和结果，不需要完整代码、提示词、密钥或用户数据。可以记录提示词版本、文件路径摘要和数据分类，而不是正文。
日志的访问权限与保留周期也应纳入设计。为了追踪成本而创建新的敏感数据集合，可能得不偿失。
每次复盘只改变一个高影响环节
复盘时按任务类型查看：
- 哪类任务单位成功成本高；
- 哪个阶段失败最多；
- 哪种错误重复发生；
- 哪些任务通过自动验证后仍被人工拒绝；
- 哪项上下文材料反复占用输入却没有改善结果。
选择一个有明确证据的问题改进，例如补充复现字段、缩小默认读取目录或增加目标测试。改动后重新跑相同任务集，再判断是否有效。
结论与限制
AI 编程工作流的成本需要以验收通过的任务为单位。稳定 task_id、明确成功定义、关联调用与验证、分类失败和记录人工返工，能把“Token 太贵”转化为具体可改进环节。
本文不提供任何供应商价格、模型排名或成本节省比例。不同接口的用量字段与计费规则会变化，实际费用应使用同期账单核对；样本规模、仓库差异和人工评分都会限制对照结果的外推。