腾讯版「龙虾」Workbuddy上线当天，我用它搭了一套行业情报日报系统

2026-05-05阅读 0热度 0

dreamweaver

写在前面

最近AI圈最火的词大概是「龙虾」。

OpenClaw掀起了一波桌面AI Agent的热潮——不再是聊天窗口里你一句我一句的问答，而是让AI直接在你的电脑上干活：操作文件、执行脚本、联网搜索、交付结果。

3月9日，腾讯发布了WorkBuddy，被称为「腾讯版龙虾」。完全兼容OpenClaw的Skills技能体系，但有一个关键差异：不需要自己买服务器部署，不需要自己购买API token，安装即用。如果你用企微，1分钟就能连上，手机发条消息就能远程让它在办公电脑上干活。

当晚就下载试了。

不是因为想写评测，而是手上正好有一个真实需求：需要一套系统，每天自动搜集全球数据平台行业的最新动态，整理成一份结构化的情报简报，推送到企微群。

这个需求已经用手动方式做了很久——每天花30-40分钟刷Twitter、LinkedIn、各厂商博客和分析师报告，再整理成笔记分享。

WorkBuddy上线当天，决定试试看：用桌面AI Agent能不能把这件事自动化。

结果是：1小时跑通了第一个可用版本，1天反复优化，3天后稳定运行。

这篇文章完整记录整个搭建过程——怎么设计、怎么实现、踩了哪些坑、怎么解的。如果你也想用AI Agent搭一套自己行业的信息自动化系统，这篇可以当一个实操参考。

一、先看效果：这份日报长什么样

在讲怎么做之前，先看产出物。

每天早上8点，一份《Data+AI全球日报》准时出现在企微群里，覆盖全球10+大数据平台厂商、5个板块、8-12条高质量情报。

推送方式

推送分两步：

先发一条精简摘要（Markdown格式，控制在4096字节内），在企微内直接可读

再发一份HTML完整版，打开后是一份带精美排版、可点击来源链接的完整报告

???? 为什么分两步？企微Webhook单条消息限制4096字节（注意是字节，一个中文3字节），但完整日报通常8000+字符。这个限制在Day 1就把人教做人了，后面会讲。

内容结构

每份日报严格按5个板块组织：

板块

内容

示例

A. Top Signals

当天最重大的3条行业动态 + 影响分析

Gartner峰会定调AI FinOps

B. Product & Tech

4-6条产品/技术更新，只取一手信源

Databricks Asset Bundles GA

C. People & Views

关键人物的原始发言

Snowflake CEO谈AI Agent战略

D. Analyst Insights

Gartner/Forrester/IDC研报核心数据

44%组织缺乏AI FinOps

E. Watchlist

值得持续跟踪但尚未定论的信号

GTC 2026推理加速

每条信息都标注了一手信源链接。

公开版

除了企微群，每期日报同时部署到GitHub Pages：

???? https://haiyangchenbj.github.io/data-ai-daily/

HTML版本有蓝色渐变头部、卡片式板块布局和可点击的来源超链接，阅读体验比企微内的Markdown好得多。

二、为什么选WorkBuddy

搭这套系统，需要AI工具同时具备三个能力。拆解一下选型逻辑，顺便说说WorkBuddy作为「腾讯版龙虾」和OpenClaw的异同。

能力1：联网搜索 + 结构化输出

日报的本质是信息搜集和整理。AI必须能实时联网搜索，而不是只靠训练数据回答问题。每次生成日报，WorkBuddy会执行10+次搜索——中英文双语，覆盖厂商官方博客、GitHub仓库、分析师报告等信源——然后按定义的模板结构化输出。

能力2：本地文件操作

整个系统涉及大量文件操作：读取JSON配置文件、生成MD和HTML两种格式的日报、调用Python脚本推送。这要求AI能直接操作本地文件系统。WorkBuddy作为桌面智能体，可以读取授权文件夹、生成文件、执行脚本。

能力3：多步骤任务链

"生成今日日报"是一句话，但实际包含5个步骤：读取配置 → 联网搜索 → 生成内容 → 推送企微 → 部署GitHub Pages。WorkBuddy可以自主拆解和执行这个任务链。

和OpenClaw的关系

WorkBuddy完全兼容OpenClaw的Skills技能体系。如果之前给OpenClaw写过Skill，可以直接导入使用。不同的是：

部署门槛：OpenClaw需要自建服务器或购买API token；WorkBuddy安装即用，免费额度覆盖日常使用

企业连接：WorkBuddy原生支持企微、飞书、钉钉，1分钟连上

模型切换：国内版支持混元、DeepSeek、Kimi等模型无缝切换, 国外版基本上主流模型都在。

对于这个场景来说，"安装即用 + 企微原生连接"是决定性的。不想为一个每天跑一次的日报系统维护一台服务器。

