Last30Days 开源解读：把社交信号变成 AI 搜索引擎

大家好，我是若风。

最近我在看一个很火的开源 Skill：mvanhorn/last30days-skill。

第一眼看 README，其实很容易把它理解成“又一个帮 AI 搜最近 30 天内容的工具”。但我顺着它的 README、SKILL.md 和 CONFIGURATION.md 一路读下来，越看越兴奋，感觉这个项目真正有意思的点，根本不在“搜索”两个字。

它更像一个把多平台社会信号拉平、再交给 Agent 重排和裁决的研究引擎。

说实话，这个判断挺重要的。因为今天大家嘴上都在说“做 research”，但很多工具做出来还是传统搜索那一套逻辑：抓网页、列链接、做摘要。你看到的是结果页面，不是社区温度；看到的是 SEO 排名，不是争议密度；看到的是编辑写好的文章，不是用户刚吵完的评论区。真要拿这些结果去做判断，后面常常会越做越焦虑。

last30days 想解决的是另一类问题：如果一个话题的真实变化，最早出现在 Reddit、X、YouTube、GitHub、TikTok、Polymarket 这些分散的平台上，Agent 怎么把它们拉到同一张桌子上讨论？

截至 2026 年 6 月 7 日我打开 GitHub 页面时，这个仓库大约有 26.7k Star、2.3k Fork，Release 页面最新版本是 v3.3.0（2026 年 5 月 17 日），而 main 分支里的 skills/last30days/SKILL.md 头部已经写到 3.3.2。这说明它现在还在快速演进，README 里的很多设计，不是营销话术，是真正在沿着一条清晰路线继续往前推。

这篇文章不写安装教程。

我更想聊的是：它到底凭什么能把“最近 30 天发生了什么”这件事做得比普通搜索更有用？尤其是，它的信源处理逻辑到底强在哪里？

先说结论

如果只看表层，last30days 是一个跨平台搜索 Skill。

但往里拆一层，它其实是 6 个环节串起来的系统：

所以它不是“给大模型加几个搜索 API”。

更准确地说，last30days 在做的事，是把社交平台、开发平台、视频平台和预测市场上的碎片化证据，整理成一条 先解析、再抓取、再裁决、最后可持续复用 的研究链路。

一句话概括：

它表面上在搜内容，真正做的是信号编排。

它为什么不是普通搜索

README 开头有个判断我很认同：Google 更像“编辑聚合”，last30days 更像“人群搜索”。它要找的不是哪篇稿子写得最好，而是哪类人最近真的在说、在争、在下注、在提交代码。

这也是为什么它天然偏好多种异构来源：

• Reddit 给你未经修饰的讨论和高赞评论；
• X 给你最早出现的观点和热争议；
• YouTube 给你长视频里的上下文和口语化解释；
• GitHub 给你真正发生的 PR、Release、Issue 和 repo 动向；
• Polymarket 给你“有人拿真钱下注”的概率判断；
• Hacker News 给你更工程师视角的技术共识；
• Web 搜索反而只是补充项，不再是唯一入口。

这个项目最聪明的地方，是它没有假装这些来源能天然兼容。

它很清楚：不同平台的信号单位完全不一样。

X 的一个高赞短帖，和 YouTube 一个 40 分钟播客片段，和 GitHub 一次发布说明，根本不是同一类东西。你如果只是把它们全塞进上下文窗口里，让模型自由发挥，最后大概率会得到一篇“看起来很全，其实很虚”的综合摘要。

last30days 的选择不是盲目求全，而是先定义一套统一的研究协议，再让这些来源进入同一条流水线。

第一层：先把“去哪里找”搞对，比直接开搜更重要

我觉得 last30days 的真正分水岭，在 SKILL.md 里的 Step 0.5 和 Step 0.55。

这两步背后的思想特别工程化：

搜索不是从关键词开始，而是从实体解析开始。

如果用户输入的是一个人、一个产品、一个开源项目，甚至一个模糊概念，系统不会立刻跑搜索。它会先判断这是哪一类 topic，需不需要补上下文，需不需要转成更可执行的研究问题。

