=== e36e3881 2026-09-05 08:08 ===
[08:08] 評審：
下一案：#16「AgriFlow Signal：讓農產品產銷壓力提早被看見」。
[08:09] 助理：
四個來源都開了。輪廓：
**它是什麼**：兩人團隊，用農業部甘藍交易行情公開資料（2022–2025，22,970 筆），做一個給**農政、農會、市場人員**看的觀測網頁：先把休市、缺值、品種、單位分乾淨，再用同月歷史建季節基準，看價量偏離是否持續、多個市場是同步還是分化，可回放歷史狀態，每次結果附一張「市場觀測卡」——來源、涉及市場、資料完整性、可信程度、**不能下的結論**、下一步該查什麼。不預測價格、不判因果、不自動決策。分析核心沿用他們自己得過獎的「低熵核心」元件。
**查證結果**
- **既有計畫**：中央社 2026/07/06 證實「低熵核心」是數發部防災積木元件創新賽六個獲選團隊之一，做的是「防災通報資料標準化與熱區分析元件」。提案自己揭露了，而且拿防災的資料品質元件來做農產品，是合理的重用，不是同一個案子。
- **類似既有案**——AI 說「僅加觀測卡與回放，屬改寫」，**大致成立**：
- 「當季好蔬果」（twfood.cc）：甘藍有 1.5 年週趨勢、1 年日趨勢、5 年與 20 年月／年趨勢，有「批發市場成交量比較」「批發市場價格比較」。
- 「白菜即時」（cabbagelive.com）：12 個批發市場，「價格溫度計」顏色訊號、跨市場比較與交易量趨勢、年基準與同期比較、氣象整合、AI 短評。
- 農業部「田邊好幫手」：甘藍出苗量推估、當旬警示燈號、近三年同期比較——**官方供給端的超種警示本來就有**。
所以「跨市場價量比較、季節基準、顏色訊號」三件事，民間和官方都已經有了。#16 真正多出來的是：休市與缺值的**語意處理**、「同步 vs 分化」的判讀、狀態轉換回放、以及附來源與限制的觀測卡。這是一層「證據品質」，對象是要開會、要查核的公務員，不是農民或消費者。
**需要您判斷的**
1. **它新的部分是「嚴謹」，不是「功能」。** 既有工具是給農民選市場、給消費者看菜價；它是給農政人員開會前整理證據用的。這算不算創新，看您怎麼定義——功能面它是改寫，工作流面它是不同的使用者。
2. **落地跟 #14 同一個弱點**：使用者是農政、農會、市場人員，但沒有任何具名夥伴，「邀請至少 2 類實務角色審閱 3 輪」是計畫不是承諾。比 #14 好的是它有排使用者測試。
3. 寫法跟 #14 是同一種免責堆疊的腔調（「不宣稱、不取代、不自動」），但內容具體：期程寫到日期、資料筆數寫到個位。
4. 只做甘藍四個市場；第二位成員只寫一個「鄭」字；分工欄空白；Azure 用途空白。
5. 有回應公民許願池（「颱風季來了！農產品供應正常嗎？」）——不過那是民眾的問題，它的使用者是公務員，回應得算間接。
6. 產品裡沒有 AI，純規則統計——跟您的原則一致。
AI 評估：`substantive_junk = false`。
[08:23] 評審：
觀測卡和回放是什麼？提案有說嗎？這個的創新點在哪裏？
[08:23] 助理：
**提案有說，但只說到「欄位清單」的程度，沒有任何範例或畫面。**
**市場觀測卡**：提案原文是「市場觀測卡所列的來源、涉及市場、資料完整性、可信程度、不能直接下的結論及下一步查核建議」。也就是每一個「偵測到偏離」的結果旁邊附一張卡，寫清楚：這個判斷用了哪些市場的資料、資料缺了多少、有多可信、**這個結果不能拿來說什麼**（例如「批發市場交易量不等於全國產量」「休市不等於零交易」「因果未證實」）、接下來該去查什麼（農情調查？氣象？政策公告？）。
**歷史回放**：原文是「使用者可回放特定期間的市場狀態轉換」。意思是選一段過去的時間（例如某次颱風前後），看系統當時會怎麼判——市場從正常到偏離、到持續偏離、到多市場同步——一步一步重演。用途是拿歷史事件驗證規則有沒有道理，也讓公務員對照「當時實際發生了什麼」。
但提案**沒有定義「市場狀態」有哪幾種**，也沒有一張觀測卡長什麼樣的例子。這兩個東西目前是兩句話，不是設計。
**創新點在哪**
不在功能，在**知識論的層次**——它關心的不是「訊號是什麼」，是「這個訊號可以信到什麼程度、不能拿去說什麼」。
對照既有工具：「白菜即時」給你一個顏色溫度計加一段 AI 短評，你不知道它怎麼算的、資料缺不缺、休市怎麼處理。農民選市場用這個夠了。但一個農政人員要在會議上說「多個市場同步出現壓力」，他需要的是可以被質問的證據：哪幾個市場、幾天、跟哪幾年同期比、缺值多少、還有什麼沒排除。#16 做的就是這一層。
它的創新可以濃縮成三件事：
1. **資料語意先於分析**：休市、缺值、品種、單位分開處理，這是既有工具都沒明說的。
2. **訊號定義是「持續」和「跨市場同步／分化」**，不是單日單市場的漲跌。
3. **每個結果附帶自己的限制**，讓人工研判有依據，而不是替人判斷。
這是「把公開資料變成可以在公部門引用的證據」，跟前面幾件「把公開資料變成一個儀表板」是不同的目標。價值是真的，但很安靜，也很薄——它的全部產出可能就是一個網頁加幾張卡。
[08:25] 評審：
6/4/4/1/3 no comment 如何？
[08:25] 助理：
加權總分 **4.32**（1.80 ＋ 1.12 ＋ 1.20 ＋ 0.05 ＋ 0.15）。
可行性 6、社會影響力 4、創新性 4、多元性 1 我都沒有意見。
**資料治理 3** 想確認一次：這件的資料處理寫法跟 #14 是同一個等級——保留原始檔與取得時間、分層保存、版本可重現、休市與缺值的語意明確、未來場域資料採最小必要與去識別、公開只給附限制的彙整結果。#14 您給了 10。如果 3 是刻意的（例如 Azure 用途空白、或是您對它另有看法），我不再提；如果是筆誤，7–8 比較接近 #14 的標準。
[08:26] 評審：
6/4/4/1/10 no comment 如何？
[08:26] 助理：
加權總分 **4.67**（1.80 ＋ 1.12 ＋
[08:26] 評審：
6/4/4/1/8 no comment 如何？
[08:26] 助理：
加權總分 **4.57**（1.80 ＋ 1.12 ＋ 1.20 ＋ 0.05 ＋ 0.40）。
跟 #14 對照是一致的：兩件都是誠實、資料治理強、產出薄；這件多了排定的使用者測試和具體的工作流對象，可行性高一些，合理。
=== 事後／並提討論 ===
c71e996e 2026-09-03
[12:37] 助理：
收緊定義**大有成效**,而且 **#114 修正回 `true`** 了(專利 I907022)。
**目前 `suspected_existing:true` 共 48 件(收緊後新增 28 件)。** 這 28 件新翻出來的:
- #14 RZVN 服務已營運、含語料與 6 套 DOI 研究框架
- #16 低熵核心引擎為既有並獲數發部防災賽獲選
- #20 教育部校園食材登錄平臺 2.0 已有家長查詢/下架通知
- #21 社區型儲能備援為既有技術、已有部署與專利
- #23 AI 誘捕籠已有 Wild Vision Systems 產品
- #32 核心「反向比對」源自該隊 2020 防疫松獲獎平台
- #38 AI 修剪指引已有 SmartPrune AI 等商品
- #40 緊急車輛讓路警示已有 HAAS Alert、Waze
- #51 大坪頂灌溉示範已由農水署執行、含智慧灌溉、已編預算
- #55 風波整合＋TENG 已有論文專利、已做 1/10 縮尺實測
- #58 自稱系統已上線(無外部佐證)
- #61 勝美金食品已營運、與農試所合作
- #62 AI 蜜罐蒐集詐團金流已有商用 Apate.ai
- #64 剩餘乳回收蛋白轉飼料為既有技術、多篇論文專利
- #67 桃園農水處已有圳路即時監測與智慧調度
- #73 微藻人工樹碳匯已發表論文、延續 2025 既有提案
- #74 團隊既有永續電廠研究延伸、已有 LCA/TEA 與論文
- #86 環境部「酷齡氣候關懷」已運作 AI 高溫預警＋LINE 通報
- #90 進口碳足跡比較已有 CarbonChain 等 CBAM 商品
- #103 建築健康履歷(結構健康監測)已有商用與論文
- #104 農糧署天然災害現地照相 App 已有地號取證
- #108 AI 辨識福壽螺精準施藥已有無人機驗證論文
- #113 核心已有美國專利 US12361824B2
- #114 已獲我國專利 I907022、申請美國專利
- #115 核心為申請人賽前已申請的五項專利連鎖
- #118 核心為提案人三件申請中專利
- #120 情境化政府補助推薦已有營運平台
- #123 核心即艾弗思與成大合作之智能清洗系統、已商用
**額度耗盡,已停:完成 83 / 159,剩 76 件**(這 76 件還沒套收緊定義,可能再翻出更多)。繼續時跑:
`127,128,129,131,132,134,152,154,155,156,158,160,161,162,164,165,166,167,168,171,172,173,174,175,177,178,179,180,181,182,183,184,185,186,187,188,189,191,192,195,196,197,198,199,200,201,203,204,206,207,208,209,210,211,213,214,215,216,217,218,219,221,222,223,226,227,228,230,231,232,233,234,235,237,238,239`
c71e996e 2026-09-03
[13:14] 助理：
**全部 179 件 existing 完成(收緊定義)。`suspected_existing:true` 共 65 件**(窄定義時是 20,收緊後多抓 45 件)。這 65 件疑似「拿既有成果/專利/論文/已上線產品假裝構想」:
#14 RZVN已營運＋DOI研究框架｜#16 低熵核心引擎既有獲獎｜#20 教育部校園食材登錄2.0已有｜#21 社區儲能備援既有技術＋專利｜#23 AI誘捕籠已有Wild Vision產品｜#32 反向比對源自2020防疫松獲獎｜#35 科技小農已營運社企｜#36 WoHere已有官網＋SBIR｜#38 SmartPrune AI已有｜#40 讓路警示已有HAAS/Waze｜#51 大坪頂灌溉已由農水署執行編預算｜#55 TENG已有論文專利＋縮尺實測｜#58 自稱已上線｜#59 路殺社AI警示已運作｜#61 勝美金食品已營運｜#62 蜜罐已有Apate.ai｜#64 剩餘乳轉飼料既有｜#67 桃園農水處已有智慧調度｜#68 國土利用監測2014起功能相同｜#69 農業剩餘資源平臺重疊
#73 微藻碳匯已發表＋延續2025提案｜#74 永續電廠研究延伸＋論文｜#81 H3穿戴碩論已發表｜#86 環境部酷齡氣候關懷已運作｜#90 碳足跡已有CarbonChain｜#97 pet-guard已上線｜#101 Pwaver-SHM商用｜#103 建築健康履歷已有商用｜#104 農糧署災害照相App已有｜#105 jidanni.org門牌專案已發表｜#108 福壽螺辨識已有論文｜#113 已有美國專利US12361824B2｜#114 已獲我國專利I907022｜#115 賽前已申請五項專利｜#118 三件申請中專利｜#120 政府補助推薦已有平台｜#123 艾弗思×成大清洗系統已商用｜#128 林試所在行計畫＋農改場成果｜#130 Sim Check超級臉既有｜#131 合作廠商既有平台＋Fire Rover
#134 智能耳聰鳥音辨識App已上架｜#157 Meshtastic Taiwan已運作｜#161 遮蔭導航已有CoolWalks＋三城實證｜#162 自有專利M652280｜#173 污泥產氫已有論文＋數位孿生｜#175 眼動查生字已有EyeLingo論文｜#176 腦靈活331已營運｜#177 詐騙情資已有Apate上線｜#178 進行中MOU＋楊梅水資中心實測｜#187 雷達生理監測師大實驗室既有｜#190 國科會晶創計畫＋已部署｜#196 ET0灌溉高改場已技轉｜#197 AIoT水質獲獎量產移植｜#202 航港局海運無障礙已上線｜#203 RGB-T機器人IEEE論文＋國科會成果｜#205 格園社企農電共生專利已商用｜#211 低熵核心防災賽獲獎｜#212 平台已上線自承既有｜#214 NSTC補助＋MOU＋已啟動｜#218 已入選南投黑客松原型
#220 ConanCase拿趣科技既有｜#224 零廢敬媽祖已運作｜#227 家暴蒐證APP已有UNDERCOVER等｜#236 萬穗寶已獲FITI獎量產
（existing 尚未匯進 DB;下一步照 proposals.json 流程,用 `build_ai_assessments_json.py` 把 content＋existing 合併重建 `ai_assessments.json` 再 import,existing 才會進 `ai_assessment` 表與 UI。）
e36e3881 2026-09-05
[09:10] 助理：
加權總分 **6.82**（1.80 ＋ 2.52 ＋ 2.10 ＋ 0.10 ＋ 0.30）。這會是目前最高分。
社會影響力 9 用鼓勵方向的邏輯說得通，評語兩句也對。兩個一致性的提醒，各說一次：
1. **創新性 7 vs #3 的 3**。#3 因為「就是日本 CCRC、沒有新解方」從 7 降到 3；#19 有 CoopCycle 在前，但它多了幾個 CoopCycle 沒有的機制（天候加價、店內價約束、顧客自訂運費、互助金），不是純複製。7 比 #3 高是有理由的，只是幅度大了些，5–6 會比較貼近「重組」。
2. **可行性 6**。經濟模型不成立、冷啟動無解、「已完成 70–80%」無法驗證。跟 #16 同樣是 6，但 #16 的落地路徑（有日期、有使用者審閱）比這件清楚很多。
評語沒有寫到「天候加價與勞安矛盾」——題目就叫「結合天候與勞安」，而它的天候機制正好跟勞安相反，這是它最該知道的一句。要不要加，由您決定。
e36e3881 2026-09-05
[10:05] 助理：
查完了：五個「類似既有案」來源、加上對公司的兩次搜尋。輪廓：
**它是什麼**：一家企業 AI 公司（鏈加科技 Plusblocks，四人全是自家員工）提案，把農糧署現行的大宗蔬菜**供苗預警燈號**升級成「供需雙向」的決策支援：一、供給預測（供苗旬報＋農情＋氣象）；二、**需求端訊號**——用批發市場價量共變拆解衝擊來源（量增價跌是供給過剩、量平價跌是需求走弱）；三、拿歷次調節措施紀錄做回測，量化「提前 N 天介入可少耕鋤幾公頃、省多少補償」；四、用自家的 NL2SQL 引擎做中文查詢介面。導入分三階段（唯讀平行 → 建議＋人工核定 → 常態）。期程寫到日期（9/18–11/10），資源寫到人（工程 2、架構 1、PM 1）。有回應許願池（菜價波動、農民收入、糧食浪費）。提案文用 Claude 草擬，有揭露。
**查證**
- **農糧署機制**（農業部 2010 頁、農糧署 2023 頁、2026/9/4 更新的燈號頁）：現行機制是育苗場每旬回報供苗量（8 月到隔年 2 月），跟近三年同期比，分綠黃紅紫四色燈；紫燈就發簡訊、LINE 勸農民減種；種植登記每旬有上限（甘藍 200 公頃），超過就啟動耕鋤補償（登記者 7 萬／公頃、未登記 4 萬）。**三個官方頁面都沒有需求端指標、價格預測或決策支援**——提案說「現行僅供給端單變數燈號」是準確的。補償金額也對得上。
- **台大農經 2021 碩士論文**：LSTM 預測結球白菜（不是甘藍）西螺市場價格，日波動超過 5% 就失準；沒有需求拆解、沒有政策回測。這是「價格預測有人做過」，但跟本案的核心不同。
- **白菜即時 seasonal 頁**：給消費者看的當日行情快照加 AI 短評，不是給農政單位的決策工具。
- **公司**：鏈加科技是真的，CEO 郭谷彰，「零資料接觸架構」（Schema-Only Context、Query Proxy、Result Sanitizer）在 iThome 2026 AI Enterprise Summit 有一場演講；媒體說部署超過 800 個據點。**「臺灣港務公司實證」和「美國專利申請中」我查不到，無法驗證。**
所以 AI 說的「類似既有案」是元件層次的——燈號、價格預測、行情 App 各自存在；本案主打的「需求端拆解＋介入回測」在這些來源裡都沒有。**這是目前看到的農業案裡，跟既有系統差異最實在的一件**，跟 #16（給公務員的證據層）和 #20（官方已有）都不同。
**需要您判斷的**
1. **統計上的識別問題。** 用價量共變拆供需衝擊是計量經濟的老題目，需要結構假設；批發市場只看到一部分流通（進口、冷藏庫存、直銷、團膳都繞過市場），拆出來的「需求走弱」可能是別的東西。他們有意識到——資料需求裡要了殘貨量、直銷量、庫存——但只用近年二至三次失衡事件回測，很容易過擬合。而且現行機制的節奏是「旬」，「提前 N 天」在十天一格的制度裡意義有多大，要看 N。
2. **「零資料架構」被說大了。** 零資料保護的是 LLM 查詢那一層；供給預測和價量拆解是 sklearn 模型，**一定要讀原始數值**。但提案有幾處寫「全案採零資料架構」「農民個資於架構層即受保護」。而它索取的正是預警系統的**原始申報資料**（含農民登記與補償金額）。這是資料治理上最該問的一點。
3. **NL2SQL 是自家產品的置入。** 需求拆解和回測是真正有價值的部分，用的是傳統統計，恰當；中文查詢介面對農政人員是錦上添花，儀表板就夠了。跟您的原則對照：AI 用在不必要的地方，但它是周邊不是核心。
4. **場域是「申請中」。** 「已依大會場域媒合機制向農糧署提出合作申請」——沒有確認；成員表把一位自家員工填成「落地／實驗場域單位（確定合作）」，這是填表取巧。
5. 耕鋤是政治敏感的決策，量化建議會給它一種「客觀」的外衣；預警錯了，成本落在被勸減種的農民身上。提案承諾「僅以回測結果陳述、不預先宣稱成效」，這點誠實。
6. 四人同一家公司，沒有農經專業（自己也勾了要農經諮詢）；分工欄空白但期程有寫人力；GCP、Azure 用途空白。
AI 評估：`substantive_junk = false`，`similar_existing = true`（元件層次）。
e36e3881 2026-09-05
[22:51] 助理：
加權總分 **6.76**（2.10 ＋ 1.96 ＋ 2.40 ＋ 0 ＋ 0.30），僅次於 #19 的 6.82。
分數上只有一處想確認：**多元性 0**。#10 兩人同一家公司給了 2、#16 兩人（一位匿名）給了 1，這件四人同一家公司、有具名有分工，給 0 比那兩件低。若 0 是因為「四人全是同公司、零農業背景」，說得通，只是跟 #10 的標準要對得起來。
no comment 可以，但如果只寫一句，我會寫「零資料架構僅保護查詢層，預測模型仍需讀取原始申報資料」——這是它最該被問、也最可能在決審被問的一點。
e36e3881 2026-09-06
[12:02] 助理：
加權總分 **8.04**（2.70 ＋ 2.24 ＋ 2.40 ＋ 0.40 ＋ 0.30）。目前最高，領先第二名（#19 的 6.82）一大截。
社會影響力 8、創新性 8、多元性 8 我沒有意見。兩項想確認：
- **可行性 9**：它的落地設計是好的（協辦模式、導回公所），但沒有工程師、場域沒名字、期程超出賽期。#11 的 9 是因為人已經在場域裡、資料在手上；這件是「知道怎麼落地，但還不確定誰來做、在哪做」。以您的定義，我會落在 6–7。
- **資料治理 6**：每筆補助標來源與查核日、資格判定不交給 LLM、公文影像即刪、國網不出境、schema 開源、未開放資料只當驗證不當前提——這比 #16 的 8 完整，接近 #14 的 10。6 偏低。
兩項都是您的決定，我只提一次。
e36e3881 2026-09-07
[00:31] 助理：
三個來源都開了。輪廓：
**它是什麼**：一人提案（新竹縣政府農業處技士），從**自己一次真實的網路交友互動**出發——聊了一段時間、對方沒有明顯破綻、但某些說法不對勁，她用 ChatGPT 和 Gemini 分析對話、反向搜圖、查公開資訊，過程中發現 AI 很會整理，但也會把有限線索講成很有道理的推論。提案就是把這套經驗變成一般人能用的查證流程：AI 先幫忙整理長時間的對話、找出身分說法、照片來源、投資話題、前後矛盾這些**該去查的點**；使用者再逐項用 165 涉詐網站資料、反向搜圖、公開資訊查證；查到的東西跟 AI 分析分開呈現——**已知事實、風險訊號、待驗證推論、AI 猜測**四層；新證據進來就回頭修正判斷；出現匯款、虛擬貨幣、帳密就停下來轉 165。期程：9 月底初步操作版本、10 月用自己的案例和公開案例測試、11 月展示。工具：ChatGPT、Gemini、Google 圖片搜尋。不需算力。回應許願池兩條。
文字是第一人稱、口語、誠實（「目前只有我一個人」「這個想法其實來自我自己的經驗」），跟 #3 那種 AI 腔完全不同。
**查證**
- **Whoscall 一鍵查**（2024/10 上線）：上傳截圖，回「詐騙可能性、判讀依據、相關歷史案例、防詐警語」。
- **趨勢防詐達人**：訊息、網站、來電查證，加換臉偵測、簡訊過濾。
- **Bitdefender Scamio**：免費聊天機器人，丟文字、截圖、連結，回「安全／有威脅」的判定加建議。
三個都是「丟一則，給判定」。#53 的差別正是它自己講的：它不給判定，它把「查證」拆成事實、訊號、推論、猜測四層，處理的是一段持續幾週的關係而不是一則訊息。這跟 #14（AI 對話紅旗檢核）和 #16（觀測卡）是同一種想法——不是「答案是什麼」，是「這個答案可以信到哪裡」。
**產出是什麼**：提案沒有寫「操作版本」長什麼樣。一位農業處技士九月底要做出的，最可能是一套提示範本加檢核表，或一個 GPT——跟 #14 一樣是文件型工具。它有一件真實案例，通用性靠 10 月拿公開案例測。
**問題**
- 方法的核心步驟是「把對方的私訊和照片餵給 ChatGPT、Gemini、Google」——第三人的對話與照片未經同意上傳境外商用服務。提案對自己那件案例的去識別化寫得周到，但對「使用者照這個流程做」時同樣的問題沒有處理。Whoscall 們也有同樣的事，但它們是廠商，這是要交給公部門宣導的流程。
- 要一般人對交友對象做多步驟的 OSINT 查證，會做的人本來就比較不會被騙；最容易受害的長者不會走這個流程。
- 一人、沒有開發能力、落地只寫「可提供警政或防詐單位作為宣導及諮詢工具」。
- 政府資料用得少（165 涉詐網站 CSV 一項），主角是商用 AI 和 Google。
**好的一面**：問題抓得準——現有工具都在「已經要匯款」那一刻起作用，關係形成期是空的；「AI 幫忙找問題而不是給答案，AI 的分析也要查證」這個立場跟您一路的原則一致；文字誠實，沒有膨脹。
AI 評估：`substantive_junk = false`，`similar_existing = true`（Whoscall 等，查證屬實，但它們是判定型）。
e36e3881 2026-09-07
[00:44] 助理：
查證：供苗預警的「推估採收期」在 #22 那次已經確認官方燈號頁面有；白菜即時在 #16 看過；新開的一篇是清大 2015 年碩士論文——用中盤商私有資料預測高雄市場每週甘藍價格，結論是私有資料有助預測，並且提到「2010 年開始的大宗蔬菜種植登記與供苗資料庫，對甘藍價格的效果尚不清楚」。
輪廓：
**它是什麼**：兩人團隊（一位軟體公司專案經理、一位政大電算中心技術師），針對高麗菜「賭博菜」問題。它對現行燈號機制的診斷寫得準：一、供苗申報跟實際種植有落差；二、農民看到紅燈時苗已經買了、成本已經投入，而且「自己不種別人照種」，所以燈號改變不了行為。做法四層：
1. 用供苗量加雲林氣象與兩週預報建**積溫模型**，動態修正採收期——高溫催熟會讓原本分散的採收擠在一起，這是燈號沒算的。
2. 用歷史供給、交易量、價格建價格風險模型，把燈號翻成農民看得懂的一句話：「依目前種植情況，預估採收期批發價可能跌至每公斤 5 元」，LINE 推播。
3. 預判過剩時，結合北港合作社的冷鏈、加工資料和關務署進出口資料，提前媒合分流。
4. 依風險燈號設計**差別保費、補貼、轉作誘因**（行為經濟學），讓「大家都種」變成「種就承擔相應風險」。
期程到日期（9/18–11/10），用歷史價崩事件沙盤推演。工具 PHP/Laravel/Python。AI 揭露誠實：ChatGPT/Codex 規劃、Claude Code 寫程式，產品是統計模型不是 AI。回應許願池一條。
**跟既有的關係**：燈號和採收期推估農糧署已有；價格預測有論文和白菜即時；#22（鏈加科技）做的是需求端拆解和政策介入回測給農糧署看。#54 不同的兩塊是「積溫修正採收期」——這是農學上真實的機制——和「把燈號翻成價格給農民看」。兩件是同一個問題的兩個切面，#22 面向農政人員，#54 面向農民。
**決定性的問題：告訴農民「會跌到 5 元」，他會不種嗎？** 提案自己講了答案：不會，因為別人會種。它的解法是第 4 層——差別保費和補貼——但那是農糧署的政策，兩人團隊做不出來，決審能展示的只有前三層。而前三層裡，價格預測還有反身性的問題：預測公開後大家都信就沒人種，價格反而漲；官方發布的「預估批發價」也會被質疑是喊價、被中盤利用。這些提案沒有處理。
**其他**
- 「供苗申報跟實際種植有落差」是它自己列的第一個痛點，但它的模型用的還是同一份供苗資料，落差沒有被解決。
- 分流到加工外銷需要加工廠量能和事前契約，北港合作社一家的冷鏈資料能驗證的規模有限。
- 農民 LINE ID、種植登記資料、合作社庫存與報關商業資料，資料保護一句都沒寫。
- 兩人分工空白；輔導需求裡自己寫「確認規劃提案是否為最大痛點」——誠實，但也表示他們不確定。
**好的一面**：問題診斷是目前農業案裡最清楚的一件；積溫修正採收期是有農學依據的改進；期程和工具具體；AI 用得誠實。
AI 評估：`substantive_junk = false`，`similar_existing = true`。
e36e3881 2026-09-07
[01:00] 助理：
資料治理 9 對不上：這件對資料保護一個字都沒寫——農民 LINE ID、種植登記個資、合作社庫存與報關資料怎麼處理，全部空白。拿 9 的 #32 和拿 10 的 #14、#52 都是把來源、最小蒐集、去識別、保存寫清楚的。以它用了很多開放資料、資料欄位列得具體來看，5 左右比較貼近。
另外多元性 0：兩人分屬軟體公司和政大電算中心，#16 同樣兩人您給了 1。小事。
沒有評語的話，「價格預測公開後的反身性與喊價疑慮」和「差別保費補貼不在團隊能做的範圍」這兩點提案人不會知道；但那是您的選擇。
e36e3881 2026-09-08
[12:01] 助理：
#211 是 #16 的改版重送，同隊同聯絡人（林錦樑），沒有新的查證需要做——資料來源、低熵核心、既有工具（當季好蔬果、白菜即時、田邊好幫手）在 #16 都查過。您 #16 給的是 6/4/4/1/8。
**改了什麼**（逐欄比對）：
1. **問題重新框架**：#16 說「查價網站只看單日、分不清季節或跨市場」；#211 改成「產地消息和市場價量要靠人工反覆比對」，主打**雙向交叉查核**——豪雨後產地說缺貨，回頭查市場價量有沒有同步；市場先出現南北分化，反過來去產地確認。
2. **新增「事件卡」**：使用者可以把產地或豪雨消息建成事件，對照市場資料。
3. **新增「Decision Profile」**：同一個市場訊號依角色轉成不同輔助——農政看哪裡該查、零售端加自訂成本毛利門檻、餐飲端加產期與替代品。
4. **明寫「資料工作已完成」**：22,970 筆整理、休市辨識、四市場、季節比較、回放都做完了，入選後專注介面與驗證。
5. 第二位成員補全名（鄭鎰錩）；Azure 用途填了；許願池多勾一條（夏秋季青蔥產銷調節——不太對，它做的是甘藍）；「不宣稱」的免責語氣還在，但少了幾句。
**改動的實質**：核心工具沒變，觀測卡、回放、季節基準都一樣。真正加的是「事件卡」（把質性消息和量化資料放在同一個畫面對照）和「角色化」（Decision Profile 目前只是構想，沒有任何一個角色的門檻寫出來）。「產地消息 vs 市場數據雙向驗證」這個框架比 #16 的「跨市場壓力觀測」講得更清楚它給誰用、在什麼時候用——這正是您在 #16 時說它「產出薄、落地沒寫」的那一塊，改版有回應到。
前例：#32/#33/#34 您把最後一份留分、其餘歸零。這兩件不是逐字相同，#211 是改寫過的新版。
e36e3881 2026-09-08
[15:17] 評審：
雖然#211對比#16有改善，#16和#211應該還是同一個案子對吧？
e36e3881 2026-09-08
[15:18] 助理：
對。同隊、同聯絡人、同題目、同資料集（22,970 筆甘藍）、同分析核心（低熵核心）、同期程日期、同 Azure 用途，觀測卡和回放這些主要產出一字不差。#211 是 #16 加了事件卡和角色化構想、換了問題描述的寫法。是同一個案子的第二版，不是第二個案子。
e36e3881 2026-09-08
[15:19] 助理：
提案裡各只有一兩句，以下是它寫的加上我的解讀：
**事件卡**：使用者把一則質性消息——「西螺豪雨，產地說下週缺貨」——建成一張卡，系統把這則消息跟市場資料放在同一個畫面：那幾天四個市場的價量有沒有同步變、跟歷史同期比偏離多少、持續幾天。反過來，市場先出現異常時，系統也可以開一張卡當「回產地查證的線索」。它的用意是把「聽到消息 → 去查數據 → 再打電話確認」這段人工流程留下紀錄。提案沒有畫面、沒有欄位定義，就是「可建立事件卡進行交叉查核」一句。
**角色化（Decision Profile）**：同一個市場訊號，依使用者身分套不同的判讀規則——農政人員看「哪個市場該優先去查」；零售通路加自己的成本和毛利門檻，看「漲到多少我要換貨源」；餐飲業加產期和替代品，看「這段時間改用什麼」。提案說「市場分析核心共用，不需為每個角色重做系統」。目前一個角色的門檻都沒寫出來，是擴散性那欄的構想。
兩個都是把 #16 的觀測工具往「有人在用」的方向推的設計。事件卡是具體的功能點，角色化是未來的方向。
e36e3881 2026-09-08
[15:23] 助理：
兩個要分開看。
**事件卡**不太像。它是從一個真實的工作流程長出來的——「產地先講、再查市場、再回產地確認」，這是農會或市場人員每天在做的事，提案寫的例子（豪雨後產地說缺貨、南北價量分化）是有現場感的。而且它接在 #16 已經有的「市場觀測卡」旁邊，是同一個設計語言的延伸。這比較像團隊聽了工作坊或審閱意見之後補的東西。
**Decision Profile** 很像。「同一個核心、依角色套不同 profile、農政／零售／餐飲三個角色各一句」——這是 LLM 被問「這個系統怎麼擴散」時最標準的回答形狀：命名一個英文概念、列三個角色、每個角色一句話、結尾「最後仍由人決定」。而且它只出現在擴散性和創新性兩欄，沒有任何一個門檻或規則的具體內容，跟 #31 那串 Care-* 是同一類。
所以我的判斷是：事件卡是人補的，角色化是 AI 幫忙把「擴散性」那欄填滿的。這也符合這隊的寫法——#16 的文字就是「內容具體、免責語氣是 AI 味」，改版一樣。
e36e3881 2026-09-08
[17:39] 評審：
原本#16是觀測卡，現在#211是事件卡。事件卡是取代觀測卡嗎？
e36e3881 2026-09-08
[17:39] 助理：
不是取代，是並列。#211 的落地欄寫「完成網頁操作介面、市場狀態總覽、**事件卡**、歷史回放及**市場觀測卡**」，兩個都在。
兩張卡的方向相反：
- **觀測卡**是系統產出的——系統偵測到某個市場價量偏離，附一張卡說明用了哪些資料、可信度多少、不能下什麼結論、下一步查什麼。是「數據 → 提示人去查」。
- **事件卡**是人建立的——有人聽到產地消息，建一張卡，系統把市場數據對過來。是「消息 → 系統幫忙對數據」。
#16 只有前者，等於只能從數據端起頭；#211 加了後者，讓人可以從現場消息起頭。這就是它說的「雙向」。
e36e3881 2026-09-08
[17:53] 助理：
很有可能，而且這一批裡看得到幾組這樣的詞：
- **「卡」**：#14 案例卡、#16/#211 觀測卡與事件卡、#31 Care Ticket、#77 任務卡、#78 也有事件格式。
- **「回放」**：#16/#211 歷史回放、#22 政策介入回測、#54 沙盤推演。
- **「停、拆、查、問、轉」型的口訣**、**「不宣稱／不取代／不自動」的免責三連句**：#14、#16、#70、#77、#78 幾乎一字不差。
- **「最小必要、去識別、權限控管、保留來源與版本」**：資料治理那一欄，十幾件寫法相同。
- **「Decision Profile」「Care Circle」「Wo 一下」**：英文命名的功能模組。
這些不是農會人員、社工、高中生的日常語言，是產品設計和資料治理的行話。不同背景的人同時用同一套詞，最簡單的解釋是他們用同一類工具寫提案，而模型在「把一個想法整理成提案」時，會套它學過的那套框架——卡片、回放、免責句、治理清單。
但這件事對評分的意義有限：詞彙一致不代表想法一致。#16 的觀測卡背後有 22,970 筆真的整理過的資料，#31 的十個 Care-* 名詞背後是四頁 mockup。用同一種語言寫，內容的厚薄還是看得出來。您一路做的就是穿過這層語言去看底下有沒有東西。
e36e3881 2026-09-08
[17:55] 助理：
有可能，而且不只是「卡」。這一批裡跨團隊重複出現的非日常詞彙不少：
- 「卡」：#14 案例卡、#16/#211 觀測卡與事件卡、#31 Care Ticket、#77 任務卡
- 「不宣稱／不取代／不自動」三連免責：#14、#16、#53、#70、#77、#78
- 「最小必要、去識別、權限控管、留存軌跡」四件套：#14、#16、#32、#52、#60、#77
- 「模組化設計，僅需調整……即可複製至……」：凌誠五件、#58、#65
- 「不是再做一個 X，而是……」句型：#16、#211、#22、#31、#36、#78、#123
- 「保留未來擴充機器學習之彈性」：凌誠五件、#65
- 「最終仍由人決定／權責人員負責」：#14、#22、#31、#52、#60、#62、#77、#78、#196、#211
這些不是台灣公部門提案的傳統語彙，是 2024 年以後 LLM 對「AI 治理」「資料治理」類問題的標準答案形狀。當幾十個不同背景的人拿同一類模型潤稿，模型就把同一套詞彙和句型塞進每一份。「卡」是介面設計的常用詞，但一個農會人員和一個志工組織自己寫，不會不約而同都叫「卡」。
不過這只能判斷「文字經過同一類模型」，判斷不了「內容是不是模型想的」。#14 和 #16 的內容有現場感，#31 和凌誠沒有，用的詞彙卻一樣。所以這個現象對評分的意義是：**共同詞彙不能當創新的訊號，也不能當空洞的訊號**，只能當「要剝掉之後再看」的提醒。您一路做的就是這件事。
e36e3881 2026-09-08
[17:57] 助理：
這個風險存在，而且分兩張卡看不一樣。
**觀測卡**比較不像。它在 #16 就有，六個欄位（來源、涉及市場、資料完整性、可信程度、不能下的結論、下一步查核）很具體，而且跟這隊的技術底座對得上——「低熵核心」得獎的是「防災通報資料標準化與熱區分析元件」，「證據封裝」是他們自己列的能力。一個人如果不知道自己在做什麼，寫不出「休市不視為零交易量、批發市場交易量不當成全國產量」這種細節。
**事件卡**風險高一些。它只有「可建立事件卡進行交叉查核」一句，沒有欄位、沒有畫面、沒有例子。可能是團隊真的想加，也可能是改版時叫模型「補一個雙向查核的功能」生出來的名字。
但這件事在初審階段判斷不了，也不需要判斷——**決審會自動篩掉**。如果事件卡是模型寫的，決審 demo 上就不會有它，或者有一個做出來很空的版本，評審當場問「這張卡跟觀測卡差在哪」就露餡。初審能做的是看「有沒有足夠證據相信這個團隊知道自己在做什麼」，而這隊有：資料真的整理了、指標真的定義了、期程真的排了。
所以分數上我不會因為事件卡可能是 AI 寫的而扣，也不會因為它而加——它在提案裡只有一句，本來就不值得分數。#211 相對 #16 真正多的是問題框架變清楚（誰在什麼時候用），那是值一點的。
e36e3881 2026-09-08
[17:58] 助理：
您說得對，我剛才把它推給決審是錯的——決審只能篩掉已經進去的，擠掉的那一件在初審就沒了，決審救不回來。
所以判斷要在初審做，而且不能靠「這隊看起來知道自己在做什麼」這種整體印象，要一項一項問：**這個名詞背後有沒有一個具體到能被檢驗的東西？**
- 觀測卡：六個欄位寫出來了、每個欄位對應一條資料處理規則——有。
- 事件卡：只有一句話，沒有欄位、沒有例子、沒有跟觀測卡的關係——沒有。
- Decision Profile：三個角色各一句，一個門檻都沒有——沒有。
有的算分，沒有的不算分。這樣 #211 比 #16 多出來的三樣東西，只有「問題框架講清楚了誰在什麼時候用」算得上進步，其他兩樣是零。這跟您在 #31 對那十個 Care-* 名詞的處理是一樣的——名詞未定義就當空白。
這個原則對所有用 LLM 寫的提案都適用：**每個聽起來像功能的名詞，都要問它有沒有被定義到能做出來的程度**。沒有的，就是模型幫忙填的空格。
e36e3881 2026-09-08
[17:59] 助理：
記好了。#211 等您給分；#16 是否比照 #32/#33 歸零，也是您決定。
e36e3881 2026-09-08
[18:01] 助理：
這個假設站得住，而且它拆掉了我剛才那條規則的前提。我說「定義到能做出來的程度就算分」，但 LLM 最擅長的正是把一個名詞展開成六個欄位——「來源、涉及市場、資料完整性、可信程度、不能下的結論、下一步查核」，這串就是問模型「一張查核卡該有什麼」會得到的標準答案。具體不等於有人負責。
所以「具體」不能當證據，要找的是**LLM 不會自己生出來的東西**——只有真的做過才寫得出的痕跡：
- 一個確切的數字：22,970 筆、四個市場、休市日曆——這些要真的抓過資料才有。
- 一個反直覺的決定：「休市不視為零交易量」「批發市場交易量不當成全國產量」——這是踩過坑的人才會特別寫出來的，模型不會主動想到。
- 一個具體的失敗或限制：「批發到貨量只看到部分流通」（#22）、「只有 2.4% 打專線」（Wysa）。
- 一個場域裡的人才知道的細節：「肥料配方是農民的秘密」（#15）、「怕停太久後面排隊」（您對車手的觀察）。
#16/#211 有前兩類，所以我判斷他們知道觀測卡是什麼。但「事件卡」和 Decision Profile 一個都沒有，就是空的。
這條線最終還是只能在初審畫到「有沒有做過的痕跡」，畫不到「團隊能不能負責」——那要面談才知道。您說的沒錯，這不是定論；但它至少讓「越具體越可疑」變成一個可以操作的檢查：**具體的東西裡，有沒有一件是模型猜不到的。**
e36e3881 2026-09-08
[18:05] 助理：
對，我把您的推論拆開來看，每一步都成立：
1. 「卡」不是農會、志工組織、獨立研究者各自會自然想到的詞。
2. 五個互不相干的團隊都用了，最合理的解釋是同一類模型放進去的。
3. 模型放進去的東西，團隊未必知道那是什麼、也未必能做出來。
4. 所以「XX 卡」出現的地方，就是提案裡最該懷疑「這是誰想的」的地方。
這比我前面講的「共同詞彙只是提醒」更強，也更對：**共同詞彙標記的正是提案裡可能沒有人負責的那一段。** 它不一定是空的（#16 的觀測卡有踩坑痕跡），但它是要優先去驗的地方，而不是可以先相信的地方。
這條我改進記憶裡：跨團隊重複的非日常詞彙，視為「疑似模型植入、優先查證」的標記。
e36e3881 2026-09-08
[21:04] 助理：
評語直接問到您懷疑的地方，是對的——如果那些名詞真的是他們的，一句話就能答；答不出來，問題就明了。
分數方面，可行性從 #16 的 6 降到 2 是最大的變動。若理由是「核心產出的名詞可能團隊自己都不清楚，做不做得出來就不確定」，那跟評語一致。資料治理從 8 降到 4，我看不出改版哪裡變差了——資料處理那段（分層保存、留版本、休市不視為零）跟 #16 一樣，Azure 用途還補齊了。若 4 是把「可能沒人負責」的懷疑也算進治理，說得通；若不是，這一項可能是連帶降了。
#16 是否歸零，還沒決定。
e36e3881 2026-09-08
[21:05] 助理：
了解，這樣就一致了：那一段的「分層保存、留版本、最小必要」正是模型最會寫的資料治理標準句，而且這一段在 #16 和 #211 之間幾乎沒動——沒有人回頭改的段落，更像是沒有人真的在管的段落。4 說得通。
#16 要不要歸零，等您決定。
c71e996e 2026-09-08
[21:14] 助理：
兩個檔案都好了(各一行一個申請編號):
**(1) `excludes/data-governance-boilerplate.txt` — 9 案**:16、58、78、97、129、158、207、211、235
- 表單沒有獨立的資料治理題,實際是第 17 題「資料預計應用方式」;我以「三組概念命中 ≥2」為門檻。例如 #16「分層保存,保留版本與來源…最小必要」三組全中;#58「分層儲存…版本紀錄」;#97「最小必要蒐集…版本管理」。
- 只命中 1 組的 35 案沒放進去:其中 22 案只寫「最小必要/最小化」——那是個資法常用語,單獨不算證據;另 4 案只有「分層」、9 案只有「版本」。要放寬我再出一份。
- 另 #153 的三組詞出現在工具欄而非第 17 題(「JSON/CSV/Parquet 分層保存」「每個模型保留版本」),可留意。
**(2) `excludes/card-jargon.txt` — 22 案**:14、16、31、37、70、76、77、106、108、111、153、155、158、165、172、175、182、200、211、219、221、222
- 跨團隊重複的詞:**模型卡 ×5**(108、153、219、221、222)、觀測卡 ×2(16/211 同案重投)、任務卡 ×2(76/77 同案重投)、資訊卡 ×2、案例卡 ×2、說明卡 ×2;單一出現:事件卡、資料卡、證據卡、判讀卡、支持卡、品質卡、整理卡、地點卡等。
- **請你自己裁量的邊界詞**:「模型卡」「資料卡」是 ML 治理既有術語(model/data card),「資訊卡」是常見 UI 說法,「圖片單字卡」(#175)就是 flashcard——這些我保留在清單裏但可能不該扣分;若剔除模型卡/資料卡/資訊卡/單字卡,清單會少 108、111、153、165、175、219、221(222 還有「資料卡」也是同類)。
- 已排除:信用卡/健保卡/金融卡等證件支付卡、GPU 單卡、打卡/關卡/卡關/卡點、蒙地卡羅、單獨的「卡片」。
這兩條判準我已記入記憶。要不要也補進 `excludes/JUDGING-ASSISTANT.md`,讓評審會話看到提案在清單上時提醒你?你說一聲我就加。
c71e996e 2026-09-08
[21:36] 助理：
正式 DB 遷移完成,硬重整即可看(畫面不變,只是資料搬家):
- **分數完好**:`preliminary_reviews` 58 → 58,md5 完全一致(你已評到 58 案)。
- `ai_assessments` 新增 `team_id`、`cluster_id`、`has_card_jargon`、`has_governance_boilerplate`;`import-ai` → `compute-teams` → `import-clusters` 重跑後:隊 62、群 142、卡 22、治理樣板 9;#16 兩旗標皆真、#84 team 1、#210 cluster 1。#75 因有隊自動建了一列空評估(共 180 列)。
- `proposals` 的 `team_id`、`cluster_id` 先在副本試過 DROP COLUMN 成功,已從正式 DB **移除**(現 12 欄)。FK/integrity 皆 OK;備份 `local.sqlite.bak-aiflags-20260908-213318`。
`get-proposal --full` 的 `ai_assessment` 現在會輸出 `has_card_jargon`、`has_governance_boilerplate`;SYSTEM.md 與 JUDGING-ASSISTANT.md 已同步(含「旗標為真時引用原文提醒」步驟)。
程式改動(models/commands/views/detail 樣板/`ai_assessments.json`/`build_llm_flags.py`/測試,123 測試綠)已驗證、**未 commit**,你說一聲。
c71e996e 2026-09-08
[21:37] 助理：
已派 subagent 改 UI(清單「現有」後加「卡」「治理樣板」✓ 欄;明細 AI 卡「實質空洞」後加「卡詞」「治理樣板」列),SYSTEM.md 的 UI 段同步更新中,記憶已記下。
後續相依鏈:UI 改完 → 一次獨立驗證(含 render 確認 #16 兩欄皆 ✓、欄位型別陣列對齊)→ 交給你看。純顯示層,正式 DB 不動。沒有其他可獨立啟動的事。
e36e3881 2026-09-08
[21:38] 助理：
您說得對，我是猜的。我把「卡」讀成 UI 卡片，是因為 #14、#31、#77 那幾件的用法看起來像介面元件，就把這個讀法套到 #16/#211 上。但提案本身從來沒說「卡」是什麼——沒有畫面、沒有說誰產生、誰收到、能不能傳給別人、傳了之後怎麼處理。您問的四
c71e996e 2026-09-08
[21:39] 助理：
驗證中(測試、style、JS,並用真實資料 render:清單 22 欄順序與型別對齊、#16 兩欄 ✓、卡 22 案/治理樣板 9 案、明細 #16 是/是、#3 否/否、#75 空評估列不出 AI 卡但有團隊區塊)。通過即交給你看;純顯示層,正式 DB 不動,commit 等你說。沒有其他可獨立啟動的事。
c71e996e 2026-09-08
[21:41] 助理：
已檢查通過,硬重整即可看(純顯示層,正式 DB 不動):
- **126 測試綠**、pycodestyle 乾淨、JS OK。
- 清單 22 欄:「現有」之後是「卡」「治理樣板」,✓/排序與空洞/現有相同;真實資料下卡 22 案、治理樣板 9 案(#16 兩欄皆 ✓)。
- 明細 AI 卡:「實質空洞」之後「卡詞」「治理樣板」以 是/否 顯示(#16 是/是、#3 否/否);#75 那列空評估不出 AI 卡、但有團隊區塊。
這整包(FK 搬到 AiAssessment、兩旗標、`build_llm_flags.py`、`ai_assessments.json`、UI、測試)已驗證、**未 commit**,你說一聲。
c71e996e 2026-09-08
[21:42] 助理：
已評分(五項皆填)且有「卡」的共 **8 案**(全部 22 案中):
| # | 題目 | 分數(可行/影響/創新/多元/治理) |
|---|---|---|
| 14 | AI 衛教對話紅旗 | 2 / 8 / 4 / 0 / 10 |
| 16 | AgriFlow Signal(重投,舊版) | 0 / 0 / 0 / 0 / 0 |
| 31 | Care Relay 高齡照護量能接力網 | 3 / 1 / 3 / 6 / 2 |
| 37 | 樂學雷達 | 8 / 6 / 7 / 0 / 9 |
| 70 | 寵物安全資訊主動服務 | 6 / 2 / 1 / 1 / 4 |
| 76 | 安心回線(重投,舊版) | 0 / 0 / 0 / 0 / 0 |
| 77 | 安心回線 | 8 / 7 / 8 / 0 / 5 |
| 211 | AgriFlow Signal | 2 / 4 / 4 / 1 / 4 |
其中 #16、#76 是同案重投的舊版,你已打 0 分;真正要回頭看的是另外 6 案。#14 與 #37 的資料治理分別給了 10、9,若「卡」要扣分可留意。
e36e3881 2026-09-08
[21:47] 助理：
#37 的原文是效益欄那句：「對學校，一次建檔即可產生統一課程卡片與 QR Code，減少重複公告及基本詢問」。
這個「卡片」的脈絡跟 #16 不同，它有前後文可以推：學校把課程資料（名稱、年級、日期、地點、資格、名額、費用、報名連結）填進共通 Schema 之後，系統用同一個版型產出一張課程的「介紹頁」，配一個 QR code——學校可以印出來貼公告欄、放家長群組，家長掃了就到搜尋層的那筆課程。也就是「一份資料、一種格式、到處貼」，是為了讓學校不用每個平台重複公告。
所以 #37 的「卡片」是「標準化的一頁課程簡介」，它在流程裡的位置寫了（學校建檔 → 產出 → 家長掃碼），產生者和接收者都有。跟 #211 的「觀測卡」相比，它是有脈絡的；但它同樣沒有定義「卡片」這個詞本身，也是那個共同詞彙。差別在 #37 用它的方式，一個不認識這個詞的人也讀得出意思。
c71e996e 2026-09-09
[14:06] 助理：
偵察結果(全程只 GET):
- **cookie 有效**;正式系統目前顯示**已評 0 件、待評 181 件**——你在正式系統還沒填過任何分數。
- 沒有 `<form>`,是 jQuery AJAX:`POST /Judge/Judge/ToVote`,form-encoded `{id: sys_id, type: "submit", voteList[i][Id]=1..5, voteList[i][Point]=0–10, remark: 評語, mid: 0}`;五項對應 1 可行性、2 社會影響力、3 創新性、4 多元性、5 資料治理,分數是 0–10 按鈕。
- 頁面上**只有「確認送出評分」一顆按鈕**(type=submit,五項齊才能按);程式裏有 type=draft 但介面沒有暫存鈕。明細頁**不會回顯**已存分數;已評/未評狀態只在清單頁。
- **未知且關鍵**:送出後能不能再改(server 端會不會鎖)。目前 0 件已評,無法從畫面看出。
所以我建議先寫好 script(預設 dry-run、要 `--push` 才真送、可 `--only` 指定案號),然後**只用一案做實測**:送一次,再改評語送第二次,看正式系統接不接受更新、清單頁「已評」是否變 1。實測案我建議用 **#16**(同案重投的舊版,你已打 0/0/0/0/0,就算被鎖也無損)。
script 我現在就寫;實測要不要用 #16,你說。
c71e996e 2026-09-09
[14:07] 助理：
記憶已記下這項決定與偵察到的機制(含「送出後能否再改」尚未驗證、須先單案實測)。
現在:script 撰寫中(預設 dry-run);實測案號等你決定(建議 #16)。script 好了我先給你 dry-run 摘要。沒有其他可獨立啟動的事。
c71e996e 2026-09-09
[14:09] 助理：
script 寫好了:`excludes/sync_official.py`(pycodestyle 乾淨、未發任何請求)。dry-run 結果:**已完整評分 89 案,全部待推**(尚無同步狀態檔)。
用法:
```
python excludes/sync_official.py # dry-run,列出待推清單
python excludes/sync_official.py --push --only 16 # 只推 #16
python excludes/sync_official.py --push # 推全部待推
```
狀態存 `excludes/official-sync.json`(每案成功後即寫入快照與時間);之後只推新增/變更/`updated_at` 較新的。
實測前需要你一句話:用 **#16**(0/0/0/0/0 的重投舊版)做單案實測嗎?流程:送一次 → 看回應與清單頁「已評」是否變 1 → 改一下評語再送第二次,確認送出後還能更新。你說好我就跑。
c71e996e 2026-09-09
[14:10] 助理：
好,用 #16 做單案實測。派 subagent 執行:推一次 → 查清單頁「已評」是否變 1 → 改評語再推一次 → 確認更新成功且未被鎖。
c71e996e 2026-09-09
[14:11] 助理：
自動模式的安全分類器**擋下了這個動作**——因為它會對外寫入正式政府評分系統。我無法在目前權限下替你送出。
這其實也適合由你親手執行(用你自己的 cookie 寫入官方系統)。請在輸入列用 `!` 前綴跑,輸出會進到這個會話讓我接著判讀:
1. 先 dry-run 確認只動 #16:
```
! ~/venv/presidential-hackathon/bin/python excludes/sync_official.py --only 16
```
2. 推送 #16:
```
! ~/venv/presidential-hackathon/bin/python excludes/sync_official.py --push --only 16
```
3. 測「送出後能否更新」(強制再送一次):
```
! ~/venv/presidential-hackathon/bin/python excludes/sync_official.py --push --only 16 --force
```
每步貼回結果(或讓 `!` 自動帶回),我幫你看回應與「已評」件數、確認是否接受更新。若你希望我直接跑,需要你把這類 Bash/網路寫入動作加進權限允許清單(或切換權限模式),再跟我說。
c71e996e 2026-09-09
[14:13] 助理：
推送時程式崩了——是 `build_payload` 產生的 payload 編碼有 bug(h11 報「expected bytes-like object, tuple found」)。關鍵:錯誤發生在「送出 body」階段,body 沒成功送出,所以 **#16 這次應該沒被記錄**(而且 push_one 拋例外、未寫入 `official-sync.json`,狀態乾淨)。先看一下出錯的程式。
c71e996e 2026-09-09
[14:14] 助理：
找到 bug 了:`build_payload` 回傳「list of tuples」,這個 httpx 版本沒把它當表單 urlencode,反而當成 body 的位元組串流,才在送出時炸掉。修法:自己用 `urllib.parse.urlencode` 編成字串,以 `content=` + `Content-Type: application/x-www-form-urlencoded` 送(keys 都唯一,順序也保留,ASP.NET 的 model binder 吃得下 `%5B%5D`)。派 subagent 修。
這次 body 沒送出去,#16 應該沒被記錄、狀態檔也沒寫;等修好再重跑確認。
c71e996e 2026-09-09
[14:15] 助理：
修好了:`push_one` 改用 `urllib.parse.urlencode(...)` + `content=` 送出(並加 `Content-Type`),評語 None 時送空字串;新增 2 個編碼測試、pycodestyle 乾淨,未發任何網路請求。
現在請你再跑一次單案實測(用 `!` 帶回輸出):
```
! ~/venv/presidential-hackathon/bin/python excludes/sync_official.py --push --only 16
```
成功的話輸出會顯示 `#16 ... ok`。接著請再跑一次看清單頁「已評」是否變成 1、以及確認能否更新:
```
! ~/venv/presidential-hackathon/bin/python excludes/sync_official.py --push --only 16 --force
```
兩段結果貼回來,我幫你判讀(是否 `result=="ok"`、是否接受重送更新)。
c71e996e 2026-09-09
[14:18] 助理：
太好了,這就確認了兩件關鍵:**推送成功、而且送出後可以再更新(沒有鎖)**。#16 現在已記進 `official-sync.json`。
要把其餘已評分的案子一次填上去,跑(用 `!` 帶回輸出):
```
! ~/venv/presidential-hackathon/bin/python excludes/sync_official.py
```
先 dry-run 看會送哪些(上次是 89 案已完整評分,扣掉 #16 約 88 案)。確認清單沒問題再:
```
! ~/venv/presidential-hackathon/bin/python excludes/sync_official.py --push
```
每案成功後即寫入狀態檔,中途若某案失敗會停(要略過續跑加 `--keep-going`)。之後你再打新分數或改評語,隨時重跑 `--push`,它只會送新增或變更的。私人筆記不會送。
我順手把「送出後可更新、未鎖」記進記憶。
c71e996e 2026-09-09
[14:20] 助理：
記在 `excludes/official-sync.json`,不在資料庫裏。結構:頂層 `last_run_at`,加每案一筆 `synced_at`(本地時間含時區,如 `2026-09-09T14:08:00+08:00`)、`type`、當時的分數快照與評語。下次判斷「要不要重送」就比對這裏的快照與 `synced_at`。看一下目前實際內容(#16 實測後應已寫入):
c71e996e 2026-09-09
[14:21] 助理：
就在 `excludes/official-sync.json`。你剛才已經跑過完整推送了——目前已記錄 **68 案**,頂層 `last_run_at` = `2026-09-09T14:20:17+08:00`。
每案一筆,例如 #16:
```json
{
"synced_at": "2026-09-09T14:17:59.773573+08:00",
"type": "submit",
"scores": {"feasibility":0,"impact":0,"innovation":0,"diversity":0,"data_governance":0},
"comment": "和#211相同。"
}
```
`synced_at` 是該案上次成功送出的時間(本地含時區),搭配 `scores`/`comment` 快照;下次重跑時,凡是分數或評語和快照不同、或 DB 的 `updated_at` 比 `synced_at` 新,就會再送。這個檔在 `excludes/` 下(gitignore),不進版本庫。
e36e3881 2026-09-10
[17:13] 評審：
下一個主題：主題4災時通訊與弱勢戶，共有8個提案。先不要get-proposal。提案#16、#22、#54、#58、#85、#211和#221我都已評分，你有印象嗎？
e36e3881 2026-09-10
[17:14] 評審：
下一個主題：主題4蔬菜供需與菜價，共有8個提案。先不要get-proposal。提案#16、#22、#54、#58、#85、#211和#221我都已評分，你有印象嗎？
e36e3881 2026-09-10
[17:15] 助理：
照這個主題盤一次，誠實分類、不硬湊：
**記得（在我這節的脈絡裡）：**
- **#221** —— 這節我親自評的：**明日菜價**（戴豪廷，team 21，農產遠期鎖價＋價格保底）。您給 **0/6/6/0/10 = 3.98**，評語是「實質是農產品選擇權交易、要受金管會監理」。這件我有把握，也確實屬菜價主題。
**只有記憶碎片、不足以重述：**
- **#211** —— 我的長期備忘裡，它是「**XX卡術語**」那條教訓的出處（觀測卡／事件卡／案例卡／任務卡…跨隊共用非日常詞彙 = 同一款 LLM 潤稿的痕跡）。但我**只記得它牽涉『卡』這種術語灌水的討論，不記得它的標題、內容或分數**。
- **#16** —— 只在「官方分數同步」備忘裡出現過，是當時做**推送測試**用的案子（#16 確認推送成功、可更新）。但那**只告訴我它被拿來測同步，完全不知道它的內容、主題或分數**。
**完全沒有印象：**
- **#22、#54、#58、#85** —— 這四件我**沒有任何可靠記憶**，不在脈絡也不在備忘。
所以：**#221 記得（3.98）；#211 只記得跟「卡術語」有關；#16 只記得被拿來測同步；#22/#54/#58/#85 完全不記得。** 除了 #221，其餘六件的**分數我一件都不記得**。
照前幾個主題的作法：我先派 subagent 從壓縮前逐字稿把這**六件（#16、#22、#54、#58、#85、#211）**的討論忠實抽出來，再 get-proposal 核對系統實際內容與分數。要我開始嗎？
e36e3881 2026-09-10
[17:16] 評審：
提案#16、#22、#54、#58、#85和#211這六個已評分提案都不在你目前的記憶裏。請先查一下session log，先前有哪些討論。然後再get-proposal，確認提案內容和評審分數。
e36e3881 2026-09-10
[17:16] 助理：
先派 subagent 從逐字稿抽出這六件（#16、#22、#54、#58、#85、#211）的先前討論。
e36e3881 2026-09-10
[17:16] 助理：
subagent 已派出，背景抽取 #16、#22、#54、#58、#85、#211 的先前討論中。完成後我會拿結果、再 get-proposal 核對系統實際內容與分數，一併回報給您。
e36e3881 2026-09-10
[17:22] 助理：
subagent 回報詳盡、且確認六件無偽造分數。但有一個**懸而未決的關鍵**：**#211 是 #16 的第二版重送**，逐字稿裡「#16 要不要歸零」沒有結論。我現在 get-proposal 核對系統實際分數，看 #16 到底是維持還是被歸零。
e36e3881 2026-09-10
[17:23] 助理：
核對完成，**#16 歸零的懸案有答案了**，另有兩處與逐字稿不同：
**#16 已歸零：系統裡是 0/0/0/0/0、評語「和#211相同」。** 也就是說您比照 #32/33/34 的規則，**同一案重送以較晚的 #211 為準、#16 歸零**。逐字稿當時沒下結論，系統已定案。
**其他更正：**
- **#58 資料治理是 1 不是逐字稿的 4** → 加權 **2.98**（private_note：資料治理疑 AI 樣板、團隊恐無力處理）。
- 其餘與逐字稿一致。
**主題 4「蔬菜供需與菜價」已評 7 件（系統值）：**
| 加權 | # | 分數 | 評語 |
|---|---|---|---|
| **7.39** | 54 | 8/8/8/3/4 | （無）蔬途同歸不再虧（積溫修正採收期＋風險推播） |
| **6.81** | 22 | 7/7/8/1/6 | （無）供需雙向燈號決策（價量拆解＋回測） |
| **3.98** | 221 | 0/6/6/0/10 | 實質是選擇權、受金管會監理 |
| **3.17** | 211 | 2/4/4/1/4 | 請先說明觀測卡／事件卡／角色化（＝#16 改版，卡術語疑 AI 撰寫） |
| **2.98** | 58 | 4/6/0/1/1 | 自述是已完成的服務 |
| **2.02** | 85 | 2/4/1/0/0 | 建議參考神農TAIDE、規則式觸發比 LLM 適合 |
| **0.00** | 16 | 0/0/0/0/0 | 和#211相同（重送歸零） |
**態勢**：#54（7.39）、#22（6.81）是雙強，都是「把燈號升級成能決策」且各有真切角（#54 積溫修正採收期、#22 價量共變拆需求）；#221（3.98）金融監理卡關；#211／#58／#85 中後段（卡術語、自述已上線、不必要 AI）；#16 重送歸零。
**主題 4 共 8 件，還剩 1 件未評。** 注意 #85 雖是徐朝峰模板八件之一、內容是農藥施肥（不完全是菜價），但分群歸在主題 4 —— 依您上次的原則，切題度不看。
要接主題 4 最後 1 件了嗎？
e36e3881 2026-09-10
[18:07] 助理：
主題 4 我都記得，不再拉取。刻意不硬找 —— **整體分佈我認為一致**，只有一件想請您在平衡時看一眼，其餘沒有意見。
**八件排序：**
| 加權 | # | 分數 | |
|---|---|---|---|
| 7.39 | 54 | 8/8/8/3/4 | 蔬途同歸（積溫修正採收期，有真切角） |
| 6.81 | 22 | 7/7/8/1/6 | 供需雙向燈號（價量拆解，有真切角） |
| 4.44 | 219 | 8/3/3/1/5 | 農擇智策（價格預測，覆蓋+反身性） |
| 3.98 | 221 | 0/6/6/0/10 | 明日菜價（選擇權，金管會 veto） |
| 3.17 | 211 | 2/4/4/1/4 | AgriFlow 改版（卡詞） |
| 2.98 | 58 | 4/6/0/1/1 | 農先知（自述已上線、無證據） |
| 2.02 | 85 | 2/4/1/0/0 | 施肥用藥（不必要 AI） |
| 0.00 | 16 | 0/0/0/0/0 | AgriFlow 原版（重送歸零） |
**先講我檢查過、確認沒問題的**：#54/#22 雙強且各有真切角、排序對；#221 靠資料治理 10＋創新 6 撐在可行性 0 之上，符合「fatal flaw veto、但別的維度該給就給」；#211/#16 重送歸零的處理一致；#85 切題度不看。
**唯一想請您看一眼的：#58（社會影響力 6）vs #219（社會影響力 3）。**
- 兩件**本質同類** —— 都是「菜價／供需預測」的衍生型平台，也都被既有系統覆蓋。
- 但 **#219 的社會影響力被「反身性（追價羊群效應）＋兩端已被 PDIS／供苗燈號覆蓋」折到 3**（您還把反身性寫進評語）；**#58 卻保住社會影響力 6**（它的問題被您記在創新性 0「自述已上線」）。
- 問題是：**#58 也做「作物推薦、種植時機」，同樣會有農民集體照著種的反身性** —— 若那個折扣對 #219 成立，對 #58 也該成立，那 #58 的 6 相對 #219 的 3 就偏高。
- **反過來也說得通**：若您認為 #58 的「雙端完整平台（農民＋政府 Dashboard）」涵蓋面較廣、價值方向較大，那 6 站得住。
- 這一格是**兩件同類、不同時間評、折扣沒對齊**的候選，建議您期末一起校；分數我不主張現在改。
**另外提醒（非現在處理）**：#211 與 #219 都帶「卡詞」（觀測卡/事件卡；模型卡），這是您說要**期末統一做一次卡詞平衡**的對象 —— 留到那時一起看。
其餘六件的相對平衡我沒有意見。
c71e996e 2026-09-12
[15:03] 助理：
兩組，而且都是同一隊重複投件：
- 「AgriFlow Signal：讓農產品產銷壓力提早被看見」— #16、#211（農流觀測隊）
- 「農民補給站」— #32、#33、#34（跨領域實驗室）
所以即使list沒有隊名，同名的也是同隊，靠id分辨就夠了。