企业官网建设流程全解析

上午十点半，微信准时弹出一条新消息，标题写着“AI 日报｜第 24 期”。点开以后，内容已经被排得清清楚楚：今日最值得关注的一件事、三个值得留意的开源项目、一条值得细读的观点。这不是我订阅的某个科技媒体号，而是我自己搭的一条自动化流水线——WorkBuddy 负责定时触发和调度 AI 模型，我给它配了一个生成日报的 Skill，每天上午十点半自动抓取信息源，让大模型完成摘要、筛选和排序，最后借道 Webhook 把内容送进微信。

花了大半天搭好之后，它已经连续跑了三周，中间踩了不少坑，也顺手修了不少问题。这篇文章打算把整套方案、配置思路和排雷过程尽量完整地写出来。如果你也被“每天起床先刷两小时资讯”这件事困扰，或者正好想把日常工作里那些重复的信息收集交出去，这里面的大部分思路应该可以直接参考。

1. 早晨的信息焦虑，是自动化最值得解决的第一件事

1.1 每天睁眼先刷两个小时资讯的恶性循环

先聊聊我为什么折腾这件事。以前我每天早上醒来的第一件事，是打开手机里那批固定的资讯入口：几个技术媒体、开源社区的热榜、社交平台的时间线、常看的技术博客。目的很简单，生怕漏掉 AI 领域的重要动态。但实际效果很差：一个多小时刷完，脑子里留下的有效信息往往只有两三条，大部分时间花在“确认没有大事发生”上。更尴尬的是，真正重要的一条消息经常藏在时间线二十条之后，手指快速划过时根本注意不到。

这个状态说白了就是信息焦虑。表面上每天都在接收信息，实际上没有一条真正进入决策层。后来我意识到，问题不在于信息量不够，恰恰相反，是信息量太大但过滤太粗糙。我需要的是每天早上有一份已经整理好的结果放在面前，而不是自己去承担那个筛选过程。于是“定时推送一份 AI 日报”这个需求就被记了下来。

1.2 为什么候选方案那么多，最终锁定了 WorkBuddy

想解决这个需求，可选方案其实不少。最传统的是 crontab 加 Python 脚本，每天定时去爬几个源，再调大模型接口做摘要，最后通过消息推送服务发到微信。这套方案我早年写过，能用，但维护成本不低：RSS 结构一变要改代码，网页布局一变要改解析规则，任务跑挂了还没人通知。后来也试过 n8n 这类自动化平台，优点是环节都被模块化了，但 AI 编排能力偏弱，想把“判断一条新闻值不值得进日报”这种模糊逻辑写清楚反而费劲。

现成的 AI 日报订阅服务我也试过几个，问题在于信息源不透明，它推什么我看什么，过几天就发现内容偏向严重。最终选中 WorkBuddy，主要看中的是它把大模型能力、Skill 机制和定时任务放在了同一个环境里。Skill 允许我用自然语言而不是代码来定义执行规则，后续改信息源、改打分标准、改输出模板，都只是在配置里调整文字，不用重新部署脚本。对不想维护一堆代码的人来说，这是最省心的一条路。

1.3 一条日报从触发到送进微信，中间发生了什么

这条流水线可以拆成七个环节：定时器触发、抓取信息源、初步清洗、LLM 摘要与筛选、格式排版、调用 Webhook、微信展示。

十点半一到，WorkBuddy 里的定时任务先唤醒执行器，接着按我在 Skill 里配置的抓取清单逐个拉取信息源内容。拿到原始材料后，清洗阶段负责去掉广告噪声、剔除重复内容、过滤掉明显低质量的信息。然后进入 LLM 阶段，大模型按照提示词完成摘要、打标签、打分、排序。最后一步是把整理好的结果按照日报模板拼装成 markdown 文本，通过 Webhook 推到我的微信。整个流程没有什么黑魔法，关键就在于每一层都要有明确的输入输出，出了问题才查得到是哪一环在报错。

2. 给 WorkBuddy 写“日报任务”前，我先把规则拆成了三层

2.1 Skill 的本质：把人的判断标准翻译成机器可执行的指令

