content-quality-auditor

內容品質審核員

基於 CORE-EEAT 內容基準。完整基準參考：references/core-eeat-benchmark.md

此技能根據 8 個面向共 80 項標準化標準評估內容品質。產出完整的審核報告，包含逐項評分、面向與系統分數、依內容類型加權的總分，以及優先處理行動計畫。

何時必須觸發

當內容在發布前需要品質檢查時使用——即使使用者未使用審核術語：

• 使用者問「這可以發布了嗎」或「這個品質如何」
• 使用者剛用 seo-content-writer 或 content-refresher 寫完內容
• PostToolUse 鉤子建議：內容撰寫或大幅編輯後，命令支援的鉤子可能建議執行此審核。鉤子觸發時，跳過設定問題——直接審核剛產出的內容。
• 發布前審核內容品質
• 評估現有內容以尋找改善機會
• 將內容與 CORE-EEAT 標準進行基準比對
• 比較內容品質與競爭對手
• 同時評估 GEO 就緒度（AI 引用潛力）與 SEO 強度（來源可信度）
• 作為內容維護計畫的一部分，定期執行內容品質檢查
• 使用 seo-content-writer 或 geo-content-optimizer 撰寫或最佳化內容後

此技能的功能

1. 完整 80 項審核：為每項 CORE-EEAT 檢查項目評分（通過/部分/未通過）
2. 面向評分：計算全部 8 個面向的分數（各 0-100）
3. 系統評分：計算 GEO 分數（CORE）與 SEO 分數（EEAT）
4. 加權總分：套用內容類型特定權重計算最終分數
5. 否決偵測：標記關鍵信任違規（T04、C01、R10）
6. 優先排序：找出影響最大的前 5 項改善項目
7. 行動計畫：產生具體、可執行的改善步驟

快速開始

從以下提示開始。最後以發布結論及交接摘要結束，格式請參考 Skill Contract 中的儲存庫格式。

審核內容

針對 CORE-EEAT 審核此內容：[內容文字或 URL]

對 [URL] 執行內容品質審核，類型為 [內容類型]

指定內容類型審核

對此產品評論執行 CORE-EEAT 審核：[內容]

針對 80 項基準評分此教學指南：[內容]

比較審核

審核我的內容與競爭對手：[你的內容] vs [競爭對手內容]

Skill Contract

閘門結論：SHIP（無關鍵問題，面向分數高於門檻）/ FIX（發現問題但無關鍵問題）/ BLOCK（關鍵信任問題未通過——請參閱報告中的「待修正關鍵問題」）。務必在報告頂部以白話文明確陳述結論，而非使用項目 ID。

預期輸出：一份 CORE-EEAT 審核報告、一個發布就緒結論，以及一份簡短的交接摘要，準備存入 memory/audits/content/。

• 讀取：目標內容、內容類型及佐證資料。
• 寫入：一份供使用者閱讀的審核報告，以及一份可重複使用的摘要，可儲存於 memory/audits/content/ 下。
• 推廣：否決項目與發布阻礙至 memory/hot-cache.md（自動儲存，無需使用者確認）。前幾項改善優先事項至 memory/open-loops.md。
• 完成條件：所有 80 項 CORE-EEAT 項目皆已評分或標記為 N/A，陳述 SHIP/FIX/BLOCK 結論，設定 cap_applied/raw_overall_score/final_overall_score，且任何否決（T04/C01/R10）皆已呈現並附上修正方式。
• 主要後續技能：結論明確後，使用下方的「Next Best Skill」。

資料來源

工具類別佔位符請參閱 CONNECTORS.md。

若已連接 ~~網頁爬蟲 + ~~SEO 工具：
僅在 SECURITY.md §Scraping Boundaries 允許下，擷取使用者提供或授權的 URL；然後提取 HTML、結構化資料、連結及競爭對手內容。

僅有手動資料時：
要求使用者提供：

