当大模型遇上旅行规划，效率提升的背后是AI落地的真实困境。本文作者通过3个月的实践，揭示了从提示词优化到第三方数据对接的全流程挑战，更直面了团队协作与算法备案等致命陷阱。这场关于效率与可行性的博弈，为AI产品商业化提供了鲜活样本。

1、机会发现

为啥会想走一个利用大模型来进行旅游规划的应用呢？

在之前进行旅行规划，总是需要在小红书、马蜂窝等平台找信息，然后再进行规划，要几个小时的时间。

去年下半年去环游中国，因为我从2024年下半年开始越来越多使用大模型的原因，因此当时想到使用大模型来进行一个规划。

然后我就用豆包、deepseek、腾讯元宝做了一下规划，规划的效果还说的过去，如下图所示。

使用提示词进行多次迭代之后，出的效果如下图，能够按照天、小时规划行程，距离，骑行时间，当日详细安排，核心景点，各项费用，整个行程持续3个多月时间。

在这个三个月时间行程时间中，也发现这样的文本规划信息其实存在很多缺点，比如说：

a、我要从A地去B地，要导航等还是需要从文本信息中复制内容到第三方地图软件去导航，没去一个地方都需要进行反复操作

b、大模型梳理的景点信息不实时，有些景点已经关闭，或者有些景点，比如博物馆有些事企业的，实地到了之后发现根本不对外

c、天气信息无法实时获取，需要不断地查询。

与大模型对话，要获得一个比较好的行程规划，也是需要一些提示词技巧的，整个与大模型的对话也需要几十分钟的时间。而且获得行程也是文本的，不能和线下行程深度的融合，信息无法实时更新。

因此，我有了一个想法，想着利用大模型来帮助用户进行行程规划，要达到的效果如下

a、搭建一套行程规划的完整流程，将一个行程规划压缩到1分钟以内

b、引入天气、地图、景点信息等第三方软件，获取实时的信息

c、对整个行程的路线进行规划，指定最优的行程

d、根据目的地的天气、目的地场景（是否登山，山峰高度）等，提供行程装备建议

2、可行性判断

然后我进一步思考这个项目的可行性。

这个方式相对于传统的旅行规划方式是否有很大的效率提升呢？

确实是有的，最传统的方式通过搜索网络信息来进行规划需要数小时，如果利用大模型，将规划流程和相关提示词固化之后，可以压缩到1分钟内。那么这个效率可以提升几十倍以上。

如果相对现在大语言模型比如deepseek，豆包这种呢，也有很大的优势。在对接了第三方天气、景点、酒店等数据之后，规划的行程更具有可用性。

加上地图工具之后，那么用户可以直接在我的这个应用中实现导航，可以进行最优路径的规划。

这就比纯文字版本的旅行规划要好很多。

进一步调研，发现市面上有一些做类似的，比如飞猪、马蜂窝、高德地图、携程、小红书有在做类似的产品，试用之后发现，效果并不是很好。

国外的也有类似的产品，也去尝试了一下，效果也不是很理想。

我有些犹豫是否要做，因为这些公司在旅游行业或者知识分享领域有很多的积累，有大量的用户，之后如果竞争，则会面临很大的压力。

后面考虑到这些公司比较大，组织响应比较慢，在迭代速度上会比较慢，另外这些公司内部会有大量的项目会争夺资源，业务中心并不一定放在这上面。

这个项目的商业逻辑是，to C端用户，在国内to C用户旅行规划直接收费不太可能，因此是利用这个旅行规划功能获取用户，然后在用户有一定规模的时候，再去销售旅游产品获取收益。

因此，考虑可以稍微赌一把，并设置一些里程碑。

a、进一步找种子用户来进行调研

b、研发一个最简化的MVP版本，

c、做冷启动的用户拓展

d、根据冷启动的情况，看下一步如何做

3、团队组建

整个团队组建为1产品+2技术研发（非全职），我充当产品+运营+市场的角色。

在这个AI旅游规划项目中，两位技术研发一位负责前端，一位负责后台。两位技术合伙人都具有8年以上的研发经验，但我们之前没有实际合作过项目，是以各种方式认识的，之后有各种线上或者线下交流。

团队组建完成之后，我刚开始的想法是直接研发项目，然后快速上线。早期的产品不会做APP，而是微信小程序的方式进行，这样可以利用微信生态进行分发。

