企业官网建设流程全解析

1. 为什么我要给 WorkBuddy 装一个“十点半闹钟”

每天上午十点半，我的微信会准时弹出一条消息。不是老板催进度，也不是群里有人艾特我，而是一份排版整齐的 AI 日报——昨天我关注的几个技术方向有什么新动态、我手头项目的待办有没有卡点、当天值得留意的行业信息，全部浓缩在一条消息里。这件事我已经跑了小半年，从最初手动复制粘贴，到后来用 WorkBuddy 配合自动化流程全权托管，中间踩的坑足够写一篇长文。

先说清楚这套东西到底是什么。WorkBuddy在这里扮演的是“任务编排中枢”的角色，它负责把 DeepSeek 这类大模型的调用、数据的抓取整理、消息的推送这几件事串成一条流水线。AI 日报是最终产物，一份由模型根据我预设的关注点自动生成、经过格式化处理的简报。微信是投递渠道，因为这是我每天打开频率最高的应用，消息送到这里，我不需要额外装 App、不需要记着去某个后台看。自动化是灵魂，整个流程从触发到送达没有人工干预，我要做的只是在前一天晚上把关注方向微调一下。

这套方案解决的核心痛点很具体：信息过载。做技术的人都有体会，每天要跟的东西太多——某个开源项目更新了、某个模型发了新版本、某个工具链出了新玩法。靠人肉刷，要么刷不过来，要么刷得碎片化，看完就忘。我需要的不是“更多信息”，而是“经过筛选和归纳的信息”，并且最好在我刚坐到工位上、还没被会议打断的那个时间点送到眼前。十点半这个时间是我反复调过的：太早，前一天晚上的数据还没沉淀完；太晚，上午的节奏已经被打乱。十点半刚好是处理完紧急邮件、可以喘口气看看方向的窗口。

适合谁来参考这套东西？三类人。第一类是像我这样的一线开发者或技术负责人，需要持续跟踪特定技术栈的动态，但没时间做信息聚合。第二类是做运营、产品、投资的朋友，需要每天盯某个赛道的变化，逻辑完全一样，只是关注点从“代码库更新”换成“竞品动作”。第三类是想入门 AI Agent 自动化但不知道从哪下手的人，这套流程麻雀虽小五脏俱全，涵盖了触发、调用、处理、推送四个环节，跑通一遍对理解自动化编排很有帮助。哪怕你完全不懂编程，只要愿意照着步骤配置，也能把这套东西搭起来。

2. 整体架构拆解：一条消息背后的四段流水线

2.1 从触发到送达，数据到底走了哪几步

很多人一听“自动化日报”觉得玄乎，其实拆开看就是四段流水线，每一段各司其职，段与段之间用标准接口衔接。我用一个生活化的类比来解释：这就像你订了一份早餐外卖。触发环节是“闹钟响了”，相当于你下单的动作；数据采集是“骑手去店里取餐”，把原材料拿到手；AI 处理是“厨师加工”，把生的变成熟的、把散的变成整的；推送是“骑手送到你家门口”，最终交付。

具体到这套系统，第一段是定时触发。WorkBuddy 内置了调度能力，我设置了一个每天上午十点半执行的定时任务。这里有个细节值得说：触发时间不要设成整点，因为整点是各种系统任务的高峰期，容易排队延迟。我设成十点半，实测下来比十点整稳定得多。第二段是数据采集与预处理，从几个预设的信息源拉取原始内容，做去重、截断、格式清洗。第三段是模型调用与内容生成，把清洗后的素材喂给 DeepSeek，用我写好的提示词模板生成日报正文。第四段是消息推送，把生成的内容通过微信的接口发到我的对话里。

这四段里，最容易出问题的是第二段和第三段。数据采集的难点在于信息源格式不统一，有的返回 JSON，有的返回 HTML，有的干脆是一坨纯文本。模型调用的难点在于提示词要足够稳定，否则今天生成得像模像样，明天就给你胡言乱语。后面我会专门讲这两块的实操细节。

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