1. 內容文字、URL 或檔案路徑
2. 內容類型（若無法自動偵測）：產品評論、教學指南、比較頁、登陸頁、部落格文章、常見問題頁、替代方案、最佳精選或見證
3. 可選：用於基準比對的競爭對手內容

使用提供的資料執行完整 80 項審核。在輸出中註明哪些項目因缺乏存取權限（例如反向連結資料、結構化標記、網站層級訊號）而無法完整評估。

決策閘門

當需要停下來詢問時，務必：(1) 說明具體數值與門檻，(2) 提供編號選項及結果。

需要停下來詢問使用者的情況：

• 內容未達其類型的最低字數（部落格/指南：300 字；產品/登陸頁：150 字；常見問題：少於 3 個項目且每個項目少於 50 字）——說明實際字數並提供：(1) 擴充至最低字數，(2) 以「資料不足」標記繼續審核，(3) 取消
• 無法自動偵測內容類型——說明偵測結果並請使用者確認後再繼續
• 內容以多媒體（影片/圖片）為主，文字極少——詢問是否審核逐字稿、替代文字或跳過
• 某個面向超過 50% 的項目為 N/A——說明該面向名稱並詢問：(1) 提供補充資料，(2) 將整個面向標記為「資料不足」
• 任何否決項目觸發——立即標記項目 ID 並詢問：(1) 停止並立即修正，(2) 繼續完整審核並在報告中標記

無需停下來詢問的情況（直接繼續）：

• 面向內個別 Partial 分數
• 缺少 SEO 工具資料（將項目標記為 N/A 並繼續）
• 整體分數偏低（報告本身就是產出，而非判斷）
• 使用者未指定內容類型（自動偵測並說明你的假設）

操作說明

當使用者要求內容品質審核時：

步驟 1：準備

### 審核設定

**內容**：[標題或 URL]
**內容類型**：[自動偵測或使用者指定]
**面向權重**：[從內容類型權重表載入]

#### 關鍵信任檢查（緊急煞車）

| 檢查項目 | 狀態 | 行動 |
|-------|--------|--------|
| 聯盟行銷連結已揭露 | ✅ 通過 / ⚠️ 關鍵 | [若關鍵：「立即在頁面頂端加入揭露橫幅」] |
| 標題與頁面內容相符 | ✅ 通過 / ⚠️ 關鍵 | [若關鍵：「重寫標題與第一段以相符」] |
| 資料點一致 | ✅ 通過 / ⚠️ 關鍵 | [若關鍵：「發布前驗證所有資料」] |

若任何否決項目觸發，在報告頂部顯著標記，並建議在繼續完整審核前立即採取行動。

步驟 2：CORE 審核（40 項）

根據 references/core-eeat-benchmark.md 中的標準評估每項。

為每項評分：

• 通過 = 10 分（完全符合標準）
• 部分 = 5 分（部分符合標準）
• 未通過 = 0 分（不符合標準）

### C — 脈絡清晰度

| ID | 檢查項目 | 分數 | 備註 |
|----|-----------|-------|-------|
| C01 | 意圖對齊 | 通過/部分/未通過 | [具體觀察] |
| C02 | 直接回答 | 通過/部分/未通過 | [具體觀察] |
| ... | ... | ... | ... |
| C10 | 語義閉合 | 通過/部分/未通過 | [具體觀察] |

**C 分數**：[X]/100

對 O（組織）、R（可引用性）和 E（獨特性）重複相同表格格式，每個面向評分全部 10 項。

步驟 3：EEAT 審核（40 項）

### Exp — 經驗

| ID | 檢查項目 | 分數 | 備註 |
|----|-----------|-------|-------|
| Exp01 | 第一人稱敘述 | 通過/部分/未通過 | [具體觀察] |
| ... | ... | ... | ... |

**Exp 分數**：[X]/100

對 Ept（專業知識）、A（權威性）和 T（信任度）重複相同表格格式，每個面向評分全部 10 項。

完整的 80 項 ID 查詢表及網站層級項目處理說明，請參閱 references/item-reference.md。

