企业官网建设流程全解析

每天早上十点半，我的微信会准时收到一份 AI 日报：当天值得关注的 AI 行业动态、模型发布、开源项目，以及几条我自定义关注方向的热点，全部被压成一篇可以直接读完的摘要。这不是哪个资讯 App 的订阅推送，而是我用 WorkBuddy 搭出来的一条自动化链路。做法说起来很直白——给 WorkBuddy 设一个每天十点半的"闹钟"（定时任务），到点让它自动收集信息、生成日报，再通过 Webhook 把内容推进微信。真正跑起来之后，我从"每天花一小时刷信息"变成"每天花五分钟看日报"。

这篇文章适合两类人：一是想给自己或团队搭定时 AI 日报、但不知道从哪下手的人；二是已经在用 WorkBuddy 这类 AI 工具、想把它从"问答助手"升级成"自动干活的小跟班"的人。我会把链路设计、定时触发、日报生成、微信推送四条线全部拆开讲，最后附上我这两个月踩过的坑和排查思路。

1. 为什么我要折腾这么一条日报链路

1.1 信息过载的真实痛点

先说背景。我每天要跟踪的东西包括：AI 圈的模型和工具发布、几个垂直方向的技术动态、还有竞品相关的消息。以前我的做法是早上到工位先刷一遍 RSS、再扫几个群聊记录、然后点开一堆公众号文章。这个过程看起来没什么，实际消耗非常大：半小时起步，而且经常刷完发现真正有价值的信息只有两三条，大部分时间是浪费在"过滤噪音"上。

更重要的问题是"不及时"。有些动态是半夜发的，等我早上刷到已经过了大半天；有些信息被群聊淹没了，等想到去翻记录，早就不知道沉到哪去了。我需要的不是一个"搜索工具"，而是一个每天固定时间主动把信息整理好送到我面前的自动化流程。这其实就是典型的定时任务加 AI 摘要场景：采集、过滤、总结、推送，四件事每天重复做。

1.2 WorkBuddy 在这个需求里的位置

一开始我想过两种方案：写纯脚本抓 RSS 再套模板，或者直接用一个现成的新闻简报服务。前者的问题是只能做关键词匹配，做不了"理解"——同样是"发布了新模型"，有的值得展开，有的只是一行带过，脚本判断不了；后者的问题是信息源不可控，我给你推送什么你就看什么。

然后我注意到 WorkBuddy。它本身是个 AI Agent 工具，除了能对话之外，可以自定义 skill（技能），也就是把一系列工具调用和提示词打包成一个可复用的任务。这正好命中我的需求：我可以把"读 RSS、抓网页、按我的关注点总结、输出固定格式"定义成一个 skill，然后让定时任务每天触发它跑一次。WorkBuddy 负责"理解和生成"的部分，定时任务负责"到点叫醒它"，微信推送负责"把结果送到眼前"。三者各管一段，互不干扰，出问题也容易定位。

这里我多说一句：很多人在这一步就把架构搞复杂了，想着让 WorkBuddy 自己带调度器、自己跑定时、自己推送。其实没必要。AI Agent 擅长的不是"守时"，而是"理解任务和生成内容"。把调度交给系统级的 cron，把推送交给现成的 Webhook 渠道，才是最少出错的分工。

2. 整条链路的设计：闹钟、Agent 和微信的分工

2.1 三个角色各干各的

我的链路拆成三段，每段一个明确职责：

这个拆法的好处是：任何一环出问题，我可以根据"哪一步断了"快速缩小范围。比如日志里显示 WorkBuddy 已经输出了日报，但我没收到微信，那问题一定出在推送环节，不需要重新排查前面两段。

2.2 为什么不让 WorkBuddy 自己"记住"定时

WorkBuddy 确实有任务和流程的概念，但它本质上是"被调用方"：你给它一个指令，它执行并返回结果。让它自己记住"每天十点半要干活"，等于把可靠性寄托在一个 AI 系统的内部状态上。万一它更新了、重启了、或者上下文被重置，这个"记忆"可能就没了。

