设计稿转代码的交付流程可以分为五步：确定目标框架，整理图层与组件，生成界面代码，在项目中补齐交互和数据，最后检查视觉与运行结果。设计稿转代码工具提供的是实现界面的起点，不会自动完成登录鉴权、接口接入和上线验证。先从一个完整页面或业务区块开始，比直接转换整个产品更容易发现问题。
1. 设计稿转代码改变了哪些交付工作？
（1）从样式交接到可检查的代码
设计师完成高保真原型后，开发者需要把间距、色值、字体和布局关系落实到页面。D2C 可以把部分界面信息转换为代码，减少从空文件开始搭建的工作，但开发者仍要判断组件如何拆分、状态放在哪里，以及内容变长后怎样布局。
涉及响应式设计时，交付物不能只有一张固定宽度的画板。应说明哪些元素固定、哪些区域伸缩，以及窄屏时哪些内容换行或折叠。设计稿越清楚，研发越容易判断生成结果是否符合原意。
（2）标注、代码生成与组件映射各解决什么问题
三种交付方式可以接续使用：先读懂设计，再生成界面，已有组件库的团队进一步对接项目组件。它们的区别在于交给研发什么，以及后面还要补什么。
| 交付方式 | 研发拿到什么 | 接下来需要做什么 |
|---|---|---|
| 标注与资源导出 | 尺寸、颜色、间距、图标和图片 | 编写页面结构、组件与交互，核对资源路径 |
| D2C 界面代码生成 | 目标框架的界面结构与样式代码 | 适配项目依赖、路由、数据和状态，进行视觉与运行检查 |
| DSM 组件映射 | 设计组件与项目组件标签、属性的对应配置 | 维护解析器，确认组件引用、属性和业务用法正确 |
2. 哪些因素影响代码还原与交付质量？
（1）布局关系：不能只看一个固定宽度
绝对定位并非一律错误，浮层或装饰元素可以需要它；问题在于本应随内容伸缩的区域也被固定了坐标。整理设计稿时，优先表达容器、间距、对齐和内容伸缩关系。生成后把设备名称换成长文本、改变页面宽度，再看卡片、按钮与说明是否重叠，不能只凭初始截图接近就判断布局已完成。
（2）跨平台输出：先选入口，再确认框架
Pixso 的 D2C⁺ 客户端流程支持 React、Vue、Flutter；通过 MCP 调用 design_to_code 时，工具说明还列有 HTML 和 ArkUI 等输出。团队需要先确定自己使用的入口与目标框架，再检查生成文件及依赖，不把一种格式的代码直接放进另一种工程。
准备使用ArkUI时，仍需在目标鸿蒙工程中验证 SDK、组件属性、资源引用与页面路由。代码文件已经生成，不代表设备能力、权限申请和业务接口已接好。
使用 Pixso D2C⁺ 需要企业版全功能席位或研发席位，目标文件须在企业空间内，包括该空间下的个人草稿。先确认这些条件，再安排团队试用。进入 Pixso 查看设计文件
3. 从设计稿到项目代码的五步流程
以一个设备列表页为例：页面有设备卡片、在线状态和添加设备入口。先完成这一页的界面交付，再连接真实设备数据，不要同时生成所有页面并混入接口改造。
第一步：确定代码框架与生成入口
打开企业空间中的设计文件，进入研发模式，在右侧 D2C 下拉菜单中选择 D2C⁺。如果工程使用 React，就按 React 路径生成；Vue、Flutter 项目选择对应输出。使用 MCP 时，在指令中明确框架和图层链接。
第二步：把工程约束写清楚
说明项目使用的语言、样式方案、组件目录和现有依赖。已有团队组件库时，先确认是否需要在 DSM 中配置设计组件到代码组件的映射。没有绑定代码库的需求，可以先生成界面，不必为了开始试用而额外创建解析器。
第三步：选择最小但完整的业务容器
设备列表页应包含页面标题、卡片、状态与主要操作，而不是只选中某张设备图片。检查选区和图层名称；通过 MCP 提供链接时，使用带 item-id 的图层链接，避免只给页面链接导致目标不明确。
第四步：对照设计与代码逐项检查
查看组件结构、样式和资源引用，核对设备卡片是否可复用，在线与离线状态是否有对应表达。运行页面后检查长名称、空列表和窄屏布局。发现重复样式或不合理的固定尺寸时，明确指出要调整的区域，不用整页重新生成来修一个按钮。
第五步：接入工程并验证业务路径
将生成结果放入独立分支，按项目方式安装依赖、接入路由与数据。设备卡片的点击、添加设备、加载中、失败重试和无权限状态需要分别检查。通过构建、代码检查、交互测试和设计走查后，再提交合并；下载到本地不是上线完成。
4. 冗余代码、命名与上线边界
（1）如何处理冗余代码与命名混乱？
先把图层 1、矩形 2 等名称改成可辨认的对象，再检查生成的组件是否按职责组织。需要复用项目按钮、卡片和输入框时，通过 DSM 的别名及组件解析器建立对应关系。生成后仍要检查类名冲突、重复样式、重复组件和未使用资源，不能把自动生成等同于已经完成代码整理。
（2）自动生成的代码可以直接上线吗？
不能只根据生成成功作出上线判断。D2C 主要帮助构建界面结构与样式；业务逻辑、接口调用、状态管理、权限和安全要求需要结合项目实现。设计稿中没有说明的加载、失败或禁用状态，也不能默认已经生成完整。
对交付效率的判断，应看同一任务从整理设计到完成合并实际用了多久，还要计入生成后的修改和测试。不能仅统计代码生成时间，就推导整个开发周期减少了固定比例。
5. 用 AI 继续完善生成结果
通过 Pixso MCP 完成设计转代码后，可以继续选择响应式布局、CSS 变量、代码精简和对齐项目设计系统等优化方向。已有组件解析配置时，先核对设计实例与代码组件的对应关系，再要求 Agent 调整；不要让一次视觉修改同时更改已经确认的数据结构。
例如设备列表在窄屏出现横向滚动，可以要求：“只调整设备卡片和操作区的布局，保留设备名称、在线状态与点击行为；在窄屏让卡片换行，不修改数据请求。”这类有对象、有保留项的指令，比“把代码再优化一下”更容易检查结果。
代码预览、设计稿和运行页面是不同的检查对象。先核对生成的文件与引用，再运行页面观察交互；AI 的修改也应保留差异记录，并检查相邻组件是否受到影响。
6. 常见问题解答
问：设计稿转代码能保证像素级还原吗？
答：不能用固定还原率概括所有页面。字体加载、图片资源、容器约束、真实内容和运行环境都会影响结果。应在相同尺寸下对照设计稿，再检查窄屏、长文本与不同状态；初始截图接近并不代表所有场景都一致。
问：生成代码会不会让页面加载变慢？
答：需要检查实际产物。图片体积、字体、依赖、重复资源和渲染逻辑都可能影响加载与运行表现。先在项目中构建并检查资源请求，再决定压缩、延迟加载或组件拆分，不能仅凭代码行数判断性能。
问：如何选择前端框架和输出方式？
答：沿用已有工程的技术栈。D2C⁺ 客户端流程和 MCP 的 design_to_code 工具提供不同入口；涉及 HTML、ArkUI 等输出时，可从 Pixso MCP 设计转代码指令确定调用方式，再在对应工程环境中验证，不把代码包当作已经配置好的完整应用。
把设计稿转代码接入团队流程时，先选一个有正常、空白和失败状态的页面，完成生成、接入、检查和交接。这样更容易看清工具帮忙完成了哪些工作，以及团队仍需承担哪些开发任务。打开 Pixso 开始整理交付页面
