entity-optimizer

Entity Optimizer

稽核、建立並維護實體在搜尋引擎與 AI 系統中的身份。實體 — 即搜尋引擎與 AI 系統視為獨立事物的個人、組織、產品與概念 — 是 Google 與大型語言模型決定「品牌是什麼」以及「是否引用它」的基礎。

為什麼實體對 SEO + GEO 很重要：

• SEO：Google 的知識圖譜驅動知識面板、豐富結果及基於實體的排名訊號。定義良好的實體能獲得搜尋結果頁面的版位。
• GEO：AI 系統在生成答案前會先將查詢解析為實體。如果 AI 無法識別某個實體，就無法引用它 — 無論內容多好都沒用。

此技能的功能

稽核實體在知識圖譜、維基數據、維基百科及 AI 系統中的存在度；繪製全部 6 大訊號類別（47 項訊號）；產出差異分析、建立計畫及消歧策略。

快速開始

從以下提示之一開始。最後產出標準化實體檔案及一份交接摘要，使用技能合約中的儲存庫格式。

實體稽核

稽核 [品牌/人物/組織] 的實體存在度

搜尋引擎與 AI 系統對 [實體名稱] 的識別程度如何？

建立實體存在度

為 [新品牌] 在 [產業] 領域建立實體存在度

將 [人物名稱] 建立為 [主題] 領域的認可專家

修正實體問題

我的知識面板顯示錯誤資訊 — 修正 [實體] 的實體訊號

AI 系統將 [我的實體] 與 [其他實體] 混淆 — 協助我進行消歧

技能合約

預期輸出：一份實體稽核報告、一份標準化實體檔案，以及一份可直接存入 memory/entities/ 的簡短交接摘要。

• 讀取：實體名稱、主要網域、已知檔案、主題關聯及先前的品牌背景。
• 寫入：一份使用者導向的實體報告，加上可重複使用的檔案，可儲存於 memory/entities/ 下。
• 提升：標準化名稱、sameAs 連結、消歧註記及實體缺口至 memory/hot-cache.md、memory/entities/ 及 memory/open-loops.md。
• 完成條件：6 大訊號類別各獲得 Pass/Fail/Partial 評分，AI 解析測試已執行（或標記為使用者自行執行），並產出標準化檔案及前 5 項優先行動。

此技能是 memory/entities/<name>.md 標準化實體檔案的唯一寫入者。其他技能僅將實體候選寫入 memory/entities/candidates.md。當累積 3 個以上候選時，應建議使用此技能。

檔案結構：每個標準化實體檔案的前置資料遵循 Entity-GEO Handoff Schema 中的權威合約。該結構定義了下游技能（geo-content-optimizer、schema-markup-generator、meta-tags-optimizer、ai-overview-recovery）所依賴的欄位。請勿省略必要欄位 — 否則消費者會優雅降級為 DONE_WITH_CONCERNS 並產生指向此處的 open_loop。

• 主要後續技能：一旦實體真相明確，使用下方的 Next Best Skill。

交接摘要

依照 skill-contract.md §Handoff Summary Format 發出標準格式。

資料來源

有工具時：查詢知識圖譜 API、~~SEO 工具、~~AI 監控工具、~~品牌監控工具。無工具時：向使用者詢問實體名稱/類型、網域、檔案、主題及消歧背景。請參閱 CONNECTORS.md。

零依賴本地輔助工具（無需金鑰）：python3 "${CLAUDE_PLUGIN_ROOT}/scripts/connectors/kg.py" reconcile "<entity>" 將名稱解析為維基數據 QID 並附上信心分數（判斷驅動知識面板與 AI 答案的開放知識圖譜是否識別該實體）；kg.py entity <QID> 回傳 claims 與 sameAs。請參閱 scripts/connectors/README.md。

決策閘門

停止並詢問使用者，當：

• 未提供實體名稱且無法從專案背景推斷 — 在稽核前詢問實體名稱與類型。
• 實體為個人（創辦人、作者、公眾人物）且可能為歐盟/歐洲經濟區/英國居民，在寫入 memory/entities/ 前 — 提示：「您即將為某人建立標準化檔案。如果此人為或可能為歐盟/歐洲經濟區/英國居民，GDPR 第 6 條要求合法基礎：(1) 同意、(2) 正當利益、(3) 合約、(4) 其他。對於非歐盟主體，請檢查當地法規（CCPA/CPRA、PIPEDA、LGPD 等）。如果不確定，請跳過並回傳 NEEDS_INPUT。」僅在使用者確認基礎後才繼續。僅供參考 — 不構成法律建議。參考：Memory Management — GDPR / Privacy Compliance。

靜默繼續（永不停止）：

• 缺少 ~~AI 監控工具或 ~~知識圖譜工具存取權 — 將那些行標記為使用者自行執行，並根據使用者提供的觀察繼續。
• 個別訊號未知 — 將其評為 Partial 並附上驗證行動，然後繼續。

操作說明

當使用者要求實體優化時：

步驟 1：實體發現

建立實體在所有系統中的當前狀態。

### 實體檔案

**實體名稱**：[名稱]
**實體類型**：[人物 / 組織 / 品牌 / 產品 / 創意作品 / 活動]
**主要網域**：[URL]
**目標主題**：[主題 1, 主題 2, 主題 3]

#### 當前實體存在度

