月鹿手记：从网站能打开到真正可用，一次 AI 创作情报站上线复盘

网站上线并不等于产品已经能用。对“月鹿造物·AI 创作情报站”来说，绑好域名、完成备案、首页能够打开，只是给产品找到了一个线上地址。真正的挑战，是让网站里的内容趋势、产品雷达、赛事雷达持续更新，并且不再依赖一台始终开机的电脑。

此前，网站经历过两次调整：最初用 WorkBuddy 搭建创作者工作台，后来精简为产品雷达和赛事雷达，并改名为“月鹿造物·AI 创作情报站”。此前一直说“产品才刚开始”，直到真正上线后才明白，这不是客气话，而是产品状态最真实的描述。

一、域名已经生效，为什么产品数据却是空的？

备案通过后，通过 moondeerai.com 能正常打开首页，表面上看，网站已经上线。但进入产品雷达页面后，页面却出现了白屏。

通过浏览器调试工具检查后，发现两个数据文件返回 404。这意味着服务器上找不到对应文件：页面框架虽然存在，但页面需要读取的数据并没有被正确找到。

排查后发现，问题出在部署路径：

• 网站首页文件被部署到了网站根目录；
• 数据文件却被部署脚本上传到了子目录；
• 域名访问的是根目录，页面自然无法读取子目录中的目标数据。

AI 将部署脚本调整为直接上传到网站根目录，重新执行部署后，产品雷达的数据恢复正常。

这一步说明：域名能访问，不代表网站已经完整上线。首页能打开，只能证明页面入口存在；数据、接口、静态资源是否都能被正确访问，才决定用户看到的是完整产品，还是一张空壳页面。

二、自动化任务显示成功，为什么线上还是旧数据？

数据问题修复后，WorkBuddy 的自动化任务每天都会按时触发，终端里也持续显示“部署成功”。但两天后再次打开网站，数据仍然停留在 8 月 4 日。

问题不在任务有没有运行，而在任务究竟更新了哪个目录。

此前网站改版时，网站源码已经迁移到新的目录，但 WorkBuddy 中的自动化任务仍然指向旧目录。于是便出现了一种很容易误判的情况：

• 自动化任务每天都在执行；
• 旧目录中的文件每天都在更新；
• 真正上线的新网站却没有任何变化。

两套目录各自运行，后台看起来很忙，用户看到的网站却依旧停在原地。

随后，AI 将任务工作目录、部署脚本和数据文件统一迁移到新目录，并重新验证完整流程：

采集信息 → 写入数据文件 → 部署网站 → 线上展示内容

整条链路跑通后，线上网站才真正开始同步更新。

自动化能跑，不等于它在更新正确的产品。对于需要持续部署的网站来说，域名路径、部署路径、源码目录、任务工作目录必须保持一致。路径不一致时，即使日志全部显示成功，最终用户看到的也可能还是旧内容。

三、电脑关机后，自动化为什么也停止了？

网站的三个板块可以自动更新后，新的问题变得更明显：所有任务都运行在本机的 WorkBuddy 中。

其中，赛事雷达每天早上 9:30 执行一次更新，主要包括以下步骤：

1. 读取当前已有的赛事数据；
2. 检查哪些比赛已经截止，并将其归档；
3. 调用 Kimi 联网搜索新的 AI 黑客松、AIGC 创作赛、应用创新赛；
4. 将值得关注的新赛事补充到数据库；
5. 重新部署更新后的网站。

这套流程大约需要 3 到 5 分钟。但它有明确前提：电脑必须开机、网络必须稳定、WorkBuddy 必须保持运行。

如果睡过头、出门忘记开电脑，或者网络短暂中断，任务就会错过执行时间。而且错过后不会自行补跑，只能手动重新触发。内容趋势和产品雷达也有相同的问题：

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

三个任务都依赖个人电脑，意味着产品每天能否更新，取决于人是否在电脑旁边。这并不是真正的自动化，更无法支撑一个需要长期运行的产品。

四、为什么要把自动化任务迁移到云端？

针对本机任务依赖电脑的问题，AI 提出了云端迁移方案。但没有一次性搬迁全部任务，而是先选择逻辑最清楚、结果最容易验证的赛事雷达进行测试。

赛事雷达的流程比较直观：

