上一篇聊「设计稿端到端出码」（从 pix2code 到 Design2Code），结论是那条路最硬的核，是把二维视觉无损翻译成一维带层级的代码。这一篇换一条路：不追求端到端翻译，而是先造一套高质量、高还原的「物料」，再靠组合搭建出页面。 这条路看起来更工程、更可控——但它把难题换了个地方藏起来了。这篇想在动手之前，把藏起来的坑尽可能挖出来摆到台面上。
一句话主线
物料驱动搭建的命门，不是「物料够不够漂亮」，而是「业务逻辑既不在设计稿里、也不在物料里」。 谁想清楚这一点，谁才知道该把力气花在哪——以及该把「自动 vs 人工」的边界画在哪。
先记住这句，后面所有几十个坑点，都是它的展开。
立一个心智模型：一个「活」的页面 = 5 层
搭建范式最常见的错觉是:物料齐了，页面就出来了。 不对。一个能上线的真实页面，是这 5 层叠出来的：
| 层 | 它回答什么 | 物料库能覆盖吗 |
|---|---|---|
| ① 视觉物料 | 长什么样（按钮、卡片、表格、图表） | ✅ 物料的主场 |
| ② 布局关系 | 物料之间怎么摆（嵌套、间距、对齐、响应式） | ⚠️ 只能覆盖一半，本质欠约束 |
| ③ 数据 | 物料里显示的内容从哪来 | ❌ 不在物料里 |
| ④ 逻辑/交互 | 点了会怎样、联动、校验、跳转 | ❌ 不在物料里 |
| ⑤ 状态/边界 | loading / empty / error / 权限 / 超时 | ❌ 几乎没人画 |
一句话把它钉死：物料库最多把①做到满分、②做一半，而③④⑤ 既不在设计稿里，也不在物料里。
这就是「还原业务逻辑」这件事的根本困难——你手上的两个输入源（设计稿 + 物料库）都不含业务逻辑。它必须从第三个地方来：PRD、接口文档、或人工在搭建器里配。这个「第三输入」怎么设计，才是整套系统真正的胜负手。 下面的几十个坑，按这 5 层往下挖。
A. 物料本身怎么设计（地基，也是冷启动最痛的地方）
物料是这套范式的原子。原子设计错了，上面全塌。
- 粒度：原子（按钮）→ 分子（搜索框）→ 区块（整个筛选区）→ 模板（整页）。粒度太细，搭一个页面要拼几百个物料，组合爆炸；太粗，稍有不同就复用不了。这是第一权衡，且没有普适答案，只有「针对你业务的答案」。
- 职责边界：一个物料是「视觉单元」还是「逻辑单元」？纯展示的卡片和自带请求逻辑的「商品卡片」是两种东西，必须分开治理——否则纯展示物料会被业务逻辑污染，复用性归零。
- 可配置面（props schema）：一个物料对外暴露哪些配置项——尺寸、颜色、密度、变体、排列方向？暴露太多，等于没封装；太少，等于不可用。封装的艺术就是「藏对东西」。
- 状态覆盖：hover / active / disabled / loading / empty / error / 选中 / 只读……每个态都得有物料表达。缺一个态，还原时那块就是空白。
- 响应式责任归属：物料自己响应断点，还是由外层布局统一控制？这条边界必须一开始定死。含糊不清时，两边都做一点，叠加出来就是没人能 debug 的错位。
- Token 化 / 主题能力：物料消费 design token（颜色、间距、字号、圆角、阴影），而不是写死值——这样才能换肤、才能和设计系统对齐。这是「高还原」的技术前提，不是锦上添花。
- 质量门禁：「高质量」得能被卡口。还原度、可访问性（a11y，键盘/读屏）、性能（首屏/重渲染）、浏览器与跨端兼容——每一条都要能自动检测，否则「高质量」只是口号。
- 版本与演进：物料升级、废弃、破坏性变更时，已经搭好的成千上万个页面怎么办？向后兼容策略、灰度、批量迁移——物料是活的，页面依赖它，这是个供应链问题。
B. 物料的「可搭建性」元数据（决定它能不能被自动/AI 使用）
一个物料好用给人用，和好用给「搭建系统/AI」用，是两回事。后者需要一层机器可读的自我描述。
- 搭建描述 schema：每个物料要声明——可配置属性、插槽（slots）、抛出的事件、约束条件。没有这层，搭建工具和 AI 面对物料就是「睁眼瞎」。
- 语义标签：给物料打上语义（「这是商品卡片」「这是页头导航」「这是数据筛选区」），供设计稿匹配和检索用。视觉长得像不够，得知道它「是什么」。
- 组合契约：谁能嵌进谁、父子约束（表格行只能放进表格）、互斥关系（这两个物料不能同时出现）。没有契约，组合出来的就是非法结构。
- 容器/插槽机制：布局类物料如何接纳子物料，插槽的数量、类型、默认值约束。这是「组合」能成立的物理基础。
C. 设计稿 → 物料的匹配（这里，上一篇的 Design2Code 接了进来）
如果搭建的起点仍是设计稿，那就绕不开「识别」。这一整段，本质是上一篇那个 2D→结构 难题的翻版，只是答案空间被物料库约束住了。
- 识别：从设计稿里判断「这块该用哪个物料」——视觉匹配 + 语义匹配双通道，缺一不可。
- 覆盖率与 fallback：设计稿里出现了物料库没有的东西怎么办？降级成自由元素？还是提示「该建新物料」？覆盖率是这个范式能否落地的生死线——覆盖率 60% 和 95%，是两种完全不同的产品。
- 参数反推：识别出「这是个按钮」还不够，还得从设计稿反推它的具体 props——文案、主色、是主按钮还是次按钮、有没有图标。这正是 pix2code 当年「经常选错颜色」的老毛病，七年过去依然难。
- 一图多解：同一块视觉，能用不同物料组合拼出来。选哪个？最少物料数？最贴语义？最易维护？得有明确的择优准则，否则结果不稳定。
- 匹配置信度与人工介入：匹配不确定时必须有兜底流程，别让一个低置信度的错误匹配悄悄污染整页。把不确定性显式暴露出来，比假装确定更工程。
- 设计稿的规范性：设计师是不是按组件（Figma Components）来画的？规范的设计稿匹配率高；随手画的稿，识别难度指数级上升。真正的解法是把治理往设计源头推——让设计和物料库共用一套组件，而不是在末端硬猜。
D. 布局与组合（呼应上一篇「2D→1D 带层级」的天花板）
物料都识别对了，怎么把它们摆回原样，又是一道独立的难题。
- 布局模型选择：用 flex / grid / absolute 哪种来承载物料间的空间关系。选错模型，后面全是补丁。
- 像素还原 vs 布局意图：是还原绝对坐标（像素级像，但一改就崩），还是还原自适应意图（灵活，但可能偏离设计）？这是保真度的核心张力，没有免费的午餐。
- 嵌套层级推断：视觉上的「包含」关系（这个卡片在那个容器里）要正确翻译成 DOM 树层级。人眼一目了然，机器要显式推断。
- 间距与对齐体系：用 token 化的间距（8/16/24）还是硬编码像素？前者规整可维护，后者像素级还原但脆。
- 响应式推断（根本性欠约束）：一张设计稿通常只有一个尺寸。凭它怎么推断出手机、平板、宽屏下的行为？信息是缺失的——这不是算法不够强，是输入里根本没有。只能靠规则补，或要求设计师多给几套稿。
- 内容自适应与溢出：文案变长、列表 0 条或 1000 条、图片挂了——布局会不会崩。设计稿画的永远是「刚好的那一版」，真实数据不会配合你。
E. 业务逻辑（你最关心的，也是最难的一层）
到这里，物料和布局都解决了，页面「长得对」了。但它还是死的。让它「活」起来的所有东西，都不在前面任何一个输入里。
- 数据来源与绑定：物料字段 ↔ 接口返回结构的字段映射，以及 mock 数据 → 真实 API 的平滑切换。
- 交互逻辑：点击、跳转、弹窗、抽屉、二次确认、复制、下载——每一个都是设计稿上看不出来的行为。
- 跨物料联动：一个物料的变化驱动另一个（选了「省」→「市」下拉刷新→ 地图重绘）。这是纯物料组合最难表达的部分——因为联动是物料「之间」的关系，不属于任何单个物料。
- 逻辑编排：事件 → 动作的编排（低代码里那块「逻辑画布」）。简单的还能可视化配，复杂度一上来，可视化编排的成本迅速超过直接写代码。这是低代码的能力天花板所在。
- 表单体系：校验规则、字段联动、异步校验、提交、失败回填、草稿保存。表单是业务逻辑密度最高的地方，单拎出来都是个系统。
- 条件渲染与权限：什么条件下显示哪个物料，按角色/权限控制可见性与可操作性。同一个页面，不同人看到的是不同的东西。
- 路由与页面流转：多页面跳转、传参、回退态保持、深链接。页面从来不是孤岛。
- 副作用：请求、埋点、缓存、防抖节流、轮询、WebSocket。这些是「看不见但少了就出事」的东西。
- 异常与边界态：loading / empty / error / 超时 / 降级兜底。设计稿几乎从不画这些，但真实业务里它们能占到一半的工作量。 这是「还原一个 demo」和「交付一个能上线的页面」之间最大的鸿沟。
- 国际化 i18n：多语言下文案变长、货币/日期格式、RTL 布局翻转。
- 业务逻辑的输入源（全篇最关键的一条）：承接开头——逻辑既不在设计稿，也不在物料。所以你必须设计一个「第三输入」：把 PRD 结构化、把接口 schema 喂进来、或让人在搭建器里显式配置。不解决这个输入从哪来，「还原业务逻辑」就是一句空话。这条决定了整套系统的上限。
F. 搭建产物与工程化（决定这东西能不能被团队真正接手）
能搭出来，和搭出来的东西能维护，是两码事。
- 产物形态：出可运行代码，还是出 schema/DSL 由运行时渲染？这是最根本的架构分叉。代码灵活但难回改；schema 可二次编辑但表达力受限。
- Round-trip（低代码的头号顽疾）：搭完之后有人手改了代码，还能不能同步回 schema？这个双向一致性极难，几乎所有低代码平台都在这里流血。想清楚你要不要支持手改，比事后补救重要得多。
- 出码质量：生成代码的可读性、是否符合团队规范、能否被人接手继续开发。「能生成」但「没人敢碰」，等于没生成。
- 与现有工程集成：技术栈（React/Vue）、构建链、路由、状态库、Design Token 对齐。搭建产物不能是工程里的一块飞地。
- 运行时依赖治理：物料版本、打包体积、tree-shaking、按需加载。一个页面拖进来半个物料库，性能就没了。
G. 保真度里那些「隐藏的信息」
有些东西设计稿里根本不含，但少了就不叫还原。
- 资源：切图、字体缺失的兜底、图标从设计到代码图标库的映射。
- 动效：设计稿是静态的，过渡/动画/微交互的信息天然缺失，得单独补一套输入。
- 跨端一致性：web / 小程序 / App 的物料表现差异与对齐。
H. 系统与度量（决定这套东西能不能长期活下去）
- 冷启动：物料库不全，就搭不出页面——先有鸡还是先有蛋。破局靠「边搭边沉淀物料」的闭环，而不是指望一开始就把物料铺全。
- 覆盖率度量：一个新页面，有多少比例能被现有物料覆盖？这个数必须能算出来，它是产品健康度的核心指标。
- 反馈闭环：搭建过程中发现缺料 → 自动或半自动反哺物料库。没有闭环，物料库会慢慢腐烂。
- 度量体系：还原度、搭建效率、出码可用率怎么量化？这正是上一篇 Design2Code 教我们的那一课——单一指标一定会骗你，要按「失败的种类」分层设计指标：视觉像不像、元素全不全、逻辑对不对，分开量。一个整体「90 分」的页面，可能逻辑全错。
- 人机协作的边界：哪些自动、哪些必须人工确认、确认成本有多高。这条线画在哪，直接决定这套系统是「提效」还是「添乱」。
预设一个反对：「模型越来越强，这些不都能自动解决吗？」
会有人说：等多模态模型再强一点，识别、布局、甚至逻辑都能自动推断，何必搞这么重的物料体系。
一半对。识别、参数反推、布局这些「信息在输入里、只是难提取」的问题，会随模型变强而缓解——这是上一篇里说的「局部属性类难题」，会随规模消失。
但另一半不会：业务逻辑、响应式行为、边界态这些「信息根本不在输入里」的问题，模型再强也变不出来。 你不能从一张静态设计稿里推断出「提交失败时要保留草稿」——因为那是个产品决策，不是视觉事实。这类「欠约束」难题，唯一的解法是补充输入，而不是增强模型。物料体系的价值，恰恰在于它是一个承载这些「设计稿之外信息」的容器。所以这条路不会被端到端出码取代，两者是互补的。
收敛：4 个绕不开的根本张力
几十个坑点压到最后，本质是 4 个「你永远在中间做取舍」的张力：
- 静态 → 动态的鸿沟：物料和设计稿是「死」的，页面是「活」的。业务逻辑不在视觉里，必须引入第三输入。（最重要，其余三个都从它派生）
- 欠约束：一张设计稿对应无穷多种合法实现（响应式、边界态、数据量变化）。缺的信息要么靠规则补、要么靠人补，没有第三条路。
- 保真 ↔ 可维护：越像素级还原越死板，越语义化越可能偏离。物料的粒度与配置面，都是在这条线上找点。
- 组合爆炸 ↔ 复用率：物料粒度的永恒权衡；而 schema 与 code 的 round-trip 一致性，是压在低代码头上的阿喀琉斯之踵。
一个务实的落地建议：按保真度分层交付
别一上来就追「全自动还原含业务逻辑」——那是拿系统的命门当起点。更稳的路是按层交付、把边界画清：
- ①视觉 + ②布局：追求高还原，这部分物料库能吃下大部分工作，也是模型最擅长的。
- ③数据绑定：做成半自动——系统给出字段映射建议，人确认。
- ④逻辑 + ⑤边界态：明确交给人工在搭建器里补，但要让「补」这件事足够顺手（好的表单编排、齐全的边界态物料）。
把「哪部分自动、哪部分人工」这条线画清楚，比追求端到端全自动更重要。 这跟我更早那篇讲的判断是同一个道理——机械层可以外包，判断与综合层不能。搭建系统里，识别和布局是机械层，业务逻辑是判断层。想清楚这条线，你就不会在错误的地方追求全自动，也不会在正确的地方浪费人力。
写在最后：物料驱动搭建，表面上是把「出码」这件事工程化、可控化了。但它没有消灭难题，只是把难题从「怎么生成代码」挪到了「怎么把设计稿之外的信息，系统性地喂进来」。看清这次搬家，你才不会误以为「物料造漂亮了，页面就还原了」。页面是活的，而活的部分，从来不在设计稿里。