我做产品拆解这几年有一个习惯不看首页有多好看看它每天几点更新、内容怎么来的、有没有人肉痕迹。AIHOT 进入我的视野是在它月活刚起来的那段时间我连续盯了差不多一个月越看越觉得有意思。表面看它是一个 AI 行业热点聚合站点进去是各类资讯卡片、话题榜、工具推荐但你仔细研究它的内容节奏和页面结构会发现它背后根本不是一支编辑团队在写稿而是一条几乎可以自己运转的情报流水线——采集、筛选、成稿、发布每个环节都自动完成。这篇文章不打算给 AIHOT 做背书我也拿不到它的内部架构。我只是从外部可观察的产品表现、内容更新规律和公开分享里把它拆开再结合自己过去一年搭相似系统的实际经验把这条“自出版流水线”的产品逻辑、技术方案和可复现做法完整讲一遍。如果你在运营行业资讯站、做 AI 工具产品或者想用 AI 构建一套自动内容管道这篇文章应该能帮你省掉不少弯路。1. 先判方向AIHOT 做的不是资讯是“情报消化”1.1 百万月活的源头到底是什么先说结论AIHOT 能跑到百万月活不是因为它内容数量多而是因为它把“读信息”这件事自动化了。我们过去获取行业信息是什么路径关注几十个公众号、刷几个社区、看 RSS、再加几个付费 info 群每天花两三个小时最后很可能还是漏掉重点。AIHOT 做的事情本质上是把这段路径压缩成一条流水线信息源还是那些信息源但“阅读 提炼 归纳 排序”全部交给 AI 完成用户打开页面看到的已经是加工好的情报成品。这个产品切中的是 AI 行业从业者极大的信息焦虑——不是材料不够而是没时间读。我再给你一个观察点AIHOT 的内容更新不是均匀分布的。我记录过它的更新时间集中在早上八点前后、中午十二点半、下午六点半左右半夜偶尔有补量。这个节奏非常像“定时任务驱动 人工兜底审核”的产物而不是一支实时追热点的编辑部。换句话说它用脚本定时唤醒流程把过去 4~6 小时的散点热点收集起来统一消化再发布。1.2 为什么“流程”比“内容”更值钱很多团队做内容产品第一反应是招小编、签作者、约稿这些动作本质上是在买“人的时间”。但 AIHOT 的模式完全不同它把内容生产抽象成了一个可重复执行的工作流每一次执行成本趋于零边际成本几乎全在算力和接口调用上。这才是它能保持高频更新同时不需要大规模扩充团队的核心原因。我可以给你算一笔账。假如一个内容平台每天更新 100 条行业情报用传统的人工方式需要至少三到四个编辑轮班一个人盯信息源一个人写摘要一个人排版发布一个月人力成本轻松过万。而流水线方式下一套成熟的采集应用加上大模型 API 调用单条内容的综合成本是几分钱级别一天 100 条的运行成本也就是几块钱到几十块钱取决于你用的模型档次和采集源的规模。当别人还在算人力 ROI 的时候流水线的成本优势已经不在同一个数量级了。但“流程比内容值钱”这句话得说透它值钱不是因为它省了钱而是因为它把内容生产从“经验驱动”变成了“参数驱动”。传统编辑死了内容质量会波动流水线不会只要你的提示词和筛选策略写好了输出质量永远在一条稳定的水位线上。2. 拆开流水线的四个核心环节这条自出版流水线不管外面包装成什么样内核拆出来就是四段采集、筛选、生成、发布。我一个个拆给你看。2.1 采集环节在信息源头撒网采集是整个流水线的地基。AIHOT 这类产品能稳定产出首先是因为它解决了“有东西可写”的问题。常见的信息源有三大类。第一类是开源 RSS 源比如 GitHub Trending、arXiv、Hacker News、Product Hunt这些站点都有相对稳定的输出格式直接订阅就行。第二类是垂直站点 API像少数派的资讯接口、各类技术媒体自己的开放接口只要对方不封你拿到的数据结构比抓网页干净得多。第三类是网页抓取针对那些没有 RSS 也没有 API 的平台用爬虫定时把页面拉下来再解析但这类源稳定性最差站点改版一次你的解析规则就得跟着改一次。我自己的经验是采集源宁可少而精不要多而杂。早期我搭情报系统时一口气接了 50 个源结果每天采集回来的原文有一大半是重复转载反而给后面的筛选环节造成了巨大的过滤压力。后来我把源砍到 20 个以内每个源先人工确认内容质量再写进配置里整体效果立刻提升了一个档次。2.2 筛选环节用 AI 替代“小编”做判断采集只是把原料拉到仓库真正拉开差距的是筛选环节。一条信息值不值得进入用户视野传统做法是编辑凭经验判断AI 时代这活可以全部交给模型。筛选规则一般分三层。第一层是硬性过滤用关键词黑名单把广告、低质内容、与 AI 无关的新闻直接踢掉第二层是结构化评分让模型给每条候选信息按“时效性、影响面、话题热度、与目标用户的相关度”四个维度打分第三层是去重根据标题和正文的语义相似度合并同类项避免同一个消息被翻来覆去讲三遍。AI Hot 这类产品在筛选上的一个显著特征是你几乎看不到“旧闻重发”。这说明它的流水线里对“新鲜度”是有硬性约束的。我后来在自己的系统里也加了一条规则发布时间超过 48 小时的信息除非是深度解读类内容否则直接降权。这一条规则让整个信息流的“当下感”立刻不一样了。2.3 生成环节把素材磨成可读的情报生成环节是流水线的“大脑”。采集回来的是原始信息筛选完的是候选列表到这里要变成用户能直接消费的成品——也就是情报摘要。这里的关键不是让 AI 写出多华丽的内容而是让它保持稳定。我给 AI 生成的指令永远固定那几个要素标题控制在 22 字以内正文先用一句话概括核心事实再用三句话补充背景和影响最后给出一个“值得关注”的理由。这套模板化的写法保证了无论今天采集到的是 OpenAI 的新模型发布还是某个开源项目的版本更新输出给读者的阅读体验都是统一的。AIHOT 的内容风格我特意看过它每张卡片都像一个结构化简报信息密度很高没有废话没有“震惊体”。这种风格不是模型天生的而是提示词约束出来的。后文我会把我的提示词拆给你看你会发现这一步其实一点都不玄。2.4 发布环节定时触发与多渠道分发最后一步是发布。这一步决定了整个流程是“一次性脚本”还是“流水线”。发布环节要解决两个问题什么时候发和发到哪里。“什么时候发”靠定时调度解决对应到技术选型上就是 Cron 表达式。我统计过 AIHOT 的更新时间早晨、中午、傍晚三个高峰这很明显是做过用户活跃度分析的——这些时段正好是上班前、午休和下班后打开率最高。“发到哪里”就是多渠道分发网页端是最基础的进一步是推送到微信群、飞书群、Telegram 频道再进一步甚至可以自动生成一版邮件摘要发给订阅用户。这一步很多人会忽略但我觉得它恰恰是“会自己出版”的关键。一套系统如果只有生成没有自动发布那它只是半自动——你还得每天手动把内容搬出去。一旦把这一步也接上整条流水线才真正闭环从采集到上线全程不需要人坐在那里。3. 实操一条最小可用的 AI 情报流水线光讲原理容易飘我给你一套我实测过的最小可复现方案。这套方案不要求你有很强的编程背景只要会配置和改改文本就行。3.1 工具底座Dify Agent 任务调度我选型第一原则是不重复造轮子。流水线里的每个环节现在都有现成的开源工具可以组装。编排框架我用 Dify这工具的好处在于可视化工作流你可以把采集、筛选、生成、发布四个环节画成流程图每个节点配不同的模型和参数改完直接发布。它的知识库功能还能帮你建立长期记忆比如让系统记住你之前发过哪些选题避免重复生产。热搜榜上那些“dify知识库流水线”的关键词不是没道理的Dify 在这条赛道上的地位基本等于水电基础设施。Agent 部分我习惯把流水线拆成四个独立的 Agent采集 Agent 负责对接信息源筛选 Agent 负责打分去重写作 Agent 负责生成简报发布 Agent 负责对接分发渠道。四个 Agent 各干各的活通过 Dify 的工作流串起来。这样做的好处是任何一个环节出问题只需要单独替换那个 Agent不需要动整条链路。任务调度我用了最简单的方式服务器上的 Crontab。你不需要上 K8s也不需要搞复杂的任务队列一条 Cron 规则就够了。我通常这么写0 8 * * * cd /opt/aihot_flow python scripts/run_pipeline.py --mode morning 0 12 * * * cd /opt/aihot_flow python scripts/run_pipeline.py --mode noon 30 18 * * * cd /opt/aihot_flow python scripts/run_pipeline.py --mode evening三行配置定时唤醒整条流水线。我实测跑了大半年稳定性非常高唯一会出问题的场景是模型 API 偶尔超时所以我在 Python 脚本里加了自动重试逻辑。3.2 数据接入三种信息源怎么配对大多数人来说第一步不需要写爬虫可以从 RSS 开始。GitHub Trending 和 arXiv 都提供 RSS 输出你在 Dify 里可以做一个“RSS 采集节点”填入订阅地址设定抓取频率数据就会自动进入工作流。这里有一个细节RSS 返回的 XML 结构在不同源之间差异很大建议在采集节点后面接一个“格式化”步骤用一段简单的 Python 代码把 title、link、description、published 字段提取出来统一成 JSON 格式再往下游传。Product Hunt 和 Hacker News 有公开的 API前者的 API 需要申请 Token后者的 Firebase API 是无鉴权的直接调用即可。API 返回的数据往往是嵌套结构我用的是 Dify 里的 Python 节点来做字段清洗把 APIData 里我们需要的字段剥出来。网页抓取类的源比如某些垂直媒体我放在最后才接——因为解析规则过于脆弱站点稍微改个 CSS 类名脚本就废了投入产出比不高。我给你一个我自己选源的参考表信息源类型代表接入方式维护难度内容质量官方 RSSGitHub Trending、arXivRSS 订阅低高开放 APIHacker News、Product HuntHTTP 请求低中高垂直媒体各类行业科技媒体网页解析中高高社交媒体Twitter、即刻等API/抓取高中噪音大建议新手期只保留前三类社交媒体源等流水线跑顺了再考虑。3.3 提示词设计让 AI 持续输出高质量简讯的核心这是我觉得整个流水线里最值得反复打磨的部分。模型能力在同等水平下提示词的好坏直接决定输出质量。下面这条提示词是我从多轮迭代里沉淀出来的版本你可以直接抄走你是一名 AI 行业情报编辑。我会给你一条原始信息你需要输出一份结构化简报。 要求 1. 标题不超过22个字必须包含核心主体和关键动作。 2. 正文结构固定第一句写核心事实第二句写背景第三句写影响第四句写值得关注的理由。 3. 只输出事实不输出情绪化评价禁止使用“重磅”“震惊”“震惊”等夸张词汇。 4. 如果原始信息与AI行业无关回复【SKIP】。 5. 全文控制在150字以内。 原始信息 {raw_content}为什么这条提示词有效因为我把编辑的判断标准全部显性化了。模型不像人你告诉它“写得专业一点”它不知道专业是什么意思但你告诉它“只输出事实不输出情绪化评价”它就知道要去掉形容词。你告诉它“全文控制在150字以内”它就不会长篇大论。这套模板化的约束就是流水线能够“稳定复制”的秘密。我后期还加过一个批次处理版本一次传入 10 条候选内容让模型在一次调用里输出 10 条结构化简报。这样能大幅降低 API 调用次数和耗时成本能再降一半以上。3.4 自动发布从生成到上线全自动我的发布端分两个接受对象网站和即时通讯群。网站发布我用的方案最简单Dify 工作流的输出节点把生成好的结构化内容直接写入数据库表前端页面定时从数据库拉取最新记录渲染出来。这套方案不需要额外写接口一个定时刷新的列表页就够了。即时通讯群的推送稍微复杂一点。我通过 Webhook 把格式化好的内容推送到群机器人每条推文带上标题、摘要原文和原始链接。这里有个小技巧推送到群里之前我会让 AI 额外生成一句“人工摘要”控制在 50 字内的超短版方便群里的人快速扫一遍决定要不要点开看全文。超短摘要和详细简报在同一条流水线里生成只是提示词里把字数要求调整一下而已。整个发布过程跑完后脚本会往日志文件里写一行记录包括生产了哪几条内容、状态码是多少、耗时多久。每天早上我看一眼日志就能知道昨晚流水线有没有正常运转不需要人肉去网站检查。4. 我踩过的坑和排查实录流水线不是搭完就万事大吉跑起来之后问题才开始。下面这几个坑是我实际踩过的给你做个避雷参考。4.1 重复内容泛滥去重的三种姿势第一个坑来自采集环节。我一开始接了多个信息来源同一篇行业深度文章经常被不同媒体转载结果 AI 把它们当成不同的内容全推了出去一天能出现四五条高度雷同的简报用户很快就烦了。后来我做了三层去重。第一层是 URL 去重置维护一个已发布链接的集合新内容只有在链接不存在时才进入候选池——这是最简单也最可靠的一层。第二层是标题相似度我把标题做规范化清洗后计算文本相似度相似度超过 80% 就直接打入冷宫。第三层是正文摘要去重配合大模型做语义相似度比较这一层能识别“换个标题洗稿”的情况。三层叠加之后重复率基本降到 5% 以下。4.2 Agent 卡死在长流程里超时与重试设计第二个坑是模型 API 的不稳定。流水线每个环节都依赖 API一旦调用超时整个流程就会卡在那里后面的内容全部延迟发布。我的处理方式分两层。工作流层面我在 Dify 的每个模型节点上都设置了超时时间超过 30 秒就自动失败重试重试次数设定为 2 次。脚本层面我用了重试装饰器对网络请求做指数退避重试。这两层兜下来我后面三个月没有再遇到过流水线卡死的情况。做定时任务你还要想清楚一个问题如果某次运行失败了你是要跳过还是要补跑。我采用的是“失败自动跳过 日志报警”不会因为半夜一次失败就滚动补跑把用户刷屏。宁可少发不能乱发。4.3 发布频率失控如何控节奏第三个坑是发布频率失控。有段时间我在测试阶段把 Cron 调成了每 20 分钟跑一次AI 又要基于当天的话题去重和热度排序进行生产结果一天生成了 50 多条内容把用户的信息流彻底淹没。后来我加了“每日发布上限”的硬逻辑脚本在生成阶段设定了一个上限值比如早上那轮最多产出 15 条中午那轮最多 10 条晚上最多 10 条一天总量不超过 35 条。这条规则的出发点很简单内容不是越多越好用户的时间是有限的。宁可每天精选 35 条高质量内容也不要推 100 条刷屏信息。4.4 质量滑坡回流反馈闭环第四个坑是 AI 输出质量会悄悄滑坡。这个问题很隐蔽——模型不会突然从“90 分”掉到“30 分”它是慢慢从 85 分滑到 70 分再到 60 分的。如果没人干预你可能会在两周后才反应过来怎么最近的内容这么水为了应对这个问题我在流水线里加了一个“质量抽检”环节。每天随机抽取当天发布的 3 条内容把原始信息和生成的简报同时发给另一个模型做打分评估评分低于阈值的会触发告警。也就是说用 AI 来监督 AI。这个方法不完美但它至少保证质量滑坡能在两天内被发现而不是拖到用户来投诉。5. 流水线之外的几点体会流水线本身是一件工具但工具背后有一个经常被忽略的东西你对整个领域的信息判断力。AIHOT 能做到百万月活表面上是流水线效率高实际上是它的产品团队对“AI 行业里的人到底关注什么”有足够深入的理解。流量、热点、工具、模型发布、政策动向这些内容在产品上呈现一个明确的优先级这个优先级不是流水线自己会长出来的是产品团队把它嵌入到筛选规则里的。我个人在搭这套系统的过程中最大的改变是从“每天刷手机看新闻”变成了“每天看一遍流水线的日志”。日志会告诉我今天收集到了哪些源的信息哪些源今天没有更新哪些源被筛选环节拒绝的次数特别高。这些元信息反过来又帮我优化信息源配置和提示词策略形成了第二个层面的反馈闭环。如果你也想搭一套自己的情报流水线我的建议是不要一开始就追求大而全。先用一个 RSS 源 Dify 模板 一个群机器人把这个最小闭环跑通再慢慢加源、加策略、加渠道。一次加一个变量出问题了你能知道是哪一环的锅一次性铺开 20 个源出了问题你连日志都不知道该看哪个字段。这条流水线再往后发展我看到的方向是不只是聚合已有信息而是基于这些信息去做趋势推断比如自动判断哪条技术路线正在从一个信号变成主线然后在爆发前提前预警。这已经是下一个量级的问题了但起点仍然是这条“会自己出版”的流水线——先把手动动作全部自动掉再谈智能决策。