Skill 这个词在 WorkBuddy 里看着唬人，想明白之后就很简单：它相当于给一个能力很强但没有任何主观立场的实习生写工作手册。大模型确实什么都知道一点，但它不会自动知道“你关心的 AI 动态”具体指什么，不会知道你信任哪些站点，更不会知道一条信息到底凭什么进你的日报。

很多人搭自动化日报失败，问题就出在规则太含糊。我一开始写的提示词比这还简单，基本是“请帮我整理今天的 AI 新闻”，结果得到的日报像一份低配版的新闻联播：所有条目平均用力，谁也没说清楚它为什么值得我看。后来把规则拆成三层——数据源层决定看什么，判断层决定留下什么，输出层决定长什么样——日报的质量才真正稳定下来。这个分层思路比具体用什么参数重要得多，值得在这里展开说。

2.2 我的信息源清单与抓取策略

数据源层，我现在一共配了五类来源。

第一类是聚合型 RSS，包括 Hacker News、Product Hunt 和 arXiv 的 AI 分类，这类源头信息量大，适合做第一轮粗筛。第二类是固定的技术媒体和官方博客，通过 RSS 订阅按关键词过滤，确保重大发布不漏。第三类是 GitHub Trending 上 AI 相关的仓库，重点捕捉新出现的大模型项目和开发工具。第四类是社区讨论里热度快速上升的帖子，这种往往是早期信号，比媒体报道要快半天到一天。第五类是检索型任务，如果前四类跑完内容仍然偏少，就让 Agent 使用内置搜索能力补几条关键词热点。

抓取顺序也有讲究：先抓能拿到全文的源，再抓只有标题和链接的源。全文越完整，后面摘要的质量越高，这一点我是对比试出来的：让模型从三十个标题里猜内容，远不如给它十篇全文让它挑三篇。为了控制抓取时间，我会把每个源的最大抓取条数都限制好，避免一次任务拉回来几百条标题，反而把真正有效的内容淹没。

2.3 分段编排：抓取、清洗、摘要、排版各干各的

在设计 Skill 的执行流程时，我特意没有把所有工作塞进一个智能体对话里，而是拆成了四个独立步骤。这样做主要是为了三点。

第一是可控性。一个步骤做一件事，日志会非常干净。如果日报里突然出现乱码，我可以直接定位到摘要这一步的输入输出，而不必在一大段对话历史里翻找。第二是成本。分段执行可以在每一段都设置不同的模型档位：抓取和清洗用便宜快速的小模型，摘要和排版用能力更强的大模型，整体花费比所有内容都走同一个高级模型要低不少。第三是排查方便，这一点等会讲踩坑时还会提到。

每个步骤的输入输出我都做了约定：抓取步骤输出的是结构化条目数组，清洗步骤输出的是干净文本列表，摘要步骤输出的是带字段的对象。字段固定下来之后，后面排版才不需要想破脑袋去猜模型吐出来的格式。

3. 日报内容结构：怎么让大模型替你筛出“真正值得看的东西”

3.1 日报模板：我要的是“领域雷达”，不是“新闻联播”

早期那种平铺式日报，说实话连我自己都没看完过。我真正需要的是：十分钟之内判断出今天 AI 领域发生了什么，哪件事跟我当前的工作方向有关，哪些变化需要我调整接下来的计划。所以我把日报模板固定成了五个模块。

第一个模块是“今日头条”，只保留一条最有价值的信息，写清楚发生了什么、为什么重要、可能影响哪些人。第二个模块是“值得关注”，放三到五条次重要内容，每条一句话摘要加一句点评。第三个模块是“开源与工具动态”，记录两到三个具体项目，写清楚项目是做什么的以及它的看点和适用场景。第四个模块是“数据与观点”，挑一条值得细读的评测或者有分歧的讨论，附上原文链接。第五个模块是“今日判断”，让模型综合当天信息给出一句话倾向性判断，这部分相当于模型替我做的二次加工。

实际体验下来，这五块结构最大的好处是：它逼着模型做取舍，而不是把所有东西都塞进来。没有“今日头条”这个限制时，模型倾向于给每条内容一个差不多的权重，结果就是什么都没有被突出。设定了只允许一条之后，模型反而需要真正去比较和排序，这个比较过程就是筛选价值最大的部分。

