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