design

当交付内容应放在 Subframe 中时，使用此工作流。实现时使用 develop；将现有设计系统引入 Subframe 时，使用 import。

为什么以及何时使用 Subframe

为什么使用 Subframe。 为设计提供一个独立于代码分支的持久存放位置，方便团队成员查找、审阅和回看。在画布上并排比较不同方案和多屏流程。在修改代码前收集团队成员的意见。在设计旁边的设计文档中记录决策及其依据。当 Subframe 是事实来源时，从其中的主题和组件同步代码。

何时使用： 探索方向、比较选项、征求评审意见或创建可分享的成果，或修改多个屏幕或设计系统。

何时不使用： 对现有 UI 进行小幅修复，或只修改代码行为时，直接在代码中操作，除非用户要求使用 Subframe，或项目将设计保存在 Subframe 中。

步骤

1. 确定哪些内容必须保留，哪些内容需要更改。对于现有设计，阅读其实际内容并检查渲染效果。对于网站或代码库参考，使用来源平台的浏览或文件工具收集相关源内容和截图。仅凭文字描述不足以作为重现现有 UI 的可靠依据。
2. 选择能够满足需求的最小操作。直接编辑现有页面或片段；需要精确副本时则复制。创建新设计或方向有实质性变化时使用生成。确定预期产物是可复用组件、页面组合、用法示例还是书面指南。
3. 生成前准备好参考资料。提供实际源内容、图片或 Subframe 资源，并附上使用说明，解释哪些内容需要保留、哪些需要更改。如果源代码依赖子组件和样式，也应一并提供。在生成任务说明中写入这些指示；生成器看不到你的对话或推理过程。
4. 先完成依赖项，再处理使用它们的内容。如果页面需要尚不存在的可复用基础组件，先使用 design_component 创建。先完成独立基础组件，再处理嵌入它们的组件，之后再生成页面。一次性的页面组合应直接内联。不要在重现页面时擅自重建组件库。
5. 完成请求的屏幕和编辑后，检查最终结果。将截图与参考资料及所请求的更改进行比较，包括下方各区段、受影响的响应式布局和相关状态。报告前，修复缺失内容、裁切、间距和排版差异。

页面和流程

让每个方案的任务说明都自成一体。描述布局或重点的具体差异；不要要求某个方案照搬另一个方案。如果用户要求的方案数量超过单次调用的限制，就在同一画布上分多次调用，完成所需数量。

对于流程，先确定第一个屏幕的共享框架。wait_for_jobs 报告完成后，确认页面确实存在，并立即将其 ID 用作下一个屏幕的 sourcePageId。如果生成了多个备选方案，请自行选择一个连贯的起始方向，并说明后续采用了哪一个。指定下一个屏幕的差异时，保留导航和布局。不要等待用户选择。

现有设计

使用 update_node_styles 设置样式，使用 edit_page 或 edit_snippet 编辑内容或结构。从现有类和子树开始操作，以保留无关布局、子元素和文案。替换时，保留现有节点上的 data-node-id；新建或插入的节点不添加 ID。遇到过期 ID 错误后，重新读取受影响的资源，并重建编辑内容，而不要重试旧标记。

如果请求的更改属于共享组件，请使用 edit_component。检查有代表性的用例，了解更改效果。页面专属的调整应应用于该页面的实例或组合。

对于由评论驱动的编辑，请将每个请求的讨论串与其当前元素匹配，并跟踪已处理的反馈。若讨论串对应的元素已消失，应先解读反馈，而不是针对旧 ID 进行编辑。

主题与设计指导

重新设计样式时，更新现有令牌，让当前设计继承预期外观。保留语义角色和别名，不要创建外观相似的并行令牌。在受影响的模式下检查有代表性的页面和组件。对于需要确认的删除或替换操作，在请求确认前准备具体的令牌映射。要采用外部令牌源，请使用 import。

设计文档应记录未来设计师无法从 UI 推断的信息：何时使用某种模式、内容限制以及产品特定例外。更新现有指导并保留嵌入的示例。对于无需组件 API 的可复用示例或组合，请使用 design_snippet；不要为每个页面都创建文档或示例。

审核与恢复

作业完成后，对更改过的页面使用 screenshot_page 截图，对更改过的组件使用 screenshot_component 截图。对于代码片段，如果有现成页面用例，请在其中检查；不要仅为验证而额外创建页面。说明任何缺失的视觉覆盖情况。

在认定编辑成功前，先查看解析器警告和应用结果。如果内容被丢弃或规范化处理而消失，请更直接地表达预期的静态设计。被屏蔽的“Something went wrong”错误并不能证明没有发生更改：重试创建前，请检查目标位置和作业状态。只重试缺失的工作，并报告持续失败所涉及的资源以及返回的任何作业 ID。