# Ckw Design

> 前端设计入口：方向指引、设计系统、视觉理念。在构建或调整任何 Web UI（组件、页面、仪表盘、React/Vue/HTML-CSS）的外观时使用，或当用户说「让这个好看一点」「修复间距/布局」，或提及样式、颜色、字体或打磨时使用。触发词：前端设计、UI 设计、视觉设计、设计系统、视觉打磨、视觉方向、组件设计、页面设计、仪表盘、视觉层次、视觉风格。

- Skill: `kscz0000/ckw-design` (Agent Skill)
- Install (CLI): `npx skillmds@latest add kscz0000/ckw-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kscz0000/ckw-design/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- License: MIT
- Author: kscz0000 (https://skillmd.com/u/kscz0000)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/kscz0000/ckw-design

---

## 何时使用

在构建或为 Web UI 添加样式时使用——组件、页面、仪表盘、落地页、React/Vue/HTML-CSS 布局——或在用户要求让某个东西"更好看/更漂亮"、修复间距/布局，或提及样式、颜色、排版、字体、响应式设计、打磨、美学时使用，即便没有出现"设计"这个词。

_来源：[connerkward/ckw-design-skill](https://github.com/connerkward/ckw-design-skill)（MIT）。_

# 设计（入口）

当用户要求构建或为 Web UI 添加样式时使用本技能：组件、页面、仪表盘、落地页、React/Vue/HTML-CSS 布局，或任何前端界面。目标：产出独特、可用于生产环境的成果，避免千篇一律的 AI 美学。

**在宣称任何设计"完成"之前：渲染它，并让一个*独立的*评审者来评价图像**（而不是代码、不是自我打分）——参见 design-spatial §1。盲目的生成看不到自身的碰撞；这适用于所有设计输出，不仅仅是空间类工作。

> **强制横向溢出检查门——在任何 Web UI 被视为"完成"之前必须执行。**
> 在**窄宽度（约 390px 和约 1024px）下，本轮**测量 `document.documentElement.scrollWidth - document.documentElement.clientWidth`，并确认其为 `0`。这个 bug 在桌面宽度下不可见，每当某一行（头部、导航、工具栏）新增一项时就会再次出现，因此反复被发布。默认在头部/工具栏行使用 `flex-wrap:wrap`，并在 `body{overflow-x:clip}` 中设置，**并在向横向行添加任何元素后重新测量。** 完整流程与复发案例：design-spatial §4。如果你没有在窄宽度下测量，就不算完成——不要宣称。

## 子技能（在相关时加载）

- **design-thinking**——为每个设计任务加载。定义目的、基调、领域、色彩世界、评审标准，以及跨领域视角（电影、建筑、营销、UX、汽车、工业设计）。参见 [design-thinking/SKILL.md](https://github.com/connerkward/ckw-design-skill/blob/main/design-thinking/SKILL.md)。
- **design-system**——在实施时加载：设计令牌、排版、动效、色彩语义、背景。在构建组件、页面或设计系统时使用。参见 [design-system/SKILL.md](https://github.com/connerkward/ckw-design-skill/blob/main/design-system/SKILL.md)。
- **design-spatial**——在编排布局时加载：显式网格 + 8 点间距约束、视觉权重/平衡/对齐，以及渲染-后-评价的视觉循环。用于修复"空间理解偏差"——生成那种居中成一团、错位或在某宽度下崩坏的布局。参见 [design-spatial/SKILL.md](https://github.com/connerkward/ckw-design-skill/blob/main/deterministic-design/design-spatial/SKILL.md)。
- **design-ux**——在审计可用性（不仅仅是外观）时加载：一个"感觉不对劲"/"用着难受"、难以学习、需要一面操作说明墙的 UI，或任何交互式工具/编辑器/应用在发布前都需要审计。通过一个*独立*的全新视角评审者对照 Nielsen 10 条 + 交互启发式为渲染后的 UI 评分 → 输出按优先级排列的修复清单。可用性 ≠ 美学。参见 [design-ux/SKILL.md](https://github.com/connerkward/ckw-design-skill/blob/main/deterministic-design/design-ux/SKILL.md)。
- **design-philosophy**——在高概念工作、营销活动，或当用户要求视觉理念、宣言、或具有不可混淆的艺术性美学时加载。参见 [design-philosophy/SKILL.md](https://github.com/connerkward/ckw-design-skill/blob/main/design-philosophy/SKILL.md)。

## 视觉资产——生成或获取

当 design-thinking 识别出对视觉资产（标志、图标、主视觉图像、纹理、背景）的需求时：

1. **生成** → 使用图像生成模型或 API 生成合成/品牌化资产。
2. **获取真实的/档案图片** → 免费图库或档案图片搜索，通常比生成更便宜也更真实。
3. 使用 design-thinking 的输出（基调、领域、色彩世界）来撰写提示词/查询。
4. 依据设计理念进行评估、迭代，并集成到构建中。

## LLM 辅助工作——始终注明模型与成本

当设计工作涉及运行 LLM（生成资产、VLM 分析、布局评审、提示词生成等）时：

- **运行前：**说明将使用哪个模型以及预估成本（例如"gpt-4o-mini · 约 $0.005/张"或"FLUX v1 · 约 $0.006 每次生成"）。
- **结果产出后：**在输出上注明所用模型、实际成本（若与预估不同），以及任何关键参数（种子、提示词、设置）。成本必须*对用户可见*（在消息中、对比页头部或资产说明中），而不是埋在日志里。
- **原因：**用户正在决定成本与质量的权衡是否值得。未标注或隐藏的成本隐藏了最重要的调节杠杆。本规则镜像用于生成资产的 `media-attribution-rule`，并将其扩展到设计工作流中的任何 LLM 操作。

**示例：**
- "对 8 个设计运行 gpt-4o-mini 布局评审 · 预估约 $0.04 合计"（运行前）。
- 对比页头部："FLUX v1 · $0.48 合计（6 次生成 × $0.08）"（运行后）。
- 资产说明："hero_banner_flux-dev_seed3891.jpg"（种子使结果可复现）。
- 不确定性滑块结果："对 46,978 张图像进行 VLM 分流 · gpt-4o-mini · 约 $9.40"（运行前）；"✓ 完成：12,447 张图像已分类 · gpt-4o-mini · $7.62"（运行后）。

## 算法/模型解释器——展示公式、标注术语

每当 UI 向用户展示算法或模型时（"ⓘ 原理"面板、模型分解、方法说明），**包含实际的公式，使用排版格式，并标注其关键术语**——不要止步于文字。仅用文字描述的打分器（"按所选颜色所占比例排序"）是无法证伪的敷衍；而带有逐项标注的公式 `score = Σ fracᵢ · max(0, 1 − ΔEᵢ/τ)` 则精确地告诉用户这个旋钮的作用，并建立起背后确有真实数学的信任。

**如何应用：**
- 每个算法渲染一个干净、居中的公式——"性感"的核心，而不是每一个细节。使用规范记号：σ 表示 sigmoid、Σ 表示求和、‖·‖ 表示范数、上标、ΔE、∇²；使用与正文区隔开的等宽/衬线数学块。
- **逐项标注每个符号**，紧接其下方：`e_x`、`w`、`τ`、`Q` 各代表什么，各占一行。未标注的公式是装饰；已标注的才是规格说明。
- 保持轻量依赖——风格化的 HTML/Unicode 数学即可，且能离线工作；只有在表达式确实需要时才引入 KaTeX/MathJax。
- 写出**决策规则**与评分并列（例如"P ≥ 0.55 则为个性化"）。
- 这与上面的模型+成本标注相互配合：公式说明*计算什么*，模型/成本行说明*用什么来跑、跑了多久*。

**示例（一个 logistic 头）：**
> P(personal │ x) = σ(**w**·**e**ₓ + b),  σ(z) = 1 / (1 + e⁻ᶻ)
> • **e**ₓ —— 图像的 768 维嵌入 · **w**, b —— 从你的标签中学习到的权重
> · 决策：P ≥ 0.55 为个性化，P ≤ 0.40 为参照。

## "全选"必须配套"取消全选"——不存在死路选择

任何**"全选"**交互都必须配套一种**清除所选项**的方式——最好就是*同一个按钮*，在所有项已选时切换标签（"全选" ⇄ "取消全选"）。没有反向操作的"全选"是一个陷阱：用户过度选择（或本能地点了它），然后不得不逐个取消点击，或重新加载页面，才能恢复。代价是无声的——只在*他们已经提交了错误集合之后*才会咬人。

**如何应用：**
- **切换同一个按钮**（最简单、最少的控件）：当所有可见项已选时，按钮显示"取消全选"并清除；否则显示"全选"。一个控件，无死路。
- 或者当选择非空时显示一个单独的**清除/取消选择**控件。
- 取消选择必须作用于**与"全选"相同的范围**（所有*已显示的*、所有*已筛选的*、所有*当前页的*）——不要让"全选"抓取 500 项，而"清除"却只丢屏幕上的 50 项。
- 这可推广到一般情况：任何可逆的批量切换（选择、全部展开、全部静音、全部勾选）都需要其反向操作触手可及。动作的对称性——参见 restraint-rule（不要让用户卡在任务中途）。

## 局限性

- 本技能改善视觉方向和评审纪律，但不能替代在实际浏览器或设备上渲染真实的 UI 并进行检查。
- 部分建议假设可访问截图、浏览器自动化或视觉评审；当这些不可用时，将指引视为设计检查清单而非证据。
- 来自产品方的品牌、法律、可访问性和本地化约束优先于本处的审美规则。