這份文件把平台終態的所有頁面、後台、資料管線、AI 模組、合規層全部攤開， 用「1 設計 + 1 前端 + 1 後端 + AI」這個人力去算每一項要幾個 person-week， 得出「完整車要多少時間」的基準數字。然後再示範三種砍法 —— 讓老闆 / Na 姐能在同一份事實上做 informed cuts。
你說的是對的 —— 「先把整台車設計完，才知道哪裡可以砍」。
如果直接從 MVP 開始想，會永遠停在「這個也想要、那個也想要」的拉扯裡。
把車身、引擎、變速箱、內裝、儀錶板、空調、影音系統、安全氣囊都列出來，
每一個都有公開的工時數字，砍掉時就知道「拿走哪一塊」，
而不是模糊地說「先簡單一點」。下面的 xlsx 就是這台車的 BOM。
以「1D + 1F + 1B + AI 全力協助」的團隊計算，做完所有 201 個模組需要的日曆時間。 兩個情境：樂觀 = AI 工具發揮極致；保守 = 整合損耗、需求改動、學習曲線都算進去。
以 1 個後端工程師（瓶頸角色）為基準。Curation 還要另外算
7.7 – 10.6 個 curator-year（需要另聘 2-3 個全職 medical writer / data curator）。
換句話說 — Na 姐五年計畫要做完整 vision，
必然需要砍掉 50–70% 的功能。
這份文件的剩下部分就是教你怎麼砍。
缺口：樂觀情境少 4.4 年的工程容量，保守情境少 11.5 年。
必須靠「砍功能 / 加人 / 更激進的 AI」三種手段組合才能填上。
主檔層（Zone B）佔了 33% 的總工時 —— 因為含 50+ 醫院、500 醫師、150 疾病的 curation 工作。 後台層（Zone E）佔 18%，是團隊隱形的最大支出。
| Zone | 名稱 | 模組數 | Base (pw) | Opt (pw) | Cons (pw) | 佔比 |
|---|---|---|---|---|---|---|
| A | 對外探索層 Public Front | 23 | 226 | 110 | 175 | 8.0% |
| B | 主檔層 Entity Profiles · 含 Solution Package | 54 | 816 | 448 | 672 | 32.8% |
| C | 證據與國際公信力 Evidence & Authority · 含 ICHOM/Newsweek/Statista | 15 | 254 | 124 | 197 | 9.1% |
| D | 合作市集 Marketplace | 15 | 253 | 117 | 191 | 8.6% |
| E | 後台層 Backends · 院所/買家/平台 ops | 41 | 551 | 249 | 413 | 18.3% |
| F | 資料 AI 基建 Data, AI, Infra | 19 | 232 | 103 | 171 | 7.6% |
| G | 信任商業 Trust, Compliance, Commerce | 27 | 325 | 158 | 248 | 11.6% |
| X | 跨層基建 Cross-cutting (design system, devops, QA, brand) | 7 | 107 | 55 | 86 | 4.0% |
| TOTAL | 八個 zone · 完整車 | 201 | 2,764 | 1,364 | 2,153 | 100% |
※ 詳細到「每個模組 × 每個角色」請看 snq-build-plan.xlsx → Modules sheet。每個 base 工時都是藍字可改。
團隊三個角色不能互換。設計師不能寫後端，curator 不是 dev。 所以日曆時程不是「總工時 ÷ 3 人」，而是「最慢那個角色的工時 ÷ 1 人」。 後端是 9.4 年的根源。
事實一：完整車要 9.4 年（樂觀）是因為後端工時 453 person-weeks ÷ 48 週/年 = 9.4 年，
無論前端設計多快都填不了這個洞 — 後端等於是這台車的引擎。
事實二：NT$3,000 萬／年養 3 名工程＋ 1 名 BD ＋ 1 名 PM ＋ AI 工具，已經幾乎見底。
要 hire 第二個後端，得從別處挪 NT$300+ 萬，可能要砍 BD 或 marketing。
事實三：Curation 真的不能外包給 AI。 醫療資料需要 medical writer / 院所專人配合。
2 名全職 curator 一年消化 96 週，剛好夠 Y1 的 50 家醫院 + 50 種疾病的精煉工作。
MAX 是設計願景車（給老闆畫的餅），REALISTIC 是 5 年內 1+1+1 團隊能做到的（給內部 sprint 對齊用）， MIN 是 Y1 必須上線那一版（也是「能開上路的二手車」）。
完整 sitemap — 從首頁到 RWD pipeline、從 NDA library 到媒合 AI 一個不少。對外願景圖用。
當「終點是哪裡」的對話用 — 工程基準線、設計向量、永遠的北極星。
保留所有 S1+S2 模組 + 半數 S3，砍掉純 S4 modules（重型 marketplace、買家後台全套、payment、tier）。
內部 sprint 用這版。每季 review，發現偏離就回頭看 Modules sheet 重排序。
Y1 末必須上線的最小組合：首頁 + 50 醫院 + 50 疾病 + 院所後台基本 + SNQ ops 審核 + 法務地基。
需要對 Na 姐誠實告知 — Y1 年底 ship 仍可能只有 30 個模組，剩下 15 個進 Y2 Q1。
三個情境的詳細模組清單在 xlsx 的 Modules sheet 最右側三欄（MAX / REALISTIC / MIN）。 改 0/1 即可移進移出，Scenarios sheet 會自動 reflow。 下次跟老闆討論時可以即時調整 — 是這份模型的核心價值。
下面的工時數字裡，AI 倍率已經內建。樂觀情境假設下列工具被用得很到位（每月預算 NT$3 萬以內）。 別在這部分省錢 — 一個月 NT$3 萬的工具能救一個 NT$25 萬／月的工程師。
把 sitemap 餵 Claude → 自動生成所有頁面的 wireframe（ASCII / Mermaid）。Designer 不必從零開始畫每一頁。
省 ~40% Designer wireframe 時間把 wireframe + 設計系統 token 餵進去 → 產出高保真設計。v0 較精準（適合 web），Stitch 更接近 figma 互動。
省 ~30% Designer 視覺時間Designer 給 spec → 直接 prompt 生 React。複雜互動仍需人類，但 90% 的 JSX/CSS 是 AI 寫的。
省 ~50% Frontend 切版時間Schema 寫好 → AI 生成 CRUD、admin UI、API。Y1 院所後台主力用這個 — 是最大省時甜蜜點。
省 ~60% Backend CRUD 時間把醫療領域知識給 Claude → 產出 schema 第一版。關鍵：schema 一定要人類最終 review，定錯了未來重做整套。
省 ~30% Backend schema 設計時間把院所原始資料整理成結構化格式 + EN 翻譯草稿。醫療專家必須校稿 — AI 不能直接 ship。
省 ~50% Curator / Writer 時間PubMed / ClinicalTrials 等 connector 套版。現成 connector 用就好 — 自己寫是浪費時間。
省 ~55% Backend ETL 時間RAG over 平台資料，做 AI 媒合 / 疾病 Q&A。Y3+ 才正式上 — Y1 重心在「資料齊全」而非「AI 花俏」。
省 ~40% Backend ML 時間E2E 測試完全由 AI 寫。三人團隊無人專責 QA，但靠這套能確保品質。
省 ~55% QA 時間Hosting / DB / CI/CD setup 用 AI 配置。絕對不要自己架 K8s。三人團隊無法承擔 infra 維運。
省 ~60% DevOps 時間完整 14 個工具的清單與每個建議的月費，請看 xlsx 的 AI Stack sheet。 建議每 3 個月 review 一次 — AI 工具市場每月變化。
某些模組是別的模組的 blocker —— 在它們做完前其他事都動不了。 Y1 必須照這個順序，順序錯了會浪費 2-3 個月重工。
加總 ~ 56 weeks (~13 個月)。所以 Y1 12 個月內想 ship Beta，必須有重疊執行 — Step 02 跟 03 平行、Step 05 提前在 Step 04 後段開始。
這不是「按表抄」的工程文件，是談判桌上的 reality check 工具。 建議跟老闆、Na 姐、團隊三場對話依下面的順序進行。
1. 跟老闆：用 MAX 願景圖談「終點」，用這份計算告訴他 5 年內能落到 REALISTIC，
Y1 只能落到 MIN。讓他選願意接受哪個對外承諾。
2. 跟 Na 姐：用 REALISTIC 對齊 Y1-Y5 timeline，確認 ICHOM/Newsweek/Statista 的工作可以排到哪一年。
3. 跟團隊：用 MIN 排 Y1 sprint。每季 review、調整 MAX/REAL/MIN 的 flag。