最近有一份33頁的文檔在AI圈傳得挺火Anthropic內(nèi)部關(guān)于Claude使用方式的技能手冊。我認(rèn)真讀了兩遍相關(guān)的公開討論又照著里面的方法論實(shí)際試了一周最大的感受是——這份手冊最核心的一句話恰恰是很多人最意外的一句別讓它動(dòng)手。不是讓Claude多干活而是別讓它直接動(dòng)手。這兩個(gè)方向的差別解釋了為什么同樣是使用Claude與Skills有人又快又穩(wěn)有人卻總在收拾爛攤子。如果你正在用Claude或Claude Code做開發(fā)、寫內(nèi)容、搭自動(dòng)化流程或者只是好奇AI編程工具到底該怎么用這份手冊背后的邏輯都值得花幾分鐘琢磨。它不是在教你放棄自動(dòng)化而是在教你劃清楚自動(dòng)化的邊界。1. 手冊里的核心反直覺Claude 被定位成參謀而非執(zhí)行人1.1 別讓它動(dòng)手反對(duì)的到底是什么很多人一看到別讓它動(dòng)手就想那要Claude干什么其實(shí)這里說的動(dòng)手指的是讓AI直接執(zhí)行那些有后果、有累積錯(cuò)誤、難以撤回的操作。比如直接在工作目錄里批量改文件、直接跑部署命令、直接提交發(fā)布、直接修改全局配置。這些操作的問題在于它們本質(zhì)上是不可逆動(dòng)作疊加多步?jīng)Q策。對(duì)語言模型來說單次生成一個(gè)代碼片段是它的強(qiáng)項(xiàng)但讓它從頭到尾自主決定改哪些文件、怎么改、改完怎么驗(yàn)證每一步都有出錯(cuò)概率多步累積下來成功率會(huì)指數(shù)級(jí)下跌。我自己就栽過跟頭。有一次讓AI幫忙做代碼重構(gòu)指令是把項(xiàng)目里的回調(diào)改成async/await聽起來目標(biāo)很明確對(duì)吧結(jié)果它一口氣改了三十多個(gè)文件其中兩個(gè)地方依賴被改掉的函數(shù)簽名整個(gè)測試直接崩了。關(guān)鍵不是它改得不對(duì)而是當(dāng)AI一口氣改很多的時(shí)候錯(cuò)誤被放大了而且你很難追蹤錯(cuò)誤到底從哪一步開始。手冊里的別讓它動(dòng)手本質(zhì)上是在說把Claude當(dāng)作戰(zhàn)術(shù)參謀它可以出方案、給代碼、標(biāo)影響范圍但扣扳機(jī)的必須是你。1.2 為什么這個(gè)觀念和主流 AI Agent 宣傳正好相反市面上好多AI工具都在宣傳全自動(dòng)、讓你徹底解放雙手Anthropic內(nèi)部手冊里反而強(qiáng)調(diào)保守這其實(shí)反映了他們對(duì)可靠性邊界的清醒認(rèn)知。我經(jīng)常用一個(gè)比喻來理解這件事Claude像一個(gè)天賦極高但入職第一天的實(shí)習(xí)生。你讓他寫一份調(diào)研報(bào)告他可能比老員工寫得還漂亮但你直接讓他去對(duì)接客戶、修改生產(chǎn)庫、給全公司發(fā)通知你敢嗎不敢。因?yàn)樗€不熟悉你的業(yè)務(wù)規(guī)則、不知道哪些雷不能踩、更沒法對(duì)自己的行為負(fù)責(zé)。AI也是同樣的道理。Anthropic內(nèi)部之所以把建議權(quán)和執(zhí)行權(quán)分開是因?yàn)樗麄儗?duì)質(zhì)量要求極高一份方案錯(cuò)了可以馬上改但推送到生產(chǎn)環(huán)境的東西錯(cuò)了影響的是真實(shí)用戶。所以手冊里的做法是讓Claude把方案做得足夠詳細(xì)把代碼寫得足夠完整把風(fēng)險(xiǎn)點(diǎn)標(biāo)注得足夠清楚然后由人來做最終確認(rèn)。這不是不信任AI而是信任AI的方式更務(wù)實(shí)——把它最強(qiáng)的能力生成與推理用滿把它最弱的能力自主承擔(dān)后果交給人類兜底。1.3 手冊對(duì)人類角色的重新定義不是監(jiān)工是決策者這里有一層很容易被忽略的意思手冊不只是給AI立規(guī)矩也在給使用AI的人重新定位。你不再是操作員每步都手動(dòng)敲命令也不是甩手掌柜全程放手讓AI跑而是決策者批準(zhǔn)方向、把控風(fēng)險(xiǎn)、驗(yàn)收結(jié)果。這個(gè)角色轉(zhuǎn)換非常關(guān)鍵。如果你是操作員心態(tài)你會(huì)覺得AI給的方案反正比你自己想得快于是逐漸放松審查最后被小錯(cuò)積累拖垮如果你是甩手掌柜心態(tài)你會(huì)把AI的一次性失誤放大成巨大的返工成本。只有切換到?jīng)Q策者心態(tài)你才會(huì)在每一個(gè)關(guān)鍵節(jié)點(diǎn)認(rèn)真問自己這個(gè)方案真的要批準(zhǔn)嗎影響范圍我清楚嗎回滾路徑準(zhǔn)備好了嗎說白了手冊并非教你怎么管住Claude而是教你怎么承擔(dān)起使用AI的責(zé)任。一場協(xié)作里AI負(fù)責(zé)提供高質(zhì)量的可能性你負(fù)責(zé)挑選可能性并承擔(dān)后果這才是真正的人機(jī)分工。2. Skills 體系的底層設(shè)計(jì)讓 Claude 知道該做什么而不是放權(quán)隨便做2.1 Skills 到底是什么和普通 Prompt 的實(shí)質(zhì)區(qū)別如果說別讓它動(dòng)手是手冊的第一層核心那第二層核心就是對(duì)Skills的定位Skills是用來給Claude裝知識(shí)的而不是用來放權(quán)限的。熱搜詞里大量出現(xiàn)skills大全skills下載平臺(tái)前端開發(fā)skills分鏡skills說明很多人已經(jīng)意識(shí)到Skills很關(guān)鍵但理解上容易走偏。簡單說Skills是一組預(yù)先編排好的專業(yè)方法包里面包含領(lǐng)域知識(shí)、操作規(guī)范、輸出模板和邊界規(guī)則。普通Prompt是一次性的指令Skills則是可復(fù)用的能力模塊。對(duì)比維度普通 PromptSkills使用方式每次手動(dòng)輸入按需加載或自動(dòng)觸發(fā)內(nèi)容構(gòu)成一段話指令知識(shí)流程模板邊界規(guī)則打包穩(wěn)定性每次效果不穩(wěn)定收斂到一套成熟流程適用場景臨時(shí)、非高頻任務(wù)高頻、有強(qiáng)流程要求的任務(wù)打個(gè)比方普通Prompt是你口頭吩咐新人幫我把這個(gè)表做一下Skills是你甩給他一本《本部門周報(bào)編制規(guī)范》里面寫了數(shù)據(jù)來源、圖表格式、檢查清單、常見錯(cuò)誤。后者當(dāng)然更穩(wěn)。2.2 手冊里對(duì) Skills 使用邊界的態(tài)度約束比能力更重要手冊里有一個(gè)讓我印象很深的原則Skills應(yīng)該規(guī)定Claude能獲得什么信息、按什么格式輸出、不能越界做什么而不是只告訴它你可以做到這些。Anthropic在內(nèi)部使用Skills時(shí)偏好把約束寫得非常具體。比如一份代碼審查Skills里面可不止如何審查的流程還會(huì)清清楚楚寫出這樣幾條只能提出修改建議不能直接改動(dòng)倉庫里的文件涉及安全敏感模塊時(shí)必須標(biāo)記為高風(fēng)險(xiǎn)交由人工復(fù)核給出的每條建議必須對(duì)應(yīng)到具體代碼行不允許籠統(tǒng)評(píng)價(jià)這種設(shè)計(jì)邏輯的本質(zhì)是用Skills給Claude裝上行業(yè)知識(shí)和行為約束讓它從一個(gè)能說會(huì)道但沒邊界的模型變成一個(gè)懂規(guī)矩、知進(jìn)退的協(xié)作者。很多人把Skills當(dāng)成某種外掛裝上后以為AI就什么都能干了。其實(shí)Skills真正的價(jià)值在于把不確定的黑盒變成可控的灰盒它依然可能出錯(cuò)但出錯(cuò)的范圍、方式和速度都在你預(yù)設(shè)的軌道里。2.3 怎么判斷一份 Skills 值不值得用既然熱搜詞里都在找skills推薦skills安裝包這里有必要多說幾句。我見過不少朋友一口氣裝了十幾個(gè)Skills結(jié)果大部分在吃灰甚至有的互相打架。判斷一份Skills值不值得用我一般看三點(diǎn)。第一它解決的是不是你自己高頻遇到的問題。你天天寫前端「前端開發(fā)Skills」就很有用你一個(gè)月才用一次那臨時(shí)寫Prompt反而更靈活沒必要多一層依賴。第二它的規(guī)則是否清晰。一份好的Skills會(huì)明確說明輸入、輸出、邊界、注意事項(xiàng)而不是堆砌形容詞和空話。拿到Skills先讀一遍規(guī)則段如果讀完之后你依然不知道那我到底該拿它做什么這技能包多半是水的。第三它會(huì)不會(huì)攔截你的關(guān)鍵決策。如果發(fā)現(xiàn)用了某個(gè)Skills之后AI開始自動(dòng)執(zhí)行原本應(yīng)該由你來確認(rèn)的操作——比如直接改文件、直接外發(fā)消息、直接安裝依賴——那就要警惕了。這種Skills違背了手冊里別讓它動(dòng)手的精神風(fēng)險(xiǎn)很高。3. 從手冊拆解內(nèi)部工作流方案先行、人工審批、小步驗(yàn)收3.1 第一步先讓 Claude 出方案而不是直接開工Anthropic內(nèi)部的實(shí)際工作流第一步通常是方案對(duì)話。他們會(huì)要求Claude先分析需求、列出可能的做法、標(biāo)出不確定的地方、給出推薦方案以及備選方案。在這一步Claude動(dòng)的是嘴不是手。我們平時(shí)用Claude也應(yīng)該照搬這個(gè)邏輯。比如你想讓它幫你重構(gòu)一段Python代碼規(guī)范的提問方式是這樣先不要改任何代碼。請(qǐng)你分析當(dāng)前實(shí)現(xiàn)存在的問題列出三種改進(jìn)方案并就每種方案說明改動(dòng)范圍、遷移成本和風(fēng)險(xiǎn)點(diǎn)最后給出你的推薦及理由。而不是幫我把這個(gè)重構(gòu)了。兩種問法在Claude看來有本質(zhì)區(qū)別。第一種把它限制在獻(xiàn)策者角色它會(huì)用更多推理篇幅去權(quán)衡利弊第二種它可能直接一個(gè)版本改完扔給你改得對(duì)不對(duì)你自己去測試。實(shí)踐下來第一種看起來慢實(shí)際總耗時(shí)更短——因?yàn)槟闶〉袅舜罅康姆倒ず团挪闀r(shí)間。這套邏輯不只在代碼場景成立。寫方案、做研究、排日程也一樣先讓它提交一份作戰(zhàn)計(jì)劃你看完再?zèng)Q定是讓它展開細(xì)節(jié)還是讓你自己接手寫。凡是涉及多步驟、幾步驟之后可能有分叉的任務(wù)方案先行永遠(yuǎn)優(yōu)于立刻執(zhí)行。3.2 第二步人工審批點(diǎn)到底設(shè)在哪里手冊里最值得普通用戶學(xué)的就是人工審批點(diǎn)的設(shè)計(jì)。你不需要所有環(huán)節(jié)都盯著Claude更不需要完全放手而是在幾個(gè)關(guān)鍵節(jié)點(diǎn)插入強(qiáng)制確認(rèn)。拿我最近在走的Claude Code小步開發(fā)流程舉例審批點(diǎn)我會(huì)這樣設(shè)置環(huán)節(jié)Claude 的產(chǎn)出人工審批動(dòng)作需求理解需求文檔與任務(wù)拆解確認(rèn)它是否真正理解了目標(biāo)方案設(shè)計(jì)技術(shù)方案 / 改動(dòng)清單確認(rèn)技術(shù)選型與影響范圍實(shí)現(xiàn)階段每個(gè)小功能的代碼小步提交前人工review測試驗(yàn)證測試用例建議 / dry-run 結(jié)果決定是否允許進(jìn)入正式環(huán)境這里的關(guān)鍵不是每個(gè)步驟都要審批而是可能產(chǎn)生不可逆影響的操作必須有審批。推送、發(fā)布、覆蓋文件、刪除數(shù)據(jù)、批量發(fā)消息這些必須卡人。而生成草稿、整理要點(diǎn)、總結(jié)會(huì)議記錄這類無副作用的操作大可以放手讓Claude隨便跑。順便說一句Claude Code里有個(gè)常用功能叫自動(dòng)接受工具調(diào)用默認(rèn)建議別全開。你可以在配置里把它調(diào)成每次都問一下雖然多點(diǎn)幾次確認(rèn)但換來的是你對(duì)整個(gè)工作流狀態(tài)的掌控感值。3.3 第三步小步執(zhí)行并設(shè)定可回滾邊界如果你確實(shí)需要Claude動(dòng)手做些事手冊的做法是圈定一個(gè)明確的小范圍并且保證可回滾。幾個(gè)我實(shí)測管用的約束只允許在feature分支上修改不給master分支的寫權(quán)限運(yùn)行前必須生成變更diff人過一眼再合并涉及第三方API調(diào)用或資金數(shù)據(jù)時(shí)只允許生成測試用例不允許直接操作生產(chǎn)數(shù)據(jù)所有自動(dòng)執(zhí)行先開dry-run模式看它準(zhǔn)備做什么再?zèng)Q定放不放行。這些約束聽起來像工程管理的基本素養(yǎng)但在AI協(xié)作里很容易被忽略。因?yàn)锳I給你一種很全能的錯(cuò)覺你在它身上放權(quán)就像讓一個(gè)能力很強(qiáng)但還不熟悉你業(yè)務(wù)的實(shí)習(xí)生直接管生產(chǎn)環(huán)境——多半會(huì)出事。我實(shí)測過最穩(wěn)的執(zhí)行粒度是一次讓它改不超過三個(gè)文件每個(gè)文件改動(dòng)控制在幾十行以內(nèi)然后立刻測試、驗(yàn)證、提交。改得越小出了問題越容易定位。這種小步快跑的節(jié)奏看起來不酷但長期下來返工率極低。3.4 一個(gè)完整的端到端案例用 Claude 做新功能開發(fā)為了讓你把上面三條串起來我用一個(gè)實(shí)際案例演示方案先行—人工審批—小步執(zhí)行怎么走。假設(shè)我要做一個(gè)新功能給博客加一個(gè)相關(guān)文章推薦模塊。我不會(huì)上來就說幫我實(shí)現(xiàn)這個(gè)功能而是分四步。第一步方案。我讓Claude先分析推薦算法有哪幾種可選標(biāo)簽匹配、協(xié)同過濾、向量相似度各自對(duì)博客這種低數(shù)據(jù)量場景的適配度如何需要引入哪些依賴對(duì)現(xiàn)有架構(gòu)的影響面在哪里。它給了方案我挑了最簡單的標(biāo)簽匹配。第二步拆解。我批準(zhǔn)方案后讓Claude把任務(wù)拆成小步驟數(shù)據(jù)模型、查詢邏輯、展示組件、測試用例。并且約定好每一步只給代碼建議由我決定何時(shí)寫入項(xiàng)目。第三步逐個(gè)實(shí)現(xiàn)。我每次只問一個(gè)子任務(wù)比如基于標(biāo)簽匹配算法給出查詢相關(guān)文章的SQL和Python代碼注意排除當(dāng)前文章。拿到代碼后我review、測試、提交再問下一步。第四步驗(yàn)證。我讓Claude先給出一份測試用例清單說明覆蓋哪些邊界情況。我看完覺得不夠又補(bǔ)了一條沒有任何標(biāo)簽重疊時(shí)的兜底邏輯。整個(gè)過程Claude生成的代碼占了八成以上但每一步的開關(guān)都在我手里。最終功能上線很順利沒有一次大的返工。這就是別讓它動(dòng)手策略在實(shí)踐中該有的樣子。4. 落到我們自己手中的四類用法把高級(jí)顧問價(jià)值榨出來4.1 用法一把 Claude 當(dāng)方案評(píng)審員而不是代寫機(jī)器這是我最推薦的入門用法。不要一開始就讓Claude幫你從零寫一個(gè)完整系統(tǒng)而是讓它審你已有的代碼、文章、方案。讓它找問題、指風(fēng)險(xiǎn)、給改進(jìn)建議你決定改哪些。這樣做有三個(gè)好處第一你對(duì)現(xiàn)狀的理解不會(huì)丟不會(huì)被AI帶著跑偏第二Claude建議的質(zhì)量通常比憑空輸出高很多因?yàn)樗芯唧w上下文可以參考第三萬一它建議錯(cuò)了你多半也能發(fā)現(xiàn)因?yàn)槟阒垃F(xiàn)狀的來龍去脈。我每天都會(huì)把剛寫完的代碼貼給Claude加一句請(qǐng)以資深工程師視角做code review先不要修改原始代碼只列出問題清單、風(fēng)險(xiǎn)等級(jí)、修改建議按優(yōu)先級(jí)排序。它的回復(fù)通常很具體而且不會(huì)自作主張把代碼全改掉。這種做法幾乎完美契合手冊的精神Claude輸出專業(yè)判斷人類執(zhí)行最終修改。4.2 用法二把高頻經(jīng)驗(yàn)沉淀成自己的 Skills 包既然大家都在搜Skills下載那我順帶說一下怎么自己做一個(gè)簡單可用的Skills。不需要多復(fù)雜三步就夠。第一步找重復(fù)任務(wù)。比如你每周都要寫數(shù)據(jù)分析周報(bào)每次都要重復(fù)交代格式、數(shù)據(jù)來源、圖表風(fēng)格。這種任務(wù)最適合做成Skills。第二步封裝經(jīng)驗(yàn)。把做這個(gè)任務(wù)需要遵循的步驟、參考標(biāo)準(zhǔn)、輸出模板、易錯(cuò)點(diǎn)寫清楚。這就是Skills的核心內(nèi)容。比如一份數(shù)據(jù)分析周報(bào)Skills可以包含必須用哪些數(shù)據(jù)源、圖表必須配文字結(jié)論、每部分字?jǐn)?shù)上限、常見的數(shù)據(jù)口徑錯(cuò)誤。第三步配置成技能。在Claude Code或桌面端里把這份內(nèi)容打包成專門的指令集設(shè)置觸發(fā)條件或按需加載。以后說一句用周報(bào)技能生成這周的分析它會(huì)自動(dòng)按你的流程走不需要每次重新解釋背景。這和Anthropic內(nèi)部把企業(yè)知識(shí)打包成Skills的思路一模一樣只是規(guī)模不同。如果你手里還沒有自己的Skills強(qiáng)烈建議從一件你每周重復(fù)做的事情開始做完之后你會(huì)明顯感受到模板化協(xié)作和每次從零講起的效率差距。4.3 用法三Claude Code 的正確姿勢——先問再小步做Claude Code近期熱度很高熱搜詞里大量出現(xiàn)claude code安裝claude code使用vscode配置claude code說明很多人正在嘗試這條路。但安裝配置只是第一關(guān)真正拉開差距的是使用姿勢。我總結(jié)了一套適合大多數(shù)人的姿勢六句話先描述全局背景再問具體任務(wù)讓Claude先列計(jì)劃確認(rèn)后再動(dòng)手堅(jiān)持小步提交一個(gè)改動(dòng)配一個(gè)說明所有高風(fēng)險(xiǎn)操作改成手動(dòng)確認(rèn)測試案例永遠(yuǎn)讓Claude先給你來決定跑不跑出錯(cuò)時(shí)把完整報(bào)錯(cuò)貼回去別只貼最后一行。用這個(gè)姿勢跑了一段時(shí)間后你會(huì)明顯感受到它比直接放權(quán)省心得多。不是AI不行而是人機(jī)協(xié)作需要節(jié)奏感。過早放權(quán)等于把方向盤交給了還不熟悉路況的副駕駛它技術(shù)再好你也心慌。4.4 用法四本地模型、隱私場景下的取舍熱搜詞里還有一條很有意思claude code 調(diào)用lmstudio的本地模型。對(duì)隱私要求高的場景不少人確實(shí)會(huì)把Claude Code接到本地模型上跑。這條路我也試過能跑通但有兩個(gè)結(jié)論必須提醒。第一本地模型的推理能力通常比官方Claude有差距所以前面說的方案先行、人工審批、小步執(zhí)行這套流程要執(zhí)行得更嚴(yán)格。本地模型更容易偏離軌道人工把關(guān)的密度必須更高不能因?yàn)樗茉谧约弘娔X上就覺得安全。第二Skills體系在本地模型上不一定完整兼容有些人能把一些復(fù)雜Skills跑出像樣的效果有些則明顯變差。遇到后一種情況別急著怪Skills寫得不好先判斷一下模型本身的指令遵循能力是否夠用必要時(shí)把Skills拆得更簡單減少復(fù)雜指令嵌套。4.5 普通用戶最容易踩的三個(gè)坑結(jié)合我自己的經(jīng)歷和網(wǎng)上大量反饋三個(gè)最典型的坑列出來你們對(duì)照一下自己有沒有中招?？右灰簧蟻砭腿詣?dòng)。很多人裝完Claude Code第一件事就是讓它自己搞定整個(gè)項(xiàng)目結(jié)果改出一堆不兼容代碼然后責(zé)怪AI不行。其實(shí)問題不在AI而在你跳過了方案確認(rèn)這個(gè)環(huán)節(jié)。全自動(dòng)模式適合無人值守的簡單任務(wù)不適合有技術(shù)債、有歷史包袱的項(xiàng)目?？佣つ慷裇kills?？吹絪kills大全就全裝上我此前也干過最后發(fā)現(xiàn)很多Skills互相沖突同類問題兩個(gè)技能包搶著響應(yīng)。之后我只保留真正高頻使用的三五個(gè)每個(gè)都有明確的觸發(fā)條件效果反而大幅提升?？尤袰laude當(dāng)成搜索引擎。它不是搜索引擎你直接問怎么寫登錄功能它給的是通用解法。你把項(xiàng)目背景、技術(shù)棧、已有代碼上下文都放進(jìn)去再讓它基于現(xiàn)狀給建議質(zhì)量會(huì)完全不一樣。好的結(jié)果來自好的上下文這句話不是空話。另外補(bǔ)一個(gè)小經(jīng)驗(yàn)無論你用哪個(gè)模型如果發(fā)現(xiàn)同樣的指令在多輪對(duì)話之后效果開始變差多半是上下文里累積了太多無效信息。此時(shí)別硬問開個(gè)新對(duì)話把關(guān)鍵背景重新交代一遍效果通常立刻回升。這個(gè)技巧看似簡單我身邊很多人到現(xiàn)在還在用。我自己用下來的體會(huì)是這份手冊的最大啟發(fā)不在于某個(gè)具體技巧而在于重新思考了人和AI的邊界。Claude再強(qiáng)目前它最可靠的角色仍然是高密度輸出建議的參謀而不是替你負(fù)全部責(zé)任的執(zhí)行者。你把它放在參謀的位置它會(huì)源源不斷地給你靈感你把它放到需要承擔(dān)后果的崗位上它就會(huì)暴露出現(xiàn)階段的脆弱。反正我如今寫代碼、寫方案、做分析都默認(rèn)這套節(jié)奏了——不是不敢用而是知道怎么用才穩(wěn)。最后再給一條小建議如果你想驗(yàn)證一套AI協(xié)作流程靠不靠譜先用假數(shù)據(jù)、假目錄、測試分支跑一遍dry-run全程觀察它打算做什么再做最終決定。這比任何參數(shù)調(diào)優(yōu)都管用。Skills的自建方法我后面會(huì)單獨(dú)整理一份更詳細(xì)的操作教程這套方法論可以先上手試試多跑幾輪你就懂手冊里那句別讓它動(dòng)手的含金量了。