当大模型遇上旅行规划，一场关于精准与效率的战役正式打响。本文深度拆解对话式AI行程规划产品的核心流程，揭秘多模态意图识别、行程框架生成等关键环节中，大模型与传统算法的黄金分割点。从提示词设计到模型评估体系，手把手教你打造一个听得懂、问得准、规划稳的AI旅伴。
上一篇文章，和大家聊了一下这个项目，做了一个整体性的复盘，但主要是以业务和团队等方面说的，但是实现方案和大模型相关评估上，说的不多，这篇文章，我们就在产品实现方案和大模型这块来聊一下。
这个项目主要是让用户通过对话，利用大模型来实现旅行行程规划。
核心的流程：收集用户意图 → 行程框架规划 → 每日景点规划 → 行程路径规划→ 结果展示
详细流程图如下所示。
我们将流程更详细的说一下，这样大家对项目逻辑和作用，之后在哪些环节使用大模型，哪些环节不使用大模型就会更请清楚。
首先我们需要收集用户的旅行规划相关信息，有了这些信息，才能作为大模型的输入。
输入的方式提供了三种模式：
a、快捷输入方式——每个快捷方式预设提示词，比如说周末周边游，预设情侣一男一女，获取定位确定地区，不出省内，2天1夜，休闲，价格适中，自驾出行
b、通过文字、语音、图片——在对话显示框中给出提示词，提示用户提供必要的信息
c、长途旅行——模版信息填写提交，让用户填写必要的信息，然后提交
用户填写信息之后，对于快捷方式和长途旅行的模版信息，都是有标准信息的，基本可以进入旅行规划，但是针对用户输入框输入的需要做两件事情
a、判断用户信息是不是旅游相关及与旅行规划相关，如果不是，则需要提醒用户
b、用户输入的信息是否满足规划所需的最低信息
当我们收集到用户的旅行相关意图信息并且判断符合规划启动条件时，就开始规划整个行程的宏观内容，也就是整个行程总的天数，哪些地区，行程包含哪些类型的景点等
在宏观规划之后，进一步的规划每一天的行程，包括吃、住、行、玩的各方面。
进一步将这些元素进行按照时间从早到晚进行组合，规划路径，提供进一步的行程建议。
最终，我们将宏观规划和微观规划的行程，打包之后组合成一个完整的行程，然后按照一个固定的展示框架输出给前端进行展示。
上面我们较为详细的说了一下整个的流程，现在我们进一步讨论，这整个业务流程中，哪些选择使用大模型来处理，哪些还是使用传统的方式来处理，以及为什么这么做。
这个环节中，涉及到用户通过输入框来输入信息，里面有语音及图片方式，需要模型来解析用户的语音及图片，这涉及多模态的理解，用户意图的提取，这里是必须要用到大模型的。
需要判断用户的输入信息是不是旅游相关信息，如果不是，需要提醒用户聊跟旅游相关的，用户问了旅行相关信息，则回复用户，比如最近哪里适合旅游。
并且进一步判断，用户输入的信息是否和旅行规划信息相关，是否满足出发旅行规划的最少参数。
如果判断用户输入的信息不足，则需要对用户进行追问，提醒用户还确实哪些信息。以上这些都是需要大模型来处理。
当识别到用户旅行规划信息已满足规划需求时，则将相关信息和预设的旅行规划提示词作为输入，给到大模型，由大模型进行规划，给出整个行程的基调。
根据宏观规划中整体的方向+每一天的行程重点+限制条件（比如当日景点数+单日经费标准）作为输入，让大模型规划每日行程，包含早中晚餐食，景点。
以上部分采用大模型来规划，以下部分则采用固定算法处理。
为了达到让行程的景点数据为可用数据，则将行程景点在大模型规划的时候多规划一些作为冗余，然后再对接三方API数据进行查询，将不可用的景点剔除，对剩下的按照最优路径法从早餐店开始规划直到入驻酒店。
如果无效景点数据过多，则需要重复大模型规划进行补齐。
规划完成之后，还需要做一些补充，比如将从第三方获取的景点信息等，再让大模型进行一些加工，提炼景点的一些特色信息，简介等方便给用户做出更标准的展示。
最终将整个方案，按照固定逻辑展示给用户端，这里不是让大模型直接输出展示，也不是让大模型来生成每次的界面，而是使用传统前端控制的方式来处理。
以下是各个流程节点涉及模型及其作用
通过以上每个节点中涉及的大模型，我们进一步讨论，怎样评估哪个环节使用哪个大模型，又如何设计评估维度、指标、测试集等让最终应用达到一个好的效果。
用户说话可能乱糟糟的：打字、发语音、甚至发一张照片。模型第一件事就是搞明白用户到底想去哪、玩几天、和谁去、花多少钱。
字段准确率：用户说“五一去西安3天”，模型必须听出“西安”和“3天”。要是把“西安”听成“西藏”，后面全白干。这是最基础的。
偏好召回率：用户说“我喜欢历史，也爱吃小吃”，模型漏掉“爱吃”的话，推荐的行程可能全是博物馆，没有美食街。用户会觉得“你没听懂我”。
多模态识别准确率：用户发一张海边照片说“想去这儿”，模型得认出这是三亚。或者发语音说“去成都”，得转成文字。这个指标看模型能不能处理“非打字”的输入。
用户经常只说一半，比如“想去成都”。模型不能瞎编，得知道还缺什么，然后礼貌地问。
缺失字段识别率：用户没说玩几天，模型得知道“缺的是天数”，而不是去问“您喜欢什么景点”。
用户可能会问“今天天气怎么样”甚至不礼貌的问题。AI旅伴只做旅游，不该答的要拒绝，但拒绝后要引导回来。
用户不想一上来就看每天几点去哪，太晕。模型应该先给个整体概览：主要去哪些区域、大概花多少钱、行程松还是紧。
用户确认概览后，模型给出每天几点去哪、怎么去、吃什么、住哪。必须真实可行，不能坑人。
对于三方返回的景点数据，有时候过多，无法再用户端完全展示，需要大模型给进一步提炼出特色标签，对内容进行精炼。
这些不针对某个环节，而是看整个产品快不快、稳不稳、安不安全、贵不贵。
我们上面已经针对各个业务流程节点中用到大模型的地方设计了评估维度和指标，然后我们针对每个节点的业务情况，设计测试题，大致标准如下，具体题目就不展示了。
这套测试就像AI旅伴的“驾照考试”——科目一考交规（听懂意图），科目二考倒库（追缺失信息），科目三考路考（宏观+微观规划），科目四考文明驾驶（拒答非旅游问题）。全部通过，才能放心让用户上路用。
4.2.1 AI旅游项目的提示词设计概述
以下是对 AI 旅伴项目各节点提示词设计的概述，聚焦于“为什么这样设计、设计时怎么想、用了什么方法”，不包含具体提示词内容。
4.2.2提示词的设计原理
角色锚定
给模型一个明确的身份（如“意图提取员”“行程规划师”）。原理是：大模型在预训练中见过大量不同角色的对话，指定角色能让它调用对应语境下的语言风格和推理模式，减少跑偏。
格式约束
强制要求输出 JSON 或固定字段。原理是：模型生成自由度越高，越容易出现格式混乱。结构化约束相当于给它一个“填空模板”，大幅降低解析难度和出错率。
Few-shot 示例
给 2-3 个“输入→正确输出”的例子。原理是：大模型本质是 next token prediction，示例相当于隐式地教会它映射规则，比单纯用文字描述“你该怎么做”更直接、更稳定。
分步思考（Chain-of-Thought）
让模型先输出中间步骤（如预算估算：先算住宿、再算餐饮…再求和）。原理是：复杂推理任务中，一步到位容易出错，分解成小步骤能降低错误率，而且中间结果可解释、可调试。
负面约束
明确告诉模型“不要做 X”（如“不要编造信息”“不要输出天气”）。原理是：模型有时会自作聪明补充无关内容，明确禁止能有效切断这种倾向。
4.2.3 实际案例
以下是第二个节点，也就是查找用户信息是否遗漏的节点的提示词初版，后期可以根据效果继续调优提示词。
你是一个旅行规划助手的对话管理器。你的任务是检查用户已提供的旅行信息是否完整，并生成友好的追问。
必填字段：destination（目的地），duration_days（天数），travelers（人群）。
推荐字段：，budget（预算），preferences（偏好）。
规则：
1. 如果缺少必填字段，必须追问。一次最多问2个问题。
2. 如果只缺少推荐字段，可以追问（一次一个），也可以跳过（如果用户已多次忽略或明确拒绝）。
3. 用自然、友好的语气，不要使用技术术语。
4. 如果必填字段齐全且至少有一个推荐字段（或用户明确表示无更多需求），输出“信息完整，可以规划”。
5. 不要输出JSON、代码块或额外解释，只输出追问语句或确认语句。
6. 结合对话历史时，先更新用户已提供的字段，避免重复追问。
以下示例供参考：
输入：{“destination”: null, “duration_days”: 3} → 输出：您计划去哪个城市呢？
输入：{“destination”: “北京”, “duration_days”: null} → 输出：这次旅行打算玩几天？
输入：{“destination”: “上海”, “duration_days”: 2, “travelers”: null, “budget”: null} → 输出：方便告诉我您是独自旅行还是结伴？大概预算多少？
输入：{“destination”: “成都”, “duration_days”: 3, “travelers”: “solo”, “budget”: “economy”} → 输出：信息完整，可以规划。
注意事项：
– 不要重复问用户已经回答过的问题。
– 如果用户明确表示不想提供某个信息（如“预算无所谓”），则跳过该字段。
– 一次最多问2个问题，语气亲切。
因为没有自己部署模型，所以直接选择云服务器厂商提供的模型。市面上的模型服务厂商也比较多，可以做个选择。现在很多厂商都通过了测试赠送的token，前期测试评估这些token完全够用。
评估维度（加权打分，权重分可以根据自己的情况调整）：
评估步骤：
选3-4家候选（如阿里云、腾讯云、百度云、华为云）。
用统一测试集和简单提示词，批量调用各模型，计算自动化指标并抽样人工评分。
记录token消耗、延迟、错误率。
加权计算综合得分，确定主选和备选厂商。
目的：使用你的 初版提示词 + 主模型，在完整的测试集上评估每个节点的达标情况，定位瓶颈。
a、将主模型和初版提示词分别配置到 7 个节点（有些节点可共用模型，但 prompt 分开）
b、依次运行每个节点的专用测试集（如意图测试集、宏观测试集、微观测试集等）
c、用自动化评估脚本计算每个节点的核心指标（参照之前的指标设计表）
d、对未达标的节点（指标低于通过标准）进行 bad case 分析，根因分类（是提示词不足还是模型能力不足）
e、评估各个节点的问题，
最终经过单节点的评估，我们可以明确指出哪个节点、哪个指标不达标，以及可能的原因（提示词 vs 模型）。
目的：针对不达标的节点，通过修改提示词、更换模型、增加后处理等方式，使指标达到通过标准。
原则：
优先改提示词（成本最低，见效最快）。
其次换模型（如果同一节点尝试 3 轮提示词优化后仍不达标，考虑换更强的模型或专用模型）。
最后加后处理规则（模型无法完美解决的，用确定性代码兜底）。
详细操作步骤如下：
将优化后的各节点串联起来，模拟真实用户流程，确保整体业务达标，并准备上线。
可重复性原则
所有评估（测试集、脚本、模型版本、提示词版本）必须固化，确保任何人可以复现结果。
隔离原则
每个节点的评估独立进行，避免因上游节点错误导致下游指标虚低。端到端测试使用完整流程，但单节点评估使用标准化的输入（不依赖上游模型的输出，而是用标注好的输入直接喂给该节点）。
渐进原则
先离线，后在线；先小流量，后全量。每个改动（换模型、改提示词）必须先在离线测试集上验证，再上线小流量。
成本意识原则
记录每次评估的 token 消耗和 API 费用，防止评估成本失控。在离线评估阶段，可使用小模型（如蒸馏版本）跑中间指标，仅当需要准确结果时再用大模型。
人工复核原则
自动化指标不能完全替代人工判断。每个评估阶段结束后，必须抽样人工复核至少 20 条 bad case 和 10 条 good case。
回滚原则
始终保留上一个稳定版本的模型+提示词。线上出现问题时，能在 5 分钟内回滚。
原因分析
每个节点独立评估时，输入都是标准化、理想化的（例如节点5的输入是人工标注的完美宏观规划），但实际端到端中，上游节点的输出可能存在微小偏差（如意图提取漏了一个偏好），这些偏差在下游节点被放大，导致最终行程不合理。
节点之间缺少契约校验：下游节点假设上游输出一定符合某种格式或取值范围，但实际输出可能超出预期（如“预算”字段输出“中等”，但下游期望的是“标准水平”）。
解决方案：
原因分析
大模型本质是概率模型，即使 temperature=0，由于浮点运算的非确定性、批处理顺序、甚至硬件差异，输出仍可能微小波动。但在某些关键点上（如预算数字、景点名称），微小波动就会导致结果有时正确有时错误。
提示词中的约束不够强，模型在某些情况下会“自由发挥”。
解决方案
原因分析
初步评估时使用的测试集较短，未考虑实际对话中的多轮交互（每轮都会调用模型）。
解决方案
原因分析
云厂商会不定期升级模型版本（如从 qwen-max-2024-12 升级到 2025-03 版），新版本可能在推理风格、输出格式上变化，导致调优的提示词不兼容。
模型更新可能修复了一些问题，但引入新的 bug（例如对中文地名的识别变差）。
解决方案
本文由人人都是产品经理作者【markzou】，微信公众号：【markzou的笔记】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。