--- id: design-travel-route type: sop status: published version: 1 updated: 2026-11-06 token_estimate: 2220 --- # 如何设计一条旅行路线 > **用途**：把一次旅行的模糊想法，变成一条能照着走的路线。先问清三件事，再排顺序。 > > **覆盖**：城市游、周边短途、多日行程、带明确点位的定制。 > > **产出**：按天分段的路线，每天有主任务和取舍理由，附可替换项。 > > 拿到就能跑：缺信息时按第二、三步收敛，**不要跳过去直接排路线**。 --- ## 触发的变异问法 - 「帮我做一份成都三天的行程」 - 「下周去青岛，怎么安排」 - 「带老人和小孩去西安玩四天，路线怎么走」 - 「我只有两天，能去哪」 - 「帮我排个路线」 - 「第一次去日本，行程怎么定」 - 「这几个地方怎么连起来才顺路」 - 「周末周边有什么好去的」 - 「不想走回头路，怎么排」 --- ## 什么时候不要用这份文件 - **只要推荐地点，不要路线** —— 那是清单，不是行程。直接给候选即可，不要套路线结构。 - **每天去哪已经定好，只需要订票订房** —— 那是执行，不是设计。 - **要求实时信息**（今天是否闭馆、现在排队多久、临时交通管制）—— 这份文件不含实时数据源，硬答就是编。 - **行程已经结束，要写游记** —— 方向相反：游记是回顾，路线是预排。 --- ## 执行步骤 ### 第一步 · 先查输入里有什么 拿到需求后，不要立刻开始排。先做一张三格表： ``` 地方：□ 有 / □ 无 —— 城市或区域，具体到能定位 时间：□ 有 / □ 无 —— 几天，或具体日期区间 点位：□ 有 / □ 无 —— 景点、饭店、酒店，用户点名的 ``` 三条判定： - **有的，按用户给的办。** 不替换、不"顺手优化"、不加「其实更推荐」。用户点名要去的地方，是他已经决定了的事。 - **时间只有一个数（"三天"）也算有。** 不需要具体日期，除非行程跨节假日。 - **点位是最常见的空缺，也是最不该问的一项** —— 那是设计的空间，不是信息缺口。 **输出**：三格表填完，明确知道缺哪几项。 ### 第二步 · 缺什么问什么，一次只问一样 只问缺的那几项，**不要一口气抛出四个问题**。三个原则： 1. **一次只问一个**。问完再问下一个。 2. **给选项，不要开放题**。「想去哪个城市」很难答，「偏自然风光还是城市漫步」好答。 3. **说清为什么问**。「确认城市是为了不给你排错地方的路线」——让对方知道这不是走流程。 对应问法： - 缺地方 → 先问范围（省内 / 国内 / 出境），再问城市。 - 缺时间 → 问几天，或「周五晚上到、周日下午走」这种形态。 - 缺点位 → **不问**，转第四步。 **输出**：每一项缺失得到一个可执行答案，或者进入第三步。 ### 第三步 · 连续三轮问不到，就换方式 判据：**同一个问题问了三轮，对方仍然给不出可执行答案**。这时不要继续问——继续问只会让对方更烦，且答案质量不会提升。 换成给候选，两种方式： - **按地区引导**：给出 3–5 个城市或区域，每个配一句特征（「A 城：古城 + 小吃，走路能逛完」「B 城：海边，适合带孩子」）。 - **按景点引导**：给出该区域 3–5 个标志性点位作锚点，问「这几个里有没有想去的」。 对方从候选里挑一个，比从零描述容易得多。**换问法，不是重复问。** **输出**：拿到一个可定位的城市或区域。 ### 第四步 · 城市确认之前，不排路线 这一条是硬边界。 **确认之前**，最多只给方向性建议——一句到两句，例如「三天的话，市区两天加近郊一天比较稳」。**不查资料、不排日程、不列点位。** **确认之后**，才开始大量获取与整理信息：交通耗时、开放时间、区域分布、季节性。 理由：城市没定就查资料，查的是错的城市；排出来的路线看起来完整，用户可能直接拿去用，错得更彻底。**宁可只说不做，不要做错。** **输出**：一句方向性判断（确认前）／一份信息底稿（确认后）。 ### 第五步 · 排路线 拿到确认后的信息，按四条规则排： 1. **按天分段，每天一个主任务**。不要一天两个主题（上午古城、下午海岛），那通常意味着两地相距太远。 2. **同一天的点位在地理上成团**。宁可少去一个，不要横穿城市两次。 3. **顺序要有理由**。为什么先去这个再去那个——离得近、开门早、避开人流、日落时间。说不出理由的顺序就是随便排的。 4. **留出空白**。每天留 1–2 小时不安排，用来应付排队、走错路、临时起意。 **输出**：按天分段的路线草稿。 ### 第六步 · 交付，并标出可替换项 交付时给三样东西： - **路线本体**：按天分段，每天写清上午 / 下午 / 晚上。 - **取舍理由**：为什么这么排，以及**放弃了什么**（「没排 C 是因为它在城另一头，来回三小时」）。 - **可替换项**：每一两天给一个备选（下雨了换什么、累了砍哪个）。 第三样最容易被省掉，但它决定了这份路线能不能真用——实际旅行中总有一样会变。 **输出**：完整路线 + 理由 + 备选。 --- ## 输出规范 ### 人读 ``` 第 N 天 · 主任务 上午 / 下午 / 晚上：点位（含一句为什么） 交通：段与段之间怎么走、多久 备选：下雨 / 累了 / 关门了换什么 取舍说明：放弃了哪些，为什么 待你确认：两三处需要你定的（预算档位、是否自驾、能不能早起） ``` ### 机器读 ``` days: [{n, theme, slots: [{period, place, why}], transit, backup}] dropped: [{place, reason}] pending: [{question, options, affects}] confidence: 依据充分 / 部分推测 / 需实地核实 ``` `confidence` 不能省——哪些是查到的、哪些是按经验推的，必须分开。 ### 一句话版 `已排 N 天，主任务是 X；没排 Y 因为 Z；有两处等你定。` ⛔ 不要只说「给你排好了」，必须带出放弃了什么。 --- ## 常见错误 - **需求没说清就开始排路线** —— 最常见的失败。排出来的东西看着专业，城市可能都错了。 - **用户点名的点位被"优化"掉** —— 人家已经决定了，不需要你替他权衡。 - **一天塞四五个点** —— 地图上近，实际走不完；排得满不等于排得好。 - **只给点位不给顺序理由** —— 用户没法判断该不该信，也没法在变化时自己调整。 - **三轮问不出来还在问** —— 该换问法了，不是该再问一遍。 - **把「三天」当成三个整天** —— 到达日和离开日通常只有半天，这是最常见的低估。 --- ## 最后核对 2026-11-06。本文件不依赖具体工具与平台。与所执行系统的既定标准冲突时，以那个系统的标准为准。