昨天拿 FUJI ROCK 的 timetable 拆了一輪之後，我列出了 Must See、Want to See、Maybe、舞台移動時間、能不能只看半場、要不要休息、能不能提早離場……一堆排團時會考慮的條件。
今天原本要把這些東西整理成使用流程，結果才剛開始想介面，就發現一個問題：
如果每一個條件最後都變成一個設定，那這個工具可能會比我自己排 timetable 還麻煩。
例如打開網頁之後先問：
跑場意願：1～5
可以接受只看部分演出嗎？
最短可以接受看幾分鐘？
多久需要休息一次？
願意提前幾分鐘離開上一場？
一天最多想看幾組？
光想到這裡我就不想用了 😂
所以 Day 3 決定先不要想功能還能加什麼，而是反過來想：
使用者最少需要做哪些事情，才能排出自己的行程？
我先把第一版的流程壓到最簡單：
選擇音樂祭 → 選擇日期 → 選想看的藝人 → Must See / Want to See / Maybe → 告訴系統其他看團偏好 → 產生行程 → 處理撞團 → My Schedule
第一版會先以 FUJI ROCK 為主，所以實際開發時，「選擇音樂祭」這一步甚至可以先固定，不急著做成可以選一堆音樂祭的平台。
目前最重要的還是先讓一個音樂祭真的排得出來。
畫 User Flow 的時候，我開始重新看昨天列出的那些條件。
有些東西其實很適合直接用點的。
例如選完藝人之後，標記：
這種設定很直覺，根本不需要 AI。
但有些需求就開始麻煩了。
例如我真正想說的可能是：
我不想一直跑來跑去，Mitski 一定要看完整場，其他團如果撞到，看半場沒關係。
如果要把這句話拆成五六個設定，讓使用者自己一項一項選，我覺得又回到前面「填 20 個設定」的問題。
所以目前 Gemini 預計會在這邊發揮功用。
使用者照平常講話的方式告訴系統自己想怎麼看團，再讓 Gemini 把這些內容整理成排程可以使用的條件。
例如上面那句話，之後可能會變成：
{
"movement_tolerance": "low",
"full_set_required": ["MITSKI"],
"partial_set_allowed": true
}
這部分今天還沒有真的做，最後的資料格式也不一定長這樣。
但至少做到 Day 3，我終於比較清楚 Gemini 在這個工具裡到底要幹嘛：
不是拿來算兩場有沒有撞團，而是成為 user 肚子裡的蛔蟲
時間有沒有重疊、兩個舞台之間來不來得及移動，這些事情交給程式算就好。
User Flow 畫到「產生行程」之後，我原本很自然地想：
按下 Build My Schedule → 出現一張完整行程 → 完成。
這是最完美的懶人排行程法，但後來發現根本不可能這麼簡單。
昨天拿 FUJI ROCK 測試時，就找到 MASSIVE ATTACK 和 MITSKI 兩場撞在一起的例子。
如果我剛好把兩組都設成 Must See，系統不可能憑空變出一條兩邊都能完整看的行程。
這時候我也不想讓 AI 自己決定：
「根據你的喜好，我推薦你放棄 MITSKI。」
不准幫我決定這種事 😂
我比較希望它告訴我現在有哪些選擇。
例如完整看 MASSIVE ATTACK，接受只能看 MITSKI 後半場；或是提早離開 MASSIVE ATTACK，再移動到 WHITE STAGE 看 MITSKI。
每個方案少看到什麼、需要怎麼移動，系統可以幫我算。
最後要犧牲哪一團，還是我自己決定。
所以 User Flow 裡才會多出「處理撞團」這一步，而不是 AI 排完之後直接把結果當成答案。
前兩天都在想這個工具「還需要考慮什麼」，今天第一次開始反過來想：
哪些事情可以不要讓使用者處理？
如果最後使用這個工具之前，還得先花十分鐘設定自己的跑場邏輯，那我可能真的自己拿 timetable 畫一畫比較快。
所以目前 v1 的邏輯先縮成：
選我想看的團、告訴系統哪些不能錯過，其他能自動處理的就不要丟回來叫我設定。
真的遇到無法同時滿足的撞團，再把選擇權還給我。
另外昨天也收到 Build on Google AI 提供的 Google Cloud Skills Boost 和 Cloud Credit 資源。
不過我決定先忍住，不要因為免費 Credit 就開始亂花額度😂
目前還是照原本順序，先搞清楚產品到底需要什麼，真的需要用到哪個 Google Cloud 服務再來弄。
明天就要開始處理真正有點棘手的東西：
這些音樂祭、舞台、藝人和演出時間，到底要怎麼存？
下集待續
iThome鐵人賽
看影片追技術