Community程式設計與開發github.com

Hizir-SamuelP/deep-trip-planning

一個 Claude 技能,將一串地點轉換成真正可行的行程。

deep-trip-planning 是什麼?

「深度旅行攻略製作法」是一個專為 Claude 設計的 AI 技能,用於將原始的地點清單轉化為高度可行、考慮周全的旅行行程。它不僅僅是排列順序,而是透過一系列嚴謹的步驟,確保行程在現實世界中可執行。該技能支援 Claude 與其他 AI 代理平台,核心在於處理真實世界的複雜性,例如:強制性預訂、天氣依賴、交通效率、身體限制及預算限制。其工作流程從鎖定硬性限制(如已付款的住宿與交通)開始,接著透過量化風格偏好(如節奏、排隊容忍度、餐飲地位)來建立數值門檻,然後再進行逐日排程、驗證營業時間與假日、撰寫詳細交通指引、以及產出倒數計時清單。此技能的最大特色在於,它顯式地識別並處理了旅行規劃中容易出錯的隱藏成本與邊界情況,例如:跨時區調整、抵達日不安排硬性項目、以及連鎖延誤的緩衝機制。對於開發人員與進階用戶而言,此技能提供了一套可程式化、可複製的規劃邏輯,能大幅減少旅行前與旅行中的決策疲勞。

相容平台✓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 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件

深度旅行攻略製作法

工作流

按順序做。跳步的代價通常在後面某一天集中爆發。

前置分支:目的地未定

用戶只問「十月去哪玩」這類問題時,先不要跳進逐日排線。用第 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 — 輸出骨架、逐日/倒數計時模板、行李生成法、需填具體號碼的應急卡。開始成文時讀。

相關技能