夜雨聆风搜索引擎的底层逻辑正在被重写——当 Google 还在聚合编辑内容时，一个新的开源项目选择了一条更激进的路径：让真实用户的点赞、评论和真金白银的预测赔率来排序结果。
40K Star 背后的信号
GitHub 本周趋势榜上，last30days-skill 以 12,257 的周新增 Star 霸榜第一，总星标突破 40,547。这个数字放在整个 AI 工具生态里都算罕见——毕竟，它不是一个模型、不是一个框架，而是一个AI 代理的调研技能。
一句话定位：给 AI Agent 装上一双能同时扫遍 Reddit、X、YouTube、Hacker News、Polymarket 和全网的眼睛，然后合成一份有据可查的摘要。不是 SEO 排序，不是编辑推荐，而是人群的真实参与度驱动排序。
核心数据
40,547 总星标， 12,257 本周新增； 14 个数据源接入； 1,012 个测试用例全部通过
为什么它不可替代
一个残酷的事实是：当前没有任何单一平台能同时访问 Reddit 的真实讨论、X 的实时观点、YouTube 的深度内容、TikTok 的创作者视角和 Polymarket 的资金信号。Google 屏蔽 Reddit 评论，ChatGPT 仅和 Reddit 有合作且无法访问 X 和 TikTok，Gemini 仅有 YouTube 数据，Claude 原生没有上述任何平台数据。
数据孤岛不是技术问题，是商业博弈——每个平台都在用独占数据建自己的护城河。
last30days 的解法不是去打破这些墙，而是让用户带着自己的钥匙进门：自带 API 密钥和浏览器会话，AI 代理同时搜索所有平台，对结果交叉评分。这不是搜索引擎的优化，是搜索范式的重构。
免费接入的数据源（无需任何配置）
· Reddit — 公开 JSON API，含评论和点赞数
· Hacker News — 开发者共识，技术讨论核心阵地
· Polymarket — 真金白银的预测赔率，非主观观点
· GitHub — PR 动态、Release、Issue 讨论
六层架构：先解析再抓取再裁决
一个容易被忽略的设计：last30days 的核心壁垒不在来源数量，而在前置解析。大多数搜索工具拿到关键词就开搜，它却先停下来问三个问题：这是谁？在哪个社区讨论？用什么身份搜？
这就是 v3 引入的实体解析引擎——搜索"OpenClaw"，引擎会自动解析到创始人的 X 账号 @steipete、对应的 Subreddit、YouTube 频道和 TikTok 标签。搜索"Kanye West"则匹配 r/hiphopheads、@kanyewest 和 YouTube 上的评测内容。
整个系统分六层递进：
① 话题预判 — 高风险问题先追问，避免浪费完整运行
② 实体解析 — 找到人、社区和场域，再开始搜
③ 查询规划 — 意图驱动的子查询拆分，而非裸关键词
④ 多源抓取 — 14 个数据源并行拉取异构信号
⑤ 信源治理 — 跨平台合并、单作者上限、实体消歧
⑥ 持续沉淀 — SQLite 持久化，支持 watchlist 和每日简报
设计哲学一言以蔽之：先解析 → 再抓取 → 再裁决 → 最后可持续复用。
信源治理：跨平台复读不等于多元证据
多源搜索最大的陷阱不是"搜不到"，而是同一故事在三个平台出现，被当成三条独立证据。last30days 的集群合并算法解决了这个问题——当 Reddit、X、YouTube 出现同一事件时，v3 引擎将其合并为一个集群，保留多平台视角作为属性，而非独立计数。
更微妙的是单作者上限：每个作者最多展示 3 条内容。这是对"大声的人垄断简报"的工程级防御——KOL 一天发 12 条，平台推高，模型按热度吃料，摘要就被单一声部带偏。per-author cap 强制保留多声部空间。
评分逻辑也做了根本性翻转。传统的 mention count 排序在"最佳编程语言"这类问题上会失效——训练数据偏见 + 营销号复读推高噪声。last30days 转而追踪信号质量：重量级人物的立场变化、高质量 benchmark 的意外结果、少数派但证据更硬的观点。
信源治理核心规则
跨平台复读 → 合并为单条； 单作者刷屏 → 限 3 条封顶； 提及次数 ≠ 信号质量 → 按立场变化和意外结果评分
v3 引擎的五个关键更新
v3.3.0 版本不只是功能迭代，而是对整个搜索管线的重构：
① 可分享 HTML 简报 — 自包含暗黑模式 HTML，可直接分享到 Slack、邮件、Notion，无 JS、离线可用
② 智能搜索 — 先理解主题再确定搜索范围，搜索"OpenClaw"自动解析到创始人、社区和频道
③ Best Takes — 第二评分维度，按幽默感、趣味性和传播度输出最 viral 的引用
④ 单通道对比 — 旧版"CLI vs MCP"需 3 次串行搜索耗时 12+ 分钟，v3 一次通道同时搜索双方，同等深度仅需 3 分钟
⑤ 自动发现竞品对比 — 执行 --competitors，模型自动发现 Top 2 竞品并输出三方对比
从一次性搜索到持续情报基础设施
最容易被低估的是 last30days 的持续沉淀层。添加 --store 参数后，搜索结果会持久化到 SQLite——相同的 source_url 跨 run 出现时自动更新而非重复插入。搭配 watchlist.py 可实现定时运行，新内容自动通过 Slack/Webhook 推送；搭配 briefing.py 可生成每日/每周摘要。
搜索从一次性工具变成了情报基础设施——这是项目名"last30days"的真正含义：不是搜索过去 30 天，而是持续追踪过去 30 天。
模型不是法官，是流水线里的不稳定工位
一个值得所有 AI 工具开发者学习的工程哲学：last30days 把模型约束在"不稳定工位"上，用协议、前置解析、flag、模板和失败案例来约束，而非寄望于模型每次都做对。
具体来说：强制追问 gate 阻断模糊问题、QUERY_PLAN_JSON 约束搜索范围、缺省查询模板兜住降级路径、输出格式强制命令行校验。当模型输出漂移时，协议和模板比 retry 更可靠。
边界：它不是万能的
last30days 也有明确的能力边界。它强在 30 天内的实时信号，而非 5 年的历史纵深；强在社区真实讨论，而非结构化事实查询。医疗、法律、审计等高风险领域，社区讨论不能替代官方来源。无明确研究对象的泛泛主题，自身的 topic trap 机制也会先行拦截。
搜索工具的价值不在于它能搜到什么，而在于它知道自己搜不到什么。last30days 的 topic trap、--diagnose 诊断和优雅降级机制，正是这种自觉的工程化表达。
当搜索结果的排序依据从"谁写的最好"变成"谁真的在说、在争、在下注、在提交代码"，搜索的底层逻辑就被重写了。我们正站在这场范式革命的序幕——而非高潮。
参考来源
[1] mvanhorn/last30days-skill — GitHub
[2] Last30Days 开源解读：把社交信号变成 AI 搜索引擎
[3] 深度解析 last30days-skill — 知乎