AI大模型智能旅游规划项目实战复盘
一位产品经理独立操盘AI旅游规划产品从0到停滞的完整复盘：3个月环游中国催生产品灵感，1产品+2技术非全职团队远程协作踩遍PRD缺失、大模型滥用、算法备案三重雷，最终因冷启动获客受阻项目停滞——五条教训直指MVP原则、分发优先级、大模型使用边界。
基本信息
- 来源类型：网页文章
- 原文位置：raw/articles/2026-05-31-105950-tg-69f876.md
- 原文 URL：https://www.woshipm.com/pd/6404761.html
- 作者：markzou
- 发布日期：2026-05-29
- 消化日期：2026-05-31
核心观点
-
旅行规划效率差距催生产品机会：传统方式规划一次3个月环游行程需要数小时，大模型+提示词迭代可压缩到1分钟，效率提升几十倍。但纯文本输出无法与地图导航、实时天气、景点状态深度融合——这个”最后一公里”断层就是产品切入点。
-
MVP 原则被形式主义反噬：作者明知要最小化做事，却在团队压力下注册了公司（“项目做起来不到5%”），导致后续算法备案等合规流程消耗了大量时间和精力。教训：“无必要，勿增实体”，项目没跑通前不要增加组织层面的实体。
-
大模型使用边界是技术团队最容易踩的雷：技术合伙人对大模型能力评估过高，在路径规划等需要精确计算的场景用大模型替代传统算法，导致”某天第一个景点在云南丽江、第二个景点在北京”这种离谱输出。多个大模型节点叠加后系统偏差极大。
-
远程非全职团队的沟通成本被严重低估：3人3地、非全职、无技术评审→PRD理解偏差→2-3周返工。本质问题是”没有进行技术评审”——技术说”你不用管”不等于”已经对齐了”。教训：产品流程与规范（评审、测试）一个都不能省，不管团队多小。
-
冷启动获客是独立项目最大的生死线：在豆瓣/QQ/微信群铺软文，峰值日引200+用户，但1周后被删帖封号，流量彻底断裂。产品再好，“酒香也怕巷子深”——分发比大多数创始人想象的重要得多，也难得多。
-
算法备案是AI产品上架微信小程序的隐藏门槛：应用以算法和大模型为主，微信小程序要求算法备案，审核周期10-15个工作日/次，指导信息不足导致2次被打回。最终紧急切换H5方案（只需ICP备案），浪费约2周。
实操内容保留
（本文无实操代码/模板，以项目管理经验为主）
操作步骤
作者设定的项目里程碑：
- 进一步找种子用户来进行调研
- 研发一个最简化的 MVP 版本
- 做冷启动的用户拓展
- 根据冷启动的情况，看下一步如何做
团队踩坑后的补救流程：
- 指定研发负责人（解决无人统筹问题）
- 手动重绘原型 + 完整PRD文档（解决信息不对齐）
- 强制技术评审（解决大模型滥用问题）
- 从小程序紧急切换H5（解决算法备案卡点）
关键概念
- MVP — 作者第一条教训即是”一定要MVP的去做事”，但实践中因注册公司等形式主义反噬了MVP原则
- 冷启动 — 项目最终死于冷启动阶段：获客渠道单一（软文），被封后无备用渠道，流量断裂导致项目停滞
- 种子用户 — 作者在可行性判断阶段就规划了”找种子用户调研”，用Figma高保真原型收集反馈，但冷启动阶段的种子用户拓展失败
- 项目复盘 — 本文本身就是一个完整的项目复盘案例，五条教训覆盖MVP、分发、大模型边界、流程规范、长板理论
- 算法备案 — 微信小程序上架AI产品的合规卡点，审核周期长、指导不足，是AI产品落地的隐藏成本
- AI产品PRD — 作者先用Figma AI生成PRD（准确率约80%），后手动用Axure重写，说明AI生成PRD仍需人工校准
- Claude Code — 技术合伙人将Figma前端代码给到Claude生成用户端界面，但自测不足导致基础bug流入测试
与其他素材的关联
- 与 2026-05-09-ai-pm-c-end-0-to-1 的关系：同为AI产品C端从0到1实战复盘，该文聚焦MVP假设验证方法论，本文更侧重团队协作踩坑和冷启动失败
- 与 2026-05-09-product-to-startup-blues 的关系：同为产品到创业的失败复盘，该文讲GTM认知，本文讲”获客比产品重要”的血泪教训
- 与 2026-05-28-woshipm-vibe-coding-cold-start-offline 的关系：同为独立产品冷启动案例，该文成功（1个月1500+用户），本文失败（获客渠道被封后停滞），形成正反对照
- 与 2026-05-29-woshipm-ai-emotional-product-practice-methodology 的关系：同为AI产品练手项目复盘，该文强调假设驱动和安全底线，本文强调MVP原则和团队协作
原文精彩摘录
这里提醒大家，如果项目没有成规模的时候，根本不需要注册公司。很多时候我们担心一旦项目做起来了，会不会被人剽窃，商标名称会不会被人抢注，如果不去申请软著会不会出什么问题。其实这些担心完全是多余的，因为新项目真正能够做起来的不到5%，绝大部分的项目最终会被市场验证为不OK。我们在前期最主要的精力应该是验证这个项目的可行性，而不是担心项目做大了之后被各种侵权。无必要，勿增实体，最小化的去做事情。
技术前期对于大模型的能力评估过高，在一些大模型不能保证精度的场景使用大模型来处理，而不是采用传统的固定算法，比如路径规划等——这导致规划结果非常不稳定。多个节点的多个大模型叠加之后，系统偏差极大。单流程节点的大模型提示词和示例存在问题，提示词太笼统，宽泛，限制条件不足，导致单个模型的输出内容都差异极大，而且出现一些和现实世界极不相符的内容——比如某一天的第一个景点是云南丽江的景点，第二个景点是北京的一个景点。
做事的本质逻辑没有任何变化，该做的事情一件也没有变化，比如产品流程与规范，更细节的比如产品的评审，技术的评审，测试等，这些流程节点和规范没有变化，只是这个流程由谁来做，是不是要单独分岗位出来做而已。每个节点要做的事情，要达到的标准规范这些事省不掉的，如果省掉了，这些问题就会流入下一个环节，最终会暴雷的。
获客要放到非常高的优先级，分发比大多数创始人想象的重要得多，也难得多，产品好，但没人找到你，和产品不存在差不多，或者换一句话也行，就是”酒香也怕巷子深”。
要做自己擅长的事情，也就是做木桶的长板，不要妄想利用AI把所有的短板补齐。因为AI会让你提效，在你的长板部分提效的数量级会高于短板，带来的效果也是。短板你补齐只能到一个较为平均和平庸的水平，这种水平不会产生太大的价值。