有人会问，这东西用 Python 写个脚本不就完了，为什么要用 WorkBuddy？我一开始也是这么想的，甚至真写过一个版本，用定时任务加 requests 库加模型 API，跑是能跑，但维护成本高得离谱。信息源改个字段名，脚本就崩；模型 API 换个版本，参数就得重调；想加个新信息源，得改代码重新部署。WorkBuddy 的价值在于它把这些“胶水逻辑”可视化了，改信息源、调提示词、换推送渠道，都是在界面上点几下的事，不用碰代码。

更关键的是容错和重试机制。自己写的脚本，一旦某一步失败，整个流程就断了，你得手动去查日志、手动重跑。WorkBuddy 的编排引擎支持节点级重试，比如数据采集失败了，它会自动重试三次，三次都失败才走异常分支，给我发一条“今天日报生成失败”的提醒。这个机制在实际运行中救了我很多次，尤其是某个信息源临时抽风的时候。

还有一个隐性好处是可观测性。自己写脚本，想看某一步花了多久、返回了什么，得自己打日志。WorkBuddy 每个节点的输入输出都能在界面上看到，调试的时候一目了然。我调提示词的那几天，就是靠这个功能快速对比不同版本的效果。

2.3 微信作为投递渠道的取舍

投递渠道的选择其实是个挺重要的决策。我试过邮件、试过飞书、试过钉钉，最后回到微信。原因很简单：触达率和打开率。邮件我一天可能只看两次，飞书和钉钉在工作时间之外基本不打开，只有微信是全天候在线的。日报这种东西，价值在于“被看到”，如果送到一个我三天才看一次的地方，那跟没送一样。

微信推送有几种实现路径，我选的是企业微信应用消息这条路。个人微信没有官方的机器人接口，第三方方案要么不稳定要么有合规风险，不建议碰。企业微信可以创建一个内部应用，拿到 CorpID 和 Secret，就能通过接口给自己的账号发消息。这个方案的好处是稳定、官方支持、不需要额外装东西，消息直接出现在企业微信的对话列表里。如果你没有企业微信，也可以注册一个，个人也能注册企业，流程不复杂。

注意：推送渠道的选择要优先考虑“你每天一定会打开的应用”，而不是“技术上最酷的方案”。我见过有人费半天劲接了个 fancy 的推送渠道，结果自己一周都不看一次，纯属自嗨。

3. 核心环节实操：从零把这条流水线搭起来

3.1 环境准备与 WorkBuddy 的基础配置

动手之前先把地基打好。你需要准备的东西不多：一个 WorkBuddy 账号（国际版和国内版功能有差异，日报这种场景国内版够用）、一个 DeepSeek 的 API Key、一个企业微信的管理员权限。这三样齐了就能开工。

WorkBuddy 的安装和初始化不复杂，注册后在控制台创建一个新的工作流。这里有个新手容易忽略的点：工作流的命名和分组要提前规划好。我一开始随手建了一堆“测试1”“测试2”，后来自己都分不清哪个是哪个。建议按“用途-频率”来命名，比如“日报-每日”“周报-每周一”，一眼就能认出来。

DeepSeek 的 API Key 在官网的控制台申请，申请完记得把 Key 存到一个安全的地方，不要直接写在代码或配置的明文里。WorkBuddy 支持环境变量和密钥管理，把 Key 配到密钥管理里，工作流里引用变量名就行。这一步多花两分钟，能避免以后 Key 泄露的麻烦。

企业微信这边，登录管理后台，在“应用管理”里创建一个自建应用，记下 AgentId、Secret 和企业的 CorpID。这三个值后面推送节点要用。创建应用的时候，可见范围记得把自己加进去，否则收不到消息。

3.2 定时触发节点的参数怎么设

触发节点是整个流水线的发令枪。WorkBuddy 的定时触发支持 Cron 表达式，也支持可视化配置。我建议用可视化配置，不容易写错。设置项主要有三个：执行频率、执行时间、时区。

执行频率选“每天”，执行时间填“10:30”，时区选你所在的时区。这里有个坑：时区一定要确认清楚。我有一次忘了设时区，系统默认用了 UTC，结果日报在北京时间下午六点半才到，完全错过了上午的窗口。改过来之后就好了。

