企业官网建设流程全解析

1. 先捋清楚需求：为什么日报要自动化，而不是每天手动查

作为一个每天靠 AI 新闻续命的人，我之前的早晨通常是这样的：地铁上打开十几个公众号和资讯站点，一路刷到公司，收藏夹多了十几条链接，脑子里却几乎没留下什么。后来我把这事交给了 WorkBuddy——直接在它里面设了一个每天上午十点半触发的定时任务，让它把当天的 AI 日报整理好，自动推进我的微信。这套流程已经稳定跑了两周，今天把完整方案拆开讲一遍：为什么这么设计、WorkBuddy 的定时触发机制是怎么工作的、微信推送通道怎么选，以及我踩过的几个坑。

先说需求。如果你的工作内容和 AI 沾边，不管是做开发、做产品还是做技术决策，每天至少需要知道这么几类信息：今天有没有新模型发布、有哪些好用的开源工具、大厂的 AI 产品线有什么动作、值得精读的论文和技术博客有哪些。这些信息分散在 X、GitHub、公众号、Hacker News、arXiv 和一堆邮件订阅里，全看一遍至少一两个小时。

你可能会说，一两个小时也还好吧？问题是绝大多数时候，刷完之后能留在脑子里的信息密度极低。我做过一个实验，把每天刷资讯的场景录下来，事后回看发现大部分时间花在"标题点击-快速滑走-再点击"的循环里，真正产生价值的时间不到十分钟。更糟糕的是，这种零散的获取方式没法沉淀，三天后想找一条当初看到的重要资讯，往往要翻很久的浏览记录。

所以我才想到做自动化。不是要省掉那一小时，而是要把"收集信息"和"理解信息"这两件事分开。收集交给工具，理解留给自己。WorkBuddy 能定义定时任务和技能（Skill），本质上给了我一个"值班实习生"：每天到点开工，按我的要求整理资讯，然后把成果送到一个我一定会看的地方——微信。

1.1 每天手动刷新闻的成本被低估了

很多人不愿意做这种自动化，潜意识里觉得"我每天刷一会儿也没花多少钱"。真去算账就发现不是这么回事。这里面的成本分三块：

第一块是时间成本。每天平均少说半小时，按一年算就是 180 多个小时。更关键的是这半小时通常发生在早上精力最好的时段，被无关信息消耗掉之后，上午写代码的专注度明显下降。

第二块是注意力成本。AI 资讯的标题几乎都是按"振奋人心"来写的，点进去可能只是某个模型发了个小版本更新。大脑反复被这种廉价刺激打断之后，对真正重要的信息反而麻木了。

第三块是管理成本。关注了这么多渠道，你得自己维护一个"信息管道"，哪天某个渠道不更新了你甚至不知道。定时任务把这个问题也一并解决了：所有源由 WorkBuddy 统一抓取，统一去重，统一输出。

1.2 我理想中的 AI 日报长什么样

在动手之前，我先给自己定了一个"日报验收标准"，避免做出来的东西又是一坨长长的链接列表：

• 每天 5 到 8 条，不再多，宁缺毋滥；如果当天确实没什么大事，允许只有两三条。
• 每条包含三件套：一句话结论、两三句摘要、链接来源。一句话结论负责让我快速决定"要不要细看"，摘要负责让我不点开也能知道大概内容。
• 按主题分类，目前固定四个分类：模型发布、开源工具、应用实践、值得读的论文。
• 格式是 Markdown，既方便我自己看，也方便一键转发到团队群。

有了这个标准，后面的 Skill 配置、提示词编写就都有了依据。顺便说一句，如果你也想搭一套，建议把这个标准写在最前面，因为你后面写提示词的时候会不断回到这个标准上来校准。

2. 定时任务是怎么在 WorkBuddy 里跑起来的：Skill、触发器和推送通道

