🦞 什麼是「龍蝦」？前端／全端工程師把 Agent 接進開發流程的實戰用法

最近我在開發 Next.js 專案時，常用一類工具來做「專案檢查、修補缺失、對齊前後端規格」的工作。 它不是某個特定品牌，而是一類 Agent/CLI Bot/Automation 工具——我習慣叫它 「龍蝦」。

這篇文章我想用工程師視角，講清楚三件事：

1. 龍蝦是什麼（它在工具鏈裡的位置）
2. 怎麼引入龍蝦（你要餵什麼上下文，它才不會亂跑）
3. 怎麼用在前端／後端／全端（具體到日常 workflow）

我不會把它神化，也不會寫成行銷文。你可以把這篇當成「Agent 入門＋上手指南」。

1) 什麼是「龍蝦」

先講最工程師的定義： 龍蝦 = 一類能讀取專案上下文，協助分析/產出/檢查的 Agent 工具。

它通常以 CLI 或互動介面存在，可以看檔案結構、讀設定、比對規格，甚至幫你生成程式碼或修補缺失。

如果你用過 LLM 直接問問題，你大概知道它的限制：

• 沒有專案上下文
• 容易憑空猜測
• 給的建議不一定能落地

龍蝦的價值通常在於它能取得（或你能提供）更完整的 context，例如：

• 專案的 package.json（技術選型、版本）
• 路由結構（Next.js App Router / Pages Router）
• content schema（Contentlayer / MDX / CMS）
• 某個頁面或 API 的實際實作

有了 context，它就能做更像「資深 reviewer」的事：指出缺失、提出修補方式、甚至幫你產出最小可行修改。

但前提是：你要把它當工具，而不是把它當決策者。

2) 為什麼前端／全端工程師會需要龍蝦

我用龍蝦，通常不是拿來「幫我寫 UI」，而是拿來補以下幾種人類很常漏掉的事情。

✅ (A) 前端專案越來越像「系統」

以 Next.js 為例：routing、metadata、SEO、RSC/CSR 邊界、cache、build-time… 你不是在做幾個頁面，而是在做一個可維護的系統。

人腦很容易在趕功能時漏掉：

• generateMetadata 沒做，分享出去全站同一個 title
• 沒 sitemap / robots，Google 索引慢到你懷疑人生
• 日期格式造成 hydration mismatch（尤其跨時區）

龍蝦很適合當**「上線前 checklist 的自動 reviewer」**。

✅ (B) 全端最痛的是「對齊」

做全端的人一定懂： 前端 UI 寫完才發現後端 payload 欄位叫法不同、狀態 enum 不一致、權限邊界沒想清楚。

龍蝦可以做：

• 對齊 API contract（前端需要什麼、後端回什麼）
• 掃描缺失的欄位/路由/回傳格式
• 把規格整理成可執行的修改清單

✅ (C) 它幫你「省掉反覆確認的腦力」

很多事情不是難，是煩：

• 文章頁要不要 canonical？
• feed.xml 怎麼做最乾淨？
• metadataBase 要放哪？

龍蝦可以快速把 best practice 拉到你面前，你只要負責判斷要不要採用。

3) 如何引入龍蝦到專案（最重要：先鎖 scope）

我看過最多的翻車方式就是：

「幫我優化整個專案」

然後它開始亂改、亂升級、亂重構。 我後來把使用方式固定成一個流程——你也可以直接抄。

Step 1：先讓它看「專案輪廓」

最有用的三個檔案通常是：

1. package.json
2. 專案路由樹（src/app 或 pages）
3. content schema / config（例如 contentlayer.config.ts）

你不需要一開始就把整個 repo 丟給它。 給「骨架」就夠了。

Step 2：明確說「不要做什麼」

我的固定防呆條款通常是：

• 不要執行指令
• 不要修改檔案
• 不要升級/降級依賴
• 不要重構目錄結構

只要你沒講，它就會很自然地「順便幫你改」。

Step 3：用分級來控制改動範圍

我會把任務拆成三層（很像 code review 的嚴重程度）：