还有一个进阶设置是错过执行的处理策略。如果十点半那一刻系统正好在维护或者网络抖动，任务没触发，是跳过还是补执行？我选的是“补执行”，但延迟不超过一小时。这样即使有小概率的抖动，日报还是能到，只是晚一点。如果选“跳过”，那就得等第二天了。

实操心得：定时任务的时间不要设在整点或半点之外的“奇怪时间”，比如 10:37 这种。虽然理论上没问题，但有些调度系统对非标准时间点的支持不够好，容易出玄学问题。10:30 这种整点后的半点，既避开了整点高峰，又在标准调度粒度内，最稳。

3.3 数据采集：把散落的信息源收拢起来

数据采集是决定日报质量的上游环节。你喂给模型什么，它就产出什么。我目前配了四类信息源：技术社区的热门讨论、几个核心开源项目的更新日志、行业媒体的头条、以及我自己维护的一个待办清单。

采集方式分两种。对于有公开接口的信息源，直接用 HTTP 请求节点拉取，返回 JSON 后用脚本节点提取需要的字段。对于没有接口的，用网页抓取节点，配置好选择器把正文抠出来。这里的关键是做减法：不要贪多，每个信息源只取最核心的三五条，取多了模型处理不过来，日报也会变得冗长。

清洗环节容易被忽视，但很重要。原始数据里往往有大量噪音：HTML 标签、广告文案、重复内容。我加了一个清洗脚本节点，做三件事：去 HTML 标签、按标题去重、超长内容截断到 500 字以内。截断这一步是为了控制后面模型调用的 token 消耗，500 字足够模型理解大意了，再长就是浪费。

# 数据清洗脚本示例（WorkBuddy 脚本节点） import re def clean_items(raw_items): seen_titles = set() cleaned = [] for item in raw_items: title = item.get('title', '').strip() # 去重 if title in seen_titles: continue seen_titles.add(title) # 去 HTML 标签 content = re.sub(r'<[^>]+>', '', item.get('content', '')) # 截断 content = content[:500] cleaned.append({'title': title, 'content': content}) return cleaned

这段脚本不复杂，但能省掉后面很多麻烦。我试过不清洗直接喂给模型，结果模型把 HTML 标签也当成内容处理了，生成的日报里夹杂着一堆尖括号，很难看。

3.4 DeepSeek 调用与提示词工程

这是整套系统的核心。模型调用本身很简单，填上 API Key、选好模型、把清洗后的数据拼进提示词就行。难的是提示词的设计，它直接决定日报的质量和稳定性。

我的提示词模板经过十几版迭代，现在稳定下来的结构是这样的：先给模型一个角色设定，告诉它“你是一个技术情报分析师”；然后给输出格式要求，明确日报分几个板块、每个板块写几条、每条多少字；接着给素材，把清洗后的数据按类别贴进去；最后给约束条件，比如“不要编造素材中没有的信息”“如果某类素材为空就跳过该板块”。

你是一名技术情报分析师，请根据以下素材生成一份简洁的日报。 输出格式要求： 1. 分三个板块：技术动态、项目进展、今日待办 2. 每个板块最多三条，每条不超过 80 字 3. 用简洁的陈述句，不要用营销腔 素材： 【技术动态】{tech_news} 【项目进展】{project_updates} 【今日待办】{todo_list} 约束： - 只使用素材中出现的信息，不要自行补充 - 如果某个板块素材为空，直接跳过该板块 - 不要输出任何解释性文字，直接输出日报正文

这个模板的关键在于约束条件。不加约束的话，模型会“脑补”，把没有的信息编进去，日报就失真了。加了“只使用素材中出现的信息”之后，幻觉问题基本消失。另一个关键是输出格式的明确性，你告诉它分三个板块、每板块三条，它就老老实实照做，不会自由发挥。

注意：提示词里的变量占位符要和上游节点的输出字段名严格对应。我踩过一次坑，上游输出的字段叫news_list，提示词里写的是tech_news，结果模型收到的是空字符串，日报里技术动态板块直接没了。排查了半天才发现是字段名对不上。

3.5 微信推送节点的配置细节