而 crontab 是操作系统级的定时器，只要服务器不宕机、配置没写错，它就会按时执行。我用了一个特别朴素的比喻来给朋友解释这件事：WorkBuddy 是那个负责写稿的编辑，cron 是那个每天早上准时敲他门的闹钟，微信机器人是送报的。编辑可能忘事，但闹钟不会——所以我把"守时"这个最重要的职责，交给最不会出错的角色。

2.3 数据流向

完整链路是这样的：

1. crontab 在 10:30 执行一个 shell 脚本；
2. 脚本调用 WorkBuddy 的 CLI 或 API，传入今天要执行的 skill 任务（"生成今日 AI 日报"）；
3. WorkBuddy 按 skill 定义去读取信息源（RSS、网页、配置好的关键词搜索），做去重和 AI 总结，输出一段 Markdown 文本；
4. 脚本拿到输出，把它拼成微信消息的 payload；
5. 脚本用 curl 请求企业微信机器人 Webhook（或 Server酱），把消息推送出去；
6. 所有步骤写入本地日志文件，方便事后排查。

这个顺序看起来很简单，但每一步都有不少细节，下面我分开讲。

3. 定时触发落地：cron 才是真正可靠的闹钟

3.1 候选方案对比

"定时任务"听起来是个老生常谈的东西，但真到选型的时候还是有几个岔路。我梳理了四个方案：

• crontab（最终选择）：系统级，简单可靠，任何 Linux 机器都有。缺点是语法有点反直觉（五个星号很多人第一次看会懵），而且没有内置的失败重试。
• systemd timer：比 cron 更现代，支持更精确的控制和依赖关系，但配置相对麻烦，适合已经有 systemd 服务化习惯的人。
• Python APScheduler：适合整个流程都用 Python 写的场景，可以在代码里直接定义任务和重试逻辑，但依赖进程常驻，进程挂了任务就没了。
• WorkBuddy 自带调度：如果工具有这类功能，可以用，但我不建议作为唯一方案，原因上面说过——可靠性依赖 AI 系统的内部状态。

我的结论是：链路里最不能出错的一环用最保守的技术。cron 在 Unix 世界里跑了四十多年，为一个每天一次的日报任务，没必要上更复杂的调度器。

3.2 cron 配置与时区坑

cron 的语法是"分 时 日 月 周"，每天 10:30 对应的表达式是：

30 10 * * *

对应到 crontab 文件里，完整的一行是这样：

30 10 * * * /home/user/workbuddy-daily-report/run.sh >> /home/user/workbuddy-daily-report/cron.log 2>&1

这里有个我踩过的坑：cron 默认使用系统时区。如果你的服务器时区是 UTC，那30 10 * * *触发的是 UTC 10:30，也就是北京时间 18:30。第一次配完，我下午六点半收到了日报，还以为是延迟了。排查之后才发现是时区问题。解决办法是在脚本开头显式设置时区：

export TZ=Asia/Shanghai

或者在 crontab 里用CRON_TZ=Asia/Shanghai（不同发行版支持情况不一样，还是export TZ最通用）。配置完记得跑一下timedatectl确认服务器时区，养成习惯。

提示：改完 crontab 后先跑crontab -l确认配置已写入，再手动执行一次脚本验证，别等第二天早上才发现没生效。

3.3 一个完整的触发脚本

我的run.sh大致长这样：

#!/bin/bash export TZ=Asia/Shanghai cd "$(dirname "$0")" LOG_DIR="./logs" mkdir -p "$LOG_DIR" STAMP=$(date +"%Y-%m-%d %H:%M:%S") echo "[$STAMP] 任务开始" >> "$LOG_DIR/run.log" # 1. 调用 WorkBuddy 生成日报，输出保存到 report.md python3 generate_report.py >> "$LOG_DIR/generate.log" 2>&1 if [ -s report.md ]; then echo "[$STAMP] 日报生成成功，开始推送" >> "$LOG_DIR/run.log" # 2. 推送日报到微信 python3 push_wechat.py >> "$LOG_DIR/push.log" 2>&1 else echo "[$STAMP] 日报文件为空，跳过推送，请检查 generate_report.py" >> "$LOG_DIR/run.log" # 这里可以加一个告警，比如直接推送一条"日报生成失败" python3 push_wechat.py "今日日报生成失败，请检查日志" >> "$LOG_DIR/push.log" 2>&1 fi echo "[$STAMP] 任务结束" >> "$LOG_DIR/run.log"

