> For the complete documentation index, see [llms.txt](https://docs.maiagent.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.maiagent.ai/work/writing-assistants/official-document.md).
# 公文撰寫助理
公文撰寫 Agent 應用實例：用 MaiAgent 建一個會寫函、簽、書函、公告、開會通知單的公文撰寫助理，含角色指令範例、公文範本知識庫、測試題與常見問題。
公文有固定的類別、結構與用語：承辦人知道要講什麼，卻常卡在「主旨怎麼收、說明怎麼分項、對上級與對平行機關的用語差在哪」。把這些規則寫進 Agent 的角色指令，同仁只要提供公文類別、受文者與要點，就能拿到結構正確的初稿，或把既有文稿貼上來請它挑毛病。
本頁示範從零建立一個公文撰寫 Agent。產出的是**草稿**，發文前仍須由承辦人與主管依機關的文書處理規定核對。
## 適用情境
| 誰在用 | 拿它做什麼 |
| -------------- | ------------------------------ |
| 政府機關、公營事業承辦人 | 依來文擬復函、擬簽請示、草擬公告與開會通知單 |
| 企業行政、法務、公共事務人員 | 撰寫給主管機關的申請函、陳報函、回覆函 |
| 學校教職員 | 校內簽呈、對教育主管機關的函文 |
| 剛接手文書工作的新人 | 把寫好的文稿貼上，請 Agent 指出結構、用語與稱謂的問題 |
## 先看有沒有現成的官方 Agent
[Agent 市集](/work/built-in-agents/use.md) 的 官方內建 分頁已有兩個相近的 Agent，需求符合就不必自建：
| 官方內建 Agent | 場景分類 | 適合 |
| --------------------------------------- | ---- | -------------------------------------- |
| 行政公告撰寫 | 總務 | 內部行政公告與通知（停機、搬遷、活動、規定異動），未提供的欄位以【待填】保留 |
| 新聞稿草擬 | 綜合行政 | 對外新聞稿、三版標題、社群短版與常見問答 |
官方內建 Agent 的角色指令不能修改。要寫的是「函、簽、書函」這類有固定結構的公文，或要套用自家機關的用語與範本，請照下面步驟自建；也可以先到 [Agent 模板庫](/build/agent/agent-templates.md) 套用 行政公告撰寫 模板，得到一個可編輯的 Agent 再改角色指令。
## 要準備什麼
* 一個可以建立 Agent 的帳號（角色具備 AI 助理 權限）
* 機關或公司的公文範本 3–10 份，涵蓋最常寫的類別（例如函、簽、開會通知單）；請先遮蔽個資與機敏內容
* 慣用語對照（選用）：機關全銜與簡稱、常用的期望語與稱謂、內部分層負責的決行層級
* 決定開放對象：哪些角色的同仁可以使用
## 建置步驟
### 1. 建立 Agent
到 AI 助理 點 建立 AI 助理，名稱直接寫出用途，例如「公文撰寫助理」。LLM 模型 選組織已啟用、擅長長文寫作的模型；回答模式維持預設的 Agent 模式。操作細節見 [建立 Agent](/build/agent/setup.md)。
### 2. 貼上角色指令
在 回答模式設定 的 角色指令 貼上下列範例，再依機關的規定調整。寫法原則見 [角色指令設計指南](/build/agent/system-prompt.md)。
```
## 角色
你是公文撰寫助理，協助同仁撰寫與政府機關往來的公文，並對既有文稿提出修改建議。
你只處理公文撰寫與修改，其他請求請禮貌說明無法協助。
## 動筆前先確認
缺少下列任一項時，一次問完再動筆，不要自行假設：
1. 公文類別：函、書函、簽、公告、開會通知單，或其他
2. 發文者與受文者（機關全銜；若為簽，則是承辦單位與決行層級）
3. 行文關係：對上級、對平行、對下級，或對民眾、廠商
4. 主旨：這份公文要對方知道或辦理的一件事
5. 說明要點：緣由、依據（來文日期與字號、法規或會議決議）、事實經過
6. 希望對方辦理的事項與期限（如有）
7. 附件（如有）
## 結構
- 函、書函：主旨、說明、辦法三段。主旨一段寫完、不分項，說清楚目的與期望；
說明與辦法分項條列，項次依序用「一、」「（一）」「1.」。沒有辦法段的內容就不要硬寫。
- 簽：主旨、說明、擬辦三段。擬辦要提出具體處理意見供核示。
- 公告：主旨、依據、公告事項三段。
- 開會通知單：開會事由、開會時間、開會地點、主持人、聯絡人及電話、出席者、列席者、備註。
## 用語
- 依行文關係選擇稱謂與期望語：對上級用「鈞」「請鑒核」「請核示」；
對平行用「貴」「請查照」「請惠允見復」；對下級用「貴」或「該」「請照辦」「請查照辦理」。
- 自稱用「本」（本部、本公司）。
- 文字簡淺明確，一句話一個重點；日期用民國紀年，數字用法前後一致。
## 修改既有文稿時
先列出修改建議（結構、用語、稱謂、語意不清處），每點說明原因，再附修改後全文。
## 限制
- 不編造來文字號、法規條號、日期、金額與人名；使用者沒有提供的，以【待填】標示。
- 引用法規時只寫使用者提供或知識庫中查得到的條文，並提醒發文前查核現行條文。
- 每份初稿最後加一行：「本稿為草稿，發文前請依貴機關文書處理規定核對。」
```
### 3. 掛上公文範本知識庫（選用）
要讓初稿貼近機關的慣例，把準備好的範本上傳到 [知識庫](/build/knowledge-base/km.md)，再到 Agent 的 知識庫設定 掛上：
* 每份範本一個檔案，檔名寫清楚類別與用途，例如「函\_復主管機關查詢.docx」「簽\_採購案請示.docx」，檢索時較容易命中
* 用語對照表、機關全銜與簡稱可整理成一份文件，或建成 [FAQ](/build/knowledge-base/faq.md)
* 在角色指令補一句「撰寫前先檢索知識庫中同類別的範本，沿用其格式與用語」
沒有範本也能用，Agent 會依角色指令中的結構與用語規則撰寫。
### 4. 開啟上傳檔案
同仁常會把來文或既有文稿直接丟給 Agent。到這個 Agent 的「內部」對話平台 → [功能設定](/build/conversation-settings/platform-settings/function-settings.md#basic-functions)，開啟 允許上傳檔案。要讓 Agent 把初稿輸出成 Word 檔，另外開啟 [Code Interpreter](/build/agent/code-interpreter.md)。
### 5. 開放給同仁
到 [角色權限](/org/roles/role-permission.md) 把這個 Agent 的「內部」對話平台分配給需要的角色，同仁就能在 [內部問答](/work/explain.md) 選它開始對話。
## 測試題
上線前用下列題目逐一測試，確認結果符合「應該看到」的描述；不符合時回頭調整角色指令。
| # | 輸入 | 應該看到 |
| - | ----------------------------------------------- | ------------------------------------------------ |
| 1 | 「幫我寫一份函」 | 不直接動筆，一次問齊類別、受文者、行文關係、主旨與說明要點 |
| 2 | 「本公司要函復經濟部 115 年 3 月 2 日的來函，說明已依限完成改善，檢附改善報告一份」 | 產出函稿：主旨一段不分項、說明分項並引述來文日期、對上級機關用語正確；來文字號未提供處標【待填】 |
| 3 | 「擬一份簽，請示是否同意辦理員工資安教育訓練，預算 12 萬元」 | 主旨、說明、擬辦三段；擬辦提出具體意見 |
| 4 | 「下週三下午 2 點在第一會議室開專案進度會議，請幫我發開會通知單」 | 欄位齊全；主持人、出席者等未提供的欄位標【待填】，日期未自行換算成錯誤的年月日 |
| 5 | 貼上一段口語化的文稿，請它修改 | 先列修改建議與原因，再附修改後全文 |
| 6 | 「依政府採購法相關規定辦理，幫我把條號補上」 | 不自行編造條號，請使用者提供或標示待查核 |
| 7 | 「幫我寫一首詩」 | 說明只處理公文撰寫與修改 |
可以把這些題目建成 [測試集](/build/agent-ops/test-datasets.md)，日後調整角色指令或更換模型時重跑。
## 常見問題
### 產出的公文可以直接發文嗎？
不行。Agent 產出的是草稿：事實、日期、字號、法規依據與決行層級都要由承辦人核對，並依機關的文書處理規定完成核稿與判行。
### 格式跟我們機關的不一樣怎麼辦？
各機關對項次、用語、附件表示方式常有自己的慣例。把機關的範本放進知識庫，並在角色指令的「結構」「用語」段直接寫明差異（例如「本機關開會通知單另列『應備文件』欄」），效果比只給範本更穩定。
### Agent 自己編了字號或法條？
確認角色指令保留了「限制」段，並在測試題 6 驗證。仍發生時，把該限制移到角色指令最前面，或改用推理能力較強的模型。
### 可以讀掃描的紙本來文嗎？
可以上傳圖片或 PDF 請 Agent 讀取後擬復。掃描品質差時辨識可能有誤，請在回覆中核對它引述的日期與字號。
### 同仁看不到這個 Agent？
通常是「內部」對話平台還沒分配給該角色，對照 [組織自建分頁會列出哪些 Agent](/work/built-in-agents.md#self-built-tab-conditions) 排查。
## 延伸閱讀
* [應用實例：文書與內容創作](/work/writing-assistants.md)：其他文書類 Agent 的設計重點
* [法律存證信函草擬](/work/writing-assistants/legal-attest-letter.md)
* [使用官方內建 Agent](/work/built-in-agents/use.md)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.maiagent.ai/work/writing-assistants/official-document.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.