Community코딩 & 개발github.com

Hizir-SamuelP/deep-trip-planning

A Claude Skill that turns a list of places into an itinerary you can actually follow.

deep-trip-planning란 무엇인가요?

deep-trip-planning is a Claude Code agent skill that a Claude Skill that turns a list of places into an itinerary you can actually follow.

지원 대상Claude Code~Codex CLI~Cursor
npx skills add Hizir-SamuelP/deep-trip-planning

Installed? Explore more 코딩 & 개발 skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

즐겨 사용하는 AI에게 물어보기

이 에이전트 스킬이 미리 로드된 새 채팅을 엽니다.

문서

深度旅行攻略制作法

工作流

按顺序做。跳步的代价通常在后面某一天集中爆发。

前置分支:目的地未定

用户只问“十月去哪玩”这类问题时,先不要跳进逐日排线。用第 0.5 步的旅行风格,给 3 个候选目的地,并为每个写清具体取舍:当地季节和天气风险、预算量级、以用户护照为前提的签证核验难度、飞行时长/转机负担。不要直接断言签证结论,注明官方核验去处。用户选定目的地后,再进入第 0 步。

第 0 步:先钉死硬约束

已经付过钱、已经订好的东西是地基,不是变量。 先问清楚并写在最上面:

  • 已订的住宿(地址、入住/退房时间、取消截止日、终价)
  • 已订或已锁定的交通(航班时刻、到达/离开的具体钟点)
  • 同行人数、明确的必去项和明确不感兴趣的项
  • 有没有身体条件会改变选项(身高、腿脚、纹身、饮食禁忌、晕车、带小孩、带长辈)——这些常常悄悄决定了一大批选项能不能用

先运行 ${CLAUDE_SKILL_DIR}/scripts/trip_dates.py <国家/地区码> <开始日期> <结束日期>,不要心算星期几。 它会在网络时间核验通过后,给出每天的星期几、法定假日和连假。若脚本缺失、无法执行或时钟检查失败,停止日期相关规划:明确告诉用户日期未获核验,并要求安装完整 skill 目录(含 scripts/)或提供可核验的日历;绝不改用心算。 然后仍要检查:用户给的日期是不是已经过去了?星期几和他们提到的安排对不对得上("周末去某处"但那天其实是周三)?发现对不上就先问一句再动手——按错误年份做完一整份攻略,等于全部返工。

定"原点"。 每天的路线都从一个固定的出发点展开:城市行程里通常是住宿的最近车站,自驾行程里是住宿本身(外加停车条件),多城行程里每一段各有各的原点。原点定了,顺不顺就基本定了。

如果用户还没订住宿,先走"住宿决策"(见 references/lodging-decisions.md),因为后面所有动线都依赖它。

第 0.5 步:问清旅行风格,把偏好变成数字

这一步决定了后面所有"门槛"填什么值。跳过它,你就会把自己的默认偏好当成用户的偏好写进去。

同一趟行程,一对想吃遍米其林的情侣和一对只想逛店的朋友,做出来应该是两份完全不同的攻略。所以先问(或从用户已说的话里推断,推断不出来就直接问):

要问的它决定什么
节奏:一天想去几个点?愿不愿意早起?每天排几段、缓冲留多少
吃的地位:吃是这趟的主线,还是补给?正式餐安排几顿、要不要为餐厅预约绑住动线
排队容忍度:为一家很想去的店最多愿意排多久?排队上限那个数字
购物比重:会大买特买,还是随便看看?预算弹性项、行李额、退税流程要不要重点写
预算姿态:省钱优先、体验优先,还是不太敏感?花钱买时间的地方要不要花
确定性偏好:喜欢全订好,还是喜欢留白?预约多少、候选留几家

把答案落成具体数字写进攻略,不要留成形容词。"不爱排队"要变成"排队超过 X 分钟换下一家";"想吃点好的"要变成"安排 N 顿需要预约的正餐,其余走日常价位"。

用户没表态的项,用最省事的默认值并说明你的假设,让他们能一眼推翻。

第 1 步:定主日和换日规则

