# 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 面向的是真实世界约束（高德驾车耗时、景点营业时间窗、停留时长），这些问题只有精确的优化算法能解决。采用优化算法不是"更花哨的解法"，而是**在真实约束下唯一能给出可行解的方案**。