你知道 Claude Code 的創造者說最重要的是什麼嗎？
不是如何寫提示詞，也不是選擇哪個模型。
「給 Claude 驗證自己輸出的方法。」
這才是唯一的重點。他明確表示，這是使用 Claude Code 最重要的技巧。
這篇文章是對這個討論的延伸。我們理解這個原則，但具體來說，要如何提供那些方法？答案就是 MCP 伺服器。
老實說，知不知道這件事，真的會改變使用 Claude Code 的體驗。花在貼文件、複製問題、手動開啟畫面檢查的時間——全部都會變得不再需要。
你也正在經歷這些嗎？
- 生成的程式碼用了舊語法，你每次都自己修正。
- 你最後還是得自己開瀏覽器，確認做出來的畫面是不是真的能動。
- 你複製 issue 內容，貼給 Claude，讓它實作，然後再回去寫進度。
- 每次生產環境出錯，你就從 Sentry 複製堆疊追蹤。
- 你知道 MCP 這個詞，但因為不知道該加什麼，所以什麼都沒設定。
對，我以前也都在做這些事。
我先說清楚：就算不會寫程式的人也能讀這篇文章。我會在遇到技術名詞時逐一解釋。事實上，MCP 對非工程師來說，效益可能更大。
等你讀完，你很可能會想在工作流程中找到一個「每次都要複製貼上」的環節。
請把這篇存起來。
「Boris」到底是誰？
Boris Cherny。他就是創造 Claude Code 的人。
他明確表示「我創造了 Claude Code」，所以這點毫無疑問。他是最深入理解 Claude Code 設計哲學的人。
他的使用方式非常驚人。
首先，他已經很久沒有手寫程式碼了。相反地，他同時在終端機執行大約五個 Claude 工作階段，在網頁上再執行五到十個，並將分頁編號，透過通知來管理哪個 Claude 正在等待人工輸入。
（想像一下，你有 15 個下屬，各自處理不同的任務，只有卡住的人才會來找你。）
此外，他的 CLAUDE.md——也就是專案規則書——只有大約 100 行。他不是那種會寫大量規則的人。
他最有名的一句話是：
「不要寫提示詞。要寫迴圈。」
與其尋找更好的提問方式，不如創造一個環境，讓 Claude 能夠自行循環處理任務。這才是他哲學的核心。
Boris 反覆強調的 3 個原則
仔細看他的文章，他總是在說同樣的幾件事。
原則一：給 Claude 驗證自己輸出的方法。
他稱之為「最重要的技巧」。他的解釋非常簡單明瞭：
如果你叫一個人建立網站，但禁止他使用瀏覽器，會發生什麼事？什麼像樣的東西都做不出來。
但如果你給他瀏覽器，他就會建立、查看、修正、再看、重複，直到滿意為止。
Claude 也一樣。如果你給它驗證的方法，它就會自己反覆迭代，直到滿意為止。
原則二：把每天做超過一次的事，變成系統。
每次都在聊天中解釋同樣的流程，純粹是浪費時間，所以把它變成一個 Skill 或一個指令。因為準備好等呼叫的成本幾乎是零，所以建立它也沒有壞處。
原則三：把外部工具帶進 Claude Code 的工作區。
Slack、issue 追蹤器、資料庫、內部 API。讓這些工具能直接從 Claude Code 存取，工具之間的切換就會消失。
這就是 MCP 登場的地方。
最後
每次談到 MCP，總會遇到這個瓶頸。
一旦連上 MCP，Claude Code 的手就伸進了生產環境。部署、DNS、付款、客戶資料。讀取還好，但如果突然允許寫入或刪除，就會出意外。
那麼，哪些地方要委託，哪些地方要由人來驗證？
我免費提供一份界線圖表。我希望你在安裝 MCP 之前先看過一次。
👇
一句話總結 MCP
我們先把這件事說清楚。
MCP 是「連接 AI 工具與外部服務的通用介面」。把它想像成 USB 標準。
在沒有這個標準的世界裡，你得為 Claude、ChatGPT 和其他 AI 分別建立不同的整合。有了 MCP 標準，服務提供者只要建立一次，就能讓所有相容的 AI 工具使用。
而且，MCP 不只是為 Claude Code 增加功能。
它把工作目標本身帶進了 Claude Code 裡面。
Figma 設計稿、Sentry 錯誤、Linear 票單、Cloudflare 生產日誌——Claude 可以直接看到它們，直接操作它們。這就是為什麼複製貼上會消失。
而現在，這個標準已經有了重大改變。
MCP 前提條件的轉變
這點在繁體中文圈還沒有整理得很好，所以請特別注意。
在最新的規格更新中，MCP 經歷了發布以來最大規模的改版。以下是四個主要變更：
無狀態化。 以前的遠端 MCP 設計成伺服器要維持連線狀態。現在沒有了；它變成類似標準 HTTP 的請求-回應類型。好處是它可以直接在 serverless 或 edge 環境上執行。MCP 現在可以建成一個隨著存取量擴展的系統，而不是單一常駐伺服器。
支援長時間執行的工作。 原本假設工具會立即回傳結果，現在這個限制已經移除。它可以先回傳一個追蹤編號，之後再進行進度檢查、更新和取消。大型程式碼遷移、影片生成、長時間資料分析、完整環境部署——這些「需要數小時的任務」現在正式透過 MCP 支援。
能夠在對話中回傳 UI。 以前 MCP 以文字和 JSON 為主，現在伺服器可以回傳操作畫面。部署目標選擇畫面、圖表、核准/拒絕按鈕、表單。簡而言之，MCP 正在從 AI 在背景呼叫 API 的系統，轉變為在 AI 上執行的小型應用程式標準。
組織層級認證。 與企業身分提供者整合，管理員核准後，員工在首次登入時就會自動連線。個人取得 API 金鑰的操作就此消失。
請注意，Anthropic 端正在逐步推出這些功能。規格定案，不代表你本機的 Claude Code 就能立刻使用所有功能。
（我偶爾會看到誇大這點的文章，但官方說法是「逐步推出」。）
Claude 的連接器清單中列出了超過 950 個 MCP 伺服器。數量很驚人，但實際上你真正需要安裝的並沒有那麼多。
8 個改變 Claude Code 的官方 MCP 伺服器
這就是重點部分。
挑選標準有三個：必須是提供者管理的官方伺服器、初學者容易感受到效果、且直接落實 Boris 的三個原則之一。
- Context7 MCP：消除程式碼過時的根源
當 Claude Code 輸出錯誤的程式碼時，原因通常不是模型不夠聰明。
只是它參考的資訊太舊了。
使用已棄用的 API、輸出舊的 Next.js 語法、混用不同版本的設定、產生不存在的選項、靠猜測補上文件中沒有的實作。都是這些問題。
Context7 是一個 MCP，它為 Claude Code 提供依版本區分的函式庫和框架最新文件。不是靠記憶回答，而是創造一個先查詢特定版本資料再實作的狀態。
實用提示詞：
使用 Context7，檢查這個專案中使用的 Next.js 目前版本的官方文件。
檢查完成後，在開始實作之前先整理以下內容：
- 目前版本的建議實作方式
- 已棄用的實作方式
- 與目前專案程式碼的差異
- 需要修改的檔案
不要基於猜測來實作，只使用文件中描述的方法。
注意：不要在一個查詢中混入多個概念。同時問「驗證、路由和快取」，會得到廣泛但淺層的結果。分開查詢概念，準確度會更高。
官方倉庫：https://github.com/upstash/context7
- Playwright MCP：讓 Claude 親自操作瀏覽器
這直接落實了 Boris 的原則一。
Claude Code 可以寫程式碼，但它不知道它寫出來的畫面是否真的能動。連接 Playwright MCP 之後，Claude 可以開啟真實的瀏覽器、點擊按鈕、填寫表單、追蹤頁面轉換、捕捉錯誤、修正錯誤、再檢查一次。
這個系統有趣的地方在於，它不只是把螢幕截圖當成圖片來看。它會讀取 Accessibility Tree——也就是畫面的結構化資訊。它知道什麼是按鈕、什麼是輸入欄位、什麼是標題。因為它讀取的是意義，所以比較不容易混淆視覺上相似的元素。
實用提示詞：
實作完成後，用 Playwright MCP 開啟本機環境。
實際操作並驗證以下項目：
- 新註冊
- 登入
- 輸入錯誤時的顯示
- 手機寬度下的版面破版
- 登出
如果失敗，不要只靠閱讀程式碼來猜測原因，先在瀏覽器中重現問題再修正。
修正後，重新執行相同操作，確認成功後才回報完成。
我必須老實說。
Boris 自己說他做網頁工作時每次都用的，其實是 Claude Code 瀏覽器擴充功能，而不是 Playwright MCP。他說因為可以共用登入狀態，所以比類似的 MCP 更穩定。
所以使用情境是：如果你要使用已登入的瀏覽器來檢查實際畫面，就用擴充功能。如果你要把它自動化當作測試，反覆執行相同流程，就用 Playwright MCP。
兩者共享同樣的哲學：「給 Claude 一個瀏覽器。」
官方倉庫：https://github.com/microsoft/playwright-mcp
- Figma MCP：讀取設計資料，而不只是圖片
只要你是把設計稿當作截圖傳給 Claude，Claude 就永遠在猜測。
邊距是多少像素？字體大小是多少？這個顏色是品牌色還是臨時色？這個部分是 reusable 元件嗎？全部都是從圖片中靠眼睛猜測。
連接 Figma 開發者 MCP，可以直接存取結構化的設計資訊。數值、顏色、元件結構、設計 token。猜測從此消失。
實用提示詞：
從 Figma MCP 中取得目前選取的畫框。
首先，只提取以下內容，不要開始實作：
- 頁面結構
- 需要重複使用的元件
- 顏色與字體定義
- 邊距規則
- 響應式縮放時預計的變化
確認提取的內容後，優先使用現有專案元件進行實作。
如果需要建立新元件，先說明為什麼現有元件不足。
而這裡才是真正的重點。
從 Figma 拉設計、在 Claude Code 中實作、用 Playwright 檢查、壞了就修。把這三個連接起來，就能讓設計到驗證變成一條線。
MCP 的價值，在這種連接中比孤立使用更容易理解。
官方文件：https://developers.figma.com/docs/figma-mcp-server/
- Linear MCP：讀取票單並寫入進度
Boris 會在 PR 中用 @claude 提及他的同事，並讓它把學習到的內容加入規則書。簡而言之，他不會把問題管理空間與 AI 工作區分開。
連接官方 Linear MCP，可以在 Claude Code 中搜尋、建立、更新和評論 issue。由於這是 Linear 託管的遠端連線並附帶認證，你不需要在本機上一直跑著伺服器。
這讓以下流程變得順暢：
讀取 Issue → 調查相關程式碼 → 建立實作計畫 → 實作 → 測試 → 在 Issue 上評論進度 → 更新狀態
實用提示詞：
檢查 Linear 中指派給我、且狀態為進行中的 issue。
整理優先順序和相依性後，對最高優先順序的 issue 執行以下步驟：
- 找出需求中缺少的資訊
- 調查相關程式碼
- 建立實作計畫，實作前先提出
- 核准後進行實作與測試
- 在 Issue 上評論已採取的行動
在變更狀態之前，請先等待我的確認。
一定要加上最後那句。如果你讓它自動變更狀態，從其他團隊成員的角度來看，就會出現「未完成的工作被標記為已完成」。
官方文件：https://linear.app/docs/mcp
- Sentry MCP：不用貼錯誤就能追蹤原因
生產環境發生錯誤時，你會怎麼做？
打開 Sentry，複製堆疊追蹤，貼給 Claude，找到你懷疑的檔案，再貼一次。這些都不需要了。
Sentry MCP 的價值不只是顯示錯誤列表。它把錯誤內容、堆疊追蹤、發生頻率、受影響用戶、來自哪個版本、相關程式碼，以及過去類似的失敗，全部放進一個調查迴圈中。
實用提示詞：
從 Sentry 中取出過去 24 小時內受影響用戶最多的未解決錯誤。
依下列順序調查：
- 分析發生條件
- 找出相關程式碼
- 建立重現測試
- 如果可以重現，實作最小修正
- 執行所有測試
- 總結根因與修正方式
如果無法重現，不要基於猜測進行修正。列出縮小原因範圍所需的額外資訊，然後停下來。
「如果無法重現，不要基於猜測進行修正」這句話很有效。沒有它的話，可能會套用一個看似合理的修正，但根因還在，它還會回報「已修正」。
官方文件：https://docs.sentry.io/product/sentry-mcp/
- Cloudflare MCP：顯示部署目標的狀態
到目前為止我們談的都是開發，但這個是關於營運的。
Cloudflare 發布了多個官方 MCP 伺服器來操作其服務。檢查設定、管理 Workers、日誌分析、DNS 設定、安全設定、效能檢查。它的設計不只是讀取，還能提出建議並實際進行變更。
這代表 Claude Code 可以在看到程式碼在部署目標的實際行為後，再進行改善。
實用提示詞：
使用 Cloudflare MCP 檢查目前生產環境的狀態。
調查：
- 過去 24 小時內的錯誤
- 回應時間
- 快取命中率
- 安全事件
- Workers 中發生的例外狀況
然後，將問題分類為以下兩類：
A. 需要程式碼變更
B. 可以透過 Cloudflare 設定改善
兩種情況，在執行變更前都必須先提出計畫。在我核准之前，不要變更設定。
由於這會接觸到基礎設施，建議在初期導入時只設為唯讀。不需要一開始就允許變更設定。
官方文件：https://developers.cloudflare.com/agents/model-context-protocol/cloudflare/servers-for-cloudflare/
- Stripe MCP：讓付款程式碼與 Stripe 設定同步
付款實作之所以困難，是因為只看程式碼無法知道正確答案。你必須同時檢查 Stripe 端註冊了哪些商品和價格，以及 webhook 如何在另一個分頁設定，同時撰寫程式碼。
官方 Stripe MCP 除了 Stripe API 操作外，還包含搜尋官方文件和支援資訊。實作、設定驗證、文件參考，都在同一個地方完成。
此外，Stripe 除了 MCP 之外，還為 Agent 提供了 Skills。用 MCP 操作，用 Skills 強制執行最佳實踐。這個組合非常強大。
實用提示詞：
使用 Stripe MCP 和官方 Stripe 文件，為每月訂閱功能建立實作計畫。
確保檢查以下項目：
- Product 和 Price 的設定
- 如何建立 Checkout Session
- 需要透過 Webhook 接收的事件
- 取消流程
- 付款失敗時的行為
- 防止重複註冊的方法
- 測試方法
工作期間只使用 Stripe 測試模式。不要對生產資料做任何變更。
絕對不要刪掉最後兩行。這不是一個可以在閘門打開的狀態下執行的 MCP。
官方文件：https://docs.stripe.com/mcp
- GitHub MCP：關閉審查回應的迴圈
最後是這個。
但請不要誤會；GitHub MCP 的價值不在於「能夠執行 git 指令」。Claude Code 本來就可以操作本機 git 和 GitHub CLI。
它的價值在於遍歷只有遠端才有的資訊：issue 細節、PR 審查評論、CI 結果、其他儲存庫的狀態、內部程式碼搜尋，以及過去的討論。
實用提示詞：
使用 GitHub MCP 檢查目前分支對應的 PR。
找出所有未解決的審查評論，並分類為以下三種：
- 必須修正的項目
- 需要設計決策、由我來決定的項目
- 判斷為不需要修正的項目（附上理由）
只實作「必須修正的項目」，並通過測試。
不要碰觸需要設計決策的項目；而是整理爭論點和選項後提出。
讀取審查評論、修正、測試、回報——全部在 Claude Code 內完成。
官方倉庫：https://github.com/github/github-mcp-server
建立「堆疊」，而不是單一工具
MCP 一個一個加，效果有限。要根據工作流程排列起來，才能產生轉變。
網頁開發堆疊：
從 Figma 拉設計 → 用 Context7 檢查目前正確語法 → 在 Claude Code 中實作 → 用 Playwright 進行瀏覽器驗證 → 在 GitHub 上處理 PR 和審查回應 → 在 Cloudflare 上部署和檢查日誌
SaaS 開發堆疊：
從 Linear 拉需求 → 用 Context7 檢查技術規格 → 在 Claude Code 中實作 → 用 Stripe 設定和驗證付款 → 用 Playwright 測試使用者操作 → 用 Sentry 監控生產錯誤
發生了什麼事？
在兩個堆疊中，流程都是一樣的。
取得資訊、規劃、建立、自己驗證、對外反映、看到結果。
這個迴圈不需要離開 Claude Code 就能完成。
Boris 的「給它驗證的方法」，不只是指一個瀏覽器。而是指給它確認流程中每個步驟正確性的方法。
初學者只需要這三個
我不是說要全部安裝八個。那樣做會讓你掉進下一章的陷阱。
第一階段：Context7
目標是減少錯誤的程式碼。
由於是以讀取為主，風險很低。從這裡開始最安全，也最快能感受到效果。
第二階段：Playwright 或瀏覽器擴充功能
目標是讓 Claude 自己驗證產出物。
如果你在做網頁工作，這個會帶來很大的改變。建立、開啟、找到破版、修正、再開啟。人類不再需要在中間介入。
第三階段：Linear 或 GitHub
目標是連接工作的輸入和輸出。
從票單到實作、PR、進度更新。到了這個階段，Claude Code 會從「等待指令的程式設計師」轉變為「自己推動工作進度的成員」。
這三個就夠了。真的。
你必須讀的陷阱
陷阱一：MCP 越多不代表越聰明
這是最常見的誤解。
如果你連接大量 MCP，Claude 可以選擇的工具候選數量就會增加。然後會發生什麼事？
它會搞混該用哪一個。它會消耗上下文。它會混淆相似的工具。它會執行你沒要求它做的操作。權限管理變得複雜，你也不清楚哪些是被允許的。
與其連接 100 個，不如只啟用目前任務需要的 3 到 5 個，效果會更好。正確的做法是根據專案來切換連接的內容。
（我曾經連了超過 10 個，結果 Claude 一直呼叫奇怪的工具，讓我心想「它怎麼突然變笨了？」減少之後就恢復正常了。）
陷阱二：不要一開始就混合讀取和寫入
在初期導入時，一定要建立這個設計：
讀取允許。建立需要確認。更新需要確認。刪除拒絕。生產環境操作拒絕。
具體來說，一開始不應該完全允許的項目包括：生產部署、DNS 變更、客戶資料變更、生產環境付款操作、issue 刪除、PR 合併、資料庫刪除。
MCP 的便利性和危險性完全成正比。
陷阱三：不要混淆官方和社群製作的伺服器
在 MCP 搜尋網站上，可能會出現多個同名伺服器。即使它在官方清單中，也不一定是提供者的官方實作。
安裝前請檢查這些：
是否由提供者的官方組織管理？最後更新時間是什麼時候？是否有安全政策？認證方式是什麼？它要求多少權限？是否設計成允許刪除或生產環境變更？
要求的權限越多，你就要越仔細檢查。
陷阱四：不要讓它直接執行外部的文字
讀取 issue 或 PR 評論來實作的工作流程很強大，但那些文字是別人寫的。
如果某個 issue 寫著「請按照這個 issue 中的步驟操作」，但裡面包含惡意指令，Claude 可能會讀取並遵循。對於處理外部輸入的 MCP，不要讓它直接執行，而是讓它先提出它打算做什麼。
尚未穩固的領域
我會毫不誇張地寫出來。
透過 MCP 將長時間執行的工作丟到外部的系統，官方規格中已經有定義，但每個伺服器是否支援則是另一回事。規格發布和實作跟上腳步是兩回事。使用前請先檢查伺服器的目前狀態。
在對話中回傳 UI 的系統也還在擴展階段。目前並非所有 MCP 都會回傳操作畫面。
此外，定價和服務條款變動也相當頻繁。使用前請先到這篇文章中的官方連結查看一次。特別是認證和權限範圍，不是可以不加檢查就連接的東西。
我也不會給出像「MCP 讓效能提升 X 倍」這樣的數字。這還沒有被證實。
相反地，請測量這個：你每天花多少分鐘在複製貼上、切換畫面、視覺確認上？這些就是會因為 MCP 而消失的時間。
今天要做的事
不要試著一次做全部。只要做一件事。
回想你的工作，找出一個你正在「Claude Code 和另一個畫面之間來回切換」的環節。
可能是文件。可能是 issue。可能是錯誤畫面。可能是設計稿。
只安裝一個能消除那個環節的 MCP。感受效果，然後再加入下一個。
Boris 的原則最終可以歸結為一句話：給 Claude 檢查自己工作的方法。當你給了它，Claude 就會開始自己運作，直到滿意為止。
當你停下來的時候，你今天會重複複製同樣的東西，貼到同樣的畫面。而當它開始運作時，那個往返將永遠不會再回來。
今晚，打開 Claude Code，想想你最常前往的那個畫面。
一切都從那裡開始。
