当前判断：先重新定义交付物，而不是继续优化命令
前面几轮方案执行不顺，并不完全是流程太重或命令太多，更根本的原因是：我们一开始把设计侧的交付目标定义错了。
原来的假设是：设计师借助 Agent，直接产出符合研发组件分层、能够进入生产代码的业务组件。
但在实际协作中，设计和研发理解的“组件”不是同一个概念：
- 设计侧按视觉、功能区域和交互完整性划分对象，例如导航栏、侧边栏、卡片、页面区块。
- 研发侧还要根据状态管理、数据边界、业务逻辑、复用范围和代码职责划分组件。
- 同一个侧边栏，设计可能把它看成一个完整模块；研发则可能将容器样式、历史列表、新建会话、收起按钮分别放进不同层级。
这不是设计师“不懂组件”，也不是研发的划分天然更正确，而是双方处理的问题不同。要求设计师在设计阶段提前做生产代码的组件拆分，本质上是把研发架构职责转移给设计，而且 Agent 也缺少足够的业务上下文做出稳定判断。
因此，当前更合理的目标应该改为：
设计侧交付的不是生产组件，而是受设计系统约束、可在浏览器运行和验收的代码原型。它相当于一种“可运行的 Figma”。研发再将其翻译、拆分并接入生产代码。
这里的“翻译”不再是研发凭截图重新猜一遍，而是在已有 React 结构、Token 取值、交互状态和视觉结果的基础上做工程化改造。设计意图已经从静态图片变成了可以检查、复制和运行的代码，研发只需要对生产边界负责。
建议：
我的建议不是做一个完全自由、与代码库无关的在线画布，也不是默认让设计师直接修改生产组件，而是在现有仓库中增加一个隔离的 Design Lab（设计实验区）。
每个设计需求对应一个独立的场景页面，例如：
design-lab/
└── changes/
└── chat-sidebar-redesign/
├── brief.md
├── spec.md
├── Scenario.tsx
├── fixtures.ts
└── handoff.md其中：
Scenario.tsx是设计师真正操作和验收的画布，可以是一张卡片、一个模块、一段侧栏，也可以是完整页面。fixtures.ts提供可切换的模拟数据和状态，不要求设计师接真实接口。spec.md用一个文件记录状态、设计 Token 和可复用原子组件，内部可以分为state / design / domain三个章节，不必强迫设计师理解三份工程文档。handoff.md记录已确认的视觉结果、交互说明、生产接入建议和仍需研发处理的事项。
Design Lab 应直接加载生产仓库里的 Token、图标和 L1/L2 基础组件，保证原型从一开始就使用真实设计资产；但它的页面组合方式不等于最终生产架构，允许研发在接手后重新拆分。
核心边界
设计对最终可见结果负责，研发对生产组件边界负责。 设计师需要确认样式、内容层级、交互和各种状态是否正确，但不需要决定某段 JSX 最终属于 L2 还是 L3。
为什么不建议一开始做“线上页面代理到本地”
直接代理线上组件到本地虽然预览最真实，但会同时引入登录态、接口数据、环境配置、跨域、线上版本差异和误改生产代码等问题。它适合后续处理存量页面的高级模式，不适合作为设计师第一次使用 D2S 的默认入口。
第一阶段更适合使用：真实 Token 和基础组件 + 本地模拟数据 + 独立场景路由。 等这条链路稳定之后，再补充针对存量页面的代理或组件替换能力。
D2S 应该按任务类型分流
不是所有需求都需要相同的流程。/d2s 启动后应先由 Agent 自动判断任务类型，并告诉设计师当前走哪条路径。
| 类型 | 典型需求 | 工作位置 | 最终交付 |
|---|---|---|---|
patch | 改颜色、间距、圆角、文案或局部样式 | 现有组件或现有 Design Lab 场景 | 可直接 Review 的小范围代码变更 |
prototype | 新卡片、新模块、新侧栏、新页面 | Design Lab 独立场景 | 可运行的代码原型，由研发工程化接入 |
translate | 根据截图、HTML 或 Figma 还原一版设计 | Design Lab 独立场景 | 受 Token 和原子组件约束的代码原型 |
只有边界非常明确、风险很低的 patch 才适合直接修改生产代码。新模块和页面默认进入 Design Lab，不要求设计师直接产出可合并的 L3 业务组件。
建议的渐进式流程
一键执行 /d2s start 直到启动预览的问题，是中间任何一步理解错了，错误都会一直放大到实现阶段。对非开发人员友好，不等于把过程全部藏起来；更合适的方式是减少工程术语，但保留几个能感知、能回退的自然阶段。
[一次性准备]
/d2s setup
|-- 安装依赖、检查运行环境
|-- 检查仓库权限和公司邮箱
|-- 检查 Design Lab 是否可以启动
v
[1. 说清要设计什么]
/d2s brief <自然语言需求>
|-- 判断 patch / prototype / translate
|-- 只追问会改变页面结构、状态或交互的问题
|-- 生成 brief.md，并用几句话复述理解
v
[2. 生成可运行原型]
/d2s design
|-- 生成单文件 spec.md
|-- 复用真实 Token、图标和基础组件
|-- 创建或修改 Design Lab 场景
|-- 自动启动浏览器预览
v
[唯一正式门控：设计验收]
/d2s review
|-- A：符合预期 -> 进入 handoff
|-- B：视觉或交互不对 -> 带反馈继续修改原型
|-- C：需求理解错了 -> 回到 brief 调整范围
v
[3. 交付研发]
/d2s handoff
|-- 审计硬编码、Token、原子组件和状态完整性
|-- 生成 handoff.md 和变更摘要
|-- git add / commit / push
|-- 创建 PR，由研发完成拆分、业务逻辑和生产接入这里仍然只有一个正式的 A/B/C 门控，但不会让 Agent 一口气做完所有事情。brief 阶段的复述只是低成本对齐，不需要设计师审核工程文档；设计师真正需要做决定的地方仍然是浏览器中的最终效果。
追问应该问到什么程度
追问的目标不应该是“确保 Agent 能写出三份文档”，而应该是：避免生成后才发现页面结构、关键状态或交互方向理解错了。
建议只追问会显著改变产物的问题：
- 这个模块给谁用，要帮助用户完成什么任务？
- 它出现在什么位置，上下游内容是什么？
- 除了正常态，是否存在空态、加载态、错误态、禁用态或超长内容？
- 用户可以进行哪些关键操作，操作后应该看到什么反馈？
- 是否有必须保留或必须复用的现有组件、视觉结构和文案？
- 本次要的是局部样式调整、独立模块，还是完整页面？
满足以下条件后就应该停止追问并开始生成：
- 能确定原型的空间范围；
- 能列出关键状态和关键操作；
- 能判断哪些现有资产必须复用；
- 剩余不确定项可以通过合理默认值实现，而且修改成本低。
不要追问组件该拆成几层、文件放在哪里、状态由哪个生产组件管理。这些属于研发接入阶段的问题。
新旧流程的本质变化
| 维度 | 原流程 | 最初设想的 D2S | 调整后的 D2S |
|---|---|---|---|
| 设计交付物 | Figma 静态稿 | 可直接合并的业务组件 | 可运行的模块/容器/页面代码原型 |
| 设计关注点 | 视觉稿和标注 | 视觉 + 生产组件拆分 | 视觉、交互、状态、Token 使用 |
| 研发工作 | 看图还原 + 业务接入 | 主要做 Review 和业务接入 | 基于代码原型做工程化翻译、拆分和业务接入 |
| 双方共同语言 | 图片、标注、口头说明 | 生产 React 组件 | React 原型 + 浏览器效果 + 规格摘要 |
| 组件边界责任 | 研发在还原时决定 | 错误地前移给设计 | 明确留在研发侧 |
| 验收时机 | 提测后末端走查 | 代码完成后验收 | 原型阶段由设计先验收，研发接手前收敛 |
这个调整不会完全消灭“翻译”工作，但会显著降低翻译的不确定性。研发不再从一张图猜 Token、状态和交互，而是从一份能运行的 React 原型出发，把已经确认的设计结果转成符合生产架构的代码。
这套方案能解决什么，不能解决什么
能解决的：
- 用可运行原型替代一部分 Figma 出稿和静态标注时间；
- 把视觉走查前移到研发接手之前，减少研发反复修改样式；
- 让设计结果天然使用真实 Token、图标和基础组件；
- 让交互、状态和异常场景成为可点击、可检查的交付物；
- 给研发提供比截图更完整、更少歧义的实现参考。
不能承诺的：
- 设计师生成的代码可以不经研发处理直接上线；
- Agent 能稳定判断生产代码的最佳组件颗粒度；
- 所有需求都不再需要 Figma，品牌探索、复杂动效和跨页面体验仍可能更适合 Figma；
- 研发不再参与样式工作，研发仍需保证响应式、可访问性、性能和生产集成质量。
建议拿去讨论的几个问题
和相关同学讨论时，不建议只问“这个方案行不行”，而是请大家分别对以下边界做判断：
- 交付边界：是否认可“设计交付可运行代码原型，研发负责生产化”作为第一阶段目标？
- 组件边界：哪些基础组件必须由设计复用，哪些模块组合允许设计自由搭建，哪些业务组件禁止设计直接修改？
- 仓库形态：Design Lab 应该放在生产仓库、组件库文档站，还是独立原型仓库？哪一种最方便复用真实 Token 和组件？
- 研发接入：研发应该直接从原型复制和重构，还是由 Agent 基于原型再生成一份生产实现 PR？谁对最终拆分结果负责？
- 存量修改：修改已上线页面时，第一阶段采用本地 fixture 复现，还是值得直接建设线上页面代理能力？
- 验收标准：设计验收通过后，研发是否还需要做一次视觉验收？哪些问题属于设计返工，哪些属于工程改造？
- 试点指标：用什么数据判断流程有效——设计出稿时长、研发样式工时、走查轮次、硬编码数量，还是从需求到可验收原型的总时长？
最需要先拍板的问题
第一阶段究竟要验证“设计师能否自主产出生产组件”，还是“代码原型能否比 Figma 更高效地传递设计意图”？建议选择后者。前者同时包含设计工具、代码架构和生产交付三类难题，试点范围过大，也会让组件颗粒度争议掩盖真正需要验证的价值。
建议的最小试点
先不要建设完整的页面画布或线上代理能力。选一个包含正常态、空态和交互态，但不依赖复杂接口的侧栏或业务卡片，完成一次完整闭环：
- 设计师用自然语言描述目标；
- Agent 在 Design Lab 生成独立场景；
- 设计师在浏览器中迭代并确认；
- 研发根据代码原型完成生产组件拆分与接入；
- 分别记录设计耗时、研发翻译耗时、走查轮次和 Token/组件违规数。
试点后重点回答两个问题：
- 与 Figma 交付相比，代码原型是否真的减少了设计表达和研发理解的总成本？
- 研发从代码原型到生产实现的“二次翻译”成本，是否小于过去从 Figma 到代码的还原成本？
只有这两个问题得到正向答案，再继续建设 /d2s handoff 自动生产化、线上页面代理和更完整的组件注册流程。