D2C 探索及使用体验

临近年底，需求多到让人怀疑人生，领导也是连续两周都在嫌我打螺丝有些慢了。为了提高开发效率，我把一些 UI 上的工作交给了内部提供的 D2C Agent，效果令人惊艳！

五个页面 + 业务逻辑实现，一共用了不到半小时！其中：

D2C 产出初版代码花了十来分钟左右。UI 还原度可以达到 80% 以上，且由于在提示词中我已经加上了相关的业务逻辑，所以最终的功能完成度也能达到 90% 以上！
剩下十来分钟的时间，就是 AI 善后工程师（没错，就是本人）的 show time。主要是将一些样式细节和交互细节进行优化（感觉自己成了个边角料😭）。

这速度、这效率简直让人可怕。难道前端真的要失业了吗？zeng～zeng～可怕😨

话说回来，有些小伙伴可能还不曾了解过 D2C，这里我给大家再介绍一下相关概念：

D2C 全称 Design To Code，顾名思义，它是可以将设计稿直接转换为前端代码的技术。这种技术打破了前端开发人员的传统工作模式：

除此之外，D2C 在一定程度上更是打破了职责划分，设计师、产品甚至后端人员，都可以通过 D2C 技术实现前端代码。对于整个开发流程来说，这无异提高了开发效率、节省了大量的开发时间。

Screenshot-to-code 是在之前的文章中介绍过的一款 D2C 产品，如之前的文章所说，虽然它存在一定的局限性，但并不妨碍它在一些特定场景下能发挥出意想不到的作用。详细可以查看👉《虽然 V0 很强大，但是 ScreenshotToCode 依旧有市场》。

没有细究过这个 Agent 的实现原理（再说细究了也不能发出来😄），只能猜测和 ScreenshotToCode 以及 Figma MCP 大差不差。

在 ScreenshotToCode 中需要多模态模型，这是因为需要 AI 去分析理解这些图片，然后再生成代码。整个流程是：图片输入 → LLM理解 → 直接输出代码。
Figma MCP + CC（或者其他 AI 编辑器）可以将 Figma 设计图直接转为可用的 HTML/React/Vue/CSS 代码。先通过 MCP 将 Figma 设计稿转为结构化数据，再将数据交给 AI 进行代码转换。详见《D2C 的另一种选择—Figma MCP + Claude Code》。
还有一些早就存在的转换技术，这种并不需要借助 AI，比如 58 同城在 20 年 9 月开源的 Picasso。它的工作原理就是先解析 Sketch 设计文件，提取图层、样式、布局等信息，然后将其转换为内部DSL，并对其进行样式转换，包括单位转换（px→rem/rpx）、平台特定属性处理等，最后根据转换后的DSL生成对应平台的前端代码。

从模式上来看，D2C 的方式有四种：

早期类似 Picasso 这种，通过底层算法将设计稿先转为 DSL，再将 DSL 转为前端代码（但它只服务于安卓）。即先将设计稿转为特定数据结构，再将其转为代码。
低代码平台其实也是 D2C 的一种，设计师或者产品可以通过托拉拽的方式进行一些页面设计，并导出对应代码。
再就是利用多模态模型理解和分析图片组成，再通过代码进行“复原”，例如 ScreenshotToCode。
最后一种可以说是第一种方式的改进版，设计稿被转化为特定数据结构之后，通过 AI 来读取和分析这些图层数据，然后输出成用户指定的代码。比如通过 Figma MCP + Claude Code 实现设计稿还原。

D2C 带来的收益是巨大的：

打破了传统开发中的协作壁垒和角色边界：
- 传统开发中，从设计稿到代码，需要人工校对，整个过程可能会出现一些细微偏差。D2C 通过 AI 加持，实现了像素级别的还原，减少了沟通成本和开发成本。
- 甚至说产品经理可以在原型设计阶段，就通过 D2C 技术生成一份基础代码，前端只需要进行一些“善后”工作。
成倍增长的开发效率：还原设计稿的时间被大大缩短，前端开发人员可以将更多的精力投入到业务逻辑和细节调整上
打破技术栈的僵化边界：可以指定它用 Vue、React、Angular、小程序等框架进行开发。

同时也带来一些挑战：

当然这并不是说会取代前端工程师，而是将其从重复劳动中解放，更聚焦于：

AI 的迭代日新月异，不管是前端还是后端开发，都要紧跟步伐，这样才不会被技术更新所淘汰。