企业官网建设流程全解析

1. 从“手动刷新闻”到“机器人替我值班”

先说个直白的问题：你每天到底花多少时间在刷新闻上？我算过自己的用量，早高峰地铁刷一遍、午饭边吃边刷一遍、睡前又忍不住瞟几眼，表面上是在“了解信息”，实际上一大半时间都耗在了重复内容、标题党和水文上。后来我索性做了个自动化新闻推送的小系统，让机器人和AI帮我值班，连续跑了五日，每天只花十分钟左右做人工复核，其他时间都是程序在处理。这篇文章就把这五天的真实观察和踩坑记录完整拆给你看。

这个项目本身不复杂，核心就四件事：定时抓取信息源、用规则和AI做内容筛选、生成适合快速阅读的推送摘要、通过推送机器人发到我常用的聊天入口里。它适合所有对信息获取效率有要求的人，尤其是工作里需要盯行业动态、竞品消息、政策更新但没有专门舆情团队的人。你不用会写很复杂的代码，今天这套方案里用的东西基本都是开源工具加一个AI接口，只要你愿意动手，两三个小时就能搭出一个能跑的版本。

之所以强调“五日观察”，是因为我特别想验证一件事：自动化方案跑起来之后，到底是省心了还是反而制造了新麻烦？第一天我会觉得推送很新鲜，第二天开始嫌弃它推得太杂，第三天发现过滤规则不够灵光，第四天开始跟AI摘要较劲，第五天才勉强找到那个平衡点。这个过程比最终成品本身更有参考价值，因为你迟早会遇到同样的问题。

2. 方案选型：为什么是“RSS抓取 + 规则过滤 + AI改写 + 机器人推送”

2.1 四个环节各自解决什么问题

整个自动推送链路可以拆成四段，每一段都有明确的职责边界。第一段是信息采集，要解决“内容从哪来”的问题。我没有直接去写爬虫抓各种新闻网站，因为新闻站的HTML结构动不动就改，维护成本太高，我选的是RSS源加少量定向爬虫的组合。RSS的好处是格式标准、更新及时、几乎不需要额外解析逻辑，你需要的只是维护一份可靠的信息源清单。

第二段是内容筛选，要解决“什么值得推”的问题。这一步我用的是分层策略：先做硬性规则过滤，比如标题或正文里必须出现哪些关键词、来源域名是不是在白名单里、是否命中排除词；再交给AI做一次质量评估，让模型判断这条内容是和目标主题强相关、弱相关还是不相关。硬规则负责拦住明显没用的，AI负责处理那些规则说不清楚的模糊情况。

第三段是内容改写，要解决“用户要花多久才能读完”的问题。一条原始新闻稿动辄几百上千字，不适合直接扔到聊天窗口里刷屏。我调用了AI接口做摘要生成和要点提炼，让模型输出三到五行的精简版本，保留时间、主体、核心数据、影响判断这四个要素。这一环节最考验提示词设计，因为模型不理解你的“信息偏好”，你得把偏好说清楚。

第四段是推送触达，要解决“东西送到哪”的问题。我试过邮件、自建网页和即时通讯机器人三种渠道，最终用的是即时通讯机器人，因为它有主动推送能力，不依赖用户主动打开页面，而且接口封装成熟。这一段的重点反而在频率控制和消息格式上，不是技术难度，而是你怎么设计才能不打扰自己。

信息采集、内容筛选、内容改写、推送触达这四个环节是标准的数据管道结构。每一段都解耦，单独改某一环不影响其他环节，这是我当时做技术选型时最看重的事。

2.2 技术栈清单与选型理由

具体用到的工具和库我列一张表，都是社区里验证过的成熟方案，你不一定照抄，但可以当个起点参考。

这个组合的核心逻辑是：能不用重型组件就不用，所有环节尽量做成可以独立测试的小函数。很多人的自动化项目最后烂尾，不是因为代码写不出来，而是因为一开始引入了太多自己不熟悉的基础设施，出了问题都不知道去哪个环节排查。我的原则是，哪怕技术土一点，只要我能完全掌控它，它就是好方案。

3. 核心实现拆解：从采集到推送的每一个关键点

3.1 信息源配置：决定你推送质量的上限

