同一个 bug，两段 Prompt 差了 18 倍成本——这件事把 AI 编程的账彻底算清楚了

同一个 bug，两段 Prompt 差了 18 倍成本——这件事把 AI 编程的账彻底算清楚了

你有没有过这种经历：给 AI 编程工具发了同样的 bug 描述，只是措辞稍微不同，结果一个方案 5 分钟搞定，另一个方案折腾了半小时还没收尾。

这不是玄学。

一篇刚发在 arXiv 上的 preregistered benchmark 给出了硬数据：在任务、模型、验收标准完全一致的前提下，仅改 prompt 措辞，就能让同一个 coding agent 的推理 token 暴涨 2.4–7.4 倍，甚至把总成本拉到 18 倍——而成功率纹丝不动。

这件事真正该被看见的，不是“prompt 很重要”，而是：对于 coding agent，prompt 的本质不是文字优化，是工作设计。

一、同一段代码，两套成本

PointFive 团队的研究跑了一个很干净的对照实验：

• 24 个确定性编码任务
• 6 个 reasoning 模型 + Claude Sonnet 5 复现
• 2 个真实 harness：Claude Code 和 PI.DEV
• 4,644 次有效运行

结果很清楚：

“多方案对比”是最贵的措辞。

让 agent “develop and compare several approaches” 这种说法，会让模型在内部生成 3 条 elaborated-but-discarded 的分支，最后只实现 1 条。推理 token 直接涨了 2.4–7.4 倍，但成功率没变化。

“确保万无一失”是另一种昂贵。

要求“maximum certainty” 会让 agent 进入 redundant verification loop：重复跑测试、重复读文件、反复确认。最高成本的跑法比 clean run 贵 18 倍，工具调用多 2.5 倍，耗时多 3 倍，成功率依旧原地踏步。

更关键的是，这两种浪费的“成本载体”不一样：

• 多方案浪费 → token-borne，主要在模型推理里烧钱
• 确定性浪费 → tool-borne，主要在工具调用和延迟里烧钱

这意味着：换 harness、换模型、甚至换云厂商，都可能改变这笔账的比重，但只要你 prompt 里写了“多方案对比”，它就会在某个地方把钱烧掉。

二、Harness 差距比模型差距还大

另一个让很多人意外的发现：harness 设计对成本的影响，和模型大小的影响是一个量级的。

HuggingFace CEO 转发的一项 10-harness 对比研究显示：

• 同一模型 GLM-5.2，pass@1 从 23% 到 52%，完全取决于 harness
• Codex 在 GLM-5.2 上排第 2，换到 Gemma-4 直接掉到第 9
• 模型无关的 harness（crush、opencode、pi）在小模型上反而爬升

Claude Code 和 PI.DEV 的对比也印证了这一点：同样的模型+任务+prompt，Claude Code 的静态前缀大 12–15 倍，每成功一次成本高出 5–30 倍。

这不是说 Claude Code 不好，而是说：harness 是一个独立变量，会和 prompt 相乘影响最终账单。

你花大力气调 prompt，如果 harness 的静态前缀已经占了 90% 上下文，省下来的钱其实很有限。

三、工程上该怎么把这笔账算清楚

基于这些研究，有三件事你现在就可以做：

1. 把 prompt 当 work design，不当文字压缩

研究里最有效的模板叫“bounded-efficiency wording”：明确范围、明确验收标准、明确停止条件。它不追求最短，但能把 agent 导向“最小足够改动 + 运行相关测试 + 停止”。

对比一下：

• ❌ “develop several approaches and compare trade-offs”
• ✅ “inspect only what the evidence requires, make the smallest sufficient change, run the relevant tests, and stop”

前者让 agent 进入锦标赛模式，后者让 agent 进入 bounded execution。

2. 给 harness 做“成本隔离”

把 harness 当基础设施来管：

• 静态前缀（system prompt、tool schemas）单独审计，和业务 prompt 解耦
• 工具权限按最小特权配置，read-only agent 不要给 write 权限
• 高成本工具调用（网络请求、重型测试）加显式审批，不要默认放行

Anthropic 的 Claude Code 安全文档里已经把这几层说得很清楚：permission engine、tool registry、execution engine、security auditor，四层防御缺一不可。

3. 把“成本”变成可观测指标

很多团队只监控成功率，不监控 cost-per-success。研究里明确说：

Agent evaluations should measure success and end-to-end cost while controlling the system variables.

具体做法：

• 记录每次运行的 billed tokens、tool calls、wall-clock
• 按 harness/model/prompt 分组对比
• 把“cost per successful task”当成核心指标，和 latency、error rate 一起进 dashboard

四、结论

Prompt engineering for coding agents 的核心矛盾是：同样的任务目标，不同的 prompt 会诱导 agent 做完全不同 kind 和 amount 的工作。

这不是“写得好不好”的问题，是“让 agent 做什么工作”的问题。

一段 prompt 里的几个词——“compare several approaches”“ensure maximum certainty”——就会把 agent 拉进分支锦标赛或验证死循环，账单翻几十倍，结果不变。

所以，下次你写 coding agent prompt 的时候，不要只问“这句话通顺吗”。要问：这句话会让 agent 多做哪些工作？这些工作有回报吗？

如果你把 prompt 当工作设计来写，把 harness 当基础设施来管，把 cost-per-success 当核心指标来追，那 AI 编程的成本账才算真正被算清楚了。

参考

• arXiv 2608.01347: Prompt-Induced Waste in Coding Agents
• The Agent Times: Harness Design Outweighs Model Size on Benchmarks
• Anthropic: Claude Code Security Documentation
• PointFive: Preregistered benchmark, 4,644 runs, 24 tasks