WorkBuddy＋CloudBase：我把 AI 情报站从本机搬到了云端

月鹿手记

网站上线复盘 · 2026年08月12日

之前写过两篇文章。

第一篇，我用 WorkBuddy 搭了一个创作者工作台。

第二篇，我把它砍成只剩产品雷达和赛事雷达，改名叫“月鹿造物·AI 创作情报站”。

这两篇结尾，我都说“产品才刚开始”。

真正上线以后我才理解这句话的意思——不是客气，是字面意思。

绑好域名、备案通过、页面能打开，只是证明你有了一个地址。后面碰到的每一个问题，都在提醒我：这离“能用的产品”还差很远。

月鹿造物·AI 创作情报站网站页面

网站上的三个板块——内容趋势、产品雷达、赛事雷达——每天都要自动更新。

内容趋势每天 09：00 搜集公众号、小红书和抖音的爆款，产品雷达 08：30 检查 AI 产品的版本和功能更新，赛事雷达 09：30 归档过期比赛、搜索新赛事。

WorkBuddy 里的三个自动化任务

这三个任务都跑在我电脑上的 WorkBuddy 里。电脑必须开机、网络必须稳定，任务才能按时触发。错过了也不会自动补，我得手动重跑。

睡过头、出门忘记开电脑、网络断了一会儿，当天的更新就没了。用户打开网站，看到的还是昨天的数据。

这一点也不“自动化”。

WorkBuddy 自动化任务运行记录，可以看到失败的任务

我自己不懂技术，每次碰到问题，都是把现象告诉 AI，让它自己去排查、修改、重新部署。

这篇写的就是从“首页能打开”到“电脑关机也能每天自动更新、用户可以搜索任意产品”之间，我和 AI 一起反复打磨产品的过程。

01

有了域名，数据却丢了

DOMAIN AND DATA

备案通过那天，我在浏览器里敲 moondeerai 点 com，看到自己的网站从这个域名打开，确实高兴了一下。

然后我点进产品雷达，白屏。

打开浏览器调试工具，发现两个数据文件返回了 404——服务器上找不到这些文件。

我把现象描述给 AI，它排查后发现：部署脚本默认把文件传到了一个子目录里，但域名指向的是网站根目录。首页的页面在根目录，数据文件在子目录，路径对不上，所以首页能打开，数据全是空的。

AI 把脚本改成直接传到根目录，重新跑一遍，数据恢复正常。

首页能打开，不代表网站真的完整上线。

域名入口已经打开，但数据被传到了错误的子目录

02

自动化在跑，网站还是旧的

AUTOMATION PATH

数据修好之后，我以为自动化会接管一切。WorkBuddy 每天按时触发，终端里也能看到“部署成功”。

两天后我打开网站，数据还停在 8 月 4 号。

我让 AI 排查，它发现：我之前改版时把网站源码移到了新目录，但 WorkBuddy 的任务还指向旧目录。任务每天勤勤恳恳跑着，只是在更新旧网站。新网站这边，纹丝不动。

两套目录，各自更新，互不干扰。后台很忙，线上没变。

AI 帮我把任务的工作目录、脚本和数据文件统一迁到新目录，重新跑一遍完整链路：采集→写文件→部署→线上展示。这次才真正通了。

自动化能跑，不等于在更新你以为的那个东西。路径一致性是最容易忽略的前提。

自动化任务沿着旧轨道更新旧网站，小月将轨道切换到新网站

03

电脑一关，自动化也跟着下班

CLOUD MIGRATION

三个板块都能自动更新了。但有一个前提条件：我的电脑必须开着。

拿赛事雷达来说。每天早上 9：30，WorkBuddy 会读取现有的赛事数据，检查哪些比赛已经截止、需要归档；然后调用 Kimi 联网搜索新的 AI 黑客松、AIGC 创作赛、应用创新赛，把值得关注的赛事补进数据库；最后把更新后的网站重新部署到线上。

整套流程大概需要 3—5 分钟。这期间，我的电脑必须开机、网络必须稳定、WorkBuddy 必须在运行。

WorkBuddy 赛事雷达任务配置为每天 09：30 执行，右侧显示运行记录

