系列导航本系列记录 gdev-masterNVIDIA/nouveau 用户态 GPGPU 运行时从 C/C 到 Rust 的移植工程。已发布01 调研与规划本篇02 工程化工作流opencode 多会话分工 tmux/TUI 模型切换 分层验收一、opencode 多会话分工规划、翻译、验收分开会话职责明确不做opencode 规划会话规划 / 写任务 spec / 脚手架 / 文档 / 监督不直接写翻译代码opencode 翻译会话Kimi K3 / deepseek逐文件 C→Rust 实现不写博客 / 不改规划opencode 验收会话flash 档跑 verify.sh / 符号核对 / 枚举值比对不改代码这样分的理由翻译是「机械 需要大量上下文」的活规划/验收是「需要全局判断 签字」的活。三者混在一个会话里既烧钱又容易「边写边改设计」。分工后翻译会话只面对一个任务 spectasks/id.md规划会话只面对一个「完成报告 verify 结果」验收会话只面对「spec 的判定标准 C 源码 oracle」。每个任务的完整闭环AGENTS.md强制读开场git status/log → STATUS.md → tasks/id.md → PITFALLS → plan.md领任务后先写mini-plan翻译清单 / 依赖 / 难点风险 / 验收策略高风险任务契约层 types.rs、P4 硬件后端交给用户审一眼规划完成才写代码禁止边写边想整体结构完成后verify.sh全绿 → 更新 STATUS.md → 踩坑回填 PITFALLS →git commit一任务一提交消息带 task id。二、opencode 的启动方式tmux TUI方式 B用户指定不用 headlessopencode run而是用 tmux 挂一个常驻 TUI 会话tmux new-session -d -s gdev-oc cd /home/cos/work/gdev-both opencode用户tmux attach -t gdev-oc即可实时看到 opencode 的思考/命令/diff但不需要逐项确认权限已配external_directory: allow项目内 edit/bash/webfetch 默认放行。这比 headless 好在可监督、可中断又比逐项审批省事。三、模型切换策略三档 一个省钱档opencode 背后的模型有额度上限且多个免费/会员通道各自独立限流实测踩了两类坑opencode-go 账号有 5 小时用量上限账号级不是单模型级——切 opencode-go 内的模型无效kimi/k3 API 也有自己的 5h 上限providerIDkimi modelIDk3报AI_APICallError: 5-hour usage limit。所以建立四档切换策略./scripts/switch-model.sh一键切换后重启 tmux档模型场景1opencode-go / kimi-k3额度充足时质量最好2kimi APIk3opencode-go 撞 5h 上限后3deepseek APIdeepseek-v4-prokimi 额度也不足时强推理兜底4deepseek-flashv4-flash翻译任务机械、spec 已定设计时省钱verify 反复失败怀疑推理不足再切回 pro四、验收下放flash 档独立验收会话为省 deepseek 账单机械验收全部下放给一个独立的 opencode 验收会话跑 deepseek-flash 档规划会话deepseek-v4-pro只做规划/spec/最终签字。下放范围跑verify.sh、nm -D符号核对、枚举判别值grep比对、读产物.rs挑错、git/tmux 状态查询。关键在「独立」验收会话用独立 tmux 会话 独立上下文不复用翻译会话的上下文——否则「验收」会带着翻译的思路去看、失去独立性flash 档也比 pro 档便宜。连「翻译会话是否卡住」这种视觉状态判断也下放验收会话自己tmux capture-paneps -o pcpu,etimess -tnp三合一判断「在推进 vs 停滞」报结论给规划会话拍板。这套「验收外包」是本期能把 25 个任务稳定验收下来、又控制住成本的关键。五、会话接续与状态留存93 个 commit 跨多次会话靠三份「状态文件」保证上下文不丢STATUS.md进度账本当前任务 下一步 每任务 commit/验证/备注权威来源verify.sh --progress从它渲染PITFALLS.md踩坑合集现象 → 定位 → 修复跨会话累积宁可多写一条不可让下一个 agent 再踩一次plan.md / PORTING_SCOPE.md范围与铁律稳定不常改。新会话按AGENTS.md开场顺序约 1 分钟就能恢复「我是谁、做到哪、下一步、怎么分工」。六、每日收尾每晚跑./scripts/daily-summary.sh按blog/模板.md的四段式今日目标 / 完成内容 / 测试与验证 / 遇到的问题与解决 / 下一步写当日日志每个移植阶段另写一篇阶段博客草稿blog/P0-01-*.md…blog/P3-04c-*.md目前 25 篇留痕四要素工作内容、进度、验证方法、问题解决。七、后记分工的实际演进 —— 规划/监督这一侧换成 Claude Code前面六节写的是立项时的方案第一节那张表里的三个会话当时都挂在 opencode 上第一行「opencode 规划会话」就是原始设计。真跑起来之后换掉的正是第一行——规划 / 写 spec / 验收签字 / 监督这一侧改用 Claude Codeopencode 退回成专一的翻译主力。其余全部照旧tmux TUI 的启动方式方式 B、三档模型切换、验收下放 flash 档、一任务一会话、三份状态文件接续一条没改。为什么把「监督」单独拎出来换一套工具两个理由一、额度该花在翻译上。opencode 的额度相对充足而逐文件 C→Rust 翻译正是「机械 吃大量上下文」的活——额度花在这儿最值。规划与监督是另一种性质的活判断多于产出占的是同一份额度却买不到对应的东西。二、auto mode 能把纪律自动化。Claude Code 一侧可以开 auto mode自动接受编辑与执行、不逐项打断于是整条链能自己跑完读状态git / STATUS.md / tasks/id.md / PITFALLS / plan.md → 写任务 spec验收标准先定死 → 起 opencode 会话tmux方式 B 不变 → 收 verify 结果 → 跑验收 / 与 C oracle 比对 → 更新 STATUS.md / 回填 PITFALLS.md → git commit一任务一提交 → 关掉这个 opencode 会话下个任务重开一任务一会话人只在关键节点签字改 C 源码、push、上目标机、定版——不可逆或对外的动作auto mode 一律不碰。这次调整的实质一句话auto mode 的价值不是「让 AI 自己写代码」是「让纪律不依赖人的记性」。「一任务一提交」「踩坑回填 PITFALLS」「状态文件当天更新」这些事人做三天就会漏交给带 auto mode 的监督层才真的每天发生。分工本身没变opencode 仍然只面对一个任务 spec、只负责实现变的只是「谁来读 verify 结果、谁来更新状态、谁来发 commit」。系列后面各篇能一篇篇稳定产出靠的就是这条链。
