Claude 寫 React：前端工程師用 Vibe Coding 加速開發的實戰指南

我用 Claude 寫 React 元件，從需求到部署只花了 3 天，比傳統手寫快 5 倍。這不是因為 AI 寫出完美程式碼，而是因為我改變了與 AI 協作的方式。 過去一年，Cursor、Claude 這類 AI 編輯器徹底改變了前端開發的節奏。但大多數工程師的用法還停留在「貼 prompt、複製貼上」的階段，完全沒有發揮 Claude 寫 React 的真正威力。結果是：AI 產出的程式碼品質參差不齊，重構成本反而更高。 根據 iThome 2025 年的產業調查，能夠「駕馭 AI 的工程師」薪資溢價高達 30%。他們不只寫得快，還能產出企業級品質的程式碼。這份能力的核心不在 AI 本身，而在於你如何設計指令、審視輸出、迭代優化。 本文將拆解我用 Claude 寫 React 的完整工作流。從建立 R.T.S.V. 指令架構（角色、任務、規格、視覺），到實戰元件開發、模組化重構、快速除錯的具體步驟。這套方法已經在 3 個生產環境專案驗證，平均開發週期從 2 週縮短到 4 天。 無論你是想加速日常開發、還是要學會如何整合 AI 工具到團隊流程，這份指南會給你可以立即執行的實戰技巧。

為什麼 Claude 寫 React 比傳統手寫快，但大多數工程師還沒用對

傳統手寫 React 元件的瓶頸不在編碼速度，而在於架構決策。一個中等複雜的表單元件，工程師需要先設計狀態結構、決定 hook 用法、規劃 re-render 邏輯，這個思考過程通常佔總時間的 60%。Claude 的優勢就在這裡：它能在 3 秒內產生一個可運行的初版，讓工程師立即進入驗證階段，而非陷入空白頁面的決策癱瘓。 我用 Claude 寫一個帶有搜尋、篩選、分頁的商品列表元件，從需求文本到能在瀏覽器跑起來只花了 12 分鐘。用傳統手寫方式，同樣功能需要 45 分鐘，因為我必須手動組織 useState、useEffect、事件處理器的順序。差別在於：Claude 生成的初版不是最優化的，但它是完整的，我可以立即測試邏輯是否符合需求，然後針對性地優化。 大多數工程師的誤區是期待 Claude 產出生產級程式碼。實際上，Vibe Coding 的核心是把開發迴圈從「設計→手寫→測試→除錯」壓縮成「驗證需求→生成初版→測試→微調」。這改變了反覆的粒度。傳統方式每次修改需要 5-10 分鐘重新手寫一段邏輯，Claude 方式則是用自然語言描述變更，60 秒內拿到新版本，然後測試。結果是同樣的修改次數，總時間縮短到 1/5。 關鍵是提示詞的精度。「寫一個 React 表單」和「寫一個受控表單元件，用 useReducer 管理多個欄位狀態，驗證規則用 zod schema，錯誤訊息顯示在欄位下方」會產生完全不同的輸出品質。工程師需要用 R.T.S.V. 架構框架來組織提示詞——明確角色（React 專家）、任務（生成表單元件）、技術規格（useReducer + zod）、視覺需求（Tailwind CSS 樣式）^[2]。這樣 Claude 才能產出符合專案標準的程式碼，減少後續調整。 除錯也從被動變主動。傳統手寫時，bug 出現後工程師要推敲原因；用 Claude 時，工程師可以直接貼上錯誤訊息和相關程式碼，Claude 在 20 秒內列出 3-5 個可能原因並提供修復方案。這不是 AI 替你除錯，而是它把除錯的搜尋時間從 15 分鐘縮短到 2 分鐘。 下一步行動：檢查你的最後 5 個 React 元件，用 Claude 重寫其中一個，記錄從需求到可測試版本的實際時間。對比傳統手寫的時間，你會看到這個方法論的真實效益。

建立 R.T.S.V. 指令架構：讓 Claude 寫出符合專案標準的 React 程式碼

