设计系统的 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 等开源工具进行微调。评估标准：
四、边界分析
微调的维护成本：设计系统更新后（如品牌色从蓝色改为绿色），已微调的模型不会自动更新——它学的是旧的颜色。需要在每次设计系统重大更新后重新微调，这引入了版本管理的复杂度。
训练数据质量的关键性：Garbage in, garbage out。如果训练数据中包含不符合规范的旧代码（比如有人在组件中用了硬编码的颜色值），模型会学到这个坏习惯。
微调不是万能的：微调让模型记住了"通常怎么做"，但无法理解"为什么这样做"。当遇到全新的组件需求时，微调后的模型可能仍然输出不符合新场景的代码。
