企业官网建设流程全解析

系列导航：本系列记录 gdev-master（NVIDIA/nouveau 用户态 GPGPU 运行时）从 C/C++ 到 Rust 的移植工程。

已发布：01 调研与规划

本篇：02 工程化工作流：opencode 多会话分工 + tmux/TUI + 模型切换 + 分层验收

一、opencode 多会话分工：规划、翻译、验收分开

这样分的理由：翻译是「机械 + 需要大量上下文」的活，规划/验收是「需要全局判断 + 签字」的活。三者混在一个会话里，既烧钱又容易「边写边改设计」。分工后，翻译会话只面对一个任务 spec（tasks/<id>.md），规划会话只面对一个「完成报告 + verify 结果」，验收会话只面对「spec 的判定标准 + C 源码 oracle」。

每个任务的完整闭环（AGENTS.md强制）：

1. 读开场（git status/log → STATUS.md → tasks/<id>.md → PITFALLS → plan.md）；
2. 领任务后先写mini-plan（翻译清单 / 依赖 / 难点风险 / 验收策略），高风险任务（契约层 types.rs、P4 硬件后端）交给用户审一眼；
3. 规划完成才写代码，禁止边写边想整体结构；
4. 完成后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 上限（providerID=kimi modelID=k3报AI_APICallError: 5-hour usage limit）。

所以建立四档切换策略（./scripts/switch-model.sh一键切换后重启 tmux）：

四、验收下放：flash 档独立验收会话

为省 deepseek 账单，机械验收全部下放给一个独立的 opencode 验收会话（跑 deepseek-flash 档），规划会话（deepseek-v4-pro）只做规划/spec/最终签字。

• 下放范围：跑verify.sh、nm -D符号核对、枚举判别值grep比对、读产物.rs挑错、git/tmux 状态查询。
• 关键在「独立」：验收会话用独立 tmux 会话 + 独立上下文，不复用翻译会话的上下文——否则「验收」会带着翻译的思路去看、失去独立性（flash 档也比 pro 档便宜）。
• 连「翻译会话是否卡住」这种视觉状态判断也下放：验收会话自己tmux capture-pane+ps -o pcpu,etime+ss -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 Code，opencode 退回成专一的翻译主力。其余全部照旧：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」。系列后面各篇能一篇篇稳定产出，靠的就是这条链。