官方技能 · AI 實務

使用前審查 AI 草稿

v1.0.1 · 2026 年 11 月 4 日 更新

在使用 AI 產出的草稿之前先審查：需要查證的陳述、可能捏造的出處、語氣與規範問題、與需求的落差，以及修正清單。

可在 Claude、ChatGPT 和程式設計代理中使用。使用 Team 和 Business 方案時，我們改進官方技能後，你 Pod 裡的這個技能會自動更新。

適用情境

• 你準備寄出或發布 AI 寫的內容
• 草稿引用了研究、統計數字、法規或引言

你要提供的內容

• 草稿
• 原始需求
• AI 拿到的參考資料
• 相關規範

你會得到的內容

一張陳述表、一份引用查核、依嚴重程度排序的修正清單，以及結論：可以使用、修正後可用，或重寫。

運作方式

1. 確認有回應需求 逐點對照草稿和需求：每個問題都有回答、格式和長度符合要求、對象正確。列出缺漏的部分，以及沒人要求卻加上去的部分。
2. 挑出每個事實陳述 數字、日期、人名、價格、產品功能、法規或政策說法、「研究顯示」、引言。每項一行，並註明在草稿中的位置。
3. 替每個陳述分類 有依據（可追溯到提供的資料，寫出位置）；待查證（可能是真的，需要外部查證，寫出去哪裡查）；可疑（很具體卻沒有出處、精確到不像猜的，或與資料矛盾）。任何沒有出處的統計數字至少是「待查證」。
4. 找出捏造的出處 每個被引用的研究、文章、網址、判例、法條或引言：標題、作者、日期和網址是否存在，內容是否真的這樣說？無法確認的一律標為「使用前須查證；可能是捏造的」。絕不憑記憶確認引用。
5. 檢查語氣和規範 公司做不到的承諾（日期、折扣、保證）、機密或個人資料、行銷不能說的話（「最好」、「保證」、「100%」）、不符合對象的語氣，以及空洞的套話。
6. 檢查前後一致 加總對不上的數字、同一個名字有兩種寫法、互相衝突的日期、內文撐不起的結論。
7. 寫出修正清單 依嚴重程度排序：必須修正（錯誤、捏造、有風險）、應該修正（缺漏、不清楚）、可以修正（文字風格）。每項寫出：位置、問題、修正方式或查證方法。最後給出結論：可以使用、修正必修項後可用，或重寫。

SKILL.md 檔案

完整檔案，就是你的 AI 讀到的內容。 下載檔案

---
name: ai-output-review
description: 在任何人使用 AI 產出的草稿之前先審一遍：列出每個需要查證的事實陳述，標出可能是捏造的出處、引言和引用，檢查數字、語氣、公司規範，以及草稿是否真的回應了需求，最後交出依嚴重程度排序的修正清單。有人要你檢查、查核事實、校對或把關 ChatGPT、Claude、Gemini、Copilot 寫的內容，在寄出、發布或歸檔之前，或問「這份 AI 草稿可以相信嗎？」時使用。
---

# AI 產出審查

AI 草稿不管對不對，讀起來都很通順。英國政府的 AI Playbook 提醒，語言模型會產出看似合理但錯誤的內容，也不能取代專業意見；2024 年史丹佛大學的研究中，GPT-3.5、Llama 2 和 PaLM 2 回答具體法律問題時，有 69% 到 88% 的答案出現幻覺。所以審查不是判斷草稿「聽起來對不對」，而是把每個可查證的陳述挑出來，註明怎麼查，再交出一份修正清單，讓作者在使用前逐項處理。

## 適用情境

- 寄出、發布或歸檔任何 AI 起草的內容之前：給客戶的信、報告、文章、提案、規章。
- 草稿引用了研究、法規、統計數字、引言或網址時。
- 別人用 AI 寫的東西送到你這裡等你核准時。
- 不能取代律師、會計師或醫師審閱法律、財務或醫療內容：這類內容標出來交給專家。

## 需要準備

- 草稿本身。
- 原始需求或提示詞：原本要它做什麼、寫給誰。
- AI 拿到的所有參考資料。無法追溯到這些資料的陳述，需要另外查證。
- 適用的公司規範或寫作規則。如果沒有，就用步驟 5 的一般原則檢查，並在審查中註明。

## 步驟

1. **確認有回應需求。** 逐點對照草稿和需求：每個問題都有回答、格式和長度符合要求、對象正確。列出缺漏的部分，以及沒人要求卻加上去的部分。
2. **挑出每個事實陳述。** 數字、日期、人名、價格、產品功能、法規或政策說法、「研究顯示」、引言。每項一行，並註明在草稿中的位置。
3. **替每個陳述分類。** 有依據（可追溯到提供的資料，寫出位置）；待查證（可能是真的，需要外部查證，寫出去哪裡查）；可疑（很具體卻沒有出處、精確到不像猜的，或與資料矛盾）。任何沒有出處的統計數字至少是「待查證」。
4. **找出捏造的出處。** 每個被引用的研究、文章、網址、判例、法條或引言：標題、作者、日期和網址是否存在，內容是否真的這樣說？無法確認的一律標為「使用前須查證；可能是捏造的」。絕不憑記憶確認引用。
5. **檢查語氣和規範。** 公司做不到的承諾（日期、折扣、保證）、機密或個人資料、行銷不能說的話（「最好」、「保證」、「100%」）、不符合對象的語氣，以及空洞的套話。
6. **檢查前後一致。** 加總對不上的數字、同一個名字有兩種寫法、互相衝突的日期、內文撐不起的結論。
7. **寫出修正清單。** 依嚴重程度排序：必須修正（錯誤、捏造、有風險）、應該修正（缺漏、不清楚）、可以修正（文字風格）。每項寫出：位置、問題、修正方式或查證方法。最後給出結論：可以使用、修正必修項後可用，或重寫。

