1. 中文命令的想法是怎么來的從機械敲英文 slash 到順手的工作流先交代一下起因。我日常用 Claude Code 做編碼輔助一開始跟絕大多數(shù)人一樣把提示詞全寫成英文slash 命令也沿用默認的那幾個。用久了之后我發(fā)現(xiàn)兩件事第一同一個倉庫里的歷史項目、交接文檔、內(nèi)部術(shù)語混在一起每次啟動會話都要重新解釋“這個項目的目錄結(jié)構(gòu)是什么”“哪些文件是生成的”“測試該跑哪一條”上下文被大量重復述求占掉第二中文母語者在做代碼審查、提交信息、排障復盤時思維語言其實是中文硬要把提示詞轉(zhuǎn)成英文再喂給模型等于在思維和工具之間加了一道翻譯損耗。所以我決定做一件很樸素的事把這套 AI 編程工作流里反復用的動作打包成 10 個中文命令裝進 Claude Code 里。這里的“中文命令”不是指自定義 slash 命令的底層實現(xiàn)變成了中文而是命令的觸發(fā)詞、語義邏輯、輸出結(jié)構(gòu)全部圍繞中文使用場景設(shè)計。做完之后最直觀的感受是打字從/explain變成/解釋從/commit變成/提交從“先寫一段英文說明再貼代碼”變成直接“給我看看這段到底哪里有問題”。命令本身不復雜但整套工作流的體感完全是另一回事。如果你也在用 Claude Code 這類終端里的 AI 編程工具或者你在用 Codex、其他 AI 編程插件但一直覺得交互不夠貼合自己的習慣這篇文章可能正合適。我會把 10 個命令的掛載方式、命令文件內(nèi)容、前后串聯(lián)的邏輯、踩過的坑全部攤開講你照著做就能復現(xiàn)一套自己的中文工作流包。2. Claude Code 命令的掛載機制.claude/commands與全局命令的關(guān)系在開始列命令清單之前先把命令是怎么生效的講清楚。Claude Code 支持兩類自定義命令一類是放在項目目錄下的.claude/commands/文件夾里只對當前項目生效另一類是放在用戶全局目錄的~/.claude/commands/里對所有項目生效。命令文件就是普通的 Markdown 文件文件名去掉.md后綴之后就是你在對話里輸入的 slash 命令名。這個設(shè)計的好處在哪我舉個例子。我手頭有 A、B 兩個項目A 是后端 API 服務(wù)B 是前端后臺管理。A 項目里我可能需要一個/建表命令讓它根據(jù) model 定義生成數(shù)據(jù)庫遷移腳本B 項目里我更需要的是/接口命令讓它把后端 Swagger 文檔直接轉(zhuǎn)成前端請求函數(shù)。如果全部塞進全局命令兩個項目里都會出現(xiàn)一堆用不上的命令選擇成本反而變高。所以我的策略是全局命令放“所有項目都用得上的通用動作”/解釋、/補全、/重構(gòu)、/提交、/審查。項目命令放“跟當前代碼庫強相關(guān)的動作”/建表、/接口、/日志、/排障。剩下一個/測試我放在全局但命令文件里會根據(jù)當前項目自動探測測試框架后面細說。命令文件的頭信息是可選的我習慣在文件最上方保留一段 YAML 格式的描述用來寫這個命令是干什么的部分版本也支持在頭信息里聲明參數(shù)提示和可用工具。名字可以直接用中文文件名在終端里輸入/審查和/code 審查都能觸發(fā)我實測下來中文文件名在 zsh 和 bash 下都沒有兼容問題唯一要注意的是團隊協(xié)作時如果別人用 macOS 而你在 Windows 上提交文件文件名編碼最好保持 UTF-8。實際掛載步驟非常簡單# 全局命令目錄 mkdir -p ~/.claude/commands # 項目級命令目錄 mkdir -p .claude/commands # 查看當前已加載的命令 claude --list-commands這里有一個容易被忽略的坑命令文件名的前綴匹配是嚴格區(qū)分大小寫的。我一開始建了個Review.md又建了個review.md結(jié)果兩個文件同時存在時系統(tǒng)只認其中一個而且不報錯。后來我把命令名統(tǒng)一改成小寫拼音加中文描述才徹底避開這個歧義。命令名我選擇用小寫拼音比如shencha、buxian正文輸出全部中文這樣既保留中文語義又避免在某些終端環(huán)境里輸入中文斜杠命令時輸入法搶占焦點的問題。如果你不怕麻煩直接用中文文件名也可以但我在遠程服務(wù)器上通過 ssh 操作時遇到過中文輸入不進去的情況所以最終方案是拼音觸發(fā)詞。3. 十個命令背后的分工邏輯從補全到排障為什么是這十個一套工作流包不能貪多命令太多記不住等于沒用。我篩選命令的原則是“每天至少用一次、覆蓋編碼閉環(huán)的關(guān)鍵節(jié)點、命令之間可以串聯(lián)”。最終留下的十個命令大致分成三類。觸發(fā)詞文件位置作用典型場景/buxian全局補全當前文件中未實現(xiàn)的函數(shù)和 TODO寫了一半的代碼繼續(xù)填/jieshi全局解釋代碼片段或整個文件接手舊代碼、Code Review 前理解邏輯/chonggou全局小步重構(gòu)并給出測試建議函數(shù)太長、重復邏輯太多/shencha全局審查 git 改動并輸出風險清單提交前自查、MR 前檢查/ceshi全局根據(jù)上下文生成單測用例新功能落地后補測試/tijiao全局生成符合規(guī)范的中文提交信息每次 git commit/jiantab項目讀取 model 定義生成建表 SQL 或遷移文件后端加數(shù)據(jù)表/jiekou項目把接口文檔轉(zhuǎn)成前端調(diào)用函數(shù)前后端聯(lián)調(diào)階段/rizhi項目分析日志文件并給出異常鏈路排查線上報錯/paizhang項目針對當前報錯啟動多步排查流程本地環(huán)境問題定位我特意保留了“提交”這個反直覺的選項。很多人覺得 AI 生成 commit message 是小菜一碟但我實際用下來直接讓模型看git diff生成的信息經(jīng)常出現(xiàn)“改了什么文件”和“為什么這么改”兩層信息失真的問題。/tijiao命令在提示詞里明確要求模型先讀 diff再讀最近五條歷史提交信息模仿本倉庫已有的提交風格最后輸出一個不超過三行的中文提交信息。它不會自動執(zhí)行g(shù)it commit只把信息生成好放在那里我自己確認后再提交——這是我有意為之的邊界設(shè)計后面會展開說。3.1 日常編碼三件套補全、解釋、重構(gòu)/buxian是我用的最頻繁的一個命令。它做的事很簡單掃描當前文件的 TODO、pass、NotImplementedError、空函數(shù)體、以及明顯中斷的代碼塊逐個補全實現(xiàn)。真正讓它好用的是我在命令里加了幾條約束每次只補一個 TODO補全后必須給出“我改了什么”的摘要如果函數(shù)涉及外部服務(wù)調(diào)用需要先輸出依賴說明再輸出實現(xiàn)。如果是復雜項目還可以指定上下文文件。這個“逐個處理”的設(shè)定很關(guān)鍵如果一次讓它補十個地方模型容易在前幾處消耗大量上下文后面的補全質(zhì)量明顯下降。/jieshi則是一個“反向”命令。它不是讓 AI 寫代碼而是讓 AI 當解說員。這個命令對兩類場景特別值錢一是剛接手別人的代碼二是看自己兩個月前寫的代碼。命令提示詞里我寫了固定的輸出結(jié)構(gòu)先一句話概括這段代碼的職責再按執(zhí)行順序拆成列表解釋最后指出“如果我要改某個行為應(yīng)該關(guān)注哪幾行”。這個結(jié)構(gòu)不是憑空想的早期版本里我讓它“隨便解釋一下”結(jié)果它輸出一大段教科書式描述我根本抓不住重點。后來強制了輸出結(jié)構(gòu)價值立刻出來了。當你拿/jieshi去解釋一個文件它生成的往往不是代碼逐行翻譯而是把模塊之間的依賴和設(shè)計意圖梳理出來這個信息密度比讀注釋高很多。/chonggou的設(shè)計原則是“小步安全重構(gòu)”。提示詞里固定出現(xiàn)三個字“不要跳步”。我見過不少 AI 重構(gòu)翻車案例原因都是模型一次性給出一個完美但巨大的改動方案看起來很有道理實際上牽一發(fā)動全身。所以我的命令要求它先列出候選重構(gòu)點標出高風險項目然后一次只做一步每步后補上驗證命令編譯、測試或 lint。這個命令還強制要求模型在重構(gòu)前先調(diào)用 git 創(chuàng)建分支或至少確認當前工作區(qū)是干凈的。我把它和/ceshi串聯(lián)起來先重構(gòu)再補測試效果比單獨重構(gòu)穩(wěn)定很多。3.2 質(zhì)量把關(guān)四件套審查、測試、提交、排障/shencha是這十個命令里對我工作方式改變最大的一個。以前提交 MR 之前我要么自己肉眼過一遍 diff要么隨手寫一段英文讓 Claude 看常常丟三落四。現(xiàn)在/shencha的命令文件里寫死了執(zhí)行順序先拿到當前分支相對主分支的文件列表再逐個看 diff按“變更文件-變更摘要-風險點-建議”的格式輸出。它還會自動檢查有沒有把密鑰、日志路徑、調(diào)試代碼帶進提交。最實用的一個細節(jié)是命令里要求它給每個風險點標注嚴重程度分為“必須處理”“建議處理”“可以忽略”三級。這樣我在提交前只處理紅色級別的風險就夠了不會每個問題都停下來糾結(jié)。/ceshi是我反復調(diào)教最多次的命令。第一版提示詞太簡單它生成的測試用例經(jīng)常是“快樂路徑”所有異常分支全部沒覆蓋。后來我在命令里加入了被測文件上下文、現(xiàn)有測試風格示例、覆蓋率優(yōu)先級三部分。命令會先讀取項目中已有的一個測試文件作為風格模板再生成新用例。比如項目里已有 pytest 風格它不會給你生成 unittest 風格的東西。測試用例的數(shù)量我控制在“核心邏輯不少于三條正常輸入、邊界輸入、異常輸入”避免它一次生成五十條湊數(shù)。/tijiao前面說過了關(guān)鍵設(shè)計是不自動執(zhí)行 commit。同樣道理也用在/paizhang上。/paizhang是一個多步排查命令它的輸入通常是一個報錯信息也可能是日志中的異常堆棧。命令會強制模型走“復現(xiàn)-定位-假設(shè)-驗證-修復建議”五步流程尤其強調(diào)前面兩步。我遇到過太多次模型跳過復現(xiàn)直接給修復方案結(jié)果修復方案本身就有問題。有了五步流程之后它至少會在輸出里寫清楚“我在當前倉庫里找到了哪些線索”“哪些證據(jù)還不足”這個收斂感很重要。如果排查對象是本地環(huán)境問題它還會檢查依賴版本是否匹配。對了/paizhang和/rizhi經(jīng)常配合使用前者處理單個報錯后者做海量日志的異常鏈路分析。/rizhi單獨說一下。這個命令面向的不是實時終端而是項目里收集到的日志文件。命令會先讓用戶指定一個日志文件路徑或目錄然后掃描其中的 WARN、ERROR、Exception 關(guān)鍵詞把相關(guān)行按時間軸聚合再結(jié)合當前代碼庫里的源碼棧輸出錯誤鏈路的可能原因。我把這個命令放在項目級目錄因為只有具體項目才清楚自己的日志格式。我曾經(jīng)把它放在全局目錄結(jié)果命令面對不同項目五花八門的日志格式時不知所措后來挪到項目級再配合項目的CLAUDE.md里的日志規(guī)范說明準確率立刻上來了。3.3 工程協(xié)作兩件套建表、接口/jiantab和/jiekou是比較偏業(yè)務(wù)的命令適用范圍沒有前面幾個廣但在我參與的后端 API 服務(wù)項目和前端后臺項目里價值極高。/jiantab做的事情是讀取項目里已定義的 model 或?qū)嶓w類生成對應(yīng)的建表 SQL 或者 ORM 遷移文件。命令里最重要的提示是“先讀現(xiàn)有遷移文件的風格再生成新遷移”否則它生成的字段類型、命名規(guī)則、索引策略會跟項目歷史完全不搭。有過一次教訓后我還加了一條“如果 model 里沒有注釋不允許猜測字段含義必須輸出待確認項”。這一條治好了 AI 最致命的毛病——強行合理化。它不知道user_type到底是用戶類型還是用戶組類型時以前會靠上下文猜一個現(xiàn)在會直接問。/jiekou則是把后端接口文檔轉(zhuǎn)成前端可用的請求函數(shù)。它支持的輸入包括 OpenAPI 的 JSON/YAML 文件、Swagger 頁面復制過來的接口說明、甚至后端同事寫在文檔站里的 Markdown 版接口說明。命令會識別出接口的路徑、方法、參數(shù)、返回值然后結(jié)合前端項目里現(xiàn)有的請求封裝庫比如 axios 實例、攔截器生成對應(yīng)的 TypeScript 函數(shù)。這個命令最關(guān)鍵的一點是強行綁定現(xiàn)有封裝如果沒有讓它先讀src/api/request.ts它生成的代碼就像是自己造了一套網(wǎng)絡(luò)層既沒有統(tǒng)一攔截器也沒有錯誤處理。加上這個約束之后生成的代碼風格和手寫的一致到可以放進 code review。4. 把它們串成工作流一次從需求到合并的最小閉環(huán)單獨一個命令好用跟把它們串成一條工作流是兩種體驗。我現(xiàn)在的日常狀態(tài)基本上是一條命令鏈接到需求后先jieshi現(xiàn)有代碼定位改動位置然后手寫或讓buxian補全實現(xiàn)寫完跑一遍shencha自查必要時chonggou整理結(jié)構(gòu)再ceshi補單測最后tijiao生成提交信息。為什么這個順序很重要因為每一步的輸出都是下一步的輸入。shencha輸出的風險清單里如果有“這個函數(shù)復雜度太高”我會先執(zhí)行chonggou再補測試而不是先寫測試后重構(gòu)。重構(gòu)會改變行為嗎理論上不該改變但人寫的代碼和 AI 寫的代碼都可能出錯測試如果建立在重構(gòu)前的結(jié)構(gòu)上重構(gòu)后很可能要重寫一版。所以我的優(yōu)先級永遠是“結(jié)構(gòu)穩(wěn)定再補測試”。在聯(lián)調(diào)階段鏈路的組織換了一種方式。后端改完表結(jié)構(gòu)jiantab生成遷移文件前端拿到新接口文檔jiekou生成請求函數(shù)聯(lián)調(diào)報錯了rizhi分析后端日志paizhang處理單點異常。整個過程里我不需要反復把人話翻譯成英文指令中文命令直接對應(yīng)具體動作對于團隊里的初級工程師來說摸清這條鏈路的成本也低。我還有一個比較特殊的工作流是用 Claude Code 結(jié)合本地模型跑“輕量驗證”。項目在 VSCode 里配置好 Claude Code 之后我通常先用本地模型做第一輪代碼風格審查再用云端模型做深度重構(gòu)建議。這個做法有兩個好處一是高頻小動作不燒額度二是兩個模型交叉驗證能發(fā)現(xiàn)單一模型固定思路下的盲區(qū)。如果你也想這么搞可以先在 Claude Code 里配置好本地模型服務(wù)地址比如 LM Studio 啟動的本地 API把第一輪審查命令指向它。我實際體驗下來本地模型對中文命令的理解也很穩(wěn)定畢竟命令文件里的提示詞是完整的中文文本不依賴模型的英文能力。當然如果你沒有本地模型的條件這個環(huán)節(jié)完全可以跳過不影響主流程。5. 實現(xiàn)過程中踩過的坑與適配方案命令不是越多越好而是越收斂越好這十個命令不是一次性設(shè)計出來的期間我踩了不少坑有些坑可能你也正在踩。第一個坑是上下文爆炸。早期我把大量項目背景寫進全局命令結(jié)果每個命令文件動輒三四百行每次調(diào)用都要消耗大量上下文。比如/chonggou里我塞了項目編碼規(guī)范、目錄結(jié)構(gòu)、禁止事項看起來面面俱到實際上模型在處理重構(gòu)任務(wù)時根本用不上那么多背景反而因為上下文太長對核心代碼的關(guān)注度下降了。解決方案是收斂全局命令只放“跟語言無關(guān)的動作指令輸出格式約束”項目背景交給項目的CLAUDE.md文件去管命令里的提示詞保持在 100 到 200 行以內(nèi)。命令和記憶文件各管一攤這條邊界越清楚整體效果越好。第二個坑是命令文件的版本失控。當命令文件進入 git 倉庫后團隊成員會各自修改。有人喜歡加語氣詞“請”有人改成命令句式改來改去最終文件被改得面目全非某些人本地的行為跟倉庫里的行為對不上。我現(xiàn)在的做法是命令文件一進倉庫就設(shè)為只讀所有修改必須走 MR并且在命令文件頭部寫一行注釋說明這個文件由誰維護。有人覺得這樣太重了但對一個多人協(xié)作超過三個人的項目來說這種克制能避免大量莫名其妙的“為什么我本地沒有這個效果”的問題。第三個坑是輸出結(jié)構(gòu)沒有強制化。這是我最想提醒的一點。Claude Code 這類工具默認行為是讓模型自由發(fā)揮但如果一個命令每次調(diào)用的輸出格式都不一樣你就沒法在這個命令之上再做自動化。比如/shencha如果一會兒輸出 JSON 格式的風險清單一會兒輸出散文式的審查報告你就無法在命令結(jié)果后面接其他處理。我的做法是每個命令文件都定義明確的輸出段落標題例如/paizhang固定輸出“1. 復現(xiàn)步驟 2. 定位依據(jù) 3. 假設(shè)列表 4. 驗證命令 5. 修復建議”。這些段落標題本身就是要喂給下一步處理的結(jié)構(gòu)化錨點。第四個坑藏在命令觸發(fā)詞與輸入法沖突里。在終端里用中文輸入斜杠命令會碰到輸入法狀態(tài)切換的問題。你敲完/之后如果輸入法還在中文模式后面的拼音會被直接輸入為英文字母命令可能觸發(fā)失敗。我改成拼音觸發(fā)詞之后這個問題就消失了但我們團隊里也有人更喜歡英文觸發(fā)詞。我建議你在命名時提前統(tǒng)一策略要么全中文、要么全拼音、要么全英文別混著來否則記憶成本會急劇上升。如果你把命令文件放進項目倉庫還要考慮 CI 工具在非交互環(huán)境下掃描.claude/commands時對中文文件名的兼容性部分自動化流程里中文文件名會帶來不必要的編碼問題。第五個坑是你以為給了上下文其實沒給到位。/jiekou早期版本在生成前端請求函數(shù)時經(jīng)常寫出跟項目封裝不一致的代碼。我以為它“知道”項目里有個request.ts但實際上我沒有在命令文件里明確說“先讀 src/api/request.ts”。在 AI 編程工具里上下文不是默認共享的而是需要顯式指路的。所謂的指路有兩種方式一種是在CLAUDE.md里寫好模塊地圖一種是命令文件里直接要求模型先讀取目標文件。我兩種方式都用了效果最好的是雙管齊下。命令開始時的第一句話往往是“先讀取以下文件之后再繼續(xù)”這句話的輸出順序要非?？壳胺駝t模型可能在讀了目標文件之前就開始生成代碼。第六個坑跟安全邊界有關(guān)。很多 AI 編程工作流包喜歡讓 AI 自動執(zhí)行g(shù)it commit、git push這些操作。我不反對自動化但我的命令設(shè)計原則是高風險動作一律半自動。/tijiao只生成信息不跑 commit/chonggou只改代碼不動 git/shencha只輸出結(jié)論不直接改代碼。原因很簡單AI 執(zhí)行代碼改動時如果改動范圍超過預期你至少要在 commit 這一步停下來看一眼。把最后一道閘門握在自己手里整個工作流包的風險會小一個量級。這套“半自動”理念后來也被我用在其他工具鏈上比如 CI 配置、依賴升級腳本都保留了人工確認步驟。6. 從命令包到個人工作流的遷移建議這套東西搭好之后下一步自然是想把它遷移到其他項目、其他機器上去。如果你也想搭一套自己的中文命令包我建議你按下面的路徑來而不是一上來就復制我的命令文件。先盤點自己一周內(nèi)重復最多的十個動作。用 Claude Code 的人打開終端敲/的時候心里大概都有數(shù)哪些指令是高頻的是“解釋這段代碼”還是“幫我寫測試”是“看下日志”還是“生成提交信息”不要把別人清單里的命令硬搬過來每個團隊、每個項目的痛點不一樣。我這份清單里的/jiantab和/jiekou就是明顯偏后端業(yè)務(wù)的項目命令你如果是純前端項目可能更需要一個/樣式命令或/狀態(tài)命令。第二步是區(qū)分全局命令和項目命令。判斷標準很簡單這個命令換一個項目還能用嗎如果答案是“能”放全局如果答案是“不能得結(jié)合這個項目的技術(shù)棧才行”放項目目錄。我剛開始時幾乎把全部命令都塞在全局用了兩周后發(fā)現(xiàn)一半命令在某個項目里完全沒有調(diào)用過白白占掉命令列表的展示空間。全局命令控制十個以內(nèi)是比較舒服的上限再多選擇成本就高過收益了。第三步是為每個命令寫“不可違背的邊界”。這里的邊界分兩種一是動作邊界比如“永遠不要在執(zhí)行前就修改文件”“永遠不要自動 push”二是輸出邊界比如“所有風險點必須標注嚴重級別”“所有解釋必須先給結(jié)論再給細節(jié)”。這些邊界用兩三行就能寫完但它們決定了工具是“可用”還是“好用”。最后命令文件要當成代碼去維護。我見過很多人把~/.claude/commands當存放草稿的文件夾想起來就新建一個命令過期了隨手刪掉從來不進版本庫。我的建議是每一個命令文件都進 git 倉庫單獨放在一個claude-commands/目錄下通過軟鏈接或者是部署腳本同步到.claude/commands。這樣換新機器、拉新項目、團隊協(xié)作都有一條確定的同步鏈路。我的做法是在~/.claude/commands全局目錄里放一個README.md記錄每個命令的觸發(fā)詞、維護人、最近修改時間這個 README 本身就是一個命令索引幫我快速回憶起每個命令細節(jié)。如果還要說一點個人體會我想說這類中文工作流包真正的價值不在于命令數(shù)量而在于你終于把“跟 AI 對話的套路”沉淀成了可重復使用的資產(chǎn)。以前我每次打開 Claude Code 都要重新組織語言現(xiàn)在十個命令一放大部分對話都是一句話觸發(fā)剩下的精力集中在真正需要思考的設(shè)計決策上。那種“工具在順從你的習慣而不是你在遷就工具”的感覺用久了就回不去了。