ChatGPT Prompt 教學：寫出可驗收的工作指令

Prompt、脈絡、輸出契約與驗收循環的概念圖。操作示意圖／非官方介面截圖。
Prompt、脈絡、輸出契約與驗收循環的概念圖。操作示意圖／非官方介面截圖。

ChatGPT Prompt 教學：寫出可驗收的工作指令

ChatGPT Prompt 教學真正要解決的，不是把一句話改得更像咒語，而是讓 ChatGPT 知道要完成什麼、可以使用哪些資料、結果要長什麼樣子，以及你會用什麼條件判斷它有沒有完成。這四件事沒有交代清楚，Prompt 寫得再長，也可能只是把模糊要求包裝成一大段文字。

如果你只想偶爾問問題，短 Prompt 通常已經夠用。如果你要重複處理文章、整理研究資料、清理欄位或產生固定格式的報告，就應該把 Prompt 當成一個小型工作規格。它不需要一次寫到完美，但需要可以測試、修改和回查。

本文是對 NICROW 舊有 Prompt 文章的更新。舊 URL 保留不變，內容則移除 2023 年的產品畫面和過時例子，改用目前可查到的 OpenAI、Anthropic 與 Google 官方 Prompt 文件，整理一套不依賴特定介面的寫法。文中不承諾你的 ChatGPT 帳號有某個方案或按鈕，也不把某一種標籤格式說成唯一標準。

ChatGPT Prompt 教學先講結論：可驗收比華麗更重要

一個值得保留的 Prompt，至少要回答四個問題：這次任務的目標是什麼，ChatGPT 可以依據哪些脈絡，輸出必須遵守哪些格式，最後要怎麼檢查結果。你可以把它簡化成一條工作鏈：任務，脈絡，輸出契約，驗收。

這個順序比「請你扮演世界頂尖專家」更重要。角色描述有時能補充語氣、讀者或專業背景，但它不能替代資料，也不能替代判斷條件。若讀者、資料範圍和輸出格式都沒有寫，前面那句角色設定通常只是在增加氣氛。

OpenAI 的ChatGPT 提示工程最佳實務把清楚、具體、提供背景和反覆迭代列為基本方向。OpenAI 的API Prompt Engineering guide也提醒，模型之間的行為可能不同，Prompt 需要配合測試和 eval，而不是只在一個漂亮案例上判斷成功。這些原則可以用在日常 ChatGPT 工作，但不表示每個 ChatGPT 帳號都會有相同介面或功能。

先把「會用」改成「能檢查」

「幫我把這篇文章寫得更好」是一個可以開始對話的要求，卻還不是一個可驗收的工作規格。你至少需要補上文章讀者、改寫目標、不能改動的事實、希望保留的語氣，以及交付格式。完成後，驗收也要能說出什麼算通過，例如保留原有數字、標出不確定處、輸出三個標題版本，或把每個修改理由放在表格中。

「請給我最好的答案」也不是驗收條件。最好對誰最好，依據是正確、完整、短、可執行，還是符合公司格式？如果你沒有選定判斷標準，模型只能根據當下脈絡猜測。它可能交付一篇讀起來很順的答案，而你真正要的是一份能直接貼進試算表的資料，這種落差很常見，也不必怪模型先怪規格沒有寫完。

一個可工作的 Prompt 要交代哪些事

下面這張表是我在寫工作 Prompt 時會先檢查的骨架。它不是官方唯一格式，也不要求每次都用固定標籤。重點是每個欄位要解決不同的失敗來源。

Prompt 元件它要說清楚什麼缺少時常見的結果何時可以簡化
任務要完成的動作和目的回答方向正確但沒有完成工作只是一次簡單問答時
脈絡讀者、背景、資料範圍和已知事實答案泛泛而談，或把不相關資訊帶進來問題本身已包含必要背景時
限制字數、語氣、不可改動項目、禁止事項結果看似完整，卻不符合使用場景沒有格式或風險要求時
輸出契約欄位、順序、格式和缺值表示法每次回答的結構都不同只需要一段自由回答時
範例一兩個輸入和合格輸出模型誤解你的分類或語氣規則已經非常清楚時
驗收你會檢查什麼，以及不合格怎麼處理很難比較版本，也不知道是否改善臨時探索、不會重複使用時

