HackMD
    • Sharing Link copied
    • /edit
    • View mode
      • Edit mode
      • View mode
      • Book mode
      • Slide mode
      Edit mode View mode Book mode Slide mode
    • Note Permission
    • Read
      • Only me
      • Signed-in users
      • Everyone
      Only me Signed-in users Everyone
    • Write
      • Only me
      • Signed-in users
      • Everyone
      Only me Signed-in users Everyone
    • More (Comment, Invitee)
    • Publishing
    • Commenting Enable
      Disabled Forbidden Owners Signed-in users Everyone
    • Permission
      • Forbidden
      • Owners
      • Signed-in users
      • Everyone
    • Invitee
    • No invitee
    • Options
    • Versions
    • Transfer ownership
    • Delete this note
    • Template
    • Save as template
    • Insert from template
    • Export
    • Google Drive Export to Google Drive
    • Gist
    • Import
    • Google Drive Import from Google Drive
    • Gist
    • Clipboard
    • Download
    • Markdown
    • HTML
    • Raw HTML
Menu Sharing Help
Menu
Options
Versions Transfer ownership Delete this note
Export
Google Drive Export to Google Drive Gist
Import
Google Drive Import from Google Drive Gist Clipboard
Download
Markdown HTML Raw HTML
Back
Sharing
Sharing Link copied
/edit
View mode
  • Edit mode
  • View mode
  • Book mode
  • Slide mode
Edit mode View mode Book mode Slide mode
Note Permission
Read
Only me
  • Only me
  • Signed-in users
  • Everyone
Only me Signed-in users Everyone
Write
Only me
  • Only me
  • Signed-in users
  • Everyone
Only me Signed-in users Everyone
More (Comment, Invitee)
Publishing
More (Comment, Invitee)
Commenting Enable
Disabled Forbidden Owners Signed-in users Everyone
Permission
Owners
  • Forbidden
  • Owners
  • Signed-in users
  • Everyone
Invitee
No invitee
   owned this note    owned this note      
Published Linked with
Like1 BookmarkBookmarked
Subscribed
  • Any changes
    Be notified of any changes
  • Mention me
    Be notified of mention me
  • Unsubscribe
