WordPress 插件团队的 AI 辅助开发经济学
一支交付 WordPress 网站统计插件的小团队的真实成本核算。优化前的 Anthropic 账单是什么样、现在又是什么样、以及复合节省到底来自哪里。
第 1 个月里我们诚实回答不了的一个问题
把 Claude Code 当作日常协作者来交付一款 WordPress 插件，到底要花多少钱？
构建 Statnive 的第一个月，我们答不上来。账单看得到。但驱动账单的因素是什么，看不清楚。有些日子是 $3，有些日子是 $11，方差与当天交付的代码量没有明显相关性。
四个月后，我们对全貌有了更清晰的认识。本文是这份成本核算：钱花在哪里、复合起来大约带来 2–3 倍 节省的四个杠杆，以及那个比任何单项优化都重要的数字。
要点：在工程产出不变的前提下，每日支出从 约 $6/天降到 $2–3/天。这些节省不是相加的，而是相乘的。
AI 支出实际花在哪里
Anthropic 针对 Claude Code 相关模型的定价，截至 2026 年初：
| 模型 | 输入 / MTok | 输出 / MTok | 适用场景 |
|---|---|---|---|
| Haiku 4.5 | $1 | $5 | 只读探索、验证、常规修复 |
| Sonnet 4.6 | $3 | $15 | 标准开发工作 |
| Opus 4.7 | $5 | $25 | 复杂架构、深度推理 |
朴素地看，挑一个模型，按它的费率乘以 token 消耗付钱。但真实情况要更细，下文四个优化杠杆中有三个就是利用了这一点。
作为参考，每类操作的典型 token 预算如下：
| 操作类型 | 典型 tokens | 实际耗时 |
|---|---|---|
| 简单修复（Haiku） | 2K–5K | 1–2 分钟 |
| 标准功能（Sonnet） | 10K–20K | 5–10 分钟 |
| 复杂重构（Sonnet + 扩展思考） | 30K–50K | 15–25 分钟 |
| 架构评审（Opus） | 50K–100K | 20–40 分钟 |
把这些操作乘以一个工作日，就是单个工程师 ~$6/天 的来源。再乘以一年，优化这件事就值得认真对待了。
杠杆 1 — 提示缓存（稳定前缀约 90%）
Claude Code 会自动缓存每次会话的稳定前缀：系统提示、内置工具定义、技能元数据，以及根目录的 CLAUDE.md。缓存读取的费用是 基础价格的 0.1 倍 —— 在被缓存的部分上 降低 90%。
大多数环境下，稳定前缀超过 50K tokens。没有缓存，每一轮对话都要重新计费这 50K tokens；有了缓存，第一次之后每一轮只按 10% 的费用读取。
两条实操规则：
- 内容排序：静态在前，动态在后。 缓存命中需要前缀完全匹配。如果会话开头放了任何动态内容，就会击穿缓存，被迫整段重读。我们把根
CLAUDE.md和技能元数据放最前，把动态上下文（变更过的文件、当前分支状态）放最后。 - 不要让会变的东西污染前缀。 这就是保持
CLAUDE.md精简的真正原因 —— 您删掉的每一个字节，都是文件变更时不需要重新缓存的字节，而且较短的缓存前缀在过期后刷新成本更低。
缓存是单项最大的成本杠杆，而且大部分是自动的。功夫在于不破坏它。
杠杆 2 — 模型路由（被路由的部分 3 倍）
Haiku 4.5 每 token 比 Sonnet 便宜 3 倍。在只读和验证类任务上，能力差异很小。Anthropic 建议 约 80% 的常规任务默认使用 Haiku。
实际中我们的路由如下：
| 任务 | 模型 | 原因 |
|---|---|---|
| 代码探索（“找出所有调用 X 的地方”） | Haiku（子代理） | 只读、确定性 |
| 测试失败分诊 | Haiku（子代理） | 模式匹配、判断量小 |
| 标准功能实现 | Sonnet（主会话） | 生产工作的默认 |
| 架构决策、模式设计 | Opus（主会话，偶尔） | 难推理时溢价值得 |
| 代码评审 | Haiku（fork 子代理） | 读密集，返回摘要 |
路由与 子代理 配合时威力最大，因为子代理有独立于主会话的模型设置。我们可以让主对话跑在 Sonnet 上，让一个 fork 子代理在 Haiku 上做读密集型工作。模型路由发生在技能边界，而不是会话边界。
杠杆 3 — 子代理隔离（主上下文减少约 37%）
子代理（也叫 fork 代理）有自己独立的 200K-token 上下文窗口。在子代理内部完成的工作不会污染主对话，只有摘要会返回。
Anthropic 文档显示，子代理可以从超过 10,000 tokens 的内部工作中 只返回约 500–1,000 tokens —— 在复杂任务上大致相当于 主上下文减少 37%。
两个成本效应：
- 直接的 token 节省。 一次读了 30 个文件后给出结论的代码评审，会在隔离环境内消耗它的 tokens。如果没有隔离，那 30 次文件读取就会留在主上下文里，每一轮后续对话都被重新计费（缓存生效的部分另算）。
- 由质量驱动的 token 节省。 长上下文会降低检索质量 —— 研究记录到，当上下文被填满时，性能下降 15–47%，即”中段迷失”问题。质量下降意味着更多重试、更多重读、更多 tokens。保持主上下文整洁能避免这一整类浪费。
权衡也是真实的：代理团队的总 token 用量大约是标准会话的 7 倍，因为每个代理都会启动一个新实例并自带初始化开销。我们接受这一点，因为我们优化的不是总 token，而是主上下文的整洁度和整体吞吐。而 Haiku 上的子代理无论如何都很便宜。
杠杆 4 — MCP 工具延迟加载（约 85%）
我们在 关于 MCP 工具搜索的那篇文章 里做了详细介绍。简短版：
二十四个 MCP 连接器在不做延迟加载时，每次会话约消耗 135,000 tokens 的基线开销。Tool Search 把它降到了 约 3,000 tokens 的索引，完整 schema 按需加载。降低 85%，准确率反而 提高了，会话也不再憋屈。
成本效应：每一个基线开销 token，都是每次会话缓存前缀里的一部分。砍掉 13 万 tokens 的开销，就是砍掉 13 万 × 单 token 价格的 0.1 倍 × 每次会话的缓存读取。即便只按 10% 的费用算，对一名持续工作的工程师而言，也是每月数百美元。
复合乘数
下面是头条数字捕捉不到的部分。这四个杠杆是 相乘的，不是相加的。
设想一个基线会话在 5 分钟任务上烧掉 $0.30。逐个套用每个杠杆：
| 杠杆 | 效果 | 累计成本 |
|---|---|---|
| 基线 | — | $0.30 |
| 提示缓存（稳定前缀降低 90%） | 稳定前缀约占会话 tokens 的 70% | ~$0.12 |
| 模型路由（Haiku 适用部分降至 1/3） | 约 50% 的工作适用 Haiku | ~$0.07 |
| 子代理隔离（主上下文减少 37%） | 主上下文缩小，重新计费的部分变少 | ~$0.05 |
| MCP 工具延迟加载（工具 schema 开销降低 85%） | schema 不再进入基线 | ~$0.04 |
每一步都不显眼，组合起来却很惊人。具体百分比并不重要 —— 结构性的洞见是：token 成本优化之所以能复合相乘，是因为它们作用在账单中互相重叠的部分。修好其中四项，就能改变量级。
这就是为什么在交付内容不变的前提下，我们的每日支出从 约 $6 降到了 $2–3。同样的代码、同样的测试、同样的发布节奏。只是默认配置不同了。
我们现在把钱花在什么地方
优化之后，Statnive 一个典型的工程日：
| 活动 | 大约成本 |
|---|---|
| 早晨在一个开放 PR 上做代码评审（fork、Haiku） | ~$0.20 |
| 在 React 仪表盘里做 2 个标准功能（Sonnet，开启缓存） | ~$0.80 |
1 次发布闸门（statnive-release 技能） | ~$0.30 |
| 文档/博客文章草稿 | ~$0.40 |
| 杂项探索与问答 | ~$0.50 |
| 合计 | ~$2.20 |
整个团队，每月 Anthropic 账单远低于一份普通 SaaS 订阅的价格。作为对照：这笔账单资助了一位 AI 协作者，帮助交付一款被真实业务使用的 WordPress 插件，每次发布都要通过 248 项测试和 22 道发布闸门。
扩展思考：把关键词与任务匹配
一个值得了解的定价细节：Claude 的扩展思考模式按关键词分配预算：
| 关键词 | 思考预算 |
|---|---|
think | 5K–10K tokens |
think hard | 20K–50K tokens |
think harder | 50K–100K tokens |
ultrathink | 100K–128K tokens（最大值） |
这些 tokens 计入输入。够用就用最便宜的那个。常规工作我们默认不加思考修饰，非平凡的设计决策用 think hard，只有真正的架构问题、深度推理能产生回报时才用 ultrathink。在改一个错别字时去用 ultrathink，相当于为了打开一个网页而开 50 个标签页的 Chrome 窗口。
会话卫生与杠杆同样重要
一个反直觉的发现：每日成本中最大的方差来自会话长度，而不是技能或工具配置。
不重置上下文的长时段自治会话会逐步降低质量。“中段迷失”效应 —— 上下文填满时性能下降 15–47% —— 直接转化为更多重试、更多重读、更多被浪费的 tokens。跑过 80% 上下文水位的会话，做相同的工作，成本是较短会话的 2–3 倍。
两条卫生规则我们已经固化进工作流：
- 不相关任务之间用
/clear。 从前端 bug 切换到发布闸门改动，是两段不同的对话。清理上下文不花钱，能避免污染。 - 在 60–70% 上下文水位主动
/compact，而不是等到 95% 的自动压缩阈值。 在临界点的自动压缩是一种慌乱操作，会丢失信息。主动压缩保留重要状态、清掉噪声。
把状态持久化到文件、而不是对话历史里，可以让这两条规则都安全 —— 重要的东西都在磁盘上，clear 不会丢。
我们没去优化的部分
- 我们还没按技能维度量化成本。 通过 Anthropic 计费可以看到每日总额，本地
/cost和/stats命令可以做点抽查，但没有按技能归属的口径。ccusage（读取 Claude 本地 JSONL 会话文件）和 Claude-Code-Usage-Monitor 之类的工具是存在的，我们还没集成。 - 子代理比例可能仍然偏低。 我们在评审和审计上积极使用 fork 模式，但相当比例的标准工作其实也可以 fork 出去，进一步保持主上下文整洁。我们没做严格的测量。
- 我们没做正式的 A/B 对比。 $6 → $2–3 这个数字来自优化稳定后与稳定前的对比，背后没有受控实验。您的情况会不一样。
再砍一半成本要付出什么
诚实的答案：大概不值得。
可以更激进地用 Haiku，可以把更多工作打包进子代理，可以在技能里写更严苛的输出预算契约。每一项也许还能再省 10–20%。
多招一名工程师的成本，是我们整个 Anthropic 支出的好几倍。把工程时间花在优化 AI 成本上、过了某个点之后，就是把工程时间从 真正的产品 上挪走。会话憋屈或账单令人意外时我们才优化，否则就交付。
试用 Statnive
注重隐私的 WordPress 网站统计插件，由一支既看重成本核算、也看重测试覆盖的团队打造。从 WordPress.org 免费安装 Statnive —— 数据留在您自己的服务器上，我们的支出留在一条预算线上，并且 整个工程实践都是开源的。