八個分頁和一個試算表
晚上十一點，星期三。她已經花了三個小時規劃一趟十天的日本行。一個瀏覽器分頁開著 Google Flights。另一個是 Booking.com。第三個是 Google Sheet，她手動把飯店價格輸入 B 欄，在 C 欄把日圓換算成台幣。第四個分頁是大阪的天氣預報。第五個是一篇 2019 年的文章，標題叫「京都私房景點」— 裡面一半的餐廳已經關了。第六個是 Google Maps，在量寺廟之間的步行距離。第七個是一篇關於日本鐵路周遊券的文章，跟第八個分頁 — 另一篇關於日本鐵路周遊券的文章 — 互相矛盾。
她什麼都還沒訂。什麼都還沒決定。她把自己整理到癱瘓了。試算表有四十列，零個結論。
這就是現代旅行規劃的陷阱。資訊不是問題 — 資訊太多才是。問題在於整合。你需要一個系統，能把「我想四月去日本十天，我喜歡美食和寺廟，預算七萬五」變成一份具體的、逐日的計畫，上面有真正的數字。
那個系統存在。它跑在你的 terminal 裡。
你會做出什麼
一個旅行規劃器，運作方式如下：你告訴 AI 要去哪裡、什麼時候、在意什麼、預算多少。它建出一份結構化行程 — 逐日、有時間區塊、地點名稱、預估費用和備註。然後它查即時天氣預報、根據天氣調整計畫（第三天下雨？把戶外健行挪到第五天）、算出完整的預算明細、再根據天氣和行程產出一份打包清單。
輸出是一個 markdown 檔。你可以用任何文字編輯器讀、列印出來、commit 到 git repo、或在 Obsidian 裡打開。重點在這裡：因為它是一個檔案，不是一則聊天訊息，你可以編輯它。第四天改主意了？刪掉那幾行、打上你想要的、叫 AI 把後面的全部調整 — 預算、打包清單、行程表。
計畫是一份活的文件。不是一個你再也找不到的對話截圖。
你需要什麼：
- Claude Code 已安裝並驗證。還沒裝的話，Claude Code 第一個小時教學大約十分鐘搞定。
- Claude Pro 訂閱（$20 美元/月）或 Anthropic API key。
- 基本的 terminal 操作能力 — 會打
cd和ls就夠了。
不需要程式經驗。
第一步：建立旅行專案（2 分鐘）
打開 terminal。建一個旅行用的資料夾，在裡面啟動 Claude Code：
mkdir japan-april-2026 && cd japan-april-2026
claude
就這樣。你現在有一個 AI agent 跑在一個專屬於這趟旅行的資料夾裡。它建的所有東西都會放在這裡 — 行程、預算、打包清單、筆記。
第二步：用白話描述你的旅行（5 分鐘）
跟 AI 說話就像跟一個很懂旅行的朋友說話。具體說明你在意什麼。模糊的輸入產出模糊的計畫。具體的輸入產出你真的能照著走的計畫。
範例 prompt：
Plan a 10-day trip to Japan starting April 12, 2026.
Travelers: 2 adults.
Budget: $2,500 USD total (excluding flights).
Interests: food (especially ramen, sushi, street food), temples, walking neighborhoods, one day hike.
Base cities: Tokyo (4 nights), Kyoto (3 nights), Osaka (2 nights).
Constraints: no car rental. Public transit only. One rest day built in.
Create a file called itinerary.md with:
- Day-by-day schedule with morning/afternoon/evening blocks
- Specific restaurant and site recommendations with estimated costs in USD
- Daily cost estimate
- Running budget total
- Notes on transit between cities (which trains, rough cost, travel time)
按 Enter。AI 會在你的專案資料夾裡建出 itinerary.md。用任何文字編輯器或 markdown viewer 打開它。
你拿到的不是一個「東京必去 Top 10」清單。是一份結構化的行程表。Day 1，早上：抵達成田，搭 Skyliner 到上野（$25 美元），check in。下午：散步谷中，參觀根津神社。晚上：新宿風雲児拉麵（$12 美元/人）。當日小計：$120。累計：$2,500 中的 $120。
AI 根據它的訓練資料 — 餐廳推薦、寺廟開放時間、鐵路路線、一般價格。不是完美的。有些價格是估算。有些餐廳可能已經換了。但結構是扎實的，你現在有一個具體的東西可以驗證和修改，而不是八個分頁和一張空白的試算表。
第三步：加入即時天氣資料（5 分鐘）
沒有天氣的行程是在猜。你把戶外市集排在第六天，但第六天可能是颱風。AI 可以查即時天氣預報然後調整。
在同一個 Claude Code session 裡，打：
Check the weather forecast for Tokyo (April 12-15), Kyoto (April 16-18), and Osaka (April 19-21). Use the Open-Meteo API — it's free, no API key needed.
Then update itinerary.md:
- Add a weather summary line to each day (high/low temp, rain probability)
- If any day has >60% rain chance, swap outdoor activities with indoor alternatives
- Update the packing list section based on the actual forecast
AI 會寫一個腳本去打 Open-Meteo API — 免費、不需要 API key 的天氣 API — 拿到你確切日期和城市的預報，然後織進你的行程表裡。
現在第三天不只寫「參觀伏見稻荷」。它寫「參觀伏見稻荷 — 18°C，降雨機率 15%」或「預計降雨（72%）— 改為錦市場和漫畫博物館（室內替代方案）」。
這就是計畫和真正的計畫的差別。天氣資料把願望變成決策。
第四步：建立預算明細（5 分鐘）
行程表裡已經有每日預估費用了。現在讓它更嚴謹：
Create a file called budget.md with:
- A table: category (accommodation, food, transit, activities, misc) x day
- Row totals and column totals
- A buffer row (10% of total) for unexpected costs
- Currency note: show both USD and JPY at current exchange rate
- Flag any day where spending exceeds $300
Also update itinerary.md to reference budget.md for the detailed breakdown.
AI 建出一個乾淨的 markdown 表格。你一眼就能看到第二天是最貴的一天（$310 — 那頓壽司 omakase），第七天最便宜（$85 — 休息日）。Buffer 給你 $250 的彈性空間。
這份預算不是鎖死的。它是一個 markdown 檔。你改行程的時候，叫 AI 重算預算。數字跟著計畫走，不是反過來。
第五步：產出打包清單（3 分鐘）
打包清單不該是通用的。它應該反映你真正要做的事和真正的天氣。
Create packing-list.md based on:
- The weather forecast already in itinerary.md
- The activities planned (hiking day, temple visits, city walking)
- The trip duration (10 days)
- Two travelers
Organize by category: clothing, electronics, documents, toiletries, misc.
Add notes where relevant (e.g., "comfortable walking shoes — you're averaging 18,000 steps/day based on the itinerary").
AI 看了行程表，知道你有一天健行（Day 5 — 需要登山鞋）、多次寺廟參拜（不能穿無袖上衣）、十天的城市步行（預防水泡）、還有四月的關西天氣（洋蔥式穿搭、薄防水外套）。打包清單反映的是你這趟旅行的實際情況，不是一篇通用的「去日本要帶什麼」部落格文章。
第六步：迭代 — 活的文件（持續進行）
這裡就是 terminal 方式完勝瀏覽器分頁方式的地方。
你朋友傳訊息來：「大阪不去了，那幾天改去廣島。」在瀏覽器分頁的世界裡，你從頭開始。重新查飯店、重新查餐廳、重新查車次、重新算預算。最少一個小時。
在 terminal 裡：
I'm changing the plan. Replace Osaka (Days 8-9) with Hiroshima.
Update itinerary.md, budget.md, and packing-list.md.
Keep the same daily budget target.
Add the Hiroshima Peace Memorial and Miyajima Island.
Recalculate transit costs (shinkansen from Kyoto to Hiroshima instead of Kyoto to Osaka).
兩分鐘後，三個檔案全部更新。預算反映了不同的飯店價格和更長的車程。行程表有新的餐廳推薦。打包清單多了一條關於宮島步行量較大的備註。
計畫不脆弱。它不是一座紙牌屋，抽掉一張就全塌。它是一組互相連結的文件，AI 可以整體地讀取、理解、修改。
讓結果更好的技巧
明確說出你的旅行風格。「我喜歡美食」會產出通用結果。「我想要一頓高檔壽司 omakase 晚餐（$80-100 美元/人），其他時候吃街邊小吃和平價拉麵店（$8-15 美元/餐）」會產出有真正價格區間的計畫，花錢大餐和日常用餐之間的對比一目了然。
把限制條件寫清楚。「不搭計程車」、「晚上九點前要回飯店」、「一個人吃素」、「我們走得慢 — 每天上限一萬五千步」。限制條件讓計畫變得實際。沒有限制條件，你拿到的是一份野心勃勃的幻想，第二天就崩潰。
用追問來深入。 初始計畫建好之後：
For Day 4 (Kyoto temples), give me three alternative versions:
1. The popular route (Kinkaku-ji, Fushimi Inari, Arashiyama)
2. The quiet route (lesser-known temples, fewer tourists)
3. The food-focused route (temples near the best lunch spots)
現在你不只是在規劃。你在探索選項 — 像一個好的旅行顧問會做的那樣，只不過這個顧問凌晨兩點也能工作，而且永遠不會不耐煩。
把計畫 commit 到 git。 這聽起來像工程師才會做的事，但對任何人都實用：
git init
git add .
git commit -m "initial japan itinerary v1"
現在你計畫的每一個版本都被保存了。大阪改成廣島？新的 commit。想回到大阪版本？它還在那裡。旅行計畫的版本控制不是殺雞用牛刀 — 它跟保存舊草稿是一樣的事，只是更有條理。
這件事真正在講什麼
八個分頁加試算表的做法會失敗，因為它要求你當那個整合者。你從十個來源收集原始資料，然後在腦子裡組裝。這很難。很慢。而且結果很脆弱 — 改一個東西，整個心智模型就要重建。
Terminal 的做法把這件事反過來。AI 是整合者。你提供限制條件和偏好 — 只有你知道的那些東西。AI 負責組裝、計算、交叉比對，以及計畫改變時的重新排版。
你沒有把自己從規劃中移除。你移除的是苦工。選擇仍然是你的 — 去哪裡、吃什麼、花多少。試算表的算術和分頁的切換不是。
如果你從來沒用過 AI CLI 工具，給非工程師的 AI CLI 工具指南涵蓋了從打開 terminal 到完成第一個專案的所有步驟。先讀那篇，然後帶著一個目的地回來這裡。
你的下一趟旅行只隔幾個 prompt。而且這一次，規劃本身可能真的會是有趣的。