企业官网建设流程全解析

如果你也是那种每天早上打开手机，被几十个公众号和新闻客户端轮番轰炸的人，那这篇文章应该正好能帮上忙。我最近干了一件特别“偷懒”的事：给 WorkBuddy 设了个闹钟，每天上午十点半，它自动把一份整理好的 AI 日报推进我的微信群里。整个过程从触发、生成、推送到归档，大概两分钟，期间我不用碰一下电脑。

先说清楚 WorkBuddy 是什么。如果你们还没接触过，可以把它理解成一个带“工作台”的 AI 智能体，不只是聊天框，它能按规则执行任务、调用外部工具、读网页、建文件，在某些版本里还支持 skill 技能包。而我做的事情，本质上是把“每天早上花四十分钟刷 AI 资讯”这件事，拆成了“定时任务 + 信息收集 + 结构化输出 + 微信推送”四段流水线，交给 WorkBuddy 和系统计划任务一起跑。

这篇东西不是产品说明书，我也没打算教你背命令。我会尽量把设计思路、踩坑过程、关键代码和那些“文档里不会写”的细节都摆出来。不管你是开发、产品、运营，还是单纯想给自己搞个 AI 信息助理，这套方案都能直接抄作业。

1. 为什么我要给 WorkBuddy 装一个“定时闹钟”

1.1 日报真正值钱的部分，是筛选而不是搜集

最开始我试过纯手动刷信息，订阅了一堆公众号和 newsletter，结果每天光“已读”就要花掉大半个上午。后来我也试过让 WorkBuddy 随口帮我“总结几条 AI 新闻”，效果很飘：有时候它给我推三天前的旧闻，有时候一口气列二十条，排版乱得根本不想看。

问题不在于 WorkBuddy 笨，而在于我没给它定规矩。日报不是搜索引擎的“结果堆叠”，它应该有明确的骨架：今天最重要的 3 条焦点、模型和应用更新、值得关注的开源项目、以及对我实际工作有影响的观点。这个骨架一旦固定下来，AI 输出就会稳定得多。所以我的第一个决定是：日报的核心不是“抓取”，而是“筛选”，WorkBuddy 的价值在于它能同时完成搜索、对比、摘要和结构化输出，而不是简单地扔给我一屏链接。

1.2 十点半这个时间点，是我踩过时间坑之后定下来的

很多人第一反应是“早上八点推送，起床就能看”。我也试过，结果发现太早真不行。AI 圈子里的重要更新很多来自海外开源社区和技术博客，八点的时候很多页面还没来得及更新，WorkBuddy 抓到的经常是前一天的存量信息。推得太早，日报就变成了“昨日黄花”。

下午再推又失去了“日报”的意义，中午一过，新鲜感就没了。最后我把时间定在十点半：这时候晨会基本开完，用户也处理完早上最紧急的一波消息，正好空出几分钟认真读一份日报；更重要的是，上午十点前后是欧美技术圈夜间更新基本落定、内容源相对完整的时间窗口。这个时间点我连续测了一周，稳定性和信息新鲜度都明显好过八点档。

1.3 为什么是微信，而不是邮件或者独立网页

我还真纠结过触达渠道。邮件胜在排版自由，但现在谁每天主动打开邮箱？网页面板更别提了，还要我手动输网址、登录、点击查看，一旦忘了，这份日报就白做了。微信是我每天打开次数最多的应用，没有之一，推送到达后扫一眼就能读完，不需要额外跳转。

具体到实现方式，我选了群机器人 webhook，而不是去开发一个微信小程序。原因很简单：企业微信群机器人申请一个群就能拿到，接口就一个 URL，免费、无需审核、支持 Markdown 消息，十分钟就能跑通。对个人或者小团队来说，这是性价比最高的微信推送通道。后面我会把完整的接入代码放出来。

2. 搭建思路：全局规则、skill 模板和推送链路