SKILL.md 里甚至专门列了几类高风险主题，比如过于泛的单个名词、礼物类问题、教程类问题、没锚点的大类问题。遇到这种情况，要求先做 pre-flight note，必要时先追问，再决定是否继续执行。这个设计看起来有点啰嗦，但很值。

因为研究任务最贵的成本，往往不是调用 API 的钱，而是一次完整运行之后，才发现你根本搜错了地方。

更关键的是，last30days 不只是在问“这个词是什么意思”，它在问：

• 这个人有没有 X 账号？
• 他是不是也对应一个 GitHub 用户？
• 这个产品有没有官方 repo？
• 哪些 subreddit 才是它真正的社区？
• TikTok 和 Instagram 上该搜 creator 还是 hashtag？
• 对比类查询应该拆成哪几个实体去跑？

SKILL.md 把这些解析项明明白白写成 flag：--x-handle、--x-related、--github-user、--github-repo、--subreddits、--tiktok-hashtags、--tiktok-creators、--ig-creators。而且不是“有就加”，而是对不同 topic class 明确规定哪些 flag 是最低要求。

这套做法特别像一个好研究员的习惯：

别急着搜，先把人、社区和场域找准。

很多人觉得搜索的核心是召回，其实不是。对复杂话题来说，第一步更像路由。如果路由错了，后面再多并发都是白搭。

第二层：Query Plan 才是它的“智能搜索”引擎

README 把 v3 的核心升级叫做 intelligent search。我觉得这个说法没有夸张。

因为它不是简单把“OpenClaw”这个词丢给多个平台，而是先做一轮查询规划，再把查询计划传给脚本执行。SKILL.md 里明确要求在 WebSearch 可用的平台先生成 QUERY_PLAN_JSON，把话题拆成 2 到 4 个子查询，然后为每个子查询设置权重、source coverage、freshness mode 和 cluster mode。

这个设计很关键。

普通搜索的思路是：一个关键词，打满所有来源。

last30days 的思路是：同一个研究问题，按意图拆成几组不同的搜索动作。

比如产品类查询，它会更偏向：

• YouTube 上的 review / demo；
• Reddit 上的讨论和踩坑；
• TikTok 上的实际展示；
• GitHub 上的 repo 活跃度与 issue；
• 对比类场景再补 head-to-head 子查询。

SKILL.md 里还有几个细节，我觉得很见功力：

第一，它明确禁止把“last 30 days”“recent”“2026”这类时间词塞进 search_query。时间窗口不是靠关键词拼出来的，而是靠引擎自己的时效过滤和后续打分控制。

第二，它要求 comparison 查询不要只做一个 “A vs B” 查询，而是同时做 per-entity subquery 和 head-to-head subquery。这个很像研究中的“先看个体，再看交叉项”。

第三，它把 topic intent 映射到 freshness_mode 和 cluster_mode。breaking news 走 strict_recent，concept / how_to 可以 evergreen_ok，prediction 则更适合 market cluster。

这说明它不是把所有任务都当成同一种 research job。

不同问题，需要不同的检索节奏和聚类方式。

这比“接更多数据源”更重要。因为没有 query planner，多源只会带来更多噪声；有了 query planner，多源才开始变成互补。

第三层：真正的壁垒，不是多源本身，而是多源如何接入

如果你只看 README，很容易觉得 last30days 的卖点就是来源多。

但我读完 CONFIGURATION.md 后的感觉是：这个项目真正的含金量，在于它把“不同来源怎么启用、怎么降级、怎么共存”想得很细。

它不是一个 all-in API 平台，而是一套分层接入策略。

默认可用的免费层

README 和配置文档都写得很清楚，默认就能工作的几类来源是：

• Reddit（含 public JSON 评论）
• Hacker News
• Polymarket
• GitHub（gh CLI 存在时）

这几类来源的共同点是：信号质量高，而且接入成本相对低。

换句话说，last30days 不是上来就逼用户买一堆 key。它先给一层足够能打的免费骨架，再逐步解锁更贵、更复杂的来源。

条件启用的增强层

然后才是第二层：

这套分层很像一个有预算意识的研究系统。

先把便宜而高信号的来源打通，再让用户自己决定要不要为 TikTok、Instagram、Perplexity 这种来源付费。

坦白讲，这比很多“看起来一站式”的方案更现实。因为真实研究工作不是永远跑满配置，而是在 成本、信号质量、时效、场景需求 之间反复权衡。

