AI2026-05-2711 分钟阅读
Codex 如何安装和使用 ui-ux-pro-max 做前端设计
用 ui-ux-pro-max 为 Codex 前端任务补充设计系统、产品上下文、布局模式、UX 约束和技术栈实现建议。
LW
Luo WJ
Luo WJ 维护 ToolOrbit 这个实用、浏览器优先的在线工具项目，重点复核开发者、图片、PDF、AI 和电商工作流的清晰度、隐私边界以及实际可用性。
正在加载文章...
分享这篇文章
继续阅读
查看全部
用 ui-ux-pro-max 为 Codex 前端任务补充设计系统、产品上下文、布局模式、UX 约束和技术栈实现建议。
Luo WJ
Luo WJ 维护 ToolOrbit 这个实用、浏览器优先的在线工具项目，重点复核开发者、图片、PDF、AI 和电商工作流的清晰度、隐私边界以及实际可用性。
分享这篇文章
继续阅读
ui-ux-pro-max 适合在 Codex 需要做设计判断时使用，而不是只补代码。做新页面、改工具区布局、优化仪表盘、检查移动端体验前，先让它给出设计系统、色彩、字体、布局模式、UX 约束和技术栈建议。这个 Skill 覆盖 67 种视觉风格、96 套色彩方案、57 种字体搭配、25 种图表类型和 13 个前端技术栈。给它产品上下文、用户群体和 UX 问题——而不是只说"做好看一点"。
最后审校：2026-05-27。维护者：ToolOrbit Editorial Team。
很多 AI 生成界面的问题不是代码跑不起来，而是缺少产品判断：卡片过大、颜色单一、间距不统一、控件不像真实工具、首屏像模板落地页。
ui-ux-pro-max 的作用就是让 Codex 在写代码前先做设计推理。它包含产品模式、视觉风格、色彩、字体、UX 规则、图表选择和不同技术栈实现建议。
了解 Skill 的范围能帮你写出更好的提示词。Skill 把设计知识按以下类别组织：
视觉风格（67 种）： 玻璃态、黏土态、极简主义、粗野主义、新拟态、便当盒布局、暗色模式、响应式、拟物化、扁平化等等。每种风格都包含适用场景、避免场景和实现模式。
色彩方案（96 套）： 按行业（SaaS、电商、金融、医疗、教育、游戏、作品集）和氛围（沉稳、活力、可信、奢华、活泼、严肃）组织的预置调色板。每套包含主色、辅助色、中性色、强调色和语义色（成功、警告、错误）。
字体搭配（57 种）： 标题 + 正文组合，包含回退字体栈、推荐字号和行高。涵盖 Google Fonts、系统字体和可变字体。
图表类型（25 种）： 柱状图、折线图、面积图、饼图、散点图、雷达图、热力图、矩形树图、桑基图、漏斗图、仪表盘等等。每种都包含适用场景和主流库的实现说明。
前端技术栈（13 个）： React、Next.js、Vue、Svelte、SwiftUI、React Native、Flutter、Tailwind CSS、shadcn/ui 等。每个都包含技术栈特有的模式、组件库和实现陷阱。
只要任务有明显的视觉或交互界面，就适合使用：
如果只是改一行文案、纯数据调整、后端逻辑或没有界面影响的小 bug，就不需要用它。
你能给 Skill 的最重要输入就是产品类型。SaaS 仪表盘、电商产品页、开发者工具和创意作品集的设计需求本质不同：
| 产品类型 | 信息密度 | 色彩基调 | 字体方向 | 核心模式 |
|---|---|---|---|---|
| SaaS 仪表盘 | 高 | 沉稳、专业 | 干净无衬线 | 数据表、KPI 卡片、筛选 |
| 电商 | 中 | 温暖、吸引人 | 有表现力的标题 | 商品网格、CTA、信任标识 |
| 开发者工具 | 高 | 暗色模式、克制 | 等宽字体用于数据，无衬线用于 UI | 配置面板、输出区域、差异对比 |
| 创意作品集 | 低 | 大胆、有表现力 | 展示级标题 | 大尺寸媒体、极简界面 |
| 内部管理后台 | 极高 | 中性、实用主义 | 紧凑无衬线 | 密集表格、批量操作、搜索 |
| 医疗 | 中 | 沉稳、高对比、可访问 | 清晰易读、略大字号 | 表单、状态指示、时间轴 |
| 金融 | 高 | 可信、保守 | 精确、适配表格 | 数字展示、图表、交易列表 |
| 营销落地页 | 低 | 品牌化、活力 | 抓眼球 | Hero 区、社交证言、CTA |
告诉 Skill 你在构建什么类型的产品。这个信号会塑造密度、色彩方向、字体选择和布局模式。
好的请求应该告诉 Codex 产品类型、受众、风格方向和技术栈。
Use $ui-ux-pro-max to improve this ecommerce fee calculator page.
Audience: sellers comparing payment fees.
Style: practical, dense, trustworthy, not a marketing landing page.
Stack: React with Tailwind.
Keep the existing content structure, but improve layout, hierarchy, controls, and responsive behavior.
这个 Skill 应该先生成设计系统建议，也就是在动代码前确定布局模式、色彩、字体、效果和反模式。
Skill 正常工作时会先产出类似这样的设计系统，然后才写代码：
设计系统：费用计算器工具
─────────────────────────────────
布局模式：工具页（非落地页）。
- 上方为配置区域，下方为结果区域。
- 移动端单列，桌面端两列。
- 无 Hero 区域，无营销文案。
调色板： "深蓝专业"
- 背景：slate-950（暗色模式）或 white（亮色模式）。
- 表面卡片：slate-900 / gray-50。
- 主强调色：cyan-500。
- 成功：emerald-500。警告：amber-400。错误：red-400。
- 文字：白色/黑色，主要文字 90% 透明度，次要 60% 透明度。
字体： "Inter + 等宽数字"
- 标题：Inter，600 字重，紧凑字距。
- 正文：Inter，400 字重，16px 基础字号。
- 金额和费用：tabular-nums 变体，确保数字列对齐。
效果：
- 卡片使用细微边框（1px，10% 透明度）。
- 无阴影，无渐变。
- Hover：轻微背景变化，不做缩放。
反模式（禁止使用）：
- 无大尺寸 Hero 区。
- 无装饰性插画。
- 无卡片套卡片。
- 无数字跳动动画。
- 无玻璃态或新拟态效果。
这已经具体到可以实现，同时也约束得足够紧、能防止常见的设计错误。反模式部分尤其有价值——它告诉 Codex 这个页面不是什么。
如果没有设计系统，Codex 很容易只修局部症状：这里缩一点卡片，那里加一条边框，再换一个颜色。局部可能好了，但整体仍然不统一。
有了设计系统，决策会互相连接：
例如，费用计算器应该安静、实用、偏运营工具感。它不应该使用巨大的营销 Hero、卡片套卡片或装饰性渐变。作品集可以更表达性；数据仪表盘则需要更密集的对齐、稳定控件和可扫描结构。
拿费用计算器页面来说。应用设计系统之前：
应用工具页设计系统之后：
区别不是妆饰性的。第一个版本看起来像碰巧加了个计算器的营销页，第二个版本用起来像工具。
ui-ux-pro-max 按行业和氛围组织调色板。不要凭感觉选颜色，而是按场景选：
一个好的调色板至少要有六个角色：背景、表面、主色、强调色、成功色、错误色。如果调色板只定义了三个颜色，它在 UI 工作中是不完整的。
搭配 配色生成器 探索色彩方向，用 取色器 从参考截图中提取精确颜色。
字体搭配讲的是角色分工，不是品味偏好：
避免在一个页面上搭配超过两种字体家族。一种标题字体 + 一种正文字体几乎总是够用。如果确实需要第三种，只用于代码块或数据展示。
提示词越具体，结果越可控：
Use $ui-ux-pro-max to redesign the top configuration card.
Current problem: the amount input and fee presets are side by side, which looks unbalanced when content grows.
Preferred direction: vertical layout. Amount input on top, configuration below, output cards underneath.
Preserve existing calculations and translations.
这段话说明了真实 UX 问题，也保护了业务逻辑。Codex 就能专注在布局和表现上，不会误改计算规则。
如果是新页面，可以这样写：
Use $ui-ux-pro-max to design a SaaS dashboard for weekly support metrics.
Audience: operations managers.
Style: compact, calm, information-dense.
Required views: KPI row, trend chart, queue table, filters, and empty states.
Stack: React and Tailwind.
发出 ui-ux-pro-max 请求之前，确认涵盖了以下几点：
漏掉任何一个都会让输出更难预测。最常被漏掉的是问题陈述——但它恰恰是最重要的。
ui-ux-pro-max 与 Tailwind 配合很好，因为两者都是 utility-first 思路。Skill 可以生成 Tailwind 专用的调色板配置：
// tailwind.config.js 扩展
colors: {
brand: {
50: '#f0f9ff',
500: '#06b6d4',
900: '#0f172a',
}
}
对于 shadcn/ui 项目，Skill 可以推荐在不与库默认样式冲突的情况下遵循设计系统的组件组合方式。
对于 React 项目，Skill 可以推荐组件结构、UI 模式的状态管理（暗色/亮色、展开/折叠、编辑/查看），以及响应式断点策略。
Skill 覆盖了 Vue 和 Svelte 的模式，包括响应式设计令牌（CSS 自定义属性绑定到组件状态）、过渡指令实现动效，以及 scoped style 策略。
对移动端项目，Skill 会将建议适配到平台规范：导航模式（标签栏 vs 抽屉）、触摸目标尺寸（最小 44pt）、安全区域处理以及平台适配的字体比例。
ui-ux-pro-max 不仅用于创建，也用于审查：
Use $ui-ux-pro-max to review this tool page for layout, hierarchy, responsive, and accessibility issues.
Focus on: consistent spacing, scan order, mobile usability, and color contrast.
Skill 应该输出按优先级排列的问题列表：
发布前修复阻塞和重要问题。轻微问题可以进入 backlog。
可访问性不是设计完成后单独跑的检查清单。ui-ux-pro-max 从一开始就把它当作设计约束：
prefers-reduced-motion。动画应该有目的且可降级。要求 Skill 在每次生成的设计系统中包含可访问性说明。带着约束做设计，比事后补可访问性容易得多。
这些模式在 AI 生成界面中频繁出现，应该明确避免：
工具页应该展示工具本身。如果首屏是带标语和"立即开始"按钮的 Hero 区，真正的工具在首屏之下——这个页面的模式就错了。工具页应该让工作流在第一屏即可见可用。
卡片里面套卡片再套卡片，制造视觉噪音还浪费空间。对大多数 UI，一层表面抬升就够。卡片内的分组用边框或背景色变化，而不是嵌套卡片。
当每个元素都使用同一色相、只是饱和度不同时，UI 看起来是单调的，而且不是好的那种单调。即使品牌色很强烈，也要引入中性色阶（灰色）和语义色（绿色成功、琥珀警告、红色错误）。
只展示快乐路径的 UI——有数据、没错误、没空列表——是不完整的。每个展示数据的组件都需要：加载态、空态、错误态，以及边缘情况（超长文字、超大数字、零值）。
Hover 状态如果添加边框、改变字重或显示隐藏元素，会导致布局偏移。使用 box-sizing: border-box，为状态变化预留空间，优先使用透明度/颜色过渡而非尺寸变化。
计算器或格式化工具页面上的图库照片、抽象 3D 插画和装饰性渐变，只增加视觉负担而不增加效用。如果一张图片不能帮用户完成任务，就移除它。
使用随机 padding 和 margin 值（这里 12px，那里 17px，别的地方 23px）是让 UI 感觉"碎了"的最快方式。坚持一套间距比例：4px、8px、12px、16px、24px、32px、48px、64px。Tailwind 的间距系统是不错的默认选择。
前端设计经常需要一些小工具辅助：
这些工具不能替代设计判断，但可以让工作流更具体。
前端改动完成前，可以检查：
prefers-reduced-motion？第一，只说"做漂亮一点"，却不给产品上下文。CRM、游戏和个人作品集不应该长得一样。
第二，把工具页做成落地页。计算器、格式化工具、仪表盘应该在首屏展示真实工作流，而不是先放一大段营销介绍。
第三，接受布局跳动。工具栏、卡片、网格和输入区应该有稳定尺寸，避免 hover 状态或动态内容让页面重新挤压。
第四，整页只用同一个色系。单一色相很容易显得扁平。好的调色板需要中性色、强调色、成功/警告/错误状态和足够对比度。
第五，只设计了快乐路径。如果你的 UI 没有加载骨架屏、空状态提示、错误展示和禁用控件样式，它就不完整。
第六，把设计系统当作事后补救。在已经写了 500 行 UI 代码之后再让 ui-ux-pro-max 来"修一下设计"，远比在建第一个组件之前用它设定设计方向难得多。
ui-ux-pro-max 最好在写大量 UI 代码前使用。它的价值不是给完成品贴装饰，而是提前塑造设计方向。使用时要给出产品上下文、约束、技术栈和你真正想解决的 UX 问题。这个 Skill 不是设计的替代品——它是一层设计推理，帮助 Codex 做出统一、有语境的决策，而不是靠猜。