Subscribe
## "花蓮救災爭議之後:未來台灣救災程序與資訊流通如何改進?——公民意見徵集" 意見綜整報告(2026/03/15版) 資料來源:https://pol.is/report/r89seayfre3aha6vybrav 分析工具:https://make.vtaiwan.tw 原始Polis意見徵集: https://pol.is/4fxd6ehrfj (註:本Polis意見調查為匿名參與者志願填寫,並非隨機抽樣,亦不代表特定族群) ## 簡介 本報告總結了公眾意見的結果,包含: * __37 個意見__ * __748 個投票__ * 9 個主題 * 22 個子主題 所有投票者都是匿名的。 ## 概述 以下是對話中討論主題的高層次概述,以及每個主題下分類的意見百分比。請注意,當意見屬於多個主題時,百分比總和可能超過 100%。 * **政府與地方官員的責任與追究 (27%):** 中央未及時下達撤離指令、地方未執行撤離,民眾要求縣長道歉並追究官員責任,同時呼籲成立獨立調查委員會檢視救災過程。 * **資訊流通、平台與技術標準化 (24%):** 主張政府統一後端資料庫、制定標準化資料格式與 API,建置開放原始碼、可重複使用的災害資訊平台,整合志工、物資與即時地圖,同時落實個資保護與持續迭代。 * **資訊透明度與媒體角色 (14%):** 要求對散布錯誤訊息的媒體處以罰款,批評封閉的 Line 群組造成資訊不透明,提議制定災害期間媒體公約,並肯定公民記者的平衡報導功能。 * **民間參與與志工資源協調 (14%):** 建議開發具 GPS 定位的手機介面(類似 YouBike App)以即時配對志工需求與資源,並建立專業志工平台系統化媒合不同組織的人力。 * **災後補助與救助金發放原則 (5%):** 討論救助金分配的公平原則與透明機制,強調需明確標準以確保受災戶獲得適當補助。 * **水利與災害專業監測檢討 (5%):** 呼籲檢討水利設施與專業災害監測系統,提升早期警戒與災害應變效能。 * **公共參與與防災計畫前期討論 (5%):** 建議在防災計畫制定初期即納入社區與公眾意見,增進防災準備的廣泛參與與認同。 * **撤離指令與救災執行 (3%):** 強調需及時發布撤離指令並確保執行效率,以減少災害損失。 * **其他 (3%):** 收錄其他零散意見,涵蓋未列入上述主題的額外建議與關切。 ## 前 5 個最常討論的子主題 討論中出現了 22 個子主題。這 5 個子主題收到的意見最多。 ### 1. 其他 (5 個陳述) 主要主題包括: - 資訊透明 - 媒體規範 - 公民記者 - 錯誤罰款 - 救災優先 ### 2. 資料格式與 API 互通標準 (4 個陳述) 主要主題包括: - 資訊流通 - API 標準 - 平台重建 - 政府統一後端 - 資料格式與開放 ### 3. 開放原始碼平台與持續迭代 (3 個陳述) 主要主題包括: - 開放原始碼平台 - 資訊即時地圖 - 個資保護 - 持續迭代改良 - 跨單位協作 ### 4. 中央政府撤離指令的責任與追究 (2 個陳述) 主要主題包括: - 撤離指令延遲 - 政府全權負責 - 資訊流通不足 - 民眾安全保障 - 救災制度改進 ### 5. 地方政府執行撤離與救災的責任 (2 個陳述) 主要主題包括: - 撤離執行責任 - 縣市首長負責 - 民選官員責任 - 救災程序改進 - 資訊流通改善 ## 主題 從提交的意見中,識別出 9 個高層次主題,以及 22 個子主題。基於投票模式 已識別出共同點以及意見分歧 ,並在下面描述。 ### 政府與地方官員的責任與追究 (10 個意見) 此主題包含 5 個子主題,總共包含 10 個意見。 #### 中央政府撤離指令的責任與追究 (2 個意見) 此子主題與其他子主題相比具有 低度一致。 主要主題包括: * **政府責任**:陳述指出中央政府應對未及時下達撤離命令負責。 * **撤離命令時效**:陳述強調缺乏及時的撤離指示是問題所在。 * **不可推卸的義務**:陳述認為政府對此類救災指令負有不可推卸的責任。 共同點: 沒有意見達到被視為共同點的必要門檻(至少需要 20 個投票,且至少需要 70% 的同意率)。 意見分歧: 沒有意見達到被視為顯著意見分歧的必要門檻(至少需要 20 個投票,且群組間同意率差異超過 40%% and 60%%)。 #### 地方政府執行撤離與救災的責任 (2 個意見) 此子主題與其他子主題相比具有 中度偏低一致。 主要主題包括: * **地方政府的撤離執行責任**:有陳述指出地方政府應對未執行撤離行動負責。 * **縣市首長的最終責任**:有陳述認為因為是民選官員,最終責任應由縣市首長承擔。 共同點: 參與者認為地方政府應對未執行撤離行動負責。 [[1](## "\"我認為地方政府應該為沒有執行撤離行動負責。\" Votes: (Agree=17, Disagree=3)")] 意見分歧: 沒有意見達到被視為顯著意見分歧的必要門檻(至少需要 20 個投票,且群組間同意率差異超過 40%% and 60%%)。 [[1](## "\"我認為地方政府應該為沒有執行撤離行動負責。\" Votes: (Agree=17, Disagree=3)")] #### 官員道歉、政治問責與下台的討論 (2 個意見) 此子主題與其他子主題相比具有 中度偏低一致。 主要主題包括: * **官員應道歉與負責**:有陳述認為花蓮縣長應為救災失誤公開道歉並承擔責任。 * **官員下台對救災的影響**:有陳述認為官員不需要道歉,下台只會影響救災進度。 共同點: 參與者認為花蓮縣長應公開道歉並承擔救災失誤的責任。 [[2](## "\"我認為花蓮縣長應該為救災失誤公開道歉並承擔責任。\" Votes: (Agree=20, Disagree=1)")] 意見分歧: 沒有意見達到被視為顯著意見分歧的必要門檻(至少需要 20 個投票,且群組間同意率差異超過 40%% and 60%%)。 [[2](## "\"我認為花蓮縣長應該為救災失誤公開道歉並承擔責任。\" Votes: (Agree=20, Disagree=1)")] #### 專業指揮官(如消防指揮官)判斷錯誤的追責機制 (2 個意見) 此子主題與其他子主題相比具有 低度一致。 主要主題包括: * **消防指揮官應受追究**:陳述指出消防指揮官在判斷錯誤時應被追究責任。 * **專業技術官員承擔最終責任**:陳述認為因決策由專業技術官員做出,故應由其承擔最終責任。 共同點: 沒有意見達到被視為共同點的必要門檻(至少需要 20 個投票,且至少需要 70% 的同意率)。 意見分歧: 沒有意見達到被視為顯著意見分歧的必要門檻(至少需要 20 個投票,且群組間同意率差異超過 40%% and 60%%)。 #### 獨立調查委員會與救災過程透明檢視 (2 個意見) 此子主題與其他子主題相比具有 高度一致。 主要主題包括: * **成立獨立調查委員會**:有陳述認為應設立獨立委員會以公開檢驗救災過程。 * **維持政府內部檢討**:有陳述認為救災檢討應留在政府內部,不需外部審查。 共同點: 參與者主張成立獨立調查委員會以公開檢驗救災過程。 [[10](## "\"我認為應該成立獨立調查委員會公開檢驗救災過程。\" Votes: (Agree=20, Disagree=2)")] 意見分歧: 沒有意見達到被視為顯著意見分歧的必要門檻(至少需要 20 個投票,且群組間同意率差異超過 40%% and 60%%)。 [[10](## "\"我認為應該成立獨立調查委員會公開檢驗救災過程。\" Votes: (Agree=20, Disagree=2)")] ### 資訊流通、平台與技術標準化 (9 個意見) 此主題包含 2 個子主題,總共包含 9 個意見。 #### 資料格式與 API 互通標準 (4 個意見) 此子主題與其他子主題相比具有 中度偏高一致。 主要主題包括: * **資訊流通不足**:陳述指出需改良每個環節的資訊流通不足,以提升救災程序的效率。 * **標準化 API 互通**:陳述認為若有統一的 API 標準,可避免資料重複傳輸與人工比對的情況。 * **可重複使用的模板與通訊協定**:陳述說明災害平台常在每次災害後重新建置,建議使用可重複使用的模板或通訊協定以提升完善度。 * **政府統一後端與資料格式**:陳述認為政府應負責統一後端資料庫、資料格式設定、API 協定與開放資料的管理。 * **前端多元開發串接同一後端**:陳述指出個別團隊可依需求開發多元的前端網站或 App,串接同一可信的後端系 共同點: 參與者指出,資訊流通不足是災害救援的關鍵問題,應聚焦於改良每個環節而非追究個人責任。參與者建議政府負責統一維護後端資料庫、設定資料格式、建立 API 協定與開放資料,讓各團隊依需求開發前端網站或 App,並使用可重複使用的模板或通訊協定避免每次災害重新建置平台。參與者認為若制定標準化的 API 互通機制,可減少資料複製與人工比對的工作量。 [[17](## "\"我認為重點不是要咎責個人,而是要改良每個環節的資訊流通不足之處。\" Votes: (Agree=26, Disagree=1)"), [24](## "\"很多平台是發生了災情才開始建置,每次災害重新建立平台,這樣的做法很難完善。最好是有可以重複使用的模板或是通訊協定。\" Votes: (Agree=25, Disagree=1)"), [25](## "\"我認為,政府應該負責把後端資料庫維護、資料格式設定、API協定、開放資料等個別團隊很難完成的事情統一做好,然後讓個別的團隊視自己的需求,開發出多元的前端網站或App,去串接同一個可信賴的後端。\" Votes: (Agree=24, Disagree=2)"), [22](## "\"如果可以有個標準,透過 API 互通資料,可以避免複製來、複製去,同樣資料還要人工介入比對\" Votes: (Agree=21, Disagree=3)")] 意見分歧: 沒有意見達到被視為顯著意見分歧的必要門檻(至少需要 20 個投票,且群組間同意率差異超過 40%% and 60%%)。 [[17](## "\"我認為重點不是要咎責個人,而是要改良每個環節的資訊流通不足之處。\" Votes: (Agree=26, Disagree=1)"), [24](## "\"很多平台是發生了災情才開始建置,每次災害重新建立平台,這樣的做法很難完善。最好是有可以重複使用的模板或是通訊協定。\" Votes: (Agree=25, Disagree=1)"), [25](## "\"我認為,政府應該負責把後端資料庫維護、資料格式設定、API協定、開放資料等個別團隊很難完成的事情統一做好,然後讓個別的團隊視自己的需求,開發出多元的前端網站或App,去串接同一個可信賴的後端。\" Votes: (Agree=24, Disagree=2)"), [22](## "\"如果可以有個標準,透過 API 互通資料,可以避免複製來、複製去,同樣資料還要人工介入比對\" Votes: (Agree=21, Disagree=3)")] #### 開放原始碼平台與持續迭代 (3 個意見) 此子主題與其他子主題相比具有 中度偏高一致。 主要主題包括: * **建立可重複使用的災害資訊平台**:陳述指出中央政府應建置一個可重複使用、專門應對災害的資訊平台。 * **整合民間志工與資源即時地圖功能**:陳述提到平台應參考民間建置的志工、物資、捐款、據點即時地圖需求。 * **保護參與者個人資料**:陳述強調平台在完善化的同時需保護使用者的個人資料。 * **使用Google地圖作為輔助工具**:陳述建議各單位加強使用Google Map以提升資訊呈現。 * **採用開放原始碼與持續迭代改良**:陳述認為政府應以開放原始碼方式建立平台,並透過回饋循環持續改進。 共同點: 參與者指出,政府應以開放原始碼方式建立救災資訊平台,並持續收集使用者回饋以便系統迭代改良。另一位參與者建議中央打造可重複使用的災害應變平台,整合志工、物資、捐款與據點即時地圖功能,同時加強個人資料保護。第三位參與者呼籲各相關單位提升Google Map的使用,以改善災情定位與資源分配。 [[23](## "\"任何平台一開始都很難完美,所以政府應該用開放原始碼的方式建立救災資訊平台,並往返收集回饋,讓系統可以迭代改良。\" Votes: (Agree=24, Disagree=1)"), [16](## "\"我認爲中央政府應建立一個可重複使用的,專門面對災害應變的資訊平台,參考民間建置的志工、物資、捐款、據點即時地圖功能需求,將它完善化並保護參與者的個人資料\" Votes: (Agree=22, Disagree=3)"), [19](## "\"各單位應加強使用Google map Votes: (Agree=19, Disagree=4)")] 意見分歧: 沒有意見達到被視為顯著意見分歧的必要門檻(至少需要 20 個投票,且群組間同意率差異超過 40%% and 60%%)。 [[23](## "\"任何平台一開始都很難完美,所以政府應該用開放原始碼的方式建立救災資訊平台,並往返收集回饋,讓系統可以迭代改良。\" Votes: (Agree=24, Disagree=1)"), [16](## "\"我認爲中央政府應建立一個可重複使用的,專門面對災害應變的資訊平台,參考民間建置的志工、物資、捐款、據點即時地圖功能需求,將它完善化並保護參與者的個人資料\" Votes: (Agree=22, Disagree=3)"), [19](## "\"各單位應加強使用Google map Votes: (Agree=19, Disagree=4)")] ### 資訊透明度與媒體角色 (5 個意見) 此主題包含 1 個子主題,總共包含 5 個意見。 #### Other (5 個意見) 此子主題與其他子主題相比具有 中度偏高一致。 主要主題包括: * **媒體錯誤資訊與罰則**:有陳述指出新聞台散播錯誤訊息應受到罰款。 * **資訊透明與封閉通訊渠道**:有陳述批評相關單位過度使用封閉的Line群組,導致資訊混亂與缺乏透明。 * **公民記者的平衡角色**:有陳述認為公民記者能在主流媒體報導不中立時提供平衡。 * **救災優先與資訊操弄的擔憂**:有陳述強調災後應先救災,並譴責利用天災散布偏頗訊息以影響大眾情緒。 * **災害期間媒體報導準則**:有陳述建議制定媒體公約,明確規範災區資源需求、變動性高訊息及禁止煽動仇恨或洩露受災戶隱私的報導。 共同點: 參與者要求對散布錯誤訊息的新聞台處以罰款,以遏止不實報導。參與者指出災後首要任務是救災,並譴責有人利用天災散布偏頗訊息企圖操控大眾情緒,認為此行為極其惡劣。參與者提議在重大災害發生時制定媒體公約,規定必須報導災區所需資源、暫緩報導變動性高的消息,並明令禁止煽動仇恨與洩露受災戶隱私。參與者認為公民記者能平衡主流媒體的偏頗報導,同時批評相關單位過度依賴封閉的Line群組,導致資訊不透明與多頭馬車的混亂,呼籲提升資訊流通的開放性。 [[6](## "\"我認為新聞台散播錯誤訊息應該被罰款。\" Votes: (Agree=29, Disagree=0)"), [28](## "\"我覺得災害發生之後,先救災比較重要,這次有人利用這個天災,故意提供偏頗訊息,希望影響大眾的認知和情緒,非常惡劣!\" Votes: (Agree=19, Disagree=0, Pass=1)"), [30](## "\"在台灣重大災害發生時,媒體該有一個公約或準則可以互相約束,什麼該報導(比如災區所需要資源),什麼暫時不要報導(例如變動性高的消息),什麼不能報導(比如煽動仇恨情緒、受災戶的隱私)。\" Votes: (Agree=20, Disagree=0, Pass=1)"), [20](## "\"公民記者可以平衡主流媒體上不中立的報導。\" Votes: (Agree=21, Disagree=2)"), [18](## "\"我認為許多相關單位太習慣使用封閉的Line群組,忽略了資訊透明和外溢的重要性。這造成的資訊混亂和多頭馬車的問題。\" Votes: (Agree=20, Disagree=3)")] 意見分歧: 沒有意見達到被視為顯著意見分歧的必要門檻(至少需要 20 個投票,且群組間同意率差異超過 40%% and 60%%)。 [[6](## "\"我認為新聞台散播錯誤訊息應該被罰款。\" Votes: (Agree=29, Disagree=0)"), [28](## "\"我覺得災害發生之後,先救災比較重要,這次有人利用這個天災,故意提供偏頗訊息,希望影響大眾的認知和情緒,非常惡劣!\" Votes: (Agree=19, Disagree=0, Pass=1)"), [30](## "\"在台灣重大災害發生時,媒體該有一個公約或準則可以互相約束,什麼該報導(比如災區所需要資源),什麼暫時不要報導(例如變動性高的消息),什麼不能報導(比如煽動仇恨情緒、受災戶的隱私)。\" Votes: (Agree=20, Disagree=0, Pass=1)"), [20](## "\"公民記者可以平衡主流媒體上不中立的報導。\" Votes: (Agree=21, Disagree=2)"), [18](## "\"我認為許多相關單位太習慣使用封閉的Line群組,忽略了資訊透明和外溢的重要性。這造成的資訊混亂和多頭馬車的問題。\" Votes: (Agree=20, Disagree=3)")] ### 民間參與與志工資源協調 (5 個意見) 此主題包含 1 個子主題,總共包含 5 個意見。 #### 數位平台與即時配對 (2 個意見) 此子主題與其他子主題相比具有 中度偏低一致。 主要主題包括: * **手機介面與GPS定位**:陳述指出希望有類似YouBike App的手機介面,利用GPS快速查找所在附近的需求與資源。 * **即時需求與資源匹配**:陳述強調在救災現場需要即時配對志工需求與可用資源,以提升救援效率。 * **專業志工平台與組織媒合**:陳述建議建立一個專業志工平台,將不同組織的專業人員進行媒合,應用於救災工作。 共同點: 參與者認為,從現場志工的需求角度,應該開發類似YouBike App的手機介面,利用GPS定位快速查詢志工所在附近的各種需求與資源。 [[26](## "\"從現場志工的需求角度,最好是能夠有像YouBike App那樣的手機介面,可以依照GPS定位,快速查到自己所在附近的各種需求和資源。\" Votes: (Agree=27, Disagree=1)")] 意見分歧: 沒有意見達到被視為顯著意見分歧的必要門檻(至少需要 20 個投票,且群組間同意率差異超過 40%% and 60%%)。 [[26](## "\"從現場志工的需求角度,最好是能夠有像YouBike App那樣的手機介面,可以依照GPS定位,快速查到自己所在附近的各種需求和資源。\" Votes: (Agree=27, Disagree=1)")] ### 災後補助與救助金發放原則 (2 個意見) ### 水利與災害專業監測檢討 (2 個意見) ### 公共參與與防災計畫前期討論 (2 個意見) ### 撤離指令與救災執行 (1 個意見) ### 其他 (1 個意見)

