AI TracksSTUDIO
中文 EN
開始合作

React 與前端工程

用 Cursor 寫網站：Laravel 13 API + Blade 前台 + React 後台，一套棧走天下

用 Cursor 搭配 Laravel 13 API、Blade 前台、/backend React 後台、Tailwind + jQuery，以及「SQLite 開發、MySQL 上線」的資料庫策略，整理一套好寫、好維護、也好開玩笑的網站寫法。

2026.08.06 5 分鐘閱讀 Studio 管理員 到訪次數 37
用 Cursor 寫網站：Laravel 13 API + Blade 前台 + React 後台，一套棧走天下

有人問我：「現在還手寫網站嗎？」

我說：「手寫？我跟 Cursor 輪流寫。」

它負責把 boilerplate 一次吐完，我負責決定哪些東西不該長成「又一個紫色漸層儀表板」。兩邊各有專長——Cursor 很會補全；人類很會翻白眼。

下面這套棧，是我拿來做內容站、活動站、甚至小型電商後台時，最不想再重新發明輪子的組合：

層級 技術 一句話定位
API / 領域邏輯 Laravel 13 API 真正的大腦與契約
前台 UI Laravel Blade SEO 友善、伺服器渲染、改文案超快
後台 UI /backend React 複雜表單、列表、權限，交給 SPA
樣式與互動 Tailwind CSS + jQuery 樣式現代、小互動不必上整套前端框架
資料庫 SQLite（開發）→ MySQL（主戰場） 本機零摩擦，上線不開玩笑

聽起來像「前後端都有、還有第三種前端」？沒錯。這不是混亂，這是分工——誰該當主角，誰該當特效。

為什麼這套組合適合跟 Cursor 一起寫

Cursor 最強的地方不是「替你想產品」，而是在清楚邊界內瘋狂加速。

你給它的邊界越清楚，它越不會把 Blade 寫成 Next.js、把 API 寫成「直接在 view 裡查資料庫」。

所以先把合約講死：

  1. 瀏覽器看得到的前台 → Blade + Tailwind + 適量 jQuery
  2. 給編輯／營運用的後台 → React，掛在 /backend
  3. 兩邊都吃同一套 → Laravel 13 API（或同專案內的 API routes）
  4. 資料庫 → Eloquent 寫得跟 MySQL 友善；本機用 SQLite 起飛

Cursor 喜歡這種「角色清楚」的專案。你也會喜歡——因為 code review 時終於知道該罵誰。

1. Laravel 13 API：先把契約寫好，再談畫面漂不漂亮

API 不是「給 React 用的那個東西」，而是整站的憲法。

前台 Blade 要列表？打 API（或走同專案的 service，但回應形狀要一致）。
後台 React 要 CRUD？打 API。
未來若有 App、小程式、合作夥伴串接？還是打 API。

建議習慣

  • Resource Controllers + Form Request：驗證寫在門口，不要散落在前端
  • API Resource / Transformer：把資料庫欄位醜名藏起來，前端只看乾淨 JSON
  • 權限與 policy：後台 React 再漂亮，沒權限就是 403——請對 Cursor 說清楚「不要在前端藏刪除按鈕就算安全」
  • 版本意識：就算你現在只有 v1，也別把路由取名叫 /doStuff

跟 Cursor 合作的小撇步

提示詞寫清楚一點，例如：

新增文章 API：GET/POST /api/posts，欄位 title、slug、content_html、published_at；用 Form Request；回傳 API Resource；圖片上傳轉 WebP、檔名用 UUID。

它很會補齊 CRUD；你要負責補齊「為什麼 slug 不能改三次」這種產品智慧。

2. 前台用 Blade：SEO 要吃飯，SSR 是主廚

部落格、官網、活動頁——搜尋引擎與社群爬蟲才不管你 React hydrate 漂不漂亮。
Blade 在這裡是正確的無聊選擇。

