UI 设计从截图到可落地：40 万次安装的 Skill，先给你一套设计系统

做一个新页面时，最容易写进需求文档的，往往是最没法执行的一句话：

“做得高级一点。”

前端拿到这句话，通常会开始挑渐变、圆角和卡片阴影；Agent 拿到这句话，也会很勤快地给你拼一套“看起来像 SaaS”的东西。页面能跑，问题是每个决定都没有出处：为什么是这组颜色、为什么这里该是表格不是卡片、窄屏时哪些信息应该先消失？下一轮评审又得从头吵。

这两天我在 Skill 雷达里看到一个很夸张的数：ui-ux-pro-max 在 skills.sh 的安装记录已经到 40.37 万次；本轮抓取 GitHub 时，仓库是 13.8 万 Star，10 月 15 日还有提交。它不是画图工具，也不是让 Agent 自动生成一张“漂亮页面”的魔法棒。

它更像一个把模糊审美要求翻译成设计决策的翻译器：先识别你在做哪一类产品，再给出页面结构、颜色、字体、交互和验收约束。对天天在“截图—改一版—再改一版”里打转的人，这个顺序比多一个 UI 组件库更值钱。

它解决的不是“不会画”，而是“没有设计决策”

仓库现在写的是：79 个可搜索的 UI 风格、192 个产品类型及对应配色、74 组字体搭配、119 条 UX 指南，以及 192 条按产品类型工作的推理规则。数字当然不是质量保证，但它至少说明一件事：它试图输出的不是一个孤立的按钮样式，而是一组可以互相约束的选择。

比如你说“做一个内部运营控制台”，真正要回答的不是“蓝色还是紫色”，而是这些更麻烦的问题：

• 页面是密集看数，还是把重点指标做成一眼能扫完的卡片？
• 审核、告警、筛选和导出这些高频动作，谁应该在首屏，谁应该藏进二级菜单？
• 深色状态色怎么和正文、禁用态、错误态一起工作？
• 表格到了 375px 宽度，应该横向滚动、折叠字段，还是换成详情抽屉？

这些问题不先落下来，再漂亮的截图也只能算一次性布景。这个 Skill 的设计系统生成器把它们往前提：先出产品模式、风格、色板、字体、组件规则和交付检查项，代码生成只是后一步。

这点很适合和 Agent 配合。你不必让它“自由发挥”，而是让它先交一份可以质疑的设计合同。

十分钟怎么装，怎么开口

最直接的安装方式是：

npx skills add nextlevelbuilder/ui-ux-pro-max-skill

仓库也提供自己的 CLI 安装器。若你的工作环境是 Codex CLI，README 给出的路径是下面这组；两种分发方式选一种即可，不必叠着装。

npm install -g uipro-cli
uipro init --ai codex

装完别上来就说“帮我做一个 dashboard”。把你本来会写在 PRD 边角的条件，一次交代给它。下面这段可以直接改产品名后使用：

为「Ops Console」设计一个内部运营控制台。

用户要在一屏里处理告警、筛选任务、查看关键指标；桌面端优先，375px 仍要可用。
先不要写页面代码。请先输出：
1. 页面模式与信息层级；
2. 色彩、字体、间距和状态 token；
3. 筛选、空状态、加载、错误、权限不足的行为；
4. 375px、768px、1024px、1440px 的验收条件；
5. 再按这套规则给出组件拆分。

这一段的重点不是“提示词写得像不像专家”，而是把输出顺序锁住。先拿到选择依据，再拿 JSX、HTML 或设计稿。这样设计评审里有人说“这个按钮不对”，你们可以回到它属于哪个任务、什么状态、什么密度，而不是继续争“我觉得更高级”。

我跑了一次，它给了什么

这次没有拿一张成品页面来冒充亲测。我用仓库自带的 search.py，以“internal operations dashboard”生成了一个名为 Ops Console 的设计系统，产物保存在本文的本地材料里。

结果先把页面归成“实时／运营”模式，再选择“数据密集 Dashboard”：深色背景、绿色正向状态、紧凑的指标卡和表格；随后给出 4px 到 64px 的间距 token、Fira Code／Fira Sans 字体、悬浮与聚焦状态，以及 375、768、1024、1440 四个宽度的验收项。

这里最有价值的不是“它选了深色”。我更在意最后那张交付前清单：图标要来自同一套库；点击元素要有指针和可见 focus；文字对比度至少 4.5:1；尊重减少动效；窄屏不得横向溢出。把这些写到 Agent 的上下文里，下一次它改页面时就不至于又忘掉。

但也别被“设计系统”四个字催眠。这个本地输出同时给了一个很好的提醒：它把背景设为 #020617，却在通用次级按钮示例里使用 #0F172A 的文字和边框。放在深色页面上，这个组合很容易不够清楚。也就是说，Skill 能把漏项和选择显性化，却不能替你通过视觉验收。

这反而是它更正确的使用方式：把它当成设计 Review 的第一轮，而不是把设计责任外包给一个命令。

哪些场景特别顺手，哪些先别用

它最适合三类场景：

一是从零做产品原型。 你只有用户、任务和几个功能名，却不想让首页永远长成同一张 AI 落地页。先用它定信息层级和风格边界，再做原型。

二是给已有页面补秩序。 页面不是不够“好看”，而是 loading、empty、error、权限不足和移动端都没人管。把现有页面类型和约束交给它，往往比整页重画划算。

三是让设计、产品和前端说同一种话。 它输出 token、组件规则和验收项，比较适合变成 Issue 的 acceptance criteria。等代码出来后，再用截图、键盘操作和真数据过一遍。

反过来，如果你已经有完整品牌系统、Figma 组件库和严格的设计规范，别让它从头改色改字体。此时更好的提问是：“在不动现有 token 的前提下，补齐订单列表的状态和移动端策略。”它该做的是补洞，不是把团队的设计语言冲掉。

还有一件小事很重要：仓库 README 里展示的 Before／After 是作者提供的案例，不是你的业务指标。它可以证明这种工作流能产生一套可见的设计方向，但不能证明会让你的转化、留存或交付速度自动变好。真要拿去上线，仍然得在真实内容、真实窄屏和真实操作路径里验收。

我自己的判断是，做 UI 时最该交给 Agent 的，不是“替我审美”，而是“替我把遗漏的问题一条条摊到桌面上”。这个 Skill 的热度背后，可能正好是大家都被那种能生成、但无法解释也无法维护的页面折腾够了。

你现在和 Agent 做页面时，最容易被它漏掉的是视觉风格，还是空状态、移动端和交互细节？