信息源是整个自动化的源头，也是最容易被低估的一环。我第一天搭建的时候随手加了二十多个RSS源，结果第一个小时就发现问题——有些源看起来是科技新闻，实际上一半内容都是软文；有些源更新频率极低，三天才有一条；还有些源直接是垃圾站，靠标题党蹭流量。这些噪声会顺着管道一路流到你的聊天窗口里，AI再聪明也挡不住源头的水质太差。

我最终把信息源分成了三类：核心源、扩展源、临时源。核心源是那些我每一条都不想错过的，数量控制在五个以内；扩展源是内容质量尚可但偶尔有噪声的，数量控制在十个左右；临时源是用来测试新主题的，跑两三天就评估一次，符合预期才转正。分类之后，我在代码里给每个源打上标签，后续的过滤规则可以直接引用这个标签，比如核心源的推送阈值可以放宽一些，扩展源的阈值就得收紧。

选源的判断标准我总结成三条：第一，这个源的历史文章标题里，真正跟我的目标主题相关的比例有没有超过一半；第二，它过去一周的更新频率是不是稳定在一个合理区间；第三，这个源的内容是否经常被其他信源重复转载，如果一个链接在多个源里反复出现，说明它虽然重要但不需要所有源都订阅。实际操作上，我建议你用脚本把每个源最近几十篇文章的标题和URL拉下来，人工扫一眼就够了，不用做很精确的统计，感觉不对就直接踢掉。

3.2 抓取模块与增量更新：别让你的机器人重复劳动

抓取模块要解决两个问题：怎么避免重复抓取，以及怎么高效识别新内容。我用的是最朴素的方案，每篇新闻的完整URL作为唯一标识存在SQLite里，入库之前先查重，遇到过就直接跳过。有些RSS源会在文章更新时改变URL，这时候就得退一步用标题加发布时间来联合判断是不是同一条新闻。

解析RSS的时候有一个容易忽略的坑：不同源的字段命名和内容格式差别很大，有的源在summary字段里给你全文，有的只给一段摘要，有的甚至直接把图片链接混在summary里。我的解析函数里做了一堆容错处理，比如对必填字段做缺失值补全，对HTML标签做清理转换，对整个条目做异常捕获，单条解析失败不能影响整批抓取。开发的时候看起来这些是很琐碎的事，但在持续运行五天的场景里，这些琐碎恰恰是最容易出问题的地方。

增量更新的调度我用了最老实的办法：脚本每隔十分钟检查一次配置里的所有源，如果超过对应源的刷新间隔就抓一轮。没有用消息队列，也没有用分布式调度，因为单机单进程完全够用。这里有一个取舍逻辑：很多人喜欢一开始就上个看起来高大上的架构，但新闻推送这个场景对实时性要求并不极端，十分钟的延迟完全感知不到，反倒是架构复杂度带来的维护成本是实打实的。

注意：抓取请求一定要设置合理的超时时间和重试次数。我遇到过某个源响应超时把整个循环卡死的情况，后来给每个请求都加了超时限制和失败重试，才彻底解决。

3.3 过滤策略：硬规则负责拦截，AI负责判断

硬规则过滤我用的是关键词表和正则表达式的组合。关键词表分为正向词和负向词，正向词用于决定“这类内容我要”，负向词用于决定“这类内容我坚决不要”。判断逻辑是：标题或正文里出现了任意一个正向词，且没有命中负向词，这条内容才会进入下一轮。正则表达式主要用于处理一些更精确的模式，比如版本号、股票代码、特定机构的名称变体。

这个阶段有一个值得注意的设计：规则的输出不应该只是“过或不过”，还应该输出命中的关键词和命中的规则ID，这些信息会跟着这条新闻的完整记录存到数据库里。这样一来，即使某条内容最终被推送了但你觉得不想要，也可以回溯到底是因为哪个关键词放它进来了，方便后续调整规则。这种做法听起来很简单，但实际用的时候你就知道它有多重要。

过了硬规则的内容会带着一个结构化摘要数据进入AI判断环节。我给AI的提示词会让它输出一个JSON结构，包含三个字段：主题相关性评分（一到五分）、简要理由、是否需要人工复核。评分三到四分的进入推送队列，五分直接推送，两分以下的丢弃，恰好两分或模型自己拿不准的标为待复核。这套逻辑跑下来，AI的准确率比纯规则高不少，尤其能拦住那些“标题里有科技两个字但实际上是个广告”的内容。

