企业官网建设流程全解析

1. 当"日报"变成"日更"：一个内容聚合项目的起点

做内容的人都有一个共同的痛点：信息太多，时间太少。每天打开各种信息流，光是筛选"今天到底发生了什么值得关注的事"就要花掉一两个小时，等筛完了，写稿的精力也没了一半。我身边不少做科技媒体、行业分析、投资研究的朋友，都在这件事上反复消耗。于是从去年开始，我陆续折腾了一套自动化程度比较高的"AI日报"生成流程，每天定时跑一遍，把当天值得看的AI领域动态聚合成一份结构化的日报，人工只需要做最后的审核和微调。这套流程跑了大半年，中间踩过的坑、换过的方案、推翻重来的架构设计，攒了不少经验，今天借这个标题把它完整拆一遍。

先说清楚这套东西到底是什么。它不是一个简单的RSS阅读器，也不是把几个网站的内容抓下来拼在一起就完事。核心目标有三个：第一，信息源的覆盖要足够广，不能只盯着三五家媒体，否则日报会变成"某几家公司的传声筒"；第二，去重和聚类要做得足够好，同一件事被十家媒体报道，日报里只能出现一次，而且要把最完整的信息整合进来；第三，摘要要能看，不能是简单的截断或者机器翻译腔，得让人读起来像人写的。这三点听起来简单，真做起来每一环都有大量细节要处理。

适合谁来参考这套方案？我觉得有三类人。一类是做内容运营或者媒体编辑的，每天需要产出行业简报、资讯汇总；一类是做行业研究或者投资分析的，需要持续跟踪某个领域的动态；还有一类是纯粹的技术爱好者，想自己搭一套信息聚合系统练手。不管你是哪一类，这套流程的架构思路和踩坑经验都能直接拿去用，代码层面需要根据自己的技术栈做适配，但核心逻辑是通用的。

下面我会从信息源管理、抓取与清洗、去重聚类、摘要生成、日报排版与分发这几个环节逐一展开，每个环节都会讲清楚"为什么这么设计"以及"实际跑起来会遇到什么问题"。文章会比较长，但都是实打实跑出来的经验，不是纸上谈兵。

2. 信息源管理：日报质量的天花板在这里就定死了

2.1 为什么信息源不能"抓到什么算什么"

很多人搭这类系统的第一反应是：找几个RSS源，配个定时任务，抓下来就完事。我一开始也是这么干的，结果第一版日报跑出来，满屏都是重复内容，而且大量低质量的信息混在里面，根本没法看。问题出在信息源的管理上——你喂给系统的原料质量，直接决定了日报的质量上限。

信息源管理要解决三个问题：覆盖度、信噪比、稳定性。覆盖度是指你的源要能覆盖到行业的主要动态，不能有大的盲区；信噪比是指源里有效信息的比例要高，不能抓一百条只有三条能用；稳定性是指源的格式和可访问性要相对稳定，不能今天能抓明天就挂了。这三个问题里，覆盖度和信噪比是矛盾的——覆盖越广，信噪比往往越低。所以我的做法是分层管理：把信息源分成核心层、扩展层和观察层三层。

核心层是那些质量稳定、更新频率高、信噪比好的源，比如几个头部科技媒体的AI频道、几个主要AI公司的官方博客、几个高质量的行业通讯。这一层大概控制在15到20个源，是日报内容的主力。扩展层是覆盖面更广但质量参差不齐的源，比如综合科技媒体的AI标签页、一些垂直社区的讨论区、几个聚合平台的热榜。这一层大概30到50个源，用来补充核心层可能遗漏的动态。观察层是一些新出现的、还不确定质量的源，先放进来观察一段时间，表现好就升到扩展层甚至核心层，表现差就踢掉。

2.2 源的健康度监控：不监控就等于没有源

分层管理之后，还需要一套健康度监控机制。我吃过这个亏：有个核心层的源挂了将近两周我才发现，那两周的日报里那个方向的内容明显偏少，但我一直以为是那段时间行业本身没什么大事。后来写了个简单的监控脚本，每天记录每个源的抓取成功率、平均抓取条数、内容去重后的有效条数，一旦某个指标连续几天异常就告警。

