6題分析、13支影片，花了58小時、33.7億Token，我怎麼做，踩到哪些坑，一次給你看

做到內湖塞車那一題的時候，AI 交來一份算得很仔細的分析：從下午 4 點半開始，每個時刻離開內科，到市區要多久。數字都對，圖也畫得漂亮。

我先回它「幹得好，方法論上很漂亮」，接著補了一句：

但是沒有人能在 16:30 下班啊，這個算法是沒有用的正確。

這次市政 debug松 的六題，我最常做的就是這件事。AI 很會算出對的答案，我負責問：這個答案對誰有用？

市政 debug松 是沈伯洋競選總部辦的開放資料活動，出了六道題目。

上次我 23 天做完 4 個 App，是一次做一個，我參與每個決定。

這次不一樣。10 月 14 日我開始摸這次的開放資料，然後放置。到了 10 月 20 日晚上 9 點 22 分決定六題同時做，10 月 23 日早上 6 點 55 分第六題上線，前後約 58 小時，2/3 時間我不在電腦前，靠手機遠端合作。

這 58 小時裡一起跑的 AI 有 12 個。5 個做專案：1 個統籌，自己做垃圾桶和危老；種樹、鼠患、內湖塞車、公車各一個。7 個協助：做影片、網站上架、中文校稿、讀者審稿、論述審稿、插圖、資料備份與監看。分析寫完，再請另一家公司的 AI 當第三方審一次。

六題是：

• 種樹：「一年少了 3,164 棵樹，多為病蟲害或自然死亡？怎麼種回去。」台北 53.8 萬人住在樹蔭不夠的里，那裡有 499 個舊樹穴，先去看能不能種回去。
• 垃圾桶：「一年撤掉 876 組垃圾桶，怎麼用感測偵測桶滿」找回消失的垃圾桶。
• 鼠患：「夜市、下水道與垃圾清運」補足垃圾清運跟下水道的基本功，同時恢復量測老鼠。
• 內湖塞車：「用早高峰車流讓市府跟企業談錯峰上班」內科下班去市區：一樣約 7 點到松菸、直線距離差不多，搭捷運要比北車早 15 到 23 分鐘出發。
• 公車：「公車與捷運路線重疊、依需開車，避免司機過勞」台北 35.4 萬人一小時內到不了八成的里。
• 危老：「50年以上老屋佔比高，結合土壤液化跟消防通道過小，及居民年齡，建立公辦都更優先序模型」危老屋有兩種，有的搶著都更，有的需要介入。

方法論：每一題都走這幾步

1. 先驗題目的前提。主辦的題目都帶著一個預設，開工第一件事拿資料驗它。
2. 盤資料。清單上的每一份先下載跑過，清單外的也去找；只給「現在」的即時資料，當天開始存。
3. 先定單位和分母，再算比例。空白和預設值先當成「不知道」。
4. 問讀者會拿誰跟自己比。比較的對象、讀者真的會選的時刻、這個量會不會沿路累加，三件事定了才開始算。
5. 分清楚事實和主張。「沒人量」是事實；主張要講該做什麼、在哪裡做。
6. 驗證的門檻在算之前就寫死。沒過就不放，不回頭改門檻。
7. 做敏感度。換權重、換半徑、換算法，結論還在才寫成主張；不在，就把幾種結果都列出來。
8. 每一題交上來，我只問三件事：論證是什麼、基礎夠強嗎、對市民有用嗎。

探索：題目的前提，先拿資料驗

六題裡有四題的預設被推翻或改寫。

內湖塞車最明顯。10/21、10/22 這兩天，整段掉到最塞一級的時間，早上進內湖合計 2 分鐘，傍晚出內湖 415 分鐘。早上往內科的堤頂大道錯開半小時，只省 23 到 58 秒。

鼠患那題在開放資料裡找不到老鼠：陳情資料 19 個月份檔，類別裡沒有鼠，也沒有地點；2015 年以前每年做的密度調查，之後沒有再做。公車那題要的刷卡資料沒有開放。危老那題要的逐棟屋齡、結構、住戶，也沒有。

主辦列的資料清單只是起點，能用的檔常常在清單外。內湖塞車靠的是交通局每分鐘更新的即時路況檔，免金鑰，主辦的清單沒列。它只給「現在」，歷史要自己存，所以我們每分鐘抓一次，會一路存到 10 月 30 日。種樹那題想知道哪些行道樹不見了，市府沒有開放移除紀錄。我們從網頁存檔找回 2024 年 11 月的舊名單，跟今年 10 月的比，消失了 9,363 個樹籍編號（每棵樹的編號）。

數據分析：資料會騙人的幾種方式

六題做下來，最花時間的是資料。好幾次數字算完，才發現資料跟我以為的不一樣。

主辦附的資料可能是舊的。垃圾桶那題，主辦列的公車站牌是 2020 年的檔，3,407 個。換成公運處今年的站位檔，變成 3,460 個，「站牌 100 公尺內什麼都沒有」也從 50% 變成 53%。