3.2 筛选规则的核心是“信息权重”，不是“关键词”

如果只靠“包含 ChatGPT 就保留”这种关键词过滤，日报最后一定会变成轰炸式的列表。我的做法是给每条候选信息打四个维度分。

第一维是相关性，判断这件事是否与 AI、大模型、Agent 工作流直接相关。第二维是时效性，看它是不是过去 24 小时内的新变化。第三维是权威性，一手信源得分高于二手转述，官方发布高于小道消息。第四维是差异度，看这条信息跟已经选入日报的内容是否存在视角上的重复。

每个维度一到五分，加权求和后设定一个入选阈值。这个打分逻辑本身不复杂，大模型执行起来很稳，关键在于权重可以分阶段调。比如某天正好赶上一场重磅发布会，我会把差异度权重调高，避免十条内容全在讲同一件事的多篇稿子。这套权重配置不是一次到位的，我是跑了快一周之后才慢慢调到目前这个比较顺手的状态。

3.3 用自然语言把质量要求写进系统提示词

日报质量的上限，基本取决于系统提示词写得有多具体。这里分享一段我目前在用的提示词框架，可以直接复制到 WorkBuddy 的 Skill 配置里改一改用：

你是一个面向 AI 领域从业者的情报编辑。我会分批给你原始信息源内容，你需要完成筛选和摘要。 约束条件： 1. 只保留与 AI 大模型、Agent 产品、AI 开发工具直接相关的信息。 2. 今日头条只能有 1 条，必须是你认为最重要的动态，要写清楚发生背景和影响面。 3. 值得关注的条目控制在 3-5 条，每条摘要不超过 120 字，点评不超过 60 字。 4. 开源项目要给出项目名称、主要用途、近期的突出变化。 5. 所有判断必须基于今天的材料，不要写泛泛的行业趋势。 6. 整体语气中立，不要用夸大词，不允许出现“震惊”“重磅”这类表述。

这段提示词我迭代过四版。一开始没有约束字数，模型把每条都写成两百字，日报总长度直奔六千字；后来加了硬性字数限制，又出现了模型用列表硬凑的毛病。现在的版本强调的是“基于今天的材料”和“不要写泛泛的行业趋势”，这两句话确实把输出质量拉高了一截。

4. 微信送达方案：我绕开了个人号限制，用 Webhook 走通

4.1 为什么不考虑“直接调用个人微信发消息”

微信推送是这套流程的最后一环，也是很多人在配置中最纠结的一步。这里面有一个需要明确的边界：微信没有向个人用户开放的推送接口，你不能写代码直接给你的私人微信发消息。

市面上确实有一些方案号称能绕过这个限制，基本思路是去操作微信客户端的内部逻辑。我不建议用，封号风险是其一，稳定性是其二。你现在搭的是一个每天都要跑的生产流程，不是做实验，通知链路出事会比日报内容出错更麻烦。正确解法是走向上兼容的通道——用 Server酱、PushPlus、企业微信群机器人这类服务，它们利用的是微信对外开放的消息接收能力，本质上是合规微信生态内成熟的解决方案。

4.2 三种方案横向对比：Server酱、PushPlus、企业微信群机器人

这三条路我都实际跑过，简单做一个横向对比：

我日常用的是 Server酱，主要原因是接入最简单，只需要一个 SendKey 就能发消息，推送成功与否还有明确的返回状态码。如果你的日报是给团队里几个人一起看的，企业微信群机器人会更合适，一条 Webhook 地址就能让一整个群收到消息。

4.3 用 Webhook 把日报送进微信：完整配置流程

以 Server酱为例，整个配置过程只需要三步。

第一步，打开 Server酱官网，完成微信登录后复制你的 SendKey。第二步，找到 Server酱的推送接口地址，地址格式是固定的：https://sctapi.ftqq.com/{SendKey}.send。第三步，从 WorkBuddy 的“Webhook 发送”步骤发起一个 POST 请求，把日报标题和正文分别放在 title 和 desp 两个字段里。