優點很現實：

  • 首屏就是完整 HTML，Lighthouse 比較不會對你翻白眼
  • 行銷改文案、改區塊順序，常常只是改 .blade.php
  • 跟 Laravel 的 auth、session、validation error 天生合拍
  • Cursor 對 Blade + component 的補全通常很穩

Tailwind：讓 Blade 看起來像 2026，而不是 2012 管理後台

Tailwind 適合 Blade 的原因很單純：你在模板裡就能完成版面，不必在「CSS 檔案考古學」與「class 名稱發明大賽」之間來回。

原則：

  • 設計 token（顏色、字級、間距）先定，再讓 Cursor 擴充元件
  • 前台要有「一個視覺主張」，不是 dashboard 拼盤
  • 能用 utility 解決的，就別再開一個 custom-button-final-v3.css

jQuery：不是復古，是工具箱裡的螺絲起子

先說清楚：我不是要你用 jQuery 重寫整個 SPA。

前台常有的需求是：

  • 手機選單開關
  • FAQ accordion
  • 簡易表單 AJAX
  • lightbox、tab、sticky header

這些用一小段 jQuery（或甚至 vanilla）就結束了。為了「漢堡選單」拉一整包前端 build pipeline，那是拿滅火器烤土司。

規則：
互動是「頁面內小行為」→ jQuery / 輕量 JS。
互動是「應用程式狀態機」→ 去後台找 React。

3. /backend 用 React：複雜 UI 終於可以喘口氣

後台才是 React 該上場的地方。

文章編輯器、圖片上傳預覽、可篩選的資料表、批次操作、權限矩陣——這些東西硬塞進 Blade + 滿版 jQuery，最後會變成「只有當初那個工程師敢碰」的傳說檔案。

把後台獨立在 /backend 有幾個好處：

  1. 路由邊界清楚：使用者站是 /，營運站是 /backend
  2. 部署與權限好切：後台可以更嚴格的 auth、CSRF、角色
  3. Cursor 不容易串台：你說「這是 React admin」，它比較不會突然在 Blade 裡 useState

實務建議

  • Laravel 當 API + 靜態／建置後的 React 入口（Vite 建置到 public/backend 或反向代理，看團隊習慣）
  • 認證走 session cookie 或 token，但選一種並寫進 README，別讓 Cursor 每次猜
  • 表格、表單、上傳元件做成可重用模組；第二次做「文章管理」時才會覺得人生有希望

一句話總結分工：

Blade 服務讀者；React 服務編輯；API 服務兩者——以及未來的你。

4. SQLite 能跑，MySQL 才是正室

這條很多人嘴上說支持，手上卻用 DB::raw 寫出只有 MySQL 懂的方言，然後在 SQLite 測試時一臉無辜。

目標策略

環境 資料庫 目的
本機開發 / CI 快速測 SQLite 零安裝、遷移快、PR 好跑
Staging / Production MySQL 併發、備份、維運、生態成熟

寫法紀律（請貼進專案規則給 Cursor）

  1. 優先用 Eloquent / Query Builder，少寫資料庫方言
  2. migration 避開「只有某一邊才爽」的型別魔術；必要時用可攜寫法
  3. full-text、特定 JSON path、鎖表細節——若非必要，別在業務程式碼裡硬綁
  4. CI 至少跑一輪 SQLite；上線前用 MySQL 做真實驗證
  5. .env 切換，不要在程式碼裡 if (sqlite) ...

SQLite 是開發加速器，不是「我們上線也用檔案資料庫碰碰運氣」的邀請函。
MySQL 才是要養小孩（資料）的那個家。

5. 專案目錄心智模型（給未來的自己與 Cursor）

你不必照抄，但心裡要有地圖：

app/
  Http/Controllers/Api/     # API 憲法執行官
  Http/Controllers/Web/     # Blade 頁面控制器
  Models/
  Policies/