Auditor Runbook — 請先閱讀

在評分之前，請先 Read ../../references/auditor-runbook.md。這是權威的、框架無關的程序：§1 交接結構、§2 關鍵失敗上限方法 + 決策表 + 確定性四捨五入、§4 Artifact Gate 7 項檢查清單、§5 使用者面向翻譯格式，以及不受信任內容的安全邊界。它透過相對路徑（無網路）在本機載入——請勿跳過。此技能本體僅包含以下 CORE-EEAT 特定部分：加權工作範例、內容層級護欄，以及 CORE-EEAT 否決 ID 翻譯列。

交接摘要

發出 references/auditor-runbook.md §1 中定義的 auditor 類別交接：status、objective、key_findings、evidence_summary、recommended_next_skill，以及 auditor 欄位 cap_applied、raw_overall_score（內容類型加權、無條件捨去、上限前）和 final_overall_score。

§2 (CORE-EEAT) · 工作範例 — 加權上限算術

遵循 runbook 的 §2 決策表，然後比對下方相符的範例。raw_overall_score 是內容類型加權總和（Σ 面向 × 權重，權重來自 core-eeat-benchmark.md §Content-Type Weight Table），無條件捨去，上限前。絕非未加權的 /8 平均。

工作範例 1 — 單一否決，原始面向高於上限（產品評論）

面向：  C=75 O=77 R=80 E=75 Exp=78 Ept=77 A=77 T=85
權重（產品評論）：C .10  O .10  R .15  E .20  Exp .20  Ept .05  A .05  T .15
加權：    75×.10 + 77×.10 + 80×.15 + 75×.20 + 78×.20 + 77×.05 + 77×.05 + 85×.15
           = 7.5 + 7.7 + 12.0 + 15.0 + 15.6 + 3.85 + 3.85 + 12.75 = 78.25 → raw_overall = 78

否決檢查：T04 未通過（聯盟行銷連結未揭露）

上限後：  T 面向 85 → 60（向下上限，原始 > 60）
            整體 78 → 60（任何否決強制整體上限）

交接：    cap_applied: true   raw_overall_score: 78   final_overall_score: 60
            key_findings:
              - title: "缺少聯盟行銷揭露"
                severity: veto
                evidence: "無揭露橫幅；內文偵測到 3 個聯盟行銷連結"

工作範例 2 — 單一否決，原始面向已低於上限（常見問題頁）

面向：  C=55 O=75 R=88 E=80 Exp=80 Ept=75 A=82 T=85
權重（常見問題頁）：C .25  O .25  R .15  E .05  Exp .05  Ept .10  A .05  T .10
加權：    55×.25 + 75×.25 + 88×.15 + 80×.05 + 80×.05 + 75×.10 + 82×.05 + 85×.10
           = 13.75 + 18.75 + 13.2 + 4.0 + 4.0 + 7.5 + 4.1 + 8.5 = 73.8 → raw_overall = 73

否決檢查：C01 未通過（標題與內容不符的點擊誘餌）

上限後：  C 面向 55 → 55（不變；上限是天花板，不是地板）
            整體 73 → 60（整體仍因存在否決而受限）

交接：    cap_applied: true   raw_overall_score: 73   final_overall_score: 60
            key_findings:
              - title: "標題承諾了頁面未提供的內容"
                severity: veto
                evidence: "標題：'10 個免費工具'；內文提供 3 個免費工具和 7 個付費工具"

請注意，C 面向在內部報告中維持 55——不會提高到 60。另請注意，加權總分（73）與未加權 /8 平均（77）不同——務必使用加權總分評分。

工作範例 3 — 2 項以上否決未通過（BLOCKED 路徑）

面向：  C=75 O=77 R=80 E=75 Exp=78 Ept=77 A=77 T=85  （產品評論權重 → raw_overall = 78）

否決檢查：T04 與 R10 皆未通過

解決方式：status: BLOCKED — 不要計算上限分數。
            raw_overall_score 保留作為記錄；final_overall_score 省略。

