---
name: toothpick
description: "设计或修改任何用户界面时使用：网页、落地页、官网、后台管理、桌面软件、移动 App、组件、仪表盘、表单、深色模式、配色、字体排版、README、思维导图，也包括“做个页面”“美化一下”“改改样式”“写个前端”这类请求。帮助识别并去掉 AI 生成界面的模板感和常见缺陷，做出克制、精确、贴合产品本身的设计。Use for any UI, frontend, web, app, dashboard, README or diagram design task."
---

# 牙签：去掉 AI 味，做出像样的界面

## 这份指南是什么

这里没有"必须用什么字体""禁止用什么颜色"的规定。你可以用任何颜色、字体、布局。

它只做两件事：
1. **让你认出 AI 味**：哪些做法是 AI 不假思索的默认值，为什么一眼就会被认出来。
2. **让你避开常见缺陷**：哪些地方做错了会显得粗糙、廉价、不专业。

判断标准只有一条：**这个选择是为这个产品做的，还是换成任何产品你都会这么做？** 后者就是 AI 味。

用户明确指定的风格、品牌规范、已有代码风格永远优先，哪怕用户要的正好是下面列出的某种"AI 味"。

---

## 什么是 AI 味

AI 在每个设计决定上都会滑向"最常见"的选项。它分两层：

**第一层，老套路**：紫蓝渐变、emoji 图标、千篇一律的圆角卡片加灰阴影、"居中大标题 + 三张功能卡"的落地页、"释放无限可能"式的文案。这些已经很多人能认出来了。

**第二层，假装有设计感**：AI 被要求"别做得像 AI"之后，会换上另一套同样固定的打扮：
- 米色纸张背景 + 衬线大标题 + 陶土色或暗红强调，假装"有温度、有品位"
- 近黑背景 + 一个荧光绿 / 琥珀 / 朱红强调色 + 等宽字体，假装"很极客"
- 报纸式黑色细线、零圆角、密集分栏，假装"很瑞士、很专业"
- 每个标题上面加一行全大写小标签，到处是 "A · B · C" 的中点分隔，链接后面都加"→"，小数据都用等宽字体，内容并不是步骤也标上"01 / 02 / 03"
- 超大的装饰数字、为了不对称而不对称的布局、用终端提示符"$"或者"●"状态点当装饰

第二层更难察觉，因为它看起来"很有设计"。但它和第一层是同一个问题：**风格是套上去的，不是从产品里长出来的。**

完整的识别清单（每条都说明了为什么、以及什么时候其实可以用）见 `references/ai-tells.md`。

## 好的界面长什么样

`references/benchmarks.md` 里有 Vercel、GitHub、ChatGPT、Google、Linear 的实测数据，也有钉钉、掘金、微信读书、少数派这几个中文产品，以及中文界面和英文界面的差别（标题更粗、行高更大、字号更小）。英文参照的共同点：

- 颜色很少，几乎只有黑白灰加一个功能色
- 一套字体，标题大但不粗
- 分隔很轻：留白、浅色细框、极淡阴影，而不是黑线和重阴影
- 产品本身是主角，装饰几乎为零
- 每一屏只有一个重点

这些是参照，不是模板。做咖啡店不该长得像 Vercel，但同样应该克制、精确、让内容当主角。

参照本身也会变成新的默认值。如果最近做的几个不同项目，遮住名字以后都是白底、中性灰、胶囊按钮、细框面板，说明参照被当成了模板。参照只用来校准做工的轻重：线多淡、阴影多轻、标题多细。颜色、材料和主角要从第 2 步的清单里来。

---

## 工作流程

### 0. 先看改动有多大
| 改动 | 例子 | 走哪几步 |
|---|---|---|
| 小 | 改颜色、间距、文案，修一个组件的问题，加一个按钮 | 读相关代码和样式变量，沿用现有风格直接改，对照 `references/ai-tells.md` 里相关的几条，交付时一两句说明（有占位才附清单） |
| 中 | 在已有产品里加一个页面或一个功能的界面 | 第 1 步、三四行的简短方案、第 5 到 7 步。风格沿用现有产品，不做盘点和论证 |
| 大 | 新产品、官网、落地页、改版 | 全部七步 |

