1. 為什么需要一張“提問急救卡”寫代碼這件事卡住的時候往往不是不會寫而是不知道該問什么。我見過太多同行包括我自己早期遇到報錯就把整段代碼甩進對話框配一句“這為啥報錯”然后等一個不知道能不能用的答案。結果要么對方回一句“信息不夠”要么給出一段看似合理但跑不通的代碼來回拉扯半小時問題還在原地。Codex 類工具本質(zhì)上是一個“按你給的上下文推理”的系統(tǒng)。它不會讀心也不會主動去翻你的項目結構。你給它的信息越模糊它只能靠猜猜錯了你就得花更多輪對話去糾正。所以真正決定效率的不是模型多強而是你怎么問。這張“提問急救卡”就是解決這個問題的。它是一套可以隨身帶著用的提問模板覆蓋了日常開發(fā)里最高頻的 7 種場景報錯排查、代碼解釋、重構建議、補測試、寫正則、性能優(yōu)化、跨語言翻譯。每個模板都規(guī)定了“必須給什么信息、按什么順序給、要它輸出什么格式”。再配合組合寫法把兩三個模板疊在一起用就能應付絕大多數(shù)復雜需求。適合誰來參考如果你是剛接觸 AI 輔助編程的新手這套模板能幫你少走很多彎路避免“問了等于沒問”如果你已經(jīng)用了一段時間但總覺得回答質(zhì)量忽高忽低那問題多半出在提問結構上這套東西能幫你把輸出穩(wěn)定下來。下面我按“設計思路—模板拆解—組合寫法—排查技巧”的順序把這張卡完整拆開講。2. 整體設計思路把提問當成一次接口調(diào)用2.1 提問的本質(zhì)是構造上下文我習慣把每一次提問看成一次函數(shù)調(diào)用。你傳進去的參數(shù)決定了返回值的質(zhì)量。參數(shù)太少函數(shù)只能返回默認值或者拋異常參數(shù)結構清晰返回值才穩(wěn)定可控。一個高質(zhì)量的提問通常包含四個部分角色設定、任務描述、上下文材料、輸出約束。角色設定告訴它“你現(xiàn)在是誰”比如“你是一個熟悉 Python 異步編程的資深工程師”任務描述說清楚“要干什么”比如“幫我找出這段代碼里的競態(tài)條件”上下文材料是代碼、報錯、環(huán)境信息輸出約束則是“用表格列出來”“只給修改后的代碼不要解釋”。很多人只給了任務描述其余三塊全缺。這就好比調(diào)用一個函數(shù)只傳了一個參數(shù)剩下的全靠默認值結果自然不可控。2.2 為什么是這 7 個模板這 7 個模板不是拍腦袋定的是我統(tǒng)計了自己和身邊同行過去半年里高頻提問類型之后歸納出來的。排在前面的分別是看不懂報錯、看不懂別人寫的代碼、想重構但怕改壞、不想手寫測試、正則寫不出來、跑得太慢、要把一段邏輯換語言實現(xiàn)。這七類基本覆蓋了日常開發(fā) 80% 以上的求助場景。每個模板的設計都遵循一個原則把“它需要猜的東西”降到最低。比如報錯模板里強制要求貼完整堆棧和最小復現(xiàn)代碼就是為了避免它去猜你的運行環(huán)境重構模板里要求先說明“不能改變的外部行為”就是為了防止它順手把你的接口簽名改了。2.3 模板不是死規(guī)矩是骨架需要強調(diào)一點模板是骨架不是鐐銬。真正用起來的時候你完全可以根據(jù)情況增減。比如一個特別簡單的報錯可能不需要貼完整項目結構一個復雜的性能問題可能要在模板基礎上再加一段壓測數(shù)據(jù)。模板的價值在于給你一個“不會漏掉關鍵信息”的檢查清單而不是讓你機械填空。我自己的習慣是先把模板背個大概用熟之后就不再逐字對照而是形成條件反射一遇到報錯手就自動去復制堆棧、圈出出錯行、寫一句預期行為。這個反射建立起來之后提問效率會有質(zhì)的提升。3. 七個常用模板逐個拆解3.1 模板一報錯排查模板這是使用頻率最高的一個。核心結構是“環(huán)境 報錯 最小復現(xiàn) 預期行為”?！经h(huán)境】語言/框架版本、操作系統(tǒng)、依賴版本 【報錯】完整堆棧信息不要截斷 【最小復現(xiàn)】能觸發(fā)該報錯的最短代碼 【預期行為】我原本希望它做什么 【已嘗試】我已經(jīng)試過哪些方法結果如何為什么要求“最小復現(xiàn)”因為完整項目里往往有幾十個文件模型很難判斷哪一行才是關鍵。你把范圍縮到最小它就能精準定位。我試過同一個報錯貼整個文件時它給了五個可能原因貼最小復現(xiàn)后它直接指出是某個庫的版本不兼容。“已嘗試”這一欄也特別重要。它能避免模型重復推薦你已經(jīng)試過的方法也能讓它在你失敗的方向上換思路。實測下來加上這一欄之后有效回答的比例明顯上升。注意堆棧信息一定要貼全尤其是最底部的Caused by部分。很多人只貼第一行結果模型只能給出泛泛的猜測。3.2 模板二代碼解釋模板接手老項目或者讀開源代碼時特別有用。結構是“代碼 關注點 輸出格式”?！敬a】需要解釋的代碼段 【背景】這段代碼在項目里大概負責什么 【關注點】我最想搞懂的是哪部分如這個裝飾器的作用、這個狀態(tài)機怎么流轉 【輸出格式】按執(zhí)行順序逐段解釋每段配一句“它在干什么”關鍵在于“關注點”。如果你只說“解釋這段代碼”它可能從第一行變量聲明開始講講了一堆你早就懂的東西。你明確說“我只關心這個回調(diào)為什么是異步的”它就會把火力集中在那里。我個人的經(jīng)驗是解釋模板配合“讓它畫一個執(zhí)行順序的文字版”效果很好。雖然不能用圖表但讓它用編號列表把調(diào)用順序列出來理解起來比純文字快得多。3.3 模板三重構建議模板重構最怕的是改出 bug。所以這個模板的核心是“約束邊界”?！粳F(xiàn)狀】當前代碼 我覺得哪里不好如嵌套太深、重復邏輯多 【約束】不能改變的外部行為如函數(shù)簽名不變、返回結構不變 【目標】希望達到的效果如降低圈復雜度、提取公共函數(shù) 【輸出】給出重構后代碼 改動點說明 潛在風險提示“約束”這一欄是靈魂。你不說清楚它可能為了“優(yōu)雅”把你的同步函數(shù)改成異步或者把返回值從列表改成生成器調(diào)用方直接崩掉。我踩過這個坑后來每次都把“不能動的東西”寫在最前面。“潛在風險提示”也很有價值。好的重構建議會告訴你“這個改動在并發(fā)場景下需要額外注意”而不是只給你一段漂亮代碼就完事。3.4 模板四補測試模板寫測試枯燥但必要。這個模板幫你把這件事變得省力?！颈粶y代碼】需要測試的函數(shù)或類 【測試框架】用的什么如 pytest、jest 【覆蓋要求】需要覆蓋哪些分支正常、邊界、異常 【輸出】可直接運行的測試代碼 每個用例的意圖說明“覆蓋要求”決定了測試的完整度。你只說“寫測試”它可能只給一個正常路徑的用例。你明確要求“邊界值和異常輸入都要覆蓋”它才會把空值、超長輸入、類型錯誤這些情況考慮進去。我通常還會加一句“用參數(shù)化方式組織用例”這樣生成的測試更簡潔后續(xù)加 case 也方便。3.5 模板五正則表達式模板正則這東西寫出來容易寫對難。模板結構是“樣本 規(guī)則 邊界”?！緲颖尽啃枰ヅ涞淖址纠辽俳o 3 個正例和 3 個反例 【規(guī)則】用自然語言描述匹配規(guī)則 【邊界】哪些情況不應該匹配 【輸出】正則表達式 逐段解釋 測試用例給正例和反例是關鍵。只給正例它可能寫出一個“能匹配但也會誤傷”的表達式。我試過匹配日志時間戳只給正例時它給的正則會把版本號也匹配進去補了反例之后立刻就修正了?！爸鸲谓忉尅蹦軒湍泸炞C它是不是真的理解了你的規(guī)則而不是碰巧湊出一個能跑的表達式。3.6 模板六性能優(yōu)化模板性能問題最忌諱瞎猜。這個模板要求先量化?！粳F(xiàn)象】慢在哪里有多慢如這個接口 P99 是 800ms 【代碼】相關代碼段 【數(shù)據(jù)規(guī)?！枯斎霐?shù)據(jù)量級如單次處理 10 萬條記錄 【已定位】是否已經(jīng)用工具定位到熱點 【約束】不能引入哪些新依賴、不能改變哪些行為 【輸出】優(yōu)化方案 預期收益 代價分析“數(shù)據(jù)規(guī)?！苯?jīng)常被忽略但它直接影響方案選擇。處理一千條和處理一百萬條優(yōu)化手段完全不同。你不說規(guī)模它可能給你一個在小數(shù)據(jù)量下更快、在大數(shù)據(jù)量下反而更慢的方案?！按鷥r分析”是我特別看重的一欄。任何優(yōu)化都有代價可能是內(nèi)存換時間可能是代碼復雜度上升。讓它把代價說清楚你才能做取舍。3.7 模板七跨語言翻譯模板把一段邏輯從一種語言搬到另一種語言時用?！驹凑Z言】如 Python 【目標語言】如 Go 【源代碼】需要翻譯的代碼 【保留點】哪些習慣要保留如錯誤處理風格、命名規(guī)范 【注意】目標語言里需要特別處理的點如并發(fā)模型差異 【輸出】翻譯后代碼 差異說明“保留點”和“注意”是精髓。不同語言的慣用法差別很大直譯往往寫出“用 Python 思維寫的 Go 代碼”。你明確說“按目標語言的慣用寫法來”它才會用地道的寫法實現(xiàn)。我一般還會要求它“指出源語言里哪些寫法在目標語言中不推薦”這能幫我順便學到目標語言的最佳實踐。4. 組合寫法把模板疊起來用4.1 為什么需要組合真實場景很少只涉及單一需求。比如你遇到一個報錯排查完發(fā)現(xiàn)是性能問題優(yōu)化完又想補個測試防止回歸。這時候單個模板就不夠用了需要把幾個模板按順序組合起來。組合的核心邏輯是前一個模板的輸出作為后一個模板的輸入。這樣每一輪對話都有明確的產(chǎn)出不會發(fā)散。4.2 三種高頻組合套路第一種是“排查 重構”。先用報錯模板定位問題確認是代碼結構導致的再切到重構模板把“約束”設為“修復該報錯的同時不改變其他行為”。這樣一輪下來問題解決了代碼也順帶優(yōu)化了。第二種是“解釋 補測試”。讀不懂的代碼先解釋清楚理解之后立刻讓它基于解釋生成測試。因為解釋過程中它已經(jīng)理解了代碼意圖生成的測試會更貼合真實邏輯而不是只覆蓋表面分支。第三種是“性能 翻譯”。一段慢代碼優(yōu)化完如果打算遷移到別的語言可以直接接翻譯模板把優(yōu)化后的版本作為源材料。這樣遷移過去的就是優(yōu)化后的邏輯而不是把老問題一起搬過去。4.3 組合時的銜接話術組合的關鍵在于銜接。不要重新開一段對話而是在同一輪里說“基于上面的分析接下來……”。這樣模型能保留前面的上下文不用你重復貼代碼。我常用的銜接句式是“基于你剛才定位到的這個熱點現(xiàn)在幫我按目標語言的慣用寫法重寫注意保留原有的錯誤處理邏輯?！币痪湓捑桶焉舷挛暮图s束都帶上了。提示組合模板時輪次不要太多。一般兩到三個模板疊加就夠了超過三個容易讓上下文變得混亂模型反而抓不住重點。5. 常見問題與排查技巧實錄5.1 回答質(zhì)量忽高忽低怎么辦最常見的原因是上下文不一致。同一段代碼你第一次貼了完整文件第二次只貼了片段模型的理解就會漂移。解決辦法是在同一輪對話里保持材料一致需要補充信息時用“補充”而不是“重新開始”。另一個原因是提問里混入了太多無關信息。比如你問一個報錯卻把整個項目的目錄結構都貼上去模型可能被無關文件干擾。這時候要果斷做減法只留最小必要信息。5.2 它給的代碼跑不通怎么排查先看它有沒有遵守你的“約束”。很多時候跑不通是因為它悄悄改了函數(shù)簽名或者依賴版本。其次看它假設的環(huán)境和你的是否一致比如它默認用了某個新版本才有的語法。我的習慣是拿到代碼后先不急著跑而是快速掃一遍它有沒有引入新依賴、有沒有改動接口。確認這兩點沒問題再放進項目里測試。5.3 常見問題速查表問題現(xiàn)象可能原因處理方式回答很泛沒重點缺少關注點或輸出約束補上“我最關心的是……”和輸出格式代碼跑不通約束沒寫清它改了接口把“不能改變的行為”寫在最前面反復推薦已試過的方法沒寫“已嘗試”補上已嘗試列表和結果測試覆蓋不全沒寫覆蓋要求明確要求正常、邊界、異常都覆蓋正則誤匹配只給了正例補上反例和邊界說明優(yōu)化方案不適用沒給數(shù)據(jù)規(guī)模補上輸入量級和已定位信息翻譯不地道沒寫保留點和注意事項明確要求按目標語言慣用法5.4 幾個我踩過的坑第一個坑是“一次問太多”。我曾經(jīng)在一個提問里同時要求排查報錯、重構、補測試、寫文檔結果它每樣都只做了一半。后來我改成一次只聚焦一個主任務用組合寫法分輪推進質(zhì)量立刻上來了。第二個坑是“不給反例”。寫正則和寫校驗邏輯時只給正例幾乎必然導致誤匹配?，F(xiàn)在我養(yǎng)成了習慣任何匹配類需求都至少給三個反例。第三個坑是“忽略版本”。同一個庫不同版本行為可能完全不同。現(xiàn)在我每次都會在環(huán)境里寫清楚版本號省去了大量“在我這能跑”的扯皮。6. 把急救卡變成肌肉記憶這套模板用熟之后你會發(fā)現(xiàn)提問這件事變得像呼吸一樣自然。遇到問題腦子里自動就彈出對應的結構報錯先貼堆棧和最小復現(xiàn)重構先說約束性能先給數(shù)據(jù)規(guī)模。整個過程不需要刻意回憶模板因為結構已經(jīng)內(nèi)化了。我個人的體會是提問能力的提升本質(zhì)上是對“自己到底卡在哪”這件事的認知提升。很多時候你以為自己不會問其實是沒想清楚問題出在哪。模板強迫你把問題拆開、把信息補齊這個過程本身就在幫你理清思路。最后分享一個小技巧把你最常用的兩三個模板存成代碼片段或者輸入法快捷短語需要的時候一鍵調(diào)出只改中間的具體內(nèi)容。這個動作能再省下不少時間尤其是報錯排查這種高頻場景效果立竿見影。