部落格

Claude 為什麼會做錯事:3 個提示詞

Markdown

Claude 不先了解你的意圖就急著寫程式,因此做出錯誤的內容。我會說明原因,並提供 3 個可直接使用的提示詞,讓它先提問。

閱讀全文

重點摘要

Claude 會做錯事,是因為它急著動手寫程式,並自行補上它認為你想要的內容。它常常猜錯。問題幾乎從來不在模型本身——即使是最強的模型,面對模糊的任務也會失準。我用一個方法解決:先讓 Claude 訪談我,釐清我的意圖,之後才開始寫。以下提供三個可以直接複製貼上的提示詞。

想進一步了解如何使用這項服務,請參閱 Ailoot 文件。

Claude 為什麼會做錯事?

重點摘要

Claude 收到簡短的要求後,會立刻補上缺漏的部分,依照自己對任務的理解開始寫程式。它的理解和你的不同。結果就是,你原本只期待改一行,差異內容卻動到了 14 個檔案。問題出在你說的內容與你心裡想的內容之間有落差,幾乎與模型無關。

你寫道:「在商品頁面新增篩選器。」你心裡想的是放幾個核取方塊,再更新清單。Claude 收到同樣的要求,卻決定打造一套完整的篩選引擎:自己的狀態儲存區、獨立的輸入延遲邏輯、URL 同步功能,以及十幾個輔助函式。原本幾個 URL 參數就能解決的事,最後多出數百行程式碼。

在這類情況下,結論很清楚:代理程式並沒有犯錯,只是解決了一個大得多的問題。問題在於,沒有簡潔而精確地說明想要的結果。

關鍵字是「意圖」。你心裡有意圖,Claude 卻沒有。它看到的是你提出要求的文字,以及此前所有上下文。接著,它會用猜測填補空白。要求越短,它猜得越多,結果也就越偏離你的期待。

Anthropic 在 Claude Code 文件中明確指出:

如果讓 Claude 直接開始寫程式,它可能會解決錯誤的問題。

— Claude Code Docs, https://code.claude.com/docs/en/best-practices

我在自己的專案中也遇過這種情況。我請它修正一個授權畫面,結果差異內容影響了相鄰模組的一半。這不是 Claude 的錯:我只給了一行要求,剩下的部分是它自行補上的。從那之後,凡是比修正錯字更大的任務,我都會先從提問開始——讓 Claude 問我問題。

真的是模型的問題嗎?為什麼連最強的模型也會失準?

重點摘要

模型的重要性沒有大家想的那麼高。面對模糊的任務,即使是最強的模型也會失準:它收到同樣不完整的指示,再用自己的猜測填補空白。能妥善掌控代理程式的開發者,不論使用頂級模型或中階模型,都能得到相同的結果。關鍵在於你能多清楚地描述自己的需求。在這裡,模型效能是次要的。

每週都會有比前一個更「聰明」的模型問世,每次我們都覺得,AI 終於能從幾個字就理解我們了。但事實並非如此。更強大的模型寫程式更快,也更擅長處理複雜邏輯,但它依然無法讀懂你的心思。如果任務界定不清楚,你得到的內容可能寫得很漂亮,卻還是錯的。

你可以從中得到一個簡單的結論:期待最新模型能猜得更準,是條走不通的路。學會交辦任務,讓它不必猜測,成本更低,也更可靠。接下來就來談這件事。

什麼是 grilling?它如何解決 AI 的認知落差?

重點摘要

Grilling 是讓 AI 在開始工作前先訪談你:它會針對任務提出詳細問題,直到雙方達成共識。目的是在寫下第一行程式碼之前,彌補溝通落差。

這聽起來不太符合直覺。我們使用 AI 是為了更快完成工作,現在卻有人要我們放慢速度,先讓它提問。但寫程式前花五分鐘回答問題,可能省下之後一小時的修正時間。

問題不只是你沒有把事情向 Claude 解釋清楚。很多時候,你自己也還沒想透這項任務——需要考量哪些情況、界線在哪裡、什麼最重要。Grilling 透過提問,把這些內容從你腦中引出來。談話結束時,你不只得到 AI 能理解的任務,也終於把自己的任務詳細說明清楚了。

