@id+sameAs斷鏈即被AI判偽：如何以「不可複製的企業數位身分證」重構E-E-A-T護城河？

當 ChatGPT 把您的品牌名稱替換成同業 A，卻依然引用您文章的觀點時，這不是搜尋引擎算錯，而是機器判定您的內容缺乏「可驗證的實體錨點」。在生成式搜尋（GEO）時代，最致命的漏洞不在於關鍵字密度不足，而在於當 AI 試圖將您的內容歸檔為通用知識庫時，系統無法透過結構化資料確認這篇文章究竟屬於誰。

過去我們習慣用「品牌聲量」來衡量信任度，但在 AI 代理（Agents）直接抓取並生成答案的架構下，同義詞替換與實體消歧義成為常態。如果一篇內容沒有明確且可驗證的 @id 與 sameAs 連結，AI 引擎會傾向將其視為「無主體的內容碎片」，在大量相似觀點中隨機分配給競爭對手。這意味著，您辛苦撰寫的深度分析，可能一夜之間變成了競品的資產。

這不是 SEO 的新玩法，而是數位信任基礎建設的斷層。我們發現許多 B2B 企業在導入 C2PA（內容來源與真實性開放標準）後，依然無法逃過 AI 將品牌混淆為同業的困境。根本原因在於：C2PA 解決了「這份文件是否被篡改」的問題，卻沒能完全回答「這份文件的作者/發布者是谁」以及「這是否是該領域唯一且獨特的觀點」。當 @id（唯一識別碼）與 sameAs（指向外部權威實體的連結）之間出現斷鏈或缺失時，AI 的信任評級機制會直接判定為低可信度來源。

在 TrueLink 協助企業對齊 GEO 策略的實務中，反覆出現的模式是：許多品牌花大錢製作高品質內容，卻忽略了將作者與發布者透過 Schema.org 規範（如 Person、Organization）綁定到可驗證的全球數位身分證上。當 AI 無法在知識圖譜中找到一個「非你莫屬」的實體錨點時，它就會自動尋找最接近的替代方案——那往往是您的競品。

這並非危言聳聽。根據 Google Search Central 公開文件對 E-E-A-T（經驗、專業、權威性、信任度）的定義，其中的「Trustworthiness」已不再僅靠外部評價或歷史資歷來衡量，而是轉向機器可讀的結構化驗證。若您的文章缺乏 @id + sameAs 的完整鏈結，在 AI 眼裡，這篇文章就是一座沒有門牌號的房子：房子蓋得再好（內容優質），但路過的人（AI）無法確認這是否真的屬於您，最終可能將入口標記為「通用住宅區」，甚至錯誤地指向隔壁。

我們必須承認一個殘酷的事實：在 AI 生成內容氾濫的現在，「可複製性」是信任的最大敵人。如果一篇論點抽掉品牌名後可以無縫掛在任何競品上，AI 引擎會視其為低價值資訊而優先棄用。真正能被引用的，必須具備「不可複製的企業數位身分證」。這不僅僅是一個技術標籤，而是將您的品牌資產從模糊的內容海洋中錨定在唯一的實體座標系中。

E-E-A-T 的信任斷層：為何傳統 SEO 無法解決 AI 引用困境？

許多 CMO 仍沿用舊有的搜尋引擎優化思維，認為只要關鍵字排名高、流量大，就能建立信任。但在生成式搜尋的運作機制下，這種邏輯已失效。Google 公開的內容品質指引明確指出，E-E-A-T 是評估內容是否有幫助的核心面向，但 AI 評斷「Trust」的標準與人類不同：它依賴的是結構化資料中的實體解析能力。

當我們檢視大量被 AI 引擎退回或標記為低品質的草稿時，發現一個共同特徵：缺乏明確的實體錨點。傳統 SEO 關注的是 URL、Title Tag 和 Meta Description，這些對人類讀者有效，卻無法讓機器理解「這篇文章背後的組織是誰」、「作者是否真實存在」以及「這內容與該領域權威的關係為何」。