在动手搭建之前，得先理解 WorkBuddy 这类 AI Agent 工作台处理定时任务的基本模型。我最初以为它就是个"定时帮你跑一段脚本"的调度器，实际用下来发现它的核心是三步结构：触发器定义什么时候干活，Skill 定义怎么干活，动作节点定义干完活之后把结果送到哪里。

这三个概念有点像工厂里的三张单据：生产计划、工艺路线、物流单。触发器就是生产计划，到点下达；Skill 是工艺路线，告诉 Agent 具体怎么加工；动作节点是物流单，决定成品怎么发出去。

2.1 WorkBuddy 的 Skill 与定时触发器是怎么协作的

Skill 在 WorkBuddy 里是一个可以复用的工作流单元。你可以把一段完整的提示词、一组工具调用步骤、甚至包含脚本执行的流程打包成一个 Skill，然后在定时任务里引用它。我理解它本质上是一个结构化的 Agent 任务定义，除了给大模型的指令之外，还包含了上下文、工具调用、输入输出约定。

定时触发器则是入口，最常用的配置是 cron 表达式。如果你用过 Linux 的 crontab，对这个应该不陌生。一个标准的五段式 cron 表达式从左到右依次是分、时、日、月、周。例如30 10 * * *表示"每天的 10:30 触发"；0 9 * * 1-5表示"每个工作日的 9:00 触发"。有些系统（比如 Quartz）会在最前面加一个秒字段，写成0 30 10 * * *，含义不变，只是多了秒的粒度。WorkBuddy 里新建定时任务时，一般会有可视化选择器，但直接填 cron 更精确。

两者协作的流程可以概括为：到了触发时间，调度器唤醒 Agent，加载对应的 Skill 定义，Agent 按 Skill 里写的步骤执行，在执行过程中可能会调用搜索工具、浏览器工具或者本地脚本，最后把输出写入指定位置或推送到外部接口。整个过程不需要人守着，唯一需要保证的是 Agent 登陆状态、网络连通性和外部服务的 token 有效性。

2.2 微信推送通道：企业微信群机器人、Server酱还是个人微信

日报生成之后，怎么送进微信是个值得提前想清楚的问题，因为它决定了你后面会不会被封号或者收不到消息。我把我考虑过的三种通道列个表格对比一下：

我最终选的是企业微信群机器人，原因很简单：我给自己建了一个只有我一个成员的群，拿到它的 Webhook 地址之后，任何脚本往这个地址发一个 HTTPS POST 请求，消息就出现在微信里了。这个通道的稳定性比我预想的要好，跑了两周没有一次丢失。Server酱也是个不错的选择，它把推送接口封装得更友好，适合不想折腾群的人，但免费版每天的推送条数有限额，用来推日报够用，如果后面想顺便推股票提醒、监控告警之类的，额度可能就紧张了。

这里有一个原则必须强调：使用微信的官方通道，不要使用任何第三方个人微信 hook 方案，封号风险真的不值得。我们就用官方提供的 Webhook 接口，完全合规。

3. 搭建全过程：让 WorkBuddy 每天十点半把日报送进微信

理论部分讲完，下面是完整搭建过程。我尽量把每个步骤展开，包括配置文件的写法、踩过的时区坑、以及怎么调试。

3.1 把"生成日报"固化成 Skill：配置与提示词模板

我先在 WorkBuddy 里新建了一个名为daily_ai_report的 Skill。创建入口在 Agent 配置面板的"技能管理"里，新建之后会得到一段 YAML 格式的定义，大致长这样：

name: daily_ai_report description: 生成每日 AI 资讯日报，并推送至微信群机器人 trigger: cron: "30 10 * * *" timezone: "Asia/Shanghai" env: webhook_url: "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=YOUR_KEY" search_source: "your_news_source" steps: - task: collect desc: "抓取 AI 相关资讯，按热度排序" - task: summarize desc: "筛选 5-8 条最重要的内容，按固定模板输出 markdown" - task: save desc: "写入 reports/$(date +%F).md" - task: push cmd: "python scripts/push_to_wechat.py reports/$(date +%F).md"

