企业官网建设流程全解析

1. 一份AI日报的诞生逻辑

每天早上八点半，我习惯性打开自己搭建的AI日报聚合面板，扫一眼过去24小时里全球AI圈发生了什么。这个习惯坚持了快两年，中间换过三种方案，踩过的坑足够写一本小册子。今天这篇内容，就是把这套"AI日报"从信息采集到最终成稿的完整流程拆开讲清楚，包括我为什么这么设计、每个环节的关键参数怎么定、遇到问题怎么排查。

先说清楚这份"AI日报（2026年10月7日）"到底是什么。它不是某一家媒体的新闻汇总，而是一套自动化程度较高的信息聚合与筛选系统产出的每日简报。核心目标只有一个：用最少的时间，把当天最值得关注的AI动态筛出来，并且附上足够的上下文，让读者不用再点开原文就能判断这条信息跟自己有没有关系。

适合谁来参考这套方案？三类人。第一类是跟我一样做技术内容输出的从业者，需要稳定的信息输入源；第二类是在AI产品团队做市场或战略的同学，需要每天跟踪竞品和行业动向；第三类是对AI感兴趣但不想被信息洪流淹没的普通读者，想要一份"过滤后的清单"。不管你是哪一类，这套流程都可以按需裁剪。

我做的这份日报，每天覆盖的信息源大概在40到60个之间，最终进入日报正文的通常只有8到12条。这个比例是刻意控制的——筛选比采集重要得多。下面从整体设计思路开始拆。

2. 整体架构与信息源选型

2.1 为什么采用"分层过滤"而不是"全量聚合"

最开始我做日报的时候，思路很简单：把所有能抓的源全抓下来，按时间排序，一股脑输出。结果就是每天产出两三百条，自己都不想看，更别说读者。后来改成三层过滤架构，才真正跑通。

第一层是信源层，负责原始信息的采集。第二层是去重与初筛层，把重复报道、低质量内容剔掉。第三层是价值排序层，按重要性和相关性打分，取Top N进入日报。这三层是串行关系，每一层都有明确的淘汰率目标：信源层采集100%，初筛层保留30%到40%，排序层最终保留10%到15%。

为什么这么设计？因为AI领域的信息有个特点：同一件事会被几十个源反复报道，但真正有价值的增量信息往往只藏在其中一两个源里。如果不在初筛层做去重，排序层就会被大量同质内容淹没，打分再准也没用。

2.2 信源清单的构成与取舍标准

我的信源清单分四大类，每类的采集方式和更新频率都不一样。

这里有个关键取舍：我没有把社交媒体个人账号纳入信源。原因很实际——个人账号的信息噪声太大，验证成本高，而且容易带入主观判断。日报的定位是"事实简报"，不是"观点合集"，所以宁可漏掉一些早期爆料，也要保证每一条都有可追溯的出处。

提示：信源清单不是越多越好。我实测下来，超过60个源之后，边际信息增量急剧下降，但维护成本线性上升。建议新手从15到20个核心源起步，跑顺了再扩。

2.3 采集频率与时间窗口的设定

日报叫"日报"，但采集不能只在早上做一次。我的方案是滚动采集 + 定时成稿。采集端每30分钟跑一次，把新内容写入临时库；成稿端固定在每天早上7点触发，取过去24小时的数据做处理。

为什么是24小时而不是自然日？因为AI圈的新闻发布有明显的时间分布特征。北美团队的发布集中在我们的深夜到凌晨，如果按自然日切，很多重要发布会被切到两天里，读者体验很差。24小时滚动窗口能保证每天早上看到的都是"最近一整天"的完整信息。

时间窗口的边界处理也有讲究。跨窗口的同一事件，我会在去重层用事件指纹做关联，避免同一条新闻连续两天出现。这个后面在去重部分详细说。

3. 核心处理环节的技术细节

3.1 去重：从URL指纹到语义聚类

去重是整套流程里最容易被低估的环节。我一开始只用URL去重，结果发现同一篇报道被不同源转载时URL完全不同，根本去不掉。后来升级到三级去重，效果才稳定下来。

