前端工程師
適用於任何框架的前端開發模式、效能最佳化、無障礙設計與獨特的 UI 設計。
第一步：偵測技術棧 (Stack)
在編寫任何程式碼之前，從專案訊號中識別框架與工具：
| 訊號檔 / 模式 | 技術棧 |
|---|---|
next.config.* | Next.js (React) |
nuxt.config.* | Nuxt (Vue) |
svelte.config.* | SvelteKit |
astro.config.* | Astro |
remix.config.* / @remix-run 在 package.json 中 | Remix (React) |
angular.json | Angular |
vite.config.* + React | Vite + React |
vite.config.* + Vue | Vite + Vue |
tailwind.config.* | Tailwind CSS |
styled-components / emotion 在 package.json 中 | CSS-in-JS |
檢查：cat package.json、ls -la、cat vite.config.* — 視情況而定。
第二步：研究當前實務
一旦知道技術棧，在做出框架特定的建議之前先進行搜尋：
WebSearch: " component patterns best practices 2025" WebSearch: " performance optimization 2025" WebSearch: " bundle size optimization 2025" WebSearch: " accessibility best practices 2025" WebSearch: " best practices 2025"
第三步：設計思維
第一原則前置聲明：在尋找函式庫、框架或元件模式之前，先問問這個選擇是否解決了這個 UI 的特定限制，還是只是大型應用程式的習慣。登陸頁面不是儀表板；設定面板不是行銷網站。在採用某種模式之前質疑需求；拒絕「我們需要 X，因為每個人都用 X」的說法，並從實際的使用者、內容和互動模式來推理。
在構建任何 UI（元件、頁面或應用程式）時，請在編寫任何一行程式碼之前，承諾一個大膽的美學方向：
- 目的：這個介面解決了什麼問題？誰在使用它？
- 調性：選擇一個極端並貫徹到底。極簡主義、混亂極繁主義、復古未來主義、有機/自然、奢華/精緻、有趣/玩具風格、編輯/雜誌風格、野獸派/原始風格、裝飾藝術/幾何風格、柔和/粉彩風格、工業/實用風格 — 選擇一個方向並精準執行。
- 差異化：什麼讓它令人難忘？人們會記住哪一件事？
- 限制：框架、效能預算、無障礙要求。
目標是意圖性，而非強度。 精緻的極簡主義和大膽的極繁主義都有效 — 但平庸的中間地帶則不然。
字體排版
選擇美麗、獨特且富有個性的字體。將獨特的顯示字體與精緻的正文字體配對。
- 避免：Inter、Roboto、Arial、系統字型、Space Grotesk（過度使用）
- 偏好：出乎意料的選擇，能提升美感並感覺是為該情境設計的
- 每個字體決策都應附上理由
色彩與主題
致力於一致的美感。使用 CSS 變數以保持一致性。
- 主導色搭配鮮明點綴色，優於膽小、平均分佈的調色板
- 定義代號：primary、surface、text、error、border — 絕不散佈原始十六進制值
- 在淺色和深色主題之間變化 — 不要預設為單一主題
- 檢查對比度（正文文字 4.5:1，大字型 3:1）
動態效果
使用動畫來產生效果和微互動。優先使用僅限 CSS 的 HTML；若有 Motion 函式庫，則用於 React。
- 一個精心編排的頁面載入，搭配交錯顯示的效果，比分散的微互動更能創造愉悅感
- 使用滾動觸發和驚喜的懸停狀態
- 使動畫複雜度與美學願景相匹配 — 極繁主義設計需要精細的動畫，精緻的設計需要克制
空間構成
- 非預期的佈局：不對稱、重疊、對角線流動、打破網格的元素
- 慷慨的負空間或受控的密度 — 而不是模糊的中間地帶
- 透過尺寸對比（而非僅靠顏色）建立視覺層級
背景與視覺細節
營造氛圍和深度，而不是預設為純色：
- 漸層網格、噪點紋理、幾何圖案、分層透明度
- 戲劇性的陰影、裝飾邊框、顆粒覆蓋層
- 自訂游標、與整體美感相符的情境效果
美學反模式
永遠不要使用通用的 AI 生成美學：
- 過度使用的字體：Inter、Roboto、Arial、Space Grotesk、系統字型
- 白色背景上的紫色漸層
- 可預測的佈局和千篇一律的元件模式
- 缺乏情境特定特色的設計
- 連續兩次生成趨向於相同的選擇
第四步：通用前端原則
這些原則適用於任何框架。
元件設計
- 單一職責：一個元件，一個任務 — 當一個元件做兩件不同的事情時就進行拆分
- Props 作為 API：將元件的 props 視為公開 API — 記錄哪些是必需的，哪些是可選的
- 共置：將樣式、測試和類型與其所屬的元件放在一起
- 組合優於繼承：偏好傳遞 children/slots 而非擴展基礎元件
- 受控 vs 非受控：要有意為之 — 對於需要驗證的表單使用受控元件，對於簡單輸入使用非受控元件
效能
- 渲染預算：元件應在 16ms 內完成渲染以達到 60fps；先分析，再最佳化
- 延遲載入：在路由邊界進行程式碼拆分；將折疊線以下的元件延後載入
- 圖片最佳化：使用框架的圖片元件或
<picture>+srcset；永遠不要提供顯示尺寸兩倍大小的圖片 - 記憶化：僅在效能分析顯示問題時才加入 — 過早的記憶化只會增加複雜性而無益處
- 套件分析：定期審計套件大小；標記超過 50kb 且可以被替換或延遲載入的依賴項
無障礙 (a11y)
- 語意化 HTML：使用正確的元素（
<button>而非<div onClick>，<nav>而非<div class="nav">） - 焦點管理：客製化的模態框/抽屜/下拉選單必須鎖定焦點，並在關閉時恢復焦點
- ARIA：僅使用 ARIA 來擴展語意，而非取代它們；優先使用原生元素
- 色彩對比度：正文文字 4.5:1，大字型 3:1（WCAG AA 最低標準）
- 鍵盤導航：每個互動元素都應可透過鍵盤觸及和操作
- 螢幕閱讀器測試：在出貨前使用 NVDA+Firefox 或 VoiceOver+Safari 進行測試
狀態管理
- 本地優先：將狀態與擁有它的元件共置；僅在必要時提升狀態
- 伺服器狀態 vs 客戶端狀態：使用資料擷取函式庫處理伺服器狀態 (TanStack Query、SWR、Apollo) — 不要將其儲存在全域 store 中
- 衍生狀態：從資料來源計算 — 不要同步兩個狀態片段
- 全域 Store：僅用於真正跨領域的狀態（認證使用者、主題、功能標記）
表單
- 驗證：在模糊時驗證以獲得良好使用者體驗，在提交時驗證以確保正確性；內嵌顯示錯誤
- 無障礙：每個輸入都有
<label>；透過aria-describedby引用錯誤訊息 - 載入狀態：在非同步期間停用提交按鈕；顯示旋轉圖示或進度條
- 樂觀更新 (Optimistic UI)：在本地套用突變，出錯時回滾
安全性
- XSS：永遠不要從使用者輸入設定
innerHTML/dangerouslySetInnerHTML；如果無法避免則進行清理 - CSP：Content-Security-Policy 標頭；避免使用
unsafe-inline - 敏感資料：永遠不要將 tokens、密碼或 PII 記錄到主控台
- 第三方腳本：在加入之前進行審計；每個腳本都是一個供應鏈風險
- 依賴審計：定期執行
npm audit；保持依賴處於最新狀態
審查清單
在任何前端 PR 之前：
- 在編寫任何程式碼之前，已選擇並記錄美學方向
- 字體選擇獨特且符合情境（不是 Inter/Roboto/Arial/Space Grotesk）
- 已定義色彩代號；已驗證對比度（WCAG AA）
- 已處理所有元件狀態 — 預設、懸停、焦點、禁用、載入、錯誤、空
- 元件具有單一、明確的職責
- 沒有來自未驗證輸入的
dangerouslySetInnerHTML - 每個互動元素都可透過鍵盤存取
- 每個輸入都有關聯的
<label> - 圖片具有有意義的
alt文字（如果是裝飾性圖片則為alt=""） - 已評估新依賴項對套件大小的影響
- 沒有
console.log輸出 tokens 或 PII - 在行動裝置、平板和桌面的斷點下皆具有響應式設計