AIHOT 项目推荐：7.6k star 的"行业热点站"框架，把 LLM 精选流水线连同提示词一起开源

AIHOT（KKKKhazix/AIHOT）是一个开源自托管的"行业热点站"引擎。它每天从一批信源里收资料，用大模型先筛一遍、再独立打两次分，挑出真正值得看的，写成中文标题和摘要；把不同来源说的同一件事聚成一个事件，按"有多少人在说"排出热点；每天早上出一份日报。

听起来像又一个"AI 新闻聚合站"？不是。它真正特别的地方是：这套站的引擎和框架全部开源，包括每一步提示词的原文和入选门槛。为什么一条消息能上精选、为什么它排在前面，全部可以打开文件逐条对照。

这次推荐我想聊的重点不是"又多了个 RSS 阅读器"，而是当"推荐算法"从黑盒变成可读的提示词与显式门槛时，工程上会发生什么变化——这是 AIHOT 真正有料的部位。

关键数据概览

• 仓库：KKKKhazix/AIHOT，MIT 许可（站名与 Logo 不在许可范围内）
• 热度：7.6k stars / 1.8k forks（2026 年 9 月 28 日创建，不到三周）
• 语言构成：TypeScript 约 321 万字节（占绝对主体）、CSS 21.5k、PL/pgSQL 3k
• 技术栈：Node.js 24 · TypeScript 7 · React Router（SSR）· Fastify · PostgreSQL 17 · pg-boss · Tailwind CSS · Docker Compose
• 活跃度：pushed_at 为 2026-10-14，最近提交集中在归组校验、后台 SelectBench 金标冲突检测、材料安全边界
• 规模：17 位贡献者、30 份提示词文件、独立迁移编号已排到 0055+
• 作者：数字生命卡兹克（设计师出身，自述"和 AI 一起重写了这套代码"）

起源：一个设计师被"行业定制需求"逼出来的开源

AIHOT 的诞生故事挺特别。作者不是职业工程师，用他自己的话说，“半年前还看不太懂代码”。他把 AIHOT 做成型之后，做法律、HR、金融、贵金属的朋友纷纷来问：能不能也给我们的行业做一个？

他做不了——不懂那些行业的信源，也不知道什么样的消息才算热点。于是选择另一条路：既然满足不了所有人，就把火种交出去。仓库里放着引擎、后台、精选流程、聚簇与热度算法，以及所有提示词原文；只把 AIHOT 自己的信源名单和运营数据拿掉，换成 18 个公开的海外 AI 资讯源做示范。

这个出身解释了它的一个特征：所有"可配置项"都被刻意收拢到了两个文件夹里——site/（站名文案、出刊时间、品牌）和 industry/（分类、标签、信源、提示词、入选门槛）。改成自己的行业，代码基本不用动。

技术亮点一：两次独立评分 + 分级门槛，把"值不值得看"变成一个可校准的分数

大多数 AI 聚合站的精选逻辑是"让大模型判断一下"，然后就没有然后了——不可复现、不可审计、调不动。AIHOT 把它拆成了三件可解释的东西：

第一件：预筛宽进，只拦明显无关的。 prefilter.md 输出 BLOCK / PASS / UNKNOWN，BLOCK 的直接不出现在任何公开页面。这一步故意做宽，避免"误杀"发生在信息入口。

第二件：同一份评分标准，独立打两次分。 注意是独立两次，不是一次打分取整。两次得分之和 ≥ 2 × 门槛才够分，页面上显示的是两次的平均值（向下取整）。为什么值得这么做？因为单次 LLM 打分的方差是真实存在的——同一个模型、同一份提示词，温度非零时对同一条资料可能给出差距不小的分数。用两次独立采样 + 求和门槛，等于在成本几乎不变的前提下做了一个轻量的"投票/集成"，把打分从"单点估计"变成"带噪声抑制的估计"。这个设计不新，但敢把它写进门槛公式并公开，是少见的诚实。

