企业官网建设流程全解析

1. 这个闹钟是怎么长出来的

先说结论：我用 WorkBuddy 搭了一条完全自动化的信息流水线，每天上午十点半，微信准时收到一份 AI 日报——不是那种"标题凑一堆、内容全靠抄"的垃圾聚合，而是经过筛选、摘要、去重、排版之后的可读内容。

先交代一下我的背景，免得大家觉得这玩意儿离自己很远。我平时的工作和 AI 沾边但不算纯技术岗，每天需要快速知道业内发生了什么：哪个模型发了新版本、哪个开源项目值得跟进、哪篇论文值得精读、哪个工具链更新了。以前我每天早上的流程是固定的——刷 Hacker News、刷 Product Hunt、刷公众号、刷推特，一圈下来四十分钟起步，而且经常被完全无关的热搜带跑偏。这个痛点听起来不大，但日积月累其实就是每天白白丢掉了半个小时的专注时间。所以某天我决定把这件破事彻底自动化，于是就有了今天这篇文章的主角：一个跑在 WorkBuddy 里的定时任务。

有人可能会问：这种东西自己写个 Python 脚本 + cron 不也能搞定吗？说实话，能，我也写过。但折腾过一段时间之后你会发现，脚本方案有几个绕不开的坑：信息来源一变，你要改代码；内容筛选逻辑想调整，你要改代码；想增加一个"只关注 Agent 方向的更新"这种规则，你还是得改代码。改到后面，维护脚本的时间比手动刷资讯还长，那就本末倒置了。但 WorkBuddy 这类工具不太一样，它能让我用自然语言描述需求、用配置而不是代码来管流程、把信息来源、筛选规则、推送渠道都变成可以随时调整的积木。这对我来说才是真正的"一劳永逸"。这篇文章我就把完整思路和配置过程写出来，所有细节都是实操过的，你可以直接照着搭。

2. 先把需求拆明白，再谈工具

2.1 一份合格的 AI 日报要满足什么标准

在动手配 WorkBuddy 之前，我先把"日报"这个需求本身拆了一遍。很多自动化项目最后做出来不好用，根子不在工具不行，而在需求定义得太模糊。"每天推送 AI 日报"这句话看着清楚，但仔细一想全是问题：日报包含哪些类型的资讯？覆盖哪些信源？每条新闻要多详细？一天推几条合适？格式是长文还是列表？万一当天没有重要新闻，是不是要推一条"今日无大事"？

我自己定的标准是这样的：每日 6 到 10 条内容，太少显得空洞，太多微信里根本看不完；每条内容必须包含标题、三句话以内的摘要、来源链接、以及我关心的关键词命中情况；内容覆盖面要广到模型层、应用层、开源项目、工具链、论文这几个维度；最重要的是，每条内容必须"真的值得看"，而不是把 RSS 里的条目全部无脑搬过来。

有了这个标准之后，再回头看整个流程就清晰多了。整个链条其实就五个环节：采集信息、过滤噪音、生成摘要、组装排版、推到微信。这五个环节在 WorkBuddy 里分别对应不同的能力——RSS 读取、网页抓取、大模型理解、代码执行、消息推送。我只需要把每个环节的输入输出接好，剩下的交给调度器按固定时间执行就行。这就像搭积木，但积木的规格必须先定好，不然拼到一半发现接口对不上，那才叫崩溃。

另外我得强调一点：日报不是越详细越好。微信阅读场景是碎片时间，你推一篇 5000 字的长文过去，大多数人划两下就关了。我之前犯过这个错，让 AI 把每篇新闻生成 500 字摘要，结果整份日报像一本电子杂志，打开率很低。后来改成每条内容就两三句话，反而阅读体验好了很多。内容这东西，克制比堆砌难得多。

2.2 为什么选 WorkBuddy 做调度中枢

工具选型这一步，我其实纠结过一阵子。市面上的方案不少：n8n 偏流程自动化，Dify / Coze 偏应用搭建，还有些纯代码方案。最后选了 WorkBuddy，主要原因有几个。

