双模型限额断点续干:三个半截任务收口与产线系统化第一刀

背景与目标

9-28 晚 Kimi Code 周额度打顶,切到 OpenCode 的小米 mimo-v2.6-flash-free 继续干活;结果 mimo 晚上也限额,三个任务干到一半全断:

1. 配置治理(junshi/thinking):负向规则正向改写,4 张并行子单断了 2 张;
2. dev 知识库接入(cio/dev):验收全过,断在 git commit;
3. 产线系统归口(cio/dev):本人拍完板("权限放宽+马上开干"),AI 回复直接断连,执行为零。

9-29 早额度重置(09:01),本人把三个会话的导出记录(output/opencodelog/2026年9月29日/)交过来,一句话下令:检查了哪些活、该恢复的恢复、能接着干完就干完。

过程回顾

第一步:解析会话导出,重建三个中断点。 OpenCode 会话导出是 JSON(info + messages),直接写脚本解析:消息流、tool 调用清单、write/edit 落盘路径、最后一条消息的 error 字段。三个断点全部定位:

• 任务①断在 4 张 task 子单派发后——2 张 completed、2 张 status=running;
• 任务②断在最后一条 bash:git add 命令 PowerShell 引号翻车(MissingEndCurlyBrace),commit 根本没发生;
• 任务③断在 assistant 消息 APIError("other side closed"),本人拍板后零执行。

第二步:磁盘对账,不信会话状态。 status=running ≠ 没干活。用任务卡自带的验收断言(grep/mtime)逐条对:任务①的"AGENTS.md 两章程"单,thinking 侧 32 条里 22 条其实已经落盘(mtime 9-28 20:41,抽查 grep 全过),只有全局 ~/.agents/AGENTS.md 6 条没动;eval 单产出文件不存在,纯零开始。要补的缺口比会话状态显示的小一半。

第三步:拆单并行续干。 缺口派 2 张 coder 子代理(原任务卡六要素全文+前序进度更新),自己同时做 dev 仓三笔范围化补提交。零文件交集,一次全过。

第四步:任务③从拍板干到验收。 立项卡(权限落章/骨架拆分/U盘内容移交/设计稿/编码卡)→ 编码卡(迁移+根配置化+多产品+ingest+schema)。编码卡卡面有矛盾(资产盘点说 SOP 留 thinking,跨项目节又写 SOP 指针改 dev),派单时军师裁定覆盖:SOP 指针不动,只改三件套位置口径。

第五步:军师亲跑验收。 不照单子代理报告:check_links 自己跑一遍(PASS=43 FAIL=0,exit 0),截图目检面板真实渲染(产品切换器在位),config_lint 归零,两仓 9 笔 commit 落盘,态势纸+台账+kb 三处落点。

关键踩坑

坑 1:验收过了,commit 没提交——中断一来等于白干。 现象:知识库接入 8/8 配置、6/6 握手全验过,但 35 项改动全挂在工作区;根因:dev 章程明写"已验收改动立即 commit",OpenCode 会话压到最后才提交,还撞上 PowerShell 引号坑;解决:断点补提交三笔(320721a/2a28288/95984f6)。教训:分段 commit 不是洁癖,是断点保险。

坑 2:子代理中断状态会骗人。 现象:会话导出里 2 张单 status=running,看着像"干了一半要重来";根因:状态停在派发时刻,磁盘才是真相;解决:续干第一步永远是"任务卡验收断言 vs 磁盘实况"对账,只补缺口不返工——本次少返工 22 条改写。

坑 3:任务卡自相矛盾。 现象:编码卡一边写"SOP.md 留 thinking 不迁",一边要求"thinking 路由表 SOP 指针改 dev 新路径";根因:立项卡子代理写编码卡时两节没对齐;解决:军师派单前裁定写进 override(SOP 指针不动、只改三件套口径),并在交付验收时核 git diff 确实只有 ±1 行。

最终方案(断点续干五步法,可复用)

1. 会话导出 JSON → 脚本解析消息流,定位断点(最后 error + 最后的 tool 调用);
2. 提取全部 write/edit 清单 + 未完成任务卡原文;
3. 任务卡验收断言 vs 磁盘实况对账,圈出真实缺口;
4. 缺口按原卡六要素重派(并行卡声明写入零交集),已验收成果先补 commit;
5. 军师亲跑核心验收(脚本退出码+截图目检),台账/态势/kb 三处落点再收口。

做得好的地方

• 零请示执行:已批方案(处置卡 5 条、拍板四条)全程没有再问一句"要不要干",直接干完再报——对上 9-28 晚本人"这东西还要问我?直接改嘛"的不满;
• 任务卡即续命符:昨晚打的任务卡六要素(验收标准机器可判),今天换了一个执行体(kimi 换 mimo 断、子代理换人)照样无缝接力——任务卡质量=抗中断能力;
• 43 链基线比对法:迁移类任务"同一批产物、同一解析结果、逐链差集为空",比"大概能跑"硬得多。

复盘与改进

• 双线作战(Kimi→OpenCode)当晚三线并发,中断面扩大,我却没提前下令分段 commit——下次长链会话每过一个验收点即提交,不攒尾;
• 续干触发现在还靠本人手工导出会话记录;OpenCode 本地有会话存储目录,理论上可跳过手工导出直读【待验证】,验证后写成 SOP;
• OpenCode 侧 config_lint 词闸抓到一次"本人裁定放宽"措辞(裁定出处违规),子代理自纠归零——闸有效,但写配置该一次避开。

成长评估

AI 自评失分点:①CIO 会话开局把项目位置搞错,在 dev 建错方向骨架被本人纠偏;②dev commit 引号翻车+"验收过没提交",章程白写;③junshi 会话对已批方案反复请示被本人当场批;④立项卡与编码卡两节矛盾,靠军师裁定兜底。

指令实证 1:"1234四条的话,第三条有点疑义,反正权限你可以更加大一点……并不一定要设置成只读。然后节奏嘛,就马上开干吧。"→ AI 行为改变:dev/AGENTS.md 只读条款改写为"任务卡显式声明写入清单即可改"(db 层只读保留);节奏从"今晚设计明早编码"改为当班两卡连干到验收。证据:D:\code\dev\AGENTS.md(commit 58a7f71)、项目\产线系统\code\(commit 0c98473)。

指令实证 2:"这个是不对的,这个项目首先搞错了,我们原先是在tinking项目里面开发的。D:\code\thinking\tools\product_flow"→ AI 行为改变:停掉 dev 错骨架,实读 product_flow 真相源,最终演化为"系统归 dev、内容归 thinking"的切割拍板,次日 U盘内容移交。证据:u.json 会话 msg[24]→[35] 转向、移交 commit 59b8194。

素材点

• 断点续干五步法可出 S2 进阶实战稿:限额/断连是常态,"任务卡+验收断言"才是抗中断资产;
• "会话状态 vs 磁盘真相"对账法可出 S3 纯技术稿:解析 agent 会话导出 JSON 定真实进度;
• 产线系统第一刀(根配置化解决 43 链迁移)本身就是"工具当产品做"的炫技素材。