先寫任務，再寫角色

任務句應該先寫動詞和交付物，例如「把以下客服紀錄整理成待追蹤事項表」，不要先寫「你是一位非常有經驗的客服主管」。角色可以在任務之後補充判斷角度，但真正需要執行的動作要先出現。

我會把任務句寫成三段：對什麼資料做什麼動作，目的是支援哪個決策，最後要交付什麼。比如說：「請閱讀以下訪談逐字稿，整理出仍需確認的產品需求，讓產品經理能安排下一輪訪談，輸出成四欄表格。」這句還不完整，但至少已經比「分析這份訪談」更容易追問和驗收。

角色設定不是沒用，而是有適用範圍。需要固定術語、讀者層級或審閱角度時，可以寫「以第一次接觸這個主題的行銷同事能理解為準」，這比堆疊「頂尖、專業、權威」更可操作。角色不會自動替你補上缺少的來源，也不會保證答案正確。

把脈絡和資料邊界寫出來

脈絡是 Prompt 最容易被低估的一層。你應該說明資料來自哪裡、哪些內容可信、時間範圍到哪一天、哪些欄位可以修改、哪些只能原樣保留。如果資料中可能有空值或互相矛盾的說法，也要先決定輸出要標成「待確認」還是保留兩個版本。

OpenAI 的 API 文件建議在指令中提供相關脈絡，並把指令與資料分開。實作上，你可以使用一般文字標題、三個井字號、引號或其他清楚的分隔方式，沒有必要迷信某一組標籤。分隔符號的功能是讓人和模型比較容易看出「這是規則」還是「這是待處理資料」。

例如，整理一段研究資料時，可以把「工作規則」、「參考資料」和「輸出格式」分成三段。若讀者貼入的原文含有看起來像指令的句子，還要寫明它是資料，不是本次任務的新增規則。這不會讓 Prompt 變成完整的安全系統，但能減少工作規格和來源文字混在一起的機會。

脈絡也包含缺席的資料。若你要比較兩個方案，卻只貼了方案 A 的條件，就不要只寫「請客觀比較」。應該改成「目前只有方案 A 資料，方案 B 缺資料時請列出未知欄位，不要自行補值」。這樣你得到的會是可追查的缺口，而不是一份表面平衡、實際上混入猜測的比較。

用輸出契約取代抽象要求

輸出契約就是交付格式的簡短規格。它可以包含欄位名稱、順序、資料型態、字數、空值寫法和需要附註的情況。要不要使用 JSON、Markdown 表格或條列式，取決於下一個使用者是人、文件還是程式，不是取決於哪種格式看起來比較高級。

如果結果要交給另一個工具，欄位名稱和格式就要寫得更嚴格。如果結果只供人快速閱讀，Markdown 表格或固定小標題通常比較易讀。你也可以同時要求「先給三句摘要，再給表格」，但要注意這會增加輸出層次，驗收時也要檢查兩個部分是否互相一致。

一個實用的輸出契約通常會寫出以下內容：

  1. 先輸出什麼，後輸出什麼。
  2. 每個欄位的名稱和定義。
  3. 找不到資料時要寫什麼。
  4. 哪些結論需要引用原文或標出依據。
  5. 超過範圍時要縮短、分頁，還是回報無法完成。

「不要胡說」比較像願望，不是完整規格。你可以把它改成「沒有在提供資料中找到依據時，將該欄位填為 unknown，並在備註說明需要什麼資料才能確認」。這樣才有可觀察的行為，也方便你在測試時檢查。