第三件：门槛按信源分级给不同值。 这段代码短到可以直接贴出来：

export const SELECTION = {
  thresholds: { T1: 60, T1_5: 65, T2: 76 },   // 两次评分的平均至少要到这个数
  understandFloor: 50,                        // 平均分高于它的未入选资料，也按入选的写法写
} as const;

T1 是官方一手信源（官网、官方博客、机构），T1_5 是官方账号与准官方创作者，T2 是媒体与个人。同样一件事，官方原文的门槛比媒体稿低 16 分。 这条规则的含义是：来源权威性不是评分类别里的一个加分项，而是直接在准入门槛上体现——官方一手稿"及格线更低"，媒体稿必须内容本身足够好才够格。这比"在提示词里让模型考虑权威性"要硬得多。

understandFloor: 50 也是个有意思的经济学设计：没入选但分数尚可的资料，也用"精选级"的写法（标题、摘要、推荐理由）来写；其余走更便宜的"标题摘要翻译"。 一条资料的文案质量服从它的分数，而不是一刀切——同一份系统里，贵的模型调用被花在最可能被读的内容上。

配套的还有一整套校准工具链：scripts/eval-selection.ts 让你拿 100–200 条自己标注的样本（{"decision":"select"|"reject"|"either"}）跑评测，输出有效输出准确率、查准率、查全率、F1、覆盖率，以及从 40 到 90 每隔 2 分扫描门槛会得到什么结果——直接告诉你门槛该定在哪。评测结果导入后台的 SelectBench 并排比较多个模型，判错的条目逐条看模型给的理由。“改提示词"在这里是一个有度量、有留出集、有回归评测的工程动作，不是玄学调参。

技术亮点二：先召回后判定的事件聚簇，和"按事件算"的热度

AIHOT 的第二个硬功夫在处理"同一件事被十家媒体报道"这个经典难题上。它的做法是两阶段：先廉价召回，再让模型判定关系。

召回阶段用标题和摘要的向量（没配向量服务时退化为文字重合度）在最近两周的窗口里找候选。这里有个工程取舍值得注意——向量只用来"缩小候选集”，不用来做最终决定。向量相似度高不代表是同一件事（同一家公司的两条不同新闻会很像），所以它只负责把候选从"全库"缩到"几十条"。

判定阶段是模型的活，关系被明确分成四类：

• SAME_OCCURRENCE：同一次真实发生，例如同一发布的官方原文和媒体报道
• SAME_STORY：不是同一次发生，但属于同一具体事件的直接进展，例如发布后的上架、评测或回应
• UNRELATED：不同的事，即使主体、产品或话题相同
• ROUNDUP：其中一方是包含多个话题的汇总

这个四分类的划分是关键。“同一件事"和"同一件事的后续进展"被分开，意味着事件可以从"一次发生"延伸成"一条时间线”——事件页有综述，后续进展挂在同一个事件下，进展和报道时间线可以一起切换"最新在前"或"最早在前"。

判定之后还有一道复核。 拿不准的合并会写入前再让模型复核一遍，而且复核可以单独换一家模型（环境变量 GROUP_REVIEW_MODEL）。这又是一个很实在的取舍：判定阶段用便宜模型跑全量，复核阶段用更好的模型只处理模糊边界——用模型的"第二意见"处理高不确定性样本，而不是对全量样本上最贵的模型。

热度算法则是彻底地"按事件算，不按文章算"：

48 小时内，每个独立来源只算一次；24 小时减半。

三行规则，但把聚合站最容易翻车的地方堵死了。一家媒体发十篇只算一次——所以刷稿不会推高排名；重复抓取不会多算——所以调度系统重跑是安全的、幂等的；48 小时窗口 + 24 小时衰减——所以榜上的是"最近还热的事"，不是"历史总曝光最高的文章"。再叠加"和 6 小时前比，涨得快的标上升，新出现的标『新』"，一个完整的热度榜就成型了，而全程不需要任何"热度模型"训练——规则显式、可解释、可被质疑。