## 輸出格式

```markdown
# AI 產出審查 — [草稿標題]
**需求：** [一行] · **結論：** [可以使用 / 修正必修項後可用 / 重寫]

## 是否回應了需求？
- [已涵蓋 / 缺漏 / 未經要求而加上]

## 需要查證的陳述
| # | 陳述 | 位置 | 狀態 | 查證方法 |
|---|---|---|---|---|
| 1 | [陳述] | [段落] | 有依據 / 待查證 / 可疑 | [資料中的位置或去哪裡查] |

## 出處與引用
| 引用 | 是否存在？ | 內容是否如草稿所說？ |
|---|---|---|
| [標題、作者、年份、網址] | 使用前須查證 | [ ] |

## 修正清單
**必須修正**
1. [位置] — [問題] → [修正]
**應該修正**
1. [位置] — [問題] → [修正]
**可以修正**
1. [位置] — [問題] → [修正]

## 需要專家判斷
- [法律 / 財務 / 醫療問題] → [交給誰]
```

## 範例

**輸入：** 需求：「幫我們的預約軟體『約診通』寫一篇 400 字的 LinkedIn 貼文，說明小型診所為什麼該改用線上預約。」草稿：「研究顯示，67% 的病患偏好線上預約（Accenture，2023）。使用約診通的診所，爽約率保證減半。線上預約完全不受個資法規範，不必做任何法遵工作。立即改用，加入 10,000 家滿意診所的行列！」

**輸出：**

```markdown
# AI 產出審查 — 約診通 LinkedIn 貼文
**需求：** 400 字貼文，談小型診所改用線上預約 · **結論：** 修正必修項後可用

## 是否回應了需求？
- 已涵蓋：為什麼要改用。長度：約 100 字，遠少於 400 字。除了「立即改用」之外沒有行動呼籲。

## 需要查證的陳述
| # | 陳述 | 位置 | 狀態 | 查證方法 |
|---|---|---|---|---|
| 1 | 67% 的病患偏好線上預約 | 第 1 句 | 可疑 | 找到 Accenture 2023 年的報告和確切數字 |
| 2 | 約診通讓爽約率減半 | 第 2 句 | 可疑 | 約診通自己的資料；「保證」不能留 |
| 3 | 線上預約「完全不受個資法規範」 | 第 3 句 | 可疑 | 交給專家確認 [待確認：當地法規]；預約資料多半含病患的個人資料 |
| 4 | 有 10,000 家診所使用約診通 | 第 4 句 | 待查證 | 內部客戶數 |

## 出處與引用
| 引用 | 是否存在？ | 內容是否如草稿所說？ |
|---|---|---|
| Accenture，2023 | 使用前須查證；可能是捏造的 | [ ] |

## 修正清單
**必須修正**
1. 第 3 句 — 法遵說法很可能是錯的，而且有風險 → 刪除；等專家審過再提法遵。
2. 第 2 句 — 「保證」是一種承諾 → 刪除；改用有出處、經查證的客戶成果，或拿掉這個數字。
3. 第 1 句 — 未經查證的統計數字 → 確認報告內容，否則刪除。
**應該修正**
1. 長度 — 約 100 字，需求是 400 字 → 加一個客戶實例和明確的下一步。
**可以修正**
1. 第 4 句 — 「滿意診所」是套話 → 只留經查證的數字。

## 需要專家判斷
- 個資法相關說法 → 法遵人員或律師。
```

## 寄出前檢查

- [ ] 草稿中的每個數字、人名、日期和引用都列在陳述表中。
- [ ] 沒有對照實際來源查過的引用，都不標為真實。
- [ ] 每個必須修正項目都有位置和具體的修正方式。
- [ ] 法律、財務和醫療問題都轉給專家，而不是直接核准。
- [ ] 結論和修正清單一致（還有必修項沒處理，就不能寫「可以使用」）。

## 常見錯誤

- 只改文字，不管事實。修飾得很漂亮的錯誤陳述，比粗糙的更糟。
- 問同一個 AI「這些出處是真的嗎？」，然後接受它說「是」。要去查來源本身。
- 只審草稿裡有的內容。漏掉一半需求的草稿，再正確也不及格。

分享給你的團隊

把它加入 AI Skill Pod，團隊每個人（外包人員也包括在內）都能從自己的 AI 使用同一個版本。 看看和團隊分享 AI 技能的最佳做法

加入我團隊的 Pod

更新紀錄

• v1.0.1 · 2026 年 11 月 4 日 · Example: the draft's length is now given as 35 words, its actual count.
• v1.0.0 · 2026 年 11 月 4 日 · First release.