背景与目标

Kimi Code 周额度打顶,当天的开发被迫换引擎。目标一句话:把已经在 Kimi 上跑通的数字员工团队配置(01 产品设计岗 / 03 后端岗 / 04 测试岗 + 根目录 CIO 调度总岗)全量搬到 OpenCode,模型换成 mimo-v2.6-flash-free,先验证两条渠道各自能用,再开正式任务。

本人当天拍板原话(本篇的最高指令):

"使用open code及现在的mimo -v2.6 -flash 模型开发时,不需要走kimi code 无头模式;现在Kimi code 周额度上限了,你是走不通的。"

时间锚:2026-09-28 凌晨 04:11–04:29【实测:命令输出时间戳 + Get-Date】,上一个 commit 是 2026-09-27 00:24【实测:git log】,本期 6 个新文件截至成稿仍未提交【实测:git status --short】。

过程回顾

尝试 1:静态验收——全绿,但只证明"配置写了"

先按 Kimi 时代的验收习惯跑静态探针:

• schema 校验:3 岗 opencode.json + 全局 opencode.jsonc 全过官方 https://opencode.ai/config.json【实测 4/4】
• agent list:三岗 agent 各自 (primary)【实测】
• debug skill:01 岗 28 个技能、03 岗 2 个、04 岗 2 个全部命中,内容与磁盘逐字节比对一致【实测脚本比对】
• mcp list:01=2 / 03=3 / 04=2 全部 ✓ connected【实测】

结果:全绿。但这一轮只是"文件层 + 加载层"的证据,没有一次真正把模型跑起来。

尝试 2:第一次端到端实跑,当场炸出真问题

> houduan · qwq-plus
Error: Incorrect API key provided...
(随后 Bun Segmentation fault 崩溃)

【实测:npx opencode-ai run --agent houduan "...",2026-09-28 凌晨】

现象是模型报错,根因不在模型:全局配置里根本没有 model 字段,OpenCode 落到了它自己的默认值 alibaba/qwq-plus——而这个 provider 在 auth.json 里压根没凭据(实测已认证的只有 opencode 和 moonshotai-cn 两个)。静态验收为什么没抓到?因为 debug config 只回显你写了什么,不回显"没写的东西会解析成什么默认值"。

尝试 3:修完跑通,并把 CIO 岗一起补齐

按本人口径写死模型后:

> houduan · mimo-v2.6-flash-free
→ Read D:/code/dev/AGENTS.md [limit=5]
READ_OK 5

【实测:03 后端岗目录,读取 cwd 之外的文件,无权限阻塞】

同一轮里还补了一个漏:本人点出"你是不是还是忘记了一个岗位的配置?就是现在根目录下的CIO的岗位"——3 个执行岗都配了,总调度岗却没配。补 .opencode/agents/cio.md + 根 opencode.json(default_agent: cio) 后,根目录起会话直接落 cio · mimo-v2.6-flash-free,且禁用工具能直接答出根 AGENTS.md 里的"硬闸② = 资产盘点+复用映射"——证明根章程被 OpenCode 自动注入,所以 CIO 的 agent 文件不必复制全文,只写身份与执行口径。

关键踩坑

坑 1:没写 model ≠ 用默认可用的模型(最贵的一个)

• 现象:第一次 run 直接 401 + 客户端崩溃。
• 根因:迁移时只顾"把 kimi 的字段搬过来",kimi 的 default_model 在 OpenCode 侧没有对应默认,落到了无凭据的 provider。
• 解决:全局 opencode.jsonc 显式写 "model": "opencode/mimo-v2.6-flash-free"。
• 教训:迁移的第一条验收必须是端到端跑一次,不是 schema 通过。schema 只回答"字段合法吗",不回答"这套配置连起来能跑吗"。

坑 2:权限写成字符串,渲染出来还是 ask

• 现象:permission.external_directory 写 "allow"(字符串简写),agent list 渲染的规则里通配仍是 ask。
• 根因:external_directory 的规则是文件系统路径模式,要用 object 形式;且 OpenCode 按"最后匹配的规则生效"求值。
• 解决:

  "external_directory": { "*": "allow" }   // object 形式,通配在前
  

• 验证:改完仍看到默认 ask 规则混在列表里,所以不靠渲染下结论,直接实跑读 cwd 外的 AGENTS.md → READ_OK 5【实测】。
• 教训:渲染/回显不等于求值结果,跨目录这类"拦不拦"的行为必须用真实越界动作验。

坑 3:截断输出把两个技能的内容看串了(流程坑,略记)

04 岗 debug skill 的输出里 bug-replay 后面跟着 # Deploy to Vercel,一度像是技能文件张冠李戴。真实原因是工具输出被截断 + findstr 只回匹配行,上下文错位。改用把完整输出重定向落盘 → Python 解析 JSON → 与磁盘文件逐条比对,证伪:match_after_fm=True,内容完全一致【实测脚本】。教训:大输出一律落盘解析,不看截断预览。

坑 4:PowerShell 下 python -c 多行命令静默无输出(略记)

