企业官网建设流程全解析

你有没有过这种体验：早上眼睛还没完全睁开，先条件反射地打开公众号、技术群、科技媒体，生怕漏掉一条和 AI 相关的新闻。页面刷了不少，真正记住的没几条，时间倒是搭进去半个多小时。后来我干脆把这活儿外包了——给 WorkBuddy 设了个“闹钟”，每天上午十点半，一份整理好的 AI 日报自动送到我的微信里。

WorkBuddy 是一款偏智能体（AI Agent）思路的 AI 工作台，支持给 Agent 设置定时任务和长期规则（Skill），它可以自主完成“搜索信息源 → 筛选判断 → 编写日报 → 调用接口推送到微信”这一整条链路。说白了，就是雇了一个不要工资、每周七天固定上班的信息编辑。这篇文章不聊概念，我就完整复盘一下这套日报流水线的搭建过程：从需求拆解、规则配置、推送选型，到踩坑排查和后续扩展，全记录下来。无论你是刚开始用 WorkBuddy，还是已经在电脑上装好了它想找个实战场景，这份记录应该都能直接抄作业。

1. 先拆需求：每天 10:30 的日报，到底在解决什么问题

1.1 痛点是“信息太多”，不是“信息太少”

我从去年开始密集跟进 AI 方向的动态。每天要看的东西大致有这几类：几个头部媒体的 AI 板块、大模型厂商的官方博客、GitHub 上的热门项目、arXiv 上值得读的论文，再加上朋友圈和群里被转发的文章。人肉刷一遍至少一两个小时，而且刷到的内容严重重复——同一个模型发布新版本，可能五六个账号在写，写的内容差别还不大。

所以我要的根本不是又一个信息聚合器，而是一个能帮我做筛选和判断的“助理”。它不需要把全网信息都给我，只需要回答一个问题：过去 24 小时里，哪些 AI 动态值得我花时间看。标题里写的“每三十分钟日报”听起来很简单，真正难的部分在“筛选”和“判断”，而不是“抓取”。

1.2 方案选型：为什么是 WorkBuddy，而不是自己写个定时脚本

最早我考虑过最传统的方案：写一个 Python 脚本，定时拉取几个 RSS 源，把标题拼起来再通过推送接口发到微信。这个方案确实能跑通，但用了几天我就发现几个问题：

• 信息源多了以后，每个网站的解析规则都不一样，有的有 RSS 能用，有的没有 RSS，有的改了页面结构，脚本就拉不到内容了。
• 拼接出来的“日报”没有判断力。它只是把一堆标题堆在一起，没有优先级、没有归类、更没有观点。
• 每次想调整日报格式，都要回去改代码、重启服务，维护成本不低。

换成 WorkBuddy 之后，这几个问题基本被绕开了。WorkBuddy 自带定时调度，不用自己维护 crontab；任务用自然语言定义，想改格式直接改提示词；最关键的是，它是 Agent 架构，能自己决定下一步调用什么工具——搜索网页、读取链接、发送 HTTP 请求，全流程自动串联。对比下来大概是这么个感觉：

用 WorkBuddy 唯一要适应的，是它的思维方式从“写命令”变成了“写规矩”。你告诉它目标、边界、输出格式，剩下的执行路径由 Agent 自己规划。一开始会不太放心，觉得不受控，跑几天之后你会习惯的——它比大多数人想象的靠谱。

1.3 整条链路三大件：定时、生成、推送

整套日报流水线拆开来看，就是三个环节：定时触发、内容生产、消息送达。定时触发是那个“闹钟”，每天 10:30 把 Agent 叫醒；内容生产是“编辑”，让 Agent 按照指定规则写日报；消息送达是“邮差”，把最终日报通过微信通道送到你手上。

这三个环节必须分开考虑，因为出问题时排查逻辑完全不同。定时没触发，问题多出在时区或调度配置；日报内容质量差，问题多在提示词和 Skill 规则；消息没收到，问题基本在推送通道。下面我会按这三个环节逐个讲配置细节，再讲实操和排查。