监控指标不用太复杂，我实际用的就四个：抓取成功率（HTTP状态码正常的比例）、有效条数（去重后进入候选池的条数）、平均延迟（从源发布到被抓到的时间差）、内容新鲜度（抓到的内容里发布时间在24小时内的比例）。这四个指标里，抓取成功率反映源的可用性，有效条数反映信噪比，平均延迟反映源的更新及时性，内容新鲜度反映源是不是在"炒冷饭"。任何一个指标连续三天低于阈值，就触发告警，人工去检查是源本身的问题还是抓取逻辑的问题。

提示：监控告警不要设得太敏感，否则每天都会被误报打扰。我的经验是抓取成功率低于80%连续三天才告警，有效条数低于历史均值50%连续三天才告警，这样既能发现问题又不会太吵。

2.3 源的动态调整：日报是活的，源也应该是活的

信息源不是配一次就一劳永逸的。行业在变，媒体的更新频率和质量也在变。我现在的做法是每个月做一次源的全量review，看每个源在过去一个月的表现数据，决定是保留、降级还是踢掉。同时每个月会尝试引入三到五个新源，放到观察层跑一个月再看表现。

这个动态调整机制带来的一个额外好处是，日报的内容风格会随着源的调整而自然演化。比如某个阶段我发现某个细分方向（比如AI在医疗领域的应用）的报道明显增多，就会主动去找几个专注这个方向的源加进来，日报在这个方向的覆盖度就会提升。反过来，如果某个方向的源质量普遍下降，日报在这个方向的内容就会自然减少，不会硬凑。

3. 抓取与清洗：脏活累活都在这里

3.1 抓取策略：别用一套逻辑打天下

信息源的类型不一样，抓取策略也得不一样。我实际遇到的主要有三类：标准RSS/Atom源、网页列表页、API接口。标准RSS源最好处理，直接用feedparser之类的库解析就行，但要注意有些源的RSS只输出摘要不输出全文，需要额外去抓正文页。网页列表页最麻烦，每个站点的HTML结构都不一样，得单独写解析规则，而且站点改版就会失效。API接口最稳定，但很多平台不开放，或者有频率限制。

我的做法是优先用RSS，其次用API，最后才用网页解析。RSS虽然有时候内容不全，但格式稳定、解析简单、不容易被封。API虽然稳定但往往有门槛。网页解析是最后的选择，因为维护成本太高。对于必须用网页解析的源，我会把解析规则写成配置文件，而不是硬编码在代码里，这样站点改版时只需要改配置不用改代码。

抓取频率也要根据源的类型来定。新闻类的源更新快，可以15到30分钟抓一次；博客类的源更新慢，一天抓一两次就够了；官方公告类的源更新更慢，一天一次甚至两天一次都行。抓取频率太高不仅浪费资源，还容易被源站限流甚至封禁。我一般会给每个源配一个抓取间隔，然后统一调度。

3.2 正文提取：Readability不是万能的

抓到网页之后，下一步是把正文提取出来。很多人直接用Readability或者类似的库，但实际用下来，Readability在新闻类页面上表现不错，在博客类页面上就经常出问题，要么把评论也提取进来，要么把正文截断。我的做法是Readability打底，加上针对性的规则修正。

具体来说，先用Readability提取一版，然后检查提取结果的几个特征：长度是否合理（太短说明可能截断了，太长说明可能混入了无关内容）、是否包含明显的导航文字或评论特征、段落结构是否完整。如果检查不通过，就用备选方案——要么用站点特定的CSS选择器重新提取，要么用基于文本密度的算法重新识别正文区域。这套组合拳下来，正文提取的准确率能到95%以上。

还有一个容易被忽略的点是编码问题。有些源返回的HTML编码声明和实际编码不一致，直接解析会出现乱码。我的做法是先用chardet之类的库检测实际编码，再和HTML声明比对，不一致就以实际检测为准。这个细节看起来小，但不处理的话日报里会出现乱码，非常影响观感。

3.3 清洗规则：把"噪音"挡在门外

