企业官网建设流程全解析

1. 为什么我要折腾一个“AI 日报闹钟”

每天早上到工位，第一件事是打开各种信息源：技术社区的热榜、几个行业资讯站、团队内部的知识库更新、还有几个我长期跟踪的博主。一圈刷下来，二十分钟没了，真正有价值的信息可能就三五条。更麻烦的是，这事儿一旦忙起来就断档，断个两三天，再捡起来又得重新建立信息脉络。

我想要的其实特别简单：每天上午十点半，一份已经筛过、归过类、带摘要的 AI 日报，自动出现在微信里。不用我打开任何 App，不用我点任何按钮，就像设了个闹钟一样，到点东西自己就来了。

这个需求拆开看，核心就三件事：定时触发、内容抓取与 AI 加工、推送到微信。听起来像是个典型的自动化流水线，但真动手做的时候，坑比想象中多——尤其是“送进微信”这一步，微信生态对外部程序主动推送消息的限制是出了名的严格。

我前后试了三套方案，踩了七八个坑，最后跑通的这套组合是：WorkBuddy 做定时调度和流程编排，DeepSeek 做内容摘要和分类，微信侧用“文件传输助手 + 服务号模板消息”双通道兜底。整套东西跑了一个多月，除了有两天因为源站改版导致抓取失败，其余时间都是十点半准时到，误差不超过两分钟。

这篇文章我会把整套方案的选型逻辑、每个环节的具体配置、参数怎么算、坑怎么填，全部摊开讲。适合两类人看：一类是想给自己搭一套个人信息自动化流水线的，另一类是想把 WorkBuddy 和 DeepSeek 串起来做实际项目的。哪怕你之前没碰过自动化工具，跟着走也能跑通。

2. 整体方案设计与选型思路

2.1 为什么是 WorkBuddy 而不是自己写脚本

最开始我是想直接用 Python 写个脚本，挂个 crontab 就完事了。但实际写下来发现，一个“日报机器人”远不止定时执行那么简单。它需要：定时触发、多源抓取、失败重试、内容去重、AI 调用、结果格式化、推送分发、运行日志。这些东西如果全用脚本手写，光是异常处理和重试逻辑就够写两百行，而且换个信息源就得改代码。

WorkBuddy 吸引我的点在于，它把“任务编排”这件事做成了可视化配置。你可以把整个流程拆成若干个节点：触发节点、HTTP 请求节点、数据处理节点、AI 调用节点、推送节点。每个节点独立配置，节点之间用数据流串联。这意味着我改一个信息源的 URL，不需要动其他任何逻辑；我想加一个新的推送渠道，只需要在末尾挂一个节点。

提示：WorkBuddy 的节点式编排和传统脚本的最大区别在于“关注点分离”。脚本里所有逻辑揉在一起，改一处可能影响全局；节点式编排里每个节点只负责一件事，改动的爆炸半径可控。

另一个关键考量是定时触发的可靠性。crontab 在服务器重启后会丢失任务状态，而且如果上一次任务还没跑完，下一次又触发了，容易出现并发冲突。WorkBuddy 内置了任务锁机制，同一个任务在上一次执行未结束时，下一次触发会自动跳过或排队，这个细节在实际运行中非常关键。

2.2 DeepSeek 在流水线里扮演什么角色

抓取下来的原始内容是一堆标题和链接，直接推给我意义不大——我没时间一条条点开看。所以中间必须有一个“加工”环节，把原始信息变成可读的摘要。

我对比过几个方案：本地跑一个小模型做摘要，优点是数据不出本地，缺点是效果差、速度慢；用通用大模型 API，效果好但成本高。DeepSeek 在这个场景下的优势比较明显：中文摘要质量稳定、API 调用成本低、响应速度快。我实测下来，一篇 800 字的技术文章，DeepSeek 生成 100 字左右的摘要，耗时大约 1.5 到 2 秒，成本几乎可以忽略不计。

具体用法上，我不是让 DeepSeek 简单地“总结一下”，而是给它一个结构化的提示词，要求它输出固定格式的 JSON，包含：标题、一句话摘要、关键要点（最多三条）、所属分类、重要程度评分（1 到 5）。这样后续的格式化节点可以直接解析 JSON，不需要再做额外的文本处理。

2.3 微信推送的三种路径与最终选择

“送进微信”是整个方案里最折腾的部分。微信对外部程序主动推送消息的限制非常严格，我前后试了三种路径：

我最终选的是企业微信机器人 Webhook。原因很简单：配置成本极低，创建一个群，添加一个机器人，拿到 Webhook 地址，往这个地址 POST 一条消息就完事了。而且企业微信的消息可以同步到个人微信（如果绑定了的话），在手机通知栏就能看到。