我在 WorkBuddy 里的实际做法是，让排版步骤直接输出成 markdown，然后由推送步骤组装成下面的请求：

import requests send_key = "你的SendKey" url = f"https://sctapi.ftqq.com/{send_key}.send" payload = { "title": "AI 日报｜6 月 9 日", "desp": "# AI 日报\n\n## 今日头条\n...（这里放完整日报内容）...", } resp = requests.post(url, data=payload) print(resp.status_code, resp.text)

这里有一个实测下来的细节：Server酱的 desp 字段是支持 markdown 渲染的，但消息渲染时对表格和超长链接支持一般，所以我在排版步骤里刻意少用表格，多用简洁的层级标题和项目符号。日报被推送到微信之后，是要在手机屏幕上阅读的，排版密度低一点、留白多一点，阅读感受完全不一样。

5. 无人值守的关键：首次端到端跑通与定时器配置细节

5.1 先手动跑一遍：每个环节都要看到中间产物

正式交给定时器之前，我先手动点击执行了好几次整个 Skill，保证每一环节的输出都符合预期。第一次跑通新流程，最容易犯的错误就是一次性看到最终推送，然后就默认系统健康。等第二天出了问题，你根本判断不了是抓取挂了、摘要崩了还是推送接口变了。

我的办法是把执行过程拆开验证。先单独测试数据源抓取，看返回的条目数量和字段是否完整；再单独测试摘要步骤，看大模型是否遵守了字数和格式约束；然后把排版结果放进 Server酱 的文档里检查渲染效果；最后才把整个流程串起来完整跑一次。每一步的中间产物我都会在 WorkBuddy 的执行日志里看一眼，确认信息源、清洗逻辑、摘要模板、推送参数这些都是按预期工作的。

5.2 十点半这个时间点的选择逻辑

定时时间选在十点半，是经过一番权衡的。一开始我贪早，设过早上八点，跑了两天就发现问题：夜间更新的信源到八点往往还不完整，国外社区的讨论经常是北京时间早上九、十点才开始活跃，八点去抓，抓到的经常是前一天的旧材料。反过来设到中午十二点也不行，等日报送达，半天已经过去了，时效性打了折。十点半刚好卡在大多数信息源完成夜间更新、白天新内容还没涌进来的空档期。

在 WorkBuddy 里配置定时器时，我用的表达式是30 10 * * *，并额外指定了时区Asia/Shanghai。这一步很容易踩坑，我刚开始就没指定时区，触发的实际时间直接变成了下午六点半。很多定时调度器默认按 UTC 执行，如果你用的是 Day of Week 类型的时间，一定要检查清楚时区设置，建议直接写成带时区的 cron 表达式。

5.3 连续跑三天，观察推送时间、内容质量和失败率

配置好定时器之后，我没有第二天就不管了，而是连续盯了三天。每天的检查动作是固定的：看推送时间是否稳定在十点半前后五分钟内；点开日报内容，对照当天的行业动态，确认没有明显漏掉的大事；扫一遍有没有重复信息和明显废话；去执行后台看一眼运行日志是否全绿。

三天里遇到过一个问题：有一天推送晚到了接近一小时。查了日志发现是信息源里有一个站点响应超时，抓取步骤等待了太久。我在该信息源的抓取配置里加了最大等待时间和失败跳过策略，之后就没有再出现类似问题。连续三天稳定之后，我才真正把这条流水线从“今天想起来就跑一次”的状态切换成“完全无人值守”。

6. 三周实测排雷：五个问题与完整排查链路

6.1 日报迟到半小时：时区设置与执行队列的双重原因

有几天，日报的推送时间从十点半迟到了十一点左右，而且不是固定推迟，时好时坏。我先去查看了 WorkBuddy 的任务日志，发现任务触发时间本身是准时的，说明定时器环节没有大碍。再仔细看每一步的执行耗时，发现等待时间主要花在抓取步骤上：有几个外部源响应非常慢，抓取器一直在等超时。