第一，WorkBuddy 对定时任务的支持足够原生。它不是那种"你要自己写 cron 再调用 API"的半吊子方案，而是直接在任务编排里提供了时间触发节点，配置一个 cron 表达式就行。第二，它能跑本地代码。日报的后期处理里经常要做文本清洗、按关键词打分、生成 Markdown 表格之类的事，这些逻辑用代码写比用大模型提示词写要可靠得多——大模型擅长做语义判断，不擅长做精确计算。第三，它有一套规则系统，可以定义"对所有任务都生效"的全局规则，这个做信息过滤非常有用。比如我可以定一条规则："所有时间敏感的内容，必须在摘要前标注日期"，这样无论是日报任务还是周报任务，都会自动遵守，不用每个任务单独配置。

当然，这里我必须说明一下，WorkBuddy 并不是唯一能做到这些事的工具，我只是在实际使用中觉得顺手。你可以用 Coze、Dify、甚至自己写 Python 脚本，核心方法论都是一样的，工具只是载体。这篇文章后面所有操作步骤我尽量写得通用，如果你用别的工具，也能对照着找到对应的能力。

3. WorkBuddy 里的任务编排：从触发到推送

3.1 创建定时触发器的正确姿势

WorkBuddy 里新建一个任务的时候，第一步是设定触发方式。我选的定时触发，这个在界面里叫"Scheduled"或者"定时"。关键是 cron 表达式的写法，我配置的是0 30 10 * * *——意思是每天上午十点三十分整触发一次。

这里有一个非常容易踩的坑：时区问题。WorkBuddy 默认的 cron 可能有自己的一套时区配置，如果你的服务器或者运行环境在 UTC 时区，那0 30 10 * * *实际触发的是北京时间下午六点半，这显然不是你要的效果。解决办法有两种，一是在触发器设置里明确指定TZ=Asia/Shanghai前缀，格式大致是TZ=Asia/Shanghai 0 30 10 * * *；二是看看工具有没有全局默认时区设置，直接把默认时区改成中国标准时间。

我建议配置完触发器之后，一定要手动测试一次，不要等到第二天看结果。WorkBuddy 提供了"立即执行"按钮，先把任务跑一遍，确认生成和推送都正常，再回去看定时配置。我见过太多人自信满满地配了个每天早上八点推送的任务，结果实际跑了一周才发现推送时间一直是下午——就是因为时区没设对。

3.2 用规则系统约束 AI 的输出行为

WorkBuddy 有个比较特别的东西：全局规则（Global Rules）。你可以把它理解成给整个工作台里的 AI 助理定"做事规矩"，所有任务都会自动遵守这些规则，不需要在每个任务里重复写。

这功能在日报场景里简直是我的救命稻草。因为大模型的输出风格不稳定，同样的提示词，今天可能给你一大段啰里啰嗦的分析，明天可能就简洁过头。我在全局规则里写了几条硬性约束，全部生效的前提是"后续对所有任务都生效"这一点设置好。

我的规则大致是这样的：

• 所有输出使用简体中文，专业术语保留英文原文并用括号标注中文解释。
• 凡是引用外部信息，必须附上来源 URL，不提供来源的内容一律不写入日报。
• 每条新闻的摘要控制在 80 到 120 字之间，禁止超过这个范围。
• 当信息源中不存在符合筛选条件的重大新闻时，明确返回"当日暂无重大更新"，不要为了凑数降低标准。

这几条规则看着简单，实际效果非常明显。尤其是"没有就不推"这条，一开始我没有写进去的时候，AI 经常把一些无关紧要的产品更新硬塞到日报里凑数，很多其实只是某个小工具改了版本号。加了规则之后，它就会老老实实地告诉你今天没什么大事，这样我反而更信任它了。

3.3 Skill 的选择与配置

