设计系统的响应速度与资源取舍设计系统里的颜色、间距、字号和圆角本来是结构化数据。把每次 Token 变更连同整份组件代码交给大模型再等待它重新生成文件看起来省掉了模板维护实际却把一个确定性转换变成了耗时、收费且结果会波动的步骤。讨论响应速度与资源成本之前先分清任务。字段改名、格式转换、类型生成可以由普通程序完成需要理解设计意图、发现命名冲突或给出迁移建议时模型才可能有用。两类工作混在一条 CI 流水线里性能问题往往不是模型太慢而是调用位置放错了。先测清楚时间花在哪里一次 Token 到代码的转换可以拆成读取源文件、解析与校验、计算差异、生成目标文件、格式化和测试。若使用模型还要加上上下文准备、排队、推理、输出校验和可能的重试。只记录总时间无法判断优化应该落在哪一段。建议用固定的脱敏样本分别跑冷启动和重复构建记录每阶段耗时、输入规模、缓存命中和失败类型。平均值之外还要看较慢的一批任务。CI 中偶发的长尾会阻塞整条流水线不能被大量快速的小组件掩盖。资源统计同样要覆盖失败请求。模型返回无效结构后再次生成第一次调用已经消耗了 Token 和时间任务被取消时如果后台请求没有真正终止也应计入成本。只统计成功结果会低估最需要治理的部分。对结构化变更使用确定性转换Design Token 应先经过 Schema 校验再转换为 CSS 变量、TypeScript 类型或组件主题对象。转换规则放在版本化代码里输入相同就得到相同输出差异可以直接审查。遇到未知字段时明确报错不让模型猜一个看似合理的映射。只处理发生变化的 Token能够减少解析和输出范围也让代码评审更清楚。但差异计算必须基于规范化后的结构不能依赖对象属性碰巧保持同一顺序。缓存键还要包括转换器版本和目标格式否则规则升级后可能错误复用旧产物。下面的示例展示一个简单的稳定缓存键。它不承诺解决所有序列化问题只适合值由 JSON 基本类型组成的 Token 对象。若输入允许日期、二进制或自定义对象应先在 Schema 层拒绝或转换。import { createHash } from node:crypto; type JsonValue | null | boolean | number | string | JsonValue[] | { [key: string]: JsonValue }; function canonicalize(value: JsonValue): JsonValue { if (Array.isArray(value)) return value.map(canonicalize); if (value typeof value object) { return Object.fromEntries( Object.entries(value) .sort(([left], [right]) left.localeCompare(right)) .map(([key, child]) [key, canonicalize(child)]), ); } return value; } interface CacheInput { component: string; tokens: Recordstring, JsonValue; generatorVersion: string; target: css | typescript; } export function cacheKey(input: CacheInput): string { const normalized JSON.stringify(canonicalize(input)); return createHash(sha256).update(normalized).digest(hex); }缓存命中只能复用通过当前规则验证的产物。内存缓存适合单次进程CI 跨任务复用则需要持久化存储并设置清理和版本失效策略。缓存内容若包含私有设计资产还要限制读取范围不能为了提速把它放到公共制品区。模型放在不阻塞构建的位置模型更适合提出建议而不是成为每次构建都必须成功的编译器。例如Token 命名发生冲突时它可以根据变更说明给出候选名称组件迁移影响较大时它可以生成一份待审阅的修改建议。建议必须通过 Schema 校验和人工确认再交给确定性生成器处理。CI 主路径应能在模型不可用时继续完成校验与构建。需要模型的辅助任务可以异步运行把结果写成单独的评审产物。这样服务限流或网络波动不会让所有组件发布停住团队也能区分“构建失败”和“没有生成建议”。确实需要同步调用时要设置总时限、重试边界和输入上限。参数错误、内容超出协议或权限拒绝不应原样重试。失败后回到人工流程或上一版产物并清楚标记本次建议未生成不要偷偷提交空文件。速度优化不能牺牲可审查性为了追求更快有些实现会跳过格式化、类型检查或视觉回归只把文件写出来。这会把耗时转移到评审和故障处理并没有降低总成本。更合理的顺序是先减少无效输入和重复工作再并行执行互不依赖的校验最后才考虑扩大计算资源。性能对比要在同一工具链、同一 Token 集和相同缓存状态下完成。报告原始阶段耗时与失败样本不给缺少来源的“提升倍数”。如果变化只对重复构建有效就明确写成热缓存结果如果首次构建仍慢也要单独留下。最终需要权衡的不是“便宜模型还是昂贵模型”而是哪些步骤真的需要推理。让结构化转换回到普通代码把模型调用变成可取消、可降级的建议环节通常能同时改善响应速度、资源开销和产物稳定性。设计系统最重要的仍是规则可追踪、变更可审查这两点不应交给一次不可复现的生成结果。