当大模型遇上旅行规划，效率提升的背后是AI落地的真实困境。这篇文章来自一位实践者的3个月复盘，从提示词优化到第三方数据对接，再到团队协作与算法备案的陷阱，完整呈现了一场关于效率与可行性的博弈。

1、机会发现

旅行规划这件事，谁做谁知道。以前规划一趟行程，得在小红书、马蜂窝来回切换，东拼西凑信息，一搞就是几个小时。2024年下半年开始频繁使用大模型后，思路自然转向了：能不能用AI来干这事？

尝试了豆包、DeepSeek、腾讯元宝，效果还算说得过去。通过反复调整提示词，最终能输出按天、按小时规划的行程，包含距离、骑行时间、当日安排、核心景点、费用明细——整个行程跨度三个多月。

但用了三个月，问题也浮出水面：

a、从A地到B地，还得把文本信息复制到地图软件导航，每去个地方都要重复操作；
b、景点信息不实时，有些已经关闭，有些博物馆是企业的，实地到了才发现根本不对外；
c、天气信息无法自动更新，得自己反复查询。

要想获得一份靠谱的行程规划，提示词的门道可不少，光对话就得几十分钟。而且最终结果只是文本，无法与线下行程深度融合，信息也没法实时刷新。于是思路转向了：能不能用大模型把整个流程固化下来？目标很明确——

a、搭建一套完整流程，把规划时间压缩到1分钟以内；
b、对接天气、地图、景点等第三方数据，获取实时信息；
c、规划最优路线；
d、根据目的地天气和场景（比如是否登山、山峰高度），提供装备建议。

2、可行性判断

接下来要回答一个问题：这个方法与传统方式相比，效率提升到底有多大？

答案是几十倍。传统方式靠搜索网络信息，数小时起步；把大模型流程和提示词固化后，1分钟出结果。即使是和DeepSeek、豆包这类纯文本模型比，对接了第三方数据后的可用性也明显高出一截。加上地图工具后，用户可以直接在应用内实现导航和最优路径规划，这已经不是纯文字版本能比的。

调研了一圈，飞猪、马蜂窝、高德、携程、小红书都在做类似产品，但试下来效果都不太理想。国外的也试了，同样不理想。

犹豫是难免的——这些公司旅游行业积累深厚，用户规模庞大，正面竞争压力不小。但转念一想，大组织响应慢，内部项目资源争夺激烈，业务重心未必放在这上面。商业逻辑是走to C路线：国内对旅行规划直接收费不现实，先靠功能获取用户，规模起来后再通过销售旅游产品变&现。

权衡之后，决定赌一把，但设置了清晰的里程碑：找种子用户调研、做最小化MVP版本、冷启动用户拓展、根据启动效果决定下一步。

3、团队组建

团队结构很简单：1个产品加2个技术研发（非全职），产品、运营、市场都由一人承担。两位技术合伙人都超过8年经验，之前没有实际合作过，但通过各种方式认识，线上线下面聊过多次。

最初的想法是直接开干，快速上线，用微信小程序而非APP——小程序上架更新快，不用维护安卓和苹果应用市场，推广成本也低得多。但技术合伙人提出要注册公司，理由是后续手续更简单，对外宣传也更正规。几次沟通后，最终让步了。

这里必须提醒：项目没成规模时，根本不需要注册公司。很多人担心项目做起来后被剽窃、商标被抢注、软著出问题，这些担心多数多余——新项目能真正做起来的不到5%，绝大部分会被市场验证为不OK。前期精力应该放在验证可行性上，而不是为那些大概率永远不会发生的“大事”铺路。无必要，勿增实体，最小化做事。

注册公司的坑踩得不止一个。因为项目大量使用AI和模型，微信小程序上架需要算法备案，而这恰恰是另一个连环坑的开端。

4、产品研发

4.1、第一阶段

选定项目、组建团队后，先用Figma做了高保真原型，给种子用户试用，反馈不错。优化demo后，和技术合伙人评审了用户端和运营后台原型。

把Figma的前端代码和核心流程给了技术，但没有写详细的PRD文档。这一步犯了几个错：

a、纯线上沟通，三方在不同地点，信息同步经常不一致；
b、没有详细PRD，后期细节理解偏差大，导致返工；
c、没有做技术评审。技术合伙人说他们来搞定，不用操心，但事实证明大家对产品的理解存在偏差，而这个雷最终在后期炸了。

