如何寫出更好的 AI 提示詞，起點是一份小型任務說明，而非神奇口令。告訴 AI 工具要做甚麼、可用哪些資料、必須保留甚麼，以及你怎樣評定結果。大多數提示詞只要收窄任務、讓完成標準清晰可見，就能改善。

關鍵要點

界定一項交付物，並寫出清晰可見的完成標準。

只加入相關而且已脫敏的上下文。

令限制、格式、示例和複核步驟都可以檢驗。

在通過你的檢查之前，把結果視為草稿。

**示例任務（截圖中未顯示）：**把一段公開的說明文字改寫成面向初學者的版本，保留每個產品名稱和數字，並把沒有根據的主張標記為 [verify]。

**速記規則：**任務 + 上下文 + 限制 + 格式 + 複核。

1. 寫清任務是如何寫出更好的 AI 提示詞的第一步

用一個動詞說明交付物：

較弱：「幫我處理這封電郵。」
較好：「把這封客戶電郵改寫成冷靜、專業的語氣，並控制在 120 字以內。」

說明你要的是草稿、比較、提綱、清單、翻譯、資料擷取還是評論。除非為每項交付物訂明次序和格式，否則不要在同一輪要求幾項無關的交付物。

2. 哪些上下文真正有用？

提供讀者、目的、來源材料、限期和相關限制。不要加入密碼、API 密鑰、身份證明文件、客戶記錄或機密程式碼。以佔位符取代敏感數值，只描述資料的結構。

AI 工具私隱風險指南解釋了為何提示詞本身就是一道資料界線。

3. 怎樣令限制可以驗收？

避免使用「好看」「專業」「完整」這類沒有定義的字眼，改用可以檢查的條件：

含糊要求	可檢驗的限制
寫短一點	100–130 字；保留列出的三項事實
語氣友善	使用淺白語言；不指責；以一個清晰的下一步作結
加上來源	每項時效性主張附一個來源；沒有根據的主張標記 `[verify]`
修正程式碼	不改公開 API；為邊界條件加入一個測試案例

如果某項要求比文風更重要，就把它放在最前面，並在複核請求中再次強調。

4. 指定輸出格式

清楚告訴工具應怎樣交回結果。例如：

「交回一個表格，欄位為 claim、evidence、risk 和 next check。不要虛構引用。欠缺證據時寫 not verified。」

格式令欠缺的資料更容易被發現，也方便比較不同輪次的答案。

5. 謹慎使用示例

一個小示例就能展示你想要的細節程度或語氣。把它標明為示例，而不是事實。如果示例中有姓名、數字或程式碼，一律使用虛構內容。不要要求工具模仿真實人物，或照抄受保護的文字段落。

6. 複核環節應包括甚麼？

不要讓工具默默地「把所有內容再檢查一次」，而要給它一份清單：

列出你所作的假設。
標出需要現行來源支持的主張。
把答案與每項限制逐一對照。
顯示相對於所提供文本的改動。
說明哪些內容你無法核實。

這只是複核輔助，不是證明。你仍需親自打開來源，檢查有後果的輸出。日期、數字或引用舉足輕重時，按逐項核對主張與來源的方法檢查。

7. 分小步迭代

採用三輪模式：

第 1 輪：提綱

要求列出小標題、假設和欠缺的輸入。在要求完整文稿之前，先修正計劃。

第 2 輪：草稿

一次只要求一個章節或一種轉換，並把原文放在手邊以便對照。

第 3 輪：評估

要求一份限制檢查清單和未解決的問題。如果結果仍然虛構細節，就停下來，提供更好的來源，或改以人手完成。

8. 把同一個提示詞改寫三次

看看這個請求：「寫一份這次事故的總結。」它沒有說明讀者、來源界線、篇幅和敏感程度。較安全的第一次改寫是：

「只使用以下已脫敏的事故筆記，為內部支援團隊草擬一份 150 字的總結。把已確認的事實和未解決的問題分開。不要寫出客戶姓名，不要推斷根本原因，也不要加入筆記沒有的時間線。」

這個版本令交付物和排除項目清晰可見。再加上格式，就更容易檢驗：

「交回四個小標題：影響、已確認的時間線、目前的緩解措施、未解決問題。每個小標題下使用要點。凡是來源沒有回答的欄位，在旁邊寫上 [not in notes]。」

最後，加入一輪評估，而不是讓模型默默自我檢查：

「草稿之後，列出每一項事實陳述、支持它的筆記，以及任何屬於詮釋的措辭。檢查姓名、數字和時間戳記沒有被改動。」

三個提示詞服務於不同階段：快速腦力激盪不必用最繁複的版本；結果會影響重要決定時，也別只用最短的版本。

9. 讓示例安全且具代表性

示例能展示細節程度和輸出形式；風險是它可能含真實個人資料，或悄悄變成指示。使用虛構姓名、合成數字和公開文本。把示例標明為示例，並說明哪些事實必須保持不變。

翻譯提示詞可以附上一小段自擬文字，並說明產品名稱、程式碼或法律用語是否必須原樣保留。程式提示詞應提供細小而可重現的輸入和預期輸出，而不是整個私人儲存庫。研究提示詞可以提供兩個公開來源，要求製作比較表；不要讓工具虛構欠缺的第三個來源。

模型過分照搬示例時，就縮短示例，以文字描述規則。它忽略某項限制時，把該限制移到獨立清單，要求交回「通過／不通過」報告。提示詞應揭露失敗，而不是用漂亮的示範把失敗掩蓋。

