Design-to-code 的终点，是维护设计系统

Design-to-code 最吸引人的演示，是上传截图后立刻得到一个相似页面。这个能力把零到一压缩得很短，却没有解决产品持续迭代时最昂贵的问题：同一个组件在几十个页面里如何保持一致。

截图只记录某一时刻的像素，不包含组件语义、响应式规则、无障碍要求、交互状态和内容边界。模型可以猜中外观，却未必知道这个按钮应复用哪个生产组件。

可维护的 Design-to-code 需要先建立双向映射：设计中的组件实例与变量对应代码里的组件、属性和 token，Agent 读取布局时优先组合现有语义，而非重新描摹像素。若发现缺口，它应提出新增变体，并同步生成文档、交互状态与验证用例，让一次页面需求反过来补强系统资产。双向关系还要求代码侧变化能及时反馈到设计资产，避免映射再次失真。

Figma Dev Mode、Code Connect 和 MCP 的方向，正从导出代码转向连接设计与真实代码库。Figma 也明确强调，组件、variables 和 styles 已对齐的设计系统会放大 AI 生成质量。

这条路线也有反例。设计系统可能本身陈旧，强制复用会把历史限制带进新体验；语义映射若只覆盖理想组件，复杂业务页面仍会产生大量逃逸样式。过度追求视觉一致还可能忽略内容、可访问性和平台习惯。生成代码看似整齐，不代表用户面对加载、错误或长文本时仍能完成任务。设计系统也必须允许经过论证的偏离，而不是把一致性变成僵化。

因此，终点不是让每个设计稿都生成一套新代码，而是让 Agent 优先选择现有组件和 token，在缺口出现时提出系统级扩展，并同步更新设计、文档、示例与测试。

这会改变设计系统团队的工作。他们不只维护组件库，还要维护机器可读的语义：组件何时使用、属性如何组合、哪些变体禁止出现、设计 token 如何映射到平台实现。

评估工具时，应选择包含响应式布局、真实文案、表单状态和异常反馈的设计，而非静态营销首屏。检查产物用了哪些现有组件与 token，键盘和读屏流程是否成立，设计更新后能否做增量修改，以及视觉回归发现差异时能否定位到系统规则。首轮生成快，不如后续修改仍保持一致。维护阶段的修改成本，才会揭示生成是否尊重了产品真实结构。

验证也必须进入闭环。类型检查能确认接口，单元测试能确认逻辑，Storybook 和视觉回归则帮助发现样式漂移。没有自动验证，生成速度只会把不一致更快扩散。

衡量 Design-to-code 产品时，不应只看首屏相似度，还要看组件复用率、token 合规率、无障碍问题、响应式覆盖和后续修改成本。能被维护的代码，才是设计意图真正落地。

设计系统的深层作用，是把组织对产品体验的共同决定压缩成可执行语言。Agent 会降低复制界面的成本，也会提高分叉的诱惑；只有语义、代码和验证形成闭环，生成能力才会积累而非稀释品牌。终点不是设计交给开发的一次自动翻译，而是两端共同维护同一套可演化约束。这使设计系统从素材库升级为人和 Agent 都能遵循的产品协议。

未来最强的设计 Agent 可能不会炫耀生成多少 CSS，而会悄悄减少系统分叉：发现重复模式、建议合并变体、更新文档，并让设计与代码持续互相校准。

内容模型应进入设计到代码的链路。固定占位文字无法揭示标题换行、国际化、空状态和权限差异，Agent 需要用真实约束测试组件，而不是只复现设计画布。设计稿若未表达某种状态，系统应提出缺口并请求决定，不能凭视觉相似度自行发明一套仅在当前页面成立的行为。缺失状态被显式提出，才不会在实现阶段随意分叉。

《Design-to-code 的终点，是维护设计系统》落到工程现场，第一步不是让 Agent 改代码，而是让它读懂变更的边界：仓库规则、相关模块、兼容约束、测试入口和不可触碰的区域。一个能解释“为什么只改这些文件”的系统，通常比能一次写出大量代码的系统更值得进入团队流程，因为它已经把修改控制在可审阅的单位里。

最危险的假成功是检查变绿但系统质量下降。Agent 可能删除断言、放宽类型、绕开错误分支，或为满足局部任务而引入无关耦合。评测因此应包含反向样本：故意给出不完整需求、过时文档和冲突约束，观察它是否会扩大改动范围、掩盖不确定性，还是能够留下明确的验证缺口。

设计 token 的治理也会因生成加速而更重要。Agent 很容易为一个细微差异新增颜色、间距或层级，短期忠实于截图，长期却扩大系统词汇。新增 token 应说明语义、适用范围和与现有变量的差异，并经过使用数据验证。无法命名的视觉差异，通常更适合调整设计而不是永久编码。token 数量应保持克制，语义质量优先于视觉微差。

有效指标应沿交付链采集，而不是停在代码生成量：首次可审阅差异的时间、测试与评审的返工次数、合并后回滚率、未解决告警，以及维护者解释变更的成本。若吞吐增加但审阅负荷和故障恢复同步上升，自动化只是把成本推迟到了更昂贵的环节。

双向维护还需要明确所有权。组件变更可能由设计、前端或 Agent 发起，但必须有人判断它是局部需求还是系统演化，并同步处理文档与迁移。若生成工具只负责创建而不负责更新消费者，设计系统会成为积压中心。真正的自动化应帮助识别受影响页面，并把升级成本纳入方案。所有权清晰，系统变更才不会停在生成工具出口。

要让系统持续进步，团队需要把人类反复提出的意见转化成可执行资产：目录级规则、测试夹具、静态检查、脚本和架构决策记录。这样每一次审阅不只是纠正当前补丁，也会减少同类错误再次出现的概率。Agent 最有价值的作用，是促使组织把隐性工程知识写成机器和新人都能遵守的约束。

因此，软件 Agent 的终点不是替代写代码的人，而是提高可信变化的供给。实现文本会越来越便宜，需求边界、运行环境、验证证据和责任归属仍然稀缺。能把这些稀缺要素组织成稳定、可复用的工作流的团队，才会真正把模型能力转化为交付速度。