企业官网建设流程全解析

1. 当"日报"变成一种产品：我为什么要做这个自动化信息聚合系统

每天早上八点半，我打开电脑的第一件事不是看邮件，而是翻十几个信息源，把过去24小时里值得关注的AI动态筛一遍。这个习惯持续了大概两年，直到某天我意识到：我花在"找信息"上的时间，已经远远超过了"消化信息"的时间。更麻烦的是，手动整理出来的东西格式不统一、来源散乱，想回溯某条消息时经常找不到出处。

于是我决定把这件事彻底自动化——做一个每天定时运行、自动抓取、自动筛选、自动排版、自动归档的AI日报系统。项目代号就叫"AI日报"，日期戳是2026-10-07，因为那天是我正式把第一版跑通的节点。这篇文章不讲虚的，我会把整个系统的设计思路、技术选型、踩过的坑、以及跑了几个月之后总结出来的调优经验，全部摊开来讲。

这个系统适合谁看？如果你是一个对信息聚合感兴趣的技术爱好者，或者你正在做一个类似的内容自动化项目，又或者你只是想了解"一个日报类产品从零到跑通"到底要经历哪些环节，那这篇内容应该能给你省下不少试错时间。我不假设你有很深的工程背景，但我会尽量把每个决策背后的"为什么"讲清楚，而不是只丢一堆代码让你自己悟。

核心逻辑其实就一句话：把分散的信息源统一采集、用规则和模型做两层筛选、按固定模板渲染成可读性强的日报、最后自动分发和归档。听起来简单，但每一个环节都有它的门道。下面我按模块拆开讲。

2. 信息源采集：从"能抓到"到"抓得稳"之间隔着多少坑

2.1 信息源的分层策略

一开始我犯了个典型错误：把所有信息源一视同仁，全部用同一套抓取逻辑去处理。结果就是有些源更新频率极高、内容噪音大，有些源几天才更新一次但每条都是精品，混在一起之后筛选压力全压到了后面的环节。

后来我改成三层结构：

• 核心层：更新频率适中、内容质量稳定、格式规范的源。这类源我直接全量采集，不做预筛选。
• 扩展层：更新频繁但噪音较多的源。这类源我会在采集阶段就做关键词预过滤，只保留命中特定主题的内容。
• 补充层：更新不规律但偶尔有独家内容的源。这类源我设置较低的采集频率，比如每6小时一次，避免浪费请求配额。

这个分层的好处是，后面的筛选环节可以根据来源层级设置不同的权重。核心层的内容默认进入候选池，扩展层的内容需要命中至少两个关键词才进入，补充层的内容则直接进入人工复核队列。

2.2 采集频率与请求节流的平衡

采集频率这件事，我调了大概两周才找到一个相对舒服的区间。太频繁了，一方面对目标站点不友好，另一方面你自己处理数据的压力也大；太稀疏了，又会漏掉重要更新。

我的实际配置是这样的：

这里有个经验：超时设置不要一刀切。有些源响应慢但内容好，你给它15秒超时它永远抓不完；有些源响应快但偶尔抽风，你给它30秒超时反而拖慢整体进度。我现在的做法是给每个源单独配置超时，初始值设为20秒，然后根据实际运行日志动态调整。

2.3 去重逻辑：别等到数据堆成山才想起来

去重这件事，越早做越好。我的去重分两层：

第一层是URL级去重。每次采集回来的条目，先跟最近7天的URL库做比对，命中就直接丢弃。这一层能过滤掉大概60%的重复内容。

第二层是内容级去重。有些源会改标题重新发布，或者不同源转载同一篇内容。这一层我用的是标题的SimHash加上正文前200字的余弦相似度，阈值设在0.85。超过这个阈值就判定为重复，只保留最早采集到的那一条。

注意：内容级去重的阈值不要设得太低。我一开始设了0.7，结果把很多"同一主题但不同角度"的内容也误杀了，反而丢失了信息多样性。0.85是我实测下来比较平衡的值。

2.4 采集失败的兜底方案

采集失败是常态，不是异常。网络抖动、目标站点临时维护、解析规则失效，这些都会导致采集失败。我的兜底方案是：

1. 每次采集任务结束后，统计失败率。如果单次失败率超过30%，触发告警通知。
2. 失败条目进入重试队列，按指数退避策略重试。
3. 连续3次重试都失败的源，自动降级为"观察状态"，采集频率减半，同时记录详细日志供后续排查。
4. 每天凌晨跑一次全量健康检查，对所有源做一次连通性测试。

这套机制跑下来，我的系统可用率大概在97%左右，剩下的3%基本是目标站点本身的不可用时间，属于不可控因素。

3. 筛选与排序：怎么让真正重要的内容浮上来

3.1 规则筛选：快、准、但不够"聪明"

规则筛选是我整个流水线的第一道闸门。它的逻辑很简单：维护一个关键词库和一个黑名单库，命中关键词的加分，命中黑名单的直接丢弃。

关键词库我分了几个类别：