拿不准时往小的一档靠，用户需要更多会说。不要为了一个按钮写设计方案。

### 1. 弄清楚这是什么：先读项目，再看访客来做什么
- **已有项目时，先读项目再动手。** 在写任何方案和代码之前，先弄清楚：
  - 项目真有哪些功能（看 README、路由、页面、接口，而不是凭页面标题猜）
  - 已有的组件、样式变量、图标库、字体，新界面要用它们，不要另起一套
  - 数据模型和接口返回的真实字段，界面按真实字段来做
  - 已有的文案用词，同一个东西保持同一个叫法

  读完用几行写下"项目里有什么"，后面的方案以它为准。读不到的部分（比如后端不在仓库里），直接问用户或者明确写出你的假设。
- 产品 / 内容是什么？给谁用？没说清楚时自己补一个具体假设，在回复里写一句，不要反复追问。
- **判断这个页面的模式**（按页面本身判断，不按产品判断：一个开发工具的官网是"说服"，它的后台是"操作"）：

| 模式 | 访客的成功是什么 | 例子 | 设计的重心 |
|---|---|---|---|
| 说服 | 做出决定并行动 | 官网、落地页、活动页、定价页 | 有观点、有冲击力，用真实画面说服 |
| 操作 | 完成任务 | 后台、仪表盘、编辑器、设置页、工具 | 好扫读、一致、高效，个性体现在精确的细节里 |
| 阅读 | 看懂内容 | 文档、文章、帮助中心、更新日志 | 结构清楚，阅读体验舒服 |
| 展示 | 沉浸在作品里 | 作品集、画廊、案例展示 | 作品领先，界面退后 |

  对应参考：说服 / 展示看 `references/web.md`，操作看 `references/app-desktop.md`，移动端另看 `references/mobile.md`。项目 README 和放在 README 里的思维导图、结构图看 `references/readme.md`。
- **改版还是优化？** 优化要保留现有的风格、文案和行为，只改范围内的东西；改版才换掉整体视觉，但产品事实、内容和功能要保留。不要在旧风格上"打补丁式"地换风格。

### 2. 盘点只属于这个对象的东西
写下 8–12 个**只属于这个客户、竞争对手没有**的具体事物：名字和它的含义、所在的街道和城市、门牌和招牌、用的材料和颜色、它的数字（座位数、海拔、营业年数）、它的限制（每月只烤一批、冬天歇业）、它的日常（早上五点点炉）、它世界里的印刷品（票据、标签、时刻表）。

设计的想法从这份清单里来，而不是从"这个行业的网站一般长什么样"里来。参考的开源 skill 做过盲测：胜出的页面都用了这类清单里的东西，输掉的页面构图不错，但用的是行业通用想法。

### 3. 先写"论证"，再决定板块
营销页每个板块都应该是一个**主张 + 证据**，一行写一个：
```
首屏：本周烘了三支豆子，周五寄出 → 证据：三只豆袋、烘焙日期
豆单：每支豆子都写清楚产地和风味 → 证据：真实的产地、海拔、杯测记录
……
```
没有主张的板块就删掉。这样可以避免"首屏 + logo 墙 + 三列功能 + 评价 + 价格 + FAQ"的套路结构。

### 4. 写一份简短方案
- 颜色：4–6 个色值，写清楚各自用在哪
- 字体：用哪几款，各自负责什么
- 布局：一句话说明思路，必要时画个简单的 ASCII 线框，写清楚对齐方式
- 主角：这个页面最有说服力的东西是什么，手上**真的有**什么素材（不要按不存在的图片来设计）
- 强度：克制（操作、阅读模式的默认）、一个主角（说服模式的默认：一个来自清单的大胆画面，其余安静），或者整体概念（见下面"什么时候做强概念"）