这个 YAML 片段里，trigger可以不用在这里写，我是放在定时任务配置里的，但把它写进来有个好处：Skill 自带说明，以后复制到别的工作区不用重新解释。真正关键的是steps里的四个步骤：collect负责抓取资讯，summarize负责筛选和整理，save负责落盘，push负责推送。每一步 WorkBuddy 都会按desc里的描述调用相应的工具。

接下来是summarize步骤里用的提示词模板，我写得比较细，因为这一步直接决定日报质量。给大家抄一段我现在的版本：

你是我的 AI 资讯编辑。请从今天的科技资讯中筛选出 5-8 条对开发者最有价值的 AI 动态，按以下规则输出： 1. 每条用一句话结论作为标题，结论要具体，禁止使用"重磅""震惊"这类词。 2. 标题下方另起一行写 2-3 句摘要，说明这条资讯的核心内容和为什么值得关注。 3. 最后附上原始链接。 4. 按四个分类分组：模型发布 / 开源工具 / 应用实践 / 值得读的论文。 5. 只输出 Markdown 内容，不要输出任何解释文字。 如果当天确实没有足够重要的内容，可以只输出 2 条，不要为了凑数降低标准。

注意最后一条，这个是我后来加的。最初版本没有这条，AI 为了完成任务会硬凑出八条，里面至少有两三条是无关痛痒的产品更新。加了"宁缺毋滥"的约束之后，日报信息密度高了很多。

3.2 设置上午十点半的 cron 闹钟：时区不能省

Skill 建好之后，接着在 WorkBuddy 的"定时任务"页面新建任务，关联到daily_ai_report这个 Skill。触发时间我填的是30 10 * * *，意思是每天 10:30 执行一次。

但这里有个很重要的细节：时区。我一开始没注意，直接在默认配置下填了30 10 * * *，结果第一次任务在下午六点半跑了。排查之后发现 WorkBuddy 的调度环境用的是 UTC 时间，而我在北京，差八个时区。解决方案有两种：一是在触发配置里显式指定时区Asia/Shanghai，二是自己手动换算成 UTC 时间再填（北京 10:30 对应 UTC 02:30，那就填30 2 * * *）。强烈建议用第一种，让系统帮你换算，否则到了夏令时切换的时候你会疯掉。

在 WorkBuddy 的 cron 配置面板里，一般都会有一个timezone选项。填Asia/Shanghai之后，任务触发时间的计算就统一按北京时间来了。这个配置看起来不起眼，但它是日后"任务准点跑"的大前提。

3.3 推送脚本：把 Markdown 翻译成微信能看懂的话

Skill 跑完之后会生成一个 Markdown 文件，现在需要把它推到企业微信群。企业微信机器人的 Webhook 接口很简单，支持的消息类型里正好有一种叫markdown，可以直接发 Markdown 文本。我用 Python 写了一个推送脚本，放在 WorkBuddy 的脚本目录里，内容是这样的：

import json import sys import requests from datetime import datetime WEBHOOK_URL = "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=YOUR_KEY" def build_content(filepath): with open(filepath, "r", encoding="utf-8") as f: content = f.read() return content def split_content(content, limit=4000): # 企业微信 markdown 消息单条最长约 4096 字节，超出按段落切分 if len(content.encode("utf-8")) <= limit: return [content] parts = [] lines = content.split("\n") current = "" for line in lines: candidate = current + "\n" + line if len(candidate.encode("utf-8")) > limit: parts.append(current) current = line else: current = candidate if current: parts.append(current) return parts def push(title, content): payload = { "msgtype": "markdown", "markdown": { "content": f"{title}\n{content}" } } resp = requests.post(WEBHOOK_URL, json=payload, timeout=10) result = resp.json() if result.get("errcode") != 0: print("push failed:", result) else: print("push ok") if __name__ == "__main__": filepath = sys.argv[1] content = build_content(filepath) today = datetime.now().strftime("%Y-%m-%d") for part in split_content(content): push(today, part)