它甚至把配置优先级都写清楚了

CONFIGURATION.md 还专门把这几件事讲明白了：

• 项目级 .claude/last30days.env 优先于用户级 ~/.config/last30days/.env；
• reasoning provider 有自己的优先级；
• web backend 也有自己的优先级；
• 没有配置 backend 时，可以退到宿主原生 WebSearch；
• 用 --diagnose 可以先做来源可用性诊断，不必真跑一轮全搜索。

这些细节看起来不起眼，但其实就是“可运营性”。

一个研究工具能不能长期用，不只看第一次能不能跑通，还看当某个来源缺失、某个 key 失效、某个平台网络变慢时，用户能不能快速知道问题出在哪。

第四层：信源处理真正强的地方，在治理，不在堆料

这是我最想聊的一部分。

如果说 Step 0.5 / 0.55 解决的是“搜哪里”，那后面的信源治理解决的就是“怎么不被搜到的东西反噬”。

README 和 SKILL.md 里有几件事，我觉得很说明问题。

1. 同一件事，跨平台只算一件事

README 提到 cross-source cluster merging：同一个故事如果同时出现在 Reddit、X、YouTube，不应该在结果里变成 3 条独立事实，而应该被合并成一个 cluster。

这件事很重要。

因为如果不做 cluster merge，多源研究很容易虚胖。你以为自己找到了 12 条证据，结果其中 8 条都在讲同一件事，只是换了平台和说法。

last30days 这里的判断非常对：

跨平台复读，不等于多元证据。

真正高质量的研究，不是罗列更多链接，而是识别哪些是同一故事的不同切面，哪些才是独立的新信号。

2. 一个作者再高产，也不能垄断整份 brief

README 里还有一个细节：per-author cap，单个作者最多 3 条结果。

这个规则我特别喜欢。

因为很多研究任务都会被“大声的人”污染。某个 KOL 一天发 12 条，平台又刚好把他推得很高，模型如果只按相关度或热度吃料，最后生成的摘要很可能全是同一个人的视角。

但高频，不等于全面。

加 author cap，本质上是在给信源做去偏置。它不是否定强信号作者的价值，而是防止一份研究报告被单一声部带偏。

3. 先信实体解析，再信模糊匹配

README 还提到 entity disambiguation。

这背后的意思是：一旦系统已经通过 pre-flight 确认了 handle、repo、社区，就应该优先相信这些解析结果，而不是继续放任关键词模糊匹配。

这特别像搜索系统里的“先消歧，再召回”。

比如一个单词既可能是产品，也可能是地名、品牌名、甚至普通名词。如果没有实体约束，搜索结果很容易被无关内容拖走。last30days 显然吃过这种亏，所以把消歧上升成了协议层要求。

4. 排名靠 signal quality，不靠 mention count

SKILL.md 里有一段我印象很深：它专门拿“best programming language for AI agents”这个失败案例说事，明确要求 recommendation 不要按 mention count 排序，而要按 signal quality 判断。

这个 distinction 很重要。

因为“被提到很多次”和“值得推荐”从来不是一回事。

训练数据偏见、 bootcamp 内容泛滥、营销号复读，这些都会把某些词的 mention count 推得很高。可真正有价值的信号，往往来自：

• 一个经验很重的人发生立场变化；
• 一个高质量 benchmark 给出意外结果；
• 一个看起来少数派、但证据更硬的观点；
• 一条能解释“为什么大家都说 X，但真正卡点在 Y”的反信号。

也就是说，last30days 不只是做信息聚合，它还在努力把“热闹”翻译成“判断”。

这件事并不简单。

第五层：它把模型当成不可靠组件来约束

这个项目还有一个让我很有好感的地方：它对大模型并不天真。

很多 Agent 工具的问题是，作者嘴上说在做 workflow，实际还是把成败押在“模型这次发挥好不好”。last30days 显然不是这种路线。

SKILL.md 里充满了各种 hard gate 和 failure mode：

• 哪些 topic 必须先追问；
• 哪些步骤在 WebSearch 平台上是强制执行；
• 少了 QUERY_PLAN_JSON 会退化成 bland summary；
• 命令必须带 --emit=compact；
• 哪种路径是 known regression，不允许走；
• stale clone 会导致旧版本 skill contract 被误读，必须先 self-check。

