把查 AI 模型做成插件
一、起因:我一天要回答三次同一个问题
做技术选型或者写文章的时候,我几乎每天都要发生三次这样的对话(有时是我自己问自己):
- “最近又有哪些新模型发布了?”
- “这个模型实测口碑怎么样?A 和 B 到底谁强?”
- “AI 圈这几天发生了什么?”
这三个问题的共同点是:答案不在一个地方,而且每一次都要重新找一遍。
跑分在 Artificial Analysis、Vals AI、SWE-bench、SWE-rebench、ARC Prize、LMArena、llm-stats、benchlm 上,口碑在 Hacker News、X、Reddit 上,中文社区的实测在 B 站、知乎、小红书、公众号、掘金上,新闻在四十多个 RSS 里。把这些挨个点开、复制、去重、对齐口径,一次要一两个小时。
更麻烦的是口径陷阱:同一个模型,在 A 站是 82 分、在 B 站是 71 分,你以为它“退步了”,其实是两套不同的刻度。人工整理十次,总有几次会混着用。
所以这个项目做的第一件事,不是“再做一个聚合页”,而是把每个源怎么解析、口径是什么、哪些分数不能相加,全部写成代码和文档。
二、三件套是什么
它其实是三个独立的命令行工具,加一层 DeepSeek Harness 的插件注册,一共 4 个工具、3 份技能文档。
| 工具 | 回答什么问题 | 主要来源 | 典型耗时 |
|---|---|---|---|
ai_model_radar | 最近 N 天有哪些模型发布 / 上线 / 开源 | 发布追踪站、OpenRouter 上架记录、官方博客 RSS、GitHub Release、arXiv、Hacker News 热度 | 数秒 |
model_report | 某个模型实测口碑如何、A 和 B 谁强 | 13 路结构化跑分 + 英文社区 + 中文社区 5 源 + 价格与上下文 | 15–25 秒(--fast 约 3 秒) |
ai_news_radar | AI 圈最近发生了什么 | 46 个 RSS/HTML 源 + 22 个官方 X 账号 + Google/Bing 检索 + HN/Reddit/公众号 | 数十秒 |
ai_fetch_article | 抓一篇指定文章的正文 | 走本机代理,返回标题 + 正文纯文本 | 数秒 |
三份技能(skills/ai-model-radar.md、model-report.md、ai-news-radar.md)不是给人看的 README,而是给 agent 看的操作手册:触发条件是什么、每个源在页面里的哪个字段、已知的坑在哪、什么情况该在报告里写“缺失”。比如 model-report.md 有 24651 个字符,光讲 13 路来源的解析细节就占了大半。
三、装它:三种形态任选
3.1 当成 DSH 插件用(推荐)
1 | dsh plugin add dsh-ai-research |
如果你用的是桌面版 DSH,等价写法是:
1 | node "<DSH 安装目录>/lib/plugin-cli.js" desktop add dsh-ai-research |
装完必须重启 DSH,插件才会被加载。之后在任何会话里都能直接调用上面那四个工具,不需要再进目录、不需要配 API key。
手工装也只需要三步:在 profile 的 package.json 里加依赖、把包写进 dsh.profile.bundles、再把 node_modules 软链进去。工具运行时的 import 解析顺序是:包内自带 tools/ → 回退到源码布局 → 插件配置里的 root 覆盖,所以从 npm 装的包和从源码克隆的仓库都能跑。
3.2 当命令行工具用
仓库里的 tools/ 是零依赖的纯 Node ESM,可以完全脱离 DSH 使用:
1 | # 最近 7 天有哪些新模型 |
常用开关:--fast(跳掉最慢的几路)、--no-x / --no-reddit / --no-lmarena / --no-cn(关掉单个源)、--per-source 5(每个源最多几条)、--json(额外输出结构化结果)。
Node 版本要求 ≥ 18,实际建议 20 以上。
四、产物长什么样
4.1 一个文档骨架,四处复用
三份工具的输出格式由同一个模块(model-report/doc.mjs)拼出来,规则只有四条,但每一条都是被坑出来的:
- 一份文档只有一个 H1。 多 H1 的 Markdown 在 GitHub 和大部分渲染器里目录会散架。
- 元信息走引用块。 第一行固定是
> 数据截止 2026-10-16 · 生成时间 12:40,第二行是> 全部来源为公开只读接口,仅供研究参考。——数据截止时间必须跟着结论走,否则一周后看到这份报告的人会以为它是今天的。 - 目录自动生成。 正文里只写一个占位符
<!-- dsh-toc -->,收尾时替换成 GitHub 风格的锚点目录(H2 + H3 两级),保证每次渲染都一致。 - 章标题自动编号。 写
## 模型档案,输出就是## 1. 模型档案,加一节不用手改序号。
4.2 报告里一定会有“数据缺口”
这是我认为整个项目最重要的设计:拿不到就写进 gaps,绝不静默返空。
1 | > 数据截止 2026-10-16 · 生成时间 12:40 |
一份报告如果悄悄少了一路来源,读者是看不出来的;但如果它在开头就告诉你“这一路没拿到,原因是这个”,你至少知道该不该信它的结论。
五、第一件套:模型发布雷达
ai_model_radar 只看一件事:最近有没有新模型出现。它合并六类信号:
| 信号 | 拿什么 | 为什么需要 |
|---|---|---|
| 发布追踪站 | aireleasetracker.com 内嵌的 releases 数组 | 人工维护的权威发布记录,更新最快 |
| OpenRouter 上架 | /api/v1/models 的 created 时间戳 | “能用了”比“发布了”更接近真实可及性 |
| 官方博客 RSS | OpenAI / Anthropic / DeepMind / Qwen / NVIDIA 等 | 一手信息,但常常滞后于社区 |
| GitHub Release | 各开源项目的 releases.atom | 开源模型的唯一真相 |
| arXiv | cs.CL 最新 40 条 | 论文先于模型,能提前看到风向 |
| Hacker News | Algolia 搜索 + 分数过滤(默认 ≥ 5 分) | 社区热度,用来判断值不值得关注 |
--days 默认 3 天;但权威发布记录本身很稀疏,所以“新模型记录”的回看窗口默认放到 60 天(releaseDays),避免每次都报“最近三天没有新模型”。
模块化 API 也留出来了:collect({days}) → summarize(res) → renderMarkdown(res),想接自己的输出渠道直接调这三个函数就行。
六、第二件套:模型体检报告
这是三个工具里最重的一个。它的目标不是“给个分数”,而是把同一个模型在不同尺度上的表现摊开。
6.1 13 路结构化来源,每一路的脾气都不一样
| # | 来源 | 拿什么 | 坑 |
|---|---|---|---|
| 1 | llm-stats 首页 | 408 个模型的统一字段(上下文、价格、GPQA、SWE-bench、HLE、arena 分数、发布日) | 数据在 RSC 的 initialHomepageLLMModels 里,不是 JSON 接口 |
| 2 | llm-stats 单模型页 | 分数 + verified / self_reported 标记 | 分三档 ★独立 / †第三方榜 / ‡厂商自报 |
| 3 | benchlm.ai | 首页静态表 25 行 | 唯一单一尺度,跨模型比较以它为主 |
| 4 | OpenRouter | 462 个模型的价格与上下文 | 缺字段要回填并标 * |
| 5 | Hacker News | story + 评论全文 | 唯一能拿到原文的英文口碑源 |
| 6 | 掘金 | 搜索 API | ctime 是秒不是毫秒 |
| 7 | GitHub | search/issues(in:title) | 这是“生态接入信号”,不是好坏评价 |
| 8 | Artificial Analysis | 700 个模型,自建 intelligenceIndex + 16 个分项 | 2.47 MB 的 RSC,约 17 秒;同一模型可能有 Max/High/Default 多档 |
| 9 | Vals AI | 50 个基准,默认取 8 个榜 | 每榜列名都不一样,得按位置定位分数 |
| 10 | SWE-bench 官方站 | 分榜:verified 116 / lite 58 / full 58 / bash-only 37 / multilingual 13 | 靠社区提交,明显滞后:实测最新只到 2026-02 |
| 11 | SWE-rebench | 115 个模型的滚动窗口解决率 | 分语言独立采样,不可相加 |
| 12 | ARC Prize | leaderboard/{v1,v2,v3}.json | ARC-AGI-3 的分数在 0.5% 量级,别当成能力暴跌 |
| 13 | LMArena | 5 个榜的 Elo / 95% 区间 / 票数 | 站点本体被 Cloudflare 挡,只能走 HuggingFace 官方数据集 |
6.2 三条口径纪律
这些坑最后沉淀成了三条硬规则:
- 不同刻度不混算。 Artificial Analysis 的“智能指数”、benchlm 的同尺度分、LMArena 的 Elo 是三套刻度,平均一下就变成毫无意义的数字。横评时只比双方都有的同名基准。
- 自报的分数要标出来。 llm-stats 的
verified字段在当前实现里恒为 false,所以 ★ 永远为 0——这不是 bug,而是“我没有能力独立复现厂商自报的分数”这件事的诚实表达。 - 滞后的榜单要标日期。 SWE-bench 官方榜是社区提交制,看到“最新只到 2026-02”不是它坏了,而是没人提交新结果。报告里会明写“官方榜提交滞后”。
6.3 横评是怎么挑对手的
--auto 3 时会从 408 个模型里按段位相近挑三个对手(看同尺度分数、参数量级、是否开源),然后逐项对齐双方都有数据的基准。挑不到就宁可只写“没有可比数据”,也不拿一个不同刻度的数字硬凑。
七、中文社区:五个源,两个坑
英文社区有 HN 顶着,中文这边要难得多。目前接了五个源:
| 源 | 需要什么 | 能拿到什么 |
|---|---|---|
| B 站 | 匿名 cookie(buvid3 / b_nut) | 实测视频 + 高赞评论原文 |
| CSDN | 无 | 教程与踩坑文 |
| 微信公众号 | 无(走搜狗) | 公众号文章,原文直链要二次请求解分片 |
| 掘金 | 无 | 技术社区讨论 |
| 知乎 | cookie(含 z_c0) | api/v4/search_v3,同题多回答按问题归并,留赞同最高的 |
| 小红书 | cookie(含 web_session)+ 本机 Chrome | 笔记与评论 |
7.1 坑一:并发一起打,会全部返空而且不报错
这个坑让我排查了很久:单独跑每一个源都正常,一旦同时并发,B 站返回 0 条、CSDN 返回 0 条、搜狗返回 0 条,而且没有任何异常。
最后的解法很朴素:串行 + 240~440ms 间隔。这听起来像退步,但它是唯一稳定的做法——顺便也更礼貌。
顺带还处理了一堆细节:B 站标题里带 <em> 要清洗、CSDN 的 URL 要削掉 utm 尾巴、搜狗返回的是跳转地址需要二次请求再还原 &。
7.2 坑二:小红书的签名只能在页面里算
小红书的搜索接口要 X-s: XYS_...、X-S-Common、X-t 三个签名头。分析下来:
- 站点 JS 里
XYS_和_webmsxyw出现 0 次——签名不是本地算的; - 它由
as.xiaohongshu.com/api/sec/v1/ds下发的混淆 SDK 在运行时生成; - 页面上
window._webmsxyw签出来的是旧版XYW_,直接拿so.主机去请求同样 406。
所以最后的实现是让页面自己搜:确保有一个开着 --remote-debugging-port=9222 的 Chrome → 注入 cookie → Page.addScriptToEvaluateOnNewDocument 挂钩子包 fetch / XHR 捕获 /search/notes 的响应 → 用原生 setter 往 #search-input 里塞关键词并回车 → 从钩子里取回 JSON。
启动 Chrome 的 --user-data-dir 必须指向系统临时目录,不能用工作区路径,否则 profile 会锁死。单次约 8 秒。
代价是有的:小红书每天新开页面的上限只有 4 次左右,碰到风控要冷却 24 小时。所以它默认排在最后、按需才跑,并且在 gaps 里明确写“本轮跳过”。
八、第三件套:AI 新闻日报
ai_news_radar 的目标是“整个行业发生了什么”,所以它的源最杂:
- 官方渠道:OpenAI、Anthropic(HTML 解析)、Google DeepMind、Google AI、Google Research、Hugging Face、Qwen、NVIDIA、AWS ML、Meta Engineering 的博客;
- 22 个官方 X 账号:OpenAI、AnthropicAI、GoogleDeepMind、nvidia、AIatMeta、Alibaba_Qwen、testingcatalog、kimmonismus、TheInformation、TechCrunch 等,按天轮转取样(X 的 syndication 接口有硬配额,15 分钟 30 次);
- 英文媒体:TechCrunch、The Verge、VentureBeat、Ars Technica、MIT TR、Wired、IEEE Spectrum、SemiAnalysis、Stratechery、Bloomberg、FT、WSJ 等二十多家;
- 中文媒体:量子位、智东西、雷峰网、InfoQ 中文、钛媒体、极客公园、IT之家、cnBeta、少数派、新浪科技;
- 检索兜底:Google News RSS(中英各 6–7 组查询)+ Bing News RSS;
- 社区:HN Algolia、Reddit(arctic-shift)、微信公众号(搜狗,默认关闭,
--wechat打开)。
去重之后按 8 个主题分类:模型/产品发布、融资并购估值、算力芯片数据中心、技术研究、人事组织、政策监管、商业合作、其它。社区热议单列。
九、礼貌与缺口:为什么它宁可空着也不编
整套工具里有几条不太显眼但很关键的纪律:
- 只读公开页面,不登录、不绕付费墙、不碰非公开接口;
- 串行 + 随机间隔,磁盘缓存,命中限流就熔断并把原因写进 gaps;
- 不静默返空:拿不到就是
null+ 一条 gap 说明,绝不用“看起来合理”的数字填坑; - 不混算口径:三套刻度各归各的章节。
这也是它和“随便爬一下”的区别:边界写在代码里,而不是写在 README 的免责声明里。
十、配置
绝大多数情况下零配置就能跑。需要微调时,用下面这些环境变量:
| 变量 | 默认值 | 作用 |
|---|---|---|
DSH_AI_RESEARCH_HOME | ~/.dsh-ai-research | 缓存、cookie、限流状态的存放目录 |
DSH_AI_RESEARCH_PROXY | 直连 | 代理地址(也认 MODEL_REPORT_PROXY / MR_PROXY / HTTPS_PROXY / HTTP_PROXY,按顺序取第一个非空;写 off 关闭) |
NO_PROXY | 空 | 不走代理的域名 |
DSH_AI_RESEARCH_COOKIES | <home>/cookies.json | 登录态文件 |
DSH_AI_RESEARCH_CHROME | 自动探测 | 指定 Chrome 路径(也认 CHROME_PATH / CHROME_BIN) |
DSH_AI_RESEARCH_CHROME_PROFILE | 系统临时目录 | 无头 Chrome 的 profile 目录 |
DSH_AI_RESEARCH_OUT | ./digests | 默认输出目录 |
国内环境最常改的就是代理:
1 | $env:DSH_AI_RESEARCH_PROXY = "http://127.0.0.1:7890" |
导入登录态
只有知乎和小红书需要 cookie,其余源全都不需要:
1 | # 把浏览器里复制出来的 cookie 直接塞进剪贴板,然后: |
脚本会自动剥掉 cookie: 前缀、折行和结尾的分号,写进 ~/.dsh-ai-research/cookies.json,全程不回显 cookie 值,只报长度、字段数和票据名。跑完 --test 会用指定关键词实测一次。
没有 cookie 也能跑:那两路会显式报“未配置登录态”并进 gaps。
十一、边界
- 抓不到就是抓不到。 Cloudflare、登录墙、纯前端渲染的站,一律明确跳过:LMArena 站点本体、HuggingFace 模型卡正文、Bloomberg / FT / Reuters 正文都属于这一类。
- 有配额。 X 的 syndication 接口 15 分钟 30 次;小红书每天新开页面 4 次左右,触发风控冷却 24 小时。
- 有滞后。 SWE-bench 官方榜靠社区提交;arXiv 只有摘要没有正文。
- 不是事实核验。 它汇总的是“网页上写了什么”,同一件事不同媒体可能有不同说法,读的时候要自己交叉验证。
- 不是投资建议,也不评价任何公司或模型的好坏——它只负责把公开信息摆整齐。
十二、链接
- 仓库:github.com/fomalhaut1998/dsh-ai-research
- npm:dsh-ai-research
- 许可:MIT
- 结构:
tools/(三个零依赖 CLI)·skills/(三份 agent 操作手册)·packages/dsh-ai-research/(插件注册层,含sync-tools.mjs/sync-skills.mjs与--check防漂移)
如果你也想把它接成自己的输出渠道(比如直接发到飞书、写进 Obsidian),collect → summarize → renderMarkdown 这三个函数就是入口,欢迎在 issue 里聊。

