我們剛剛有提到第一個是大數據的部分，像我常用的，或者是我常申請的路線，或者是分析我的使用者習慣來進行AI的設計，然後進而可以把這一些數據集結起來，可以讓我們更瞭解這個登山的部分profile。
剛剛有提到不管是在制度面上，其實也有熱門程度的問題，像也有提到珍稀資源怎麼分配，這個是太熱門了，大家都想要去，相對於被分到的資源比較少，我們這樣子應該怎麼樣來規範，還有做系統的設計，讓這個使用者達到平衡，可能不是最好的，可能不能讓每一件事都如你所想，但是可以達到平衡跟公平的狀態，這個是我們可以想像的。
剛剛有講到的是，如果不用搶的就是抽籤的麻煩，但是不論什麼機制，可能都會有一體兩面的漏洞，或者是不方便的地方，剛剛提到的是在行程安排上就會變得比較不彈性，萬分之一的機會來抽到排雲山莊，然後好好享受玉山之旅，這個是非常困難的。
謝謝蔡先生的分享。
謝謝您的分享。
再來第二個部分是，假設我可以做確認的話，這樣是不是有更好的方式，然後來防堵這一件事的發生？第二個面向您剛剛提到的是？
剛剛有提到在機制防堵的部分，我們系統上是不是可以做一些機制，然後來看這個訊息是不是有被濫用。
謝謝你的分享。
在選擇路線跟山屋的部分，有沒有其他人要補充？
您剛剛有提到自己的經驗，登山要走起走路非常困難了，沒想到申請也要熬夜，把全隊的壓力放在自己的身上，這個瓶頸到底可以怎麼樣來解決，當然包含了剛剛講到的承載量，還有山屋的數量，還有生態可允許的承載量，我們應該要考慮進去，然後再把這個部分做最優化的使用者經驗。
像剛剛腦袋有一點沒有辦法⋯⋯
再來，您也有提到依照隊伍類型來分類，像GPX的部分也有依照資訊，像多數使用者會走樣版的路線。
我們統整一下，因為您剛剛講的資訊比較多，我們都會詳細記錄下來，我統整您剛剛所講到的東西，您剛剛第一個提到的是考慮到使用者不一樣的陽台應該要有的彈性，登山經驗非常豐富的山友希望可以上傳登山計畫書，要有一些彈性，但是有很多的山友其實是要走樣版路線，怎麼樣可以更簡易來申請，如果嘉明湖三、四天的路線都是一樣的，我需要一個個點去填嗎？這個也是我們自己考慮，可以讓使用者更快可以來申請的地方。
像剛剛第三點有提到的是需考慮到的手機、使用者介面，還有剛剛講到的商業團體使用的方式比較不一樣，在場有沒有商業隊伍，也就是常常使用商業隊伍的使用者可以來分享一下這個部分經驗？如果沒有的話，我們是不是可以請蔡先生來幫我們分享一下。
第二個提到的是，在路線的狀況是不是也可以做區別來提醒使用者這個路線可能有一些既存的狀況，像雪季、崩塌或者是一些不同的註記。
謝謝蔡大哥的分享，我統整一下，第一個是在時間上是不是可以做一些考慮，像選單有一些優先選項，有熱門的時間會有路線，像針對某幾條，類似像玉山、雪山的熱門路線可以放在前面一點。
這個部分還有什麼需要補充的嗎？
並不是路線彈性就找不到人，其實也有很多的，不管是在留守的折返跟撤退的訊息都可以補充上去，如果真的有什麼事發生的時候，搜救的隊伍來瞭解這個點在哪裡，這個也有呼應到我剛剛盤守留守的時候有一些制式化的限制，有一些隊伍在彈性的時候，希望填一些跟實際路線不符合的一些狀況，實際上我們不希望這一些事發生，也就是希望申請的資料是最真實的，萬一有什麼事發生的時候，希望可以有相對應的補助，這個是非常重要的，應該在這一個部分要考慮的。
再來，您最後提到的是？
在彈性規劃的部分，是不是可以以面取代點跟線，這個是非常好的考慮，像並沒有一個固定的路線才是探勘，並不知道那邊會發生什麼事，也就是彈性來做選擇，在介面申請或者是去想像應該怎麼樣申請的時候，其實是以面來思考的，這個也是非常好的建議。
希望在路線上可以做彈性，很多路線並不是像國家公園這麼線性。
要把討論拉回來在選擇路線跟山屋上，其實我在做訪談的時候，很多人都會在山屋的規則上來訴苦，又或者是在規則上有很多不同的方式，然後需要大家不管是遵守或者是在抽籤的等待上，如果針對那一些難處在做相對應的設計，讓使用者的經驗來做得更好，這個部分是不是可以請大家分享一下你們選擇路線的實務上，是不是有一些覺得比較難用或者是比較困擾的地方，然後這樣子也讓我們在系統設計上可以有相對應的解決方案。
謝謝你的分享，像地方有提到有關於領隊，或者是嚮導的責任歸屬，當然這個也是在登山安全裡面非常重要的面向，我們會把你的意見整理下來，會放到相對應的部分。
我們舉一個例子，也就是我們在訪談時得到的，在系統設計上是不是有一個防止假人頭的機制來設計，這樣可以部分解決陳大哥剛剛提到的一些問題。
但是那一塊的部分，在今天的系統設計上，我們可以把它拉回來看這樣子的問題，我們在系統裡面應該要怎麼樣設計一個機制來防堵這一個情況的發生，所以在制度完全被改進之前，我們在系統上也可以做多一層的防護。
謝謝陳秘書長的分享，我總結一下您提到的兩件事，您提到商業團體跟個人、一般的登山團體應該要做區隔，其實我們剛剛在做盤點的時候也有提到，這個部分也會針對制度上來做檢討。
我們在選擇路線跟山屋所盤點到的不管是問題，或者是大家的需求，也是想要邀請與會的各位，在申請的步驟有沒有自己自身的經驗遇到一些困難，或者是遇到一些很不合理的地方，然後可以跟我們分享一下你的經驗。
也有人提到比較細的問題，像我在申請警政署入山證申請的時候，搜尋不到要申請的路線，其實也有人說山屋是不是可以公布名單，讓我們可以有一些，不管是剛剛提到假人頭的防堵機制，還有人提到，像蔡大哥也有提到一些路線在熱門連假有高需求，也就是有提到時間的問題，下個禮拜是中秋連假了，平常才爆掉，平常不會有這麼多人，在系統設計裡面，是不是可以考慮熱門時段的因素來讓它有一些彈性。
另外，登山整合資訊網也應該要清楚告知需要審核登山的申請山域在哪裡，其實老實來說，我沒有像各位的經驗這麼豐富，這個是長年以來我的困擾，也就是某些山到底在哪裡，我在臺灣爬山可能超過10年了，如果以國外的山友來爬山的時候，要怎麼申請，歸他們來講是更加困難的，所以怎麼樣分清楚，這個也是非常重要的。
在路線的申請跟選擇山屋的部分，很多人提到不管是建議或者是需求，我們稍微盤點一下，像我們可以想像目前所有的系統都是分開來的，像雪壩、太魯閣，但是如果整併了以後會有非常多的路線，所以路線像現在拉拉式選單的話，會變成很長的選單，可以用友善的方式來做路線的選擇，我們是不是可以用關鍵字來搜尋路線？又或者是其實在選擇路線跟山屋的部分，也有人提到其實希望有其他的欄位來上傳登山的計畫，像剛剛有提到可能不是在路線之內的路線，希望有例外上傳。
也就是選擇路線及山屋，其實你在做事前規劃的時候，不管是難易度跟事前的安排，如果都符合之後，也許可以開始進行路線的申請。
這個部分在事前規劃上想要補充的？如果沒有的話，我們就再進展到下一個步驟，當然歡迎有想到一些需要補充的東西，可以隨時跟我說。
事前規劃要掌握這個行程之外，也要瞭解動態，就是您剛剛所說的有沒有缺水、路線有沒有崩塌，還有路線上及時狀況的更新，這個是不是在整合網站上在事前規劃上幫山友考慮到。
謝謝你的分享。我們剛剛有提到健行筆記跟高山嚮導的部分，不曉得有沒有山友願意分享帶朋友跟爬山來做事前規劃的經驗呢？
你帶到的是在相關規則會做釐清，不管是路線的掌握或者是從其他的網站來做瞭解，是這樣嗎？
你所搜尋到的資訊，大概是什麼樣的程度？你看完國家公園跟網站，你就可以掌握這個路線嗎？或者還會再做其他的比對？
你剛剛也有提到運用幾個不一樣的平台來做事前規劃，像剛剛有提到健行筆記，你剛剛也有提到政府的資訊網站，我想要釐清一下的是，可以簡述一下大概是哪幾個網站嗎？
我理解一下，你所說很重要的點還是時間，也就是在可允許的時間之內可以爬什麼樣的山，然後再來是難易度，也就是根據這個隊伍的程度，根據不同程度的路線來做不一樣行程。
謝謝你的分享，你也有提到是高山嚮導，所以會帶很多不一樣的人會去爬山，你在帶領他們的時候，前面可能所做的事前規劃。
就這個部分事前的規劃上，除了用這一種方式，還有沒有人可以分享一下你是用不一樣的邏輯，或者是用不一樣的方式來做你的行程規劃？
現在是依照林區或者是部會的管轄，因為是不符合使用者經驗的，這個會依照假期的天數來做規劃，這樣用假期的天數還有步道屬性的相似來做分類，這樣是不是有考慮？
你們講的第一個部分是臺灣的假期是大家都知道，大部分的人都是放那幾個假期，所以在那幾天之內，很多人想要爬山跟放假，接下來就會有一個中秋連假，有三天就有三天的路線，可不可以規劃第一個依照熱門時間，然後第二個才會是你剛剛所講的依照熱門程度，不管是剛剛講的錐麓古道或者是北插天山，這是一天的行程，然後做到同一個規劃裡面，你是這個意思嗎？
謝謝你的分享，我覺得分享非常好，我做一個統整，看是不是正確的資訊。
又或者有沒有可以規劃在事前規劃在自己的經驗上有任何的困難，或者是任何覺得很麻煩的地方，然後讓我們的系統可以針對這一個部分來做？
有沒有也有用過健行筆記，或者是網路平台，又或者是其他方式來做事前的規劃？
謝謝分享。
我自己知道的是，可能很多人會使用健行筆記，裡面有非常多完整的資料，是不是可以先就老王來跟我們分享一下你們目前平台所提供的資訊，怎麼樣讓山友可以有完整的事前規劃。
像剛剛盤點完了事前規劃的部分，我是不是可以邀請現場最近有爬山經驗的山友分享一下你們平常是怎麼樣做路線事前規劃，有一些不同的心得分享？或者有沒有一些參考？
再來第二個部步驟，我們到了選擇路線及山屋，我做好事前規劃的時候，我要看哪一條路線就不做選擇路線跟山屋，目前有人會提到的是，我是不是要用關鍵字來搜尋路線⋯⋯剛剛講到事前規劃、選擇路線跟山屋，還有一個審核、抽籤、繳費，入山及完成登山，這個是我們的步驟，我們針對步驟來開放大家現場討論，這樣子會針對每一個步驟來講，這樣會比較精確一點。
那個部分其實對於一個服務設計師來講，我也會想說這個步步是是可以精進，當然我要知道我所需要知道的東西，但是我真的有可能在那一頁，然後就完整閱讀嗎？我們是不是可以參考其他的做法，有一個更好的使用者經驗。
