方法論——引用任何數字之前請先讀
1. 這是什麼站
在台灣，大家最怕的往往不是「被偷」，而是「被看見」——LINE 群組裡一張隨手傳的照片、巷口的一句閒話，都可能在你不知道的時候傳開。智慧眼鏡把這種怕帶到了臉上：一副眼鏡就可能在記錄，而你我都不知道它記了什麼、記給了誰。所以這個站不做評測、不做推薦，只做一件事：記帳。像老式帳房先生那樣，把每款眼鏡「收什麼、預設開什麼、資料去哪、能不能刪」一筆一筆寫清楚，筆筆有據；把每篇報導的說法原樣記下來，不添油加醋。發售追蹤在姊妹站 aiglassesdata.com，真實使用體驗在 UX Ledger（uxledger.com），本站只連結、不重抄。
2. 來源
廠商產品頁與發布公告（Meta、Snap、三星/Google）、監管機構報告（漢堡 HmbBfDI、EDPB）與發售報導。每張卡、每個事件、每行規格都帶來源連結。凡是依據二手報導而非廠商原頁的，備註裡會寫明。
3. 「未公布」是一個真實的值
廠商沒公布、或未對照可引來源核實的數字，格子裡就寫「未公布」。本站沒有任何數字是估算、內插或從同類產品借來的。平均值只對非空值計算，空值個數一併標出。
4. 隱私熱力圖規則
編碼由卡片文字按關鍵詞規則導出——「未公布」→0；「預設開啟」→3；「無持續錄製」→1；有 LED/提示燈→2；「未經獨立核實」→1；「裝置端處理」→1；「Meta 伺服器」→2。完整卡片文字就印在圖下方，任何編碼都能對回原句。把圖當地圖讀，別當評分：紅色格子意思是「預設開著——去看卡片」，不是「產品差」。
5. 搜尋熱度
Google Trends 指數（0–100），不是搜尋次數。24 小時均值是單日快照、雜訊大；週均值才是穩定的讀數。來源是 2026 年 11 月 5 日的兩張截圖（加拿大與全球）。
6. 文章與分析
報導來自 Hacker News、Bing News、技術部落格、YouTube 與 Reddit（經 Bing News）。Google News RSS 從 Worker 出口回傳 503，所以新聞漏斗走 Bing News；Reddit 直連 RSS 同樣回傳 403。每篇文章由 Workers AI（Llama 3.1 8B，@cf/meta/llama-3.1-8b-instruct-fp8）分析一次：1–3 段摘要加結構化欄位。分析依據是標題、摘要與能取回的內文片段；取不到全文的標為「snippet」。無法確定的欄位一律為空——絕不編造。文章只有標題點名了在帳型號才入庫（標題門：先 Display，再 Ray-Ban、Oakley、Galaxy Glasses、Specs）。標題門並不完美：已知一例誤錄是 9to5Google 一篇關於 Motorola Signature 27 手機的文章被歸入 snap-specs，它的電池數字已從 Snap 續航行排除並附註，原文仍留在帳裡備查。
7. 評分規則——這些指數是什麼、不是什麼
台灣人買東西常問一句「有人用過嗎？」——但「有人說好」跟「東西好」是兩回事，就像夜市口碑跟攤子本身的功夫，隔著一整條街。本站的情感指數（0–100）、推薦指數（0–100）與作者結論（buy / wait / skip / mixed，附作者原話），量的正是那條街這邊：這篇文章寫得多正面、作者本人多想推薦、作者自己下了什麼結論。它們量的是文章與作者的立場，不是產品本身，更不是本站對產品的評分。本站從不給產品打分：站內沒有本站評分、沒有排名、沒有「最佳」之選。這就是界線：描述報導的指數量保留並公開方法；任何會呈現為本站對產品判斷的數字，一律不發。站內出現的排名一律是來源自家的（例如 Google Trends 指數），頁面上會寫明。
8. 三本帳
三本帳都直接由逐篇分析生成——不是來自 experience_records（本站為 0 行；真實體驗在 UX Ledger）。
- 宣稱對實測（/api/ledger/claims）：每條帶 measured_value 的 key_claim，連同來源文章列出。measured_value 是文章裡寫明的數字，不是獨立實驗室測量。標「tested」的行來自上手/使用者文章或寫明使用時長的文章；其餘行複述的是廠商或發布數字。/metrics/battery/ 把規格表的廠商宣稱與這些文章數字並排對照。
- 分數（/api/ledger/scores）：情感與推薦指數分布（分桶 0–19 / 20–39 / 40–59 / 60–79 / 80–100）、非空值的簡單均值、每型號與全站的結論計數。沒有結論的文章計為「無結論」，絕不代它下結論。
- 故障模式（/api/ledger/failures）：按型號把 issues[] 按原文問題逐字分組。近似重複分開保留、照原文呈現，不合併。計數是已分析文章中的提及次數。
9. 證據校驗
每篇分析入庫前跑兩道確定性校驗，與模型措辭無關。第一，compared_products 只保留在證據文本（標題＋摘要＋取回內文）中逐字出現的名字；compares_with 由保留後的名單重算，絕不輕信模型原文。第二，verdict_quote 只有其正規化文本出現在正規化證據文本中才保留，否則存為 null。這兩道校驗只約束新分析；校驗上線前的舊分析可能仍帶編造項，隨重分析清洗。
10. 即時數據 / 快照
數字能連上 API（D1）時取即時數；連不上時頁面渲染建構時從同一資料庫生成的凍結快照，並在頁眉寫明。快照絕不冒充即時。圖表由 API 或快照數據即時渲染（ECharts），不用靜態截圖；每張圖下方都有原始數據表。
11. 更正日誌
- 2026-11-07 — Meta Ray-Ban Display 續航。之前：「Up to 6 hours (per buying guide; Meta figure not yet confirmed)」。之後：「Up to 6 hours per charge (mixed use); charging case adds up to 24 hours; Meta Neural Band up to 18 hours」。來源：Meta Help Center，https://www.meta.com/help/ai-glasses/1116302600085081/。舊的「with case 30 hours total」說法已被取代，不再使用。
- 2026-11-07 — Oakley Meta HSTN 麥克風。之前：未列出（來源衝突）。之後：「5-mic array (2 per arm + 1 near nose pad)」。來源：Abt 與 Android Central。「dual beam-forming」的說法不再使用。規格表新增麥克風一欄；Ray-Ban Meta Gen 3 標「6-mic array」（據本站隱私卡），其餘型號標「未公布」。
12. 局限
- 分析是對標題、摘要與部分內文的 AI 抽取；多數分析基於 snippet（全文取不到）。每個抽取出來的數字都應理解為「文章裡這麼寫的」，不是已核實的事實。
- 標題門偶有漏錄與誤錄（見 §6 Motorola 案例）。誤錄文章從受影響的對照中排除並附註，不悄悄刪除。
- 本站 experience_records 為 0 行是設計使然；此處的「宣稱對實測」來自報導抽取，不是實驗室測量。獨立測量要靠 UX Ledger 的體驗記錄。
- 搜尋熱度只是 2026 年 11 月 5 日的兩張 Google Trends 截圖，不是連續序列。
- 圖表在瀏覽器裡渲染；圖表庫載入失敗時，圖下的數據表裡有同樣的數字。
13. 歷史、現在、未來——三段完整，歷史是基線
本站的數據分三段，缺一段就不完整：歷史（已經發生過的）、現在（當前值）、未來（此後的每一次變化）。絕不能以當前 0 為起點、只等未來變化再記錄——歷史與現在是未來變化的基線，沒有基線，變化就沒有意義。做法有三條：第一，每個維度都要回填歷史——價格歷史、規格與發布歷史、評測與體驗記錄歷史、提及與事件歷史，能從公開來源拿到的都要拿；第二，已採集的文章本身就是歷史——本站 233 篇已分析文章裡的宣稱值、實測值、問題與結論，已結構化回填進歷史帳本（見 /history/），不是等未來新文章才開始記；第三，只有在公開來源與已採文章裡確實不存在歷史記錄時，0 才是可接受的起點，且必須在本頁寫明。未來的一切變化，都以回填後的基線為參照：歸檔與句級 diff 從基線開始記。現狀說明：獨立實驗室測量（experience_records）仍為 0 行——公開來源中暫無本站口徑的獨立結構化測量記錄，報導中的上手實測值已進歷史帳本（標 tested），與獨立測量分開記，不混用。