智能旅行规划助手：需求分析与系统架构设计

写在前面

最近完成了一个智能旅行规划助手项目。这个项目不是简单地调用一次大模型 API，然后把结果展示出来，而是尝试把一个真实的 AI 应用从需求拆解、外部工具接入、Agent 协作、结构化输出、前端展示到服务部署完整跑通。

这篇文章先记录第一阶段：我如何理解这个项目的需求，以及为什么最后选择了“FastAPI 后端 + LLM Agent + 高德地图工具 + Vue3 前端”的整体架构。

为什么做旅行规划这个场景

旅行规划看起来是一个很适合大模型的场景，因为用户的输入天然是模糊的：

• 想去哪个城市
• 玩几天
• 喜欢历史文化还是自然风光
• 预算大概多少
• 住经济型酒店还是舒适型酒店
• 是否需要公共交通优先

但真正做起来会发现，旅行规划不能只靠模型“编”。如果模型直接生成行程，很容易出现几个问题：

• 景点不存在，或者位置不合理
• 每天安排过满，不符合真实出行节奏
• 酒店、天气、交通等信息缺乏真实依据
• 前端无法稳定消费模型输出

所以这个项目的核心不是“让模型写一段旅行建议”，而是让模型在真实数据约束下生成可展示、可校验、可兜底的旅行计划。

需求拆解

我把用户输入拆成了几个核心字段：

• 目的地：例如北京、杭州、成都
• 出行日期：用于计算天数和天气建议
• 旅行偏好：历史文化、自然风光、美食、购物、休闲等
• 交通方式：公共交通、自驾、步行优先
• 住宿偏好：经济型、舒适型、高端酒店
• 额外要求：例如无障碍设施、亲子、避开热门景点等

对应的系统输出不能是一段自由文本，而应该是一份结构化行程：

• 每日行程概览
• 每天的景点安排
• 餐饮建议
• 住宿建议
• 交通建议
• 天气提醒
• 预算估算

这一步决定了后续必须做 Schema 设计，而不是只做普通 ChatBot。

系统架构

最终我把系统拆成四层：

1
2
3
4
5
6

用户表单
  -> FastAPI 接口
  -> 工具数据获取层
  -> LLM Agent 规划层
  -> Pydantic 校验与兜底
  -> Vue3 结果展示页

1. 前端输入层

前端负责把用户需求收集清楚，避免用户只输入一句“帮我规划北京三日游”就直接丢给模型。

这一步的意义是降低 Prompt 的不确定性。用户选择越结构化，后端构造 Prompt 时就越稳定。

2. 后端服务层

后端使用 FastAPI，主要原因是：

• Python 生态接入 LLM 和第三方 API 更方便
• Pydantic 可以直接做请求参数校验和响应结构约束
• FastAPI 自动生成接口文档，调试效率高

接口核心是：

1

POST /api/trip/plan

前端提交 JSON，后端将其解析成请求模型，然后进入规划链路。

3. 工具增强层

我没有让模型凭空生成景点，而是先调用高德地图 API 获取真实数据：

• POI 搜索
• 酒店搜索
• 天气查询

这些数据会作为 LLM 的上下文输入，让模型基于真实候选项进行规划。

4. Agent 规划层

项目里不是一个大 Prompt 解决全部问题，而是拆成多个 Agent 子任务：

• 景点搜索 Agent
• 天气分析 Agent
• 酒店推荐 Agent
• 行程规划 Agent

这样做的好处是每个子任务更清晰，也更容易排查是哪一步出了问题。

我对这个项目的定位

这个项目的重点不是算法有多复杂，而是把 AI 应用开发中的几个关键问题串起来：

• 如何把用户需求变成结构化输入
• 如何接入真实工具数据降低幻觉
• 如何让 LLM 输出稳定 JSON
• 如何用 Pydantic 做校验
• 如何在模型失败时提供兜底计划
• 如何部署成一个真实可访问的 Web 项目

这也是我目前理解的 AI 应用开发：不是只会调 API，而是要能把模型能力放到一个完整系统里，让它稳定地为用户完成任务。

小结

第一阶段主要完成了需求分析和架构设计。下一篇会继续记录 FastAPI 接口和 Pydantic Schema 的设计过程，也就是如何让前后端和大模型输出都围绕同一套数据结构工作。