顺着这个线索查下去，还发现执行队列里的任务优先级问题。我那个时段还挂了几个其他的定时任务，它们和日报任务共用执行队列，前一个任务还没跑完，日报任务只能排队。这次的解决方法是双管齐下：给每个外部信息源设置独立的超时上限，同时把日报任务的优先级调到最高。改完后再观察一周，推送时间稳定回到了十点半前后。

6.2 同一篇资讯连续三天出现：去重要分三层做

日报里持续出现同一篇旧资讯的当天，我先把当天的原始信息源列表拉出来，发现那篇资讯确实还在信息源头里，源头没有把它标记为已读或过期。等于说抓取层直接把旧内容当成新材料又喂给了摘要层，摘要层又没有记忆，自然不知道这条已经推过。

这个问题牵扯到三个层级：抓取后会有一个短暂缓存，缓存到期后如果源站仍然返回这条，去重失效；摘要层没有历史记忆，面对同一批内容它不会主动标记“这条推过了”；输出层也没有维护已推送条目池。我的处理方式是给整个 Skill 加了一个已推送标题数据库，存储格式是“标题 + 链接 + 哈希值”。每天的日报生成完毕后，所有条目的链接哈希都会写入这个库，下一次抓取时先做一次哈希比对，命中的直接剔除。这一步加上之后，重复资讯的问题就彻底消失了。

6.3 摘要越写越长：定量约束比“简洁一点”更有效

有一段时间日报的总长度接近六千字，在微信里被折叠得厉害。我本想通过提示词里加一句“请简洁一些”来解决问题，结果完全没有用。后来检查了模型输出，发现每一条的目标字数都超了，标题也很长。

这里的根因在于“简洁”是一个模糊词，大模型对这句话的理解和执行都不稳定。我把提示词里的要求全部改成硬性数字约束：今日头条摘要不超过 150 字，值得关注每条不超过 120 字，今日判断不超过 80 字。同时给摘要步骤设置了输出 token 上限，从源头卡住长度。这两处改动之后，日报正文基本控制在 2400 字左右，在微信里阅读体验马上不一样了。

6.4 某天推送静默失败：Webhook 限流与重试策略

三周里有过一次推送失败，日报内容正常生成，但微信里什么都没收到。排查日志发现 HTTP 请求返回了 429 状态码，这是 Server酱 在限流。我们的定时任务发送时间比较集中，而且手动测试时也在同一时段发了多条，正好触到了频控。

排查链路是：先看推送步骤的返回码，确认不是请求格式问题；再看 Server酱 的介绍，确认它的免费额度有限制；最后检查是不是自己在短时间内发多了。解决方案分两层：在推送步骤里加入简单的指数退避重试逻辑，首次失败等 15 秒重试，第二次失败等 60 秒；同时增加一个备用通道，如果 Server酱 连续失败三次，自动调用企业微信机器人再推一次，确保关键通知不会静默丢失。

6.5 改了 Skill 规则次日没生效：版本化与强制回归验证

有一次我调整了信息源列表，加了一个新的技术博客进去，第二天看日报却发现新源的内容完全没出现。检查配置发现，我的修改确实保存了，但 WorkBuddy 的定时任务当时还在运行旧版本实例，需要重新触发才能加载最新配置。

这个问题暴露了一个容易忽视的点：Skill 配置是带版本的，保存草稿不等于线上生效。现在的习惯是，每次改动配置后先手动执行一遍整个 Skill 做回归验证，确认改动已经加载成功，再让它正常定时跑。同时我会在 Skill 的配置说明里写一个版本号，比如 V1.3、V1.4，每天的日报里也带一个版本字段。确认当天跑的是最新版本，这一个小习惯帮我省去了大量“改了没生效”的烦恼。

整套系统跑到第三周，我最大的感受是：每天早上终于不再被不确定的信息流牵着走了。每天十点半，我拿到的是一份已经经过筛选和排序的结果，而不是十个标签页里乱七八糟的原文。这套用 WorkBuddy 搭的自动日报流程，真正价值的核心并不是替我省掉了多少时间，而是把“选择看什么”的主动权交回到我手里——这玩意的可扩展性比我想象的大得多，社区里那些多 Agent 协作、信息自动归档的玩法，我也已经在尝试了。