AI 使用政策
GetGrant 編輯團隊｜最後更新：2026-06-07
本頁說明 GetGrant 對 AI 工具的明確使用界線。我們選擇把過去的失敗、現在的分工、未來的承諾一次寫清楚， 是因為政府補助這個題目，AI 幻覺直接傷害的是真正需要補助的家庭。 這頁不會用「結合 AI 賦能編輯」、「人機協作」這類話術； 我們只會描述「AI 實際在做什麼、不做什麼、為什麼分工這樣劃」。
1. 早期事實：GetGrant 曾使用 AI 自動產製補助資料
GetGrant 在 2025 年底至 2026 年 4 月初的早期版本，曾大量使用 LLM 自動產製補助資料。當時的工作流是： 爬取機關官網的補助列表頁，把每筆補助名稱餵給 LLM，請它「依官方公告整理出補助說明、申請資格、金額、流程、FAQ、案例」。 這個做法在開站初期讓資料庫快速膨脹到 4,438 筆，看起來覆蓋率漂亮。
但這個做法有個根本問題：LLM 在沒有真實官方文件支撐時，會產出看起來像補助公告的虛構內容。 結構工整、欄位齊全、連電話格式都對 — 但金額、法規名稱、承辦窗口都是編造的。 傳統「人工抽查」的方式根本撈不到這些假頁，因為它們看起來和真的一模一樣。
這個事實必須先攤開來講。如果你正在閱讀 GetGrant 上「早期建立、近期未重新審視」的某筆補助， 它可能就是這個產製流程留下的記錄。 從 2026 年 4 月起，這類記錄都被強制歸入 needs_review，並陸續在後續的嚴格清理中下架。
2. 兩位客委會藝文傳播處同仁主動指證：才是政策轉變的觸發點
2026 年 5 月，客委會藝文傳播處承辦同仁 劉慧萍小姐 與 方小玉小姐分別來信，指證 GetGrant 站上列出的「客家文學獎 2026」、「客語生活學校補助 2026」、「客家文化力補助 2026」三筆， 並非該處承辦業務：
- 客家文學獎：為過去某年度試辦但已停辦，現行並無此補助。
- 客語生活學校補助：屬教育部國教署補助項目，並非客委會。
- 客家文化力補助：從未存在於該處承辦業務。
三筆均屬 AI 捏造或張冠李戴。我們收到回報後 24 小時內整筆下架 （commit 962b86c、51d129b、ea41021）。 隨後對客委會所有補助進行第 2、第 3 輪深查，又識別並下架 2 筆「NodeID=63 空白頁模式」的虛構記錄。
這兩位同仁的主動指證，是 GetGrant 從「AI 產製」全面轉向「AI 輔助稽核」的關鍵觸發點。 我們在 commit message 中明確公開致謝，這也是本頁前半段必須詳細記錄這起事故的原因。
其他兩起事故（事故 A 苗栗公館鄉敬老禮金混算、事故 B NCC 5G 補助虛構）詳見 編輯與查核標準。
3. 我們的轉變：AI 從「產製」改為「輔助稽核」
事故 B（NCC 5G）與事故 C（客委會 3 筆）讓團隊重新檢視 AI 在 GetGrant 工作流中的位置。 結論很直接：AI 不能負責生成事實，只能負責比對事實。
具體的政策轉變從 2026-04 開始陸續實施，到 2026-06 完成：
- 停止所有「LLM 依補助名稱自動產製內容」的爬蟲管線。
- 所有早期 LLM 生成且未經人工逐筆驗證的記錄，強制降為 needs_review。
- 執行三輪嚴格清理：4,438 筆 → 713 筆（縮減 84%）。其中 commit
cebaa31刪除 2,035 筆、0057fc3刪除 1,480 筆 source_confidence='?' 未個別審視者。 - 建立 7 個自訂稽核腳本（audit_p0_scan.py、audit_strict_url_check.py 等），把過去人工抽查抓不到的虛假模式寫成程式化檢查。
- 新增 6 條 reject 規則（張冠李戴、機關職權不符、共用首頁、商業域名等），任一觸發即整筆下架。
- 新增上架前的 5 步檢查 SOP，所有新增記錄必須依此流程通過才能 commit。
我們承認 713 筆對「補助大全」這個定位看起來「不夠完整」，但每筆都對得上官方深層連結， 比 4,438 筆裡夾雜虛假資料對使用者更有用。
4. 目前 AI 在 GetGrant 的角色：4 項輔助稽核
以下是 AI 目前在 GetGrant 工作流中實際在做的事。這 4 項共同特徵是：AI 只負責「批次比對」與「異常標記」，不負責「生成內容」與「下架決策」。
URL 健康度檢查
每日 06:00 UTC 由 GitHub Actions 跑 verify_urls.py v2。對全部 grant 的 source_url 做 HTTP 狀態、文字內容、是否為 NodeID 空白頁三層檢查。AI 在此扮演「批次比對」工具：抓取頁面 HTML、比對是否包含補助名稱字串、判斷是否為共用首頁模板。任何降級結果都進 needs_review 隊列等人工處理。
機關職權對照
對照 2022 年數位部成立後的機關改組對照表（9 項業務移轉），把補助主題與現行主管機關做交叉比對。例如：補助主題寫「5G 創新運用」但主管機關仍掛 NCC，會被自動標記，因為 5G 業務 2022 後已移交 moda。AI 只負責標記，不負責下架決策。
法規系統比對
把補助頁引用的法規名稱（作業要點、自治條例、補助辦法）丟進 law.moj.gov.tw 與各縣市法規系統做全文檢索。搜不到者標記為「疑似法規不存在」。事故 B（NCC 5G 補助）就是因為法規名稱在所有法規系統皆搜不到才被識別出來。
結構化資料生成
FAQPage、HowTo、BreadcrumbList 等 schema.org JSON-LD 由程式從已驗證的 grant 欄位自動組裝，不涉及內容生成。AI 不會幫補助「自動寫 FAQ」，所有 FAQ 內容必須由編輯依官方公告撰寫。
5. 目前人工在 GetGrant 的角色：5 項不可替代工作
以下 5 項工作 AI 不能代替任何一項。即使原始材料看起來很完整、即使 LLM 寫得很像、 即使「跑 prompt 一次就能產出」，這些工作都必須由人工編輯親自做：
個別審視
每筆補助必須由至少一位編輯逐欄位閱讀官方來源頁。中央部會主管、金額 ≥ 50 萬、涉及 2022 後改組業務者強制雙簽署。AI 不能代替任何一位人工編輯做這件事，即使原始材料看起來很完整。
深層連結驗證
編輯需親自打開官方深層 URL，確認頁面實際內容包含補助名稱、申請資格、金額描述。不接受機關首頁、NodeID 空白頁、共用入口頁作為來源。事故 C（客委會 3 筆）後特別強化此項。
主管機關公告比對
金額、申請期間、申請方式必須與主管機關當年度公告逐字比對。沿用前年度公告者不予收錄；公告未明者明確標示「請以主管機關公告為準」。
FAQ 與案例撰寫
每筆補助的 FAQ ≥ 3 題、案例 ≥ 2 個，全部由編輯依官方公告與實際申辦經驗撰寫。FAQ 內任何具體數字（通過率、件數、預算）必須有官方公告或新聞稿佐證。案例必須明確標示為「試算範例」。
機關承辦回報追蹤
收到機關承辦同仁的指證後，由編輯於 24 小時內整筆下架（不等查證完成），並對該機關所有補助觸發深查。事故 C 後續識別出的 2 筆 NodeID=63 空白頁，就是此機制的成果。
6. 每筆補助上架前的 5 步檢查
每筆新補助從草稿到上架前，依下列順序執行，跳過任一步即不予上架。這 5 步是事故 B、事故 C 後沉澱出來的 SOP， 寫在 SKILL.md 編輯流程章節：
來源確認
取得官方深層 URL，貼進 verify_urls.py 跑單筆驗證。確認 HTTP 200、頁面文字實際包含補助名稱、非機關首頁、非 NodeID 空白頁。任一項不通過即退件。
法規對照
引用之要點 / 自治條例貼進 law.moj.gov.tw 或縣市法規系統，確認可搜到原文且未廢止。搜不到即退件，不接受「LLM 整理版」或「他站轉述版」。
8 維 checklist 逐項打勾
由編輯填寫 audit report JSON：URL 深度、機關正確性、法規實在性、金額正確性、資格正確性、時程方式、聯絡資訊、FAQ/案例可驗證性。任一維未通過即降為 needs_review。
跨參驗證
P0 補助強制做跨參，至少撈 2 個獨立官方來源（機關官方頁 + 行政院公報、或機關官方頁 + 縣市政府預算書）。AI 不能作為跨參來源。
第二位編輯交叉確認
金額 ≥ 50 萬、中央部會主管、涉及 2022 後改組機關者，強制需第二位編輯逐欄位重新跑一次 8 維 checklist。本地端跑完 qa_gate.py --strict 通過才能 commit 進 git。
7. 使用者回報後 24 小時處置承諾
收到 getgrant.tw@gmail.com 或 聯絡我們 頁面提交的回報後，標準處置：
- T+0：編輯團隊內部群組收到通知，登記為「待處理 issue」並回覆收件確認。
- T+24 小時：跑一次 8 維 checklist 重新審視該筆補助。若是機關承辦人指證的虛構案（事故 C 同類），直接整筆下架，不等查證完成。
- T+72 小時：回覆回報人處理結果，附上 commit hash 與部署時間。仍需查證時間者明確告知預估日期，不留懸案。
- T+7 天：追蹤該補助所在類別、所在機關是否還有同類問題，觸發深查。
- T+14 天：若涉及新的虛假模式，寫進對應稽核腳本，形成永久防護。
致機關承辦同仁：如果你發現我們把貴單位業務寫錯了，請務必告訴我們。 事故 C 中兩位客委會同仁的主動回報，是 GetGrant 識別並修正多筆虛構記錄的關鍵。
8. 透明：所有編輯流程在 GitHub 公開
GetGrant 的完整 git 歷史在 GitHub 公開：github.com/pppppqa/getgrant2。任何人都可以追溯：
- 每一筆補助何時被新增、何時被修改、何時被下架（commit log）。
- 每一條 reject 規則對應的具體事故（commit message 與 audit report）。
- 每一個稽核腳本的演進歷史（scripts/ 目錄）。
- 每一輪嚴格清理刪除了哪些補助、為什麼刪（commit body）。
- 本頁與 編輯與查核標準 的所有改動歷史。
這份透明度不是為了表演，而是讓使用者、機關承辦同仁、同行網站都能驗證我們是不是說到做到。 如果未來本頁的某條承諾被違反，git 歷史會留下證據。
9. 我們明確不做的 AI 應用
以下情境是 GetGrant 明確拒絕的 AI 應用，即使技術上可行、即使商業上有利：
- ×不用 LLM 「依補助名稱猜測補助內容」 — 事故 B 教訓。
- ×不用 LLM 「依機關名稱推測補助項目」 — 事故 C 教訓。
- ×不用 LLM 「整理他站資料當作官方來源」 — 違反來源優先級第五級規則。
- ×不用 LLM 「生成 FAQ 通過率、補助件數、預算數字」 — 必須有官方公告佐證。
- ×不用 LLM 「自動寫補助案例」 — 案例必須由編輯撰寫並標示為試算。
- ×不用 LLM 「依使用者個資推薦補助」 — 不收集個資，也不會用 AI 做個人化推薦。
- ×不用 AI chatbot 「冒充承辦人回答資格問題」 — 補助資格認定權限在主管機關，不在 GetGrant。
- ×不用 AI 「自動翻譯為其他語言上線」 — 跨語言版本必須由具母語能力的編輯人工審校。
10. 未來政策變更
本頁政策可能隨 AI 技術進步、稽核工具改善、機關協作模式調整而更新。任何變更會：
- 提前 14 天在本頁標示「政策變更預告」。
- 變更生效當天在頁尾「最後更新日」標明變更摘要。
- git commit 歷史保留所有版本，可追溯 diff。
- 重大變更（例如重新引入 AI 內容產製）會在首頁公告 30 天。
但有一條紅線不會變：AI 永遠不會在 GetGrant 上負責「生成補助事實」。 這條寫在本站存在意義裡，違反這條，本站應該關站。