1. 为什么AI生成的界面总有一股“塑料味”
如果你用过AI辅助生成UI代码，大概率见过这种场面：对话框里输入“帮我做一个登录页”，几秒钟后代码哗啦啦吐出来，结构工整、命名规范、注释齐全，但打开预览一看——蓝底白字的按钮、圆角8px的输入框、居中卡片、灰色占位文字，和上个月生成的另一个页面几乎一模一样。更离谱的是，换个项目、换个需求，出来的东西还是那套“万能模板”。
这不是模型能力不行，而是它默认走了一条最省力的概率路径。大语言模型在生成UI代码时，本质上是在预测“下一个最可能出现的token”。训练数据里最常见的按钮样式、最常见的布局结构、最常见的配色方案，自然会被优先输出。你可以把它理解成一个从没见过真实项目、只背过教科书的设计师——你让他画个登录页，他脑子里只有课本上那一张标准图。
OJO Design Skills这个Skill包要解决的，就是这个问题。它不是换一个更强的模型，而是给模型装上一套“设计决策系统”，让它在生成界面之前先做选择：这个产品面向谁、什么调性、用什么视觉语言、哪些组件该克制、哪些地方该有记忆点。换句话说，它把“生成代码”变成了“先做设计决策，再生成代码”。
我拿到这个Skill包之后，连续跑了十几个不同类型的页面生成任务，从后台管理到移动端落地页，从工具类产品到内容社区。实测下来，最大的感受是：AI终于不再默认输出那套“Bootstrap味”的界面了。下面我把这套东西的工作逻辑、接入方式、实际效果和踩过的坑，完整拆一遍。
提示：本文讨论的是AI辅助UI生成的工作流优化，不涉及任何特定平台的独家功能，所有方法都可以迁移到你自己常用的AI编程工具链里。
2. OJO Design Skills到底改了AI的哪根筋
2.1 从“直接写代码”到“先过设计决策层”
大多数AI编程工具的工作流是这样的：用户输入需求 → 模型理解意图 → 直接生成代码。中间没有“设计”这个环节。模型跳过了所有人类设计师会做的判断：这个页面的视觉重心在哪、信息层级怎么排、用什么手段引导用户操作、品牌感从哪里体现。
OJO Design Skills的做法是在需求理解和代码生成之间插入一个设计决策层。这个层包含几个核心模块：
- 产品语境识别：判断这是工具型、内容型、交易型还是展示型产品，不同语境对应完全不同的设计策略。
- 视觉调性选择：从一组预设的设计方向中匹配最合适的，比如“极简克制”“高密度信息”“柔和亲和”“强对比冲击”。
- 组件策略生成：决定哪些地方用标准组件、哪些地方需要定制化处理，避免全盘套模板。
- 布局节奏控制：不是简单的中规中矩栅格，而是根据内容优先级决定留白、分组和视觉动线。
这套逻辑跑下来，同一个“登录页”需求，面向开发者工具和面向母婴社区，出来的东西会完全不同。前者可能是深色背景、等宽字体、极简输入框；后者可能是暖色调、圆润卡片、插画引导。关键差异不在代码层面，而在决策层面。
2.2 Skill包的本质是一组结构化提示词加约束规则
别被“Skill包”这个名字唬住，它不是什么神秘的插件或闭源模型。拆开看，核心就是一套结构化的提示词体系加上输出约束规则。提示词部分负责引导模型做设计决策，约束规则部分负责防止模型退回到默认模板。
我实际拆解过它的提示词结构，大致分四层：
- 角色设定层：把模型定位成“有十年经验的产品设计师”，而不是“代码生成器”。这个设定很关键，因为角色会影响模型调用哪些知识。
- 决策框架层：给出一组设计维度（调性、密度、对比度、圆角策略、色彩策略等），要求模型在生成代码前先输出这些维度的选择结果。
- 约束规则层：明确禁止一些默认行为，比如“不要使用默认的蓝色主按钮”“不要所有卡片都用同样的阴影”“不要连续三个区块使用相同的布局结构”。
- 输出格式层：规定先输出设计决策摘要，再输出代码，方便使用者审查和调整。
这套东西的巧妙之处在于，它没有试图改变模型的底层能力，而是改变了模型调用能力的顺序和方式。先做选择，再执行，出来的结果自然不一样。
2.3 和直接写系统提示词有什么区别
你可能会想：这不就是写一段更长的系统提示词吗？我自己写不行吗？
行，但效果差很多。我对比过两种方式。自己写提示词，通常会写成“你是一个专业设计师，请生成美观的界面”，这种描述太模糊，模型理解不了“美观”具体指什么。OJO Design Skills的价值在于它把“美观”拆解成了可操作、可验证、可组合的决策维度。
举个例子，它不会说“用好看的配色”，而是会要求模型先确定：主色饱和度范围、中性色层级数量、强调色使用场景、背景与前景对比度阈值。这些具体约束让模型的输出有了明确的方向，而不是在概率空间里随机游走。
另一个区别是一致性维护。自己写提示词，生成单个页面还行，生成多个页面时风格很容易漂移。OJO Design Skills有一套跨页面的设计令牌（Design Token）机制，确保同一项目里不同页面的圆角、间距、色彩、字体层级保持一致。这个在实际项目里太重要了，不然生成十个页面十个样，后期统一成本极高。
3. 接入实操：从零跑通第一个非模板页面
3.1 环境准备与工具链选择
OJO Design Skills本身不绑定特定工具，它可以接入任何支持系统提示词或自定义指令的AI编程环境。我实测过三种接入方式，各有优劣：
| 接入方式 | 适用场景 | 配置难度 | 效果稳定性 |
|---|---|---|---|
| 编辑器插件自定义指令 | 日常开发，边写边生成 | 低 | 中 |
| API调用时注入系统提示词 | 批量生成、自动化流程 | 中 | 高 |
| 本地模型配合提示词模板 | 数据敏感、离线环境 | 高 | 中高 |
我主要用第一种和第二种。日常开发在编辑器里直接调用，批量生成页面时走API。如果你用的是支持自定义指令的AI编程插件，直接把Skill包的核心提示词粘贴到系统指令区域就行。
注意：不同工具对系统提示词的长度限制不同。OJO Design Skills完整版提示词大概在2000-3000 token，大部分工具能吃下，但有些轻量插件可能会截断。如果发现效果不对，先检查提示词是否被截断。
3.2 第一次生成：从“能看”到“有设计感”的差距
我拿一个真实需求做测试：生成一个“个人财务管理工具”的仪表盘页面。需求描述很简短：“显示月度收支、分类占比、最近交易记录，要看起来专业但不冰冷。”
不用Skill包直接生成的结果：标准三栏布局，顶部四个统计卡片，中间一个饼图，底部一个表格。配色是默认的蓝灰系，卡片圆角8px，阴影很轻。功能上没问题，但看起来就像任何一个后台模板，没有任何“财务管理”的语境感。
接入Skill包后的结果：模型先输出了一段设计决策摘要，大意是——产品语境为工具型但面向个人用户，调性选择“可信赖但有温度”，主色用深青绿替代默认蓝，中性色偏暖灰，统计卡片采用非对称布局突出核心指标，饼图改为环形图并配合中心数字强调，交易记录用紧凑列表而非表格以降低压迫感。
然后生成的代码，打开预览，确实不一样了。深青绿的主色让页面有了辨识度，暖灰背景减少了冷冰冰的感觉，非对称卡片布局让视觉重心落在“本月结余”上，环形图中心的大数字很直观。同样的功能，完全不同的气质。
3.3 关键参数调优：让输出匹配你的项目
Skill包默认有一套参数，但实际项目里需要根据情况调整。我整理了几个最常改的参数：
- 设计密度：控制信息紧凑程度。后台管理类项目建议调高，营销落地页建议调低。
- 圆角策略：可选“统一圆角”“分层圆角”“直角为主”。工具类产品适合小圆角或直角，消费类适合大圆角。
- 色彩自由度：控制模型在配色上的发挥空间。品牌项目建议锁定主色，内部工具可以放开。
- 动效倾向：控制是否生成过渡动画和微交互。C端产品建议开启，B端后台建议关闭或最小化。
这些参数不需要每次手动改，可以按项目类型存成预设。我目前存了三套预设：后台工具、移动端C端、内容展示页。切换项目时直接换预设，省事很多。
4. 实测对比：模板界面和非模板界面的真实差距
4.1 视觉层面的差异拆解
我拿同一个需求分别用“裸模型”和“Skill包”生成了五组页面，覆盖登录、仪表盘、列表、详情、设置五种常见类型。对比下来，差异集中在几个维度：
色彩使用。裸模型倾向于使用安全色——蓝色系、灰色系、白色背景。Skill包会主动选择有语境感的配色，比如财务类用深绿、教育类用暖橙、医疗类用青蓝。而且它会控制色彩层级，不会所有元素都抢眼。
空间节奏。裸模型的间距往往是均匀的、机械的，所有区块之间距离差不多。Skill包会根据内容优先级调整间距，重要区块周围留白更多，次要信息紧凑排列。这个差异在视觉上非常明显，前者像Excel表格，后者像设计过的页面。
组件变体。裸模型生成的按钮、卡片、输入框几乎都是同一个样式复制粘贴。Skill包会生成组件变体，比如主按钮和次按钮有明显区分，卡片有带图和不带图两种形态，输入框有聚焦态和错误态的视觉反馈。
信息层级。裸模型把所有信息平铺，字号差异很小。Skill包会建立清晰的字号阶梯和字重对比，让用户一眼看到重点。
4.2 代码质量层面的意外收获
本来我只关注视觉效果，但实际用下来发现代码质量也有提升。原因很简单：设计决策清晰了，代码结构自然更合理。
裸模型生成的代码经常出现“样式堆砌”——所有样式写在一起，没有变量，没有复用，改一个颜色要全局搜索替换。Skill包因为先确定了设计令牌，生成的代码会自然地使用CSS变量或Tailwind配置来管理色彩、间距、圆角。后期维护成本低很多。
另一个改善是组件拆分更合理。裸模型倾向于把所有东西写在一个大文件里，Skill包会引导模型按功能拆分组件，因为设计决策阶段已经识别了哪些是独立模块。
4.3 什么情况下Skill包也救不了
说点实在的。Skill包不是万能的，以下几种情况它效果有限：
- 需求描述极度模糊：如果你只说“做个好看的页面”，模型再怎么做设计决策也是瞎猜。输入质量决定输出质量这条规律没有变。
- 品牌规范极其严格：如果项目有完整的品牌手册，Skill包的默认决策可能和品牌规范冲突。这时候需要把品牌规范作为强约束注入，而不是依赖Skill包的默认选择。
- 复杂交互逻辑：Skill包主要优化的是视觉和布局层面，复杂的交互逻辑、状态管理、数据流还是需要人工设计和编码。
我踩过的一个坑是：拿它生成一个需要复杂表单验证的页面，视觉上确实不错，但验证逻辑写得很粗糙。后来我调整了策略——用Skill包生成视觉框架，交互逻辑自己补。分工明确，效率最高。
5. 把Skill包用出复利：我的工作流改造记录
5.1 建立项目级设计令牌库
单个页面生成得再好看，如果十个页面风格不统一，项目整体还是散的。我的做法是：在项目开始时，先用Skill包生成一套设计令牌，包括色彩体系、字号阶梯、间距系统、圆角规范、阴影层级。这套令牌存成一个配置文件，后续所有页面生成都引用它。
具体操作上，我会先让模型输出设计决策摘要，确认没问题后，让它把这套决策转成CSS变量或Tailwind配置。这个配置文件就是项目的视觉基准，后面不管生成多少个页面，都从这个基准出发。
这样做的好处是，即使某次生成的页面布局有偏差，视觉调性也不会跑偏。改起来也方便，改令牌文件就行，不用逐个页面调。
5.2 分阶段生成：先骨架后血肉
我早期犯的错误是一次性让模型生成完整页面，结果经常是布局还行但细节粗糙，或者细节不错但整体结构不对。后来改成分阶段生成：
第一阶段只生成布局骨架，确定区块划分和视觉动线。这时候不关注具体样式，只看结构是否合理。第二阶段在骨架上填充组件和内容，这时候设计令牌已经生效，视觉一致性有保障。第三阶段做细节打磨，调整间距、对比度、微交互。
分阶段的好处是每一步都可控，出问题容易定位。而且第一阶段确认结构后，后面两个阶段可以并行推进，总体效率反而更高。
5.3 建立自己的“反模板”检查清单
即使有Skill包，模型偶尔还是会退回到模板化输出。我总结了一个快速检查清单，生成后扫一眼就能判断是否需要重新生成：
- 主按钮是不是默认蓝色或默认黑色？
- 所有卡片是不是同样的圆角和阴影？
- 页面是不是标准的“顶部导航+左侧菜单+右侧内容”三栏结构？
- 字号是不是只有标题和正文两个层级？
- 间距是不是所有区块都一样？
- 有没有任何一处设计是“这个产品特有”的？
如果前五个问题答案都是“是”，第六个是“没有”，那基本就是模板输出，需要调整提示词重新生成。这个清单帮我省了很多返工时间。
6. 那些文档里不会写的踩坑经验
6.1 提示词冲突：当Skill包遇到工具自带指令
很多AI编程工具自带一套系统指令，比如“你是一个帮助编写代码的助手”“请生成简洁高效的代码”。这些指令和OJO Design Skills的提示词有时会冲突。工具说“简洁高效”，Skill包说“先做设计决策再生成”，模型夹在中间容易精神分裂。
我的解决办法是把工具自带指令精简到最低限度，只保留必要的格式约束，把设计决策的空间完全留给Skill包。如果工具不允许修改系统指令，那就把Skill包的核心要求写进用户提示词里，虽然效果打折扣，但比冲突强。
6.2 长对话中的风格漂移
在一个长对话里连续生成多个页面时，模型会逐渐“忘记”最初的设计决策，后面的页面风格开始向默认模板回归。这是大模型的通病，上下文越长，早期指令的权重越低。
我的应对策略是每生成两到三个页面就重新注入一次设计令牌。不用重新贴完整提示词，只需要把设计决策摘要和令牌配置再发一遍，提醒模型当前项目的视觉基准。这个操作花不了几秒钟，但能有效防止风格漂移。
6.3 生成速度与质量的权衡
接入Skill包后，生成时间会变长，因为模型要多做一轮设计决策。实测下来，同样一个页面，裸模型大概5-8秒，Skill包大概12-20秒。对于批量生成场景，这个时间差会被放大。
我的做法是分场景选择：探索阶段用Skill包，慢一点但质量高；确定方案后批量生成相似页面时，可以适当简化提示词，只保留设计令牌约束，跳过完整决策流程，速度会快很多。
6.4 不要完全信任模型的色彩选择
Skill包在色彩选择上比裸模型强很多，但偶尔还是会选出对比度不足或者色相冲突的方案。特别是深色模式下的配色，模型经常翻车。我的习惯是生成后快速过一遍对比度检查，重点看正文文字和背景的对比度是否达到可读标准。如果不对，手动调一下令牌里的色彩值，比重新生成快。
7. 这套方法还能往哪延伸
OJO Design Skills目前主要解决的是Web界面的模板化问题，但这套“先决策后生成”的思路可以迁移到很多场景。
比如移动端原生界面，把设计决策层里的布局规则换成移动端规范，同样能避免生成千篇一律的列表页和详情页。再比如邮件模板、PPT版式、数据可视化图表，本质上都是“在约束条件下做设计选择”的问题，都可以套用类似的决策框架。
我最近在尝试把它用在设计系统文档生成上——先让模型做设计决策，然后把决策过程本身整理成文档，作为团队的设计规范参考。这个用法还在摸索阶段，但初步效果不错，生成的文档比人工写的更系统，因为模型会强制自己把每个决策的理由说清楚。
另一个有意思的方向是多页面一致性维护。当项目有几十个页面时，人工维护视觉一致性很痛苦。如果能把这套决策框架和设计令牌结合起来，让模型在生成每个新页面时都自动引用令牌，理论上可以做到“生成即一致”。我目前在小规模项目上验证过，页面数量在十个以内效果很好，再多了还需要配合人工审查。
说到底，AI生成界面这件事，瓶颈从来不在代码生成能力，而在设计决策能力。OJO Design Skills的价值就是把这个缺失的环节补上了。它不完美，生成结果仍然需要人工判断和调整，但它把AI从“模板复读机”变成了“能做设计选择的助手”。这个转变本身，比任何具体功能都重要。
