D2C工具的诞生背景

用 AI 工具把设计稿转成代码，还原效果一直不稳定：同一份设计，换个工具结果就不一样。一开始我们也怪过模型，后来发现只能怪一半——另一半在输入端，设计稿不标准，Figma MCP 读出来的元信息噪声就大。为了解决这个问题，我们做了 D2C，一个给 AI 生成的 UI 代码做复用决策的工具。这个系列记录做它的思路。

1.现象

同一个弹层，这次生成的边距是对的，下次换个描述就全漂移了；同一个表单项，A 工具认得出来，B 工具拆成三个散装 div。

结果不稳定有两个来源：输入是设计稿经 Figma MCP 读出来的元信息，消费是各家工具的模型理解能力和配套工程能力（harness）。两边都不稳定，凑在一起，结果就是开篇那种时好时坏。

2.三类噪声

设计稿的现状是命名随意、嵌套深、样式散装。MCP 只是搬运工，设计稿什么样，它就原样交出什么样，噪声主要有三类：

错位：视觉上是一组的东西，图层树里散在各处。最常见的是按钮：视觉上一个按钮，图层里是三个矩形加一行文字。MCP 交出来的是四个平级节点，结构关系从入口就错了。
缺失：圆角、间距、字重这些，有的写在样式属性里，有的只存在于像素里。“看起来是 8px 间距”实际是手摆出来的，MCP 只能读到一堆绝对定位坐标，读不到数值。缺失的部分只能靠猜。
冗余：隐藏图层、废弃的迭代版本、随手画的参考线，全躺在交付文件里。MCP 不做判断，照单全收。

噪声的来源可以画成这样：

flowchart LR
  nonStandard["设计稿不标准"] --> misalign["错位：结构关系失真"]
  nonStandard --> missing["缺失：数值只存在于像素"]
  nonStandard --> redundant["冗余：隐藏图层与废稿"]
  misalign --> noisy["MCP 元信息带噪"]
  missing --> noisy
  redundant --> noisy

这三类噪声都不在 MCP 这一层产生，MCP 越忠实，搬运得越完整。

3.消费端的差异

同样一份带噪的元信息，不同工具给出的结果不一样，跟输入没关系，差在消费端：

模型理解能力：“三个矩形加一行文字其实是个按钮”这种判断，需要视觉常识，有的模型跨得过去，有的跨不过去。
配套工程能力（harness）：做不做图层清洗，做不做结构归一，有没有组件库的先验知识，生成之后验不验。后者的差距往往更大，同一个模型配上清洗和校验管线，产出稳得多。

这也解释了为什么换个项目效果就不一样：项目自身的组件库沉淀和代码规范，本身就是配套工程能力的一部分。

flowchart LR
  noisyInput["带噪元信息"] --> goodTool["工具甲：清洗加校验"]
  noisyInput --> bareTool["工具乙：裸调直出"]
  goodTool --> usable["结果可用"]
  bareTool --> drifted["结果漂移"]
  projectBase["项目自身沉淀"] --> goodTool

4.为什么不动输入端

那为什么不从源头治理，让设计稿都标准化？因为成本结构不对。

一份设计稿的消费者不止研发：评审、验收、切图、运营复用，同一份文件服务好几个目标。为研发单独维护一套标准稿，等于让设计师干两遍活。而且由于大家并不属于一个团队,平时也不在一起办公,沟通成本非常高。

所以我们默认输入永远带噪，从我们自身角度思考能不能解决这些问题。

5.我们设计的架构

输入端动不了，能动的就是消费端。讨论下来，我们基于如下的架构,设计了一整套的 D2C 的工具：

flowchart TD
  noiseFilter["Figma噪声过滤"] --> reqIR["Requirement IR"]
  reqIR --> recall["知识库召回"]
  recall --> verdict["reuse/extend/new裁决"]
  recipe["Recipe与Slot有界扩展"] --> verdict
  implIR["Implementation IR：源码 AST"] --> revVerify
  verdict --> layoutProof["布局等价性证明"]
  verdict --> revVerify["反向提取验证"]
  layoutProof --> evolve["裁决数据促进系统演进"]
  revVerify --> evolve

Figma噪声过滤：输入端第一道，专门收三类噪声。错位做结构归一，冗余做清洗，缺失标出来往下传。
Requirement IR：过滤完的需求落成结构化的需求表达。后面所有环节只认它，不认原始设计稿，需求有一份唯一可信的版本。
知识库召回：拿着需求去沉淀里找候选，只找和排序，不下结论。
Implementation IR：代码侧的事实，从源码 AST 里抽出来，供给验证环节。验证的时候拿它当标尺：生成代码的结构，跟线上的真实结构对不对得上。
Recipe与Slot有界扩展：扩展的白名单。改属性、填插槽，哪些能动、动到什么程度，事先定好，之外的改法一律走新建。
reuse/extend/new裁决：拍板环节。结论只有三种，每种门槛写死，证据不够就降级，不断言。
布局等价性证明：验证的核心，证明实现出来的布局和设计等价。到这里，纸面结论才第一次接受实际检验。
反向提取验证：从生成的代码里反向抽事实，往回检一遍。正向判完反向验，两边对上了才算数。
裁决数据促进系统演进：每次裁决都留档，喂回知识库和规则。系统越用越准，靠的就是这条回流。

小结

下一篇讲链条的中间一段：从 Requirement IR 到复用裁决。