TraceGo 开发手记：如何把一个旅行打卡想法收成 1 个月 MVP

起点：一个「什么都想要」的想法

TraceGo 的最初想法很丰满：

• 目标用户是想去旅行的人，偏向社交分享；
• 希望通过打卡内容，给各地文旅带来流量；
• 想做一套奖杯 / 荣誉体系，最好还能和真实的文旅合作挂钩；
• 从大家的打卡里，筛选出优质内容。

再加上我对产品气质的要求：极简、高级，以及一个很硬的约束——一个月。

提醒：TraceGo 和台湾团队做的 iPhone 定位模拟工具 tracego.tw 只是同名，不是同一个产品。

第一刀：MVP 只留一个核心动作

所有功能里，只有一件事决定这个产品能不能活下来：

用户能不能在最短路径里，完成第一条打卡并分享出去。

于是 MVP 的范围被收成三样：

1. 打卡 + 分享：拍照、定位、一句话、发出去；
2. 轻量荣誉体系：用成就记录足迹，但先做轻；
3. 个人足迹页：地图 + 成就 + 个人主页。

被明确往后放的：评论、聊天这类复杂社交功能，以及文旅合作。文旅合作需要真实的用户规模和内容质量作为谈判筹码，在第一个月谈它，是本末倒置。

第二刀：用阶段门禁代替「一口气做完」

每一关都要有能检查的产出，才进入下一关。

先 Web，再原生

技术路线上，我选择先用 Web 交互原型验证流程，再进入 iOS 原生开发。交互原型我用 AI 工具快速生成，这一步的价值是：在写第一行原生代码之前，就能拿着可点击的东西去问人「你会用吗？」。

原型之后，才是真正的工程

原型做出来那天很开心，但我很快提醒自己：

原型完成 ≠ App 完成 ≠ 已上架。

从原型到真实产品，中间还隔着一堆不性感但必须做的事：

• 数据库安全规则：谁能读、谁能写，默认拒绝；
• 图片处理：上传前压缩、Feed 分页加载，否则流量和费用都会失控；
• 权限设计：定位、相册权限要在用户理解的场景下申请；
• 上架准备：开发者账号、签名、打包、隐私说明、审核材料。

这些我都放在门禁 02–04 里逐项打勾，而不是假装它们不存在。

我从这次收敛里学到的

1. 一个月的约束是礼物：它逼你只做最重要的那一件事；
2. 「后置」不是「放弃」：文旅合作、复杂社交都还在路线图上，只是排在验证之后；
3. 诚实标注阶段：对外说「原型阶段」，比说「即将上线」更有信用。

下一步：完成真实数据与安全规则这一关。如果你对旅行打卡 App 有想法，欢迎到 TraceGo 项目页的反馈墙 留言。