复盘：一个花了40多小时的项目，最终我选择了放弃

💡 项目反思：我花了 40 多个小时，把一个产品从 0 做到了能跑通的 MVP——然后在它即将成型的路上，我按下了停止。倒不是这东西有多难做，主要是我想明白了：有些项目，不值得投入。

一、为什么想做这件事

事情要从我的老本行说起。作为曾经的连锁酒店店长，有一项日常工作——就是持续关注当地的展会、大型活动、演唱会、赛事、考试等信息。因为这些东西直接关系到酒店的营销策略、房价、房态，要提前做营销铺排，才能把收益拉起来。

做酒店的人都懂，日常事情又多又杂，这项”盯活动”的活经常被挤到一边：要么疏漏，要么得花额外的时间，去相关网站和公众号一个个的去搜索、去收集汇总。需要干这活的，远不止店长，酒店销售、运营板块的人，都得对市场动态保持足够的敏感。

需求也就这么出来了——能不能不用每天手动去搜，靠一个自动化工具就能直接掌握全区域的活动信息？

于是我想做一个产品：酒店营销日历。它的逻辑很直接：

• 通过程序每天后台自动爬取政府各类公告，以及指定微信公众号上发布的活动信息；
• 汇总成一个数据库；
• 再渲染到前端的日历页面上。

有活动的日期会直接标出来，点进去就能看到具体信息。

不用再人工一个个公众号、一个个官网去翻，下面是页面截图：

酒店营销日历页面效果图

二、说干就干，先跑通 MVP

整个项目最核心的部分是爬取数据源，数据主要分两类：

1. 政府类网站 属于公开数据，爬起来相对容易。我先试了 5 个网站，数据都正常爬取、正常显示，数据来源为：区文化和旅游厅、区商务厅、人事考试网、区体育局、市人民政府。
2. 微信公众号 公众号这块才是真正的硬骨头。微信是一个非常封闭的系统，想免费又稳定地自动爬取文章内容，极其困难。

政府类网站这条链路已经跑通了，但公众号这边一直没有稳妥的方案。项目到这里，暂时停了两天。

酒店营销日历项目架构图

三、停下来的这两天，我做了什么

停下来的这两天，我没有闲着。我把能想到的路子都试了一遍——微信搜索、Google、GitHub，还借助 AI 工具 Workbuddy 去寻找爬取公众号数据的方案。

绕了一圈之后，结论很统一：免费的方式极不稳定；相对稳定且能落地的，是付费购买 API 接口。比如通过 Tikhub 网站购买微信 API，一个月的总成本在 200～300 元。Tikhub 官方对它的介绍也很直白：

适当付费我也考虑过，也认真算过这笔账。但我的初衷是把这个产品做成一个 免费工具，如果前期自己要先持续投入过高的固定成本，就很划不来了。

当然，我也想过更长远的路：等产品成熟、用户量上来之后，接入广告变现。这个产品的主要人群是酒店人，那么就可以对接酒店产品的供应商（布草、一次性客用品、洗护用品等），靠返点或广告费赚钱。不过坦白讲，眼下离这一步还太远，只能算作一个遥远的长期规划。

四、回头再看，项目到底值不值得做？

算完技术账，我又重新思考了产品账：这个项目到底值不值得做？

首先，需求确实存在，也是刚需。但对于身处梧州这类五六线城市的酒店营销人员，这个产品的意义并不大。主要有三个叠加的因素：

这三点叠在一起，再算上前面那些维护成本——这笔账怎么算都不划算，有点”杀鸡用牛刀”的味道。

往深了想，问题的本质其实很清晰：

这样一来，整个逻辑就崩了：自己用不上（梧州一年没几个活动）；整个广西也就南宁、柳州、桂林的活动相对多一些；做出来之后自己都没法当用户去验证效果；而一个连自己都不常用的工具，很难做好。

五、最终的决定与留下的经验

对照下来，这个项目在”用户是否足够多”、”投入产出是否成正比”、”自己是不是真的用得上”这几条上，都没能过线。归根结底，需求本身没问题，主要是小城市的活动密度，撑不起这套系统的价值。这是客观条件决定的。

这次放弃，我也总结了一个项目在评估时值得关注的几个判断维度：

我花了 40 多个小时，最终选择放弃。但放弃并不等于失败——这 40 个小时，买回的是一个更清醒的判断：什么值得做，什么不值得做。