1. 手忙腳亂的“裸用”階段我從哪一步開始覺得不對勁先說一個我自己的真實場景。幾個月前我把 Claude Code 裝好第一次在終端里敲下claude的時候確實有一種“這才是 AI 編程該有的樣子”的錯覺它能直接讀項目文件、能改代碼、能跑命令不需要我在瀏覽器里復(fù)制粘貼大段代碼。頭兩周我?guī)缀醢阉心苡盟傻幕疃紒G給了它改樣式、寫單測、補注釋、修 lint 報錯效率確實比純手寫高了一大截。但這種“裸用”的爽感沒有維持太久。大概第三周我在做一個遺留前端項目業(yè)務(wù)邏輯很繞同一個需求連續(xù)讓 Claude Code 改了三輪。我發(fā)現(xiàn)我每天都在重復(fù)同一件事把項目背景、技術(shù)棧、目錄結(jié)構(gòu)、相關(guān)文件路徑一遍又一遍地復(fù)制進對話里。它確實記住了這次對話里的內(nèi)容可下次開新會話所有上下文清零我又得從頭喂一遍。真正讓我下決心改造的是某次對線上問題的排查。那段代碼涉及一個支付狀態(tài)的機內(nèi)流轉(zhuǎn)我讓 Claude Code 幫我查問題它分析得很像回事卻始終沒有主動去讀那幾個關(guān)鍵的狀態(tài)機文件——因為我不知道該讓它讀哪個文件它也不知道項目中哪些文件真正相關(guān)。最后是我自己打開編輯器翻了大半個小時再把關(guān)鍵代碼段粘給它。整個過程中我感受到一種荒誕我明明有一個能在本地終端里工作的 AI卻還是在像用網(wǎng)頁版一樣靠手動喂上下文。那之后我認真盤點了一下“裸用”階段的問題大致有三類上下文管理靠人肉。對話一開能記住的上下文有限項目越大越容易“前后矛盾”臨時續(xù)接新會話等于失憶。外部工具和數(shù)據(jù)源是斷的。Claude Code 能讀文件夾里的代碼但拿不到 Git 倉庫的狀態(tài)、拿不到需求文檔、拿不到線上接口的實時返回。它更像一個聰明的“代碼抄寫員”而不是真正接入開發(fā)鏈路的助手。經(jīng)驗不可沉淀。我花了十幾分鐘調(diào)教出來的“該怎么審查這段代碼”的套路關(guān)掉終端之后就消失了下次還要重新說一遍。后來我做的事情其實可以用一句話概括給 Claude Code 裝上“固定的作業(yè)流程”和“可調(diào)用的外部工具”。前者是Skills后者是MCP。這張對比表基本就說明了我整個改造前后的差別維度裸用狀態(tài)工程化之后上下文靠對話內(nèi)臨時提供關(guān)閉即失憶通過 Skill 文件自動加載背景與規(guī)則外部數(shù)據(jù)讀不到 Git、數(shù)據(jù)庫、接口狀態(tài)MCP Server 按需提供實時數(shù)據(jù)任務(wù)流程每次口頭重新交代固定流程由 Skill 驅(qū)動穩(wěn)定可復(fù)用人工介入頻繁補上下文、指文件只做最終審核和關(guān)鍵決策經(jīng)驗沉淀存在腦子里換臺機器就沒了沉淀為 Skill 文件跟項目走如果你也正處于“用著 Claude Code 但總覺得差點意思”的階段這篇文章就是我在完成這次改造之后的完整復(fù)盤為什么接 MCP、怎么設(shè)計 Skills、兩者怎么配合以及我踩過的坑和現(xiàn)在還留著的人工環(huán)節(jié)。2. MCP為什么值得接它不是“插件”是給模型補上手腳的協(xié)議層MCP 的全稱是 Model Context Protocol一個模型上下文協(xié)議。很多人第一次聽到這個名字會覺得很高深其實它的作用用一個比喻就能說清楚如果大模型是一個大腦MCP 就是給這個大腦接上眼睛、耳朵和手的 USB-C 接口。在接入 MCP 之前Claude Code 的能力邊界非常清晰它能看到你項目里的代碼文件能執(zhí)行終端命令除此之外的外部世界對它來說都是盲區(qū)。GitHub 上有沒有新的 issue線上接口返回的 JSON 長什么樣數(shù)據(jù)庫里某個訂單的狀態(tài)是什么這些它一概不知道。你只能在對話里把結(jié)果復(fù)制給它它才能基于這份“二手信息”做分析。MCP 改變了這件事。它定義了一套標準化的通信方式MCP Server 負責(zé)暴露能力——可以是讀取工具、數(shù)據(jù)源、也可以是某個具體操作Claude Code 作為 MCP Client在需要的時候主動去調(diào)用這些工具。關(guān)鍵在于調(diào)用是由模型自己決定要調(diào)哪些、按什么順序調(diào)不再需要你手動把數(shù)據(jù)搬進對話框。拿我最常用的配置舉例。我在 Claude Code 里接了一個 GitHub 相關(guān)的 MCP Server配置完成后我可以直接這樣對 Cloude Code 說“看一下這個倉庫最近的 PR有沒有測試覆蓋率下降的列出來。”它會自己去調(diào) GitHub API拉取 PR 列表和檢查狀態(tài)然后給我一份匯總。整個過程我不需要復(fù)制任何鏈接、不需要口頭描述 PR 內(nèi)容它自己就把信息拿回來了。除了 GitHub我實際接入過的 MCP Server 有這幾類你可以做個參考MCP Server 類型典型用途我實際用來做什么文件系統(tǒng)類按路徑讀寫文件、搜索目錄跨目錄整理代碼片段、批量改名Git/GitHub 類拉取倉庫狀態(tài)、issue、PR、commit自動整理 changelog、審查 PR數(shù)據(jù)庫類直連數(shù)據(jù)庫執(zhí)行查詢排查線上數(shù)據(jù)不一致問題瀏覽器類控制瀏覽器訪問頁面、取 DOM驗證前端頁面狀態(tài)、抓取接口返回調(diào)試器類對接調(diào)試工具讀取運行時上下文配合本地調(diào)試定位崩潰棧在開發(fā)調(diào)試場景里MCP 的價值還會被進一步放大。比如調(diào)試類工具可以通過 MCP 和 Claude Code 對接讓 AI 直接讀取調(diào)試器的當(dāng)前棧、寄存器、反匯編結(jié)果而不是靠你手動把崩潰信息復(fù)制進去。這種“工具直連”帶來的效率提升比單純把對話模型做得再聰明都明顯。當(dāng)然接哪些 MCP Server 完全取決于你的場景我自己的原則是只在真正需要的時候把外部數(shù)據(jù)源接進來而不是為了“顯得專業(yè)”把所有 Server 都裝上。配置 MCP 的方式也很直接Claude Code 支持通過命令把 Server 注冊進去。我一般會在項目根目錄下執(zhí)行類似這樣的命令注冊一個本地 Serverclaude mcp add 我的數(shù)據(jù)源 --env API_KEYxxx -- npx 某個-server包注冊完之后項目啟動時 Claude Code 會自動加載這個 MCP Server并把它提供的工具列進可調(diào)用清單里。這里有一個容易被忽略的重點MCP Server 本質(zhì)上是本地運行的一個進程你給它配了哪些密鑰、它就能訪問哪些資源權(quán)限邊界完全由你控制。你不給它配數(shù)據(jù)庫的寫權(quán)限它就不會有寫庫的能力。所以不要擔(dān)心接了 MCP 就等于把整個項目裸奔給了 AI真正的風(fēng)險控制點還是在你的配置上。關(guān)于權(quán)限我有一條自己的判斷標準只開放“讀取和分析”類能力默認不開放“寫入和改動”類能力。比如數(shù)據(jù)庫類的 MCP Server我只會用只讀賬號去連GitHub 類的 Server我會限制成讀取 PR、commit 的狀態(tài)不在對話里直接讓它做 force push 這種事。這一條原則幫我避開過好幾次潛在的災(zāi)難后面講踩坑的時候會再展開。3. Skills的正確打開方式別把它當(dāng)成會說話的提示詞文件夾搞定了 MCP 之后我一度以為工作流已經(jīng)很理想了但很快發(fā)現(xiàn)了新的問題Claude Code 確實能調(diào)用工具了可它不知道“什么時候該用”“按照什么流程來做”。比如我讓它處理一個需求它一會兒先問我業(yè)務(wù)邏輯一會兒自己埋頭就改一會兒又想起來問我要不要跑測試。每次都像在跟一個實習(xí)生磨合你得在旁邊不停引導(dǎo)。直到我認真去理解 Claude 官方提出的 Agent Skills 機制這個問題才算解掉。Skills 是一種結(jié)構(gòu)化的“技能包”它不再是一段直白的提示詞而是一個包含說明文件、示例、腳本、資源文件的文件夾。Claude Code 會掃描這些文件夾根據(jù)技能描述自動判斷“當(dāng)前任務(wù)是否匹配某個技能”然后按技能文件里定義的流程去執(zhí)行。打個比方MCP 給了 AI 手腳Skills 給的是崗位說明書和作業(yè)指導(dǎo)書。你給 AI 一個“前端代碼審查員”的 skill它就會按照你在 skill 里定義的檢查清單去逐項核對代碼先看 props 命名和類型再查狀態(tài)管理是否合理然后檢查有沒有多余的重復(fù)渲染。這套流程是固定的、可復(fù)現(xiàn)的不會因為這次對話心情好就多查兩項、下次忘了就少查兩項。要理解 Skills 的設(shè)計邏輯最好的方式就是看它的目錄結(jié)構(gòu)。以我常用的項目為例我會在項目下建一個.claude/skills/目錄里面每個子目錄就是一個獨立的技能.claude/skills/ ├── code-review/ # 代碼審查技能 │ ├── SKILL.md # 核心說明文件 │ └── examples/ │ ├── review-sample-1.md │ └── review-sample-2.md ├── git-commit/ # 提交信息規(guī)范技能 │ └── SKILL.md └── frontend-refactor/ # 前端重構(gòu)技能 ├── SKILL.md └── scripts/ └── check-imports.sh其中SKILL.md是整個技能的入口格式上最前面有一段 YAML 風(fēng)格的元信息里面最關(guān)鍵的是name和description。description尤其重要——Claude Code 就是靠讀這句描述來判斷“當(dāng)前這個任務(wù)值不值得加載這個技能”。我把一個審查技能的描述字段設(shè)計成下面這個樣子--- name: code-review description: 用于對前端 TypeScript 代碼進行系統(tǒng)性審查重點檢查類型定義、組件邊界和狀態(tài)管理當(dāng)用戶要求審查或 review 代碼時使用。 ---注意這里有個細節(jié)描述里寫的是“當(dāng)用戶要求審查或 review 代碼時使用”而不是籠統(tǒng)的“用于改善代碼質(zhì)量”。原因后面我會重點講——技能的觸發(fā)邏輯好不好九成取決于描述字段寫得多具體。如果你寫得太寬泛Claude Code 幾乎會在每個任務(wù)里都嘗試加載這個技能結(jié)果就是上下文被無關(guān)內(nèi)容占滿響應(yīng)質(zhì)量反而下降。我把這個現(xiàn)象叫作“技能誤觸發(fā)”。和普通提示詞模板相比Skills 的核心優(yōu)勢我認為有三點這也是我在實際使用中最明顯的體感差異自動發(fā)現(xiàn)而非手動粘貼。普通提示詞需要你復(fù)制粘貼給模型Skills 是模型根據(jù)任務(wù)描述自己決定加載哪個。這省掉的不只是操作時間還避免了“忘了給提示詞”導(dǎo)致步驟缺失。結(jié)構(gòu)化支持掛載更多資源。一個 skill 目錄里可以放示例文件、參考文檔、檢查清單、執(zhí)行腳本它的信息量遠超一段文字提示詞模型在執(zhí)行時可以把這些內(nèi)容當(dāng)作執(zhí)行依據(jù)。版本可管理經(jīng)驗可遷移。技能包就是一個文件夾可以放進 Git 倉庫里管理。我換了新電腦git clone下來就能恢復(fù)整套工作習(xí)慣不需要重新調(diào)教。很多人在社區(qū)里分享的 Skills比如搜索熱詞里反復(fù)出現(xiàn)的 Superpowers Skills、Codex 的 Skills 集合本質(zhì)上都是這個思路的產(chǎn)物。Claude 官方也專門寫過一篇文章叫《Claude Agent Skills: A First Principles Deep Dive》從第一性原理的角度講技能系統(tǒng)的設(shè)計邏輯我建議大家有空去讀讀。不過要先說明別人的技能包可以參考但別指望直接拿來用就很貼合。因為技能的核心是“執(zhí)行你期望的流程”而你期望的流程往往和分享者不完全一樣。我現(xiàn)在的工作習(xí)慣是參考別人的思路然后自己捏一個定制版。4. 組合落地的完整路徑以“前端需求拆解自測審查”為例理論部分講得差不多了下面直接給你看我最近跑得最順的一條工作流拿 Claude Code 處理一個前端需求從拆解、實現(xiàn)到自測和審查全鏈路由 Skills MCP 驅(qū)動。這個例子比較有代表性因為前端開發(fā)幾乎是目前社區(qū)里 Skills 討論度最高的場景熱搜詞里“前端開發(fā) skills”“superpower skills”常年排在前列不是沒有原因的——前端項目文件多、依賴重、改造成本高AI 如果沒一套固定流程很容易改一處壞一片。4.1 環(huán)境準備先把地基打牢我后面給的方案依賴以下環(huán)境你如果從零開始先把這三步走完安裝 Claude Code。全局安裝命令一般是npm install -g anthropic-ai/claude-code裝完在項目目錄下執(zhí)行claude就能進入交互式終端。Windows、macOS、Linux 都有對應(yīng)安裝方式Ubuntu 這類 Linux 系統(tǒng)上注意先確認 Node.js 版本不要太舊否則會拿到安裝報錯。在項目下建.claude/skills/目錄規(guī)劃好技能清單。我的習(xí)慣是給每個技能一個獨立子目錄名字用-連接的小寫字母。按需注冊 MCP Server。前端場景我最常接的是文件系統(tǒng)和瀏覽器調(diào)試兩類前者讓 AI 能跨目錄讀文件后者讓它能打開本地頁面驗證效果。這些準備工作做完之后我會在claude啟動時先做一次“項目預(yù)檢”讓 Claude Code 讀一遍package.json和目錄結(jié)構(gòu)確認它清楚當(dāng)前項目的技術(shù)棧和腳本命令。這一步很關(guān)鍵因為后面所有流程都建立在“AI 知道自己是在哪個項目里干活”這個前提下。4.2 第一步需求拆解的 Skill 配置我沒有直接讓 AI 上來就寫代碼而是先設(shè)計了一個“需求拆解”技能。這個技能的作用是當(dāng)我把一段原始需求丟給它時它不會立刻動手而是先按固定結(jié)構(gòu)輸出拆解結(jié)果。--- name: requirement-breakdown description: 將模糊的業(yè)務(wù)需求拆解為可執(zhí)行的前端任務(wù)清單包含改動文件、狀態(tài)管理影響、測試計劃和風(fēng)險點當(dāng)用戶提供需求描述并期望開始開發(fā)時使用。 ---光有描述還不夠SKILL.md的正文部分我寫了五段固定結(jié)構(gòu)需求理解一致性確認、影響面分析、拆解任務(wù)列表、執(zhí)行順序建議、需要用戶確認的前置問題。這樣做的好處非常明顯決策過程被前置了。在真正改代碼之前AI 已經(jīng)和我對齊了“要做什么”“先做什么”“哪里可能有坑”而不是悶頭寫完再返工。4.3 第二步用 MCP 把“自測”環(huán)節(jié)閉環(huán)掉需求拆解確認完之后進入開發(fā)和自測階段。這里就是 MCP 發(fā)揮主力的地方了。我注冊了一個瀏覽器調(diào)試類的 MCP Server配置好本地預(yù)覽地址后Claude Code 可以直接在瀏覽器里打開我的開發(fā)環(huán)境頁面讀取頁面上的渲染結(jié)果和 console 輸出。于是“改完代碼-刷新頁面-看報錯-繼續(xù)改”這個循環(huán)就從“我把報錯復(fù)制給它”變成了“它自己打開頁面、自己觀察渲染結(jié)果、自己修”。我只需要在關(guān)鍵節(jié)點上確認一下方向?qū)Σ粚?。這個體驗和我最初“裸用”時的差異你自己對比一下就知道了。配合上面說的測試代碼生成技能Claude Code 還會在改完成之后自動補一輪關(guān)鍵路徑的單元測試。這一整套做下來一個普通中等復(fù)雜度的前端需求從接收描述到自測通過我實際盯人的時間大概只有以前的三分之一。4.4 第三步代碼審查 Skill 的檢查清單設(shè)計開發(fā)完成之后我最后一個固定動作是跑一遍“前端代碼審查”技能。這個技能的執(zhí)行重點在類型安全、組件邊界、狀態(tài)管理等幾個維度。這里也順便回答一個很多剛接觸 Skills 的人都會問的問題為什么不讓 Claude Code 直接用“審查一下代碼”這種模糊指令非要單獨建一個技能文件夾因為模糊指令沒有穩(wěn)定標準。昨天它審查時按 A 標準查今天可能按 B 標準查你要每一項都重新描述一遍很麻煩。而技能把標準固化了——我把自己多年積累的前端經(jīng)驗濃縮成了一份檢查清單放進 SKILL.md 里的“強制檢查項”區(qū)塊。以后每次審查都會按同一份清單走。說實話光是這點就值回改造的功夫了。4.5 組合起來的流程長什么樣把 MCP 和 Skills 配合起來整個工作流就成了一個可復(fù)制的流水線我丟需求給 Claude Code它調(diào)用“需求拆解”技能產(chǎn)出任務(wù)清單我確認后它開始實現(xiàn)并用 MCP 連到瀏覽器/文件系統(tǒng)完成自測最后調(diào)用“代碼審查”技能做一輪自查發(fā)現(xiàn)問題再回到實現(xiàn)步驟。這個流程本身也是可以沉淀為另一個更高層的 skill 的我管它叫“前端需求全流程處理”不過本質(zhì)上只是把上面幾個技能串聯(lián)起來。我觀察過幾周的實測數(shù)據(jù)在不考慮極端復(fù)雜邏輯的情況下一個典型的中型頁面需求從拿到需求到產(chǎn)出可提交代碼我的累計人工介入時間從平均 45 分鐘降到大約 15 分鐘。代碼審查環(huán)節(jié)發(fā)現(xiàn)的問題類型也發(fā)生了變化低級代碼規(guī)范問題明顯變少剩下的是業(yè)務(wù)邏輯和交互設(shè)計層面的問題這些本來也更需要人來判斷。5. 真金白銀踩過的坑以及我現(xiàn)在還保留的“人肉”環(huán)節(jié)任何工具用到深處都會踩坑Skills MCP 的組合也一樣。我把這段時間高頻踩過的坑整理出來按“問題-原因-對策”列了個表每條都是從實際項目里淌出來的教訓(xùn)?？蝇F(xiàn)象原因我的對策技能誤觸發(fā)無關(guān)任務(wù)也加載 skill上下文被占滿description 寫得太寬泛比如“提升代碼質(zhì)量”描述里寫清精確的觸發(fā)場景MCP Server 沒啟動工具調(diào)用靜默失敗AI 假裝執(zhí)行過依賴的本地服務(wù)端口沒起來啟動前先主動驗證 server 狀態(tài)多個工具名稱沖突AI 調(diào)用了錯誤的工具返回奇怪結(jié)果不同 MCP Server 暴露了相同命令用前綴命名區(qū)分避免裸工具名權(quán)限放太開AI 意外改動不該動的文件MCP Server 配置了寫權(quán)限只讀賬號/只讀配置優(yōu)先新版本配置失效升級 Claude Code 后 MCP 注冊丟失配置文件格式或路徑變化升級后固定檢查claude mcp list關(guān)于技能誤觸發(fā)我再展開說具體一點。我最早設(shè)計過一個“數(shù)據(jù)庫查詢”的 Skilldescription 字段我偷懶寫了“用于查詢數(shù)據(jù)庫信息”。結(jié)果它幾乎在每個任務(wù)里都被加載導(dǎo)致 Claude Code 在處理前端樣式調(diào)整時腦子里還掛著一堆數(shù)據(jù)庫操作上下文。后來我把描述改成了“當(dāng)用戶明確要求查詢數(shù)據(jù)庫、需要查表結(jié)構(gòu)或分析 SQL 執(zhí)行計劃時使用”誤觸發(fā)率立刻降下來了。這個坑太典型社區(qū)里大量“Skills 沒用”的抱怨相當(dāng)一部分根源就出在這里。除了這些工具層面的坑更要命的是 Agent 能力邊界的問題。我現(xiàn)在有明確的三類任務(wù)不會交給 Claude Code 自己做主第一類是涉及刪除/覆蓋不可恢復(fù)內(nèi)容的操作。比如批量刪除文件、批量重命名重要目錄哪怕它有 MCP 的文件系統(tǒng)權(quán)限我也堅持自己執(zhí)行或者事先 review 完整的文件清單。不是不信任它而是這類操作的“失敗成本”太高一次誤操作可能毀掉不可逆的工作成果。第二類是跨系統(tǒng)協(xié)調(diào)的最終決策。比如要發(fā)布上線、要合并到主干分支、要修改他人正在維護的模塊。AI 可以幫忙做分析、出建議、列 checklist但最后的“拍板”動作我會人工完成。這既是為了安全也是為了讓 AI 不越過團隊協(xié)作的邊界。第三類是涉及產(chǎn)品方向和業(yè)務(wù)取舍的判斷。AI 能判斷“這個函數(shù)能不能拆”但它判斷不了“這個功能該不該砍”。這類問題我連讓 AI 下結(jié)論的 prompt 都不會寫最多讓它列出利弊選項。在工具配置層面我現(xiàn)在的習(xí)慣是MCP 只接必要的那幾個 server不追求種類多Skills 的描述字段保持精確每個技能的檢查清單定期更新每完成一個項目我會順手把其中可復(fù)用的流程沉淀成一個新的 Skill 或改進舊的 Skill。這套體系現(xiàn)在已經(jīng)變成了我日常開發(fā)的一部分新電腦上只要把配置目錄同步過來整套工作習(xí)慣就跟著過來了。最后再分享一個小技巧你在設(shè)計 Skill 時不要一開始就想著把流程寫得很完美先寫一個 70 分版本實際跑幾次把跑偏的地方補進SKILL.md的“常見問題”區(qū)塊里。我那幾個最常用的技能都是這樣從粗糙版本迭代出來的。這種“先用起來再逐步固化”的思路比一開始就設(shè)計一個龐大完美的技能系統(tǒng)要實際得多——畢竟工具的最終目的不是讓流程看起來很復(fù)雜而是讓你在復(fù)雜里省下真正的時間。