脚本里做了两件比较重要的事：第一是用split_content把超长内容切开，因为企业微信群机器人对单条 markdown 消息的长度有限制，不切的话消息会整体发不出去；第二是每次推送前打印push ok或push failed，方便定位问题。实际接进 WorkBuddy 的步骤很简单：在push_to_wechat.py里把路径参数换成当天生成的文件路径即可。

4. 踩坑实录：日报没送到、内容被折叠、时区错乱

搭建过程看起来不复杂，但我从第一次触发到稳定运行，中间踩了不少坑。下面三个坑最有代表性，每个都反复折磨了我一阵子。我把完整的排查链路写出来，方便你对照。

4.1 "静默失败"：任务显示已运行，微信为什么没收到

第一次设置完定时任务后，第二天十点半我盯着手机等了五分钟，微信毫无动静。打开 WorkBuddy 的任务日志一看，状态显示"已完成"，但点进去发现summarize这一步输出为空，后面自然就没东西可推了。

顺着日志继续往前查，发现根因是搜索工具的使用额度用完了。我用的资讯搜索接口是按月限额的，月底那几天刚好额度清零，Agent 在调用搜索工具时拿到的是空结果，但它没有报错，而是很"礼貌"地完成了任务——输出了一篇内容为空的报告。这个现象我称之为"静默失败"：任务确实跑了，但没有任何有效产出，也没有任何错误提示。

解决方法是双层的。第一层是在 Skill 配置里加一个兜底判断：如果搜索步骤返回为空，就用预设的文案直接推一条"今日无重要更新"，同时标记为需要人工查看。第二层是给搜索服务加了一个额度告警，额度低于 20% 时提前推一条消息到微信。这样即使出问题，至少我有一个明确的信号，而不是等到第二天发现没收到日报才知道出事了。

另外提醒一句，如果你用的搜索源是某个需要 API Key 的服务，Key 到期是非常容易静默失败的。建议在 Skill 的collect步骤里把"检查 API Key 是否有效"也作为一个显式动作。

4.2 长文本被折叠：微信 markdown 的边界

第二个坑出现在第三天。那天内容特别多，筛出了十一条，我心想这次日报"内容丰富"了。结果推过去之后，微信里只显示了前三行，后面跟着一个"点击阅读原文"的折叠入口。

原因是企业微信机器人的 markdown 消息对长度有硬性限制，而且过长的内容会被客户端折叠处理。第一感觉是"那我砍短一点不就行了"，但实际没那么简单：每天的内容量不稳定，今天五条明天十条，不能写死长度。

后来我摸索出一个比较稳的方案：日报控制在八条以内，每条摘要不超过两行；推送脚本里按 4000 字节切分，超长的部分拆成多条消息发出。这样至少保证每条消息都能完整展示，哪怕被折叠，也是折叠在"消息条数"层面，而不是把核心内容折叠掉。还有一个小技巧：每条信息的标题和摘要之间用>引用块隔开，微信端的显示会清爽很多。

4.3 十点半变三更半夜：时区错乱排查

这个坑在 3.2 里提过，这里展开讲一下排查过程。某天我开始用一个新的工作空间测试流程，配置里没有显式写时区，第二天日志显示任务在 02:30 运行了——换算成北京时间正好是 10:30，看起来"准点"了，但我微信里收到的推送时间却是半夜两点半。

我一开始以为是消息延迟，后来查日志才发现，任务确实是在 UTC 02:30 执行的，推送也在这个时间，微信自然显示凌晨收到。换句话说，我的 cron 表达式30 10 * * *被系统理解为"UTC 时间的 10:30"，而我的本意是"北京时间的 10:30"。

排查链路梳理如下：

