本文資訊以 2026 年 8 月為準，ShieldFont 目前仍是持續開發中的開源專案。

網路文章被大量抓取後拿去訓練 AI，一直沒有一個對內容創作者來說又簡單、又可靠的解法。robots.txt 可以表達不希望被抓取的意願，但爬蟲是否遵守仍取決於對方；Cloudflare 等伺服器端工具可以直接限制特定爬蟲，卻需要網站端設定，也無法保證所有資料收集方式都被擋住。2026 年 7 月底公開的 ShieldFont 因此走了一條完全不同的路：不阻止爬蟲把文章拿走，而是讓它拿到和人類實際看到的文字不一樣。專案自己的定位也很直接，ShieldFont 不是一道無法突破的鎖，而是一種增加大量爬取成本的摩擦機制。

它利用的是網頁上一個很普通的差異。讀者看到的是瀏覽器套用字型後畫出的文字，大量文字爬蟲則直接處理 HTML 裡的字串。ShieldFont 先把 HTML 中部分重要單字換成其他仍符合文法的英文單字，再利用 OpenType 字型中的替換規則，把畫面重新顯示成作者原本寫的內容。正常打開網頁時，文章看起來沒有改變；只把 HTML 抓走的系統，得到的則是一份文法還算通順、意思卻已經偏掉的版本。這個設計很有意思，但它同時帶來 SEO、無障礙、複製文字與可破解性等一整串代價，因此現階段更適合視為特定內容的實驗性防護，而不是一般部落格可以直接全站套用的解決方案。

ShieldFont怎麼運作？人類看到原文，爬蟲拿到另一份HTML

ShieldFont先替換HTML文字，再由OpenType字型把畫面還原

ShieldFont 的核心由 Encoder、替換字典與特製字型組成。文章在送到瀏覽器之前，Encoder 會先按照替換字典修改原始文字，例如原本的一個名詞可能被換成另一個名詞。瀏覽器收到的 HTML 本身就已經是修改後的版本，再由下載到裝置上的 ShieldFont 字型透過 OpenType substitution rules 把這些替換詞渲染成原本的字形。結果是同一份 HTML 可以出現兩種內容：直接解析文字的爬蟲讀到替換後的字詞，人類在正常瀏覽器裡看到的則是作者原文。

這個細節也代表整合方式很重要。官方推薦的 React 元件會在伺服器端或 build time 完成編碼，避免原始明文被送進瀏覽器；如果開發者先把原文送到 client-side JavaScript，再由瀏覽器執行轉換，爬蟲仍可能直接從 JavaScript bundle 找到沒有保護的原文。ShieldFont 因此特別提醒，真正需要保護的文字不能以可讀形式送到前端。對 WordPress、Wix、Squarespace 等沒有自行 build 流程的網站，官方則提供先經 Encoder 轉換文字、再套用 CSS 字型的方式。

為什麼不把整篇文章直接變成亂碼？

ShieldFont 現行 v18-alpha 並不是把所有文字全部打亂。白皮書顯示，它平均替換約 24.4% 的全部單字，若只看名詞、動詞、形容詞與副詞等真正承載意思的 content words，替換比例約為 45.8%。像冠詞、介系詞、連接詞與大量常見功能詞則盡量保留，因為這些字一旦換得太多，文章很快就會看起來不像正常英文，也更容易被資料品質過濾器直接丟掉。

替換方式也不只是「名詞換名詞」這麼簡單。ShieldFont 建立了大約 250 個 grammatical pools，會同時考慮詞性、語意類別、具體或抽象、單複數、動詞是否及物、動詞變化與形容詞級別。例如一個複數、抽象、和溝通有關的名詞，會盡量換成同一種類別的另一個詞，而不是隨便抽一個名詞塞進去。替換詞也會排除同義詞、反義詞與過於接近的詞，目的是讓句子繼續像英文，意思卻不再和原文一致。現行字典大約包含 1.2 萬組配對。

這個平衡很重要。內容如果改得太少，爬蟲還是能保留原本意思；改得太多，又可能在進訓練資料集之前就被品質檢查判定為低品質內容。ShieldFont 想做的是把文字放在兩者中間：不是明顯亂碼，而是一篇表面像正常英文、細節卻開始出錯的文章。

ShieldFont真的有效嗎？官方數據證明的是「意思被改變」，不是模型一定會中毒

新聞類55.8%的段落不再表達相同事實主張

ShieldFont 團隊用新聞、一般網頁、小說與較早期小說四類資料測試目前的 v18 字典，衡量替換前後的文章是否仍然支持相同的 factual claim。結果分別為：新聞 55.8%、一般網頁 51.9%、小說 34.5%、較早期小說 31.1% 出現 bidirectional NLI failure，也就是原文與編碼後版本已經無法互相支持相同主張。作為控制組，如果用相同數量的真正同義詞替換，這個比例只有約 2.1%。