### 5. 对照方案自问：这是默认值还是选择？
- 换一个类似的需求，我会不会得到差不多的方案？会 → 这一项是默认值，回到第 2 步的清单里找想法。
- 有没有中了 `references/ai-tells.md` 里的某一条？中了 → 改掉，或者能说出这个产品为什么需要它。
- 装饰是不是比内容还多？

改了什么、为什么，简单写在回复里。

### 6. 实现
- 颜色、间距等用 CSS 变量统一管理；注意选择器优先级，避免类名之间互相覆盖（尤其是区块的 padding）。
- 示例内容要真实具体，数字要能对得上。
- 页面上展示产品界面时（比如 SaaS 官网首屏的截图位置），把它当成这个产品的一个真实片段来做：真实的数据、能对上的数字、一个明确的结论，而不是灰色色块和假数字。
- 做工细节见 `references/craft-details.md`。

### 7. 看成品，批量修改，最后删掉一样东西
- 在实际尺寸下看：桌面、手机（约 375px）、深色模式（如果做了）。一次看完、一起改，不要每改一处就截一次图。
- 对照 `checklist.md`。
- 像出门前照镜子一样，去掉一件多余的装饰。
- **看不到成品时**（模型不能看图，或者环境里没有浏览器）：不要假装看过。改成读代码检查：每个断点下的列宽放不放得下最长的文字，按色值算出文字对比度，交互状态是否都写了。交付时写明"没有在浏览器里看过"，请用户发一张桌面、一张手机的截图，再改一轮。

### 克制不等于空
去掉装饰只是一半。一个去掉了小标签、细线、卡片却什么都没补上的页面会显得单薄，甚至不如一个有点 AI 味但内容丰富的页面。另一半是**实质**：更大胆的字号、整块的颜色、这个对象世界里的真实画面、每个板块都把内容写满。

### 什么时候做强概念
克制是默认，不是上限。漫画、报纸、图纸、票据这种整页的视觉概念，下面几条都满足时就是对的：
- **有来源**：用户明确要了，或者这个对象的世界本身就有这套语言（建筑事务所的图纸、印刷厂的版样、铁路的时刻表），能在第 2 步的清单里找到
- **有对应**：每一个手法都对应一条内容。列一张对照表，比如"集中线：指向闯祸的那条 SQL""网点密度：锁的轻重"。对应不上的手法删掉
- **读得准**：代码、数字、表格、按钮仍然能被准确读出、准确点中。概念服务于内容，不能让人读错
- **事实不变**：换了风格，产品事实、功能、数据和占位清单一样都不能少
- **收得住**：主线用满，细节处照样克制，不要每个角落都塞主题元素

满足不了就退回"一个主角"：只在首屏或一个板块里用这套语言。它和"风格戏服"的区别是：戏服是不管什么产品都能套的那几套（米色衬线、近黑荧光、报纸细线），强概念是只有这个对象才说得通的那一套。

交付时用一两句话说明设计思路，方便用户直接提修改方向；同时附上占位清单（见"不伪造，不糊弄开发者"）。

### 用户要求调整时
| 用户说 | 意思 |
|---|---|
| 更大胆一点 | 加大尺度对比、用整块颜色、让主角更大，而不是加装饰 |
| 安静一点 / 太花了 | 减少颜色和动效、统一字号档位、去掉次要元素 |
| 精简 | 删掉没有主张的板块和元素，只留核心 |
| 再精致一点 | 做工细节：对齐、间距、圆角、阴影、状态、浏览器自带部件 |
| 能上线吗 | 补齐报错、空状态、超长内容、多语言、各种边界情况 |

---

## 不伪造，不糊弄开发者

做出来的东西要让用户和开发者都清楚：哪些是真的，哪些还没做。