这个脚本的重点不是代码多漂亮，而是把"生成"和"推送"拆成两步，并且每一步都有独立日志。report.md为空时宁可推送一条失败告警，也不要静默失败——这个习惯帮过我好几次。

4. 日报内容生产：怎么让 WorkBuddy 不跑偏

4.1 任务指令的结构化写法

定时跑 AI 日报和你在聊天框里问"今天有什么新闻"是两回事。手动问可以慢慢补充细节，定时任务不行——指令写得含糊，输出就跟着含糊，今天总结三条明天总结十条，格式也漂移。我的做法是把任务指令固定成一段结构化的 prompt，核心包含四个部分：

1. 角色：你是一名 AI 行业信息编辑，工作是把散落的信源整理成简明日报；
2. 任务：浏览以下信息源，筛选出与 AI 相关的动态，每一条用一句话概括核心信息；
3. 约束：最多输出 8 条，按重要性排序；不相关的信息直接忽略；只输出事实，不加评论；
4. 格式：严格按下面这个模板输出，不要额外发挥。

约束和格式是重点。没有约束，AI 会把"我注意到……"这种废话写进去；没有格式，每次输出的排版都不一样，推送到微信里看起来就像三流公众号。我建议把格式模板直接写死在 prompt 里：

# {日期} AI 日报 ## 今日焦点 1. **标题**：一句话概述（来源） 2. ... ## 值得关注 - **标题**：一句话概述（来源） - ... ## 简评 （不超过 100 字的整体观察，如果没有可不写）

4.2 信息源接入

WorkBuddy 的 skill 可以挂多个信息源。我的配置里有三类：

• RSS 订阅：主流 AI 媒体和开源社区的 RSS，每天增量抓取，WorkBuddy 负责把标题和摘要拉出来做初筛；
• 关键词监控：通过搜索接口（比如配置好的网页搜索工具）跑一遍我关心的关键词，如 Agent、多模态、开源模型、几家公司动态；
• 内部来源：我自己维护的一个"值得关注"清单，比如某个产品的更新页面、某个技术博客，WorkBuddy 会定时抓取检查有没有更新。

关于信息源，我的建议是宁少勿多。一开始我塞了二十多个源，结果 WorkBuddy 每天光抓取就要好几分钟，输出还经常被低质量内容淹没。后来砍到 8 个高质量源，日报质量明显上升，生成时间也稳定在 1 分钟内。做日报的核心不是"全"，而是"精"。

4.3 输出模板与格式稳定性

即使有了模板，AI 还是会有"自由发挥"的冲动。我做了两道保险：

第一，在 WorkBuddy 的 skill 定义里，把输出校验作为一个步骤写进去——生成完日报之后，检查是否包含"今日焦点"和"值得关注"两个小节，如果缺了，重新生成。这一步看起来笨，但实测能把格式稳定率从八成拉到接近满分。

第二，脚本侧再兜底。generate_report.py拿到 WorkBuddy 的输出后，会做一次基础校验：去头尾空格、检查是否有模板标记、计算总长度（超过 4000 字截断，因为微信消息有长度限制）。超出限制的情况确实发生过，因为某天信息爆炸，WorkBuddy 兴奋地写了五千字。截断逻辑虽然粗暴，但至少保证推送不会失败。

5. 微信推送：四条路我都试过，最后留了哪条

5.1 候选渠道对比表

微信生态的推送渠道五花八门，我实际试过的有四条，对比如下：

5.2 企业微信群机器人 Webhook 落地

我最终的方案是企业微信群机器人。理由很实在：免费、没有每日条数焦虑、Webhook 接入只需要一条 curl。建群之后在群设置里添加"群机器人"，会拿到一个 Webhook 地址，长这样：

https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

推送脚本的核心逻辑就一段：

