企业官网建设流程全解析

1. 为什么我要折腾一个“AI 日报自动进微信”

每天早上到工位，第一件事不是泡茶，而是打开四五个网页、翻两三个群聊、扫一遍行业动态，等把信息捋顺了，半小时已经没了。这种重复劳动我忍了很久，直到某天突然想明白一件事：我需要的不是“更多信息”，而是一份已经筛过、排过序、能直接看的日报。于是就有了这个项目——给 WorkBuddy 设一个闹钟，每天上午十点半，让它把整理好的 AI 日报自动推送到微信。

先说清楚这个东西是什么。它本质上是一条自动化流水线：定时触发 → 抓取/汇总信息源 → 交给大模型做摘要和归类 → 格式化成日报 → 通过微信通道送达。整条链路里，WorkBuddy 扮演的是“调度中枢 + 执行器”的角色，DeepSeek 这类大模型负责“理解与生成”，微信则是最终的“投递终点”。你不需要盯着它，它自己会在十点半准时把东西送到你面前。

它能解决的问题很具体：信息过载下的定时汇总。适合谁参考？三类人最合适。第一类是每天需要跟踪特定领域动态的从业者，比如做 AI 产品、做投资、做技术选型的；第二类是想入门自动化但不知道从哪下手的新手，这个项目链路完整、门槛不高，是个很好的练手样本；第三类是靠信息差吃饭的人，比如做内容、做咨询的，日报本身就是生产资料。哪怕你完全不懂代码，只要跟着思路走，也能理解每一步在干什么，甚至用现成工具拼出来。

我踩过的坑先给你交个底：最容易翻车的不是抓取，也不是模型，而是微信这一端的送达稳定性和定时任务的时区/触发逻辑。后面会专门讲这两块。现在先进入整体设计。

2. 整体设计与思路拆解

2.1 为什么是“定时 + 推送”而不是“实时流”

很多人第一反应是做实时推送，一有新闻就发。我试过，结果是灾难。信息是碎的，一条一条弹出来，你根本来不及消化，最后要么屏蔽，要么焦虑。日报的价值恰恰在于批处理带来的节奏感——每天固定一个时间点，把过去 24 小时的东西压缩成一份可读的东西。

从工程角度看，定时任务比实时流简单太多。实时流要考虑去重、限流、消息顺序、断线重连，而定时任务每天只跑一次，失败了重试一次就行，状态管理几乎为零。上午十点半这个时间点也不是随便定的：太早，很多源还没更新；太晚，上午的工作节奏已经被打乱。十点半刚好是“晨会结束、进入正题”的窗口，拿到日报可以直接指导当天安排。

提示：定时任务的时间点要结合你的信息源更新规律来定。如果你的源大多是海外站点，注意时区换算，别设了个“上午十点半”结果抓到的全是昨天的旧闻。

2.2 技术选型的三个关键取舍

第一个取舍：用 WorkBuddy 还是自己写脚本。自己写当然自由，但要处理调度、日志、失败重试、通知通道，一套下来没两天搞不定。WorkBuddy 这类工具的价值在于把这些“脏活”封装好了，你只需要关注业务逻辑——抓什么、怎么总结、发给谁。对于日报这种“每天一次、逻辑固定”的场景，用现成调度器是性价比最高的选择。

第二个取舍：模型用哪个。热词里出现了 DeepSeek，我也确实用它做过对比。日报场景对模型的要求是：长文本摘要能力稳、中文表达自然、成本可控。DeepSeek 在这三点上表现均衡，尤其是中文语境下的归纳，比一些英文优先的模型更贴合。当然你也可以换，接口是标准化的，换模型基本只改一个配置项。

第三个取舍：微信通道怎么走。这是整个项目最需要谨慎的部分。微信生态对自动化推送有明确限制，个人号做自动发送存在账号风险，企业微信相对规范但也要遵守平台规则。我的建议是优先使用官方支持的通道，比如企业微信的机器人、微信小程序的订阅消息、或者服务号的模板消息。这些通道有明确的接口文档和使用边界，稳定性和合规性都有保障。不要为了图省事去碰那些灰色方案，账号被封得不偿失。

2.3 整条链路的模块划分

把项目拆开，其实是四个模块：

这四个模块之间是松耦合的，任何一层出问题都不会拖垮全局。比如采集层某个源挂了，生成层照样能用剩下的源出日报；投递层失败，日报内容还在日志里，手动补发即可。这种设计的好处是可维护——出问题时你能快速定位是哪一层，而不是面对一坨黑盒。

3. 核心细节解析与实操要点

