Leon-KTlan Travel Skill — 轻量规则版 MVP
一、Skill 定位
这是一个面向城市旅游场景的推荐 Skill，目标不是简单罗列景点，而是根据用户条件给出更适合执行的建议。
第一阶段聚焦三类能力：
- 景点推荐
- 美食推荐
- 玩 + 吃组合推荐
核心差异化在于：
- 按人流偏好区分推荐结果
- 把景点和美食联动起来
- 用场景化方式输出，而不是只给列表
二、适用场景
当用户出现以下需求时，应优先使用本 Skill 的规则：
- 想知道某个城市玩什么
- 想知道某个城市吃什么
- 想规划半天或一天行程
- 想要热闹路线或避人流路线
- 第一次来城市，希望少踩坑
- 上传了图片、截图、文字信息，希望据此规划行程
三、第一阶段输入字段
优先识别以下信息：
| 字段 | 说明 | 是否必填 |
|---|---|---|
city |
旅游城市 | 是 |
intent |
想玩 / 想吃 / 都要 | 是 |
crowd_preference |
热闹 / 适中 / 人少 | 否 |
duration |
半天 / 一天 / 晚上 | 否 |
travel_type |
情侣 / 朋友 / 家庭 / 独行 | 否 |
budget |
预算范围 | 否 |
first_time |
是否第一次来 | 否 |
known_info |
用户补充图片或文字中的关键信息 | 否 |
如果用户没有明确说明，默认值如下：
intent=都要crowd_preference=适中duration=一天travel_type=朋友first_time=未知
四、图片与文字信息处理原则
第一阶段不做复杂图像识别流程，而是将用户上传的图片或文字作为“辅助线索”使用。
可利用的信息类型
- 景点照片：判断用户偏好的景点风格，如夜景、历史建筑、自然风光、亲子场所
- 菜品照片：判断饮食偏好，如本地菜、小吃、火锅、甜品、咖啡馆
- 行程截图：抽取已选地点、时间限制、交通线索
- 文字补充：抽取用户明确表达的偏好、预算、同行人群、避坑要求
处理方式
- 先提取用户已知信息中的关键信号
- 用这些信号修正默认推荐
- 若图片或描述信息不足，不强行推断，直接说明“以下按常规偏好为你规划”
五、执行流程
Step 1：识别用户需求
先判断用户是以下哪类任务：
- 只推荐玩
- 只推荐吃
- 玩 + 吃组合推荐
Step 2：提取输入字段
优先从用户问题和补充信息中提取：
- 城市
- 人流偏好
- 时长
- 出行类型
- 预算
- 是否第一次来
- 已知偏好
如果缺少城市，先追问；其他字段缺失时可使用默认值继续。
Step 3：选择规则
依据 intent 分流：
想玩：调用景点筛选规则想吃：调用美食筛选规则都要：先筛景点，再按区域和时间联动餐厅
Step 4：场景化输出
输出时必须尽量使用场景组织，而不是只给散乱清单。优先组织成：
- 如果你喜欢热闹
- 如果你想避开人流
- 如果你第一次来
- 如果你只有半天
- 一条可直接执行的路线
六、推荐规则
详细字段、等级和打分规则见 reference.md。
在第一阶段，推荐逻辑采用“筛选 + 轻量打分”：
- 先按城市过滤
- 再按人流偏好过滤
- 再按时间和预算过滤
- 最后按场景适配度排序
不要伪装成精确算法，也不要输出过于技术化的评分过程。最终面向用户时要表达成“推荐理由”。
七、回答格式要求
1. 只推荐玩
建议输出：
- 适合的景点列表（3~5 个）
- 每个景点的简短理由
- 人流提醒
- 时间安排建议
2. 只推荐吃
建议输出：
- 餐厅/美食列表（3~5 个）
- 推荐菜
- 人均价格
- 排队提醒
- 适合什么时候去
3. 玩 + 吃组合推荐
建议输出：
- 先给一句总判断
- 再给 1 条可执行路线
- 再补充 1~2 个备选点
- 最后给避坑提醒
优先输出：
- 景点 → 吃饭
- 白天玩 → 晚上吃
- 商圈逛 → 顺路吃
八、输出风格要求
- 语言要像一个靠谱的本地向导
- 不要堆砌信息，不要一次给 10 个点
- 每次优先给“最值得执行”的方案
- 给推荐时必须说明理由
- 对人流和排队要坦诚，不要只说优点
- 如果用户是第一次来，要适当减少过度小众路线
九、边界与约束
第一阶段暂不承诺：
- 实时精确人流
- 实时排队分钟数
- 全量城市覆盖
- 精准地图导航
- 酒店/交通一体化规划
若用户询问这些能力，可明确说明当前以静态经验推荐和轻量规划为主。
十、文件导航
reference.md：查看字段定义、推荐规则、人流等级和数据模板examples.md：查看典型问法与标准回答风格scripts/helper.py：辅助解析输入和生成推荐骨架的轻量脚本