種樹那題的公園樹檔有 72,011 棵，其中 9,266 棵的胸徑是 0 或空白，74 個公園整園沒填。空白很容易被當成零，算大樹之前要先挑出來，標成「不知道」。

半徑一換，結論跟著換。垃圾桶那題數公車站牌附近有沒有垃圾桶或超商：50 公尺內什麼都沒有的站牌 74%，100 公尺 53%，200 公尺 32%。三個數字都對，所以頁面寫明，引用時一定要帶半徑。

10/21 往南的堤頂大道，早上兩小時過了 6,385 輛汽車，傍晚塞住的兩小時只過 4,096 輛。只看流量，會以為早上比較忙。路一塞，車速掉下來，過得去的車就變少。所以內湖塞車看的是通過一段路要幾分鐘。

洞察形成：讀者會拿誰跟自己比

內湖塞車的主張前後改了四次，每次都是我一句話。

AI 一開始把各路段同一分鐘的塞車時間加起來。我說交通是連鎖的，前面一段塞住，你開到下一段時已經更晚、更塞了。改成沿路累加，每一段都用你抵達那一刻的路況。

接著是開頭那句「沒有用的正確」，起點改成 5 點。

然後 AI 拿傍晚跟深夜比，算出傍晚是深夜的幾倍。我說：「不要跟深夜比，大家是跟在台北上班比。」

最後我問：內湖有多少人開車上班？我們為什麼一直看自用車，搭捷運公車的不是人嗎？補上從大樓門口算起的門到門時間。

題目最後變成讀者自己會問的那一句：一樣晚上 7 點要到松菸，直線距離差不多，在內科上班的人要比在台北車站一帶上班的人早幾分鐘出門？只搭捷運，早 15 到 23 分鐘；加上公車，早 15 到 17 分鐘。開車的人看快速道路這一段，不同時段離開，下堤頂的時間會差超過 10 分鐘。

「下班比上班慘」這個結論，我想找人反駁看看，就請負責內湖的 AI 去翻 PTT 和新聞，看大家抱怨內湖塞車，講的是上班還是下班。有講時段的 24 則留言，上班 12 則、下班 10 則；光是一串颱風前關水門的討論，就占了下班那邊 4 則。分不出來。網路上的抱怨量撐不起任何一邊，所以頁面上的結論只靠感測器的資料。

鼠患的初稿主張是「市府沒在量老鼠」。我回：

主張是沒人量嗎？沒人量是事實，主張應該是綜合考量餐飲與既有清潔方式後，有多少地區是危險地區，需要落地處理下水道與垃圾清運…然後才是量，量是檢驗。

主張改成：餐飲多、垃圾車停靠點少的 58 個里，住了 33 萬人，是垃圾清運的優先區域，其中 21 個里的下水道圖還是舊圖。恢復量測老鼠，用來檢驗清理做得夠不夠。

公車的初稿在找適合改成彈性小巴的候選里，找出來沒幾個。我問：「候選里很少，是假問題嗎？」於是換一個問法：從每個里出發，轉兩次車以內、含等車一小時，到得了全市八成的里嗎？答案是有 67 個里到不了，住了 35.4 萬人。

垃圾桶也換過一次看的單位。一開始照里來算，可是里的統計會被面積和戶籍人口帶著走。垃圾桶是給路過的人用的，所以改看人會經過的點：3,460 個公車站牌和 87 個捷運站。

論點取捨：先劃掉，再留下

危老那題，題目要的是加權評級：每個里打一個總分，排出優先順序，AI 主張不要做。我的意見是：

模型不是不能做，是不能在參數不透明的狀況下做，做一組隨機參數的效果。

我們把七個里級指標的權重隨機抽了 2,000 組，每一組都排一次前 30 名。兩組名單的重疊度，中位數只有 0.28。進過前 30 名的里有 195 個，每一組權重都排進前 30 的里，0 個。

所以危老不打總分，改成把「房子那一面」和「人那一面」各分高中低，排成九宮格，兩面都高的 7 個里先去查證。題目說 2035 年老屋會過半，我們用房屋稅籍重算，分母會動，只報區間：49% 到 55%。

公車碰到的是另一種取捨。等公車的時間，用平均算，大約半個班距，白天一小時內到不了八成的里有 67 個；用最壞的情況算，等滿一個班距，是 216 個。兩種都說得通，結果差了三倍。頁面兩種都列，公車頁的標題用 67。

鼠患遇到的是官方數字自己打架。同一個春天，1999 的老鼠通報從 2 月 258 通降到 4 月 73 通，降 72%；滅鼠專案的捕獲數從每天 60 隻升到 85 隻，升 42%。市長引前者，議員引後者，都是新聞轉述，出處列在鼠患那一頁。兩個數字的算法與期間不同，不能互相驗證，我們哪一個都沒拿來當證據。

驗證沒過的東西也不放。內湖塞車原本想用公車的即時位置，補上巷道與橋這一段的時間。拿交通局的路段資料對照，相關係數 0.34，事先定的門檻是 0.6。沒過，那一段就整段拿掉。