小程序的上架和更新也要快速很多，不用去维护安卓和苹果各大应用市场，另外就是APP的推广成本已经很高了，完全没有必要。

但之后技术合伙人提出要注册一个公司，理由是公司为主体，之后的很多手续要简单很多，另外对外宣传要好一些。

最终几次沟通之后，我没有坚持个人的名义上架，同意注册公司。

这里提醒大家，如果项目没有成规模的时候，根本不需要注册公司。

很多时候我们担心一旦项目做起来了，会不会被人剽窃，商标名称会不会被人抢注，如果不去申请软著会不会出什么问题。

其实这些担心完全是多余的，因为新项目真正能够做起来的不到5%，绝大部分的项目最终会被市场验证为不OK。

我们在前期最主要的精力应该是验证这个项目的可行性，而不是担心项目做大了之后被各种侵权。

因为实际情况是，你做的项目有非常大的概率是撑不到那个时候就已经验证不对。

那么，其实我们是没有必要在注册公司或者搞各种事情上的，特别是自己做项目和业务的时候。如果是在公司上班，那就另说。

无必要，勿增实体，最小化的去做事情。

这里踩了几个坑，因为这个项目中涉及到大量的模型和AI使用，导致微信小程序上架需要对算法备案，一个是微信小程序

4、产品研发

4.1、第一阶段

在项目选定，团队组建之后，我进一步找了一些种子用户来调研，我利用figma生成了可交付的高保真原型，给到这些种子用户使用，反馈比较好。

因此我进一步的优化产品demo，

然后和技术合伙人评审了产品的用户端与运营后台原型。

我将figma的前端代码下载之后给到技术，然后把主要的核心流程也给到了技术，但是没有详细的PRD文档。

这个地方犯了错误：

a、因为我和技术合伙人不在同一个地方，都是纯线上沟通，这导致有时候信息同步不是很一致，有分别沟通的情况。

b、产品原型没有详细的PRD，这导致了后期一些细节问题大家理解不一致，我又重新返工了

c、没有进行技术评审，技术合伙人告知他们来解决技术问题，不用我担心，从之后的工作看，大家对产品各方面理解是有一定偏差的，而我没有坚持进行技术相关的评审，导致这个问题在后期成了一个雷。

技术将figma的前端代码给到Claude，之后很快出来一个用户端的界面。

我进行测试，发现很多地方的细节没有做到位，流程也有差异，做出的界面各方面也和我的原型有差异，因此我将这些问题提交了修改意见和bug。

经过2-3次之后，我发发现了问题，并意识到我们之前的信息没有对齐，大家对这个产品的理解是存在差异性的。

因此我将原型增加了完整的备注说明，第一个版本是在figma上，我使用figam的AI功能，在每个界面的右侧增加了备注说明，可以收起打开。

但发现AI写的PRD文档还是存在一些问题，能够正确80%，但剩下的一些内容，需要花很多时间去调整，但还是有不准确的地方。

因此我手动在Axure上将原型重新绘制了一个版本，手动的将产品文档写了一版。

并将这个版本给到技术合伙人这边。

我因为要承担除研发以外的所有工作，比如注册公司，想后期的运营和拓展等各方面的事情，我在研发上的精力就相对少一些。

因为我想到2为技术合伙人至少都有8年以上的经验，我们人数也少，那么他们也说技术由他们解决就好，他们来沟通，我不用担心。

但实际上，技术研发这里，2为技术合伙人没有很好的沟通，我们以周为单位的定时沟通上，发现很多信息没有同步。

在这样经过3周之后，我发现项目进度并不理想，彼此之间的协作其实并不紧密。

出来的产品效果也不理想。

4.2、第二阶段

鉴于研发的进度、协调、产品效果的问题。

在周会上沟通，指定了整个项目的研发负责人，由其中一位整体负责研发进度。

在这个阶段，我将产品重新手动绘制了一遍，并且将文档内容补充完成，按理说就不太会出现什么问题。

但是之前说的，技术没有评审，这个问题在第二阶段暴雷了。

产品经理写的文档即便很完整，但是研发真正完整而详细看文档的人其实并不多，特别在人手不太够的情况下。

当团队在一个地方办公的时候，技术会频繁的询问产品，而我们这个团队三个人在三个地方。

