Toothpick：挑出 AI 味，打造經得起考驗的介面
這份指南是什麼
這裡沒有「永遠用這個字型」或「絕不能用那個顏色」這類規則。你可以使用任何顏色、字型或版面配置。
它做兩件事：
- 幫助你辨識 AI 味：哪些選擇是 AI 未經思考的預設值，以及為什麼人們一眼就能看出來。
- 幫助你避免常見缺陷：那些讓介面看起來粗糙、廉價或不專業的錯誤。
只有一個測試：這個選擇是為了這個產品做的，還是你為了任何產品都會這麼做？ 後者就是 AI 味。
使用者的明確風格、品牌指南和現有程式碼風格永遠優先，即使他們要求的正是下面列出的「AI 味」之一。
AI 味是什麼
在每個設計決策上，AI 都會傾向於最常見的選項。它分為兩個層次。
第一層，老套的陳腔濫調：紫色到藍色的漸層、用 emoji 當圖示、帶灰色陰影的相同圓角卡片、「置中標題加三個功能卡片」的登陸頁面、像是「解鎖無限可能」的文案。很多人已經能認出這些。
第二層，假裝有品味：一旦被告知「不要讓它看起來像 AI 生成的」，AI 會切換到另一套同樣固定的裝扮：
- 奶油色紙張背景、大型襯線標題、赭紅色或深紅色強調色，偽裝成「溫暖有品味」
- 接近黑色的背景、一種螢光綠、琥珀色或朱紅色強調色、到處都是等寬字型，偽裝成「駭客風」
- 報紙風格的黑色細線、零邊框半徑、密集欄位，偽裝成「瑞士專業風」
- 每個標題上方都有全大寫標籤、到處都是「A · B · C」中間點字串、每個連結後面都有「→」、每個小數據標籤都用等寬字型、在非序列的內容上使用「01 / 02 / 03」
- 巨大的裝飾性數字、為不對稱而不對稱、使用終端機的「$」提示符或「●」狀態點作為裝飾
第二層更難察覺，因為它看起來像是「被設計過的」。但它和第一層是同樣的問題：風格是被套上去的，而不是從產品中生長出來的。
完整清單，以及為什麼每一項看起來像 AI，以及何時實際上是 OK 的，在 references/ai-tells.md 中。
好的介面長什麼樣
references/benchmarks.md 包含來自 Vercel、GitHub、ChatGPT、Google 和 Linear 的測量數據，以及中國產品 DingTalk、Juejin、WeChat Read 和 sspai，以及中文介面的差異（更重的標題、更高的行高、更小的尺寸）。這些英文參考資料的共同點：
- 非常少的顏色：幾乎全是黑色、白色和灰色，加上一種功能性顏色
- 一種字體家族；標題很大但不是很粗
- 輕微的分隔：空白、淺色細輪廓、非常淡的陰影，而不是黑色規則和重陰影
- 產品本身是主角；裝飾幾乎為零
- 每個畫面一個焦點
這些是參考，不是模板。一間咖啡店不應該看起來像 Vercel，但它應該同樣克制和精準，並把內容放在前面。
參考資料本身也可能變成新的預設值。如果你最近的幾個專案，遮住名稱後看起來都一樣——白色、中性灰、藥丸按鈕和細邊框面板——那麼參考資料已經變成模板了。用它來校準工藝：線條要多細、陰影要多柔軟、標題要多細。顏色、材質和主角則來自步驟 2 的清單。
工作流程
0. 首先，評估變動規模
| 變動 | 範例 | 要執行的步驟 |
|---|---|---|
| 小 | 顏色、間距或文案變更；修正一個元件；新增一個按鈕 | 閱讀相關程式碼和樣式變數，在現有樣式中修改，檢查 references/ai-tells.md 中少數相關條目，並用一兩句話交付（只有在有佔位符時才附上佔位符清單） |
| 中 | 在現有產品中新增一個頁面或一個新功能的畫面 | 步驟 1，一個三到四行的計劃，然後步驟 5 到 7。保持產品現有風格；跳過清單盤點和論點 |
| 大 | 新產品、網站、登陸頁面、重新設計 | 全部七個步驟 |
有疑問時，選擇較小的規模；使用者會要求更多。不要為一個按鈕寫設計計劃。
1. 理解這是什麼：先閱讀專案，再閱讀訪客
-
在現有專案中，在接觸任何東西之前先閱讀它。 在任何計劃或程式碼之前，找出：
- 該專案實際上具有哪些功能（閱讀 README、路由、頁面和 API；不要從頁面標題猜測）
- 現有元件、樣式變數、圖示集和字型。新的 UI 使用它們；不要啟動一個並行系統
- 資料模型和 API 回傳的真實欄位。基於這些欄位建構 UI
- 文案中現有的詞彙。用同一個名稱稱呼同一件事
用幾行寫下「這個專案有什麼」，並基於此制定計劃。對於任何你無法讀取的內容（例如，後端不在儲存庫中），詢問使用者或明確說明你的假設。
-
產品或內容是什麼？是給誰用的？如果不清楚，做出具體的假設，用一句話說明，然後繼續，而不是反覆詢問。
-
決定這個頁面的模式（判斷頁面，而非產品：開發者工具的首頁是「說服」，其儀表板是「操作」）：
| 模式 | 訪客的成功定義 | 範例 | 設計重點 |
|---|---|---|---|
| 說服 | 決定並行動 | 首頁、登陸頁面、活動頁、定價頁 | 觀點與衝擊；用真實圖像說服 |
| 操作 | 完成任務 | 管理後台、儀表板、編輯器、設定、工具 | 可掃讀、一致、高效；個性存在於精確的細節中 |
| 閱讀 | 理解內容 | 文件、文章、幫助中心、更新日誌 | 清晰的結構、舒適的閱讀體驗 |
| 展示 | 沉浸於作品中 | 作品集、畫廊、案例研究 | 作品領先，介面退居幕後 |
匹配參考：說服和展示使用 references/web.md，操作使用 references/app-desktop.md，行動裝置另外使用 references/mobile.md。專案 README 及其內部的思維導圖或圖表使用 references/readme.md。
- 改良還是重新設計？ 改良保持現有風格、文案和行為，只更改範圍內的東西。重新設計替換整體外觀，但保留產品事實、內容和功能。不要將新風格半途而廢地修補到舊風格上。
2. 盤點只屬於這個主題的東西
寫下 8–12 個具體的、屬於這個客戶且不屬於任何競爭對手的東西：名稱及其含義、街道和城市、門牌號碼和商店招牌、材料和顏色、它的數字（座位數、海拔、營業年數）、它的限制（一個月一批、冬天關閉）、它的儀式（烤箱在五點點燃）、它世界中的印刷品（收據、標籤、時刻表）。
設計想法來自這個清單，而不是來自「這個行業的網站通常長什麼樣」。我們參考的一個開源技能進行了盲測：勝出的頁面使用了這類清單中的項目；失敗的頁面則有基於通用行業理念的良好構圖。
3. 在選擇區塊之前先寫下論點
行銷頁面的每個區塊都應該是一個主張及其證據，每個一行：
主視覺：本週三次烘焙，週五出貨 → 證據：三個袋子，烘焙日期
咖啡豆：每種都有清晰的產地和風味 → 證據：真實產地、海拔、杯測筆記
...
刪除任何沒有主張的區塊。這可以讓你避免陷入標準的「主視覺、Logo 牆、三個功能、客戶推薦、定價、常見問題」結構。
4. 寫一個簡短的計劃
- 顏色：4–6 個值，每個值說明使用位置
- 字型：哪些字型以及各自的用途
- 版面：一句話說明想法，如果有用則加上簡單的 ASCII 線框，以及對齊方式
- 主視覺：這個頁面上最有說服力的東西，以及你實際上擁有哪些素材（不要圍繞不存在的圖像進行設計）
- 強度：克制（操作和閱讀模式的預設值）、一個主角（說服模式的預設值：從盤點清單中選一個大膽的圖像，其他一切保持安靜）、或一個完整概念（請參閱下方「何時投入一個強烈的概念」）
5. 檢查計劃：預設值還是選擇？
- 如果收到類似的簡報，我會得出大致相同的計劃嗎？如果是，那部分就是預設值；回到步驟 2 的清單尋找靈感。
- 它是否擊中了
references/ai-tells.md中的任何內容？如果是，更改它，或者能夠說明為什麼這個產品需要它。 - 裝飾是否多於內容？
在你的回覆中簡短說明你更改了什麼以及為什麼。
6. 建構
- 使用 CSS 變數管理顏色和間距。注意選擇器特異性，避免 class 互相覆蓋（特別是區塊 padding）。
- 範例內容是真實且具體的，並且數字加總正確。
- 當頁面顯示產品的介面時（例如 SaaS 首頁上的螢幕截圖區塊），將其建構為該產品的真實片段：真實數據、加總正確的數字、一個明確的發現。而不是灰色區塊和假數字。
- 工藝細節在
references/craft-details.md中。
7. 查看結果，分批修正，然後移除一個東西
- 查看真實尺寸：桌面、手機（約 375px）、如果有建構深色模式也要看。一次查看，一起修正所有問題；不要在每次調整後都截圖。
- 瀏覽
checklist.md。 - 就像離開家前檢查鏡子一樣，移除一個配件。
- 當你無法看到結果時（模型無法讀取圖片，或沒有瀏覽器）：不要假裝你看過了。改為審查程式碼：最長的文字在每個斷點是否能容納於欄位中、根據顏色值計算的對比度是多少、所有互動狀態是否都已編寫？在你的交付中說明你尚未在瀏覽器中看過，並請使用者提供一張桌面和一張手機截圖，以便進行另一輪檢查。
克制不是空無一物
移除裝飾只完成了一半的工作。一個失去了標籤、規則和卡片，卻沒有得到任何東西來填補的頁面，讀起來會很薄弱，並且可能會輸給一個仍然有一些 AI 味但更豐富的頁面。另一半是實質內容：更大膽的字級範圍、整片的顏色區塊、這個主題世界的真實圖片、每個區塊都填滿了完整內容。
何時投入一個強烈的概念
克制是預設值，不是天花板。當以下所有條件成立時，一個整個頁面的視覺概念（例如漫畫、報紙、技術圖紙、票券）是合適的：
- 它有來源：使用者要求了它，或者這個主題本身的世界講述了這種語言（建築師的圖紙、印刷廠的打樣、鐵路時刻表），而且你可以在步驟 2 的清單中找到它
- 每個裝置都對應到內容：將對應關係寫下來，例如「速度線：堆積的請求」、「網點密度：鎖的沉重程度」。捨棄任何無法對應的裝置
- 它仍然能被準確閱讀：程式碼、數字、表格和按鈕仍然可以無誤地閱讀和點擊。概念服務於內容，絕不讓人誤讀
- 事實不變：新的風格保留所有的產品事實、功能、數字和佔位符清單
- 它知道何時停止：在主線中充分使用它，並在細節中保持克制；不要在任何角落都放置主題元素
如果它不符合任何一項，則退回使用一個主角：只在主視覺或一個區塊中使用該語言。與風格服裝的區別：服裝適合任何產品（奶油色和襯線、接近黑色和霓虹燈、報紙細線）；一個強烈的概念只對這一個產品有意義。
當你交付時，用一兩句話解釋設計理念，以便使用者可以輕鬆引導，並附上佔位符清單（請參閱「不造假，不愚弄開發者」）。
當使用者要求更改時
| 使用者說 | 意思 |
|---|---|
| 更大膽 | 更大的尺寸對比、整片的顏色區塊、更大的主視覺。而不是更多裝飾 |
| 更安靜 / 太雜亂 | 更少的顏色和動畫、更少的字型大小、移除次要元素 |
| 簡化 | 刪除沒有主張的區塊和元素；保留核心 |
| 更精緻 | 工藝：對齊、間距、圓角、陰影、狀態、瀏覽器原生部分 |
| 可以發佈了嗎？ | 錯誤狀態、空狀態、非常長的內容、其他語言、邊界情況 |
不造假，不愚弄開發者
使用者和開發者都應該能夠分辨什麼是真實的，什麼是尚未完成的。
不要在使用者面前造假
- 沒有虛構的標誌、客戶 Logo 牆或合作夥伴徽章。沒有用「$」、「▲」或「●」等符號組成的假 Logo；沒有 Logo 時，使用純文字的產品名稱就夠了。
- 沒有虛構的使用者數、滿意度、成長率、客戶推薦或媒體報導。
- 檢查專業事實（技術細節、標準、法規、醫學、金融、統計）。AI 可以流暢地撰寫這些內容，而其錯誤看起來也同樣流暢：
- 列出頁面上的專業聲明。在文件或標準中查閱你能查到的內容，並在程式碼註解中引用來源
- 你無法確認的內容，要嘛省略，要嘛在佔位符清單中列在「未驗證」下
- 頁面上的數字必須相互一致（每秒 70 個請求持續 41 秒是 2,870 個請求）
不要愚弄開發者
- 沒有虛構的功能：介面中顯示的每個功能都存在於專案中，或是被明確要求的。不要為了讓頁面看起來更好而添加「智慧推薦」或「一鍵匯出」。
- 模擬數據絕不冒充真實數據：在可能的情況下連接真實 API。當你無法連接時，將模擬數據放在一個地方（例如
mock/），使用與真實 API 相同的欄位，並在程式碼中標記為模擬。不要將吸引人的數字硬編碼到元件中，讓頁面看起來像是「完成了」。 - 沒有假的互動：一個未連接的按鈕、表單或連結，不能有點擊動畫假裝它運作正常。停用它並標記為「未連接」，或在交付說明中列出。
- 從頭開始建構的展示和概念可以使用虛構的品牌和數據，但頁面必須說明這是一個範例。
附上佔位符清單
對於任何未完成的內容，附上一份簡短的清單：
- 缺少的資料庫或 API 欄位
- 待確認的事實和數字
- 你需要品質保證使用者產生的內容的區塊
- 你做出的但需要確認的假設
將它放在交付說明的頂部，以便開發者知道可以真正信任什麼。
可供參考的參考資料
使用這些文件；本技能包含它們是有原因的。
| 檔案 | 用途 | 何時閱讀 |
|---|---|---|
references/benchmarks.md | 良好介面的測量與模式 | 規劃新產品或重新設計時；校準工藝時 |
references/ai-tells.md | 完整的 AI 味清單以及何時它是 OK 的 | 審查你的計劃時；檢查成品時 |
references/craft-details.md | 字型、間距、陰影、按鈕的具體細節 | 建構時；需要超越基礎知識時 |
references/web.md | Web 的版面模式和約定 | 為說服或展示模式規劃時 |
references/app-desktop.md | 桌面應用程式的模式和約定 | 為操作模式規劃時 |
references/mobile.md | 行動裝置的考量（較小的點擊目標、滑動手勢、單欄） | 任何需要行動裝置的時候 |
references/readme.md | 專案 README 和圖表的模式 | 規劃或寫作 README 文件時 |
checklist.md | 在交付前要檢查的內容 | 步驟 7 |
關於本技能
Toothpick 是由 Ethan Marcotte（@beep）啟發的一個想法的直接實踐。它是在 Nils Binder（@nilsbinder）的「Design to the nines」工作後衍生的，並借鑒了 Andy Bell（@piccalilli_）的「Be the browser's mentor」中提出的概念。