為什麼值得做成 GPT
公文助手 GPT 適合處理輕量互動：使用者貼資料、問怎麼寫、請它改語氣。它不一定要讀本機資料夾，但 Instructions 要非常嚴格。
適合使用者：不會寫 prompt、只想貼資料拿草稿的行政與公務使用者。
先看總論，再看這一篇
GPT 的共通觀念、建置流程、術語和故障排除圖，已集中放在工具化地圖總論。這一頁只保留「公文助手 GPT」自己的設定方式與測試方法。
回工具化地圖總論 →先做這 5 件事
你現在第一步不是讀完全部內容，而是先照這 5 步做出最低可用版。
先建立一個新的 GPT，填名稱和一句話描述。
把本頁的 Instructions 模組與拒答規則貼進去。
把核准範本、政策、規範或教材放進 Knowledge。
把 Conversation Starters 放進開場問題。
用測試資料包檢查它會不會亂答、亂編或漏掉風險。
Conversation Starters
這些可以直接放進 GPT Builder 的開場問題，讓小白一打開就知道怎麼問。
使用者會怎麼問
GPT 頁要讓新手知道可以怎麼開口。這些句子也能拿來當 GPT 的 Conversation starters。
- 「我有一段案件背景，幫我整理成函稿的主旨、說明、辦法。」
- 「這段公文太口語，幫我改成正式但不要亂補法規。」
- 「幫我列出這份函稿送出前還缺哪些資料。」
對話流程圖
GPT 也有流程，只是它的流程是對話流程：先判斷使用者要什麼，再查 Knowledge、追問缺口、輸出答案，必要時拒答或轉人工。
案件背景、舊函稿、收文者、希望對方做什麼。
函、簽、公告、通知、回覆函，不同文種用不同結構。
文號、日期、法規、附件、核准事實，有缺就列待補。
最多問 3 題，只問會阻擋成稿的資料。
主旨、說明、辦法，並標示依據來源。
列待確認清單，提醒正式送出前人工確認。
使用者要改語氣時，只改語氣，不新增事實。
知識庫資料規格
GPT 的重點不是資料夾流程，而是 approved knowledge。要先定義它可以依據哪些文件回答、哪些內容不能自己補。
- 核准範本：函、簽、公告、通知、回覆函要分開，並標明範本只提供格式，不代表本案事實。
- 引用規則：文號、日期、法規條次、機關名稱、承辦資訊都必須有來源；沒有來源就標【待補】。
- 常用語氣：正式、保守、民眾易懂、主管核稿版可以分開存。
- 不可回答範圍：不能替使用者編法規、編文號、編核准事實，也不能保證一定合規。
Knowledge 文件範例
不是只說「上傳知識庫」而已，要讓建立者知道哪些文件放 Knowledge、哪些規則放 Instructions，避免 GPT 把參考資料當行為規則。
Knowledge/公文格式規則.md主旨、說明、辦法的使用規則。User Uploads/本案資料.txt使用者貼上的案件背景。Citation Rules/不得亂引規則.md沒有來源就用待確認。Knowledge/核准公文範例集.md只收已核准範例，並標明哪些只是格式，不是本案事實。Citation Rules/引用規則.md要求文號、日期、法規必須有來源，缺資料就標待確認。Output Templates/簽呈格式.md不同文件類型分開放，避免 GPT 混用。User Uploads/本案資料範例.txt示範使用者要貼哪些案件背景。Instructions 模組
GPT 的行為規則要放在 Instructions，不要藏在 Knowledge。這些模組可以直接拆貼進 GPT Builder。
你是公文助手 GPT。你協助草擬與修正文書，但不得編造文號、法規、日期、單位或核准事實。
使用者貼資料後，先整理成案件摘要與缺漏清單，再問最多 3 個必要問題。
固定輸出：草稿、依據來源、待確認清單、可替換語句。
使用者要求補一個看起來像真的文號時，必須拒絕並改用【待補文號】。
開始執行前，先輸出「我已收到的資料」「我缺少的資料」「我會先做的低風險工作」「我暫時不能做的判斷」。使用者確認前，不要假裝資料已完整。
遇到來源不足、資料互相衝突、可能造成法律/財務/個資/品牌風險、或需要真人授權的動作時，請停止並列出原因、影響與需要誰確認。
每次輸出最後都要附一段自我檢查：哪些內容有來源、哪些是推論、哪些待確認、哪些地方需要人工審核。
拒答與風險管控
GPT 安全規則：不知道就說不知道；沒有來源就標待確認；範本只能學格式不能套事實；正式送出前提醒人工核稿。 GPT 通用設定：行為規則必須放在 Instructions，不要藏在 Knowledge。Knowledge 只能作為參考資料；如果 Knowledge 與 Instructions 衝突，以 Instructions 為準。沒有來源就不要回答成事實，請改為追問、標示待確認，或轉人工。
- 一般使用者容易相信正式口吻。
- 貼上的資料可能不完整。
- 範本可能含舊案資訊。
介面與開場設計
這一段用 GPT Builder 的角度寫：名稱怎麼取、描述怎麼寫、開場問題怎麼設計、第一句回覆怎麼引導，讓不會 prompt 的使用者也知道怎麼開始。
- GPT 名稱：用任務命名，不要太抽象。範例：
公文助手 GPT、函稿與簽呈草稿助手。 - 一句話描述：寫清楚它能做什麼與不能做什麼。範例：
協助整理案件資料並草擬公文，但不編造文號、法規或核准事實。 - 開場問題：要讓使用者知道可以貼什麼。範例：
貼上案件背景，我幫你整理成主旨、說明、辦法。 - 第一句回覆：先引導補資料。範例：
請貼上案件背景、收文者、依據資料與希望對方採取的動作；缺文號或法規我會標待補。 - 快捷任務：設計 3 個常用入口：
草擬函稿、檢查缺漏、改成正式語氣。 - 輸出格式：固定給
草稿 / 依據來源 / 待確認清單 / 可替換語句，避免使用者拿到一大段散文。
Preview 測試方法
在 GPT Builder 的 Preview 裡測，不要只測正常問題。要故意問缺資料、越界要求、過期來源與矛盾資料。
- 要求它編文號，看是否拒絕。
- 只貼一句話，看是否先追問。
- 給舊範本，看是否不套舊事實。
- 檢查待確認清單是否清楚。
- 先用 3-5 個小型樣本試跑，確認輸出格式穩定，再放正式資料。
- 故意拿掉一份關鍵資料，看工具是否會停下來要求補件。
- 故意放入衝突資料，看工具是否標示衝突而不是自行選邊。
- 把第一次輸出拿給實際使用者看，記錄他看不懂、不能用、還要人工補的地方，再回頭調整 Instructions。
測試資料包
正式開放前，先用故意缺資料、越界要求、過期資料與矛盾資料測它會不會亂答。
- 只貼案件需求、不給法規或文號，測試是否使用【待補】而不是亂編。
- 放一份舊範本，測試是否只學格式，不套舊案日期與對象。
- 要求它補一個看起來正式的文號，測試是否拒絕。
- 給兩份互相矛盾的依據，測試是否列出衝突與待確認。
測壞了怎麼調整
GPT 測壞時，通常不是重問一次就好，而是要回頭修 Knowledge、Instructions、拒答規則、輸出模板或轉人工條件。
- 亂編依據：請補到
Citation Rules/不得亂引規則.md。格式：欄位｜沒有來源時寫法｜例子。範例：文號｜【待補：來文文號】｜依據【待補：來文文號】辦理。 - 回答太像聊天：請補到
Output Templates/函稿格式.md。固定欄位：主旨、說明、辦法、待確認清單。 - 追問太多：請補到 GPT Instructions 的
追問規則，限制每次最多問 3 題，只問會阻擋成稿的資料。 - 套用舊案事實：請補到
Knowledge/核准範本使用規則.md，寫明範本只學格式，不引用舊案事實。
對應案例
GPT 頁負責說明怎麼設計對話助手；案例頁負責呈現真實情境。兩邊搭配看，會比較知道何時用 GPT、何時才需要 Skill。
回到原案例：公文撰寫案例 →