Site Consistency — Offer-Aligned Text Audit

目標：網站上的每段文字都講述同一個故事——即首頁上所陳述的 offer——對同一個客戶，使用相同的承諾、名稱和術語。先進行審計；僅在使用者核准特定行後才進行修正。

兩個嚴格限制：

先審計後修正。 審計是唯讀的。在使用者核准審計表格中的特定行之前，不得修改任何檔案。
僅限文字。 這個技能只修改文字——絕不修改版面、樣式、元件、圖片、路由或頁面結構。請參見「僅限文字編輯規則」。

語言

以使用者在對話中使用的語言與之溝通。報告、表格標題、嚴重性標籤以及「原因」欄位都使用該語言。
當前文字的引用必須是逐字照錄，保持原始語言。
提議的網站文字應使用其所取代文字的語言，以地道且自然的方式書寫（絕非字面翻譯），並保持網站的稱呼方式（例如波蘭語的「Ty」/「Państwo」、德語的「du」/「Sie」）和語氣。
從 <html lang>、i18n 配置、語言環境檔案以及可見的文案中檢測網站語言。對於多語言網站，需識別主要語言環境；如果不確定要審計哪些語言環境，請詢問使用者。

工作流程

請依序執行步驟。步驟 1–6 絕不修改檔案。

步驟 1 — 偵查

閱讀 references/text-inventory.md。建立以下資訊：

技術棧與路由（URL 如何對應到檔案），
文字存放位置：元件/模板、i18n 檔案、Markdown/MDX/內容集合、元資料、電子郵件模板、外部 CMS，
語言環境與網站主要語言，
現有的 offer 文件：docs/offer/offer-brief.md（由 grand-slam-offer 技能撰寫）或 docs/ 中的任何簡報/定位文件。

如果大部分文字存放在外部 CMS 中，且沒有匯出檔案或無法讀取渲染後的網站 URL，請在繼續之前告知使用者哪些部分可以審計、哪些無法審計。

步驟 2 — 從首頁提取 offer

以首次訪客的視角閱讀首頁：先看英雄區，然後依序閱讀每個部分，再加上 <title>、meta description、頁首和頁尾。填寫 Offer Statement：

欄位	解答什麼問題
銷售內容	產品/服務及其形式
目標對象	客戶/人物誌、區隔、市場
核心承諾	客戶獲得的結果（+ 時間框架，若有提及）
機制/差異化	如何交付、為何選擇此方案而非其他替代方案
名稱	offer、產品、方法、套裝方案名稱的準確拼寫
關鍵條款	價格/套裝、保證、稀缺性/截止日期、交付時間——僅限已陳述的部份
主要轉換	主要 CTA 以及點擊後會發生什麼
語氣	語調、稱呼方式、定位（高端、實惠、專家、友善……）

為每個欄位記錄其值與來源（引用 + 位置）。如果某個欄位在首頁上未出現，則寫「未陳述」。如果存在 offer 簡報，請將其與首頁逐欄比對。

對於有多個不同 offer 的網站（例如分別針對不同受眾的服務），記錄首頁的總體 offer 並列出子 offer；每個子 offer 頁面將針對其自身的 offer 以及總體 offer 進行檢查。

步驟 3 — Offer 明確性關卡

當以下所有條件成立時，offer 為明確：

「銷售內容」、「目標對象」、「核心承諾」和「主要轉換」可以單獨從首頁獲得解答。
首頁呈現一個主要 offer（或一個清晰的總體 offer 搭配子 offer）——無衝突的 offer。
首頁上沒有自相矛盾之處（兩個價格、兩個受眾、兩個不同的承諾）。
首頁不與 offer 簡報（若存在）相矛盾。

明確 → 繼續。Offer Statement 是基準；它會放在報告的頂部，以便使用者可以更正。

不明確 → 先停止並詢問使用者關於 offer 的資訊，然後再進行其他審計。絕不要猜測 offer 以通過此關卡。

如果可用，使用 AskUserQuestion 工具（每輪最多 4 個問題），選項應來自實際在網站上找到的候選項，並留出空間讓使用者提供自訂答案。否則在聊天中提問。
僅詢問遺漏或衝突的欄位，例如「首頁同時銷售 X 和 Y——哪個是主要 offer？」、「主要客戶是 A（英雄區）還是 B（服務區）？」、「簡報說 30 天保證，首頁說 14 天——哪個是目前的？」。對於多個 offer，確認其層級（主要 offer vs. 子 offer）。
將答案記錄在 Offer Statement 中，來源註明為「使用者確認」。然後，不明確或矛盾的首頁文字將成為發現事項——首頁將像其他頁面一樣，根據確認後的 offer 進行審計。

