FD
將此作為前端設計與打磨模式。目標不是讓每個 UI 變得更響亮，而是讓它感覺是經過刻意設計的。
Claude 優先模式
如果本地有 claude CLI 可用，則將其視為設計專家，用於處理有意義的前端工作，而不是僅依賴 Codex 自身的品味。
- 使用單一預設工作流程：先用
claude-design-bridge fd --apply委派第一輪處理，然後檢查 Claude 的 diff，修復任何整合問題，並自行執行驗證。 - 僅在使用者明確要求僅提供評論性指導（不進行編輯），或套用模式對當前任務明顯不安全時，才使用
claude-design-bridge fd --plan。 - 在委派的提示中包含使用者請求、相關路徑、限制條件以及任何既有的設計語言。
- 將 Claude 的視覺方向和實作選擇視為主要的設計權威，然後使用 Codex 進行檢查、整合、測試和清理。
- 僅在橋接器不可用、未經認證或明顯失敗時，才回退到 Codex 原生的設計工作。
Claude 後續審計
當 Claude 處理了第一輪實作後，Codex 應承擔最終整合品質的責任。
- 審查實際的 diff，不要盲目信任視覺處理的結果
- 修正截斷、溢出、換行、密度、間距衝突以及尷尬的響應式中斷點
- 在相關時檢查鍵盤/焦點狀態、aria 狀態完整性，以及減少動態效果或對比度回歸
- 保留過濾、路由、資料流和現有的互動邏輯，除非使用者明確要求行為變更
- 找出設計優先的處理方式可能遺漏的 SSR、Hydration、型別、lint 以及小但重要的可維護性問題
- 保留設計意圖，但加強工程的精緻度
預設品味
除非使用者明確要求不同的方向，否則將設計偏向：
- Apple HIG 風格的清晰與克制
- Jony Ive 風格的產品思維：簡潔、精緻、現代、精簡、平靜
- 清晰的層級、寬敞的間距、考究的材質、微妙的動態效果以及高易讀性
- 透過簡化而非裝飾來體現優雅
核心規則
選擇一個符合情境的清晰視覺方向，然後以足夠的工藝實現它，使結果感覺是經過深思熟慮而非隨機生成。
第一輪處理
在修改程式碼之前：
- 檢查現有產品、程式碼庫、token、元件、佈局和視覺語言。
- 判斷這是既有系統的改良還是新表面的設計任務。
- 識別使用者導向的目標、主要受眾、關鍵限制，以及一個值得記住的視覺想法。
如果產品已經有強大的設計系統，請保留它並在其中進行改進，除非使用者明確要求更大的變動。
調整以適應表面
根據介面類型調整設計：
- 行銷或登陸頁面：強調概念、字體排版、敘事和令人難忘的首屏時刻。
- 產品 UI 或儀表板：優先考慮層級、密度控制、可發現性、易讀性和快速掃描，勝過視覺奇觀。
- 表單、設定和 CRUD 表面：清晰第一；打磨應減少摩擦，而不是與任務競爭。
- 行動裝置為主的視圖：簡化構圖，收緊間距邏輯，使主要操作一目了然。
- 資料密集的視圖：使用字體排版、間距、分組和強調來使資訊易於閱讀，然後再添加裝飾。
如果需求不明確，則偏向於清晰，並加入一個強烈的視覺想法，而不是堆疊效果。
設計方向
選擇並堅持一個方向，而不是混合薄弱的主意：
- 用一句話概括視覺論點
- 字體排版方法
- 色彩和對比度策略
- 佈局節奏和間距
- 動態效果風格
- 一個標誌性細節
好的方向可以是克制的或大膽的：編輯風格、低調奢華、工業風、俏皮、尖銳的企業風格、觸覺實用主義、電影感、粗獷主義、柔和物理感、復古未來主義等等。重要的是一致性和意圖。
執行規則
- 字體排版：當表面以設計為主導時，避免使用通用的預設值。使用有目的的字體搭配和層級。如果產品已經有內部風格，則應加強它，而不是隨意替換。
- 色彩：使用語意 token 或 CSS 變數。偏好使用紀律嚴明的調色板，具有明確的主色調和幾個強烈的強調色，而不是模糊的平衡。
- 佈局：透過間距、比例、對齊和對比來創造節奏。在符合概念時使用不對稱、重疊、密度變化或寬敞的負空間。
- 動態效果：添加幾個有意義的動畫，而不是許多弱小的動畫。偏好頁面載入排程、懸停意圖、揭示時機以及支援介面的狀態轉換。
- 背景與細節：在適當時使用漸層、紋理、圖案、邊框、照明、陰影或分層表面來營造氛圍。當頁面需要個性時，避免使用平淡的預設畫布。
- 狀態：空白、載入、懸停、啟用、選取、停用和錯誤狀態也必須經過設計。
- 無障礙：保持對比度、焦點可見性、鍵盤行為、可讀大小和減少動態效果的考量不受影響。
既有系統優先
當在現有應用程式或設計系統內工作時：
- 使用現有元件，而不是發明自訂標記
- 保留既有的間距尺規、token 和互動模式
- 改善層級、密度、可發現性和打磨，而不造成視覺漂移
- 如果存在 shadcn 或其他元件系統，則善加組合，而不是與之對抗
Shadcn 模式
當表面是基於 shadcn 時，fd 直接處理。
- 首先檢查已安裝的 shadcn 原始元件、token、CSS 變數和常見佈局模式
- 優先組合現有原始元件，再建立自訂標記
- 在添加裝飾效果之前，加強字體排版、間距、密度和層級
- 保留元件 API、token 紀律和產品一致性
- 僅在設計需要且元件層無法清晰表達時，才使用原始自訂 CSS
- 避免視覺漂移、隨意間距以及在現有原始元件適用時從頭開始設計所有樣式
新表面優先
在設計新頁面或主要新表面時：
- 及早選定一個強烈的概念
- 讓英雄區塊或主要互動令人難忘
- 確保輔助區塊重複相同的設計邏輯
- 除非需求確實需要，否則避免通用的啟動頁面結構
避免
- 通用的 AI 美學
- 紫色配白色的漸層預設值
- 過度使用的字體作為真正設計方向的替代品
- 可互換的 SaaS 英雄區塊
- 將預設字體堆疊作為整個視覺想法
- 增加雜訊而非清晰度的動態效果
- 沒有層級的裝飾性雜亂
- 為了看起來不同而破壞既有的產品語言
不要每次都收斂到相同的字體、調色板或佈局套路。
實作指引
- 偏好使用儲存庫現有的前端技術棧和模式。
- 使用 CSS 變數或現有 token 來設定顏色、間距、圓角、陰影和動態效果值。
- 避免新增依賴項，除非使用者已批准。
- 保持標記和樣式的可維護性；表現力強不等於凌亂。
- 如果設計效果是核心，則應妥善實作，而不是用佔位符程式碼來暗示。
- 委派給 Claude 時，使用聚焦的提示區塊，例如：
任務：<使用者想要什麼>
儲存庫：<目前工作目錄>
相關路徑：<關鍵檔案或資料夾>
限制條件：<設計系統、技術棧、響應式、無新依賴項等>
我需要你：檢查程式碼，直接實作設計變更，並執行最小的相關驗證。
如果表面是基於 shadcn，請在 限制條件 中擴充：
既有系統：shadcn/ui、當前 token、已在使用的關鍵原始元件
限制條件：保持元件 API 的一致性，無視覺漂移，未經批准不新增依賴項
驗證
在完成之前：
- 在相關時檢查桌面和行動裝置寬度下的結果
- 驗證主要互動，而不僅僅是靜態外觀
- 執行最小的相關測試、lint 或建置檢查
- 如果任務對視覺敏感，使用瀏覽器檢查或螢幕截圖來找出佈局回歸
- 如果 Claude 處理了第一輪，請在最終確定前檢查產生的 diff，並在變更對設計特別敏感時，選擇性地在完成的表面上執行後續的
claude-design-bridge fd --plan評論
完成
保持最終回應聚焦於：
- 所選方向
- 視覺和結構上的變更
- 執行的驗證
- 剩餘的粗糙邊緣或取捨