2. 核心设计：WorkBuddy 定时任务与 Skill 规则的配置要点

2.1 定时触发：10:30 这个时间点怎么设置

定时任务在 WorkBuddy 里属于基础能力，配置入口一般在任务或自动化面板。支持两种方式：一种是直接在界面上选“每天”，然后填具体时间；另一种是填 cron 表达式。

如果要用 cron 表达式，每天上午 10:30 对应的写法是30 10 * * *。拆开来看：第一个星号位置是分钟，填 30；第二个星号位置是小时，填 10；后面三个分别是日、月、星期，全部留星号表示“每天都执行”。这里我建议尽量用 cron 表达式，因为它的表达能力更强，你以后想改成“工作日执行”或“每周一三五执行”，改配置就行，不用重新创建任务。

有一个非常容易踩的坑：时区。如果你运行的 WorkBuddy 是在 Docker 容器或者海外服务器上，系统默认时区很可能是 UTC。UTC 早上 10:30 换算成北京时间就是晚上 18:30，你会在一个错误的时间收到日报。我一开始就是没注意这个，连续两天下午收到日报才发现问题。解决办法很直接：把容器的时区环境变量设为Asia/Shanghai，或者在 WorkBuddy 的设置里看看有没有时区选项，实在不行写 cron 的时候直接把 8 小时差换算进表达式里。

2.2 Skill 规则：把“日报怎么写”沉淀成长期约束

Skill 是 WorkBuddy 的一个关键设计，相当于给 AI 立规矩。和每次写提示词不同，Skill 一旦定义好，可以设成全局生效——后面你新建任何任务，它都会自动带上这套规则，这就对应了标题里说的“给 WorkBuddy 定几条规则，后续对所有任务都生效”。

我给日报任务立的规则是这五条：

• 日报是写给懂技术的朋友看的，不要公文腔，不要“重磅”“震惊”这类标题党用语。
• 每一条信息必须有来源链接，没有明确来源的内容不允许写进日报。
• 同一事件如果有多篇报道，只保留信息最完整的一篇，其余直接丢弃。
• 每条信息先写结论，再补细节，全文控制在 150 字以内。
• 某个板块如果当天没有足够重要的内容，就省略该板块，宁缺毋滥。

写这些规则的时候有个心得体会：规则越具体，Agent 的产出越稳定。比如只说“要附来源”，它可能会写一个看起来像链接的字符串；改成“没有明确来源的内容不允许写进日报”，它的行为就会严谨很多。规则不是越多越好，而是每条都是可执行的硬约束。

2.3 Agent 的日报提示词模板

有了全局 Skill 之后，再给 Agent 一条核心提示词，告诉它每天具体要干什么。下面这个模板我用了很久，可以直接复制：

你是一名深耕 AI 领域的科技编辑，每天必须产出一份中文 AI 日报。 信息获取方式： 1. 主动检索并浏览多个优质信息源，包括 AI 科技媒体、大模型厂商官方博客、开源社区热门项目、论文发布平台。 2. 优先选择过去 24 小时内发布的、有明确出处的内容。 3. 对同一事件的多篇报道进行交叉比对，只保留信息最完整的一篇。 日报结构： 【今日焦点】2-3 条最重要的动态，每条用 2-3 句话说明核心信息和影响。 【大模型与产品】模型发布、能力升级、产品功能更新。 【开源与开发者】GitHub 热门项目、开发工具链、框架版本更新。 【行业与观点】重要融资、合作案例、值得一读的观点文章。 硬性要求： 1. 每条必须附原始链接。 2. 每条正文不超过 150 字，先写结论再补充细节。 3. 用自己的话转述，不抄原文。 4. 某板块没有重要内容时直接省略，不凑数。

