山域安全平台：能力評估×適配組隊×留守通報

=== c84bcc28 2026-09-12 18:05 === [18:05] 評審： 下一個提案：#102「山域安全平台：能力評估×適配組隊×留守通報」。 [18:07] 助理： **#102「山域安全平台：能力評估×適配組隊×留守通報」** — 隊名「揪山心」，2 人：台灣設計研究院研究員（主提）、鳴周科技軟體工程師（合作）。回應許願池三項（志工派遣、體力夠不夠參加活動、戶外意外第一時間有人知道）。一筆未開放資料需求：林保署／國家公園署步道及園區封閉公告的標準化資料（公告類別、影響路段、封閉起訖、替代路線，API 化）。未評分。 **提案內容** - 三個缺口：登山者無客觀方式評估體能是否應付路線；自組隊能力落差大導致丟包脫隊；留守人制度是入山申請必填但形同虛設（無衛星裝置、下山才回報、留守人無異常判斷依據）。 - 三個機制：(1) 能力校準——過往登山紀錄（GPX，相容 Strava、健行筆記、Apple Watch；單日爬升量、完成時間）與路線負荷比對，產出個人化可行性判讀，規劃用機器學習；(2) 隊友媒合——組團時依能力區間篩選；(3) 即時資訊更新與留守通報——成團後自動綁定隊友、接駁司機、留守人；整合氣象署特報、災防科技中心民生示警、步道封閉公告（網頁監測＋關鍵字比對＋人工複核）；領隊設回報規則（單次或每日），逾時先問登山者本人，無回應才通知留守人；留守人免註冊、連結加入、唯讀名冊、可標記平安或撥打救援。平台明確定位「不判定山難、不代為報警，決定權在留守人」。 - 角色：隊員／乘客、領隊、司機、留守人；七條動線含「找車媒合、司機接單」。 - 現況：已用 Claude Code 做出 51 張互動原型；自製問卷 17 份有效樣本。入山許可、山屋抽籤採使用者手動登錄。 - 資料治理：匿名化、行程完成 30 天後刪除、使用者自主選擇是否授權分享。 - 期程 7 週：氣象 API、公告關鍵字監測、MVP → 媒合 → 5–10 組自組隊＋留守人封閉測試 → 訪談林保署／國家公園署 → 第二輪複測。場域雪山東峰、玉山主峰 1–2 條。 - 「全為原創內容無引用」。 **查證（AI 評估所附網址）** - Hikingbook 安全守護：留守人**不需帳號或 App**，透過 email 連結看即時活動網頁——行程、安全警報時間、預計路線與實際軌跡、裝備清單、紅黃綠狀態、打卡紀錄；逾時 1 小時 email，再逾時 email＋簡訊提醒留守人「必要時尋求協助」。跟 #102 的留守通報機制（免註冊連結、唯讀行程、逾時升級通知、決定權在留守人）幾乎一樣。Hikingbook 另有百岳難度分級。 - 登山留守平台（hiking-guard.web.app）：智慧模式 LINE 通知＋Garmin inReach，經典模式人工回報行程代碼；也是留守人機制。 - GRASS 等揪團平台：以活動難度標籤（新手團）分流，不是按個人能力篩選成員。 - 步道封閉公告沒有結構化資料、要爬網頁——這點屬實，提案把它列為未開放資料需求，並說開放後其他山域服務都能用。 **問題** - 留守通報這一段 Hikingbook 已做，而且做得更完整（有即時軌跡）；提案沒提 Hikingbook，並勾「全為原創」。 - 能力校準：機器學習模型沒有訓練資料（17 份問卷不是訓練資料），「依據大資料數據做出最精準的判讀」與現況不符；判讀錯誤給山友虛假信心是反向風險。提案自己也說準確度要靠驗證期回饋調整。 - 隊友媒合按能力區間篩選：現有揪團平台用活動標籤，按個人能力篩人是它跟現有的差別；但能力分數本身來自上面那個沒資料的模型。 - 「找車媒合、司機接單」：登山口接駁的白牌車問題，提案沒有碰。 - 資料治理：GPX 軌跡、體能、行程名冊、留守人免註冊連結（連結外流誰都能看名冊）、司機和陌生隊友可見資料；「匿名化」與「30 天刪除」只有一句。 - 2 人團隊，7 週要做 API 介接、公告爬取、機器學習模型、媒合、通知、兩輪實測；已有 51 張原型是設計稿，不是程式。 - 女性山友與陌生人媒合組隊、搭陌生司機的車，沒有考量。 [18:13] 評審： 我不是登山的人，只有偶爾走走當天來會不需要裝備的山。留守人是什麼？ [18:13] 評審： 我不是登山的人，只有偶爾走走當天來回不需要裝備的山。留守人是什麼？ [18:13] 助理： 留守人就是「留在山下、知道你去哪裏、什麼時候該回來」的那個人。 多日或進入管制山域（國家公園生態保護區、林保署的高山步道）要辦入山／入園申請，申請表上有一欄「留守人姓名、電話」，是必填。它的用意是：山上沒訊號，隊伍出事沒辦法自己求救，所以事先跟山下一個人講好行程——幾號上山、走哪條路線、預計幾號幾點下山到哪裏。時間到了人沒下來、也聯絡不上，留守人就打 119 或通報國家公園、消防隊，搜救才會啟動。留守人手上要有行程表、名單、裝備、有沒有帶衛星通訊器等，搜救單位問得到。 提案講的「形同虛設」是指：表上是填了，但實務上很多自組隊只是隨便填個家人朋友，沒有真的交代行程，路上有訊號才傳個訊息，留守人不知道什麼時候該緊張。所以事故發生到有人察覺，中間可能隔一兩天。 Hikingbook 安全守護和 #102 要做的，都是把這件事變成系統：行程和名單放在網頁上讓留守人看得到，設一個「安全警報時間」，過了沒回報就自動提醒留守人。差別在提案多了「先問登山者本人，沒回應才通知留守人」這一步。 [18:16] 評審： 所以留守人只要擁有完整資訊，甚至可以留在城市裏，沒有跟著去山下集合，對嗎？ [18:16] 評審： 所以留守人只要擁有完整資訊，甚至可以留在城市裏，沒有跟著去山下集合出發，對嗎？ [18:16] 助理： 對。留守人本來就不用到登山口，通常就是家人或朋友在自己家裏。他需要的只是資訊（行程、路線、名單、預計下山時間、緊急聯絡方式）和一支能打 119 的電話。 這也是為什麼 Hikingbook 和 #102 都把留守人設計成「免註冊、點連結就能看」——留守人不是山友，不會為了這件事裝 App。 [18:21] 評審： 那這個提案和同類型服務平台，有什麼不同？ [18:21] 助理： 分三段對： | 機制 | 現有 | #102 多的 | |---|---|---| | 留守通報 | Hikingbook 安全守護：免註冊網頁、行程與名單、即時軌跡、逾時 email→簡訊升級；登山留守平台：LINE＋Garmin inReach | 逾時先問登山者本人、沒回應才通知留守人；領隊可設單次或每日回報規則。**少了**即時軌跡（Hikingbook 有）。 | | 能力評估 | Hikingbook 有路線難度分級（路線端）；沒有人這一端的評估 | 用個人 GPX 紀錄（爬升量、完成時間）對路線負荷做「你走不走得了」的判讀。這是現有平台沒有的，但模型沒有訓練資料。 | | 隊友媒合 | GRASS、健行筆記揪團：活動標新手團／進階團，自我選擇 | 按個人能力區間篩隊員，而不是按活動標籤。前提是上面那個能力分數可信。 | 另外兩件現有平台沒有、提案也沒有做出來的：把步道封閉公告結構化（提案列為向政府要的資料）、找車接駁司機媒合（白牌車問題沒碰）。 所以整個提案的差別集中在一點：**能力校準**。留守通報是 Hikingbook 已有的，媒合是能力校準的延伸。能力校準做得出來、判得準，三段串起來就有意義；做不出來，剩下的就是一個沒有軌跡功能的 Hikingbook。而提案目前只有 17 份問卷和 51 張設計稿，沒有任何登山紀錄資料可以訓練。 [18:24] 評審： 一比較起來，感覺只是一個新產品而已啊。 ^^; 本地已經有兩個同性質產品了。當然各自服務功能有所差異啦，就跟KLOOK和KKday的差異。 [18:24] 助理： 提案裏唯一不是「又一個產品」的部份，是它向林保署／國家公園署要的那筆資料：步道封閉公告標準化、API 化。它自己也寫「一經開放亦可供其他山域服務共同使用，效益不限於本案」。這件事對 Hikingbook、健行筆記都有用，但它是向政府提的需求，不是提案要做的東西。 其餘三個機制都在 App 裏面，服務對象是它自己的使用者。 [20:31] 評審： 5/7/5/2/4，no comment，如何？ [20:31] 助理： 加權總分 **5.26**（5×0.30 + 7×0.28 + 5×0.30 + 2×0.05 + 4×0.05）。 沒有意見。主題27兩案評完：#68 3.09、#102 5.26。 [20:36] 評審： 下一個主題：主題28。請用/api/topics/<id>，取得該主題的提案。先不要看未評分的提案。針對已評分的提案：1.先查/api/proposals/<id>，只閱讀提案內容，不閱讀AI輔助評估和分數評語。2.查session log，先前有哪些討論。3.再閱讀AI輔助評估和分數評語。 [20:36] 助理： Read #70's text; waiting for the session-log search before reading the AI assessment and score. [20:38] 助理： #70 讀完了：原文、9/7–9/8 的討論、AI 評估、3/2/1/1/4 = 2.01（可行性從討論時的 6 調到 3，評語加了「請說明『安心求助測整理卡』是什麼」，私人註記標 XX 卡疑 AI 撰寫），評分邏輯清楚。 主題28另一件 #97 未評分，等你點名。 === 事後／並提討論 === c84bcc28 2026-09-12 [18:04] 助理： #68 讀完了：原文、9/7 的討論、AI 評估、7/3/0/0/3 = 3.09（可行性從討論時的 6 調到 7），評語「國土利用監測整合作業行之有年，建議參考。」，評分邏輯清楚。 主題27另一件 #102 未評分，等你點名。 c84bcc28 2026-09-12 [22:12] 助理： 八案我都記得，不用重抓。 | | 可行 | 影響 | 創新 | 多元 | 治理 | 總分 | |---|---|---|---|---|---|---| | #68 山坡抓寶 | 7 | 3 | 0 | 0 | 3 | 3.09 | | #102 山域安全 | 5 | 7 | 5 | 2 | 4 | 5.26 | | #70 毛孩安心 | 3 | 2 | 1 | 1 | 4 | 2.01 | | #97 Pet Guard | 9 | 1 | 2 | 3 | 3 | 3.88 | | #72 蛋定行動 | 8 | 2 | 0 | 1 | 2 | 3.11 | | #153 未卜先雞 | 5 | 4 | 10 | 7 | 4 | 6.17 | | #73 微藻樹 | 8 | 2 | 8 | 1 | 2 | 5.51 | | #122 藻光同行 | 8 | 2 | 4 | 1 | 2 | 4.31 | 一處對照： **#73 創新 8、#122 創新 4，對照 #55 0、#114 0（同一個成大實驗室）。** 9/8 評 #73、#122 時，你給 #55、#114 0 的理由是研究已做完；#73、#122 當時你看的是想法。今天的規則明確化之後：#73 是實驗室國科會 113–115 年三年計畫（與中鋼合作 2 噸級煙氣養藻，已運轉兩年多）的延伸，提案自述是「2025 年提案的第二代」；而且塞爾維亞 Liquid3、墨西哥 BioUrban 的微藻城市家具已商轉多年。#122 的核心「雙模辨識」就是實驗室 2026/08/01 起執行的國科會 115 年計畫題目。兩案都落在「自己已在做」那一格，跟 #35、#178、#97 同型。這四案的創新分數現在是 0 / 0 / 8 / 4。 另外 #73 可行性 8 與評語「教育用途大於實質節能減碳」——按你 9/12 的定義（提案的做法能否達成題目目的，#234 的例子），題目是「城市碳匯」，你的評語說做法達不到，這個 8 是 9/8 用「做得出來」給的。要不要按新定義動，你決定。 其餘我沒有要調整的。 c84bcc28 2026-09-13 [21:49] 助理： 第二輪十組收齊。剔除你已裁定的（#73／#123、#41、#159、#79、#103、#102／#126、#127、#115／#98、#180、#10 治理等），以及你說不必逐案看的治理完整度與多元性之後，剩下這些： ## 創新性 | 對照 | 分數 | 原文事實 | |---|---|---| | #15 阿公台語 6 vs #87 1 | | 核心相同：高齡農民台語語音＋拍照，AI 診斷病蟲害、自動產出履歷。#87 因「神農 TAIDE」給 1；#15 多的是區塊鏈／ZKP／3D 農場／高中生志工。 | | #196 水管你 7 vs #49 1 | | #196 前端直接用自家「農來訊」既有平台（隊員是農業局人）、高改場木瓜灌溉模組是隊員自己的技轉成果、預報是安吉自家商品；新增只有水存摺、燈號、LLM 一句話。#49 被評「各環節均為既有設備與技術」給 1。 | | #12 消防水源 1 vs #154 0 | | #154「自家現有產品」0；#12 提案人就是臺中市消防局，評語「臺中市消防局消防水源管理系統已存在」——也是自家機關已有。 | | #22 供苗預警 8 vs #239 5 | | #22 自述「現行供苗燈號機制之決策支援升級，而非取代」「與現行燈號並行」——既有機制上加需求端訊號；#239 新組合給 5。 | | #71 務農遮棚 8 vs #210 5、#189 1 | | #71 自承「相較固定遮棚或全天噴霧，本案採需求式控制」，你的評語也說「控制不需要 AI」；同型的分級觸發案 #210 5、#189 1。 | | #164 農機辨識 4 vs #72 1 | | 兩案評語邏輯相同（現成工具已能做：預訓練模型／ChatGPT）。 | ## 可行性 | 對照 | 分數 | 原文事實 | |---|---|---| | #118 防護卡 4 vs #23 誘捕籠 1 | | 兩案評語都判核心機制無效；#118 一人、原文自承「打樣公司無法完成，須仰賴中央印製廠」，決審前連實體卡都沒有。 | | #181 紅火蟻 9 vs #22 7、#213 8 | | #181 核心資料（疫情點位、電子聯單 GPS、鑑定結果）全是四機關未開放資料、場域「優先爭取」、七名學生、拿不到就用合成資料；#22 全開放資料、公司有部署經驗；#213 場域已確認。 | | #20 安心開飯 2 vs #227 家暴 4 | | #227 期程是「10 月和工程師討論研發方式、11 月完成所有資料」，沒有任何開發步驟。 | | #64 格外乳 6 vs #164 3 | | #64 一人、8 週要做檢驗→分離→飼料廠試製→雞場驗證，廠與場都未具名，你的評語自己質疑藥檢與規模；#164 純軟體 2 個月訓練分類器。 | | #153 未卜先雞 5 vs #232 8 | | 同型純開放資料分析平台、都有原型、都缺一筆未開放資料、都無場域、都用歷史回測。 | ## 影響力 | 對照 | 分數 | 原文事實 | |---|---|---| | #78 AgriResilience 6 vs #152 2、#11 1 | | 三案都是災時通報＋政府儀表板；#152 有場域有資料被評「價值不高」2；#78 一人無場域、評語只有「參考 Meshtastic」給 6。 | | #10 台語 AI 3 vs #111 櫃買 5 | | 兩案都是既有資訊整合入口；#10 對象高齡偏鄉、台語（加分項）；#111 對象一般投資人、櫃買內部先用。 | | #129 防偷拍 3 vs #94 綠色憑證 5 | | 兩案都有負面風險（誣告損失／漂綠）；#129 是性別安全（受害者 87% 女性）。 | | #155 地知 6 vs #131 5、#153 4 | | #155 單一鄉鎮遊客問答，你的評語列了幻覺與座標曝光；#131 全國回收場火災預警、#153 全國蛋雞產銷。 | | #108 福壽螺 0 vs #68 3 | | 同樣「台灣已有無害替代／既有作業」：愛鴨機器人、國土監測。 | | #109 熱管家 7 vs #72 2 | | 同樣評語認定既有服務已涵蓋（hiOSHA／ChatGPT）；#109 另有你自己寫的「AI agent 必然有幻覺」。 | | #65 4 vs #121 0 | | #121 的 Omni 交叉稽核（履歷、檢驗、行情、下架清單）就是 #65 的規則比對；#121 0 是扣區塊鏈。 | | #86 1 vs #238 7 | | 兩案都「台灣已有」（樂活氣象／地方創生基金會）、創新都 1。 | ## 資料治理（只列「私人資料送雲端」這一條） | 對照 | 分數 | 原文事實 | |---|---|---| | #82 直直問 8 vs #62 6、#214 4 | | #82 兒童提問（含可能的家內受虐揭露）走 AWS Bedrock 商用 LLM；#62 本地 LLM 隔離 VM 不送雲；#214 個案座標本機離線。 | | #188 城鄉韌性 5 vs #134 2 | | 你對 #188 的評語「救災資訊往往有詳細個資，送 LLM API 有資安隱私顧慮」；#134 只是「可能錄進人聲」的推測風險。 | | #53 私訊分析 9 vs #66 3 | | #53 方法就是把與第三人的真實私訊與照片丟 ChatGPT／Gemini；#66 正式運作不用生成式 AI。 | | #3 農養共生 4 vs #126 2 | | #3 長者健康狀況送 Claude／ChatGPT API、要台電台水到戶級水電資料觸發個別警訊；#126 裝置端分析不存原圖。 | | #52 防詐 ATM 10 | | 你的評語「風控參數若由生成式模型決定，無法解釋與稽核」，治理仍滿分。 | 你要從哪一段開始？