trip-review

name	trip-review
description	旅行規劃第四步（審查）：自動審查行程表、找出錯誤並修正。觸發條件：(a) 使用者打 /trip-review、(b) 從 /trip 流程串接進來、(c) 使用者說以下**特定意圖自然語言**：『檢查行程』『審查行程』『找看看有沒有錯』『檢查一下行程』。**通用詞如『下一步』『繼續』『接下來』請走 /trip 讓 dispatcher 判斷進度，不要直接執行本 skill**。
user-invocable	true

/trip-review — 行程品質審查

使用與使用者相同的語言回覆（預設繁體中文）。自動審查行程表，找出錯誤並修正。不使用 agent，直接在主對話中完成。

前置檢查

0. 解析當前行程資料夾（永遠先做）

1. 用 Read 讀 ./current-trip，令 $TRIP = 資料夾名
2. 若 ./current-trip 不存在 / 為空 / 指向不存在的資料夾 → 告訴使用者先打 /trip
3. 在回應最開頭顯示一行「📍 目前在規劃 {$TRIP}」

1. 讀取檔案

1. 讀取根目錄 ./traveler-profile.md 取得旅行者畫像，確認行程輸出格式（若畫像中無「行程輸出格式」欄位，從 ./$TRIP/trip-meta.md 的協作設定讀取；兩者皆無則預設單一檔案模式）
2. 讀取 ./$TRIP/trip-meta.md 取得行程概要
3. 根據輸出格式讀取行程表：
   • 單一檔案模式：讀取 ./$TRIP/final-itinerary.md
   • 分日拆檔模式：讀取 ./$TRIP/overview.md 及所有 ./$TRIP/day-*.md
4. 如果行程表不存在，提醒使用者先執行 /trip-go

審查項目

逐項檢查以下 22 個項目（家庭旅行追加至 25 個）：

日期與時間（最容易出錯）

1. 星期是否正確 — 用日期推算星期幾，逐日核對。這是最常見的錯誤
2. 日出日落時間 — 根據目的地和日期驗證，確認攝影/活動時間合理
3. 營業時間衝突 — 排在某時段的景點/餐廳，該時段是否真的有營業。特別注意：
   • 週日和國定假日（很多商店、餐廳、超市會關門）
   • 博物館休館日（常見週一或週二）
   • 市場只有特定日子有（跳蚤市場、農夫市集）
4. 活動時間順序 — 是否有時間上不可能的排法（例如 10:00 在 A 地、10:15 在 B 地但交通要 40 分鐘）

交通

5. 門到門時間是否合理 — 驗證交通時間是否已包含走路、等車、找路 buffer。核對公式：走到車站 5-10 分 + 等車（平日 5 分 / 假日 10-15 分）+ 實際搭車 + 出站走路 5-10 分 + 找路 buffer（旅程前幾天 5 分、後幾天 3 分）。任何段跳過算都要標
6. 交通方式是否可行 — 確認推薦的交通工具在該時段有運行（深夜地鐵是否已停駛、假日班次是否減少）
7. 城際交通銜接 — 火車/巴士的發車時間和前一個活動的結束時間是否有足夠 buffer
8. MCT（航班轉機最短接駁時間） — 若行程含轉機，驗證轉機時間是否足夠：
   • 同航空聯運：國際轉國際 60-90 分鐘、國際轉國內 45-60 分鐘
   • 不同航空：至少 120 分鐘（行李要重新託運、可能要換航廈）
   • 需要入境再出境的轉機（例如美國 CBP）：至少 180 分鐘
   • 低於 MCT 的轉機標 🔴 嚴重，建議改班次

費用

9. 價格前後一致 — 同一個票價/交通費在不同地方提到時，數字是否一致
10. 每日花費加總 — 每天的費用明細加起來是否等於小計
11. 總預算 — 所有天的花費加起來是否在預算範圍內

行程合理性

12. 行程密度 — 根據使用者的體力和旅行風格，檢查每天排的活動量是否合理：
    • 暴走族：一天 5-6 個點 OK
    • 適中：一天 3-4 個點
    • 需要常休息 / 行動不便：一天 2-3 個點
    • 慢旅型：一天 2-3 個點 + 大量自由時間
    • 家庭帶小孩：一天 2-3 個點 + 午休/零食時間
13. 動線合理性 — 同一天的景點是否在地理上相近，有沒有不必要的折返
14. 時區對 Day 1 的影響 — 從畫像取「國籍」，算目的地與使用者本國的時差（國籍為中華民國則以台北 UTC+8 為基準；其他國籍以該國首都為基準）。時差 ≥ 4 小時時，Day 1 不應排重點景點、難訂餐廳或長時間步行。只留「抵達 → 住宿 → 附近簡單晚餐 → 早睡」的緩衝節奏。違反者標 🟡。同時考慮航班抵達時間：若班機下午才到，Day 1 剩餘時間不足也適用此規則
15. 時差 Jetlag 對前 2-3 天密度的影響 — 用第 14 項算出的時差，≥ 6 小時（歐美長程）的行程，不論使用者體力標示如何，前 2-3 天活動量應降到「需要常休息」等級（每天 2-3 個點）。違反者標 🟡 並建議調整

資訊交叉驗證（Source Triangulation）

16. 關鍵資訊二次確認 — 對行程中的關鍵事實用 WebSearch 交叉驗證，特別是：
    • 門票價格是否已調漲（尤其博物館、觀景台）
    • 營業時間是否因季節/裝修而變動
    • 交通路線是否有施工或改線
    • 餐廳是否仍在營業（小店倒閉率高）
    • 只驗證會直接影響行程成敗的項目，不需要每個都查。每次審查最多驗證 8 個關鍵項目，優先驗證：火車/巴士發車時間、博物館休館日、餐廳是否仍營業。