步驟 4 — 頁面與文字清單

列出訪客可以閱讀的所有內容（詳見 references/text-inventory.md）：

每個路由/頁面，包括動態路由和內容集合，
共享文字：頁首、導航、頁尾、橫幅、彈出視窗/模態框、表單（標籤、佔位符、驗證訊息、成功/錯誤訊息）、404/500 和空狀態，
訪客間接看到的文字：<title>、meta description、Open Graph/Twitter 標籤、JSON-LD 文字欄位、alt、aria-label、Web 應用程式清單的名稱/描述，
交易電子郵件和通知（如果其模板在儲存庫中）。

為每個頁面賦予其敘事角色（見 references/consistency-checklist.md）——該角色決定了該頁面的「一致」是什麼意思。

大型網站：完整審計每個核心頁面。對於大量同類型項目（例如超過 20 篇部落格文章或產品），審計共享模板加上每個項目的標題、描述、引言和 CTA；在報告中說明已涵蓋的範圍並提供完整通過的選項。如果 Agent 工具可用，您可以將清單分配給子代理——每個子代理獲得已確認的 Offer Statement、檢查清單及其頁面列表，然後將他們的發現合併到一個表格中。

步驟 5 — 審計

閱讀 references/consistency-checklist.md。根據 Offer Statement 檢查每個文字單元的所有維度（D1–D10），並考量其頁面角色。對於每個發現，記錄：位置、逐字引用、維度、嚴重性、問題原因（連結到特定的 Offer Statement 欄位）、修正類型以及提議的文字。

首先建立事實矩陣（每次提及價格、保證、截止日期、名額、交付時間、名稱——並列比較），以便系統性地捕捉頁面之間的矛盾，而不是偶然發現。
提議的文字遵循「僅限文字編輯規則」，且絕不虛構事實。缺失的事實應以網站語言顯示為佔位符（例如 [TO FILL IN: …]，波蘭語 [DO UZUPEŁNIENIA: …]）。
對於事實衝突且無法確定真相的情況 → 修正類型為 Decision：列出選項，不要自行選擇一個。
文字無法解決的問題（圖片顯示不同產品、缺少區塊或 CTA 按鈕、不該存在的頁面、錯誤的連結目標、URL slug）歸入「超出文字範圍」——僅報告，此技能不會修正。

步驟 6 — 審計報告，然後停止

完全按照「輸出格式」呈現報告。報告總是以發現表格結尾。 表格之後只能有核准問題。然後停止並等待——在此輪中不要修改任何檔案。

核准問題（如可用，使用 AskUserQuestion）：

全部套用
僅套用 Critical 和 Major
套用選定行（使用者列出 # 號並可編輯任何提案）
不套用——僅審計

每個使用者希望套用的 Decision 行都需要一個答案；盡可能在同一輪中詢問這些問題。

步驟 7 — 套用核准的修正

僅套用核准的行，包含使用者的編輯，並遵循「僅限文字編輯規則」。
在更改字串之前，檢查它還在哪裡渲染（共享 i18n 鍵、共享元件、重複使用的 Markdown 部分）。如果新文字不適合這些上下文之一，則停止並詢問。
如果核准的修正最終需要非文字更改，或無法按核准的方式套用，則跳過該修正並報告。不要即興發揮不同的修正。
儲存在外部 CMS 中的文字：不要嘗試編輯它；準備一個複製貼上列表（CMS 條目/欄位 | 當前文字 | 新文字）。

步驟 8 — 驗證並報告

重新閱讀每個更改的段落及其周圍的文字——它在上下文中必須讀起來自然。
在核准的範圍內搜尋舊版本的遺留內容（舊名稱、舊術語、舊承諾）。
驗證更改的檔案：JSON/YAML 解析正常，語言環境檔案保持相同的鍵，插值變數保持完整。如果專案有一個可用的快速 lint/typecheck/build，則執行它。
多語言：列出其他需要匹配更新的語言環境字串，除非使用者核准也更新它們。
以摘要表格結束：# | 位置 | 狀態（已套用 / 已跳過 — 原因 / 需要 CMS 更新） | 變更（簡短）。除非被要求，否則不要提交。

僅限文字編輯規則

允許：

使用者可見的字串內容：JSX/模板中的文字節點、渲染給使用者的字串字面量、i18n 值、Markdown/MDX 散文、frontmatter 文字欄位（title, description）、儲存庫內的 CMS/內容檔案，
文字屬性和元資料：alt、title、aria-label、placeholder、<title>、meta description、OG/Twitter 文字、JSON-LD 文字值、manifest 名稱/描述，
表單、系統和電子郵件模板訊息，
在現有文字元素內重寫、縮短或刪除句子。

