Workbench 大改版 · 执行方案
「一步到位」的真正难点不是画得好看，而是设计出来的东西能开发、 该有的功能一个不漏。所以这份方案的重心不在阶段划分，在三道防线。
带橙色节点的是闸门——不过闸不许往下走。
tech-lead-agent · 独自先行
必须排在设计之前。原因很实在：设计只能按后端真实返回的数据来画， 画了不存在的字段，就是给自己挖坑。
design-agent ＋ dev-agent · 同时开跑
两边碰不到彼此：设计只写 design/，开发只写 apps/web/。
设计基于场景清单和字段契约表，出可点击的交互稿，桌面和手机两套共用一套信息层级。
tech-lead ＋ 总控 · 双向审查（闸门）
这一关专治「设计出来没法做」和「功能漏了」。两条都过才放行。
dev-agent → qa-agent → 你
按定稿实现。开发遇到稿子没说清的地方，回去问设计，不许自己发挥—— 这是过去返工的主要来源。
对应你说的「不要设计的东西无法开发，或者有的功能没被设计实现」。
所有角色读同一份场景清单（已固化成文件，含全部界面场景、 真实字段边界、三条安全红线、六项作废的假功能）。
关键在于它写明了哪些数据根本不存在——比如系统里没有 「agent 在线状态」、没有「单条消息已读」、没有「每一步耗时」。 设计里出现这些，就是凭空捏造，审查时直接打回。
设计遇到「这个能不能实现 / 有没有这个数据」，写进待澄清清单，由 tech-lead 回答， 不许自己假设一个答案继续画。开发遇到「稿子这里没说清」，同样回去问设计。
我在中间做协调：传递问题、盯住任何一方不要自行拍脑袋。问题清单不清空，不进下一阶段。
设计交付时必须附覆盖对照表：场景清单里每一个场景， 对应稿子里哪一屏、哪个状态。
漏掉不算漏，写明「本期不做 + 为什么」才算数。 静默漏掉一条，验收直接打回——这比事后发现少做了一个状态便宜得多。
每个角色都是平台上的独立实体，可以换引擎跑，也可以你直接找它对话。
| 角色 | 负责 | 不负责 |
|---|---|---|
| tech-lead | 框架选型、架构、字段契约、回归保障方案设计稿的可实现性审查 | 不画界面，不写产品代码 |
| design | 交互稿、设计系统、覆盖对照表桌面 + 手机两套，共用一套信息层级 | 不定技术选型，不写产品代码 |
| dev | 骨架重构、按稿实现、几何与状态测试 | 不自行改设计，不自行改架构 |
| qa | 独立回归复核，红线守卫 | 不代替你做验收 |
| 总控（我） | 协调、传递问题、覆盖度审查、派发与监督不让任何一方自己拍脑袋 | 不代做任何角色的活，不替你验收 |
换来：改哪块只影响哪块，多个 agent 能真正并行， 不再有「改一处崩一处」和每轮开工前的基线校验仪式。
失去：现在那套回归测试是靠直接读 index.html 的文字来检查的， 换框架之后大部分会作废。这是最大的风险——测试没了，就没人守着那三条诚实性红线。 所以阶段 01 必须先给出新的回归方案，这一条不能往后拖。
关于工期：「一步到位」和「快」是矛盾的。这次不会像之前那样几小时给你一版能看的， 前期在技术地基和交叉验收上花的时间会更多。我不会为了显得快而跳过闸门—— 跳过的代价你这几天已经付过一次了。