修正讓搜尋引擎和 AI 錯誤描述你的公開事實
使用 Codex 比較你控制的公開事實，識別損害搜尋和 AI 準確性的矛盾，並建立一個經人工批准的修正佇列。
一個強大的頁面無法獨自修復一個公開的矛盾
如果你的網站說一個服務區域、一個檔案說另一個、一個舊目錄說第三個，搜尋者和回答系統就沒有乾淨的事實可以重複。在追逐提及之前，先修復你控制的事實。
完成的定義： 一個實體修正佇列，列出一條權威事實、每個它衝突的控制位置，以及一個經人工批准的更新順序。
為第一個佇列預留 45 分鐘。 帶上事實包和你被允許檢查的公開頁面或檔案匯出。這堂課修正客戶決策事實，而不是網路上每一個舊提及。
只選擇影響決策的事實
從五個開始：官方名稱、服務/類別、網站、地點/服務區域、聯絡/營業時間或可用性。只有當你的流量任務需要時，才加入產品相容性、價格邊界、政策或作者資格。
在比較頁面之前製作一份權威事實表
以記帳範例而言，將擁有者批准的真相寫在一份文件中：
Official name（官方名稱）：[批准的業務名稱]
Offer（服務）：為個人經營設計師提供每月記帳
Does not offer（不提供）：個人自我評稅申報
Service area（服務區域）：NEEDS OWNER FACT；當前自有頁面存在衝突
Website（網站）：https://example-bookkeeping.co.uk/
Discovery-call process（探索通話流程）：由入職檢查清單確認不要因為最精美的現有頁面讀起來好，就稱它為權威。一個權威事實需要一個批准的來源：擁有者確認、現行政策、官方產品文件或其他控制的記錄。
品質檢查： 每個權威行都是 CONFIRMED、NEEDS OWNER FACT 或 DO NOT USE。如果來源衝突，保持衝突可見，而不是為擁有者選擇一個版本。
閱讀我的事實包和這些公開 URL 或檔案匯出：[列表]。建立一個實體修正佇列，
包含欄位：事實、權威值、真相來源、控制位置、觀察到的值、匹配/衝突/未知、
客戶風險和建議修正。將我控制的位置與第三方頁面分開。
按客戶損害排名前三名修正。不要登入、編輯檔案、聯絡第三方，
或假設一個觀察到的頁面是權威的。按損害排名衝突，而不是按惱人程度
在 Codex 建立佇列之後使用這個小型矩陣：
衝突 | 客戶損害 | 控制 | 優先級 |
|---|---|---|---|
自有服務頁面說僅限布里斯托；條款暗示英國遠端 | 訪客可能自我排除或不正確地詢問 | 高 | 先修復 |
目錄有一個舊的泛泛分類 | 一些發現困惑，但預約路徑正確 | 低 | 記錄並稍後審查 |
自有檔案說包含稅務申報 | 訪客可能購買錯誤的服務 | 高 | 先修復 |
舊社交貼文有過時的措辭 | 有限的決策影響 | 中/低 | 記錄；如果可見且受控則修正 |
順序不是「網站，然後每個目錄」。它是在客戶決策點阻止有害錯誤資訊的最短路徑。
如果 Codex 將一個冷門提及排在一個受控的預約頁面之上，回覆：
按客戶損害、擁有權和與決策的接近度重新排名實體修正佇列。
優先處理可以在資格、服務、地點、價格、政策或下一步行動上誤導客戶的受控頁面。
將低影響的提及保留在紀錄中，而不使它們成為本週的任務。按正確的順序修正
- 你網站的可見頁面和轉換資訊。
- 你擁有的檔案和清單。
- 通過其允許的人工流程的重要合作夥伴或目錄記錄。
- 需要修正、重新導向提案或清晰更新說明的舊頁面。
對每次外部更新使用人工審查。Codex 可以準備確切的替代文案和一份變更紀錄；它不能為你驗證擁有權或接受平台條款。
一次準備一份修正包
對一個受控頁面，只在權威事實被批准後使用這個提示詞：
閱讀修正佇列項目 [編號] 和權威事實表。準備一份修正包，包含當前的觀察文字、
已批准的替代文字、真相來源、受控 URL 或檔案、必須批准它的擁有者、
驗證方法、回溯文字，以及可能重複該事實的頁面。
不要登入、編輯檔案、聯絡目錄、提交表單或發布。如果衝突在第三方目錄上，修正包可能包含一份人工請求草稿和允許的修正路徑。它絕不能僅僅因為 Codex 準備了措辭，就聲稱已進行了更新。
讓每個修正可驗證
對一個你控制的修正，保存變更前截圖或匯出的文字、確切的新值、批准的擁有者和日期。對一個第三方頁面，保存請求方法和狀態。不要因為 Codex 起草了它就標記修正完成。
為修正佇列項目 [編號] 準備一份變更表：當前值、批准的權威值、
確切的替代文字、受控 URL/檔案、人工擁有者、驗證方法和回溯/例外說明。
不要進行更新或聯絡任何人。不要追逐每一個舊提及
當一個衝突可以在決策點誤導客戶時優先處理：錯誤的地址、不可用的服務、過時的價格、不正確的資格、損壞的預約路徑或不正確的產品相容性。一個舊的低能見度提及可以保持在紀錄中，而不成為本週的工作。
用前後證據驗證一個修正
對每個你控制的變更，保存舊文字或截圖、批准的新的文字、日期、負責的擁有者和實際驗證。對外部頁面，保存請求日期和狀態，而不是假裝控制。將佇列更新為 verified、requested、blocked 或 not worth pursuing。
不要因為相關頁面的文字看起來相似就更改它。要求 Codex 列出確切事實出現的位置，然後審查每個提議的更新。一個服務區域、產品限制或價格邊界在不同頁面上可能有不同的情境。
保留一份例外紀錄，而不是強迫一致性
不是每個變異都是矛盾。一個服務頁面可能描述一個特定地點，而一個全國支援頁面描述遠端可用性。一個產品頁面可能顯示一個價格範圍，而結帳顯示當前金額。當兩個陳述在不同情境中都為真時，加入一個例外行：
Fact（事實）：服務可用性
General canonical statement（一般權威陳述）：經批准的地方提供遠端服務。
Context exception（情境例外）：布里斯托頁面描述本地接收路徑。
Reason（原因）：不同的訪客路徑，不是衝突的資格。
Owner/source（擁有者/來源）：[批准的來源]這讓修正專案不會將有用的情境壓平為一個模糊的通用主張。
只在真實的變更觸發點上重新審視
當服務、地點、政策、產品相容性、業務名稱、聯絡路徑、價格邊界或公開檔案改變時，重新打開佇列。不要每週尋找微小的措辭差異。目標是客戶準確性，而不是網路上完美的文字相同性。
當擁有者無法確認一個事實時恢復
如果沒人能確認一個服務區域、資格條件、價格邊界或產品限制，從你控制的頁面移除未經驗證的陳述，並將事實記錄為未解決。不要用「通常」或「經常」這類較軟的版本取代它。模糊的語言仍然會誤導一個試圖做出決策的客戶。
對你不控制的第三方記錄，不要與發布者或目錄爭論。準備事實修正，遵循所述的人工流程，並記錄結果。如果它無法被更改，讓你的受控來源頁面更清晰，並將未解決的外部記錄保留在佇列中。
完成檢查清單
- [ ] 權威事實有批准的來源，或保持明確未知。
- [ ] 我按客戶損害和控制排名了三個修正。
- [ ] 在更改任何東西之前準備了一份經人工批准的修正包。
- [ ] 我為每個行動保存了前後證據或外部請求狀態。
當客戶現在可能受到傷害時升級一個修正
有些衝突不能等待下一次每週審查：錯誤的預約路徑、不可用的服務、危險的產品相容性陳述、改變的政策，或決策點上不正確的價格。將這些標記為 URGENT OWNER REVIEW，陳述受控 URL、證據、客戶損害，以及可以批准替代方案的擁有者。Codex 仍然應該準備一份包；它絕不能因為問題聽起來緊急就默默地更改一個實際頁面。
閱讀修正佇列項目 [編號]。建立一份緊急審查說明，包含當前文字、權威來源、
客戶損害、受控 URL、所需的确切批准替代方案、擁有者、驗證檢查和回溯文字。
不要編輯、發布、聯絡第三方或移除歷史證據。這讓緊急性聚焦在客戶決策上，同時保留解釋什麼改變了以及為什麼的審計軌跡。
在緊急修正被驗證之後，將其來源和決策加入常規佇列，這樣後續的頁面不會重複相同的過時措辭。
完成檢查清單
- [ ] 我可以為每個我批准的修正識別權威來源。
- [ ] 我將客戶損害問題標記為緊急，但沒有給 Codex 更改它們的權限。
- [ ] 每個受控更新都有驗證和回溯記錄。
- [ ] 不受控的第三方記錄被記錄為已請求、已阻擋或不值得追求。
課程地圖
下一課：讓 Codex 找到一個你的競爭對手無法輕易複製的信任訊號。
作者：Lydia Hart，Auspia 品牌實體策略師，負責超過 200 個實體審查。Lydia 專注於讓公開事實足夠一致，讓客戶和 AI 系統都能信任。
![實體修正工作包流程圖]()
對這項作業使用此順序：從真實輸入開始，檢查證據，準備一個可審查的輸出，然後選擇讀者的下一步。
