=== e36e3881 2026-09-11 13:12 ===
[13:12] 評審：
下一個提案：#189「以政府開放號誌資料驅動之智慧綠波導航與城市交通驗證平台」。
[13:12] 助理：
訊息核對一致。讀 #189 全文。
[13:12] 助理：
1 人團隊(大同大學資工生 賴緯麒)。做「號誌感知導航」:把號誌時制(北市開放資料)+ 路網(OSM)+ GPS + 抵達時間納入路徑成本,產生會標紅燈停等成本的候選路線、建議速度,並上路實測對比 Google Maps。調性樸素誠實(不預先宣稱固定改善比例)。讀 ai_assessment 和附的網址。
[13:13] 助理：
similar_sources 指向 GLOSA 類產品:Audi TLI、開源 GLOSA App、高德紅綠燈倒數。關鍵要分清「速度建議/倒數」和「號誌納入選路」是不是同一回事。讀兩個確認。
[13:14] 助理：
兩個網址讀完(免重複查證)。攤平給你。
## #189 事實
**是什麼**:1 人(大同資工生)。號誌感知導航——把北市開放的**號誌時制 + 號誌位置** + OSM 路網 + GPS + 抵達時間,一起納入**路徑成本**,產生會估「紅燈停等成本」的多條候選路線,給建議速度與下一號誌狀態,並上路實測對比 Google Maps。用**官方開放資料**、AI 只做開發輔助(不在核心)、不預先宣稱改善比例。
## 既有系統(已讀網址)
- **Audi TLI / GLOSA、開源 GLOSA App**:**只做速度建議**(紅燈倒數 + 算出「該開多快才能一路綠燈」),**針對你已選的路線,不做選路**。
- **高德(Amap)紅綠燈倒數**:**倒數顯示**,而且是靠**海量用戶定位/車速/停等 AI 推斷**(不是用政府號誌資料),伴隨監控與中國法資料調取的隱私疑慮。
→ 要分清:**#189 的「建議速度 + 號誌倒數」那半,GLOSA/Audi/高德已經在做**;但**「把號誌停等成本納入『選路』」那半,上述產品都沒做**(Audi 是既定路線的速度建議、高德是倒數)。所以 **#189 的差異點是「號誌感知選路」**——不是全新(它自己引 A* 研究,學界有前案),但不在所引既有產品範圍內。而且它用**官方開放資料**,資料來源比高德的群眾推斷乾淨,也正對「把政府管理資料轉成民眾服務」的智慧治理主題。
## 問題
1. **核心隱憂:靜態時制 vs 適應性號誌不符**。北市開放的號誌時制多為**靜態計畫**,但實際很多路口是**適應性/觸動號誌**(依車流動態變),用靜態資料算出的紅燈停等會與現場不符——這會直接侵蝕「選路成本估算」的準確度。這是它可行性的最大問號。
2. **資料覆蓋/正確性**:它自己也承認開放資料偏管理用途、需向交通局要更完整號誌資料、並要驗證開放資料與實際號誌是否一致(誠實揭露資料缺口)。
3. **外部性**:綠波導航可能鼓勵開車、**繞行住宅巷道躲紅燈**(rat-running);建議速度有超速/分心風險。
4. **1 人、樣本小**:自測樣本太小;僅北市;以私家車為中心(行人/單車/大眾運輸未涵蓋)。
5. **隱私**:蒐集 GPS 軌跡+telemetry 存 GCP,未提去識別/保存期限/同意(規模遠小於高德,但仍有)。
6. **正面(事實)**:誠實、樸素(不宣稱固定改善);用官方開放資料(比高德群眾推斷乾淨);切題(政府管理資料→民眾服務);AI 揭露誠實;主動點出自己的資料缺口。
以上事實與問題攤平。你給分。
[13:20] 評審：
1. 我以為Google導航現在會把紅綠燈燈號納入演算？還是我的理解有誤，它納入的是車流量？
2. 我以為上下班尖峰時間，交通警察還是保留手動控制燈號？
[13:20] 助理：
兩個都是會影響 #189 可行性的關鍵事實,我不想憑可能過時的記憶答(尤其 Google 的功能一直在變)。派 subagent 查證。
[13:21] 助理：
已派 subagent 查證這兩點。回來我再據實回答——Google 導航到底納入的是號誌時制還是車流量,以及尖峰時段交警手動控燈的實際情形(這兩點都會影響 #189 靜態時制資料與現實的落差)。
[13:24] 助理：
兩題查證回來了,直接回答:
## Q1:Google 導航納入的是車流量,不是號誌時制——你後面那個理解才對
- **Google Maps 選路與 ETA 主要用「車流/速度資料」**(即時+歷史的匿名裝置速度與位置)。紅綠燈延誤是**隱含地**被捕捉——停等、慢速的車自然把該路段速度壓低,模型從觀測到的速度學到延誤。**沒有公開證據顯示消費者版用『明確的號誌時制(相位/週期/時制計畫)』來選路或算時間。**
- **Project Green Light 是反方向的東西**:它拿 Maps 的車流資料 + AI,**產生號誌時制的調整建議給城市交通工程師**去調燈——是「Maps 資料 → 幫城市調號誌」,不是「號誌時制 → 餵進 Maps 選路」。且它改善的是整體車流,Google Maps 使用者不會被優待。
- 地圖上的**紅綠燈圖示只是顯示功能**(提示前方有號誌),與選路無關。
- 誠實的但書:Google 沒公開完整演算法,「消費者版完全不用號誌時制」是**未見反證的推論**,不是官方白紙黑字否認;搜到一些相關**專利**,但專利=有構想,不代表已上線。
## Q2:你這個理解正確——尖峰交警確實還會人工控燈
- 尖峰時段在重要路口**人工指揮、必要時「手控操燈」是台灣現行、制度化的勤務**(手控需向分局報備、週期以 180 秒內為原則)。
- 而且法定效力**指揮人員 > 號誌 > 標誌 > 標線**——交警一比手勢,該路口的實際放行時序就跟號誌時制脫鉤。
- 另外城市還有**分時制/自適應號誌**(北市把週期依尖峰/離峰/深夜切成 10–12 時段動態調整)。
- 但書:沒有全國統計說多少路口、多常改人工;一個法規頁目前 404(引自快照),但「指揮優先」與「手控操燈」規範是確實的。
## 連到 #189(事實與含意)
這兩題合起來,對 #189 有一個關鍵含意:
- 一方面,**#189 的差異點(用明確號誌時制做『選路』)確實不是 Google 在做的事**——Google 是隱含地用速度,#189 是顯式用時制。所以那個差異是真的(不是空的)。
- 但另一方面——這才是重點——**Google 那套「從實際觀測速度學延誤」的隱含做法,反而比 #189 的「靜態時制模型」更能扛住現實**。因為 Google 量的是**實際發生的延誤**,不管路口是自適應號誌、還是交警手控,觀測速度都照實反映;而 **#189 用的是公告的靜態時制計畫,恰恰在尖峰(最需要導航的時候)被自適應控制 + 交警手控雙重打臉**,算出來的紅燈停等會與現場不符。
換句話說:#189 選了一條「顯式靜態時制」的路,而它要打的對手(Google)用「隱式實測速度」早就把紅燈延誤算進去了,還天然免疫於 #189 最大的罩門(尖峰時制失真)。這強化了我先前列的第 1 個問題,而且點出它的方法在對比現有導航時的結構性劣勢。事實與含意攤在這裏,判斷交給你。
[13:29] 評審：
1/2/1/0/3「許多路口紅綠燈已改為自適應紅綠燈，因應車流量即時調整紅綠燈秒數，必要時會改由交警手控，演算法難以計算紅綠燈秒數。」如何？
[13:30] 助理：
加權總分 **1.31**(1×.30 + 2×.28 + 1×.30 + 0 + 3×.05 = 0.30+0.56+0.30+0+0.15)。
評語三點都經查證屬實:自適應號誌即時調秒數、交警手控、演算法難算紅燈秒數。這正是壓低可行性的決定性問題,記得準、只記問題。分數我沒有意見。
一個 #59 式的補充(你的取捨,不是要你加):評語記的是「時制不可預測」這道可行性罩門;它**沒**記到另一個支撐低創新/低影響的已查證事實——**現有導航(Google)已用實測速度隱含地把紅燈延誤算進去、也就是它想達到的『避開紅燈』結果既有工具已經在做**。要不要放進去你決定。
主題11 四件全評完了:#71(7.52) > #59(6.66) > #189(1.31) ≈ #113(1.01)。要做這 4 件的給分平衡回顧,你說一聲。
[13:31] 評審：
請回顧一下，主題11的提案，給分平衡有沒有哪一件要調整的？不記得的話，可以get-proposal --full，但記得就不要用了，不要徒增對話長度。
[13:32] 助理：
主題11 排序:#71(7.52) > #59(6.66) > #189(1.31) > #113(1.01)。全部在脈絡裏,不 get-proposal。
**結論:沒有哪一件明顯與證據矛盾,不需要調整。**
我實際比對的最接近一點:**#71 vs #59 的可行性(8 vs 7)**——直覺上會覺得反差:#59 是生多所(路殺社主管)+ 中研院 + **確定場域**(新北動保處),#71 是高中生帶國中弟妹、**六種硬體、無場域**,可行性卻是 #71 高。但按你的既有尺規,它站得住:
- **可行性 = 可建置度**(#68),而非落地完整度;#71 自述**已有原型/樣品**、核心(溫度觸發遮蔭)簡單;#59 的新核心(用穿山甲目擊點做預測模型)反而有「可能只預測到人多的地方」的可行性風險。
- **無場域、團隊小是黑客松該補的**(#37/#237),不扣可行性。
- 而且這一點**在當初評分時就已經被提出討論過**,你權衡後保留 8。所以不是漏看,是刻意。
其餘:#71 社會影響力 9(尖峰通勤族的曝曬,影響面廣)、創新 8(遮陽傘板橋/台北已有,但**熱風險選點圖**是新的那半)——都在你鼓勵價值/創新的尺度內。底部兩件也一致:**#113 可行性 0(新燈號無法源+撞專利=結構性/法律阻礙,否決)vs #189 可行性 1(靜態時制失準=技術退化,未到否決)**,0 與 1 的分界合理。
不動。
[13:36] 評審：
#59要用的預測資料比較複雜：它要用交通事故資料裏面動物肇事的部份。這個我不確定有沒有，還是要全部交通資料來篩選。
[13:36] 評審：
#59要用的預測資料比較複雜：它要用交通事故資料裏面動物肇事的部份。這個我不確定有沒有，還是要全部交通資料來篩選。你可以確認一下我說得對不對。
[13:37] 助理：
這是關鍵的一點,而且你可能是對的——#59 自己在提案裏就**要求在事故通報表新增一個「AVC」欄位**,這本身就暗示目前沒有現成的動物肇事欄位。我派 subagent 查證台灣交通事故資料到底有沒有「動物肇事」這個分類。
[13:37] 助理：
已派 subagent 查證。回來我再確認你說的對不對——台灣交通事故資料裏有沒有現成的「動物肇事」子集,還是得從全部資料篩(且可能根本沒編碼)、真正的動物路殺資料其實在路殺社。
[13:38] 評審：
不用查證了。提案人自己說沒有就沒有。
[13:38] 助理：
了解,不查了。提案人自己在提案裏**要求新增 AVC 欄位**,這就是他自己承認現在沒有這個資料——那就是沒有。先把還在跑的 subagent 停掉。
[13:39] 助理：
你說得對,而且是提案自己坐實的:#59 要「新增 AVC 欄位」到事故通報表,等於**它自己承認現行交通事故資料裏沒有乾淨的動物肇事子集**——不然不必新增欄位。要嘛沒有、要嘛得從全部事故資料硬篩(而且多半沒編碼、小動物路殺根本不進事故系統)。所以這個輸入是**它要爭取的、不是現成的**。
對 #59 的含意(事實,不替你判分):
- 它的熱點預測模型列了好幾個輸入:**主力是 TBN 穿山甲目擊點**,另外還有氣象/土地/道路/速限/車流/街景、1999 陳情、以及事故資料的動物部分。
- 其中**「事故資料動物部分」現在拿不到**(要靠它新增 AVC 欄位),這是一個真實的資料缺口;但它是**多個輸入之一、不是主力**,所以是**部分打擊,不是整個模型垮掉**——主力那條(穿山甲目擊點)仍在,只是先前也提過那條有「稀疏、偏差、可能只預測到人多的地方」的疑慮。
合起來:#59 的預測模型資料基礎,比乍看**弱一些**——一個輸入是還沒有的資料、主力輸入又有偏差風險。這是否要反映到你先前給的可行性/創新(7/7),balance 由你決定。
[13:40] 評審：
我調整了分數平衡，你看一下。
[13:40] 助理：
訊息核對一致。拉主題11 四件目前的系統分數。
[13:41] 助理：
一處變動:
| # | 變動 | 加權 |
|---|---|---|
| **59** | 可行性 7 → **5** ⬇ | 6.66 → **6.06** |
| 71 | 不變 | 7.52 |
| 189 | 不變 | 1.31 |
| 113 | 不變 | 1.01 |
你把 #59 可行性降 2,正對到我們剛談的:預測模型的**資料基礎偏弱**——「事故資料動物部分」現在根本沒有(提案自己要新增 AVC 欄位),主力的穿山甲目擊點又有偏差風險。可行性 5 反映「這個模型的資料能不能撐起來」的疑慮,合理。加權重算 5×.30+7×.28+7×.30+4×.05+6×.05 = **6.06**,對。
排序不變:#71(7.52) > #59(6.06) > #189(1.31) > #113(1.01),只是 #71 與 #59 的可行性差距拉開成 8 vs 5——#71 有原型、核心簡單,#59 的模型吃到部分不存在的資料,這個差距現在站得住。
這輪調整我沒有意見。主題11 收齊。
[13:42] 評審：
下一個主題：主題12。請用get-topic指令，取得該主題的提案。先不要看未評分的提案。針對已評分的提案，查一下session log，先前有哪些討論。然後再get-proposal，確認提案內容和評審分數。
[13:42] 助理：
訊息核對一致。取得主題12清單。
[13:42] 助理：
主題12 豬隻產業,4 件,只有 **#190「豬群精準健康雷達」** 已評分(#83、#197、#234 未評,先不看)。派 subagent 查 session log 對 #190 的討論。
[13:42] 助理：
主題12 只有 #190 已評分(#83、#197、#234 未評,先不看)。已派 subagent 查 session log。回來我再 get-proposal 確認 #190 的內容和你的分數。
[13:44] 助理：
subagent 撈到 #190 完整討論。get-proposal 對系統分數。
[13:46] 助理：
確認完成,與 log 一致:
**#190「豬群精準健康雷達」**(團隊18 豬豬好隊友;陽明交大電機 BASIC Lab + 台大資工博生 + 獸醫回饋)
分數 **8/4/1/7/8 = 4.57**,評語「核心技術是國科會計劃。『化被動撲殺為精準預警』屬過度宣稱,法定傳染病仍須撲殺。類似前案已有,建議參考。」
要點,現在我脈絡裏有了:
- **是什麼**:RGB-T(可見光+熱像)個體追蹤,AI 監測豬隻進食與成長、提早揪出病豬。同隊另有 #203(RGB-T 農業巡檢機器人)。
- **可行性底子強(正面)**:方法有同儕審查背書(OinkTrack 個體追蹤資料集發表於 ACM MM 2025、熱像溫度校正發表於 IEEE IAS);場域已落地(雲林大峯牧場保育舍 6 欄已部署 RGB-T + 邊緣/雲端);硬體具體。→ 可行性 8。
- **問題(多屬創新)**:核心即**已獲補助的國科會晶創計畫**(2024 起、OinkTrack 已發表、6 欄已部署)→ 創新 1;市場已有相似產品(豬來寶、農科院 ATRI、法國 Dilepix);**過度宣稱**「化撲殺為預警」(法定傳染病口蹄疫/非洲豬瘟依法仍須撲殺,AI 最多改善一般疫病);ROI 證據薄(死亡減半假設,僅 5 例風險豬);驗證基礎窄(單一牧場)。
- 資料治理 8(事件鏈/PCR 回填/去識別是它的強項)。
主題12 已評的就這一件。因為只有一件,balance 要等 #83、#197、#234 也評分後才有同主題對象。你要進未評的提案,或有其他指示,說一聲。
=== 事後／並提討論 ===
e36e3881 2026-09-11
[12:55] 助理：
主題11 道路交通與號誌,4 件。已評分:**#59「鯪鯉共好,平安回家」**、**#71「光蔭之間森呼吸-AI 綠能路口熱風險管理交通號誌」**。未評:#113、#189(先不看)。派 subagent 查 session log 對 #59、#71 的先前討論。
e36e3881 2026-09-11
[12:55] 助理：
主題11 已評分的是 #59、#71(#113、#189 未評,先不看)。已派 subagent 查 session log。回來我再 get-proposal 確認內容和你的分數。
e36e3881 2026-09-11
[12:59] 助理：
確認完成,與 log 一致:
| # | 提案 | 團隊 | 分數 | 加權 | 評語 |
|---|---|---|---|---|---|
| **71** | 光蔭之間森呼吸-AI 綠能路口熱風險號誌 | 鱻魚隊 | 8/9/8/1/3 | **7.52** | 這個提案控制不需要AI。 |
| **59** | 鯪鯉共好,平安回家 | 鯪鯉共好 | 7/7/7/4/6 | **6.66** | (無) |
要點,現在我脈絡裏有了:
**#59**(7/7/7/4/6)——生多所(路殺社的主管單位)主導 + 中教大助理教授 + 中研院資訊所 + 新北動保處(確定場域)。Q5 誠實勾「已在進行中」(原案=路殺社公民科學)。三個新東西:(1)用 TBN 穿山甲**目擊點**(非路殺點)+ 氣象/土地/道路/速限/車流/街景做**熱點預測模型**,還納入 1999 陳情與交通事故資料;(2)預測經 API 推到公路 CMS 資訊可變標誌;(3)低成本光熱感應 LED 太陽能警示器。既有前例:路殺社前 100 熱點 2021 已進 Garmin 導航;**台3線石虎路殺預警(2019,同一機構做的)**已做「AI 辨識+可變標誌+聲光」達零路殺——三個落地層都有前例,真正新的是預測模型+新資料源。你給無評語(唯一沒記下的是台3線石虎系統這個既有事實)。
**#71**(8/9/8/1/3)——羅東高中生帶兩個國中弟妹,3 人。針對路口曝曬的機車族。兩層:(1)雲端用氣象署+TDX 算「路口熱風險分數」給地方選點;(2)現場 ESP32 溫濕度+YOLO 數等待機車,「有人+高風險」才啟動,分級 30°C 遮蔭/35°C 回收雨水噴霧/40°C 局部降溫,綠能優先。既有前例:新北板橋、台北西門町/小巨蛋已有溫度觸發的智慧遮陽傘試點。核心問題:「有人才啟動」為省一點傘電加了相機+邊緣運算+影像治理,溫度+時段規則就夠了(用了不需要的 AI);35°C 噴霧使路面濕滑(對機車最糟);選點那半才是有價值的部分。你評語正是「這個提案控制不需要AI」。
主題11 已評的就這兩件(#113、#189 未評)。要做平衡回顧,得等那兩件也評分後才有完整的同主題對象。你要進未評的提案,或有其他指示,說一聲。
e36e3881 2026-09-11
[13:08] 助理：
加權總分 **1.01**(0×.30 + 2×.28 + 1×.30 + 0 + 3×.05 = 0+0.56+0.30+0+0.15)。
評語三點都經查證屬實:Itron 專利 US12361824B2(持有人 Itron、核心「幾乎一模一樣」)、台北緊急優先號誌(已布 239 路口、降 62.5% 事故)、新增燈號需法源依據。只記問題,精準。
創新 1 也正落在你的鎖上——Itron 做好/申請了(別人),不是提案人自己,所以 1 不是 0。尺度一致。
分數我沒有意見。主題11 未評的剩最後一件 #189,你給編號就繼續。
e36e3881 2026-09-11
[13:51] 助理：
三個網址讀完(免重複查證)。攤平給你。
## #83 事實
**是什麼**:5 人全畜試所。因應 2027 廚餘禁養豬,為廚餘黑豬(243 場、24.2 萬頭、68 億產值)做兩塊:
- **植物性剩餘物質查詢平台**:地圖呈現豆渣/酒糟等剩餘物在各縣市分布、距離(Google Maps API)、運輸碳排(環境部排放係數)。
- **飼料配方專家系統**:用 **LP/MILP/知識圖譜**,豬農輸入生長階段 + 可得剩餘物,一鍵算出符合營養、最低成本的配方(用畜試所 NRC/ARC/PIC/臺灣飼料成分手冊資料庫)。
Q5 誠實勾「否,已申請預算但本案非原計畫」(原計畫=發酵提高農副產物消化率的科學評估,本案加應用平台)。
## 既有系統(已讀網址)——兩塊都被覆蓋
1. **剩餘物地圖**:
- **環境部生物質平臺(biomass.moenv.gov.tw)**:已有**料源地圖**(資材/廢棄物產出分布 + 處理再利用分布),涵蓋農工副產物、數量與分布。
- **台經院 台灣生質循環加值平臺(agricycle)**:已是**剩餘資源媒合市集**,依地點列供給,末端用途含**飼料改良**。
→ #83 的查詢/媒合地圖,政府與智庫**都已上線**。
2. **最低成本配方**:**AFOS 等飼料配方軟體是成熟商用類別**(4000+ 用戶,含豬,最佳化引擎選最便宜且合營養的組合)。最低成本配方用 LP 是**數十年的教科書級 OR 應用**,不新。
3. 畜試所自己也**已有黑豬替代飼料配方範例**(附的既有資料就是畜試所的 PDF)。
→ #83 = 把**兩個各自已存在的東西**(料源地圖 + 最低成本配方)整合起來給黑豬轉型用。AI 評估:「整合為主,新意有限」。
## 問題
1. **兩塊各有既有系統**(如上),自有的是「整合 + 黑豬情境」。
2. **資料粒度打臉核心承諾**:環境部廢棄物申報統計是**縣市層級**,回答不了「在哪、多遠」——而「哪裡有、多少、多遠」正是平台主打(同 #189 靜態資料失準那一類)。
3. **加工物流才是難點,平台沒解**:豆渣易腐、需發酵設備與運輸;平台只顯示分布,不解決加工/物流。
4. **不需要的 AI / 過度設計**:LP/MILP **不是 AI**;知識圖譜只是名詞;用 **LLM 去解析結構化的政府 CSV** 是過度設計、還添解析錯誤風險(你一貫點的「能用演算法就不需要 AI」)。
5. **場域是自家畜試所總所,非真實豬場**;5 人全畜試所,**無豬農/客家社群/豆渣業者**參與。
6. **隱私**:牧場位置/配方/使用紀錄集中留存並送 Google Maps API;廢棄物申報資料可識別個別小廠商。
7. **正面(事實)**:Q5 誠實(自有研究的應用延伸);真政策問題(2027 禁養、68 億、黑豬文化);最低成本配方本身是有用且正確的技術(只是不新);畜試所有真領域專業與營養資料庫。
以上事實與問題攤平。你給分。
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 | | 你的評語「風控參數若由生成式模型決定，無法解釋與稽核」，治理仍滿分。 |
你要從哪一段開始？