ADR-004: 项目哲学——"旅行伴侣"而非"规划工具"

修改记录

日期	变更
2026-07-18	ADR-004++ 表格化，删除 §五（重复路线图），补充交叉引用

ADR-004++

状态	项	说明	验证
⏸	产品原则文档化	纳入 README 设计理念章节	未开始
⏸	面试话术对齐	整理 30s / 5min 两套叙事	未开始
⏸	后续 ADR 引用	后续 ADR 理由引用本 ADR 作为顶层依据	未开始

状态

✅ 已采纳

一、核心命题：用户不需要被决定，需要被陪伴

传统旅行规划工具的出发点是"替用户找到最优解"——最短路线、最多景点、最满安排。但旅行的乐趣恰恰来自"选我喜欢的、决定我想玩的"。用户真正需要的不是机器替自己做决定，而是机器帮自己省去规划中的体力活：翻攻略、核时间、算车程、查天气。把决策的乐趣留给用户，把繁琐的计算交给机器。

二、定位推演：从"管家"到"伴侣"的范式切换

维度	管家式工具	伴侣式产品
交互模式	被动执行：填表单 → 出结果	主动共创：聊需求 → 补信息 → 边聊边完善
核心目标	追求"最优解"	追求"适配解"，兼顾用户偏好、情绪和突发想法
算法角色	前台主角，用户直面算法参数	幕后英雄，算法隐性支撑，不喧宾夺主
覆盖范围	仅行前规划，输出完即结束	行前共创 + 行中兜底 + 行后复盘
信息方式	问什么答什么	主动关联天气、高铁、热点事件等上下文
用户感受	"这是一个工具"	"这是一个朋友"

三、三条产品铁律

铁律 1：Agent = 陪玩，不是决策者

Agent 不碰规划参数，不做宏观决策（改天数、换城市等）
参数调整通过 UI 完成——改数字比打字快
Agent 职责边界：解说规划结果、答疑、在前端已选参数范围内微调
遇到不知道的事直接说"这个我不确定"，不硬答

铁律 2：先有可靠方案，再有人情味解说

VNS+CA 双引擎保证规划质量——这是"可靠"的根基
LLM 在可靠结果上做自然语言"包装"，不编造事实
顺序不可逆：没有可靠的算法层，Agent 的解说就是空中楼阁

铁律 3：共创感 > 效率

不追求"一键生成完美方案"
设计目标是让用户觉得"这趟旅程是自己和 AI 一起聊出来的"
所以首页是对话而非表单，规划过程中可随时调整

四、行业趋势对齐

宏观背景

国家"十五五"推进"旅游强国"建设规划，智慧旅游是主线
2025 年国内出游 65.22 亿人次，旅游总花费 6.30 万亿元，均创历史新高
82.6% 青年认为 AI 在旅游中应用越来越普及，73.5% 相信 AI 旅行是未来方式

趋势映射

行业趋势	TravelPal 对应能力
高度个性化：碎片化、散客化、深度化	VNS+ 引擎按用户约束实时求解最优路径，非模板行程
AI 为核心驱动力	LLM Agent 层（解说 + 问答 + 轻量调整）
从"看景"到"入戏"：追求情感价值和沉浸感	陪伴式共创交互 + 主动信息补充
品质化、精细化	高德真实驾车矩阵 + 6 种聚类自动择优

五、追问记录（FAQ）

Q1：用户真的需要一个 AI 旅游伴侣吗？

旅游规划的核心痛点不是"不会规划"，而是"规划太累"——翻攻略、对时间、算路程、查天气，全是繁琐的体力活。现有产品都试图用算法"替用户决策"，而 TravelPal 把决策权留给用户，只在执行层面提供陪伴式支持。这不是一个更高效的规划工具，而是一个更有温度的旅行伴侣。

Q2：和"智旅云图"这类 RAG + LLM 方案有什么区别？

根本区别在设计理念。RAG + LLM 方案的本质是"信息检索 + 行程生成器"，规划质量完全依赖大模型的知识——LLM 编造路线是常见问题。TravelPal 的核心规划由 engine 层算法完成（真实驾车矩阵 + 精确时间窗约束），LLM Agent 只在可靠方案基础上做解说和答疑。算法兜底质量，LLM 提供体验。

Q3：双引擎是不是过度设计了？直接调 LLM 也能规划。

纯 LLM 生成的路线无法保证时间窗约束的可行性——它会编造到达时间、忽略交通耗时、虚构营业时间。TravelPal 面向的是真实世界约束（高德驾车耗时、景点营业时间窗、停留时长），这些问题只有精确的优化算法能解决。采用优化算法不是"更花哨的解法"，而是在真实约束下唯一能给出可行解的方案。