17. 研究報告間矛盾 — 讀取 ./$TRIP/research/ 中的 agent 報告，檢查不同報告間是否有矛盾資訊（例如 A 報告說某餐廳週一公休、B 報告卻排在週一去）。有矛盾時以最新的網路搜尋結果為準
18. 時效性資訊標記 — 檢查行程中是否有依賴時效性資訊的項目（特展結束日、季節限定活動、簽證政策變更等），在審查報告中特別標記「出發前請再確認」
19. Source citation 覆蓋率 — 讀取 ./$TRIP/research/research-checklist.md（若存在）和所有 agent 報告，檢查：
    • 行程表中的關鍵數字（票價、營業時間、距離、車資）後 100 字內是否有 URL
    • 低於 80% 覆蓋率時，列出缺來源的項目並標 🟡
    • 目標：讓業者或專業使用者事後能反查每個數字的依據

19a. 景點地理位置驗證 — 對行程中每一個景點 / 餐廳 / 活動，驗證它是否真的在目的地城市或行程涵蓋區域內： - 常見錯誤類型：同名景點在不同城市（例如「樂天世界塔」在首爾、不在釜山；「Disneyland」在加州/巴黎/東京/上海/香港都有；「中華街」橫濱跟神戶都有） - 驗證方法：對每個景點用 WebSearch 或讀 research 報告附的 Google Maps URL，確認 lat/lng 或行政區屬於目的地 - 抓到誤植 → 🔴 嚴重，自動移除該景點並建議在地替代品（從 research/agent 報告中找） - 找不到明確證據在目的地 → 🟡 標「⚠️ 地理位置待確認」

實用環境審查

20. 電壓與插座燒機風險 — 從畫像取「國籍」，查使用者本國電壓與插座（中華民國 110V A 型；其他國籍請用 WebSearch 確認）。再從研究報告或 WebSearch 確認目的地電壓：

    • 若與使用者本國電壓不同（例如台灣 110V vs 歐洲 220-230V），行程表必須明確提醒「電器務必確認支援目的地電壓，否則會燒掉」
    • 若插座類型不同（歐規 / 英規 / 澳規等），檢查行程表有沒有提醒攜帶轉接頭
    • 沒提醒者標 🟡，提醒應列在「出發前檢查清單」的 ⚠️ 級

21. 罷工 / 夏令時 / 國定假日 — 目的地近期是否有計畫性罷工、夏令時切換日、國定假日：

    • 歐洲：鐵路 / 航空工會罷工常見，查目的地近期罷工預告
    • 夏令時：3 月底 / 10 月底切換，影響航班時刻判讀
    • 國定假日：影響商店、景點、交通班次
    • 遇到衝突日標 🔴（若該日有重要行程）、其他標 ⚠️

家庭旅行專屬審查（旅伴為家庭帶小孩時追加）

22. 兒童友善設施 — 檢查每天的景點是否允許嬰兒車進入、是否有電梯/無障礙通道、附近是否有換尿布設施
23. 午休時段 — 3 歲以下幼兒建議每天保留 12:30-14:30 的午睡時段，檢查此時段是否被安排了需要移動的行程
24. 兒童票價正確性 — 交叉驗證行程中的兒童票是否套用了正確優惠（許多歐洲博物館對特定年齡以下免費）

嚴重程度分級

等級	定義	處理方式
🔴 嚴重	會直接導致行程失敗（趕不上車、景點沒開、時間衝突）	自動修正，或用 AskUserQuestion 問使用者選方案
🟡 中等	不影響行程但體驗會打折扣（動線折返、太密集、費用算錯）	自動修正並說明
🟢 輕微	格式問題、連結錯誤、小筆誤	自動修正

審查報告格式

## 行程審查結果

共檢查 22 個項目（家庭旅行 25 項），發現 N 個問題：

### 🔴 嚴重（N 個）
1. **問題描述** — 哪裡有錯
   → **修正方式**：怎麼改 / 需要使用者決定

### 🟡 中等（N 個）
1. **問題描述**
   → **已修正**：改了什麼

### 🟢 輕微（N 個）
1. **問題描述**
   → **已修正**

執行流程

1. 逐項跑完 22 個審查項目（家庭旅行 25 項）
2. 彙整所有問題，分級
3. 輕微和中等問題直接自動修正行程表（單一檔案改 ./$TRIP/final-itinerary.md，分日拆檔改對應的 ./$TRIP/day-N.md）
4. 嚴重問題如果有明確最佳解就自動修正；如果有多個可行方案，用 AskUserQuestion 讓使用者選
5. 修正完成後，顯示修改摘要（改了幾處、改了什麼）
6. 將審查報告存到 ./$TRIP/review.md

無問題時

如果全部通過，直接說「審查完成，22 項全部通過，沒有發現問題。」（家庭旅行則為 25 項）不要硬找問題。若之後使用者修改行程想再跑一次審查，直接重打 /trip-review 即可，可多次執行。

進度追蹤

用 TaskUpdate 更新任務狀態：

• 開始時：把「審查行程」設為 in_progress（activeForm: 「審查行程中」）

• 完成時：把「審查行程」設為 completed，告訴使用者「跟我說『下一步』就會繼續（或直接打 /trip-pack），建議出發前 1-2 週再跑」

  ⚠️ 不要在收尾推使用者用 /trip-pack 自己的特定意圖詞（例如「行前清單」），那會繞過 /trip 的進度偵測。讓使用者統一用「下一步」走 dispatcher 最安全。