推送节点是把成果送到眼前的一步。企业微信应用消息的接口调用不复杂，WorkBuddy 里有现成的节点，填上 CorpID、Secret、AgentId 和接收人的 UserID 就行。

消息格式我选的是markdown 类型，因为日报有标题、有列表，用 markdown 渲染出来层次清晰。纯文本的话所有内容挤在一起，阅读体验差很多。企业微信的 markdown 支持有限，不支持表格和复杂嵌套，但标题、加粗、列表这些基础语法都支持，够用了。

{ "touser": "your_user_id", "msgtype": "markdown", "agentid": 1000002, "markdown": { "content": "## AI 日报\n\n### 技术动态\n- 条目一\n- 条目二\n\n### 项目进展\n- 条目一" } }

这里有个细节：消息长度有限制。企业微信的 markdown 消息有字数上限，超过会被截断。我的日报控制在 800 字以内，从来没触发过限制。如果你要推的内容很长，建议拆成多条发，或者只推摘要，详情放个链接。

还有一个体验优化：在消息开头加一个日期和一句话摘要。比如“7月15日 AI 日报 | 今日重点关注：XX 项目发布新版本”。这样即使我不点开，在消息列表里也能看到今天日报的核心看点，决定要不要马上看。

4. 踩坑记录与常见问题排查

4.1 日报内容质量不稳定的排查思路

跑了小半年，遇到最多的问题就是“今天的日报怎么怪怪的”。表现有好几种：内容空洞、格式错乱、出现幻觉、板块缺失。排查的时候按上游到下游的顺序查，效率最高。

先查数据采集。打开工作流的执行记录，看采集节点的输出。如果输出是空的或者只有一两条，那问题在上游，可能是信息源挂了或者选择器失效了。我遇到过一次某个技术社区的页面改版，选择器匹配不到内容，采集回来全是空字符串，日报自然就空了。解决办法是定期检查采集节点的输出，发现异常及时更新选择器。

再查模型调用。如果采集正常但日报质量差，看模型节点的输入和输出。输入里如果素材很乱，输出肯定好不了。输出如果格式不对，那就是提示词的问题。我建议把提示词里的格式要求写得更“死”一点，比如明确说“用 - 开头表示列表项”，模型就更不容易跑偏。

最后查推送。如果前面都正常但消息没到，检查推送节点的返回码。企业微信的接口返回 errcode 为 0 才是成功，非 0 的话对照文档查原因。常见的是 access_token 过期，WorkBuddy 一般会自动刷新，但如果配置有问题也可能失败。

4.2 定时任务不触发的几种可能

定时任务不触发是个让人抓狂的问题，因为你不盯着就不知道它没跑。我的做法是加一个心跳检测：如果十点半没收到日报，十点四十自动发一条提醒告诉我“今天的日报生成失败了”。这个提醒本身也是通过 WorkBuddy 发的，形成一个兜底。

不触发的原因我遇到过三种。第一种是时区配置错误，前面提过，改成正确时区就好。第二种是工作流被意外停用，有次我调试的时候手动停用了工作流，忘了重新启用，结果第二天没收到日报。第三种是调度系统资源紧张，任务排队了。这种情况比较少见，但如果你的任务正好和其他大任务撞在一起，可能会延迟。解决办法是把执行时间错开，或者设置补执行策略。

实操心得：给关键任务加一个“失败告警”分支。WorkBuddy 支持在节点失败时走异常分支，我在异常分支里配了一个推送节点，一旦主流程失败就给我发消息。这样即使日报没生成，我也能第一时间知道，而不是等到发现今天怎么没收到才去查。

4.3 API 调用频率与成本控制

DeepSeek 的 API 是按 token 计费的，日报这种每天跑一次的场景，成本其实很低。我算过一笔账：每天采集的素材大概 3000 字，提示词模板 500 字，输出 800 字，加起来不到 5000 token。按 DeepSeek 的价格，一天的成本不到一分钱，一个月也就几毛钱。这个成本完全可以忽略。

但如果你把频率调高，比如每小时跑一次，或者素材量很大，成本就会上去。控制成本的手段有几个：控制素材长度，清洗时截断到合理长度；选对模型，日报这种任务不需要最强的模型，用标准版就够；加缓存，如果某个信息源一小时内的内容没变化，就不用重复采集和调用。