3.1 信息源的选择与清洗

日报的质量，七分靠源，三分靠模型。源选得烂，模型再强也只能把垃圾总结得更通顺。我的经验是源要少而精，控制在 5 到 8 个，覆盖“官方公告 + 行业媒体 + 社区讨论”三个层次。官方公告保证权威性，行业媒体保证覆盖面，社区讨论保证时效性和“人味儿”。

采集时最容易忽略的是去重。同一个事件会被多个源报道，如果不去重，日报里会出现三条内容讲同一件事，读起来很烦。去重的思路有两种：一是基于 URL 或标题的精确去重，简单但漏网多；二是基于语义相似度的模糊去重，效果好但要多花点算力。我一般先用标题关键词做粗筛，再用模型做一次语义合并，成本可控。

注意：采集频率要克制。有些源对高频访问不友好，一天抓一次足够了。别把定时任务设成每小时跑一次，既没必要，也容易触发对方的限流。

3.2 提示词设计：让模型输出“能直接看”的日报

这是整个项目里最见功力的地方。很多人写提示词就是一句“帮我总结一下”，结果模型输出一堆废话。日报的提示词要解决三个问题：结构固定、长度可控、语气统一。

我的提示词骨架是这样的：先给角色设定（“你是一个 AI 行业日报编辑”），再给输出格式约束（“按‘今日要闻 / 技术动态 / 值得关注’三个板块组织，每个板块不超过 5 条，每条不超过 80 字”），最后给风格要求（“客观陈述，不加主观评价，不堆砌形容词”）。格式约束越具体，输出越稳定。

这里有个小技巧：在提示词里给一个示例输出。模型看到示例后，格式遵循度会明显提升。示例不用长，三五行的样子就够，但能省掉你大量后期调整的时间。

3.3 微信投递的合规通道选择

前面强调过，这一块必须走官方通道。具体来说，企业微信的群机器人是最省事的选择：创建一个群，添加机器人，拿到 Webhook 地址，往这个地址 POST 一条消息就完事了。它支持 Markdown 格式，日报的排版能保留得不错。

如果你用的是服务号，可以用模板消息，但模板消息有格式限制，适合短消息，长日报要拆成多条。小程序订阅消息则需要用户主动订阅，适合做“个性化日报”的场景。选哪个取决于你的使用场景：自己看，群机器人最方便；发给一批用户，服务号或小程序更合适。

3.4 定时触发的时区与幂等处理

定时任务有两个经典坑：时区和重复执行。时区问题在于，服务器可能跑在 UTC，而你设的“十点半”是本地时间，不换算就会差 8 小时。解决办法很简单，在配置里明确写清时区，别依赖默认值。

幂等处理是为了防止“同一天发了两次日报”。触发器和执行器之间如果网络抖动，可能触发重试，导致重复投递。我的做法是在投递前检查一个“今日已发送”的标记，发过了就跳过。这个标记可以存在本地文件，也可以存在数据库，看你的环境。

4. 实操过程与核心环节实现

4.1 环境准备与 WorkBuddy 配置

先把基础环境搭起来。WorkBuddy 的安装按官方文档走就行，装完后重点是配置任务。一个典型的任务配置包含四部分：触发时间、执行脚本、环境变量、失败策略。

触发时间用标准的 cron 表达式，比如30 10 * * *表示每天十点半。这里要特别注意，如果你的 WorkBuddy 跑在容器里，确认容器的时区设置，否则 cron 会按 UTC 执行。

环境变量里要放的是敏感信息，比如模型 API Key、微信 Webhook 地址。千万别把这些硬编码在脚本里，一旦脚本被分享出去，密钥就泄露了。用环境变量或者配置文件，配置文件记得加进.gitignore。

失败策略建议设成“重试 2 次，间隔 5 分钟”。日报这种任务，偶尔失败一次很正常，重试基本能解决。如果重试还失败，就发一条告警消息给你，别让它默默挂掉。

4.2 采集脚本的编写要点

采集脚本的核心逻辑是：遍历源列表 → 请求 → 解析 → 归一化成统一结构。用 Python 写的话，requests加BeautifulSoup基本够用。如果源提供 RSS，直接用feedparser更省事。

归一化的数据结构建议长这样：

{ "title": "标题", "url": "链接", "source": "来源名", "published": "发布时间", "summary": "原始摘要" }

统一结构的好处是，后面的去重和模型处理都不用关心源之间的差异。请求时记得加User-Agent，很多站点对没有 UA 的请求会直接拒绝。请求间隔加个time.sleep(1)，既是礼貌，也是避免被封。

