14美分跑完AI编程全流程，他拆掉了厂商的锁

主流AI编程工具有个隐蔽的设计陷阱：你按月付费，却只能用它指定的模型。下个月更好的模型出来了，你换不了——不是不想，是整个架构焊死在厂商SDK上。

一位开发者受够了这种绑架。他开源了一个叫Anvil的编程代理，核心就一件事：让不同阶段调用不同模型，本地免费的做苦力，云端聪明的做决策。一次完整的功能开发，云成本14美分。

为什么"一个模型打全场"是错的

现在的AI编程工具，商业模式高度同质化。注册、按人头订阅、拿到一个黑盒模型。厂商替你做了选择，你也失去了选择权。

问题在于，大语言模型的核心特性被这种设计抹杀了：它们是可替换的、可比较的、越来越便宜的。

Claude在深度推理上强，但贵；本地小模型写代码够用，几乎免费；Gemini速度快，适合简单校验。没有单一模型能在所有维度上最优，但现有工具强迫你用一把锤子敲所有钉子。

更深层的问题是技术锁定。工具链绑死厂商SDK，想换模型？要么等厂商更新，要么自己fork代码重写。等下个月Anthropic或OpenAI发新模型，你的工具还是老样子。

Anvil的解法很直接：把流水线拆开，每个阶段按需匹配模型。

一条14美分的流水线长什么样

作者贴出了Anvil的真实运行记录，一个功能请求从澄清到合并请求的全流程：

需求澄清 → Ollama qwen3:14b（本地）~ $0.00
方案规划 → Claude Sonnet 4.6（深度分析）~ $0.05
代码构建 → Ollama qwen3:14b（本地）~ $0.00
测试执行 → Ollama qwen3:14b（本地）~ $0.00
结果校验 → Claude Haiku 4.5（便宜快速）~ $0.01
代码审查 → Claude Sonnet 4.6（判断质量）~ $0.08
提交合并 → Ollama qwen3:14b（本地git操作）~ $0.00

总计：约0.14美元。

这个分配逻辑很清晰：本地模型处理高频率、低认知负荷的环节——写代码、跑测试、git操作。云端大模型只出现在两个关键决策点：规划阶段需要全局视野，审查阶段需要质量判断。

作者的原话：「Premium models only showed up where premium models actually move the quality needle」——贵模型只出现在真能提升质量的地方。

这不是简单的成本优化。它承认了一个被行业忽视的事实：不同认知任务对模型能力的需求曲线完全不同。强行统一，要么浪费算力，要么牺牲质量。

路由规则不是代码，是配置

Anvil的模型选择不靠硬编码，靠一个YAML文件。用户声明三个维度：阶段需要的核心能力（推理/编码）、任务复杂度（S/M/L）、优先级偏好（本地/便宜/高端）。

解析器遍历模型清单，匹配最便宜且满足条件的选项。想换模型？改配置，不动代码。

这种设计把「模型选择」从工程问题变成了策略问题。团队可以基于成本、延迟、合规要求灵活调整，而不必重构工具链。

更重要的是，它把选择权还给了用户。厂商不再替你决定什么是「足够好」的模型，你自己定义质量与成本的平衡点。

八家厂商，零个SDK

Anvil内置了八个提供商的适配器：Claude、OpenAI、Gemini、OpenRouter、OpenCode、Ollama、Gemini CLI、Google ADK。

但关键不在于支持的数量，而在于实现方式：每个适配器都是手写的fetch()调用，没有引入任何官方SDK。

没有@anthropic-ai/sdk，没有openai包，没有LangChain，没有Vercel AI SDK。

作者的理由很技术，也很尖锐：「If a model is dropped tomorrow, your code keeps compiling」——如果明天某个模型下线，你的代码还能编译。

依赖厂商SDK的本质是接受其类型系统、错误处理、重试逻辑、计费方式的全套假设。这些假设会渗入你的架构，最终让你无法脱离特定生态。

Anvil的做法是反向的：统一自己的流式格式，统一错误类型（UpstreamError），统一成本上报。厂商适配器只是薄层翻译，随时可替换。

运行时的容错也很实用。如果某个模型返回429（请求过多），链式执行器会把它标记为当前不可用，自动降级到同级别的下一个选项。同厂商或跨厂商，配置决定。

v0.1.0里有什么

作者刚发布的MVP 2版本包含以下组件，每个都有明确的设计意图：

阶段系统（Stages）

把软件开发拆成原子步骤：clarify（澄清需求）、plan（规划方案）、build（构建代码）、test（执行测试）、validate（验证结果）、review（审查代码）、ship（提交发布）。每个阶段有独立的输入输出契约，可以单独配置模型策略。

这种拆分不是为了炫技，是为了让「哪里该花大钱」变得可观测。你可以精确追踪每个阶段的延迟和成本，优化有数据支撑。

工具注册表（Tool Registry）

阶段可以调用外部工具——文件读写、命令执行、网络请求。工具以声明式方式注册，带类型签名和权限标记。

设计意图是安全与可审计。你知道每个阶段能做什么，不能做什么。这比把shell权限黑盒化给AI要可控得多。

链式执行器（Chain Walker）

驱动整个流水线的引擎。处理模型选择、错误降级、重试、成本累加。核心逻辑是状态机，每个阶段完成会触发下一个，失败则按策略回退。

作者强调这不是工作流编排框架，而是专门为「模型路由」优化的执行层。延迟敏感，失败快速，成本透明。

成本追踪器（Cost Tracker）

实时累加每个阶段的token消耗和估算费用。支持多币种、多提供商的定价模型。数据可导出，可用于团队级别的预算管控。

这个组件的存在本身就在表态：AI编程的成本应该像云服务器一样可预测、可优化，而不是黑盒账单。

为什么这件事值得技术人关注

Anvil的代码量不大，但它戳破了行业的一个默契：厂商希望你相信「模型选择是专业门槛，交给我们就好」。

这个默契让工具链越来越厚，锁定越来越深。你从「用AI写代码」变成了「用某家公司的AI写代码」，区别 subtle 但致命。

作者的做法是基础设施层面的解耦。不反对用商业模型，但反对被单一商业模型绑架。不反对付云费用，但反对为不需要的能力付溢价。

更深一层，它展示了「模型即服务」的另一种可能。不是API调用的简单封装，而是认知任务的智能调度。未来可能有专门做「规划」的模型、专门做「审查」的模型、专门做「安全扫描」的模型——Anvil的架构为这种分化预留了空间。

对于25-40岁的技术从业者，这指向一个务实的判断：你的AI工具链是否应该像数据库选型一样灵活？当Claude 5、GPT-5、Gemini 3相继发布，你是等待厂商更新，还是当天就能切换对比？

开源社区已经给出了技术方案。商业化的障碍从来不是技术，而是习惯——我们已经太习惯「一站式」的便利，忘记了「可替换」的价值。

如果明天你的AI编程工具涨价300%，或者支持的模型突然落后一代，你的迁移成本有多高？这个问题，Anvil用14美金的账单和一份YAML配置，给出了另一种答案。

当模型能力以月为单位迭代，工具链的灵活性会不会成为比功能完备性更重要的选型标准？