企业官网建设流程全解析

我每天早上的固定动作曾经是这样的：先打开十几个资讯源扫一遍，看看有没有新的 AI 产品发布，再把值得关注的几个扔进收藏夹，等晚上有空了挨个点开看。这个流程持续了小半年之后，我终于意识到自己其实是在重复做一件完全没有技术含量的事——搜索、筛选、记录，每一步都是机械劳动。于是某个周末，我给我的智能助理 Hermes 加了一个每日自动执行的任务：让它自己搜索 AI 产品、自己整理摘要、自己把结果推送到指定渠道。现在这条链路已经稳定跑了两个多月，这篇文章就是想完整记录一下我是怎么把"每天早上人工扫信息"这件小事，变成一套由 Hermes 独立完成的自动化流水线的。

如果你手上也有一台能跑脚本的服务器，或者一个自托管的智能体环境，并且每天也要花不少时间在行业信息收集上，那么这篇内容应该能给你一套可以直接参考的落地思路。我会从整体架构讲到每个环节的具体实现，包括搜索源怎么选、摘要提示词怎么设计、推送格式怎么排，以及上线之后踩过的那些坑。

1. 为什么一个"会自己跑任务"的智能体比闹钟提醒更靠谱

1.1 信息过载的真正解法不是"看得更多"，而是"筛得更好"

我最早想解决的问题其实很简单：每天新冒出来的 AI 产品实在太多了。有些是真正的技术突破，有些只是套了一层 AI 壳的普通工具，还有一些干脆是蹭热点的营销页面。如果靠人工一个个点开看，时间成本高不说，还特别容易被标题党带偏。

但"用工具自动汇总"这个思路也有问题。市面上现成的资讯聚合工具我也试过不少，它们的问题在于太通用——要么是全网所有内容的搬运工，要么只能按固定分类输出，没法针对我关心的"新产品""新模型""新开源项目"做精准筛选。我需要的是有一个像助理一样的角色，它知道我关心什么、知道哪些信息值得报给我、也知道用什么样的格式报给我最舒服。

这正是 Hermes 被设计出来的动机。它不是一个简单的 RSS 抓取器，而是一个带理解能力的执行体：先按我维护的关键词池去搜索，再用规则和模型双重筛选，最后把结果整理成结构化摘要推送过来。整个过程完全自动，我只需要偶尔看一眼推送，点开真正感兴趣的条目。

1.2 Hermes 需要扮演的角色：搜索员、分析师、编辑、邮差

在动手搭之前，我先明确了一个原则：Hermes 的任务不是"把所有内容都抓下来"，而是"把值得我花时间的内容挑选出来"。所以整套系统实际上要同时扮演四个角色。

搜索员负责定时出去搜集信息，它需要知道去哪里找、找什么关键词、用什么时间频率最合适。分析师负责判断一条信息是否值得进入候选列表，它需要理解"AI 产品"这个概念在我这里的实际边界。编辑负责把原始信息改写成适合人阅读的摘要，既要保留关键亮点，又要控制篇幅。邮差负责把最终产物投递到我手边，可能是即时通讯里的一个通知卡片，也可能是一封邮件，得保证稳定到达。

这四个角色拆开来看都不复杂，但合在一起形成一个闭环之后，价值就出来了。我每天花在信息收集上的时间从原来的四十分钟压缩到了五分钟，而且信息质量反而更高了。

2. 整套自动任务的链路设计与分工：谁在什么时候做什么

2.1 四个环节：触发-采集-加工-投递

Hermes 的每日任务从结构上看就是一条单向流水线，拆成四个环节以后，每个环节都能独立修改，也不会互相拖累。

触发环节决定任务什么时候启动。我用的是定时触发方式，每天早晨九点整拉起来跑一次。这里要注意不要选在凌晨跑，很多搜索源和产品页面的更新时间都在上午，九点左右能抓到相对完整的前一天信息。