WorkBuddy 里的 Skill 相当于给 AI 装配特定的工具能力。我这个日报任务一共用到了四个 Skill，这里逐一说明它们的作用。

第一个是 RSS 读取器，用来抓取各个信息源的 RSS 内容。第二个是网页抓取器，当信息源没有 RSS 或者 RSS 里只有摘要没有正文时，它会自动打开链接抓取正文内容。第三个是代码解释器，用来执行我写的那些文本清洗、打分的逻辑。第四个是搜索增强，主要用来做补充验证——当选中的新闻信息不完整时，它可以去搜索补充背景资料。

Skill 的配置界面不复杂，核心是选择你要启用的 Skill，以及配置权限。这里我遇到过一个问题：网页抓取器默认可能会限制访问外网的频率，导致抓取速度很慢。后来在 Skill 的配置里把并发数调高了一些，情况才好转。但这里要提醒大家，并发数不是越高越好——很多信息源网站是有反爬机制的，抓得太猛容易被封 IP，反而得不偿失。

4. 信息源怎么选，决定日报的生死

4.1 信源矩阵：不能只靠一两个网站

日报内容的质量，七成取决于信息源选得好不好，三成才取决于 AI 的筛选能力。如果信源本身就是噪音爆炸的地方，那 AI 再聪明也没办法变废为宝。我现在维护了一个信源列表，按类别大致分成了几组：

• 模型层：OpenAI、Google AI、Anthropic、Meta AI 的官方博客，以及各大模型团队的 Release Notes
• 开源项目：GitHub Trending、Hugging Face Daily Papers、Papers with Code
• 应用与工具：Product Hunt、TechCrunch AI 频道、The Verge AI 分类
• 中文圈：少数几个我信任的公众号文章汇总源，以及即刻上几个 AI 产品的精选圈子

每个信源在 WorkBuddy 里配置成对应的 RSS 地址，标签打好，比如"官方博客""社区热议""开源动态"这样。这样做的目的是让 AI 在做筛选时能根据信源类型调整权重——官方博客的东西，哪怕标题不炸，也值得看一眼；社区里那种标题党，除非真有大动作，否则直接过滤是常态。

很多人一开始做日报，会一股脑地把所有 AI 相关 RSS 都塞进去，觉得信息多多益善。实话说，这样做的结果就是日报变成了一本"标题列表"，毫无可读性。信息源的纪律是宁缺毋滥：那些长期产出低质量内容的站点，该删就删，不要舍不得。我前后调了三轮信源列表，从最开始 30 多个 RSS 源删到现在的 15 个，日报质量反而提升了一大截。

4.2 RSS 缺失时怎么补救

有些重要信源没有提供 RSS，这事挺折腾人的。我遇到最典型的是几个需要登录才能看的社区内容平台，RSS 输出基本不存在。解决办法我试过两种：第一种是寻找第三方桥接服务，比如用 RSSHub 这类开源项目，把原本没有 RSS 的网站包装成 RSS 输出。第二种是直接用网页抓取器定时去扫特定页面，然后做文本比对。

这两种方案各有利弊。RSSHub 配置方便，但依赖第三方服务的稳定性，有时候上游接口一变，它就静悄悄失效了，你也不知道。网页抓取器的好处是直接，但每次抓的内容是全量抓还是增量抓，需要你设计好去重逻辑，不然日报里一天出现三条同质化内容，就很尴尬。

我在 WorkBuddy 里的做法是：优先用 RSS 源，没有 RSS 的才用抓取器，并且抓取器的频率设置得比 RSS 低一些，比如两小时拉一次页面，拿到结果后跟昨天的内容做比对，只保留新增的部分。这个逻辑我用代码解释器写了个简单的文本差量脚本，效果还不错。

5. 日报的生成策略：筛选、摘要、去重、打分

5.1 筛选逻辑：让 AI 学会说"不"

信息采集回来之后，第一步不是生成摘要，而是筛选。这一步我完全交给大模型来做，但提示词写得非常具体。我不是跟它说"挑出重要新闻"这么笼统，而是给出明确的判断标准：