跟 AI 合作：我只做兩種決定

一開始，切點、門檻這種分析上的選擇，AI 都會回頭問我。問到第三天，我請它們別再把這種選擇丟給我。從那之後分工改了：我只決定兩件事，要的方向，以及每一條能不能公開。其他分析上的選擇，由負責那一題的 AI 自己定、自己扛。

規則我盡量寫成文件，不寫在提示詞裡。種樹那題交上來，資料堆在最上面，讀者要滑很久才知道這頁要說什麼。我問：「你到底有沒有叫大家按格式？我不要再講第一百次」。之後每頁照同一個架構：主張放最上面，接著是題目怎麼說、怎麼看、解題方法，資料放最後。這個架構另外寫成一支檢查程式，每頁交件前七條要全過。

AI 之間會互相傳話，傳話只當線索，公開還是我直接跟負責的 AI 說話才算數。有一次一個 AI 轉述我同意某一頁上架，負責網站上架的 AI 就把它擋了回來。

AI 也會安靜地出錯。公車那題有一版程式，一個變數的名字跟站位清單撞在一起，456 個里全被當成沒有公車站。程式照樣跑完，沒有報錯。現在產生頁面的程式都加了檢查，數字超出合理範圍就停下來。

畫圖也一樣。內湖塞車本來想用灰姑娘當插圖，AI 畫的左格是 5 點的辦公室窗外，路上沒幾台車，正好跟資料相反：堤頂大道傍晚 5 點已經掉到最塞一級。後來換成浦島灰公主：5 點準時關電腦，路上已經塞了；騎著烏龜到市區，天也黑了。之後 AI 畫的圖一律不放數字，時間和數字用程式另外疊上去。

檢討：做對的三件，要改的三件

做對的第一件，是規則先寫成文件和程式。這 58 小時有三分之二我不在電腦前，用手機回幾句就推得動，因為每個 AI 開工先讀同一份規則，交件前跑同一支檢查。

第二件，是寫的和驗的分開。很多錯在上線前就被另一個 AI 抓到：做影片的 AI 發現危老頁面寫「低於 1 件」，程式算的是 0.5 件以下；統籌的 AI 在其他 AI 的文件裡抓到 16 處舊數字。

第三件，是資料自己存，而且看得到有沒有漏。10 月 23 日早上，公車位置改成每分鐘抓，06:55 到 09:40 應該有 166 個檔，166 個都在。

要改的第一件是 token。這 58 小時，專心做這個專案的 6 個 AI 對話（5 個專案加做影片的那個）用了 33.7 億 token，其中 97.8% 是重讀前文。AI 每做一步，讀一個檔、跑一個指令，都要把整段對話從頭再讀一次。統籌的那個對話跑了 1,937 輪，每一輪背著的前文中位數 59 萬 token，光它就重讀了 11.2 億。重讀按價格只算一般讀取的十分之一，折算下來，還是占了約三分之二的花費。

下次長的對話做滿 3 小時，或前文長到 40 萬 token，就把進度寫成一份檔案，開新對話接手；指令能一次跑完就不要拆成十次；大量讀檔的工作，另開一個做完就關掉的 AI 去讀。

第二件是即時資料太晚開始存。10 月 14 日就開始摸資料，內湖塞車的即時路況卻到 20 日晚上分頭做之後才開始存。結果只有 21、22 日兩天，第二天中午還發了颱風警報。早一週開始存，手上就有完整的平日。

第三件是轉述會走樣。統籌的 AI 曾經把 26 讀成 27，也給畫圖的 AI 傳過一則我沒說過的指示。同一份里界，各個對話手上存了 9 份，內容有 6 種。後來定了兩條規矩：每個事實只認一份原始檔，其他地方只引用；對話之間交接只傳檔案和原話。

接下來：從一頁分析，到天天用得到

這個系列觀看最多的一則，是我 10 月 20 日自己貼的垃圾桶圖文，截至 10 月 23 日 13 點有 2,099 次觀看、196 個讚。所以我另外開了一個 AI 對話，做一個查附近哪裡有垃圾桶的 App。最大的風險在資料：市府公開的垃圾桶點位表（9 月 30 日版）只有 681 個，74% 的公車站牌 50 公尺內沒有垃圾桶，也沒有超商。第一步先抽查點位對不對，再決定怎麼做。

我想做的，是讓這些分析離開比賽頁面：市府拿得去跟企業談錯峰，路上的人找得到最近的垃圾桶，住在名單上那些里的人看得到自己的里為什麼在上面。種樹那題，我想看到那 499 個舊樹穴重新種上樹。台北樹冠到三成、300 公尺內有公園的里，10 月 23 日是 52 個，每年重算一次，看它有沒有往上。每一題的程式都留著，資料一更新就重跑。內湖塞車會在颱風過後收齊 10/27 到 10/30 四個平日之後更新。

這篇寫完的時候，那支程式還在每分鐘抓一次內湖的路況。

2026 年 10 月 23 日