| 平台 | 狀態 | 詳細資訊 |
|----------|--------|---------|
| Google 知識面板 | ✅ 存在 / ❌ 不存在 / ⚠️ 錯誤 | [詳細資訊] |
| 維基數據 | ✅ 已列出 / ❌ 未列出 | [QID（若存在）] |
| 維基百科 | ✅ 條目 / ⚠️ 僅提及 / ❌ 不存在 | [知名度評估] |
| Google 知識圖譜 API | ✅ 找到實體 / ❌ 未找到 | [實體 ID、類型、分數] |
| 網站上的 Schema.org | ✅ 完整 / ⚠️ 部分 / ❌ 缺少 | [Organization/Person/Product schema] |

#### AI 實體解析測試

**注意**：Claude 無法在沒有工具存取權的情況下直接查詢其他 AI 系統或執行即時網路搜尋。當沒有 ~~AI 監控工具或 ~~知識圖譜工具時，請要求使用者執行這些測試查詢並回報結果，或使用使用者提供的資訊來評估實體存在度。

透過查詢以下內容測試 AI 系統如何識別此實體：
- 「[實體名稱] 是什麼？」
- 「誰創立了 [實體名稱]？」（針對組織）
- 「[實體名稱] 做什麼？」
- 「[實體名稱] vs [競爭對手]」

| AI 系統 | 是否識別實體？ | 描述準確度 | 是否引用實體內容？ |
|-----------|-------------------|---------------------|------------------------|
| ChatGPT | ✅ / ⚠️ / ❌ | [準確度備註] | [是/否/部分] |
| Claude | ✅ / ⚠️ / ❌ | [準確度備註] | [是/否/部分] |
| Perplexity | ✅ / ⚠️ / ❌ | [準確度備註] | [是/否/部分] |
| Google AI Overview | ✅ / ⚠️ / ❌ | [準確度備註] | [是/否/部分] |

步驟 2：實體訊號稽核

評估 6 大類別的實體訊號。完整的 47 項訊號檢查清單及驗證方法，請參閱 Entity Signal Checklist。

將每個訊號評為 Pass / Fail / Partial，並針對每個缺口提出具體行動。6 大類別為：

1. 結構化資料訊號 — Organization/Person schema、sameAs 連結、@id 一致性、作者 schema
2. 知識庫訊號 — 維基數據、維基百科、CrunchBase、產業目錄
3. 一致的 NAP+E 訊號 — 跨平台的名稱/描述/標誌/社交媒體一致性
4. 基於內容的實體訊號 — 關於頁面、作者頁面、主題權威性、品牌反向連結
5. 第三方實體訊號 — 權威提及、共同引用、評論、媒體報導
6. AI 特定實體訊號 — 清晰定義、消歧、可驗證聲明、可爬取性

參考：使用 Entity Signal Checklist 中的稽核範本，取得完整的 47 項訊號檢查清單及各類別的驗證方法。

步驟 3：報告與行動計畫

產出實體優化報告，內容包含：概覽（實體/類型/日期）、訊號類別摘要（6 大類別 ✅/⚠️/❌ 表格及發現）、關鍵問題、前 5 項優先行動（影響 × 努力）、實體建立路線圖（第 1-2 週 → 第 1 個月 → 第 2-3 個月 → 持續進行），以及 CORE-EEAT A07/A08 + CITE I01-I10 交叉參考。

參考：完整的步驟 3 報告範本請參閱 Entity Signal Checklist。

儲存結果

詢問「是否儲存這些結果以供未來使用？」（請參閱 Skill Contract §Save Results Template）— 如果是，則將標準化實體檔案寫入 memory/entities/<entity-slug>.md，使用上述的檔案結構。如果該實體對專案至關重要，也請在 memory/hot-cache.md 中加入 1-3 行的指標；請勿將標準化檔案儲存到通用的 memory/YYYY-MM-DD-<topic>.md 模式中。

在寫入任何標準化檔案之前，請檢查 memory/audits/gdpr-purges.md 中是否有先前清除此實體的記錄（依去識別化標籤或網域）。如果存在，請勿靜默重新建立檔案；回傳 NEEDS_INPUT 並要求使用者確認應重新加入該實體。

範例

使用者：「稽核 Acme Analytics 的實體存在度，我們的 B2B SaaS 分析平台，網域為 acme-analytics.example」

輸出（簡化）：AI 解析測試顯示部分識別 — ChatGPT 將其描述為通用的「分析工具」，缺乏 B2B 特異性；未列在企業分析廠商中；創辦人對 AI 系統而言未知。健康摘要標記缺少維基數據條目且無知識面板，優先行動涵蓋維基數據提交、sameAs 連結及創辦人簡介頁面。

參考：完整的實體稽核報告（含 AI 解析測試結果、實體健康摘要、前 3 項優先行動及 CORE-EEAT/CITE 交叉參考）請參閱 Example Audit Report。

實體類型參考

參考：各實體類型的關鍵訊號、結構化資料及依情境的消歧策略，請參閱 Entity Type Reference。

知識面板與維基數據優化

參考：知識面板的聲明/編輯、常見問題與修正、維基數據條目建立、各實體類型的關鍵屬性及 AI 實體解析優化，請參閱 Knowledge Panel & Wikidata Guide。

參考資料

實體優化的詳細指南：

• Entity Signal Checklist — 完整的訊號檢查清單及驗證方法、步驟 3 報告範本及成功秘訣
• Knowledge Graph Guide — 維基數據、維基百科及知識圖譜優化實戰手冊

Next Best Skill

主要：schema-markup-generator。亦可考慮：geo-content-optimizer（AI 識別缺口）或 seo-content-writer（需要新的關於/創辦人頁面時）。