這就是情境工程的運作方式:主要工作發生在提示詞之前,而不是撰寫提示詞的過程中。你不是在尋找神奇的提示詞寫法,而是事先整理好 Claude 需要的資訊,直到它不用額外解釋也能理解。

如何讓 Claude 先問你問題?

重點摘要

簡短描述任務,並明確要求 Claude 在開始工作前先訪談你:請它詢問細節、邊界情況與限制,最後再把所有內容整理成規格檔案。這是 Anthropic 的官方建議——Claude Code 文件中有現成的提示詞範本。複製範本、修改任務描述,再貼到工作階段的開頭即可。

Anthropic 不只允許這種做法,還會主動推薦。文件中有一節名為「讓 Claude 訪談你」,並附上現成的提示詞。以下是實用版本:

提示詞

Grilling 提示詞——讓 Claude 訪談你

我想打造[簡短描述任務]。

在撰寫任何程式碼之前,請詳細訪談我。詢問實作、介面、邊界情況、風險與取捨。不要問顯而易見的問題;請深入探討我可能尚未仔細思考的難題。

一次只問一個問題,並等待我的回答。每個問題都請立即提出你建議的答案。

持續提問,直到我們涵蓋所有事項。接著將完整規格整理成名為 SPEC.md 的檔案。

有三個細節讓這份提示詞真正實用,而不是只具裝飾性。第一是「一次只問一個問題」。如果 AI 一次丟出十個問題,你會不知所措,也只能草率回答。第二是「提出建議答案」:你不必從零開始想所有事情,只要同意或修正即可。第三是「把規格整理成檔案」:引導出來的意圖會成為文件,不會遺失。

Anthropic 從投入時間的角度,說明這樣做的好處:

花時間把規格整理好,比花時間盯著實作過程更有價值。

— Claude Code documentation, https://code.claude.com/docs/en/best-practices

訪談結束後,開啟新的工作階段,並提供完成的規格。乾淨的上下文,加上清楚說明的意圖,Claude 就能一次抓準方向。

「證明這是最佳方案」技巧

重點摘要

不要只讓 AI 提問,也要讓它為自己的決策辯護。我會在任務中加上一項要求:證明提出的計畫是最佳方案,而不是第一個想到的點子,並且已經考慮到後續幾個步驟。這會讓 Claude 從「我會做個類似的東西」模式切換到批判模式,在你花時間實作之前先檢查自己的工作。

Grilling 會引導出你的意圖,但 AI 還有另一個習慣:抓住第一個看起來可行的解法。Anthropic 稱這為「信任但驗證」的落差:Claude 產生看似合理的實作,卻經不起邊界情況的考驗。解法是在寫程式碼之前先要求證據。

如果你無法檢查結果,就不要提交。

— Anthropic, Claude Code Docs, https://code.claude.com/docs/en/best-practices

我幾乎總會在提示詞中加入「證明給我看」一節。以下是確切的寫法:

提示詞

提示詞——讓 AI 為自己的計畫辯護

寫程式碼之前,請像批評者一樣分析這項任務。

找出 2-3 種解法。請證明每種解法確實能解決我的任務,而不是為了增加複雜度而增加複雜度。不要只是為了寫程式碼而寫程式碼。

接著選一種解法,證明它是最佳方案,並且已考慮到後續幾個步驟。專案成長後,哪些部分會出問題?我們現在漏掉了什麼?

完成以上分析後,再提出實作方案。

沒有這一節時,Claude 會給你第一個可行方案。有了這一節,Claude 會自行排除行不通的選項、說明選擇理由,並在碰到任何檔案之前讓你看到它的推理。你只需花兩分鐘閱讀一小段文字,不必花一小時追查完成後的程式碼為什麼沒有如預期運作。

事前驗屍:開始前讓 AI 找出 10 個失敗原因

重點摘要

