如何才能有效地使用Claude程式碼？

Claude Code 的 vibe 編碼技術現在非常火爆。

好訊息是，它的確物有所值。 Claude Code 可以處理一些出乎意料的複雜編碼任務。

壞訊息是，它被過度炒作了，聲稱只需幾個小時就能用 vibe 編碼出驚人的應用程式，或者使用 10 個並行子代理循環執行的複雜工作流程來取代 5 名軟體工程師的工作。

如果你還不是 Claude Code 的高級用戶，這些宣傳可能會讓你懷疑如何有效地使用它。如果我不採用這種全新的工作流程，是否會錯失提昇效率的機會？我的使用場景應該使用子代理、命令、技能還是 MCP 伺服器？如果是，又該如何操作？

我一直在問自己這些問題，所以我花了幾個星期的時間進行研究和測試，最終得出以下結論：

只需幾個精心挑選的工具，再加上 Claude Code 的基本功能，你就有足夠的「靈感」來編寫出色的全端應用程式。

你不需要它的所有功能

看到這麼多複雜的LLM工作流程和工具，感覺有點奇怪。而我每個專案只執行一個持續的Claude對話…我從來沒用過子代理，也沒用過MCP…

而且我取得了非常好的效果¯_(ツ)_/¯*

——克里斯·麥考德，Phoenix框架的建立者

儘管 Claude Code 的功能令人印象深刻，但你很快就會發現，很多功能存在重疊，而且如果你一開始就掌握了一些關鍵要素，很多其他功能你其實都不需要經常用到。本文將解釋這些關鍵要素是什麼，並逐一深入探討每個主題。

1. 提供全端除錯可見性

• 這樣一來，Claude 就能真正看到並回應它正在編寫的程式碼，而我們不必複製貼上錯誤或描述問題。

2. 讓 Claude Code 能夠存取最新的、適合LLMs學習的文件。

• 對於可能擁有過時知識、憑空想像解決方案或被未針對 LLM 優化的「嘈雜」文件搞糊塗的 LLM 來說，這一點至關重要。

3. 使用合適的技術堆疊或框架

• 這或許是這三種方法中最容易被忽略的一種。透過選擇合適的框架，你可以為人工智慧提供清晰的模式，並從一開始就消除許多複雜性。

有了這個基礎，您就可以主要使用 Claude Code 的預設工作流程，以及一些自訂命令/技能，輕鬆建立和部署全端應用程式（我還將這些想法打包成一個簡單的 Claude Code 插件，您可以安裝和使用，但我稍後會詳細介紹）。

這種方法之所以有效，是因為它為代理商提供了護欄和正確的模式，這樣你就可以花更多的時間在業務邏輯實現上，而減少花在製定規範和技術細節上的時間。

從本質上講，你可以與代理一起實現你想要的功能，而無需解釋你想要什麼，從而將人工智慧輔助編碼的神奇感覺帶到複雜的全端應用程式中。

讓我們深入探討一下。

賦予克勞德程式碼全端願景

建立緊密的回饋迴路

我們典型的AI輔助編碼工作流程大致如下：我們提出提示，然後等待，然後查看產生的程式碼（可能），最後在瀏覽器中檢查效果。如果發生錯誤或前端設計不佳的情況，我們會複製貼上程式碼，並嘗試（更好地）解釋我們的需求。