这套归组逻辑也配套了评测：scripts/eval-relations.ts 让你用成对标注样本（两篇报道 + 正确关系标签）评测模型，输出 4×4 混淆矩阵、每类关系的查准率/查全率/F1、以及在不同置信度门槛下"把 SAME_OCCURRENCE 和 SAME_STORY 都算作连进同一事件"的完整曲线。关系的提示词改了，直接能看到矩阵怎么变。

技术亮点三：为"会花钱、会失败"的 LLM 流水线设计的可靠性约束

这部分是我认为最被低估的，也是它跟"周末玩具项目"的分界线。AIHOT 的架构文档里写死了几条规则，每条都指向一个具体的现实故障。

规则一：花钱的请求有回执。 每个付费请求（模型、X API、公众号、Jina）先记一张回执，拿到结果先存再用。意义是：进程重启、任务重试时，复用已经付过钱的结果，不重复花钱。结果不明的回执超过 30 分钟后自动放行一次；因它停在失败状态的文章会重新入队，继续未完成的正文提取或分析。这本质上是为不可靠的外部调用做了一次持久化的幂等——比常见的"重试三次"要严谨得多，因为 LLM 调用的重试代价是真金白银。

规则二：预算熔断。 每个付费服务有每分钟、每小时、每天的上限，超过就暂停。配合"每一步单独换模型"，可以用便宜模型跑预筛和日常摘要，把贵模型只留给评分与复核。

规则三：页面不调模型。 读者打开页面只读数据库里已经有的结果；模型只在 worker 的任务里调用。这条把"用户请求的响应时间"与"LLM 的响应时间"彻底解耦——也是它能做到 README 里那张性能图的原因（页面中位数 10ms、95% 在 50ms 内；接口中位数 6ms）。前端是 SSR，但数据是预计算的。

规则四：三个进程 + 一个公开读取层。 api（Fastify：站点接口、公开 API、RSS、MCP、分享图）、worker（pg-boss 队列与定时任务）、web（React Router SSR，只通过 HTTP 读 api，不碰数据库）。网页、RSS、API、MCP、站点地图、分享图读的都是同一个 packages/backend/src/publication/——公开范围与事实证据条件只在一个文件里定义，新增出口自动继承现有的撤回与全文许可规则。这是典型的"单一读写边界"设计：出口数量增加不会带来规则分叉。

规则五：“安全阀"只决定发不发，不决定走哪套逻辑。 COLLECT_ENABLED、MODEL_CALLS_ENABLED 这类开关只有设成 true 才打开，没写就是关；测试里推送一直关着，采集和模型调用只连本地假服务。开关不改变控制流，只改变副作用是否发出——这样测试覆盖的路径和线上是同一条。

顺带一提数据库迁移的约定：从 0055 起，每个迁移文件只放一条允许在线执行的语句，编号相同的不同文件分别执行，同一完整文件名不能出现在两个目录中。加列优先可空或常量默认值；加 CHECK、外键先 NOT VALID 再另起迁移验证；索引用单独的 CREATE INDEX CONCURRENTLY IF NOT EXISTS；不允许在发布迁移里做大批 UPDATE/DELETE。这些规则由 PR 检查强制执行。 一个不到三周的项目把在线 DDL 的纪律做到这个程度，是相当罕见的。

它还能做什么

除了上面的核心，工程完整度也值得一提：

