💡 前阵子，我 Vibe Coding 光中转站一天就要 50 上下；这两天换完模型、把 Kimi 摊进去，一天 all-in 也就 10 块。 中间我几乎没动一行业务代码，只做了一件事——把主力模型从 Claude Opus 4.8 一路换到了 DeepSeek V4 Flash。 按常理，这该翻车。结果不光没翻，反而更快了，一天能处理的事还更多。

后来复盘，我才回过味来——真正救我的，可能不是「换了个便宜模型」，而是我平时那套工程习惯里能自动兜底的那部分：它在我没察觉时，早就长成了一套给 AI 用的 Harness。但这话先按下，我从头讲。

起因：两条退路同时断了

事情的开头其实挺狼狈。我平时跑 Vibe Coding，手里本来有两条路：一条是包月的 Kimi Allegretto，按周给配额，我通常先把它用满；另一条是一个 API 中转站，配合 GPT、Claude 兜底。

偏偏这俩同时出了岔子：Kimi 这周的配额提前见了底，而那个中转站的费用又一夜翻了三倍多——之前一天也就 50（官方 0.3 倍，汇率 1:1）出头，那几天直接顶上去。两头一挤，肉眼可见地扛不住。

我没工夫纠结，只能赶紧找个又便宜又顶用的替代。但心里也打鼓：便宜模型要是把活儿干砸了，省下的那点钱根本不够擦屁股。

第一天：换上 DeepSeek V4 Pro

我先换了 DeepSeek V4 Pro，做好了「也许得忍它笨一点」的心理准备。

结果出乎意料：那一天我处理了 16 个 PR，明显比之前用 Opus 那阵更快，一天能往前推的事情也更多；按量付费还比中转站省了一截。

回过头想，能这么顺，多半不是 Pro 有多神，而是我这个项目的底子还行——文档、目录约定、代码范式都立着，模型不用猜我想干嘛，照着既有的样子往下写就行。

第二天（今天）：再往下试 V4 Flash

尝到甜头，今天我又往更便宜的 V4 Flash 上探。

这次主要让它干两类活：E2E 测试和问题修复。截至此刻处理了差不多 10 个 PR，效果依旧能打。关键在于——因为验证和单元测试做得比较到位，它即便偶尔写歪，也会被测试当场挡回去，没出什么乱子。

费用呢？比 Pro 那天还低——DeepSeek 按量没几个钱，再把包月的 Kimi 摊进去，今天一天 all-in 也就 10 块上下。

不过有一点得说实话：今天并不是「纯 Flash」。遇到一些我怕它拿不准的需求，我还是先让 V4 Pro 出 Plan（把需求拆开、把方案定下来），再把执行丢给 Flash。这套「Pro 想、Flash 做」的搭配，比单押一个模型稳，也更省。

这是这两天的真实记录：

把两天的账摆在一起

每日费用大致是这么一条线：之前光中转站就 50 上下／天 → 这两天换上 DeepSeek、把 Kimi 摊进去，一天 all-in 也就 10 上下。几天时间，日成本砍到原来的五分之一，活儿不光没拉胯，反而更快、能处理的事更多。

（这里的「10 块」已经把 Kimi Allegretto 包月 199/月摊进去了——折每天 ≈6.6，再加上 DeepSeek 按量那几块凑出来的，不是只挑按量付费报的漂亮数。）

复盘：我那套工程规范，悄悄长成了半套 Harness

老实讲，我不敢把功劳一口咬死在「便宜模型也能打」上。坐下来复盘，我反而后知后觉地发现了一件有点好笑的事——我从没专门为 AI「搭」过什么脚手架，可当我把模型换得越来越笨、越来越便宜，才发现真正接住它的，是两层早就存在、却被我忽略的东西。