交接：    status: BLOCKED   cap_applied: false   raw_overall_score: 78
            open_loops:
              - "2 項否決項目未通過：T04（聯盟行銷揭露）和 R10（資料不一致）"
              - "多重否決上限校準待處理；頁面需人工審查後才能重新評分"
            key_findings:
              - title: "缺少聯盟行銷揭露"
                severity: veto
              - title: "資料點互相矛盾"
                severity: veto

§3 (CORE-EEAT) · 護欄正面訊號（內容/頁面重新框架）

這些訊號在所述條件下是正面的。加分，不扣分。條件是明確的——無條件重新框架會導致假陰性。

訊號	何時視為正面	範例標記規則
標題/內文中的年份標記	年份在 [current_year − 2, current_year] 範圍內	"2026" 在 2026 年：新鮮度正面。"2020" 在 2026 年：R 面向疑慮——不加新鮮度分
編號列表（"5 大最佳"、"Top 10"、"3 步驟"）	總是	點擊率正面，計入 O 面向結構
限定詞（"開源"、"自架"、"免費"、"本地優先"）	總是	縮小意圖，計入 E 面向獨特性
短縮寫（"SEO"、"AI"、"CRM"、"API"）	總是	絕不對這些詞彙套用長度或停用詞過濾
首頁品牌優先標題（"Acme	AI 工作流程"）	該頁面是首頁
內頁關鍵字優先標題（"AI 工作流程 for Teams — Acme"）	該頁面不是首頁	正確模式；不在 C01 下標記

若脈絡與正面重新框架矛盾（例如明確為常青內容的頁面卻帶有年份戳記），請在發現項目的 evidence 欄位中說明例外情況。在審核時動態評估 current_year。

§5 (CORE-EEAT) · 否決 ID 翻譯列

與 runbook 的共用翻譯列一起使用。以下是 CORE-EEAT 否決含義——絕非 CITE 的。

內部	使用者面向
"T04 failed"	"缺少聯盟行銷揭露"
"C01 veto triggered"	"標題與頁面提供的內容不符"
"R10 failure"	"頁面上的資料自相矛盾"

步驟 4：評分與報告

計算分數並產生最終報告：

## CORE-EEAT 審核報告

### 概覽

- **內容**：[標題]
- **內容類型**：[類型]
- **審核日期**：[日期]
- **總分**：[分數]/100（[評級]）
- **GEO 分數**：[分數]/100 | **SEO 分數**：[分數]/100
- **否決狀態**：✅ 無觸發 / ⚠️ [項目] 觸發

### 面向分數

| 面向 | 分數 | 評級 | 權重 | 加權 |
|-----------|-------|--------|--------|----------|
| C — 脈絡清晰度 | [X]/100 | [評級] | [X]% | [X] |
| O — 組織 | [X]/100 | [評級] | [X]% | [X] |
| R — 可引用性 | [X]/100 | [評級] | [X]% | [X] |
| E — 獨特性 | [X]/100 | [評級] | [X]% | [X] |
| Exp — 經驗 | [X]/100 | [評級] | [X]% | [X] |
| Ept — 專業知識 | [X]/100 | [評級] | [X]% | [X] |
| A — 權威性 | [X]/100 | [評級] | [X]% | [X] |
| T — 信任度 | [X]/100 | [評級] | [X]% | [X] |
| **加權總分** | | | | **[X]/100** |

**分數計算**：
- GEO 分數 = (C + O + R + E) / 4
- SEO 分數 = (Exp + Ept + A + T) / 4
- 加權分數 = Σ（面向分數 × 內容類型權重）

**評級量表**：90-100 優異 | 75-89 良好 | 60-74 中等 | 40-59 低 | 0-39 差

### N/A 項目處理

當項目無法評估時（例如 A01 反向連結設定檔需要網站層級資料但無法取得）：

