做AIHOT这个项目起因其实特别朴素我每天都在各个信息源之间来回切换看新闻、逛论坛、刷GitHub Trending就为了整理一份和自己行业相关的热点日报。刚开始手动整理还觉得挺有成就感时间一长就烦了——找到的总是那几家头部媒体的内容真正有价值的行业动态经常被淹没在海量推送里等发现的时候已经晚了。后来我就在想一件事大模型能做摘要、能分类、能写代码那它能不能把“找热点”和“写日报”这套流程也接过去AIHOT就是这么跑出来的。它是一个开源的行业热点站构建工具核心逻辑很简单定时抓取多个数据源先用规则过滤掉明显无关的信息再用大模型做行业相关性判断和热点聚类最后把它按模板生成一份可以直接对外发布的日报渲染成一个静态站点。这篇文章会把这个项目的思路拆开来讲为什么要自己搭而不是用现成工具、数据源怎么选、大模型怎么接入最省钱、提示词怎么写日报才不像流水账、开源发布的时候有哪些坑。如果你也在做类似的内容自动化项目或者想用大模型替代一部分重复劳动这些踩坑过程应该能帮你省不少时间。1. 什么情况下值得自己搭一个热点站1.1 通用热榜解决不了“行业粒度”的问题微博热搜、百度热榜这类产品解决的是“全网在关心什么”的问题而不是“我所在行业正在发生什么”。这两个问题的答案很多时候完全不一样。一个对于AI行业非常重要的技术发布、论文更新或者开源仓库在全网热度榜上可能根本排不上号而那些排在前面的话题对你所在赛道来说又往往是无效噪音。我最早也想过直接用热榜API做数据源实测后放弃了。原因有两个一是热榜的排序逻辑和行业相关性没有任何关系二是热榜对“久远信息”的重复展示特别严重同一个热点挂一整天对日报来说信息增益几乎为零。真正好用的数据源应该是RSS、GitHub Trending、arXiv、垂直社区热帖这类“还在流动”的信息而不是平台编辑推荐出来的结果。1.2 日报整理这件事重复劳动比例太高手动整理日报的流程我从去年开始做了大半年每个工作日大概要花40到60分钟。这中间真正需要人做判断的部分其实很少信息采集是重复的摘要提炼是重复的排版整理也是重复的。我真正的价值只在最后一步——判断哪些信息值得写进去哪些不值得。这种工作形态天然适合拆成“机器做粗加工人做精审核”。粗加工的部分就是抓取、过滤、去重、摘要素这些规则可以写死在代码里精审核的部分就是看几段摘要、点几个链接每天十分钟足够。AIHOT做的事情本质上就是把粗加工环节自动化让人的时间只花在最后一道关上。1.3 通用资讯工具无法沉淀成“站点资产”还有一点是我比较在意的用公众号、邮件简报、第三方资讯App去分发日报内容发完就沉底了既不能搜索也不能按日期归档。但我把日报做成站点之后就完全不一样了——每天一份按日期归档带原始链接带标签分类时间长了就是一个结构化的行业资料库。后续想基于这些历史数据做趋势分析、做热点回溯都非常方便。所以AIHOT从一开始就定了一个原则日报不只是“发出去”而是要“沉淀下来”。这也是我把项目开源的原因之一——这种“自动化采集大模型生成静态站点沉淀”的模式换个行业、换组关键词就能复用没有理由只锁在自己的项目里。2. 整体方案选型一条可控的自动化流水线2.1 四层架构各司其职AIHOT的整体架构被我拆成了四层每一层只干一件事采集层、过滤层、生成层、展示层。采集层负责从各种数据源拉取原始信息包括RSS、公开API、GitHub Trending页面等统一解析成标准格式的条目写进本地数据库。过滤层做的第一道关是规则过滤用关键词黑名单、域名黑名单、热度阈值把明显无关的内容筛掉同时做简单的去重聚类把同一事件的多篇报道合并成一条候选热点。生成层接入大模型对候选条目做行业相关性打分和排序然后按日报模板生成最终内容。展示层则把生成的日报渲染成网页支持按日期归档和标签筛选。这样分层的好处是每一层都可以独立替换。比如你觉得RSS不够用可以只改采集层你觉得当前的大模型效果不好可以只改生成层的调用参数完全不用动其他模块。对开源项目来说这种可替换性尤其重要——别人拿过去用的时候能改的部分越明确上手就越快。2.2 为什么把大模型调用放在链路靠后的位置这是整个项目里最关键的一个设计决策我得啰嗦两句。很多人在做类似工具时习惯“先让大模型看一遍所有内容”实测下来这个方案既贵又慢。假设每天抓取2000条原始信息全部发给大模型做分析一次调用的输入就在20万token以上成本会完全失控。AIHOT的做法是把成本高的大模型调用放在规则过滤之后。规则过滤先把2000条压到200条左右大模型只处理这200条候选内容做相关性判断和热点排序。这一步的量级直接降了一个数量级但准确率并没有明显下降——因为被规则过滤掉的绝大多数内容本身就不需要模型来理解。用人话说就是能靠正则和关键词解决的事别让大模型花钱。2.3 数据流设计上的两个小细节第一个细节是“所有中间产物都可重放”。采集结果、过滤结果、候选列表都会落盘也就是说任何一个环节改完配置之后不需要重新抓取就能用历史数据验证效果。这个设计在你反复调提示词的时候尤其好用省掉了大量等数据源刷新时间。第二个细节是“生成内容永远从结构化数据出发”。日报不是让大模型凭空写的而是先把候选条目整理成结构化数据标题、链接、来源、发布时间、摘要再喂给大模型。这样生成的日报内容有据可查、有链可点出现幻觉的风险会低很多。这个原则后来也被我用到了其他LLM项目里效果一直很稳。3. 大模型选型API调用还是本地部署怎么取舍3.1 生成日报的模型能力要求AIHOT对大模型的能力要求其实并不极端核心是三点指令遵循能力好、JSON输出稳定、中文表达自然。日报生成这类任务不需要多强的逻辑推理但要能严格按模板输出不能缺字段、不能随意发挥。所以我在选型时更看重主流的商用API和成熟的开源模型而不是追求跑分最高的“大块头”模型。实测下来以qwen-plus、glm-4-flash这一档次的模型已经完全够用。它们在JSON模式下的输出稳定性很好中文日报写得也自然。极端情况下如果你手头有更强的模型比如deepseek-v3或qwen-max输出质量会更好但对应token成本也高一些——对日报这种低频任务来说没必要上最强模型够用就行。3.2 云端API和本地部署的对比接入方式上AIHOT同时兼容两种直接调用云端API或者通过Ollama这类工具在本地起一个API服务。两条路我实际都跑过各自有清晰的适用场景。云端API的优势是零运维、即时可用按token计费适合个人项目和日访问量不大的站点。本地部署的优势是数据不出内网、长期批量调用没有边际成本但需要准备GPU资源模型显存占用和推理速度都要考虑。我的建议很简单如果你的机器没有独立GPU优先用云端API没必要花几千块钱买显卡就为了跑一天一次的热点摘要。好在AIHOT用的是OpenAI兼容接口切换成本非常低。改一个base_url和model名就行代码不用动。本地部署就指向http://localhost:11434/v1云端就用对应的服务商地址。另外如果你已经在用Dify这类LLM应用编排平台AIHOT的生成环节也可以作为一个工作流节点接入不用自己维护一套客户端逻辑。3.3 一天要花多少钱成本估算过程成本问题可能是很多人最关心的我直接给出我的实测估算。假设一天抓取1600条原始信息规则过滤后剩下180条候选大模型只需要处理这180条每条输入大概300到500token含标题、摘要、来源信息行业相关性判断加排序的输出控制在50token左右。那么日常处理消耗大约在8万到10万token。按目前主流商用API每百万token几块钱到十几块钱的定价区间大概是一条日报几毛钱到一块多。日报生成再调用一次把结构化候选数据整理成1500到2500字的日报输入输出加起来不到1万token成本可以忽略。也就是说AIHOT一个月的运行成本大致可以做到两位数以内而且还是在公开API不搞活动的情况下。控制成本的核心就是前面说的能省的地方省只把最少的token花在最关键的问题上。3.4 大模型微调有必要吗我也顺带说一下微调。有朋友问过我日报生成的效果不够理想是不是微调一个模型会更好我的看法是除非你有很强的风格需求否则没必要一开始就微调。通用模型的zero-shot能力已经足够覆盖日报生成场景通过优化提示词和结构化输入效果提升会非常明显。等到你真的积累了一批人工校正过的历史日报样本再考虑用LoRA做一次轻量微调才是性价比最高的路径。4. 热点抓取与内容过滤怎样把全网信息提纯成行业热点4.1 数据源的选型原则数据源是整个热点站的地基这里我踩过不少坑说说我最终沉淀下来的选择标准。第一优先级是官方公开API和标准RSS。大多数科技媒体和技术博客都提供RSS解析稳定、格式统一、无需额外维护。GitHub Trending虽然不提供官方API但通过页面解析也能拿到热门仓库列表一天拉一次频率完全可控。arXiv这类学术平台有标准API按分类查询非常方便适合做前沿技术趋势的补充源。第二优先级才是爬虫。爬虫不是不能用但对目标站点的改动敏感稍有改版就得修代码还涉及robots协议和访问频率问题维护成本比较高。我的建议是能用RSS绝不用爬虫能走API绝不用页面解析。具体到AI行业我的默认数据源组合是头部AI媒体的RSS、arXiv的AI分类、GitHub Trending、Hacker News的科技热帖再加几个垂直社区的技术板块。这套组合兼顾了时效性、专业度和覆盖面。如果你想换一个行业只需要替换数据源配置和关键词架构不用做任何改动——这也是我把项目做开源的底气所在。4.2 三层过滤规则、信号、模型采集层的原始内容很杂不能直接交给大模型也不能直接上日报。我设计了三级过滤。第一级是硬规则过滤。维护一个关键词黑名单和一个域名黑名单把广告、带货、八卦、抽奖之类的内容直接扔掉同时做基础的数据清洗去掉无效链接、空内容、重复标题。第二级是热度信号打分。给每个数据源设置权重比如头部媒体3分、普通技术博客2分、论坛热帖按热度比例折算再结合标题中是否命中行业关键词给出附加分。算出一个基础热度分之后设定一个最低阈值低于阈值的直接淘汰。第三级才是大模型相关性判断。经过前两级过滤,剩下的候选数量已经很小交给大模型判断“这条是否属于目标行业”以及“如果属于它的重要程度是1到5的几档”。这样做的成本很低但准确率比纯粹的规则过滤高很多因为它能理解语义——比如一条讲GPU集群调度的新闻如果没有GPU这个关键词规则过滤可能会漏掉但模型能判断出来。4.3 去重聚类让日报不再“刷屏”去重是我最初忽略、后来被用户吐槽最多的一个点。同一件行业大事可能同时被五六个数据源报道如果不做合并日报就会变成几条看似不同的重复内容体验非常差。我的解决方案是两阶段去重。先做归一化把标题转小写、去掉特殊符号和多余空格计算简单相似度超过阈值比如0.85就认为是同一事件。这一步能合并标题几乎一样的重复条目。再从同一事件聚类里挑出权威来源的一篇作为主稿其余条目标记为引用。实测下来这个简单方案能合并掉80%以上的重复内容对日报的阅读体验提升非常明显。4.4 时效性的处理热点这个词本身就带着时效压力。我在做AIHOT时把“当日热点”严格限定为最近24小时内的条目超过这个时间窗的自动降权避免日报里堆积旧闻。另外要注意时区问题——不同数据源的发布时间格式和时区不一样统一转换成北京时间再入库否则零点前后的数据归属会有bug。这个问题虽然不起眼但真的要跑起来才会发现有多烦人。5. 日报生成提示词模板与结构化输出的协作流程5.1 日报内容结构怎么设计日报做给谁看、解决什么问题决定了它的内容结构。我给AIHOT设计的日报分四个板块第一个板块是“今日核心热点”选出最重要的5到8条每条包含标题、一句话摘要、来源链接、热度分级。这个板块的目标是让人30秒掌握今天最重要的动态。第二个板块是“值得关注”收录重要程度稍弱但仍然有信息量的条目只有标题和链接保持日报的轻量感。第三个板块是“数据观察”统计当天的采集总数、过滤率、热点赛道分布这个板块的价值在于从数据层面反映行业注意力流向。第四个板块是“延伸阅读”放长文、论文、仓库、深度报道专门给愿意花时间深挖的读者。这个结构看起来不复杂但要让大模型稳定输出靠的不是“让它自由发挥”而是给它一个严格的JSON格式模板。5.2 提示词设计从“写作文”变成“填表格”日报生成的提示词我调整了大概十几版最后沉淀下来几个核心经验。第一角色和任务要说清楚。开头就要告诉模型“你是XX行业的情报分析师任务是把候选条目整理成日报而不是自己编写新内容”。这能明显降低模型自由发挥的概率。第二输入必须是结构化数据不是原文粘贴。我先把候选条目预处理成表格形式每条有编号、标题、来源、链接、摘要、热度分模型只需要选择、排序、改写不需要理解一大段原始文本。第三输出必须严格按JSON格式并给一个few-shot示例。在示例里明确展示“什么该输出、什么不该输出”比在文本里解释一百遍都管用。一个简化版的提示词骨架大概是这样的你是一名AI行业情报分析师。下面是过去24小时内筛选出的候选热点条目每条包含id、标题、来源、摘要、热度分。 请按以下步骤处理 1. 删除明显重复的条目 2. 按重要程度从高到低排序 3. 结果输出为JSON数组每项包含title、summary、source、url、heat。 要求 - 只输出JSON不要输出任何解释性文字 - summary控制在80~120字务必基于输入内容改写禁止编造 - 只选出最值得关注的前8条。 候选条目 [结构化候选数据] 示例输出 [{title: ..., summary: ..., source: ..., url: ..., heat: 5}]5.3 两步生成策略先抽取再成文我最早图省事直接把候选条目和提示词一起丢给大模型让它一步生成日报。结果发现两个问题一是长输入容易让模型注意力分散二是模型写出来的summary时而精炼时而啰嗦风格不稳定。后来改成两步生成。第一步是信息抽取对每条候选分别调用模型抽取出标题、核心事件、涉及主体、影响面这几个要素输出成干净的JSON。第二步才是日报生成把抽取后的结构化数据统一喂给模型让它做排序、合并、改写。两步分开之后生成质量明显提升因为第一步只需要“理解”第二步只需要“写作”任务边界清晰模型不容易两头都做不好。代价是调用次数变多但因为候选条目本来就少多出来的token成本完全可以接受。这也是为什么我一直强调不要把LLM任务设计成一个大而全的prompt拆开来反而更省、更稳。5.4 生成结果的校验与兜底大模型输出再稳定也偶尔会有JSON解析失败、字段缺失、长度超限的情况。我的处理方式是在生成之后加一道校验层先检查JSON能不能解析再检查每个字段是否齐全最后校验URL格式和长度。校验不通过就自动重试一次如果第二次还是失败就把这条降级为普通文本条目绝不阻塞整份日报的生成。另外我强烈建议在“自动生成”和“对外发布”之间加一个审核入口。生成好的日报先落在草稿目录而不是直接渲染上线。你可以每天早上花几分钟扫一眼删掉误报、改改措辞再发布。如果你对自动化程度要求很高至少也要加一层关键词屏蔽和超链接检查防止生成内容里有不可控的链接。5.5 展示层的实现展示层我选的是静态站点方案。每天生成一份Markdown或JSON格式的日报然后用模板渲染成静态HTML推到GitHub Pages或者任意一台轻量服务器上。静态方案的好处是几乎没有维护成本和被攻击风险访问量再小也不会崩。页面布局走简洁路线首页展示最新一天日报按日期归档每条热点标题带原始链接。标签系统按赛道归拢比如“模型”“开源”“硬件”“数据集”方便读者按兴趣筛选。整个展示层没有做复杂交互因为热点站的核心价值是内容本身而不是花哨的页面效果。6. 落地部署与开源发布从本地脚本到人人可用的项目6.1 部署方式Cron定时任务加静态托管AIHOT的部署非常简单因为它本质上是一个定时任务加一个静态页面生成器。我在服务器上用Cron做定时调度每天早晨执行采集和生成任务结束后自动推送静态站点文件到托管平台。0 7 * * * cd /opt/aihot python -m aihot.crawl logs/crawl.log 21 30 8 * * * cd /opt/aihot python -m aihot.generate logs/generate.log 21 45 8 * * * cd /opt/aihot python -m aihot.deploy logs/deploy.log 21数据库我用的是SQLite单文件、零运维对热点站这种量的数据绰绰有余。如果你对稳定性要求更高可以用Docker Compose把采集、生成、展示打包成三个容器但就我的实际使用体验来说个人热点站完全没必要上这么重的方案Cron加SQLite加GitHub Pages已经跑了好几个月没出过问题。6.2 开源协议怎么选项目开源之后经常被问到的一个问题就是“Gitee/GitHub上开源许可证该选什么”。我的建议很简单工具类项目首选MIT或者Apache-2.0这两个协议都是宽松型的别人拿去用、改、商用都不需要额外跟你打招呼最有利于项目被广泛使用和传播。如果你特别在意“别人改了你的代码也必须开源”这件事可以选GPL-3.0它会强制衍生项目也采用相同协议开源。但对AIHOT这种工具型项目来说强约束协议可能会劝退一部分潜在使用者反而限制了社区发展。我的选择是MIT尽量降低别人使用的门槛让代码自己说话。另外建议在仓库里加入CONTRIBUTING文档和issue模板方便社区参与贡献。6.3 开源仓库文档怎么组织代码写得再好如果README乱七八糟别人也很难用起来。我在整理AIHOT仓库文档时遵循一个原则让一个陌生人在5分钟内能跑通最小流程。README里放了三个东西项目定位和效果截图放在最前面一张图说清楚它解决了什么问题然后是快速开始部分从拉取代码到生成第一份日报只保留必要步骤最后是配置说明把数据源、模型参数、提示词模板、部署方式用表格列清楚。示例配置和数据文件也放在仓库里别人改完配置不用等抓取直接拿示例数据就能看到效果。开源项目能不能被人用起来往往就取决于这种细节。6.4 后续可以怎么扩展AIHOT运行一段时间后历史数据会积累成一个小型行业语料库。基于这些数据可以做很多有意思的事情。比如热点趋势分析连续多天出现在候选列表里的话题热度是在上升还是下降比如来源质量评估哪个数据源的采纳率最高、哪个数据源经常带来噪音甚至可以做一个“本周行业焦点”的周报把七天日报聚合再生成一份更宏观的观察。这些扩展方向都不需要改动底层架构只需要在现有数据之上加分析逻辑。这也是分层架构带来的长期价值——当你想加新功能时不需要重构旧代码。7. 实操踩坑记录最容易翻车的六个问题7.1 数据源失效与降级数据源是最不稳定的环节。RSS地址说改就改API说加鉴权就加鉴权爬虫页面过几天就换结构。我遇到最夸张的一次一个星期内三个数据源同时失效日报差点断更。后来我加了一个数据源健康检查每次采集后记录各源的条目数量连续三次为零就告警同时在采集层做降级——一个源失败不影响其他源不会因为单点故障导致整条流水线停摆。7.2 大模型输出不稳定的JSON这个问题在早期几乎每天遇到。大模型偶尔会在JSON前后加解释性文字、用中文标点、或者丢掉某个字段。我的对策是多管齐下提示词里明确要求“只输出JSON”同时开启API的JSON模式或强制输出格式再加上解析失败自动重试的兜底。三个措施叠加之后JSON解析失败率基本降到1%以下可以忽略不计了。7.3 重复内容的聚合处理前面讲过去重这一关不做日报会变得非常“水”。除了用相似度算法合并明显重复的标题还要小心“同一事件的不同角度报道”——标题完全不同但讲的是同一件事。对于这类内容纯规则很难处理我会在日报生成的提示词里明确写“如果多条候选来自同一事件的连续报道只保留信息量最大的一条并在summary里合并时间线信息”。把语义级去重的任务交给大模型比写复杂的规则靠谱得多。7.4 token成本失控成本失控的根源只有一个让大模型处理了不该它处理的内容。我在项目早期就是把所有抓取内容一股脑丢给模型结果一天成本飙到几十块效果反而不好。后来严格按“规则先行、模型殿后”的思路先把数据量压下来再让模型介入成本降了九成效果还更稳定。这个经验后来也分享给好几个做类似项目的朋友大家都说管用。7.5 日报的时区陷阱“当日热点”的“当日”是按照哪个时区算的这个问题看起来简单处理起来全是坑。不同数据源的发布时间可能是UTC可能是东八区也可能是服务器本地时间入库时不统一零点前后就会出现错乱。我在项目里把所有时间统一转成UTC存储展示时才转成北京时间同时在做“24小时窗口”判断时以UTC为基准这才彻底解决了问题。7.6 大模型生成内容的真实性校验大模型写日报时偶尔会“脑补”一些链接或者数字尤其是在摘要里。这是LLM应用绕不开的问题。我的对策是严格限制生成范围提示词里反复强调“只能基于输入内容改写”同时对输出做一个超链接检查非白名单域名一律标记。对于日报里涉及的具体数字、论文编号、仓库名这类信息还会单独做规则校验。最终我还会人工过一遍草稿再发布。这套流程下来生成内容的事实性风险已经控制在可以接受的范围。问题出现原因解决办法数据源失效站点改版、API变更健康检查、自动降级、多渠道备份JSON解析失败模型输出不规范JSON模式、提示词约束、自动重试重复内容过多多源报道同一事件相似度去重大模型语义合并token成本飙升大模型处理了过多低质量数据规则先行、模型殿后压缩候选集时区错乱各源时间格式不统一统一UTC存储展示时转本地时区生成内容失真大模型幻觉结构化输入限制、链接校验、人工审核我在实际使用AIHOT过程中体会很深的一点是这类自动化工具体系里真正决定成败的不是某一个模型有多强而是整个链路的每一个环节是否稳定可靠。规则过滤、提示词设计、数据源维护、结果校验每一环都在用各自的方式降低风险。少了一环整体就会变得脆弱。最后还想分享一个小技巧不要追求“完全无人值守”。AIHOT每天生成的日报草稿我会花三到五分钟快速过一遍再发布这个习惯让内容质量始终保持在可控水平。自动化解决的是80%的重复劳动剩下20%的判断交给人才是最稳妥的。