2.1 给 WorkBuddy 定几条全局规则，让后续所有任务都默认守规矩

我见过很多人在用智能体的时候只会在对话里临时补一句“你写日报的时候记得标注来源”，结果第二天一问，它又忘了。原因就在于：对话里的临时指令只对当前这一轮任务生效，再开一个新任务，所有临时约束都会归零。

WorkBuddy 这一类工具通常都会提供一个“全局规则”或“系统提示词”的配置入口，放在这里的内容，会作为底层约束注入到后续每一次任务执行里。我实际配置的内容大致长这样：

global_rules: - "所有输出统一使用简体中文" - "日报内容必须标注来源和日期，禁止出现无法核实来源的传闻" - "每条新闻摘要控制在 50 字以内，只保留事实判断，不写虚的形容词" - "信息按影响力排序，而不是按抓取顺序" - "涉及数字和版本号时，必须与源页面保持一致"

这一条特别重要，热搜词里那句“给 workbuddy 定几条规则，后续对所有任务都生效”说的就是这个场景。如果你把规则只写进某一次 prompt，那叫临时约定；只有写进全局配置，它才叫工作制度。我在第四部分会专门讲这个坑。

2.2 在 skill 里固化日报模板，AI 输出才稳定

全局规则管的是“态度”，skill 管的是“格式”。如果你让 AI 自由发挥，它会每次生成一个结构的日报，一会儿列表、一会儿表格、一会儿故事体。所以我建了一个名为ai_daily_report的 skill，相当于给 WorkBuddy 一份“岗位说明书”。

skill 里面我固定了几层信息源优先级：官方发布页和技术博客排第一，arXiv 和 GitHub Trending 排第二，科技媒体的深度报道排第三。这样 WorkBuddy 不会因为某个蹭热点的营销号把重要新闻挤掉。输出模板是这样的：

# AI 日报 {{date}} ## 今日焦点（3 条） - 事件 / 影响 / 我的判断 ## 模型与应用更新 - 模型发布、版本更新、API 变更 ## 开源项目与论文 - 值得跟踪的仓库、论文、数据 ## 对开发者的影响 - 这与我当前工作场景的关系

模板固定之后，Output 的稳定性直线上升。我只需要在每天早上触发时告诉 WorkBuddy“按ai_daily_reportskill 生成今天的日报”，它就知道该采集哪些来源、按什么结构落盘、用什么样的口吻写摘要。

2.3 推送链路选型：企业微信机器人为什么最省事

触达渠道的对比，我直接列一张表，省得你们来回试。

我自己最后留下的是企业微信群机器人。它最大的优势是两个：不需要申请任何额外权限，拉一个只有自己的群就能拿到 webhook；消息类型支持 Markdown，体验比纯文本好很多。要注意的是 webhook 地址就是一个携带 key 的 URL，一旦泄露，任何人都能往你群里发消息，所以绝对不能把它提交到公开的 Git 仓库里。

2.4 整条数据流其实就是一条流水线

如果你把整套系统拆开看，它不复杂：

系统计划任务在十点半触发脚本；脚本调用 WorkBuddy 的命令行接口，注入日期、路径，要求它按 skill 生成日报；WorkBuddy 完成任务后把 Markdown 文件写到指定目录；脚本读取文件、按长度截断，然后通过企业微信机器人 webhook 推送到群里；最后文件自动按日期归档。

这个流水线的好处在于每个环节都可以单独替换。比如你今天想改成飞书机器人，只需要换掉那个send_to_wechat函数；想把时间改成早上九点，改一行计划任务就行。后面讲周报扩展的时候，你会发现这套结构根本不挑任务类型。

3. 手把手落地：从 CLI 调用到系统定时任务

3.1 准备工作：确认 WorkBuddy 环境和 CLI 命令

在写脚本之前，我先花十分钟确认 WorkBuddy 在本机能不能通过命令行独立调用。终端里先跑两条命令：