import json import urllib.request WEBHOOK_URL = "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=你的key" def push_markdown(content: str): payload = { "msgtype": "markdown", "markdown": { "content": content } } req = urllib.request.Request( WEBHOOK_URL, data=json.dumps(payload).encode("utf-8"), headers={"Content-Type": "application/json"}, ) with urllib.request.urlopen(req) as resp: result = json.loads(resp.read().decode("utf-8")) if result.get("errcode") != 0: raise RuntimeError(f"推送失败: {result}") if __name__ == "__main__": with open("report.md", encoding="utf-8") as f: push_markdown(f.read())

企业微信机器人支持markdown消息类型，正好匹配 WorkBuddy 输出的 Markdown 日报。我为了在手机上看着舒服，把内容控制在 2000 字以内，重点加粗，用小标题分隔。实测推送到手机会自动渲染成富文本，阅读体验比纯文本好很多。

5.3 服务号模板消息和 Server酱的取舍

如果你没有企业微信群（或者觉得建群麻烦），Server酱是另一个不错的选择。它的思路是：你登录 Server酱官网，用微信扫码绑定，然后它给你的微信服务号发一条模板消息。调用方式和 Webhook 一样，也是发一个 HTTP POST：

curl "https://sctapi.ftqq.com/你的SendKey.send" \ -d "title=今日AI日报" \ -d "desp=$(cat report.md)"

注意 Server酱免费版每天 5 条的限制。日报一天一次刚好在 5 条以内，但如果你还想推其他通知（比如告警、会议提醒），额度就很紧张了。这也是我最终选企业微信机器人的原因——不想为了额度精打细算。

至于公众号模板消息，它需要认证服务号，个人主体很难搞定，而且模板消息本身就是给业务通知用的，拿来给自己推日报属于杀鸡用牛刀。除非你是在做面向用户的产品，否则不建议碰这条路线。

6. 完整实施记录：从零搭到稳定跑两个月

6.1 环境准备

我的运行环境是一台 2 核 4G 的 Linux 小服务器（家里 NAS 也行，只要保证常开就行）。软件依赖就三样：Python 3.9+、curl、WorkBuddy 的 CLI 或 API Key。这里重点说一句：WorkBuddy 如果装在服务器上，务必确认它能正常启动并保持运行状态。我的做法是把它跑在 systemd 服务里，防止机器重启后忘了手动拉起。

如果你还没有 WorkBuddy，安装完第一件事是跑通一次手动任务：在终端调用 CLI 执行你要的那个 skill，确认它能返回结果，再往下做自动化。这一步千万别省，否则后面你会分不清是调度问题还是 WorkBuddy 本身没配好。

6.2 核心脚本

整个自动化其实就三个文件：

1. run.sh：入口脚本，负责设置时区、按顺序调用下面两个 Python 脚本、写主日志；
2. generate_report.py：调用 WorkBuddy 生成日报，保存到report.md；
3. push_wechat.py：读取report.md，推送到企业微信机器人。

generate_report.py简化后的核心逻辑：

import subprocess import datetime def generate_report() -> str: # 调 WorkBuddy CLI 执行日报 skill # 这里用 workbuddy-cli 作为示例，实际以你安装的版本为准 cmd = [ "workbuddy-cli", "run", "--skill", "daily-ai-report", "--date", datetime.date.today().isoformat(), ] result = subprocess.run(cmd, capture_output=True, text=True, timeout=300) if result.returncode != 0: raise RuntimeError(f"WorkBuddy 执行失败: {result.stderr}") return result.stdout if __name__ == "__main__": content = generate_report() # 简单校验：非空、包含模板标记、长度截断 if not content.strip(): raise RuntimeError("日报内容为空") content = content[:4000] with open("report.md", "w", encoding="utf-8") as f: f.write(content)

这里最容易被忽略的是timeout=300。AI 生成是有耗时的，万一某天信息源抓取特别慢，WorkBuddy 可能超时。我在脚本里设了 5 分钟超时，超时就终止这次执行，宁可今天没日报，也不要让进程卡死影响下一次任务。

6.3 日志与自检

日志是这条链路的"黑匣子"。我的日志目录结构：