读取赛事 → 搜索新赛事 → 写入数据 → 部署网站

只要查看赛事数据有没有按时更新，就能快速判断云端任务是否成功。

最终，赛事雷达采用了 腾讯云 CloudBase 云函数。AI 通过 CloudBase MCP 工具，直接完成了创建云函数、上传代码和配置定时器等操作。

MCP 为什么能帮助非技术人员部署云函数？

MCP（Model Context Protocol）是一种让 AI 可以直接操作外部服务的协议。有了 CloudBase MCP，AI 不只是告诉用户“应该去哪里配置”，而是可以直接帮助完成实际操作，例如：

• 创建 CloudBase 云函数；
• 上传任务代码；
• 设置每天定时触发的规则；
• 将自动化逻辑部署到腾讯云环境。

赛事雷达迁移后，任务被配置为每天早上 9:30 自动触发。从此以后，电脑是否开机、人在不在家，都不再影响赛事数据更新。

后来，内容趋势也采用同样的方式迁移到云端。产品雷达暂时仍保留在本机 WorkBuddy 中，因为它的搜索和更新逻辑还需要继续优化，稳定后再迁移。

本机自动化适合验证想法，云函数加定时器才更适合持续运行的个人产品。对于个人项目而言，这种方式能以较低成本，让关键任务摆脱本机环境的限制。

这套自动化机制还能做什么？

网站只是自动化能力的一个出口。真正有价值的，是持续获取、整理和更新信息的能力。

例如，这套机制还可以延伸为以下工作流：

• 每日推送信息摘要：每天 09:00 搜集到的爆款内容和创作灵感，可以自动发送到飞书群或邮箱，直接在手机上查看；
• 自动整理选题库：产品动态和赛事信息本身就是创作选题来源，可以让 AI 每周整理为选题清单，并标记哪些适合写教程、哪些适合做测评；
• 触发后续创作流程：发现热门产品更新后，不只记录信息，还可以继续让 AI 生成文章大纲、搜集竞品资料、准备演示脚本。

这样一来，从发现选题到准备创作素材，很多重复环节都可以持续运行，而不需要每次由人手动发起。

五、网站从“能看”到“能用”，关键为什么是产品搜索？

前三个阶段解决的是数据能否自动出现，接下来要解决的是：用户能不能主动从网站获得答案。

原来的产品雷达只能浏览已收录的 AI 产品。由于收录量有限，用户想了解没有被收录的产品时，仍然需要离开网站自行搜索。

因此，网站新增了产品搜索功能：

• 对于已收录的产品，直接在站内筛选；
• 对于未收录的产品，调用 Kimi 联网研究；
• 返回产品简介、开发公司、官网、核心能力、适合人群、价格、近期动态、竞品差异和选题角度。

功能首次部署后，搜索框可以显示，但输入“巨日禄”并等待十几秒后，页面弹出红字提示：network request error。

AI 直接从终端调用搜索后台逻辑，能够正常返回结果。这说明搜索逻辑本身没有坏，问题出在浏览器请求后台服务的路径上。

进一步排查发现，网页请求使用了一个单独的接口地址，而这个地址在部分网络环境下可能被拦截或发生超时。AI 随后将搜索接口调整为与网站使用同一个域名，让浏览器不再跨到另一个地址发起请求。

问题解决后，搜索功能还补充了多项限制与处理：

• 请求频率限制，避免短时间内反复调用；
• 结果缓存，减少重复搜索带来的等待；
• 输入长度限制，控制异常输入；
• 过滤内网地址和搜索引擎中转链接，只保留真实来源。

再次搜索“巨日禄”后，页面能够正常返回完整资料。

后台逻辑能跑通，不代表用户一定能用。从用户在浏览器输入内容，到网页成功发起请求、拿到结果并展示，中间还受到网络环境、接口地址和请求路径的影响。真正的验收，应当从用户入口开始完成。

六、部署反复超时，问题为什么不一定出在代码？

整个过程里，最耗时间的问题出现在云函数部署阶段。

每次更新云函数代码，都需要将代码包上传到腾讯云服务器。但电脑开启了全局网络代理工具，它会在网络底层拦截所有连接，导致上传任务每次进行到 60 秒左右就超时失败。