三、核心设计：一份3000字的「情报宪法」

这套系统最核心的部分，不是代码，是一份Prompt配置文件。

把它叫做「情报宪法」（daily-brief-config.json）——它定义了AI Agent的所有行为准则。

在做数据平台产品时，有一个强烈的认知：系统的产出质量不取决于引擎多强大，取决于规则定义得多清晰。同样的逻辑放到AI Agent上——模型是底座，但产出取决于给它的约束。

下面展开说这份配置的几个关键设计。

3.1 核心过滤原则

"core_filter": "每条信息必须能明确回答：这会影响企业数据平台的产品路线、架构设计、成本结构、治理方式、运维效率或Agent在数据场景的落地吗？如果不能明确回答'是'，一律不纳入。"

这是整份配置里最重要的一条。没有它，AI会把每天铺天盖地的AI新闻全塞进来——大模型刷新benchmark、创业公司融资——这些跟「数据平台」这个垂直领域无关。

AI不缺生成能力，缺的是判断力。判断力需要通过Prompt注入AI。

3.2 排除规则

光说"数据平台优先"不够，必须明确告诉AI什么不碰：

"exclusions": [
    "纯AI新闻：纯模型发布、纯benchmark、纯消费级AI产品",
    "财经媒体的二手报道（Bloomberg、36氪、虎嗅的转述和评论）",
    "搬运号、标题党、无来源转述、无法验证的爆料"
]

为什么排除财经媒体？因为只要一手信源。Databricks发了什么，去看Databricks官方博客原文，不看科技媒体的二手解读。

这和做数据产品的逻辑一样——宁可要一条干净的一手数据，也不要十条加工过的二手数据。

3.3 厂商优先级

"tier_1": ["AWS", "Google Cloud", "Azure", "Databricks", "Snowflake",
           "阿里云", "腾讯云", "华为云", "火山引擎"],
"tier_2": ["Confluent", "MongoDB", "ClickHouse", "dbt Labs", "Fivetran"],
"conditional": ["NVIDIA", "Intel", "AMD"]

每次生成日报约执行10+次联网搜索。不设优先级，搜索资源会被分散到太多方向。分层之后，确保头部厂商的重要动态不会被遗漏。

3.4 信源标准

"accepted_sources": [
    "官网、官方博客、Release Notes、GitHub仓库",
    "论文原文、官方Keynote",
    "创始人/CEO/CTO/核心开源Maintainer的原始发言",
    "Gartner、Forrester、IDC官方报告",
    "PR Newswire/Business Wire官方新闻稿"],
"rejected_sources": ["财经媒体、大众媒体的二手分析和转述"]

这套信源标准让同事说"比付费信息服务都好用"——因为很多付费服务也在搬运二手信息。

3.5 时间窗口

"time_window": "严格只覆盖过去24小时内首次公开的信息。原始发布日期早于窗口的，即使刚被搜索引擎收录，也不纳入。"

这条是踩坑后加的——Day 1的日报混入了一周前的旧闻，因为搜索引擎刚重新收录。加了这条规则后，「新鲜度」大幅提升。

四、技术实现：完整搭建教程

这一节是实操教程，可以直接照着做。整个系统只需要2个Python脚本 + 0个第三方依赖。

4.1 系统架构

WorkBuddy
    │
    ├── 读取 daily-brief-config.json（情报宪法）
    │
    ├── 执行10+次联网搜索
    │   ├── 厂商官方博客（中英文双语）
    │   ├── GitHub仓库
    │   └── 分析师报告
    │
    ├── 生成文件
    │   ├── Data+AI全球日报_YYYY-MM-DD.md
    │   └── Data+AI全球日报_YYYY-MM-DD.html
    │
    └── 分发
        ├── send_daily_v3.py  → 企微群
        └── deploy_to_github.py → GitHub Pages

4.2 Step 1：编写情报宪法

创建daily-brief-config.json，内容就是上一节讲的过滤规则、厂商分层、信源标准、输出模板。这是整个系统的灵魂，花多少时间打磨都不过分。

4.3 Step 2：企微推送脚本

send_daily_v3.py，222行，全部用Python标准库（urllib、json、re），不需要pip install任何东西。

核心逻辑1——智能摘要提取：

def extract_summary_from_md(md_path):
    """保留日报骨架，去掉详细内容，控制在4096字节内"""
    lines = content.split("\n")
    summary_lines = []
    for line in lines:
        stripped = line.strip()
        # 保留标题行
        if stripped.startswith("# "):
            summary_lines.append(stripped)
        # 保留今日变化和总判断
        if stripped.startswith("## 今日") or stripped.startswith("> 总判断"):
            summary_lines.append(stripped)
        # 保留板块标题 ## A. ~ ## E.
        if re.match(r"^## [A-E]\.", stripped):
            summary_lines.append(stripped)
        # 保留事件标题（### 1. xxx）
        if re.match(r"^###\s+\d+\.", stripped):
            summary_lines.append(stripped)
    # 硬性限制
    summary = "\n".join(summary_lines)
    if len(summary.encode("utf-8")) > 3900:
        summary = summary[:3850] + "\n... (完整版见HTML文档)"
    return summary