範例要用來固定判斷，不是裝飾

few-shot 範例適合處理規則難以用一句話說清楚的任務，例如品牌語氣、客服分類、欄位標準化或摘要層級。範例不一定要很多，但每一個都應該讓模型看出你在乎的判斷。只放一個很漂亮的正例，常常不足以說明邊界；加一個不應該歸類的反例，反而更有幫助。

範例也必須和實際資料相似。你拿一段短句示範，卻把真正任務換成長篇合約，可能只固定了表面格式，沒有測到長度、例外和缺值。若範例含有過時產品名稱、真實個資或不再適用的規則，也要在 Prompt 裡標示日期並先移除敏感內容。

OpenAI 的官方 API 指南把 zero-shot、few-shot 和微調視為不同層次的選項。這不代表加入範例一定比不加好，而是當清楚指令仍無法固定輸出時，可以用少量代表案例降低歧義。先測一小組案例，再決定是否需要增加範例，比一次貼上大量歷史對話更容易找出真正有效的部分。

ChatGPT Prompt 教學實作：從模糊要求改成工作規格

以下用一個不依賴特定產品介面的例子說明。假設你要把讀者回饋整理成產品團隊可處理的項目。這不是要展示某個神奇 Prompt，而是示範每次修改應該解決哪個問題。

第一版先保留原始問題

第一版可以是：「請分析下面的使用者回饋，整理出重要問題，並提出建議。」

它的好處是快，缺點也很明顯。「重要」沒有定義，「問題」和「建議」的範圍不清楚，輸出格式也沒有決定。模型可能回傳摘要、優先級、產品點子或一篇評論，這些都不一定錯，但你很難說它有沒有完成同一件事。

不要急著在第一版塞進十種角色、十個限制和一長串禁止事項。先保留它，另外記下你希望結果符合的條件。這樣後面的修改有比較對象，不會陷入「我只是覺得新版比較順」的主觀判斷。

第二版加入任務、脈絡和限制

第二版可以改成：

「請閱讀〈使用者回饋〉，找出會阻礙使用者完成付款的具體問題。只使用回饋文字中可以支持的資訊，不要推測未提到的原因。將相似回饋合併，保留能代表原意的短引句。請以產品經理需要安排後續工作的角度整理。」

這一版先固定任務和資料邊界，還沒有要求複雜格式。你可以用三到五筆已知結果的回饋測試它，觀察模型是否把抱怨、問題、功能建議和付款失敗混成同一類。若分類邊界仍然不穩，才需要增加定義或範例，不必先把整段 Prompt 寫成牆。

注意「只使用回饋文字中可以支持的資訊」不是資料驗證的替代品。它只是工作規格的一部分。真正的來源完整性、重複資料、時間範圍和權限，仍然要由你提供資料的人或流程確認。

第三版補上驗收條件

第三版可以再加上輸出契約：

「請輸出 Markdown 表格，欄位固定為：問題摘要、代表引句、影響的付款步驟、證據不足處、建議下一步。問題摘要限 30 字內，代表引句不得改寫。若回饋沒有指出付款步驟，填入 unknown。若同一回饋同時包含兩個不同問題，分成兩列，但不要新增其他欄位。表格後列出三項驗收結果：是否只使用原文、是否標出 unknown、是否保留原句。」

現在你可以檢查的不只是「讀起來像不像分析」，還包括欄位是否固定、引句是否被改寫、缺少資料時是否寫出 unknown。如果第三版仍然漏掉某個明顯問題，你要先記錄是哪一筆資料和哪條規則失效，再決定是補 Prompt、補範例，還是重新定義任務。

這個例子沒有使用神秘的系統提示，也沒有保證每次輸出都正確。它只把決策拆成可觀察的條件。當條件清楚後，Prompt 的修改才有方向，日後也比較容易交給別人維護。

六步驟建立自己的 Prompt 測試流程