第一级是URL规范化去重。把URL里的追踪参数、会话ID、排序参数全部剥掉，只保留路径主体，再做哈希。这一步能干掉大约40%的重复。

第二级是标题指纹去重。对标题做分词、去停用词、提取关键词集合，用Jaccard相似度比较。阈值设在0.75，超过就判定为同一事件。这一步再干掉30%左右。

第三级是语义聚类。对前两级没去掉的内容，用轻量级句向量模型做嵌入，按余弦相似度聚类。这一步主要处理"标题不同但讲的是同一件事"的情况，比如"某模型发布新版本"和"某团队推出升级版模型"。

# 语义聚类核心逻辑示意 from sklearn.cluster import DBSCAN import numpy as np def cluster_news(embeddings, eps=0.25, min_samples=1): """ embeddings: 句向量矩阵 eps: 余弦距离阈值，实测0.25比较合适 """ clustering = DBSCAN(eps=eps, min_samples=min_samples, metric='cosine') labels = clustering.fit_predict(embeddings) return labels

参数选择上，eps设0.25是反复调出来的。设太小，同一事件会被拆成多簇；设太大，不相关的内容会被合并。这个值跟嵌入模型的选择强相关，换模型需要重新调。

注意：语义聚类不要追求100%准确。我的目标是"宁可少合并，不要错合并"，因为错合并会把不同事件的信息混在一起，读者一眼就能看出来，信任度直接崩。

3.2 价值排序：多因子打分模型

去重之后，每天还剩30到50条。怎么从中选出最值得看的10条左右？我用的是一个多因子加权打分模型，因子和权重如下。

每个因子归一化到0到1，加权求和得到总分。总分排序后取Top 12进入日报正文，第13到20名进入"简讯"区。

这里重点说信源权威度的动态维护。我给每个源设一个初始分0.7，然后根据历史表现调整：如果某源发布的内容在24小时内被其他权威源交叉验证，加0.02；如果被证伪或出现明显错误，扣0.1。这个分数每周更新一次，避免短期波动影响太大。

领域相关性的匹配用的是关键词表加语义匹配的组合。关键词表覆盖大模型、多模态、Agent、推理优化、训练框架、评测基准等方向，每个方向有权重。语义匹配用嵌入相似度做补充，防止关键词表覆盖不到的新话题被漏掉。

3.3 摘要生成：为什么不用纯自动摘要

日报的每条内容都需要一段摘要。我试过纯自动摘要，效果不理想——要么太短信息量不够，要么太长失去摘要意义。现在的方案是模板化骨架 + 自动填充 + 人工微调。

模板化骨架的意思是，每条摘要必须包含四个要素：谁、做了什么、关键数据、为什么值得关注。自动填充负责从原文里抽取主体、动作和数字，人工微调负责补上"为什么值得关注"这一句。

为什么最后一步要人工？因为"为什么值得关注"需要判断，而判断依赖上下文。比如同样是"某模型在某个基准上提升3个点"，如果这个基准是公认的硬骨头，那3个点就很值钱；如果是已经饱和的基准，那3个点就没那么重要。这种判断目前自动化做不好，人工花30秒补一句，价值远超成本。

# 摘要骨架填充示意 summary_template = "{主体} {动作}，{关键数据}。值得关注的是，{价值判断}。" def fill_summary(entity, action, data, value_judgment): return summary_template.format( entity=entity, action=action, data=data, value_judgment=value_judgment )

实操心得：摘要长度控制在80到120字之间最舒服。低于80字信息量不够，高于120字读者会跳过。这个区间是看了几百条读者反馈后定下来的。

4. 完整实操流程与关键配置

4.1 环境准备与依赖安装

整套系统跑在一台4核8G的云主机上，操作系统用Ubuntu 22.04。为什么选这个配置？因为采集和去重是IO密集型，排序和嵌入是轻量计算，4核8G足够，再高就是浪费。

依赖清单如下：

