UI标注与切图怎么交付？Pixso D2C指南

用 Pixso 交付 UI 标注与切图，先让研发打开同一份设计文件，检查尺寸、间距、样式和可导出资源；需要页面代码时，再用 D2C 生成结果接入项目。设计师仍要说明状态、布局规则和变更范围，研发仍要完成接口、业务逻辑与页面验证。把这些信息放在同一条交付链路里，比反复发送截图和压缩包更容易找到问题。

在Pixso 的 UI 设计协作流程中，设计文件既是视觉依据，也是双方讨论组件与资源的共同入口。以下沿用音乐 App 的设计稿，看看“创建歌单”弹窗、列表封面和按钮状态怎样交给研发，以及 D2C 能接手哪些工作。

1. Pixso D2C 与标注、切图分别负责什么

标注与属性检查回答“页面应该是什么样”，切图交付回答“实现要用哪些资源”，D2C 则把已有设计结构、布局和样式转换为代码。三者可以接在一起，但拿到代码并不意味着交付信息已经完整。

（1）从静态图层到可实现的界面

一张包含图标、标题和背景的卡片，可以提供视觉结构，却不一定说明点击后去哪里、标题超过两行怎么办、图片加载失败时显示什么。设计师应把这些规则放在对应页面或组件附近，让研发能把设计对象和行为一一对照。

例如创建歌单弹窗，除了输入框和“取消”“创建”两个按钮，还要说明名称为空时的处理、提交中的反馈、关闭后是否保留输入。D2C 结果可以作为页面实现的起点，这些业务规则则需要继续落实到代码与测试中。

（2）研发模式：查看参数、资源与代码的入口

进入研发模式后，开发者可以选中目标图层，查看尺寸、间距和样式信息，并处理切图与代码。下面的设计稿中，左侧定位到封面图层，右侧显示它的宽高、圆角和 CSS 信息。交付时应把具体图层交给研发，而不是让对方在整份文件里猜哪一块需要实现。

当前 D2C⁺ 需要企业版全功能席位或研发席位，目标文件须位于企业空间，包括该空间下的个人草稿。普通参数查看、切图和 D2C⁺ 不是同一项权限，不应把能打开研发模式理解为能调用所有代码生成功能。

2. 传统 UI 交付容易卡住的三个环节

交付中的返工通常不只来自“抄数值太慢”，更常见的是说明缺失、对象不清或资源版本不一致。

（1）标注与设计稿分开维护

如果设计师另外制作一份静态标注文档，设计变动后就要同步维护两处内容。在同一设计文件中查看属性，可以减少重复录入，但弹窗出现条件、长文字处理和响应式规则仍需要说明，不能把这些判断也省略掉。

（2）开发者需要猜测布局规则

拿到一个间距数值，只能知道这一张画板上的距离。研发还需要知道容器变窄时是否换行、按钮是否固定宽度、列表封面如何裁切。微小的理解差异会变成反复的 UI 调整。对音乐 App 来说，长歌单名能否换行、封面保持方形还是跟随容器伸缩，都应在实现前说清楚。

（3）切图资产的命名与版本混乱

“icon_search_v2_final.png”这样的名称难以说明资源用途和当前版本。项目同时涉及 iOS、Android 与 Web 时，格式、倍率和引用路径还可能不同。交付前统一资源命名、导出要求和更新说明，能减少拿错图片、重复导出和压缩包互相覆盖的问题。

3. 在研发模式中完成四项交付准备

先交付可以定位、可以查看、可以解释的设计，再决定代码生成的范围。不要一次导出整份文件后才开始寻找缺失状态。

（1）切换模式，并确认目标画板与状态

打开目标设计文件，使用右上角的研发模式开关。交付链接应能定位到本轮需要开发的画板或图层，同时确认研发人员有访问权限。音乐 App 中的“歌单”“创建歌单”“新歌单”是不同画面，不能只发文件首页而不说明当前要做哪条流程。

（2）交代自动布局与窄屏行为