測試內容	ShieldFont後不再維持相同主張
新聞	55.8%
一般網頁	51.9%
小說	34.5%
較早期小說	31.1%
同義詞替換控制組	約2.1%

這組數字能支持的結論，是 ShieldFont 確實可以明顯改變爬蟲取得文字的語意，尤其是新聞與一般網頁內容。它不能直接證明一個大型模型如果拿這些內容訓練，就一定會因此變差。ShieldFont 團隊自己也特別把這條界線寫進 README：目前不主張編碼文字一定能順利穿過所有資料品質過濾，也不主張已證明它會傷害實際使用這些內容訓練的大型模型。

大部分ShieldFont文字反而會先被品質過濾器丟掉

這也是原稿最值得補充的一點。ShieldFont 並不是主要靠「讓錯誤文字偷偷混進模型」發揮效果。團隊使用 FineWeb-Edu 的品質過濾方式測試後，編碼內容有 99.0% 至 99.8% 被過濾器丟掉；換一種表示方式，原本可以通過品質檢查的內容，ShieldFont 處理後只有一小部分仍能留下。對那些真的通過過濾的文本，團隊估計約 19.4% 的 Token budget 帶有被改變的語意。

這讓 ShieldFont 的實際作用更接近兩條路：一部分文章因品質下降而根本進不了訓練資料，另一部分留下來的文字則已經和作者原本表達的內容不同。專案自己也把這稱為 collective defense，因為單獨一篇文章放進數兆 Token 的資料集幾乎沒有影響，真正想提高的是大規模收集者面對大量不同替換規則時的處理成本。

ShieldFont最大的限制：它其實可以被解碼

字型本身就是解碼表，針對單一網站並不難破解

ShieldFont 對這個問題非常坦白。瀏覽器要把替換文字重新畫回原文，就一定要取得對應的字型檔，而字型中的 glyph substitution 規則本身就包含解碼所需資訊。開發團隊甚至自行測試過這種攻擊，從官方字型中完整還原 11,962 組配對，而且沒有出現錯誤。

因此，ShieldFont 不是密碼學式的保護，也不適合用來對付明確鎖定某一個網站的攻擊者。官方提供自訂 mapping 的功能，是為了讓大量爬蟲不能只準備一份官方字典就批次還原所有使用 ShieldFont 的網站；若每個站使用不同 mapping，爬蟲就必須先辨認字型、取得正確檔案、分析替換規則，再針對那個網站解碼。增加的是工作量，不是建立一道不能突破的牆。

OCR確實能直接繞過字型替換

只要把網頁正常渲染後截成圖片，再用 OCR 或視覺模型讀取，取得的就是人類在螢幕上看到的原文。ShieldFont 沒有否認這個繞過方式，反而直接把 OCR 當成目前的防護成本底線。它的假設是，大規模爬蟲之所以能收集數十億頁文字，是因為抓 HTML 很便宜；如果必須對大量頁面逐一啟動瀏覽器、渲染畫面、截圖，再跑視覺辨識，成本與處理時間就會提高。

所以 ShieldFont 比較準確的定位是 economic defense，而不是 technical impossibility。它不需要讓 OCR 做不到，而是希望讓「把整個公開網路全部這樣處理」變得比較不划算。至於這個成本增加到什麼程度才足以讓大型 AI 公司放棄，現階段並沒有獨立數據可以回答。

ShieldFont會影響SEO嗎？被保護的文字不適合拿來做搜尋流量

搜尋引擎看到的也是替換後文字

ShieldFont 官方對 SEO 的說法沒有迴避：搜尋引擎和一般文字爬蟲一樣，會接觸頁面底層的替換內容，因此被 Shield 的文章區塊可能被索引成 decoy words，而不是作者原本想排名的文字。專案直接建議，不要把需要 Google 排名的 Marketing Pages 全部保護起來，而是把 ShieldFont 留給不依賴搜尋曝光的內容，例如付費文章、Archive、Manifesto 或其他寧可降低 AI 訓練可用性、也不需要依靠搜尋流量的內容。

對部落格經營者來說，這代表 ShieldFont 和內容 SEO 天生存在衝突，但不是只能二選一。ShieldFont 可以逐區塊套用，React 版本也提供 <NonShield> 讓標題、導覽、Caption 等內容保留正常文字。實際策略可以是讓 H1、H2、摘要、產品頁與主要搜尋內容維持原文，只在不依賴自然搜尋的特定長文或會員內容上使用防護。