说下这个模板的设计逻辑。“角色设定”那段非常关键，你不告诉 Agent 它是一个编辑，它就会默认自己是搜索引擎，给你罗列一堆链接；你告诉它“是编辑”，它才会去判断“哪些值得写”。“板块结构”是为了让微信端的阅读体验更清晰，读者扫一眼就能定位到自己关心的内容。“硬性要求”是为了对抗大模型的输出毛病——它特别容易在摘要里写废话，限字数、要求先结论后细节，能有效提升信息密度。

2.4 微信推送通道选型：四个方案对比

日报写好了，下一步是送到微信。这一环的选择直接决定了整个方案的稳定性。我实际调研和试用过四种方式：

我个人最终的选择是“企业微信群机器人”加“Server酱”双通道。企业微信群机器人负责把日报发到团队的群里，@所有人 看早报；Server酱再单独给我个人发一份，保证就算我没看群也不会漏。两个通道互不干扰，一个挂了另一个还能兜底。

这里有个方向性的建议：做微信推送，优先选官方接口通道，比如 Server酱这种基于微信服务号的方案，或者企业微信的 Webhook。不要自己去研究个人微信的协议对接，那种方案一是不稳定，二是有合规风险，完全没有必要。走正规通道，配置一次能用很久。

2.5 信息源怎么选：决定了日报质量的上限

日报质量一半由提示词决定，另一半由信息源决定。我给 WorkBuddy 设置的信息源分为两个梯队。第一梯队是每天必看的：主流科技媒体的 AI 板块、几家头部大模型公司的官方博客、开源社区的热门项目榜、开发者社区的热帖。第二梯队是按需调用的：学术论文平台的 AI 分类、几个长期更新的深度分析博客。

信息源总数我控制在 10 个以内。原因很简单，信息源太多 Agent 光搜索就花掉大量时间，而且容易抓到过时或低质量的内容。设置了优先级之后，它会把注意力放在第一梯队上，第二梯队只在第一梯队信息不足时补充。还有一个实用技巧：如果某个信息源没有提供 RSS，可以在给 Agent 的指令里直接描述“打开某个入口页面，定位最新发布区块”，Agent 会自动点击进去找新内容，不需要你再提前写好解析规则。

3. 实操记录：从装好 WorkBuddy 到 10:30 准点推送

3.1 准备阶段需要做的事

在动手配置之前，先把三样东西准备好：WorkBuddy 本体、大模型 API Key、推送通道的凭证。

WorkBuddy 安装本身不复杂，从官方渠道下载对应平台的安装包，安装后登录账号，在设置里填入大模型服务的 API Key 就行。有一点提醒：如果你的电脑比较老，注意看一下 WorkBuddy 对系统版本的要求，太旧的系统可能不支持新版，这时候找历史版本比折腾升级系统省事。

推送通道以 Server酱为例，去它的官网用 GitHub 或微信扫码登录，得到一个 SendKey，后面调用接口时会用到。整个过程几分钟就能搞定，不需要配置服务器。

3.2 创建 Agent 和 Skill

打开 WorkBuddy，新建一个智能体，我起的名字叫“早报编辑”。这个名字不是随便起的，Agent 的名字会出现在上下文里，起一个明确的功能名比叫“助手”更能让它理解自己的职责。

然后进入 Skill 管理，新建一个全局规则，把 2.2 里的五条规则写进去，生效范围选择“所有任务”。这里要注意，Skill 保存后最好先在对话里测一下，用最简单的一句话比如“请按照全局规则评价这条消息”，看它是不是真的遵守了规则。我遇到过规则写得太模糊，Agent 完全无视的情况，当场改掉比等日报上线后才发现好得多。

3.3 配置定时任务和推送节点

接下来就是重头戏：在任务页面新建一个定时任务。我的配置过程分四步：