10. 用輸出評估提示詞

每次執行後，按事先寫明的驗收條件為結果評分：

覆蓋度： 有否處理每一個必填欄位？
忠實度： 有否保留事實、姓名、單位和來源界線？
格式： 其他人能否快速檢查結果？
不確定性： 有否標出欠缺或有爭議的資料？
安全性： 有否避開秘密、沒有根據的主張和未經授權的操作？

把失敗的輸出脫敏後保存為測試案例。在友善示例上表現良好、遇到欠缺欄位就失敗的提示詞，還未可以重用。保留一小組邊界案例：空白輸入、互相矛盾的指示、附有例外條款的來源，以及一個應被拒絕的請求。工具、模型或來源格式有變時，重新執行這些案例。

11. 使用範本但不要製造虛假的確定感

範本可以把你記得要問的問題標準化，卻無法保證答案正確。把「來源」「假設」「複核人」這類欄位視為必填輸出，而不是它們準確無誤的證明。讓工具在欠缺證據時交回 unknown，並由人類複核人負責判斷結果能否使用。

範本要短到同事真的會去閱讀。把任務和風險最高的限制放在最前面。刪除不會改變輸出的指示，亦絕不要求用戶貼上密碼、復原碼、未脫敏記錄或機密來源材料。分享範本時，寫明其目標讀者、資料界線和停止條件。

12. 把起草和批准分開

再好的提示詞也不能授予權限。如果輸出將會發布、傳送給客戶、合併到程式碼或用於某項決定，就把批准列為獨立步驟。讓工具提供草稿和複核清單，再由人把草稿與來源對照，並批准相應行動。這種分工也令轉用其他工具更容易：即使介面或模型改變，驗收條件依然一樣。

草稿被拒絕時，以淺白語言記錄原因；同類失敗可能再現，就補上一個小測試案例。日子久了，提示詞會成為精簡的規格說明，附有可接受和不可接受輸出的示例。這份記錄比巧妙措辭更有價值，尤其是日後需要他人覆核時。

把驗收測試放在提示詞旁邊。

在小型樣本上測試提示詞

重用提示詞之前，用幾個具代表性的輸入測試，包括一個空白欄位、一項互相矛盾的指示，以及一個應被拒絕的情況。檢查輸出有否保留必需事實、依照格式、標出欠缺的證據，而且沒有虛構細節。示例中不要包含秘密和個人資料。小型評估集能在你更換模型、來源格式或讀者時揭示退步，比假設一次出色的首個答案能套用到所有情況更有用。

可重用的 AI 提示詞範本

任務：[一項交付物和完成標準]
讀者：[誰會使用這個結果]
上下文：[相關而不敏感的事實]
限制：[必須保持不變或必須排除的內容]
輸出：[格式、長度和次序]
證據：[可使用的來源；標出欠缺支持之處]
複核：[假設、改動和未解決的問題]

把範本當作起點，而不是例行儀式。刪除不影響任務的欄位。

常見失敗方式

範圍太闊： 答案包羅萬有，卻沒有解決任何問題。收窄交付物。
讀者不明： 語氣和細節都不對。寫明讀者是誰。
不可信輸入： 提示詞夾雜了來自網頁或檔案、與你目標相衝突的指示。把它們視為資料，並重新說明你的任務。
虛假精確： 因為你要求提供數字，工具便虛構了一個。要求它在欠缺證據時交回 unknown。
沒有驗收檢查： 一份潤飾得很好的草稿，未能符合一項你從未說明的要求。加入一份檢查清單。

總結

把提示詞寫成細小而可複核的規格說明：說明任務，加入安全的上下文，界定限制，選擇格式，並要求不確定性清晰可見。然後把答案與提示詞對照，親自核實重要主張。

上述提示詞模式以所引用的提示詞設計、私隱和風險管理指引為依據。［1］［2］［3］

常見問題

提示詞越長越好嗎？

不是。多餘的上下文可能分散工具的注意力，或暴露敏感資料。只放入會改變結果的資料。

應該要求 AI 一步一步思考嗎？

有需要時，可以要求它提供簡潔的理由、假設或檢查清單。你不必要求它展示隱藏的推理過程，重點應放在可以核實的輸出。

同一個提示詞適用於所有 AI 工具嗎？

一般原則可以沿用，但各工具的功能、上下文上限、私隱控制和輸出格式都不同。請查閱供應商的最新文件。

答案錯誤時應怎樣處理？

找出第一項錯誤的主張，提供可靠來源或欠缺的限制，然後重新執行一個較小的任務。如果錯誤持續出現，就停止使用該輸出。

VPN 會改善提示詞嗎？

不會。VPN 或可保護網絡路徑，但它不會提升推理能力，也不會改變供應商的帳戶和產品規則。

免責聲明：本文只供一般資訊參考，不構成專業建議。不要向公共 AI 服務傳送秘密或未經脫敏的個人、醫療、財務、客戶或專有資料。

來源：

Google — Prompt design strategies — https://ai.google.dev/gemini-api/docs/prompting-strategies
OpenAI — Prompt engineering — https://platform.openai.com/docs/guides/prompt-engineering
NIST — Generative AI Profile — https://www.nist.gov/itl/ai-risk-management-framework

Sources checked 2026 年 8 月 22 日。

延伸閱讀：

如何寫出更好的 AI 提示詞：把含糊請求改成可驗收的任務說明