Care Relay 全臺高齡照護量能接力網：AI 驅動跨機構支援與動態照護治理

=== e36e3881 2026-09-06 08:54 === [08:54] 評審： 下一案#31「Care Relay 全臺高齡照護量能接力網：AI 驅動跨機構支援與動態照護治理」 [08:56] 助理： 查完了。輪廓： **它是什麼**：七人團隊（漫慢文創科技執行長帶頭，成員含另一家工作室負責人（同一人列了兩次）、一位儀器公司執行長、一位資料行政、一位大二生、一位高三生，五位姓陳），要做「照護量能接力網」：家庭或機構明天出現 4 小時照護空窗 → 開一張 Care Ticket → 系統依序找曾合作的照服員、當地符合資格的人、資格過濾後公開詢單、最後親友接棒；多人家庭用 Care Circle 看誰接了哪一棒、Split Care 拆時段、Care Balance 提示責任是否長期集中；未承接的需求彙整成政策儀表板。黑客松階段只做 **4 頁 PWA 概念原型加模擬資料**，不做交易、金流、政府 API，用桌上演練驗證。等待期可用「WoHere 二微」做情緒微支持。 **查證** - **家天使**：臨時看護媒合，單次 3–24 小時，照服員有國家證照且經面試審核，每小時 280–390 元加 200 元平台費，線上打卡、雙向評價。「4 小時空窗找專業照服員」是成熟的商業服務。 - **CircleCare**（美國）：家庭照護圈 App，共用行事曆、用藥提醒，月費 6.99 美元。家人分工協調也有現成的。 - **愛長照**：資源平台，免費專人協助找看護。 - **WoHere**：漫慢文創科技官網上的產品，「我在這裡｜個人覺察與照護支持」——**確認是團隊自己的產品**，被包進提案當「等待期微支持」。 提案自己也列了優照護、Care724、家天使做比較，說「不是另一個 AI 找照服員平台」。這點誠實。 **它真正新的地方只有一個，而且是好的**：把「沒人接的空窗」和「長期由固定家人扛的照護」變成**政策資料**——夜間、假日、偏鄉、哪種技能缺，這是政府現在看不到的。正式照服員、短期親友、持續性非正式照護、未承接需求分開標記，這個資料模型有想法。 **問題** 1. **平台讓量能被看見，但不創造量能。** 偏鄉的問題是沒有人，不是看不到人。這跟「願意搬的人本來就會自己搬」是同一類：需要接力的地方沒有人可接，有人可接的地方家天使已經在做。 2. **親友接棒「不問費用」**——這句話的效果是讓無照有償照護在平台上流通而不被記錄。長照法對誰可以提供有償照護有規範，提案繞過了。 3. **跨機構支援的責任沒談。** A 機構的照服員去補 B 機構的班，雇主是誰、保險誰保、出事誰負責、登錄報備怎麼走——長照人員登錄是綁機構的。提案把這些全放進「希望主辦提供諮詢」。 4. **「AI 驅動」是標題膨脹。** AI 只做兩件事：把自然語言變成工單，以及 WoHere 生成情緒支持回應。後者是對高壓照顧者用 AI 講安慰話，沒有任何把關，而且是自家產品搭售。 5. **產出是 4 頁 mockup 加模擬資料**，配了十個自創名詞（Care Ticket、Circle、Passport、Path、Capacity、Balance、Roaming、Station、Split Care、WoHere 二微）。名詞密度跟產出厚度不成比例。 6. 七人沒有一位長照專業；場域「洽談」中；分工空白；沒回應許願池。 7. 隱私：Care Circle 讓家人互相看到誰出了多少力，小生活圈的去識別資料容易再識別；有寫最小蒐集，沒寫法律依據與同意流程。 AI 評估：`substantive_junk = false`，`similar_existing = true`。 [09:19] 評審： 所以這是臨時照護員媒合平台嗎？ [09:20] 助理： 核心是。使用者做的事就是「明天缺 4 小時，幫我找人」，系統回一串人選——這是媒合。 它在媒合外面包了兩層： 1. **把親友也算進人選**，並給多人家庭一個「誰接了哪段」的分工畫面。這是家天使沒有、CircleCare 有的東西。 2. **把沒媒合成功的需求記下來**，彙整成「哪裡、什麼時段、缺什麼能力」的政策資料。這是它唯一真正沒人做的部分。 但黑客松階段它不做交易、不做金流、不接政府 API，所以連媒合都只是「顯示人選」，不是「完成媒合」。剝掉名詞之後，決審會看到的是一個四頁的示意畫面：填需求、看人選、看家人分工、看儀表板。 所以更精確的說法是：**一個「臨時照護媒合平台」的概念稿，附帶一個好的資料想法（缺口統計），和一個自家產品的置入（WoHere）。** [09:22] 評審： WoHere是什麼？ [09:23] 助理： 查到的很少，只能講確定的部分： - 漫慢文創科技的官網（一個 manus.space 的頁面）上列了一個產品：**「WoHere｜我在這裡｜個人覺察與照護支持」**。正式網站 slowlifect.com 擋掉了我，看不到內容。 - 搜尋摘要說這家公司做一個叫 BE HERE 的 B2B SaaS「行為分析／情緒覺察」平台。WoHere 應該是同一系列。 - 提案裡的用法：需求送出後、等下一棒來的期間，照顧者可以「自願使用 WoHere 二微短暫整理壓力」，由 AI「產生短篇支持回應」。「二微」是什麼，提案沒有定義，我也查不到——猜是「微覺察、微支持」之類的自創詞。 所以就目前能確認的：**它是這家公司自己的情緒支持產品，在照顧者等人來的那幾分鐘，給你一段 AI 寫的安慰話。** 放在這個提案裡的問題有兩個：一是它跟「找人接班」沒有關係，是搭售；二是對一個正在崩潰邊緣、找不到人替手的照顧者，用 AI 生成安慰語，提案自己也承認「不取代實際人力支援」——那它在那個時刻的作用是什麼，沒有回答。 [10:31] 評審： 所以提案裏有很多未解名詞：WoHere，二微，連你查過也不知道是什麼，對吧？ [10:31] 助理： 對。而且不只這兩個。提案裡自創的名詞有十來個，提案本身都沒有定義： - **WoHere**：查到是自家產品名，做什麼只有一句「個人覺察與照護支持」。 - **二微**：完全查不到，提案也沒解釋。 - **Care Ticket、Care Circle、Care Passport、Care Path、Care Capacity、Care Balance、Care Roaming、Care Station、Split Care**：各出現一兩次，靠上下文猜大概是「需求單、家人分工、資格履歷、轉軌路徑、量能、責任集中提示、跨縣市、社區站、拆時段」，但沒有一個有明確定義。 評審看一份提案，要靠猜的名詞越多，代表它越沒把「到底要做什麼」講清楚。這件的實質內容——臨時媒合、家人分工、缺口統計——三句話就能講完，卻用了十個牌子去包。 [10:32] 評審： 這會是AI產生的結果嗎？ [10:32] 助理： 一部分很可能是，但要分兩類： **Care-* 那一串很像 LLM 的產物。** 你叫語言模型「幫我把這個照護平台的架構整理出來」，它最常見的做法就是發明一組品牌化的功能名——Care Ticket、Care Circle、Care Passport——每個功能配一個名字，排成一個看起來完整的體系。這是模型「結構化」的習慣，不是人講話的方式。提案揭露用 ChatGPT 和 Gemini 做「方案比較、服務與資料架構整理、報名文字精簡」，架構整理這一步正是這種名詞會長出來的地方。 **WoHere、二微、BE HERE 不是。** 這些是公司本來就有的品牌，是創辦人自己的命名習慣——她本來就喜歡幫東西取名字。所以 AI 大概是在一個本來就愛取名的人手上，把這個習慣放大了十倍。 **但內容不像純 AI 寫的。** 「私人接棒不問費用」「不做孝順排名」「先找曾合作的人」——這些是有立場的設計決定，帶著對家庭照護現場的觀察（誰出力誰被說孝順、親戚幫忙不好談錢），LLM 不會主動做出這種選擇。文字也沒有 #3 那種 Markdown 漏出、欄位截斷的痕跡。 所以我的判斷是：**想法是人的，包裝是 AI 的。** 跟 #14 類似——AI 把一個人真的想過的東西，寫成了一份名詞比內容多的文件。差別是 #14 的作者用 AI 寫出了「不做什麼」的邊界，這件的作者用 AI 寫出了十個功能名。 [10:33] 評審： 家人照顧也被列入資源？這能夠分享嗎？ [10:34] 助理： 提案裡的「親友接棒」是家庭自己安排自己的親戚，不是把家人放進公共池給別人用。所以嚴格說它不是「分享」，是「登記」：你家的姑姑週三下午能來，記在 Care Circle 裡，讓其他家人看得到。這部分就是 CircleCare 那種家庭行事曆。 但您的問題點到一個更深的東西：**把家人照顧當「資源」放進量能模型，本身就有問題。** 1. **家人的照顧不可轉移。** 照服員的 4 小時對任何家庭都是 4 小時；女兒的 4 小時只對她媽媽有意義。把兩者用同一個「時間×地點×資格×能力」的單位表示，等於假裝它們是同一種東西。提案有把「短期親友」「持續性非正式照護」跟「專業」分開標記，表示它知道不一樣，但還是放進同一個模型裡算「量能」。 2. **被記錄的無償勞動，不會因此變少。** 提案說 Care Balance 只「提示責任是否長期集中」、「不做孝順排名」。但一個家庭裡誰扛最多，大家本來就知道，不需要儀表板告訴他們；儀表板做到的是把「媽媽扛了 80%」變成一筆資料，然後呢？提案的回答是「長期重複出現則提供正式資源或培訓轉介」——也就是資源不足時，把長期照顧的家人轉介去受訓成照服員。這是把無償勞動正規化，不是減輕。 3. **未來的 Care Roaming 就是跨家分享。** 提案在擴散性那欄提到「跨縣市 Care Roaming」「社區 Care Station」，方向是往「量能跨家庭流動」走。到那一步，家人就真的變成池子裡的資源了，而那時「不問費用」的設計就會變成無照有償照護的通道。 所以您的直覺是對的：家人照顧不能當資源分享。這件提案現階段沒有分享，但它的資料模型和擴散方向都是往那裡去的。 [10:57] 評審： 「長期重複出現則提供正式資源或培訓轉介」我照顧我媽三個月，已經工作家庭照顧三頭燒，睡眠不足了，然後還要引介我去上課？ [10:58] 助理： 對，這句話把它的世界觀露出來了。 一個照顧了三個月、三頭燒、睡不飽的人，系統偵測到「持續性非正式照護」，反應是「轉介正式資源**或培訓**」。前半句勉強可以（如果「正式資源」指的是喘息服務），後半句是把您當成潛在的照服員供給——您已經在做這件事了，只差沒有證照，來上課吧，上完就可以正式登錄、就變成量能。 這不是文字上的失誤，是模型的必然結果：**當你把照顧定義成「時間×地點×資格×能力×可用時數」，一個長期照顧媽媽的女兒，在模型裡看起來就是一個「有時數、有能力、缺資格」的節點**。補上資格，節點就完整了。系統看到的不是一個累壞的人，是一個待轉正的資源。 正確的答案早就有了：長照 2.0 有喘息服務——居家喘息、機構喘息、日照喘息，讓照顧者可以睡覺、可以上班、可以離開幾天。提案的資料欄還列了「苗栗縣喘息服務單位公開資料」，但設計裡喘息不是主線，「培訓轉介」才是。它知道喘息服務存在，卻沒把它當成那個時刻該給的東西。 這件事對評分的意義：它宣稱要解決「家庭承載」，但它的解法會加重承載。這是社會影響力的問題，不是可行性的問題。 [10:59] 評審： 「長期重複出現則提供正式資源或培訓轉介」我照顧我媽三個月，已經工作家庭照顧三頭燒，睡眠不足了，然後還要引介我去上課？答案是讓我不要再照顧了，還是要引介我去上課？我去上課家裏誰賺錢？誰付照顧費？ [10:59] 助理： 您這一段就是這個提案的癥結。 它的資料模型偵測到「責任長期集中在一個人身上」之後，能給的回應是「正式資源或培訓轉介」。**「正式資源」是對的方向，「培訓」暴露了它的思維**：它把已經三頭燒的家庭照顧者看成潛在人力，不是需要被替換下來的人。Care Passport 那一頁寫得更直白——「呈現資格、訓練、專業及**家庭照護經驗與轉軌入口**」，擴散性那欄還有「預備人才」。也就是說，您照顧媽媽三個月的經驗，在它的模型裡是一張可以轉成照服員資格的履歷。 而您問的三個問題，正確答案本來就存在，而且不需要任何平台： - **讓您不要再照顧了**：長照 2.0 的喘息服務，一年最多 21 天（重度 21 天，中度 14 天），照服員到府或送機構，政府給付。 - **家裡誰賺錢**：您繼續上班，白天由居家服務或日照中心接手，長照給付依失能等級每月一萬到三萬多的額度。 - **誰付照顧費**：政府付大部分，部分負擔 16%，低收入戶免。 進入這套系統的方式是打 1966，照管專員來評估。這件事的瓶頸從來不是「找不到人接棒」，是**家庭不知道自己可以申請、或申請了額度不夠、或偏鄉沒有服務單位可派**。前兩個是推廣和給付政策的問題，第三個是人力總量的問題。平台三個都碰不到。 所以它偵測到您快撐不住的時候，最有用的一句話是「去打 1966」。這句話不需要 Care Ticket，也不需要 WoHere。 [11:01] 評審： 「長期重複出現則提供正式資源或培訓轉介」我照顧我媽三個月，已經工作家庭照顧三頭燒，睡眠不足了，然後還要引介我去上課？答案是減少我的照顧工作，還是要引介我去上課？我去上課家裏誰賺錢？沒人賺錢誰付帳單？長照部份負擔不是錢嗎？長照2.0就足夠所有所需照顧服務嗎？這些多出來的費用，我去上課不賺錢，誰付？ [11:02] 助理： 您問的每一句，提案都答不出來，而且那一句「培訓轉介」正好暴露了它的世界觀：**它把照顧者當成待開發的人力，不是當成需要被替手的人。** 逐題講事實： **長照 2.0 夠不夠？不夠，而且是設計上就不打算夠。** - 它是「補助額度」制：依失能等級（CMS 2 到 8）每月給一個額度，大約從一萬出頭到三萬多元，用來買居家服務、日照、專業服務。額度用完就是全額自費。 - 部分負擔：一般戶 16%、中低收 5%、低收 0%。所以就算在額度內，一般家庭每個月還是要掏錢。 - 喘息服務另有年度額度，大約幾萬元，換算下來一年幾十天。 - 夜間、假日、臨時，幾乎不在給付範圍內，而且就算你願意自費，那些時段也常常根本找不到人——這是人力問題，不是錢的問題。 所以「照顧三個月、三頭燒、睡眠不足」的人，長照 2.0 給的是白天幾小時的替手加一點喘息，其餘是自己扛。 **您要的答案是什麼？減少照顧工作。** 具體是三件事：真的有人來接手的時數、付得起這些時數的錢、請假期間收入不中斷。這三件事分別是**供給、給付、勞動政策**，全都不是一個平台能給的。平台能做的最多是「在有人可接、你付得起的前提下，讓你少打幾通電話」。 **「培訓轉介」是反向的答案。** 對一個已經沒有時間的人說「去上課」，等於再從她身上拿走時間，而且上完課她變成有證照的照服員之後，最可能的結果是——繼續照顧自己的媽媽，只是現在「合格」了。這不是減負，是把無償勞動正名化。您問「我去上課家裡誰賺錢」，提案沒有想過這個問題，因為它沒有站在照顧者的位置想過。 這件提案的問題描述其實是準的——臨時空窗、責任集中、減班離職，都是真的。但它的解法是資訊系統，而這些問題的根是錢和人。這也是為什麼它「讓量能被看見」那句話這麼空：看見了，然後呢？ [11:04] 評審： 「培訓轉介」想的是，照顧者照顧多了以後，可以轉為正職照顧員，賺錢兼照顧，也解決照顧員人數不足的問題。很多長照照顧員，都是從照顧自己家人後，培訓轉職的。 [11:05] 助理： 您說得對，我前面講過頭了。這條路是真的存在的：很多照服員就是先照顧自家長輩，發現自己做得來、也需要收入，才去受訓轉職。從政策面看，它同時回應了照顧者的收入問題和照服員短缺，衛福部的照服員訓練也一直在吸納這群人。提案想的是這件事，方向不錯。 我該修正的是：這不是「反向的答案」，是「**順序不對的答案**」。 一個三頭燒、睡眠不足的人，需要的第一件事是替手；有人替手之後，她才有時間去想「要不要轉職」。轉職是中期選項，替手是當下需求。提案的句子是「長期重複出現則提供正式資源或培訓轉介」——把兩件事並列，沒有說先後，也沒有說替手從哪裡來。所以它不是想錯了，是只寫了後半段。 另外一個實務細節值得留意（我不完全確定，建議您查證）：長照給付對照服員服務自己同住親屬有限制，受訓後要「賺錢兼照顧自家人」，未必能走長照給付的錢。真正的路徑多半是「去照顧別人家、賺錢，自己家的請別人來」——這需要更多人力進來，而不是同一個人換身分。這一點提案也沒碰到。 [11:05] 評審： 「培訓轉介」想的是，照顧者照顧多了，甚至原本的正職難以為繼，可以轉為正職照顧員，賺錢兼照顧，也解決照顧員人數不足的問題。很多長照照顧員，都是從辭職照顧自己家人後，培訓轉職的。 [11:06] 助理： 這個讀法是對的，我剛才把它讀得太窄了。台灣的照服員確實很多是這條路來的：辭職照顧家人幾年，家人走了或送機構了，回不去原本的職場，去考照服員證照，用累積的照顧經驗換一份工作。對這些人來說，「培訓轉介」是一條真實的、有尊嚴的出路，提案把它設計成入口是有道理的。 我要修正的是「它是反向的答案」那句。它不是反向，它是**另一個時間點的答案**： - 對「已經辭職、正在全職照顧」的人，培訓轉職是往前走的路——收入回來、經驗變成資格、人力缺口也補了一個。這是提案想的情境，說得通。 - 對「還在上班、三頭燒、睡眠不足」的人，它不是解法，因為她的問題是現在缺替手，不是未來缺出路。 還有一個限制要提：據我所知，長照給付的居家服務規定照服員**不能服務自己三親等內的親屬**。所以「賺錢兼照顧」實際上是：白天去照顧別人的爸媽領薪水，晚上回來照顧自己的媽媽不領薪水。這對某些人是可行的安排，但不是「把照顧自己家人變成有薪工作」。 所以我把評語式的結論改成這樣：**培訓轉介是一條真實的出路，但它服務的是「已經離職」的照顧者；對「還沒離職、正在崩潰」的照顧者，提案沒有答案。** 而後者才是它自己問題描述裡「減班離職」要預防的那群人。 [11:07] 評審： 以這個理解，再來看這個專案整體。「培訓轉介」是提案核心的部份嗎？還是只是說不清楚的side project？提案核心的部份是什麼？ [11:07] 助理： 看它自己排的四頁原型就清楚了： 1. **Care Ticket**——填需求（缺 4 小時、若沒人接會影響工作還是休息） 2. **找下一棒／Care Circle**——人選清單、家人分工、拆時段 3. **Care Passport／Care Path**——資格、訓練、家庭照護經驗、「轉軌入口」 4. **Care Capacity Dashboard**——專業／親友／非正式／未承接的量能統計 **核心是第 1、2 頁：臨時媒合加家人分工。** 提案自己在創新性那欄講的核心也是「把正式長照、機構量能、家庭支持、未承接需求納入同一套量能模型」——一個資料模型，加一個找人的介面。 **培訓轉介是第 3 頁的一部分**，全文只出現一句「長期重複出現則提供正式資源或培訓轉介」，加上 Care Path 的「轉軌入口」四個字。它有一頁的位置，但沒有一段的說明——是設計了入口，沒設計路。所以說它是 side project 是準的：有想到，沒想清楚，也沒打算在黑客松期間做。 **第 4 頁是最有價值的想法**（缺口變政策資料），但它是副產品——要先有人用第 1、2 頁，才會有資料。 所以整體的形狀是：**一個臨時照護媒合的概念稿（核心），附家人分工（借自 CircleCare），附一個轉職入口（一句話），附一個缺口儀表板（好想法但依賴前面），附一個自家情緒產品（WoHere）。**評的時候，可行性和創新性看第 1、2 頁；社會影響力可以把第 4 頁算進去；第 3 頁和 WoHere 不用花時間。 [11:09] 評審： 呃，可是家人自己照顧，打個電話就好了，為什麼要填App？這是全家每個人和幫忙的親戚都裝App，大家都在上面填時間嗎？ [11:09] 助理： 對，這是它第 2 頁的死穴。 家人分工現在是怎麼做的？一個 LINE 群組。「週三我去」「週末換你」「姑姑說她下午可以」。這個機制免費、大家都會、阿姨也在裡面。要換成 App，得讓每個家人加上偶爾幫忙的親戚都裝、都登入、都把自己的時段填進去——而幫忙的親戚是最不會裝的那個人。CircleCare 在美國賣了好幾年還是小眾，原因就是這個。 而且它的資料模型完全依賴這些填寫：誰接了哪一棒、責任集不集中、未承接的缺口有多少，全都要有人一筆一筆輸入。沒人填，Care Balance 提示不了、儀表板是空的。 所以第 2 頁的家人分工實際上不會被用，連帶第 4 頁的政策資料只會收到「願意填 App 的家庭」——一個嚴重偏誤的樣本。 剝掉之後剩下什麼？**第 1 頁「缺 4 小時，找專業照服員」**——這一段不需要家人填時間，需要的是有照服員在池子裡。而那就是家天使。 它的問題描述抓到的東西——臨時空窗、責任集中——都是真的，但那些問題在家庭裡是用電話解決的；App 解決的是「找陌生人」的問題，而找陌生人的 App 已經有了。 [11:12] 評審： 這感覺上像是社工每天花大量的時間在填報，以提供督導審視和整體dashboard。社工是領薪水的職員，可以這樣要求。家人不行吧？ [11:13] 助理： 這個類比非常準，而且直接說明了它的資料模型是從哪裡來的。 看它要收的欄位：時間、地點、服務類型、資格、能力、可用時數、來源、狀態、未承接原因、「若無人接棒對工作、休息或家庭替手的影響」——這是一張**個案管理的填報表**。它的形狀跟照管專員、居服督導每天填的東西一樣，目的也一樣：往上彙整給督導和儀表板看。 填報是一種勞動。機構裡這個勞動有人付錢——社工的薪水裡包含填報時間，督導有權要求。家庭裡沒有人付這筆錢，也沒有人有權要求。一個睡眠不足的照顧者，為什麼要在找不到人的時候，先花五分鐘填「未承接原因」和「對工作的影響」，讓某個縣市的儀表板多一個點？她得到的回報是零。 這種資料能持續收到，只有兩條路： 1. **由領薪水的人填**——照管專員在評估時記下「這個家庭夜間無人、需求未滿足」。這其實已經在發生：照管中心的評估和照顧計畫裡本來就有「需求」和「已核定服務」，兩者的差就是缺口。政策資料的答案可能早就在衛福部的系統裡，只是沒人去算。 2. **當交易的副產品自動產生**——家天使每一筆預約自然留下時段、地區、有沒有成交。使用者不用「填報」，資料是做事的副作用。 這件提案兩條路都沒走：沒有領薪水的填報者，也沒有交易。它要的是家人無償填報，去產生給政府看的資料。這就是您說的——對社工可以，對家人不行。 [11:14] 評審： 現在的情況是，長照個管師會協助家人做大量填報工作，減輕家人填報負擔。 [11:15] 助理： 那就更清楚了：**這件提案裡唯一能填這些資料的人，是它設計裡沒有的角色。** 它的使用者有四種：家庭、機構、照服員、親友。沒有個管師。可是現實裡替家庭填報、知道這個家夜間沒人、知道媽媽快撐不住的人，就是個管師。她手上已經有需求評估、核定服務、家庭狀況——「缺口」就在她的紀錄裡。 如果這個提案想要的政策資料真的有價值，它該做的是給個管師一個「記錄未滿足需求」的欄位。但個管師已經有衛福部的照顧管理資訊系統，那就回到 #11 的問題：再多一套要她填的系統，還是去改她現在用的那套？ 所以這件走到最後跟 #20 一樣：它想要的資料，最合理的來源是既有的體制內人員和既有的系統；它設計的卻是一個要家人自己填的 App。 [11:16] 評審： 現在的情況是，長照個管師會一個月checkout一次，協助家人做大量長照2.0填報工作，減輕家人填報負擔。但在這個專案裏，填報負擔又回到了家人手上？ [11:16] 助理： 對，這正是它設計上的倒退。 現在的分工是：家人負責照顧，個管師負責文書——每月訪視、核定額度、調整照顧計畫、跟居服單位對接。這個分工的道理是，填報是專業勞動，讓領薪水的專業人員做。 這個提案把資料入口放在家人手上：開 Care Ticket 的是家人，標「對工作休息的影響」的是家人，記「誰接了哪一棒」的是家人，回報「為什麼沒人接」的還是家人。個管師在整份提案裡**一次都沒有出現**。 這是它最奇怪的地方：它要的「缺口資料」——哪個家庭、哪個時段、沒人接、影響到誰的工作——正是個管師每個月訪視時親眼看到、而且有職責記錄的東西。如果它把個管師當成資料入口，設計會變成「個管師訪視時多勾三個欄位，彙整成縣市缺口儀表板」，那是一個小而可行的改進。但它做成了一個消費者 App，等於繞過現有的專業體系，把工作丟回給最沒有餘裕的人。 原因大概是團隊沒有長照專業的人——不知道個管師的存在和角色，所以想像中的長照世界只有「家人」和「照服員」兩種人。這一點在它的輔導需求裡也看得出來：它勾了「長照人員認證登錄與跨機構支援流程」「家庭照顧者支持」等一整排要主辦單位教它的東西。 [11:21] 評審： 3/1/3/6/2「WoHere、Care Ticket、Care Circle、Care Passport、Care Path、Split Care、Care Balance、Care Roaming及二微等眾多名詞未解釋，意味不明。家人照顧是一通電話就可以解決的事，現在要安裝App填報。長照2.0讓A個管定期協助家庭處理填報文書工作負擔，這個提案要把填報工作負擔又轉移到照顧者身上，只為形成政策儀表板嗎？」這樣如何？ [11:21] 助理： 加權總分 **2.48**（0.90 ＋ 0.28 ＋ 0.90 ＋ 0.30 ＋ 0.10）。 評語三句都有依據：名詞是查證過的（WoHere 是自家產品，其餘無定義）、電話取代 App 是您的判斷、A 個管的填報分工是現行制度事實。最後一個問句是全案最該被問的問題。 多元性 6 是目前最高——七人跨兩家公司加大學生高中生，就團隊組成看合理，雖然沒有長照專業。 === 事後／並提討論 === e36e3881 2026-09-06 [11:25] 助理： 六個來源都開了。這件跟前面幾件不一樣，先講結論：**這是目前看過最完整、最懂制度的一份提案，但團隊裡沒有列出任何工程師。** **它是什麼**：一個農業補助的「前端導引層」，不取代公所和農會的正式申請。四個功能： 1. 農民用一句話或台語語音說「我的芒果全掉了」，系統反向比對符合的救助方案、要什麼文件、承辦科室直撥電話、期限倒數。 2. 收到公文拍照 → 翻成白話待辦清單：缺什麼、去哪補、幾號前、不補會怎樣。 3. **災前資格健檢**：口頭租約的實耕者（約 4 萬公頃）災後十天內生不出土地證明，系統平時引導他們去做綠色環境給付的政策登錄，取得「免附土地文件」的法定豁免。 4. 匿名卡點統計加一個「這個我辦不下去」按鈕，讓機關第一次看到沉默放棄者，產出鄉鎮級卡點分布與公文難懂用語熱點圖。 架構：硬性資格用規則引擎（不讓 LLM 判資格）、口語理解和公文白話化才用 LLM，每筆輸出可回溯法條原文；國網中心 TWCC 推論，公文影像不出境、處理後即刪；schema 開源、API 給農會公所串接；**協辦模式**——農會推廣員、公所農業課、里幹事代農民操作，解決冷啟動。已經做的資料整理：150 筆歷次災害公告、20 部法規逐條結構化、30 份去識別公文樣本、109 年普查全文解析。 **查證** - **農業部獎補救助專區**：關鍵字與分類篩選、訂閱通知。沒有「描述處境反查資格」，沒有公文白話化。 - **GetGrant**：民間平台，3,020 筆補助，可依身分（含農民）篩選，每筆有摘要／資格／文件／步驟／聯絡，有一份 30 分鐘自評檢查表。是最接近的既有服務，但純文字、通用、無語音無公文。提案自己引用它當資料查核規範的參考。 - **USDA 災助工具**：五步問答找方案。**印度 Kisan e-Mitra**：政府 AI 聊天機器人，11 種語言，處理過數百萬次查詢。「反向比對」這個概念國外有國家級的實作。 - **農科院那篇**：講的是農業部病蟲害 AI 平台，跟補助無關，AI 評估引錯了。 - **2020 防疫黑客松**：行政院頁面證實五個獲獎團隊裡有「跨領域研究室」（提案隊名是「跨領域實驗室」），沒列成員。他們說反向比對模式源自那個作品，可信。 所以「處境反查補助」的概念既有（GetGrant、USDA、印度），**「公文拍照白話化」「災前健檢取得法定豁免」「放棄按鈕」**是它自己的。 **跟您前面幾個原則的對照** - AI 必要性：資格判定用規則、LLM 只做語言和 OCR——這正是您說的「規則能解的用規則」。 - 誰來填報：它的政策資料是使用的副產品，而且主要使用者是**領薪水的協辦者**（推廣員、公所、里幹事）——正好是 #31 缺的那個設計。 - 第 N+1 平台：它定位是官方管道的前端，農民釐清資格後導回公所，不另建申辦系統。 **問題** 1. **沒有工程師。** 六人是資深社工、里幹事、協會創辦人、立委助理、協會秘書長、國發所博士——一個政策團隊。技術清單卻是微調台語 Whisper、微調公文 OCR、RAG、規則引擎、PWA，兩個月內完成。分工欄空白。這是全案最大的風險。 2. **場域未定**：「一地區農會與一鄉鎮公所」沒有名字；那位里幹事在萬華，不是農業區。 3. **期程三個月加決審前**，超出賽期。 4. **錯誤的代價**：推薦準確率目標 85%，代表 15% 的農民會拿到錯的方案或錯的期限；公文補正期限讀錯就是失權。它有設「信心不足即標示需向承辦確認並附電話」，這是對的緩解，但責任歸屬沒寫。 5. 小鄉鎮的卡點統計容易再識別；協辦模式下公所人員代操作會留下摘要。 6. 沒回應許願池。文字是 Claude 潤的（有揭露且附查證聲明），但內容密度高，不空。 AI 評估：`substantive_junk = false`，`similar_existing = true`（概念層次）。 e36e3881 2026-09-06 [12:14] 助理： #34 也是同一份。跟 #32 的差別只有問題描述那一欄少了一句「為此，『農民補給站』精準打擊四大痛點：」和幾個空行——是同一份的早一點版本。所以 #32、#33、#34 是三次送件，#32 最完整。 #35 是別的團隊（科技小農，青蔥第二產區），不是重複。 順帶一提，#36「WoHere 全民心理韌性第一哩」是 #31 同一位提案人（陳彥如）的另一件，主角就是 #31 裡搭售的那個 WoHere。您問過 WoHere 是什麼，答案應該在那一件裡。 e36e3881 2026-09-06 [12:17] 助理： 六個來源開了五個（苗改場 PDF 讀不出來，但另一頁已經夠用）。這件的性質跟前面都不同： **它是什麼**：一家社會企業（協豐稼）加科技小農團隊，十人，含農試所植物病理博士、農科院博士、農糧署北區分署科員、彰化農產行銷協會總幹事、兩位農戶子弟。要做的事是**種蔥**：用農試所的青蔥健康種苗技術，在草莓產區夏秋季閒置的農地輪作青蔥，補夏季蔥荒（彰化受災就缺蔥）；彰化花壇是種苗基地、苗栗大湖 0.6 公頃前導已完成、這次以南投草屯 2.3 公頃為「治理驗證場域」，加上批次管理、田區建檔、生產履歷、食安源頭、病害風險分析、跨產區供應調節。工具是田邊好幫手、災害現地照相 App、雲端表單、ChatGPT 看病害照片。回應三條許願池，其中一條就是「夏秋季青蔥的產銷調節」。 **查證** - 第五題它誠實勾了「**否，已在進行中之計畫**」並說明。查證結果：聯發科「智在家鄉」2026/05/13 公告，科技小農是影響力加速計畫三隊之一，項目是「青蔥中心－衛星農場小農加盟模式擴大至中南部三縣市」；**2026 年 8 月桃園社企競賽暨尤努斯獎，「協豐稼社會企業（蔥破難關）」得亞軍加社企認證特別獎**——跟這份提案同名。這是一個已經有資金、有場域、剛得獎的社企事業計畫。 - 農試所青蔥健康種苗（2021 年報導）：病毒篩檢、無病株繁殖，宣稱增產 20%。技術是農試所的，已存在。 - 草莓園夏季輪作蔬果：農業部知識網 2013 年的文章就把「夏季蔬果輪作」列為草莓休耕期七種管理方式之一。**輪作不是新做法**。 - 上下游報導證實市場邏輯：夏季蔥少價高（可到三四百元一公斤）、冬季崩盤——「種蔥就是賭夏天大賺」。 **需要您判斷的** 1. **這是一個農業事業，不是一個黑客松原型。** 期程從 8 月 1 日整地開始（初審還沒評完），到 11 月 5 日收成整理——那是青蔥的生長週期，不是開發計畫。決審會看到的是一塊田的產量、履歷和 SOP。它自己說「不以另建大型資訊平台為目標」，這在您的原則裡是加分，但它跟「公共資料應用」的距離也是最遠的：開放資料只當參考，AI 只是 ChatGPT 看照片，卻申請了數位產業署的算力平台來「整理分析田間資料」。 2. **「非原計畫之內容」站不站得住。** 它說新增的是治理機制——履歷、建檔、食安、供應調節。但這些是任何農業經營本來就要做的產銷履歷工作，題目又跟尤努斯獎的得獎名稱一模一樣。 3. **供應韌性是誇大的。** 2.3 公頃對全國夏季青蔥供應沒有可測量的影響；它的價值在「示範一個模式給農政單位參考」，不在「解決蔥荒」。而且草屯不是草莓區，「閒置草莓地」的前提在核心場域不成立——那只是他們新租的田。 4. **公私界線**：農試所研究員、農糧署科員列為一家社企參賽隊的成員，而這家社企同時是種苗供應者（中心－衛星加盟）。這不是程序問題，是「公私協力」在這件裡實際長什麼樣的問題。 5. 返鄉家庭照顧者「彈性務農」——跟 #31 討論過的一樣，照顧加農務可能是雙重負擔，沒有工資與保險安排。 6. 資料治理：農戶田區、產量、銷售流向上 ChatGPT；資料所有權沒有約定。風險低但沒處理。 **好的一面**：全部是真的——真場域、真團隊、真專家、真市場邏輯、揭露誠實、日期具體、不做多餘的平台。以「做得出來」論，它是 179 件裡最確定會有成果的一件。 AI 評估：`suspected_existing = true`（查證屬實），`similar_existing = true`。 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] 助理： 可以，但要分清楚用哪一個理由，因為兩個理由的強度不同： **理由一：它是團隊自己的既有產品。** 這是最強的。WoHere 有產品頁、有 SBIR 申請中（自述）、#31 就已經把它當現成品搭售。提案自己勾了「已申請政府預算」。它主張黑客松的部分是新的「資源導航層」，但那一層是 4 頁 mockup 加一份摘要格式。這跟您給 #35 的判斷是同一類——「已在進行中之計畫，不符黑客松方向」，處理方式一致就好：創新性 0 或接近 0，評語寫明。 **理由二：市面上有現成的同類服務。** FarHugs 的 HugBee 加免費資源目錄是查證過的、流程幾乎相同；Wysa 是國際標準。這個理由可以壓創新性，但依您自己的原則（#10、#19），「有人做過」不等於零分，除非做的是同一件事——這件跟 FarHugs 的重疊度確實很高，所以用它壓到很低也站得住。 **我會建議評語以理由一為主，理由二為輔**：「WoHere 為團隊既有產品且已申請 SBIR，本案僅增加資源導航層；同類服務（如遠距抱抱 HugBee 加公費資源目錄）已存在。」兩句都有查證。 一個提醒：初審沒有「拒絕」這個動作，只有分數。分數低它自然不會進，理由寫在評語裡讓評審會議看得到就夠了。 e36e3881 2026-09-06 [16:09] 助理： 提案寫的是給**修剪廠商的第一線人員**——「透過 APP 引導第一線人員精準修樹」「導入實際修剪維運廠商於日常維護作業中運用」。不是給民眾，不是給巡檢，不是給監工。 但它設計的功能對這個使用者不成立：第一線人員在吊籃裡拿鏈鋸，用不了手機 AR。而它列的效益——「施工品質可追溯、減少不當修剪」——是監工和主管機關的需求，不是工人的。 所以它的使用者寫的是 A（工人），功能只有 B（監工、巡檢）用得上，成效指標卻是 C（民眾 1999 通報）。三個角色在提案裡沒有被區分過。這跟 #31 的問題是同一種：沒有把「誰、在什麼時候、拿著什麼、做什麼」想過一遍。 e36e3881 2026-09-08 [00:27] 助理： 沒有動機。這跟 #31 讓家人裝 App 填時間是同一個問題。 飼主買飼料的行為是：買一包、開一包、吃完再買。要「主動服務」成立，他得在每次買回來時掃一次或打一次品名、批次、效期，而且要持續做。他得到的回報是「萬一這包上了不合格公告，會收到通知」——這種公告一年幾件、涉及的品牌多半是小廠，多數飼主一輩子不會遇到。為了一個極低機率的事件，每買一包就登錄一次，沒有人會做。 現實的行為是反過來的：新聞爆出某牌飼料出事，飼主才去查自己那包有沒有中。那是「有問題才搜尋」，申報網和 Pet Health Map 已經能做，不需要事先登錄。 提案唯一能讓「登錄」自然發生的路，是跟購買綁在一起——電商或寵物店的訂單紀錄自動變成清單，飼主不用做事。但它沒有任何通路夥伴，是一個人做的 PWA。所以它的核心功能「安心吃」在使用者行為上不成立，剩下的兩塊（找醫、通報整理）是既有資訊的整理。 c71e996e 2026-09-08 [09:26] 助理： 106 筆疑義裏,**只有 32 筆(16 個單位)會實際改變「哪幾案併為同 team」**;其餘 74 筆都只出現在單一提案,怎麼判都不影響分組,不必問你。以下是真正需要你裁決的,我依影響歸成 8 題(附上會受影響的提案 #),請逐題回答: **政策題(一次決定、涵蓋多組)** 1. **同一所高中的成員,算同一組人嗎?** 影響:潮州高中 #106/#230;竹南高中 #31/#36;道明中學 #13/#15。 2. **政府「署/局/司」層級太大,一律不連?** 影響:環境部資源循環署 #131/#207/#216;環境部環境資訊科技司 #94/#156;高雄市政府農業局 #196/#209(「農業處」與「農業局」是同一單位的兩種寫法)。 3. **大型政府研究機構:** - **林業試驗所**要不要比照農試所排除?目前會把 #38/#119/#128/#234 連成 4 案同 team。 - **農科院**(財團法人農業科技研究院,#35/#72/#234)目前已排除,維持? **個案題** 4. **TAITA**(「TAITA秘書長」,#88/#89/#90/#92 共 4 案)— 這是什麼組織?若是小協會就算同 team。你認得 TAITA 嗎? 5. **#32/#33/#34** 同時共用「萬華區公所糖廍里里幹事」與「北醫大數據所」兩個訊號 → 判同一組人?(兩條線都指向同三案,幾乎確定。) 6. **屏科大「農園生產研究所」與「農園生產系」**合併為同一單位、且算同 team?(#205/#209/#236) 7. **陽明交大「電機學院/電機所/電機系」**合併為同一單位?電機系規模很大,算不算同 team?(#190/#203) 8. **小公司:**冠諭科技(#84/#91)、達豐儀器(#31/#36,且與竹南高中同時共用)→ 算同 team? 回答完我就定稿對照表,接著建 `Team` 表 + `Proposal.team_id`、把三層關聯(強關聯/同名待查證/同單位)算進去做清單標記。 c71e996e 2026-09-08 [09:50] 助理： 收到,裁決整理: - 高中 → 同 team(潮州 #106/#230、竹南 #31/#36、道明 #13/#15) - 政府 署/局/司 → 一律不算 - 林試所、農科院 → 算;而且兩者共用 #234,會自然併成一個 team(#35/#38/#72/#119/#128/#234) - 屏科大農園、陽明交大電機 → 不算同 team - TAITA秘書長 → 同一個人,同 team(#88/#89/#90/#92) 你沒答到的兩題,我依你已定的規則處理並說明:#5(#32/#33/#34)與 #8(小公司)。先查一下 #32/33/34 與 TAITA 是否根本就是「同一個成員姓名」跨案——若是,那是強關聯(同人),不必靠單位。 c71e996e 2026-09-08 [10:01] 助理： 已檢查通過,交給你 review: - create_app 匯入無誤、**94 測試綠**(新增 15)、pycodestyle 乾淨、JS 語法 OK。 - 用真實資料在記憶體 DB 跑 `import-proposals` → `compute-teams`:**24 個 team、涵蓋 73 案**(2 案 ×17、3 案 ×2、5 案 ×1、6 案 ×2、8 案 ×2),其中 **5 個標「待查證」**。 預期全部命中: - 徐朝峰那組 → team 12,共 **8 案**(#84/85/86/88/89/90/91/92,#85/#86 也是同人同電話併入)。 - #32/33/34、#31/36、道明 #13/15(basis=unit)皆正確。 - 林試所+農科院 → team 7,**8 案**(#35/38/72/119/128/234 再加 #101/#214 經「同名成員」併入)→ 因含純同名連結而標**待查證**,正是設計要抓的情況。 - 屏科大 #205/#209 併在一起是因為**同聯絡人林桐榮、同 email**(非系所);#236 獨立。 「待查證」的 5 組(team 7/8/16/18/20)都是靠同名成員、但 email/電話不同,請你人工看。 改動:`models.py`(`Team` + `Proposal.team_id`)、`commands.py`(`compute-teams`)、`views.py`、兩個 template、`proposal_list.js`、兩個測試檔,及新增 `data/org_units.json`。**未 commit**。 你說 commit 我就提交;之後正式 DB 要加 `teams` 表與 `team_id` 欄、跑 `compute-teams`(不碰分數),再告訴我。 e36e3881 2026-09-08 [10:29] 助理： 四個來源開了兩個，夠用。這件跟 #60（水保署「不漏一戶」）是同一個題目，先講輪廓再對照。 **它是什麼**：一人提案（元智終身學習中心學生）。志工平時送餐量血壓時花半分鐘更新長輩的電話、狀況、找路提示；警報來時系統依氣象署警報影響區、農業部潛勢圖、行動能力、醫療需求、最後確認日排出「這次要優先確認誰」，並顯示排序理由；**先用電話語音確認「平安請按 1，需要幫忙請按 2」**；按 2 或沒接的才交志工；志工的 PWA 支援出發前下載、山區斷網查閱與回報、回網同步。AI 只做一件事：把官方警報改寫成白話通知稿，人工審核後轉語音。POC 全用 30–60 筆虛構名冊，不碰真實個資，沒有場域。三個月。回應許願池兩條。 **查證** - **AlertBlast**（美國）：排程自動電話、按 1 確認平安、未回應通知管理者、可派緊急服務，客戶含地方政府。 - **Enrich**（日本）：LINE 安否確認，按 OK、23 小時後通知未確認者，我孫子市、中野區等採用，2 萬多使用者。 「自動打電話按 1 平安」是成熟的商品類型。#77 把它接上災害警報和離線志工任務，這是組合。 **跟 #60 對照**，兩件解同一個問題，切法不同： | | #60 水保署 | #77 一人 | |---|---|---| | 第一步 | 派志工到府 | 先打語音電話，沒回應才派人 | | 志工 | 防災專員加慈濟紅十字備援 | 平時就在送餐的志工 | | 名冊 | 保全戶名冊、區公所弱勢資料 | 志工平時微回報維護 | | 斷網 | 提到「含離線模式」 | 具體設計：預下載、IndexedDB、回網同步 | | 場域 | 甲仙區公所確定合作 | 沒有 | | 團隊 | 十人跨部會 | 一人 | | AI | 「智慧派工」（加權排序） | 只改寫警報成白話，明說不決定順位 | #77 的設計在兩處比 #60 好：**先打電話再派人**（正好回應您對 #60 的批評——不用讓志工進警戒區，電話就能先篩掉大部分人）；**名冊由平時服務的人順手維護**（解決紙本 Excel 過期的問題，成本是志工每次半分鐘）。而且它的排序理由是可解釋規則、AI 不碰個資、離線設計具體、文字誠實不誇（「不先宣稱一定能提升多少效率」）。 **問題**：一人、無場域、無志工來源——它自己也說「尚無確定合作場域」；語音「按 1 按 2」對重聽、失智、只會台語的長輩不通，這是它第一步的盲區；志工手機裡存行動能力與醫療需求，手機丟了就是外洩，它有「任務到期清除」但沒說怎麼驗證；平時微回報是否真的會被填，跟 #31 是同一個「誰來填」的問題，只是這裡填的人是領薪或固定服務的志工，比家人合理。 AI 評估：`substantive_junk = false`，`similar_existing = true`（查證屬實）。 e36e3881 2026-09-08 [15:23] 助理： 兩個要分開看。 **事件卡**不太像。它是從一個真實的工作流程長出來的——「產地先講、再查市場、再回產地確認」，這是農會或市場人員每天在做的事，提案寫的例子（豪雨後產地說缺貨、南北價量分化）是有現場感的。而且它接在 #16 已經有的「市場觀測卡」旁邊，是同一個設計語言的延伸。這比較像團隊聽了工作坊或審閱意見之後補的東西。 **Decision Profile** 很像。「同一個核心、依角色套不同 profile、農政／零售／餐飲三個角色各一句」——這是 LLM 被問「這個系統怎麼擴散」時最標準的回答形狀：命名一個英文概念、列三個角色、每個角色一句話、結尾「最後仍由人決定」。而且它只出現在擴散性和創新性兩欄，沒有任何一個門檻或規則的具體內容，跟 #31 那串 Care-* 是同一類。 所以我的判斷是：事件卡是人補的，角色化是 AI 幫忙把「擴散性」那欄填滿的。這也符合這隊的寫法——#16 的文字就是「內容具體、免責語氣是 AI 味」，改版一樣。 e36e3881 2026-09-08 [17:44] 助理： 「卡」在這裡就是介面設計常用的「卡片」：一個獨立的小方塊，把一件事的相關資訊集中在一起顯示，可以列出來、點開、留紀錄。不是實體卡片，也不是什麼特別的技術，就是網頁上的一個資訊區塊。 它為什麼選這個形式，提案沒說，但從內容推得出來：它要的不是一個「分數」或「燈號」，而是一組要一起看的東西——來源、涉及市場、資料完整度、可信程度、不能下的結論、下一步查什麼。這種「一件事配六個欄位」的東西，做成卡片最自然，一張卡就是一個可以留檔、可以翻回去看的查核紀錄。#14 的「案例卡」、#31 的 Care Ticket、#77 的「志工任務卡」，都是同一種用法——卡就是「一筆有結構的紀錄」的口語說法。 所以「事件卡」和「觀測卡」翻成白話是：「一則消息的查核紀錄」和「一次數據異常的說明紀錄」。 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:58] 助理： 您說得對，我剛才把它推給決審是錯的——決審只能篩掉已經進去的，擠掉的那一件在初審就沒了，決審救不回來。 所以判斷要在初審做，而且不能靠「這隊看起來知道自己在做什麼」這種整體印象，要一項一項問：**這個名詞背後有沒有一個具體到能被檢驗的東西？** - 觀測卡：六個欄位寫出來了、每個欄位對應一條資料處理規則——有。 - 事件卡：只有一句話，沒有欄位、沒有例子、沒有跟觀測卡的關係——沒有。 - Decision Profile：三個角色各一句，一個門檻都沒有——沒有。 有的算分，沒有的不算分。這樣 #211 比 #16 多出來的三樣東西，只有「問題框架講清楚了誰在什麼時候用」算得上進步，其他兩樣是零。這跟您在 #31 對那十個 Care-* 名詞的處理是一樣的——名詞未定義就當空白。 這個原則對所有用 LLM 寫的提案都適用：**每個聽起來像功能的名詞，都要問它有沒有被定義到能做出來的程度**。沒有的，就是模型幫忙填的空格。 e36e3881 2026-09-08 [21:38] 助理： 您說得對，我是猜的。我把「卡」讀成 UI 卡片，是因為 #14、#31、#77 那幾件的用法看起來像介面元件，就把這個讀法套到 #16/#211 上。但提案本身從來沒說「卡」是什麼——沒有畫面、沒有說誰產生、誰收到、能不能傳給別人、傳了之後怎麼處理。您問的四 e36e3881 2026-09-08 [23:59] 助理： 輪廓，同一隊（土雞瓦犬，七人同名單）的第二件，但落差很大： **它是什麼**：一個「農業保險需求回饋平台」——農民上網反映「我需要但沒有對應保單的風險」和「現有保單的保費、理賠問題」，系統依作物、地區、需求類型匿名統計成需求熱點，給農金署當保單調整參考；再加一個「需求提出→處理→回應」的追蹤機制。四階段期程無日期。用農業天然災害損失公開資料當風險分析背景。AI 只在提案階段整理資料。旗標乾淨，揭露誠實。不回應許願池。 **跟 #179 的差距**：#179 是「用鏡像貿易資料算出洗產地訊號」——一個技術核心加國際方法加已完成的概念驗證；#180 是「做一個表單收集農民意見」——一個問卷平台加一個統計儀表板。#179 有「做過的痕跡」（8 條序列、帳差算出來了），#180 沒有任何分析核心，它的「已使用資料」只是災損損失表，跟平台功能沒直接關係。同一隊，一件是硬功夫，一件是軟平台。 **查證**：農金署已經定期邀農民檢討保單（有專頁）；美國 RMA 有 508(h)民間新保單提案機制。所以「收集農民對保單的意見」官方有既有管道，這件是把它數位化加追蹤。 **核心問題**： 1. **它是一個許願箱，而許願箱的價值全在有沒有人回覆。** 農民上去填「我想要文旦颱風險保單」，然後呢？農金署沒有承諾要看、要回。提案自己把「回應追蹤機制」當賣點，但追蹤的前提是機關會回應，而它手上沒有任何機關承諾。這跟 #86 的熱傷害推播、#31 的照護登錄是同一個結構問題：平台把工作轉出去，但接收端不存在。 2. **自願填報的樣本偏誤**：會上網填保單需求的是活躍的、規模較大的、數位能力好的農民。真正保障不足的小農、老農不會填。統計出來的「需求熱點」是「會填表的人的需求」，不是實際需求。這對一個要當「政策依據」的工具是硬傷。 3. **作物乘鄉鎮的小樣本可再識別**：某鄉某作物只有幾戶，匿名統計也認得出是誰。 **這件在總統盃的位置**：它是「智慧治理」裡的意見收集工具，方向沒錯（農保需求確實有資訊落差），但它做的是最容易的那一半（收集），迴避了難的那一半（怎麼讓機關真的採用、怎麼避免樣本偏誤）。相比 #179 補的是「沒人做過的境外情報」，這件補的是「已經有管道、只是沒數位化」的東西。 **好的一面**：技術選型務實（Next.js、PostgreSQL，一個學生團隊做得出來）、隱私有想到去識別、AI 揭露誠實、不堆名詞。它是一個做得出來、但價值取決於機關買不買單的小平台。 AI 評估：`substantive_junk = false`，`similar_existing = true`（查證屬實）。 e36e3881 2026-09-09 [09:27] 助理： 加權總分 **6.28**。 評語兩句都抓在要害:GPS 護照的勞動監控性質、以及「叫工人休息但工人不能決定休不休」——後面這句尤其準,它戳破了平台的根本無力處。移動戶外工作者(清潔、巡檢、外送、農務)多半是按件、按時、受案主排程,平台推播「該休息了」,但停不停不是他能決定的。這跟 #86 熱傷害推播、#31 照護登錄是同一個結構問題:資訊到位,行為受制於別人。 分數我沒有意見,跟這件「團隊對口、方法扎實、但監控與無力兩個真問題」的定位相稱。多元性 6 反映八人跨公部門、學界、產業的組成,合理。 順帶一提,它跟 #71、#86 在同一個熱調適群,之後平衡分數時可以三件一起看——這件是三件裡最高的,對應它團隊最對口。 e36e3881 2026-09-12 [00:38] 助理： 訊息核對一致。主題14 長照量能媒合,3 件**全部已評分**(#3、#31、#230)。#3 我記憶檔裏有(創新 7 / 可行性 1、產權結構性阻礙)。派 subagent 撈這三件的 session log 討論,同時我先 GET 三件的原文+分數(讀順序:原文→討論→分數)。 e36e3881 2026-09-12 [00:44] 助理： 四個維度的定義記好了(特別是社會影響力:假設 100% 實現、與可行性脫鉤、弱勢/社會議題加分而非以整體量計、負面影響扣分;多元性維持心證)。以後我不再把可行性摻進社會影響力。 topic 14 的 log 回顧(#3/#31/#230)我已備妥,等你叫到主題14 再用。要繼續就給編號/主題。 e36e3881 2026-09-12 [00:53] 助理： 訊息核對一致。主題14 長照量能媒合,3 件**全部已評分**(#3、#31、#230)。派 subagent 撈 session log 的討論。 e36e3881 2026-09-12 [00:54] 助理： 主題14 三件全評分。已派 subagent 撈 #3、#31、#230 的討論。回來我再 GET 三件的原文和分數,讀懂當時的評分邏輯(不倒細節給你)。 e36e3881 2026-09-12 [01:00] 助理： 三件讀完(原文 + 討論 + 現值),當時的評分邏輯我掌握了。現值: - **#3** 農養共生:**1/1/3/0/4 = 1.68**(長者 relocate 違反在地老化、產權是關鍵、日本 CCRC 問題)——**比 log 裏早期那版(曾 4.88)低很多**,你後來大幅下修了,我以現值為準。 - **#31** Care Relay:**3/1/3/6/2 = 2.48**(名詞未解、家人照顧一通電話、把填報負擔推給照顧者)。 - **#230** 病床動態調度:**0/5/3/2/1 = 2.45**(年度統計得不到即時病床數,可行性 0 否決)。 主題14 三件全評分。要做給分平衡回顧,你說一聲。 e36e3881 2026-09-12 [01:02] 助理： 主題14 排序:#31(2.48) > #230(2.45) > #3(1.68)。三件原文都讀過、都在脈絡裏,不重抓。 **結論:平衡成立,不需要調整。** 整個主題偏弱(三件都有重大問題)。 我用你剛釐清的定義逐維核過,幾個關鍵點: - **社會影響力(用「100% 實現後的影響、含隱性負面」這個定義):** #230=5——若實現,即時病床+長照媒合是**真正有益**的;#3=1、#31=1——若實現是**方向錯/淨負面**:#3 讓長者 relocate **違反在地老化**(把長者移出社區,對長者有害),#31 把**填報負擔推回崩潰中的照顧者**(加重它宣稱要解的問題)。有益 vs 有害的落差(5 vs 1),正是這個定義該有的結果。 - **可行性(方法能否達成目的):** #230=0——即時病床資料**根本不存在**(只有年度統計),核心達不到,否決;#3=1——產權/在地老化擋住;#31=3——平台做得出來但**創造不了供給**(偏鄉缺的是人不是能見度)。0<1<3 反映障礙嚴重度。 - **創新:** 三件都 3(既有政策/媒合的整合,無技術新意;#31 的「缺口→政策資料」是唯一較新但小)——一致。 - 資料治理(#230=1 資料本身不存在+臨床 PII、#31=2、#3=4)、多元(你暫不規格化,#31=6 跨公司、#230=2 同校、#3=0 一人)方向都對。 一個因近似而值得你知道的事實(不主張改):#31(2.48) 和 #230(2.45) 加權幾乎並列,但 **#230 帶著可行性 0 的重大瑕疵旗標、#31 沒有**——若排序到邊界,這個旗標是差異。其餘不動。 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-13 [16:49] 助理： 第一輪十組全部收齊。我先剔除你這兩天已經明確裁定過的（#122／#186 可行性、#190 與 #204 的 10、#212、#97、#101／#226 可行性、#83、#158、#35 治理 8 等），剩下的整理如下。每項都是子代理讀原文後指出的事實，不是 AI 評估的意見。 ## 創新性（0／1／在地化的分界） | 對照 | 分數 | 原文事實 | |---|---|---| | #237 農災 AI 判讀 vs #104 田野之眼 | 創 8／可 8／影 8 vs 創 3／可 0／影 0 | 同一題（AI 初判農損、公所流程、三級燈號）。你給 #104 的理由「AI 憑照片無法判斷災損」對 #237 同樣成立；你對 #237 的評語也說 Sentinel-2 穿不透雲、10 m 分不出農損。#237 資料欄空白、創新欄是工具欄複製。 | | #179 產地汪汪隊 9 | vs #214／#113／#165／#67 各 1 | #179 原文自述「IMF 鏡像資料手冊、美國 CBP、歐盟 OLAF 同路徑，台灣缺本土化對應工具」——是在地重製，9/12 的規則是 1。你在 9/12 說過「#190 世界首創 10 > #179 在地化 9」，跟同日定的「別人做好了＝1」互相衝突。 | | #226 PEBPS 臺灣化 8 | vs #41 0、#91／#20 1 | 引用欄自承「引用 PEBPS 名稱、架構、原始五因子公式，不宣稱原創」，題目就是「臺灣化」。 | | #177 AI Agent 詐騙 8 | vs #159 5、#66 3 | 你的評語「建議和新北反詐養蜂人合作」；原文自引 Chatterbox、Apate 為前例。 | | #74 永續電廠 8 | vs #55 0（同實驗室） | 原文「本提案為團隊既有永續電廠研究之延伸」「沿用既有研究，以大林電廠為案例」，交付是 Streamlit 儀表板。#73 你今天已確認 8；#74 沒談過。 | | #197 掌上明豬 1 | vs #154 0 | 原文「自行研發軟硬體及 APP，114/9–115/2 每 10 分鐘一筆、11,200 筆」——自家系統已運轉半年，是 0 那一格。 | | #14 AI 衛教紅旗 4 | vs #114 0 | 你的評語首句「是現有研究成果」，跟 #114「屬既有成果」措辭相同，一個 4 一個 0。 | | #34 農民補給站 8 | | 原文自述核心「反向比對」模式「源自團隊 2020 年防疫黑客松獲獎作品」。是不是「得獎模式換題重投」由你認定。 | | #201 治蚊 7 vs #84 灌溉巡檢 1 | | 同架構（無人機→AI 辨識→GIS→派工）；#201 自引台南 114/8 已有無人機登革熱巡查，本次加 AI；#84 也是既有巡查加 AI。 | | #19 外送新生態 7 vs #167 審時農曆 2 | | 兩案評語都由你點名前例（CoopCycle／台大黏蟲紙與農試所系統），都是前例上加東西。 | | #106 運用 AI 防詐 5 vs #119 農本生意 2 | | #106 你自己註「只有要做 UI，沒有系統」「深偽辨識無依據」；#119 才是被引前例扣的那個。 | | #182 一鍵巡田 0 | vs #158 3 | #182 因「原型已完成」給 0；#158 原文「前期已完成技術可行性驗證、57 項自動化測試通過」同樣提案前做好，未以此扣。 | | #204 神農計劃 10 | | 新事實：原文自己寫「MIT 曾以微型溫室研究，2020 年硬體不穩關閉」，引用 Wright 2023 開源生長箱——這個問題有人做過。你給 10 時是以「值得鼓勵的實驗」為由。 | ## 可行性（決審前能否驗證） | 對照 | 分數 | 原文事實 | |---|---|---| | #60 防災弱勢戶 vs #77 安心回線 | 可 3／影 5 vs 可 7／影 8 | 同題。#60 十人、甲仙區公所確定場域、慈濟紅十字確定志工、真實名冊；#77 一人、無場域、虛構名冊。#60 被扣「志工不應進警戒區」，#77 原文同樣派志工進山區沒被扣。 | | #205 檳榔轉作 8 vs #224 媽祖 4 | | #205 期程 115/12 容許→116/12 營運，決審前無物可驗；跟 #224「決審前無法驗證」同型。 | | #11 FireMind 9 vs #85 施肥用藥 2 | | 同型：一人、LLM/RAG 疊開放資料、無場域、評語都是「已有現成系統」。 | | #162 滑軌充電 8 vs #130 SkillReady 1 | | 評語都是「現有產品」；#162 一人無場域、期程只有模擬影片與草圖；#130 有耕莘確定場域與實測。 | | #106 5 vs #223／#192 2 | | #106 是 Figma 模擬原型（你的私註）；後兩案有實作。 | | #236 捕風捉稻影 7 vs #58 農先知 4 | | #236 期程 1–6 個月、場域導入在決審後；#58 系統已上線可回測。 | ## 影響力 - #128 油茶 5 vs #51 智慧配水 7：#128 原鄉、老農、台語（你定義裏加分項）；#51 自述只針對大坪頂一產區。 - #178 黑泥氫能 2 vs #74 永續電廠 8：兩案都是既有研究延伸；#178 承諾範圍全台 80 座水資中心，#74 是一座電廠的儀表板。 - #220 柯南櫃 0 vs #187 安心夜 5（治理 0 vs 2）：#187 上雲的是去識別**生理訊號**＋國網跑 LLM，比 #220 的找物事件敏感；#220 支援台客語。 - #112 阻詐演練 5 vs #200 2／#176 1：三案創新都 0（現有），#112 原文最明確已在執行（407 份問卷），影響最高。 ## 資料治理（權重 5%，但方向反的一組） 寫得最完整的拿低分、寫得最空的拿高分：#153（4）vs #14／#177（10）；#200、#108（4）vs #157 Meshtastic（8，評語本身是資安缺陷）、#38（6，資料只有文件名）；#209（4，「Gemini 或 cheatGPT 收集資料」）vs #95（2）；#58（1）vs #236（3）；#119（2）vs #61／#162（4）；#175（4）vs #126／#134（2）；#158（3）vs #215（5）。 ## 多元性（心證，只並排） #70 一人給 1（規則是 0）；#72 三類型 1 vs #10／#154 兩人 2；#185 三類型 3 vs #52 八人同銀行 6；#210 兩類型 6 vs #188／#19 兩類型 2；#234 五類型 6 vs #207 9／#128 8；#190 同校為主 7 vs #180 六校 4／#196 三類 4；#109 五類 5 vs #31 6／#199 7／#203 7；#62 兩類 1 vs #38／#39／#237 單一 2；#55 4 vs #74 1（同實驗室）。 你要從哪一段開始？ c84bcc28 2026-09-13 [17:27] 助理： 先回你問的兩個： - **#74 高分有什麼問題**：問題只在跟同實驗室 #55 的 0 對不對得上——兩案都自述「既有研究延伸」，#55 交付水槽模型、#74 交付儀表板。若你的判斷是 #74 像 #73 一樣「有想法」（把研究做成決策儀表板）、#55 只是工程，那 8 對 0 就說得通，跟你今天確認 #73 的理由一致。 - **#106 有什麼問題**：165 網址比對、簡訊關鍵字、深偽偵測、包裹照片——每一項市面上都有（Whoscall 類、各家防詐 App），組合也不新，你自己註「只有要做 UI、深偽無依據」；5 是「新組合、有自己想法」那一格，跟 #119（有「立真」憑證鏈）的 2 反過來了。 你其他的裁定我都記下，特別是一條新規則：**「別人做好了＝1」指台灣已有；只在國外有、台灣沒有的在地重製可以高分**（#179 9、#19 7 對 #167 2）。 **還沒回的：** 創新 - #226 PEBPS 臺灣化 8：原文自承引用 PEBPS 架構與公式、不宣稱原創——依上面那條新規則，PEBPS 台灣沒有，8 可以成立；只是要你確認。 - #177 AI Agent 詐騙 8：你的評語建議跟新北「反詐養蜂人」合作——台灣已有同類，這條規則下該是低分那一格。 - #182 一鍵巡田 0 vs #158 安心有據 3：兩案都提案前做好原型（#158「57 項測試通過」），一個因此 0、一個沒扣。 - #204 神農 10：新事實——原文自己寫 MIT 微型溫室做過（2020 關閉）、引 Wright 2023 開源生長箱；你給 10 是鼓勵實驗，看要不要因為「有人做過」調。 - #201 治蚊 7：跟 #84 同架構，台南自己已有無人機巡查（原文自引），本次加 AI；你說 #84「概念太多人做了」，#201 是不是同一句話？ 影響力 - #128 油茶 5 vs #51 智慧配水 7：#128 原鄉、老農、台語是你的加分項；#51 自述只做大坪頂一區。 - #178 黑泥氫能 2 vs #74 永續電廠 8：都是既有研究延伸，#178 承諾範圍全台 80 座水資中心，#74 是一座電廠儀表板。 - #220 柯南櫃 0 vs #187 安心夜 5：#187 上雲的是去識別生理訊號＋國網跑 LLM，比找物事件敏感；#220 有台客語。 - #112 阻詐演練 5 vs #200 2、#176 1：三案創新都 0（現有），#112 最明確已在執行，影響反而最高。 資料治理（5%） - 方向反的一組：寫得最完整的低、最空的高——#153（4）vs #14／#177（10）；#200、#108（4）vs #157 Meshtastic（8，評語本身是資安缺陷）、#38（6）；#209「Gemini 或 cheatGPT 收集資料」（4）vs #95（2）；#58（1）vs #236（3）；#119（2）vs #61／#162（4）；#175（4）vs #126／#134（2）；#158（3）vs #215（5）。 多元性（心證，只有一條是規則） - #70 一人團隊給 1，規則是 0。其餘並排：#72 1 vs #10／#154 2；#185 3 vs #52 6；#210 6 vs #188／#19 2；#234 6 vs #207 9／#128 8；#190 7 vs #180／#196 4；#109 5 vs #31／#199／#203 6–7；#62 1 vs #38／#39／#237 2；#55 4 vs #74 1。