1. 先确认任务日志里的运行时间，看是否与预期一致。
2. 确认 WorkBuddy 调度环境默认使用的时区（一般是 UTC）。
3. 确认 cron 表达式的解析规则（是五段式还是带秒的六段式）。
4. 在触发配置里显式设置timezone: Asia/Shanghai。

这四步走完基本能定位所有时区问题。如果你用的是别的调度平台，尽量养成在配置里写明时区的习惯，不要依赖默认值。

5. 把自动化做厚：配置模板、扩展场景与我的体会

日报跑顺之后，我慢慢意识到这套"定时触发 + Skill + 微信推送"的模式不止能做日报。它本质上是一个将任意周期性信息处理任务自动化的通用框架。这里分享我目前沉淀下来的一套模板，以及我接下来准备扩展的三个场景。

5.1 直接抄作业：我最终用的配置模板

如果你也想在 WorkBuddy 里搭一套，可以直接参考下面这个配置。以我目前稳定运行的版本为准：

name: daily_ai_report description: 每天 10:30 生成 AI 日报并推送微信群 trigger: cron: "30 10 * * *" timezone: "Asia/Shanghai" env: webhook_url: "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=YOUR_KEY" search_source: "your_news_source" max_items: 8 steps: - task: collect desc: "抓取 AI 相关资讯，按热度排序，过滤掉 24 小时前的旧闻" - task: summarize desc: "按模板生成日报 Markdown，分类并附带链接" prompt_file: "prompts/daily_report.txt" - task: validate desc: "检查输出是否为空，为空时写入兜底文案" - task: save desc: "写入 reports/$(date +%F).md" - task: push cmd: "python scripts/push_to_wechat.py reports/$(date +%F).md"

prompt_file指向一个独立文件的好处是后续调整文案不需要动 Skill 结构，只改文本即可。我习惯把提示词和配置分开管理，这样复制到其他项目时也更干净。

5.2 闹钟之外：定时任务还能做竞品监控、周报、晨会摘要

尝到甜头之后，我又在 WorkBuddy 里加了三类定时任务，思路完全一样，只是换掉 Skill 的搜索关键词和提示词模板：

第一类是竞品监控。把search_source的关键词从"AI 新闻"换成你关注的几个竞品名字，再把推送时间定在早上十点。这样每天开工前就能看到竞品昨天有没有发新版本、有没有新功能上线、社区口碑有什么变化。做产品的朋友应该懂这个需求有多刚需。

第二类是周报自动生成。每周五下午四点半触发，Skill 里让它去拉取我这周的 Git 提交记录、任务面板里完成的事项，然后用提示词整理成一份三到五条的周报草稿推过来。我在草稿基础上改几分钟就能提交，省掉了回忆这周干了什么的过程。

第三类是晨会摘要。每天早上九点触发，拉取项目群新增消息、需求池变更、工单状态，用三行摘要概括"今天需要注意的事"。这个任务的搜索步骤不太一样，用的是工作台内部数据的查询能力，但对 WorkBuddy 来说流程是一样的。

这些场景都验证了一件事：定时任务真正的价值不是"每天帮你跑个脚本"，而是把那些你每天都在重复的"信息搬运和整理"工作，变成标准化流水线。你要做的只是定义清楚输入源、处理逻辑和输出目标。

最后说一点我的体会。跑了两周之后，我最大的感受不是"省了多少时间"，而是注意力被解放出来了。以前刷几十条新闻，本质上是把"收集"当成了"获得"，刷完有一种虚假的满足感，第二天什么也没留下。定时日报告诉我，把收集交给工具，把判断留给自己。当然，任何自动化都有失灵的时候，我现在给自己留了一个很小的兜底习惯：每天十点半之后如果微信没动静，就去翻一眼 WorkBuddy 的任务日志，这比盯着推送等消息要稳得多。工具不会替你思考，但它值得成为一个可靠的值班实习生。