事前驗屍是一種技巧:請 AI 想像專案已經失敗,並說出失敗的原因。Claude 會從樂觀的「我會完成這件事」模式切換為尋找弱點,這些弱點原本可能要等到工作一週後才會浮現。你可以在投入時間之前取得風險清單,並預先處理問題。

這是我最喜歡的技巧,因為它運用了心理學。當你要求 AI「把事情做好」,它就會以成功為前提,略過問題。如果你要它想像失敗,它就會開始看見先前忽略的地方。提示詞很短:

提示詞

事前驗屍提示詞——開始前找出疏漏

想像現在是一年後。我們正在規劃的專案已經失敗。

請列出失敗的 10 個原因。開始時我們沒有考慮到什麼?低估了什麼?在哪裡偷工減料?哪些假設最後證明是錯的?

接著,針對每個原因,告訴我現在可以做什麼來解決。

我會在核准計畫之前使用這個提示詞。列出的原因有一半根本不合理,但另一半是真正的陷阱,而我原本會在一週後碰上它們。在規劃階段處理,只需要十分鐘。等到專案完成後才遇上,就得花好幾天調查。

組合方式很簡單:grilling 引出意圖,「證明給我看」為決策辯護,事前驗屍找出疏漏。三段簡短文字,在寫程式碼之前貼上即可。它們能讓 Claude 從急著執行的工作者,轉變為先思考的合作夥伴。

為什麼過度堆積的上下文會讓 Claude 變笨?

重點摘要

Claude 的 context window 有容量限制,也就是它一次能記住的資訊量。當視窗填滿超過一半,它就會開始遺漏重要細節、混淆先前的共識,並用猜測填補空白,而不是記住內容。一場什麼都談的漫長對話,是 AI 到了一天結束時,做的事和早上談妥的內容完全不同的常見原因。

即使任務描述得再完美,只要在雜亂的上下文中工作,仍然會出問題。運作方式如下:你每提出一項新要求,整段聊天紀錄都會進入 Claude 的工作上下文。工作階段越長,視窗填滿得越快。請讓它保持在半滿以下;超過之後,AI 就會開始變笨,遺忘你在一開始討論的重要事項。

最能減少我挫折感的規則是:一項任務,一個聊天室。完成一個函式後,就關閉聊天室,為下一項任務開啟新的聊天室。沒錯,有時把所有事情放在同一個視窗裡比較方便,但你會因此失去上下文,還會收到離題的回答。

Anthropic 將這種失敗模式稱為「垃圾抽屜工作階段」。解法很簡單:在不相關的任務之間使用 /clear 清空視窗,避免把前一項任務的雜亂內容帶進新任務。

如果你進行長時間工作階段,卻不清楚費用和 AI 的注意力都花在哪裡,我在 Claude Code 的 token 都去哪了指南中另外說明了這個主題。我也在設定 CLAUDE.md指南中整理了持續性上下文的基本資訊,Claude 每次啟動時都會讀取它。

Grilling 和 Plan Mode 有什麼不同?兩者該如何搭配?

重點摘要

Grilling 和 Plan Mode 解決的是同一問題的不同部分。Grilling 在計畫形成之前,透過提問引出你的意圖。Plan Mode 則是處理已經理解的任務,列出變更計畫,並在你核准前不碰任何內容。兩者搭配效果最好:先透過 grilling 釐清要打造什麼,再用 Plan Mode 清楚查看如何打造。

人們常把這兩種技巧混為一談,或認為只要其中一種就夠了。實際上,它們各自在流程的不同階段發揮作用。

功能GrillingPlan Mode
執行時機計畫之前——釐清意圖之後——制定變更計畫
誰問誰AI 訪談你你閱讀並核准計畫
取得內容任務規格逐檔案的變更計畫
主要優點避免「這不是我想要的」避免「不要碰其他東西」

Anthropic 描述了一套標準的四階段工作流程:首先是 Explore(Claude 調查並提出問題),接著是 Plan(擬定計畫但不進行變更),然後是 Implement(依計畫撰寫程式碼),最後是 Commit(記錄結果)。Grilling 發生在第一階段;Plan Mode 則在第二階段。第二階段的完整說明,請參閱 Claude Code 的 Plan Mode指南。

