AI 辅助 UI 生成先让设计系统接住不确定性把设计稿直接翻成代码最容易失控的地方往往不是模型而是设计稿本身颜色没有绑 Token、变体名称随手写、图层只为排版临时存在。我的做法是把生成器放在校验之后。能明确映射的节点自动生成拿不准的节点留下诊断交给人确认。先识别再替换颜色接近某个 Token不代表一定该替换。品牌色、透明度和叠加背景都会影响结果。匹配工具可以给候选项但不要把“相似”当成“正确”。同样未命名的 Frame 也不该默认变成一个组件。const token findExactToken(fill); if (!token) { diagnostics.push({ nodeId: node.id, reason: 未找到明确的颜色 Token }); return fallbackStyle; } return { backgroundColor: var(--${token}) };把边界写进流水线生成代码进入仓库前至少检查组件 API、可访问性和样式约束。像value与defaultValue同时出现、图标按钮没有可读名称、任意值类名绕开 Token这些都应当拦下。自动修复只能处理规则明确的问题语义不明的地方保留给设计和研发一起决定。日志只保留节点类型、规则编号和构建版本不保存设计内容或个人资料。这样既方便回查也不会把协作素材带进不必要的记录里。让生成结果便于维护第一阶段只覆盖按钮、输入框、卡片这类稳定组件。页面级布局依赖业务语义生成得再像也可能难维护。把失败案例积累成规则比一开始追求“全自动”更实际。先建立可追溯的映射表设计节点、组件库条目和最终代码之间最好有稳定的关联。比如按钮节点对应组件名、尺寸变体和状态而不是只存一段生成后的 JSX。设计师把主按钮的圆角从 8 改到 10 时工具可以指出它影响的是哪个 Token、哪些实例和哪些测试研发也能判断这是组件变更还是某个页面的例外。映射表不用追求覆盖所有图层先覆盖会重复使用、会进入发布验收的部分即可。对生成失败的节点诊断信息要足够具体是缺少语义名称、状态不完整还是找不到可复用组件。只写“无法转换”没有行动价值。团队可以每周看一次高频失败原因补命名规范或组件能力。这样模型输出不是一次性的代码投递而是持续暴露设计系统缺口的入口。把人工确认放在风险最高处表单、支付、权限提示和删除操作不适合静默生成后直接合并。即使样式完全一致也要人工核对文案、焦点顺序、禁用条件和错误状态。对于纯展示卡片审查可以更轻对于影响业务流程的组件生成器应提交一个清晰的变更说明列出使用的 Token、推断出的属性和未处理项。最后把生成结果放到真实页面里看而不是只看独立组件截图。长标题、空数据、加载中和系统字体放大都会改变布局。能在这些状态下保持结构清楚才说明这段代码真的可以进入维护链路。生成内容还应遵循仓库已有的目录、导入和测试习惯。工具不确定某个依赖是否存在时宁可标记为待处理也不要凭空补一个包名。提交前由 CI 校验类型、样式规则和快照审查者则重点看生成器无法理解的业务语义。这样既不会把人工变成逐行抄写也不会把“自动生成”误当成免审查。设计系统提供的是受约束的选择空间生成器只能在这个空间内提高速度。