# 核心依赖 pip install feedparser requests beautifulsoup4 pip install sentence-transformers scikit-learn numpy pandas pip install apscheduler pyyaml # 可选：如果要做本地嵌入加速 pip install onnxruntime

嵌入模型我选的是轻量级多语言模型，参数量在100M左右。为什么不用更大的？因为日报场景对嵌入精度要求不高，聚类和相关性匹配用轻量模型完全够，而且推理速度快，单条处理时间在50毫秒以内。

4.2 采集任务的调度配置

调度用APScheduler，配置如下：

from apscheduler.schedulers.blocking import BlockingScheduler scheduler = BlockingScheduler() # 采集任务：每30分钟一次 scheduler.add_job( collect_all_sources, 'interval', minutes=30, id='collect_job', max_instances=1 ) # 成稿任务：每天早上7点 scheduler.add_job( generate_daily_report, 'cron', hour=7, minute=0, id='report_job' ) scheduler.start()

max_instances=1这个参数很关键。我踩过一次坑：某次采集任务因为网络问题卡住，下一次调度又启动了新实例，结果两个实例同时写库，数据出现重复。加上这个限制后，同一任务永远只有一个实例在跑。

4.3 去重与排序的串联执行

成稿任务触发后，执行顺序是固定的：先取数据，再去重，再打分，最后生成摘要。每一步的输出都落盘，方便出问题时回溯。

def generate_daily_report(): # 1. 取过去24小时数据 raw_items = fetch_recent_items(hours=24) # 2. 三级去重 deduped = dedup_by_url(raw_items) deduped = dedup_by_title(deduped) deduped = dedup_by_semantic(deduped) # 3. 多因子打分 scored = score_items(deduped) # 4. 取Top N top_items = sorted(scored, key=lambda x: x['score'], reverse=True)[:12] # 5. 生成摘要 report = build_report(top_items) # 6. 落盘 save_report(report)

每一步的中间结果我都会保留7天。为什么是7天？因为大部分问题在3天内会被发现，7天足够排查，再长就是浪费存储。

4.4 日报成稿的排版规则

最终输出的日报有固定结构：头条区、重点区、简讯区、观察区。头条区放1到2条当天最重要的；重点区放5到6条有实质内容的；简讯区放3到4条一句话能说清的；观察区放1到2条趋势性判断。

为什么要有观察区？因为纯事实罗列读者只能看到"点"，看不到"线"。观察区的作用是把当天几条相关信息串起来，给一个轻量的趋势判断。这部分完全靠人工写，每天花10到15分钟。

提示：观察区不要写太长，150字以内。写长了就变成评论文章，偏离日报定位。

5. 常见问题与排查技巧

5.1 采集端典型问题速查

采集端最常见的问题是源站改版。我的经验是，每个源都要有备用采集方案。RSS失效就切页面监控，页面结构变了就用XPath兜底。这套冗余设计让我这两年几乎没有因为单源问题断过日报。

5.2 去重环节的误判处理

去重最怕两种误判：该合的没合和不该合的合了。

该合的没合，表现为同一条新闻出现两次。排查方法是看两条内容的标题相似度和嵌入距离，如果都接近阈值但没触发，说明阈值设高了。我的处理是把阈值下调0.05，观察一周。

不该合的合了，表现为两条不同新闻被合并成一条。这个更严重，因为会丢信息。排查方法是看聚类结果里同一簇的内容，如果发现主题明显不同，说明阈值设低了。处理是上调0.05。

实操心得：阈值调整一次只动0.05，动完观察至少三天。我见过有人一次调0.2，结果整个去重逻辑崩掉，回滚都来不及。

5.3 排序结果的偏差修正

排序偏差通常表现为某类内容长期霸榜或长期缺席。比如有一段时间我发现"融资类"新闻总是排前面，但读者反馈说更想看技术进展。排查后发现是"话题热度"因子里，融资新闻的跨源出现次数天然就高，导致权重被放大。

修正方法是给不同类别设类别配额。比如技术类至少占40%，产品类不超过30%，融资类不超过20%。配额不是硬性截断，而是在打分时给超出配额的类别一个惩罚系数。

