Deco 是京东推出的 AI 设计稿转代码工具，输入是设计文件，输出是 Taro、React、Vue 等框架的页面代码，中间做组件识别、语义化命名和自适应布局。它解决的是前端最枯燥的一段活：把视觉稿还原成结构正确的页面。但「能生成」和「能上线」是两件事，适用范围划不清，省下的时间会以返工的形式还回去。这篇讲清它在哪类页面上真好用。
它到底做了什么
流程可以拆成三步：先解析设计文件里的图层，把矩形、文字、图片归类成盒子与文本节点；再按位置和间距推断布局关系，生成弹性或栅格结构；最后套用组件库，把按钮、输入框、卡片映射成现成组件。三步里最难的是第二步——设计稿里没有「这是导航栏」这种标注，工具只能靠位置和命名去猜。猜对了省事，猜错了就是一堆写死坐标的 div。前端工具链的整体分工，插件与命令行怎么选一篇有对照。
好用的三类页面
第一类是中后台的列表页、表单页、详情页：结构规整、组件标准、交互简单，生成后基本能直接用。第二类是营销活动页：一屏一个模块，图片加文案，还原度高。第三类是原型验证：产品要快速看效果，先生成再改，比手写快得多。这三类的共同点是「布局规则、交互轻」。
| 页面类型 | 为什么好生成 | 生成后要做什么 |
|---|---|---|
| 中后台列表、表单、详情页 | 结构规整、组件标准、交互简单 | 基本能直接用，只做结构微调 |
| 营销活动页 | 一屏一个模块，图片加文案 | 换素材与文案，还原度高 |
| 原型验证 | 只要快速看到效果 | 先生成再改，比手写快 |
必须人工接手的四类
强交互动效、复杂状态管理、需要精细无障碍标注的页面、以及设计本身不规范（图层混乱、命名随意）的稿子。前两类的问题在于工具只能还原静态结构，逻辑要人写；后两类的问题在输入端——稿子本身不干净，生成的代码只会把混乱放大。判断方法很直接：打开设计文件看图层命名，如果连设计师自己都要猜，就别指望工具能猜对。
怎么用才不返工
把工具放在「出初稿」的位置，而不是「出成品」的位置。约定好设计规范（间距、字号、组件命名），生成后只做结构微调与逻辑补全，效率提升最明显。反过来，如果团队没有规范、每次都是自由发挥，生成结果会一次次推倒重来，还不如手写。想系统练这套流程，用项目学编程一篇的思路可以借用。
和低代码平台的分界
两者都能「少写代码」，但解决的问题不同。设计稿转代码是把视觉还原成结构，产出的是页面骨架；低代码平台是把数据、权限、流程可视化配置，产出的是能跑的业务系统。做营销页、活动页，前者快；做内部管理系统，后者快。混用的场景是：用低代码搭框架，用设计稿转代码补自定义页面。国内同类工具怎么选，文心快码一篇可以对照着看。
Deco 适用速查
- 三步链路：图层解析、布局推断、组件映射
- 好用：中后台列表表单、营销活动页、原型验证
- 难用：强动效、复杂状态、无障碍要求高、稿子不规范
- 定位是出初稿，不是出成品
- 前提是设计规范统一，否则返工大于收益
关于 Deco 的三问三答
- 生成的代码能直接上线吗？：静态页面接近可用，带交互与数据逻辑的部分必须人工补。
- 支持哪些框架？：常见的是 Taro、React、Vue 这几类，具体支持范围以官方说明为准。
- 设计稿不规范也能用吗？：能生成，但结构会很乱，整理稿子的时间往往超过手写。
补一句：稿子的规范程度决定成败。先把间距、字号、组件命名统一，再谈自动化；规范没统一就上工具，返工的时间会超过省下的时间。