如果這個 Prompt 只會用一次，做到前面的輸出契約可能已經夠了。如果它會每天或每週重複使用，我會加上下面六個步驟。這是依據官方文件強調的測試與迭代整理出的實作建議，不是 ChatGPT 的保證功能，也不是唯一流程。

  1. 先定義交付決策。 寫下這份輸出要支援誰的什麼決定。若沒有決策場景，後面的「完整」很容易變成越寫越長。
  2. 準備固定的小型案例。 選幾筆正常資料、邊界資料、缺值資料和容易誤判的資料。案例不用先追求大量，但每筆都要知道為什麼放進測試。
  3. 記錄基準版本。 保存原始 Prompt、使用的模型或產品入口、查驗日期和輸入資料。不同模型或版本可能有不同表現，不能把條件換掉後還說是 Prompt 改善。
  4. 一次只改一個主要變因。 先補輸出格式，下一輪再補範例，或先調整任務定義。一次改十處，結果變好時你也不知道是哪一處有用。
  5. 按失敗類型標註結果。 把問題分成漏資料、誤分類、格式錯、沒有標示未知、語氣不合或超出範圍。不要只留下「這次不好」的感想。
  6. 保留通過條件和已知限制。 新版通過固定案例後，仍要寫下它沒有測到什麼。通過五筆資料不代表可以直接處理所有正式資料，更不代表可以取消人工抽查。

OpenAI Cookbook 的評估飛輪範例將分析失敗、量測結果和改善 Prompt 放在循環裡，並指出一個 Prompt 可能在某天看起來有效，遇到邊界案例卻失效。Anthropic 的Prompt Engineering overview也把成功標準和經驗測試放在 Prompt 修改之前。兩份文件的產品脈絡不同，但對日常工作的提醒相同：先說明什麼叫成功，再用案例驗證。

測試結果最好寫成簡單紀錄，而不是只存最後一版 Prompt。至少保留日期、輸入案例、輸出、失敗分類和你的處理決定。若結果要進入正式內容、客服回覆或資料庫，再加上人工複核和回滾方式。Prompt 是文字檔，不代表它沒有版本和風險。

不同工作情境怎麼調整 Prompt

同一套骨架可以套用在不同工作，但欄位的重量會變。下面是我會用來決定先補哪一層的簡表。

工作情境優先寫清楚的部分建議的驗收方式常見未知
文章改寫讀者、不能改動的事實、語氣和篇幅對照原文數字、專有名詞和段落結構原作者真正想保留的語氣
研究整理來源範圍、查證日期、引用方式和缺資料標記抽查每個結論是否能回到來源來源是否完整、是否有最新版本
資料清理欄位定義、標準化規則、空值與衝突處理用含錯字、空值和重複列的測試資料原始資料的真實意義
會議摘要參與者、決議、待辦、負責人和期限對照逐字稿，檢查每個待辦是否有依據口頭承諾是否已正式確認
腦力激盪問題邊界、受眾、資源限制和產出數量檢查是否仍在題目範圍，並由人挑選哪個想法真的值得投入

這張表不是在替任何工作設定固定格式。它的用途是提醒你，驗收條件要跟下一步決策一致。研究整理最怕來源與日期不清，資料清理最怕欄位定義含糊，腦力激盪則不該把「新奇」假裝成已驗證的商業機會。

如果你的工作跨越好幾種情境，與其做一個超長萬用 Prompt，不如拆成共用規則和任務專用規則。共用規則處理輸出語言、未知值和基本格式，任務專用部分處理該次資料與判斷標準。這樣一條規則變更時，不必重新檢查一整段和它無關的內容。

Prompt 失效時，先判斷是不是 Prompt 的問題

Prompt 失效時，第一個反應通常是再加三段指令。這有時有效，但也可能把真正的問題藏起來。下面按照失敗表現拆開看。

結果錯，可能是資料或任務定義不完整

