终端里的省钱清单：让 Agent 每次交付都能复验

先把“改好了”变成终端里可验证的结果

每天在编辑器里让 Agent 改代码，最贵的往往不是第一轮生成，而是后面三轮“这里还不对”。我现在接任务先写检查清单，再让它动手。目标不是让模型逐字复述同一份答案，而是让同一份需求得到范围一致、可以复验的交付。

比如给订单接口增加幂等保护，不要只写“实现幂等并补测试”。把验收条件落进仓库里的任务文件，让 Agent、审查者和下一次会话读取同一个版本。

• 相同幂等键与相同请求体必须返回首次创建的订单，而且不能重复写入数据库。
• 相同幂等键与不同请求体必须返回约定的冲突状态，并且保留原始订单内容。
• 所有新增行为必须通过指定测试命令验证，交付说明必须记录命令和退出状态。

固定输入，避免每轮都重新猜项目约定

我会在清单开头记录提交哈希、运行时版本、依赖锁文件和测试入口，再明确允许修改的目录。敏感配置只列变量名，不把密钥塞进提示词。时间、随机数和外部接口能替换成测试夹具的，就不要依赖现场环境。

这些约束比“请认真检查”更省钱。模型不必反复搜索同样的目录，也不容易顺手重构半个项目。清单还要写清停止条件：缺少数据库迁移约定时先提问，不要自行发明。

• 修改前先列出准备触碰的文件及其原因，超出允许范围时必须暂停并请求确认。
• 测试必须使用固定夹具和明确断言，不得通过删除失败断言来制造通过结果。
• 无法执行的验证必须标记为未验证，并说明缺少的依赖或者环境条件。

把清单拆成规划、修改、验收三个关卡

第一轮只读代码，输出方案和风险，不生成补丁。确认方向之后，第二轮只做清单要求的最小修改。第三轮执行验收，逐项附上证据。小任务可以合并轮次，但不要省掉验收关卡。

我通常先让 DeepSeek V4 Flash 处理边界清楚的小改动；遇到跨模块设计，再试 Claude Sonnet 5.5。这不是固定的能力排名。拿同一组任务比较首次验收通过率，比根据一次漂亮回答选模型可靠。

通过 Fluxo，我用一个密钥和一个基础地址 https://api.fluxorelay.com 接入 Claude、GPT、Gemini、DeepSeek、Kimi、GLM、Qwen、Grok 等系列，在 Claude Code、Codex、Gemini CLI 或任意 OpenAI SDK 工作流里复用任务清单。切换工具和模型时，仍需检查参数、上下文限制与工具调用差异，不能把统一入口当成行为完全一致。

用每次验收通过的成本衡量节省

只看单价容易算错账。我的记录包含任务版本、模型、输入输出 token、缓存读取与写入 token、重试次数和验收结果。核心指标是这批任务的总费用除以通过验收的任务数；同时记录人工修复时间，避免把便宜但难收拾的补丁算成胜利。

Fluxo 没有月费，按实际 token 用量计费，缓存读取和写入也计入费用。稳定的项目约定放在提示前部，变化的任务放在后部，有助于利用支持的缓存机制，但是否命中、能省多少，要看实际用量记录，不能假设缓存免费。

失败时只修清单缺口，不重发整个任务

验收失败后，我给 Agent 的不是“再试一次”，而是失败命令、相关日志、当前补丁和未通过的条目。要求它先解释偏差，再提交最小修复；两轮仍失败就暂停，检查需求或换模型，避免无限重试。

你可以创建一个 Fluxo 账户，拿同一个小任务做一轮成本对照。邀请他人后，对方付费时你也能获得推荐分成，不过评估工作流时应把它与任务成本分开记账。

最后把有效清单随代码提交。下一次复跑时，沿用相同夹具和验收命令，再记录环境变化。真正可复现的不是模型措辞，而是任何人打开终端，都能判断这次修改到底有没有完成。