这个 Skill 能做什么，适合哪些场景？
这是一个面向编码 Agent 的 UI/UX 咨询 Skill，核心定位是“耐心的访谈者”而非“特定审美的助手”。它把规则严格分成两层：10 条跨风格通用的 UX Hard Rules，以及 8 个由项目自选的风格家族，避免把某一种审美当成全局标准。它提供三种模式：design（默认，通过对话生成 design-spec.md）、review（输出 P0/P1/P2 修复清单）和 guide（输出某类页面的该做/不该做规则）。触发前它会先静默扫一遍项目代码，了解现有 token 和 UI 框架，再开始提问。仓库自带 8 个 eval 测试用例和大量参考文档。
进入 design 模式时，先读取项目的 tailwind.config / theme.ts / globals.css / package. 等文件，判断项目处于五档中的哪一档（空白、半成品、成熟、复杂遗留、不确定），再决定走完整流程还是捷径；随后逐项询问产品、品牌参考与约束，为每个 token（颜色、字体、圆角、间距、阴影、动效及容器策略、图标、装饰、语言四个扩展维度）给出 2–3 个不带星标的并列选项；通过 config 驱动的 HTML 预览模板在 dashboard / marketing / form 等 5 类面型上渲染候选方案（支持 Compare、Full、dark mode 和 viewport 切换），最终在项目根目录生成 design-spec.md。review 模式基于 HCI 定律、认知偏差和设计心理学参考文档输出按 P0/P1/P2 分级的问题清单、修复建议和验收检查点。guide 模式输出纯要点式的 do/don't 规则。它不会因“这个按钮颜色对吗”这类轻量问题启动完整流程。
- 启动新项目的开发者，想通过对话定下一套项目专属的颜色、字体、圆角、间距、阴影、动效，并生成 design-spec.md 作为团队和 AI 的共同规范
- 接手了 token 分散、组件风格不统一（比如圆角 4/8/16 混用）半成品项目的工程师，想先整理现有决定再补全缺口
- 维护 Web 管理后台的团队，想评审现有界面并获得按 P0/P1/P2 分级的修复清单和验收检查点
- 为 B 端长表单、dashboard、设置页等特定页面类型快速获取该做/不该做 UX 规则的开发者
- 项目已有强烈品牌资产（logo、brand book）的团队，希望所有 token 从现有品牌派生而非套用某个流行风格
- 同时使用 Codex / Claude Code / Cursor / Windsurf 的开发者，希望设计规范指令通过 AGENTS.md 在多个工具间共享
如何安装这个 Skill？
- 本评估为静态源码审查，未执行任何测试；evals. 的行为断言未经实际运行验证。
- 预览模板引用 Google Fonts CDN，中国大陆网络下字体可能加载失败，但不影响核心功能。
- 技能会写入项目根目录的 design-spec.md 并调用系统 open 命令，使用前请知悉这些副作用。
- README 与 evals. 的用例数（8 vs 12）不一致，说明文档维护存在漂移；无版本号与 changelog。
- 最终 design-spec.md 由模型生成，需人工校对后方可作为团队规范采用。
- 本地文件系统
方式一：用 skills CLI 安装到多个 Agent：
npx skills add oil-oil/ui-ux-guide --list
npx skills add oil-oil/ui-ux-guide -a codex -a claude-code -a cursor -a windsurf
加 -g 可全局安装。方式二：手动克隆：
git clone https://github.com/oil-oil/ui-ux-guide ~/.codex/skills/oiloil-ui-ux-guide
Skill 正文位于 skills/oiloil-ui-ux-guide/SKILL.md；仓库通过 AGENTS.md 作为跨工具共享入口，CLAUDE.md 和 .cursor/rules/*.mdc 桥接到它。
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/oil-oil/ui-ux-guide.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/oiloil-ui-ux-guide" ~/.claude/skills/
rm -rf "$tmp"根据源仓库地址和 Skill 路径自动生成，只复制这个 Skill 的文件夹。如果上文有作者提供的安装方式，请优先按作者说明操作；想只在当前项目中使用，把 ~/.claude/skills 换成项目里的 .claude/skills。
如何使用这个 Skill？
安装后，把下面任意一句发给 Agent 即可触发：
- 请使用 $oiloil-ui-ux-guide 帮我把这个项目的设计规范定下来
- 帮我定一套这个项目的颜色和字体
- 评审这个仪表盘
- 给我表单页的 UX 规则
两种触发方式：显式点名（“请使用 $oiloil-ui-ux-guide 帮我把这个项目的设计规范定下来”）或直接描述任务（“帮我定一套这个项目的颜色和字体”/“评审这个仪表盘”/“给我表单页的 UX 规则”）。未指定模式时默认进入 design；review 和 guide 需要显式说明。仓库 README 提供了三种模式各自的推荐提示词模板，可在提示中注明背景、要求和约束（例如“先扫一遍现有 design tokens 再开始问我”“不要按某种风格家族评判我们”）。
这个 Skill 有哪些优点和局限？
- 规则分层设计清晰：10 条跨风格的 UX Hard Rules 与 8 个项目自选的风格家族互不越界，避免了把某种审美当全局标准
- 访谈式交互：先静默扫代码再开口，选项并列不带星标推荐，把决定权交给用户
- 自带 config 驱动的 HTML 预览模板，支持多候选对比、dark mode 和 desktop/tablet/mobile 切换
- 跨工具支持完善，提供 AGENTS.md / CLAUDE.md / Cursor rules 桥接和 skills CLI 一键安装
- 参考文档体系完整（访谈流程、风格家族、HCI 定律、设计心理学、评审模板、各面型清单），并带 8 个 eval 测试用例
- 设计流程较长（Phase 0–5 共多轮对话），不适合想要快速单一答案的场景；轻量问题 skill 会主动拒绝进入完整流程
- style-neutral 意味着它不会替你拿主意——除非明确询问，它不给出 starred 推荐
- evals. 仅 8 个测试用例，覆盖深度有限；README 未提供实际使用效果或用户验证数据
- 最终产物是 Markdown 规范和静态 HTML 预览，不直接修改项目代码或生成组件实现
- 预览模板需要用户在浏览器中手动刷新查看，无自动化截图或对比报告
这个 Skill 与同类方案有什么区别？
与相关 Skills 并排比较；分数均按同一 FSRS 标准得出。
| Skill | FS 评分 | Star 数 | 最近更新 | License |
|---|---|---|---|---|
| UI/UX 咨询顾问 本页 | 56 · 谨慎使用 | ★ 113 | 1 个月前 | Apache-2.0 |
| Figma 设计系统页面构建器 ✓ OpenAI · 官方 | 46 · 谨慎使用 | ★ 28k | 4 个月前 | — |
| 原型提示词生成器 | 59 · 推荐 | ★ 2.8k | 5 个月前 | AGPL-3.0 |
| Stitch 设计系统文档生成器 | 45 · 不推荐 | ★ 8.5k | 2 个月前 | Apache-2.0 |
| Stitch 界面生成器 | 45 · 不推荐 | ★ 8.5k | 2 个月前 | Apache-2.0 |
FollowSkills 如何评估这个 Skill？
技能无网络请求、无凭据读取、无隐藏外发数据；副作用限于读取项目文件、写 design-spec.md 到项目根目录、生成 /tmp 下的 HTML 预览并调用 open 命令，数据流基本透明，用户可随时回滚删除文件。扣分：文件写入和 open 系统命令没有显式确认环节，最低权限声明不完整。
SKILL.md 与 references 内部高度自洽（Phase 0-5 流程、五档判断、契约文件互相引用一致），对歧义输入有默认行为和宣布机制，evals. 覆盖 12 个行为断言包括异常路径（过度触发、用户坚持）。扣分：静态审查无法执行验证；README 称 8 个测试用例而 evals. 实有 12 个，存在文档不同步；evals 仅为行为断言、无自动可运行测试，失败反馈质量未经验证。
触发条件与非触发条件在 description 中明确界定（狭义问题不触发），三种模式边界清晰，明确支持中文（eval 9 专门测试 CJK 字体与中文业务稿），对大陆网络基本无外部服务依赖（Google Fonts CDN 仅影响预览字体加载，非核心功能）。扣分：预览模板依赖 Google Fonts CDN，大陆网络下字体加载可能受限；实际触发精度只有行为断言、无执行证据。
文档分层好（SKILL.md → references 渐进披露）、有安装说明、Apache-2.0 许可、跨工具桥接、已知限制有披露（Phase 4b 跳过场景）。扣分：无版本号与 changelog，README 与 evals. 用例数不一致，无明确维护责任声明和更新路径。
核心价值主张清晰：以结构化访谈产出项目专属 design-spec.md，相对手动做法有明确边际价值（强制代码扫描、五档分流、业务稿门控）。扣分：静态审查无法验证输出质量，最终产物依赖模型行为而非确定性脚本，产出 design-spec.md 仍需用户大量校对，无代表性已验证输出。
有可审计的主要材料：完整的 references 体系、12 条行为断言 evals、业务稿契约等一手文件。扣分：无第三方执行证据、无 CI 测试工作流、断言不可自动复现，作者行为声明与实际表现之间的相关性未证实。
点击维度查看打分理由
证据充分度：低 — 主要依赖静态检查、作者材料或有限演示；适合发现线索，不适合做高风险决策。
查看完整评分方法 →