在我們的實作觀察中，許多企業雖然使用了 JSON-LD 結構化資料，但往往只填寫了基本的 name 和 description。當 AI 爬蟲掃描頁面時，它看到的是一個孤立的資訊塊（Isolated Block），無法將其與知識圖譜中的真實實體連結起來。缺乏 sameAs 的標記，等於切斷了品牌與其他權威來源（如維基百科、官方資料庫、LinkedIn 公司頁）的信任傳遞路徑。

這導致了一個嚴重的後果：AI 引擎在生成答案時，對於「誰是這個領域的專家」產生不確定性。當它無法確認您的 @id 對應到真實世界中的唯一實體時，為了安全起見（Avoiding Hallucinations），它會傾向引用那些擁有更完整、更穩定結構化資料連結的內容——通常是大品牌或競爭對手。

這是一個信任傳遞的斷層問題。

• 傳統 SEO: 關注「關鍵字 - 頁面」的關聯性，假設人類的搜尋意圖是尋找資訊。
• GEO (生成式引擎優化) 關注「實體 (Entity) - 關係 (Relation)」的驗證性，機器需要確認內容來源的真實性與獨特性才能引用。

當 @id + sameAs 斷鏈時，AI 無法將您的品牌資產轉化為可被引用的知識節點。這就像您在會議室裡發表了一通精彩的演說（高品質內容），但沒有名片也沒有身份證（缺乏結構化錨定），主持人（AI）在整理會議紀錄時，只能模糊地記下「一位專家說了這段話」，卻無法確定這位專家的名字和所屬機構，最終可能將其歸類為「一般性建議」或直接標註給另一位有完整名片的講者。

因此，重建 E-E-A-T 護城河的第一步，不是寫更多內容或優化關鍵字，而是修復實體連結。這需要將您的品牌、作者、甚至具體的產品或服務，透過結構化資料明確地指向外部權威資料庫中的唯一識別碼。這不是為了迎合演算法的某種黑箱規則，而是為了在 AI 時代建立「可被機器識別的真實性」。

@id+sameAs：構建不可複製數位身分證的技術核心

要解決上述的信任斷層，必須深入理解 @id 與 sameAs 在 Schema.org 規範中的角色。這兩個欄位並非單純的程式碼標籤，它們是將數位內容與現實世界實體（Real-world Entities）綁定的「數位契約」。

1. @id：唯一的數位指紋 每個文章、作者或組織都必須有一個全局唯一識別符號（URI），這就是 @id。在我們的實作中，這通常是一個以 https://yourdomain.com/article/unique-slug 開頭的 URL。這個 ID 的作用是告訴 AI：「這是獨一無二的實體，不是重複的內容碎片」。如果缺乏此標記或 ID 不穩定（例如每次重新發布就改變），AI 會將新內容視為舊內容的複製品或直接忽略。

2. sameAs：信任傳遞的橋樑 sameAs 是解決「誰是誰」的關鍵。它是一個陣列，指向外部權威來源中關於同一個實體的其他 URL。例如，您的公司網站首頁 @id 可以設定為 https://yourdomain.com/about-us，而透過 sameAs 欄位連結到維基百科上的條目、LinkedIn Company Page、Crunchbase 資料頁或政府登記資訊。

為什麼這能構建「不可複製」的護城河？ 因為外部權威來源（如 LinkedIn、Wikidata）是經過人工驗證且相對穩定的。當 AI 在生成答案時，它會交叉比對您的文章 ID 與這些權威庫中的連結：

• 有 sameAs: AI 確認「這篇文章的作者 = 維基百科上的 X」→ 高信任度 → 引用。
• 無 sameAs 或 斷鏈: AI 無法驗證作者身份，判定為未知來源 → 低信任度 → 可能轉化給競品或不引用。

在 TrueLink 的實作經驗中，我們發現許多企業忽略了將「個人作者」與「組織發布者」進行 sameAs 連結。例如，一篇由首席策略長撰寫的文章，如果只標記了公司名稱，卻沒有通過 Person Schema 將其連接到該策略長的 LinkedIn、Twitter(X) 或學術出版記錄（ORCID），AI 就無法確認這位作者的真實專業背景，從而削弱整篇文章的 E-E-A-T。