如果我睡过头了，或者出门忘记开电脑，9：30 到了任务也不会跑。错过了也不会自动补，我得手动重新触发一次。

产品雷达和内容趋势也是一样的情况。三个任务加起来，每天我都要盯着电脑在家，确保这几个时间点不出问题。

这对一个想持续运行的产品来说，是硬伤。

AI 建议我把任务搬到云端，但不一口气全搬，先拿一个验证。选了赛事雷达，因为它的逻辑最清楚：读赛事→联网搜新赛事→写数据→部署。成没成功，一眼看得出来。

WorkBuddy 分析让赛事雷达脱离本机运行的三种云端迁移方案

最初讨论的三种迁移方案。继续拆解任务后，赛事雷达最终改用 CloudBase 云函数。

AI 通过 CloudBase MCP 工具，直接帮我操作腾讯云——创建云函数、上传代码、配置定时器。这些原本需要在控制台点来点去、填各种配置的操作，我只要告诉 AI“把赛事雷达搬到云端，每天 9：30 自动跑”，它就能自己完成。

MCP（Model Context Protocol）是一个让 AI 能直接操作外部服务的协议。有了 CloudBase MCP，AI 不只是告诉我怎么做，而是直接帮我做完。这才是非技术人也能部署云函数的关键。

从本机 WorkBuddy 调度迁移到 CloudBase 云函数的架构对照图

讨论阶段的整体迁移蓝图。实际执行时仍按任务逐个迁移，并分别配置触发时间。

AI 帮我把赛事雷达的逻辑放到腾讯云 CloudBase 的云函数上，再配一个每天早上 9：30 自动触发的定时器。从此这个任务跟我的电脑彻底无关——关机、睡觉、出门，它照样跑。

CloudBase 云函数的定时触发器配置，每天 09：30 自动运行

后来内容趋势也用同样的方式搬到了云端。但产品雷达还跑在本机 WorkBuddy 上，因为它的搜索和更新逻辑还需要继续优化，等稳定了再迁移。

这套自动化机制不只能用来做网站。同样的逻辑，还可以：

每天早上把摘要推送到飞书或邮箱

比如我每天 9：00 自动搜集的爆款内容和灵感，可以直接发到飞书群或者邮箱，打开手机就能看，不用专门登录网站。

自动生成选题库

我现在搜集的产品动态和赛事信息，本来就是创作选题的来源。可以让 AI 每周把这些信息整理成一份选题清单，标注哪些适合做教程、哪些适合写测评，直接变成我的写作素材库。

触发后续创作流程

发现一个热门产品更新后，不只是记录下来，还可以自动触发下一步：让 AI 生成文章大纲、搜集竞品资料、准备演示脚本。整条创作流程串起来，从发现选题到准备素材，都不需要手动开始。

网站只是这套自动化机制的一个出口。真正有价值的是每天持续获取、整理、更新信息的能力。

本机自动化适合验证想法，但撑不起“产品级”的稳定性。对个人项目来说，云函数加定时器是成本最低的方案。

04

网站从“能看”变成“能用”

PRODUCT SEARCH

前面三个阶段解决的都是“数据能不能自动出现”。这一步，我想让网站能回答问题。

产品雷达原来只能浏览已经收录的 AI 产品。收录量有限，想了解一个没收录的产品，用户只能自己去搜。

我让 AI 加一个搜索功能：已收录的产品直接筛选；没收录的，调用 Kimi 联网研究，返回产品简介、开发公司、官网、核心能力、适合人群、价格、近期动态、竞品差异和选题角度。

第一次部署上去后，搜索框出来了。我输入“巨日禄”，等了十几秒，弹出一行红字：network request error。

我把错误截图发给 AI。它从终端直接调用搜索的后台逻辑，正常返回结果。说明搜索本身没坏，坏在浏览器怎么请求这段逻辑的路上。

AI 诊断后发现：网页请求走了一个单独的接口地址，这个地址在某些网络环境下会被拦截或超时。它把搜索改成了跟网站同一个域名下的接口，浏览器请求不再跨到另一个地方去，问题解决。

同时 AI 还加了请求频率限制、结果缓存、输入长度限制，还过滤掉了内网地址和搜索引擎中转链接，只保留真实来源。

