野生码农
Kimi Code 的周额度快到期了,原计划等额度重置再派的 P1 编码单,能不能当场用另一个免费模型干掉?——这是本文实测的起点。结论先放这:干完了,断续约 4.4 小时,无一次全量返工,但全口径 token 账和你想的不一样。
场景:周额度告急,把 P1 丢给免费模型
2026-10-11 晚,我问跑在 OpenCode 里的调度岗(模型换成小米 MIMO V2.6 Flash,下文称"军师"):
「你说我现在这个 IPMS 系统还有个什么 P1 的任务没做?因为 Kimi Code 的额度周额度已经快到期了。你看看我们 OpenCode 里面,这个活能不能干?用 MIMO v2.6 Flash 版本。能不能干这个活啊?」
军师没有直接拍胸脯,先查了台账、交接文档,摸了代码规模,然后给出的答复是:这个 P1 = 终审台改造(自研内容生产系统 IPMS 的人机交接台:AI 分析、建议采纳、段落快改、标题 10 选 1、摘要/封面可编辑),范围 A 六项 + 范围 B 四项,并列出 4 件待拍板事项。
我当场拍板四项,其中最关键的一条改变了整个任务的执行形态:
「我们在 OpenCode 的里面是没有这个无头派单的模式的,我们不能去派 Kimi Code 去干活。全部由 OpenCode 里面进行后续的开发。」
翻译成工程语言:没有 kimi 无头派单通道,六张编码卡全部由 OpenCode 会话内自研自测,产线跑稿用 kimi 会话内嵌子进程。原定"10-13 额度重置后派 03 后端 + 04 测试"的双岗流水线,改成免费模型一岗闭环。当晚 22:41 拍板落档,开发开始。
过程:4.4 小时断续,六卡连收
活跃时间从痕迹聚合(git 提交、任务运行、产出文件 mtime,相邻间隔 ≤20 分钟算同一段):
| 时段 | 时长 | 在干什么 |
|---|---|---|
| 10-11 22:41→22:56 | 15min | 拍板落档 + P1-F 收口 |
| 10-11 23:28→23:57 | 30min | P1-E、A1、A2 三卡连收 |
| 10-12 00:19→01:01 | 42min | A4、A3 收口 + 首个写稿任务实跑 |
| 10-12 10:17→10:50 | 33min | AI 分析实测(203s)→ 标题解析首修 |
| 10-12 13:29→14:06 | 12min | 组包/写稿产线实跑 |
| 10-12 19:11→19:47 | 36min | 产线跑稿 + 标题解析二修 |
| 10-12 20:39→22:47 | 128min | 提速方案(K3 会话)+ 落地 + 收尾修 |
| 合计 | ≈263min ≈ 4.4h | 日历跨度约 40 小时,其余是空档 |
交付物(全部带回归测试):
- P1-F:meta 下游契约适配(快捷复制取写手主推,兼容旧综合首选);
- P1-E:外部稿导入通道 + 快车道头尾模板秒级组包(零 LLM 拼装);
- P1-A1/A2:终审页 AI 分析后端通道 + 前端卡片(建单门槛、建议采纳/忽略持久化);
- P1-A4:段落级敏捷快改(预览/回写双端点,三 mode);
- P1-A3:终审定稿标题 10 选 1 + 摘要/封面可编辑(点选持久化 + 按节回写 + 资产哈希刷新);
- 产线侧:团队 #47~#49 母稿与组包连跑,AI 分析提速 203s→46s(末次实测;提交记录里的首次实跑是 53s,见 c5fad76)。
测试从 161 用例涨到 197,全绿 exit 0 常态化——每张卡、每笔修复都带回归用例,这是"敢用免费模型"的底气来源:验收不靠感觉,靠机器判定。
关键修复:一个根因连修 4 棒
全程无一次全量返工(唯一返工级问题按我指示单点修:"就单独修改一下,不返工了"),但有一个缺陷根因反复冒头:
| 缺陷根 | 棒次 | 证据 |
|---|---|---|
| meta 标题格式不健壮(#44/46 → #47 → #48 → #49 四种格式陆续翻出) | 4 | 941a029 / 447d45f / df4948d(部分)/ 7d52abc |
| 复制标题带理由段、不读终审定稿 | 2 | df4948d / 1890071 |
| 排版前言=流水账(GEO 答案前置违背,我定性"大问题") | 2(单点修 + 管线根治) | 6cfcea7 / 00e1741 |
| AI 分析完成事件标签错 | 1 | c5fad76 内顺带修 |
教训很直白:首修时没拿全量样本(44/46/47/48)回放,才连吃 4 棒。第一棒就该把四种格式全部固化成回归用例——这是免费模型(以及任何 AI 编码)最该配的保险:格式兼容类修复,首修即全量回放。
提速是另一个亮点。我在 kimi K3 会话里拍的方向:
「把提示词写精准,要求写精准……直接发给 LLM 模型。模型不要去思考了,就直接回结果,这样效率肯定是最高的……把 K3 的思考改成 low。」
落地后单次 AI 分析 203s→46s,单次 token 12.1 万→3.7 万——确定性任务上,提示词纪律比模型智商更值钱。
真相:全口径 token 账
这是全文最想给你的东西。"token 消耗"这个词至少有三个口径,差 14 倍:
| 口径 | 数值 | 说明 |
|---|---|---|
| IPMS 落库产线(cost_record 11 笔) | 581 万 | 只算写稿/组包/AI 分析子进程 |
| kimi 侧 P1 全口径(产线+探针+手工会话) | 2,705 万 | 含我全程手修的 K3 会话 2,101 万 |
| 两通道 P1 全口径(截至 10-13 00:00) | ≈7,233 万 | kimi 2,705 万 + MIMO 调度侧 4,528 万 |
MIMO 调度侧 4,528 万的构成(实测 opencode.db 消息级,431 条):
| 项 | 数值 | 占比 |
|---|---|---|
| 非缓存输入 | 214.6 万 | 4.7% |
| 缓存读 | 4,276.8 万 | 94.5% |
| reasoning | 23.3 万 | 0.5% |
| 输出 | 13.3 万 | 0.3% |
94.5% 是缓存读。缓存读按套餐折扣计费(远低于原价,具体折扣以各家价目表为准),所以物理 token 数≠额度扣减数——这也是为什么我们自己那篇《一周 5.3 亿实测》里,5.3 亿物理 token 并没有想象中那么"烧"。评价一个 AI 开发会话贵不贵,不看总量,看非缓存输入量(每轮真正"新喂"给模型的字节)和输出量。
另一个反直觉的点:MIMO 侧 4,528 万里,大部分消耗不是在"写代码",而是在调度岗每一轮重读全部上下文(4,276.8 万缓存读就是这么来的)。长会话调度的成本结构 = 轮数 × 全上下文缓存读。想要省钱:短会话、任务卡切小、少留无效中间产物。
为什么这个活能干完(机制,不是鸡汤)
三个条件,缺一不可:
- 需求是明确的。P1 有交接文档、有范围 A/B 清单、有 4 件拍板事项、有 HTML 高保真原型已点通。免费模型最怕"你帮我做个好东西",最不怕"照这个单子干"。
- 确定性需求占大头。六张卡里 80% 是"接口+落库+回归"的确定性工程——这正是 MIMO 这类免费模型的能力舒适区。开放性判断(提速方案方向、前言块定性)我用强模型 K3 会话兜底,形成分层:免费模型跑确定性管线,强模型做关键判断。
- 验收是机器可判定的。每张卡的验收标准=pytest 全绿 + 探针实跑退出码 + 数据断言。AI 没法"感觉良好"地交差。
问题,照实说
- 慢。OpenCode 上免费通道用的人多,长上下文轮次等待明显,"半天才出一个结果"是真的。但免费=用等待换现金,这笔账认。
- 智商差 K3 一点(个人体验口径)。确定性任务无感,开放性取舍有感——所以才要把两类任务分层。
- 什么都写脚本。这是双刃:确定性来自流程重(任务卡、互斥清单、回归用例都要写),换来的是返工可控。不写脚本的快是债,迟早要还。
- 套餐积分制看不懂(本人查阅小米官网,自报口径):十几亿积分的营销话术,一个 token 对应几百积分的换算,规则不透明。绝对价格在各家模型里算低档,但性价比要打问号——看不清计费规则的产品,先按物理 token 实测账自己算,再决定投入。
可抄走的东西
① 免费模型派活边界清单(接活前过一遍):
- 有没有交接文档/范围清单?没有 → 先补文档再派;
- 验收能否写成机器判定(测试/断言/退出码)?不能 → 别派;
- 任务里开放性判断占比 >30%?→ 拆出来给强模型;
- 修复类任务有没有全量样本回放计划?没有 → 补上再动手。
② 全口径 token 统计法(本文数字的复现路径):
- OpenCode 侧:
~/.local/share/opencode/opencode.db的 message 表,tokens JSON 五段求和(input/output/reasoning/cache.read/cache.write);开发期窗口过滤按 time_created。 - kimi 侧:
~/.kimi-code/sessions/*/session_*/agents/*/wire.jsonl的usage.record全量求和,输入 = inputOther + inputCacheRead + inputCacheCreation(含缓存读,这就是"全口径"),输出 = output;与落库侧 cost_record 同口径,可交叉验证。
③ 分层用模型的最小模式:调度岗+确定性编码 = 免费模型(MIMO);关键方案判断 = 强模型会话(K3);产线跑稿 = 无头子进程(谁便宜用谁)。我们这套跑完,两通道合计 7,233 万物理 token,其中 94%+ 走缓存折扣——免费模型不是玩具,是调度岗和确定性管线的正经选项。
推荐结论
MIMO V2.6 Flash 作为一个免费模型:kimi 额度用尽时拿来接力,能干;学生党、AI 入门、预算不足时拿来练手,能用;主力生产环境等它把计费规则和算力都磨明白了再说。没额度的时候可以体验一下——这是它当前最诚实的定位。
素材点
- 接单问句原话(10-11 晚):「你看看我们 OpenCode 里面,这个活能不能干?用 MIMO v2.6 Flash 版本。」
- 执行形态拍板原话:「全部由 OpenCode 里面进行后续的开发。」
- 提速方向拍板原话:「模型不要去思考了,就直接回结果,这样效率肯定是最高的。」
- 返工处置原话:「就单独修改一下,不返工了。」(对应 6cfcea7 单点修)
- 数据落库原则(本人 10-12 晚在 K3 会话沉淀):「有数据库的,数据保存到数据库优先……不要弄一堆的日志,文件来保存。」