workbuddy --version workbuddy run "你好，请回复 OK"

不同年头、不同发行版的命令名可能略有差别，但思路是一样的：必须确保它能在不打开图形界面的情况下，通过一条命令接收 prompt 并返回结果。等到这条命令稳定执行成功，后面的事情就都很顺了。我一开始在这个环节卡了很久，因为我在图形界面里能用，但命令行一跑就报“无法定位工作目录”，后来发现是没有初始化本地配置目录，执行一次初始化命令就好了。

另外一个容易被忽视的问题是脚本运行环境。系统计划任务执行脚本时，不会加载你自己终端里那一堆自定义环境变量。所以我后来在脚本开头就写死了几个绝对路径，别贪图省事用相对路径，否则手动跑是好的，定时跑就各种报错。

3.2 核心脚本：生成日报文件

我建议让 WorkBuddy 直接把日报写到本地文件，而不是把 stdout 拿回来解析。原因有两个：一是终端输出的转义和编码问题很烦，Windows 上经常出现 Unicode 乱码；二是文件归档本来就是日报这个场景的刚需，按日期落盘等于自动建了历史数据库。

#!/usr/bin/env python3 # -*- coding: utf-8 -*- import subprocess import pathlib import datetime DATE = datetime.date.today().isoformat() REPORT_DIR = pathlib.Path("/data/ai-reports") REPORT_PATH = REPORT_DIR / f"daily-{DATE}.md" def generate_daily_report(): prompt = ( f"请按照 ai_daily_report skill 生成今天 {DATE} 的 AI 日报，" f"把结果保存到文件 {REPORT_PATH}" ) result = subprocess.run( ["workbuddy", "run", prompt], capture_output=True, text=True, timeout=300, encoding="utf-8", ) if result.returncode != 0: raise RuntimeError(result.stderr[-500:]) return REPORT_PATH if __name__ == "__main__": report_file = generate_daily_report() print(f"日报已生成: {report_file}")

这里有几个细节。timeout 我给了 300 秒，因为 AI 需要搜索来源、读取页面、整理摘要，如果限定太短容易出现中途失败。如果你发现自己的机器配置比较差，可以放宽到 600 秒，然后在计划任务里把“如果任务仍正在运行，则不要启动新实例”这个选项打开，避免重叠加塞。

3.3 推送代码：企业微信机器人的 Markdown 消息

文件生成之后，接下来就是推送。企业微信机器人的 webhook 调用非常简单，用requests发一个 JSON 即可。我额外做了两件事：一是判断返回码，二是内容长度保护。企业微信机器人的 Markdown 消息正文有长度限制，超过之后会被直接拒绝，所以我会先把内容截断到安全范围，避免推送失败。

import requests import json WEBHOOK_URL = "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=你的key" def send_to_wechat(content: str): # 企业微信 markdown 消息有长度限制，保留前 4000 字符 content = content.strip()[:4000] payload = { "msgtype": "markdown", "markdown": { "content": content } } resp = requests.post(WEBHOOK_URL, json=payload, timeout=15) data = resp.json() if data.get("errcode") != 0: # 常见频控错误会返回 45009，这里只简单抛出 raise RuntimeError(f"企业微信推送失败: {data}")

如果你连requests都不想装，用 curl 也能实现同样的效果，适合先在命令行里验证 webhook 是否可用：

curl 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=你的key' \ -H 'Content-Type: application/json' \ -d '{"msgtype":"text","text":{"content":"hello from WorkBuddy"}}'

第一次测试通过之后，再把这段 curl 替换成 Python 版本，放进完整的调度脚本里。

完整的调度脚本其实就是把 3.2 和 3.3 拼起来：先调 WorkBuddy 生成日报文件，再读文件内容，最后推送微信。我在把这两段代码合并的时候额外加了一行日志记录，把每次执行的时间、生成文件路径、推送结果写进run.log，方便日后排错。