**不伪造给最终用户看的内容**
- 不编造 logo、客户 logo 墙、合作伙伴标志；不用"$""▲""●"这类符号拼假 logo，没有 logo 就用产品名的纯文字。
- 不编造用户数、满意度、增长率、评价、媒体报道。
- **专业事实要核对**（技术细节、规范、法规、医疗、金融、统计数据）。AI 写这些内容很流畅，错了也看不出来：
  - 把页面上的专业说法列出来。能查文档、规范的就去查，在代码注释里写上出处
  - 查不到或拿不准的，要么不写，要么写进占位清单的"未核实"
  - 页面上的数字要互相算得通（比如每秒 70 次 × 41 秒 = 2,870 个请求）

**不糊弄开发者**
- **不编功能**：界面上出现的每个功能，项目里都要真的有，或者是用户明确要求做的。不要为了页面好看加上"智能推荐""一键导出"这类不存在的功能。
- **假数据不能冒充真数据**：能接真实接口就接；接不了时，模拟数据集中放在一个文件里（比如 `mock/`），字段和真实接口一致，代码里注明是模拟数据。不要把一堆假数字直接写死在组件里，让页面看起来"已经做完了"。
- **不做假交互**：没有接通的按钮、表单、链接，不能只做一个点击动画假装能用。要么禁用并写明"未接入"，要么在交付说明里列出来。
- **从零做演示或概念稿时**可以虚构品牌和数据，但要在页面上标明是示例。

**交付时附一份占位清单**

在回复里列出离真正上线还差什么，例如：
```
占位清单
- 模拟数据：mock/orders.ts（字段按 GET /api/orders 的返回结构）
- 未接通：「导出 CSV」按钮，「订阅」表单提交
- 待替换：首页客户评价【待补充】、产品截图【待补充】
- 我的假设：退款状态只有三种（待处理、已退款、已拒绝），需要确认
- 未核实：「部分退款不重新计算优惠券」，来自需求描述，没在代码里找到对应逻辑
```
没有占位就写"无"。

## 文案

文字也是设计的一部分，套话和模板化布局一样有 AI 味。
- 说清楚是什么、做什么，而不是推销：❌"释放团队潜能" ✅"把会议录音整理成待办清单"
- 按钮写会发生什么：❌"提交" ✅"保存修改"。同一个动作从头到尾用同一个词。
- 报错说清楚发生了什么、怎么解决，不道歉、不含糊。
- 空状态告诉用户下一步可以做什么。
- 不加没有用处的小标签、副标题、口号。

## 质量底线

这些不需要特意提，但必须做到：
- 文字对比度足够（正文至少 4.5:1）
- 键盘焦点可见
- 每个可交互元素都有悬停、按下、禁用等状态
- 手机宽度下不横向滚动、不重叠、不截断
- 尊重"减少动态效果"的系统设置
- 加载中、空数据、出错这些状态也要设计
- 深色模式不是简单反色（见 `references/big-company-details.md`）

## 参考文件

| 文件 | 内容 |
|---|---|
| `references/ai-tells.md` | AI 味识别清单：是什么、为什么、什么时候可以用 |
| `references/benchmarks.md` | 英文和中文产品的实测数据，以及中英文界面的差别 |
| `references/craft-details.md` | 做工细节：圆角、阴影、对齐、图标、交互、表单、浏览器自带部件 |
| `references/readme.md` | 项目 README 的结构和写法，以及 README 里思维导图的设计 |
| `references/big-company-details.md` | 苹果、谷歌、IBM、微软规范里的细节（深色模式、动效、点击区域等） |
| `references/typography.md` | 排版原则和中文字体的技术注意事项 |
| `references/color.md` | 配色思路和深色模式实现 |
| `references/web.md` | 网页 / 营销页常见问题 |
| `references/app-desktop.md` | 软件 / 后台 / 桌面端常见问题 |
| `references/mobile.md` | 移动端常见问题 |
| `checklist.md` | 自评时用的问题清单（有截图看截图，没有截图就对照代码） |