3.4 AI摘要生成：把千字长文压缩成五句话

AI摘要是我花时间最多的地方。刚开始我就是简单地在提示词里写“请总结以下新闻”，结果模型输出的内容经常是“该新闻报道了……”这种毫无信息量的废话。后来我把提示词改成了一套明确的输出规范，要求必须包含事件主体、时间节点、核心数据、关键影响这四个要素，且每条要点都用短句表达，不要用“此外”“与此同时”这种连接词开头。改成这个格式之后，推送的可读性提升了至少一个档次。

摘要生成还要考虑成本问题。AI是按token计费的，如果每条新闻都把正文全文发给模型，成本会快速累积。我的优化方案是：先取正文的前五百字，加上标题，拼成摘要生成的输入文本。五百字对绝大多数新闻来说已经能覆盖核心信息，而token消耗比发全文少了好几倍。如果你发现某些内容确实需要更完整的理解，再单独走一条“深度摘要通道”，不要所有内容统一处理。

提示词里我还加了一个指令，让模型对不确定的事件标注“待核实”。因为新闻摘要传播错误信息比不推送更可怕，模型如果遇到信息矛盾或明显不符合常识的数据，宁可标出来也别擅自采用。这一条对于任何做自动化信息分发的人来说都值得参考。

3.5 推送模块：消息格式与去重节奏

推送模块用的是即时通讯工具的企业机器人Webhook，每次推送就是一次普通的HTTP POST请求。Webhook设计得极其简单，只需要你把消息内容拼成JSON发给一个固定的URL，就能在人家的客户端里收到一条富文本通知。我在消息格式上做了一点设计：标题加粗、摘要内容按行排列、末尾附上原文链接和来源名称。

消息去重不只是内容层面的，还有节奏层面的。我设置了两个推送时间窗：工作日早上八点到九点推一次“早间聚焦”，中午十二点到一点推一次“午间速览”，下午六点到七点推一次“傍晚要点”。每一个时间窗内最多推送五条，超过五条就先存在队列里等下一个窗口。这个设计是为了避免把聊天窗口淹没在连续不断的推送里，信息密度比数量更重要。

到这里，整个自动化的主体结构已经搭完了。但说实话，搭完那一刻只是万里长征第一步，接下来的连续五天运行才是真正的考验。你会看到那些只在文档里出现的异常情况，一个接一个地冒出来。

4. 五日观察实录：每天遇到什么问题、又是怎么修好的

4.1 第一天：管道通了，但推送的东西没法看

第一天是最兴奋的，因为整个流程从抓取到推送第一次完整跑通。我早上起来看到企业机器人发来的第一条推送时还挺有成就感，但坐下来仔细看内容就发现问题了：五条里有两条是跟主题几乎没关系的泛科技新闻，一条是不知道从哪个博客源抓来的个人观点文章，真正符合预期的只有两条。

我去翻数据库里的记录，发现噪声几乎都来自那批“扩展源”。这些源本身不是完全不相关，但它们的内容范围比我设想的要杂很多。比如某个源平时聊硬件评测不错，可它偶尔也会发一篇跟生活有关的软文，标题里确实含有关键词，但内容完全是另一回事。硬规则过滤对这种情况无能为力，而AI判断那一轮我用的相关性评分阈值又设得太宽松，才让这些东西混了进来。

当天的修复动作有两个：一是把扩展源里最差的几个直接停用，宁缺毋滥；二是把AI判断的推送阈值从“三分以上推”改成“四到五分推，三分暂存”。我还顺手在代码里加了一个“暂存区”，那些被AI判为三分的内容不会推送，但会留在数据库里，第二天可以人工复核一遍，看是不是值得调整规则。

第一天最大的收获是明白了什么叫“管道通了，不代表产品能用了”。自动化只是把问题从“花时间找新闻”变成了“处理噪声推送”，你的人工精力只是从一个环节转移到了另一个环节。

4.2 第二天：重复内容开始刷屏

第二天的问题比第一天更烦人：重复内容开始刷屏。不是同一篇文章被抓了两次那么简单的重复，而是同一家公司的同一款产品，被五六个科技媒体同时报道。每篇报道的标题措辞都不一样，内容角度也略有差异，但它们本质上说的是同一件事。如果你不做交叉比对，就会在一天里收到好几条“看起来是新消息，实际上是旧消息”的推送。

