AIHOT 开源 AI 热点日报怎么搭建？自动抓取 GitHub、AI 新闻、生成摘要与部署成本

页面启动了，却没有新内容；或者摘要看起来流畅，点回原文却对不上。
最快解法：先按官方流程完成 AIHOT 部署，再用一小批可核验的内容检查信源、模型接口和成刊链路，最后按真实调用量核算运行成本。

适合想自托管 AIHOT 的个人开发者：你可以核对模型配置、启动步骤和首轮验收方式。
适合准备改造成行业热点站的技术团队：你需要审定信源、精选标准和行业提示词。
适合负责内部技术日报的工程师：你需要验证采集、去重、摘要和定时发布是否可靠。

最后更新于 2026 年 9 月 30 日，部署信息核实自 AIHOT 官方仓库 README、部署与定制文档。仓库内容和依赖可能继续变化，动手前请再对照当前版本；本文不把示范信源或项目介绍中的线上表现当作你的部署结果。(AIHOT 官方仓库)

先按使用场景选启动路径

AIHOT 的关键不是首页能打开，而是从来源到日报的链路能否按你的用途持续工作。项目处理流程包含采集、预筛、评分、摘要写作、事件归组和日报生成；任一环节都可能让内容漏掉、重复或失真。

你的场景	先做什么	验收重点
个人开发者试跑	用示范配置启动站点，不急着改提示词	首页能访问、后台可登录、出现首批内容
行业团队改造	先列出行业一手来源，再改分类、标签和筛选标准	来源覆盖目标领域，误选和漏选可复核
内部日报运维	对照任务运行记录检查采集、摘要和发布	来源故障能发现，模型异常有记录，内容可追溯

官方部署文档提供 Docker 启动路径，包括克隆仓库、生成环境变量，再运行 docker compose up -d --build。首次启动会导入示范来源；文档中的首批内容处理时间只是项目环境描述，不是对你的服务器、模型响应或信源可用性的保证。(Docker 部署文档)

第一步：跑通模型接口与网站

从模型配置到网站启动，先核对哪些内容？准备 Docker 环境和一个兼容 OpenAI 接口格式的模型 API，再按当前仓库说明生成或填写 .env。基础配置涉及 LLM_BASE_URL、LLM_API_KEY 与 LLM_MODEL；示例还列出按步骤分别指定模型的配置，具体字段以你检出的版本为准。(环境变量示例)

建议按以下里程碑推进：

检查仓库和运行前提。阅读当前 README 与部署文档，确认 Docker Compose、模型服务地址和网络出口可用。不要先改来源文件，否则启动失败时很难分辨是环境问题还是定制错误。
生成并保护环境变量。按说明运行初始化脚本，或复制环境变量示例后自行填写密钥。把管理员密码、会话密钥和模型 API 密钥放在服务器环境中，不要提交到代码仓库或发在公开日志里。
启动服务并检查容器。执行仓库提供的 Compose 启动命令，查看 api、worker、web 与数据库相关服务状态。若页面打不开，先检查容器日志、端口映射和模型 API 连通性。
验证本地访问和后台。打开本地地址检查首页，再进入 /admin。首次登录后确认管理员凭据已妥善保存；不要因为后台可访问就直接把管理入口暴露给公网。
等首批内容处理后抽样。挑选几条站点展示的内容，分别打开原文，检查原始标题、来源归因、摘要事实和发布时间是否对应。若文章没有进入列表，先查来源抓取记录，再看预筛与评分结果。
跑完回归检查再改配置。修改行业分类或提示词后，按项目文档运行类型检查、测试和冒烟测试，并重新查看首页、日报和信源后台。

检查项	可观察证据	不通过时先查
页面和服务	首页能加载，服务日志没有持续报错	容器状态、端口、反向代理
模型接口	处理任务有完成记录，输出符合预期	API 地址、密钥、模型名、额度
来源采集	后台能看到试抓结果与近期条目	来源地址、解析配置、网络访问
内容成刊	原文、标题、摘要、分类彼此对应	过滤规则、提示词、事件归组结果

提醒：仓库默认示例是用来帮助你看懂流程，不代表你的目标领域已有合适来源，也不代表每个示例来源在你的服务器网络环境中都能抓取成功。

第二步：换来源前先定内容边界

示范信源能否调整为其他行业来源？可以。官方定制说明将行业配置集中在 industry/ 目录，涵盖来源、分类与标签、主题以及精选提示词；但“技术上能换”不等于“换完就可信”。来源质量、入选边界和行业术语应由熟悉目标领域的人审核。(行业定制文档)

信源文档列出 RSS、网页列表、JSON 接口、社交账号、公众号和外部推送等类型。不同类型可能需要选择器、第三方采集凭据或自建推送脚本；付费来源会增加外部服务账单，且来源可访问不代表你有权在站内展示全文。(信源类型说明)

