野生码农
免费模型接手真实代码迭代实测:MIMO V2.6 Flash 4.4 小时收口 P1,全口径 token 账 7233 万
环境与版本:调度/编码模型 = MIMO V2.6 Flash(小米免费模型,运行于 OpenCode 会话);关键判断兜底 = Kimi K3 会话;产线跑稿 = kimi 会话内嵌无头子进程。被改对象 = 自研 IPMS 内容生产管理系统(终审台:选题、写稿、质检、组包产线中的人机交接环节)。token 取数来源:OpenCode 侧
~/.local/share/opencode/opencode.db,kimi 侧~/.kimi-code/sessions下 wire.jsonl。
一、任务背景
10 月 11 日晚,Kimi Code 周额度即将到期,手上压着一张 P1 编码单:IPMS 终审台改造,包括 AI 分析、建议采纳、段落快改、标题 10 选 1、摘要封面可编辑,范围 A 六项加范围 B 四项,外加 4 件待拍板事项。原计划等 10 月 13 日额度重置后再派。
当晚调度岗会话模型正好换成 MIMO V2.6 Flash,当场拍板:六张编码卡全部由 OpenCode 会话内自研自测,产线跑稿走 kimi 会话内嵌子进程。原定"额度重置后派后端加测试"的双岗流水线,改成免费模型一岗干到底。22:41 拍板落档,开发开始。
二、实测结果
断续活跃约 4.4 小时(按 git 提交、任务运行、产出文件修改时间聚合,相邻间隔不超过 20 分钟计同一段),日历跨度约 40 小时:
| 时段 | 时长 | 内容 |
|---|---|---|
| 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 | 提速方案落地 + 收尾修 |
| 合计 | ≈263min ≈ 4.4h | 其余为空档 |
交付物全部带回归测试:P1-F(meta 下游契约适配)、P1-E(外部稿导入通道 + 快车道头尾模板秒级组包)、P1-A1/A2(终审页 AI 分析后端通道 + 前端卡片)、P1-A4(段落级敏捷快改)、P1-A3(标题 10 选 1 点选 + 摘要封面可编辑)。产线侧连跑三篇母稿与组包。
回归测试从 161 个涨到 197 个,全绿。每张卡的验收标准为 pytest 全绿 + 探针实跑退出码 + 数据断言——验收不靠感觉,靠机器判定。
三、踩坑复盘:一个根因连吃 4 棒
现象
meta 标题格式不健壮,四种历史格式陆续翻出,同一根因先后触发 4 次修复;另有复制标题带理由段、不读终审定稿,排版前言写成流水账,AI 分析完成事件标签错等关联缺陷。
排查
| 缺陷根 | 棒次 | 证据(git 提交) |
|---|---|---|
| meta 标题格式不健壮,四种格式陆续翻出 | 4 | 941a029 / 447d45f / df4948d / 7d52abc |
| 复制标题带理由段、不读终审定稿 | 2 | df4948d / 1890071 |
| 排版前言写成流水账 | 2 | 6cfcea7 / 00e1741 |
| AI 分析完成事件标签错 | 1 | c5fad76 内顺带修 |
根因
首修时未做全量样本回放:四篇历史稿的 meta 格式各不相同,只按当前样本修复,旧格式继续触发新缺陷。
解决
全程未做全量返工;唯一的返工级问题按指示单点修复("就单独修改一下,不返工了"),逐棒收口后将各格式固化。
预防
格式兼容类修复,首修即全量回放,把全部历史格式一次性固化为回归用例。这是给免费模型最该配的保险,对任何 AI 编码都适用。
四、提速:提示词纪律比模型智商值钱
提速方向在 Kimi K3 会话拍板:把提示词写精准、要求写精准,直接发给 LLM,模型不思考直接回结果,把 K3 的思考档位调成 low。
落地后实测:单次 AI 分析从 203 秒降到 46 秒,单次 token 从 12.1 万降到 3.7 万——速度提升 4 倍多,token 省七成。靠的不是换更贵的模型,而是提示词精度与思考档位。确定性任务上,提示词纪律比模型智商值钱。
五、token 全口径账:三个口径差 14 倍
"token 消耗"至少有三个口径:
| 口径 | 数值 | 说明 |
|---|---|---|
| IPMS 落库产线(cost_record 11 笔) | 581 万 | 只算写稿/组包/AI 分析子进程 |
| kimi 侧 P1 全口径(产线+探针+手工会话) | 2,705 万 | 含全程手修的 K3 会话 2,101 万 |
| 两通道 P1 全口径 | ≈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% |
缓存读即模型每一轮重读已见过的上下文,按套餐折扣计费,远低于原价。因此物理 token 数不等于额度扣减数:本轮 7,233 万物理 token 里九成四走缓存折扣,真正按原价计的新输入只有 214.6 万,约等于把调度侧计费成本压到物理量的二十分之一。
另一点:这 4,528 万的大头不是写代码,而是调度岗每一轮重读全部上下文。长会话调度的成本结构 = 轮数 × 全上下文缓存读。想省钱就三条:短会话、任务卡切小、少留无效中间产物。
六、复现路径:全口径 token 统计法
OpenCode 侧:
~/.local/share/opencode/opencode.db
→ message 表,tokens 字段五段求和,开发期窗口按 time_created 过滤
kimi 侧:
~/.kimi-code/sessions 下 wire.jsonl
→ usage.record 全量求和;输入 = 常规输入 + 缓存读 + 缓存创建,输出单列
两边与落库口径能互相对上,可交叉验证。
七、为什么这个活能干完
机制层面三个条件缺一不可:
- 需求明确:P1 有交接文档、范围清单、4 件拍板事项,高保真原型已点通过。免费模型最怕"帮我做个好东西",最不怕"照这个单子干"。
- 确定性需求占大头:六张卡八成是接口 + 落库 + 回归的确定性工程,正在免费模型能力舒适区;开放性判断(提速方向、前言块定性)用强模型 K3 会话兜底。分层就此形成:免费模型跑确定性管线,强模型做关键判断。
- 验收机器可判定:每张卡的验收标准是 pytest 全绿 + 探针实跑退出码 + 数据断言,AI 没法"感觉良好"地交差。
八、免费模型派活边界清单(可直接抄)
- 有没有交接文档或范围清单——没有就先补文档再派;
- 验收能否写成机器判定(测试、断言、退出码)——不能就别派;
- 任务里开放性判断占比是否超过三成——超过就拆出来给强模型;
- 修复类任务有没有全量样本回放计划——没有就补上再动手。
配套分层用模型的最小模式:调度岗 + 确定性编码用免费模型,关键方案判断用强模型会话,产线跑稿用无头子进程,谁便宜用谁。
九、问题照实说
- 慢:免费通道用的人多,长上下文轮次等待明显,半天出一个结果的情况确实存在。免费就是用等待换现金。
- 开放性取舍:智商差 K3 一点(个人体验口径)。确定性任务无感,开放性取舍有感,所以两类任务必须分层。
- 什么都写脚本:双刃。确定性来自流程重——任务卡、互斥清单、回归用例都要写,换来返工可控;不写脚本的快是债。
- 计费规则不透明:积分制,一个 token 对应几百积分的换算,规则看不懂。绝对价格在各家模型里算低档,但性价比存疑。看不清计费规则的产品,先按物理 token 实测账自己算,再决定投入。
十、结论
MIMO V2.6 Flash 作为免费模型的当前定位:额度用尽时拿来接力,能干;学生党、AI 入门、预算不足时拿来练手,能用;主力生产环境,等计费规则和算力磨明白了再说。确定性编码交给低成本模型,架构和方案判断留给贵模型,成本按非缓存输入量盯——这套做法搬进公司业务同样成立。
我是野生码农,AI实战派。17年全栈工程师,一人AI公司实践者。打造个人IP内容体系、软件全链路产品产线,拥有百套企业AI方案、200多个岗位Agent;自研知识库、AI数字员工系统,公开实战复盘。
本文所有内容均为本人 AI 实战的过程和结果,经 AI 整理后发布,无任何瞎编虚构内容。
这篇来自《AI员工团队》系列。
关注我,看真的。
野生码农AI实战 · 全网同名