设计系统的 LLM 微调实践用团队规范训练专属 AI 设计助手一、引子通用模型不懂你的品牌色让 Claude 生成一个卡片组件颜色用--color-primary它选了蓝色。让 GPT-4o 做同样的任务它选了紫色。没有对错之分——通用模型的默认审美和应用的设计规范之间有一道鸿沟。微调Fine-tuning是跨越这道鸿沟的技术手段。不是让 LLM 重新学习如何写代码而是在现有能力基础上教会它我们这个团队的具体偏好。二、微调 vs Prompt Engineering 的边界何时使用 Prompt规则数量 20 条、规则每次都可能变化、Token 列表如颜色值适合直接注入 Prompt。何时使用微调规则数量 50 条、编码风格是稳定且独特的、有 200 高质量组件代码作为训练数据。三、微调实践步骤第一步构建训练数据集从团队的代码仓库中筛选 200-500 个质量最高的组件代码。每个训练样本是一个Prompt-Response对Prompt系统提示 需求描述: 使用团队设计系统创建一个用户资料编辑表单。包含头像上传、姓名输入、简介文本域、保存按钮。 Response团队实际代码: [完整的组件代码使用团队的 Token 变量、编码风格、状态管理模式]关键质量要求只使用经过 Code Review 的合并代码排除含有已知 Bug 的组件确保每个组件覆盖至少 3 种状态loading/empty/error第二步数据清洗/** * 训练数据清洗脚本 */ function cleanTrainingData(components: CodeSample[]): CodeSample[] { return components // 去除重复 .filter((c, i, arr) arr.findIndex(x x.hash c.hash) i) // 去除代码行数 20 的太简单没有训练价值 .filter(c c.code.split(\n).length 20) // 确保使用了设计系统 Token .filter(c /var\(--/.test(c.code)) // 去除有 TODO 或 FIXME 的代码不完整 .filter(c !/TODO|FIXME/.test(c.code)) // 去除没有 TypeScript 类型的 .filter(c c.code.includes(:) c.code.includes(interface)) // 平衡组件类型分布 .filter(c ensureTypeBalance(c)); }第三步微调与评估使用 OpenAI 的 Fine-tuning API 或 LLaMA-Factory 等开源工具进行微调。评估标准颜色正确率生成的代码中使用 Token 变量而非字面量的比例目标 100%间距一致性间距值符合设计系统步进的比例目标 95%状态完整度正确处理 loading/empty/error/disabled 四种状态的比例目标 90%类型安全TypeScript 编译零错误目标 100%四、边界分析微调的维护成本设计系统更新后如品牌色从蓝色改为绿色已微调的模型不会自动更新——它学的是旧的颜色。需要在每次设计系统重大更新后重新微调这引入了版本管理的复杂度。训练数据质量的关键性Garbage in, garbage out。如果训练数据中包含不符合规范的旧代码比如有人在组件中用了硬编码的颜色值模型会学到这个坏习惯。微调不是万能的微调让模型记住了通常怎么做但无法理解为什么这样做。当遇到全新的组件需求时微调后的模型可能仍然输出不符合新场景的代码。五、总结规则 20 条用 Prompt Engineering 50 条且稳定时考虑微调训练数据需要 200-500 个高质量组件代码经过 Code Review 的合并代码数据清洗包括去重、最低行数、Token 变量检查、类型安全检查评估标准颜色正确率、间距一致性、状态完整度、类型安全每次设计系统重大更新后需要重新微调增加维护成本微调训练的数据质量直接影响模型产出质量