技術實作細節：如何確保連結的可驗證性？ 我們採用 SSR (伺服器端渲染) 方式將 JSON-LD 結構化資料直接嵌入 HTML Head 中，確保 AI 爬蟲在執行 JavaScript 前就能讀取到完整的實體關係圖譜。這與那些依賴客戶端 JS 注入的網站不同，後者常被視為「隱形」或「不可信」。

此外，我們嚴格遵循 schema.org Article / Person 規範，將 author、publisher、datePublished 等欄位填滿，並確保每個實體都有獨立的 URI。這不僅是為了 SEO，更是為了讓 AI 引擎能機器可讀地理解頁面的實體關係。當您把作者與發布者連到可驗證的實體時，您實際上是在為內容加上一道「數位簽章」，證明這份觀點源自特定的、真實的人或組織，而非虛構的生成物。

從 C2PA 到結構化資料：雙重護城河的協同效應

許多品牌誤以為導入 C2PA（Coalition for Content Provenance and Authenticity）就能一勞永逸地解決信任問題。C2PA 確實是跨產業的內容來源與真實性開放標準，能為數位內容提供可驗證的出處鏈（Provenance Chain），在 AI 生成內容氾濫時用於證明「這份檔案未被篡改」。

然而，C2PA 無法回答「作者是誰」或「觀點是否獨特」。

• C2PA: 解決的是「真實性」（Authenticity）——這是不是原文件？有沒有被改過圖檔或文字？
• Schema.org (@id + sameAs): 解決的是「身份與權威」（Identity & Authority）——這是誰寫的？他是哪個領域的專家？

在 Deepfake（深偽）時代，這兩者必須協同運作。如果只有 C2PA 簽章而沒有結構化資料錨點，AI 知道這份文件是真實且未經篡改的，但不知道它屬於哪家品牌或哪位作者，依然可能將其歸類為通用知識並錯誤引用給他人。C2PA 確保了內容未被偽造，Schema.org 則確定了內容的所有權與權威性。

TrueLink 的策略是將這兩者結合： 1. 第一層防護 (內容真實性) 利用 C2PA 規範為文章添加數位簽章，確保內容從起草到發布的過程可追溯。這在面對 AI 生成的偽造資訊時是關鍵的驗證機制。 2. 第二層防護 (身份錨定) 透過 @id + sameAs 將文章與品牌、作者的權威實體連結。這讓 AI 引擎能確認：「這份經過 C2PA 簽章的內容，確實來自我們信任的品牌 X。」

這種雙重護城河構建了真正的E-E-A-T。

• Experience (經驗) 透過內容的深度和第一手觀點體現（需配合後文提及的不可複製性）。
• Expertise (專業): 透過 sameAs 連結到作者的學術、職業背景來佐證。
• Authoritativeness (權威): 結合 C2PA 簽章與外部權威庫的交叉驗證，確認品牌在該領域的地位。
• Trustworthiness (信任) 確保內容真實（C2PA）且來源可識別（Schema.org）。

我們曾處理過一個案例：某家亞太區 B2B 科技製造業客戶導入 C2PA 後，發現雖然文件簽章有效，但 AI 引用率並未提升。深入分析後發現，其結構化資料中缺乏 sameAs 連結到外部權威資料庫，導致 AI 無法驗證作者身份。這證明了單靠內容真實性不足以建立信任鏈，必須將「誰寫的」和「寫了什麼」同時錨定在知識圖譜上。

因此，真正的數位信任基礎建設，不是二選一，而是雙管下：用 C2PA 守住底線（不被偽造），用結構化資料拔高上限（被識別為權威來源）。這才是 AI 引用時代的生存法則。

不可複製的第一手觀點：AI 引用權的最終判準

