樂學雷達：讓每個孩子都找得到、報得到暑期學習機會

=== e36e3881 2026-09-06 15:40 === [15:40] 評審： 下一個提案：#37「樂學雷達：讓每個孩子都找得到、報得到暑期學習機會」。 [15:42] 助理： 四個來源都開了。輪廓： **它是什麼**：一人提案（產品與政策規劃背景），要做寒暑假學習活動的**跨校跨縣市搜尋層**，不是報名系統。家長免登入，依距離、年級、日期、主題、費用搜尋，找到後導回原本的報名系統。資料來源三種：地方政府既有平台的公開欄位（API 或轉接器）、學校用表單或試算表上架、沒有介面時由 AI 把公開公告擷取成「待確認草稿」再人工覆核。定共通 Schema 和資料字典並開源。政府端看去識別的供需儀表板（額滿速度、跨校開放率、區域可及性）。不存學生個資。北北桃先試。期程寫到日期，決審前目標 50 筆資料、5 位家長、3 位承辦、1 個教育單位測試。 值得注意的一點：問題描述引用了一封**國教署的民意信件回函**（臺教國署國字第 1150073229 號）——提案人真的去問了主管機關，回函說各校開放對象不一、平台由地方規劃、媒合統計請找地方政府。這是全案立論的基礎，也是目前看到唯一一件用公文往來當證據的提案。 **查證** - **台北市國小暑期體驗營**（holiday.tp.edu.tw）：市府平台，依類別瀏覽，問題要自己聯絡承辦學校。 - **新北市寒暑期育樂營**（camp.ntpc.edu.tw）：跨校集中報名網站。 - **桃園青春不放假**：354 個營隊、預計 5.5 萬人次，官網統一報名。 - **AICamp**：民間付費營隊的彙整站，不含公立學校。 所以**北北桃三個縣市各自都有跨校平台**，提案自己也明講，定位是「在三個平台上面加一層跨縣市搜尋」。但它問題描述裡的主角其實是**夏日樂學**——1,371 校、3.5 萬人次、**沒有任何集中的招生資訊**，散在各校網站。這個缺口是真的，國教署回函也證實了。 **需要您判斷的** 1. **第 N+1 層的問題，但形狀比較對。** 它是聯邦式的：不取代、不收報名、導回原站、產出共通 Schema。這比 #11、#20 那種「再做一個平台」好，比較像是在做資料標準。可是三個縣市平台各自改版時，轉接器誰維護？一個人。 2. **真正的解法可能更簡單。** 夏日樂學的缺口，只要國教署把核定方案（校代碼、課程、期程、年級、名額）當開放資料公布，就解決了大半——提案的資料需求表要的正是這份資料。它做的 Schema 和資料字典是往這個方向走，這是對的槓桿；但如果國教署願意給資料，平台本身就不太需要了。 3. **跨縣市搜尋的需求有多大？** 台北家長會送孩子去桃園上暑期營嗎？而且各校「開放對象不一」——非原校生常常根本不能報。限制在資格，不在搜尋。提案有設「跨校開放名額使用率提升 10%」的指標，表示它知道。 4. **試辦場域選得跟受益者相反**：它說要幫偏鄉、新住民、弱勢，試辦卻在北北桃——三個已經有平台的地方。 5. 一人團隊、分工空白；不回應許願池；爬其他縣市網站的授權只說「不規避權限」。 **好的一面**：AI 用得克制（只擷取公告成草稿、人工覆核、擷取不可靠就改人工表單）；不存學生個資、保留來源與時間戳、Schema 開源、設保存期限——資料治理寫得完整；指標可量測；期程對得上賽期。 順帶一提，這位提案人跟 #3 是同一人（同電話信箱），兩份提案的品質差距很大。 AI 評估：`substantive_junk = false`，`similar_existing = true`（北北桃各自有平台）。 [15:46] 評審： 這和家長自己search，或是家長請ChatGPT search，有什麼差別？ [15:47] 助理： 差別不在「搜尋」，在「有沒有可以被搜尋的資料」。 **家長自己 Google 會遇到的**：夏日樂學的招生公告是 1,371 所學校各自貼在校網上的 PDF、圖片、公告系統，Google 索引不完整、不即時；搜「夏日樂學 三年級 7 月 新北」出來的是新聞稿和教育部政策頁，不是課程清單。就算找到一所學校的公告，名額、資格、是否收非原校生、截止日這些欄位要自己一頁一頁讀，而且營隊幾天就額滿，找到時常常已經過期。 **請 ChatGPT 搜會遇到的**：它底下還是同一批網頁，抓不到的一樣抓不到；抓到的公告是非結構化文字，它會漏、會混淆年度、會把去年的當今年的，而且不會告訴你它漏了哪些學校。對「我孩子三年級、住板橋、7 月第二週有空、要免費的」這種多條件查詢，它給的是一段看起來很完整的猜測。 **提案做的差別就是把資料變成結構化的**：每筆有校代碼、年級、日期、費用、資格、名額、截止日、更新時間、來源連結，還有失效檢查。有了這個，家長用什麼工具搜都會準——包括 ChatGPT。 **所以誠實的結論是**：它的價值在資料層（Schema、欄位、更新規則、來源追溯），不在搜尋介面。如果國教署把核定的夏日樂學方案當開放資料公布，Google 和 ChatGPT 隔天就能回答家長的問題，這個 App 的搜尋頁就沒有必要了。提案有意識到這一點——它要的未開放資料正是核定方案，它開源的是 Schema——但它還是把主要產出做成一個搜尋網站。 至於北北桃那三個縣市，市府平台本來就是結構化的，家長自己上去搜就好，ChatGPT 也搜得到。所以跨縣市那一層的邊際價值更小。 [15:50] 評審： 8/6/7/0/9？ [15:50] 助理： 加權總分 **6.63**（2.40 ＋ 1.68 ＋ 2.10 ＋ 0 ＋ 0.45）。排在 #34、#19、#22 之後。 資料治理 9 有充分依據（不存學生個資、來源與時間戳、Schema 開源、保存期限、AI 擷取有退路）。 只有**可行性 8** 想標記一次：一人團隊、沒列工程師、場域是「洽談」、核心資料要看國教署給不給、三個縣市平台的轉接器要自己維護。#32 六人有落地設計拿 7，這件一人拿 8，差距在哪裡我不太確定。若是因為它的落地設計（聯邦式、導回原站、測試目標具體）比 #32 更清楚，說得通。 [15:52] 評審： 8/6/7/0/5「如何永續營運維護？」如何？ [15:52] 助理： 加權總分 **6.43**（2.40 ＋ 1.68 ＋ 2.10 ＋ 0 ＋ 0.25）。 評語問到點上——一個人維護三個縣市的轉接器，這是它最實際的風險。 一點供您參考：**資料治理 5** 跟 #36 的 10 對照起來倒過來了。這件不存學生個資、每筆保留來源與時間戳、失效檢查、設保存期限、Schema 開源、AI 擷取保留原文與提示版本並抽樣量測正確率——寫得跟 #14、#32 是同一個等級。#36 是「原始 Wo 不交政府」加幾句原則。如果您平衡時要對照，這兩件是明顯的一組。 [15:52] 評審： 8/6/7/0/9「如何永續營運維護？」如何？ [15:53] 助理： 加權總分 **6.63**（2.40 ＋ 1.68 ＋ 2.10 ＋ 0 ＋ 0.45）。 評語問的正是它最弱的一點——轉接器跟著三個縣市平台改版、一個人維護。 只有**可行性 8** 想確認一次：這是一人團隊、場域「預計」北北桃、沒有任何確認的合作學校或教育局。它的落地設計（聯邦式、不取代、導回原站、有日期有指標）是目前最清楚的，這值得分數；但跟 #11（體制內、有資料有使用者，9）和 #34（六人、有前作、7）放在一起，一個人沒有場域拿 8 稍微高了一點。若是刻意給落地設計的，我不再提。 [15:53] 評審： 因為這是可以改善的問題。黑客松就是要他來參加黑客松找團隊改善的。 [15:54] 助理： 了解，這個原則說得通：**可行性看的是「有沒有結構性的障礙」，不是「現在人夠不夠」。** 缺人是黑客松本身就設計來解決的問題（入選後媒合團隊、輔導），不該扣；產權談不下來（#3）、經濟模型不成立（#19）、誘餌沒證據（#23）那種才是扣分的理由。 這樣回頭看，#34 的可行性 7 也是同一個邏輯——沒工程師是可以補的，落地設計好才是重點。我把這條記進記憶。 [15:54] 助理： 記好了。#37 加權總分 6.63。 === e36e3881 2026-09-08 21:47 === [21:47] 評審： #37的「統一課程卡片」是什麼？ [21:47] 助理： #37 的原文是效益欄那句：「對學校，一次建檔即可產生統一課程卡片與 QR Code，減少重複公告及基本詢問」。 這個「卡片」的脈絡跟 #16 不同，它有前後文可以推：學校把課程資料（名稱、年級、日期、地點、資格、名額、費用、報名連結）填進共通 Schema 之後，系統用同一個版型產出一張課程的「介紹頁」，配一個 QR code——學校可以印出來貼公告欄、放家長群組，家長掃了就到搜尋層的那筆課程。也就是「一份資料、一種格式、到處貼」，是為了讓學校不用每個平台重複公告。 所以 #37 的「卡片」是「標準化的一頁課程簡介」，它在流程裡的位置寫了（學校建檔 → 產出 → 家長掃碼），產生者和接收者都有。跟 #211 的「觀測卡」相比，它是有脈絡的；但它同樣沒有定義「卡片」這個詞本身，也是那個共同詞彙。差別在 #37 用它的方式，一個不認識這個詞的人也讀得出意思。 === 事後／並提討論 === e36e3881 2026-09-08 [07:34] 助理： 評語準確，這正是它多出來的那一段。可以再加半句：「板橋、台北已試辦氣溫觸發的自動遮陽傘，建議參考。」讓他們知道有現成的可以看。 分數只有可行性 8 想提一次：這是高中生加國中生三人，硬體清單有遮陽、噴霧、致冷、儲能、攝影機、感測器六種，場域未談。跟 #37（一人做軟體、落地設計清楚、8）比，這件要做的東西重得多。若 8 是鼓勵學生的話，跟 #13 的 5 對照一下。 e36e3881 2026-09-08 [11:57] 助理： 分數沒有問題。 評語準確。只提一點：可行性 6 對這件稍低——它是農業案裡落地最完整的（資料、技術、場域、操作者全在隊裡，期程到週），比 #37（一人無場域）的 8 低兩分。若 6 是因為方法陳舊或落地細節仍有疑慮，說得通；若是把「不需 AI」也算進可行性，那已經在創新性扣過了。您決定。 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:49] 助理： 這句的斷句是「安心求助 測 整理卡必要欄位完成率」——「安心求助」是它第三個功能的名稱，「測」是量測，「整理卡」是那個功能產出的東西。 「整理卡」在提案裡的脈絡：「安心求助：遇到動保事件時，在裝置端整理時間、地點與客觀狀況，照片不上傳，再銜接 1959 正式通報。」所以整理卡是飼主在手機上填的一份動保事件摘要——時間、地點、客觀狀況——填好了再自己拿去打 1959。效益欄的指標是「整理卡必要欄位完成率」，也就是使用者填得完不完整。 跟 #211 比，它有產生者（飼主）、內容（三個欄位）、去向（1959）；但「卡」這個詞同樣沒有定義，而且這個功能本身就很薄——一張三欄位的表單。它是一個有脈絡但沒什麼內容的卡。 三件排下來：#37 的卡有流程有用途、#70 的卡有流程沒內容、#211 的卡有內容沒流程。三個團隊互不相干，「卡」出現在三種不同的完整度裡——這更像是模型把這個詞塞進去、各團隊各自消化到不同程度，而不是三個團隊各自想到同一個詞。 e36e3881 2026-09-10 [09:07] 助理： 先更正我自己一個算術錯：**#236 是 3.09 不是我先前說的 2.94**（7×.30+3×.28+3×.05）。以上表為準。 我刻意**不硬找問題**（您剛提醒過）。整體分佈我認為**相當扎實**： - 底部乾淨且一致：兩件既有產品（#154、#236）創新性都 0；三件「AI 核心做不到＋反傷農民或亂語」（#104、#222、#171）都壓在 1 以下；無人機雙胞（#84/#89）同分；否決級的 0 用得一致。這些不用動。 - 中段（#13/#154/#152/#164/#236，3–4 分）是「各有致命傷」的混戰，相對關係都說得出理由。 **唯一真正值得您再看一眼的，是最上面三名 —— 而且我要誠實說，這是「判斷」不是「錯誤」：** `#237 7.44 ＞ #188 7.11 ＝ #213 7.11`，三者只差 0.33、都很強。關鍵在 **#237 靠 8/8/8 登頂，但它是這三名裡「落地準備最差」的一件**： - **#188**：真軟體公司（本業就做 LINE bot）＋**已確認**的社區夥伴。 - **#213**：**已確認**原民 NGO 合作＋法律專業＋研究最深＋資料治理最高（8）＋打最弱勢的原鄉。 - **#237**：**三名學生、無領域人、零實作（資料欄全空）、還需機關歷年資料才能回測**。 依您 #37 的原則（可媒合的缺口不扣可行性）＋ #68（可行性＝做得出來），#237 核心只靠開放資料＋軟體就能建、無結構性阻礙，**可行性 8 站得住**，我不主張一定要改。 但若您在**這個最頂端**想用「落地準備度」分高下 —— **#237 的可行性 8 就是唯一的施力點**：它是三者中唯一「連場域都還沒確認、也還沒動工」的。把它落到 6–7，總分會降到約 6.8–7.1，就會**退到與 #188／#213 並列或之下**，讓「有確認場域、研究更深、治理更好」的 #213 上來。 所以問題收斂成一句：**#237 是否真的該壓過「研究最深、場域已確認、治理最好、打最弱勢」的 #213？** 若您認為「把風險導向稽核引進公共流程」的制度創新值這個第一，維持即可；若您重視落地準備與原鄉價值，#213 該與它並列或在其上。這一格是我唯一建議您重看的，其餘 14 件的相對平衡我沒有意見。 e36e3881 2026-09-11 [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 的分界合理。 不動。 e36e3881 2026-09-12 [00:05] 助理： 了解,收回那個 flag。你的理由成立,而且點出我比錯了軸: - **可行性看的是「能不能大規模鋪出去」,而那本質是成本問題**——感測器逐棟 × N 棟。#101 用衛波的專業級感測器、貴;#103 用低成本公民科學套件、便宜。所以同樣一句「難以大規模實施」,**對便宜的 #103 是『比較不難』**——5 萬棟的成本牆對它低。可行性 6 > 5 因此站得住,而且 Safehub 本來也是靠**低成本**感測器商品化的,證明便宜這條路走得通。 - **我剛才比的是團隊能力**(#101 有結構教授、有成品)——但那正是你 #37/#237 講過「黑客松不因團隊/未落地扣可行性」的東西,**不是可行性該計的軸**。我用錯軸了。 一個誠實的殘留(不是要翻案):便宜是拿**精度/可靠度**換的——公民科學套件量不量得準自然頻率變化、抗不抗得住風/車流雜訊,是它的風險;不過 Safehub 用低成本也做成了,這個風險被沖淡。 所以 **#103 定案 6/8/1/2/4 = 4.64,我沒有意見了。** 主題13 剩最後一件 #184。 c84bcc28 2026-09-12 [09:16] 助理： 三層都對齊了(原文、#32 那輪的完整討論、現值)。你當時的邏輯我掌握了:可行性從 9 收到 7(無工程師、場址未定、期程超期,但依 #37 原則「缺工程師是黑客松可補的」所以不再低)、多元 10、資料治理 9(逐筆補助標來源與查核日、LLM 不判資格、公文即刪、TWCC 不出境),重複上傳依「最後上傳留分」給 #34、#32/#33 歸零。無評語。 **跨主題平衡:#34 的 7.69 落在上段,位置是自洽的。** 把它和記憶中最接近的幾件排開: | | 分數 | 加權 | |---|---|---| | #52 詐騙終結站 | 9/8/9/6/10 | 8.44 | | #179 洗產地 | 9/7/9/4/10 | 8.06 | | #62 反詐養蜂人 | 8/8/9/1/10 | 7.89 | | #204 Eden Cube | 7/8/10/2/6 | 7.74 | | **#34 農民補給站** | **7/8/8/10/9** | **7.69** | | #232 磷超載 | 8/8/8/3/10 | 7.69 | | #71 光蔭之間 | 8/9/8/1/3 | 7.52 | | #237 / #226 / #83 | | 7.44 / 7.41 / 7.38 | 每一個相鄰的順序都有證據撐: - **在 #52、#179、#62 之下**是對的——那三件都有**已完成的 PoC 或更新的核心**(#179 鏡像貿易已跑出帳差、#62 蜜罐、#52 ATM 感測+跨行感染鏈),可行性 8–9;#34 的「反向比對」概念國內外都有(GetGrant、USDA 工具、印度 Kisan e-Mitra),自有的是公文白話化/災前健檢法定豁免/放棄鍵,而且**沒有工程師**——創新 8、可行性 7 比它們低一階,合理。 - **和 #232 剛好同分 7.69**,而且是互補的:#232 可行性 8/資料 10、多元 3;#34 可行性 7/資料 9、多元 10;兩件都是創新 8、影響 8——兩件同樣精心、強項不同的案子落在同一個總分,是平衡的,不是巧合的問題。 - **#204 高它 0.05**:純靠創新 10(世界首見的框架)壓過 #34 的創新 8;#34 靠多元 10/資料 9 補回。合理。 - **在 #71/#237/#226/#83 之上**:那幾件不是在地化既有方法就是既有元件整合,#34 的自有設計比它們多,又對到你社會影響力定義裏的**弱勢農民 + 台語**加分點。 所以**不需要調整**。 一個 #59 式的補充(你的取捨):#34 至今**沒有評語**。有兩個已查證、你當時知道的問題沒被記下——(a) **團隊未列工程師、場域未定**(你可行性只給 7 的原因),(b) 第二份 AI 評估抓到的**「公文影像處理後即刪」vs「用 100 份公文微調 OCR」自相矛盾**(微調需要留存影像)。要不要補進評語你決定。 c84bcc28 2026-09-12 [09:23] 助理： 兩件讀完(原文 + 討論 + 現值),當時的邏輯我掌握了: - **#36 = 6/5/0/5/10 = 3.95**「這是現有產品服務。」——WoHere 是團隊自家產品(已申請桃園 SBIR、也搭售在同公司的 #31),創新 0 是「自己做好了」那格;私人註記記了「已申請桃園 SBIR」。 - **#63 = 0/0/0/1/0 = 0.05**——可行性 0 是「它不會療癒患者」(宣稱的核心效果不可能達成,和 #23 誘餌同類,後來成為這條原則的錨定案例);臉部特種個資與「0 個資」矛盾。 一件留到平衡的舊帳:當時評 #37 時我提過 **#36 的資料治理 10 和 #37 對照是「倒過來的」**,你當時把 #37 拉到 9、#36 沒動。這個點我記著,等 #81 評完做主題18 平衡時再看一次。 主題18 剩 **#81** 未評,你給編號就繼續。 c84bcc28 2026-09-12 [09:39] 助理： 主題18 排序:#81(4.63) > #36(3.95) > #63(0.05)。三件都在脈絡裏,不重抓。 **結論:有一處值得你看——#36 的資料治理 10。其餘一致。** **#36 資料治理 10 vs #81 資料治理 3。** 這是我在 #37 那次就標記過「倒過來」的舊帳,當時你把 #37 拉到 9、#36 沒動;現在同主題有 #81 可以直接對照: - **#81 = 3**:有真的資料設計——原始訊號留實驗室主機、平板不留存量完即清、個資與訊號分開只以流水號連結、去識別、記錄開放資料版本日期;缺的是**服務階段的同意機制**(住址與風險值回報衛生局超出研究同意)。 - **#36 = 10**:有「原始 Wo 不交政府、摘要本人確認、治理端只看去識別趨勢」三句設計,但**沒提外部 LLM(用 ChatGPT/Gemini)、沒提法源、沒提未成年同意、沒提危機處理**;情緒與財務資料放在一家私人公司手上。當時我就說「大概在 6–7,若 10 是刻意的,我不再提」。 同一個維度,**設計較實、缺一個同意機制的 #81 給 3,設計只有三句、缺四樣的 #36 給 10**——這個反差不容易站住。你拿 10 的基準是 #14(來源帳冊、版本、最小蒐集、明示限制)和 #32/#34(逐筆標來源與查核日、影像即刪、資料不出境),#36 沒到那個等級。權重只有 5%,動 #36 到 6–7 總分只掉 0.15–0.2、排序不變;要不要動是你的心證,我把對照擺這裏。 其餘一致: - **創新 #81=0、#36=0、#63=0**:三件全 0 但理由各異且都對——#81 自己做完的論文、#36 自家產品、#63 沒依據的核心;「自己做好了」那格兩件、「不成立」一件。 - **可行性 #81=9 > #36=6 > #63=0**:達得到自己目的(再收案)> 做得出但只是產品加導航 > 不會療癒患者。 - **社會影響力 #81=6 > #36=5 > #63=0**:農村長輩客觀初篩 > 都市一般人的一句話日記 > 無依據。方向對。 除了那一格,不動。 c71e996e 2026-09-14 [08:04] 助理： 是，混了。627行裡： - **一般性原則**（該留的）：五個維度的定義（可行性＝目標可達性而非成品完成度、創新0分只給「已有人做出來的產品」、零分＝否決旗標）、錯誤方向（誤判由誰承擔）、乾淨核心勝過落地就緒、LLM文字紅旗、你打分後我才給意見、重看已評案的閱讀順序……大約三分之一。 - **今年提案的評審理由**（不該混在裡面）：#14、#37、#39、#49、#68、#74、#104、#152、#153、#162、#195、#201、#211、#212、#216、#221、#235、team 4、team 22、主題2/13/35–38的評分、三輪全域平衡的逐案裁決……都是逐案紀錄，而且大多已經在DB的`comment`/`private_note`裡。 建議拆成兩份： 1. `judging-scoring-philosophy.md`——只留蒸餾過的通則，每條一段，不帶案號（案號頂多當例子括號註明）。 2. `judging-2026-rulings.md`——今年的逐案理由與平衡裁決，明年可整份刪掉。 要我拆嗎？拆的時候通則我會重新精煉、不是搬段落。