采集环节负责真正把内容拿回来。这一层同时做三件事：根据关键词池向搜索接口发请求、读取预设来源列表里的更新条目、把返回的页面正文提取出来。采集之后的原始数据是乱的，标题、链接、正文片段、发布时间混在一起，所以紧接着要做规范化处理。

加工环节是整条链路的核心。先跑一遍规则过滤器，把明显不合格的条目扔掉，再用模型对剩下的内容做精排和摘要生成。这个环节消耗的资源最多，也是决定推送质量最关键的部分。

投递环节把加工好的结构化结果封装成固定格式的消息，通过即时通讯渠道的 Webhook 推送到我手机上。如果推送失败会自动重试，连续失败三次就发一条告警通知提醒我去看日志。

这四段式的分工参考了经典的管道设计，好处是每一段的输入输出都是清晰的数据结构。我后来调整过其中任何一段，都不用动其他段的代码。

2.2 定时调度的选择：为什么我最终选了"轻量定时触发器"

其实一开始我纠结过要不要用常驻进程，让 Hermes 一直挂在后台监听消息。后来想明白了，这个任务的特点就是每天一次、时间固定、执行时间不超过几分钟，完全没有常驻的必要。

用轻量定时触发器是最省心的方案。我用的是系统自带的 crontab 来跑入口脚本，表达式是0 9 * * 1-5，周一到周五每天早上九点整触发。周末不跑，因为我周六早上本来就不太想看业务信息，留到周一再汇总反而更清爽。

这种方式的优势很明显：没有常驻进程就不会有内存泄漏的风险，出问题也就是第二天任务不跑，排查起来非常直接。任务启动以后还会写一条日志到本地文件，记录本次执行的成功失败状态和耗时数据，我偶尔抽查一眼就能掌握链路运行状况。

唯一需要注意的就是服务器本地时间和定时表达式的关系。如果服务器配置在境外，记得把 cron 表达式里的时区换算清楚，否则任务会按服务器时区而不是你所在时区触发。

3. 搜索环节：把"找 AI 产品"这件事从玄学变成工程

3.1 关键词池与来源清单：决定搜索质量的隐藏因素

搜索环节的产出质量，九成取决于两个东西：关键词池长什么样，来源清单覆盖哪些站点。刚开始我以为只要把"AI"、"人工智能"这些大词扔进去就行，结果第一天就翻车了——返回的全是行业宏观分析文章，几乎没有具体产品。

后来我把关键词拆成了几类：产品类词汇比如"AI 助手""智能写作""AI 编程工具"；技术类词汇比如"大模型""文生图""Agent"；行为类词汇比如"发布""上线""开源"。每次搜索用"产品词 + 行为词"组合的方式，比如"智能写作 + 发布"，这样匹配到的结果大多是新产品的发布信息，而不是泛泛的观点文章。

来源清单也要维护。我筛了一批固定的信息源，包括几个技术社区的新鲜事栏目、几家头部 AI 公司的官方博客、还有几个专门收录新工具的产品目录站点。固定来源的好处是稳定性高，缺点是有遗漏，所以搜索接口和固定来源两条腿走路，彼此互补。

这里有个容易被忽略的细节：不同来源的内容格式差异很大，有的直接给出完整介绍，有的只有一句话加一条链接。所以采集完成后必须统一转成同一种内部格式，保存成产品名、链接、简介、发布时间四件套，方便后面加工。

3.2 去重指纹与初次粗筛：先干掉 70% 的噪音

采集回来的内容里面，重复现象特别严重。同一个产品经常同时出现在三四个信息源里，标题还各不相同，所以必须做一层去重。

我用的是最简单的指纹去重方案：把标题统一转成小写，去掉所有空格和标点符号，然后算一个哈希值。这个哈希值就是文章的唯一指纹，存进本地数据库，新抓到的内容如果指纹已经存在就直接丢弃。中文内容在去标点时要注意别把全角符号和半角符号混在一起，最好统一做一次字符归一化。

