1. 為什么我要給 AI 編程助手做一套中文命令包用 AI 編程助手寫代碼這件事我從它剛能補(bǔ)全函數(shù)的時(shí)候就開始了。一路用下來最大的感受不是模型不夠聰明而是溝通成本高得離譜。你腦子里想的是幫我把這個(gè)模塊的邊界條件補(bǔ)全順便把異常處理統(tǒng)一一下手上敲出來的卻是一段又長又啰嗦的提示詞等它回你一大段代碼你還得逐行核對(duì)它有沒有理解偏。來來回回幾次寫代碼的節(jié)奏全被打斷了。后來我注意到一個(gè)現(xiàn)象這些 AI 編程工具其實(shí)都支持一種叫自定義命令或者斜杠命令的機(jī)制。你可以把一段固定的、反復(fù)要用的提示詞封裝成一個(gè)短命令比如輸入/review就自動(dòng)觸發(fā)一套代碼審查流程。這個(gè)機(jī)制本來是給英文用戶設(shè)計(jì)的命令名、參數(shù)說明、觸發(fā)詞全是英文。但問題是我日常思考用的是中文我描述需求、判斷代碼好壞、跟同事討論方案腦子里跑的都是中文。每次還要先把中文需求翻譯成英文提示詞再喂給工具這個(gè)中間層特別消耗精力。于是我就想能不能干脆做一套純中文的命令包把我在日常開發(fā)里最高頻的十來個(gè)操作全部封裝成中文命令。比如/補(bǔ)全、/審查、/重構(gòu)、/寫測試、/解釋、/優(yōu)化、/查錯(cuò)、/文檔、/提交、/拆解。這樣我只要敲兩個(gè)中文字AI 就知道我要干什么而且提示詞里已經(jīng)內(nèi)置了我多年積累的怎么問才問得準(zhǔn)的經(jīng)驗(yàn)。這套東西做出來之后我的開發(fā)流確實(shí)變了。以前是想需求 → 組織英文提示詞 → 等結(jié)果 → 反復(fù)調(diào)整現(xiàn)在是想需求 → 敲中文命令 → 拿結(jié)果。中間那層翻譯和措辭的負(fù)擔(dān)被徹底拿掉了。這篇文章我就把這套中文命令包的設(shè)計(jì)思路、每個(gè)命令背后的提示詞工程、以及實(shí)際用下來踩過的坑完整地拆給你看。不管你是剛接觸 AI 編程的新手還是已經(jīng)用了一陣子但覺得效率卡在瓶頸的老手這套思路都能直接抄去改。2. 中文命令包的整體設(shè)計(jì)與選型考量2.1 為什么是命令包而不是提示詞模板很多人做 AI 編程提效第一反應(yīng)是搞一個(gè)提示詞模板文檔用的時(shí)候復(fù)制粘貼。我一開始也這么干但很快就放棄了。原因有三個(gè)。第一復(fù)制粘貼有摩擦。你正在編輯器里寫代碼手不離鍵盤這時(shí)候要去另一個(gè)文檔里找模板、選中、復(fù)制、切回來、粘貼、再改參數(shù)這一套動(dòng)作下來至少十幾秒而且打斷了心流。命令包是直接在對(duì)話框里敲兩個(gè)字符就能觸發(fā)的摩擦幾乎為零。第二模板容易過期。你把提示詞存在文檔里改了一版又一版最后自己都分不清哪個(gè)是最新的。命令包是文件形式存在的每個(gè)命令一個(gè)文件改完即生效版本清晰。第三模板沒法帶參數(shù)。好的提示詞往往需要根據(jù)上下文變化比如審查這段代碼重點(diǎn)看并發(fā)安全。命令包支持參數(shù)傳遞你可以/審查 并發(fā)安全把關(guān)注點(diǎn)作為參數(shù)傳進(jìn)去提示詞會(huì)自動(dòng)拼接。模板做不到這一點(diǎn)你只能手動(dòng)改。所以選命令包這個(gè)形態(tài)本質(zhì)上是為了降低觸發(fā)成本和支持參數(shù)化。這兩點(diǎn)決定了它能不能真正融入日常流而不是變成一個(gè)偶爾想起來才用的擺設(shè)。2.2 十個(gè)命令是怎么選出來的我沒有一上來就設(shè)計(jì)十個(gè)命令而是先觀察了自己兩周的開發(fā)行為把我反復(fù)讓 AI 做的事列了個(gè)清單然后按頻率排序取前十個(gè)。這個(gè)清單大概是這樣的高頻操作出現(xiàn)頻率是否封裝讓 AI 解釋一段看不懂的代碼極高是/解釋讓 AI 補(bǔ)全或生成函數(shù)極高是/補(bǔ)全讓 AI 審查代碼找問題高是/審查讓 AI 寫單元測試高是/寫測試讓 AI 重構(gòu)一段爛代碼高是/重構(gòu)讓 AI 排查報(bào)錯(cuò)高是/查錯(cuò)讓 AI 優(yōu)化性能中是/優(yōu)化讓 AI 生成注釋和文檔中是/文檔讓 AI 生成提交信息中是/提交讓 AI 把大任務(wù)拆成小步驟中是/拆解這十個(gè)命令覆蓋了從讀代碼到寫代碼到改代碼到交付代碼的完整鏈路。你會(huì)發(fā)現(xiàn)它們不是隨便湊的而是沿著一條真實(shí)的開發(fā)流水線排布的。早上來先/解釋一段昨天沒看懂的代碼然后/補(bǔ)全新功能寫完/審查一遍/寫測試補(bǔ)覆蓋/重構(gòu)清理結(jié)構(gòu)/優(yōu)化處理性能瓶頸/文檔補(bǔ)注釋最后/提交生成規(guī)范的提交信息。如果任務(wù)太大先用/拆解分步。這條鏈路走下來基本就是一個(gè)完整的開發(fā)循環(huán)。2.3 命令命名為什么用中文而不是拼音或英文縮寫這一點(diǎn)我想重點(diǎn)說一下因?yàn)楹芏嗳藭?huì)糾結(jié)。我的結(jié)論很明確用中文不要用拼音也不要用英文縮寫。用拼音的問題是/buchong和/chonggou這種你敲的時(shí)候要在腦子里做一次中文→拼音的轉(zhuǎn)換而且拼音沒有語義看命令列表的時(shí)候反應(yīng)慢。用英文縮寫的問題是/exp、/ref、/opt這種你得記住每個(gè)縮寫對(duì)應(yīng)什么學(xué)習(xí)成本高而且容易和工具自帶的英文命令混淆。用中文的好處是零轉(zhuǎn)換成本。你腦子里想補(bǔ)全手上就敲/補(bǔ)全中間沒有任何映射。而且中文命令自帶語義你打開命令列表掃一眼就知道每個(gè)是干嘛的不需要記憶。實(shí)測下來中文命令的肌肉記憶形成速度比英文快得多大概用兩三天就能盲敲了。提示如果你的工具對(duì)中文命令名支持不好比如某些版本對(duì)非 ASCII 字符處理有 bug可以退而求其次用中文拼音首字母比如/bc補(bǔ)全、/sc審查。但優(yōu)先還是試中文大部分現(xiàn)代工具都沒問題。2.4 提示詞工程的核心原則命令包的外殼是命令名內(nèi)核是提示詞。這十個(gè)命令的提示詞我反復(fù)打磨了很多輪總結(jié)出四條原則后面每個(gè)命令都會(huì)體現(xiàn)。原則一角色前置。每個(gè)提示詞開頭都明確 AI 要扮演什么角色。/審查開頭是你是一位嚴(yán)格的代碼審查者/重構(gòu)開頭是你是一位注重可讀性的重構(gòu)專家。角色決定了 AI 的輸出風(fēng)格和關(guān)注點(diǎn)不寫角色AI 就會(huì)用那種四平八穩(wěn)的通用口吻出來的東西沒針對(duì)性。原則二約束輸出格式。不約束格式AI 就會(huì)寫一大段散文你還得自己從里面挑重點(diǎn)。我在每個(gè)命令里都規(guī)定了輸出結(jié)構(gòu)比如/審查要求按嚴(yán)重問題 / 建議改進(jìn) / 可選優(yōu)化三檔分類/寫測試要求先列測試用例清單再寫代碼。格式約束讓輸出可以直接用不用二次加工。原則三內(nèi)置領(lǐng)域經(jīng)驗(yàn)。這是最值錢的部分。比如/審查里我內(nèi)置了重點(diǎn)檢查空指針、邊界條件、并發(fā)安全、資源泄漏、錯(cuò)誤處理這幾個(gè)我踩過坑的點(diǎn)。AI 拿到這個(gè)清單就會(huì)逐項(xiàng)檢查而不是泛泛地說代碼看起來不錯(cuò)。這些經(jīng)驗(yàn)是命令包的靈魂也是它比通用提示詞強(qiáng)的地方。原則四留參數(shù)口子。每個(gè)命令都支持一個(gè)可選參數(shù)用來傳遞本次的特殊關(guān)注點(diǎn)。/審查 并發(fā)安全會(huì)讓 AI 重點(diǎn)看并發(fā)/優(yōu)化 內(nèi)存會(huì)讓 AI 聚焦內(nèi)存優(yōu)化。參數(shù)讓固定命令有了靈活性。3. 十個(gè)中文命令的逐個(gè)拆解與實(shí)操要點(diǎn)3.1 /解釋把看不懂的代碼講成人話/解釋是我用得最多的命令沒有之一。接手老項(xiàng)目、看開源庫、讀同事寫的復(fù)雜邏輯全靠它。提示詞的核心結(jié)構(gòu)是這樣的先讓 AI 判斷這段代碼的整體意圖再逐段拆解關(guān)鍵邏輯最后指出這段代碼里最容易被誤解的地方。第三步是我特意加的因?yàn)楹芏鄷r(shí)候代碼本身不難難的是它為什么這么寫。比如一段看起來多余的判空背后可能是某個(gè)歷史 bug 的規(guī)避。讓 AI 主動(dòng)指出這些反直覺點(diǎn)能幫你快速建立對(duì)代碼的信任感。實(shí)操的時(shí)候有個(gè)技巧不要一次貼幾百行。AI 的注意力是有限的代碼太長它會(huì)抓不住重點(diǎn)。我的做法是按函數(shù)或按邏輯塊貼一次控制在 50 行以內(nèi)。如果確實(shí)要看一個(gè)大文件先用/拆解讓它把文件結(jié)構(gòu)理出來再逐個(gè)函數(shù)/解釋。注意/解釋的輸出里AI 有時(shí)會(huì)腦補(bǔ)一些代碼里沒有的意圖。看到它說這里是為了處理 XX 情況的時(shí)候如果代碼里沒有對(duì)應(yīng)的注釋或測試最好自己再確認(rèn)一下。AI 的解釋是幫你理解不是替你判斷。3.2 /補(bǔ)全從注釋或簽名生成實(shí)現(xiàn)/補(bǔ)全的用法是你寫好函數(shù)簽名和一段描述性注釋然后敲/補(bǔ)全AI 根據(jù)簽名和注釋生成實(shí)現(xiàn)。這個(gè)命令的提示詞里我強(qiáng)制要求 AI 做三件事第一先復(fù)述一遍它理解的函數(shù)職責(zé)確認(rèn)沒跑偏第二生成實(shí)現(xiàn)第三列出它做的假設(shè)。第三步特別重要。比如你寫了個(gè)parseConfig(path)AI 可能會(huì)假設(shè)文件不存在時(shí)拋異常也可能假設(shè)返回空配置。這兩種假設(shè)對(duì)應(yīng)完全不同的調(diào)用方處理邏輯。讓它把假設(shè)列出來你一眼就能看出它有沒有理解錯(cuò)。實(shí)操心得注釋寫得越具體補(bǔ)全質(zhì)量越高。不要寫解析配置要寫讀取指定路徑的配置文件支持 JSON 和 YAML 兩種格式文件不存在時(shí)返回空配置對(duì)象格式錯(cuò)誤時(shí)拋出帶行號(hào)的異常。你給的信息越足AI 猜的空間越小出來的代碼越接近你要的。3.3 /審查像資深工程師一樣挑刺/審查是我認(rèn)為最能體現(xiàn)命令包價(jià)值的一個(gè)。因?yàn)榇a審查這件事新手和老手的差距不在能不能看出問題而在知道該看哪些地方。老手腦子里有一張檢查清單新手沒有。/審查就是把這張清單固化下來。我的提示詞里內(nèi)置的檢查清單包括空值和邊界條件、并發(fā)與競態(tài)、資源釋放文件句柄、連接、鎖、錯(cuò)誤處理是否吞異常、輸入校驗(yàn)、日志是否泄露敏感信息、命名是否誤導(dǎo)、是否有重復(fù)邏輯可以抽取。AI 會(huì)按這個(gè)清單逐項(xiàng)過輸出分三檔嚴(yán)重問題必須改可能導(dǎo)致 bug 或安全問題、建議改進(jìn)改了更好不改也能跑、可選優(yōu)化風(fēng)格層面。這里有個(gè)反直覺的經(jīng)驗(yàn)不要讓 AI 一次審查太多代碼。我試過貼一個(gè) 300 行的文件讓它審結(jié)果它只挑了表面問題深層的邏輯漏洞全漏了。后來我改成按函數(shù)審每個(gè)函數(shù)單獨(dú)/審查問題檢出率明顯提升。原因是 AI 的審查注意力也是有限的代碼越長它越傾向于走馬觀花。3.4 /寫測試先列用例再寫代碼/寫測試的提示詞結(jié)構(gòu)是先分析被測函數(shù)的輸入空間和邊界列出測試用例清單正常路徑、邊界值、異常路徑、并發(fā)場景然后逐個(gè)用例寫測試代碼。為什么先列清單因?yàn)闇y試的質(zhì)量取決于用例設(shè)計(jì)而不是代碼寫法。很多人讓 AI 寫測試AI 直接給一堆a(bǔ)ssert看著挺多但全是正常路徑邊界和異常一個(gè)沒覆蓋。先讓它列清單你就能看出它有沒有想到邊界情況。如果清單不全你可以補(bǔ)充還要測空輸入和超大輸入再讓它寫代碼。實(shí)操技巧寫完之后讓 AI 自己跑一遍變異測試的思路——如果我把被測函數(shù)里的某個(gè)條件反過來你的哪個(gè)測試會(huì)失敗如果它答不上來說明那個(gè)條件沒被覆蓋到。這個(gè)方法能快速找出測試的盲區(qū)。3.5 /重構(gòu)在保持行為不變的前提下改善結(jié)構(gòu)/重構(gòu)的提示詞里我加了一條硬約束重構(gòu)后的代碼必須保持外部行為完全不變。AI 會(huì)先說明它打算怎么改提取函數(shù)、消除重復(fù)、簡化條件、替換魔法數(shù)字等改完之后列出行為不變性說明逐條解釋為什么改完還是原來的行為。這條約束很關(guān)鍵。不加的話AI 經(jīng)常借著重構(gòu)的名義偷偷改邏輯比如把改成把異常改成返回默認(rèn)值。這些改動(dòng)在重構(gòu)里是絕對(duì)不允許的因?yàn)樗鼈兏淖兞诵袨?。有了行為不變性說明你就能快速核對(duì)它有沒有越界。提示重構(gòu)前一定要有測試覆蓋。沒有測試的重構(gòu)就是賭博。如果這段代碼沒測試先/寫測試補(bǔ)上再/重構(gòu)。這個(gè)順序不能反。3.6 /查錯(cuò)從報(bào)錯(cuò)信息反推根因/查錯(cuò)的輸入是報(bào)錯(cuò)信息加相關(guān)代碼。提示詞要求 AI 做四步第一翻譯報(bào)錯(cuò)信息的字面含義第二列出可能導(dǎo)致這個(gè)報(bào)錯(cuò)的三種原因按可能性排序第三針對(duì)最可能的原因給出驗(yàn)證方法第四給出修復(fù)方案。第三步驗(yàn)證方法是精髓。很多人拿到報(bào)錯(cuò)直接讓 AI 給修復(fù)代碼結(jié)果改了半天發(fā)現(xiàn)根因在別處。讓 AI 先給驗(yàn)證方法你花一分鐘驗(yàn)證一下確認(rèn)根因再改能省下大量瞎改的時(shí)間。比如它說最可能是空指針你在這行加個(gè)打印看看對(duì)象是不是 null你驗(yàn)證一下是就改不是就換下一個(gè)原因。3.7 /優(yōu)化先測量再優(yōu)化/優(yōu)化的提示詞里我強(qiáng)制要求 AI 先問一句你測量過瓶頸在哪里嗎。如果我沒提供性能數(shù)據(jù)它會(huì)拒絕直接優(yōu)化而是建議我先加埋點(diǎn)測量。這個(gè)設(shè)計(jì)是刻意的因?yàn)闆]有測量的優(yōu)化都是瞎猜。我見過太多人憑感覺優(yōu)化把一段根本不熱的代碼改得面目全非真正的瓶頸還在那兒。如果你提供了性能數(shù)據(jù)比如這個(gè)函數(shù)占了 60% 的 CPU 時(shí)間AI 就會(huì)針對(duì)性地給優(yōu)化方案并且每個(gè)方案都標(biāo)注預(yù)期收益和引入的復(fù)雜度。你可以根據(jù)收益/復(fù)雜度比來決定做哪個(gè)。3.8 /文檔生成能看懂的注釋/文檔生成的不是那種函數(shù)名復(fù)讀機(jī)式的注釋比如// 獲取用戶配getUser()而是解釋為什么的注釋。提示詞要求 AI 說明這個(gè)函數(shù)解決什么問題、有什么非顯而易見的約束、調(diào)用時(shí)要注意什么、有沒有副作用。我特別要求它不要注釋那些一眼就能看懂的代碼。注釋是稀缺資源滿屏注釋等于沒注釋。只注釋那些看代碼看不出來的信息比如這里必須用 因?yàn)檫吔缡情]區(qū)間、這個(gè)鎖的順序不能反否則會(huì)死鎖。3.9 /提交生成規(guī)范的提交信息/提交會(huì)讀取當(dāng)前的改動(dòng)生成符合約定式提交Conventional Commits格式的信息比如feat: 增加配置解析的 YAML 支持。提示詞要求它區(qū)分改動(dòng)類型feat/fix/refactor/test/docs/chore并且正文里說明為什么改而不只是改了什么。實(shí)操技巧如果一次改動(dòng)包含多個(gè)不相關(guān)的修改/提交會(huì)建議你拆成多個(gè)提交。這個(gè)建議很有價(jià)值因?yàn)橐粋€(gè)提交只做一件事回滾和 review 都方便。3.10 /拆解把大任務(wù)切成可執(zhí)行的小步/拆解的輸入是一個(gè)模糊的大需求比如給項(xiàng)目加個(gè)用戶認(rèn)證。提示詞要求 AI 輸出一個(gè)分步驟的計(jì)劃每步都是可獨(dú)立驗(yàn)證的——做完這步你能明確知道它對(duì)不對(duì)。并且標(biāo)注每步的依賴關(guān)系和預(yù)估復(fù)雜度。這個(gè)命令的價(jià)值在于把不知道從哪下手變成照著清單做。大任務(wù)最怕的就是一團(tuán)亂麻拆解之后每一步都清晰了執(zhí)行起來心理負(fù)擔(dān)小很多。4. 命令包的落地實(shí)現(xiàn)與配置細(xì)節(jié)4.1 命令文件的目錄結(jié)構(gòu)大部分支持自定義命令的 AI 編程工具都是從一個(gè)約定目錄讀取命令文件的。常見的結(jié)構(gòu)是這樣項(xiàng)目根目錄/ .ai-commands/ # 命令目錄具體名字看工具約定 explain.md # /解釋 complete.md # /補(bǔ)全 review.md # /審查 test.md # /寫測試 refactor.md # /重構(gòu) debug.md # /查錯(cuò) optimize.md # /優(yōu)化 document.md # /文檔 commit.md # /提交 breakdown.md # /拆解每個(gè).md文件就是一個(gè)命令。文件內(nèi)容分兩部分頭部是元信息命令名、描述、參數(shù)說明下面是提示詞正文。不同工具的元信息格式不一樣有的是 YAML front matter有的是特定注釋語法你需要查一下自己工具的文檔。但提示詞正文部分是通用的換工具也能用。4.2 一個(gè)完整命令文件的寫法拿/審查舉例一個(gè)完整的命令文件大概長這樣--- name: 審查 description: 對(duì)代碼進(jìn)行嚴(yán)格審查按嚴(yán)重程度分類輸出問題 argument: 可選本次審查的重點(diǎn)關(guān)注方向 --- 你是一位嚴(yán)格的代碼審查者有十年以上一線開發(fā)經(jīng)驗(yàn)。 請(qǐng)審查以下代碼重點(diǎn)關(guān)注空值和邊界條件、并發(fā)與競態(tài)、 資源釋放、錯(cuò)誤處理、輸入校驗(yàn)、日志安全、命名準(zhǔn)確性、重復(fù)邏輯。 如果用戶指定了關(guān)注方向$ARGUMENT請(qǐng)優(yōu)先深入檢查該方向。 輸出格式 1. 嚴(yán)重問題必須修改可能導(dǎo)致 bug 或安全問題 2. 建議改進(jìn)改了更好不改也能運(yùn)行 3. 可選優(yōu)化風(fēng)格和可讀性層面 每個(gè)問題請(qǐng)給出問題位置、問題說明、修改建議。 不要泛泛而談每個(gè)結(jié)論都要有代碼依據(jù)。 待審查代碼 $SELECTION這里的$ARGUMENT是參數(shù)占位符$SELECTION是當(dāng)前選中的代碼占位符。不同工具的占位符語法不同但思路是一樣的把用戶輸入和上下文注入到提示詞里。4.3 參數(shù)傳遞的實(shí)操細(xì)節(jié)參數(shù)傳遞看起來簡單實(shí)際用起來有幾個(gè)坑。第一個(gè)坑是參數(shù)為空時(shí)的處理。如果用戶敲/審查不帶參數(shù)$ARGUMENT就是空字符串提示詞里那句如果用戶指定了關(guān)注方向就會(huì)變成如果用戶指定了關(guān)注方向讀起來很怪。解決辦法是在提示詞里寫清楚如果參數(shù)為空則忽略此條或者用工具的條件語法處理。第二個(gè)坑是參數(shù)里的空格。/審查 并發(fā) 安全和/審查 并發(fā)安全在有些工具里解析結(jié)果不一樣。前者可能被當(dāng)成兩個(gè)參數(shù)后者是一個(gè)。我的建議是參數(shù)盡量用連字符或下劃線連接比如/審查 并發(fā)-安全避免歧義。第三個(gè)坑是參數(shù)注入提示詞的位置。參數(shù)放在提示詞開頭還是結(jié)尾效果不一樣。我實(shí)測下來放在關(guān)注方向這種明確的位置效果最好放在最后容易被 AI 忽略。4.4 跨工具遷移的注意事項(xiàng)這套命令包我先后在幾個(gè)不同的 AI 編程工具上用過遷移的時(shí)候有幾個(gè)點(diǎn)要注意。占位符語法不同。有的工具用$SELECTION有的用{{selection}}有的用selection。遷移的時(shí)候要全局替換。命令觸發(fā)方式不同。有的工具在對(duì)話框敲/觸發(fā)有的用快捷鍵喚起命令面板。這個(gè)影響不大習(xí)慣就好。上下文注入范圍不同。有的工具會(huì)自動(dòng)把當(dāng)前打開的文件作為上下文有的只注入你選中的部分。這個(gè)要搞清楚否則會(huì)出現(xiàn)AI 看不到我想要的代碼的情況。中文支持程度不同。大部分工具對(duì)中文命令名支持良好但個(gè)別工具在命令列表展示時(shí)會(huì)有編碼問題。如果遇到可以給命令加一個(gè)英文別名兩個(gè)都能觸發(fā)。提示遷移之前先把命令文件里的工具特定語法抽出來做成一個(gè)適配層。比如把占位符統(tǒng)一寫成{{SELECTION}}然后寫個(gè)小腳本在部署時(shí)替換成目標(biāo)工具的語法。這樣換工具只需要改腳本不用改十個(gè)命令文件。5. 常見問題與排查技巧實(shí)錄5.1 命令不觸發(fā)或觸發(fā)錯(cuò)誤最常見的問題是敲了命令沒反應(yīng)。排查順序是這樣的先確認(rèn)命令文件在正確的目錄下文件名和命令名對(duì)得上再確認(rèn)文件格式正確元信息沒有語法錯(cuò)誤最后確認(rèn)工具版本支持自定義命令這個(gè)功能。我遇到過好幾次是文件放錯(cuò)了目錄工具根本掃不到。還有一個(gè)隱蔽的問題是命令名沖突。如果你自定義了/解釋而工具本身也有個(gè)/explain一般不會(huì)沖突。但如果工具本身就有中文命令就可能撞車。解決辦法是給自定義命令加個(gè)前綴比如/x解釋。5.2 AI 輸出不符合預(yù)期格式有時(shí)候你明明在提示詞里規(guī)定了輸出格式AI 還是給你寫一大段散文。原因通常是格式約束寫得太靠后被前面的內(nèi)容淹沒了。解決辦法是把格式約束提到提示詞靠前的位置并且用明確的標(biāo)記比如輸出必須嚴(yán)格遵循以下格式不要添加額外說明。另一個(gè)原因是格式約束太復(fù)雜。如果你規(guī)定了五層嵌套的結(jié)構(gòu)AI 很容易亂。建議格式控制在兩層以內(nèi)用列表或簡單表格。5.3 中文命令在某些場景下識(shí)別不準(zhǔn)極少數(shù)情況下AI 會(huì)把中文命令名當(dāng)成普通文本處理而不是觸發(fā)命令。這通常發(fā)生在命令名和正文連在一起的時(shí)候比如/解釋這段代碼中間沒空格。解決辦法是命令名后面加個(gè)空格/解釋 這段代碼。如果問題持續(xù)檢查一下工具的輸入解析邏輯看它是不是對(duì)中文字符的邊界判斷有問題。實(shí)在不行就換成拼音首字母命令。5.4 提示詞效果隨時(shí)間衰減這是個(gè)容易被忽略的問題。你精心調(diào)好的提示詞用了一段時(shí)間后發(fā)現(xiàn)效果變差了。原因可能是模型更新了新版本對(duì)提示詞的響應(yīng)方式變了。這時(shí)候不要急著大改先做小范圍測試看是哪個(gè)部分失效了針對(duì)性調(diào)整。我的做法是給每個(gè)命令文件加一個(gè)版本和最后驗(yàn)證日期的元信息每隔一兩個(gè)月重新驗(yàn)證一遍確保效果穩(wěn)定。5.5 常見問題速查表現(xiàn)象可能原因排查方法命令不觸發(fā)文件位置錯(cuò)誤 / 格式錯(cuò)誤檢查目錄和元信息語法輸出格式亂格式約束太靠后或太復(fù)雜前置格式約束簡化結(jié)構(gòu)中文識(shí)別不準(zhǔn)命令名和正文粘連命令名后加空格效果變差模型更新導(dǎo)致提示詞失效小范圍測試定位失效部分參數(shù)不生效占位符語法錯(cuò)誤核對(duì)工具的占位符規(guī)范上下文缺失工具注入范圍不符預(yù)期確認(rèn)選中范圍或手動(dòng)粘貼5.6 幾條踩坑換來的經(jīng)驗(yàn)第一命令不要貪多。我一開始設(shè)計(jì)了二十多個(gè)命令結(jié)果自己都記不住常用的還是那五六個(gè)。后來砍到十個(gè)每個(gè)都高頻使用反而效率更高。命令包的價(jià)值在于常用不在于全。第二提示詞要定期回爐。我每個(gè)月會(huì)挑一兩個(gè)命令看看最近的輸出質(zhì)量如果發(fā)現(xiàn) AI 開始偷懶輸出變短、變泛就回去加強(qiáng)提示詞里的約束。第三保留一個(gè)萬能命令。除了這十個(gè)專用命令我還留了一個(gè)/問就是把我輸入的內(nèi)容原樣發(fā)給 AI不做任何包裝。遇到十個(gè)命令都覆蓋不了的場景用/問兜底。第四把命令包納入版本管理。這些命令文件是你的提示詞資產(chǎn)值得用 Git 管起來。每次調(diào)整都提交出問題能回滾也能看到自己的提示詞是怎么一步步演化的。這套中文命令包用下來最大的感受是AI 編程的效率瓶頸往往不在模型能力而在你和模型之間的接口設(shè)計(jì)。命令包就是這個(gè)接口。接口設(shè)計(jì)得好同樣的模型能多干一倍的活設(shè)計(jì)得差再強(qiáng)的模型也使不上勁。中文命令包的意義就是把這個(gè)接口從英文思維切換到中文思維讓溝通成本降到最低。你可以從最簡單的/解釋和/補(bǔ)全開始用順手了再逐步加慢慢長成一套屬于自己的工作流。