企业官网建设流程全解析

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

每天早上到工位，第一件事不是打开编辑器，而是先刷一遍昨天夜里堆积的消息、群聊、邮件和几个内容平台的热榜。这个动作看起来只花十几分钟，但真正消耗的是注意力切换成本——你刚进入状态，又被一条新消息拽走，等回过神来半小时没了。我试过用各种待办工具、RSS 阅读器、聚合面板，最后发现真正能解决问题的不是“再多一个看板”，而是让信息主动来找我，而且只来一次、来在固定时间。

这就是我给 WorkBuddy 设“十点半闹钟”的出发点：每天上午 10:30，让一个 AI 代理自动把过去 24 小时里我关心的内容整理成一份日报，直接推送到微信。我不需要打开任何新 App，不需要记任何网址，微信里那条消息就是我的“信息早餐”。关键词里的WorkBuddy、AI、微信、自动化、deepseek基本就是这套方案的五个支柱：WorkBuddy 负责调度和技能编排，AI 负责摘要与筛选，微信负责触达，自动化负责定时，deepseek 这类模型负责把原始内容压成可读的短句。

这套东西适合谁？如果你每天需要跟踪固定几个信息源、又不想被信息流牵着走，或者你已经在用 WorkBuddy 做零散任务、想把它升级成“有节奏的助手”，那这篇内容可以直接抄作业。它不要求你会写复杂后端，也不要求你懂微信底层协议，核心就是定时触发 + 数据抓取 + 模型摘要 + 微信推送这四步。下面我会把每一步拆开讲，包括我踩过的坑和最后稳定下来的配置思路。

提示：整条链路里最容易被低估的是“推送触达”这一步。很多人把摘要做得很漂亮，结果卡在微信侧发不出去，或者发出去格式全乱。所以我会把微信推送单独拎出来讲透。

2. WorkBuddy 的定时机制：闹钟到底挂在哪里

2.1 为什么不用系统 cron 而用 WorkBuddy 自带调度

一开始我图省事，直接在服务器上写了个 crontab，每天 10:30 跑一个 Python 脚本。跑了两天就发现问题：脚本本身能跑，但 WorkBuddy 里的技能状态、上下文、模型调用配额是分散的，cron 触发的脚本和 WorkBuddy 里的会话完全是两套东西。结果就是日报内容和我平时在 WorkBuddy 里积累的偏好对不上，模型每次都要重新“认识”我。

后来我把触发点挪回 WorkBuddy 内部，用它的定时任务/计划任务能力来挂这个闹钟。这样做的好处很直接：任务运行时天然带着我的技能配置、自定义指令和历史上下文，模型不需要从零开始。WorkBuddy 的调度粒度通常支持到分钟级，设10:30完全没问题。如果你用的是国际版或者 Linux 环境，调度入口位置可能略有差异，但逻辑一致——找到“计划任务”或“定时触发”这一类入口，新建一个每天固定时间执行的任务。

这里有个细节：时区。我有一次把任务设成 10:30，结果实际推送是 18:30，排查半天发现是容器时区默认 UTC。所以设完闹钟第一件事，就是确认运行环境的时区和你所在时区一致。可以在任务里先跑一条打印当前时间的指令验证。

2.2 任务里到底放什么：技能编排的基本结构

WorkBuddy 的定时任务不是一个空壳，它里面要挂具体的执行逻辑。我的做法是把整个日报拆成三个可复用的技能/步骤：

1. 采集技能：负责从固定信息源拉取过去 24 小时的内容。信息源可以是 RSS、公开 API、你关注的几个页面，甚至是你自己维护的一份链接清单。
2. 摘要技能：把采集到的原始文本交给模型，按我给定的模板压缩成日报格式。
3. 推送技能：把最终文本通过微信通道发给我。

这三个技能在 WorkBuddy 里可以串成一条流水线。关键点是每一步的输出格式要约定好，否则第二步拿到的是一坨乱文本，模型摘要质量会断崖式下跌。我一般让采集技能输出 JSON，字段固定为title、source、time、raw_text，摘要技能只读这几个字段，推送技能只认摘要技能输出的digest字段。这样任何一步出问题，都能快速定位是哪一环。

注意：如果你的 WorkBuddy 版本支持“自定义指令”，强烈建议把日报的格式要求写进指令里，而不是每次在提示词里重复。比如“输出必须包含：今日要闻三条、值得关注的一条、一句话总结”，这样模型每次输出结构都稳定。

2.3 十点半这个时间点是怎么选出来的

很多人会问为什么是 10:30 而不是早上 8:00。我实测下来的原因是：8 点推送的信息，很多是凌晨产生的，质量参差；10:30 刚好是上午工作节奏稳定下来、昨夜到今晨的信息也基本沉淀完毕的时间点。而且 10:30 推送不会和早会冲突，你开完会回来正好看到一份已经整理好的日报，直接进入深度工作。

