📜 製作歷程（全部公開：資料、假設、調參紀錄、沒做的事）

台北市長模擬器・製作歷程

全部公開：資料從哪來、每個數字是事實還是假設、調參時試過什麼、沒做的事。

這份檔案由 build-game.js 原樣嵌進遊戲的「製作歷程」面板。

一句話

把一位市長參選人官網上的 94 項政策，放進一個有人力上限、有預算年度、有議會會期、有選舉週期的四年模型裡，看「做不做得到」。不模擬成效，不是預測。

資料來源（事實）

policies.json：https://puma.taipei/heart-island-assets/policies.json（官網核對日 2026-10-10；本專案擷取 2026-10-27）。14 島、94 項、20 條政策關聯（flows）、3 句訪談引文。
characters.json：同一頁面內嵌的「台北的哪一種人」角色資料（7 區 8 位人物，年齡與身分照原文）。
時程：每項政策的 phase.stages 照官網原文（如「第 1–8 個月盤點」「第 3–4 年」「117 學年」「第二階段」）。94 項裡 46 項有時程、48 項官網沒寫。
制度事實：就任日 2026-12-25（第 1 月＝2027-01）；年度預算由前任市府編列；台北市議會每年兩次定期會，下半年審明年度預算；117 學年 2028-08-01（第 20 月）；2028-01 總統大選（第 13 月）；2030-11 地方選舉（第 47 月）。

把官網字句翻成數字（假設，標 ASSUMED）

官網寫法	當成第幾月結束
第 1–8 個月／第 8–18 個月	8／18
短期／中期／長期	12／30／72
第一／二／三階段	12／24／36
第 1 年／第 1–2 年／第 2–3 年／第 3–4 年／第 5–8 年	12／24／36／48／96
117 學年	32（且不得早於第 20 月開學）
沒寫	開工月份隨機 1–20，不當評分依據

成本等級（關鍵字推斷＋手動修正 11 項）：要蓋（heavy，34 項，需年度預算 3 單位）、經常門（medium，23 項，1 單位）、盤點（light，37 項，不需預算）。全速投入所需月數：6／12／22 個月（ASSUMED）。

模型裡的規則（全部可在原始碼 `World.prototype.step` 查到）

人力上限：市府同時只能全速推 26 項（ASSUMED，見調參）。每項拿到的速度＝權重 ÷ 總權重 × 量能；全部一起開＝每項都走慢。
專注：被點星的島權重 2，其他 1。專注是重新分配，不是加班，所以不增加壓力；有明確優先順序反而每月降壓 0.01。
壓力：同時開工項數超過上限就累積；壓力高時量能打折（最多 −25%）、隨機延誤、長期無人力的項目可能中止。
預算：第 1 年只有前任編的預算，資本門不能動（要蓋的項目做到 35% 就要等）。每年 12 月議會審明年預算，通過比例＝0.55＋0.5×滿意度−0.55×議會阻力±噪音；就算全過，一年也只夠 45% 的資本門需求（ASSUMED），專注島先拿。
議會：含「條例／自治」字眼的項目做到 100% 後要在會期（5、6、11、12 月）表決，被退回機率＝議會阻力×0.8，退回後進度回到 60%。議會阻力每季向「1−滿意度」靠近 20%；第 44 月（選前一年）阻力＋0.15。
選舉：第 13 月量能 ×0.9，第 44 月起 ×0.8。
先減壓（官網引文 Q4、Q7「半年之內一定要把這件事情做完」）：公務員政策每完成一項，量能 +5%（旋鈕預設 0.3 ÷ 6 項）。
上游島：官網 20 條 flow 的上游島完成度 ≥50% 時，下游島速度 ×1.2。
滿意度：完成加分（盤點 +0.006、其他 +0.015）、停滯扣分（每項每月 −0.00015）、低壓加分、預算沒過扣分。
工程超支：每項各自抽 1.2× 上下 ±30%（對數常態）。

調參紀錄（都是同一支程式、30 個種子、議會阻力 0.4）

