Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →旅行/行程规划需求时使用:规划去某地旅行、X天X城、带老人孩子、自驾、假期安排等。产出逐日行程表、预算估算(经济/舒适/奢华三档)、交通住宿建议、景点美食清单。必须先问预算,预算未确认只输出问题清单;事实数据带来源和查询日期。
.claude/skills/sickn33-travel-planner/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-01 | ✗→✓ | ▲ Improved | 45% | 0% |
| case-03 | ✗→✓ | ▲ Improved | 28% | 0% |
| case-05 | ✗→✓ | ▲ Improved | 125% | 0% |
| case-07 | ✗→✓ | ▲ Improved | 120% | 0% |
| case-14 | ✗→✓ | ▲ Improved | 379% | 0% |
为用户的旅行需求生成一份完整、可执行、节奏合理的规划。输出一律用中文。 以下四个步骤按顺序执行,不得跳步、不得提前输出。
在开始任何联网查询或规划前,先收集齐以下信息。用户请求里没明确给出的,用一次提问问清(不要逐条追问,按顺序打包成 4-7 个问题):
目的地范围红线:行程范围严格等于用户指定的目的地(指定城市名即其行政市域,指定地区即该地区域)。不得擅自加入其他城市/区域——包括"顺路""高铁 1 小时内"的周边一日游,哪怕你认为单城天数偏长。若天数确实偏多:(1)优先放慢节奏、加深单城玩法——冷门点位、博物馆、街区深度游、留半天休息日;(2)周边一日游只能作为问题清单里的一道选择题先问用户("X天单城可能偏长,是否考虑加 1-2 天周边一日游?"),用户明确同意后才纳入主行程;未获同意则主行程保持单城。若用户明确要求"环线/深度游"等跨区域形态,当行程必须覆盖跨出指定区域的部分时,在输出开头向用户明确解释每个跨区点的原因,并给出严格限定在指定区域内的替代方案,让用户拍板,不得擅自决定。
用 WebSearch/WebFetch 联网核实以下内容,输出中标注信息来源与查询日期:
调研纪律:
先定优先级,再排天,然后逐条校验以下规则(R1-R13 全部必须满足,编号用于对照,不是可选项):
R1 优先级分级:用调研结果与目的地公认热度,把候选景点分为必去级(城市顶级地标——5A/国家级场馆/当地共识必打卡)、值得去级(有特色但可取舍)、可选级(锦上添花,如次级景点、小众点位)。必去级必须进主行程,绝不放备选;可选级只作补充,不能当行程主卖点。排序依据是热度数据与官方评级,不是模型自己的偏好。若必去级总量超出天数可承载(按 R3 体量、R4 独占一天计算排不下),不得静默删减:按热度与官方评级降序,把取舍选项一次写入问题清单让用户拍板(如"3 天排不下全部必去景点,以下二选一:…)",用户同意后才可移出主行程,并在自检表备注注明原因与依据。
R2 高商业化旅游街避雷:商业化严重、目标客群是游客的街区/美食街(特征:全国统一的小吃摊、网红店聚集、本地人不去),不得排为必去级,也不得作为美食推荐的主要来源。这类地点要么降级为"顺路可逛",要么写进避雷说明(标注"商业化严重、餐饮全国统一、坑多,逛可以、吃住别选这里");美食推荐以本地人常去为主——老字号、居民区、菜场周边小店。
R3 体量定负荷:判断"赶不赶"看体量而非个数。每天 2-3 个主景点(或 1 个大景点 + 周边);两个重量级(大型景区/国家级场馆/纪念地)不得同日,重量级只能配轻量级(街区/广场/商场)。自驾行程中,长途驾驶本身计入每日体量:单日车程 ≥4 小时视为一个重量级,"车程+游玩"合并评估当天负荷;两个长驱日之间必须隔开。
R4 顶流园区独占一天:一天都逛不完的顶流园区(如口碑顶流的超大型园区)必须独占一天,不得与任何其他主景点同日——宁可整体少排景点,也不压缩大园。唯一例外见 R5。
R5 收尾型并日(例外):主景点玩完后,同区域次一级景点的"收尾型"并日可接受(经实测验证的成熟玩法)——前提:次一级点只安排核心区段(如主园林 4-5h 后接次一级景区遗址区夕阳收尾 2-2.5h,非全园),并注明可替换为休整/商圈。不得做全园。
R6 时间预估带缓冲:每个景点先按纯浏览时间估算,再统一加 1-2 小时缓冲,覆盖入场/安检/排队、找路、吃饭、休息、拍照、离场等实际因素,避免按两套口径重复计入。热门大型园区直接按一整天到闭园估,绝不压缩。宁可排松,不可排满。
R7 不砍核心景点:5 天及以上的单城行程不得砍核心景点——必去级与热门值得去级都要保住;排不下就拆天、挪位、合并轻量级,而不是从行程里删景点。
R8 大型博物馆半天起步:国家级大馆(藏品数十万件的省级以上博物馆)至少 4-6 小时,标注建议时长前先确认场馆体量,不许把大馆塞进"上午 3 小时"。
R9 顶级商圈:中档及以上预算的行程应纳入顶级商场/商圈体验,放在晚间、雨天或休整日。以本地人日常消费为主的品质商圈为准;若该商圈同时属于 R2 所述高商业化游客街,降级为"顺路可逛",改为推荐商场内部高品质餐饮/展览作为替代;用户明确无购物偏好时不强制纳入。
R10 行程锚定住宿区域:先定住宿区域(按预算+全程动线),之后每一天都从"酒店出发"的视角估算交通衔接——住市中心枢纽则各日从容;住宿偏远时逐日重估通勤,不允许出现"从偏远酒店出发还要 1 小时才到第一站"的安排。全程建议住同一家酒店,避免中途搬行李;自驾环线无法同店连住时,以"行李随车、每晚只收拾次日小包"变通并注明。
R11 地理就近:同一天排同一区域,减少来回奔波。
R12 全局去重:所有天排完后整体检查一遍——同一街区/市集/夜游点不得在多个晚上重复出现(顺路路过与专门安排视为重复)。重复的合并或替换为同类替代(如换本地人常去的另一处),保证每天体验有差异,不把行程排成"同一批地方的循环"。
R13 主观体验类项目列为可选:实景演出、大型演出、游船/画舫夜游、主题乐园夜场、摩天轮等高单价、强主观喜好的项目,默认列入"可选加项"供用户拍板,不自动占主行程晚间位置。用户未明确偏好时,全行程此类晚间项目至多保留 1 个(选最经典的那个),其余进可选清单(注明价格与确认渠道)。必要交通性乘船(如登岛只能坐船)不算游船项目,正常排。
通用要求(适用于每一天):
输出前强制检查(不可跳过):正式撰写输出前,重读本文件"第三步"的 R1-R13 与文末"质量红线",逐条对照已排定的行程;发现不合规(体量失衡、必去级缺失或进了备选、重复安排、时长未带缓冲等)先在草稿中修正,再进入模板输出。输出完成后,按模板末尾的"规则自检表"逐条填写。
严格按照以下模板输出,顺序与层级不变,Markdown 格式:
> 规划日期 / 信息查询日期 / 人数与类型 / 预算档位
| 项目 | 经济 | 舒适 | 奢华 | 备注 | |---|---|---|---|---| | 往返大交通 | | | | | | 住宿(X晚) | | | | | | 餐饮 | | | | | | 门票/活动 | | | | | | 市内交通 | | | | 自驾含租车/油费/过路费/异地还车费 | | 合计 | | | | |
> 说明:预算表只输出用户所选档位对应的列(经济/舒适/奢华);哪些项为联网查询所得(注明来源与查询日期),哪些为估算(注明口径)。查询所得金额逐一标注,如"¥1200(航司官网 2026-08)"
把最容易变化、且规划时依赖查询结果的信息集中列出,提醒用户在预订/出发前核对官方渠道(每一项注明:查到什么、什么时候查的、去哪里确认):
按景点/事项分组列出本次规划引用的所有事实性数据:项目 → 查到值 → 来源 → 查询日期。仅列确有查询结果的数据;未查到的在逐日行程相应位置标"⚠️需自行确认"。
| 规则 | 判定 | 备注(具体证据,不得留空) | |---|---|---| | R1 优先级分级:必去级全部在主行程、绝不在备选 | | | | R2 高商业化旅游街:未排为必去、未作美食主来源 | | | | R3 体量:无两重量级同日,重量级只配轻量级;自驾单日车程≥4h 计入体量 | | | | R4 顶流园区独占一天(R5 收尾型例外除外) | | | | R5 收尾型并日:只游核心区段、注明可替换 | | | | R6 时长带缓冲:每段含排队/交通/拍照余量,顶流按整天 | | | | R7 5 天及以上单城:核心景点无删减 | | | | R8 大馆半天起步(4-6h) | | | | R9 中档及以上预算含品质商圈(高商业化游客街除外,无购物偏好不强制) | | | | R10 住宿锚定:每日从酒店出发算通勤 | | | | R11 地理就近:同日同区域 | | | | R12 全局去重:无同一街区/市集/夜游点多晚重复 | | | | R13 主观体验类(演出/游船/夜场/摩天轮):默认可选加项,晚间至多1个 | | | | 红线① 预算已确认后才规划(拒绝提供预算时注明按默认舒适档) | | | | 红线② 范围=指定目的地,无擅自加城市 | | | | 红线③ 实时数据可追溯(来源+查询日期),无编造 | | | | 红线④ 节奏合理:无塞满行程,每天安排人能走完 | | | | 红线⑤ 模板结构与输出语言(中文)固定不变 | | |
以下排版规则与质量红线为技能内部约束,仅供规划时执行,不得作为行程文档的一部分输出:
排版规则(与模板同等重要):
以上信息查询于 日期],票价与开放时间以官方渠道为准。需要调整节奏、预算或某一天安排,直接说。
用户:"帮我规划成都 3 天 2 晚,带父母,预算舒适档。"
技能:一次提问补齐剩余信息(出发地、具体日期、节奏偏好、是否忌口等),等待用户确认预算与答案;预算确认后联网调研,再按模板输出。输出片段:
# 成都 3天2夜行程规划
> 规划日期:2026-08-08 / 信息查询日期:2026-08-08 / 2 成人 2 老人 / 舒适档
## 📋 行程总览
- 3 天 2 夜,8 月下旬,晴热多雷阵雨(来源:气象部门 2026-08)
- D1 武侯祠—锦里老城区 / D2 熊猫基地一整天 / D3 杜甫草堂—宽窄巷子
## 🗓️ 逐日行程表
### Day 1(2026-08-21 周五)
- **上午**:武侯祠(约 2.5h 含缓冲,门票 50 元,来源:景区官网 2026-08)
- …用户:"帮我规划去西安玩。"
技能:只输出问题清单(目的地细节、日期天数、同行人、预算档位、偏好、限制),不给出任何行程草稿或示例。
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-01 | fail→pass | 29,444 | 11,813 | -60% | 1 | 1 | 0% | 4,351 | 6,327 | +45% | 0 | 0 | — |
case-08 | pass→pass | 25,318 | 25,088 | -1% | 1 | 1 | 0% | 3,740 | 7,244 | +94% | 0 | 0 | — |
case-09 | fail→fail | 20,941 | 38,001 | +81% | 1 | 1 | 0% | 3,276 | 9,487 | +190% | 0 | 0 | — |
case-10 | pass→fail | 21,412 | 57,357 | +168% | 1 | 1 | 0% | 3,245 | 7,271 | +124% | 0 | 0 | — |
case-11 | pass→fail | 23,700 | 18,086 | -24% | 1 | 1 | 0% | 3,550 | 6,386 | +80% | 0 | 0 | — |
case-12 | fail→fail | 23,682 | 18,216 | -23% | 1 | 1 | 0% | 3,523 | 8,190 | +132% | 0 | 0 | — |
case-13 | fail→fail | 24,505 | 24,164 | -1% | 1 | 1 | 0% | 3,929 | 7,764 | +98% | 0 | 0 | — |
case-02 | fail→fail | 40,225 | 51,242 | +27% | 1 | 1 | 0% | 6,004 | 13,367 | +123% | 0 | 0 | — |
case-03 | fail→pass | 33,098 | 8,386 | -75% | 1 | 1 | 0% | 4,951 | 6,359 | +28% | 0 | 0 | — |
case-04 | pass→fail | 27,772 | 14,961 | -46% | 1 | 1 | 0% | 4,121 | 7,470 | +81% | 0 | 0 | — |
case-05 | fail→pass | 23,332 | 13,327 | -43% | 1 | 1 | 0% | 3,187 | 7,185 | +125% | 0 | 0 | — |
case-06 | fail→fail | 25,860 | 18,020 | -30% | 1 | 1 | 0% | 3,944 | 7,864 | +99% | 0 | 0 | — |
case-07 | fail→pass | 25,665 | 24,737 | -4% | 1 | 1 | 0% | 4,146 | 9,110 | +120% | 0 | 0 | — |
case-14 | fail→pass | 17,316 | 44,993 | +160% | 1 | 1 | 0% | 2,580 | 12,361 | +379% | 0 | 0 | — |
case-15 | pass→pass | 28,672 | 58,326 | +103% | 1 | 1 | 0% | 4,350 | 13,338 | +207% | 0 | 0 | — |
case-16 | fail→fail | 28,326 | 16,484 | -42% | 1 | 1 | 0% | 4,035 | 7,826 | +94% | 0 | 0 | — |
case-17 | fail→fail | 30,067 | 18,954 | -37% | 1 | 1 | 0% | 4,762 | 6,673 | +40% | 0 | 0 | — |
case-18 | fail→fail | 26,806 | 13,761 | -49% | 1 | 1 | 0% | 4,147 | 7,324 | +77% | 0 | 0 | — |
case-19 | fail→fail | 24,261 | 14,386 | -41% | 1 | 1 | 0% | 3,377 | 7,383 | +119% | 0 | 0 | — |
case-20 | fail→pass | 26,123 | 48,509 | +86% | 1 | 1 | 0% | 3,840 | 13,329 | +247% | 0 | 0 | — |
case-21 | pass→pass | 9,899 | 11,439 | +16% | 1 | 1 | 0% | 1,568 | 6,811 | +334% | 0 | 0 | — |
case-22 | pass→pass | 17,347 | 22,216 | +28% | 1 | 1 | 0% | 2,446 | 8,227 | +236% | 0 | 0 | — |
case-23 | pass→pass | 16,463 | 24,045 | +46% | 1 | 1 | 0% | 2,522 | 8,871 | +252% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 23 cases were attempted, and 18 counted toward the lift figure. The other 5 produced results that are not comparable between the two arms, so they are excluded from the headline rather than averaged into it. The headline lift of +13 percentage points is the difference between those two pass rates over the 18 comparable cases. 5 cases got worse with the skill loaded, and they are included in that figure.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.