logs/ ├── run.log # 主流程日志，每次任务的开始和结束 ├── generate.log # WorkBuddy 执行日志 ├── push.log # 推送日志 └── report-2025-xx-xx.md # 每日日报存档

日报存档是个意外收获。跑了两个月之后，我手里攒了几十天的日报，回头查某件事的发布时间线特别方便。另外我写了一个简单的自检脚本，每天任务结束后检查三个东西：report.md是否存在且非空、推送接口是否返回errcode=0、整个流程是否在 10 分钟内完成。自检结果也推到微信，只不过发给自己所在的另一个群，不打扰日报群。这样相当于给自动化加了监控，日报没来我也能第一时间知道原因。

注意：第一次跑通后，建议连续观察三天再逐步增加信息源，避免一次改太多东西导致问题难定位。

7. 踩坑复盘：那些没收到日报的早晨

7.1 连续三天失联的排查链路

跑通之后的第二周，我连续三天早上没收到日报。按照架构设计，我直接从日志开始查。

第一步看run.log，发现每天早上 10:30 的"任务开始"日志都在，说明 cron 正常。第二步看generate.log，结果发现 WorkBuddy 执行报错，错误信息是网络请求超时。第三步看信息源，发现某个 RSS 源改版了，响应时间从原来的几百毫秒变成了 30 秒，WorkBuddy 抓取时直接超时。

问题找到了：不是调度问题，不是推送问题，是某个信息源拖垮了整个任务。解决办法有两个：一是把 WorkBuddy 的抓取超时调短，单个源超过 10 秒就跳过；二是把那个不稳定源从列表里踢掉。我做了第一件事，然后在 skill 里加了一条约束："单个源抓取超时超过 10 秒则跳过并继续"。之后日报再没因为这个原因断过。

这次排查给我的教训是：日志一定要分环节写。如果我只在run.log里写"任务失败"四个字，排查范围就得从 cron 一路查到 WorkBuddy 再到网络，至少折腾半小时。分日志之后，两分钟就能定位到generate.log里的具体错误。

7.2 常见故障清单

除了上面那次，这两个月我还遇到过几个典型故障，整理成清单：

其中 Webhook Key 失效那次最折腾——我换了企业微信账号，旧机器人的 Key 自然就吊销了，但脚本里的配置没改。这提醒我：把 Webhook 地址和 API Key 这类配置单独放在config.py里，不要硬编码在业务脚本中，换环境的时候只需要改一处。

8. 还能怎么玩：这套链路的扩展方向

8.1 多源多主题日报

跑通单条日报之后，我顺手扩展了几个变体：

• 多主题并行：除了 AI 日报，我还挂了"开源项目周报"（每周一推送）和"竞品动态监控"（有变动时即时推送）。做法完全一样的套路，只是换 prompt、换信息源、换 cron 时间。
• 早晚双报：早报偏行业动态，晚报偏技术干货。早报 10:30 发，晚报 18:00 发，两条 cron 互不干扰。

8.2 团队群推送和定时提醒

如果你有团队，这套链路可以直接搬进团队群。我有朋友按我给的方案搭了一个"团队日报"，每天早上把竞品动态、用户反馈摘要、行业新闻推进公司群，群机器人免登录免审核，比挨个转发链接高效得多。

另外，定时推送的用途不只有日报。我在同一台服务器上，还用同样的 cron 加 Webhook 套路做了每周提醒（比如每周五下午提醒提交周报）和项目状态播报。思路一旦打通，只要是"固定时间、固定动作、内容可变"的需求，都能用这条链路解决。

最后说一点个人体会：这类自动化的价值不在于技术多炫，而在于它稳定地替你省掉了重复劳动。我最初只是想少刷点新闻，后来发现它顺带养成了我每天早上看日报的习惯——因为推送就在那里，点开就能看完。如果你也想搭这么一套，建议先从最简单的版本开始：先手动跑通 WorkBuddy 的单次任务，再挂 cron，再接微信，一步步来，别一开始就追求完美。稳定跑起来之后，你会感谢那个每天十点半准时出现的"闹钟"。