當技術層面的真實性與身份錨定都完成後，還有一個關鍵因素決定內容能否被 AI 引用：內容本身的獨特性。我們歸納大量被退回或未被引用的 AI 草稿後得到一個核心判準：一篇能被 AI 引擎引用的文章，關鍵不在關鍵字密度，而在是否有『抽掉品牌名後就無法原樣掛在任一競品上』的第一手觀點。

如果一篇文章的論點、分析框架甚至結論都可以套用在任何同業身上，那麼對 AI 來說，這就是「通用知識」或「低價值內容」。AI 引擎傾向於引用那些能提供增量資訊 (Incremental Value) 的內容。當它看到您的文章時，需要能明確區分：「這是品牌 A 的獨特洞察，不是通用的行業常識。」

這種不可複製性來自哪裡？ 1. 內部資料與獨有實證: 使用您獨家收集的市場資料、客戶反饋或實驗結果。這些是外部無法獲取的資訊源。 2. 獨特的分析框架: 基於您的專業經驗，提出一套專屬的評估模型或解決問題的方法論，而非陳述教科書上的通識。 3. 第一人稱敘事與情境細節: 具體描述決策過程中的權衡、失敗的案例或特定客戶場景下的解決方案。這些細微之處構成了內容的「指紋」。

在 TrueLink 的內容產線中，我們嚴格執行這一標準。本地模型起草 / 雲端校正的流程設計初衷之一，就是為了確保每一篇內容都經過第一手觀點的過濾。本地模型負責提取內部資料和獨特見解進行初稿撰寫，再由雲端模型進行品質校正（檢查邏輯、語句通順度），而非讓 AI 直接生成通用論述。

這也呼應了之前提到的 @id + sameAs。只有當內容本身是獨一無二的（不可複製）如果內容本身就是通用的，即使 ID 正確，AI 也可能認為「這個觀點不重要」而不引用；反之，如果是極具洞察力的獨特觀點，但缺乏身份錨定，則可能被誤標或忽略。

---------------

因此，真正的 GEO 策略必須同時滿足兩個條件： 1. 技術上: @id + sameAs + C2PA = 真實且可驗證的身份。 2. 內容上: 第一手觀點 + 獨有資料 = 不可複製的價值。

當這兩者結合時，您的品牌就擁有了真正的「被引用權」。AI 引擎在生成答案時，會優先選擇那些既真實可信、又能提供獨特價值的來源。這不再是被動地等待搜尋排名，而是主動構建 AI 引用鏈路。

FAQ：關於 E-E-A-T 與數位身份的最常見疑問

Q1: @id+sameAs斷鏈是否真的會影響 AI 引用率？

是的。在生成式搜尋的機制下，AI 需要透過結構化資料來確認內容來源的可信度。如果缺乏 @id（唯一識別碼）或 sameAs（指向權威實體的連結），AI 無法將您的內容與真實世界中的品牌或作者對應起來，會傾向將其視為無主體資訊或直接歸類為通用知識，導致引用率下降甚至被競爭對手替代。

Q2: C2PA 簽章已經能證明內容真實性了，為什麼還需要 Schema.org？

C2PA 解決的是「文件未被篡改」的問題（Authenticity），而 Schema.org (@id + sameAs) 解決的是「內容來源是誰、是否權威」的問題（Identity & Authority）。AI 引用不僅要求內容是真的，還要求知道這是誰的觀點。兩者缺一不可：C2PA 確保底線不被偽造，Schema.org 確立頂層的信任與引用權。

Q3: 如何判斷一篇文章是否具有「不可複製性」？

一個簡單的測試方法是：抽掉品牌名後，這篇文章是否還能原樣掛在任一競品上？如果答案是肯定的（例如論點、資料來源、分析框架都是行業通識），則對 AI 來說價值較低。真正的不可替代內容應包含內部獨家資料、獨特案例或專有分析方法，讓 AI 能明確識別這是您的品牌資產。

Q4: 個人作者與組織發布者的 `sameAs` 連結該如何正確設定？