3.4 注册到系统计划任务：Windows / Linux / macOS

生成和推送的脚本搞定之后，剩下就是让系统每天上午十点半自动执行它。

在 Windows 上，我推荐直接用计划任务。打开“任务计划程序”，创建一个新任务，触发器设置为每天 10:30，操作里把程序指向你的 Python 解释器和脚本路径。也可以用命令行一步到位：

schtasks /Create /TN "WorkBuddyDailyAI" /TR "D:\Python312\python.exe D:\scripts\generate_daily_report.py" /SC DAILY /ST 10:30

Linux 或 macOS 就简单多了，直接上 crontab：

30 10 * * * cd /opt/workbuddy-report && /usr/bin/python3 /opt/workbuddy-report/generate_daily_report.py >> /var/log/workbuddy-daily.log 2>&1

这里有两个坑必须交代清楚。第一，Windows 计划任务不会加载你终端 shell 里的 PATH，所以/TR里的 Python 一定要写绝对路径，否则会出现“脚本运行不了但手动执行没问题”的诡异情况。第二，如果你的电脑在十点半正好处于关机或睡眠状态，任务就不会按时触发。Windows 可以在任务设置的“条件”页里勾选“如果错过计划开始时间，尽快启动任务”；Linux 下就得靠anacron或者让电脑保持开机，这一点要在部署之前想清楚。

3.5 首次试跑与效果验收

我在正式部署后，连续观察了三天。第一天的 output 有点偏长，一个焦点写了三段；第二天的 output 又过短，只有干巴巴的四条列表。后来发现是我 skill 里的摘要字数约束写得不够死，补上一句“焦点部分单条不得超过 80 字”之后，内容就稳定下来了。

验收日报是否合格，我给自己定了三条标准：第一，是否包含至少 3 条我完全不知道的新信息；第二，是否能在 3 分钟内读完；第三，所有数字和版本号是否能追溯到原始链接。三天跑下来，前两个标准都达标了，第三个偶尔有偏差，AI 还是会在摘要里加入自己的推测，这是它的天然毛病，后面我会专门讲如何约束。

4. 跑起来之后的避坑实录：从失败到稳定

4.1 最常见问题速查表

如果你也照这套方案搭了一个，大概率会遇到下面这些情况。我先给一张速查表，再挑几个详细展开。

4.2 “规则不生效”的真正原因：临时指令和全局规则的区分

这个坑我印象最深，必须单独拿出来说。刚开始我把所有约束都写在 prompt 里，例如“请生成今天日报、要标注来源、要用简体中文、要按 1.2.3 格式”。当时 WorkBuddy 执行得非常好，我还以为自己已经大功告成。结果第二天重新执行，它完全放飞了，标题变成营销号风格，来源标注也丢了。

排查到最后发现问题出在规则生效范围。prompt 里的约束是“一次性”的，只会注入到当前任务上下文。只要换一个 session、换一个任务进程，之前的约定就全部消失。真正想让“每条日报都执行同一套标准”，必须把这些约束写进全局规则，让它对所有任务默认生效。这也是我在 2.1 里反复强调配置管理的原因。对这类智能体平台来说，规则不是写出来提醒自己的，而是写进配置中心让每次执行都能读到的。

4.3 路径、环境变量和定时器上下文不一致的坑

第二个高频坑是“手动执行一切正常，定时执行必挂”。我一开始在 Windows 上遇到这个问题，任务计划程序里明明填了脚本路径，但是每次执行都一闪而过，日志里也没有任何输出。

后来我把 Python 解释器路径、脚本路径、工作目录全部改成绝对路径，并且把日志重定向到固定文件，才看到真实报错：脚本里用了一个相对路径的配置文件，手动运行时的当前目录是项目目录，定时运行时的当前目录却是C:\Windows\System32，自然找不到配置。解决方式是在脚本开头用pathlib.Path(__file__).parent把项目根目录算出来，再把所有路径拼在绝对根目录之上，从此再也没犯过这个错。