如果你所在团队有固定的站会时间，可以把闹钟往后挪到站会结束后 15 分钟。核心原则是：推送时间要落在你“愿意停下来读两分钟”的窗口里，而不是你最忙的时候。我试过 9:00 推送，结果连续一周都是已读不回，后来改到 10:30 才真正用起来。

3. 日报内容从哪来：采集环节的取舍与清洗

3.1 信息源不是越多越好，而是要“可摘要”

我最初贪心，一口气接了十几个源，结果日报变成了一篇三千字的流水账，模型摘要完还是很长，读起来比我自己刷还累。后来砍到5 个以内，并且每个源都问自己一句：这个源的内容，模型能不能在 200 字内说清楚？如果不能，要么换源，要么只取标题。

比较稳的源类型包括：结构化的 RSS、有稳定字段的公开接口、你自己整理的链接列表。不太适合直接丢给模型的是：纯图片流、需要登录才能看全文的页面、以及评论区比正文还长的社区帖。后者不是不能做，而是清洗成本高，容易把噪声带进日报。

采集时我会做一层轻量清洗：去掉 HTML 标签、去掉重复的空行、把超长正文截断到 2000 字以内。截断这一步很关键，因为模型上下文有限，你把一篇一万字的文章塞进去，摘要质量反而下降。截断策略我一般用“前 1500 字 + 后 500 字”，保证开头和结论都在。

3.2 去重和时间窗口：过去 24 小时怎么算

“过去 24 小时”听起来简单，实际做起来有两个坑。第一个坑是时间字段格式不统一，有的源给的是时间戳，有的是 ISO 字符串，有的是“3 小时前”这种相对时间。我的处理方式是统一转成时间戳再比较，相对时间就按当前时间倒推。第二个坑是重复内容，同一个事件被多个源报道，如果不去重，日报里会出现三条几乎一样的要闻。

去重我用的方法比较土但有效：对标题做归一化（去标点、转小写），然后算相似度，超过阈值就只保留最早的那一条。阈值我设在 0.8 左右，实测能干掉大部分重复，又不会误杀真正不同的内容。如果你不想写相似度计算，也可以简单按“标题前 10 个字符”做粗去重，效果差一点但够用。

3.3 采集失败的兜底：不要让一条源拖垮整份日报

任何自动化链路都会遇到某个源挂掉的情况。我的原则是单源失败不影响整体：每个源单独 try-catch，失败就记录一条“该源今日不可用”，继续跑下一个。这样即使某个源临时抽风，你收到的日报里只是少了一块，而不是整份消失。

另外我会在日报末尾附一行“数据源状态”，比如“5 个源中 4 个正常”。这行信息看起来不起眼，但能让你快速判断今天这份日报的可信度。如果连续几天某个源都失败，你就知道该去修它了，而不是等到某天发现漏了重要信息才回头查。

4. 让 deepseek 把原始内容压成“人话日报”

4.1 提示词结构：角色、任务、格式、约束

摘要环节是整个链路里最影响体验的一步。我试过直接丢一句“帮我总结一下”，结果模型输出要么太啰嗦，要么抓不住重点。后来固定成四段式提示词结构：

• 角色：你是一名信息筛选助手，服务对象是每天只有两分钟阅读时间的从业者。
• 任务：从以下内容中选出最重要的三条，每条用一句话说明“发生了什么”和“为什么值得关注”。
• 格式：严格按“今日要闻 / 值得关注 / 一句话总结”三段输出，不要额外解释。
• 约束：总字数不超过 300 字，不要编造原文没有的信息，不确定的内容标注“待确认”。

这个结构的好处是可复现。你不需要每次调提示词，只要把原始内容塞进“以下内容”部分就行。deepseek 这类模型对结构化提示词的遵循度比较高，输出格式基本稳定。

4.2 为什么我坚持让模型“标注不确定”

这是我从一次翻车里学到的。有次日报里出现了一条“某项目已上线”的消息，我转发给同事后才发现是模型把“计划上线”理解成了“已上线”。从那以后我在提示词里强制要求：凡是原文没有明确说“已完成/已发布”的，一律保留原文的时态，不确定就写“待确认”。

这个约束看起来降低了日报的“干脆感”，但它极大提升了可信度。你读日报是为了快速判断，不是为了被误导。宁可看到“某项目计划本周上线（待确认）”，也不要看到一句斩钉截铁的错话。

4.3 摘要长度和条数的实测调参

我试过几种组合：5 条 × 60 字、3 条 × 100 字、3 条 × 80 字。最后稳定在3 条要闻 + 1 条关注 + 1 句总结，总字数 250 到 300 字。原因是微信消息在手机上阅读，超过 300 字就需要滑动，滑动就会打断阅读节奏。3 条要闻刚好覆盖“必须知道”的信息量，再多就开始稀释重点。

如果你跟踪的领域信息量特别大，可以做成“要闻 3 条 + 简讯 5 条（每条 20 字）”的两级结构。简讯只给标题和来源，不展开，需要细节再点链接。这样既保证覆盖面，又不牺牲可读性。