1. 任务名称填“AI日报-10:30”，方便之后在任务列表里一眼认出来。
2. 触发条件选“每天”，时间填 10:30，如果支持 cron 就直接填30 10 * * *。
3. 任务内容里绑定“早报编辑”Agent，并指定执行日报生成的核心提示词。
4. 添加一个“HTTP 请求”节点，把日报内容发送到推送通道。

第四步是整条链路里最技术化的地方。企业微信群机器人的 Webhook 地址是固定的，HTTP 请求节点里只需要配置 POST 方法和请求体。以 Server酱为例，请求体大致是这个结构：

{ "title": "AI 日报（每日 10:30）", "desp": "这里填入 Agent 生成的日报内容" }

对应到 curl 命令就是这个效果：

curl -X POST "https://sctapi.ftqq.com/你的SendKey.send" \ -H "Content-Type: application/json" \ -d '{"title": "AI 日报（每日 10:30）", "desp": "日报正文内容"}'

要说明的是，实际配置时你不一定真的执行 curl。多数情况下 WorkBuddy 的 HTTP 请求节点里可以直接填 URL、请求方法和 Body 模板，把 Agent 输出的内容映射到desp字段即可。如果你需要在其他脚本里复用这套逻辑，上面的 curl 命令就是一个标准的参照。

3.4 首次联调的正确姿势

配置完成后先别急着开定时，手动触发一次任务，验证三件事：日报内容是否完整、链接是否真实有效、微信有没有收到推送。

我第一次跑的时候，日报倒是生成出来了，但推送消息里只有标题没有正文。排查后发现是 HTTP 请求节点里变量映射的问题——它默认发送的是会话的标题字段，而不是 Agent 输出的正文内容。把变量改成指向最后一条消息的正文字段之后，问题就解决了。

这里分享一个非常重要的小技巧：先用“随便别的什么时间”验证整条链路，确认没问题再改成 10:30。比如你可以把定时先设在 10:29（假设你正在调试），坐等一分钟看它跑不跑；不要直接设成 10:30，然后等一天后才发现没推成功，那就白等了。

3.5 跑起来之后的迭代节奏

定时任务上线后，建议不要频繁改配置，先让它跑一周。一周后回看每天的日报，你会明显看出哪些内容你会点开、哪些内容你根本不会看。我的日报最开始是大模型新闻偏多，后来发现真正给我价值的是“开源工具”板块，于是我把提示词里的板块顺序调整了一下，把“开源与开发者”提到了第二位。

日报的格式稳定之后基本不用再管它，只需要每隔一段时间检查一下数据源是不是失效了。Agent 挂在某个不可用的数据源上时，它会自动找其他源，但如果所有源都老了，日报的质量就会明显下降——这时候需要更新一下信息源列表。

4. 踩坑实录：日报流水线的调试笔记与避坑建议

4.1 到点了没推送，先排查三件事

定时任务到点没触发，不用慌，按顺序排查。第一是时区问题，很多情况下容器默认是 UTC，日报会“准时”在错误的时区推送。第二是 cron 表达式本身有没有写对，有些 WorkBuddy 版本只认标准五段式表达式，不要想当然地用类似H 10 * * *这种 Jenkins 语法——它根本不认。第三是进程是否常驻，WorkBuddy 所在的那台电脑或服务器有没有休眠、断网、重启，任何一环断了任务都不会执行。

我的经验是，定时任务这类东西一定不要放在日常办公笔记本上。笔记本一合盖就休眠了，日报自然就歇菜了。找一台长期在线的设备（比如家里的迷你主机、NAS 里的虚拟机）来跑，一劳永逸。

4.2 推送成功但内容为空，大概率是变量映射问题

日报生成了，微信也收到消息了，但正文是空的。这种情况如果出现在配置阶段，九成是 HTTP 请求节点里变量映射没配对。你要发送的是 Agent 生成的完整日报正文，而不是会话标题、任务名称这样别的内容。检查一下请求体里对应的模板变量是否指向了正确的字段。如果正文字段被截断，则多半是推送通道的长度限制。Server酱这类服务对单条消息长度有上限，日报写太长就会丢内容。解决方法是压缩日报长度——我后来把每条摘要限制在 150 字以内，总条数控制在 8 到 12 条，截断问题基本不再出现。