这个是新闻推流场景里最经典的难题，行业里的专门术语叫“事件聚类”。我当天的处理方案比较朴素但有效：从数据库里拉出过去二十四小时内的所有推送记录，对标题做简单清洗，去掉标点、空格、常见停用词和“重磅”“突发”这些高频修饰词，然后计算两两之间的字符相似度。相似度超过一个阈值就认为是同一事件的重复报道，只保留最早出现的一条，后续相似内容直接丢弃。

我用的相似度算法不是那种高深的向量模型，就是最简单的字符级重合率，俗称编辑距离变体。因为中文字符本身就是语义的基本单位，标题清洗之后再算重合率，已经完全够用。你也完全不需要引入向量数据库或者做embedding，那是给百万级语料用的玩法，个人项目用不上。

这个去重逻辑里面有一个细节要小心：如果报道确实有实质性的新信息，比如原来是传闻，今天发了官方确认，那它们虽然相似但应该分开推送。我的处理方式是把相似度判断结果分三档：高度相似直接丢弃；中度相似保留但标记为“跟进报道”；低度相似视为新事件。跟进报道不会被主动推送，只会记录在当天晚间的观察简报里。

4.3 第三天：AI开始“一本正经地胡说八道”

第三天的问题让我折腾了一整天：AI摘要开始出现事实性错误。我翻到一条推送，原文标题说的是某家公司营收同比增长了百分之十五，但AI摘要里写成了“利润翻倍”。这种错误特别危险，因为它不是你一眼就能识破的明显错误，而是那种“好像有点不对但不确定哪里不对”的微妙偏差。一旦推送出去，影响的是你对整条消息的信任感。

我去检查提示词和模型参数，发现核心问题出在我只给了模型五百字的正文输入，而这五百字里包含的上下文信息有限。模型在信息不足的情况下会自动“脑补”一些它认为合理的内容，这种脑补在生成摘要时尤其可怕。解决办法是给提示词加上强约束：必须严格基于给定文本，禁止推理或联想；如果原文没给出具体数值或结论，对应字段就写“原文未提及”。同时把模型温度参数调低到接近零，让它尽量选择高概率的确定性输出而不是创造性输出。

另外我加了一道“摘要反向校验”逻辑：让模型在生成摘要的同时，把支撑摘要的原文关键句子摘录出来。后续脚本会检查这些关键句子是否真的出现在原文里。如果摘录的句子在原文里找不到，就说明模型在编造内容，这条摘要会被自动丢弃并标记为异常。这套反向校验虽然不能揪出所有错误，但能挡住很大一部分“编造原文没有的事实”的情况。

经过这一天的折腾，我意识到一个重要原则：AI摘要这玩意只适合当人脑的辅助速读工具，不适合当唯一的信息来源。所以我在推送消息的底部加了一行提示：以上内容由AI生成，仅供参考，详情请点原文链接。这不是免责声明，而是防止你在刷牙的时候把一条错误信息当成了既定事实。

4.4 第四天：信息源本身开始“生病”

第四天遇到的问题不是我的代码出问题，而是外部信息源开始“生病”。有两个RSS源内容停更了，还有一个源突然改了输出的HTML结构，导致解析出来的正文全是乱码。这类问题最讨厌的地方在于：你的脚本完全正常，它每天都在按时运行，但它抓进来的东西质量已经变了，而你不看数据库根本发现不了。

当天加了一个“信息源健康度监控”模块。每次抓取完成之后，脚本会统计这个源最近的抓取成功率、内容平均长度、文章平均间隔时长，跟历史数据做对比。如果某个源连续几轮抓取的内容为空、或者返回的文章长度异常地短、或者更新时间间隔突然比历史平均值拉长了好几倍，脚本就会打一条健康告警，提示我人工去检查那个源。告警不发到聊天推送群，而是单独发到另一个运维通知群里，避免跟正常的新闻推送混在一起。

对于那个内容停更的问题，我的处理是：如果某个源连续两天没有任何新文章，就先把它移出活跃源列表，等它恢复更新了再重新加回来。很多RSS源就是这样，维护者可能忙别的事情去了。你如果一直等它，其实也没什么帮助。不如移出列表，让活跃源保持在一个可控的规模内。