如果 ChatGPT 把資料中沒有的內容當成事實，先檢查你是否提供了足夠的來源和時間邊界，再檢查任務是不是要求它完成資料本身無法支持的推論。把「請不要猜」寫五次，不會自動產生缺少的資料。

比較好的寫法是明確處理未知：告訴它哪些結論需要來源，找不到來源時寫 unknown，並把需要補查的欄位列出。接著你仍然要自己確認輸出，尤其是醫療、法律、財務或會影響他人的正式決定。Prompt 只能描述流程，不能取代專業審查和權限控制。

如果任務本身含有兩個互相衝突的目的，例如同時要求「極度精簡」和「保留所有背景」，你應該先決定優先順序。把互相衝突的要求全部保留下來，再期待模型自行調和，最後通常只會得到一個沒有明確取捨的折衷答案。

格式亂，先檢查輸出契約

格式不穩時，先把欄位、順序、空值和例外寫清楚，並提供一個短小的合格範例。不要只說「請專業地輸出 JSON」，因為專業不是可解析的欄位定義。若結果要被程式讀取，還要在工作流程中檢查解析失敗，不要把格式要求當成程式驗證。

有時格式亂是因為任務太長，或一次要求摘要、分類、評論和改寫。你可以把工作拆成兩個階段，先抽取結構化資料，再由人或下一個 Prompt 生成可讀文字。這不是所有案例都需要的架構，而是當單一輸出契約一直被不同目的拉扯時，值得測試的選項。

同一 Prompt 忽好忽壞，建立固定測試集

官方文件都沒有把 Prompt 描述成完全固定的程式函式。OpenAI 文件明確提醒不同模型或快照可能需要不同提示，Anthropic 也建議先建立成功標準與經驗測試。對你來說，這表示「昨天成功」只能證明昨天那組條件產生了一個成功結果，不能直接推出下週所有資料都會成功。

如果同一個 Prompt 的結果有波動，先固定輸入、模型入口、日期和輸出要求，再比較不同版本。若你使用 API，還要把相關參數記錄下來；若你使用 ChatGPT 介面，則至少留下對話設定、輸入材料和查驗日期。無法讀回的帳號或模型狀態要標成未知，不要自行補上。

接著用測試集看波動集中在哪裡。若只有缺值案例失敗，補充空值規則可能有效；若所有案例都格式錯，先修輸出契約；若只有某類知識過時，應該更新來源或改用能提供查證的流程。這就是為什麼我不會把「改 Prompt」列為所有失敗的第一順位。

Prompt、Context Engineering 與 AI Agent 的邊界

當任務變大，Prompt 不是唯一需要管理的東西。NICROW 的Context Engineering 文章把注意力放到模型收到哪些脈絡、如何組織和維護；這比單次指令再加幾個形容詞更接近長期工作流程的問題。

可以用三層來分辨：Prompt 是一次任務的指令和輸出契約，Context Engineering 管理任務需要的資料、狀態和脈絡組合，AI Agent 則可能再加上工具、執行環境、記憶、權限和多步驟行動。三者可以一起使用，但不是同義詞。想知道 Agent 為什麼會在錯的目錄執行或拿到過大的權限，可以先看AI Agent Harness 的模型、工具與執行環境說明。

如果你需要接外部資料或工具，還可以延伸看MCP 是什麼，以及如何理解工具協定。那篇文章處理的是連接層，不是把每一次聊天 Prompt 寫得更漂亮。至於完整的自動化工作流程，可以參考自動化工作的方法與風險，先拆出觸發、執行、人工確認和結果回查。

判斷邊界的方法很簡單：如果你只是希望一次回答更符合格式，先改 Prompt；如果你需要跨文件、跨步驟、保留狀態或呼叫工具，開始檢查 Context Engineering 和 Agent 層；如果你需要保證資料不會外洩、動作不會重複或正式結果可追蹤，就要設計權限、記錄和人工驗收。把所有問題都塞進 Prompt，通常只會得到一條負責太多事情的長句子。

