我做了一个 Skill，让本地Gemma4模型也能用上大厂 UI设计技巧
把本地部署的 Gemma 4、开源的 design.md 设计参考体系，以及我自己做的 Skill 调用链路，真正串成了一套能日常使用的工作流。本地模型负责高频执行，design.md 负责提供 UI 设计约束，Skill 负责把整个过程自动化
原创 超级猛 2026年4月9日 13:12
最近我把几样比较火的技术真正接到了一起，也把它们落成了一条能日常使用的 AI 页面生成工作流。
简单说，就是把本地部署的 Gemma 4、开源的 design.md 设计参考体系，以及我自己做的 Skill 调用链路，真正串成了一套能日常使用的工作流。
它最让我满意的地方，不是又跑出了一个 demo，而是这次三层能力终于接上了：本地模型负责高频执行， design.md 负责提供 UI 设计约束，Skill 负责把整个过程自动化。页面生成这件事，也第一次从“试试看”慢慢变成了“可以稳定复用”。
这篇文章我想重点讲的，也正是这三层价值：
- 本地模型
- UI生成能力
- 自动化调用。
它们单独看都不新鲜，但真正接起来之后，整个工作流的效率、稳定性和 token 使用方式都会不一样。
先把 AI 做页面那股“通用模板味”解决掉
我一直觉得，AI 生成页面最大的问题，从来不是不会写 HTML，而是太容易写出一份“完整但普通”的东西：结构都有，模块也齐，但就是不像一个真实品牌会发出来的页面。
后来我看到 VoltAgent/awesome-design-md 这个开源项目，感觉一下就对了。它把很多品牌和厂商的设计语言整理成可供 AI 参考的 DESIGN.md ，这比一句“做高级一点”“做得像大厂官网一点”有效得多。
但它也有一个很现实的问题： 流程偏手动 。
你还是要自己挑风格、找厂商、看设计描述，再把这些内容塞回当前任务里。做一次没问题，做多了就会发现，这一步很打断节奏。
所以我后来没有重新发明什么方法，而是把这套能力做成了自己的 Design System Picker Skill。
它做的事情很简单：把“我想要更像 Stripe 的开发者产品感”、“我想要 Claude 那种克制、温和的表达”、“我想要更偏 Apple 的简洁科技感”这种模糊要求，先映射到对应的设计系统参考，再自动送进后面的生成链路。
这一步一旦 Skill 化，意义就变了。
design.md 不再只是一个临时查阅的资料库，而是一个可以稳定调用、反复复用的 UI 生成能力。
这套 Skill 我也准备在下一篇文章里免费放出来，等我把跨平台兼容性再测稳一点、确认不同环境下都没问题之后，就会整理出来分享。
下面是用这套流程生成的3个Demo页面
1、Claude风格的网站首页
2、Stripe风格的网站首页
3、苹果风格的【超级猛】个人网站首页
为什么 Gemma 4 是我现在最满意的本地模型
这次我的环境很直接： Mac Studio M3 Ultra 96G
模型用的是 google/gemma-4-26b-a4b 。
根据 Google 在 2026 年 4 月 2 日公开发布 Gemma 4 时给出的信息，这一代强调的是多模态、长上下文和开发者可集成性。官方资料提到，Gemma 4 的大模型支持最高 256K 上下文，覆盖 140+ 种语言；而 26B A4B 这个版本是 MoE 结构，模型卡给出的信息是总参数约 25.2B ，每个 token 推理时激活约 3.8B 参数。
对我来说，参数不是最重要的。更重要的是，它在本地可用性和结果质量之间找到了一个很实用的平衡。
至少到目前为止，Gemma 4 是我在这台 Mac Studio 上跑出来最满意的模型。它不是那种“演示一下很惊艳，真正做事就不稳定”的类型，而是真的能接住日常任务：结构化输出比较稳，页面生成不会太飘，配合设计约束之后也能产出更像样的结果。
运行时我看了一下机器状态，GPU 基本能冲到接近满载，这也说明本地模型一旦进入实战，硬件压力是很真实的。
本地模型的边界也很清楚：长会话更吃力
如果会话太长、上下文塞得太多、分支太杂，本地模型的问题就会慢慢出来：更吃性能，也更容易出现幻觉、漂移和“前面说过，后面又忘了”的情况。
所以我现在对 Gemma 4 的定位很明确：
它更适合处理较短上下文、边界清晰、可拆解的任务，而不是硬扛一整个超长会话。
这也是我现在更推荐的工作方式：先用 API 模型把复杂任务的大方向跑通，把目标、结构和关键约束理清；然后把那些高频、小块、重复但又要求不能太差的任务，尽量交给 Gemma 4 去处理。
这样做其实非常划算。复杂推理留给更适合的模型，日常执行交给本地模型，既能把成本压下来，也能把工作流跑顺。
真正有价值的，是三层能力终于接成了一条线
这次我确实也跑了3个单页面 demo，说明这套流程已经不只是概念，而是能产出结果。
但 demo 不是重点。
重点在于，这次我终于把三层能力接成了一条线。
- 第一层是本地模型，也就是 Gemma 4。它解决的是“不是所有任务都值得联网、都值得烧昂贵 token”这个问题。
- 第二层是 UI 生成能力，也就是
design.md。它解决的是“为什么 AI 能写完整页面，却总写不出真实产品感”的问题，因为真正缺的往往不是代码，而是设计约束。 - 第三层是自动化调用，也就是 Skill 体系。它解决的是“明明知道正确方法，但每次都要手工重复一遍”的问题。只有把这部分固化下来，它才可能真正进入日常生产流。
当这三层接起来之后，页面生成才真正从“让 AI 帮我写一份 HTML”，变成“让 AI 按一套设计语言替我跑出第一版可用结果”。
这段时间我越来越在意：高效使用 token
这段时间我最大的体会是，模型不一定非得只靠一个，关键是能不能把它们配合起来，把一件事情用更少的 token 做完。
我现在越来越在意的，不是“这次我用了哪个最强模型”，而是“这个任务有没有被拆到最合理，每一步有没有交给最合适的模型”。
复杂规划、长上下文、高稳定性任务，先交给 API 模型；本地 Gemma 4 则去承接那些短链路、可拆解、日常高频的工作。
这样用下来，我越来越确认一件事：高效使用 token，本身就是一项非常重要的技能。
最少的 token，实现最佳的效果。我知道token会越来越便宜，但我要表达的是一种精准制导，而非狂轰乱炸一顿乱问。
谁越早形成这种意识，谁就越容易把模型真正接进长期工作流，而不是停留在“今天试一个新模型、明天试一个新提示词”的热闹阶段。
最后想说
如果要我用一句话总结这次实践，那就是：真正产生价值的，不是 Gemma 4、 design.md 或 Skill 中的任何一个单点，而是本地模型、UI 生成能力和自动化调用这三层能力接起来之后，开始稳定地服务真实工作。
这比单独跑出几个好看的 demo 更重要。
关注我，下一篇文章邀请你体验这个skill
作者提示: 个人观点，仅供参考
继续滑动看下一个
超级猛
向上滑动看下一个
AI 总结
我做了一个 Skill，让本地Gemma4模型也能用上大厂 UI设计技巧
核心思想
这篇文章介绍了作者将本地部署的 Gemma 4 模型、开源的 design.md 设计参考体系和自定义的 Skill 调用链路整合为一套可日常使用的 AI 页面生成工作流。通过三层能力的协同——本地模型负责高频执行、design.md 提供设计约束、Skill 实现自动化——页面生成从”试试看”变成了”可以稳定复用”的生产工具。
我的理解
这篇文章最有价值的地方，不在于展示了一个新的技术demo，而在于它提出了一种非常务实的 AI 工作流思路：不追求用一个模型解决所有问题，而是通过组合不同层级的能力（本地模型 + 设计知识 + 自动化），形成一个既高效又可控的生产 pipeline。这种分层协作的思路，其实比单纯追求”最强模型”更有实际意义。
主要内容
问题背景：AI 生成页面的”通用模板味”
AI 生成页面最大的问题不是不会写 HTML，而是太容易写出”完整但普通”的页面：结构都有，模块也齐，但就是不像真实品牌会发布的页面。缺的不是代码能力，而是具体的设计约束。
解决方案：三层能力整合
第一层：design.md 设计参考体系
- 来自 VoltAgent/awesome-design-md 开源项目
- 将各大品牌和厂商的设计语言整理成可供 AI 参考的 DESIGN.md
- 比”做高级一点”这种模糊提示有效得多
- 但原项目流程偏手动，需要自己挑风格、找厂商、看描述
第二层：Design System Picker Skill
- 作者自己开发的 Skill，将手动流程自动化
- 把模糊需求（“更像 Stripe 的开发者产品感”、“Claude 那种克制温和的表达”、“Apple 的简洁科技感”）映射到对应的设计系统参考
- 自动送入后续生成链路
- 让 design.md 从临时查阅的资料库变成可稳定调用、反复复用的 UI 生成能力
第三层：本地 Gemma 4 模型
硬件环境：
- Mac Studio M3 Ultra 96G
- 使用 google/gemma-4-26b-a4b 模型
Gemma 4 的特点：
- MoE 结构，总参数约 25.2B，每个 token 推理时激活约 3.8B 参数
- 支持最高 256K 上下文，覆盖 140+ 种语言
- 在本地可用性和结果质量之间找到了实用平衡
- 结构化输出稳定，页面生成不会太飘
- 配合设计约束后能产出像样的结果
- GPU 基本能冲到接近满载
Gemma 4 的边界：
- 长会话更吃力，上下文太多、分支太杂时容易出现幻觉、漂移
- 更适合处理较短上下文、边界清晰、可拆解的任务
推荐的工作方式
- 先用 API 模型：把复杂任务的大方向跑通，理清目标、结构和关键约束
- 再用本地模型：把高频、小块、重复但要求不能太差的任务交给 Gemma 4
- 收益：复杂推理留给更适合的模型，日常执行交给本地模型，既能压低成本，也能跑顺工作流
三层能力的价值
| 层级 | 作用 | 解决的问题 |
|---|---|---|
| 本地模型 Gemma 4 | 高频执行 | 不是所有任务都值得联网、都值得烧昂贵 token |
| UI 生成能力 design.md | 提供设计约束 | 为什么 AI 能写完整页面，却总写不出真实产品感 |
| 自动化调用 Skill 体系 | 固化流程 | 明明知道正确方法，但每次都要手工重复一遍 |
我的理解
这篇文章提出的”三层架构”思路非常值得借鉴。它不是在追求某个单一维度的最优（比如最强的模型、最全的设计库），而是在构建一个系统：
- 分层决策：把”做什么”（设计约束）和”怎么做”（代码生成）分开，把”想清楚”（API模型）和”勤动手”（本地模型）分开
- 能力固化：通过 Skill 把最佳实践固化下来，避免每次都要重新思考流程
- 成本意识：明确意识到 token 也是成本，高效使用 token 本身就是一项重要技能
这种思路其实可以泛化到很多 AI 应用场景，而不仅仅是页面生成。
总结
这篇文章展示了一个非常务实的 AI 工作流实践：通过整合本地 Gemma 4 模型、design.md 设计约束和自定义 Skill 自动化，形成了一套可日常使用的页面生成 pipeline。作者强调真正有价值的不是任何一个单点技术，而是三层能力接起来之后能稳定服务真实工作的系统。
我的扩展总结
从”模型优先”到”系统优先”的范式转变
这篇文章最让我认同的是它体现了一种从”模型优先”到”系统优先”的思维转变。很多人在做 AI 应用时，第一反应是”我要找一个最强的模型”，但这篇文章告诉我们：比单个模型更重要的是系统设计。
这让我想到软件工程的发展历史：早期我们追求单个程序员的能力，后来发现真正能规模化产出高质量软件的，是好的架构设计、开发流程和协作机制。AI 应用的发展可能也在走类似的路径。
关于”高效使用 token”的深层思考
作者提到”高效使用 token，本身就是一项非常重要的技能”，这个观点非常有启发性。这里的”高效”其实有几层含义：
- 经济效率：用更少的钱办成事
- 时间效率：本地模型可能更快，不用排队等 API
- 隐私安全：敏感数据不需要上传到第三方
- 可靠性：不依赖网络连接，不会因为 API 故障而中断
但更深层的是，这是一种”精准制导”vs”狂轰乱炸”的思维差异。当我们习惯了”有问题就问大模型”时，往往会忘记思考：这个问题真的需要大模型吗？有没有更轻量的解决方案？
Skill 作为”知识载体”的价值
作者把 design.md 从一个”资料库”变成一个”可调用的能力”，这个转变很关键。这让我想到：Skill 不仅仅是自动化脚本，它更是一种知识载体。
当我们把”如何挑选设计风格”、“如何应用设计约束”这些知识编码到 Skill 中时，这些知识就从”某个人的经验”变成了”可复用的系统能力”。这可能是 Skill 体系最有价值的地方——它让知识可以被固化、被传播、被迭代。
对未来工作流的想象
沿着这个思路，我们可以想象未来的 AI 工作流可能是这样的：
- 任务分解层：用大模型把复杂任务拆成小任务
- 能力选择层：根据任务特点选择最合适的模型/工具
- 知识约束层：注入领域知识、设计规范、质量标准
- 执行层：用本地或云端模型执行具体任务
- 验收层：用另一套 Skill 检查输出质量
这篇文章其实已经在做这样的尝试，只是还比较初步。
本文档基于 https://mp.weixin.qq.com/s/7tctB4Iubfrg3dbPFKmiwQ 整理总结，并加入了扩展理解