2026 Prompt Engineering 快速手冊

這份 2026 prompt engineering 快速手冊整理 CRAFT、CoT、few-shot、JSON 與模型選擇，也說明為何 context engineering 變得更重要。

2026 年的 prompt engineering 變得更實用，也更挑剔。Prompt Architects 的內部測試跑了約 10,000 個 prompts，從無結構請求改成結構化框架後，輸出品質平均提升 62%。

這個數字很直白。真正拉開差距的，是結構，不是文采。你把 prompt 寫得更清楚，模型就比較少亂補洞，後面的人也比較好改。

結構比靈感更有用

LLM 不會讀你的心，只會讀 token。你給它的 prompt 越模糊，它就越容易吐出平均值很高、細節很差的內容。這也是很多團隊第一次上線 AI 功能時，最常踩的坑。

所以這份快速手冊一直在講同一件事。你不是在寫漂亮句子，你是在縮小模型的自由度。只要把角色、格式、限制講清楚，錯誤答案就會少很多。

這裡可以拆成三件事。第一是消歧義，讓每個限制都砍掉一部分錯誤輸出。第二是啟動語境，像「pricing strategist」或「securities lawyer」這種角色，會把模型推向對的詞彙。第三是可驗證性，像 table 或 JSON schema，讓結果能直接檢查。

• Role prompt 讓語氣和領域更準。
• Format prompt 讓輸出更好接系統。
• Tone prompt 讓內容少一點通用 AI 味。
• Constraint prompt 讓模型少亂發揮。

這也解釋了，為什麼同一套方法能在 OpenAI、Anthropic、Google Gemini 上都能用。底層模型不同，但人類要交代清楚的事一樣多。

常用框架其實不多

這篇文章的觀點很務實。日常工作常用的框架，大概五個就夠了。再多的名詞，多半只是把同一組概念換個順序。

最常見的是 CRAFT、Chain-of-Thought、CARE、RTF、few-shot。實務上，CRAFT 適合大多數任務；CoT 適合推理；few-shot 適合分類、抽取、格式對齊。

這種整理方式很適合團隊。因為你不用每次都重新發明 prompt。你只要先決定任務屬性，再選框架，速度會快很多。

“Think step by step. Show your reasoning, then give the final answer on a new line prefixed with ‘ANSWER:’.”

這句話來自 Chain-of-Thought prompting 的研究脈絡。作者之一是 Jason Wei。那篇研究把 540B 模型的推理表現拉起來，後來也成了很多產品團隊的模板。

實際上，你可以這樣選：

• 要通用 brief，用 CRAFT。
• 要多步推理，用 CoT。
• 要穩定格式，用 few-shot。
• 要快寫短任務，用 CARE 或 RTF。

CRAFT 最值得背下來

如果只記一個格式，我會選 CRAFT。它代表 Context、Role、Action、Format、Tone。這五個欄位很像寫給同事的工作說明，少廢話，也少誤解。

Context 說明情境。Role 指定模型要扮演什麼專家。Action 要求單一任務。Format 決定輸出長相。Tone 控制語氣。每一項都在減少模型亂補的空間。

舉例來說，如果你要做一個 B2B SaaS 的 usage-based pricing 方案，CRAFT 可以直接要求三個標題候選，再附一行 subhead，最後輸出成 markdown table。這種 prompt 很像編輯工作，不像聊天。

這也是它實用的原因。當 prompt 結構固定，後面的審稿、比對、轉成 API 輸出都會順很多。對產品團隊來說，這比「寫得像人」更重要。

你可以把 CRAFT 當成最小可用規格：

• Context：這次任務的背景。
• Role：模型要用哪種專業視角。
• Action：要交付什麼。
• Format：要 JSON、表格，還是條列。
• Tone：要正式、直接，還是偏口語。

推理、範例、格式會直接改變結果

這份手冊最有說服力的地方，在於它引用了研究數字。以 GSM8K 為例，8 個 Chain-of-Thought 範例把準確率從 17.9% 拉到 56.9%，再加上 self-consistency，最後到 74%。

這些數字很像老新聞，但在產品端還是有用。因為它說明一件事：單一答案常常不夠好，多次採樣再投票，往往更穩。

few-shot 也一樣。當任務邊界模糊，或輸出格式很硬時，2 到 5 個範例通常比一大段規則更有效。像客服分類、欄位抽取、品牌語氣對齊，都很吃這招。

• 分類任務常靠範例定邊界。
• 抽取任務常靠範例定欄位。
• 品牌文案常靠範例定語氣。
• JSON 任務常靠範例定格式。

這裡也要吐槽一下。很多人把 prompt 當成魔法咒語，想靠一句話解決所有問題。實際上，模型更像一台高敏感度的文字機器，輸入越清楚，輸出越像樣。

還有一個實務重點，是 sampling 設定。temperature 和 top-p 會影響創意和穩定度。要寫標準答案時，參數通常要保守一點；要發想時，才放寬一點。

2026 的重點是 context engineering

這篇文章最後的判斷很準。2026 年的重心，正在從 prompt engineering 移向 context engineering。意思很簡單，prompt 只是其中一塊，周邊資料才是整體品質的來源。

如果上下文不完整，模型還是會猜。這時候你再怎麼修 prompt，效果都有限。你需要的是正確的背景、範例、限制、文件來源，還有適合的檢索資料。

所以文章也提到什麼時候該用 prompt，什麼時候該用 RAG，什麼時候該做 fine-tuning。這三者差很多。Prompt 是最快的修正方式。RAG 適合補知識。Fine-tuning 適合固定模式。

對做產品的人來說，這個分界很重要。你如果只是想改善一個工作流，先改 prompt 很合理。你如果要穩定回答事實問題，就該先補知識庫，不要硬改字眼。

如果你今年在做 AI 功能，我會直接給這個順序：

• 先用 CRAFT 寫清楚需求。
• 推理任務再加 CoT。
• 格式容易飄，就補 few-shot。
• 事實不夠，就上 RAG。
• 模式固定，再考慮 fine-tuning。

這套方法對台灣團隊也很實際

台灣很多團隊現在都在做 AI 助理、內部知識搜尋、客服自動化，或是文件摘要。這些場景很少需要花俏 prompt，反而很需要穩定輸出、欄位一致、語氣可控。

所以這份手冊的價值，不在於教你寫得多聰明，而是教你把需求寫得像規格。當 prompt 變成可維護的資產，團隊才有辦法一起用、一起改、一起追版本。

如果你要挑一個最先導入的做法，我會選 JSON 輸出。因為它最容易接後端，也最容易做驗證。接著再補 CRAFT，最後才是 CoT 和 few-shot。

下一步很明確：把你現在最常用的 3 個 prompt，全部改成 CRAFT 格式，再看錯誤率有沒有下降 20% 以上。這種改善通常比你多背十個框架更有感。