AI 曾尝试关闭代理环境变量，也尝试关闭系统设置中的代理，但都没有解决问题。原因是该工具并不只作用于应用层设置，而是在更底层影响网络连接。

最初，AI 判断代码包过大也是导致问题的原因之一。因为包含依赖文件的代码包约有 41MB，只能使用大文件上传通道。

随后，部署策略进行了调整：

1. 不再把依赖文件直接打进代码包；
2. 改为将代码上传到云端后，再由云端安装依赖；
3. 代码包从 41MB 缩减至几百 KB；
4. 最终关闭全局网络代理工具后，重新执行直传部署。

最后，云函数部署成功，网站完成重新发布。

当同一个环节持续失败时，不能只盯着代码。网络环境、代理配置、上传方式和打包策略，都会成为部署“最后一公里”里的关键变量。

七、从“能找到”到“能获得答案”，这次上线解决了什么？

回看整个上线过程，产品经历了几个明确阶段：

1. 域名生效：解决用户能否找到网站的问题；
2. 修正部署路径：解决用户能否看到完整数据的问题；
3. 统一目录与任务路径：解决自动化是否真正更新线上网站的问题；
4. 迁移云函数：解决电脑关机后任务是否仍能运行的问题；
5. 使用同域接口：解决用户能否稳定搜索并获得答案的问题。

每一步单独看都不算复杂，但没有一步是“部署完成后自然正确”的。真正难的并不是先把一个功能做出来，而是让功能可以稳定运行，不依赖某一台电脑，也不依赖某个人每天守着任务时间。

八、做类似网站时，哪些实践最值得注意？

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

不要一开始就急着部署到云端。这里先使用 WorkBuddy 在本地验证了几天，确认内容趋势、产品雷达和赛事雷达都能正常完成采集、写入和展示后，才开始考虑云端迁移。

本地已经跑通的流程，迁移到云端只是更换执行环境；本地尚未跑通时，上云只会让问题更难定位。

2. 确认所有路径都指向同一个位置

域名需要指向网站根目录，部署脚本也应当上传到对应根目录；自动化任务的工作目录，则必须与实际修改代码的目录一致。

改版后如果忘记迁移任务路径，就可能出现后台显示成功、线上仍是旧数据的情况。这个问题曾经直接造成两天时间被浪费。

3. 每次只迁移一个任务，验证后再继续

不要一次性把所有自动化任务全部搬到云端。可以先选择逻辑清晰、结果容易判断的任务做 PoC 验证。

这里先将赛事雷达迁移为云函数，连续运行几天确认稳定后，再迁移内容趋势。产品雷达则继续保留在本机，等待搜索与更新逻辑进一步优化。

逐个迁移的价值，在于问题出现时更容易定位，也不会让多个变量同时叠加。

4. 使用 CloudBase MCP 部署云函数

如需让 AI 直接协助操作腾讯云 CloudBase 环境，可以先安装 CloudBase MCP 工具：

npx @cloudbase/cli mcp install

安装完成后，AI 可以协助完成创建云函数、配置定时器等工作，减少在控制台中重复配置的步骤。

5. 必须从真实用户入口完成测试

终端显示“部署成功”，不代表用户真的能够使用功能。产品搜索功能就是典型例子：后台调用正常，但用户从浏览器发起查询时却出现网络报错。

真正的验收标准，应当是用户打开网页、输入真实查询内容、看到完整结果。只有这条链路走通，功能才算真正可用。

结语：产品真正的开始，是不依赖自己也能运行

个人产品的门槛，不只是能不能把页面和功能做出来，而是能不能持续运行。对于不懂技术的人来说，AI 的价值也不只是帮助会写代码的人提高效率，更在于帮助不会写代码的人把想法做成真正能够运行的产品。

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

我认为：一个网站最初看上去只是几张页面、几份数据和几个定时任务，实则每一个环节都在追问同一件事：人不在场时，它还能不能照常运转。页面能打开，未必能读到数据；任务能执行，未必更新了线上；后台有结果，用户未必拿得到答案。产品之难，往往不在最热闹的功能里，而在那些不显眼的路径、网络、目录和时间点中。把这些细处一一理顺，产品才不再只是一个被展示出来的想法，而成为一个可以自己往前走的东西。

#个人产品