1. 為什么“提問”本身需要一張急救卡寫了十幾年代碼我?guī)н^的新人沒有一百也有八十發(fā)現(xiàn)一個特別有意思的規(guī)律同樣一個報錯有人三分鐘拿到可用答案有人折騰一下午還在原地打轉(zhuǎn)。差距不在技術(shù)底子而在“怎么把問題說清楚”這件事上。Codex 這類 AI 編程助手本質(zhì)上是一個知識極廣但完全沒有上下文的搭檔你給它的信息越精準它還給你的東西就越接近能直接粘貼進項目的程度。反過來你甩一句“我的代碼報錯了怎么辦”它只能給你一堆正確的廢話。所謂“提問急救卡”就是把這套“怎么問”的經(jīng)驗固化成幾個可以反復套用的模板。我把它叫急救卡是因為它真正發(fā)揮價值的場景往往很急——線上冒煙、構(gòu)建掛了、臨交付前發(fā)現(xiàn)一個詭異 bug這時候你根本沒心思組織語言掏出模板往里填就行。這篇文章我會把 7 個我實際用得最多的模板拆開講透再講怎么把它們組合起來應對復雜場景。適合誰看剛接觸 AI 編程助手的新手能直接抄作業(yè)用了一段時間但總覺得“AI 答不到點子上”的中級開發(fā)者能查漏補缺帶團隊的人可以拿去做內(nèi)部規(guī)范。先說一個底層認知這也是整張急救卡的設計依據(jù)AI 編程助手最缺的不是知識是上下文。它不知道你的運行環(huán)境、不知道你的項目結(jié)構(gòu)、不知道你已經(jīng)試過什么、更不知道你真正想要的是“解釋原因”還是“直接給能跑的代碼”。提問的本質(zhì)就是在一兩段話里把這些缺失的上下文補齊。7 個模板分別對應 7 類最常見的上下文缺失理解了這一點你甚至能自己造模板。2. 七個常用模板逐個拆解2.1 模板一報錯定位型——把“報錯”變成“可診斷的問題”最基礎的場景也是最多人問得最爛的場景。新手常見問法是“這段代碼為什么報錯”然后貼一大坨代碼。AI 只能靠猜。正確的模板結(jié)構(gòu)是四段式環(huán)境 完整報錯 最小復現(xiàn)代碼 已嘗試的動作。我常用的寫法是這樣的環(huán)境Python 3.11 / Windows 11 / 依賴版本見下 報錯信息完整堆棧 Traceback (most recent call last): ... 最小復現(xiàn)代碼 只保留能觸發(fā)報錯的那幾行 我已經(jīng)試過把 X 改成 Y報錯變成 Z查了官方文檔關于 A 的說明沒找到對應場景。 請幫我定位根因并給出修改后的代碼。為什么強調(diào)“最小復現(xiàn)代碼”因為完整堆棧里 90% 的幀都跟問題無關你貼三百行代碼AI 的注意力會被稀釋反而容易抓錯重點。我實測下來把代碼壓縮到 10 行以內(nèi)AI 一次命中根因的概率明顯更高。另外“已嘗試的動作”這一項特別關鍵它能防止 AI 給你一個你早就試過的方案浪費一輪對話。注意報錯信息一定要貼完整堆棧不要只貼最后一行。很多問題的根因藏在中間某個Caused by里只貼最后一行等于讓 AI 盲猜。2.2 模板二代碼生成型——把“幫我寫個功能”拆成可驗收的規(guī)格“幫我寫一個登錄功能”——這種提問拿到的代碼基本沒法直接用因為 AI 不知道你的技術(shù)棧、不知道你的數(shù)據(jù)庫結(jié)構(gòu)、不知道你的鑒權(quán)方案。代碼生成型模板的核心是把需求寫成一份迷你規(guī)格說明書包含五個要素輸入、輸出、約束、技術(shù)棧、驗收標準。舉個例子同樣是登錄功能我會這樣寫技術(shù)棧Node.js Express PostgreSQL已有 users 表字段id, email, password_hash, created_at 需求實現(xiàn) POST /api/login 接口 輸入JSON body { email, password } 輸出成功返回 { token, user: { id, email } }失敗返回 401 { error: ... } 約束密碼用 bcrypt 校驗token 用 jsonwebtoken 簽發(fā)有效期 2 小時不要引入新的 ORM 驗收標準給出接口代碼 一段可直接運行的 curl 測試命令這套寫法的價值在于它把“模糊的愿望”翻譯成了“可驗收的交付物”。AI 拿到這種規(guī)格產(chǎn)出的代碼通常能直接跑你只需要微調(diào)。我個人的經(jīng)驗是約束那一欄寫得越具體返工越少。比如“不要引入新的 ORM”這一句能省掉你后面刪依賴的功夫。2.3 模板三代碼解釋型——讓 AI 當你的“代碼翻譯官”接手別人的代碼、讀開源項目、看一段看不懂的算法都需要這個模板。很多人問“這段代碼什么意思”得到的回答是把代碼逐行翻譯成中文毫無營養(yǎng)。真正有用的解釋應該包含三層這段代碼在做什么意圖、為什么這么寫設計動機、有什么坑邊界條件。我的模板長這樣請分三層解釋下面這段代碼 1. 整體意圖它解決什么問題輸入輸出是什么 2. 關鍵實現(xiàn)逐段說明核心邏輯重點解釋 [某個我不懂的地方] 3. 潛在問題邊界條件、性能隱患、可讀性問題 代碼 貼代碼第三層是精華。我踩過好幾次坑一段看起來人畜無害的代碼AI 指出它在輸入為空時會拋異?；蛘咴诖髷?shù)據(jù)量下是 O(n2)。這種“主動挑刺”的能力是逐行翻譯給不了的。你可以把第三層的要求寫得更狠一點比如“假設這段代碼要上生產(chǎn)列出所有可能出問題的地方”。2.4 模板四重構(gòu)優(yōu)化型——帶著“目標”去改而不是“隨便看看”“幫我優(yōu)化一下這段代碼”是最容易得到無效回答的提問之一因為“優(yōu)化”是個沒有方向的目標。是優(yōu)化可讀性性能還是減少依賴方向不同改法完全相反。重構(gòu)優(yōu)化型模板的關鍵是先聲明優(yōu)化目標再給約束。優(yōu)化目標可讀性優(yōu)先性能次要 約束不改變函數(shù)簽名不引入新依賴保持現(xiàn)有測試全部通過 現(xiàn)狀這個函數(shù)有 80 行嵌套 4 層我覺得難維護 請給出重構(gòu)后的版本并說明每一處改動的原因。我特別想強調(diào)“說明每一處改動的原因”這句。它逼著 AI 給出可解釋的重構(gòu)而不是甩給你一坨看不懂的新代碼。你從中學到的是方法下次自己就能改。另外約束里的“保持測試通過”是個硬指標如果 AI 的重構(gòu)破壞了測試你能立刻發(fā)現(xiàn)。2.5 模板五方案對比型——把選擇題交給 AI但你來定標準技術(shù)選型是程序員的日常用 Redis 還是本地緩存用 REST 還是 GraphQL這種問題直接問“哪個好”是得不到答案的因為“好”取決于你的場景。方案對比型模板的精髓是讓 AI 按你給定的維度做對比表。場景日活 5 萬的小型應用團隊 3 人運維能力有限 候選方案ARedis、B進程內(nèi)緩存 請按以下維度對比實現(xiàn)復雜度、運維成本、一致性保證、擴展性、適用邊界 最后給出針對我這個場景的推薦并說明理由。這個模板的妙處在于維度是你定的AI 只負責填充。這樣得到的對比表直接貼合你的決策需求而不是泛泛而談。我一般會加一句“如果我的日活漲到 50 萬結(jié)論會變嗎”讓 AI 順帶把擴展性也講清楚。2.6 模板六調(diào)試排查型——把“玄學 bug”變成“可驗證的假設”有些 bug 特別邪門本地好好的一上測試環(huán)境就掛跑一次沒事跑十次掛一次。這種問題問 AI如果只是描述現(xiàn)象它會給你一堆“可能的原因”。調(diào)試排查型模板的核心是讓 AI 幫你生成排查清單和驗證方法?，F(xiàn)象本地正常測試環(huán)境偶發(fā)失敗頻率約 1/10 已知測試環(huán)境是容器化部署本地是直接跑 請列出最可能的 5 個原因按可能性排序 對每個原因給出一個具體的驗證方法命令或代碼“給出驗證方法”這一句是靈魂。它把 AI 從“算命先生”變成了“排查助手”。你拿著這份清單一條條驗證很快就能縮小范圍。我實測下來這種問法比直接問“為什么”效率高得多因為它輸出的是可執(zhí)行的下一步而不是一堆猜測。2.7 模板七學習路徑型——讓 AI 當你的私人教練想學一個新框架、新語言、新領域直接問“怎么學”得到的往往是網(wǎng)上抄來的大綱。學習路徑型模板的關鍵是告訴 AI 你的起點和目標讓它規(guī)劃一條最短路徑。我的起點熟悉 JavaScript沒接觸過類型系統(tǒng) 我的目標兩周內(nèi)能用 TypeScript 獨立寫一個小型 CLI 工具 每天可投入1.5 小時 請給出一個按天拆解的學習計劃每天包含學習內(nèi)容、動手練習、驗收標準“驗收標準”這一欄很重要它讓學習變成可量化的進度而不是“感覺學得差不多了”。我按這個模板規(guī)劃過好幾次學習最大的收獲是它幫我砍掉了大量無關內(nèi)容直奔能用的部分。3. 組合寫法復雜場景怎么把模板拼起來3.1 為什么單一模板不夠用真實工作里的問題很少是純粹的“報錯”或純粹的“重構(gòu)”往往是復合的。比如“這段老代碼報錯了我想順便重構(gòu)一下但不確定重構(gòu)方向?qū)Σ粚Α边@就同時涉及報錯定位、代碼解釋、重構(gòu)優(yōu)化三個模板。這時候如果只用一個模板AI 的回答會顧此失彼。組合寫法的思路是按優(yōu)先級串聯(lián)模板讓 AI 分步驟輸出。3.2 串聯(lián)式組合一步接一步串聯(lián)式適合有明確先后順序的場景。比如排查一個性能問題我會這樣組合第一步代碼解釋先解釋下面這段代碼的整體意圖和關鍵實現(xiàn) 第二步調(diào)試排查基于上面的理解列出可能導致響應慢的 5 個原因 第三步重構(gòu)優(yōu)化針對最可能的原因給出優(yōu)化方案約束是不改變對外接口 代碼貼代碼這種寫法的好處是每一步都建立在前一步的輸出上AI 的推理鏈條是連貫的。我實測下來串聯(lián)式組合得到的答案質(zhì)量明顯高于把三個問題混在一起問。關鍵技巧是用“第一步/第二步/第三步”明確分節(jié)讓 AI 知道你要的是分階段輸出而不是一鍋燴。3.3 嵌套式組合模板里套模板嵌套式適合需要“先定義再執(zhí)行”的場景。比如你要 AI 生成一段代碼但這段代碼涉及一個你不熟悉的算法你可以把“代碼解釋”嵌套進“代碼生成”里請幫我實現(xiàn) [功能]技術(shù)棧 [X] 要求在給出代碼之前先用三句話解釋你打算用的算法思路 代碼寫完后單獨用一段說明這段代碼的邊界條件和潛在坑這里的“先解釋思路”和“后說明邊界”就是嵌套進去的解釋型模板。它的價值在于讓你在拿到代碼的同時理解代碼而不是盲目復制。我特別推薦新手用這種寫法長期下來你對 AI 產(chǎn)出的信任度和判斷力都會提升。3.4 組合寫法的三個避坑點組合寫法雖然強但有幾個坑我踩過。第一別一次串太多步。超過四步AI 容易在中間某步跑偏而且回答會變得很長重點被淹沒。我的經(jīng)驗是三步以內(nèi)最穩(wěn)。第二每步都要有明確的輸出物。比如“列出 5 個原因”“給出修改后的代碼”有輸出物你才能判斷這一步做沒做好。第三步與步之間要留出你的判斷空間。別讓 AI 一口氣跑完所有步驟中間停下來看看必要時調(diào)整下一步的方向比一次性問完更高效。4. 常見問題與排查技巧實錄4.1 AI 答非所問怎么辦這是最高頻的問題。原因通常有三個上下文給少了、問題太寬泛、或者你問的其實是兩個問題。排查順序是這樣的先檢查是不是把兩個不相關的問題塞進了一段話拆開分別問再檢查是不是缺少關鍵上下文環(huán)境、版本、代碼補上最后檢查問題本身是不是太寬泛用模板把它收窄。我個人的經(jīng)驗是八成“答非所問”都是因為問題太寬泛比如“怎么優(yōu)化性能”改成“這個函數(shù)在 10 萬條數(shù)據(jù)下耗時 3 秒怎么降到 1 秒以內(nèi)”答案質(zhì)量立刻不一樣。4.2 AI 給的代碼跑不起來怎么辦先別急著罵 AI按這個清單排查依賴版本對不對、環(huán)境變量配了沒、代碼是不是被截斷了、有沒有隱藏的假設比如假設某個文件存在。我遇到最多的情況是AI 假設了一個不存在的依賴或字段這時候把報錯貼回去加上一句“我這邊沒有 X請用 Y 替代”通常一輪就能修好。另一個高頻原因是代碼被輸出截斷尤其是長函數(shù)這時候直接說“代碼不完整請從第 X 行繼續(xù)”。4.3 怎么判斷 AI 的回答靠不靠譜這個問題很關鍵因為 AI 會一本正經(jīng)地胡說。我的判斷標準有三條第一看它有沒有解釋“為什么”只給結(jié)論不給理由的可信度打折第二看它有沒有提到邊界條件一個成熟的方案一定會談限制第三小步驗證別一次性把 AI 的代碼全量替換進項目先在一個隔離環(huán)境跑通再說。我踩過的坑里最慘的一次是直接信了 AI 給的“最佳實踐”結(jié)果那個方案在我的場景下根本不適用因為它默認了一個我根本沒有的前提。4.4 提問急救卡速查表場景用哪個模板核心要素最容易漏的一步代碼報錯報錯定位型環(huán)境堆棧最小復現(xiàn)已嘗試貼完整堆棧寫新功能代碼生成型輸入輸出約束技術(shù)棧驗收寫清約束讀不懂代碼代碼解釋型意圖實現(xiàn)潛在問題要求挑刺想改代碼重構(gòu)優(yōu)化型目標約束改動說明聲明優(yōu)化方向技術(shù)選型方案對比型場景候選對比維度推薦自己定維度詭異 bug調(diào)試排查型現(xiàn)象已知原因清單驗證方法要驗證方法學新東西學習路徑型起點目標時間驗收標準寫驗收標準這張表我建議直接存成便簽遇到對應場景就掏出來填。用熟之后你會發(fā)現(xiàn)提問的質(zhì)量直接決定了你從 AI 那里拿到的價值而這張卡就是提升提問質(zhì)量的最短路徑。5. 把急救卡變成肌肉記憶模板這東西看一遍記不住用十遍才內(nèi)化。我自己的做法是前兩周每次提問前都對著速查表挑模板填完再發(fā)。剛開始會覺得麻煩但大概二十次之后你會發(fā)現(xiàn)自己在打字的時候就已經(jīng)自動按模板的結(jié)構(gòu)組織了根本不用刻意想。到那個階段你甚至能根據(jù)具體場景微調(diào)模板比如把報錯定位型的“已嘗試動作”換成“我懷疑是 X但不確定”引導 AI 往你的假設方向驗證。還有一個我個人的小習慣把每次得到高質(zhì)量回答的提問原樣存下來攢成一個自己的模板庫。因為不同項目、不同技術(shù)棧的提問細節(jié)差別很大通用模板只是骨架真正好用的是你根據(jù)自己的項目沉淀出來的“血肉版”。我現(xiàn)在的模板庫里大概有三十多條覆蓋了我常打交道的幾個技術(shù)棧每次遇到類似問題直接改幾個參數(shù)就能用效率比現(xiàn)想高太多。最后分享一個判斷標準如果你問完一個問題AI 的回答讓你覺得“這不就是我自己也能想到的嗎”那說明提問沒到位上下文給少了或者問題太寬泛。好的提問應該讓你有“原來還能這么想”的感覺。這個標準我用了很久幫我不斷校準提問的質(zhì)量。