去重之后的粗筛规则我也整理了一套。标题里包含明显广告词的内容直接扔掉；发布时间超过十五天的内容不纳入汇总；正文长度少于五十字的条目没有分析价值；还有一条比较狠的规则——标题里同时出现三个以上竞品名称的，基本可以判断是行业综述文章，也不是我们要找的具体产品。这一套规则跑下来，大约能干掉七成噪音，剩下来进模型的内容量就小多了。

3.3 抓取与正文处理的注意点

抓取页面正文这件事，看起来简单，实际全是坑。很多站点做了防爬手段，直接请求会返回验证页面。我目前的处理方式是请求头里伪装成普通浏览器的 User-Agent，并且控制抓取频率，同一个域名两次请求之间至少间隔三秒，避免给对方服务器造成压力。

正文提取我用的是体重轻量级解析方式，优先拿页面里的结构化数据字段，拿不到再用正文提取规则。遇到拿不到正文的页面，就用它的简介字段兜底。这里的原则是绝不硬抓——如果某个页面连续三次都取不到有效内容，就把这个条目标记为"内容缺失"，但不会让整个任务失败。

采集到的原文也不会直接存数据库，而是先做一次清洗：去掉网页尾巴、去广告、拆出核心段落。清洗后的正文通常也就三五百字，足够后续模型判断和生成摘要了。

4. 加工环节：提示词怎么写才能让摘要像"人写的简报"

4.1 两步式加工：规则打分 + 模型精排

加工环节刚开始我也犯过错，以为把所有内容一股脑丢给模型，让它挑出来就行。结果 token 消耗巨大，而且模型会把一些流量很高的营销软文当成优质内容留下。后来我改成两步式方案：先规则打分，后模型精排。

规则打分给每个候选条目算一个基础分，分数由四部分组成：标题匹配度最高三十分，看关键词覆盖了多少关键词池里的词；发布时间权重十五分，越新越高；来源权重二十分，我信任的优质源加分；正文关键词密度二十五分，剩下的十分给链接完整度。分数超过及格线的条目才进入下一轮。

到了模型精排这一步，输入内容量已经很小了。模型的主要任务不是"找",而是"判断和改写"：判断这条产品是否确实有值得关注的点，然后把原始信息改写成一段有条理的摘要。这一步跑完，输出结果的质量明显上了个台阶。

4.2 一个可以直接抄走的 JSON 输出提示词模板

模型生成的摘要我要求它严格按 JSON 结构输出，这样后续推送到不同渠道都很方便。参考模板大致长这样：

你是资深 AI 产品分析师。根据下面提供的原始内容，生成一条产品简报。 要求： 1. 只输出 JSON，不要解释，不要多余文字。 2. JSON 字段固定为 name, brief, highlights, fit, risk, source。 3. highlights 最多三条，每条不超过四十字。 4. 如果原始内容不足以判断 fit 或 risk，对应字段写"信息不足"。 原始内容： {title} {summary} {date}

对应输出样例：

{ "name": "某智能写作助手", "brief": "面向长文写作者的 AI 写作工具，支持一键生成结构化大纲，并在写作过程中实时提供引用建议。", "highlights": [ "支持多文档联合检索，引文来源可追溯", "内置主流写作风格模板，可自动调优语气", "免费版每月可用次数较同类产品更宽裕" ], "fit": "适合每天有大量文字产出任务的内容创作者、自媒体运营者", "risk": "信息不足，未找到明确的隐私政策说明", "source": "某技术社区产品发布帖" }

这里有个小经验：JSON 输出一定要加上"不要输出多余文字"这个约束。不加的话，模型时不时会在 JSON 前面加一段开场白，后面解析程序就会崩。

4.3 Token 成本控制的经验数值

跑了一段时间后，我统计了一下成本消耗。目前每天进模型的条目数量控制在六十条以内，每条原始文本经过裁剪后大约三百字，模型按日常思考模式跑一次，每天一共消耗的 token 量并不多，按市面上常见模型的定价算，一个月成本非常低。

