寒水微痕1. 为什么我要做 RouteMind：被"行程规划"这件事逼出来的项目
事情得从一次真实的旅行经历说起。去年年底我计划去成都玩五天，打开各种旅游App翻了两个小时，收藏了四十多个攻略帖子，最后打开备忘录开始手写行程。写到第二天就崩溃了——景点之间的交通时间没算、博物馆周一闭馆没查、网红餐厅排队动辄两小时、天气预报说那天降温但我的行程里全是户外项目。
那个瞬间我意识到一件事：现在根本不缺信息，缺的是把信息整理成可执行方案的能力。 攻略帖是别人替你踩过坑的"静态存档"，但每个旅行者的出发地点、时间预算、体力偏好、兴趣侧重完全不同，照搬攻略等于穿别人的鞋走自己的路，不合脚的概率极高。
RouteMind的定位从一开始就很明确：做一个面向网页端的AI行程规划助手，用户输入出发地、目的地、天数、偏好，它直接输出一条带时间线、带交通衔接、带备选方案的完整行程。 不是给一堆景点让你自己挑，也不只是生成一张"打卡清单"，而是把"规划"这个动作本身接过去。
为什么一定要做网页端而不是小程序或者App？我有几个很实际的考量：
- 零安装成本。用户从搜索到进入页面到拿到行程，理想状态是三分钟以内。小程序还得打开微信搜一搜，App更是直接劝退绝大多数人。
- 分享和复制链路短。网页端无论是复制文本、导出PDF还是分享链接，都比小程序内转发要顺畅。做工具类产品，分享传播就是免费获客。
- AI能力的接入自由度更高。网页端可以更好地控制调用的上下文长度、流式输出的渲染方式，也能后续扩展插件机制——比如接入实时天气、火车余票查询这些外部数据源。
所以最终我敲定了这个技术方向：前端用轻量的React单页应用，后端接一个大模型API做意图解析和行程生成，配一个简单的偏好提取模块，行程结构用JSON Schema做强约束，确保大模型输出的格式稳定可解析。整套系统在浏览器里跑起来，就是一个"行程规划工作台"。
这个项目最核心的价值，不在"生成"那一秒，而在生成之前怎么理解用户需求，以及生成之后怎么把内容结构化组织成能直接用的行程单。下文我会把这套思路完整拆开讲。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心设计思路：行程规划不是"推荐景点"而是"求解约束问题"
很多想做类似工具的人，第一步就理解偏了。他们以为AI行程规划等于"输入目的地，AI推荐几个景点，排个序"，然后把串好的文本丢给用户就完事。这种实现方式做出来的东西，本质上还是个搜索结果的拼接器，谈不上"规划"。
我把行程规划重新定义成一个约束求解问题，底下这几类约束必须同时满足：
| 约束类型 | 具体说明 | 举例 |
|---|---|---|
| 时间约束 | 每天可用时段、就餐时段、景点营业时间 | 都江堰建议预留4小时，金沙遗址周二闭馆 |
| 地理约束 | 景点间通勤距离与交通耗时 | 宽窄巷子到武侯祠地铁约25分钟 |
| 偏好约束 | 用户对类型、节奏、消费层级的偏好 | 用户写明"不太想走断腿"则减少步行密度 |
| 体验约束 | 同类型景点避免扎堆，一天内不建议塞3个博物馆 | 上午文博、下午自然或商业街区，节奏有起伏 |
| 备选约束 | 每个时段最好有备选方案以应对天气变动 | 雨天替换为室内场馆 |
这个视角一旦建立，整个产品的技术架构就清楚了：不是让大模型"自由发挥"写一篇小作文，而是让大模型在一个明确的结构框架内做决策。 大模型负责的是知识调用和常识推理——比如知道"锦里适合晚上去""大熊猫繁育研究基地最好早上去"这类隐含经验，而结构化的框架负责保证输出能被后续处理和修正。
我在设计里给大模型设定了五个模块化的思考步骤，用一篇隐藏的System Prompt把事情讲明白：
- 解析用户意图：从自然语言里抽出目的地、天数、同行人结构（家庭/情侣/独行）、节奏偏好、预算范围。
- 建立景点候选池：基于目的地知识库，先圈定一批符合用户属性的候选点，这个阶段宁可多不要漏。
- 做时空预排布：把候选点按地理簇聚成"日区域块"，再按开放时间和交通时间做一次可行性检查。
- 生成行程骨架：输出每天的时间轴，早中晚三段，每段有主选和备选。
- 附加说明与提醒：每个点带上推荐理由、交通提示、门票参考、体感强度标签。
这套设计的核心收益，是让生成结果"可解释"。用户打开行程，能看到每个安排的逻辑来源，而不是一行冷冰冰的"9:00 去武侯祠"。可解释性直接决定了用户对这个工具的信赖度——这也是为什么我坚持在结果里嵌入"为什么这样安排"的原因，后面会专门讲。
3. 技术选型与架构落地：从Prompt模板到Json Schema强约束
3.1 前端与交互层：快、轻、不打扰
前端我选的是React 18 + Vite，没有上重型UI框架，用纯CSS加少量组件封装。页面结构就三块：
- 左侧是输入区，用户可以填目的地、天数、出发地、偏好标签（美食/人文/自然/亲子/购物）、节奏选项（悠闲/紧凑/适中）。
- 中间是对话式补全区，AI在生成前会先确认关键参数，比如"你是一个人还是带父母？"、"每天几点起床？"——这两问对后续行程的真实可用性影响极大。
- 右侧是实时行程预览区，采用流式渲染，AI每生成一个时间段，就实时渲染一个时间段，用户不用盯着空白页面干等。
交互层的核心原则是"不打扰但可干预"。生成结果出来之后，用户可以点击每个时间块单独调换景点，也可以拖动调整顺序，整个页面不会刷新。这一步实现了从"AI单方输出"到"人机协同修改"的转变——这也是我特别坚持的一点，行程规划这种事，AI给草稿，用户做决定，双方各有分工。
3.2 后端与大模型接入：独立服务层，不止是套壳API
后端我用的是Python FastAPI，单独起一个服务层，不把AI调用直接暴露给前端。服务层做三件事：会话状态管理、大模型调用与解析、行程结果的二次校验。
大模型这一环，我对比了多套方案，最终选择以高性价比的通用模型为主、复杂任务自动升级为更强模型的双通道策略。简单的偏好提取和参数确认走快速通道，完整的五天行程生成走精细通道。 这么做最直接的好处是成本可控，实测下来单次完整行程生成的大模型调用成本能控制在较低水平。
但光有大模型不够，我最看重的一层是输出校验。大模型偶尔会"一本正经地胡说八道"，比如输出一个上午8点出发下午5点逛完三个跨区景点的行程，纯物理上就不可能实现。所以我写了专门的校验函数：
- 检查每天的总时长是否超过18小时（超出则报警）
- 检查相邻景点的通勤时间是否被标记（缺失则标黄提示用户）
- 检查是否出现"同一景点在同一天出现两次"的异常
- 检查周一/周二闭馆类时间冲突（比如安排周二去金沙遗址，会被自动标记并给出替换建议）
这些校验规则看起来简单，但跑通之后非常提气。它相当于给大模型加了一层"常识护栏"，把明显不可行的方案在展示前就拦截掉。
3.3 行程结构的JSON Schema设计
这是全项目里我投入时间最多、收获也最大的一部分。如果大模型的输出结构不稳定，后面所有功能都无从谈起。 所以我花了一整天时间手工设计了一份行程的JSON Schema，并在System Prompt里明确要求模型严格按照这个结构输出。
简化后的结构长这样：
json复制{
"trip": {
"destination": "成都",
"total_days": 5,
"travelers": "二人情侣",
"pace": "适中"
},
"schedule": [
{
"day": 1,
"theme": "老城文化线",
"segments": [
{
"period": "morning",
"time_range": "09:00-12:00",
"place": "武侯祠",
"duration_minutes": 180,
"transport_from_previous": "酒店步行10分钟",
"why": "游客相对少的时段，适合认真逛",
"backup": "锦里（雨天也可走室内部分）",
"tags": ["人文", "历史"]
}
]
}
]
}
这套结构看着简单，但每个字段都有它的用意。比如 transport_from_previous 这个字段，就是为了强制模型在规划时意识到"上一个点怎么到下一个点"这个物理约束；backup 字段则是给每条安排留了后路——天气不好、临时闭馆、体力不支，都有可替换方案。
为了让模型稳定输出合法JSON，我在Prompt里给了两层保障：一是few-shot示例，粘贴了一份完整的样例输出；二是失败重试机制，解析失败时自动把错误信息反馈给模型让它重新生成。实测下来，稳定率从初期的60%出头爬到了95%以上，这一点经验对任何做AI结构化输出场景的朋友都适用。
4. 生成质量的调优实录：那些"看似合理实则离谱"的AI输出
项目做到第二轮demo演示的时候，问题集中暴露在生成质量上。不是格式问题，而是内容层面的"常识性错误"和"体验性错误"。
我挑几个经典案例说说，每个都代表一类必须处理的坑。
4.1 案例一：把"地理上顺路"误解为"时间上顺路"
AI生成Day 2行程的时候，给出了这样的排列：上午9点熊猫基地，中午12点返回市区吃火锅，下午2点去都江堰。单看每个点都没问题，但实际上熊猫基地在东北方向，都江堰在西北方向，一来一回等于把一天的时间全砸在通勤上，实际体验极差。
问题出在模型只是按"景点知名度"和"大致区域"做的排序，没有做真正的"地理聚类"和"路线优化"。我的解法是：引入一个简单的距离矩阵，把所有候选景点的经纬度算好，按地理簇分成若干片区，提示模型"每天尽量在同一个片区内活动，跨片区移动只允许在早晚各一次"。
改进之后，同一趟行程变成了：Day 2上午熊猫基地，下午回市区逛建设路和东郊记忆，晚上九眼桥，全部在东北片区加市中心范围内，通勤距离大幅缩短。这一改，整个行程的真实可行性上了一个台阶。
4.2 案例二：闭馆日完全没概念
有次测试生成"成都三日游"，AI把金沙遗址博物馆安排在了周二上午。现实情况是金沙遗址博物馆周一闭馆（多数场馆的惯例），周二正常开放。这种错误说大不大，但用户一旦按行程去了发现关门，对整个产品的信任直接归零。
我在这块做了两层处理：知识层面，在候选景点库里给每个点标注了开放时间的规则字段，并在Prompt里要求模型"生成前先核对当天的星期与场馆开放规则"；代码层面，校验模块按真实星期数据再查一遍，发现冲突就自动替换为备选室内景点。
这个案例给我一个很深的印象：大模型的常识库"广而不精"，你要么给知识库，要么给校验器，绝不能裸奔。
4.3 案例三：同质化景点扎堆，一天逛了三个"老街"
某次生成结果里，一天之内安排了锦里、宽窄巷子、文殊坊三个仿古商业街区。单独看每个都合理，叠在一起就非常疲劳——体验上毫无区分度，照片拍出来全是同一种风格。
我在提示词里加了一条"同质化约束"：同一天内相同主题/类型的景点不超过两个，且必须穿插不同类型的体验。再配合后续的"推荐理由"栏，让模型说明"为什么这个点跟上下两个点搭配不违和"。从那以后，生成行程的节奏起伏明显好看了，不再是一条平铺直叙的清单。
4.4 关于模型选择的实验记录
开发过程中我试过好几代模型的输出效果，列一个简单的对比供参考：
| 评估维度 | 轻量快速模型 | 旗舰推理模型 |
|---|---|---|
| 单次生成速度 | 明显更快 | 偏慢，需要流式渲染兜底 |
| 格式稳定性 | 中等，偶发缺字段 | 较稳定 |
| 常识/经验判断 | 偏弱，偶尔"一本正经胡说" | 明显更合理 |
| 成本 | 低 | 约为轻量模型数倍 |
| 适合角色 | 偏好提取、参数确认、简单问答 | 完整多日行程生成 |
最终我的方案是双通道并行：简单任务全走轻量模型，完整行程生成走旗舰模型并开启流式输出。这样既控制住了平均成本，又保住了核心生成质量。
5. 从Demo到可用：流式渲染、用户编辑、结果导出
5.1 流式渲染的落地方式
行程生成不像聊天问答，它是一次性输出几百行结构化数据。如果让用户盯着空白页面等上十几秒，体验就会大打折扣。所以我做了流式渲染：大模型每输出一个JSON片段，前端就解析并渲染一个时间块。
技术上其实不复杂，关键是对JSON做增量解析——需要将缓冲区的文本累积起来，尝试用宽松模式解析部分JSON，解析成功就渲染对应部分，解析失败就继续等待下一个数据块。这里有个小坑：大模型偶尔会输出残缺的JSON片段，我在渲染层做了防御性处理，解析失败绝不报错，只是静默等待补齐。
实测下来，用户从点击"生成行程"到看到第一个时间块出现，时间能压缩到3秒以内。这在心理感知上是巨大的差异——用户会觉得"这工具反应很快"，而不是"又要等好久"。
5.2 编辑与协同：用户不是看图的人，是改图的人
生成完成之后，我预留了每个时间块的"编辑/替换/删除/上移/下移"按钮。替换景点时，系统会从候选池中筛选同片区的同类型点并给出理由；下移操作会让后续所有时间块自动重新做一次时间衔接计算。
这里有一个值得说的交互设计：所有修改都会实时更新到整体行程数据模型上，并自动重新渲染整个页面。 用户修改任意一个节点，后续节点的交通提示和时段区间都会联动调整。这相当于把"AI生成一次性结论"变成了"AI提供可编辑数据底座"，用起来更像一个真正的生产工具。
导出功能我做了两条路：一是复制文本版行程单，适合直接发到好友聊天框里；二是导出本地JSON或打印模板，适合做成PDF存档。文本版的模板长这样：
code复制Day 1：老城文化线
上午 09:00-12:00 武侯祠（建议时长3小时，酒店步行10分钟到达）
下午 13:30-17:00 杜甫草堂（建议时长2.5小时，地铁3号线转4号线约30分钟）
晚上 18:30-21:00 九眼桥（酒吧街，夜景氛围好）
替代方案：雨天可改为四川博物院
这种格式的好处是任何地方都能直接粘贴使用，不依赖网页存活。
5.3 实时数据接入的规划
目前的版本还没有接实时天气和实时交通，但架构上已经预留了接口：每个生成的时间块可以挂外部数据源的标签，比如"地铁预计用时""当前温度""景点实时拥挤度"。后续只要接上地图服务或气象服务，就能在行程旁边自动刷新这些信息。
我在开发日志里给这一阶段写了一句备注：行程规划的终局不是生成一个静态安排，而是生成一个能感知环境变化、主动调整的动态计划。 现在生成的行程像一张地图，下一步要做的是让地图跟着路况动起来。
6. 踩坑记录：三个让"行程规划助手"差点翻车的细节
6.1 提示词被"景点清单"污染
早期版本有个很隐蔽的问题：模型生成结果时偏好堆砌景点数量，一天能塞六七个地方，每个时间块都压得很紧。究其原因，是训练数据里大量"XX景点打卡攻略"风格的内容给模型灌输了错误的概念——它以为"尽量多去景点"就是好行程。
解法是反其道而行之，在Prompt里明确写了一条"少即是多"原则：每天安排的景点上限为4个，核心体验点不超过2个，留有至少1小时自由缓冲时间。 同时给每个时间块增加了"why"字段，逼着模型说清楚"为什么值得这个时间投入"，大幅压缩了凑数景点出现的概率。
6.2 用户偏好被"平均化"
初次测试时，一个用户填了"偏好人文历史"，模型生成的行程里还是塞了40%的自然风光和商业街。原因是偏好提取阶段过于简单，只有一个标签被送进生成链路，其他都被忽略了。
后来我把偏好模块升级成"优先级排序"：用户选标签之后，还会额外回答一个"最不能放弃的体验是什么"。这个答案会被作为最高权重约束注入Prompt。效果直接体现在行程定性上——用户要"人文"，行程里就不会再莫名出现"游乐场半日游"这种内容。
6.3 JSON解析失败后的处理策略
大模型的JSON输出偶尔会因为一个多余的逗号或未转义引号导致整个解析失败。早期我的做法是直接报错重试，结果就是用户看到"生成失败"四个字，体验很糟。
改进后我做了三级兜底：
- 宽松解析：去掉多余逗号、截断尾部不完整对象等容错处理，先试一次。
- 局部截取：如果宽松解析仍失败，就尝试从原始字符串中截取最像JSON对象的片段再解析。
- 重试生成：前两级都失败，才走重试链路，并把错误样本反馈给模型纠正。
实测中，90%以上的解析失败在宽松解析这一级就被解决了，真正的重试率不到5%。
7. RouteMind下一步：记忆、插件与个性化模型微调
RouteMind开发到这一步，产品骨架已经完整。接下来我想往三个方向继续深入，也顺便聊聊我对这类工具演进路径的理解。
第一个方向是记忆能力。当前的会话是孤立的一次性对话，用户第二次来还得重新填一遍所有参数。我打算引入轻量的用户画像存储：把偏好标签、出行节奏、预算区间、常去城市沉淀下来，下次打开直接预填，AI也能基于历史规划做更有连续性的推荐。比如用户上次规划过"成都+美食+宽松节奏"，下次问重庆时，AI会自动沿用这套偏好来生成。
第二个方向是工具插件化。行程规划不应该是一个信息孤岛，它需要跟火车票查询、酒店比价、天气预警、地图导航这些工具协同。我正在设计一个插件接口：每个外部数据源都能注册成一个工具，AI在生成行程时按需调用对应工具，把实时数据嵌入到行程的每个节点里。等这一层做出来，行程就真正从"静态地图"升级成"实时驾驶舱"了。
第三个方向是小样本微调。现在主要靠Prompt工程约束大模型的输出质量，虽然效果基本达到了预期，但每次调整Prompt都要全量回归测试，成本不算低。后期如果有足够的真实用户行程数据沉淀，可以基于开源模型做轻量微调，把"行程规划"这个技能内化到模型权重里，让生成速度和质量都能再上一个台阶。
结合我自己这几个月开发RouteMind的体会，最深的感受是：做AI应用，真正的壁垒从来不在"接一个大模型API"这种表面动作，而在于围绕模型搭起的那套约束、校验、交互和反馈机制。 模型是发动机，但把发动机装进一台好开的车里，还需要变速器、悬挂和方向盘——这恰恰是应用层开发者最值得投入精力的地方。
最后再分享一个小技巧：如果你的项目也是让大模型输出结构化数据，务必在设计阶段就把JSON Schema定死，并且在开发环境里跑一遍"生成-解析-校验-修正"的闭环自动化测试。这个测试哪怕每天只跑二十条真实用例，也能在早期帮你拦截掉大量表述层面的不确定性。RouteMind能稳定走到今天，这套闭环测试是功不可没的。