判断设计稿转代码的质量，先把生成结果放进目标项目运行，再检查组件结构、布局、资源、状态和维护成本。预览接近设计稿只是第一项；缺少接口、交互或异常处理的页面，不能据此判定为可上线。使用 Pixso AI 或 D2C 生成界面后，可以沿着下面的检查顺序，逐项记录问题与修改结果。
1. 评估 D2C 的核心质量标准是什么
评价生成代码，不能只看预览效果，还要深入源码和运行行为。先检查这四个维度：
- 语义与组件：名称是否能表达用途；按钮、链接和输入框是否用了合适的元素；重复区域能否由同一组件维护。
- 代码结构：是否存在无作用的容器、重复样式、未使用资源和难以追踪的覆盖规则。
- 工程适配：导入路径、依赖、类型、路由和组件用法是否符合目标项目，能否通过构建与代码检查。
- 布局与状态：长文本、窄屏、空数据、加载与失败时是否仍可阅读和操作。
2. 不同框架的生成结果分别检查什么
通过 Pixso MCP 的 design_to_code 可请求 HTML、React、Vue、ArkUI、Flutter 等代码。D2C⁺ 客户端快速开始则介绍了 React、Vue、Flutter 路径。先明确入口、框架和目标工程；不要拿一个格式的预览结果推断其他框架也通过了验证。
设计转代码能力需要企业版全功能席位或研发席位，目标文件须位于企业空间内。没有权限或选错文件时，应先处理权限与目标，不能把“没有生成代码”归为代码质量问题。
（1）鸿蒙原生（ArkUI）：先过工程检查，再看界面
在目标鸿蒙工程中检查生成的页面、组件和资源文件，确认 SDK、模块配置与引用关系匹配，再运行页面。
- 结构检查：查看容器的排列、尺寸、间距与组件属性，检查代码引用的类型和资源是否存在；出现编译错误时先定位具体文件与属性。
- 运行检查：对照同尺寸设计稿观察字体、对齐、裁切和滚动，再尝试长内容与不同设备尺寸。是否可用以这些检查结果为依据，不把生成成功换算成某个还原百分比。
（2）Web 框架（React/Vue）：布局与业务组件分开看
绝对定位可以用于浮层和装饰，不宜替代所有内容布局。关键是区分固定对象与需要随内容伸缩的区域。
- 布局检查：在生成的 React 或 Vue 页面中改变容器宽度，输入长名称，检查列表、按钮和说明是否重叠。即使设计稿使用了自动布局，也要看生成结果是否保留了正确约束。
- 命名检查：搜索框、聊天卡片和底部导航应有可辨认的职责。若仍有大量 Frame、Group 等通用名称，先辨认其用途，再按项目约定命名；不要假设工具已经理解所有业务语义。
（3）Flutter：查容器职责，不只数 Widget 层数
较深的 Widget 层级不必然有问题。先判断每层是否承担布局、样式、滚动或交互职责，再考虑合并。
- 检查重点：确认依赖和资源路径可解析，运行后检查溢出、滚动与长文本。移除无作用的包装前，先确认不会改变约束、点击区域或状态更新范围；性能应通过实际运行观察，不能由“代码更扁平”直接推断。
3. 命名、组件复用与弹性布局怎么检查
（1）语义化命名与组件对应关系
图层名称、设计组件名称和代码组件名称是三种信息。把设计中的卡片命名清楚，有助于辨认用途，但不代表生成结果已经自动导入项目的 Card 组件。需要绑定代码库时，在 DSM 中设置别名和组件解析配置，再检查生成的标签、属性与导入语句。
（2）布局关系：从固定坐标检查到内容变化
以聊天列表为例，头像可以固定尺寸，消息摘要应在剩余空间中排版，时间和未读数不应被长昵称挤出屏幕。检查源码中哪些区域使用固定宽高，哪些区域能伸缩，再与设计意图逐项对应。
可以把一个昵称替换为较长的中文名称，将未读数从个位改为三位，并把消息内容设为空。分别记录是否出现截断、重叠或误触，再修改相关布局。一次拉伸没有出错，不足以说明所有响应式场景都正确。
4. 在研发模式中获取标注与代码
在 Pixso 研发模式下查看目标图层的尺寸、间距和样式，再与生成代码及运行结果比较。设计标注描述的是设计对象，不等于浏览器或设备已经按相同方式渲染。
- 框架与组件：确认输出框架与工程相符，检查引用的组件是否存在，组件属性与事件是否已经接入业务。
- 资源与路径：核对图标、图片和字体是否齐全，路径能否解析，是否重复加载。需要导出设计资源时，可通过 MCP 的
get_export_image获取相应图层资源，不默认所有资源已按项目要求处理。
5. 提高代码可维护性的三个做法
图层命名、自动布局和样式变量，是整理设计稿时可以优先处理的三项内容：
- 按职责命名：区分页面、列表、卡片、状态和操作，避免同名对象分散在多个不相关的层级。代码命名还要遵循现有项目约定。
- 表达布局约束：用容器和自动布局说明排列、间距与伸缩关系；生成后继续检查长内容、窄屏和隐藏元素，不把开启自动布局当作质量保证。
- 核对样式变量：整理颜色、文字和间距的命名，检查生成代码是否引用预期变量。需要时继续要求 Agent 提取 CSS 变量，再核对变量值和使用范围，不默认自动生成完整主题配置。
6. 常见问题与技术排障
Q1：为什么导出的代码有大量绝对定位？
- 先看用途：如果对应浮层或装饰，它可能是合理实现；如果聊天卡片、正文和按钮全靠坐标摆放，就需要检查容器约束与内容伸缩。
- 处理顺序：先整理设计中的父子层级和自动布局，再重新生成受影响的区块。通过 MCP 完成代码生成后，也可选择响应式布局优化；最后仍要运行页面检查，不是只要开启自动布局就会自动修好。
Q2：怎样让生成结果复用 Ant Design 或 Element Plus？
- 建立映射：D2C⁺ 可通过 DSM 的组件解析器，把设计组件映射为项目中的组件标签与属性。可以手动配置，也可以让 MCP 辅助生成配置；不能仅在提示词里写一个组件库名称就视为绑定完成。
- 检查产物：逐项检查导入路径、组件名、属性和图标。再试一个不同尺寸、状态或文案的实例，确认输出的是目标代码组件，而不是仅用 <div> 等普通元素拼出接近的外观。
Q3：ArkUI 代码可以直接在 DevEco Studio 中运行吗？
- 先检查工程条件：把生成文件放入目标工程，核对 SDK、模块、资源、页面路径和依赖，通过编译后再检查运行结果；没有这些步骤，不能判断是否可直接运行。
- 再接业务：鉴权、接口、状态管理、硬件能力和异常处理需要按项目需求实现。生成界面代码不代表这些能力已完成，视觉接近也不等于工程质量通过。
接手一份 D2C 代码时，保留生成版本和修改记录，把问题分为结构、视觉、交互和工程四类。能够说明每一项如何检查、如何修复，比一个没有测试条件的还原率更能帮助团队判断是否采用。在 Pixso 查看待交付的设计稿
