五月那篇《双模型协作工作流》写的是最初版本：两个角色、三个文件、一套切换规则。跑了快两个月，规则又长出了几条，记一下变化和中间踩的一个坑。
风险分流：不是所有代码都值得同等审查
最初的设计是”工作者写代码，全局者审查”，一视同仁。跑了一段时间后发现一个问题：审查追不回设计层面的质量差距——工作者用的模型能力弱一些，代码写出来能跑，但架构判断力这块，事后审查很难纠偏。
解法不是全面换用更贵的模型（成本受不了），而是按风险分流：认证/密钥、支付、并发竞态、不可逆的数据操作、对外 API 设计这五类，强制升级成全局者直接实现，工作者只做集成；普通模块被打回两次以上，同样升级。升级项由全局者在任务清单里显式标注，工作者不能自己认领。
一个真实踩到的坑：critic 子代理”有时候不在场”
工作流设计里有个 critic 子代理——只读、跑在 Haiku 上，专门做安全审查，让全局者不用自己去读一堆代码，凭它的结构化报告判断。
用了一阵之后遇到怪事：同样的项目，有的 session 能 invoke critic，有的直接报 Agent type 'critic' not found。查到最后发现规律：Claude Code 只在 session 启动那一刻按当前目录扫描 .claude/agents/，之后不管怎么 cd 进项目目录都不会重新扫描。 习惯从 /root 起 session 再 cd 进项目的用法，会让项目根钉死在 /root，永远加载不到项目自己的 critic.md。
两个解法：要么两个终端都从项目目录直接启动 session；不方便重启时，退而用内置的 security-reviewer 顶替，效果等价，本地已经有先例在跑。工作流文档也顺手补了这条注意事项，省得这坑以后还有人再踩一次。
安全预检脚本：不能只靠工作者自己说”没有安全项”
前面的机制里，“安全项非空 → 必须读代码”这条规则依赖工作者在交接时自报。跑下来发现一个已知失效模式：工作者为了尽快收尾，容易把交接清单里的几项一律填”无”，尤其是”未解决的疑虑”这种最不愿意承认不确定的项——一旦该报的安全项被漏报，“安全项非空必读”这道闸门就被空过去了，机制形同虚设。
对策是加了一个 security-scan.sh：全局者审查前先跑一遍，纯本地 grep 扫 diff 里新增的行和未跟踪的新文件，零 token，客观触发——不再单靠工作者自己判断”这算不算安全相关”。
slash 命令改了名
最初的切换命令叫 from-worker / from-overseer，语义是”从 X 角色切过来”。后来改成了 as-overseer / as-worker——“我现在要以 X 角色行动”，读起来更直觉，键盘上 a/s 相邻打起来也顺手。纯命名调整，不影响功能。
一点感想
这套工作流最开始只是想解决”单模型上下文耗尽、角色混乱”这两个具体问题，跑起来之后反而不断在暴露新的薄弱点——工作者自报不可靠、子代理会因为启动目录悄悄失效、风险不该被一视同仁地审查。回头看，这些补丁没有一条是一开始能设计出来的，都是先真的用坏了一次，才知道该往哪补。
完整规则见项目页面。