注意：企业微信机器人的 Webhook 地址里包含一个 key，这个 key 等同于密码，不要泄露到公开仓库里。我在 WorkBuddy 里是把它存在环境变量里的，节点配置里只引用变量名。

如果你没有企业微信，退而求其次的方案是用服务号的模板消息，但需要有一个认证过的服务号，个人开发者申请比较麻烦。还有一个更轻量的方案是邮件推送，虽然不在微信里，但手机邮件 App 的通知也能达到类似效果。

3. 核心环节拆解与实操配置

3.1 信息源的选择与抓取策略

信息源的质量直接决定了日报的质量。我一开始贪多，塞了十几个源进去，结果每天抓回来一百多条，AI 处理要跑好几分钟，最后推给我的日报长得像一篇论文，根本看不完。

后来我做了减法，最终保留五个源，覆盖三个维度：

• 技术动态类：两个技术社区的热榜，主要看大家在讨论什么
• 行业资讯类：一个 AI 领域的资讯站，看有没有重要的产品发布或论文
• 深度内容类：两个我长期跟踪的博主更新，质量稳定
• 团队内部：一个内部知识库的更新列表

抓取方式上，大部分源用的是 RSS，少部分没有 RSS 的用 HTML 解析。WorkBuddy 的 HTTP 请求节点支持自定义请求头和超时时间，我一般把超时设成 15 秒，超过就跳过这个源，不让它拖慢整个流程。

{ "source_name": "tech_community_hot", "url": "https://example.com/api/hot", "method": "GET", "timeout": 15000, "headers": { "User-Agent": "Mozilla/5.0 (compatible; DailyBot/1.0)" }, "retry": { "max_attempts": 2, "interval": 3000 } }

重试策略我设的是最多两次，间隔三秒。实测下来，大部分临时故障（比如网络抖动）重试一次就能成功，两次还失败的基本就是源站挂了，再重试也没用。

3.2 DeepSeek 提示词的设计与调优

提示词的设计直接决定了摘要质量。我前后改了六版，最终稳定下来的版本是这样的：

你是一个技术资讯编辑。请对以下内容进行处理，输出严格的 JSON 格式，不要输出任何其他文字。 输入内容： 标题：{{title}} 正文：{{content}} 输出要求： { "title": "保留原标题，如果标题超过30字则精简", "summary": "用一句话概括核心内容，不超过80字", "key_points": ["要点1", "要点2", "要点3"], "category": "从以下分类中选择一个：模型发布、产品更新、技术教程、行业观点、工具推荐", "importance": 1到5的整数，5表示非常重要 } 注意： - summary 要客观陈述，不要加入主观评价 - key_points 最多三条，每条不超过40字 - 如果内容质量太低或无法理解，importance 设为1

这个提示词有几个关键设计点。第一，强制 JSON 输出，这样后续节点可以直接解析，不需要用正则去提取。第二，分类枚举，限定在五个类别里，避免模型自由发挥导致分类混乱。第三，重要程度评分，这样我可以在推送前做过滤，只推 importance 大于等于 3 的内容。