4.3 日报内容同质化、像“新闻联播摘抄”，怎么治

跑了几周后你会遇到一个质量瓶颈：日报里的每条新闻都能看，但都是一句话复述原文，没有观点、没有分析。这个问题的根源不在信息源，而在于提示词里缺少“编辑视角”的要求。

我的解决办法是在 Skill 里补了一条规则：所有信息必须用自己的话重新组织，并写清楚这条新闻对谁有影响、意味着什么。听起来简单，但效果非常明显。比如同样写一个开源框架发布新版，之前 Agent 写“某框架发布 2.0 版本，包含多项新特性”，补上规则之后它会写成“某框架 2.0 发布，新增功能主要用于简化 Agent 状态管理，正在做相关项目的开发者可以重点关注”。哪个有阅读价值，一目了然。

4.4 链接失效怎么办：让“无法确认来源的信息”写不出来

AI 生成的日报最让人头疼的问题之一是链接。大模型有概率生成“看起来像真的”但实际不存在的链接，这是模型训练时的记忆偏差导致的。我在早期就吃过几次亏，点开日报里的一个链接，结果是 404。

解决办法是在提示词里加一条硬约束：所有链接必须来自 Agent 实际访问过的页面；如果无法确认来源，就不写链接，只写“信息来源于某平台”。比这个更稳的做法是让 Agent 优先从 RSS 源获取条目，因为 RSS 里的链接通常就是真实有效的原始链接，拿到链接后再去抓取页面内容做摘要，既保证链接真实，又有摘要质量。

4.5 常见问题速查表

5. 日报流水线的更多打开方式

5.1 多人、多主题日报并行

这套模板建好之后，复制成本极低。我现在给团队分别跑了三个日报：AI 技术动态、产品市场观察、行业融资信息。每个日报只需要新建一个 Agent、配置不同的信息源和提示词，再指向不同的企业微信群即可。Skill 里的全局规则完全复用，不需要重复定义。如果你需要跟进多个方向又不想手动分流信息，这个思路可以直接照搬。

5.2 日报自动沉淀成周报

日报看的是“今天发生了什么”，但时间长了你会需要一个“这周到底发生了什么”的总结视角。我的做法是在 WorkBuddy 里再加一个周五下午的定时任务，让一个分析助手读取本周所有日报任务的输出，自动生成一份“本周 AI 要事回顾 + 趋势判断”，推送到同一个群里。因为日报规则是全局生效的，周报生成时也会自动保持“附来源、先结论”的底线，不会跑偏。

5.3 和知识库联动，构建个人 AI 信息库

更进一步的玩法是把每一期日报归档到知识库，日积月累形成一个可检索的个人 AI 情报库。之后你可以直接问 Agent：“这个月有哪些值得关注的开源 Agent 框架”“那家公司上个月发布了什么模型”，让它在历史日报里检索答案。注意归档时只保留合规、干净的内容，不要把敏感信息往里面存。这条链路跑通之后，你相当于给自己建了一个私人的领域知识库，时间和信息的复利效应会越来越明显。

最后说说我个人的真实体会。这套方案跑到现在，最让我满意的不是“每天自动推送”这件事本身，而是它把“追信息”变成了“收信息”。以前是我主动去刷，现在每天十点半微信准时响起，我花一两分钟扫完日报，有感兴趣的再点开链接细读，整个早上的信息摄入效率是完全不同的体验。最后再分享一个小技巧：搭建初期不用追求日报格式完美，先让链路从“生成到推送”通起来再说，后期靠改规则和 prompt 逐步迭代。你可能会发现，跑了一个月之后，这份日报越来越像你自己写的——因为是你亲手把规矩一条条教给它的。