不允許（改為在「超出文字範圍」下報告）：

新增、移除、重新排序或重新設計樣式、區塊或元件；更改標記、類別、CSS 或非文字屬性，
清空元素——空的元素是版面變更；應改為重寫，
i18n 鍵、變數名稱、檔案名稱、路由、URL slug、錨點（slug 是文字，但更改它們會破壞連結和 SEO），
連結目標（href）——只能更改連結文字，
圖片、圖示、影片和其他媒體，
程式碼邏輯、條件、資料擷取。

編輯時：

保留插值和語法：{name}、{{count}}、%s、:attribute、ICU plural/select、HTML 實體、字串內的內聯標籤（<strong>、<br>、<0>…</0>）、Markdown 格式以及轉義（JSX/JSON 中的引號，PHP 字串中的撇號）。
保持長度與原始文字相近（大約 ±30%），因為版面不會變更。如果修正需要更長的文字，請在提案中說明。
符合網站的排版慣例（引號、破折號、不換行空格）。

強制規則

R1. 唯讀審計。 在明確核准之前，不得進行編輯或寫入檔案（包括報告檔案，除非使用者要求）。核准僅涵蓋核准的行。
R2. 僅限文字。 任何超出「僅限文字編輯規則」的內容都將報告，不會更改。
R3. 先有基準。 絕不要基於猜測的 offer 進行審計：Offer Statement 必須來自首頁或經使用者確認。
R4. 證據。 每個發現必須逐字引用當前文字，並給出精確的位置（file:line 或 i18n 鍵）。
R5. 表格始終在最後。 每個審計報告都以發現表格結尾，即使沒有發現——則以覆蓋範圍表格結尾（頁面 | 角色 | 判定）。
R6. 不虛構事實。 提案絕不添加使用者未提供或網站尚未一致陳述的數字、結果、推薦、保證或條款。衝突 → Decision。遺漏 → 佔位符。
R7. 一致性，而非統一性。 不要將英雄區的承諾到處貼，也不要把銷售話術強加到每個頁面。僅標記那些與 offer 相矛盾、削弱、偏離或分散注意力的文字，並考慮頁面角色。法律頁面絕不為敘事而重寫——僅標記其與行銷文案的事實衝突，並建議由法律審查。
R8. 對齊 offer，而非重新設計它。 此技能將網站與確認後的 offer 對齊。如果 offer 本身薄弱（模糊的承諾、無證明、價格驅動），在摘要中用一句話說明，並建議使用 grand-slam-offer 技能；不要在此處重建 offer。
R9. 語言。 使用對話語言溝通；提議的網站文字使用其所取代文字的語言。

輸出格式

審計報告

按此順序撰寫，使用對話語言：

基準 offer — Offer Statement（緊湊表格）+ 其來源（首頁 / offer 簡報 / 使用者確認）。
範圍 — 審計的頁面和文字來源（計數 + 列表或分組）、語言環境、透過抽樣覆蓋的內容、位於儲存庫外且未審計的內容。
摘要 — 按嚴重性分類的發現計數；2–3 個最大的敘事問題，每個一句話；可選擇性地用一句話說明 offer 本身（R8）。
完整重寫（僅在需要時）——超過約 40 個字的提案，完整呈現，並標註發現編號。
超出文字範圍（僅當有相關內容時）——簡短列表；此技能不會修正它們。
發現表格 — 報告的最後一個元素。

發現表格 — 表頭翻譯成對話語言：

#	位置	嚴重性	現狀	為何不該如此	建議修正

# — 用於核准的穩定 ID。
位置 — 頁面 · 區塊 · file:line 或 i18n 鍵。
嚴重性 — Critical / Major / Minor（見檢查清單）。
現狀 — 相關片段的逐字引用；超過約 25 個字時用「…」縮短。
為何不該如此 — 與基準的具體衝突，例如「首頁：針對牙科診所；此處：針對任何行業」。
建議修正 — 以網站語言呈現的確切新文字、「見完整重寫 #N」、或 DECISION: A) … / B) …。

按嚴重性排序，然後按清單中的頁面順序排序。

例如，在波蘭語對話中，三個核心表頭變成「Jak jest dziś」、「Dlaczego tak nie powinno być」、「Jak to poprawię」。

範例行（英文網站，英文對話）：

#	位置	嚴重性	現狀	為何不該如此	建議修正

…（為翻譯截斷）

site-consistency — 要約對齊文案 QA