5. 把日报送进微信：推送通道的选择与格式处理

5.1 为什么微信推送比邮件和 App 通知更有效

我对比过邮件、系统通知、微信三种触达方式。邮件的打开率最低，因为邮箱里全是别的东西；系统通知容易被忽略，而且换设备就没了；微信的优势是它本来就是你每天高频打开的应用，消息到达即被看到。而且微信消息可以转发、可以收藏、可以稍后读，天然适合“日报”这种需要二次处理的内容。

需要说明的是，这里说的微信推送指的是合规的消息触达方式，比如通过企业微信应用消息、微信服务号模板消息、或者你自己搭建的合规通知通道。具体用哪种取决于你的账号类型和开发权限。我个人的选择是走企业微信应用消息，因为配置相对直接，消息格式支持 Markdown 子集，适合日报排版。

5.2 消息格式：Markdown 在微信里的实际表现

微信消息对 Markdown 的支持是有限的。我实测下来，加粗、换行、有序列表基本可用，但表格、代码块、复杂嵌套列表经常渲染异常。所以日报的格式我做了简化：

• 用**今日要闻**做小标题，不用多级标题。
• 每条要闻用1. 2. 3.有序列表，不用嵌套。
• 来源和链接放在每条末尾，用短横线分隔。
• 不用表格，需要对比的信息改成“A：xxx；B：xxx”这种一行式表达。

这样处理之后，消息在 iOS 和 Android 微信里显示基本一致，不会出现“我这边好看、你那边乱码”的情况。

5.3 推送失败的常见原因和排查顺序

推送环节出问题，我一般按这个顺序查：

我遇到最多的是消息体超长和格式不合法。前者靠控制字数解决，后者靠简化格式解决。这两个问题解决后，推送稳定性基本在 99% 以上。

提示：推送成功后建议在日志里记一条“已送达 + 时间戳”。这样当你某天没收到日报时，能快速判断是“没发出去”还是“发出去了但你没看到”。

6. 跑通之后我才发现的几个坑

6.1 模型调用超时导致整条链路卡死

定时任务最怕的不是报错，而是卡住不动。我有一次任务跑了 40 分钟还没结束，最后发现是模型调用没有设超时，网络抖动时一直挂着。后来我给每个步骤都加了超时：采集 60 秒、摘要 120 秒、推送 30 秒。任何一步超时就跳过并记录，保证整条链路在 5 分钟内一定结束。

这个改动看起来简单，但它把“偶发卡死”变成了“可控降级”。即使模型服务临时不稳定，你最多收到一份不完整的日报，而不是什么都收不到。

6.2 日报内容“太像 AI 写的”怎么破

早期日报读起来有一股明显的机器味，比如“综上所述”“值得注意的是”这种词反复出现。我的解决办法是在提示词里加一条禁用词列表，明确要求不要使用“综上所述、值得注意的是、随着……的发展、在……背景下”这类表达。同时要求每条要闻以具体主语开头，比如“某团队发布了……”“某平台调整了……”，而不是“有消息称……”。

另外一个技巧是给模型一个示例。我在提示词里放了一条我手写的要闻作为范例，模型会模仿这个语气。实测下来，加了示例之后，日报的可读性提升非常明显。

6.3 周末和节假日的“空日报”问题

工作日信息量大，日报很充实。但周末信息源更新少，模型经常输出“今日无重要更新”。这种日报推过来反而让人烦躁。我的处理方式是加一个最小条数判断：如果采集到的有效内容少于 3 条，就跳过推送，或者只推一句“今日信息较少，已跳过”。这样既避免打扰，又不会让你怀疑系统是不是挂了。

如果你希望周末也收到，可以把周末的采集窗口拉长到 48 小时，或者把阈值降低到 1 条。这个完全看个人习惯，没有标准答案。

7. 我现在的日常使用方式和一点个人体会

这套东西跑稳之后，我的早晨节奏变成了这样：10:30 微信弹出一条日报，我花两分钟读完，把其中一条转发给相关同事，把另一条收藏进待办，然后继续手头的事。整个过程不需要打开任何新页面，也不需要做任何筛选决策——筛选已经在后台完成了。

我最大的体会是：自动化的价值不在于“省了多少时间”，而在于“减少了多少次注意力切换”。你省下的那十几分钟刷信息的时间，真正珍贵的是它让你保持在一个连续的思考状态里。WorkBuddy 在这里扮演的角色不是“更聪明的搜索”，而是“有节奏的过滤器”。

如果你准备动手，我的建议是先从一个信息源 + 一条推送跑通，确认微信能收到、格式能看，再逐步加源、加摘要逻辑。不要一上来就搭大而全的流水线，那样任何一环出问题你都会卡住。先跑通最小闭环，再迭代，这是我踩了多次坑之后最想分享的一条经验。