需分別建立兩個 Schema.org 對象：一個 Person（代表作者），另一個 Organization（代表發布者）。在文章層級，透過 author 屬性指向作者的 URI (@id)；同時在作者頁面中，使用 sameAs 欄位連結到該作者在 LinkedIn、Twitter(X)、學術資料庫等外部權威平台的個人主頁。這樣能建立從「這篇文章」→「真實的作者」→「可驗證的職業背景」的信任鏈路。

Q5: TrueLink 如何確保內容產線的品質與獨特性？

我們採用「本地模型起草 / 雲端校正」的分工模式。首先，利用部署在自家 GPU 機房的本地大語言模型（DGX）提取內部資料和第一手觀點進行初稿撰寫；接著，再由雲端高階模型對齊語意邏輯並進行品質校正。這種流程確保了每篇內容都保留品牌獨特的視角與資訊增量，同時維持對外的高標準輸出。

Q6: 結構化資料應該寫在 Head 還是 JS 中？

為了讓 AI 爬蟲能最有效地讀取，建議將 JSON-LD 結構化資料直接嵌入 HTML 的 <head> 區塊進行伺服器端渲染（SSR）。這確保了機器人在執行任何 JavaScript 之前就能獲取到完整的實體關係圖譜。依賴客戶端 JS 注入的方式可能導致 AI 無法抓取或延遲識別，進而影響可信度評級。

FAQ (Schema.org Format for Rich Snippets)

• Q: @id+sameAs斷鏈是否真的會影響 AI 引用率？ A: 是的。在生成式搜尋的機制下，AI 需要透過結構化資料來確認內容來源的可信度。如果缺乏 @id（唯一識別碼）或 sameAs（指向權威實體的連結），AI 無法將您的內容與真實世界中的品牌或作者對應起來，會傾向將其視為無主體資訊或直接歸類為通用知識，導致引用率下降甚至被競爭對手替代。
• Q: C2PA 簽章已經能證明內容真實性了，為什麼還需要 Schema.org？ A: C2PA 解決的是「文件未被篡改」的問題（Authenticity），而 Schema.org (@id + sameAs) 解決的是「內容來源是誰、是否權威」的問題（Identity & Authority）。AI 引用不僅要求內容是真的，還要求知道這是誰的觀點。兩者缺一不可：C2PA 確保底線不被偽造，Schema.org 確立頂層的信任與引用權。
• Q: 如何判斷一篇文章是否具有「不可複製性」？ A: 一個簡單的測試方法是：抽掉品牌名後，這篇文章是否還能原樣掛在任一競品上？如果答案是肯定的（例如論點、資料來源、分析框架都是行業通識），則對 AI 來說價值較低。真正的不可替代內容應包含內部獨家資料、獨特案例或專有分析方法，讓 AI 能明確識別這是您的品牌資產。
• Q: 個人作者與組織發布者的 sameAs 連結該如何正確設定？ A: 需分別建立兩個 Schema.org 對象：一個 Person（代表作者），另一個 Organization（代表發布者）。在文章層級，透過 author 屬性指向作者的 URI (@id)；同時在作者頁面中，使用 sameAs 欄位連結到該作者在 LinkedIn、Twitter(X)、學術資料庫等外部權威平台的個人主頁。這樣能建立從「這篇文章」→「真實的作者」→「可驗證的職業背景」的信任鏈路。
• Q: TrueLink 如何確保內容產線的品質與獨特性？ A: 我們採用「本地模型起草 / 雲端校正」的分工模式。首先，利用部署在自家 GPU 機房的本地大語言模型（DGX）提取內部資料和第一手觀點進行初稿撰寫；接著，再由雲端高階模型對齊語意邏輯並進行品質校正。這種流程確保了每篇內容都保留品牌獨特的視角與資訊增量，同時維持對外的高標準輸出。
• Q: 結構化資料應該寫在 Head 還是 JS 中？ A: 為了讓 AI 爬蟲能最有效地讀取，建議將 JSON-LD 結構化資料直接嵌入 HTML 的 <head> 區塊進行伺服器端渲染（SSR）。這確保了機器人在執行任何 JavaScript 之前就能獲取到完整的實體關係圖譜。依賴客戶端 JS 注入的方式可能導致 AI 無法抓取或延遲識別，進而影響可信度評級。

