教 Codex 它可以和不可以使用的業務事實
建立一個事實包（Fact Pack），在它研究、起草或改善 SEO 和 GEO 頁面之前，給 Codex 已批准的主張、證明連結、範例、限制和開放問題。
Codex 在你給它一個事實邊界時寫得更好
創造薄弱 SEO 內容的最快方式是要求 AI「寫一篇專家指南」，然後希望它知道你的產品、服務、地點、價格、流程、客戶和限制。
它不知道。事實包解決了這個問題。它是一個小型來源資料夾，告訴 Codex 它可以陳述什麼、事實來自哪裡，以及在你確認之前它必須留白什麼。
完成的定義： 你有一個事實包，包含至少十個事實或來源連結，每個都標記為 confirmed、needs owner fact 或 do not use。你可以為課程中的每個頁面重複使用它。
預留 45 分鐘。 帶上你的流量任務、允許使用的公開頁面和文件，以及一種向擁有者詢問缺失事實的方式。不要上傳密碼、客戶數據、私人合約或你未被授權分享的資料。
按決策收集事實，而不是按部門
打開一個名為 fact-pack.md 的文件。只加入幫助流量任務訪客做出決策的資訊。
事實群組 | 範例 | 安全的來源 |
|---|---|---|
適合度 | 服務適合和不適合誰 | 已批准的服務頁面、擁有者確認 |
流程 | 服務或購買之前、期間和之後會發生什麼 | 文件化的工作流程、支援政策 |
證明 | 資格、產品規格、測試方法、可見範例 | 第一方文件或已批准的證據 |
限制 | 價格邊界、可用性、地點、相容性、排除項目 | 現行政策、庫存系統、擁有者確認 |
下一步 | 預約、購買、試用、註冊、支援路徑 | 即時的轉換頁面或已批准的流程 |
除非你有一個明確的來源，且頁面可以解釋它們，否則不要加入像 best、trusted、fast 或 easy 這類模糊的主張。
從一份來源登記表開始，而不是一堆分頁
建立一個名為 fact-pack 的資料夾。只加入你樂意讓編輯審查的來源副本或連結：
fact-pack/
traffic-mission.md
service-scope.md
onboarding-checklist.pdf
public-terms-url.txt
owner-questions.md
fact-pack.md以記帳的連續範例而言，前五個可用的事實可能是：
事實 | 狀態 | 來源 | 幫助的地方 |
|---|---|---|---|
為個人經營設計師提供每月記帳 | CONFIRMED | 已批准的服務範圍，2026-07-29 | 適合度開場 |
不提供個人稅務申報 | CONFIRMED | 服務條款，2026-07-29 | 範圍邊界 |
入職前會進行探索通話 | CONFIRMED | 入職檢查清單 | 下一步說明 |
服務區域僅限布里斯托 | NEEDS OWNER FACT | 公開文案存在衝突 | 本地適合度段落 |
客戶每月節省數小時 | DO NOT USE | 沒有測量來源 | 從頁面構想中移除 |
請注意，最強的資料列不是一個行銷句子。它是一個改變訪客決策的事實。一個來源必須具體到另一個人稍後可以找到它：頁面 URL、文件名稱、擁有者和審查日期。
先分類，再讓 Codex 組織
自己先快速做第一遍。只有當一個陳述有當前的來源時，才標記為 CONFIRMED；當它可能為真但你無法證明時，標記為 NEEDS OWNER FACT；當它是錯誤、模糊、過時或太有風險時，標記為 DO NOT USE。不要讓 Codex 從銷售語言中推斷狀態。
如果兩個自有來源衝突，把兩者都寫進包裡並將事實標記為 CONFLICT。它變成一個擁有者問題。衝突不是模型應該通過選擇更有吸引力的主張來解決的事情。
用 Codex 建立事實包
你是我的事實包編輯器。
流量任務：
[貼上任務]
我擁有或批准的來源素材：
- [公開 URL]
- [文件路徑]
- [截圖或筆記]
- [擁有者聲明]
建立 fact-pack.md，包含此表格：
FACT | STATUS (CONFIRMED / NEEDS OWNER FACT / DO NOT USE) | SOURCE | WHERE IT HELPS
然後新增：
1. 第一流量頁面所需的事實。
2. 不安全的主張。
3. 最多五個擁有者問題，按重要性排序。
4. 一段簡短的「Codex 規則」：僅使用已確認的事實；標記缺失的事實；
絕不將未知變成主張。
不要發明事實、推斷私人客戶成果、建立推薦、更改來源檔案或發布任何內容。要求主張層級的結果，而不是一份漂亮的摘要
完成的 fact-pack.md 應該包含可以直接在後續草稿中使用的資料列。以下是好與壞的樣貌：
不好的資料列 | 為什麼失敗 | 更好的資料列 |
|---|---|---|
我們提供無壓力的記帳。CONFIRMED。 | 「無壓力」是一種感受，不是可檢查的服務事實。 | 我們在每月記錄交接前發送一份文件化的入職檢查清單。CONFIRMED。來源：入職檢查清單 v3，2026-07-29 審查。 |
我們幫助所有自由工作者。CONFIRMED。 | 「所有」是一個有風險、可能錯誤的適合度主張。 | 個人經營設計師列在已批准的服務範圍中。CONFIRMED。其他自由工作者類型：NEEDS OWNER FACT。 |
我們是本地商家。CONFIRMED。 | 它沒有告訴訪客地點或是否提供遠端服務。 | 僅限布里斯托對比英國遠端可用性：NEEDS OWNER FACT。在擁有者確認之前不要陳述服務區域。 |
如果模型將缺失的事實轉化成流暢的文案，使用這個修正：
逐行審查事實包。將每個沒有支持的形容詞、結果、數量、地點、價格、
時間主張或客戶成果，替換為有來源支持的事實、NEEDS OWNER FACT、
CONFLICT 或 DO NOT USE。不要因為一個主張聽起來合理就保留它。在兩分鐘內審查輸出
搜尋事實包中的 CONFIRMED。每個已確認的事實都需要一個讀者或擁有者可以檢查的來源。搜尋 NEEDS OWNER FACT；這些不是失敗。它們正是阻止虛假主張在到達頁面或 AI 回答之前的東西。
不好的事實包條目：客戶節省時間。CONFIRMED。來源：常識。
好的事實包條目：入職檢查清單需要一個已連接的 Shopify 商店和產品饋送。CONFIRMED。來源：入職文件，日期 2026-07-28。幫助的地方：設定適合度段落。
在信任這個包之前執行四次搜尋
逐個搜尋文件中的這些詞彙：
CONFIRMED：每一列都需要一個來源和日期或擁有者參考。NEEDS OWNER FACT：每一列都需要一個直接的問題，而不只是標籤。CONFLICT：每一列需要指出競爭的來源。DO NOT USE：每一列都需要遠離頁面文案，即使它聽起來有說服力。
然後選擇對第一個頁面而言「阻塞性」的三個事實。以記帳指南而言，服務範圍和稅務申報排除項目是阻塞性的。推薦則不是。用一份精簡的請求告訴擁有者你需要什麼：
我正在為 [流量任務] 準備一個頁面。請僅確認這些事實：
1. [特定的服務區域或資格問題]
2. [特定的流程或價格邊界問題]
3. [表單或試用之後的特定行動]
我會將任何未回答的項目標記為 NEEDS OWNER FACT，並且不會將它發布為文案。使用帶日期的變更紀錄
事實會老化。價格、服務區域、產品支援、政策、庫存和入職步驟都會改變。在每個變更的資料列下加入這一行：
Changed：2026-07-29 | Owner/source：[名稱或文件] | Pages to recheck：[URL]當你更新一個事實時，不要讓 Codex 重寫整個網站。讓它列出使用該事實的草稿和頁面，然後僅為受影響的頁面準備可審查的變更。
在每個後續 Codex 提示詞中使用事實包
每當 Codex 研究、起草或修訂一個頁面時，加入這句話：
先閱讀 fact-pack.md。僅使用 CONFIRMED 事實。保持 NEEDS OWNER FACT 可見。
絕不將未知變成一個合理的說法。當一個事實改變時，先更新包，包括日期和來源。然後詢問 Codex 哪些頁面使用該事實。這給你一個安全的路徑來更新變化的價格、服務區域、政策、產品相容性和入職步驟。
給 Codex 一個狹窄的起草邊界
當你到達頁面撰寫課程時，將這個指示加到每個提示詞前面：
在進行任何工作之前閱讀 fact-pack.md。僅使用標記為 CONFIRMED 的資料列。
不要將 NEEDS OWNER FACT、CONFLICT 或 DO NOT USE 的資料列轉化為讀者面向的文案。
對於每個計畫中的主張，引用它來源的事實包資料列。
如果一個必要的句子沒有 CONFIRMED 來源，停下來向擁有者詢問事實。這看起來很嚴格，因為它確實是。事實包是讓 AI 輔助頁面可以被一個沒有寫它的人審查的東西。
保持包足夠小以便使用。一份四十頁的存檔並不會自動比一份包含當前範圍、限制、來源和開放問題的兩頁文件更好。只有當流量任務需要時才加入更多素材。
在每次後續交接之前執行五分鐘的事實檢查
當 Codex 回傳一份草稿、簡報、差異或變更表時，不要假設它遵守了事實包。挑選三行最重要的敘述——通常是資格、範圍、價格、地點、相容性或政策陳述——並要求它顯示確切的支援資料列。如果回應指名了一個不在包裡的來源，在擁有者加入之前，將該主張視為未驗證。
閱讀 [建議的工件] 和 fact-pack.md。為每個重要的公開陳述建立一份主張追蹤表：
確切的主張、事實包資料列、來源/日期、狀態和所需行動。
將任何沒有 CONFIRMED 資料列的陳述標記為 REMOVE OR NEEDS OWNER FACT。
不要改寫工件、發布或軟化一個沒有支持的主張。這在長提示詞之後尤其重要：合理的措辭不等於已批准的事實。將追蹤表與頁面包儲存在一起；它讓後續的發布審查更快，並在事實改變時讓修正成為可能。
課程地圖
下一課：讓 Codex 找出你的客戶已經在問的 30 個真實問題。Codex 現在有一個事實邊界，然後它才將客戶語言轉化為機會。
完成檢查清單
- [ ] 每個已確認的事實都有來源。
- [ ] 缺失的資訊是可見的，而不是被默默假設。
- [ ] 事實包在相關處包含適合度、流程、證明、限制和下一步事實。
- [ ] 我已將
fact-pack.md儲存在未來 Codex 提示詞可以讀取的地方。 - [ ] 我為每個 CONFIRMED 資料列記錄了來源和審查日期。
- [ ] 我將衝突與未知分開，而不是讓 Codex 選擇一個版本。
- [ ] 我為阻塞性事實發送了一份小型、按優先順序排列的擁有者問題請求。
作者：Iris Campbell，Auspia 編輯證據分析師，審查超過 2,500 個來源。Iris 專注於讓 AI 輔助內容保持有用和準確的證據系統。
![事實包工作包流程圖]()
對這項作業使用此順序：從真實輸入開始，檢查證據，準備一個可審查的輸出，然後選擇讀者的下一步。