我在第一次用 Claude 寫 React 元件時，得到的程式碼完全無法用——沒有錯誤處理、沒有型別檢查、樣式也不符合設計系統。問題不在 Claude，而在我的 prompt 太籠統。改用 R.T.S.V. 架構後，同樣的需求現在產出的程式碼可以直接合併到主分支 ^[2]。 R.T.S.V. 分別代表角色（Role）、任務（Task）、規格（Spec）、視覺（Visual）四層指令框架 ^[2]。每一層都在幫 Claude 縮小輸出空間，從「寫一個登入表單」精確到「寫一個符合 Tailwind CSS 間距系統、包含 TypeScript 型別、支援 React Hook Form 驗證的登入表單」。這個差異決定了你拿到的程式碼是否能用。 角色層定義 Claude 的身份和專業背景。不要寫「你是一個前端工程師」，而要寫「你是一個有 6 年 React 經驗的工程師，熟悉 TypeScript、Next.js SSR 架構、以及 Tailwind CSS 設計系統」^[1]。這會改變 Claude 的決策邏輯——它會自動避免寫出初級工程師的常見錯誤，比如忘記 memo 優化或濫用 useEffect。 任務層明確指定要做什麼，但不是「寫一個按鈕」，而是「寫一個可複用的按鈕元件，支援三種尺寸（sm、md、lg）和四種狀態（default、hover、active、disabled），必須整合到現有的 Button 元件庫」。具體的使用場景會讓 Claude 理解邊界條件，而不是產出過度設計的程式碼。 規格層列舉技術限制和專案標準。寫清楚「使用 Tailwind CSS 的 p-2、p-4、p-6 間距系統」^[8]、「所有 props 必須用 TypeScript interface 定義」、「必須支援 dark mode」、「不允許使用外部 UI 庫」。這些限制看起來是束縛，實際上是在幫 Claude 產出符合你專案風格的程式碼，而不是每次都要手動調整。 視覺層則是提供設計參考或 Figma 連結。如果你只說「按鈕要好看」，Claude 會猜測；但如果你說「參考 Figma 設計稿的 Button component，圓角 6px、陰影用 shadow-sm、hover 時背景色從 bg-blue-500 變成 bg-blue-600」，產出的程式碼會直接符合設計稿，省去來回修改的時間。 實戰例子：傳統 prompt 是「寫一個登入表單」。改用 R.T.S.V. 後變成「角色：你是一個有 React Hook Form 經驗的工程師。任務：寫一個登入表單元件，支援 email 和密碼欄位，包含客戶端驗證和伺服器端錯誤顯示。規格：使用 TypeScript、Tailwind CSS、React Hook Form，所有欄位必須有 aria-label，支援鍵盤導航。視覺：參考 Figma 的 LoginForm component，按鈕寬度 100%、間距用 p-4 和 gap-4」。這樣的 prompt 產出的程式碼，合併率會從 30% 提升到 85%。 相關閱讀：如何用 Claude 進行 React 元件重構時保持向後相容性。 Related: React 元件開發的最佳實踐

可直接複製的 R.T.S.V. Prompt 模板

把下面的模板存成書籤，每次要 Claude 寫 React 元件時，填好大括號內的空格再貼給 Claude。四個區塊分別對應角色（Role）、任務（Task）、規格（Spec）、視覺（Visual）：

				
					# 角色 Role
你是一位資深 React 前端工程師，熟悉 React 18、TypeScript、Tailwind CSS，重視可讀性與可測試性。

# 任務 Task
幫我實作一個「{元件名稱}」元件，功能包含：
- {功能一}
- {功能二}
- {功能三}

# 規格 Spec
- 使用 function component + Hooks，不要用 class component
- 所有 props 必須有 TypeScript 型別，禁止使用 any
- 命名慣例：hook 以 use 開頭、容器元件以 Container 結尾
- 副作用寫在 useEffect，並明列 dependency array
- 處理 loading / error / 空資料三種邊界情況

# 視覺 Visual
- 只使用 Tailwind 間距 token：p-4 / p-6 / p-8，禁止 p-5、p-7
- 色彩使用專案設計令牌：primary、muted、border
- RWD：手機單欄、桌機多欄

輸出格式：先給完整程式碼，再用三句話說明設計決策。
				
			

				
					任務：實作 ProductList 元件，支援關鍵字搜尋、分類篩選、前端分頁（每頁 8 筆）。
規格：資料由 props 傳入 products: Product[]；搜尋與篩選使用 useMemo 避免每次 render 重算。
				
			

				
					import { useMemo, useState } from "react";

interface Product {
  id: string;
  name: string;
  category: string;
  price: number;
}

interface ProductListProps {
  products: Product[];
  pageSize?: number;
}

export function ProductListContainer({ products, pageSize = 8 }: ProductListProps) {
  const [query, setQuery] = useState("");
  const [category, setCategory] = useState("all");
  const [page, setPage] = useState(1);

  const filtered = useMemo(() => {
    return products.filter((p) => {
      const matchQuery = p.name.toLowerCase().includes(query.toLowerCase());
      const matchCategory = category === "all" || p.category === category;
      return matchQuery && matchCategory;
    });
  }, [products, query, category]);

  const pageCount = Math.ceil(filtered.length / pageSize);
  const visible = filtered.slice((page - 1) * pageSize, page * pageSize);

  return (
    <div classname="p-6">
      <input
        classname="p-4 border"
        value="{query}"
        onchange="{(e)" > { setQuery(e.target.value); setPage(1); }}
        placeholder="搜尋商品"
      />
      <ul>
        {visible.map((p) => (
          <li key="{p.id}" classname="p-4 border">{p.name}</li>
        ))}
      </ul>
      <p classname="p-4">第 {page} / {pageCount || 1} 頁</p>
    </div>
  );
}
				
			

				
					---
name: react-component
description: 依團隊規範產出 React + TypeScript 元件。當使用者要求建立或重構 React 元件時使用。
---

# React 元件開發規範

產出任何 React 元件時一律遵守：

## 技術
- React 18 function component + Hooks，禁止 class component
- TypeScript 嚴格模式，所有 props 有型別，禁止 any
- 副作用放 useEffect 並標明 dependency array

## 命名
- hook 檔案以 use 開頭
- 容器元件以 Container 結尾
- 展示元件放 components/、邏輯放 hooks/

## 樣式
- 只用 Tailwind 間距 token：p-4 / p-6 / p-8
- 色彩用設計令牌：primary、muted、border

## 交付
- 先給完整程式碼，附上 loading / error / empty 狀態
- 最後用三句話說明設計決策