resources/
  views/                    # Blade 前台
  js/backend/               # React 後台原始碼
  css/                      # 或 Tailwind 進入點
routes/
  api.php
  web.php
database/
  migrations/               # 同時對 SQLite / MySQL 友善
public/
  backend/                  # React build 產物（示意）

Cursor 看到結構，就比較不會把「前台 CTA 按鈕」實作成「後台 Modal 裡的三層 Context」。

6. 一天開發節奏（幽默版，但意外實用）

  1. 早上：跟 Cursor 把 migration + Model + API Resource 生出來——此時咖啡還是熱的。
  2. 中午：Blade 把列表、內文、分页做出來；Tailwind 調到「看起來像有設計師」。
  3. 下午：React /backend 接同一套 API，做編輯與上傳；順便跟圖片說「你好，請變成 WebP」。
  4. 傍晚：SQLite 測一輪，MySQL 再測一輪；發現 JSON_EXTRACT 寫太開心的地方，默默重構。
  5. 晚上：寫 CHANGED / README——因為未來的你比 Cursor 更健忘。

7. 常見踩坑（建議直接寫進 Cursor Rules）

  1. 前台為了炫技上 React
    結果 SEO、首屏、維護成本一起爆炸。炫技請去後台炫。

  2. 後台為了「統一技術」硬用 Blade 堆 SPA
    最後 jQuery 與 data-* 會組成復仇者聯盟。

  3. API 沒契約，前端各自解讀
    同一欄位三種命名：postTitle、title、name。這不是多元，這是刑求。

  4. 只在 MySQL 開發，CI 用 SQLite 才爆
    等於把地雷埋給未來的 CI 綠燈幻想。

  5. 讓 AI 自由發揮資料庫 schema
    沒有 soft delete、沒有 index、時間戳時區混亂——上線後再補，會補出哲學問題。

什麼時候這套棧特別香

  • 內容型網站、品牌官網、活動落地頁 + 需要正經後台
  • 前台要快、要 SEO、要好改文案
  • 後台操作密度高，值得 React
  • 團隊希望本機簡單（SQLite），上線穩（MySQL）
  • 你已經在用 Cursor，想要「提示詞一丟就對得上架構」

什麼時候要再考慮別的：

  • 前台本身就是超大型互動產品（那可能前後都 React / 其他 SPA）
  • 完全靜態、幾乎無後台（也許 SSG 就夠）
  • 組織已有強制技術標準（那就別在會議上朗讀這篇文章）

結語：專業一點說，好笑一點活

好的架構不是「用最多框架」，而是讓每個框架只做它擅長的事：

  • Laravel 13 API 管真相與規則
  • Blade 管讀者看得到的第一印象
  • React /backend 管營運效率與複雜互動
  • Tailwind + jQuery 管前台美觀與小動作
  • SQLite → MySQL 管開發速度與上線現實

Cursor 則是那個「打字極快、偶爾過度自信」的 intern——你給規範，它給產量；你給 review，它給下一次更好的補全。

所以別問「AI 會不會取代工程師」。
先問：「你有沒有把 Laravel、Blade、React 的分工寫清楚到連 AI 都不敢亂寫？」

若有，恭喜——你已經比一半的 side project 更接近可維護的產品了。
若還沒，把這篇存起來，下次開專案時連同圖片一起貼進 brief。Cursor 會感謝你；你的未來自己會請你喝珍奶。

快速檢查清單

  • API 路由、驗證、Resource 形狀已定
  • 前台頁面以 Blade + Tailwind 為主
  • 前台小互動用 jQuery／輕量 JS，不為小功能上 SPA
  • 後台固定在 /backend，React 只打 API
  • migration／查詢對 SQLite 與 MySQL 都友善
  • 圖片上傳策略（UUID 檔名、WebP）寫進約定
  • Cursor Rules／README 寫明上述邊界

寫完這份清單，就可以開工了——記得先開 Cursor，再開咖啡，順序很重要。

← 返回技術文章