跟信息源“生病”紧密相关的还有一个小坑：时区。有些源用的是UTC时间，有些是北京时间，还有的是美国东部时间。如果你在筛选时依赖文章发布时间做“最近二十四小时”的判断，就一定要统一先转成时间戳再做比较。我项目里最初的版本没做这个统一，结果有一类源的内容因为时区偏移总是被当成“过期内容”丢弃，白白丢了好几条有价值的信息。

4.5 第五天：规则越来越细，我开始动手优化体验

到了第五天，稳定性已经有了一定保障，噪声减少了很多，重复内容也基本被挡住了。这时候我开始琢磨体验层面的优化，而不是继续加过滤规则。因为我知道如果规则继续叠加下去，迟早会走到另一个极端：什么都不推，那自动化也就没什么意义了。

第一处体验优化是给推送内容加“标签分类”。推送给用户的消息里，每条标题前面加上一个小标签，比如[行业动态][产品发布][观点评论][政策解读]。这样你在快速滑动聊天记录的时候，就能立刻判断哪条值得点开、哪条可以跳过，不用每条都读一遍摘要才能知道它是什么。标签的来源有两种：规则命中的关键词映射，以及AI判断返回时的分类字段。

第二处体验优化是增加“早间简报”汇总模式。除了整点推送单条新闻之外，每天早上会额外生成一条简报，把过去二十四小时的所有内容按主题分组汇总，你可以花三分钟扫一眼简报，再做决定要不要细看。这就相当于把“推送频次”和“信息密度”做了分层，高频低密度的单条推送适合随时随地快速扫读，低频高密度的汇总简报适合早晨坐在工位前的深度浏览。

第三处优化是启用“相似主题聚合”功能。基于文本相似度，把同一事件的不同角度的多篇报道，折叠到一条推送消息里，用“多条角度”的形式展示。比如某大厂发布了一款新手机，推广硬件配置的那篇是一个角度，深挖产业影响的另一个角度，其他几篇则没有足够的新信息。折叠之后，你看到的不是五条相似的推送，而是“一条事件卡片+两个不同的解读角度”，信息广度还在，但阅读量大幅下降。

五天的运行结束之后，我给这个项目做了个统计：每天平均抓取原始信息约一百二十条，经过规则过滤后剩二十五条，经过AI判断后剩十条，经过去重和事件聚合之后推荐的条数是六到七条，其中真正被标记为“值得细读”的大约占一半。这个漏斗数据让我很满意，因为它说明整个系统不是一条直线从抓取到推送，而是每经过一层处理就在帮你做一次注意力筛选。

5. 常见问题与排查技巧实录：那些让你头秃的瞬间

5.1 抓取环节的典型问题速查表

这个表中第二行值得多说一点。很多RSS源提供的内容摘要有长有短，短的甚至只有一句话。如果你是把这一句话拿去做AI摘要输入，那质量肯定很差。我的处理方式是根据文章链接再去抓取页面正文，把RSS里的summary当作索引而不是内容本体。当然这需要你额外写一个网页正文提取逻辑，属于爬虫的范畴。如果觉得麻烦，也可以直接用现有的开源正文提取库，比自己写正则靠谱得多。

还有一个小细节：写抓取脚本的时候，请在代码里给每个源留一个单独的处理函数入口，不要写一个万能的通用抓取函数去套所有源。因为新闻源的多样性远超你的想象，有的源返回XML，有的返回JSON，有的虽然是RSS但字段不规则。虽然大部分逻辑可以共用，但你一定会遇到需要针对某个特定源特殊处理的情况。预留这个入口，以后加新源会容易得多。

5.2 规则过滤与AI判断的调参心得

规则过滤最核心的经验是：规则要控制在“能数得过来”的程度。如果你发现自己的关键词表膨胀到上百个词、正则写了几十条，那系统大概率已经变成了一坨补丁，每加一条规则都在试图弥补上一条规则带来的误伤。这种情况下，正确的做法不是继续加规则，而是停下来问自己：是不是信号源本身就该清理了？