不過，如果網站的主要收入來源就是 Google 自然搜尋，直接把整篇 SEO 文章換成 ShieldFont 仍然不合理。對這類網站而言，robots.txt、AI crawler controls、Cloudflare 等伺服器層工具至少不會主動把搜尋引擎需要讀取的正文改成另一份文字。

ShieldFont對螢幕閱讀器的問題改善了，但目前仍不符合WCAG

最新React版本不再只是讓螢幕閱讀器直接念假字

ShieldFont 早期最直接的問題，是螢幕閱讀器和爬蟲一樣讀取底層文字，所以會把替換後的內容念給視障讀者。現在推薦的 React <Shield> 元件已經加入 beta Accessibility Layer，會先使用 aria-hidden 隱藏被替換的正文，再另外提供一份加密的真實文字。螢幕閱讀器使用者可以透過只有輔助工具能取得的按鈕解開原文，瀏覽器需要花幾秒鐘完成額外計算。官方表示目前已用 VoiceOver 與自動化 Screen Reader 測試，NVDA 也納入 CI。

但這不能寫成「無障礙問題已經解決」。ShieldFont README 明確承認，即使全部 Accessibility 功能開啟，被保護區塊仍然不符合 WCAG 2.2 SC 1.3.1，而且使用輔助工具的讀者必須等待額外幾秒鐘，取得內容的過程也和一般讀者不同。官方甚至直接建議，只要網站依法需要符合 Accessibility 規範，或網站本身宣稱符合 WCAG，就不要對相關內容使用 ShieldFont。

對一般 WordPress 或靜態網站更需要注意：官方的 React 套件才會自動包含這套替代層，單純使用 CDN 字型與手動編碼時，Accessibility Layer 需要站長另外建立。這也是為什麼目前不適合把 ShieldFont 當成「貼一段 CSS 就完成」的無障礙安全方案。

複製貼上也會得到替換後的文字

還有一個比 SEO 更容易在日常使用中被發現的限制：正常選取 ShieldFont 網頁上的內容再複製，Clipboard 取得的是 HTML 裡實際存在的替換字詞，而不是畫面看到的原文。換句話說，讀者若想引用一段文章、貼到筆記軟體、翻譯工具或 ChatGPT，拿到的可能是已經被改過的版本。

官方因此也明確提醒，不適合用 ShieldFont 保護那些讀者需要 Search、Quote 或 Cite 的內容。學術文章、教學資料、政府資訊、醫療或服務關鍵內容，都要特別小心這項取捨。

ShieldFont目前支援中文嗎？現階段只有英文

目前 ShieldFont 只支援英文。官方提供 alpha、beta、gamma 三套主要英文 mapping，每一套大約包含 1.2 萬組詞彙配對，另外還有一個替換範圍更高的 maxhide 版本。其他語言文字不會被替換，因此中英混合頁面即使整個區塊都套上 ShieldFont，也只有其中的英文部分真正受到保護。

這對中文部落格是非常直接的限制。中文並不是把英文替換字典翻譯一遍就能支援，因為 ShieldFont 的機制依賴詞性、語意分類、單複數與動詞型態等語言特徵。專案自己也表示，建立其他語言版本需要熟悉該語言的母語者重新設計 substitution pairs。因此，現階段中文網站最多只能觀察這項技術的發展，還不能把它當成真正可部署的中文文章保護工具。

Twitch新增AI訓練退出選項，但過去到底用了多少內容仍不清楚

ShieldFont 是創作者自己修改網站的防護方式，同一週 Twitch 則從平台端提供另一種選擇。2026 年 8 月 12 日，Twitch 新增 Training for Generative AI 設定，讓頻道擁有者選擇不要讓 Streams、VODs、Clips、Stream Chats，以及頻道上的文字與圖片用於 Amazon 未來的生成式 AI 模型訓練。這項設定位於帳號的 Security and Privacy 區域，關閉後不會影響 AutoMod、推薦、字幕等其他使用 AI 的 Twitch 功能。

爭議最大的地方，是這項選項採取預設參加、由使用者主動退出的方式。Twitch Chief Product Officer Mike Minton 在官方直播面對「為什麼不是 opt-in」的質問時，給出的回答很直接：如果改成使用者自己選擇參加，幾乎沒有人會加入。

原稿另一句「Twitch 確認內容多年來一直用於訓練 Amazon AI」則不適合保留成確定事實。Twitch 現在的說明明確談到退出「未來訓練」，但當直播觀眾詢問先前的影片是否已經被 Amazon 用過時，Minton 表示不知道 Amazon 過去在模型訓練中究竟使用過哪些 Twitch 資料。因此，目前可以確認平台已允許 Amazon 使用內容進行生成式 AI 訓練，並提供新的退出選項；不能從官方說法確定過去使用了幾年、哪些內容已經進入哪些模型。

