如果你跟我一樣是個(gè)天天泡在終端里的開發(fā)者應(yīng)該體會(huì)過這種落差A(yù)I 對(duì)話模型能說會(huì)道卻沒辦法直接幫你執(zhí)行一個(gè)命令、讀一個(gè)文件、改一個(gè)配置。最近社區(qū)里聊得很多的 Claude Code Mods正好補(bǔ)上了這塊短板——它把 Claude 從“會(huì)聊天的助手”變成了“能動(dòng)手的工具人”還能在終端里畫出可用的界面。這篇文章我打算從概念、原理、實(shí)操到踩坑把 Claude Code Mods 這件事完整捋一遍給想嘗鮮的開發(fā)者一條盡量少繞彎的路。先說清楚一個(gè)前提Mods 這個(gè)叫法在不同人口里意思稍微有點(diǎn)偏差有人叫它擴(kuò)展包有人叫它工具集還有人直接叫“技能包”。在我自己的實(shí)踐里它本質(zhì)上就是一套“工具注冊(cè) 觸發(fā)規(guī)則 界面輸出”的組合方案讓 Claude 在終端環(huán)境中擁有讀文件、跑腳本、查系統(tǒng)狀態(tài)、輸出富文本界面這些能力。文章后面所有的內(nèi)容都圍繞這個(gè)理解展開。1. Claude Code Mods 是什么我為什么稱它為“給 AI 裝手”1.1 從聊天窗口到終端工具鏈Mods 出現(xiàn)的直接動(dòng)機(jī)大多數(shù)人對(duì) AI 編程助手的認(rèn)知還停留在“對(duì)話框里聊代碼”。你讓它寫一段 Python它給你一段代碼你復(fù)制粘貼跑一下有問題再貼回來。這套流程的痛點(diǎn)非常明顯AI 看不到你的目錄結(jié)構(gòu)讀不到你的配置文件更沒法自己在終端里跑一條命令看看結(jié)果。換句話說它沒有“手”只有“嘴”。Claude Code Mods 解決的就是這個(gè)問題。它的思路說起來很簡單把 AI 之外的操作能力拆成一個(gè)個(gè)可調(diào)用的工具讓模型在推理過程中按需“伸手”。比如你說“幫我看下當(dāng)前項(xiàng)目的依賴版本沖突”普通對(duì)話助手只能憑空猜而掛載了工具能力的 Claude 可以先執(zhí)行一行命令讀取依賴清單再讀取鎖文件最后把對(duì)比結(jié)果整理給你。我覺得用 IDE 插件來類比最合適。編輯器本身只會(huì)處理文本裝上插件才能格式化、補(bǔ)全、連接遠(yuǎn)端。Claude 本身只會(huì)處理語言掛上 Mods 才能操作文件系統(tǒng)、運(yùn)行命令、解析結(jié)果、渲染界面。這種“理解能力”和“執(zhí)行能力”的分離恰恰是它能在真實(shí)開發(fā)環(huán)境里起作用的關(guān)鍵。1.2 Mods、插件、Agent 能力包一套命名背后的多種心智模型如果你翻社區(qū)討論會(huì)發(fā)現(xiàn)好多名詞在講同一個(gè)概念。有些帖子管它叫“Claude Code Mods”有些管它叫“Agent 工具擴(kuò)展”還有些直接說“MCP 工具”。這里我不打算嚴(yán)格考證術(shù)語的官方出處但想幫你把它們之間的關(guān)系理清楚。Mods 在我的理解里更像是一個(gè)用戶視角的稱呼強(qiáng)調(diào)的是“給 AI 加模組”這個(gè)動(dòng)作。MCP 則是偏向協(xié)議層面的說法描述的是 AI 與外部工具之間“如何標(biāo)準(zhǔn)化地通信”。你可以把 MCP 看作 Mods 底層的運(yùn)輸協(xié)議把 Mods 看作上層打包好的能力單元。實(shí)際使用中你更關(guān)心的是“我要怎么裝一個(gè)工具”而不是“它底層走的是什么協(xié)議字節(jié)”?？创男闹悄Ｐ陀腥N插件模型為已有程序增加功能、技能模型教會(huì) AI 一個(gè)新本領(lǐng)、接口模型把 AI 接到命令行世界里。三種模型都對(duì)只是關(guān)注點(diǎn)不同。我會(huì)在后面的章節(jié)里分別用這三個(gè)視角來展開因?yàn)橥粋€(gè) Mod從安裝角度是插件從使用角度是技能從調(diào)試角度是接口。1.3 適合誰用、不適合誰用先看清邊界再動(dòng)手說實(shí)話Claude Code Mods 不是給所有人準(zhǔn)備的。如果你只是偶爾讓 AI 寫個(gè)函數(shù)、查個(gè)語法那這東西對(duì)你的幫助有限裝上反而要花時(shí)間維護(hù)。它更適合這幾類場(chǎng)景日常大量工作在終端里完成的開發(fā)者、需要 AI 執(zhí)行多步驟運(yùn)維或構(gòu)建任務(wù)的工程師、以及想探索“AI 自動(dòng)操作電腦”玩法的人。反過來如果你完全沒接觸過命令行看到環(huán)境變量就頭大那我建議你先別碰 Mods。它并不能降低使用門檻反而會(huì)把終端操作、腳本編寫、輸出解析這些復(fù)雜度一并引入。我見過有些新手裝完工具包之后因?yàn)榄h(huán)境問題折騰半天最后連基礎(chǔ)對(duì)話都沒法用了這就本末倒置了。所以我的建議是先在命令行里正常使用 Claude Code 完成幾次代碼生成和修改確認(rèn)你確實(shí)需要“讓它自己跑命令、讀文件”這種能力之后再來看 Mods。2. Mods 的工作原理拆解工具注冊(cè)、調(diào)用循環(huán)與“畫界面”的真相2.1 工具注冊(cè)表AI 如何知道自己“能干什么”這里有個(gè)核心設(shè)計(jì)問題Claude 本身并不知道你裝了哪些 Mod更不知道每個(gè) Mod 能做什么。它之所以能“想起來調(diào)用工具”靠的是一份工具注冊(cè)表。通常這份注冊(cè)表是一個(gè)配置文件里面描述了每個(gè) Mod 的名稱、功能說明、參數(shù)結(jié)構(gòu)、執(zhí)行命令。可以把它理解成給 AI 的一份菜單。菜單上寫著“環(huán)境快照采集當(dāng)前系統(tǒng)信息無需參數(shù)執(zhí)行命令 python3 env_snapshot.py”。模型讀到這條描述后在對(duì)話中判斷“用戶想知道系統(tǒng)狀態(tài)”時(shí)就會(huì)主動(dòng)去點(diǎn)這份菜單上的菜。關(guān)鍵是功能說明寫得準(zhǔn)不準(zhǔn)。因?yàn)槟Ｐ筒⒉皇钦娴拈喿x了你的工具源碼它只是通過描述來決定調(diào)用策略。描述寫得太模糊它會(huì)在不需要的時(shí)候調(diào)用描述寫得太具體它又可能錯(cuò)過合適的觸發(fā)時(shí)機(jī)。這算是配置 Mods 的一個(gè)核心手藝活后面實(shí)操部分我會(huì)單獨(dú)講。2.2 工具調(diào)用循環(huán)從你說了半句話到工具跑出結(jié)果Mods 的執(zhí)行不是一個(gè)一次性過程而是一個(gè)循環(huán)。用戶下達(dá)指令后模型內(nèi)部會(huì)做決策我這句回答需不需要借助外部工具如果需要它就從注冊(cè)表里挑出最匹配的工具填充參數(shù)然后觸發(fā)執(zhí)行。工具跑完后的輸出會(huì)作為新的上下文回填給模型模型再根據(jù)這個(gè)結(jié)果決定是繼續(xù)調(diào)用下一個(gè)工具還是直接生成回答。這個(gè)過程很像人類查資料你問一個(gè)復(fù)雜問題我意識(shí)到自己不確定就去翻文檔文檔里看到一個(gè)數(shù)字我基于這個(gè)數(shù)字進(jìn)一步計(jì)算最后把完整答案告訴你。AI 自己不會(huì)“翻文檔”它需要 Mods 幫它翻翻完的內(nèi)容由它繼續(xù)思考。理解這個(gè)循環(huán)對(duì)調(diào)試非常重要。當(dāng) Mod 沒有生效時(shí)問題往往出在循環(huán)的某個(gè)環(huán)節(jié)要么模型壓根沒決定調(diào)用工具要么工具執(zhí)行失敗沒產(chǎn)出有效結(jié)果要么結(jié)果回傳后模型不知道如何繼續(xù)。很多時(shí)候不是工具寫得有問題而是工具輸出的格式讓模型“看不懂”。2.3 為什么終端還能“畫界面”ANSI 轉(zhuǎn)義序列與 TUI 最小原理標(biāo)題里提到“在終端畫界面”這句話容易讓人誤解成類似桌面的圖形界面。實(shí)際上終端里面畫的界面是字符界面底層靠的是 ANSI 轉(zhuǎn)義序列。這是一套特殊字符組合終端收到后會(huì)改變顯示方式比如顏色、光標(biāo)位置、清屏等。舉個(gè)例子你平時(shí)在終端里看到紅色的報(bào)錯(cuò)信息、粗體的警告都是程序輸出 ANSI 控制碼實(shí)現(xiàn)的。Mods“畫界面”的常規(guī)做法就是讓工具直接輸出帶這些控制碼的文本Claude 所在的終端會(huì)把它們渲染成帶邊框、顏色、高亮的“偽圖形界面”。如果你需要真正的交互式界面——比如上下鍵選擇選項(xiàng)、實(shí)時(shí)刷新進(jìn)度條——那復(fù)雜度就上去了。這類界面通常需要額外的前后臺(tái)控制、按鍵監(jiān)聽、光標(biāo)管理和備用屏幕切換。一些 Mods 會(huì)調(diào)用現(xiàn)成的 TUI 工具或腳本庫來實(shí)現(xiàn)而不是自己從零寫轉(zhuǎn)義序列。理解這一層你就明白為什么有人說“在終端畫界面”是可行的但又是有限制的。3. 從零開始裝一個(gè) Mods環(huán)境準(zhǔn)備、目錄結(jié)構(gòu)與第一個(gè)自定義工具3.1 環(huán)境準(zhǔn)備與安裝路徑用戶級(jí)和項(xiàng)目級(jí)配置怎么選在開始動(dòng)手前先確認(rèn)兩件事你的 Claude Code 能在終端里正常運(yùn)行并且 Python 3 或 Node.js看你要寫什么工具在 PATH 里可用。不同版本的 Claude Code 對(duì) Mods 的支持方式有一點(diǎn)差異我下面給出的目錄結(jié)構(gòu)和配置格式是按照社區(qū)里最能通用的約定整理的你實(shí)際操作時(shí)要以本機(jī)版本的實(shí)際提示為準(zhǔn)。安裝路徑通常有兩種用戶級(jí)和項(xiàng)目級(jí)。用戶級(jí)把所有 Mods 放在當(dāng)前用戶的主目錄下任何項(xiàng)目都能調(diào)用適合放通用性強(qiáng)的工具比如系統(tǒng)信息采集、代碼統(tǒng)計(jì)、文本轉(zhuǎn)換。項(xiàng)目級(jí)則跟著倉庫走放在項(xiàng)目的隱藏目錄里適合放和該項(xiàng)目強(qiáng)綁定的工具比如讀取本項(xiàng)目特有的配置、執(zhí)行項(xiàng)目專用腳本。我個(gè)人建議是“少量通用工具放用戶級(jí)項(xiàng)目專屬工具放項(xiàng)目級(jí)”。原因很實(shí)際用戶級(jí)目錄裝太多工具會(huì)讓模型在每次對(duì)話時(shí)面對(duì)大量可用工具的描述既增加上下文消耗也容易造成選擇混亂。工具箱太大AI 也會(huì)挑花眼。3.2 第一個(gè)自定義 Mod用 Python 做一個(gè)環(huán)境快照采集器直接上一個(gè)最小可用示例讓大家感受一下工具本身長什么樣。我先創(chuàng)建一個(gè)目錄結(jié)構(gòu)通常每個(gè) Mod 獨(dú)立一個(gè)文件夾里面放一個(gè)配置文件和一個(gè)執(zhí)行腳本。~/.claude/mods/ └── env_snapshot/ ├── manifest.json └── env_snapshot.pymanifest.json 描述這個(gè)工具的基本信息和調(diào)用方式。我按常見的約定寫一個(gè)最精簡版本{ name: env_snapshot, description: 采集當(dāng)前終端環(huán)境的系統(tǒng)信息和常用環(huán)境變量返回 JSON 格式結(jié)果, schema: { type: object, properties: {}, required: [] }, command: [python3, env_snapshot.py] }對(duì)應(yīng)的 env_snapshot.py 也很簡單#!/usr/bin/env python3 import json import os import platform import sys def main(): info { hostname: platform.node(), system: platform.system(), release: platform.release(), python: sys.version.split()[0] if sys.version else , shell: os.environ.get(SHELL, ), path_count: len(os.environ.get(PATH, ).split(:)), } print(json.dumps(info, ensure_asciiTrue)) if __name__ __main__: main()這里要注意幾個(gè)習(xí)慣。輸出只用標(biāo)準(zhǔn)輸出打印 JSON不要往標(biāo)準(zhǔn)輸出打日志否則模型會(huì)把非結(jié)構(gòu)化內(nèi)容當(dāng)作工具結(jié)果。其次命令入口一定要寫對(duì)Python 腳本最好加上可執(zhí)行權(quán)限避免出現(xiàn)調(diào)起來卻沒有任何反應(yīng)的情況。3.3 注冊(cè)與調(diào)試如何讓 Claude 看到并正確調(diào)用你的工具把文件放到目錄、配置好 manifest 之后理論上 Claude 下一次會(huì)話就能看到這個(gè)工具。但“看到”和“正確調(diào)用”之間還有不少距離。第一次測(cè)試我建議你直接給一句非常明確的指令“用環(huán)境快照工具采集系統(tǒng)信息并解釋每個(gè)字段的含義?！比绻?Claude 沒有調(diào)用工具而是直接作答常見原因有三個(gè)工具描述不夠清晰、當(dāng)前會(huì)話沒有刷新注冊(cè)信息、工具注冊(cè)表的目錄路徑?jīng)]有指對(duì)。逐個(gè)排查先重啟會(huì)話再確認(rèn)目錄路徑與配置文件格式最后把 description 改得更有行動(dòng)感比如把“系統(tǒng)信息”改成“當(dāng)用戶想要了解系統(tǒng)環(huán)境或排查環(huán)境問題時(shí)采集詳細(xì)環(huán)境信息”。調(diào)試過程中最重要的一環(huán)是看工具的輸出有沒有被模型理解。如果它輸出了這里沒有的工具名稱或者猶豫不決地重復(fù)調(diào)用多半是返回格式有問題。我的習(xí)慣是讓所有工具統(tǒng)一輸出 JSON穩(wěn)定、簡潔、機(jī)器可讀。模型解析 JSON 的可靠性遠(yuǎn)高于解析自由文本。4. 在終端里“畫界面”渲染能力、交互組件與實(shí)用封裝4.1 終端渲染的能力邊界什么能畫、什么不能畫先給“終端畫界面”這件事定個(gè)性它能畫出漂亮的富文本面板、狀態(tài)提示、選項(xiàng)菜單但它畫不出像素級(jí)自由布局的圖形應(yīng)用。想要拖拽、縮放、圓角陰影那是桌面 GUI 的事終端里做不到。這塊邊界想清楚后面設(shè)計(jì) Mod 時(shí)就不會(huì)走歪。終端里能畫的東西其實(shí)非常豐富。文字顏色有 16 色、256 色、真彩色三種模式支持加粗、斜體、下劃線、隱藏可以控制光標(biāo)移動(dòng)、清屏、滾動(dòng)甚至可以用備用屏幕臨時(shí)切換整頁顯示。組合起來已經(jīng)足以模擬出老式應(yīng)用軟件的界面質(zhì)感。我自己在實(shí)踐中發(fā)現(xiàn)最有用的能力是富文本狀態(tài)展示和簡易選項(xiàng)菜單。比如運(yùn)行完一批檢查后用綠色輸出通過的項(xiàng)、紅色輸出失敗的項(xiàng)、黃色輸出警告的項(xiàng)。這種視覺分層比讓 AI 用純文本描述“哪些正常哪些異?！币庇^太多。4.2 做一個(gè)可交互的終端配置面板從零到能用為了讓“畫界面”不太抽象這里我給一個(gè)能用的小示例。它仍然是一個(gè) Mod但輸出不再是普通文本而是帶邊框和顏色的面板。腳本用 Python 寫核心就是拼 ANSI 轉(zhuǎn)義序列。#!/usr/bin/env python3 import sys def panel(title: str, items: list[str]) - str: width max(len(t) for t in [title] items) 4 line ─ * width out [] out.append(f\x1b[38;5;39m┌{line}┐\x1b[0m) out.append(f\x1b[38;5;39m│\x1b[1m {title:{width-2}} \x1b[0m\x1b[38;5;39m│\x1b[0m) out.append(f\x1b[38;5;39m├{line}┤\x1b[0m) for item in items: out.append(f\x1b[38;5;39m│ {item:{width-2}} │\x1b[0m) out.append(f\x1b[38;5;39m└{line}┘\x1b[0m) return \n.join(out) if __name__ __main__: demo panel(系統(tǒng)狀態(tài), [CPU: 正常, 內(nèi)存: 充足, 磁盤: 已用 67%]) print(demo)這段代碼會(huì)在終端渲染出一個(gè)帶藍(lán)色邊框的狀態(tài)面板。關(guān)鍵控制碼是\x1b[38;5;39m設(shè)置前景色和\x1b[0m重置。加粗用\x1b[1m前面已經(jīng)用過了。你把這個(gè)腳本掛到 Mods 目錄里Claude 就可以在你詢問系統(tǒng)狀態(tài)時(shí)返回這樣一塊面板。不過要提醒一句這個(gè)面板是“靜態(tài)繪制”的不能響應(yīng)按鍵。真正可交互的配置面板需要讀終端按鍵事件并依據(jù)按鍵重新渲染界面。這已經(jīng)超出了純 Mods 輸出文本的范圍通常需要額外的前端交互程序配合。我自己的經(jīng)驗(yàn)是別勉強(qiáng)在 Mods 層做復(fù)雜交互把交互界面做成一個(gè)獨(dú)立命令再讓 Claude 幫你運(yùn)行和解讀結(jié)果反而更穩(wěn)。4.3 進(jìn)階讓 Mod 輸出帶有操作引導(dǎo)的界面一個(gè)更好的做法是讓 Mod 除了畫面板還要告訴 Claude “這個(gè)界面里的選項(xiàng)分別對(duì)應(yīng)什么操作”。比如面板里顯示“構(gòu)建項(xiàng)目”“運(yùn)行測(cè)試”“清理緩存”三個(gè)按鈕工具輸出后面再附一段說明文本“用戶選擇構(gòu)建項(xiàng)目時(shí)請(qǐng)運(yùn)行 build.sh選擇運(yùn)行測(cè)試時(shí)請(qǐng)運(yùn)行 test.sh?！边@樣就把界面展示和后續(xù)操作銜接起來了。模型看到面板后會(huì)在下一輪對(duì)話中提示用戶做選擇用戶一旦選擇它就調(diào)用對(duì)應(yīng)的命令。整個(gè)過程像是一場(chǎng)由 Mod 導(dǎo)演的交互流程而 Claude 充當(dāng)了引導(dǎo)和執(zhí)行的中間人。我特別推薦這種“UI 輸出 行為約定”的組合方式它不需要終端交互編程就能實(shí)現(xiàn)接近菜單導(dǎo)航的效果。在很多工具鏈里我都是先讓 AI 繪制一個(gè)選項(xiàng)面板再把每個(gè)選項(xiàng)對(duì)應(yīng)的命令寫清楚實(shí)用性和穩(wěn)定性都非常好。5. 我實(shí)際踩過的坑路徑、權(quán)限、退出碼和渲染兼容性5.1 工具目錄與路徑規(guī)范化問題第一次寫完 Mod 后我最常見的問題就是路徑找不到。工具在被 Claude 調(diào)用時(shí)當(dāng)前工作目錄未必等于你寫腳本時(shí)的目錄尤其是項(xiàng)目級(jí) Mods 在倉庫不同子目錄下被調(diào)用時(shí)相對(duì)路徑特別容易錯(cuò)。解決辦法是腳本內(nèi)部盡量使用絕對(duì)路徑或者在 manifest 里顯式聲明執(zhí)行時(shí)的工作目錄。還有一個(gè)小技巧在工具腳本開頭打印當(dāng)前工作目錄到標(biāo)準(zhǔn)錯(cuò)誤流調(diào)試時(shí)可以看到它實(shí)際在哪運(yùn)行不至于瞎猜。5.2 退出碼與輸出解析為什么 Claude 會(huì)“誤解”結(jié)果模型解析工具輸出本質(zhì)上是在“讀字”而不是在“感受狀態(tài)”。如果你的工具運(yùn)行失敗了但腳本把堆棧跟蹤打到了 stdout模型可能會(huì)把錯(cuò)誤信息當(dāng)作有效結(jié)果繼續(xù)一本正經(jīng)地分析下去。這是非?？拥囊粋€(gè)情況。正確的做法是腳本正常路徑只輸出預(yù)期格式的數(shù)據(jù)出錯(cuò)時(shí)不僅要以非零退出碼結(jié)束還要把錯(cuò)誤信息輸出成結(jié)構(gòu)化的 JSON比如{error: 路徑不存在}。這樣模型讀取后既能判斷出錯(cuò)了又能知道錯(cuò)在哪并能向用戶解釋發(fā)生了什么。標(biāo)準(zhǔn)錯(cuò)誤流是給人工調(diào)試看的模型一般不讀它。5.3 渲染兼容性、終端寬度與中文亂碼終端界面的渲染效果在不同終端下差異很大。有的終端支持真彩色有的只支持 256 色有的對(duì)字符邊框的處理不同。我在某次實(shí)際使用中就遇到過類似情況面板在某個(gè)終端下正常顯示換到另一個(gè)終端后邊框錯(cuò)位、顏色失真。這不是腳本邏輯問題而是終端能力差異。另一個(gè)高發(fā)問題是非 ASCII 字符亂碼。中文內(nèi)容在面板里顯示為問號(hào)多半是環(huán)境沒有正確設(shè)置 UTF-8 編碼。腳本開頭設(shè)置環(huán)境變量PYTHONIOENCODINGutf-8或者子進(jìn)程顯式處理編碼可以避免大部分亂碼。終端寬度也要留意腳本里如果寫死了邊框?qū)挾仍谡翱谥袝?huì)換行錯(cuò)亂盡量根據(jù)環(huán)境變量動(dòng)態(tài)計(jì)算寬度。5.4 上下文消耗與性能調(diào)優(yōu)的小賬本很多人忽略一個(gè)問題Mods 不是免費(fèi)的每一個(gè)工具的 description、調(diào)用參數(shù)、輸出結(jié)果都要占用模型的上下文長度。工具越多每輪對(duì)話燒掉的 token 越多。我遇到過最極端的情況是掛載了一堆大型工具后簡單問一句話模型都要在海量工具描述里“找自己需要的那一個(gè)”反應(yīng)明顯變慢。實(shí)踐下來比較好的策略是精簡工具描述每句話都言之有物不寫廢話工具輸出盡量壓縮只返回必要字段長日志截?cái)嗵幚韯e讓模型讀幾百行原始輸出。相當(dāng)于你在幫 AI 做信息減負(fù)它的反應(yīng)和準(zhǔn)確度都會(huì)隨之提升。6. 把這些能力用在工作流里配置檢查、代碼審查與自動(dòng)化收尾6.1 場(chǎng)景一多環(huán)境配置檢查我在一個(gè)模擬項(xiàng)目里嘗試過一套很實(shí)用的 Mod 組合。項(xiàng)目有開發(fā)、測(cè)試、生產(chǎn)三套配置里面的連接參數(shù)經(jīng)常不一致。人工檢查費(fèi)時(shí)費(fèi)力用 Mods 就順很多。思路是做一個(gè) config_check 工具輸入是配置目錄路徑輸出是三套配置的字段差異矩陣。腳本里遍歷配置文件讀取同名 key對(duì)比后輸出 JSON。模型拿到結(jié)果后自動(dòng)生成一份差異報(bào)告并標(biāo)注最可能影響線上行為的字段。整套流程里模型負(fù)責(zé)“判斷哪些差異重要”而工具負(fù)責(zé)“把所有差異挖出來”各司其職。6.2 場(chǎng)景二代碼審查的“人工AI”雙軌模式代碼審查是我覺得 Mods 最有價(jià)值的應(yīng)用場(chǎng)景之一。傳統(tǒng)做法是人打開 diff 一點(diǎn)一點(diǎn)看效率低。我的做法是寫一個(gè) review_prep 工具自動(dòng)執(zhí)行幾個(gè)命令并匯總輸出先取當(dāng)前分支的變更文件列表再運(yùn)行一個(gè)靜態(tài)檢查工具最后把結(jié)果壓縮成精簡的 JSON 交給模型。這個(gè)工具的調(diào)用過程模擬下來大致是用戶說“幫我看下這次改動(dòng)的風(fēng)險(xiǎn)”Claude 先調(diào)用工具拿到變更概況然后針對(duì)每個(gè)變更文件閱讀差異結(jié)合靜態(tài)檢查結(jié)果輸出審查意見。和人工審查最大的區(qū)別是速度它能在幾秒鐘內(nèi)覆蓋所有變更文件而且不會(huì)漏掉那些看起來不起眼的配置修改。需要強(qiáng)調(diào)的是這種審查是“人工AI”雙軌模式AI 的輸出是輔助判斷的素材最終合不合并、怎么改仍然需要人來拍板。我一般把 Mods 生成的審查報(bào)告當(dāng)作第一道篩子它能攔住低級(jí)錯(cuò)誤但不能替代真正的業(yè)務(wù)理解。6.3 場(chǎng)景三版本發(fā)布的信息匯總發(fā)布版本時(shí)最煩的事情之一是整理發(fā)布說明。要從 git 日志里提取提交記錄、關(guān)聯(lián)需求、標(biāo)記破壞性變更還要生成一份格式統(tǒng)一的文檔。這件事 Mods 做得很好因?yàn)樗妮斎胼敵龆挤浅＝Y(jié)構(gòu)化。release_brief 工具的職責(zé)是收集提交歷史、變更文件列表、標(biāo)簽信息過濾掉 chore 類提交再按類型分組輸出。模型收到結(jié)果后會(huì)補(bǔ)上用戶可讀的發(fā)布摘要并把遺留事項(xiàng)單獨(dú)列出來。相比人工翻日志這個(gè)流程節(jié)省的時(shí)間以小時(shí)計(jì)而且不容易漏掉重要變更。在這些實(shí)踐里我最大的體會(huì)是Mods 真正強(qiáng)大的地方不在于單個(gè)工具多復(fù)雜而在于它們可以被模型組合調(diào)用。模型像一個(gè)編排者按需選擇工具、串聯(lián)結(jié)果、綜合判斷。你提供的工具越貼合真實(shí)工作流它的組合效果越驚人。最后再分享一點(diǎn)個(gè)人經(jīng)驗(yàn)。當(dāng)初我剛開始寫 Mods 的時(shí)候總想著把界面做得越炫越好、工具做得越多越好。折騰過一陣子后回頭發(fā)現(xiàn)真正穩(wěn)定好用的恰恰是那些功能單一、輸出干凈、描述清晰的小工具。一個(gè)能穩(wěn)定被調(diào)用、返回有效結(jié)果的簡單工具遠(yuǎn)勝過一個(gè)花哨但經(jīng)常出錯(cuò)的大型界面包。先讓工具鏈跑通再考慮畫界面加交互這條路會(huì)順暢很多。