这段代码的设计思路：保留日报的「骨架」（标题、板块名、事件标题），去掉「肉」（来源链接、详细分析），确保精简版在企微字节限制内。

核心逻辑2——文件上传（纯标准库实现）：

def upload_file_to_wecom(filepath):
    """不用requests，用urllib手工构建multipart/form-data"""
    boundary = "----PythonBoundary7MA4YWxk"
    filename = os.path.basename(filepath)
    with open(filepath, "rb") as f:
        file_data = f.read()
    
    body = (
        f"--{boundary}\r\n"
        f'Content-Disposition: form-data; name="media"; '
        f'filename="{filename}"\r\n'
        f"Content-Type: application/octet-stream\r\n\r\n"
    ).encode("utf-8") + file_data + f"\r\n--{boundary}--\r\n".encode("utf-8")
    
    req = urllib.request.Request(upload_url, data=body)
    req.add_header("Content-Type", f"multipart/form-data; boundary={boundary}")
    resp = urllib.request.urlopen(req)
    return json.loads(resp.read())["media_id"]

为什么不用requests？因为这个脚本每天只跑一次，生命周期可能很长。零依赖意味着在任何有Python的环境里都能直接跑——不用装包，不用配环境，不用担心版本冲突。对于「每天跑一次 + 长期运行」的脚本，零依赖就是零维护。

核心逻辑3——两步推送：

# Step 1: 推送精简摘要
summary = extract_summary_from_md(md_path)
send_markdown_to_wecom(summary)

# Step 2: 推送完整版HTML文件
media_id = upload_file_to_wecom(html_path)
send_file_to_wecom(media_id)

4.4 Step 3：GitHub Pages部署脚本

deploy_to_github.py，198行，通过GitHub API将HTML日报部署到GitHub Pages：

# 1. 读取HTML并Base64编码
encoded = base64.b64encode(html_content.encode("utf-8")).decode("ascii")

# 2. 上传到index.html（最新版，覆盖写入）
api_request("PUT", file_url, {
    "message": f"Deploy: Data+AI daily {date_str}",
    "content": encoded,
    "sha": existing_sha,  # 幂等更新：先获取旧文件SHA
})

# 3. 同时归档到archive/{date}.html（历史版本）
api_request("PUT", archive_url, {
    "message": f"Archive: {date_str}",
    "content": encoded,
})

# 4. 启用GitHub Pages
api_request("POST", pages_url, {
    "source": {"branch": "main", "path": "/"}
})

几个工程细节：

安全：GitHub Token从环境变量GITHUB_TOKEN读取，不硬编码在脚本里

幂等：上传前先GET获取文件SHA，有则更新、无则创建，重复执行不报错

双重存储：index.html始终是最新版，archive/目录保留全部历史

4.5 Step 4：写一条SOP规则

最后一步，把完整流程写成一条WorkBuddy的SOP规则文件。以后只需要说一句"生成今日报告"，AI就会按标准流程执行全部5步。

五、迭代实录：1小时 → 1天 → 3天

这套系统不是规划出来的，是跑出来的。

第1小时：跑通最小可用版

WorkBuddy上线当晚，把之前手动整理日报时积累的过滤规则写成了一份JSON配置文件（也就是「情报宪法」的初版），然后让WorkBuddy联网搜索并生成了第一份日报。

Markdown格式的日报生成出来后，直接扔到企微——报错了。超过4096字节限制。

临时方案：手动截取前3000字符发送。虽然粗暴，但至少跑通了「配置 → 搜索 → 生成 → 推送」的完整链路。

这一步的意义不是产出有多好，而是验证了「用桌面AI Agent搭日报系统」这条路走得通。

Day 1：解决三个阻塞性问题

问题1：PowerShell中文乱码

最开始用PowerShell调企微Webhook，群里收到的全是乱码。原因：PowerShell默认编码不是UTF-8。折腾半小时后切换Python，一行# -*- coding: utf-8 -*-解决。

问题2：消息长度限制

这个问题倒逼出了后来被证明体验更好的方案——「摘要 + 完整版」双推策略。先发精简摘要（企微内直接可读），再传HTML完整版（精美排版 + 超链接）。实际使用中发现，大多数人只看摘要就够了，想深入了解的再打开HTML。

问题3：过旧信息混入