• 涉及主流 AI 厂商（OpenAI、Anthropic、Google、Meta、微软等）的产品发布、模型更新，全部保留。
• 开源项目的标准是 GitHub star 增速快、或者属于 AI Agent / 大模型应用方向的新项目，保留。
• 论文只看被广泛讨论的，判断依据是 Hugging Face 上的收藏量或者 Twitter 转发量。
• 单纯工具链的 incremental 更新（比如某个库修了个 bug）自动丢弃。
• 带有标题党倾向但实际内容空泛的，丢弃。

这套判断标准写进提示词之后，日报的内容密度一下子提上来了。以前十分钟刷不完整份日报，因为里面有一堆无关紧要的信息，现在基本两分钟就能看完，而且每一条都值得点进去看一眼。筛选比生成重要得多，这是我从这个项目里学到的最大教训。

5.2 摘要生成的技巧：结构化模板

筛选完之后，AI 需要对每条入选的内容生成摘要。这个环节的难点不是"让 AI 写摘要"——这个它天生就会——而是让摘要的格式保持统一，方便我阅读。我设计了一个固定的模板结构：

【类型】模型更新 / 开源项目 / 论文 / 工具 【一句话概述】不超过 30 个字的核心信息 【为什么值得关注】1-2 句，说清楚这件事对你的影响 【来源】URL