def apply_category_quota(scored_items, quota): """ quota: {'tech': 0.4, 'product': 0.3, 'funding': 0.2, 'other': 0.1} """ category_counts = {} for item in scored_items: cat = item['category'] category_counts[cat] = category_counts.get(cat, 0) + 1 total = len(scored_items) for item in scored_items: cat = item['category'] actual_ratio = category_counts[cat] / total if actual_ratio > quota.get(cat, 0.1): item['score'] *= 0.85 # 惩罚系数 return scored_items

惩罚系数0.85是试出来的。太低没效果，太高会把好内容也压下去。

5.4 摘要质量的把控要点

摘要最容易出的问题是信息失真。自动抽取的数字或主体搞错了，读者一看就发现问题。我的做法是加一道数字校验：摘要里出现的所有数字，必须能在原文里找到对应。找不到就标红，人工确认。

另一个问题是价值判断空洞。比如"值得关注的是，这标志着重要进展"——这种话等于没说。我的标准是，价值判断必须包含至少一个具体维度：是性能提升、成本下降、能力扩展，还是生态影响。写不出具体维度，就说明这条内容可能不值得进日报。

6. 让日报真正有用的几个经验

6.1 读者反馈的收集与利用

日报做出来是给人看的，所以反馈必须收集。我在日报末尾放了一个极简的反馈入口，只有两个选项："有用"和"没用"。为什么不做更细的评分？因为读者懒，选项越多越没人填。两个选项的填写率是五档评分的三倍以上。

收集到的反馈怎么用？每周统计一次，看哪些类型的内容"没用"比例高。如果某类内容连续两周"没用"超过30%，就降低它的排序权重。这个机制让日报的内容结构能跟着读者需求慢慢演化，而不是我拍脑袋决定。

6.2 人工介入的边界

整套系统自动化程度不低，但人工介入是必须的。我的原则是：机器负责"筛"，人负责"判"。筛选、去重、排序、摘要骨架填充，这些交给机器；价值判断、趋势观察、最终成稿的取舍，这些交给人。

人工介入的时间控制在每天早上30到45分钟。超过这个时间，说明自动化环节出了问题，要去排查而不是硬扛。我见过有人每天花三小时手工整理日报，那不是做系统，那是做苦力。

6.3 长期维护的节奏

这套系统不是搭完就一劳永逸的。信源会失效，模型会过时，读者口味会变。我的维护节奏是：每周小调，每月大调，每季度重构一次。

每周小调是看反馈数据，微调权重和阈值。每月大调是检查信源清单，替换掉失效或低质的源。每季度重构是看整体架构有没有需要升级的地方，比如嵌入模型要不要换、打分因子要不要加。

这个节奏跑下来，系统一直保持在一个"够用且不臃肿"的状态。我不追求完美，追求的是每天早上七点能稳定产出一份我自己愿意看的日报。

6.4 一个容易被忽略的细节：时区处理

最后说一个特别容易踩的坑：时区。AI新闻是全球性的，如果时区处理不对，会出现"昨天的新闻今天才出现"或者"今天的新闻被算到明天"的问题。我的做法是所有时间戳统一存UTC，只在最终展示时转成目标时区。这个规则听起来简单，但我在早期因为混用本地时间和UTC，导致去重逻辑判断错误，同一事件被当成两天的事件处理，连续一周日报都有重复内容。后来统一成UTC存储，问题再没出现过。

注意：如果你的读者分布在不同时区，日报的"日期"定义要明确。我的做法是以目标读者主要所在时区的自然日为准，采集窗口仍然是24小时滚动，但成稿时的日期标签按目标时区标注。

这套AI日报的流程，从最初的手工整理到现在半自动化，前后迭代了大概七八个版本。每个版本的改进都来自实际使用中遇到的问题，而不是预先设计出来的。如果你也想做一份自己的日报，我的建议是先从最简单的版本跑起来，哪怕每天只聚合5个源、只输出3条内容，先跑通再优化。系统是在使用中长出来的，不是在设计图上画出来的。