技术把Figma代码喂给Claude，很快出了用户端界面。测试发现很多细节没到位，流程有偏差，界面和原型有差异。反复提了2-3次修改意见后，才意识到信息根本没有对齐。于是用Figma的AI功能在原型界面右侧加了备注说明，但AI写的PRD准确率只有80%左右，剩下20%得花大量时间调整，仍有不准确的地方。最终手动在Axure上重绘了原型，手写了一版产品文档。

承担产品之外的注册公司、运营拓展等工作，研发上的精力自然少。两位技术合伙人都有8年以上经验，人数少，他们也说技术由他们解决，但实际情况是，彼此之间沟通不畅，每周的定时沟通会上，发现大量信息没有同步。三周下来，进度不理想，协作也不紧密，产品效果更不用提。

4.2、第二阶段

问题摆在眼前，周会上指定了研发负责人，由其中一位整体推进。产品重新手动绘制完成，文档补充完整，按理说不该出问题了。但之前没有做技术评审的问题，在第二阶段直接暴雷。

产品文档再完整，真正仔细看全文的研发并不多，尤其在人手紧张的情况下。如果团队同地办公，研发会频繁问产品，但三个人在三个地方。技术非全职，同时在推进多个项目，精力分散。结果就是，有些时候技术让Claude做的项目连自测都没做好，基础问题都没发现。最后是产品经理扛起了测试工作，反复要求后，技术自测情况才有所好转。

针对信息不一致的问题，要求进行技术评估，深入探讨实现逻辑，明确统一方案后，情况才逐渐改善。当时的主要问题集中在：

a、技术前期对大模型能力评估过高，在精度要求高的场景（如路径规划）使用大模型而非传统固定算法，导致规划结果极不稳定，多个节点叠加后系统偏差极大；
b、单流程节点的大模型提示词太笼统，限制条件不足，单个模型输出内容差异极大，甚至出现同一天第一个景点在云南丽江、第二个景点在北京这种荒谬的情况；
c、技术想探索大模型的各种能力，流程节点没有按规划走，且没有同步相关信息。

总结起来就是：技术没有按产品规划逻辑执行，走了其他方案且未同步，对大模型的使用边界和场景认知不足，泛化使用过度。前后折腾了2-3周。

与此同时，公司注册完成后开始申请微信小程序账号，发现上架必须算法备案——因为应用核心就是算法和大模型。算法备案审核周期极长，一次10-15个工作日，网站指导信息不足，反复提交2次仍未通过。紧急将前端从小程序改为H5，又浪费了2周左右。H5的好处是只需ICP备案，备案后可随时更新，无需平台审核，自由度极大。

5、上线运营

项目网址：https://m.lvtuai.com/planning

上线前，通过各种方式找到了大量旅游用户聚集地：豆瓣、QQ、微信等，所有渠道汇集用户几十万。在相关渠道发产品软文、群里发产品介绍，被踢了一大波群。在论坛发软文，开始时获得不错流量，多的时候一天200多人通过软文进入产品，但一周后被管理员删帖、举报广告，账号被封。流量瞬间断掉。后续尝试了多种拓客方式，效果都不理想。

中途找过运营合伙人，对方都担心与携程、飞猪、马蜂窝这类平台竞争，最终没有合作。项目因拓展受阻，整体陷入停滞。

6、复盘教训

a、必须坚持MVP原则——最小化成本做验证。不管资源多寡，这个原则都不能放弃。如何做MVP？回归第一性原理。

b、获客的优先级要提到最高。分发比多数创始人想象的更重要、更难。产品再好，没人知道，等于不存在。酒香也怕巷子深，这句话在当下比任何时候都真实。

c、现阶段，大模型并不能解决所有问题。不要盲目信任AI而轻视传统方法。具体内容可以参考《最近几个月的AI大模型独立应用实践-3-大模型解决不了一切》。

d、做事的本质逻辑没有任何变化。该做的事情一件不能少：产品流程与规范、评审、测试……这些节点和标准省不掉。每个环节该达到的标准和规范，如果被跳过，问题就会流入下一环，最终暴雷。

e、要做自己擅长的事——做木桶的长板。别指望AI能补齐所有短板。AI能在长板部分带来数量级的提效，效果远胜于把它用在补齐短板上。短板最多补到平均水平，这种水平形不成真正的价值。