一句話說明
AI 寫前端元件很快,但產生的 JSX 和 Vue 模板經常包含 XSS 風險、缺少無障礙標記,而且會引入你不需要的依賴套件。
AI 前端開發的實際效率
用 Cursor 或 GitHub Copilot 開發前端元件,最大的效率提升在元件骨架和 CSS 樣式。飛飛實測下來,產生一個帶表單驗證的 React 元件大約省下 60-70% 的時間。但省下來的時間往往要花在修正 AI 沒處理好的部分:狀態管理邏輯、API 錯誤處理、邊界情境的 UI 呈現。
AI 常見的前端安全問題
XSS:dangerouslySetInnerHTML 和 v-html
AI 在需要渲染使用者提供的 HTML 內容時,經常使用 dangerouslySetInnerHTML(React)或 v-html(Vue):
// AI 常產生的寫法(XSS 風險)
function Comment({ content }) {
return <div dangerouslySetInnerHTML={{ __html: content }} />;
}
如果 content 來自使用者輸入且沒有經過消毒處理,攻擊者可以注入 <script> 標籤。修正方式是用 DOMPurify:
import DOMPurify from 'dompurify';
function Comment({ content }) {
const clean = DOMPurify.sanitize(content);
return <div dangerouslySetInnerHTML={{ __html: clean }} />;
}
如果不需要渲染 HTML,直接用文字節點就好,React 預設會跳脫文字內容。
依賴套件安全
AI 喜歡引入套件來解決問題。飛飛見過一個專案在 AI 輔助下開發三週後,package.json 多了 47 個新的依賴套件,其中 12 個超過一年沒更新,3 個有已知漏洞。
檢查方式:
# 檢查已知漏洞
npm audit
# 檢查過時套件
npm outdated
# 檢查沒有用到的套件
npx depcheck
原則:如果一個功能可以用 10 行程式碼寫完,不要為了它引入一個套件。AI 傾向用套件是因為它的訓練資料裡大量使用了這些套件,但你的專案不需要為了一個日期格式化功能引入整個 moment.js。
CSP 設定
AI 產生的前端專案幾乎不會設定 Content Security Policy。CSP 可以防止未授權的腳本執行,是防禦 XSS 的重要防線。
Next.js 在 next.config.js 中設定:
const securityHeaders = [
{
key: 'Content-Security-Policy',
value: "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:;"
}
];
module.exports = {
async headers() {
return [{ source: '/:path*', headers: securityHeaders }];
}
};
注意:如果你的前端使用了 inline script(AI 常產生這種程式碼),CSP 的 script-src 'self' 會擋下它們。要嘛改成外部腳本,要嘛用 nonce-based CSP,但不要直接加 'unsafe-inline'。
無障礙(Accessibility)問題
AI 產生的元件經常缺少無障礙標記。最常見的問題:
按鈕用 <div onClick> 實作,鍵盤使用者無法觸發。應該用 <button>。
圖片缺少 alt 屬性,或 AI 填了無意義的 alt 文字如「image」。
表單欄位缺少 <label> 元素或 aria-label。
Modal 彈窗沒有 focus trap,Tab 鍵可以跳到背景元素。
顏色對比度不足,AI 產生的淺灰色文字在白色背景上對比度低於 WCAG 要求的 4.5:1。
用 eslint-plugin-jsx-a11y(React)或 eslint-plugin-vuejs-accessibility(Vue)可以在開發時期抓到大部分問題。
工具使用建議
Cursor
適合元件開發。用 Composer 模式可以一次產生多個相關檔案(元件、樣式、測試)。在 .cursorrules 裡寫清楚專案的技術棧和元件慣例,可以讓產生的程式碼更一致。
建議在 .cursorrules 加入安全相關規則:
不要使用 dangerouslySetInnerHTML,除非明確指定。
所有使用者輸入都要經過驗證。
圖片一定要有描述性的 alt 屬性。
互動元素使用語義化 HTML 標籤。
GitHub Copilot
適合逐行補完。在寫元件邏輯時補完速度快,但容易產生和你專案風格不一致的程式碼。如果專案用 Tailwind,Copilot 有時候會產生 inline style 或引入不在專案中的 CSS 框架。
Claude Code
適合大範圍的重構和跨檔案修改。例如「把所有 class component 改成 function component」或「把 CSS Modules 換成 Tailwind」這類批次操作。但要注意它在修改過程中可能會改到不相關的檔案。
開發流程建議
飛飛建議的前端 AI 開發流程:
先手動建立專案結構和基礎設定(ESLint、Prettier、TypeScript config、CSP headers)。這些設定會影響 AI 後續產生的程式碼品質。
用 AI 產生元件骨架和基本功能。這是 AI 效率最高的部分。
手動檢查每個元件的無障礙標記和安全問題。AI 不會主動處理這些。
用 AI 產生單元測試,但手動補充邊界情境的測試案例。
在 CI 中加入 npm audit、ESLint 安全規則、Lighthouse CI 的無障礙分數檢查。
安全考量
前端程式碼是公開的。不要在前端程式碼裡放 API Key、內部 API 路徑、或任何不想讓使用者看到的資訊。AI 有時候會在前端程式碼中直接寫入 API Endpoint 的完整路徑,包含內部服務的域名。
使用 AI 工具開發前端時,注意不要把設計稿、客戶品牌素材、未公開的功能規格貼進公開版本的 AI 工具。Cursor 的 Privacy Mode 可以避免程式碼被送到伺服器訓練,但預設不是開啟的。
第三方套件的供應鏈攻擊是真實的威脅。AI 可能建議你安裝一個名稱和熱門套件很像的惡意套件(typosquatting)。安裝前檢查套件名稱、下載量和最後更新日期。
知識檢測
讀完文章後,測試一下你對這個主題的理解。
常見問題
AI 寫的 React 元件品質如何?
元件的視覺呈現和基本功能通常沒問題,但狀態管理、錯誤處理和無障礙支援經常需要修正。AI 傾向產生受控元件(controlled component),在簡單表單上沒問題,複雜表單可能導致不必要的重新渲染。
要不要用 TypeScript?
強烈建議。TypeScript 的型別定義會幫助 AI 產生更準確的程式碼,也更容易在編譯階段抓到 AI 產生的型別錯誤。AI 對 TypeScript 的支援度比純 JavaScript 好。
AI 產生的 CSS 有什麼問題?
AI 產生的 CSS 傾向用絕對單位和固定寬度,在小螢幕上可能跑版。建議在 Prompt 中明確要求用 rem 單位和 max-width 做響應式設計。另外 AI 常產生重複的樣式定義,可以用 CSS 分析工具找出冗餘。
Cursor 的 Composer 和 Chat 模式差在哪?
Composer 可以同時新增和修改多個檔案,適合新功能開發。Chat 適合問答和單一檔案修改。開發新元件時用 Composer,除錯時用 Chat,程式碼補完時用 Tab(inline completion)。
AI 能幫忙寫 E2E 測試嗎?
可以產生 Playwright 或 Cypress 的測試骨架,但 AI 寫的 E2E 測試通常只涵蓋正向流程。需要手動補充的情境包括:網路錯誤、載入狀態、空資料、權限不足的頁面跳轉。