1. 將項目標記為「N/A」並附上原因
2. 從面向分數計算中排除 N/A 項目
3. 面向分數 = （已評分項目總和）/ （已評分項目數量 × 10） × 100
4. 若某面向超過 50% 的項目為 N/A，將該面向標記為「資料不足」並從加權總分中排除
5. 僅使用資料充足的面向重新計算加權總分，重新正規化權重使其總和為 100%

**範例**：權威性面向有 8 個 N/A 項目和 2 個已評分項目（A05=8, A07=5）：
- 面向分數 = (8+5) / (2 × 10) × 100 = 65
- 但 8/10 項目為 N/A（>50%），因此標記為「資料不足 — 權威性」
- 從加權總分中排除 A 面向；將其權重按比例重新分配給其餘面向

### 逐項分數

#### CORE — 內容主體（40 項）

| ID | 檢查項目 | 分數 | 備註 |
|----|-----------|-------|-------|
| C01 | 意圖對齊 | [通過/部分/未通過] | [觀察] |
| C02 | 直接回答 | [通過/部分/未通過] | [觀察] |
| ... | ... | ... | ... |

#### EEAT — 來源可信度（40 項）

| ID | 檢查項目 | 分數 | 備註 |
|----|-----------|-------|-------|
| Exp01 | 第一人稱敘述 | [通過/部分/未通過] | [觀察] |
| ... | ... | ... | ... |

### 依嚴重性分層的發現

在「前 5 項優先改善」之前呈現。根據 [Runbook §5 Severity tier routing](../../references/auditor-runbook.md) 將每個 `key_findings` 項目按 `severity` 分組：`veto` → **關鍵問題（必須修正）**，`high` → **應修正**，`medium`/`low` → **有則改之**。在每個層級內按 `weight × points lost` 排序（最高優先）。套用 §5 Never say → Always say 翻譯——使用者輸出中不得出現 `P0/P1/P2` 或 `severity:` 字面值。省略空層級標題。