同一条命令用 -c 带换行时不出结果也不报错,连踩三次才发现是 shell 传参问题。改回既有纪律:一律 Write 成脚本文件再执行——这条在 09-15 的复盘里已经写过("写脚本一律 Write 不经 bash 中转"),本次属于条款入库未入脑。

最终方案(可抄走的迁移清单)

本次产出的 6 个文件(git status 未跟踪):

Kimi → OpenCode 映射要点:

• 模型:default_model → 全局 "model": "provider/model",必须显式写。
• 权限:default_permission_mode=auto + 全 allow → permission 对象;external_directory 用 object 形式(岗位 cwd 与 项目\ 任务卡目录不同根,不放行无头派单会卡住)。
• 技能:--skills-dir 是排他挂载 → skills.paths 是追加挂载,全局 ~/.agents/skills 的 17 个技能会跟着进岗位实例【实测:01 岗 45 = 28+17,03/04 岗 19 = 2+17】。这是两套工具的真实行为差异。
• MCP:.kimi-code/mcp.json 的 startupTimeoutMs → 岗位 opencode.json 的 mcp.<name>.timeout(近似)。
• 规则:OpenCode 会从 cwd 向上遍历自动加载 AGENTS.md,不用复制进 agent 文件。

派单命令(OpenCode 口径):

# cwd 必须是岗位目录
npx -y opencode-ai@latest run --agent <chanpin-sheji|houduan|ceshi> "任务卡 + 要求"

双渠道可用性与识别

两条渠道各跑一次自证探针:

识别信号(写进了 .opencode/agents/cio.md,两边会话都能自我判定):

做得好的地方

• 没有停留在静态验收:schema、agent、skill、mcp 全绿之后仍然跑了真实 run,才把模型默认值这个真坑挖出来。
• 渲染结果不轻信:权限规则渲染是 ask 时,用真实越界读文件做行为级验证,而不是改到"看起来对"为止。
• 被点出的遗漏当场闭环:CIO 岗被点名后,补配置 → 验证 → 把"渠道识别 + 未拍板项"写进 agent 文件,一轮完成。

复盘与改进

1. 验收顺序倒了:正确顺序应该是 ①端到端跑通一次 → ②再做静态细粒度验收。本次反着做,静态全绿给了虚假安全感。
2. 迁移类任务缺"默认值清单":搬字段时只看"两边都有的",不看"目标侧没写会怎样"。下次迁移先列目标侧必填但易漏的三件:模型、工作目录边界、默认 agent。
3. 条款入库未入脑:Write 落盘这条 09-15 就写过,本次仍用 python -c 连踩三次。改进:把"多行命令一律落盘执行"从复盘文提到会话纪律层。
4. 两处待本人拍板仍未动(不自作主张):根 AGENTS.md 的 kimi 派单段落是否改写为 opencode 口径;CLI 是否全局安装(现靠 npx 拉包)。

成长评估(第 5 节)

模块目的:沉淀"什么指令带来什么结果"的可验证经验,分数只是索引,指令实证才是本体。

五维评分(10 分制,只对事)

AI 自评失分点(本人抓到的优先)

1. 漏配 CIO 岗——本人一句话点破:"你是不是还是忘记了一个岗位的配置?就是现在根目录下的CIO的岗位。"根因:我按"3 个执行岗"清单思维干活,没回到章程的岗位编制表(4 岗)对账。
2. 验收顺序错——静态验收跑了一大圈才做第一次真实 run,模型没配这种硬伤本该第 5 分钟就暴露。
3. 截断输出误判技能内容——浪费一轮才用落盘解析证伪。
4. python -c 多行连踩三次——违反自己已沉淀的条款。

指令实证(强制)

1. 原话:"使用open code及现在的mimo -v2.6 -flash 模型开发时,不需要走kimi code 无头模式;现在Kimi code 周额度上限了,你是走不通的。" → 行为改变:当场停止 kimi 无头链路的所有后续验证,改为 OpenCode 端到端实跑;发现默认模型落空后直接把全局 model 写死为 opencode/mimo-v2.6-flash-free。 → 结果证据:~/.config/opencode/opencode.jsonc 的 model 字段 + 实测输出 > cio · mimo-v2.6-flash-free。

2. 原话:"你是不是还是忘记了一个岗位的配置?就是现在根目录下的CIO的岗位。" → 行为改变:补建根目录 CIO 岗配置,并把"渠道识别 + 两个未拍板项"固化进 agent 文件,防止后续会话自行改章程。 → 结果证据:D:\code\dev\.opencode\agents\cio.md、D:\code\dev\opencode.json(根 agent list 含 cio (primary))。

素材点

• "静态验收全绿 ≠ 能跑":schema/agent/skill/mcp 四类探针全过,第一次 run 仍因缺 model 直接 401。
• 迁移必填三件:模型、工作目录边界、默认 agent——这三个不写,目标侧会用"它自己的默认值"而不是"你以为的默认值"。
• 两套工具的技能挂载语义相反(排他 vs 追加),是渠道切换期最容易被忽略的行为差异。
• 双渠道并存期,"我此刻在哪条渠道"必须是可判定信号(模型 ID + 专属工具),不能靠感觉。
• kimi 403 原文可作"周额度打顶"这一现实约束的直接证据。