第一层，才是真正意义上的 Harness——模型外面那层「驱动机器」。 业内现在把它定义得挺干脆：一个 agent = 模型 + Harness，Harness 就是除模型之外、负责驱动它干活的一切（工具、上下文、验证反馈、护栏、编排）。我这两天真正在吃红利的，其实是三件早就在做的事：

• 自动验证回喂：每次改动必须跑通 lint、类型检查和相关测试，不过就把失败原因塞回去让模型自己改。写错不要紧，被挡回来重写就是了。
• 跨模型路由：我手里不止一个模型——底下还垫着一个包月的 Kimi Allegretto（199/月），平时搭配 GPT、Claude 一起用，通常先把 Kimi 的周配额耗尽，再动用按量付费的部分；拿不准的需求让强模型出方案，执行再丢给便宜模型。这套「谁便宜谁先上、谁靠谱谁拍板」的调度，本身就是 Harness 的活儿。
• 护栏：危险操作拦一道、留好回滚，换个更笨的模型也不至于闯大祸。

这三样，本来是给「人」和「省钱」定的规矩，却恰好接住了模型掉下来的那部分能力——它们才是真正让我敢把模型一路降级的东西。

第二层，是代码库本身的底子——模型干活的那片「地形」。 严格说它不算 Harness，但它决定了 Harness 好不好使：扎实的文档、目录约定、代码范式，让模型一进来就知道规矩、不用猜。而这片地形，很可能正是早期 Opus 协助我一点点打下来的——那阵子是它陪我把架构立稳的；如今 Flash 进来，更多是「比着葫芦画瓢」，照着既有模式填，而不是从零做架构决策。

所以更准确的说法是：不是「便宜模型也能打」，而是「一套够用的 Harness，加上一片打好的地形，合起来把模型变成了一个可以随时替换的零件」。

几个我不敢打包票的地方

把话说满之前，得先承认这次「实验」并不严谨：

• 只有两天、一个项目。 样本小到不能再小，换个陌生代码库、换个阶段，结论完全可能反过来。
• 任务偏「顺手活」。 这两天大多是常规开发、E2E 和问题修复，本来就吃既有模式；真要从零做架构、啃硬骨头，便宜模型大概率还是会露怯。
• 账单的下降，不全是模型的功劳。 从约 50 到约 10 里，既有「模型本身更便宜」的部分，也有「我顺手绕开了那个突然涨价的中转站」的部分。省钱是真的，但别把它整个算成「便宜模型的胜利」。

所以更准确的说法是：够扎实的底子 + 强模型早期打的地基 + 合适的任务类型，三者合起来，才把「换便宜模型」的代价压到了我能接受的范围。

几条体会，也有差点栽的地方

不谈虚的，就说我这两天最实在的几点：

1. 真正给我底气的是验证闭环，不是模型。 要不是 lint、类型检查和测试在那兜着，我根本不敢把模型往便宜了换——这一步要是缺了，换模型基本等于裸奔。
2. 别指望便宜模型「全包」。 今天我也是被自己提醒着才学乖：拿不准的需求先让强模型出方案，再交给便宜模型执行，别一上来就 all in。
3. 文档和约定要趁早，别等到想省钱才想起。 底子越清楚，越便宜的模型越够用；临时抱佛脚是补不回来的。
4. 把模型做成可切换的配置。 这样下次再冒出更便宜的，几分钟就能再省一笔，而不是回头改一堆代码。

写在最后

这次从 Opus 换到 Flash，省下的钱很实在；但更让我在意的，是一个越来越强的猜测：

在 Agent 编码的时代，决定体验的，可能早已不只是你用了哪个模型，而是你把模型之外那层底子做得有多扎实。

模型只会越来越便宜、越来越快。结论我还不敢拍死，但至少这两天我信了一件事：你认真做的每一条工程规范，都在悄悄攒成一套 Harness——等哪天你想换个更便宜的模型，它早就替你把路铺好了。

（本文基于 2026 年 6 月 29 日至 30 日两天的真实使用记录，结论可能随后续观察修正。）