改完之后再搜“巨日禄”，正常返回完整资料。

巨日禄搜索成功，显示产品简介、核心能力、适合谁用等完整信息

后台逻辑能跑通，不代表用户能用。从用户真正打开网页到看见结果，中间还隔着网络环境和请求路径的问题。

05

最后一公里，不是代码的问题

THE LAST MILE

整个过程中让我卡得最久的，是部署本身。

每次更新云函数的代码，都需要把代码包传到腾讯云的服务器上。但我电脑开了一个全局网络代理工具，它在网络底层拦截所有连接。结果就是：每次上传到 60 秒就超时，失败。

我把现象描述给 AI，它试过关闭代理的环境变量、关闭系统设置里的代理——都没用。因为这个工具是在更底层拦截的，应用层的开关管不着它。

一开始 AI 判断问题出在代码包太大（装了依赖文件有 41MB），只能走大文件上传通道。后来它换了思路：不打包依赖文件，改为上传后在云端重新安装。代码包一下从 41MB 缩到几百 KB，可以直接传上去。

最后：我关掉那个代理工具，AI 重新执行直传，部署成功，网站重新发布。

反复卡在同一个环节的时候，问题可能不在代码。网络环境、代理配置、打包策略，都是“最后一公里”里藏着的变量。

41MB 代码包堵住网络隧道，压缩成几百 KB 后顺利送达云服务器

∞

写在最后

FINAL THOUGHTS

回头看这几个阶段：

01域名解决了“能找到”

02路径修正解决了“能看到完整内容”

03目录迁移解决了“自动化真的在更新线上”

04云函数解决了“我不在也能工作”

05同域接口解决了“用户能主动获得答案”

每一步都不复杂，但没有一步是“部署上去就自动对了”。

之前做工作台的时候，我以为最难的部分是把功能做出来。做完这一轮才发现，做出来只是开头，让它稳定地、不依赖我本人地跑下去，才是真正难的地方。

我自己不懂技术，每次碰到问题，就把现象告诉 AI——页面白屏、数据没更新、搜索报错。AI 会自己去看日志、查报错信息、排查路径，然后告诉我哪里出了问题，帮我改好代码、重新部署。反复几轮之后，网站才真正能用。

如果你也想做类似的网站，这几件事最值得注意：

先在本地把功能和数据流跑通

不要一上来就想着云端部署。我就是先用 WorkBuddy 在本地验证了几天，确认三个任务都能正常采集、写入、展示，才开始考虑上线。本地能跑通，迁移到云端只是换个地方执行；本地都没跑通，上云只会把问题藏得更深。

确认所有路径都指向同一个地方

域名指向网站根目录，部署脚本也要传到根目录；自动化任务的工作目录，要跟你实际改代码的目录一致。我就是因为改版后忘记迁移任务路径，白白浪费了两天时间，后台说成功，线上却是旧数据。

单个任务验证通过再迁移下一个

不要一口气把三个任务全搬到云端。我先选了逻辑最清楚的赛事雷达做云函数 PoC，跑了几天确认没问题，才开始迁移内容趋势。产品雷达现在还在本地，因为它的逻辑还需要优化。一个一个来，出了问题也好定位。

如果你也想让 AI 帮你部署云函数，需要先安装 CloudBase MCP 工具。在终端里运行：

...bash

npx @cloudbase/cli mcp install

装好之后，AI 就能直接操作你的腾讯云 CloudBase 环境，创建云函数、配置定时器，不用你自己去控制台点。

从用户入口测试，不只看后台日志。终端显示“部署成功”，不代表用户真能用。我的产品搜索功能，后台调用正常，但用户从浏览器访问就报错。最后是从浏览器打开、输入真实查询、看到完整结果，才算验收通过。

个人产品的门槛不在于能不能做，在于能不能持续运行。而 AI 的意义，不只是帮会写代码的人提效，更是让不会写代码的人也能把想法变成真正运行的产品。

CLOSING NOTE

做出来只是开头， 让它稳定地、不依赖自己地运行，才是产品真正的开始。

如果你觉得今天这篇有收获，欢迎点赞、在看、收藏，我们下篇见。

点赞在看收藏