这个模板在 WorkBuddy 里通过提示词实现，配合我前面说的全局规则，输出的稳定性非常可以。有一点要注意：提示词里的模板格式，必须用分隔符（比如---或者 ``` 之类）包起来，不然模型容易把格式要求和实际内容混在一起，输出就乱了。

我还试过让 AI 给每一条新闻打个"关注度评分"，从 0 到 10。一开始觉得这种主观打分没什么用，后来发现了一个妙用：我可以在任务里设定一条规则，比如"当日仅当存在关注度评分大于等于 8 的内容时，才推送日报；否则发送一条极简简报即可"。这个机制避免了每天都被强推一堆无用信息的烦恼。

5.3 去重与排版：最后一道质量关

重复内容处理是整个流程里最容易被忽视的环节。同一个新闻，很可能同时出现在多个 RSS 源里，如果不做去重，日报里就会出现三条内容相似但来源不同的条目。WorkBuddy 的去重逻辑我用的是文本相似度计算——把每条新闻的标题处理后（去掉标点、停用词）算一个哈希值，再比较相似度，超过阈值就只保留一条。

排版方面，微信里适合短段落 + 清晰列表结构。我最终输出的格式是 Markdown 渲染后的纯文本，每条新闻之间用空行隔开，标题加粗，URL 直接暴露而不是用[链接](url)这种隐藏形式——因为在某些微信推送环境下，超链接的跳转并不总是可靠，裸 URL 反而更实用。整份日报的长度我控制在 1200 字以内，超过这个阈值就砍内容，优先保前面的高优先级条目。

6. 微信推送通道：我踩过的坑和最终方案

6.1 四条路，逐一评测

推送这一步是"最后一公里"，看起来简单，其实最折腾。微信并不像 Telegram 那样有开放的 Bot API，想在微信里收到自定义内容推送，你得走一些"曲线救国"的路线。我认真试过下面这几种：

第一是企业微信群机器人。这是我最推荐也最终在用的方式——你只要建一个群，添加一个自定义机器人，就会拿到一个 webhook 地址，往这个地址 POST 一段 JSON，消息就能进群。整个过程不需要写任何微信相关的代码，稳定、简单、不会被封号风险困扰。

第二是 Server酱 / PushPlus 这类第三方推送服务。原理是你关注它们提供的服务号，然后通过 HTTP 请求把内容转成微信模板消息推送给你。好处是个人就能用，不需要建群；坏处是依赖第三方服务的稳定性，而且模板消息的格式限制比较多，长文体验一般。

第三是钉钉/飞书的群机器人。虽然它们不是微信，但如果在日常办公里本来就在用，也是一个替代方案。这里不展开讲，只是提一句，因为我知道有些读友的公司团队用钉钉比较多。

第四是个人微信的自动化登录方案。这条我不建议走，因为现在对个人微信的自动化协议管得越来越严，账号容易被限制甚至封禁，为了推送个日报冒这么大风险，完全不值得。

综合下来，我最推荐企业微信群机器人方案——它绕开了所有个人微信的限制，又不需要引入第三方。你在正常的企业微信里建一个只有你自己的群，把别人都踢掉，加个群机器人，就相当于给自己开了一条专属推送通道。

6.2 群机器人的配置与实测

配置企业微信群机器人的流程很简单，几个关键步骤说一下。

在企业微信里创建一个群，群名随意，比如我就叫"我的日报"。群建好之后，点群设置，找到"群机器人"选项，选择"添加机器人"，给它起个名字比如"AI 日报助手"，添加完成后会得到一个 webhook 地址，类似https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx。

这个 webhook 地址就是推送通道的入口。然后你在 WorkBuddy 的消息推送节点里，配置一个 HTTP 请求，把这个地址填进去，请求方法选 POST，请求体是一个固定格式的 JSON：

{ "msgtype": "markdown", "markdown": { "content": "### AI 日报 2025-03-20\n\n- **标题一**：[摘要文字](https://example.com)\n- **标题二**：[摘要文字](https://example.com)" } }

注意这里我用的是markdown消息类型，不是text。markdown类型在微信客户端里能渲染加粗、标题、链接这些格式，阅读体验好很多。text类型则纯粹是纯文本，适合极简场景。

我实测下来，企业微信群机器人对 markdown 的支持比想象中好，但也有一些限制，比如##这种多级标题可能渲染异常，最好只用###和加粗。另外链接必须写完整的http(s)://开头，不然没法点击跳转。这些细节我在调推送模板的时候都踩过，写出来给大家省点时间。

6.3 推送失败的重试机制

推送通道配置好了之后，还有一个不能忽略的问题：如果 webhook 请求失败怎么办。网络抖动、企业微信服务临时不可用，这些都有可能造成推送丢失。WorkBuddy 的任务编排里支持设置重试策略，我建议把它设置成失败后重试 3 次，间隔分别设为 1 分钟、5 分钟、15 分钟——前两次解决瞬时故障，第三次兜底。

还有一种更稳妥的做法是：把推送结果也写入一个本地日志文件。我不是在 WorkBuddy 里做的，而是利用代码解释器在推送后追加写一条记录到日志文件。这样万一第二天你发现没收到日报，可以直接打开日志看是采集环节失败了、生成环节失败了，还是推送环节失败了，排查速度会快很多。

7. 常见问题与排查实录：能救一个是一个

7.1 日报没推送？先查这三处

这类问题我大概遇到了四五次，每次排查的路径都差不多。第一步看 WorkBuddy 的任务日志，确认定时任务当天有没有正常运行。如果任务连跑都没跑，基本是时区配置问题或者调度器被暂停了。第二步看采集环节——检查一下 RSS 源是不是正常返回了数据，有时上游 RSS 源本身挂掉了，任务照样跑，但采集到的内容是空的。第三步看推送环节的日志，确认 webhook 的返回码是不是200，如果是4xx说明请求格式有问题，5xx可能是企业微信服务端的问题。

排查顺序一定要从上游往下游走，不要一上来就看推送。我见过有人遇到没收到日报，第一反应就是改 webhook 配置，结果把本来正常的部分也改坏了。先看数据流到哪儿断了，再动手改。

7.2 日报内容质量忽高忽低

这个问题的根源大概率在提示词写得不够具体，或者全局规则没有严格执行。大模型的输出是概率性的，同样的提示词，两次生成结果可能有差异。我自己处理的办法就是版本化管理提示词——WorkBuddy 支持给提示词配置版本号，我每次调整都会存一个新版本，如果效果变差了，就回滚到之前的版本。

另外，我强烈建议在日报生成之后、推送之前，让 AI 自己做一个"质量自检"：检查是否每条新闻都有来源 URL、是否超过字数限制、格式是否符合模板。这个自检步骤会额外多消耗一些 API 调用时间，但换来的是每天日报的稳定质量。我加了这一步之后，几乎没再因为格式问题重推过。

7.3 海外 RSS 源抓取延迟或失败

不少优质 AI 信源都在海外服务器上，国内网络环境访问时延迟高或者直接失败。这个问题我在搭建过程中也遇到了，尤其是某一阵子，Hugging Face 的 RSS 时好时坏。解决思路有几个：第一是给 WorkBuddy 配置代理，如果你自己的网络环境有可用代理，直接在抓取请求里加上 proxy 配置；第二是切换镜像站点的 RSS 地址，部分开源项目提供镜像服务，速度会快很多；第三是在 RSS 读取失败时启动网页抓取兜底，用浏览器的能力直接访问原始页面。

不过这里我要提醒一句，配置代理属于网络环境相关的常规操作，具体能不能用、怎么用，取决于你自己所在网络的情况，我不展开细说。我只想强调：不要因为一个信源抓不到就不管了，要把失败处理纳入任务逻辑里，否则整个日报会因为这个单一依赖点而变得不可靠。

7.4 企业微信里 markdown 格式渲染异常

这个问题比较诡异，但确实发生过。同样的 JSON 内容，在某一天推送后，微信里显示的 markdown 没有渲染，直接显示了原始语法字符。我查了下原因，大概率是接口返回了特殊转义，或者在推送到服务端时多了一层转义。

解决办法是在 WorkBuddy 的消息推送节点里，把 content 字段做一次 JSON 序列化处理，确保特殊字符被正确转义。比如换行用\n，引号用\"，这样微信端的解析器能正确处理。另一个经验是不要用多级嵌套的 markdown 语法，保持在最简形态——标题 + 加粗 + 链接 + 列表，这样即使渲染出了问题，纯文本状态下也能看懂。

8. 后续还能怎么玩：从日报到自动化工作流

这个日报任务跑起来之后，我有了一个很深的体会：一旦你习惯了"信息主动送上门"的状态，就很难再回到"自己主动去刷"的旧模式。最近我正琢磨着把这几条经验复制到别的任务上。

比如周报生成。以前每周五下午都要花一两个小时写周报，现在我打算把本周所有工作通知、会议记录、项目进展的碎片信息，在每周四周五自动汇总成一个"周报素材包"，推给我。这样周五写周报就变成了在已有素材上进行补充润色，效率能提高不少。

再比如关键词追踪。我现在有一个特别关注的研究方向，比如"多模态 Agent"，那么我可以另外建一个监控任务，专门捕捉全网这个方向的新动态，一旦发现符合特定条件的重大进展（比如有新的论文发布），不仅推日报，还直接推一条强提醒通知到我手机上。这个需求本质就是把日报里的筛选条件极端化，构建一个"雷达"任务。

如果你也想搭类似的自动化，我的建议是千万别一上来就把流程做得很复杂。先从最简单的做起：一个信息源、一种推送方式、一条不加筛选的摘要。跑通之后，再逐步加信源、加筛选规则、加评分机制。这个迭代过程虽然慢，但每一步都扎实，最终的系统一定比凭空设计出来的要靠谱得多。

我个人实际用下来的体会是：工具的选型固然重要，但真正决定体验的是你有没有想清楚"要什么"和"不要什么"。给 WorkBuddy 设的这个闹钟，技术上一点都不炫酷，它就是一个定时触发、抓取、生成、推送的循环。但这个循环一旦转起来，每天稳定地帮你节省三十分钟，一年下来就是一百八十多个小时——这笔账，怎么算都不亏。