「放著不管」＝不點任何島；「先減壓」＝專注 civil；「先減壓＋2 島」＝civil＋交通＋教育；「三大島」＝衛福＋教育＋運動；「輪流」＝每半年換三島。

版本	放著不管	先減壓	先減壓＋2 島	三大島	備註
上限 100、無預算約束	91	91	91	—	全部做完，沒有遊戲
上限 45	87	87	85	86	仍太鬆
上限 30、壓力回饋 50%	38	38	32	27	滿意度歸零、取消 44 項——壓力正回饋崩潰
上限 36、取消變罕見	84	83	68	46	雙穩態：不是全過就是崩
上限 30、專注算進負載	76	77	75	73	專注永遠不比放著好——專注被算成加班
上限 26、專注＝重新分配	53	72	73	61	定案。輪流 61。策略有差，先減壓最好，照官網承諾
上限 22	33	41	41	34	太難，滿意度全歸零

定案理由：三種策略拉得開、「先減壓再推其他」這句官網承諾在模型裡真的最有效（不是硬寫進去的，是人力上限＋量能加成自然跑出來的）、取消項數個位數（真實世界政見很少正式宣告取消，多半是拖）。

測試（2026-10-27 深夜）

莎士比亞（猴子測試員 ZPD/_tools/monkey.py）在線上版亂按 90 秒、645 下：零錯誤、零假按鈕、零死鈕。
試飛員（pilot.js，不開瀏覽器直接跑引擎）：每場隨機抽一個台北與一種策略，檢查六條不變量（進度 0–1、完成不早於開工、117 學年前不得完成、沒經費不得完成、量表不超界、94 項守恆）。一萬場零違規，十萬場也零違規（34 秒／萬場，十萬場約 6 分鐘）；十萬場的趨勢分布圖在 trends.html（仿「一千個地球」的扇形帶：每月 10–90% 與 25–75%）。
一萬場的數字：放著不管中位 53 項（九成在 47–58）、先減壓 73（67–77）、先減壓＋兩島 73（65–77）、隨機三島 65（52–73）。議會阻力 0.05 與 0.95 只差 4 項（74 vs 70）——議會在這版模型裡影響太小，是下一個要修的地方。

沒做的事

沒有金額。官網沒有任何預算數字，所以預算只以「比例」代入。
沒有成效。「完成」＝排定的最後階段結束，蓋好的中心有沒有人用，模型不知道。
沒有校準。沒有查到歷任台北市長政見完成率的可用紀錄；人力上限 26 是用「讓策略拉得開」調出來的，不是測出來的。
沒有音效。
48 項官網沒寫時程的政策，開工月份是隨機的；面板上會標「官網沒寫時程」。

製作過程

2026-10-27 晚間。先抓官網頁面，發現 three.js 政策島讀的是一支 policies.json，整份資料結構完整（含 flows、引文、角色）。
第一版是「報告」（蒙地卡羅 20,000 次、敏感度表）。Master：「我要做成遊戲！就跟模擬地球一樣！」改做成月份逐格跑的互動版。
第二版加入可愛／擬真／極簡三軸（照 cute-hardcore-realism 規範）：居民表情、建築從虛線→工地→亮燈、一種操作（點島）、人力／預算／議會／選舉四個真實約束。
調參七輪（上表）。
Master 定名「模擬北市3000」；要求遊戲內不出現人稱代詞、製作歷程全部公開。
部署：片場代號 ab875ca2，noindex，不上 Lab。
Master：「為什麼不用之前發展的標準版面？」——第一版自己排的版面是疏失。改套基本框架第一號 primary-left（主視窗 1400² 靠左；右欄 System Control 100｜Info 630｜Control 630；外距間距一律 20），手機照 primary-phone（Title｜System → 正方形主視窗 → Info → Control，事件／島民／旋鈕／製作歷程是按鈕後滑上來的抽屜）。
Master 定名「台北市長模擬器」（原「模擬北市3000」保留為製作期代號）。

署名

資料：沈伯洋台北市長競選官方網站（公開資料）。模型、程式、調參：Yen-Ting R. Lin 與 Claude（Anthropic）協作，2026-10-27。

台北市長模擬器