多數人下提示詞時，有一個近乎反射的習慣，結尾就補一句「請一步步想」或「請解釋你的推理過程」。這招用在傳統生成模型上確實管用，換到 OpenAI 的 o 系列、Google 的 Gemini、Anthropic 的 Claude 這類「推理模型」身上，情況卻整個顛倒——同一句咒語，在這類模型上很可能不是加分，而是扣分。
這裡說的「一步步想」，在提示工程裡有個正式名稱，叫思維鏈提示詞（Chain-of-Thought Prompting）：在提示詞裡加一句引導語，讓模型先展開中間推理步驟，再給出最終答案。它曾經是讓語言模型少算錯、少跳步驟的標準解法，但推理模型的內部運作方式跟傳統模型完全不同，同一招搬過去用，輕則浪費 token、拖慢回應，重則讓模型分心去經營表面的推理敘事，反而想得更差。分清楚什麼時候該下、什麼時候該收手，直接決定你的提示詞是在幫模型，還是在扯後腿。
先從這招當年為什麼有效講起，再一路拆到推理模型時代，提示詞邏輯整個翻轉之後該怎麼下。
思維鏈提示詞是什麼？為什麼曾經是提示工程的標準答案？
思維鏈提示詞的做法很單純，在提示詞裡加一句引導，像是「請一步步思考」，讓模型在給出最終答案前，先用文字把中間的推理步驟攤開來寫。這個技巧最早由 Google Research 的 Jason Wei 等人在 2022 年提出，論文〈Chain-of-Thought Prompting Elicits Reasoning in Large Language Models〉裡的實驗數據很直接，同一個 5400 億參數的語言模型，只靠八個思維鏈範例引導，就在 GSM8K 這個數學應用題資料集上跑出當時最頂尖的準確率。
這招之所以在傳統生成模型上這麼好用，原因出在這類模型「拿到問題就直接跳答案」的預設行為。GPT-4、GPT-4o 這類非推理模型，沒有內建的中間推理階段，遇到需要拆解好幾步才能算對的題目，常常一步跳過去就直接吐出答案，結果不是算錯，就是把複雜問題想得太淺，漏掉關鍵條件。思維鏈提示詞等於是硬把「先想清楚再回答」這個習慣塞給模型，逼它把跳過的步驟一步步補回來，準確率因此顯著提升。也正因為這個效果太明顯，它很快就變成提示工程裡幾乎人人都會用的標配招式，直到推理模型出現，情況才整個翻過來。
推理模型跟一般對話模型，多了哪一段內建思考？
要搞懂思維鏈提示詞為什麼會反過來扣分，得先弄清楚「推理模型」跟「一般對話模型」差在哪裡。兩者的差別不是聰明多一點、笨一點，而是運作方式整個不同。
OpenAI 官方把自家的 o 系列稱為「the planners」，GPT 系列稱為「the workhorses」：o 系列被訓練成願意花更多時間、更用力思考複雜任務，擅長擬定策略、規劃怎麼拆解難題；GPT 系列則是低延遲、成本效益高，設計上就是拿來直接執行明確任務。這組定位不只 OpenAI 這麼分，Google 的 Gemini 系列有專門的 thinking 機制，官方文件說明模型會依請求的複雜度自動調整思考量；Anthropic 的 Claude 也一樣，在產生最終答案前會先建立一段內部的思考內容，把推理攤在裡面，再根據這段推理去組織正式回覆。DeepSeek 的 R1 走的也是同一條路線。
這幾家的做法背後是同一件事：推理模型在你看得到答案之前，會先在內部完成一段規劃、驗證、甚至推翻重來的隱藏思考，這段歷程不需要你在提示詞裡另外要求，模型自己就會做。一般對話模型沒有這一段，你問什麼，它就根據輸入直接生成回覆，中間沒有內建的「先想過一輪」機制。這個差異正是接下來要拆的重點。推理模型已經內建一套思考流程，你在提示詞裡再手動加一句「請解釋你的推理過程」，會撞出什麼結果？
為什麼自己補一句「請一步步想」，推理模型反而更差？
OpenAI 官方文件裡寫得很直白：「Since these models perform reasoning internally, prompting them to “think step by step” or “explain your reasoning” is unnecessary.」翻成白話就是，推理模型本來就會在內部完成規劃、拆解、自我檢查這一整套流程，你這時候再用提示詞硬性要求它解釋每一步，等於是拿一個外部指令去打斷它原本的內部推理路徑，模型得分心去經營一份「看得懂的推理敘事」，而不是專心把問題想對。
這種被打斷的狀態，學界稱之為過度思考（overthinking）。有研究指出，大型推理模型即使面對簡單查詢，也會生成過多的推理 token，不僅拉高成本，還可能讓模型陷入反覆自我懷疑的迴圈，遲遲無法收斂到答案。換句話說，多下的那句「請一步步想」不是在幫模型多想一輪，而是在誘發它把本來就會做的內部規劃，重新用外顯文字演一遍，多花的是 token 與等待時間，換來的卻不一定是更準的答案。
這條規則在簡單任務上格外明顯。Helicone 這家專門做 LLM 監測的國際平台，整理過的推理模型提示建議裡就提到，像 OpenAI 的 o1-preview 這類模型，給了少量範例（few-shot）引導反而表現變差，這跟傳統模型「範例越多越好」的直覺完全相反。任務本身不需要模型想那麼多，你卻硬塞範例或步驟指令進去，反而拖累了它。
一般對話模型和推理模型，提示詞邏輯剛好相反
把前面兩節擺在一起比，關鍵差異已經很清楚。對話模型跟推理模型該怎麼下提示詞，不是程度上的差別，而是方向整個相反。對話模型缺了那段內建推理，提示詞要負責補上；推理模型已經有那段內建推理，提示詞的角色反而要退到旁邊，別擋路。以下把兩套下法分開講。
對話模型：給步驟、給範例，引導它「想清楚」再答
面對 GPT-4o、GPT-4.1 這類非推理模型，前面提到的整套思維鏈提示詞、少量範例、「請先想清楚再回答」這類引導語，依然有效，而且值得繼續用。原因很直接：這類模型定位就是快速、低成本地執行明確任務，本身不會主動展開推理，你不引導，它就直接從問題跳答案。提示詞在這裡扮演的角色，是把模型拉著走過中間步驟，給它看幾個範例，告訴它先列出思考過程再回答，它才會照著做，而不是一步跳過去。
請一步步思考後再回答：這篇產品文案有沒有誇大不實的用詞？先列出你檢查的每一個判斷點，再給出最終結論。Code language: plaintext (plaintext)這類提示詞把「怎麼想」交代得很清楚，對話模型才有辦法照著這個路徑，一步一步走到正確答案。
推理模型：給目標、給限制，讓它自己找路
換到推理模型，提示詞要反過來做減法。OpenAI 官方對推理模型的建議很簡潔，把指令寫得簡單直接，先試零示例（zero-shot），真的有格式落差才補少量範例；同時清楚交代限制條件跟怎樣才算成功，而不是把過程步驟寫給它看。這跟對話模型的邏輯正好相反。你不是要教它怎麼想，而是要講清楚你要的結果長什麼樣、邊界在哪裡，剩下的路讓模型自己去找。
檢查這篇產品文案有沒有誇大不實的用詞。只要回覆有問題的句子與修改建議，不必說明你的判斷過程。Code language: plaintext (plaintext)Helicone 整理的對照範例也印證了這一點：同樣是問一個問題，直接問「古典制約和操作制約的主要差異是什麼」，推理模型表現得比鋪陳一大段背景資訊、再問同一個問題來得好。多餘的背景交代，對推理模型來說不是幫助，反而是雜訊，模型得先花力氣消化這些用不上的細節，才能找到真正要回答的問題。所以面對推理模型，提示詞越乾淨，模型越能把力氣專心用在真正的推理上。
三個問題判斷，這次任務該用哪一套下法？
邏輯釐清之後，真正要面對的是怎麼把判斷落實到手上這個任務。做法是用三個問題，由粗到細一路問下去。
- 這個任務要拆成幾步才能解完？ 步驟數是最關鍵的判斷依據。北京大學研究團隊做過一項分析指出，推理模型在需要五步以上的任務上表現最明顯突出；落在三到五步之間，推理模型只有小幅改善；少於三步的簡單任務，推理模型的表現反而可能不如對話模型。任務越簡單，越不需要勞師動眾請推理模型出馬，更不用在提示詞裡疊加思維鏈指令，那等於是在一個不需要想太多的任務上，硬逼模型演一齣想很多的戲。
- 問題本身定義清楚，還是模糊、帶著沒說出口的假設？ 範圍明確、條件清楚的任務，對話模型搭配清楚指令就足夠應付；但如果問題本身模糊，容易讓模型帶著錯誤前提往下推論，這種情況更適合交給推理模型，而且提示詞裡最好明講「先列出你認定的前提，再往下解」，避免整個答案建立在一個沒被檢查過的假設上。
- 最後要不要結構化輸出，像是固定格式、JSON、表格？ 這一題容易被忽略，但很關鍵。同一份分析也指出，推理模型被要求嚴格輸出結構化格式時，表現反而不如傳統模型穩定。如果格式要求很硬，一個可行的分工是讓推理模型負責想，再交給對話模型負責排版，把想跟排這兩件事拆開，各自用擅長的模型去做。
三題都問完，多數情況只要抓住第一題的步驟數，就能決定大方向；後面兩題用來微調，問題模不模糊決定要不要交給推理模型多想一層，輸出要不要結構化則決定要不要拆成兩階段處理。
想再進一步，現在可以直接用參數調整推理深度
提示詞技巧講完，還有一件事值得知道，這兩年主流的推理模型平台幾乎都已經把「要不要多想、想多深」做成一個可以直接設定的參數，不必只靠提示詞裡堆字去引導。
OpenAI 的推理模型，思考深度是由一個叫 reasoning.effort 的參數控制，分成 none、low、medium、high、xhigh 五個等級。官方建議一般任務從 medium 起跳當作平衡點，對延遲敏感、要求快速回應的場景改用 low 甚至 none，真正碰到需要極致推理品質的任務才拉到 xhigh，而 xhigh 官方明講是留給最困難、品質優先的工作，不是預設值。另外還有一個 verbosity 參數，專門控制回答的詳細程度，跟 effort 控制的思考深度是兩件事，可以分開調整。
Anthropic 的 Claude 新一代模型，走的是調適型思考（adaptive thinking）：思考深度同時由一個 effort 參數，以及模型自己判斷的任務複雜度決定，簡單問題，模型會判斷不需要多想，直接給答案；複雜任務才會拉長內部思考。官方也提醒，延長思考會增加回應延遲，只有在真的能讓答案品質變好的情況下才該用，遇到簡單問題，提示詞不必硬性要求模型多想一輪，讓它直接回答就好。
Google 的 Gemini 則是用 thinking_level 參數，分 minimal、低、中、高四個等級。官方建議，單純的事實查詢或分類這類簡單任務，用低階（甚至 minimal）思考就夠；需要比較概念、帶點創意判斷的中等任務，用預設思考；真正碰到進階程式、數學計算、多步驟規劃這種複雜任務，才把思考等級拉到最高。
三家的做法雖然參數名稱不同，心法卻一致，先把提示詞本身寫清楚，定義好目標跟怎樣算成功，參數是最後才拿來微調的旋鈕，不是拿來取代把話講清楚這件事。
真的需要看到推理過程，還有什麼折衷做法？
不過，凡事總有例外。有些場景還是需要看到模型的中間推理，不能只靠「別下思維鏈提示詞」一刀切帶過，像是除錯、內容審核，或是任何需要對別人交代判斷依據的場合。你看不到模型怎麼想，就沒辦法確認它想得對不對，也沒辦法把理由講給別人聽。
這時候有一個折衷做法，不是完全不給引導，而是限制模型每一步推理的篇幅，讓它留下精簡但可追蹤的推理軌跡。Zoom Communications 的研究團隊做過一項實驗，把這個做法取名為思維草稿（Chain of Draft），概念是讓模型像人在打草稿一樣，只寫出最精簡但夠用的中間推理，而不是把每一步都展開成完整敘述。研究用的提示詞長這樣：
Think step by step, but only keep a minimum draft for each thinking step, with 5 words at most. Return the answer at the end of the response after a separator ####.Code language: plaintext (plaintext)這段指令要求模型推理時每一步最多只留五個字的精簡草稿，想清楚才進到下一步，最後在分隔符號後給出正式答案。實驗數據相當驚人，在一項體育常識判斷任務上，Claude 3.5 Sonnet 用完整思維鏈時平均要花 189.4 個 token 才能得出答案，準確率是 93.2%，換成思維草稿的寫法後，平均 token 用量降到 14.3 個，減少 92.4%，準確率反而提升到 97.3%。在算術、常識推理（如日期理解）、符號推理這類其他任務上，同一份研究也觀察到用字量減少近八成到八成六不等，準確率大致維持在接近完整思維鏈的水準，部分任務甚至打平。
換句話說，「要不要看到推理過程」跟「要不要讓推理過程拖累效率」，其實是兩件可以分開處理的事。不必為了保留可解釋性，就照單全收一大段又長又慢的思考過程。
提示工程走到這裡，重點其實已經悄悄挪位。過去教的是怎麼讓 AI 一步步想，現在真正該練的，是把你要的目標、限制條件、怎樣算成功講清楚，剩下的規劃交給模型自己去處理。思維鏈提示詞並沒有被淘汰，它只是換了戰場，留給還沒學會在內部自己想的對話模型，而不是每一次下筆都預設要加這一句。分清楚手上這個任務該問哪一套模型、該用哪一套邏輯，才是這個階段真正該練的判斷力。