ChatGPT Prompt 教學 FAQ

Prompt 越長越好嗎？

不一定。長度本身不是品質指標。若任務需要很多脈絡和例外，Prompt 當然會變長；但每一段都應該對應一個可檢查的需求。把互相重複、過時或沒有判斷作用的句子刪掉，通常比繼續增加強調語氣更有幫助。

你可以先問每一段文字三個問題：它是在說任務、提供資料、限制輸出，還是在定義驗收？如果四者都不是，它可能只是背景噪音。刪除前先用固定案例比較，因為有些看似多餘的例子其實在處理邊界。

每個 Prompt 都要先設定角色嗎？

不用。角色設定在需要固定讀者、專業角度、語氣或審查責任時有用，但它不是正確答案的來源。先寫清楚任務、資料和輸出，再判斷是否需要角色。如果「以新手能理解」比「你是世界級專家」更能改變結果，優先寫前者。

也不要把角色當成權限。說「你是公司管理員」不會真的給 ChatGPT 讀取公司資料的權限；說「你是醫師」也不會把一般資訊變成個人診斷。需要權限和工具時，必須在產品或工作流程層確認。

什麼時候值得加入 few-shot 範例？

當你很難用規則說明分類、語氣或合格邊界時，few-shot 範例值得測試。選和真實任務相似的案例，最好包含一個容易混淆或應該標成未知的反例。範例若只是展示漂亮排版，卻沒有展示判斷理由，價值通常有限。

先用少量範例和不加範例的版本跑同一組測試，再觀察錯誤有沒有減少。範例會增加 Prompt 長度，也可能把過時規則帶進來，所以每次資料或流程改變時，都要重新檢查。

同一個 Prompt 可以永遠沿用嗎？

不應該把它當成永遠不變。模型、產品入口、資料、讀者和輸出需求都可能改變。OpenAI 官方 API 文件指出不同模型或快照可能需要不同 Prompt；這是模型文件的適用範圍，不是對你的 ChatGPT 帳號狀態的確認。

可行的做法是保留版本、查驗日期和一組固定案例。當結果明顯改變時，先回看是哪個條件變動，再決定要修改 Prompt、更新範例或換工作流程。若你沒有這些紀錄，就只能憑感覺判斷，這在低風險的臨時問答還可以，在重複工作裡會很快失控。

遇到不知道的資料，要在 Prompt 裡禁止模型猜測嗎？

可以要求它標出未知和依據不足，但不要把這句話當成保證。更具體的寫法是：沒有提供資料時填 unknown，不要補值；每個結論附上來源段落或輸入欄位；無法判斷時列出需要補充的資料。然後用真的缺值案例測試它是否照做。

如果結果會影響正式決策，仍然需要人工檢查、來源回查和適合的專業流程。Prompt 能改善可觀察性，不能把未提供的事實變出來，也不能替你承擔發布、付款或對外溝通的授權責任。

結語：把 Prompt 當成可修改的工作規格

ChatGPT Prompt 教學最後應該讓你少背幾個格式，多建立一個判斷習慣：先寫任務，再補脈絡和資料邊界，明確定義輸出契約，必要時使用代表性範例，最後用固定案例驗收。結果不好時，先分辨是規格、資料、模型、工具還是流程出了問題。

如果只是一次性問答，保持簡單就好。如果是每天重複的工作，請把 Prompt、測試案例和失敗紀錄一起保存。當任務開始跨越資料、工具和多步驟執行，再把問題往 Context Engineering、AI Agent 或自動化流程延伸。這樣 Prompt 才是一個能被維護的工作元件，而不是每次失敗都要重新祈禱的一段長文字。

查證邊界

本文於 2026-09-16 查閱下列官方文件。官方文件會隨模型、產品和版本更新，文中只寫查證日能確認的通用原則；你的帳號看到的介面、方案與模型名稱可能和文中不同，套用前再對一次。

參考來源