Import from clipboard

Advanced permission required

Your current role can only read. Ask the system administrator to acquire write and comment permission.

This team is disabled

Sorry, this team is disabled. You can't edit this note.

This note is locked

Sorry, only owner can edit this note.

Reach the limit

Sorry, you've reached the max length this note can be.
Please reduce the content or divide it to more notes, thank you!

Import from Gist

Import from Snippet

or

Export to Snippet

Are you sure?

Do you really want to delete this note?
All users will lost their connection.

Create a note from template

Create a note from template

Oops...
This template has been removed or transferred.


Upgrade

All
  • All
  • Team
No template.

Create a template


Upgrade

Delete template

Do you really want to delete this template?

This page need refresh

You have an incompatible client version.
Refresh to update.
New version available!
See releases notes here
Refresh to enjoy new features.
Your user state has changed.
Refresh to load new user state.

Sign in

Forgot password

or

Sign in via GitHub

New to HackMD? Sign up

Help

  • English
  • 中文
  • 日本語

Documents

Tutorials

Book Mode Tutorial

Slide Example

YAML Metadata

Resources

Releases

Blog

Policy

Terms

Privacy

Cheatsheet

Syntax Example Reference
# Header Header 基本排版
- Unordered List
  • Unordered List
1. Ordered List
  1. Ordered List
- [ ] Todo List
  • Todo List
> Blockquote
Blockquote
**Bold font** Bold font
*Italics font* Italics font
~~Strikethrough~~ Strikethrough
19^th^ 19th
H~2~O H2O
++Inserted text++ Inserted text
==Marked text== Marked text
[link text](https:// "title") Link
![image alt](https:// "title") Image
`Code` Code 在筆記中貼入程式碼
```javascript
var i = 0;
```
var i = 0;
:smile: :smile: Emoji list
{%youtube youtube_id %} Externals
$L^aT_eX$ LaTeX
:::info
This is a alert area.
:::

This is a alert area.

Versions

Versions

Upgrade now

Version named by    

More Less
  • Edit
  • Delete

Note content is identical to the latest version.
Compare with
    Choose a version
    No search result
    Version not found

Feedback

Submission failed, please try again

Thanks for your support.

On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?

Please give us some advice and help us improve HackMD.

 

Thanks for your feedback

Remove version name

Do you want to remove this version name and description?

Transfer ownership

Transfer to
    Warning: is a public team. If you transfer note to this team, everyone on the web can find and read this note.