為什麼「問法」能決定答案的品質
要講清楚這件事，得先知道大型語言模型到底在做什麼。它不是一個裝滿知識、你按下按鈕就吐答案的資料庫，它的核心其實是一台「接話機器」：根據你給的上下文，一個字一個字去預測「接下來最可能出現的字」。你給的提示，就是它接話的全部依據。
這就解釋了為什麼同一個任務，隨便丟一句跟交代得清清楚楚，結果會差那麼多。當你的指令含糊，模型面前是一大片「都說得通」的可能答案，它只能挑一個機率高的接下去，未必是你要的那個；當你把角色、背景、格式、限制都講明白，等於把這片可能性一路收窄，逼它往你要的方向走。這裡面沒有玄學，就是把一個機率分布「條件化」的過程——線索給得越準，落點就越靠近你心裡的那個答案。
不同模型、資料集、提示、判分方式與正式流量，結果可能差很多。公開 benchmark 只能用來理解方法，不能直接當成專案承諾；驗收應使用公司自己的題庫，分別記錄正確率、引用支持率、拒答、延遲、成本與人工覆核量。
幾個經得起驗證的實用技巧
底下這幾招，都不是我自己拍腦袋想的，是這幾年被反覆驗證、也最容易上手的。
先把角色和任務講明白
與其丟一句「幫我看這份合約」，不如說「你是一位審約助理，請找出這份合約裡關於付款期限與違約金的條款，逐項列出並註明在第幾條」。把角色設定、要做的事、輸出長什麼樣子一次交代清楚，品質會差非常多。原理還是同一個：你替模型把場景框好了，它就不必在一堆可能性裡亂猜。如果你是在寫系統提示（system prompt），把角色跟語氣放進去，等於幫整段對話定了調，後面每一次回覆都會照這個基準走。
與其描述格式，不如直接給範例
很多人會用一大段文字去描述「我要什麼格式」，其實遠不如直接丟一兩個範例給它看，這招叫少樣本示範（few-shot）。範例的威力在於，它同時把格式、語氣、連邊界狀況該怎麼處理都示範了一遍，比你用形容詞去描述精準得多。有一點要提醒：範例不是越多越好。研究上的經驗是，多數任務給三到五個就夠，超過五到八個之後效果就邊際遞減，只是徒增成本。挑那種最典型、最能代表你要的樣子的例子，比堆一大堆更有用。
需要動腦的題目，要它先想再答
碰到要推理、要算、要判斷的問題，請它「先分析、把步驟寫出來，再給結論」，往往比劈頭就要答案可靠得多，這就是所謂的思維鏈（chain-of-thought）。它為什麼有效？因為模型是邊寫邊算的，把中間推理一步步攤在文字上，等於給了它更多「想的空間」，而且每一步又替下一步鋪好了條件，錯誤就不容易一次崩掉。有意思的是，就算完全不給範例，只在問題後面補一句「請一步一步思考」，在推理題上都能看到明顯的提升。想再穩一點，還可以讓它把同一題算個幾遍、取多數決（這叫自洽性 self-consistency），在數學題上又能再拉高一截。不過也別無腦全套上——現在有些模型內建就會自己跑這套推理，簡單的任務再硬要它長篇大論，只是白花錢又拖慢速度。
用分隔符把「你的指令」和「要處理的資料」分開
這一招看起來不起眼，回報卻高得驚人。當你的提示裡同時混著指令、背景、範例，還有一段要它處理的原始資料，模型有時會分不清哪句是「要它做的事」、哪段是「被處理的對象」。解法很簡單：用明確的分隔符把不同性質的東西包起來，例如把待處理的內文用三個反引號框住，或用類似 <instructions>、<context>、<input> 這種標籤各自標明。只要花三十秒把使用者丟進來的內容包進一個分隔區，就能一口氣消掉一整類的誤判。附帶一個很大的好處：這樣做同時也是資安上的防線，等一下談風險時我會再回頭講。
限定依據作答，還要允許它說「不知道」
這條在企業場景裡特別關鍵。你要先明白，模型講錯話其實有兩種很不一樣的毛病：一種是它講的東西跟真實世界不符（事實性錯誤），另一種是它講的東西跟你「明明給了它的資料」對不上、自己加油添醋（忠實性錯誤）。企業最怕的往往是後者。對付它，最基本也最管用的一句指示就是：「只根據我提供的資料回答，找不到就說不知道，不要自己編。」關鍵在後半句——你要明白給它一個「可以認輸」的許可，很多幻覺就是被逼著非答不可才硬生出來的。但也要提醒：就算你這樣講了，模型有時還是會塞進沒根據的細節，所以碰到高風險的答案，該補一道人工或程式的查核，別把命全押在一句提示上。
什麼時候該停手，改上 RAG 或微調
提示工程厲害歸厲害，但它有個天生的極限：它沒辦法讓 AI 知道它本來就不知道的事。你公司內部的報價邏輯、產品規格、歷年案例，這些模型從沒學過，你再會問也問不出來。這時候硬凹提示是浪費時間，該往上一階走了。
我通常會建議按這個順序爬：先把提示調到位，不夠再上 RAG，真的還不夠，才考慮微調。這個順序不是憑感覺，是照成本跟效益排的。提示幾乎零成本，只花你一點 token；RAG（檢索增強生成）是替模型接上你的知識庫，讓它引用你自家的資料來作答，投入中等；微調則要準備資料、花算力去訓練，前期成本最重，而且知識一變還得重訓。
幾個最常見、也最花冤枉錢的誤區
- 以為提示越長越好。塞一堆不相干的背景進去，反而會把真正的指令稀釋掉，重點還可能被埋在一長串中間、被模型忽略。提示要的是「準」，不是「長」，講清楚就好，別灌水。
- 技巧無腦全疊。簡單任務也硬要它長篇推理、又給一堆範例，只是拖慢速度、多燒 token。什麼題用什麼招，是要判斷的，不是招數越多越厲害。
- 沒有評測，全憑感覺。這是最要命的一個。你改了提示覺得「好像變好了」，到底是真的變好，還是自己的錯覺？沒有一小組標準答案去比對，你永遠不會知道。哪怕只準備十題、二十題有正解的樣本，每次改動都跑一遍對照，你的優化才算站得住腳，不然就是在賭。
- 迷信一句到位。好提示幾乎都是改出來的，不是一次寫成的。把它當成一個要反覆微調的過程，別指望第一版就完美。
企業導入時，別忘了適用邊界與風險
前面講分隔符時我留了個伏筆，這裡補上。當你的 AI 開始會去讀外部內容——像是客戶寄來的信、系統裡的工單、網頁、上傳的文件，甚至知識庫裡的某一篇——風險就跟著進來了。因為那些內容裡可能藏著「假裝成指令」的句子，誘導模型去做你沒授權的事，這叫提示注入（prompt injection），而且它長年都是這類系統裡最常被拿來攻擊的弱點。
防這件事沒有單一神招，得層層設防：把外部讀進來的東西一律當「資料」而不是「指令」來對待（分隔符就是這道防線的第一步）、給 AI 的權限抓到剛好夠用就好、涉及動錢或對外發送這類高風險動作一定要留一關人工確認，再定期拿刁鑽的輸入去測它。這些聽起來麻煩，但只要你的 AI 會碰到外部內容，就非做不可，不是可選項。
把提示變成整個團隊的資產
最後我想強調，提示工程不該只是工程師的事。客服、行政、業務，只要會用 AI、懂得把問題問清楚，產出的品質就明顯不一樣，這是一門低成本、高回報的內功。
比較聰明的做法，是把公司裡好用的提示整理成範本，統一收好、還做個版本管理，讓大家共用；再配上前面說的那一小組評測題，每次改版都驗過一次。這樣一來，提示就不再是某個人腦袋裡的手感，而是會累積、能傳承的團隊資產。用久了你會發現，這件事比你想像中值錢。
廷皓科技在高雄，我們協助南台灣的企業建立好用的提示範本、訓練同仁把 AI 問對問題，需要時再往上搭配 RAG 與地端部署，把公司專屬的知識補進去。在你打算花大錢微調、或換更貴的模型之前，先把提示這個最划算的基本功練到位——真的，很多問題到這一關就解掉了。有需要，歡迎找我們一起把它調對。
