每次去音樂祭，我最頭痛的不是買不到票，而是 timetable 公布之後，到底要怎麼排才不會衝到。

想看的團同時開演、前一場還沒結束，下一場就開始了；有時候兩場時間接得上，舞台卻離超遠。最後只能邊看表演邊分心查手機算舞台趕場時間：

「這團要不要提早走？」
「另一團只來得及看後半場欸」
「兩個舞台走過去要多久？」
「這組比較想看，但另一組可能錯過這次就看不到了……」

行程還沒排好，腦袋已經累了 😂

所以今年參加 iThome 鐵人賽的 Build on Google AI，我想用 30 天做一個自己會用得上的音樂祭排團助手。

我想解決的問題

音樂祭通常會公布 timetable，有些官方 APP 也能讓你把想看的藝人加入行程。但撞團的時候，還是得自己決定要看哪一組、提早離開幾分鐘，或是乾脆放棄其中一場。

我想先讓使用者把藝人分成三種：

• ❤️ Must See：一定要看
• ⭐ Want to See：很想看，撞團時可以取捨
• 👀 Maybe：有空再看

再把舞台間的移動時間算進去，也讓使用者設定能不能接受只看半場、要不要留休息時間，以及不想一直跑場等條件，排出一份自己的行程。

第一個測試音樂祭，我想先選 FUJI ROCK。這種大型音樂祭，不能只看演出時間，還得知道從一個舞台走到另一個舞台要多久。我想知道，當一堆想看的團撞在一起時，我做的程式排出來的行程到底走不走得完。

AI 要負責哪一部分？

我不想為了參加 AI 題目，就什麼都丟給 AI 算，我也沒那麼多 token 可以花。兩場演出有沒有撞時間、從 A 舞台走到 B 舞台來不來得及，這些其實人腦就能處理。

比較值得測試的，其實是讓 Gemini 聽懂使用者用平常說話方式講的需求。比如：

我不想一直跑來跑去，但這團我死都要看完整場，其他團看一半沒關係。

使用者不用一項一項調整設定，先把需求講出來，再由系統依照這些條件排時間。

這是目前的想法，實際做起來會不會順利，我也不知道。

現場 Delay 怎麼辦？

這是最有可能發生的狀況，音樂祭現場可能遇到舞台 delay、人潮太多，或是暴雨造成表演暫停，原本排好的行程也會跟著受影響。

如果前面的排程功能做得出來，我再來研究看看能不能讓現場觀眾回報 delay，並依照最新狀況重排後面的行程。

Day 1：先把要做的事列清楚

v1 先處理這幾件事：

選擇音樂祭 → 選藝人 → 設定優先順序 → 加入舞台移動時間 → 處理撞團 → 產生個人行程。

接下來 30 天，我會學 Google AI、Firebase 這些工具，再一步一步把它做成可以操作的 prototype。我不是工程師，現在還不知道最後能做到什麼程度，所以打算先從 FUJI ROCK 的一天行程開始拆解。

明天要整理的是：排音樂祭行程時，除了 timetable，還有哪些條件得一起考慮？

下集待續