其實不管是人工智慧還是工人智慧，使用者看到的界面是一樣的。我們在做使用者體驗研究的時候有Wizard of Oz 綠野仙蹤法，就是看起來像人工智慧，事實上是人在幫忙選。
至少在進行開發或測試的時候有人在假裝是人工智慧幫你選，這件事情會不會有幫助，如果沒有什麼幫助，這件事就保持在人工作就好。如果發現每次都有幫助的話我們就稍微投資一點時間或一些演算法下去，去把這部分自動化。只是探索，沒有要馬上變成 Machine learning，這樣可以嗎？就稍微往這方向想。
第4個是說，縣市政府根據區域差異都會有決策流程，包含地方的一些系統，泛指工人跟人工智慧的部分。
想問的是：API都已經接出來了，是否有可能Survey一下縣市政府的決策流程，我們可以提供什麼決策服務？接到當地的決策系統，或是他們沒有開發系統的能量，我們這邊可以幫忙一些東西。
這部分我們請國發會已經通過了OAS3，國際標準組織Linux Foundation下周會正式頒布這份文件，我們也會參與後續的幾個開發。以後地方政府特別要求你們寫某個端點出來的時候，建議用這個方式把它寫清楚，開了什麼明管出來。
這樣其他地方政府就可以說我要跟他一樣的，但是加這個地方或減這個地方，這樣子未來大家才能夠有一致的討論空間，不然每個縣市政府都有一大本說明書，這樣其實比較難討論。所以這個之後也參考國發會與工程會頒布的那個「共通性應用程式介面」的規格進行客製化，我覺得比較好。
那地方政府我上次去聯席會議，他們講的另一個非常有幫助的部分，之前常常需要登打好幾次，因為不同部會跟系統需要不同格式，如果這邊有辦法做一些基本的格式轉換，或是格式沒辦法轉換的話，可以一次填這兩個連集到你們系統，你們再去作分流。
其實每次災害發生的時候，他們只要稍微減少一點重複登打力氣，他們就多很多力氣做實際防救災工作。這部分我們也把他列進去，如果需要跨部會協商，甚至包含欄位這些的，就隨時跟我說。這個原則來做第4點。
當登打有派工的時候，這個事項的追蹤是否有在這個系統做呈現？
不用等一下，現在就可以做DEMO(笑)。
我聽起來葉副的意思不只是這個東西RWD，讓他在手機上開得起來。而是Fundamentally是把這個東西也做成一個API，然後在手機上接那個API，在手機上進行繪製。即使一開始明年五月在手機上繪製還是跟這個差不多也沒有關係，但是以後某一個點上面，他可以用不同的方式做繪製，可能可以跟某知名叫車軟體一樣（笑） 。
至少他留下這個可能性。不是說明年五月就跟某知名叫車軟體一樣，至少我們前後端分離，是用結構化資料方式呈現在手持裝置上，可能明年五月還是只能畫成表格，這是無所謂的，但是要保留未來變成某知名叫車軟體的可能性（笑）。
所以這部分我想就是API First，這是一件事情。另為一件事情是目前登打是像追蹤，從你們中心人員以及被派遣人員，我們叫做User Journey，如果能夠趁這次規劃的機會畫出來，事實上可以請廠商畫出來。目前有API，User Journey長得跟現在一樣沒關係，我們未來要做優化的時後，才有優化的起點，比較不會辦現有的系統綁住。大概是這樣。
那接下來就是教案的部分，剛剛也規劃了一些經費，這樣剛剛具體的建議是說，實際上請K-12的朋友們，或是中學生甚至小學生，來參加這個規劃，也包含目前民間對防救災感興趣的朋友，是不是也把他們邀進來。
接下來也是現有的，EMIC的功能，避難所的管理，是不是也是比照剛才知名叫車系統的規劃來做（笑）？
這個系統是今年才開始可以用？
親友協尋系統。
其實只要3G還有開設，其實這些朋友就會去社群媒體報平安。現在我們這個其實不是讓民眾自己填，是讓收容所的人填？
好，謝謝，很清楚。
就是說目前事實上收容處所是不是已經有一個管理的，包含人數，事實上主要就是人數。也包含你剛剛說的要地方政府配合，這部分已經有人配合了嗎？
意思是說，他們很難出一個專職的人來去問每一個進來的人身分證字號，然後把它輸入進去？
所以目前其實已經有人用手抄，好比說身分證字號，但那張紙目前沒有到任何地方。
但如果人數已經是統計性的，他已經不涉個資，他為什麼不能接過來？
事實上是有嗎？EMIC裡面有人數資料？我們剛剛看沒有看到的原因，只是因為他前端沒有介面而已？
這樣我有聽懂。
剛剛葉副講一個觀念，與其精度非常高，但花非常多時間，不如寧可就是多個precision都不怎麼樣，但加起來還是知道狀況。
不曉得說，在這個案子裡面有沒有可能加進一些規劃，另一個是說在這個案子外，有沒有地方政府在做類似的嘗試。
要我找衛福部開會不是問題啊！重點是他來的時候你要有proposal給他，還是要有一個看起來願意合作的，至少一個地方縣市，願意跨部門合作。也包含他們那邊的承包方，跟其他的局處，對不對？
我們就找衛福部來開會啊！這應該不是什麼問題。現在就是說你們之前已經有過一個初版Proposal，包含那個行李箱。
這個不一定要綁入特別預算，我們拿公務預算也是有空間。
而且如果是試做的話，他成本並不是非常高，所以想說你們被拿掉那一段看是不是先寄給我。我先把它看懂，然後技術上我覺得沒有太大問題的話，可能就另案跟衛福部討論這個部分，作為一個實驗性質的處理方法。這樣也比較沒有明年五月一定要交卷的壓力，這個我想對大家也都是個壓力，所以我們把它切開來做，但我想這個還是值得去做。
因為如果已知卡在這邊的話，現在技術成本已經非常低了，我們也不能像以前等技術成本更低來作為藉口，現在沒有這個藉口可以用了，從民間看起來明明可以做的為什麼不做。以前我們還可以說太貴了，現在說太貴了外面是不接受的。
接下來就是定期改版這件事情，剛剛也有講說，汛期前上版，到冬天的時候做壓力測試。這是不是固定的時間點；如果是固定的，就明確的寫進RFP裡面，就是固定每年兩次或三次可以動系統的時間。
下一個第9個是在講分析的功能，剛才我們講的一堆資料的接取，如果有第三方或是NCDR這邊，或是學界，做了一些分析，見了一些模型，在這邊是不是有一個開口可以讓各地方政府或是民眾，接取這些分析。
這其實就像國發會的開放資料平台，他有一區放資料活化應用。意思就是說拿開放資料做活化應用的話，可以跟國發會申請說，我要把活化應用登在其中的某一區，讓其他人也可以來看這個資料的活化應用。可能是一個很簡單的可以掛分析的地方，不曉得這邊有沒有覺得困難或是需要討論更清楚的部分。
基本上就是說如果已經是Open Data或OpenAPI 就直接掛載data.gov.tw上，如果有第三方拿這些去做應用的話，本來就有一個可以掛分析的地方。那我們未來在APP上或是網站上，怎麼樣在接近來，就看實際有活化應用出現的時候，我們來看這些分析服務可以放在介面的哪裡。
救災雲賡續計畫，是服務型智慧政府，還是智慧型服務政府，我從來沒有很記得。S2G裡面的計畫跟我們特別預算的關係，不曉得...
意思是說他們是獨立的，沒有什麼路徑相依性。
我的意思是說，沒有一定要這邊交前瞻那邊才能做，或是前瞻一定要做到什麼程度這邊才能做，是獨立的兩個計畫。機房的部分，不是用內政部的嗎？
意思是說也沒有白買，舊機器搬過去，還是是說其實有白買？
那就麻煩真的要整體規劃（笑）。不然就會出現賡續買的機器卻沒有用的情況。這部分沒有太大的問題。
剛剛講到運算平台，不管向上級中，放在東七或HGR。在公共民生物聯網總綱，只少要放一份應設在國網。這部分有任何困難或問題嗎？
我想這個就是資料跟API目錄做出來的話，用統一的方式介接。最大的問題是要測瞬間流量，這個我覺得也還好。國網硬碟幾乎是不用錢的（笑），即使用motion jpeg應該也是放得下－－這是為什麼當初到國網（的原因）。
接下來是，災防辦這邊提到的我們在分類裡面，對於防檢局的疫災，跟颱風地震無關的海難空難，這些態樣，是否在上面有呈現的方式？
簡單來講，希望未來有個自訂災害模組的功能。自訂災害模組應該是讓領域專家定義，而不是我們現在對疫災或其他來定義。能夠自訂災害模組的部分，是規劃在四年期對不對？是在前瞻裡面把它做完嗎？還是沒有？
就是我們能夠承諾的是四年之內把颱風跟地震，弄到颱風歸颱風，地震歸地震，其他災害模組要四年以後再來討論，意思是這樣嗎？這樣可以接受嗎（笑）？
這邊講的就是說，前後端分離。後端我們理解到不會一下子出現到海難空難模組，但前端是否有可能讓別的後端，用這個東西來當作呈現的方式。
我們這邊需要做的其實就是把我們相關部分前端的程式碼或是API的接口，提供給航港局或防檢局，告訴他們說如果要串接的話要準備怎麼樣格式的資料。除此之外，我們也沒有辦法，因為我們真的沒有那麼懂。
（即使）沒有辦法提供後端應該怎麼寫，但是至少後端只要改成這個資料格式，那我們前端可以幫忙呈現。這邊希望的是這樣？到這個程度應該還好吧？
這個就會變主要維護還是航港、防檢在維護，但是新聞暨這上來的時候還是可以在這邊看到最新的災害情況，這樣子。但是我們這邊就不再後端去做開設或是派工，這樣可以嗎？這個程度。