正文提取出来之后，还要做一轮清洗。清洗的目标是去掉那些虽然属于正文但不适合放进日报的内容，比如推广信息、作者简介、相关阅读推荐、版权声明等。这些内容如果不清掉，日报会显得很杂乱。

清洗规则我分成两类：通用规则和站点特定规则。通用规则处理那些普遍存在的噪音，比如以"关注我们""点击这里""阅读原文"开头的段落、包含特定推广关键词的段落、明显是作者简介的段落（通常包含"作者""编辑""来源"等词且长度较短）。站点特定规则处理那些某个站点特有的噪音，比如某个站点的正文末尾总是跟着一段固定的版权声明。

清洗规则要定期review，因为噪音的形式会变化。我一般每两周看一次清洗后的样本，发现新的噪音形式就加规则。但规则也不能加得太激进，否则容易误伤正文。我的原则是宁可漏掉一些噪音，也不要误删正文，因为漏掉的噪音读者能自己忽略，误删的正文会让日报信息不完整。

4. 去重与聚类：同一件事只出现一次

4.1 去重的两个层次：完全重复和近似重复

去重这件事，听起来简单，做起来分两个层次。第一个层次是完全重复，就是两篇文章的正文完全一样或者几乎一样，这种通常是同一篇通稿被多家媒体转载。第二个层次是近似重复，就是两篇文章讲的是同一件事，但措辞和角度不同，这种通常是多家媒体各自报道同一件事。

完全重复好处理，直接算正文的哈希值或者用SimHash之类的算法比对就行。近似重复就麻烦多了，因为两篇文章可能只有部分内容重叠，或者用词完全不同但说的是同一件事。我实际用的方案是两阶段去重：第一阶段用SimHash做快速筛选，把相似度高的文章聚在一起；第二阶段用更精细的相似度算法（比如基于TF-IDF的余弦相似度或者基于句向量的语义相似度）在候选集里做精确比对。

这里有个参数需要调：相似度阈值。阈值太高，近似重复的文章去不掉；阈值太低，不同事情的文章会被误判为重复。我的经验是SimHash的汉明距离阈值设在3到5之间，余弦相似度阈值设在0.75到0.85之间，具体值要根据实际数据调。调的方法是拿一批标注好的数据跑一遍，看准确率和召回率的平衡点在哪里。

4.2 聚类：把"同一件事"的报道归到一起

去重之后，还要做聚类。去重解决的是"两篇文章是不是重复"，聚类解决的是"多篇文章是不是在讲同一件事"。这两件事的区别在于，去重是两两比对，聚类是全局分组。比如某天有三篇文章分别从不同角度报道同一个发布会，去重可能认为它们不重复（因为措辞不同），但聚类应该把它们归到一组。

聚类的算法我用过几种，最后稳定下来的是基于语义向量的层次聚类。具体做法是先用句向量模型把每篇文章的正文编码成一个向量，然后计算向量之间的余弦相似度，用层次聚类把相似度高的文章聚成一类。这个方案的好处是不依赖关键词匹配，能处理"用词完全不同但语义相同"的情况。缺点是计算量比较大，文章多的时候需要做优化。

聚类的粒度也要控制。聚得太粗，不同的事情会被归到一起；聚得太细，同一件事会被拆成好几组。我的做法是先粗聚再细调：先用一个较宽松的阈值做初步聚类，然后人工检查聚类结果，对明显不合理的聚类做合并或拆分，把调整逻辑沉淀成规则。跑一段时间之后，规则越来越完善，需要人工干预的情况就越来越少了。

4.3 组内代表选取：选哪篇放进日报

聚类完成之后，每一组里有多篇文章，日报里只需要放一篇（或者把多篇的信息整合成一篇）。选哪篇？我的标准是信息完整度优先，其次是来源权威性，最后是发布时间。信息完整度是指这篇文章是否包含了事件的核心要素（时间、地点、人物、事件、影响），权威性是指来源是否可靠，发布时间是指是否是最新的。

实际操作中，我会给每篇文章算一个综合分，信息完整度占60%，权威性占25%，发布时间占15%。信息完整度的计算可以用一些启发式规则，比如正文长度、是否包含关键要素词、段落结构是否完整等。权威性可以用源的分层来定，核心层的源权威性高，扩展层次之，观察层最低。发布时间就是越新越好。