• 技术类：模型架构、训练方法、推理优化、多模态、Agent、RAG等。
• 产品类：发布、上线、公测、开源、融资等。
• 行业类：政策、标准、白皮书、报告等。

每个关键词有不同的权重。比如"开源"权重是3，"发布"权重是2，"报告"权重是1。一条内容命中多个关键词时，权重累加。

规则筛选的优点是快，毫秒级就能处理完几千条数据。缺点是它只能做"是或否"的判断，没法理解语义。比如"某模型宣布不再开源"这条内容，命中了"开源"关键词，但实际含义是相反的。这种就需要第二层来兜底。

3.2 模型打分：用语义理解补上规则的短板

第二层我用了一个轻量级的文本分类模型来做语义打分。不是那种动辄几十亿参数的大模型，而是一个经过微调的小模型，推理速度快，单条处理时间在50毫秒以内。

模型输出的不是一个简单的"相关/不相关"，而是一个0到1之间的连续分数。我根据实际运行数据画了一条分数分布曲线，发现0.3以下的基本都是噪音，0.7以上的基本都是精品，中间那段需要结合规则分数一起判断。

最终的排序分数是这么算的：

最终分数 = 规则分数 × 0.4 + 模型分数 × 0.6

为什么模型分数权重更高？因为实测下来，模型对语义的理解确实比关键词匹配更靠谱。但规则分数也不能丢，它在处理一些模型没见过的领域术语时能起到兜底作用。

3.3 时效性衰减：旧闻不应该占据头条

信息是有保质期的。一条三天前的消息，哪怕内容再好，也不应该排在今天的新消息前面。所以我加了一个时效性衰减因子：

时效因子 = exp(-λ × 小时差)

λ的取值我试过0.01、0.02、0.05，最后定在0.03。这个值意味着：12小时前的消息，权重衰减到原来的70%左右；24小时前的消息，权重衰减到原来的49%；48小时前的消息，权重只剩24%。

这个衰减曲线不是拍脑袋定的，是我根据自己阅读习惯反推出来的。我发现自己对24小时内的消息关注度最高，超过48小时的基本就不太看了。所以衰减因子的目标就是让排序结果跟我的实际关注度对齐。

3.4 多样性控制：别让一个话题霸屏

有一段时间我发现日报里全是同一个话题的内容，因为那几天那个话题确实很热，所有源都在报。但作为读者，我希望看到的是"今天发生了什么"，而不是"今天大家都在说同一件事"。

所以我加了一个多样性控制逻辑：

1. 对排序后的内容做主题聚类，用简单的TF-IDF加层次聚类就能搞定。
2. 每个聚类最多保留3条内容，超出的按分数排序截断。
3. 最终日报中，同一个聚类的条目不超过总条目的30%。

这个逻辑加上去之后，日报的可读性明显提升了。读者能看到不同角度的信息，而不是被单一话题淹没。

4. 日报渲染：从数据到可读内容的最后一公里

4.1 模板设计：结构固定但内容灵活

日报的模板我改了大概七八版，最后定下来的结构是这样的：

• 头部：日期、总条目数、覆盖的信息源数量。
• 要闻区：3到5条最高分的内容，每条配一句话摘要。
• 分类区：按技术、产品、行业三个类别分组展示，每类5到8条。
• 速览区：剩余内容的标题列表，只保留标题和来源。
• 尾部：数据统计和系统运行状态。

这个结构的好处是，读者可以先看要闻快速了解重点，有兴趣再往下翻分类区，最后速览区用来扫一眼有没有漏掉什么。

4.2 摘要生成：不是简单的截断

摘要生成我试过三种方案：

第一种是直接截取正文前100字。效果很差，因为很多内容的开头是客套话或者背景介绍，真正的信息在后面。

第二种是用TextRank做抽取式摘要。比截断好一些，但有时候抽出来的句子之间缺乏连贯性，读起来像拼凑的。

第三种是用一个小型的生成式模型做摘要。效果最好，但推理成本也最高。我最后的方案是混合策略：对核心层的内容用生成式摘要，对扩展层和补充层的内容用TextRank抽取，然后人工规则做后处理。

后处理规则包括：去掉重复的实体、统一术语表述、限制摘要长度在80到120字之间。这些规则看起来琐碎，但对最终可读性的影响很大。

4.3 渲染性能：别让排版成为瓶颈

渲染环节本身不复杂，但如果数据量大了之后处理不当，也会成为瓶颈。我一开始用的是同步渲染，所有条目处理完才输出，结果发现当条目超过200条时，渲染时间会超过10秒。

后来改成流式渲染：先把头部和要闻区渲染出来，分类区和速览区异步处理，最后拼接。这样首屏时间从10秒降到了1秒以内，用户体验好了很多。

另外一个小技巧：模板中的静态部分预编译。比如头部的HTML结构、CSS样式这些不随数据变化的部分，在系统启动时就编译好缓存起来，渲染时只需要填充动态数据。这个优化让渲染速度又提升了大概30%。