在AI判断这一环，我调过的最关键参数是“相关性评分的基准线”。这个基准线没有标准答案，完全取决于你对噪声的容忍度。如果你希望推送纯度高，就把阈值调到四以上，代价是可能漏掉一些相关度中等的好内容；如果你更怕漏掉重要消息，阈值可以放宽到三，代价是噪声更多。我在跑了几天之后把阈值设置在“三点五”，并且给每个刚进入推送队列的内容都设置了“观察期”，如果在观察期内被手动删除过，后续相似内容会自动降权。

另外建议把AI返回的原始结果完整保存到数据库里。不只是保留最终摘要，而是把模型返回的完整JSON、相关性评分、模型认为的关键句子都存下来。这样当你对某条推送不满的时候，可以翻出原始输出，看到底是模型判断错了，还是你提供的信息不够。这个过程非常有助于迭代你的提示词。

5.3 推送渠道的避坑注意事项

推送渠道是最容易触发“劝退感”的环节。第一个坑是消息长度限制。不同即时通讯工具的机器人接口对单条消息长度有不同限制，如果你把AI生成的长文摘要直接塞进去，很可能被接口拒绝。我的处理方式是先做一段字符数检查，超限就截断，并在消息末尾加上原文链接。摘要本来就不需要完整，点到为止即可。

第二个坑是推送频率限制。大多数企业机器人接口不是无限次给你调用的，短时间频繁调用会被限流。我在推送队列里增加了一个平滑机制：每次推送之间至少间隔三十秒，且每个推送窗口的总条数上限是五条。这个机制直接避免了“连续推送十几条然后被限流半小时”的尴尬场景。

第三个坑是消息格式兼容性。同一个消息内容，在企业机器人的客户端里显示正常，但换个客户端可能就乱了。我在格式上追求极简、少用复杂样式，只用加粗和换行，不在消息里嵌套图片或外部链接预览。宁可在视觉上朴素一点，也要确保在任何一个客户端上都能正常阅读。

6. 这套自动化还能往哪些方向扩展

五天观察做完之后，这个系统已经充分融入了我的日常工作流里。但我也知道目前这套东西还有明显的边界，比如它只能处理“信息推送”，不能处理“信息决策”。如果我需要的不只是把新闻送到眼前，还要它帮我判断“这条新闻跟我的某个具体项目有什么关系”，那就不能只做五天的方案了，而是要引入更细粒度的实体识别和关系网络分析。

最简单的扩展方向是增加“个人关注实体库”。把你在意的一批公司名、产品名、人名、机构名填进一个清单里，让AI在摘要之外额外输出“涉及实体”字段，然后脚本负责匹配实体库。凡是命中重点关注实体库的内容，推送权重自动提高，消息里额外标出命中的实体名称。这个扩展几乎不需要改动现有架构，只是多加了一个字段和一条匹配逻辑。

再往下扩展就是“用户反馈回路”。目前系统的过滤逻辑是单向的，你只能在事后手动决定一些内容不想要。更好的设计是让每一次人工操作都成为一次训练信号：你点开了一篇推送说明这类内容权重应该上调，你忽略了一篇推送说明权重适当下调，你手动删除了某篇说明它的来源或关键词需要降权。把这些信号回填到规则表里，系统的个性化程度会越用越高。

还有一个方向是“跨天趋势对比”。当前所有推送都是单日窗口，看不到消息面和情绪面的变化。如果你把每天的推送摘要和关键词频次存成历史序列，就能得到一些粗浅的“趋势指标”。比如某个关键词在三天内频次持续上升，大概率是有事情正在发酵。这种信号对于投资决策、市场研究和竞争情报场景特别有价值，我已经在尝试给系统加这层能力。

我自己后面还准备做的一件事是把订阅源的管理界面化。现在改一个信号源清单都要手改配置文件，虽然不麻烦，但让一些不太懂技术的人用它就有了门槛。如果做一个简单的本地网页，用表单来管理源和规则，那这个系统就能从一个个人工具变成可以推荐给同事用的协作工具了。

做自动化信息推送这件事，真正困难的从来不是写代码和接接口，而是找到一套让你自己舒服的“信息接收节奏”。机器的优势是稳定、快速、不抱怨，但它不理解你的真实需求，所以得靠你一点一点把需求翻译成规则和提示词。这五天的观察让我深刻体会到一件事：自动化不是用来替代你的判断力的，它是用来保护你的注意力的。你省下来的那些刷新闻的时间，应该花在你真正认为重要的事情上。