{% embed https://youtu.be/gOMOpURvoRY %}

更糟的是，我們可能需要反覆操作幾次才能滿意，或讓一切恢復正常。

我們總是忙於監控進度，反而大大拖慢了速度。有時候，我們應該放手讓程式自行改進，直到每次迭代都完成，然後再檢查結果。

但要做到這一點，我們需要為 Claude Code 配備一雙「眼睛」。幸運的是，透過合適的功能和工具，我們可以做到這一點，讓它能夠看到自己編寫的程式碼的執行結果，並在堆疊中的任何位置遇到錯誤時快速自主地進行修改。

讓我們來看看具體方法。

將開發伺服器作為後台任務執行

Claude Code 引入了後台任務功能，允許它在背景執行長時間執行的任務，例如應用開發伺服器（例如npm run dev ），而不會阻塞 Claude 執行其他工作。更棒的是，Claude 可以在你工作的同時繼續讀取和回應這些任務的輸出。

{% embed https://youtu.be/ixT5Etvs9O0 %}

若要在背景執行命令，您可以：

• 提示 Claude Code 在背景執行命令，例如"run my app's dev server in the background"

• 按 Ctrl+B 可將常規 Bash 工具呼叫移至背景執行，例如"run the dev server" + Ctrl+b即可在啟動時執行。

即使 Claude 可以讀取後台任務的輸出，但有時您可能還是需要自行查看，這也可以做到。只需使用向下箭頭選取後台任務訊息，然後按回車鍵即可。

這很棒，因為現在 Claude 可以對建置和執行程式碼過程中出現的問題做出反應。遺憾的是，它仍然無法對應用程式在瀏覽器中執行時發生的錯誤做出反應。

但有一個很棒的解決方法。

瀏覽器自動化工具

目前還缺少的一點是讓 Claude 能夠真正看到他寫的程式碼的結果，最典型的就是使用者介面的外觀。

有些問題只有在應用程式在瀏覽器中執行時才會出現，例如設計問題和執行時錯誤，代理程式還無法看到這些問題。因此，通常需要人工介入並回饋： “按鈕錯位了” 、 “嘗試登入時出現 404 錯誤” 、 “控制台顯示undefined資訊” 。

但幸運的是，我們可以為 Claude Code 配備瀏覽器自動化工具來解決這個問題。這些工具允許以程式方式控制瀏覽器，例如載入頁面、點擊按鈕、檢查元素、讀取控制台日誌，甚至截圖。

{% embed https://youtu.be/oyYwfbuNrtc %}

這樣就完成了整個堆疊的閉環，並賦予 Claude 完全自主地完成更大功能任務的能力。

Chrome DevTools MCP 伺服器是目前最好的選擇之一，當然還有許多其他替代方案。它易於安裝，並且專門用於瀏覽器除錯和性能分析。

要安裝它，請在終端機中執行以下命令，將其新增至目前專案：

claude mcp add chrome-devtools --scope project npx chrome-devtools-mcp@latest

然後開始一個新的 Claude 會話，並給它一個類似這樣的提示：

Verify in the browser that your change works as expected.

你應該會看到一個由 Claude 控制的獨立 Chrome 實例開啟。現在，你可以給它分配更多任務，例如：

• 驗證測試用戶

• 檢查網站的 Lighthouse 效能評分（例如載入速度）

• 為您提供有關如何改進應用程式設計的回饋

將所有要素連結起來

{% embed https://youtu.be/eS1Uio\_rrP8 %}

現在，當您在應用程式中實現全端功能時，請讓 Claude 透過檢查開發伺服器中的日誌以及使用 Chrome DevTools MCP 在瀏覽器中檢查日誌來驗證該功能是否正常運作。

或者，如果您希望 Claude始終自動使用 DevTools MCP 驗證瀏覽器中的更改，而無需明確要求它這樣做，則可以在CLAUDE.md檔案中新增一條規則到 Claude 的記憶體中。

賦予代理人存取正確文件的權限

版本控制問題

你可能遇到過這種情況：你正在使用某個函式庫的 API 進行程式碼編寫，而 AI 卻自信地寫出一段在兩個版本前完全可以正常運作的程式碼。或者，它會針對一個已知問題（而這個問題在文件中明明有簡單的解決方案）建立一些複雜且過度設計的變通方案。

這是因為模型的訓練資料有截止日期。除非您授予其存取最新文件的權限，否則LLM和像Claude這樣的工具無法獲知更新後的程式碼模式。

但正如安德烈·卡帕西所觀察到的，大多數文件包含的內容與LLMs課程無關：

99% 的圖書館文件仍然只是簡單地渲染成漂亮的靜態 .html 頁面，假設讀者會點擊瀏覽。到了 2025 年，文件應該是一個 your_project.md 文字文件，可以直接在 LLM 的上下文視窗中開啟。

有研究支持他的說法，研究表明，當無關內容（如 HTML 語法或冗長的人類指令）加入到上下文中時，LLM 的性能會下降，因為它會分散注意力，降低準確性。

換句話說，上下文視窗中每一個不必要的標記都會使 AI 的工作效率略微下降。

所以我們需要給克勞德·科德合適的文件。

解決方案：精選文件存取權限

解決方法很簡單：讓代理程式能夠取得並讀取您正在使用的工具的相關、針對 LLM 最佳化的文件。

以下是開發者實現這一目標的兩種主要方式：

• MCP 伺服器－一種用於向 AI 代理提供資料的外部系統標準。諸如Vercel之類的常用開發工具，透過文件搜尋工具提供這些伺服器。

• llms.txt 與文件對應— 一種在知名 URL（例如https://wasp.sh/llms.txt ）上發佈 LLM 友善文件的標準。代理程式會取得針對 LLM 上下文視窗最佳化的結構化文件。

用於文件獲取的 MCP 伺服器

模型上下文協定 (MCP)是一種開放標準，用於將人工智慧應用（例如智慧體、邏輯邏輯模型）連接到外部系統。 Claude Code 可以與 MCP 伺服器通信，以存取專用工具和資訊。

目前已經有許多適用於熱門工具的 MCP 伺服器，例如 Supabase、Jira、Canva、Notion 和 Vercel。 Claude Code 的文件部分列出了這些以及更多其他工具，並提供了安裝說明（如果您有興趣的話）。

像Supabase和Vercel這樣的開發者工具 MCP 伺服器都提供了一些工具，可以根據查詢取得代理的文件。不過，這種方法也有一些優缺點。

優點

• 可以在將文件發送回去之前對其進行一些預處理。

• 可以跨多個文件/指南進行版本檢查、篩選和取得相關程式碼片段

• 返回結構化輸出而非原始文本

缺點

• MCP 伺服器決定哪些資訊是相關的，而忽略一些可能有用的訊息。

• 它的所有工具（不僅僅是文件獲取工具）都會加載到LLM的上下文視窗中，並迅速將其填滿，從而降低代理的效能。

• 代理程式需要更多開銷：評估提示 → 找到適當的 MCP 工具 → 呼叫該工具 → 等待 MCP 伺服器的回應 → 評估回應 → 執行操作

由於 LLM 沒有真正的內存，因此每次啟動新會話時，它們都必須將資訊載入到上下文中，例如可以使用的工具。單一 MCP 伺服器可以在上下文中新增約 15-30 個工具，而使用多個伺服器時，在開始工作之前，LLM 的上下文視窗很容易就會佔用 10-20% 甚至更多的空間。

如果你想查看上下文視窗已使用了多少空間，可以在活動的 Claude Code 會話中執行/context斜線命令。

上面的範例表明，僅一個 MCP 伺服器就佔用了 2.5% 的上下文視窗。

隨著 LLM 的上下文視窗逐漸填滿，其效能會下降。有些開發者甚至建議，當上下文視窗達到 75% 時就啟動一個新會話來避免這種情況，這可以透過 Claude Code 中的/clear命令來實現。您也可以執行/compact命令，該命令會產生當前會話上下文的摘要並將其傳遞給下一個會話。

幸運的是，如果您使用 MCP 伺服器的主要原因只是為了搜尋文件，那麼還有一個更合適的替代開放標準。

LLM 友善文件 URL — LLMs.txt

LLMs.txt已迅速成為向 LLM 提供網站上下文友善版本的標準，路徑為/llms.txt 。

不妨在您常用的開發者工具網址上試試，例如：

• stripe.com/llms.txt

• supabase.com/llms.txt

• wasp.sh/llms.txt

{% embed https://youtu.be/zBsc8nIiXGk %}

儘管 llms.txt 文件的內容可能千差萬別，但它們始終遵循相同的格式：一個簡單的 Markdown 文件，包含網站標題和一些連結。僅此而已！這使得 LLM 能夠獲取精準訊息，而無需處理任何無關內容。

以下是使用 llms.txt 取得文件的一些優點和缺點：

優點

• 為LLMs和代理人精心整理的最相關資訊列表

• 極為簡單；適用於任何可以取得 URL 的代理程式。

• 代理商決定追蹤哪些連結，並可以查看完整的源程式碼。

• 非常有效率的上下文視窗

缺點

• 原始文件/Markdown文件可能包含超出所需的資訊。

• 代理可能會獲取不相容的連結/文件

• 代理人可能需要更多關於如何正確與文件互動的指導/規則。

我認為，透過llms.txt URL 取得文件是更好的方法，因為它更節省上下文資訊。例如，典型的文件檔案大約需要 100 個 token，而僅僅一個 MCP 伺服器就需要 5,000 到 10,000 個 token。

這意味著上下文使用量減少了 10 倍。

Claude Code 在瀏覽文件結構圖方面也表現出色，能夠精準地提取最相關的資訊。此外， llms.txt檔案也更便於人查閱，這無疑是一大優點。

這也是 Claude Code內部取得文件時所使用的方法。因此，當你向它詢問有關其自身功能的問題時，它會首先獲取其文件映射 Markdown 文件的 URL ，以找到正確的指南。

既然您已經知道如何讓 Claude Code 存取最新的文件，那麼接下來要回答的問題是，您可能需要為哪些工具提供文件？

最顯而易見的答案就是你用來建立全端應用程式的技術堆疊或框架。

選擇合適的技術棧/框架

熱門選擇

這可能是三大支柱中最容易被忽略的一點。

選擇一個人工智慧可以輕鬆理解的技術堆疊，將大大簡化建立所需應用程式的工作。市面上有許多選擇，但幸運的是，其中不乏可靠的選擇，例如：

• Wasp （React、NodeJS、Prisma）

• NextJS （React，NodeJS）

• Laravel （PHP）

• Ruby on Rails （Rails）

到 2026 年，使用 Claude Code 和上面列出的任何框架，你都能取得很大的進展。但是，儘管這些框架都提供了良好的約定，並負責將技術堆疊中最關鍵的部分連接起來，但它們中的大多數仍然需要某種形式的額外整合。

你該選擇哪一個？

對於更專注於客戶端的 NextJS，你需要選擇並連接自己的資料庫層。而對於將後端和資料庫合而為一的 Laravel 和 Rails，你需要決定使用哪個客戶端以及它如何與後端通訊。

這就是為什麼很多開發者會選擇包含這些框架的流行技術堆疊/組合，例如：

• NextJS + tRPC + Prisma + NextAuth（又稱T3 技術堆疊）

• Laravel + Inertia.js + React

• Rails + Hotwire

您可能也注意到了，T3 Stack 是唯一包含身分驗證庫 NextAuth 的框架。這是因為後端框架 Laravel 和 Rails 已經提供了一套固定的身份驗證方式，而 NextJS 則沒有。

另一方面，Wasp 是這批產品中唯一一個將堆疊的所有部分（客戶端↔後端↔資料庫）統一起來的，同時對功能也有自己的看法。

這一切都很棒，但你最終應該選擇哪一個呢？

越有主見越好

框架越固執己見，就越能與人工智慧產生共鳴。

如果一個框架有明確的規範，通常意味著程式碼的放置位置只有一個，並且遵循的模式也只有一個。人工智慧無需猜測。它們已經預先做出了決策，因此你（以及你的代理）不必為此費心。它們將架構智慧編碼成約定，選擇了要使用的庫，確定了身份驗證的實作方式，以及應用程式的結構。

因此，當需要做的決定減少、需要編寫的樣板程式碼減少、需要整合的工具減少時，開發過程就會變得更加可靠。

隨著應用變得越來越複雜，人工智慧也不會失去焦點，因為框架會處理許多底層複雜性。你也可以更輕鬆地理解和檢查生成的內容，避免陷入混亂的境地。

想想看，有規範的框架可以減少 60-80% 的樣板程式碼。例如，Wasp 的身份驗證聲明可以用 10 到 15 行的配置取代 500 多行典型的身份驗證程式碼。這意味著需要產生和審核的程式碼減少了 97%！

在這些框架中，Wasp 無疑是最有個性的，但它也是最新的。其次，Laravel 和 Rails 緊隨其後，但它們分別基於 PHP 和 Rails 建置，並擁有各自獨立的生態系統，因此你很可能還需要搭配 React 等前端 JavaScript 框架。 NextJS 是其中最受歡迎但個性最弱的，這意味著你和你的 AI 需要處理更多複雜性和前期選擇，但從長遠來看，這提供了更大的靈活性。

所以最終，你的選擇很大程度上取決於你想達到什麼目標、你覺得舒服的方式以及你需要多大的靈活性。

請記住，框架提供的結構和預設值越多，AI 就越容易產生合適的程式碼——你花在修復令人困惑或不一致的輸出上的時間就越少。

這對克勞德·科德意味著什麼

好的。所以我們已經確定，使用預設框架意味著它可以幫助你處理很多複雜性。

但當與 Claude Code 一起使用時，這實際上意味著什麼？

• 架構規劃的子代理程式？框架已經決定了架構。

• 程式碼應該存放在哪裡？有詳細的計劃嗎？規範會告訴你答案。

• 來回討論以達成一致意見？模式早就定好了。

• 將應用程式的各個部分黏合在一起？框架負責管理這些程式碼。

• 用於解釋您的應用程式結構的上下文資訊？它已嵌入到框架中。

從某種意義上說，該框架就像你和克勞德都已經理解並同意的大型規範。

與其進行多輪對話來弄清楚如何建造東西，不如直接說出你想建造什麼。

所以，當你告訴克勞德「新增評論新模型」或「新增使用者帳戶設定功能」時，克勞德會完全明白這意味著什麼以及所有功能應該放在哪裡。此外，你還能獲得額外的好處：這些實現遵循最佳實踐，並由框架背後經驗豐富的專業人士做出決策，而不是某些LLM（LLMs）基於錯誤假設倉促地實現某個功能。

這並不是說你不再需要做好規劃、建立完善的規格或產品需求文件供代理商遵循。在進行概念編碼（或實踐「規範驅動開發」）時，這仍然是非常重要的一步。

但這確實意味著，有了具有明確方向的全端框架，您在規劃階段就不需要花太多時間來討論架構和技術實作細節了。

這種方法，在一個插件中

如果你想將我上面討論的理論方法進行實踐檢驗，那麼我建議你試試我們為 Claude Code 建立的 Wasp 插件。

我們，Wasp框架的建立者，負責維護這個插件，所以我們已經用Wasp框架對它進行了實戰測試。此外，我們是一個非常積極回應的社區，我們會認真聽取回饋並不斷改進它。

以下是入門步驟：

1. 安裝 Wasp

npm i -g @wasp.sh/wasp-cli

2. 安裝 Claude Code 插件

# add the Wasp marketplace to Claude
claude plugin marketplace add wasp-lang/claude-plugins

# install the plugin from the marketplace
claude plugin install wasp@wasp-plugins --scope project

3. 啟動一個新的黃蜂專案

# create a new project
wasp new

# change into the project root directory
cd <your-wasp-project>

4. 在你的 Wasp 專案目錄中啟動 Claude Code 會話

claude

5. 執行初始化命令來設定插件

/init-wasp-plugin

接下來，你可以讓 Claude “啟動開發伺服器”，它會引導你按照上述步驟建立完整的堆疊可見性。或者，你也可以讓它實作 Wasp 的某個功能，然後看著它為你取得版本相符的文件指南！

更重要的是，Wasp 框架比其他框架更接近人工智慧原生領域，因為它有定義應用程式的中央設定檔。

這個主設定檔就像你應用程式的藍圖。 Wasp 會讀取這些聲明，並為你管理這些功能的程式碼。

請參考以下範例設定檔身份驗證程式碼片段：

app TaskManager {
  wasp: { version: "^0.21.0" },
  title: "Task Manager",
  auth: {
    userEntity: User,
    methods: {
      email: {},
      google: {}
    },
    onAuthFailedRedirectTo: "/login"
  }
}

這就是 Wasp 中身份驗證實現的樣子。就是這樣。

這段只需 8 行的設定就能產生通常需要 500-800 行程式碼才能實現的功能：元件、會話處理、密碼雜湊、OAuth 流程和資料庫架構。 Claude 只需要知道你想要使用哪些身份驗證方法。

Claude無需擔心選擇使用哪種身份驗證實作方式，也無需產生任何黏合程式碼。它可以直接著手建立功能。

當你確實需要那些高級貨的時候

我在這篇文章中一直在論證，對於全端應用程式開發來說，你可以忽略 Claude Code 的許多功能。但我不想讓你覺得這些功能毫無用處。

當您使用一致的標準重複執行相同的任務時，自訂子代理程式、命令和技能就能發揮作用，例如：

• 測試— 一個專門的測試執行子代理，它了解您的測試模式，執行測試套件，分析故障，並提出修復建議。

• 程式碼審查— 程式碼審查指令或子代理，可在每次開發後執行測試、修復錯誤並審查程式碼。

• 執行腳本—如果您經常執行一些確定性任務，例如部署腳本或使用命令列工具將部落格圖片轉換為 webp 格式，那麼技能功能會非常有用。在技能中定義這些任務並將腳本連結到該技能，Claude Code 會在認為適合當前任務時執行這些腳本。

對於這類任務，您希望每次都遵循相同的流程，因此配置完善、具有特定規則的子代理程式就顯得有意義。

大多數情況下，只有當簡單的方法不再奏效時，才應該採用複雜的方法。

現在開始建造！

我認為，有了這三樣東西，大多數全端應用程式開發者就能完成絕大部分工作，無需再加入其他東西：

1. 一個有預設框架，可以處理架構/樣板程式碼，這樣 Claude 就不必再為此費心了。

2. 版本相符的文件，以便 Claude 能夠取得最新的實作細節。

3. 實現全端可見性，這樣 Claude 就能看到發生了什麼並自行修復。

有了這些，Claude Code 的基本工具集——探索、規劃、讀取、編寫和執行命令——就足以建立真正複雜的全端應用程式。子代理、鉤子、插件和複雜的配置也一應俱全，以備不時之需，但說實話，大多數情況下你都用不上它們。

原文出處：https://dev.to/wasp/claude-code-for-fullstack-development-the-3-things-you-actually-need-1p6p