这类设计其实透露出一种很成熟的心态：

模型不是法官，模型是流水线里的一个不稳定工位。

既然它不稳定，就要靠协议、前置解析、flag、模板、失败案例和输出 law 来兜住。

这也是为什么我觉得 last30days 值得写。

它不是在炫“我能接多少来源”，而是在认真处理一个更难的问题：当来源变多、步骤变长、模型参与更多时，怎么让整个系统不要漂。

第六层：从一次性搜索，变成长期情报基础设施

很多人读这种 repo，容易只盯着 slash command 本身。

但 CONFIGURATION.md 其实还埋了一个很重要的方向：--store、SQLite、watchlist.py 和 briefing.py。

也就是说，last30days 不只想做“一次性跑一篇最近 30 天总结”。

它还想把这个过程变成持续监控：

1. 先跑一次 baseline；
2. 用 --store 把 findings 持久化到 SQLite；
3. 通过 watchlist.py 管 recurring topics；
4. 新发现再推送到 Slack 或 webhook；
5. 最后由 briefing.py 生成 daily / weekly digest。

这就不是搜索框思维了。

这是情报系统思维。

尤其是 findings 按 source_url 做去重这一点，很像数据层面的“事实主键”。相同 URL 在不同 run 出现，不会无限堆重复，而是更新已有记录。这说明作者已经在考虑时间序列和增量监控，而不是只做一次性的 markdown 产物。

所以如果你把 last30days 只理解成一个 research prompt，其实有点可惜。

它更像一个逐步成型的 personal intelligence pipeline。

它适合什么场景

我会把 last30days 放在这几类任务里优先考虑。

第一，追踪一个人、产品或公司最近一个月到底发生了什么。 特别是那些变化先发生在社交平台、issue、视频和评论区，而不是先出现在媒体报道里的主题。

第二，做开源项目或 AI 工具的社区温度判断。 GitHub 活跃度、Reddit 争议、X 口碑、YouTube 演示和 Polymarket 概率放在一起看，信息密度会比纯搜文章高很多。

第三，做 sales / BD / 投资前的短周期研究。 你不是要一份百科全书，而是要最近 30 天的增量信号。

第四，做持续 watchlist。 某个赛道、某家创业公司、某个创始人，只要你需要每周盯一次，store + watchlist + briefings 这套就很有价值。

第五，拿它给 Agent 做上下文注入。 先用它建立一份带来源的 research brief，再让模型继续写邮件、做内容、做选型，靠谱程度会明显高一截。

它不适合什么场景

当然，它也不是万能的。

第一，历史纵深很长的问题。 last30days 强在最近 30 天信号，不强在五年演变史。做长期历史分析，还是要配合更传统的资料整理。

第二，完全结构化的事实查询。 比如某个 API 参数、某项法律条文、某个数据库字段定义，这类问题直接查官方文档更快。

第三，对来源一致性要求极端严格的领域。 医疗、法律、审计这类高风险场景，社区讨论可以做补充，但不能替代官方和专业来源。

第四，没有明确研究对象的泛泛主题。 SKILL.md 自己就对这类 topic 很警惕，因为越泛的问题，越容易在多源平台里炸成噪声。

最后说两句

我看完 last30days 之后，最大的感受是：这不是一个“会搜索的 Skill”，而是一个把 research 这件事拆得很工程的开源项目。

它真正有价值的地方，既不是花哨的 prompt，也不是来源数量本身。

真正关键的是三件事：

第一，搜索前先做实体解析和查询规划。

第二，抓回来以后先做信源治理，再交给模型综合。

第三，把一次性 brief 继续往 store、watchlist、weekly digest 这条链路上延长。

如果你最近也在做 Agent research workflow，我很建议认真读一下这个仓库。尤其是 SKILL.md 和 CONFIGURATION.md，里面很多判断都很实战。

表面上看，它是在回答“最近 30 天大家在聊什么”。

真正关键的是，它在回答另一个更难的问题：

当世界的信息先碎在十几个平台里时，Agent 要怎么先学会找人、找社区、找证据，再学会下结论。