第 6 部分：控制成本

关于 AI 开发，通常的问题是"我们能多快交付？"更好的问题是"拥有它的成本是多少？"速度掩盖了真实的经济逻辑。诚实的衡量指标是总体拥有成本（TCO），而在 AI 工作流中，这由一件事主导：Token 经济。

快速行动背后的隐性债务

随意的提示词方式看起来几乎免费——一个订阅加上一些漫不经心的提示，前期成本近乎为零。账单稍后才到，而且会复利滚雪球：

• Token 消耗。 把庞大的非结构化文件塞进上下文窗口，再让模型修复它自己未经验证的错误，会产生一个代价高昂的重试循环，首次成功率极低。每次失败的尝试都是白白烧掉的 Token。
• 维护税。 非结构化的生成代码缺乏一致性。六个月后，一名工程师要花好几天逆向工程没人设计过的"意大利面条"代码。
• 安全修复成本。 没有评估套件，快速的代码生成就变成了快速的漏洞生成。在生产中修复一个缺陷的成本，远高于在设计阶段发现它。

结构化方法颠覆了这一点：你在模式、测试和上下文上前期投入，而后每个功能的交付和维护边际成本大幅下降。构建成本更高，拥有成本大幅更低。

杠杆一：首次成功率

最便宜的 Token 是你不用在重试上花费的那个。精炼、高信噪比的规则文件（第 1 部分）和管理良好的上下文（第 2 部分）能提高智能体的首次成功率，从而直接削减那些烧钱的试错循环。上下文工程不只是质量实践——它也是成本控制实践。同一份精简的 CLAUDE.md 既能改善输出，也能降低支出。

把整个 100,000 Token 的代码库塞进每个提示词，在规模上是财务上不可行的。检索相关内容；为你使用的内容付费。

杠杆二：按任务路由

在随意的工作流中，你用一个大型前沿模型做所有事情——为修复一个错别字或生成样板测试支付高昂费用。一个经过设计的工作流按任务复杂度路由：

• 架构、硬性设计 → 前沿模型——需要最大推理能力
• 初始复杂实现 → 前沿模型——高风险、模糊不清
• 测试生成 → 小型/廉价模型——确定性、规格明确
• 代码审查（第一轮） → 小型/廉价模型——模式匹配
• CI / 监控检查 → 小型/廉价模型——重复、范围窄

一个简单的路由配置让这个逻辑变得清晰：

routing:
  default: small-fast
  rules:
    - match: ["architecture", "design", "migration plan"]
      model: frontier
    - match: ["write tests", "lint", "review diff", "ci check"]
      model: small-fast
    - match: ["implement feature"]
      model: frontier

编排一个多模型组合，让你在关键处维持输出质量，同时降低大量确定性工作的成本。

杠杆三：动态上下文和技能

回到第 2 部分的内容。静态加载所有内容意味着每次调用都要为其付费。将特定任务的知识推入按需加载的技能中——通过按需调用而不是把所有内容都烘焙进提示词来使用工具——能让每次请求的有效载荷保持精小。在规模上，"始终全量加载"与"只加载所需"之间的差异，是可行成本结构与不可行成本结构之间的差异。

一个直觉计算

假设在你投入规则文件和几个技能之后，首次成功率从 40% 提升到 80%。原来需要约 2.5 次尝试的任务，现在只需约 1.25 次。同样的输出，Token 减少了一半——这还是在你将任何任务路由到更便宜的模型之前。再叠加路由策略（廉价模型处理测试生成和审查，这可能占你调用量的一半），运营成本曲线就会大幅弯折。

搭建你自己的工作流

• 停止只测量速度；开始追踪每个交付功能的 Token 支出。
• 专门收紧你的规则文件，以提高首次成功率，消灭重试循环。
• 设置模型路由：廉价模型用于测试生成、审查和 CI；前沿模型用于架构和高难度实现。
• 将特定任务的上下文移入按需技能，避免每次调用都为其付费。
• 比较改进前后的每功能成本——前期投入应该体现为更低的持续账单。