從燈號到決策——大宗蔬菜供需雙向智慧預警與產銷調節系統

=== e36e3881 2026-09-05 10:03 === [10:03] 評審： 下一案#22「從燈號到決策——大宗蔬菜供需雙向智慧預警與產銷調節系統」 [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`（元件層次）。 [10:20] 評審： 所以這個案子到底要幹嘛？ [10:20] 助理： 一句話：**幫農糧署把「菜會不會種太多」的紅綠燈，升級成「菜價會不會崩、為什麼、該什麼時候出手」的儀表板。** 具體流程是這樣： 現在農糧署每十天收一次育苗場回報，供苗量比三年平均多太多就亮紫燈，發簡訊叫農民少種。這套只看「種了多少」，不知道「賣不賣得掉」。 這個案子要做的是，把批發市場每天的價格和交易量拿來一起看：如果到貨量增加、價格下跌，是種太多；如果到貨量沒變、價格卻跌，是沒人買（例如寒假團膳停了）。兩種情況農糧署該做的事不一樣，前者要勸減種，後者減種沒用，要去化。然後再把過去幾次崩盤時政府啟動耕鋤的紀錄拿來對照：如果當時早十天出手，可以少鋤幾公頃、少賠幾千萬。最後包成一個畫面，農政人員打「下個月甘藍會不會崩」，系統回答風險多高、主因是什麼、建議用哪個工具。 它的顧客是農糧署和縣市農業處的承辦人，不是農民也不是消費者。它賣的不是一個 App，是一個分析方法加一個查詢介面。 至於為什麼是一家企業 AI 公司來做這件事——因為那個查詢介面是他們的產品，農糧署是他們想進的市場。分析方法是真的有東西，介面是順便帶進來的。 [22:51] 評審： 7/7/8/0/6，no comment，可以嗎？ [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 可以，但如果只寫一句，我會寫「零資料架構僅保護查詢層，預測模型仍需讀取原始申報資料」——這是它最該被問、也最可能在決審被問的一點。 [22:52] 評審： 7/7/8/1/6，no comment，可以嗎？ [22:52] 助理： 加權總分 **6.81**（2.10 ＋ 1.96 ＋ 2.40 ＋ 0.05 ＋ 0.30）。跟 #19 的 6.82 幾乎並列最高。 分數我沒有意見。只有評語：這件有一個具體、有查證的問題值得留一句——**「零資料架構」只保護 NL2SQL 層，預測模型仍需讀原始數值，卻索取含農民個資的原始申報資料。** 這是資料治理 6 的依據，也是提案人真的需要被指出的地方。要不要寫，由您決定。 === 事後／並提討論 === e36e3881 2026-09-06 [12:04] 助理： 加權總分 **7.69**（2.10 ＋ 2.24 ＋ 2.40 ＋ 0.50 ＋ 0.45）。目前最高，領先 #19 和 #22 將近一分。 分數我大致同意。唯一想標記的是**可行性 7**：它的落地設計（協辦模式、導回公所、有量化查核點）是目前最好的，但團隊六人沒有一位工程師，技術清單又是最重的一份。7 是在賭他們找得到人做。如果要留評語，「團隊未列工程師，場域未定」這一句就是可行性 7 而不是 9 的理由，也是提案人最需要知道的事。 多元性 10 和資料治理 9 有充分依據。 e36e3881 2026-09-06 [15:09] 助理： 五個來源都開了。這件是 #31 同一個團隊（成員表一模一樣，含重複列的那位），主角就是 #31 裡搭售的 WoHere。 **它是什麼**：一個心理健康 App 的「社安網前端」版本。使用者花 15 秒寫一句話（「Wo 一下」），AI 回「四微」（微陪伴、微覺察、微行動……第四個沒寫）；需要更多支持時勾選財力、時間、距離、照顧責任、支持網絡、揭露意願，系統產生一份「最小必要支持摘要」，依條件導向自我陪伴、民間公益、民營專業、公部門或危機資源；使用者可以自己帶著摘要去社福中心、心衛中心，不用重講一遍。黑客松階段做 4 頁 PWA 概念原型，用「27 種生命狀態」模擬情境，跟機構桌上演練。不通報、不派案、不做風險評分。 **誠實揭露**：第五題勾「否，已申請政府預算」——WoHere 核心已投桃園 SBIR（評審中），並解釋 SBIR 是個人版與資料基線，這次是公共服務的資源導航層。回應許願池三條，其中一條就是「全民心理健康早期預警與資源媒合平台」。 **查證** - **WoHere** 是他們的產品（官網有列），SBIR 是自述。 - **衛福部心快活**：衛教文章、自評問卷、「心據點」醫療院所名冊。沒有 AI、沒有日記。官方有資源目錄，沒有前端。 - **FarHugs 遠距抱抱**：2019 年起的商業平台，六萬會員，有 **HugBee AI 接案員**「把目前的狀況說出來、整理成比較清楚的脈絡」，還有一篇整理 22 縣市心衛中心電話、15–45 歲三次免費諮商、1925 安心專線的免費資源目錄。**「AI 幫你整理狀態 → 導向公私資源」在台灣已經有商業實作**，跟 #36 的流程幾乎一樣。 - **Sort AI**：引導式反思 AI，建議外部資源但沒有整合轉介。 - **Wysa 研究（2024）**：AI 能偵測 82% 的危機使用者，但**反覆鼓勵之下只有 2.4% 的人打了專線**。這個數字對 #36 很重要：「資源導航」從 App 走到真人求助的轉換率極低，而且 Wysa 是有臨床團隊設計的。 **唯一算得上想法的部分**：「本人確認的最小必要支持摘要」——讓求助者帶一份自己控制的摘要去窗口，不用每個窗口重講一次，也不用全盤揭露。這是使用者本位的設計，跟 #14 的「停拆查問轉」是同一類的小而實在。其餘是既有的。 **問題** 1. **跟 #31 同樣的形狀**：4 頁 mockup、模擬資料、桌上演練、洽談中的場域、沒有社工或心理專業的家庭團隊、自創名詞（Wo、四微、27 種生命狀態——#31 寫「二微」，這件寫「四微」，兩件都沒定義）。 2. **自相矛盾**：說「不做風險評分、不自動通報」，但要導向「危機資源」——不評分怎麼知道誰是危機？Wysa 做這件事靠臨床團隊設計多層 SOS 流程；這件沒有任何安全設計的描述，而 LLM 直接回應正在痛苦的人。 3. **把結構問題個人化**：使用者的困境是財務壓力、照顧疲憊、工作耗竭，它給的第一步是「15 秒整理自己」。您在 #31 問過的問題在這裡一樣成立：一個找不到人替手的照顧者，Wo 一下之後呢？ 4. **公共資料應用幾乎沒有**：資料欄寫的是「總統盃、公民許願池、社安網 2.0」——那是政策文件，不是資料。 5. **隱私**：一句 Wo 包含情緒、財力、照顧狀況，由一家私人公司保管；有沒有送外部 LLM 沒說；使用者可能含未成年。它有寫「原始 Wo 不交政府或企業、治理端只看去識別化趨勢」，比 #31 多想了一步。 6. 它是一個等 SBIR 結果的商品，來總統盃找公部門通路。這跟 #10、#22 的結構一樣，只是產品更薄。 AI 評估：`suspected_existing = true`（自家產品，已揭露），`similar_existing = true`（FarHugs 幾乎同流程）。 e36e3881 2026-09-06 [15:35] 助理： SBIR 是「小型企業創新研發計畫」（Small Business Innovation Research），台灣經濟部（中小及新創企業署）補助中小企業做研發的計畫，仿自美國同名制度。中央有一個，各縣市也有自己的「地方型 SBIR」——#36 說的「桃園 SBIR」就是桃園市政府辦的版本。 **運作方式**：企業提一個研發計畫，通過審查後政府補助一部分經費（通常是總經費的一半以內，地方型一件幾十萬到一兩百萬元），企業自籌其餘，做完要交成果報告。分先期研究、研究開發、加值應用等階段。 **對 #36 的意義**：它代表 WoHere 已經是一個「公司拿去申請政府研發補助」的產品，而不是黑客松期間想出來的點子。提案自己揭露了這一點（第五題勾「已申請政府相關預算」），並主張 SBIR 做的是個人版和資料基線，黑客松做的是公共服務導航層，所以不重複。這個切法在形式上說得過去，實質上黑客松那一層很薄。 順帶一提，#22（鏈加科技）提到的「美國專利申請中」和這件的「SBIR 評審中」是同一種訊號：公司帶著自己的產品來找公部門的應用場景。 e36e3881 2026-09-06 [15:50] 助理： 加權總分 **6.63**（2.40 ＋ 1.68 ＋ 2.10 ＋ 0 ＋ 0.45）。排在 #34、#19、#22 之後。 資料治理 9 有充分依據（不存學生個資、來源與時間戳、Schema 開源、保存期限、AI 擷取有退路）。 只有**可行性 8** 想標記一次：一人團隊、沒列工程師、場域是「洽談」、核心資料要看國教署給不給、三個縣市平台的轉接器要自己維護。#32 六人有落地設計拿 7，這件一人拿 8，差距在哪裡我不太確定。若是因為它的落地設計（聯邦式、導回原站、測試目標具體）比 #32 更清楚，說得通。 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:02] 助理： 分數我沒有意見；比 #22 高一點也說得通——它面向農民，問題診斷更準。 沒有評語的話，兩件對提案人最有用的事不會被記下：一是價格預測公開後的反身性（大家都信就沒人種，官方預估價會被當喊價），二是它真正能改變行為的第 4 層（差別保費補貼）不是團隊做得出來的。要不要寫，您決定。 e36e3881 2026-09-07 [09:47] 助理： 搜尋查不到「農先知」的任何公開蹤跡——沒有網址、沒有報導、沒有 App。伊諾科技只有一個空的 LinkedIn 頁。農糧署燈號的部分之前在 #22、#54 已查證。 輪廓： **它是什麼**：兩家軟體公司（伊諾科技、日新軟體）三位工程師，加兩個「洽談中」的單位（農糧署、台北農產）。它反覆強調「**系統已完成開發並正式上線**」「並非概念構想」。內容：整合農情調查、批發市場量價、氣象資料，用作物生育週期把「現在種植面積」映射到「未來採收時間」，建 30／60／90 日供需預警與價格區間；農民端有作物推薦、種植時機、ROI 損益試算、AI 推薦；政府端有全台供需 Dashboard。技術是 Python、Scikit-learn、XGBoost、時間序列、PostgreSQL、Redis、REST API、RWD 前端，規劃再加 LLM 把模型結果翻成自然語言。回應許願池一條（「希望農民在種下作物之前，就能知道未來會不會賺錢」）。 **這是甘藍預警的第三件**：#22（鏈加科技，需求端拆解＋政策回測，給農糧署）、#54（兩人，積溫修正採收期＋把燈號翻成價格給農民＋差別補貼）、#58（三位工程師，通用的供需預測平台，農民和政府都給）。三件用同一批開放資料、面對同一個燈號機制。#58 跟前兩件相比，**沒有一個自己的切角**——#22 有價量共變拆解、#54 有積溫修正，#58 講的「生育週期映射採收時間、量價關係、氣候修正」是三件的公分母，也是農糧署燈號已經在做的「推估採收期」。 **決定性的問題：它說已上線，但拿不出任何東西。** 沒有網址、沒有截圖描述、沒有任何回測數字、沒有一個示範作物的預測誤差。一個「已完成並上線」的系統，提案裡最該有的就是「我們預測了什麼、對了多少」，一個字都沒有。它的期程第一階段寫「核心系統及 MVP 已完成」，第二階段才是「以歷史資料進行擴大回測、分析預測誤差」——也就是上線了但還沒驗證過準不準。這兩種讀法：一是系統真的存在但只是把資料接進來畫了圖，預測是名詞；二是「已上線」是寫給評審看的。不管哪一種，「已上線」都不該當它的優勢。 **其他問題** - 「第五題勾是」——但通篇說已完成、已上線，跟「尚未進行」的宣告矛盾；AI 評估標 `suspected_existing = true` 是基於它自己的敘述。 - 30–90 日的氣象預報本身不可靠，拿來當產量修正因子，誤差會被放大。 - 「農民在種下去之前知道會不會賺錢」——這正是 #54 討論過的反身性：大家都信就都不種，價格反而漲。 - 合作單位欄把「政府單位／農業部農糧署」和台北農產填成成員，狀態是洽談中；三位工程師沒有農業專業，輔導需求裡自己寫要專家「協助確認作物生育週期、種植面積與實際上市量之關聯」——那是模型的核心假設。 - 分工空白；文風是標準的 LLM 排比（沒有揭露用 AI 寫提案）。 **好的一面**：資料標準化和分層儲存寫得認真（來源、更新時間、版本）；AI 用在該用的地方（時間序列預測），LLM 只做翻譯層。 AI 評估：`substantive_junk = false`，`suspected_existing = true`（自述），`similar_existing = true`。 e36e3881 2026-09-07 [21:10] 助理： 評語準確。分數沒有問題，跟 #35、#51 的「既有計畫」處理方式一致。 一點供參考：它跟 #22、#54 是同一題的三件，之後平衡時可以放在一起看——這件是三件裡唯一沒有自己切角、也拿不出任何驗證數字的。 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 [18:01] 助理： 這個假設站得住，而且它拆掉了我剛才那條規則的前提。我說「定義到能做出來的程度就算分」，但 LLM 最擅長的正是把一個名詞展開成六個欄位——「來源、涉及市場、資料完整性、可信程度、不能下的結論、下一步查核」，這串就是問模型「一張查核卡該有什麼」會得到的標準答案。具體不等於有人負責。 所以「具體」不能當證據，要找的是**LLM 不會自己生出來的東西**——只有真的做過才寫得出的痕跡： - 一個確切的數字：22,970 筆、四個市場、休市日曆——這些要真的抓過資料才有。 - 一個反直覺的決定：「休市不視為零交易量」「批發市場交易量不當成全國產量」——這是踩過坑的人才會特別寫出來的，模型不會主動想到。 - 一個具體的失敗或限制：「批發到貨量只看到部分流通」（#22）、「只有 2.4% 打專線」（Wysa）。 - 一個場域裡的人才知道的細節：「肥料配方是農民的秘密」（#15）、「怕停太久後面排隊」（您對車手的觀察）。 #16/#211 有前兩類，所以我判斷他們知道觀測卡是什麼。但「事件卡」和 Decision Profile 一個都沒有，就是空的。 這條線最終還是只能在初審畫到「有沒有做過的痕跡」，畫不到「團隊能不能負責」——那要面談才知道。您說的沒錯，這不是定論；但它至少讓「越具體越可疑」變成一個可以操作的檢查：**具體的東西裡，有沒有一件是模型猜不到的。** 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: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 [17:26] 助理： #219 農擇智策（游家昇／**聖得醫學科技**，4 人；智慧治理，主題 4；未評分） **團隊要先點出**：**聖得醫學科技是一家醫療科技公司**（CEO、演算法工程師、平台架構師、PM，四人全自家員工），**跟農業毫無關係**。查證 suspected_existing = false：查無它任何農業成果。這是一支**做醫療的軟體團隊跨界來投農業案**，無農業／農經領域人。 **這是什麼** 用農業部＋氣象署開放資料，做**雙端供需預測平台**： - **農民端**：依作物、產區、生育期、成本、風險偏好，給採收窗口的**收益區間、風險、產銷建議**； - **消費者端**：未來 **7–14 日菜價趨勢、漲跌原因、替代品建議**。 共用一個供需預測核心（LightGBM/XGBoost），Bronze/Silver/Gold 資料分層、point-in-time 特徵、walk-forward 回測、附信賴區間。 **工藝面其實不錯（先講好的）** - **資料工程寫得專業**：列了十來個官方資料源（交易行情、農情調查、農情預測、供苗預警、氣象、成本調查、土壤網格、災損…），Bronze/Silver/Gold 分層、point-in-time 避免資料洩漏、walk-forward 回測、模型卡、信賴區間 —— 這套 MLOps 紀律在農業案裡算好的。 - **誠實不虛列**：明寫「無自備資料、尚未全量串接，故不虛列資料筆數與訓練期間」、「初審聚焦共通解法，實作期再選場域」、「批發價僅作趨勢指標、不宣稱等同零售價」。 - AI 揭露誠實（核心是傳統 ML，Codex 只做盤點與文書）。 **最決定性的問題（依重要性）：** **一、它想做的兩端，官方都已經有現成系統 —— 查證後很清楚。** - **消費者端（菜價趨勢、漲跌原因）＝ PDIS「菜價整合平台」**：我實查，PDIS 早就整合零售價、批發價、氣溫雨量、庫存、預估產量、進口量成一個查詢介面，還疊天氣看關聯、開源、有 API，**2017 就上線**。#219 的消費者端幾乎是它的重做。 - **農民端（供給／採收預警）＝ 農糧署「大宗蔬菜供苗預警燈號」**：我實查，它已提供供苗量、當旬警示燈號、與三年均比較、推估採收期。#219 的「領先供給訊號」就是接它。 - 加上開放資料 LSTM 甘藍價格預測論文早有。所以 #219 是**把 PDIS ＋ 供苗燈號 ＋ 價格預測模型整合改寫**，新意有限（similar_existing = true）。它自稱的創新「用同一核心連接兩個時間尺度（選作 vs 7–14 日菜價）」是唯一差異點，但那也只是把兩個既有系統的資料接在一起。 **二、羊群效應（reflexivity）—— 這是它作為「選作建議」最根本的自我矛盾。** - 若很多農民**依同一個預測選作**，就會**一起去種被預測看好的、一起避開被預測看跌的** → 反而製造新的集中上市與過剩，**預測自己把自己推翻**。這跟 #54 討論到的反身性是同一個坑，而 #219 完全沒處理。它想解「追價集中種植」，但一個公開的集體選作建議，恰恰可能**加劇**它。 **三、團隊與領域完全不符 + 無場域 + 無農業專家。** - 醫療科技公司做農產供需，**無農業／農經領域人**；生育期、上市量、適作性這些模型核心假設，需要農學知識校準，團隊沒有。 - **場域完全未定**（連品項、產區都說「實作期再選」）—— 比其他菜價案（#22 向農糧署申請、#54 有北港合作社）更空。 - 預測失準的責任歸屬未談（農民依它選作賠了、消費者依它判斷）。 **四、has_card_jargon 觸發** —— 我看提案本文沒有明顯「XX卡」術語，這個旗標可能誤判（或抓到「模型卡」這種正規 ML 詞）；不當堆砌扣分，但值得您留意它是自動旗標、非人判。 **與主題 4 其他案對照**：#22（價量拆解）、#54（積溫修正採收期）各有**真切角**、且更接地（有申請／有合作社）；#219 工藝相當、但**沒有自己的切角**（兩端都是既有系統整合）、團隊完全跨界、場域最空。定位比較接近 #58（自述完整但缺實證）那一類，只是 #219 更誠實（不宣稱已上線）。 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 都帶「卡詞」（觀測卡/事件卡；模型卡），這是您說要**期末統一做一次卡詞平衡**的對象 —— 留到那時一起看。 其餘六件的相對平衡我沒有意見。 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。 還有什麼問題？ c84bcc28 2026-09-13 [23:03] 助理： 帶狀 20 案（第 11–30 名）原文我已全部讀完，對照裁定過的項目後，剩下這幾件： **會動到入選線（第 20 名 #226 6.81／第 21 名 #134 6.78）的** 1. **#83 黑豬產業 創新 9**（第 12 名 7.38）。兩個模組：「飼料配方專家系統」是線性規劃最低成本配方，這是數十年的標準做法，台灣 2003 年就有中興大學的「飼料配方線上計算系統」論文，商用軟體遍地都是；「植物性剩餘物質查詢平台」是把環境部事業廢棄物申報年報畫成地圖加距離。私註寫的本質就是「找附近哪裏有豆渣酒糟」。9 分和 #179 洗產地同分。若創新降到 6，總分 6.48，掉到線下。 2. **#213 農災韌力雷達 創新 7**（第 14 名 7.11）。核心是 RAG 拿法規與救助公告做 LLM 問答，這是 #155 被裁定「改成用 LLM 問問題已經做爛了」給 2 分的同一型；不同的是它另外有「農民登錄作物×鄉鎮比對公告主動推播」和「部落回報覆蓋率圖層」。要看本質算哪一半。若創新降到 5，總分 6.51，掉到線下。 **不跨線、只影響線下次序的** 3. **#71 熱風險路口 可行 8 vs #59 鯪鯉 可行 5**。#59 給 5 的理由是 LED 警示器「11 月中」才裝設測試，在 11/11 決審之後。#71 自己的期程是「第 7 至 8 週場域安裝、第 9 週分析前後差異」，9/18 起算第 8 週已是 11/13，同樣落在決審之後，硬體（遮陽＋噴霧＋致冷＋綠能儲能＋AI 攝影機）還要宜蘭縣政府道路施工許可。兩案同一種缺陷，一個 8 一個 5。 4. **#153 蛋價 資料治理 4 vs #226 地震派檢 資料治理 10**。兩案都是純開放資料分析、都有原始層／清整層分離、品質旗標、版本可重跑、不含個資；#153 的資料管線甚至更完整（缺日不插補、零值視缺值、一鍵重跑）。差 6 分。#153 就算治理拉到 10 也只到 6.47，不跨線。 其他：#22/#239 創新、#177 創新、#19 創新、#226 創新、#77 可行、#181 可行、#153 可行與影響、#134 治理、#71 創新、#190 創新皆已裁定，未再列。 Sources: [飼料配方線上計算系統（臺灣博碩士論文）](https://ndltd.ncl.edu.tw/cgi-bin/gs32/gsweb.cgi?o=dnclcdr&s=id=%22091NCHU0289028%22.&searchmode=basic)、[飼料成本極小化之最適規劃模型（華藝）](https://www.airitilibrary.com/Article/Detail/U0017-0808201911465200)