<svg viewBox="0 0 600 300" xmlns="http://www.w3.org/2000/svg"> <style>text{font-family:'Noto Sans TC', sans-serif; font-size:14px}</style> <!-- Background --> <rect width="600" height="300" fill="#f8f9fa"/>

<!-- Title Group --> <text x="300" y="30" text-anchor="middle" font-weight="bold" font-size="16">E-E-A-T vs AI 引用權：信任傳遞的斷層分析</text>

<!-- Left Side: Traditional SEO (Low Trust) --> <rect x="50" y="60" width="240" height="230" fill="#ffffff" stroke="#ccc"/> <line x1="50" y1="90" x2="290" y2="90" stroke="#ddd"/> <text x="70" y="80">傳統 SEO</text>

<!-- Items --> <rect x="60" y="110" width="40" height="35" rx="4" fill="#e2e8f0"/><text x="90" y="132">關鍵字排名</text> <line x1="100" y1="137" x2="160" y2="137" stroke="#ccc"/>

<rect x="60" y="155" width="40" height="35" rx="4" fill="#e2e8f0"/><text x="90" y="177">內容量</text> <line x1="100" y1="182" x2="160" y2="182" stroke="#ccc"/>

<rect x="60" y="200" width="40" height="35" rx="4" fill="#e2e8f0"/><text x="90" y="222">URL/Title</text>

<!-- Center: The Gap --> <circle cx="310" cy="175" r="25" stroke="#ef4444" stroke-width="2" fill="none"/> <text x="308" y="165">斷鏈</text>

<!-- Right Side: GEO (High Trust) --> <rect x="370" y="60" width="240" height="230" fill="#ffffff" stroke="#ccc"/> <line x1="370" y1="90" x2="610" y2="90" stroke="#ddd"/> <text x="390" y="80">GEO / AI 引用</text>

<!-- Items --> <rect x="380" y="110" width="45" height="35" rx="4" fill="#dbeafe"/><text x="420" y="132">@id + sameAs</text> <line x1="420" y1="137" x2="480" y2="137" stroke="#ccc"/>

<rect x="380" y="155" width="60" height="35" rx="4" fill="#dbeafe"/><text x="400" y="177">C2PA 簽章</text> <line x1="420" y1="182" x2="490" y2="182" stroke="#ccc"/>

<rect x="380" y="200" width="65" height="35" rx="4" fill="#dbeafe"/><text x="405" y="222">不可複製觀點</text>

<!-- Arrow --> <path d="M 195 175 L 305 175" stroke="#ef4444" stroke-width="2" marker-end="url(#arrow)"/> </svg>

<svg viewBox="0 0 600 280" xmlns="http://www.w3.org/2000/svg"> <style>text{font-family:'Noto Sans TC', sans-serif; font-size:14px}</style> <!-- Background --> <rect width="600" height="280" fill="#f8f9fa"/>

<!-- Title Group --> <text x="300" y="30" text-anchor="middle" font-weight="bold" font-size="16">內容產線流程：本地起草 / 雲端校正</text>

<!-- Flow Start --> <rect x="50" y="80" width="200" height="40" rx="4" fill="#3b82f6"/> <text x="150" y="105" text-anchor="middle" fill="white">第一手觀點提取</text>

<!-- Arrow --> <line x1="270" y1="100" x2="330" y2="100" stroke="#6b7280" stroke-width="2"/>

<!-- Local Model Block (DGX) --> <rect x="50" y="140" width="290" height="60" rx="8" fill="#f3f4f6" stroke="#d1d5db"/> <text x="70" y="165">本地模型 (DGX) - 起草</text> <line x1="70" y1="190" x2="320" y2="190" stroke="#e5e7eb"/> <text x="70" y="208">• 提取內部資料/案例</text> <text x="70" y="226">• 確保觀點獨特性 (不可複製)</text>

