我第一次认真拆解AIHOT是在一个周五深夜。那周我刚手工整理完一份行业情报周报从盯信源、筛内容到排版发布忙了整整两天。结果点开AIHOT一看它当天自动推送的几条热点分析信息密度、时效性、行文结构都比我手工做的强。最扎心的是它几乎从不断更每天固定时段出稿、固定格式分发稳定得就像一条没有情绪的生产线。后来我花了几周时间把AIHOT对外可见的产品形态和行为特征一条条拼起来又用Dify知识库流水线做了一轮完整的复刻实验。这篇文章就是我对这套百万月活情报产品的拆解笔记也是我亲手搭建同类流水线的实战记录。适合两类人一类是想搞明白AI自动内容产品到底怎么运转的独立开发者和产品经理另一类是正在用Dify这类工具搭知识库、但卡在工程化细节上的技术同学。看完你应该能回答三个问题这套流水线每个环节到底在做什么环节之间为什么会互相冲突以及什么样的产品不适合走全自动出版这条路。1. AIHOT的百万月活背后先看清它到底在做什么1.1 它是情报系统不是资讯网站很多人第一次打开AIHOT会自然而然地把它归类为AI资讯站或者热点聚合App。以我对内容产品的观察这个归类其实是误判——资讯站的核心驱动力是编辑团队热点聚合的核心驱动力是爬虫和分发算法而AIHOT的核心驱动力是一整条自动化的情报处理链路多源采集、噪音过滤、事件研判、内容生成、自动发布。用户每天看到的那批文章和榜单只是这条链路末端的可见产物。换句话说AIHOT本质上是在用自动化手段复刻一个资深情报分析师的工作流。一个传统的情报分析师日常工作可以拆成四件事盯住信源、筛掉噪音、判断哪些事值得跟进、把判断写成简报。AIHOT做的就是把这四件事分别变成流水线上的独立工位每个工位由不同的模型和规则来执行最后由一段总装逻辑把它们拼接成用户看到的内容产品。这套设计的精妙之处在于它真的能做到会自己出版。自己出版不是完全没有人在管而是人的角色发生了根本变化——从亲手写内容的人变成了定义规则、处理例外、抽检质量的调度员。内容生产、排版、推送、更新这些高频操作全部自动化人只在关键节点介入。这才是它能支撑起百万月活、同时保持极低边际成本的原因。1.2 一条情报从进入系统到出现在用户面前走完四个环节我基于AIHOT公开可见的行为把这条流水线归纳成四个核心环节信源接入层覆盖行业媒体、技术博客、社交平台讨论、学术预印本、产品发布公告等信息源。这一层的关键指标不是信源数量而是覆盖度与信噪比之间的平衡。清洗与结构化层把不同来源、不同格式的原始信息统一成标准化的情报条目包含事件主体、发生时间、影响范围、置信度等结构化字段。选题与研判层对每条情报打分排序综合热度、新颖度、与核心用户的相关度来决定哪些内容值得被产出。自动出版层生成正文、生成摘要、排版、定时发布到多个渠道并在发布后把点击、收藏、转发等行为数据回收进系统。这四个环节不是一条单行道。最后两个环节产生的用户反馈会重新影响前两个环节——比如某个信源多次贡献出高互动内容它的权重会上升某个话题类型的选题持续表现不佳它在选题阈值里的相关度权重会被调低。所以我把AIHOT理解成一条会自我调整的流水线它的内容口味不是被某个人固定下来的而是被用户行为持续塑形的。有一点我需要说明这套环节拆分是我基于AIHOT可观测的外部行为做的推断不是它的官方架构文档。但它的参考价值不依赖官方性——我在复刻实验中验证过不管用什么工具来搭这四个环节都是绕不开的必经之路。2. 拆解会自己出版的五个关键工位2.1 采集工位信源按信号衰减期分级而不是越多越好我最初做情报采集时踩过一个特别常见的坑见到一个信源就加进去觉得来源越多覆盖越全。跑了两个星期数据量上去了但有效信息的增速远远落后于噪音的增速每天上百条原始内容里真正值得深挖的不超过十条。大部分时间都耗在从垃圾里捡金子上了。AIHOT给我的启发是信源要按信号衰减期来分级管理。所谓信号衰减期指的是一条信息从出现到被目标人群广泛知晓的时间窗口。产品发布会、版本更新、突发动态这类信息衰减期非常短必须以分钟级去抓取行业报告、深度分析这类信息衰减期长达数天甚至数周完全可以放到低频任务池里慢慢消化。我自己搭建时参考了这个思路把所有信源分成三档信源级别典型来源抓取频率处理优先级S级头部媒体RSS、官方公告、社交平台热榜5-15分钟立即清洗A级技术博客、行业社区、中型媒体1-4小时批量处理B级学术预印本、深度报告、论坛长文每天闲时处理这个分级看起来不复杂但它直接决定了计算成本和队列压力。如果让所有信源都用5分钟的高频去抓取绝大多数请求都浪费在轮询没有更新的源头。按信号衰减期分配抓取频率本质上就是让计算资源跟着信息的时效价值走——重要的信息抢时间不重要的信息省资源。2.2 清洗工位格式统一、事件级去重、实体对齐清洗是整个流水线里最枯燥、但最不能省的工位。从信源抓下来的原始数据有多脏同一件事可能有五六个渠道在报道每个渠道的标题、措辞、数据口径都不一样甚至同一个模型的发布消息在不同媒体笔下的版本能差出半个故事。不把这一步做扎实直接把脏数据喂给下游的模型后续的选题和生成都会出问题。有效清洗至少包含三件事第一是格式统一。把HTML正文、PDF、图片里的文字全部提取并转换成统一的纯文本结构顺带把正文里夹带的导航、广告、版权声明清理掉。第二是事件级去重。注意这不是文本相似度去重。两个标题完全不同、措辞完全不同的报道可能讲的是同一个发布会。如果只做文本相似度匹配这两条会被当成独立事件放进下游最终生成两篇实质内容高度重合的文章用户的直接感受就是这个产品在重复灌水。事件级去重需要抽取出每条报道的事件指纹——主体、动作、时间、关键对象——再做匹配。第三是实体对齐。同一家公司在不同报道里可能有全称、简称、中文名、英文名、产品代号等多种写法同一个人物在不同渠道里的称呼也可能完全不同。实体对齐要把这些不同写法统一成标准实体为后面的检索和生成建立干净的索引基础。第三件事是后文要重点讲的流水线冲突的高发区。举个真实例子一条来源写着某AI公司发布了新一代模型另一条写着the company announced its latest model两篇报道都没有出现具体的模型代号。如果实体对齐不到位这两条会被当成两个独立事件送进研判工位最终产生两篇方向相同的文章。这类问题在单篇上不容易看出来但放大到一周的产出上重复感会非常明显。2.3 研判工位给每条情报打一个值得做的分清洗完成之后流水线进入研判环节。这个环节要解决的问题非常具体今天收到的几十条有效情报里哪几条值得写成内容推给用户如果没有这个筛选步骤有多少情报就有多少篇文章用户会被信息淹没。我的复刻版本用了一个非常朴素的打分公式情报分 热度分 × 0.35 相关度分 × 0.35 新颖度分 × 0.2 可信度分 × 0.1热度分衡量的是事件被多个独立信源交叉验证的频次以及它在社交平台的讨论规模相关度分计算情报与目标用户关注主题的语义距离新颖度分看的是它与知识库已有情报在时间和内容上的差异程度可信度分则来自信源的历史表现。这个公式真正的难点不在公式本身而在权重怎么确定。AIHOT有百万月活积累的行为数据来校准权重——用户点击了哪类内容、收藏了哪类内容、在什么时段阅读这些信号都能反向优化研判参数。个人搭建的版本没有这个数据优势我的做法是人工抽检每周调参每天随机抽20条被判为高分的选题做人工复核每周统计一次命中率如果命中率连续低于60%就调高相关度权重、调低热度权重。土办法但非常有效而且能让我对系统的行为建立直觉。2.4 自动出版工位生成、审校、定时发布、数据回流研判工位选出当天的选题清单后下游的生成逻辑开始工作。这一层实际做的事情比大多数人想象的要多我拆成了四个子任务生成初稿时最关键的一个细节是触发生成时不只是把情报条目丢给模型而是从知识库里把与该事件相关的历史条目和背景资料一起拼进上下文。这样才能产出有纵深的情报分析型内容而不是干巴巴的新闻流水账。同样是报道某公司发布新品只给新闻稿模型写出来就是一个转述把这家公司过去一年的产品线、市场动作、相关评论都喂进去模型写出来的东西才有点分析师的样子。自动审校环节做三件事事实性检查日期、数字、机构名是否一致、敏感信息过滤、与历史内容的重复度检查。这一步如果不够严格流水线跑得越快出错的代价就越大——一条错误信息会在最短时间内被扩散到所有分发的渠道。定时发布不是随便定几个时间点而是跟着用户的阅读行为高峰走。AIHOT的内容更新有明显的时段节奏早间快报、午间热点、晚间深度这种编排是在用发布节奏配合用户注意力周期。发布环节同时要做多渠道适配同一篇内容在网页端、信息流、群推送里的格式要求都不一样。最后的回流环节最容易被忽略但也是会自己出版的点睛之笔发布完成不是结束而是下一轮选题的开始。阅读率、完读率、收藏率、转化率这些数据会回到研判工位成为下一次打分的输入。没有这个闭环流水线只是自动的有这个闭环流水线才是会自我进化的。2.5 调度工位用消息队列把工位串成一条不会堵死的产线有了前面的工位还需要把它串成一条产线。我在自己的流水线里用的是消息队列架构每个工位都是一个独立的任务处理器工位之间通过队列传递数据采集工位把原始数据写入待清洗队列清洗工位消费这个队列清洗完成写入待研判队列研判工位消费队列产出带评分的选题写入待生成队列生成工位消费队列产出成品写入待发布队列发布工位按照预定时间窗口把内容推出去。这套架构的最大好处是每个工位都能独立伸缩、独立维护。假设某天某个大厂一口气发布了三个产品采集工位和清洗工位的压力会瞬间增大但研判工位和生成工位完全感知不到这种波动——它们只看到自己队列里的任务数量变多了。反过来如果某个模型服务出了问题最多是生成工位的队列出现堆积不会让整条流水线瘫痪。3. 用Dify知识库流水线复刻这套系统实战记录3.1 为什么选Dify而不是从零开始写代码讲完AIHOT的抽象模型说说我的复刻实验。为什么不直接写代码因为从头搭建一套内容流水线需要同时处理采集、清洗、入库、检索、生成、分发六件事。这六件事里真正跟业务逻辑相关的不到三成剩下七成都是在重复实现通用能力。Dify这类平台的价值在于把知识库生命周期管理——包括文档解析、分段、向量化、索引更新、混合检索、引用配置——做成了开箱即用、可编排的模块。这里要澄清一个容易被误解的点Dify知识库不是简单地把文档上传上去、让模型在对话时检索。它提供的是完整的知识库工程化管理能力这正好对应AIHOT流水线里的清洗、结构化、检索三个环节。把这三个环节承接好剩下的采集、调度、分发只需要写少量胶水代码就能串起来。但我也要先把丑话说在前面用Dify复刻AIHOT不等于能做出一个百万月活的产品。AIHOT的护城河是它多年来积累的用户行为数据和信源关系网络这些是任何工具都给不了的。复刻实验的真正价值在于验证一个判断——这套流水线的工程结构能不能被低成本复现、跑起来稳不稳定。我的答案是能复现稳定性的问题集中在我后面要讲的冲突管理上。3.2 五个搭建步骤附实际配置参数第一步设计知识库结构。我建了三个独立的知识库信源库存信源的元数据和历史可靠性评分、情报库存清洗后的结构化情报条目、背景库存行业分析报告和历史深度内容。三个库分开放是因为它们的检索频率和更新频率完全不同信源库低频更新情报库高频写入背景库中频补充。合并成一个库会让向量检索的噪音明显变大检索结果里经常混进不相关的历史内容。第二步配置文档分段。分段策略直接决定检索质量。我的经验是情报类内容的分段不能太小也不能太大。太小的分段比如按句切会让检索到的片段缺乏上下文模型拿到的是孤零零的一句话太大的分段比如整篇一块会把多个主题混在同一段里检索命中率下降。我的最终参数是按语义段落切分每段控制在500-800字同时开启标题级索引让模型在检索时能拿到文档的层级结构。第三步写采集与清洗的接入逻辑。Dify不负责外部信源的抓取需要自己写采集器。我用Python写了一个轻量服务定时从S级和A级信源拉取内容做格式清理和一级去重然后通过Dify的API写入指定的知识库。写入前还会做一次规范化处理把正文里的广告、导航链接、版权声明全部剥离保证进库的文本干净可用。第四步配置混合检索。这一步直接决定生成内容的质量。我配置的是关键词匹配向量语义检索并行的混合模式再按相关性加权融合结果。为什么要混合而不是纯向量因为纯向量检索对专有名词和数字不敏感。举例来说两个不同版本的模型名在语义向量空间里距离很接近但它们在事实上是完全不同的两个对象。混合检索的作用就是在向量语义之外补上精确匹配的约束。第五步编排生成工作流。这一步在Dify的画布上完成。我编排的生成流程是接收情报条目 → 从情报库检索事件上下文 → 从背景库检索相关知识 → 拼接完整上下文 → 调用生成模型 → 格式化审校 → 输出成品。整个工作流可以独立运行也可以通过API批量触发配合定时任务就能实现无人值守。3.3 调度方案从固定时刻触发到首尾衔接工作流搭好后最后一步是让它自己跑起来。我最开始的方案是三个定时任务采集任务每15分钟跑一次清洗入库任务每30分钟跑一次生成发布任务每天早、中、晚各跑一次。跑了不到一周就发现问题了每个工位的处理时长是不确定的偶尔清洗一批数据要40秒偶尔模型生成一篇内容要2分钟。固定时间戳触发很快造成任务堆积发布批次越来越晚。后来我把调度逻辑改成事件驱动不是到点就触发而是上一批任务完成后立刻触发下一批。这个改动看起来很小但效果立竿见影——每个工位变成了首尾衔接的接力跑而不是各自按固定的钟表时间跑。无论某一批处理得慢了还是快了下一批总能在上一批结束后立即跟上整条流水线重新恢复稳定。4. 流水线中的冲突三类典型问题的踩坑与解法4.1 信息冲突同一条情报多个信源的版本不一致信息冲突是所有情报类流水线的第一道坎同一条情报在不同信源里的描述不一致让清洗、研判、生成环节都接受到矛盾的信号。我踩过一个非常典型的坑。某天晚上三个信源同时推送了同一条消息但措辞分别近似于某公司发布了新版本某公司宣布新一代产品即将推出某公司被曝正在测试新产品。这三条指向同一件事但对事件状态、确定性、细节的描述全都不一样。如果在清洗环节不做冲突消解系统就会把它们当成三条独立情报送进生成工位最终产出一篇逻辑上自相矛盾的内容该公司发布了新产品同时新产品即将推出同时还在测试中。解决信息冲突我用了三步事件指纹匹配提取每条情报的主体、动作和时间生成事件指纹指纹一致的情报自动归拢到同一个事件组。置信度投票事件组内部信源历史可靠性越高的描述权重越大出现频次最高的描述组合胜出作为该事件的标准版本。保留不确定性如果冲突实在无法消解一个信源说已发布另一个说即将发布不要强行二选一把两种说法都保留下来在生成时让模型以多方信息并存的方式表述。4.2 流程冲突工位之间抢资源、踩节奏流程冲突是流水线内部最隐蔽的问题不跑到一定规模很难暴露出来。它的本质是多个工位共享同一份资源或者工位之间的节奏互相干扰。我的第一个流程冲突发生在知识库层面。清洗工位在往情报库里写入新数据同一时刻生成工位在从知识库检索背景资料。一旦写入操作触发的是全量重建索引而检索请求恰好赶在重建过程中到达就会返回空结果。当时最直观的症状是流水线偶尔会产出一篇明显缺少历史背景的失忆内容排查了很久才定位到是索引重建和数据检索撞在一起了。第二个流程冲突是发布时间冲突。我设置早、中、晚三个固定发布窗口结果有一天的中午批次因为模型生成超时拖到下午两点才发布下午六点的批次又照常触发用户在一小时内收到了两轮推送。内容本身没有错但这种节奏的混乱对用户体验的伤害非常大。解决这两类问题我的经验是两条原则读写分离知识库拆成主库和只读副本写操作和索引重建走主库检索请求只打副本副本重建完成后平滑切换。这样任何一次写操作、重建操作都影响不到正在服务的读流量。熔断与降级每个工位设置超时上限和重试次数超时后不是无限等待而是把当前任务标记为失败降低它的优先级优先保证后续批次能按节奏执行。宁可让一条内容迟到也不能让整条产线瘫痪。4.3 内容冲突同质化过载与风格漂移内容冲突发生在生成环节最典型的形态是同质化过载。假设某天行业里同时发布了几份强相关的报告按情报分排序它们大概率会一起进Top5。最终用户看到的五篇内容里三篇在讲同一个大趋势的不同侧面观感上就是同一个话题换了几个标题反复推送。我的解法是在选题环节加多样性约束同一批次的选题两两之间的语义相似度不能超过预设阈值一旦超过分数较低的那条被替换。这个约束用向量相似度计算就能实现不算复杂但对阅读体验的提升立竿见影。它本质上是在情报分之外人为地加入一个覆盖度目标防止系统因为追逐分数而陷入局部最优。另一个内容冲突是风格漂移。当流水线在不同批次调用了不同模型或者不同参数时产出的文字风格会不一致——早间批次是冷静克制的分析语气晚间批次可能变成热情洋溢的推荐语气。单看每一篇都正常但用户连续读几天会产生明显的人格分裂感。我的经验是把角色设定、语气偏好、结构规范写成一个固定的系统提示词模板所有批次的生成共用同一个模板只有内容主体随情报变化。这样可以最大程度压低风格漂移。4.4 冲突治理的总体原则踩过这些坑之后我总结出一条总体原则冲突治理不是消灭冲突而是给冲突设计消化机制。信息冲突靠证据投票来消化流程冲突靠架构容错来消化内容冲突靠约束规则来消化。分布式系统里完全消灭冲突不现实能做的只是让冲突暴露得足够早、定位得足够快、处理得足够安静。还有一个工程上的建议所有冲突消解逻辑都要留日志。我后来给流水线的每个关键决策点加了结构化日志记录这条情报为什么归到A事件组而不是B事件组这个选题为什么被替换掉。刚开始觉得写日志麻烦但真正排查问题的时候才发现没有这些日志基本等于盲人摸象。5. 拆完AIHOT之后的三点判断5.1 内容产品的护城河正从生产能力转移到判断能力AIHOT这套流水线让我感触最深的一点是生成能力被工具普及之后内容产品的竞争重心发生了整体转移。以前大家拼的是谁能更快、更好地产出内容现在模型能力已经拉平了大部分团队的生产下限真正的差异化变成谁能更准确地判断什么值得写、什么不值得写、什么时候写。同样的情报样品交给十个团队用同一个模型来生成初稿质量不会有本质差别。差别出现在对这条情报的优先级排序、角度选择、发布节奏这些决策上。AIHOT的百万月活本质上不是内容质量的胜利而是它在数据闭环里反复优化判断力的胜利。它每天都在用用户行为校准自己的选题模型这种能力是任何单独的模型能力都替代不了的。5.2 至少有三类产品不适合走全自动出版路线拆完之后我也认真地想过边界这条流水线是不是适合所有内容产品我的答案是不适合至少有三类产品我会明确建议不要全自动。第一类是强观点型内容。流水线擅长事实信息的整理和归纳但强观点内容需要稳定的立场和深度思考这不是靠检索和模板能解决的。自动化会让观点表达趋向平均值最终失去立场。第二类是强信任型内容比如医疗、金融、法律领域。这类内容的容错率极低一条错误信息造成的信任损失远超自动化带来的效率收益。可以用流水线做素材收集和初稿辅助但出口必须有人工审核而且得是足够资深的人。第三类是强风格型内容。如果产品核心卖点是某个特定作者的写作风格和人格魅力自动化会把这种特质抹成一张平滑的脸。5.3 人的位置把高频决策前置给系统把判断力留给人类说了这么多自动化最后想认真聊聊人。AIHOT的流水线再自动背后依然有一小群人在做关键节点的事情定义信源分级规则、设置选题阈值、处理极端情况、复盘数据异常。流水线能够自己出版是因为这些规则被人为前置到了系统里而不是它真的摆脱了人。这给我的实际操作启示是搭建自动出版流水线时不要一开始就追求无人值守。先让人在环里至少跑一个月观察系统行为规律把那些高频的、确定性高的决策逐步下沉到系统里再把人的精力释放到真正需要判断力的事件上。这个过程很像带新员工第一步你在旁边盯着第二步让它独立处理日常事件第三步只有在极端情况下你才接手。走完这三步再去谈会自己出版你会对这套系统建立真正的掌控感。我个人在实际操作中的体会是一条好的行业情报流水线最大的价值不是替人省了多少工时而是把团队的注意力从怎么把内容做出来转移到了什么内容值得做上。这个注意力转移本身就是内容生产效率的一次质变。