4.3 模型调用与输出格式化

调用模型这一步，关键是把采集到的数据整理成模型能吃的格式。我一般把每条信息压成一行“标题 + 摘要”，拼成一个大字符串，前面加上提示词。注意控制输入长度，太长了模型会截断，反而丢信息。如果源很多，可以先做一轮规则筛选，把明显不相关的去掉，再喂给模型。

模型返回的是文本，需要做一次格式化才能投递。如果走企业微信机器人，把文本转成 Markdown 就行。转换时注意转义特殊字符，比如标题里的#要处理掉，否则会打乱排版。

def format_daily(text): header = "## AI 日报\n\n" return header + text

4.4 投递与送达确认

投递就是往 Webhook 地址发一个 POST 请求。企业微信机器人的接口很简单：

curl -X POST "你的Webhook地址" \ -H "Content-Type: application/json" \ -d '{"msgtype":"markdown","markdown":{"content":"日报内容"}}'

发完之后要检查返回码。企业微信返回errcode: 0才算成功，其他值都要记录到日志里。我见过有人发完就不管了，结果机器人被移出群聊都不知道，日报发了个寂寞。送达确认这一步不能省。

提示：日报内容如果超过机器人单条消息的长度限制，要自动拆分。拆的时候按板块拆，别把一条内容从中间截断，读起来很难受。

5. 常见问题与排查技巧实录

5.1 日报没收到，怎么一步步排查

这是最高频的问题。排查顺序应该是从后往前：先看投递层，再看生成层，最后看采集层。

第一步，查投递日志。有没有发出请求？返回码是多少？如果返回码非 0，看错误信息，常见的是 Webhook 失效或内容格式不对。第二步，如果投递成功但你没看到，检查是不是被群消息淹没了，或者机器人被限制了。第三步，如果投递层没问题，看生成层有没有产出内容，模型调用是否超时。第四步，如果生成层也没内容，那就是采集层没抓到东西，检查源是否改版、网络是否通。

5.2 模型输出格式跑偏怎么办

模型偶尔会不按格式来，比如该分三个板块结果只分了一个，或者字数超了一大截。解决办法有三层：提示词加约束、输出后校验、校验不过就重试。

提示词里把格式要求写得越死越好，最好给示例。输出后用正则或简单的规则校验一下，比如检查板块标题是否存在、每条长度是否超标。校验不过就带着“请严格按格式重新输出”再调一次，一般第二次就正常了。如果反复跑偏，说明提示词还是太模糊，回去改提示词。

5.3 采集源失效的应对

信息源改版是常态，今天能抓的页面明天可能就变了。应对策略是多源冗余 + 失效告警。同一个领域至少准备两个源，一个挂了另一个顶上。同时给采集脚本加个检查：如果某个源连续三天抓不到内容，就发告警提醒你去看看。

我自己的做法是维护一个源健康度表，记录每个源最近的成功率。成功率低于阈值的源，要么修，要么换。这个表不用很复杂，一个 JSON 文件就够。

5.4 几个我踩过的坑

第一个坑是时间点设得太早。一开始我设的早上七点，结果很多源还没更新，日报内容很干。改成十点半之后，信息量明显上来了。

第二个坑是没做去重。有段时间日报里同一件事出现三次，读起来像复读机。加了语义去重之后清爽多了。

第三个坑是密钥写死在脚本里。有次我把脚本发到群里求助，忘了删密钥，幸好发现得早。从那以后所有敏感信息一律走环境变量。

第四个坑是没设失败告警。有次机器人被移出群，日报连发三天没人收，我第四天才发现。现在只要投递失败就立刻告警，问题不过夜。

6. 这套东西还能怎么扩展

日报跑顺之后，你会发现这套链路的复用性很强。把“AI 日报”换成“竞品动态”“专利更新提醒”“行业价格监控”，逻辑几乎不用改，只换采集源和提示词就行。我自己就基于同一套框架做了三个不同主题的日报，维护成本很低。

再往深了做，可以加个性化。比如根据你前一天的阅读行为，调整日报的板块权重；或者做多端同步，微信收一份，邮件收一份，Notion 里存一份。这些扩展都不难，核心链路已经跑通了，剩下的都是锦上添花。

我个人在实际操作中的体会是：自动化工具的价值不在于省了多少时间，而在于把“需要记得做的事”变成“不需要记得也会发生的事”。日报这件事，以前是我追着信息跑，现在是信息按时来找我。这个转变带来的心理松弛感，比省下的那半小时值钱多了。