改造对象	你需要审定的内容	常见返工原因
信源	是否一手、是否稳定、内容是否属于目标行业	来源重复、页面结构变化、缺少关键机构
精选规则	什么值得进入日报，什么属于噪声	直接沿用示范行业的判断标准
归类与标签	分类定义、别名、行业实体	标签边界不清，模型混淆相近概念
展示与引用	摘要范围、原文链接、全文授权	把“抓得到”误当成“可全文转载”

把改造分成“先能抓，再选得准”。先用后台试抓确认来源解析；随后由行业人员审阅原文样本，调整预筛和评分提示词。官方校准文档建议用人工标注的样本评估精选结果；样本应代表真实业务，而不是只挑明显正确或明显错误的内容。(精选校准文档)

第三步：用内容链路验收日报

怎样判断采集结果和摘要值得发布？不要只看日报是否按时出现。按“原文—采集记录—筛选结果—摘要—事件归组—发布页”逐层抽查，才能定位是来源解析、筛选门槛还是模型输出导致的问题。

采集：检查后台来源状态和最近抓取的条目。确认标题、原文地址、发布时间不是空值，也没有把旧内容误认作当天新消息。
去重：选取同一事件的多条报道，检查重复内容是否合并；同时确认后续进展没有被错误并入旧事件。
筛选：挑选应入选和不应入选的样本，查看筛选理由是否符合行业规则。若边界不一致，先调整规则并复测，不要仅靠人工删除首页结果。
摘要：将标题、摘要中的机构、数字和结论逐项对照原文。摘要若添加原文没有的因果关系或判断，应先暂停自动发布并修订提示词。
发布：检查日报的分类、来源链接和事件归属，再确认首页和日报展示的内容一致。

事件归组尤其值得单独验收：同一新闻的不同报道应尽量集中，但报道的后续进展不应被误当成完全相同的内容。官方文档介绍了关系判断和评测方式，可将人工核对过的事件对作为回归样本。(事件归组文档)

第四步：把日常故障和费用放进预算

AIHOT 持续运行并非只有服务器托管费。模型调用受新内容数量、筛选和摘要步骤影响；信源可能需要付费采集服务；数据库、图片等数据需要存储与备份；日志检查、规则校准和故障处理也会占用维护时间。官方部署说明提及模型调用、按请求计费的采集服务和预算限制，但没有可直接套用于每个使用者的固定总价。

预算表应包含哪些支出项？把账拆成“固定支出、按量支出、人力投入”，用你自己的账单和运行记录填数，不要用项目介绍里的示范数据推算生产月费。

成本项	记录方法	主要变量
模型 API	按处理步骤记录调用量与账单	新增资料数、筛选比例、摘要与归组任务
服务器托管	按实际账单记录	服务规模、运行时长、网络与磁盘资源
采集服务	单独统计各服务的请求与费用	来源类型、抓取频率、失败重试
存储与带宽	看主机及对象存储账单	数据保留期、图片缓存、访问流量
维护时间	记录排查、更新、校准耗时	来源变更、摘要纠错、备份恢复演练

把实际的每日来源条目数、模型调用次数、失败重试和账单放在同一张记录表里，再决定是否扩大来源。官方文档中的示范导入调用量属于项目环境数据，只能说明处理链路会触发多种模型任务，不能直接当作你的模型费用或日常成本。

按条件决定扩容还是回退

若示范来源能稳定采集、原文与摘要可对应，且后台日志可追溯，则进入行业定制；否则先修好网络、解析配置和模型接口，不要先扩来源。
若领域人员认可筛选样本，且重复事件和后续进展的归组符合预期，则小范围试发日报；否则继续校准分类、门槛与提示词。
若一段实际运行记录已覆盖模型、托管、采集、存储和维护投入，则据此评估长期运行；否则保持小规模试跑，避免按宣传指标或假设账单扩容。
若需要持续对外服务且已有备份、访问控制和告警流程，则再部署公网；否则先限定访问范围并补齐运维措施。

上线前还要分别确认后台访问限制、密钥管理、数据库备份和监控告警。仓库提供服务与运行日志等能力，不意味着你的公网权限、备份策略和恢复流程已自动设置完成；按部署文档检查日志、数据卷和备份方式，并实际验证恢复路径。

如果你的方案目前是单台云服务器，它适合持续运行网站，但你仍要承担系统更新、密钥保护、数据备份和故障排查；若在个人电脑上试跑，则长期开机、网络可达性和多人访问也会成为限制。Mac 更适合承担开发、构建和 macOS 兼容性验证，不宜在没有运维设计时直接替代生产环境的长期服务主机。需要临时测试 Mac 环境时，可以先比较 Kvmkit 的 Mac mini 方案与价格；正式部署仍应按 AIHOT 的服务架构、账单和恢复要求选择托管方式。正在规划临时测试或云端资源的团队，也可先通过 Kvmkit 帮助中心了解环境使用事项，再决定是否租用。