自动布局有助于表达排列、间距与伸缩关系，但它不是所有屏幕自动适配的保证。以弹窗为例，需要约定最小留白、输入框伸缩、按钮排列和长文本的处理；生成代码后，再用实际窄屏与较长歌单名检查一次。不要仅凭设计稿设置了自动布局，就跳过浏览器中的响应式测试。

（3）分别整理图片资源与代码输出

封面照片、搜索图标和界面布局不是同一种交付物。图片资源先确认格式、尺寸和裁切范围；需要导出的图层应设置相应导出属性。研发可通过切图面板获取资源，发现面板为空时，先检查是否选中了具有导出属性的对象。

• 封面照片：说明使用尺寸、裁切焦点和空缺时的替代内容，避免导出后拉伸。
• 界面图标：确认是否用项目已有图标库；确需交付图片时，再约定 SVG 或 PNG 等格式与倍率。
• 页面代码：当前 D2C⁺ 支持 React、Vue 和 Flutter。按项目技术栈选择输出，不把右侧样式片段与完整页面代码混为一谈。

在研发模式右栏的 D2C 下拉菜单中选择 D2C⁺，再选中设计稿或元素生成代码，具体入口与权限见D2C⁺ 快速开始。通过 MCP 调用时，design_to_code 工具说明还列有 HTML、ArkUI 等输出。鸿蒙项目可以继续参考ArkUI 界面实现流程，生成后仍要完成目标工程的适配与设备验证。

（4）把视觉参数对应到项目规范

• 颜色：明确是固定颜色还是设计变量，并与项目里的变量名称对应。
• 字体：检查字体是否可用、字重与行高是否一致，同时准备缺字或字体缺失时的处理。
• 圆角与阴影：核对参数和实际效果，尤其注意不同背景、缩放和裁切下的差别。

项目已有按钮和输入框时，应优先复用组件。D2C⁺ 可通过 DSM 的组件解析器建立设计组件与代码组件的映射；不需要绑定组件库时，也可以直接生成。如何配置映射见DSM 设计系统管理。

4. 怎样判断标注与切图交付真的更省事

效率要看从设计准备到研发接入的总工作量，不能只统计点击生成按钮的时间。可以选一条已经熟悉的歌单创建流程，记录准备说明、获取资源、接入页面和修复问题分别用了多少时间，并把最终达到的质量要求保持一致。

（1）标注环节：减少重复录入，保留必要说明

在研发模式中直接查看属性后，不必再把同一组尺寸手抄到另一份文件。节省的是这部分重复工作，而不是设计交付的全部时间。弹窗关闭规则、空名称反馈和提交失败后的恢复方式，仍需要设计与产品确认。

（2）切图环节：让资源可以自行获取

设计师整理好可导出对象、命名和格式后，研发按需求获取资源。是否真的减少沟通，可以看有没有继续发生“漏一张图”“倍率不对”“拿到了旧封面”等问题。若仍频繁返工，应先改资产组织方式，而不是再多发一份压缩包。

（3）UI 实现环节：把接入与修复计入结果

代码能复制出来，不等于已经复用了项目组件。要检查生成结果接入现有路由、按钮和输入框之后，还需要改多少布局、替换多少组件，以及空态、失败和长文本有没有补齐。相关检查可继续参考D2C 代码接入与质量检查。

5. 团队交付中容易忽略的三种情况

场景 A：敏捷开发团队的异步交付

远程或跨地域协作时，设计师可以把目标画板、变更说明和待确认问题一起交付，研发通过链接查看参数与资源。异步协作减少的是来回寻找文件和重复解释；涉及状态或业务规则的争议，仍要留下明确决定，而不是假设对方看图就能理解。

场景 B：设计系统更新后的版本对齐

品牌色或按钮组件更新后，先确认设计文件使用的资源库版本，再检查项目变量、组件解析配置和已实现页面是否需要更新。DSM 能维护设计与代码的对应关系，但这不等于外部代码仓库会自动接受每次改动，也不等于设计和代码已经双向同步。