第一版日报混进了一周前的Databricks旧闻——搜索引擎会重新收录旧页面。在Prompt里加了严格的24小时时间窗口后解决。

Day 2：从「能用」到「有用」

新增D板块（分析师洞察）：把Gartner、Forrester的数据单独成板块，日报从"搬运新闻"升级成"情报分析"

写了自动摘要提取函数：替代Day 1的手动截取，保证摘要保留所有事件标题

GitHub Pages上线：写了deploy_to_github.py，一行命令部署到公开网站，方便分享给外部同行

Day 3：从「有用」到「稳定可复用」

修复摘要提取Bug：函数不识别### 数字.格式的三级标题，导致摘要丢失事件标题。排查后补了一条正则

流程标准化：把五步操作写成SOP规则文件，以后一句"生成今日报告"触发全流程

质量稳定：连续推送3天，同事反馈信息覆盖度和信源质量稳定，没有再出现过旧信息混入的问题

六、几点设计思考

做完这套系统，技术层面其实没什么难的——代码总共不到600行。但过程中有几个认知层面的收获，觉得值得分享。

1. 定义问题 > 解决问题

整个系统里，花最多时间的不是写代码，是打磨那份3000字的Prompt配置。什么值得关注？什么要排除？信源标准怎么定？时间窗口怎么设？

这些「定义问题」的工作才是核心。如果做过数据产品，对这一点会有共鸣：平台的价值不在引擎多快，在规则定义得多好。

2. AI擅长执行，判断力需要你来注入

AI可以在3分钟内搜索10+个信源、生成8000字结构化报告。但如果不设过滤规则，它会把搜到的东西全塞进来。排除规则写得越细，产出质量越高。

这不是AI的缺陷，这是协作方式。提供判断力，AI提供执行力。

3. 桌面Agent的真正价值：缩短从「想法」到「跑通」的路径

过去做类似的自动化项目，光是搭建环境、调试API、处理依赖就要花半天。WorkBuddy这类桌面Agent工具把这个过程压缩到了小时级——从动手到跑通第一个版本只花了1小时。

不是因为技术变简单了，而是因为大量中间步骤被Agent代劳了。只需要描述意图、定义规则、审核产出。

在之前的文章里讨论过AI Agent如何重塑企业数据平台。那篇是从行业视角看趋势。这次是亲自下场，用一个具体项目验证了一个判断：Agent改变的不是能力边界，而是人与系统的协作方式。

七、复用指南：搭你自己行业的日报

这套方案的技术门槛不高，核心逻辑可以迁移到任何垂直领域。你需要：

一个支持联网搜索 + 本地文件操作的AI Agent（用的WorkBuddy，OpenClaw或其他类似工具也行）

一份Prompt配置文件（你的行业版「情报宪法」）

两个Python脚本（推送 + 部署，总共不到400行，全部在本文中给出了核心代码）

把"数据平台"替换成你关心的领域——AI基础设施、半导体、新能源、生物医药——方法论是一样的：

明确覆盖范围（你关心哪些厂商/信源）
    ↓
定义排除规则（什么不要）
    ↓
规定信源标准（只要一手）
    ↓
设定输出模板（结构化、可行动）
    ↓
自动化分发（推送到你的消费场景）

可以先从最简单的开始——写一份你所在行业的「情报宪法」，让AI每天帮你搜索和整理，发到你的群里或笔记里。有了初版再迭代，比从零规划要快得多。

八、下一步

目前系统还是半自动——每天需要手动说一句"生成今日报告"来触发。接下来计划：

接入Windows任务计划程序，实现全自动定时触发（3月12日更新后在Automation已实现）

增加日报质量评分（信息覆盖率、信源多样性、时效性）

开发周报自动汇总——把5天日报聚合成一份周度趋势分析

探索语音版日报（通勤路上听）

如果有类似的想法或已经在做了，欢迎交流。

写在最后

回看整个过程，真正花时间的不是写代码——代码不到600行。而是想清楚「什么值得关注、什么不值得关注」——这个判断力是AI替代不了的，也是行业认知的一部分。

桌面AI Agent正在成为一种新的生产力工具。OpenClaw开了头，WorkBuddy降低了门槛。但工具本身不是壁垒，你对自己所在领域的理解才是。

???? 日报公开地址：https://haiyangchenbj.github.io/data-ai-daily/

欢迎围观，也欢迎提建议。

WorkBuddy由腾讯于2026年3月9日正式发布，目前可在官网免费下载使用。新用户注册送5000 Credits，无门槛

也可直接到GitHub下载使用：https://github.com/haiyangchenbj/data-ai-daily-brief-skill本文仅为基于个人使用经验的记录分享。

✍️ 科里笔记 Coralyx Notes，

Written by 科里（Coralyx），发表于「边界层」