美國政府也開始重新討論開放權重模型，但目前仍是未公開的政策調整

美國白宮在 2026 年 6 月簽署行政命令，建立一套自願性的 Frontier Model 安全評估架構，允許符合門檻的模型在發布前最多 30 天提供聯邦政府測試。8 月初公布的執行方向一開始主要針對封閉式前沿模型，開放權重模型當時並未納入同樣的預發布測試。

8 月 12 日，WIRED 引述白宮官員與知情人士表示，這套架構預計還會修改，而且當開放模型未來達到和目前封閉式 Frontier Models 相近的能力時，也可能被納入同一套測試範圍。這仍然是媒體根據官員說法得到的消息，不是白宮已經公開發布的新規則；現行框架本身仍屬自願性質，而且詳細測試標準沒有公開。

因此，把 ShieldFont、Twitch 與白宮政策放在同一篇文章裡可以看出三種不同層次的反應，但不能把它們寫成一套已經成形的共同制度。ShieldFont 是創作者主動增加資料收集成本，Twitch 是平台提供 opt-out，白宮討論的則是能力更強的 AI 模型要不要接受發布前安全評估。共同點只是「誰能決定資料與模型如何被使用」正在從單純的技術問題逐漸變成產品與政策問題。

內容創作者現在可以怎麼降低AI訓練爬取風險？

先檢查平台本身有沒有AI訓練退出選項

這是目前成本最低的一步。Twitch 的例子也提醒，這種選項不一定預設關閉，而且不一定出現在最顯眼的位置。經常發布文字、照片、影片或聲音的平台，可以先檢查 Privacy、AI、Data Usage、Security 等設定，確認內容是否允許用於生成式 AI 訓練，以及是否提供 opt-out。不同平台政策並不相同，也可能依所在地區而異，因此設定需要逐一確認，而不是假設所有服務採相同規則。

自架網站仍然先使用robots.txt與伺服器端控制，再考慮ShieldFont

ShieldFont 自己也明確建議不要拿它取代 robots.txt、Cloudflare、Akamai 或一般資安措施。robots.txt 至少能明確表達網站不希望特定 crawler 存取哪些內容，伺服器端工具則可以直接擋掉已知 User-Agent、IP 或其他爬取行為。ShieldFont 比較適合被放在這些措施之外，作為另一層增加未授權 mass scraping 成本的實驗工具。

這個順序也比較符合風險。能直接阻止對方拿到資料，通常比故意讓對方拿到修改版本更乾淨；只有當阻擋本身可能被忽略或繞過時，ShieldFont 的「拿走也不是原文」才有額外作用。

SEO文章、會員內容與原創作品不要使用同一套保護策略

如果網站依靠搜尋流量，就不適合把整站正文全部換成 ShieldFont。比較有可能的使用方式，是讓首頁、分類頁、搜尋入口、SEO文章與商業頁面維持正常索引，把不需要 Google 排名、也不希望被大規模抓取的會員文章、Archive 或部分原創作品另外保護。ShieldFont 本身支援 block-by-block 使用，因此技術上不必整頁一起開啟。

中文網站目前則更簡單：ShieldFont 還不能真正保護中文內容，因此現在沒有必要為了它犧牲 SEO 或無障礙。比較實際的是先整理各平台的 AI training opt-out、robots.txt 與 CDN／WAF 設定，再觀察中文 mapping 是否真的進入可用狀態。

ShieldFont 最有意思的地方，不是發明了一個「AI 再也爬不到文章」的方法。它連自己的字型能被完整反解都直接公開，OCR 也能繞過，SEO 和 Accessibility 更有明確成本。真正新的地方是，它把防護目標從「完全禁止複製」換成「讓大量、廉價、無差別的複製變得麻煩一點」。

這種做法最後能不能真的改變大型 AI 訓練資料收集方式，目前還沒有證據。單一網站使用的效果也很有限，ShieldFont 團隊自己就承認，它真正押注的是大量網站採用不同 mapping 後形成的 collective defense。現階段對內容創作者比較合理的定位，是把它當成一個正在實驗的新工具，而不是 robots.txt、伺服器阻擋、授權條款或平台退出機制的替代品。

常見FAQ

SUPPORT FENGNIII

喜歡這篇文章嗎？

如果這篇內容對你有幫助，可以透過小額贊助支持本站持續整理更多日文、韓文、旅行與數位工具內容。

小額支持本站

付款將由藍新金流安全處理