有时候一组里没有一篇文章是完整的，需要把多篇的信息整合起来。这种情况我会用一个简单的整合逻辑：以信息最完整的那篇为底稿，把其他篇里独有的信息补充进去。整合的时候要注意去重和逻辑连贯，不能简单拼接。

5. 摘要生成：让日报读起来像人写的

5.1 抽取式摘要和生成式摘要的选择

摘要生成有两条路线：抽取式（从原文里挑句子）和生成式（用模型重新组织语言）。抽取式的好处是不会产生事实错误，因为句子都是从原文里来的；缺点是读起来可能不连贯，而且受限于原文的措辞。生成式的好处是读起来流畅自然；缺点是有可能产生幻觉，编造原文里没有的信息。

我实际用的是混合方案：先用抽取式挑出关键句子，再用生成式模型把这些句子改写成连贯的摘要。这样既保证了事实准确性（关键信息来自原文），又保证了可读性（语言经过重新组织）。改写的时候会给模型明确的指令，要求它只能使用原文中出现的信息，不能添加新信息。

这个方案的关键在于抽取阶段的质量。如果抽取的句子不包含核心信息，改写阶段再厉害也救不回来。我的抽取逻辑是基于位置和关键词的双重打分：位置分看句子在文中的位置（开头和结尾的句子权重高），关键词分看句子是否包含事件的核心要素词。两个分数加权求和，取分数最高的几个句子。

5.2 摘要长度的控制：不是越长越好

摘要长度是个需要仔细调的参数。太短了信息不全，太长了读者没耐心看。我的经验是每条摘要控制在80到150字之间，具体长度根据事件的重要程度调整。重要的事件可以到150字，一般的事件80到100字就够了。

长度控制的方法是在生成阶段给模型明确的字数限制，同时在抽取阶段就控制好输入句子的总长度。如果生成的结果超长，就做一轮压缩；如果太短，就补充一些次要信息。压缩和补充都要基于原文，不能凭空发挥。

还有一个细节是摘要的开头。日报里的摘要如果都以"据悉""据报道"开头，读起来会很单调。我的做法是在生成阶段要求模型用多样化的开头，比如直接以事件主体开头、以时间开头、以影响开头等。这样整份日报读起来会更有节奏感。

5.3 事实一致性检查：防止模型"编故事"

生成式摘要最大的风险是幻觉。模型可能会把原文里的"某公司计划推出某产品"改写成"某公司已经推出某产品"，一字之差，事实完全变了。所以生成之后必须做事实一致性检查。

我的检查方案是关键要素比对：从原文里提取出关键要素（主体、动作、时间、数字等），从摘要里也提取出关键要素，然后比对两者是否一致。如果不一致，就标记出来人工检查。这个方案不能覆盖所有情况，但能抓住大部分明显的事实错误。

除了自动检查，我还会做抽样人工检查。每天随机抽5到10条摘要，人工比对原文，看是否有事实错误或者表述不当。发现的错误会记录下来，用来优化生成阶段的指令和检查规则。这个反馈循环跑一段时间之后，摘要的准确率会明显提升。

6. 日报排版与分发：最后一公里决定阅读体验

6.1 排版结构：让读者三秒找到重点

日报的排版结构直接影响阅读体验。我的日报结构是标题区、要闻区、分类区、简讯区四块。标题区是日报的名称和日期，要闻区是当天最重要的3到5条新闻，分类区是按主题分类的新闻（比如模型发布、产品更新、行业动态、研究进展等），简讯区是那些重要程度一般但值得知道的短消息。

要闻区的选取标准是影响范围乘以事件强度。影响范围是指这件事影响多少人、影响多深，事件强度是指这件事的新颖程度和讨论热度。两个维度都高的进要闻区，只有一个维度高的进分类区，都不高的进简讯区。这个分类逻辑要稳定，不能今天这么分明天那么分，否则读者会困惑。

