一萬七千個訊號
我的 Obsidian 知識庫包含 17,913 則訊號筆記。每一則都是一篇研究論文、部落格文章、安全公告，或社群討論——經由掃描器判定可能與我追蹤的九個主題相關：AI 安全、LLM 代理、Claude/Anthropic、SwiftUI/iOS、設計系統、創意程式設計、ML 研究、科學，以及資安。這是我所謂品味基礎設施的運作層——美學與編輯判斷必須編碼進系統，而非臨時拼湊。
在這 17,913 個訊號中，我仔細閱讀過的大概只有 200 個。另外約 500 個影響了某個決策、一篇文章或一項設計選擇。其餘 17,213 個是雜訊——我掃描、評分、歸檔，卻未曾採取行動。
雜訊並非浪費。雜訊本身就是校準的工具。
評分難題
每個訊號都會獲得一個 0 到 1 的複合分數，依四個維度加權計算：相關性（是否符合我的主題）、可行性（能否據此採取行動）、深度（內容是否有實質內涵）、權威性（來源是否可信）。分數高於 0.55 的訊號會寫入領域資料夾；介於 0.40 到 0.55 之間的進入收件匣；低於 0.40 則直接跳過。
這些門檻是校準出來的，不是隨意選定的。它們來自數月的掃描，反覆檢視每個分級的內容，不斷調整，直到訊噪比感覺對了為止。0.55 最初設得太高（漏掉了後來證明很重要的論文）。0.30 又太低（收件匣塞滿了垃圾）。目前的門檻每次掃描約產生 15-30 則領域寫入和 10-20 則收件匣項目。
這套評分系統有我清楚了解的偏差：
研究論文的權威性起點是 0.75。 一篇 arXiv 論文只要分類和關鍵字吻合，在任何內容評估之前就已獲得 0.75 分。這是刻意的：來自相關領域的同儕審查研究，具備部落格文章和 HN 討論所不及的基線可信度。
安全公告的權威性起點是 0.95。 來自 NVD 的 CVE 或 GitHub 的 GHSA，無論內容如何都會獲得高分，因為漏洞公告的存在本身就是訊號。內容是次要的，事實的存在才是關鍵。
HN 討論的權威性起點是 0.55。 社群討論在情緒感知和發現新事物方面很有價值，但作為事實來源並不可靠。一篇高票 HN 文章討論某篇新論文，那是發現機制，不是來源。論文本身才是來源。
這些基線編碼了我對來源可靠性的判斷。不同的人，有不同的優先順序，自然會設定不同的基線。這些基線不是客觀真理，而是對「信任從何而來」的系統化見解。完整的評分方法記載於我的訊號評分管線。
雜訊教會了什麼
大多數掃描產生 80-100 則領域寫入和 20-40 則收件匣項目。其中大部分是雜訊：我永遠不會讀的論文、與我無關的軟體安全公告、我追蹤但不會採取行動的主題討論。
雜訊教會了三件事：
領域的輪廓。 當 ai-safety 掃描持續回傳關於機制可解釋性和 RLHF 的論文，這告訴我研究社群的焦點所在。當 llm-agents 掃描突然在一週內產出五篇關於代理式程式碼審查的論文，這告訴我一個趨勢正在成形。單篇論文或許是雜訊，但頻率分佈本身就是訊號。
驚奇的基線。 在 ai-safety 主題中，一篇 0.65 分的論文毫不起眼。一篇 0.91 分的論文則令人驚訝。這種驚訝之所以有意義，正是因為我有大量 0.65 分論文建立的基線。雜訊建立基線，訊號是偏離基線的異常值。
覆蓋範圍的盲區。 當 LiteLLM 供應鏈攻擊發生時，我的 scan-intel 管線透過 HN 關鍵字匹配捕捉到了它。但當時管線尚未接入安全公告來源（NVD、OSV、GHSA）。這個盲區在事件落入漏洞之前是隱形的。隔週，我便擴充管線，新增了三個安全公告來源。這些新來源產生的雜訊正在教我什麼是正常的公告流量。下一個盲區，會更早被看見。
擴充歷程
管線最初有 6 個來源，現在有 12 個：
| 來源 | 類型 | 捕捉內容 |
|---|---|---|
| arXiv | API | 依分類與關鍵字篩選的研究論文 |
| Semantic Scholar | API | 含引用數據的學術論文 |
| Hacker News | API | 以票數加權相關性的社群討論 |
| HuggingFace Daily Papers | API | HF 社群策展的 ML 論文 |
| Lobsters | RSS | 技術社群討論 |
| Simon Willison | Atom | 來自實務工作者的 AI 工具評論 |
| Anthropic blog | Scrape | Anthropic 官方公告 |
| Papers With Code | Scrape | 附帶實作的論文 |
| Apple ML Research | Scrape | Apple 的 ML 研究發表 |
| NVD | API | 含 CVSS 評分的 CVE（2026年3月新增） |
| OSV | API | 針對 15 個監控套件的套件級公告 |
| GitHub Advisories | CLI | 含別名交叉比對的 GHSA 條目 |
每個來源都帶來了雜訊，但每個來源也捕捉到了其他來源漏掉的東西。LangChain 路徑穿越漏洞出現在 GHSA 但未見於 HN。Claudini 自動研究論文在 arXiv 上出現的時間比 HN 早了 12 小時。LiteLLM 憑證竊取程式在 OSV 中帶有 MAL-2026-2144 識別碼，而 NVD 當時尚未收錄。
別名去重系統會合併跨來源的重複項。同一個 CVE 同時出現在 NVD、OSV 和 GHSA 時，只會產生一則訊號筆記，而非三則。首次正式運行中，85 則安全訊號裡有 6 則經別名去重。隨著來源成熟，去重率將會提升。
分流紀律
一萬七千個訊號需要嚴格的分流紀律。我的做法很簡單：瀏覽輸出，閱讀高分項目，其餘歸檔。
一次典型的掃描需要 3 分鐘執行、2 分鐘審閱。0.80 以上的訊號我每則必讀（通常每次 2-5 則）。0.60 到 0.80 之間的快速瀏覽，留意是否有異常。0.60 以下的一概忽略，除非某個關鍵字恰好引起注意。
掃描已成為習慣。晨間一次，晚間一次。有些天產出超過 100 則領域寫入（新一批 arXiv 論文發布時）。有些天產出為零（7 天回溯窗口已完全去重時）。波動是正常的，習慣是恆定的。
最重要的訊號，是那些改變了我所建造或書寫之物的訊號。Claudini 論文（0.83）成為了一篇部落格文章。LiteLLM 供應鏈攻擊（HN 來源 0.67，隨後經 OSV 確認為 0.62）成為了一篇部落格文章及兩篇既有文章的引用更新。LICA 資料集（手動發現，非 scan-intel 捕獲）成為了設計品味引擎的規劃方案。SlopCodeBench 論文（0.77）成為了複合脈絡文章的引用候選。
多數訊號不會變成任何東西。它們靜靜歸入知識庫，建立基線，等待某一天——一個新訊號與一個舊訊號產生連結，生成兩者各自都不曾包含的洞見。
知識庫即記憶
知識庫不是閱讀清單。我無意閱讀那 17,213 個未讀的訊號。知識庫是一座可查詢的記憶體，記錄著我觀測期間這個領域產出了什麼——一種知識拓撲，其中連結的結構比任何單一節點都更重要。
當我撰寫一篇關於供應鏈安全的部落格文章時，我可以搜尋知識庫中過去 90 天內所有標記為「security」和「supply-chain」的訊號。搜尋結果會回傳 LiteLLM 攻擊、Trivy 入侵事件、MCPTox 基準測試、Clinejection 攻擊，以及十餘個影響 AI 基礎設施套件的 CVE。每一個都是潛在的引用、數據點或反論。
當我規劃新功能時，可以搜尋與該領域相關的訊號。LICA 資料集在某次 scan-intel 運行中以 0.72 的 design-systems 訊號出現。我不可能透過定向搜尋找到它，因為我根本沒在找圖形設計資料集。掃描器之所以浮現它，是因為關鍵字（「design systems」、「typography」）吻合。知識庫建立了這個連結。
那 17,213 個未讀訊號不是白費功夫。它們是可查詢的索引化脈絡，在需要時隨時調用。掃描成本極低，索引完全自動。價值處於潛伏狀態，直到某個問題連結上數月前歸檔的某個答案。這就是複合脈絡的實踐：今天存入的每一個訊號，都可能成為未來某次綜合分析中缺失的那一片拼圖。
常見問題
使用了哪些工具？
掃描器是一支自訂的 Python 腳本（scan_intel.py，約 1,200 行），從 12 個來源擷取資料，透過分流引擎評分，經三層去重（URL、論文 ID、公告別名），最後將 markdown 筆記寫入 Obsidian 知識庫。知識庫使用 Dataview 進行查詢。設定存放於 JSON，狀態（已見 ID）同樣存於 JSON，並設有 90 天清除機制。
成本多少？
零。所有來源都是免費 API 或公開 RSS 訂閱。arXiv、Semantic Scholar、OSV 和 HN Algolia API 無需驗證。NVD 有免費方案，附帶速率限制（每 30 秒 5 次請求）。GitHub 公告使用 gh CLI，透過現有的 GitHub 登入階段進行驗證。
如何避免資訊過載？
靠評分門檻和分流紀律。每次掃描我花 2 分鐘審閱輸出。0.60 以下的訊號歸檔但不閱讀。知識庫持續增長，但我的注意力不隨之擴張。知識庫是記憶體，不是閱讀作業。
我也能用這套系統嗎？
架構是可移植的：從 API 擷取資料、以加權條件評分、去重、寫入知識庫。具體的來源、關鍵字和門檻是針對我的興趣校準的。您需要定義自己的主題、關鍵字和權威性基線。評分引擎和去重邏輯與領域無關。我的 Obsidian 指南詳細介紹了知識庫架構和查詢模式，而混合檢索器一文則說明了我如何在這個語料庫上結合關鍵字搜尋與語意搜尋。