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