要是哪天搜索源特别多有超额风险，就要启用量化裁剪策略：只保留每条内容的标题与前两个关键段落，其余全部截断。这个操作会把上下文长度压下去一大截，虽然摘要内容可能会少一些，但核心信息基本都在。

另外建议把模型的温度参数调低一点。这类生成摘要的任务是在做信息压缩，不是创意写作，温度越低输出越稳定，也不容易出现"天马行空"的跑偏描述。

5. 推送环节：结果用什么姿势送到你面前

5.1 推送渠道的选择：即时通讯 Webhook、邮件还是自建页面

加工完成的结果不能躺在服务器里，得推到我随时能看见的地方。目前我用的主要渠道是即时通讯工具的自定义 Webhook 机器人。这种方式的优势非常明显：手机端实时推送、支持富文本消息、还能把多条结果收进同一条汇总消息里，体验比邮件轻很多。

邮件渠道我也预留了，作为兜底方案。Webhook 偶尔会因为服务不稳定出现延迟，这时候邮件至少能保证信息不丢。自建一个展示页面的方案我也考虑过，专门用来截图存档每日推送，但暂时还没有实施，因为 Webhook 加邮件的组合目前够用。

加 Webhook 的时候要配置一个新增消息的接口地址，把加工完的 JSON 数据结构转成目标平台的消息卡片格式。提醒一句，推送目标平台的消息格式限制要提前查清楚，比如长文本截断长度、字段最大长度、是否支持自定义标题这些，否则消息内容会被悄悄切掉。

5.2 推送内容的排版与样式模板

为了让推送出来的一堆消息不至于变成流式刷屏，每条产品简报我固定用同一套排版模板：产品名称加粗作为第一行，下面是简介，然后是一个包含三个要点的小列表，最后附上来源链接和适合人群。整体效果类似下面这个样子：

某智能写作助手面向长文写作者的 AI 写作工具，支持一键生成结构化大纲，并在写作过程中实时提供引用建议。

• 支持多文档联合检索，引文来源可追溯
• 内置主流写作风格模板，可自动调优语气
• 免费版每月可用次数较同类产品更宽裕 适合人群：内容创作者、自媒体运营者 来源：某技术社区产品发布帖

排版这件事不要低估。同样一条信息，排版清楚和排版混乱给人的阅读成本差别非常大。我自己迭代过好几个版本，最终定下"加粗名称 + 单段简介 + 短横线列表 + 灰色来源行"的组合，实测阅读效率最高。

5.3 幂等与重试：别让同一条消息刷屏

推送接口调用不能傻乎乎只调一次。网络抖动、目标平台服务异常都可能导致推送丢消息，所以必须加重试逻辑。我的策略是失败后等待十秒重试，一共重试三次，三次都失败就把消息状态标记为失败并转移到一个独立队列，第二天随当日推送一起补发。

但如果重试逻辑写得不仔细，就可能出现同一条内容被重复推送好几遍的情况。尤其要注意的是，重试前必须检查当前消息是否已经被成功推送过，用消息的唯一日志ID做标记，避免重复发送。我就在这上面栽过一次，某天推送接口超时但实际消息已经发出去了，重试之后同一内容出现在屏幕上两次，后来加了幂等标记才解决。

6. 上线两周后踩过的坑与逐步调优记录

6.1 坑一：搜索接口返回了大量"伪 AI 产品"营销文

上线到第四天，我发现推送里混进来好多明显是营销软文的条目。点进去一看全是同一模板批量生成的内容，标题蹭了 AI 关键词但正文都是在推广某个培训课程。这个坑直接暴露了关键词池方案的缺陷——只看关键词匹配，挡不住营销文案。

当时想了几种对策，最终管用的有两招：第一，在规则打分里加了一个"营销信号"惩罚项，标题中出现"免费领取""限时优惠""包教包会"这些词的直接扣分；第二，手动维护了一个不可靠来源黑名单，凡是名单里出现过的域名，直接不给进入候选列表的机会。两招下来，营销文占比立刻降到了可控范围。

