這次東京自由行，我做了一個有點不一樣的實驗：把行程規劃交給 AI 家庭管家「蝦蝦」協助。
一開始我以為，這件事大概就是把想去的景點丟給 AI，再請它排成八天七夜。實際做下去才發現，列出一份看起來豐富的行程很簡單；真正困難的是讓它符合交通、營業時間、預約、體力和家人喜好，而且到了東京真的走得動。
這篇不只是分享東京景點，而是整理我們怎麼把一段普通的聊天，逐步變成可執行的行程表，以及過程中踩到哪些 AI 規劃旅遊常見的坑。
第一個問題：使用者說的是願望，不是規格
人在討論旅行時，通常不會一次交出完整需求。我們比較可能陸續說：想逛某間店、不要去 Disney、某天有預約、希望不要走太累，或突然又想到一個想吃的東西。
如果 AI 只處理最後一句話，很容易每改一次就破壞前面的安排。因此，我們先把零散對話整理成幾種不同限制：
- 固定限制：旅遊日期、住宿位置、已購買的門票與預約時間。
- 明確排除：例如這次不安排 Disney，就不能過幾輪又把它當成推薦景點塞回來。
- 個人偏好：喜歡逛的店、可接受的步行量、購物與景點的優先順序。
- 彈性項目：有時間才去，下雨或太累可以刪除。
這其實很像軟體開發的需求管理。景點清單只是 backlog，真正要做的是標示優先級、相依性和不可違反的條件。
第二個問題：地圖上同一區，不代表動線真的順
AI 很容易用「區域名稱」排路線，例如把上野、谷中、根津視為同一區，然後判定它們可以順路走完。但旅途中真正影響體力的，往往是住宿處到車站的距離、轉乘次數、出口位置，以及下車後還要走多久。
我們曾檢討谷根千的安排。若只看觀光分類，從根津開始逛似乎合理；實際核對後，住宿處前往千代田線並不方便，而且根津站走到谷中銀座也不算近。改成從上野搭 JR 到日暮里，再步行進谷中銀座，才比較符合「少走一點」的目標。
這讓我得到一個很重要的原則：
行程最佳化的單位不能只有景點，必須包含「住宿地 → 車站 → 轉乘 → 出口 → 步行」。
後來每段行程都盡量補上主交通方式、轉乘提醒、預估步行時間，也會一併評估東京地鐵票券是否真的划算。因為一張票涵蓋很多路線，不代表為了使用它而多轉車就是省錢。
第三個問題：預約景點不是表格裡的一列，而是硬性約束
一般景點可以前後移動，但已預約的展覽或觀景台不行。它們比較像排程系統裡不能錯過的 deadline。
例如某天下午 5 點有 DQ 特展預約，前面的購物與散步就必須保留緩衝時間；如果逛店超時，應該縮短中間停留，而不是讓整天行程一起往後滑。另一天晚上 6 點半有晴空塔門票，下午的六本木行程便要設定明確離場時間，而不能只寫「傍晚前往押上」。
更大的教訓則來自 teamLab Planets。最初雖然把它排進行程，卻沒有把「票券是否已購買」當成獨立狀態確認。到了當天買不到票，加上豐洲市場週日休市，只好臨場改成千客萬來與台場。
這次調整不算失敗，最後也順利看到台場獨角獸鋼彈的燈光；但它清楚暴露一個問題：
「已排入行程」不等於「已確認可執行」。
所以需要預約的地點至少要有「尚未確認、已訂票、已確認時間」等狀態，並在出發前再次檢查，而不是只出現在行程名稱裡。
第四個問題：好看的答案，不一定是好用的交付物
聊天視窗適合討論，但不適合在旅行當天快速查資料。我們最後把行程整理到 Google Sheet，而且不是把大段文字直接貼進去，而是慢慢調整成實際好讀的格式：
- 同一天的日期合併顯示。
- 時段緊接在日期後面。
- 主交通方式獨立成欄。
- 保留區域、地點、地址、備註、費用與成行狀態。
- 使用換行、欄寬與置中，讓手機上也能快速掃到重點。
這裡也踩過一個很工程味的坑：試算表裡的空白列可能造成寫入列號偏移。因此，每次修改後不能只相信 API 回傳成功，還要重新讀取內容核對，並避免覆蓋原本已確認的行程。
換句話說，AI 行程規劃的最後一哩，不是生成文字，而是把內容寫進使用者真正會打開的工具，並驗證寫入結果。
幾個實際案例：同一句需求，講法不同會排出完全不同的行程
和龍蝦排行程時，我慢慢發現一件事：AI 不是不能排，而是它不知道我心裡哪一條條件最重要。如果我只丟景點名稱，它就只能猜；把取捨原則說清楚後，結果才會開始像「我的行程」。
案例一：不要只說「幫我排順路」
原本我可能會說：
幫我把谷中銀座、根津、上野排在同一天，要順路一點。
問題是「順路」有很多解釋。AI 可能理解成地圖上由南往北依序走，也可能單純把同區景點放一起，卻沒有計算從住宿地出發是否方便。
更有效的說法是：
我們從住宿處出發，希望少走路、少轉乘。請比較「根津開始」和「JR 日暮里開始」兩種走法，列出搭乘路線、轉乘次數、下車後步行時間，再推薦比較省力的方案。不要只因為景點在同一區就判定順路。
這種問法要求 AI 先比較方案，而不是直接生成一個看似合理的答案。最後我們也因此發現，從日暮里進谷中銀座，比特地轉進根津更符合當天需求。
案例二：加一個景點時，要說能不能犧牲原行程
旅行前很容易一直看到新景點，然後對 AI 說：「這個也幫我加進去。」如果沒有補充條件，AI 常會努力把它塞進空隙，結果每一站都只剩一點時間，交通也變得很趕。
更有效的說法是：
我想加入中野，但不要壓縮晚上 18:30 晴空塔的預約，也不要讓下午連續趕三個區域。請先判斷是否適合放進原行程；如果不適合，告訴我應該替換掉哪一站，不要硬塞。
關鍵是允許 AI 回答「放不下」。行程規劃不是俄羅斯方塊，空白也不是浪費；它可能是迷路、排隊、休息和臨時購物所需要的緩衝。
案例三：已預約和想去，必須用不同等級描述
「我想去晴空塔」與「我已買好 18:30 晴空塔門票」對排程的意義完全不同。前者可以移動或取消，後者是整天行程的錨點。
更有效的說法是：
7/27 晴空塔已購票，入場時間 18:30，這是不可移動行程。請從預計抵達時間往前倒推，包含找入口、排隊和至少 30 分鐘緩衝，告訴我六本木最晚幾點要離開。
這樣 AI 才會做「倒推排程」，而不是把兩個景點分別列在下午和晚上，卻沒有回答中間到底來不來得及。
案例四：票券狀態要明講，不能只說想去
teamLab Planets 的經驗最直接。把景點排進表格時，如果沒有說票還沒買，AI 很可能默認它是可執行的行程。
更有效的說法是：
teamLab Planets 想去但尚未購票。請標成「待確認」，查需要預約還是能現場買，並準備同區、不需要預約的雨天替代方案。在我確認買到票以前，不要把它當成固定行程。
這裡不是要 AI 保證一定有票，而是要求它把「願望」與「已完成準備」分開管理。若當天仍無票，也能快速切換到千客萬來或台場，而不是整段行程臨時重排。
案例五：告訴 AI 是誰要走這份行程
只說「步行不要太多」仍然很抽象。有人覺得一天兩萬步很正常，有人走一萬步就已經想回飯店躺平。
可以改成：
這是家庭旅行，請用「不趕路」為優先。連續步行超過 20 分鐘要提醒，每半天最多安排兩個主要區域；午餐保留 60～90 分鐘，晚上預約前至少留 30 分鐘緩衝。若行程超量，優先刪除購物以外的備選景點。
一旦把「累」轉成可檢查的規則，AI 才有辦法在新增景點時主動指出衝突。
② 比較交通方案，不要只看同一區。
③ 放不下就提出替換，不要硬塞。
④ 修改指定區段，保留已確認內容。
如何更有效地和龍蝦一起排行程
實際使用後，我覺得最有效的方式不是一次下完美指令，而是分階段協作。每一階段只解一種問題，會比叫 AI 一次產生八天完整行程可靠很多。
第一步：先建立旅行規則，不急著排每天
先告訴 AI 這趟旅行的基本資料：
- 日期、航班與住宿地區。
- 同行者及體力需求。
- 一定要去、想去、可有可無與明確不去的地點。
- 已購票或已預約的日期時間。
- 能接受的起床時間、步行量與每日景點密度。
- 購物、美食、拍照、親子或動漫等偏好的優先順序。
可以直接這樣說：
先不要排每日行程。請把下面資料整理成「固定限制、偏好、排除項目、待確認事項」四類；有矛盾或資訊不足先列問題，不要自行猜測。
這一步很重要，因為它可以先抓出「同一天兩張不同區域的票」或「想去的店只在某幾天營業」等衝突。
第二步：先分區，再排時間
不要一開始就要求精確到每半小時。先讓 AI 依真實交通把景點分成幾組，並說明為什麼適合同一天。
可用的說法是：
請依住宿處出發的交通便利性分組，不要只看地理距離。每組列出主要車站、適合搭配的景點、最麻煩的轉乘，以及大約需要半天還是一天。
看過分組後，人再決定哪一組放哪一天。這比讓 AI 一次決定所有日期更容易檢查，也比較不會牽一髮動全身。
第三步：用固定行程當錨點，往前後排
先放入門票、展覽、餐廳訂位與只能特定日期去的店。接著從這些錨點往前後補行程。
這一天的固定錨點是 17:00 DQ 特展。請倒推最晚出發時間，前一站安排可隨時離開的地點；15:30 後不要再加入需要排隊或至少停留一小時的景點。
這能避免 AI 把高不確定性的活動排在預約前面。逛街通常可以提早離開，主題展或熱門餐廳則不一定。
第四步：要求它揭露假設與風險
AI 給出行程後，不要只問「這樣可以嗎」，而要請它主動找碴：
請用挑錯模式檢查這一天：營業日、最後入場、是否需預約、交通轉乘、步行過長、用餐時間、行李與回飯店路線。把不確定資訊標出來源與查詢日期，不確定就說不確定。
這個步驟可以把漂亮的行程文案，轉成比較接近上線前測試的結果。尤其日本店家臨時休業、展覽預約制與市場休市，都不能只靠模型記憶判斷。
第五步：修改時說清楚「只改哪裡」
若只說「幫我調整一下」，AI 可能順手重排整天，連已確認的內容都改掉。比較安全的講法是：
只修改 7/28 下午，上午吉祥寺與晚餐保持不變。把中野加入後重新計算交通；若時間不足，谷中銀座改成備選。不要更動其他日期。
這就像修改程式時限制變更範圍，可以降低回歸錯誤，也讓人更容易比較調整前後差異。
第六步：要求輸出「主方案、刪減點、備案」
真正好用的行程不只一條路。每一天最好同時準備：
- 主方案：天氣與體力正常時照著走。
- 優先刪減點：落後 30～60 分鐘時先取消什麼。
- 雨天或無票備案：不要跨太遠，最好在同一區。
- 返回方案：太累時從哪個車站最方便回住宿處。
可以這樣要求：
請不要把備案混進主時間表。主方案照順序列出，另外標記「延誤 30 分鐘先刪哪站」和「下雨時換去哪裡」，讓我現場不用重新問一次。
第七步：出發前做一次整體凍結與核對
行程接近完成後，應該把已確認內容凍結，不再每天因為新推薦而大改。最後一次請 AI 檢查：
這是出發前定稿。請列出所有尚未購票、需要再次確認營業時間、交通仍有疑問的項目；不要再推薦新景點。確認完成後，把結果同步到行程表，並讀回核對是否寫入正確。
「不要再推薦新景點」其實很重要，否則 AI 永遠能再找到十個值得去的地方，行程也永遠不會完成。
一份可以直接複製使用的行程規劃指令
如果要快速開始，可以把下面這段交給 AI，再逐步補資料：
你是我的自由行規劃助手。先不要急著產生完整行程，也不要自行補上我沒說過的偏好。請先把資料整理成：固定限制、已預約／已購票、一定要去、想去、可刪除備選、明確不去、待確認事項。
排程時以實際交通與步行負擔為準，不要只因景點在同一區就視為順路。每一天先放不可移動的行程，再往前後安排；預約前保留至少 30 分鐘緩衝。新增景點時若時間不足，請提出替換方案，不要硬塞。
每段請列主要交通、轉乘、車站出口、預估步行和停留時間。需要預約、可能休館或資訊不確定的項目要明確標示，不可假設已經買到票。
每天提供主方案、優先刪減點、雨天／無票備案，以及太累時的返回方式。修改時只調整我指定的日期與區段，保留其他已確認內容。最後輸出前請做一次風險檢查，並列出仍需由我確認的事項。
這份指令不是用來一次得到完美答案，而是建立雙方共同遵守的規則。之後每次新增資料，龍蝦就能用同一套標準判斷，而不是從頭猜一次。
我們最後形成的規劃流程
經過幾輪修改後，整套流程大致變成：
- 收集想去的景點、餐廳、購物點與排除項目。
- 標記不可移動的預約與尚未購票的風險。
- 依住宿位置與實際交通，而不是只看行政區域來分組。
- 計算轉乘、出口與步行成本，保留休息及緩衝時間。
- 將次要景點設成可刪除的彈性選項。
- 寫入 Google Sheet，讀回核對格式與內容。
- 旅行途中依天氣、體力、營業狀態與票券即時調整。
從技術角度看，這比較接近「帶狀態的反覆規劃」，而不是一次性的文字生成。AI 不只要會推薦景點，還必須記住已確認的決策、辨識限制衝突，並在新資訊出現時只調整受影響的部分。
AI 做得好的地方，以及人仍然要把關的地方
AI 很適合做大量整理：把散落在對話裡的需求結構化、比較多種動線、補齊交通欄位，或在臨時取消景點時快速產生替代方案。它也很適合維護表格，減少人工反覆搬資料的時間。
但幾件事情仍不能完全放手：
- 營業日、臨時休館與最新票況要查官方來源。
- 地圖上的時間只是估算，還要考慮找路、等車與家人的步調。
- AI 可能忘記先前已排除的選項，因此關鍵決策要持續保存。
- 修改外部文件後必須讀回驗證，不能把「送出成功」當成「內容正確」。
最理想的分工不是讓 AI 決定所有事情，而是讓它負責高成本的整理與比較，人負責偏好、取捨和最後確認。
結語：旅行規劃其實是一個小型系統工程
這次經驗讓我覺得，AI 規劃自由行真正有趣的地方，不是它能在幾秒內列出十大景點，而是它能不能在持續變動的需求中，維護一份真的能執行的計畫。
一趟家庭旅行同時包含需求訪談、限制條件、路線最佳化、資料驗證、例外處理與介面設計。說穿了，根本就是一個小型系統工程，只是最後部署的不是程式，而是我們一家人在東京的一天。
而最實用的成果也不是一份排得滿滿的完美行程，而是一份知道什麼不能錯過、什麼可以臨時放掉，遇到變化仍然走得下去的計畫。