行程里总有几项受天气/季节支配(看山、看海、看红叶樱花、露天观景台、户外拍摄)。给每一项指定一个主日,同时写明哪几天可以和它对调。

主日优先给工作日,避开周末和当地连假。换日规则要写成可执行的句子,比如"11/16 晚做第一次决定,11/17 晚做最终决定,先处理车票改签",而不是"看天气决定"。

第 2 步:逐天排线,同时写好删减层级

每天产出:时间 → 动作的表格,加三样东西:

  1. 不回头路的顺序——在地图上验证,不要靠读地址想象。同一个区域一次走完。
  2. 必须保留 / 可全部删除——每天明确标出来。体力和天气一定会吃掉某些项,提前决定牺牲谁,比当天现想强。
  3. 天气预案——每天一条,按目的地的实际天气风险来(雨、雪、高温、大风、台风季)。不是"下雨就改室内",而是具体改成什么。

排线的隐藏成本:换乘时间、找出口的时间、进商场找店的时间、停车找车位的时间。每天留一段不分配的缓冲,长度按用户的节奏偏好定——赶行程的人留少些但要接受连锁延误的风险,慢游的人留多些。没有缓冲,第一次延误就会一路连锁到晚上。

抵达日和离境日不排硬项目。 抵达当天不安排不可取消的预约正餐、不倒推到分钟的黄金时段,也不把唯一必去项押在航班落地后;把行李、入境、延误和跨时区恢复留进缓冲。跨时区时,第一晚优先安排轻量步行、吃饭和早睡,后续两天再逐步回到正常节奏。离境日同理:按航司、机场和交通运营方的当次要求倒推出发,前面只放可随时删掉的活动,不把退税、还车、寄存或最后购物当作“顺路就能做”。

第 3 步:逐店核验(这一步最容易糊弄,也最值钱)

核"营业中"是没用的。要核的是"计划那天是星期几,那天营不营业,计划到店的钟点是否落在营业时间内"。

完整方法见 references/verification.md。必须做的最小集:

  • 每家店对照计划日期的星期几核营业时间和定休日
  • 查旅行期间的当地法定假日和连假——连假会同时抬高车站、景点、寄存柜、机场的拥挤度
  • 查旅行期间有没有制度变更生效(退税、签证、入境手续、票务规则)
  • 季节性项目的实际见顷/开放期是否覆盖你的日期,别默认"那个季节去就有"
  • 查当地有没有特殊日子落在你的行程里(祭典、纪念日、开学、大型会展)

第 4 步:交通逐段写死

从原点出发,把每天的去程和返程写死。公共交通写成"线路 + 换乘站 + 时长 + 票价",自驾写成"路线 + 车程 + 停车 + 收费"。

详见 references/transit-and-maps.md。通用原则是:每写完一段,问自己"一个不认路的人拿着这句话能不能走对"——"坐地铁很方便"不合格,"搭 X 线各停直达 Y 站,20 分钟、0 换乘,急行不停,上车前看车头显示"才合格。

票务的判断方式:默认按次付费,只在算得过账的那一天/那一段买通票,并把算式写给用户看。

第 5 步:地图落地

攻略停留在文档里就没完成。见 references/transit-and-maps.md 的"地图三层法"。核心是:自定义地图不能离线也不能导航,所以现场必须有另外两层配合。

第 6 步:预算

分成"本币直接支出"和"目的地货币支出"两块,最后合并。见 references/budget-and-customs.md

关键是识别出唯一没有上限的那一项(通常是购物),给它设三档,并建议用户定一个硬顶写在手机里。

第 7 步:倒计时表

把所有硬日期收进一张表,按时间排序:抢票开售日、免费取消截止日、预约窗口、登记办账号的截止、临期复核日。

特别留意撞在同一天的两件事——比如取消截止日和抢票日同一天。撞车要点出来。

第 8 步:交付前自检

逐条回看第 0 步的硬约束表和第 0.5 步定下的偏好数字,检查每一天是否违反。然后把「审查一份已有攻略时」的七条检查用在自己刚写完的产出上:内部矛盾、绕路、倒推、核验缺口、空档、风险日预案、期待错位。