6.2 坑二：模型偶尔"幻觉"出不存在的新功能

模型生成摘要的另一个问题是有时会"脑补"。原始内容里只提到了"支持多人协作"，它生成的亮点里却变成"支持多人实时协作编辑"。这个偏差单独看没什么，但一旦整理进推送，读者就会误以为产品已经具备了这个能力。作为信息汇总工具，忠实于原文是底线。

我目前的处理方式分两步。一是提示词里明确写："亮点必须可以在原始内容中找到对应依据，禁止推测和引申"。二是在流程里加了一个校验动作：生成亮点后，让程序检查亮点文本里的关键词是否出现在原始内容关键词列表中，匹配不上的自动降级为"信息不足"。这个方法虽然粗暴，但能有效拦截幻觉。

6.3 坑三：每天推送变成了信息轰炸

跑了九天之后出现了一个新的困扰：工作日每天推送十条左右的简报，数量并不夸张，倒是排版风格很拖——上午推送一次，下午偶尔又补发一条，信息碎片化反而让人烦躁。我意识到了推送节奏的问题，不只是"推什么"，还包括"何时推""多久推一次"。

于是我把策略调整成两个层级。每个工作日保持九点推一次，但把全部内容聚合到下午统一推。同时允许非工作日只推重要内容，数量超过十五条的日期再加一个"今日最值得关注 Top 3"置顶区，省得让我在海量条目里自己挑重点。

6.4 调优：把推送频率从高到低、内容聚合成日报

后来我把推送进一步格式化，从"九点一次实时推送"改成"每日九点推送昨日汇总日报"。这个调整执行之后，阅读率提升了不少。原因也很简单：实时推送在情绪上会给人一种被消息追着跑的紧迫感，汇总日报则更像一份可以从容浏览的材料，信息密度更大且没有干扰。

聚合日报的格式说实话就是前面 5.2 节模板的扩展版本——开头一个"今日关注"推荐区，列出三条重点；正文按"新工具""新模型""开源项目""观点文章"四个分组排列；结尾一行统计今日抓取、筛选和最终推送的条目数量。加了这个统计信息后，我对每日系统的运行状况一目了然。

7. 这套系统目前的状态，以及如果有时间我会再做点什么

7.1 关于可维护性的体会

这套 Hermes 每日任务到现在已经稳定跑了两个多月，最大的体会是：让一套自动化系统长期可靠运行，麻烦不在于"跑起来"，而在于"持续维护"。关键词池会过时、来源站点会改版、推送渠道会调整接口，哪个环节断了，整个链路都会出问题。所以我隔两周会花半小时扫一遍仓库里的配置项，并根据近期的推送效果手动优化关键词池，及时补充新发现的优质来源，剔除已经失效的信息源。

日志也很重要。从第一版开始，我就坚持让每个环节都写结构化日志，至少记录输入条数、过滤条数、生成结果数、推送状态这四个核心指标。当某个渠道的推送效果变差时，回溯日志能很快定位到是采集量下降还是筛选尺度过严。

7.2 最后说一点个人建议

如果你也想给自己的智能体安排类似的任务，我的建议是先跑通一个最小路径，不要一开始就搭建复杂的架构。第一天先让脚本能抓五个固定来源；第二天加上最简单去重；第三天加一个粗糙的推送；接下来再逐步往里面加功能。每一次修改都要保证当天能验证效果，这样整套系统的技术债能被压到最低。

还有一个值得投入的方向是把历史推送积累成数据库。我目前每天推送之后都会把原始整理结果存进本地库，现在数据库里大概积累了上千条产品信息，后续可以用来做趋势分析，甚至可以反向训练一个推荐模型。当初只是为了一时方便，现在看这成了一个额外资产。技术项目做到这种程度，往往才会发现它带来的好处已经超出了最初的设计目标。