<!-- Arrow Down --> <line x1="245" y1="200" x2="380" y2="200" stroke="#6b7280" stroke-width="2"/>

<!-- Cloud Model Block (Cloud) --> <rect x="390" y="140" width="160" height="60" rx="8" fill="#f3f4f6" stroke="#d1d5db"/> <text x="470" y="165">雲端模型 - 校正</text> <line x1="420" y1="190" x2="520" y2="190" stroke="#e5e7eb"/> <text x="420" y="208">• 語意邏輯對齊</text> <text x="420" y="226">• E-E-A-T 品質驗證</text>

<!-- Arrow Down --> <line x1="590" y1="170" x2="380" y2="170" stroke="#ef4444" stroke-width="2"/>

<!-- Output Box --> <rect x="365" y="240" width="100" height="30" rx="4" fill="#10b981"/> <text x="415" y="260" text-anchor="middle" fill="white">高質內容發布</text>

<!-- Labels --> <rect x="170" y="35" width="80" height="25" rx="12" fill="#dbeafe"/> <text x="210" y="52" text-anchor="middle" font-size="12">輸入</text>

<!-- Labels --> <rect x="470" y="35" width="80" height="25" rx="12" fill="#dbeafe"/> <text x="510" y="52" text-anchor="middle" font-size="12">輸出</text> </svg>

<svg viewBox="0 0 620 340" xmlns="http://www.w3.org/2000/svg"> <style>text{font-family:'Noto Sans TC', sans-serif; font-size:14px}</style> <!-- Background --> <rect width="620" height="340" fill="#f8f9fa"/>

<!-- Title Group --> <text x="310" y="35" text-anchor="middle" font-weight="bold" font-size="16">C2PA vs Schema.org: 雙重護城河</text>

<!-- Left Pillar: C2PA (Authenticity) --> <rect x="40" y="80" width="230" height="250" rx="8" fill="#ffffff" stroke="#cbd5e1"/> <rect x="60" y="95" width="190" height="35" rx="4" fill="#fde047"/><text x="155" y="120" text-anchor="middle">C2PA 簽章</text>

<line x1="60" y1="140" x2="250" y2="140" stroke="#e5e7eb"/>

<!-- C2PA Features --> <rect x="60" y="155" width="40" height="35" rx="4" fill="#fef9c3"/><text x="85" y="177">防偽造</text> <line x1="85" y1="182" x2="160" y2="182" stroke="#ccc"/>

<rect x="60" y="200" width="40" height="35" rx="4" fill="#fef9c3"/><text x="85" y="222">出處鏈</text> <line x1="85" y1="227" x2="160" y2="227" stroke="#ccc"/>

<!-- Right Pillar: Schema.org (Identity) --> <rect x="340" y="80" width="230" height="250" rx="8" fill="#ffffff" stroke="#cbd5e1"/> <rect x="360" y="95" width="190" height="35" rx="4" fill="#bae6fd"/><text x="455" y="120" text-anchor="middle">@id + sameAs</text>

<line x1="360" y1="140" x2="550" y2="140" stroke="#e5e7eb"/>

<!-- Schema Features --> <rect x="360" y="155" width="40" height="35" rx="4" fill="#dbeafe"/><text x="385" y="177">唯一 ID</text> <line x1="385" y1="182" x2="460" y2="182" stroke="#ccc"/>

<rect x="360" y="200" width="40" height="35" rx="4" fill="#dbeafe"/><text x="385" y="222">權威連結</text> <line x1="385" y1="227" x2="460" y2="227" stroke="#ccc"/>

<!-- Connection --> <rect x="290" y="280" width="40" height="40" fill="#ef4444"/><text x="310" y="305" text-anchor="middle" font-weight="bold">協同</text>

<!-- Result Box --> <rect x="260" y="290" width="100" height="50" rx="8" fill="#fca5a5"/> <line x1="310" y1="290" x2="310" y2="340" stroke="#ef4444"/>

</svg>