Anthropic 本身也提出一項重要提醒:小任務不必用這套流程增加負擔。

如果你能用一句話描述變更,就略過計畫。

— Official Claude Code documentation, https://code.claude.com/docs/en/best-practices

如果只是修正錯字、更改名稱或修改一行,直接提出要求即可,不必進行訪談或制定計畫。Grilling 適合用在模糊且犯錯代價高的任務。用在簡單的小事上,只會拖慢進度。

讓 AI 做錯事的 5 個任務描述錯誤

重點摘要

AI 幾乎所有失誤都可歸因於五種任務描述錯誤:一句模糊的要求、沒有設定限制、只說「寫程式碼」卻沒有「先理解」的階段、沒有定義「完成」的標準,以及所有事情都放在同一個無止盡的工作階段。每一項都會讓 Claude 用猜測補上任務內容。以下說明每種錯誤的樣貌,以及如何取代它們。

我把常見陷阱整理成一張表。左欄是人們通常會做、卻容易出錯的方式;右欄則是替代做法。

錯誤聽起來像是替代做法
模糊的一句話「把儀表板做得更好」描述任務並開始 grilling,讓 AI 透過提問引出細節
沒有限制「新增授權功能」說明哪些內容不能損壞、不能加入哪些函式庫,以及哪些事情不在範圍內
立刻要求「寫程式碼」輸入提示詞後馬上開始寫程式先「理解並提問」,再寫程式碼
沒有定義「完成」期待 AI 猜出結果提供範例、參考螢幕截圖或測試,說明「正常運作」的意思
所有事情放在同一個工作階段一整天都使用同一個聊天室一項任務搭配一個新聊天室,避免上下文變得雜亂

檢查一下最近一次讓 AI 答錯的提示詞。幾乎可以確定,這五種錯誤中至少有一種造成了問題。最常見的是第一種:你只給了一句簡短的話,卻期待 Claude 能正確補上其餘內容。它確實補上了,只是沒有照你心裡想的方式。

接下來:建立一套系統,讓 AI 聽幾個字就能理解你

重點摘要

個別提示詞解決的是個別任務。若要讓 AI 每次都能理解你,而不必長篇解釋,就需要一套系統:grilling 為每項任務引出意圖,Second Brain 儲存專案知識,而情境工程則串起 Claude 在提示詞之前會讀取的所有內容。如此一來,AI 做錯事的原因就消失了:它總是有足夠的上下文,不必靠猜測。

本指南介紹的三個提示詞——grilling、「證明給我看」和事前驗屍——都能處理眼前的特定任務。光是這樣就很有幫助:你不會只是想改一行,最後卻收到涉及 14 個檔案的差異內容。

但 grilling 有其上限。每次都從頭引導出你的意圖,需要很長時間。真正的轉變來自隨時備妥的上下文:專案知識資料夾、Claude 每次啟動時都會讀取的 CLAUDE.md 檔案,以及編碼在技能中的工作方法。如此一來,AI 開始任務前就已了解你的業務、目標與風格;因為你事先整理了半數上下文,所以只需幾個字就能理解你。

Anthropic 最近的分析顯示,這項工作有多重要:開發者在約 60% 的工作中使用 AI,但能完全信任 AI 處理的任務只有 0-20%。其他工作仍需要你的理解、監督,以及說明該打造什麼的能力。這才是值得培養的技能,而不是追逐最聰明的模型。

認識 Ailoot。

更多詳情

常見問題:Claude 為什麼會做錯事:3 個提示詞

何時先用訪談提示,不直接寫程式?

成果、邊界或限制不明,且錯誤代價高時使用。一次問一題,把同意結果存 SPEC.md;錯字或清楚一行變更可直接要求。

接受計畫前該查什麼?

要求兩三種做法,依規格及限制比較,再用 pre-mortem 提示審查失敗原因,實作前處理相關風險。

所有文章