而且技术非全职，他们也有自己一些项目在做，也就是同时在推进多个项目，这导致精力分散。

最终的结果就是，有些时候，技术让Claude做出来的项目都没有很好的自测，连一些比较基础的问题都没有发现。

我承担起了测试的工作。

之后在我强烈要求下，技术的自测情况有了好转。

而对于信息不一致的情况，我要求再进行技术评估，对与技术的实现逻辑进行了更深入的探讨，我对整个技术实现完全了解，并要求按照统一沟通实现，之后情况有了好转。

当时主要问题是：

a、技术前期对于大模型的能力评估过高，在一些大模型不能保证精度的场景使用大模型来处理，而不是采用传统的固定算法，比如路径规划等——这导致规划结果非常不稳定。多个节点的多个大模型叠加之后，系统偏差极大。

b、单流程节点的大模型提示词和示例存在问题，提示词太笼统，宽泛，限制条件不足，导致单个模型的输出内容都差异极大，而且出现一些和现实世界极不相符的内容——比如某一天的第一个景点是云南丽江的景点，第二个景点是北京的一个景点。

c、技术想要探索大模型的能力，进行了各种技术探索，流程节点没有按照规划流程图实现，但没有同步相关信息

总结起来就是，技术没有遵循产品规划逻辑走，存在走其它方案的情况，并且没有同步相关信息，并且对大模型的使用边界和场景认知不足，过于泛化的使用大模型的情况。

以上问题，导致前后折腾了2-3周时间。

同时我公司注册之后，开始申请各种账号，比如微信小程序，发现微信小程序上架需要进行算法备案。

原因是我们的应用中主要就是以算法和大模型最主，没有进行算法备案是上不了的。

算法备案的审核周期非常长，一次审核就需要10-15个工作日，但现在这个进行算法备案的网站，给的指导信息不太足，导致反复提交了2次依然没有通过。

因此，我们紧急的将前期上线用户端，从小程序该为了H5，这中间又浪费2周左右的时间。

使用H5的好处就是只需要做ICP备案，备案之后的网站，可以随时更新，无需别的平台进行审核，自由度极大。

5、上线运营

这是AI旅游规划的项目网址https://m.lvtuai.com/planning

在上线之前，我已经通过各种方式，找到了一大批旅游用户的聚集地，比如说豆瓣，QQ，微信等。

所有这些渠道汇集的用户，有几十万。

我在相关渠道发产品软文，各种群里发产品介绍，被踢了一大波群。

在各种论坛发产品软文，刚开始获得了不错的自然流量，多的时候一谈有200多人通过软文进到产品中使用，但经过1周左右之后，被论坛的管理员删帖，举报广告，导致账号被封禁了。

流量一下就断掉了，后续也尝试了多种方式拓客，但效果都不如人意。

中途有尝试找运营合伙人，但对方都担心这种产品和携程，飞猪，马蜂窝这种平台竞争，最终没有合作。

所以最终项目因为拓展受阻，整个项目陷入停滞状况。

6、复盘教训

a、一定要MVP的去做事，最小成本的做事，不要注重形式和名声，不要讲排场——这是要坚持的原则，无论你的资源如何，都不能放弃这个原则。如何做MVP，坚持第一性原理

b、获客要放到非常高的优先级，分发比大多数创始人想象的重要得多，也难得多，产品好，但没人找到你，和产品不存在差不多，或者换一句话也行，就是“酒香也怕巷子深”。

c、目前阶段，大模型不能解决所有问题，不要盲目信任大模型而看不起传统的做事方式和方法，详细内容可以查看文章最近几个月的AI大模型独立应用实践-3-大模型解决不了一切

d、做事的本质逻辑没有任何变化，该做的事情一件也没有变化，比如产品流程与规范，更细节的比如产品的评审，技术的评审，测试等，这些流程节点和规范没有变化，只是这个流程由谁来做，是不是要单独分岗位出来做而已。每个节点要做的事情，要达到的标准规范这些事省不掉的，如果省掉了，这些问题就会流入下一个环节，最终会暴雷的。

e、要做自己擅长的事情，也就是做木桶的长板，不要妄想利用AI把所有的短板补齐。因为AI会让你提效，在你的长板部分提效的数量级会高于短板，带来的效果也是。短板你补齐只能到一个较为平均和平庸的水平，这种水平不会产生太大的价值。