=== e36e3881 2026-09-04 10:30 ===
[10:30] 評審：
下一個提案：#12 FireWater AI－智慧消防水源決策平台。
[10:31] 助理：
讀完了，並且查了兩個網頁。輪廓：
**同一個提案人。** #12 跟 #11 是同一人（洪義順、同電話、同信箱、同消防局），隊名不同。#12 是 #11 的**縮小版**：只做「消防水源」這一塊——火警定位後，依距離、管徑、供水能力、道路可達性、即時路況，推薦最佳供水點與行駛路線。
**縮小之後好很多。** 問題描述具體（巷弄、山區、工業區找不到合適水源會延誤供水），範圍單一，AI 評估也不再判它 `substantive_junk`。這是他兩件裡比較誠實的一件。
**但他自己的局裡已經有這套系統了。** 我開了 AI 評估附的兩個網址：
- `water.tccfd.gov.tw` 是臺中市消防局的「消防資訊系統」登入頁，開發廠商是築夢園資訊科技，頁面上還有一個「水公司登入」連結——代表自來水公司也在這套系統裡更新水源資料。
- 築夢園的產品頁列出的模組包括「**消防水源管理系統**」「**消防水源整合衛星導航**」「**GIS 水源、建物地理資訊系統**」，廠商自稱已導入 17 個縣市消防局。
他的問題描述說「消防水源資訊雖已建置於不同系統，但缺乏結合 GIS 定位、導航、即時交通及智慧分析的整合決策工具」——而現有系統的名字就叫「水源整合衛星導航」。**所以真正的缺口只剩兩樣：即時路況、以及一個依條件排序的推薦。**這正是 #11 那個「第 N+1 個平台」的具體案例，只是這次規模小一點。
**剩下的新東西不需要 AI。** 「綜合距離、道路可達性、供水能力」排序可用水源，是加權排序；行駛路線是導航。這比 #11 更純粹地是一個確定性演算法問題，而且救災要的就是確定性——但工具欄還是寫生成式 AI、LLM、AI Agent。
**其他跟 #11 一樣**：一人、分工空白、Azure 用途空白、Markdown 粗體漏出、勾「全為原創無引用」、自備資料都是局內資料。這件沒有回應公民許願池。
**一個您可能會在意的程序問題**：同一人投兩件高度重疊的提案，如果兩件都進，等於一個人佔兩個名額；如果評分要分開看，#12 是明顯比較好的那一件。
[10:40] 評審：
同一人投兩件高度重疊的提案，如果兩件都進，等於一個人佔兩個名額；如果評分要分開看，#12 是明顯比較好的那一件。 => 你多慮了。第一件很爛。第二件我也不覺得會很高分。就算我一個人的評分不算數，還有其他評審，會顧慮同樣的「一人兩件進決審」的問題。而且還有初審評審會議，討論後會擋下來。我相信眾人的智慧。
[10:40] 助理：
了解，撤回這一點。程序上的把關有評審會議，不是單一評審在這裡要處理的事。
回到 #12 本身，我剩下的判斷只有一個：它跟 #11 同一個病（不需要 AI、局裡已有水源導航系統），但範圍縮小、問題真實，所以是同一個人的兩件裡比較誠實的一件。您決定分數。
[10:42] 評審：
LLM寫程式以後，沒有人想改善現有系統，大家都想重做，因為重做成本很低，對吧？ ^^;
[10:42] 助理：
對了一半，另一半更糟。
**對的一半**：LLM 把「從零寫出一個看起來能動的東西」的成本壓到近乎零，但「讀懂別人的系統再改」的成本幾乎沒降——理解一套沒文件的舊系統，LLM 幫得少，而且改壞的風險自己扛。成本結構一邊塌了，一邊沒動，理性選擇當然是重做。
**更糟的另一半**：重做便宜的只是前 80%。#12 的例子看得很清楚——現有系統裡有「水公司登入」，代表自來水公司在裡面更新消防栓狀態，這是跟另一個機關談出來的資料流，不是程式。重做的人三個月寫出一個漂亮的水源排序，然後消防栓故障沒人更新，一年後它的資料比舊系統還舊。**看得見的成本降了，看不見的成本一毛沒少**，只是被移到上線之後才付。
還有一層是公部門特有的：**舊系統是廠商的，根本不能改。** 築夢園的程式碼不在消防局手上，一個同仁想加即時路況，唯一開放給他的路就是另起一套。所以「大家都想重做」在公部門不只是 LLM 造成的心態，也是採購結構造成的——LLM 只是讓這條原本走不通的路突然走得通了。
最後，黑客松本身也在鼓勵這件事：「我幫既有系統加了即時路況」不會是一件提案，「FireWater AI 智慧決策平台」才是。所以您會一直看到重做。
[10:43] 評審：
同一人投兩件高度重疊的提案，如果兩件都進，等於一個人佔兩個名額；如果評分要分開看，#12 是明顯比較好的那一件。 => 你多慮了。#11很爛，我給的分數很低你沒注意到嗎？#12我也不覺得會很高分。就算我一個人的評分不算數，還有其他評審，會顧慮同樣的「一人兩件進決審」的問題。而且還有初審評審會議，討論後會擋下來。我相信眾人的智慧。
[10:43] 助理：
您說得對，我多慮了。程序面的事有評審會議處理，我只需要看內容。
[10:43] 助理：
記下了，之後只看內容。#12 請給分。
[10:43] 評審：
LLM寫程式以後，沒有人想改善現有系統，大家都想重做，因為重做成本很低，不用等預算發包執行，對吧？ ^^;
[10:44] 助理：
對，而且原因比「便宜」再深一層：**現有系統他根本改不了。**
那套水源系統是築夢園的產品，程式碼在廠商手上，要改一個排序功能得走需求變更、議價、驗收，等一年。對體制內的人來說，「改善現有系統」這條路實際上不存在，只有「等發包」跟「自己重做」兩條。以前自己重做要會寫程式，門檻擋掉了大多數人；現在 LLM 把門檻拆了，於是每個有痛點的人都可以重做一套。
但 LLM 降低的只是**看得見的那部分**——介面、程式碼。看不見的部分一毛錢都沒降：資料從哪裡來、誰負責更新、資安誰審、人調職後誰維護、跟原系統怎麼同步。重做的人看到的是「三個月就能做出來」，看不到的是「做出來之後要活多久」。
所以結果會是：公部門裡冒出一大堆能跑的原型，每個都比廠商系統好用一點點，每個都沒有維運預算，每個都在做的人離開之後死掉，死之前還會跟正式系統的資料對不上。這其實是二十年前 Excel 和 Access 影子系統的故事重演一遍，只是這次做出來的東西看起來像正式系統，更容易被誤信。
從評審的角度，這讓「盤點現有系統」變得比以前更重要，不是更不重要——因為重做的誘惑變大了，能說清楚「為什麼不能改現有的、我的東西跟現有的怎麼共存」的提案才真的有想過。
[15:20] 評審：
二十年前 Excel 和 Access 影子系統的故事是什麼？
[15:21] 助理：
就是「影子 IT」（shadow IT）／「終端使用者運算」（end-user computing）那段歷史。
**故事的形狀**：1990 到 2000 年代，公司和機關的資訊部門排程很慢，一個需求要排好幾個月。各單位的業務人員發現 Excel 和 Access 自己就能做——一個表單、幾個巨集、一個小資料庫，兩個禮拜就能解決自己的痛點。於是每個部門都長出自己的小系統，資訊部門完全不知道它們存在。
**然後發生的事**，跟我剛才描述的幾乎一樣：
- 這些小系統越做越大，慢慢變成業務不可或缺的東西——薪資計算、庫存、客戶名單、預算彙整都在裡面跑。
- 沒有文件、沒有版本控制、沒有測試、沒有備份。整個系統的知識在一個人腦子裡。
- 那個人調職或退休，接手的人不敢動，只能繼續用；壞了沒人會修。
- 資料跟正式系統對不上——同一個客戶在 ERP 裡是一個名字、在某人的 Access 裡是另一個名字，報表兩邊數字不同，沒人知道哪個對。
- 稽核進來，發現決策依據是一個沒人能驗證的試算表。
**幾個有名的案例**：
- 2012 年摩根大通「倫敦鯨」事件，風險模型用 Excel 手動複製貼上計算，公式錯誤低估了風險，損失數十億美元。
- 2013 年 Reinhart–Rogoff 的經濟學論文，主張國債超過 GDP 90% 會拖累成長，被各國拿來當撙節政策依據，後來發現 Excel 公式少算了幾列。
- 2020 年英國公共衛生署用舊版 Excel 彙整 COVID 檢測資料，超過 65,536 列的上限，近一萬六千筆確診資料被無聲地截掉，接觸者追蹤漏了一大片。
後來業界學到的教訓，是把 Excel／Access 視為「需要治理的系統」——盤點、登記、指定負責人、關鍵的要移入正式系統。
**跟現在的對應**：LLM 寫程式就是新一代的 Excel／Access。差別是這次做出來的東西有網頁、有 API、有登入畫面，看起來就像正式系統，所以更容易被信任、更難被辨認出是影子系統。而且以前 Excel 至少是在自己電腦上，現在直接部署到 Azure。
[16:59] 評審：
9/1/1/0/3「請先盤點現有系統。臺中市政府消防局消防水源管理系統已存在多年。」
[16:59] 助理：
加權總分 **3.43**（2.70 ＋ 0.28 ＋ 0.30 ＋ 0 ＋ 0.15）。
一個小提醒：我開的兩個頁面只能證實系統**存在**（消防局登入頁、廠商產品含水源管理與導航模組），頁面上沒有建置年份，「已存在多年」這一點我沒有查證到。若您是從別處知道的，沒問題；若不是，寫「已存在」比較穩。
=== 事後／並提討論 ===
c71e996e 2026-09-05
[09:55] 助理：
目前**同分不並列**:先依加權總分由高到低,同分時再依**申請編號由小到大**排,名次就是這個排序裏的位置。所以名次一定是連續唯一的 1、2、3…,不會出現兩個第 3 名。
例如三件都 8.40,申請編號 #12 / #45 / #78,名次就依序是第 3、第 4、第 5(不是三個並列第 3)。
e36e3881 2026-09-09
[02:08] 助理：
哈,這確實是個真問題,但按您自己立的規矩,不是您這一關要處理的。
回到 #11/#12 那次您教我的:一人兩件進決審會不會佔兩個名額、團隊分身乏術——這類程序問題交給其他評審和初審評審會議,眾人智慧會擋。您那時說得很清楚,我還記進了記憶。第四隊五件、可能好幾件進決審,是同一類問題,只是規模大一點:七個人要同時做 #179 洗產地、#181 紅火蟻、#183 重金屬三個都要跨機關、都要建模型的案子,決審前的實作量能撐不撐得住,是評審會議該衡量的,不是您逐案評分時要扣的。
您這一關的職責是:每一件就它自己的實質給分。#179 好就是好、#183 好就是好,不因為「同一隊已經有一件高分」而壓低另一件——那樣反而是用程序理由懲罰了實質。真的都進了決審、團隊分身乏術,會議會請他們自己取捨,或看實作進度自然淘汰。
所以誠實的答案是:您發現的這件事是對的,而且很可能真的會發生;但它正好落在您自己劃給「評審會議」的那一格,不落在「逐案評分」這一格。您繼續按實質給分就好。
e36e3881 2026-09-12
[01:08] 助理：
訊息核對一致。主題15 火災與消防,已評分:**#11 FireMind、#12 FireWater**(#131 未評,先不看)。這兩件我記憶檔裏有(同一位消防局圈內人的兩件重疊提案,#11 可行性 9)。派 subagent 撈 session log 的討論。
e36e3881 2026-09-12
[01:08] 助理：
已派 subagent 撈 #11、#12 的討論。回來我再 GET 兩件的原文和現值分數,讀懂邏輯就好。
e36e3881 2026-09-12
[01:12] 助理：
兩件原文讀完,現值確認:**#11、#12 都是 9/1/1/0/3 = 3.43**(subagent 說的 3.28 是算錯,API 確認 3.43)。
當時的邏輯我掌握了:同一位臺中消防局圈內人的兩件重疊提案(#12 是 #11 的水源切片),**可行性 9**(圈內人有資料、願自己動手做;有完整團隊/原型的反而違反創意原則不給 9)、**社會影響力 1**(只服務自己大隊、又是第 N+1 個整合孤島;#12 臺中水源系統已存在)、**創新 1**(整合儀表板既有、AI 用錯位)、多元 0、資料治理 3(內部派遣/PII/危險物品資料上公有雲、無機關授權、shadow IT)。
主題15 已評的就這兩件,**#131 未評(先不看)**——完整平衡等 #131 也評完再做。要進 #131 就給編號。
e36e3881 2026-09-12
[01:20] 助理：
兩個網址讀完。攤平給你。
## #131「「預」火重生」事實
**是什麼**:資源循環署主導的資源回收場**火災早期預警**。多感測融合(CCTV YOLO 辨危險物 + 紅外線熱影像升溫率 + CO/CO₂ 氣體)偵測**悶燒早於明火** → 三通道告警(工位三色燈/耳機語音/LINE),日夜雙模;另在進料端 YOLO 攔檢鋰電池等危險物。場域**五股細分選場**(確定),9 人政府+業者團隊。
**技術亮點(對黑客松是強項)**:**明確用邊緣 YOLO、排除雲端 VLM/LLM**,還講清楚為什麼不用(延遲 1–4 秒 > 採樣間隔、頻寬成本、斷線失效)——正是你一貫要的「用對工具、不硬塞 LLM」。CO 氣體早於煙偵測悶燒有科學依據(EN 54、Solórzano 2022)。真問題(90 通報案件、鋰電池、40%+ 夜間火災)。
## 既有系統(已讀網址)
- **Fire Rover(美,已部署商用)**:熱像 + 煙 + 火焰**多階段早期偵測**,回收/廢棄物場,悶燒前即抓、24/7。= #131 的核心偵測。
- **JFE Smoke AI(日,2021 已部署)**:AI 影像偵測垃圾坑煙/火,**專攻鋰電池火災**(同問題)、連動自動撒水。= #131 的核心。
- → AI 評估「**整合重製**」。#131 相對它們的區隔:**CO/CO₂ 氣體融合**(更早偵測悶燒,但技術本身既有)、**進料危險物 YOLO**(源頭攔檢 vs 事後偵測)、**三通道告警 + 政府聯防 + 稽查數據**(在地治理層)、資源循環署主導 + 確定場域。
## 問題
1. **概念既有**:Fire Rover(美)+ JFE Smoke AI(日)已做回收場 AI 早期火災預警(且 JFE 同樣專攻鋰電池)。#131 屬在地化整合 + CO 氣體/進料攔檢的增補。
2. **8 週無真實火災樣本**:只做加熱模擬,「秒級預警、低誤報」**沒有基線**可驗證偵測率/誤報率。
3. **地端 vs 雲端矛盾**:宣稱地端排除雲 LLM,卻又申請國網雲算力;VLM 自動標註恐把場域影像上雲。
4. **職場監控**:監控「人員危險行為」+ 稽查數據 = 職場監控;車牌/車流可識別個人(雖稱不做人臉)。
5. **廠商鎖定/利益衝突**:技術依賴大豐、晶淨(業者隊員)。
6. **根源未處理**:真正源頭(民眾未分類、鋰電池混入)沒解,是下游偵測而非源頭預防。
7. **隱私**:業者堆置量屬營業機密;LINE 經第三方。
同主題事實(供平衡,不排序):主題15 三件,**#131 是政府主導、有真場域、技術紮實(且 AI 用對)的一件**;#11/#12 是一人的 N+1 整合平台(9/1/1/0/3)。#131 的主要弱點是概念既有(Fire Rover/JFE)。
以上事實與問題攤平。你給分。
e36e3881 2026-09-12
[02:04] 助理：
加權總分 **4.65**(5×.30 + 5×.28 + 4×.30 + 7×.05 + 4×.05 = 1.50+1.40+1.20+0.35+0.20)。
評語兩點都準,而且正好抓到「新的不穩、穩的不新」:內置鋰電池難以視覺辨識(進料攔檢那半的物理限制)、熱像儀偵測燃燒很普遍(悶燒偵測那半是既有 Fire Rover/JFE)。各維度我沒有意見:可行性 5(悶燒偵測那半可行 + 有確定場域/邊緣 YOLO 用對,但進料攔檢受限 + 8 週無真火樣本)、創新 4(在地化 Fire Rover/JFE + 模糊增補,不新不純抄)、社會影響力 5(火災/空污/職安價值,但職場監控/廠商鎖定/根源未解拉回)、多元 7、資料治理 4 都對得上。
主題15 三件全評完了:**#131(4.65) > #11(3.43) = #12(3.43)**。要做這 3 件的給分平衡回顧,你說一聲。
e36e3881 2026-09-12
[02:05] 助理：
主題15 排序:#131(4.65) > #11(3.43) = #12(3.43)。三件原文都讀過、在脈絡裏,不重抓。
**結論:平衡成立,不需要調整。**
我特別對的一個**反直覺點**——**可行性:#131=5 竟低於 #11/#12=9**(一件認真的政府提案、有真場域,可行性卻低於兩件一人的 N+1 平台)。但用你的定義核下來它站得住:
- 你的可行性 = **「做法能否達成提案目的」**。
- **#11/#12=9**:圈內人(消防局)有資料、有能力,**做得出他描述的整合平台、也確實會做到「整合資訊」這個目的**——目的達成。它的「沒用/是第 N+1 個孤島」你放進**社會影響力 1**,不是可行性。而且 **#11 本來就是你「圈內人→可行性 9」這條原則的錨定案例**(記憶檔裏就是拿 #11 立的)。
- **#131=5**:它的**悶燒偵測那半達得到**(早期預警成立),但**進料攔檢那半達不到目的**(相機看不到藏起來的電池——正是主要危險),加上 8 週無真火樣本。所以是**部分達標**→ 5。
所以「9 vs 5」= 「完全達成(即使冗餘)的既有目的」 vs 「只達成一半的目的」——在你的定義下自洽,雖然直覺上刺眼。要不要因為 #131 是認真提案而覺得這個反差需要動,是你的心證;我指出這個反直覺點 + 它為何自洽,不主張改。
其餘一致:社會影響力(#131=5 公共火災/空污價值 >> #11/#12=1 只服務自己、N+1 孤島)、創新(#131=4 在地化+增補 > #11/#12=1 純既有)、多元(#131=7 跨域 > 0)、資料治理都對得上。不動。
c84bcc28 2026-09-12
[09:06] 助理：
主題16 排序:#79(3.29) > #162(3.16) > #21(0.00)。三件都在脈絡裏,不重抓。
**結論:平衡成立,不需要調整。** 整個主題偏弱,三件是三種不同的弱法。
逐維核過,兩個乍看會刺眼的點都在你的框架內自洽:
- **可行性 #162=8 > #79=3**:#162 的做法(移動式懸吊充電樁服務多格)**已被中國商轉證明做得到**——「做法能否達成目的」是肯定的,所以高;它的低分落在創新 0(賣自己的產品)和影響 2。#79 則是**水那半根本不服務災害目的**、場址未定、8 週塞硬體——只達成一半。和主題15「#11/#12=9 > #131=5」是同一套邏輯:能達成自己所稱目的的給高,價值歸到影響/創新去扣。
- **社會影響力 #79=3 > #162=2**:#79 若實現,服務的是莫拉克災區/原民鄉的水電韌性(你加分的對象),但被空的水站、台電已在做、二手電池安全拉回到 3;#162 若實現,是替公寓住戶解禁裝——真問題,但它是已有市場裏多一個廠商的產品,又有「滿時單方斷電」的負面,給 2。弱勢災區 > 都會便利產品,方向和你的定義一致。
- **創新 #79=4 > #162=0 = #21=0**:#79「好歹是個水站」(台灣無先例的組合 + 退役電池),#162 賣自己既有產品,#21 空——這條你都定過了,不動。
- 多元(#79=3、其餘 0)、資料治理(#79=#162=4 都是 OT 無資安、#21=0)一致。
不動。
c84bcc28 2026-09-13
[16:29] 助理：
第一步結果：
**整體沒有漂移。** 9/10 前評的 118 案平均總分 3.72，9/11 起的 63 案 3.82；可行性 4.7→5.0、影響力 3.8→3.9、創新 3.2→2.9，都在一般波動內。多元性 2.1→3.2 上升、治理 4.0→3.4 下降，但 9/8 那天評了徐朝峰八案與凌誠系列（一人案多），拉低了早期多元性；治理下降對應 9/12 你把「用不必要的區塊鏈／LLM」算進治理扣分之後。這兩項是標準明確化，不是漂移。
**三件具體的：**
1. **創新 0 的 9/12 分界。** 你 9/12 定了「0＝自家已做好、1＝別人做好了」，並把 #88、#91、#161 從 0 調成 1。9/12 前評的創新 0 還有 28 案沒動過。從評語看，屬於「別人做好了」那一型、依同樣規則該是 1 的有 13 案：
#41（運研所無人機計畫）、#61（很多廠商在做）、#68（國土監測）、#69（生質循環平臺）、#72（ChatGPT 可做）、#78（Meshtastic）、#86（樂活氣象、酷齡）、#92（政府現行業務）、#95（電商很多）、#166（旅遊網站很多）、#185（各縣市專案很多）、#215（食藥小幫手）、#118（Deepfake 無有效偵測——這件比較像「做不到」，你判斷）。
其餘 15 案是自家既有／已完成／研究／產品／政策試點／AI 雜訊，0 對得上規則。
2. **影響力 0 集中在今天。** 全部 14 案影響力 0，8 案是 9/13 評的（#105、#108、#121、#132、#160、#186、#220、#227），理由是隱私負面、有無害替代、不合法、政策提議。9/12 前只用在「AI 判不出來」或「特種個資無法源」那種（#63、#104、#173、#198、#222）。今天的用法比較嚴；早期有隱私負面的案子（例如 #15 鏈上永久存證＋無人機拍鄰居給 3、#66 給 3）沒用同樣的標準。要嘛接受今天的較嚴，要嘛回頭看早期幾件。
3. **可行性 9/11 定義。** 9/11 前評、可行性 ≥7 但影響力 ≤2 的只有 5 案：#11、#12（消防第 N+1 平台，各 9）、#72、#73、#122。#73、#122 你今天已確認過；#72 拍蛋 8 分是「做得出來」。#11、#12 是 9/4 評的最早一批，可行性 9 是舊定義。
其他：#195 多元性 0 是因為四格成員是 XXXX，沒問題。
第 1 項你要不要一次處理？我可以把 13 案的評語與分數再列一次讓你逐案決定。
c84bcc28 2026-09-13
[16:40] 助理：
1. 了解，#41 是前幾年得獎團隊重投、法規過不了——依「去年得過獎就不用了」的規則 0 維持。其餘 12 案要不要逐案看，你決定。
2. 了解，是今天題材的組成，不是標準變嚴。
3. 第 3 項的問題是：9/11 你把可行性的定義說清楚——「提案的做法能不能達成提案的目的」，不是「做不做得出來」。#11、#12 是 9/4 評的，可行性各 9，當時的邏輯是「一個消防資訊平台一定做得出來」。用新定義看：#11 的目的是消防決策、#12 是消防水源決策，做法是再建一個整合平台——平台做出來確實能做決策，目的達得到，只是跟現有的重複；重複是創新與影響力的問題，不是可行性的問題。所以 9 在新定義下也站得住。#72 同理（幫消費者挑蛋，做得到）。
也就是第 3 項查出來沒有需要改的，只是把最早那批對過一次。
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 | | 你的評語「風控參數若由生成式模型決定，無法解釋與稽核」，治理仍滿分。 |
你要從哪一段開始？
c84bcc28 2026-09-13
[22:51] 評審：
分數平衡有調整。除了已調整的以外：
創新：
#15：是因為同類型做過所以創新。
#12：是要自幹一套隊上現有系統，加自己要的功能，不是拿隊上現有系統來參賽。
#22：要建立模型；#239只是自動灌溉。
#164：建議拿現有模型訓練，是從現有進步；#72多模態LLM已經做得到了，根本不需要做。
可行性：
#153：不符現在台灣蛋價的決定方式；#232沒有市場的問題。
社會影響力：
#78：是因為沒什麼問題才沒給評語；#152價值不高；#11同類型系統太多了，沒有附加價值。
#10：別人都做了，它做這個沒有額外的社會影響力。
#129：是傷害當事人的問題；#94是當事人不當得利的問題。問題性質不同。
#131：對人的影響力；#131對垃圾的影響力；#153 100%做出來也難以預測價格。
#108：噴藥對環境有害。
#109：對勞工有利額外加分；#72對買蛋的消費者有利，範圍很小。
#65：沒有問題；#121就算上鏈也無法證明什麼。
#86：加分回來；#238地方創生額外加分。
資料治理：
#3：扣分回來；#126取得不必要的臉部資料，不管有沒有送AI。
還有什麼問題？
c84bcc28 2026-09-13
[22:52] 評審：
分數平衡有調整。除了已調整的以外：
創新：
#12：是要自幹一套隊上現有系統，加自己要的功能，不是拿隊上現有系統來參賽。
#22：要建立模型；#239只是自動灌溉。
#164：建議拿現有模型訓練，是從現有進步；#72多模態LLM已經做得到了，根本不需要做。
可行性：
#153：不符現在台灣蛋價的決定方式；#232沒有市場的問題。
社會影響力：
#78：是因為沒什麼問題才沒給評語；#152價值不高；#11同類型系統太多了，沒有附加價值。
#10：別人都做了，它做這個沒有額外的社會影響力。
#129：是傷害當事人的問題；#94是當事人不當得利的問題。問題性質不同。
#131：對人的影響力；#131對垃圾的影響力；#153 100%做出來也難以預測價格。
#108：噴藥對環境有害。
#109：對勞工有利額外加分；#72對買蛋的消費者有利，範圍很小。
#65：沒有問題；#121就算上鏈也無法證明什麼。
#86：加分回來；#238地方創生額外加分。
資料治理：
#3：扣分回來；#126取得不必要的臉部資料，不管有沒有送AI。
還有什麼問題？
c71e996e 2026-09-14
[19:48] 助理：
建議這樣做：
**欄位**：`PreliminaryReview.discussion`（`Text | None`，唯讀），存純文字逐字稿；只在detail頁顯示（`<pre>`或依段落），list頁和API不動（`GET /api/proposals/<id>`的`my_review`可以帶，方便日後查）。
**來源**：一個離線builder＋一個匯入command，和其他資料一樣：
- `flask build-discussions <session_dir>`：讀指定的session jsonl（你給的兩個），只取user和assistant的文字turn（略過tool call/tool result/task notification/compaction摘要），依「下一個提案：#N」、「#N」這類切換句切段，每段歸到一個申請編號；同一案跨session或重複討論就依時間接在後面。輸出`data/discussions.json`（`[{id, discussion}]`）——**這個檔不進git**（內容是逐字稿，含提案人資訊和你的私下判斷），放`excludes/`當command參數。
- `flask import-discussions <file>`：寫入`preliminary_reviews.discussion`，只動這一欄，不碰分數。
**難點**：切段的邊界。你的session有「下一個提案：#12 …」這種明確句，但也有主題模式（一次談5案）和平衡時多案並提，用規則切會有漏或錯歸。建議builder先跑一次、輸出每段的歸屬和前兩行讓你抽查，不對的用一個小的override清單（`turn範圍→申請編號`）修正，再匯入。不建議用LLM切——逐字紀錄要的是精確，不是判斷。
**遷移**：`ALTER TABLE preliminary_reviews ADD COLUMN discussion TEXT`（備份、md5核對照舊）。
要動手就說一聲；動手前我會先做一次乾跑，把切段結果給你抽查。