实测下来，DeepSeek 对这个提示词的遵循度很高，JSON 解析成功率在 98% 以上。偶尔会出现模型在 JSON 外面包了一层 ```json 代码块的情况，这个在解析节点里做一下兼容处理就行。

3.3 内容去重与排序逻辑

去重这件事比想象中重要。同一个新闻，可能三个源都在发，如果不去重，日报里会出现三条几乎一样的内容。

我的去重策略是标题相似度 + URL 域名双重判断。具体来说，先把所有条目的标题做归一化处理（去掉标点、转小写、去掉空格），然后计算两两之间的编辑距离。如果编辑距离小于标题长度的 30%，就认为是重复内容，只保留 importance 最高的那条。

排序逻辑上，我用的公式是：

最终得分 = importance × 0.6 + 时效性得分 × 0.3 + 来源权重 × 0.1

时效性得分是根据发布时间计算的，24 小时内的得 1.0，24 到 48 小时的得 0.7，超过 48 小时的得 0.3。来源权重是我手动给每个源设的，深度内容类的源权重高一些，热榜类的低一些。

这个公式不是拍脑袋想的，是我跑了两周之后根据实际阅读体验调的。一开始 importance 的权重设的是 0.8，结果推过来的全是“重磅”“震惊”类的内容，深度分析反而被挤掉了。调到 0.6 之后，平衡感好很多。

3.4 微信推送的格式化与发送

企业微信机器人的消息支持 Markdown 格式，这比纯文本可读性高很多。我的日报格式是这样的：

## AI 日报 · 2025-01-15 > 今日共筛选 8 条，以下按重要程度排序 ### 1. [模型发布] 某团队发布新一代开源模型 **摘要**：该模型在多项基准测试中表现优异，推理成本降低约 40%。 **要点**： - 参数规模 70B，支持 128K 上下文 - 开源协议为 Apache 2.0 - 已在多个平台上线 [阅读原文](https://example.com/article/123) --- ### 2. [技术教程] 如何用 WorkBuddy 搭建自动化流水线 ...

每条内容之间用---分隔，标题里带上分类标签，方便快速扫读。链接放在最后，想深入看的直接点。

推送节点里有一个细节需要注意：企业微信机器人对消息长度有限制，单条消息不能超过 4096 字节。如果日报内容太长，需要做分片发送。我的处理方式是，如果格式化后的内容超过 3500 字节，就按条目拆分，分多条发送，每条前面加一个“（1/3）”这样的序号。

4. 完整实操流程与关键参数

4.1 环境准备与 WorkBuddy 任务创建

WorkBuddy 的安装过程这里不展开，官方文档写得很清楚。重点说一下任务创建时的几个关键配置。

创建任务时，触发方式选“定时触发”，Cron 表达式填30 10 * * *，这就是每天上午十点半触发。时区一定要选对，我一开始没注意，默认是 UTC，结果推送时间是下午六点半，白白等了一天。

任务创建后，先别急着配节点，先把环境变量配好。我用到的环境变量有：

环境变量配好之后，节点里引用变量用{{env.VARIABLE_NAME}}的语法，这样配置和密钥分离，分享配置的时候不会泄露敏感信息。

4.2 节点编排的完整流程

整个任务的节点编排是这样的：

1. 定时触发节点：每天 10:30 触发
2. 并行抓取节点组：五个源并行抓取，每个源一个 HTTP 请求节点
3. 数据合并节点：把五个源的结果合并成一个数组
4. 去重节点：按标题相似度去重
5. AI 处理节点：循环调用 DeepSeek，逐条生成摘要
6. 过滤排序节点：按 importance 过滤，按得分排序
7. 格式化节点：生成 Markdown 格式的日报
8. 推送节点：发送到企业微信机器人
9. 日志节点：记录本次执行的结果，写入日志文件

并行抓取这个设计很关键。如果串行抓取，五个源每个平均 3 秒，光抓取就要 15 秒。并行之后，总耗时取决于最慢的那个源，一般 5 秒以内搞定。

AI 处理节点我设的是并发数为 3，也就是同时处理三条内容。这个数字是权衡的结果：并发太高，DeepSeek 接口可能限流；并发太低，处理速度慢。实测并发 3 的情况下，20 条内容大约 15 秒处理完。

4.3 参数计算与性能调优

整个流程的耗时分布大致是这样的：

从十点半触发到推送到达，整个过程大约 25 秒。这个速度我觉得可以接受，毕竟不是实时性要求很高的场景。

如果要进一步优化，最大的空间在 AI 处理环节。两个方向：一是提高并发数，但要注意接口的限流阈值；二是减少处理条数，在 AI 处理之前先做一轮粗筛，把明显不重要的内容过滤掉。我目前是在抓取阶段就做了限制，每个源最多取 10 条，总共不超过 50 条，去重后一般剩 20 到 30 条。

4.4 日志与监控配置

日志这块我踩过一个坑。一开始没配日志，结果有一天日报没来，我完全不知道是哪个环节出了问题，只能从头排查。后来加了日志节点，每次执行都记录：抓取到多少条、去重后剩多少条、AI 处理成功多少条、推送是否成功、总耗时多少。

日志格式我用的是 JSON Lines，每行一条记录，方便后续用脚本分析。日志文件按天切割，保留最近 30 天。

{"date":"2025-01-15","trigger_time":"10:30:00","fetch_count":47,"dedup_count":23,"ai_success":23,"ai_fail":0,"push_status":"success","total_duration":24.3}

有了日志之后，排查问题就快多了。有一次推送失败，我看日志发现 push_status 是 failed，错误信息是“webhook key invalid”，一查发现是企业微信机器人的 key 过期了，重新生成一个换上就好了。

5. 常见问题与排查技巧实录

5.1 抓取失败：源站改版与反爬

问题表现：某个源连续几天抓取结果为 0 条，日志里显示 HTTP 状态码 200 但内容为空。

排查思路：先手动访问那个源的 URL，看看返回的内容结构是不是变了。我遇到过一次，源站把文章列表从 HTML 里的<ul>改成了 JavaScript 动态加载，原来的解析规则完全失效。

解决方法：如果是 RSS 源，检查 RSS 地址是否还有效；如果是 HTML 解析，需要更新解析规则。我的建议是尽量用 RSS，因为 RSS 的格式相对稳定，源站改版一般不会影响 RSS 输出。如果必须用 HTML 解析，把解析规则写成可配置的，改的时候只改配置不改代码。

实操心得：我给自己定了个规矩，每个月第一个周一手动检查一遍所有源，看看有没有异常。这个习惯帮我提前发现了两次源站改版，避免了日报断档。

5.2 AI 处理超时或返回格式错误

问题表现：AI 处理节点报错，错误信息是“JSON parse failed”或者“request timeout”。

排查思路：JSON 解析失败通常是模型没有严格按格式输出，可能是在 JSON 外面包了代码块，或者输出了额外的解释文字。超时一般是网络问题或者接口限流。

解决方法：对于 JSON 解析失败，在解析之前先做一轮清洗，去掉json 和标记，去掉首尾空白。如果还是失败，就把这条内容标记为“处理失败”，跳过它继续处理下一条，不要让一条失败卡住整个流程。对于超时，把超时时间从默认的 10 秒调到 20 秒，同时把并发数从 3 降到 2。

import json import re def parse_ai_response(raw_text): # 去掉可能的代码块标记 cleaned = re.sub(r'^```json\s*', '', raw_text.strip()) cleaned = re.sub(r'\s*```$', '', cleaned) try: return json.loads(cleaned) except json.JSONDecodeError: # 尝试提取第一个完整的 JSON 对象 match = re.search(r'\{.*\}', cleaned, re.DOTALL) if match: try: return json.loads(match.group()) except json.JSONDecodeError: return None return None

5.3 微信推送失败：消息太长或格式错误

问题表现：推送节点返回错误码 40058 或 40008，提示消息格式不正确或消息太长。

排查思路：企业微信机器人对 Markdown 消息的支持有一些限制，比如不支持表格、不支持嵌套列表超过两层。消息长度超过 4096 字节也会报错。

解决方法：把表格改成列表，把嵌套列表拍平。长度问题用分片解决，我写了一个简单的分片函数，按条目拆分，保证每片不超过 3500 字节。

5.4 日报内容质量下降：信息源污染与模型漂移

问题表现：连续几天推过来的内容都是低质量的营销文或者标题党。

排查思路：先看是哪个源的问题，在日志里加上源名称字段，统计每个源的 importance 平均值。如果某个源的平均 importance 持续低于 2，说明这个源的质量在下降。

解决方法：短期方案是调低这个源的权重，或者直接暂时移除。长期方案是定期审视信息源列表，把质量下降的源替换掉。我一般每季度做一次信息源审查，看看哪些源还在贡献有价值的内容，哪些已经变成水文聚集地了。

注意：不要因为一两天的质量波动就急着换源，有些源的质量是周期性的，比如周末质量低、工作日质量高。至少观察一周再下结论。

5.5 定时任务未触发或重复触发

问题表现：日报没来，或者同一天收到了两份。

排查思路：先看 WorkBuddy 的任务执行记录，确认是没触发还是触发了但执行失败。如果没触发，检查 Cron 表达式和时区设置。如果重复触发，检查是否有多个任务实例在运行。

解决方法：Cron 表达式我建议用在线工具验证一下，确保理解正确。时区一定要显式设置，不要依赖默认值。重复触发的问题，WorkBuddy 有任务锁机制，在任务配置里开启“防止并发执行”选项即可。

6. 后续可以继续折腾的方向

这套东西跑了一个多月，基本达到了我最初的目标：每天十点半，一份筛选过的 AI 日报自动到微信。但用着用着，又冒出了一些新的想法。

第一个方向是个性化推荐。现在的排序逻辑是全局统一的，但不同的人关注点不一样。我在想能不能根据我过去一周的点击行为，动态调整分类权重。比如我最近在关注模型发布类的新闻，那这类内容的权重就自动调高。这个需要记录点击行为，目前还没做，但思路是可行的。

第二个方向是多端同步。现在只推送到企业微信，有时候在电脑前工作，更希望日报直接出现在浏览器的一个标签页里。我在考虑加一个 Web 页面，把每天的日报存成静态 HTML，通过一个简单的静态服务器提供访问。这样微信和网页两个渠道都能看。

第三个方向是交互式追问。现在的日报是单向推送，我看完之后如果有疑问，没法直接追问。如果能把 DeepSeek 的对话能力接进来，让我可以在微信里直接回复某条内容进行追问，那就更实用了。不过这个涉及到消息接收的处理，比单向推送复杂不少，需要再研究一下企业微信的接收消息接口。

最后分享一个我在配置过程中总结的小技巧：先把流程跑通，再优化细节。我一开始花了很多时间在调提示词上，想把摘要质量调到完美，结果整个流程还没跑通，调了也没法验证效果。后来我改变策略，先用最简单的提示词把全流程跑通，看到日报真的推过来了，再逐步优化每个环节。这个顺序很重要，先有反馈，再谈优化。