【2026飞猪AI旅行创新大赛】 #170

参赛项目名称

观途 · 跨城观演全程管家（上海 / 北京 / 成都 / 杭州 / 广州 五城）

团队 / 作者

oraguinal9

旅行场景与目标用户

场景：跨城观演——"为一场演出奔赴一座城"。用户先确定"我要看谁"，再解决哪一天去、怎么去、住哪片、散场怎么走、周边吃什么。
目标用户：愿意为一场演唱会/音乐节跨城出行的观演者（95 后、00 后为主），以及带老人小孩的家庭观众。

我做了什么

一句话：不做演出聚合平台，只做「单场次全程管家」——从您动身到散场回家，这一场的事都管。

核心功能：

1. 一句话编排：说一句"10月10号从南京带七十岁老人去听林忆莲，当天回得来吗"，智能体自己认人 → 按演出时间倒推车次 → 给出「当天往返 / 住一晚」两条路，并替用户做判断。
2. 按演出时间倒推车次：以开演前 90 分钟到场、散场点倒推，算出去程/末班车/次日返程，并标注"从容 / 有点紧 / 赶不上"。
3. 散场怎么走：每个场馆的散场动线、接驳、地铁限流与错峰提醒（真实高频痛点）。
4. 出处制度（核心创新）：每条行程项都标来源（官方口径／公开信息／经验／飞猪 POI／待核实），答不上来直说"我这儿没资料"，绝不编店名、时刻、方位。这是与"什么都能办"的作品最大的差别。
5. 问管家：只依据本页已核实资料作答。

百炼使用说明（必填）

• 百炼能力 / 模型：通义千问 qwen-plus（文本生成）
• 调用方式：百炼 API（DashScope OpenAI 兼容模式，/compatible-mode/v1/chat/completions）
• 使用环节与输入输出：运行时链路，两处。①「问管家」——把本场次已核实资料作为事实上下文，用户提问 → 依据资料作答（120–220 字）。②「一句话编排」——两段式：先用 qwen-plus 解析意图（temperature 0.1，输出 JSON：艺人/出发地/人数/是否当天回/日期），中间用本地逻辑匹配演出并调飞猪算车次，再第二次调用生成方案（temperature 0.6，200–320 字，替用户做判断）。输入＝结构化场次资料 + 车次实算结果；输出＝成文方案/回答。
• Skill 名称（如有）：无（未使用官方 skill，自行封装调用）
• 其他工具 / 技术栈：飞猪 flyai skill（search-train 火车 / search-hotel 酒店 / search-poi 门票玩乐 实时数据）；零依赖 Node.js 服务端；Nginx + Let's Encrypt HTTPS。

效果展示

项目链接与复现方式

在线 Demo（可直接体验）：https://concert.zbjh.top

• 复现步骤：打开 Demo → 顶部切换五城任一站 → 在「说一句，管家替你排一趟」输入"从南京带老人去看林忆莲怎么安排"看方案；或点「或者，自己挑一场」任一演出 → 看「三天怎么过」「散场怎么走」「出处一览」→ 在「从外地来·两种走法」填出发城市算来回 → 用「问管家」追问。
• GitHub 仓库：暂未开源（在线 Demo 即为完整可运行作品）。
• 说明：未提交任何 API Key / 密码。

踩坑记录（可选）

1. 飞猪风控 451/429：高频调用会整站被拦 → 预取落库 + 强缓存（6h）+ 陈旧缓存兜底 + 限流退避重试 + 无缓存时降级不崩（不用 502）。
2. 飞猪只有 CLI/Skill、无 HTTP 接口 → 自建一层 Node 转接。
3. 演出的日期/场馆/票价服务端拿不到（商品页有验证码）→ 只能人工精选 + 结构化录入（反而成了内容护城河）。
4. 飞猪没有"用车"命令 → "顺道去哪玩"改用 search-poi。
5. 火车数据有方向性差异（上海→南京常只返回换乘）→ 如实标注，不硬说直达。
6. AI 编不编取决于喂的资料厚不厚 → 先把资料喂厚，再加事实护栏。