频率方面，我建议日报就一天一次，最多早晚各一次。跑太频繁意义不大，信息没那么多更新，反而增加噪音。我试过一天跑四次，结果每次日报内容都差不多，纯属浪费。

4.4 微信推送的合规与稳定性注意事项

推送这块有几个红线要注意。不要用个人微信的第三方机器人方案，这类方案不稳定且有合规风险，账号可能被限制。企业微信的自建应用是官方支持的路径，稳定性和合规性都有保障。

消息内容要干净。不要推送任何敏感、争议性内容，日报就聚焦技术和业务信息。我见过有人把日报做成了“全网热点聚合”，什么话题都往里塞，这种很容易出问题。聚焦你的专业领域，既安全又有价值。

控制推送频率。即使是企业微信，短时间内大量推送也可能触发限制。一天一条日报完全没问题，但如果你要推多条，建议合并成一条发，或者间隔开时间。

5. 让日报更懂你的几个进阶玩法

5.1 用历史反馈微调关注方向

日报跑了一段时间后，你会发现有些内容你每次都看，有些内容你每次都跳过。这个反馈信号很有价值，可以用来优化信息源和提示词。我的做法是每周花五分钟回顾一下这周的日报，把“总是跳过”的信息源降权或去掉，把“总是细看”的方向在提示词里加重。

更进阶的做法是让模型自己学习你的偏好。你可以在提示词里加一段“历史偏好说明”，比如“用户对 XX 方向的内容关注度较高，请优先呈现”。这个说明可以手动维护，也可以从你的阅读行为里自动提取。我目前是手动维护，每两周更新一次，效果已经很明显了。

5.2 从日报到周报：时间维度的扩展

日报跑顺了之后，自然会想能不能自动生成周报。逻辑是一样的，只是把时间窗口从一天拉长到一周，提示词里加上“请总结本周的趋势和变化”。周报的价值在于看趋势，日报看的是“今天发生了什么”，周报看的是“这一周整体在往哪个方向走”。

实现上周报可以复用日报的大部分节点，只需要改触发频率（每周一早上跑）和提示词（从“汇总”改成“总结趋势”）。我建议周报和日报用两个独立的工作流，不要混在一起，否则逻辑会变复杂，维护起来麻烦。

5.3 把待办清单接进来形成闭环

我现在的日报里有一个“今日待办”板块，数据来自我自己维护的一个清单。这个清单可以是简单的文本文件，也可以是 Notion、飞书表格之类的在线文档。WorkBuddy 采集节点把清单拉过来，模型整理成待办事项，推到微信里。

这个闭环的价值在于提醒。待办写在文档里容易忘，推到微信里每天十点半准时出现，想忘都难。更进一步，你可以在日报里加一个“昨日待办完成情况”的回顾，形成“计划-执行-回顾”的循环。我试过一段时间，对推进项目的效果很明显。

5.4 多端同步与备份策略

最后说个容易被忽视但很重要的事：备份。工作流配置、提示词模板、脚本代码，这些东西一旦丢了，重建很麻烦。我的做法是定期把工作流导出成 JSON 文件，存到本地和云盘各一份。提示词模板单独维护一个文档，每次修改都记一笔，方便回溯。

多端同步方面，WorkBuddy 的工作流是云端存储的，换设备登录就能用，这点很方便。但如果你在多个环境里跑（比如测试环境和生产环境），要注意配置的隔离，不要把测试的 Key 用到生产上。我给每个环境建了独立的工作流，命名上区分清楚，避免混淆。

这套东西从最初的想法到稳定运行，前后折腾了大概两周，其中大部分时间花在调提示词和排查采集问题上。现在它已经成了我每天工作流的一部分，十点半那条消息弹出来的时候，我基本能在一分钟内扫完，知道今天该关注什么、该推进什么。如果你也想搭一套，建议从最简单的版本开始——一个信息源、一个模型调用、一个推送，跑通了再逐步加东西。别一上来就追求大而全，那样很容易在调试阶段就放弃了。