5. 分发与归档：日报做完了然后呢

5.1 分发渠道的选择与适配

日报做出来是给人看的，所以分发渠道很重要。我目前支持三种分发方式：

• 邮件：最正式的方式，适合归档和转发。我用的是HTML邮件模板，兼容主流邮件客户端。
• 即时消息：适合快速浏览。我把日报拆成几条消息推送，避免单条消息过长被截断。
• 静态页面：适合长期存档和检索。每天生成一个独立的HTML文件，按日期归档。

每种渠道的内容格式都不一样。邮件需要完整的HTML结构，即时消息需要纯文本加少量格式标记，静态页面则需要考虑SEO和加载速度。我的做法是维护一套中间数据结构，然后针对不同渠道写不同的渲染器。这样新增渠道时只需要加一个渲染器，不用改核心逻辑。

5.2 归档策略：三个月热数据加一年冷数据

归档这件事我踩过一个坑：一开始所有数据都放在同一个数据库里，跑了半年之后查询越来越慢。后来改成冷热分离：

• 热数据：最近3个月的日报，存在主数据库里，支持快速查询和全文检索。
• 冷数据：3个月到1年的日报，压缩后存到对象存储，需要时再解压加载。
• 超冷数据：超过1年的，只保留标题和摘要，正文归档到离线存储。

这个策略让主数据库的体积控制在了可控范围内，查询性能也稳定了。

5.3 运行监控：让系统自己告诉你它病了

一个每天自动运行的系统，最怕的就是"悄无声息地挂了"。所以我加了一套监控机制：

• 采集监控：每个源的采集成功率、平均响应时间、失败原因分布。
• 处理监控：每个环节的处理耗时、条目数量变化、异常丢弃率。
• 分发监控：各渠道的发送成功率、打开率（如果有反馈的话）。
• 系统监控：CPU、内存、磁盘、网络的基本指标。

这些指标每天汇总一次，生成一份系统健康报告。如果某个指标偏离历史均值超过两个标准差，就触发告警。这套机制帮我提前发现了好几次潜在问题，比如某个源的解析规则即将失效、某个环节的处理时间在缓慢增长等。

6. 跑了几个月之后，我总结出的几条实战经验

6.1 不要追求"全自动"，留一个人工复核的口子

我一开始的想法是做一个完全自动化的系统，从采集到分发全部不用人管。但跑了大概两周之后我就发现，完全自动化在现阶段是不现实的。模型会犯错，规则会过时，信息源会变化，这些都需要人工介入。

所以我在流程中加了两个人工复核点：

第一个是每日抽检。每天随机抽取10条内容，人工判断筛选和排序是否合理。如果发现明显错误，就回溯调整规则或模型阈值。

第二个是周度复盘。每周花半小时看一下这一周的日报，检查有没有系统性的偏差，比如某个类别的内容总是被低估、某个源的内容总是被误杀等。

这两个复核点花不了多少时间，但能显著提升系统的长期稳定性。

6.2 阈值和参数不要一次定死，留出调优空间

我在系统里设了很多阈值和参数：去重相似度阈值、关键词权重、模型分数权重、时效衰减系数、多样性控制比例等等。这些参数我一开始都是拍脑袋定的，后来发现每一个都需要根据实际运行数据来调。

我的做法是：把所有参数集中在一个配置文件里，每次调整都记录变更日志和调整理由。这样当效果变差时，可以快速回溯到上一个稳定版本。

另外，我建议每次只调一个参数。同时调多个参数，你根本不知道是哪个起了作用。我吃过这个亏，调完之后效果变好了，但不知道是哪个参数的功劳，下次遇到类似问题还是不知道怎么处理。

6.3 数据质量比算法复杂度更重要

我花了很多时间在筛选算法上，试过各种模型和策略。但后来发现，信息源本身的质量才是决定日报质量的上限。如果源里面全是噪音，再好的算法也筛不出精品。

所以我现在把更多精力放在信息源的维护上：定期评估每个源的内容质量、及时剔除质量下降的源、积极寻找新的优质源。这个工作的投入产出比，比调算法高得多。

6.4 日报的"人味"很重要

最后说一点感受。我一开始追求的是"信息密度最大化"，恨不得把当天所有相关内容都塞进日报里。但后来发现，读者要的不是"全"，而是"精"。一份好的日报应该像一个靠谱的朋友在跟你说："今天这几件事值得关注，其他的你不用管了。"

所以我现在会在日报里加一些主观判断的痕迹，比如"这条值得细看"、"这条可以跳过"之类的标注。这些标注不是模型生成的，是我每天花几分钟手动加的。虽然增加了工作量，但日报的可读性和实用性提升了很多。

这个系统到现在跑了几个月，中间经历过几次大的调整，也踩了不少坑。但每次看到早上打开日报时那种"信息已经帮我整理好了"的轻松感，就觉得这些投入都是值得的。如果你也在做类似的事情，希望这些经验能帮你少走一些弯路。