公文撰寫 Skill

為什麼值得工具化

公文撰寫看似文字工作，其實是資料檢核工作。Skill 要先確認案件事實、來文、範本、依據與核准流程，再產草稿，不能讓 AI 憑語感生出文號與法規。

適合使用者：行政、公務、學校、協會、公司總務與常寫函稿、簽呈、通知的人。

資料夾設計

輸入資料規格

這一段把「要準備資料」講得更明確。真正做 Skill 時，使用者要知道每份檔案或表格至少需要哪些欄位。

• 文種：函、簽、公告、通知、回覆函、計畫書、會議紀錄或其他正式文件。
• 讀者與目的：收文者、要對方知道什麼、要對方做什麼、期限與附件。
• 依據資料：來文、法規節錄、前案、會議紀錄、長官裁示、核准範本。
• 不可編造欄位：文號、日期、法規條次、機關名稱、承辦資訊、核准事實。
• 核稿欄位：承辦人、主管、法制或法務、業務單位各自要確認什麼。

文件長相範例

不是叫使用者「準備資料」而已，要讓他知道檔案可以長什麼樣子、怎麼命名、哪些內容要分開放。

操作流程

1. 先做資料夾檢查，分出可引用依據、僅供參考範本、缺少資訊。
2. 整理案件事實：誰、何時、何事、依據、要對方做什麼。
3. 產出主旨、說明、辦法三段草稿，每段都標示資料來源。
4. 把不確定欄位留成待確認，不用看似正式的假文號補洞。
5. 最後產出承辦人檢查表，讓人能快速核稿。

指令不要只寫一段。實務上要拆成角色、輸入檢查、分析流程、輸出格式與追問規則，之後才好維護。

你是公文撰寫 Skill。你可以整理資料、草擬主旨/說明/辦法、檢查格式，但不能編造法規、文號、日期、機關名稱、承辦人或核准事實。

開始前先列出：已提供依據、可用範本、缺少資料、不可引用資料。若缺少文號或法規，請以【待補：文號】標示，不可自行生成。

先輸出案件摘要，再輸出公文草稿。主旨要一句話說明目的；說明要按事實與依據排列；辦法要寫清楚對方要做的動作、期限與附件。

輸出四塊：1. 案件摘要 2. 公文草稿 3. 待確認清單 4. 核稿檢查表。每個法規、文號、日期都要附來源檔名。

如果資料不足，每次最多問 3 個會阻擋成稿的問題。不要問風格偏好這類可晚點處理的問題。

先讀案件主檔，再讀依據資料夾，最後才讀範本。範本只能提供格式與語氣，不得把舊案事實帶入新案。

把內容分成可直接引用、可參考、不可引用、缺少資料四類。文號、法規、日期、金額、人名與機關名稱必須逐項核對。

送出前請檢查：主旨是否一句話說明目的；說明是否都有依據；辦法是否有對象、動作、期限、附件；是否仍有【待確認】欄位。

開始執行前，先輸出「我已收到的資料」「我缺少的資料」「我會先做的低風險工作」「我暫時不能做的判斷」。使用者確認前，不要假裝資料已完整。

遇到來源不足、資料互相衝突、可能造成法律/財務/個資/品牌風險、或需要真人授權的動作時，請停止並列出原因、影響與需要誰確認。

每次輸出最後都要附一段自我檢查：哪些內容有來源、哪些是推論、哪些待確認、哪些地方需要人工審核。

安全規則：不得編造文號、法規、日期、機關名稱、核准事實；不得把範本舊案事實套成新案；所有依據必須來自依據資料夾；不確定內容一律用【待確認】標示。

進階設定：所有看起來像正式依據的內容，都必須能回到來源檔。若來源檔沒有文號、日期或條文，不得補上格式相似的假資料。若使用者要求直接送出，仍需提醒人工核稿。

通用風險設定：你必須把「資料不足」視為正常狀態，而不是用猜測補完。不得編造來源、不得省略限制、不得把範例當成事實、不得在未取得確認前執行不可逆動作。高風險輸出要明確標示需要人工審核。

• 公文最大風險是正式感很像真的，但裡面有假依據。
• 範本污染也是高風險，必須清楚區分範本語氣與本案事實。
• 若主管指示與依據資料衝突，AI 只能標示衝突，不能自行決定。

介面與輸出設計

• 上傳區要分成案件主檔、依據、範本、附件，避免範本被誤當事實。
• 草稿中每個文號旁放來源標記，方便承辦人核對。
• 待確認清單要固定在草稿上方，提醒使用者先補關鍵資料。
• 輸出 Word 草稿與一份核稿表。

試驗方法

不要一次就相信工具。先用小資料夾、故意放錯資料、看它會不會停下來，最後才放進真流程。

1. 缺文號測試：拿掉依據文，看它是否以【待補】標示。
2. 範本污染測試：放一份舊案範本，看它是否沒有沿用舊案日期與對象。
3. 格式測試：輸出是否符合主旨、說明、辦法的基本結構。
4. 核稿測試：請承辦人只看待確認清單，是否能知道要補哪些資料。
5. 先用 3-5 個小型樣本試跑，確認輸出格式穩定，再放正式資料。
6. 故意拿掉一份關鍵資料，看工具是否會停下來要求補件。
7. 故意放入衝突資料，看工具是否標示衝突而不是自行選邊。
8. 把第一次輸出拿給實際使用者看，記錄他看不懂、不能用、還要人工補的地方，再回頭調整 Instructions。

測試資料包

正式導入前，先準備一包故意有缺漏、衝突與邊界情境的小資料，拿來測 Skill 會不會亂猜、亂改或漏報。

1. 只給需求、不給法規，測試是否停止並要求補依據。
2. 給兩份互相矛盾的前案，測試是否列出衝突，不自行選一份。
3. 要求 AI 補一個正式文號，測試是否拒絕亂編並標待補。
4. 給舊公文範本，測試是否只學格式、不套用舊案事實。

測壞了怎麼調整

測試失敗不是壞事。重點是知道要回頭修哪裡：資料規格、紅旗清單、風險規則、輸出格式，還是人工覆核點。

• 亂編文號：請補到 04_待確認清單/不可編造欄位.md，寫明文號、日期、法規條次、機關名稱沒有來源就用【待補】。範例：依據【待補：來文文號】辦理。
• 草稿不像公文：請補到 03_範本資料夾/文種結構.md。範例：函=主旨/說明/辦法；簽=主旨/說明/擬辦；公告=依據/公告事項。
• 內容太空泛：請補到 01_案件主檔/案件說明.md。欄位：收文者、目的、期限、附件、要對方採取的動作、承辦窗口。
• 把舊範本事實套進新案：請在 03_範本資料夾/README.md 寫清楚「只學格式與語氣，不引用舊案事實」。
• 一直追問太多：請補到 Skill 的 核心指令模組 > 追問規則，限制每次最多問 3 題，而且只問會阻擋成稿的問題。

對應案例

工具頁負責說明怎麼產品化；案例頁負責呈現真實情境。兩邊搭配看，會比較知道什麼時候用 Skill、什麼時候用 GPT。