分类区的分类维度也要固定。我用的分类是：模型与算法、产品与应用、行业与商业、研究与论文、政策与伦理。每个分类下的条目按重要程度排序。分类的数量控制在5到7个，太多了读者看不过来，太少了又不够细。

6.2 分发渠道：不同渠道不同格式

日报做出来之后要分发。不同渠道的格式要求不一样，不能一份内容到处发。我的做法是一份内容，多种格式：Markdown格式用于内部存档和邮件分发，HTML格式用于网页展示，纯文本格式用于即时通讯工具推送，图片格式用于社交媒体分享。

格式转换用模板引擎做，把日报的内容和格式分离。内容用结构化的数据（JSON或者YAML）存储，格式用模板定义。这样改格式的时候不用动内容，改内容的时候不用动格式。模板要针对每个渠道单独设计，比如即时通讯工具的推送要更简洁，社交媒体的图片要更注重视觉效果。

分发的时间也要考虑。我的日报是每天早上8点推送，这个时间点是大部分人的上班路上或者刚到工位的时候，正好需要一份简报来了解昨天发生了什么。推送频率是每天一次，周末也不停，因为AI领域的动态不会因为周末就停下来。

6.3 反馈收集：让读者告诉你哪里不好

日报做出来不是终点，还要收集反馈。我在日报末尾放了一个简单的反馈入口，读者可以标记"这条摘要不准确""这条不该进要闻""这个分类有问题"等。反馈数据会汇总起来，用来优化各个环节的参数和规则。

反馈收集的关键是降低反馈成本。如果让读者写一大段文字反馈，大部分人不会写。我的做法是提供几个预设的反馈选项，读者点一下就行。比如每条摘要旁边有"准确""不准确""信息不全"三个按钮，读者点一下就能反馈。反馈数据积累到一定量之后，就能看出哪些环节需要优化。

除了显式反馈，还有隐式反馈可以收集，比如日报的打开率、每条摘要的阅读时长、分享次数等。这些数据能反映读者的真实兴趣，用来调整要闻区的选取标准和分类区的排序逻辑。显式反馈和隐式反馈结合，优化方向会更准确。

7. 跑了大半年之后，我总结出的几条经验

这套系统从第一版跑到现在，中间大改过三次，小改过无数次。有几条经验是踩了坑之后才明白的，写出来给准备入坑的朋友参考。

第一条是不要追求一步到位。我第一版想做得完美，结果拖了两个月才上线，上线之后发现很多设计在实际数据面前根本不成立。后来改成先跑一个最小可用版本，每天人工检查，发现问题就改，迭代速度反而快得多。现在这套系统是第四版，但如果没有前三版的积累，第四版也做不出来。

第二条是人工审核不能省。我试过完全自动化的方案，结果日报里出现了好几次事实错误，有一次把某公司的融资额写错了一个数量级，差点闹笑话。后来改成自动生成加人工审核，审核时间控制在15分钟以内，既能保证质量又不会太累。审核的重点是事实性错误和重要遗漏，文字表达的小问题可以放过。

第三条是数据比直觉可靠。我一开始凭直觉觉得某些源很重要，结果数据跑出来发现那些源的有效条数很低。反过来，有些我觉得一般的源，数据表现却很好。所以源的调整、参数的调整都要看数据，不能凭感觉。当然数据也不是万能的，有些新源数据还没积累起来，需要人工判断，但至少在有数据的地方要以数据为准。

第四条是系统的价值在于持续运行。这套系统最大的价值不是某一天的日报有多好，而是它能持续不断地运行，每天稳定产出。所以稳定性比先进性重要，一个能稳定跑一年的简单系统，比一个跑一周就挂掉的复杂系统有价值得多。为了稳定性，我在架构上做了很多妥协，比如不用太新的库、不做太复杂的优化、保留人工干预的入口，这些妥协在实际运行中都被证明是值得的。

最后分享一个小的技巧：日报的标题不要用"AI日报"这种泛泛的名字，加上日期和一句当天的亮点，打开率会明显提升。比如"AI日报 2026-10-07：某模型发布新版本，推理成本降了一半"这样的标题，读者一眼就知道今天值不值得看。这个技巧看起来小，但对日报的传播效果影响很大。