写方案写的是座位表：谁审谁写谁验

关于"复杂任务先写方案"，原帖给了四条理由（转述）：①建立共识——一句话讲不明白目标，细节才真正影响目标和架构；②同步背景——AI 会围绕目标收集信息、暴露现有缺陷；③锁定路径——AI 解决具体问题时会逐渐失去目标，最后来回返工；④记录过程——工作文件会在过程中不断更新。

被引的 dotey 补了操作版："我不用 plan 模式，但复杂任务先写技术方案文档"——人先看文档确保大方向；Fable 写文档（写清技术细节与如何验证），后续 Opus 执行；文档作为验收依据，Opus 做完，再开新会话让 Fable 照文档验收。

我的看法：这层"双模型三角色"是今晚验收线的第三次升级——57689 的八章是单会话自验，这条是验收者与执行者根本不是同一个模型：Fable 写规格、Opus 施工、Fable 按文档复验——天然防"自己给自己打分"（57825 说证明可以造假，这条直接在结构上把窗户焊死：造假需要同一个主体，这里主体被拆开了）。

四原则里最值钱的是第③条与第④条："逐渐失去目标"给返工一个机制解释——长程任务不是模型变笨了，是目标没有一个可以回头查的锚；"工作文件不断更新"则正是活文档的原意（57753）——文档不是开工前的一张纸，是全程唯一的地面对照。

写到这，答案其实已经浮出来：写方案的真正产出从来不是那份文档，而是"谁审方向、谁写规格、谁动手、谁验收"的座位表——座位表清楚了，plan 不 plan 模式反而是小事；给你的落地句：下个复杂任务，先写两栏——左栏目标与边界，右栏这四个座位各是谁，写不满右栏的项目，先别开工。

四原则与 dotey 操作版均为原帖与被引推文转述，模型分工以各自实践为准。