4.4 推送频率限制和超长内容的处理

企业微信机器人的频控策略比较严格，单个机器人每分钟最多发送 20 条消息。对于一天一份日报来说完全够用，但如果你把多份报告、告警消息都堆到同一个群里，就要小心了。我后来把周报也接进了同一个 webhook，周五下午恰好和几条系统告警撞在一起，结果有一条被限流丢掉。

应对办法是给推送函数加一个简单的退避重试机制，失败后等待 60 秒再试，但最多只重试两次。为什么不能无限重试？因为日报不是实时告警，错过一条不会造成事故，但无限重试反而可能触发连环限流，把后面的消息全部堵死。至于超长内容，企业微信会直接拒绝发送，所以我的做法是截断到 4000 字符以内，并把完整版留在本地文件里，需要的时候再去翻归档。

4.5 确保 AI 不胡编：来源标注是我最后的底线

做日报最怕的不是漏掉新闻，而是 AI 把不存在的“新闻”一本正经地写出来。市场上有太多大模型为了凑字数编造版本号和发布会，放到日报里就是事故。为了把这个风险压到最低，我做了三件事：在全局规则里强制每条内容附原始链接；让 WorkBuddy 只从我在 skill 里指定的信息源抓取，不给它自由发挥的空间；每天人工花十几秒扫一遍标题，看到可疑的内容直接点进来源核对。

我知道这一步对自动化来说显得有点“倒退”，但它非常必要。AI 自动化最大的价值是节省信息收集和整理的时间，而不是替代最终的判断责任。

5. 从日报到自动化面板：这套机制还能扩展成什么

5.1 把同一套 skill 升级成周报和月度复盘

日报跑顺之后，你会自然想把它扩展到更大的周期。我的做法是复制了一个ai_weekly_reportskill，把 prompt 改成“整理本周重要 AI 动态”，并且让它读取本地日报归档目录里最近七天的文件，做一次聚合。

这一步价值很大。周报不是日报的简单拼接，它需要提炼趋势，比如“这周模型推理成本下降是不是一个共性现象”，或者“这周哪个开源项目 star 增长异常”。WorkBuddy 只需要把日报中的零散信息当作素材，重新归纳一遍，就能输出更高质量的分析。我的周报就设置在每周五下午三点推送，忙了一周之后正好作为总结。

5.2 接入多群推送、@ 特定人和关键字提醒

企业微信机器人的 webhook 是按群生成的。如果你想让不同群接收不同内容，只需要多申请几个 webhook，然后按群分发脚本的结果即可。比如我的日报推给“个人助手”群，周报推给团队项目群，告警消息推给“值班”群，每个群的 webhook 都是独立的，互不影响。

如果你的团队用企业微信办公，还可以在机器人消息里带上 @ 成员，格式是<@userid>。这样当日报里出现某个成员负责的模块时，可以提醒他重点关注。不过这块我没有深入做，因为我更倾向于把日报当作“不打扰”的参考材料，一旦开始 @ 人就失去了低干扰的优势。

5.3 我对这类自动化的真实态度：定期生成，但保留人工确认环节

跑了两个多月，我的总体感受是：这套系统帮我省下的不是“每天四十分钟”的时间，而是每天决策“该看什么”的精力。以前面对几百条推送会焦虑，现在固定时间、固定格式、固定触达渠道，反而让阅读变得更专注。

但我没有把系统设置为“完全无人值守”。每周我会抽出十分钟人工核对日报来源是否可靠、信息源有没有失效、模板有没有因为版本升级而变形。这个动作听起来不酷，却是所有自动化系统长期稳定运行的真正保险。建议大家也从日报这种低风险、低权限的任务开始做自动化，先磨合规则，再逐步扩大范围。等 WorkBuddy 完全摸清了你的阅读习惯和信息标准，说不定下一步它就能帮你直接整理工作周报了。