• Level 1：只補缺失（上線阻擋項）
• Level 1.5：一行等級補強（不改架構、低風險）
• Level 2：結構性調整（刻意才做）

只要你用這種方式下指令，龍蝦的輸出品質會穩定很多。

4) 龍蝦在前端、後端、全端的實戰用法

這裡我用「我真的會怎麼用」的角度來寫。

🖥 前端（Next.js / React）

用法 1：上線前 SEO/內容站 checklist

內容型網站（blog、docs、landing）最常缺：

• 動態 metadata（文章頁 title/description/og:image）
• sitemap / robots
• RSS feed
• canonical
• metadataBase

這些其實不難，但很容易忘。 龍蝦非常適合做「補洞」：

1. 先掃 repo，列出缺失
2. Level 1：補 sitemap/robots/metadata/feed
3. Level 1.5：加 canonical、metadataBase、RSS autodiscovery

用法 2：抓 hydration mismatch 的風險點

例如你在 server component 裡做：

• new Date().toLocaleString()
• Math.random()
• Intl format + timezone

龍蝦可以快速指出「哪裡可能 SSR/CSR 不一致」。

用法 3：路由與資料來源是否一致

Next.js 尤其容易發生：

• slug 路由存在，但 contentlayer 沒產生對應內容
• tags page 存在，但 tags 計算邏輯漏掉某些文章

它可以當「routing consistency checker」。

🔧 後端（API / Schema / Auth）

我做後端時，龍蝦主要用在**「規格對齊」與「權限邊界檢查」**。

用法 1：API payload 對齊前端需求

你可以把前端使用點（例如某頁需要哪些欄位）丟給它，請它檢查：

• 後端 response 有沒有缺欄位
• naming 是否一致（snake/camel）
• enum/status 是否對齊

它做的事情很像你請一個人幫你做「規格比對」。

用法 2：Auth / RBAC 邊界檢查（全端最常翻）

它很適合找：

• user-scoped endpoint 是否可能 IDOR
• 角色權限是否只在前端擋（後端沒擋）
• 是否有「靠 token parse 的 ad-hoc 寫法」需要統一

這種工作很瑣碎，但出錯就很大條。

🔁 全端整合（我最常用的場景）

全端整合其實是「很多小地方都要一致」。

用法 1：把「前後端對齊」拆成可執行清單

我會請龍蝦輸出：

1. 需要調整的 API 清單（path、method、fields）
2. 前端要改的型別/mapper
3. 可能需要 migration 的地方

然後我自己決定順序，逐項完成。

用法 2：讓它當 PR reviewer，而不是 coder

這個差別很重要：

• coder 模式：它會改很多你不一定要改的東西
• reviewer 模式：它會指出風險與缺失，你可以控節奏

我的經驗是： 長期維護的專案，reviewer 模式更省時間。

5) 常見誤用：龍蝦什麼時候會害你

❌ 誤用 1：一句「幫我最佳化」

這是最可怕的咒語。 它會開始幫你做所有它覺得「更好」的事——但那不一定是你當下需要的。 ✅ 解法：用 Level 1/1.5 限定範圍。

❌ 誤用 2：沒給 context 就要它結論

你只給它一句「看一下專案」，它就只能猜。 猜對算你運氣好，猜錯就是你浪費時間。 ✅ 解法：先給「骨架檔」：package.json + routing tree + config。

❌ 誤用 3：把它當決策者

工具很強，但它不知道你的產品節奏、使用者、deadline、維護策略。 ✅ 解法：你決定方向，它只當輔助。

6) 小結：我把龍蝦放在哪個位置

我現在把龍蝦定位成：

高級 Reviewer + Checklist Bot + 對齊助手

而不是「代替我寫完整系統的人」。

它最強的地方，是幫你把「容易漏的小洞」補起來， 或把「全端對齊的雜事」整理成可執行清單。

而你真正要守住的是：

1. scope（今天要做什麼）
2. 禁止項（不要做什麼）
3. 停損點（什麼時候該停）

如果你把這三件事控制好，龍蝦就會是一個很爽的工具。