在交付末尾留下本次自检结果。 不要默默检查;用户需要知道哪些硬约束已满足、哪些信息仍标作出发前复核。


贯穿全程的决策规则

这些规则的作用是把"到时候再看"变成"到时候按这条执行"

营业时间、定休日、价格与票价、车程与换乘次数、预约规则与开放时间、法定假日、季节窗口的实际预测期、无障碍与坡道台阶实情,必须有本次查证的来源。 训练数据里"记得"的值一律视为过期:这些字段随时会变,而模型不知道自己记的是哪一年。写不出来源就不要写那个数字;改写成"出发前 X 天复核",并注明去哪里复核。诚实的空缺比自信的错误有用。

下面提到的所有数字都是占位符,不是推荐值。 它们必须来自第 0.5 步问到的用户偏好。把别人的偏好当默认值写进攻略,是这个 skill 最容易犯的错。

具体的排队、候选、正餐、预约、倒推、花钱买时间、A/B 关闭门槛与信息源分工,见 references/decision-thresholds.md。开始排线或给出选择结论前必读;外移是为了减轻入口文件,不是放宽规则。


输出格式

默认输出一份 Markdown 攻略文档,除非用户指定别的格式。输出骨架、逐日模板、倒计时表、行李生成法和应急卡都在 assets/planning-templates.md;按行程重心增删,不要为了填模板而虚构信息。

常见调整:吃是主线时单开餐饮候选库;购物是主线时单开比价、退税和行李额度;自驾改写为路段、停车、加油、路况与离线导航;多城市按城市分段;带小孩或长辈时每天加最近休息点并整体放慢。

先给结论再给理由;每个建议带执行条件;不确定的地方标出复核时间和去处;修改已有攻略时直接改原文件,不另起平行文档。


审查一份已有攻略时

用户拿着现成行程来问"有没有问题"时,按这个顺序找,收益从高到低:

  1. 内部矛盾——同一天里两条时间对不上("14:30–15:00 走 A 街"和"14:40 必须到 B")
  2. 绕路——有更短的换乘方案却写了长的
  3. 倒推不成立——按写的出发时间根本到不了它自己定的黄金时段
  4. 核验缺口——没核星期几、没查连假、没查制度变更
  5. 空档——两个安排之间莫名空 50 分钟
  6. 风险日没有预案——特别是抵达日和离境日
  7. 期待错位——用户以为能看到的东西,实际季节/时间对不上
  8. 明显过载或自相矛盾——例如 10 天排 12 个城市。明确指出为何不可行,给具体替代方案,然后按用户的决定继续执行;只提示,不拦截、不要求再次确认,也不反复劝。

指出问题时给出替代方案,不要只说"这里有问题"。 并且直接改进原文档,而不是把问题列成清单让用户自己去改。


参考文件

需要时读,不用一次全读:

  • references/verification.md — 逐店核验、假日与连假、制度变更、季节窗口的期待管理、黄金时段倒推、社交平台的用法与边界。第 3 步必读。
  • references/transit-and-maps.md — 以原点展开的交通写法、公共交通的五个陷阱、自驾要点、通票算账、当地地图工具、地图三层法。第 4、5 步必读。
  • references/lodging-decisions.md — 含税终价横评、换房门槛、平台设施描述里的陷阱、位置与动线的关系。用户问"这家酒店好不好/该不该换"时读。
  • references/budget-and-customs.md — 预算结构、购物档位、海关免税额度、现金与支付、行李额。第 6 步读。
  • references/entry-and-health.md — 按国籍核验签证/电子许可、入境登记、健康、护照余量与保险。目的地确定后、订票前读;不得直接断言签证结论。
  • references/decision-thresholds.md — 排队/预约/倒推/换房等门槛,以及社交、官网、平台、地图的信息源分工。开始排线或比较选择前读。
  • assets/planning-templates.md — 输出骨架、逐日/倒计时模板、行李生成法、需填具体号码的应急卡。开始成文时读。

관련 스킬