我如何设计一个低 Token 消耗的自动编程工作流

目标：同样任务，更少往返

自动编程工作流里，Token 成本通常来自四块：

1. 过长的系统提示与历史对话
2. 反复读取同一批文件
3. 无结构化的失败重试
4. 「先大段生成，再靠对话修」的低效循环

我的设计原则是：把确定性工作交给程序，把不确定工作交给模型，并让每次模型调用都带着窄上下文与硬验收。

工作流骨架

一个低 Token 倾向的闭环可以拆成：

定位范围 → 最小上下文装配 → 计划（短）→ 局部实现 → 自动验收 → 仅失败处再推理

1. 定位范围，而不是整库倾倒

优先用路径、符号、测试失败栈来圈定文件集合，而不是把仓库摘要一次性塞进提示词。

2. 上下文分层

• L0 契约：目标、禁止项、输出格式（稳定，可缓存）
• L1 相关代码：当前任务真正触及的片段
• L2 证据：测试输出、类型错误、diff

避免把 L0 与大量无关文件重复拼接。

3. 计划短、实现窄

先要一份可检查的短计划（改哪些文件、预期测试），再进入实现。计划阶段禁止大段代码，减少「生成后推倒重来」。

4. 验收自动化

用测试、类型检查、lint 作为硬门禁。通过则停止；失败则只回传失败摘要，而不是完整日志洪水。

降本策略清单

策略	作用
工具结果摘要化	降低重复原始输出
文件级缓存 / 指纹	避免重复读取未变更文件
重试熔断	防止同错误空转
patch 优先于全文重写	减少输出 Token
分阶段模型选型	简单步骤用更小模型（若链路支持）

不该省的地方

成本优化不是压缩一切：

• 安全相关上下文不能省
• 验收命令与结果不能省
• 变更边界说明不能省

省掉这些，后面的返工会更贵。

一个可观测的最小指标集

即使不做复杂实验平台，也可以先记录：

• 每次任务的模型调用次数
• 输入/输出 Token（或近似字符量）
• 首次通过验收的比例
• 平均重试次数

有指标，优化才不是感觉驱动。本文不给出虚构数字；你应在自己的仓库与任务集上建立基线。

小结

低 Token 自动编程的关键不是「让模型少说话」，而是：

1. 缩小决策面
2. 固化可自动部分
3. 用验收闭环替代长对话修补

当你把 Skills、Tools、Hooks 放进 Harness，并给每次调用装上预算与证据要求时，成本控制会从口号变成工程属性。