建议把“设计版本、组件版本、代码提交”放在同一条变更记录中。若歌单按钮只改了圆角，就只处理相应样式与回归检查，不应重新生成整个页面并覆盖研发已经接好的创建接口。

场景 C：同一设计需要交给多个终端

iOS、Android、Web 或鸿蒙原生项目可能采用不同布局、资源和交互规范。可以共用设计意图和资源清单，但应分别确认目标框架、图片要求与运行环境。比如歌单弹窗的返回操作、输入法遮挡和封面加载，在不同设备上都需要检查；不能把生成的某一种代码直接当作多端完成品。

6. 研发接手 UI 的三条路径

根据已经有多少代码、准备复用哪些组件，选择本轮需要的接入方式；同一个项目可以在不同阶段使用不同路径。

• 参数与资源交付：现有页面只改按钮、间距或封面时，选中目标图层查看样式与尺寸，并取得所需切图。研发在原组件中实现变化，避免为一个局部调整另建一套页面。
• D2C⁺ 页面或组件生成：需要新增页面结构时，先选定目标画板与输出框架；有项目组件库就准备映射，生成后接入当前工程。对基础 HTML 实现的理解，可继续看设计稿与 HTML 结构的对应关系，不要把样式片段等同于完整业务功能。
• MCP 接入 IDE：在已有代码项目中，通过Pixso MCP让 Agent 读取指定设计对象，或调用 design_to_code 获取 D2C⁺ 结果，再按项目约束处理代码。工具调用、修改文件、执行测试和提交代码是不同动作，需要分别约定范围；接入 MCP 本身不会建立无人审核的代码同步流程。

7. 比较交付工具时，用同一条任务检验

团队如果正在比较 Pixso、Figma Dev Mode 或 Zeplin，应拿同一张设计稿和同一份交付要求判断，而不是只看功能名称或笼统的速度评价。已有工具是否顺手，与文件权限、项目组件、资源管理和团队使用方式有关。

• 已有 Figma 设计文件：检查设计组件与代码组件如何对应、研发怎样获取资源、修改后怎样通知到实现人员，再评估继续原流程或迁移的工作量。
• 已经使用 Zeplin 做交付：检查设计文件与交付版本如何更新、谁负责同步，以及研发能否明确区分当前版本和旧版本。迁移时保留仍有用的交互说明与资源清单。
• 在 Pixso 中设计与交付：可从同一设计文件查看属性、资源与代码，但仍要安排版本确认、代码接入与业务验收，不能省略这些责任。

8. UI 标注与切图交付常见问题

Q1：D2C 生成的代码，怎样判断是否容易维护？

先看是否使用项目组件、命名是否便于理解、样式是否存在重复，再看代码接入之后能否独立修改。图层语义清楚有助于理解设计，但不意味着类名必然逐字继承。出现中文乱码时，应检查源文字、文件编码、字体与构建处理，服务器所在地区不能保证所有环境都不会乱码。

Q2：有了 D2C，还需要前端开发做什么？

前端仍要处理业务逻辑、状态管理、接口与权限，并检查生成结果在项目中的表现。歌单弹窗能显示，只证明界面出现了；提交后能否正确创建、失败时是否保留输入、重复点击怎样处理，都属于实际功能的一部分。

Q3：怎样检查还原度，而不是只看一张截图？

先在约定宽度比较布局、字体、图标、间距和资源，再检查窄屏、长歌单名、空列表与失败状态。自动布局和组件映射有助于表达设计规则，但不会保证任意页面都达到相同还原结果。发现差异时定位到具体对象，局部调整后重新运行页面。

好的 UI 交付，是研发能找到当前设计、拿到正确资源、理解状态规则，并把变化接回正在维护的代码。先从一张熟悉的画板开始，整理标注与切图，再决定是否用 D2C⁺ 或 MCP 推进实现。打开 Pixso，整理一份可交接的设计稿。