```markdown
**關鍵問題（必須修正）**
- [項目名稱] — [白話觀察]

**應修正**
- [項目名稱] — [觀察]

**有則改之**
- [項目名稱] — [觀察]

前 5 項優先改善

排序依據：所有層級的 weight × points lost（影響最高優先）。這是跨層級的重點；上述分層細項是完整畫面。

1. [ID] [名稱] — [具體修改建議]

   • 目前：[未通過/部分] | 潛在增益：[X] 加權分數
   • 行動：[具體步驟]

2. [ID] [名稱] — [具體修改建議]

   • 目前：[未通過/部分] | 潛在增益：[X] 加權分數
   • 行動：[具體步驟]

3–5. [相同格式]

行動計畫

快速勝利（< 30 分鐘）

• [ ] [行動 1]
• [ ] [行動 2]

中等努力（1-2 小時）

• [ ] [行動 3]
• [ ] [行動 4]

策略性（需規劃）

• [ ] [行動 5]
• [ ] [行動 6]

建議後續步驟

• 如需完整內容重寫：使用 seo-content-writer 並帶入 CORE-EEAT 限制條件
• 如需 GEO 最佳化：使用 geo-content-optimizer 針對未通過的 GEO-First 項目
• 如需內容更新：使用 content-refresher 並以弱勢面向為重點
• 如需技術修正：執行 /aaron-seo-geo:audit --tech 處理網站層級問題

#### 步驟 4.5：套用評分 Runbook

依序執行，使用 [references/auditor-runbook.md](../../references/auditor-runbook.md) 中的框架無關程序，以及本檔案中的 CORE-EEAT 特定 §2 工作範例、§3 護欄和 §5 否決列：

1. **上限執行**（Runbook §2）：走決策表。識別你的輸入符合哪種情境（0 否決、1 否決高於上限、1 否決低於上限、或 2+ 否決）。套用上限規則——記住這是天花板，不是地板。在交接中設定 `cap_applied`。
2. **Artifact Gate 自我檢查**（Runbook §4）：執行 7 項檢查清單。若任何項目未通過，強制設定 `status: BLOCKED` 並在 `open_loops` 中說明原因。
3. **使用者面向翻譯**（Runbook §5）：在呈現使用者面向報告前翻譯內部語言。否決 ID、原始與上限差異、以及內部欄位名稱不得出現在渲染輸出中。交接 YAML 保留原始值供下游消費者使用；使用者看到的是白話發現和單一分數，並附上說明句。

#### 儲存結果

將審核產出寫入 `memory/audits/content/YYYY-MM-DD-<topic>.md`（來自 [skill-contract.md §Write Paths](../../references/skill-contract.md) 的按角色路徑；PostToolUse Artifact Gate 會驗證 `memory/audits/` 下的任何內容），並在其 frontmatter 中設定 `class: auditor-output`。將任何否決問題推廣至 `memory/hot-cache.md`。`memory-management` 稍後會將這些彙總到每月 `memory/audits/YYYY-MM.md` 中。請勿將審核產出儲存到裸 `memory/` 路徑——這會繞過閘門。

### 驗證檢查點

#### 輸入驗證
- [ ] 已識別內容來源（文字、URL 或檔案路徑）
- [ ] 已確認內容類型（自動偵測或使用者指定）
- [ ] 內容足夠充實以進行有意義的審核（≥300 字）
- [ ] 若為比較審核，競爭對手內容也已提供

#### 輸出驗證
- [ ] 所有 80 項已評分（或標記為 N/A 並附原因）
- [ ] 所有 8 個面向分數計算正確
- [ ] 加權總分與內容類型權重設定相符
- [ ] 否決項目已檢查並在觸發時標記
- [ ] **依嚴重性分層的發現區塊在前 5 項之前呈現**——當 key_findings 有項目時，至少有一個層級（關鍵/應修正/有則改之）非空；省略空層級標題
- [ ] 前 5 項改善按加權影響排序，而非任意排序
- [ ] 每項建議具體且可執行（非一般性建議）
- [ ] 行動計畫包含具體步驟與努力程度估計
- [ ] 使用者可見輸出中無 P0/P1/P2 或 `severity: …` 字面值（依 Runbook §5 翻譯）

### 範例

完整的評分範例（顯示 C 面向全部 10 項、優先改善及加權評分）請參閱 [references/item-reference.md](references/item-reference.md)。

### 成功秘訣

1. **從否決項目開始**——T04、C01、R10 無論總分如何都是關鍵
   > 這些否決項目與 CORE-EEAT 基準（第 3 節）一致，該基準將其定義為可覆蓋整體分數的項目。
2. **專注於高權重面向**——不同內容類型優先考慮不同面向
3. **GEO-First 項目對 AI 可見性最重要**——若目標是 AI 引用，優先處理標記為 GEO 🎯 的項目
4. **某些 EEAT 項目需要網站層級資料**——不要因僅在網站層級可觀察到的事項（反向連結、品牌認知）而處罰內容
5. **使用加權分數，而非僅原始平均**——獨特性強的產品評論比權威性強更重要
6. **改善後重新審核**——再次執行以驗證分數改善並捕捉回歸
7. **搭配 CITE 以獲得網域層級脈絡**——低權威網域上的高內容分數與相反情況代表不同的優先事項；執行 [domain-authority-auditor](../domain-authority-auditor/SKILL.md) 以獲得完整的 120 項畫面

### 參考資料

- [CORE-EEAT 內容基準](../../references/core-eeat-benchmark.md) — 完整的 80 項基準，包含面向定義、評分標準及 GEO-First 項目標記
- [項目參考](references/item-reference.md) — 所有 80 個項目 ID 的緊湊查詢表 + 網站層級項目處理說明 + 評分範例報告

### Next Best Skill

主要：[content-refresher](../../optimize/content-refresher/SKILL.md)（FIX 結論）。BLOCK：[seo-content-writer](../../build/seo-content-writer/SKILL.md) 或 [entity-optimizer](../entity-optimizer/SKILL.md)。SHIP：[rank-tracker](../../monitor/rank-tracker/SKILL.md)。