• 六种信源：RSS、网页列表、JSON 接口、X 账号、微信公众号，以及自己脚本推送。信源分三级，抓取频率按产出自动调整
• 给 Agent 用：RSS（精选/全部/全文/日报/周报/月报）、公开 API（/openapi-v1.json）、MCP、Agent Markdown、llms.txt——同一份内容给人看也给 Agent 用；仓库里还自带 AGENTS.md
• 三种刊期：日报每天 08:00（按规则编排，不调用模型——一件事一条，报过的事只在有新进展时跟进）；周报周一 10:00、月报每月 1 日（从日报汇编，模型只写总述和栏目导读，不增删条目）
• 反幻觉护栏：周报/月报里模型写出的名字或数字，如果条目里没有，这段话直接不用——总述换成模板生成的一句，栏目不放导读。规则很朴素，但比"提示词里写『不要编造』“可靠得多
• 模块系统：只属于你这个站的功能做成 modules/<名字>/ 独立 npm 包，有自己的后端、页面、迁移和测试；框架代码不导入任何模块，只读清单——所以合并上游更新时不容易和自己的功能冲突
• 后台：信源管理与试抓、内容诊断与人工评分更正、精选评测（SelectBench）、每一步单独换模型、付费请求上限、运行记录与告警

优点与注意事项

优点

• 全流程可解释：30 份提示词原文 + 显式门槛 + 完整校准工具链，“为什么选它"能回答到底
• 两次评分 / 分级门槛 / 事件级热度三个设计各自独立成立，且都能被数据校准
• 可靠性约束扎实：回执幂等、预算熔断、读路径不调模型、单一公开读取层
• 迁移纪律与模块边界有 PR 检查兜底，不是写在文档里的愿望
• 部署门槛低：Docker Compose 一条命令起来，用 OpenAI 兼容的任意模型 API（DeepSeek、千问、智谱都行）
• 文档密度高：docs/ 下从信源配置到归组评测、部署、成本估算都有

注意事项

• 它是"AIHOT 的引擎"而不是通用框架：作者明确说了同步时直接从线上导出，不保证每次同步；模型榜、主题页大事记等只对 AI 行业有意义的功能只留在线上站
• 信源和运营数据要自己补：仓库只带 18 个公开海外 AI 资讯源做示范，真正的信源得换成你行业的
• 换行业要重新校准：默认门槛（T1:60 / T1_5:65 / T2:76）是 AI 领域一直在用的一组偏严的数，作者明确要求换行业后按 eval-selection.ts 重新标样本、跑评测再上线
• 成本取决于你自己的模型选择：两级评分 + 归组复核 + 文案生成会持续产生调用，好在有回执复用和预算熔断，README 的部署文档里有费用讨论
• 作者的自我说明很实在：“一定还有写得不好的地方”；Issue 数量不多不代表代码没有粗糙处
• 需要 Node.js 24 + PostgreSQL 17 + Docker；没有 Docker 时也可在 Linux/macOS 直接跑（Windows 走 WSL2）

适合谁

• 想给自己行业做一个热点站，但不想从零写采集/去重/聚簇/刊期这套基础设施的人
• 做 LLM 应用工程的同学：这是一份难得的"生产级 LLM 流水线"参考样本，尤其是回执幂等、预算熔断、两级模型复核、产出物反幻觉校验这几个模式
• 关心内容策展与推荐系统的工程师：把"推荐"从模型黑盒改写成显式规则 + 可评测提示词，这条路值得看
• 需要自托管、数据不出门的团队：整站跑在自己机器上，读者的收藏与已读只存在浏览器里
• 已经在维护 Newsletter / 行业日报、想把流程自动化的人

项目地址

GitHub：https://github.com/KKKKhazix/AIHOT

线上原站（同款引擎跑出来的效果）：https://aihot.news

文档入口：docs/customize.md（改成你的行业）、docs/selection.md（精选与校准）、docs/grouping.md（归组与关系评测）、docs/architecture.md（架构与不变的规则）。

一句话总结：AIHOT 把"一个 AI 热点站是怎么选新闻的"完整摊开给你看了——包括那 30 份提示词和那行门槛代码。在这个到处都是黑盒推荐的年代，愿意把标准开源出来，本身就是一种技术态度。