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 预算：
| 操作类型 | 典型 token | 实际耗时 |
|---|---|---|
| 简单修复（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+ token。如果没有缓存，每一轮都要为这 50K token 重复付费。有了缓存，第一轮之后的每一轮都按 10% 的成本读取它们。
两条实用规则：
- 内容排序遵循「静态在前、动态在后」。 缓存命中要求前缀完全匹配。任何在对话开头出现的动态内容都会让缓存失效，强制完整重读。我们把根
CLAUDE.md和技能元数据放在最前面，把动态上下文（变更文件、当前分支状态）放在最后。 - 不要让前缀里夹带每次会话都会变的内容。 这才是让
CLAUDE.md保持精简的真正理由 — 您每删除一个字节，就少一个字节在文件变更时需要重新缓存，而较短的缓存前缀在过期后刷新成本也更低。
缓存是最大的单一成本杠杆，而且大部分是自动的。工作在于不要把它弄坏。
杠杆 2 — 模型路由（被路由部分降低 3×）
Haiku 4.5 每 token 的成本比 Sonnet 低 3×。在只读和验证类任务上，能力差异极小。Anthropic 建议 约 80% 的常规任务默认使用 Haiku。
实践中，我们的路由如下：
| 任务 | 模型 | 原因 |
|---|---|---|
| 代码探索（「找出 X 被调用的所有位置」） | Haiku（subagent） | 只读、确定性 |
| 测试失败分诊 | Haiku（subagent） | 模式匹配，判断要求低 |
| 标准功能实现 | Sonnet（主会话） | 高效工作的默认选项 |
| 架构决策、Schema 设计 | Opus（主会话，偶尔使用） | 难推理任务值得这份溢价 |
| 代码评审一遍 | Haiku（fork subagent） | 重读取，返回摘要 |
模型路由在与 subagent 配合时威力最大，因为 subagent 拥有独立于主会话的模型设置。我们可以让主会话跑在 Sonnet 上，同时让一个 fork subagent 用 Haiku 完成重读取的工作。模型路由发生在技能边界，而不是对话边界。
杠杆 3 — Subagent 隔离（主上下文减少约 37%）
Subagent（也叫 fork agent）拥有自己 200K token 的上下文窗口。在 subagent 内完成的工作不会污染主对话。只有摘要会返回。
Anthropic 记录的 subagent 表现是 从 10,000+ token 的内部工作中返回约 500–1,000 token — 在复杂任务上对主上下文 大约减少 37%。
两种成本影响：
- 直接的 token 节省。 一次读取 30 个文件并返回结论的代码评审会在隔离环境中消耗 token。如果不隔离，这 30 次文件读取就会留在主上下文中，在之后的每一轮都被重复计费（除了缓存命中的部分）。
- 质量驱动的 token 节省。 长上下文会降低检索质量 — 研究表明性能下降 15–47%，这就是「lost in the middle」问题。质量下降意味着更多重试、更多重读、更多 token。保持主上下文清洁可以避免这一整类浪费。
权衡也是真实的：与标准会话相比，agent 团队总 token 消耗大约 多 7×，因为每个 agent 都会产生一个新实例及其设置开销。我们接受这一点，因为我们优化的不是总 token — 我们优化的是主上下文的清洁度和总体吞吐量。而且无论如何，跑在 Haiku 上的 subagent 都很便宜。
杠杆 4 — MCP 工具延迟加载（约 85%）
我们在 MCP Tool Search 那篇文章中详细讲过。简短版本：
24 个 MCP 连接器在没有延迟加载时，每个会话大约消耗 135,000 token 的基线开销。Tool Search 把它降到了仅约 3,000 token 的索引，完整 schema 按需加载。减少 85%，准确率反而上升，会话不再让人感觉憋屈。
成本影响：每一个基线开销 token 都属于每个会话都被缓存的前缀。砍掉 13 万 token 的开销，相当于每个会话都减少 13 万 × 0.1× × 每次缓存读取的费用。即使按 10% 的成本算，对于一个工作中的工程师来说，每月也是几百美元。
复利倍增
下面是头条数字没法体现的部分。这四个杠杆是 乘法，不是加法。
想象一个基线会话在 5 分钟的任务上消耗 $0.30。逐一应用每个杠杆：
| 杠杆 | 效果 | 累计成本 |
|---|---|---|
| 基线 | — | $0.30 |
| 提示缓存（稳定前缀 90%） | 稳定前缀约占会话 token 的 70% | 约 $0.12 |
| 模型路由（Haiku 适用部分降低 3×） | 约 50% 的工作适合 Haiku | 约 $0.07 |
| Subagent 隔离（主上下文减少 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 插件，每次发布都通过 141 项测试和 31 项合规检查。
扩展思考：让关键词与任务匹配
一个值得知道的定价小细节：Claude 的扩展思考模式有按关键词触发的预算：
| 关键词 | 思考预算 |
|---|---|
think | 5K–10K token |
think hard | 20K–50K token |
think harder | 50K–100K token |
ultrathink | 100K–128K token（最大） |
这些 token 计入输入。请用最便宜、又能完成任务的那一个。我们对常规工作不加思考修饰符，对非平凡的设计决策用 think hard，仅在真正涉及深度推理才能赚回成本的架构问题上才使用 ultrathink。在改一个错别字时动用 ultrathink，相当于在 AI 开发界开 50 个 Chrome 标签页只为读一篇网页。
会话卫生为我们节省的，与杠杆相当
一个反直觉的发现：我们日常成本的最大波动来源是会话长度，而不是技能或工具配置。
没有上下文重置的长时间自主会话，质量会逐步下降。「lost in the middle」效应 — 上下文充满时性能下降 15–47% — 会直接转化为更多重试、更多重读和更多浪费的 token。跑过 80% 上下文的会话，做同样的工作通常要花 2–3× 的成本。
现在我们工作中已经固化的两条卫生规则：
- 在不相关任务之间使用
/clear。 从前端 bug 切到发布门禁更改是两段不同的对话。清空上下文不花钱，但能防止污染。 - 在 60–70% 上下文时主动
/compact，而不是等到自动压缩的 95% 阈值。 在极限处的自动压缩是一种慌乱操作，会丢失信息。主动压缩可以保留重要状态并清除噪音。
把状态持久化到文件而非对话历史，可以让这两条规则都很安全 — 重要内容都写在磁盘上，clear 不会丢失它。
我们没有优化的部分
- 我们还没有按技能测量成本。 我们可以通过 Anthropic 的账单看到每日总额，并使用本地的
/cost和/stats命令做抽查，但我们没有按技能归因。诸如ccusage（读取 Claude 本地 JSONL 会话文件）和 Claude-Code-Usage-Monitor 之类的工具是存在的，但我们还没有集成。 - 我们的 subagent 比例可能太低。 我们在评审和审计中积极使用 fork 模式，但有相当一部分标准工作其实可以 fork 出去以保持主上下文清洁。我们没有严格度量过。
- 我们不做正式的 A/B 比较。 $6 → $2–3 这个数字来自我们对优化稳定前后支出的对比。这背后没有受控实验。您的情况会不一样。
再砍一半要付出什么
诚实地说：可能没什么值得做的事。
我们可以更激进地用 Haiku。我们可以把更多工作打包进 subagent。我们可以在技能里写更激进的输出预算合约。每一项可能再多省 10–20%。
多招一个工程师的成本是我们整个 Anthropic 支出的好几倍。把工程师工时花在过度优化 AI 成本上，就是没花在交付实际产品上的工时。我们只在会话开始憋屈或账单意外飙升时才优化。其他时候，我们就专心交付。
试试 Statnive
由一个把成本核算和测试覆盖看得同样重要的团队打造的隐私优先 WordPress 分析。从 WordPress.org 免费安装 Statnive — 您的数据留在您的服务器上，我们的支出留在单独一行预算上，整个工程实践都是开源的。