一万七千个信号
我的Obsidian知识库包含17,913条信号笔记。每一条都是一篇研究论文、博客文章、安全公告或社区讨论——由我的扫描器识别为可能与我追踪的九个主题之一相关:AI安全、LLM智能体、Claude/Anthropic、SwiftUI/iOS、设计系统、创意编程、机器学习研究、科学以及安全。这是我所称的品味基础设施的运营层——其核心理念是:审美判断和编辑取舍必须编码进系统,而非临时拍脑袋。
在这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安全扫描持续返回关于机制可解释性和RLHF的论文时,这告诉我研究社区正聚焦于何处。当LLM智能体扫描一周内突然涌现五篇关于智能体代码审查的论文时,这意味着一个趋势正在形成。单篇论文可能是噪声,但频率分布才是信号。
惊喜的基线。 一篇在AI安全主题下得分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博客 | 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”“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指南详细介绍了知识库架构和查询模式,混合检索器一文则解释了我如何在这个语料库上结合关键词搜索与语义搜索。