AI 讓你做出東西，軟體工程思維讓它活下去：Vibe Coding 時代，真的還需要前後分離嗎？
Omakase Smart Hospital 系列
每個人都在 Vibe Coding
2025 年開始，我們身邊的對話明顯變了。
不只是工程師在聊 AI，連醫院裡的行政人員、護理師、甚至科主任都在說：「我用 ChatGPT 寫了一個小工具」「我請 Cursor 幫我做了一個排班表」「我兒子用 AI 三天做出一個 app」。
這件事本身是好的。Andrej Karpathy 把它叫做 Vibe Coding，「感覺對了就好」，不用真的懂每一行程式碼在做什麼，只要對 AI 描述你想要的東西，它就幫你生出來。門檻從來沒有這麼低過。
但大家是否有注意到一件事：這些「Vibe 做出來的東西」，大多數活不久。
不是因為功能不對，是因為沒有人想過它怎麼上線、怎麼更新、怎麼在出問題的時候找到原因。能跑和能用是兩回事，能用和能活下去又是兩回事。
前後分離的十年
在談 AI 改變了什麼之前，我想先回頭看一個更早的趨勢。
過去十年，「前後端分離」幾乎成了業界的預設選項。前端用 React、Vue、Angular，後端用 Node.js、Go、Java 寫 API，中間用 JSON 溝通。分工明確，各司其職。再加上微服務架構的流行，一個系統被拆成十幾個服務，每個服務各自部署、各自維護。聽起來很美好，但現實是大多數團隊根本不需要那麼大規模的拆分，這樣反而被架構本身的複雜度拖慢了速度。
我個人一直偏好「微系統」甚於「微服務」。微服務是把一個系統拆成很多碎片，微系統則是讓一個完整的小系統自己就能獨立運作。不是把一件事拆給十個人做，是讓一個人把一件事做完。這兩者的哲學完全不同。
這其實跟 SMART on FHIR 的設計邏輯不謀而合。SMART on FHIR 的核心思想就是：每個應用程式都是一個獨立的小系統，透過標準化的 FHIR API 和 OAuth2 認證跟醫院的主系統溝通。你不需要把功能塞進龐大的 HIS 裡面，而是讓每個小系統各自完整、各自獨立運作，需要的時候透過開放標準串接。
想像一下 LEGO。微服務像是把一塊完整的積木切碎，每一小片都要靠其他片才能站得住。微系統像是每一塊 LEGO 本身就是一個完整的模組，可以獨立存在運行，也可以跟其他模組拼在一起組成更大的東西。SMART on FHIR 就是那套讓 LEGO 能彼此卡合的標準介面。每個 app 是一塊完整的積木，FHIR API 是卡榫，OAuth2 是確保資訊安全且只有對的積木能接上去的機制。
這才是我認為醫療資訊系統該走的方向：不是蓋一座拆不開的城堡，是打造一盒可以自由組合的 LEGO。
前後分離加上微服務，這套組合有它的道理：大團隊、大產品、前後端各有專精的人。但它也帶來一個副作用，Fullstack 這個角色漸漸被邊緣化了。你說你什麼都會？面試官會覺得你什麼都不精。前端嫌你 CSS 不夠細緻，後端嫌你 SQL 不夠深入，DevOps 覺得你不懂 Kubernetes。
Fullstack 工程師被拆散了。不是因為這個角色沒有價值，而是因為產業的分工邏輯把它擠到了縫隙裡。
然後 AI 來了之後.....
AI 讓 Fullstack 重新成為可能
Vibe Coding 的出現，表面上看是「人人都能寫程式」。但對原本就具備軟體工程能力的人來說，它的意義完全不同。
AI 補上了 Fullstack 工程師最大的痛點：跨領域的細節成本。
過去，一個後端工程師想碰前端，光是搞懂 webpack 設定、CSS 框架的 class 命名邏輯、React 的 state management，就要花掉大量時間在不產生直接價值的地方。反過來也一樣，前端要學 SQL 最佳化、API 認證流程、伺服器部署，每一項都是一座小山。
現在這些小山被 AI 剷平了大半。不是說你不需要理解這些東西，而是你不需要記住每一個細節。你知道方向在哪裡，AI 幫你處理路上的碎石。
這讓一件事好像變得真的可行，一個人，從需求到上線，交付一個完整的系統。
不是 demo、不是 prototype、不是「能跑就好」。是一個有測試、有部署流程、有監控、可以持續維護的系統。
能跑、能上線、能活下去
這裡就是 Vibe Coding 和軟體工程的分界線。
我用幾個實際的專案來說明這個差距。
做出東西：每個人都做得到
用 AI 工具建一個掛號系統的 prototype，大概一個下午。畫面會動、可以點按鈕、可以選醫師、可以送出掛號。截圖貼到社群上，看起來很像那麼回事。
讓它上線：需要工程判斷
但如果這台掛號機要放在醫院大廳，給阿公阿嬤實際操作呢？
以自助掛號機為例，放在醫院大廳給阿公阿嬤操作。插入健保卡、選醫師、完成掛號，整個流程必須在幾秒內完成，因為後面還有人在排隊。同時有 30 台機器在不同樓層運作，門診尖峰時段一台都不能當掉。
這裡面每一個設計決策都不是 AI 能幫你做的。用什麼框架、資料怎麼傳、系統之間怎麼溝通、效能要撐到什麼程度，這些都需要工程師根據已經存在的條件做判斷。
這些決策不是「vibe」出來的，是軟體工程思維。
讓它活下去：需要持續維運
掛號機上線之後，才是真正挑戰的開始。
30 台機器分散在不同樓層，不可能出問題就跑去現場插隨身碟重灌。所以建了 OTA 遠端更新機制，透過地端自建 S3 發布新版的安裝套件，每台機器自動下載、驗證、安裝。版本管理、錯誤回報、日誌收集，每一項都是「能跑」階段完全不會想到的事。
這整個專案一個人開發。AI 幫了很多忙，但幫的是實作細節，不是工程決策。
軟體工程思維到底是什麼
講到這裡，可能有人會問：你說的「軟體工程思維」到底包含什麼？是不是就是 DevOps、CI/CD 那些東西？
不全是。DevOps 和 CI/CD 是其中一環，但軟體工程思維是一整套讓系統「活下去」的能力。
先想清楚再動手。 開發醫院官網的時候，團隊用了 Spec-Driven Development 的方式，每個功能變更都從一份規格書開始。三個月累積了 118 份歸檔的功能規格。聽起來很繁瑣，但效果是：AI 依照規格書實作，品質穩定；團隊成員看規格書就知道功能在幹嘛，不用開會。Vibe Coding 是「邊做邊想」，軟體工程是「想清楚再讓 AI 做」。
寫測試不是浪費時間。 能跑不代表正確。醫院官網有完整的測試套件和安全掃描，不是因為我們時間很多，是因為改壞一個門診掛號功能，影響的是真的病人。Vibe Coding 做出來的東西通常沒有測試，改一個地方壞三個地方，最後只能砍掉重來。
上線不是終點，是起點。 另一個例子是火線超人，透過 LINE 聊天介面查詢 FHIR 醫療資料，支援多家醫院、符合 SMART on FHIR 國際認證標準。461 個 commits，跑在一台每月 5 美元的 DigitalOcean 主機上，用 Docker + Kamal 部署。它不是做完就放著的 side project，是持續在演進的系統。每一次更新都有 CI 流程、安全稽核、zero-downtime 部署。
安全不是選配。 火線超人處理的是病人的醫療資料，OAuth2 認證、資料遮蔽、權限控管，每一項都是必要的。自助掛號機讀取的是健保卡，個資保護不能馬虎。Vibe Coding 出來的東西通常連基本的輸入驗證都沒有，更別說資料加密和權限設計。
一個人搞定全部，不是神話
有人可能覺得這些聽起來像是大團隊才做得到的事。
事實是，自助掛號機是一個人開發的。火線超人也是。個人部落格更不用說，從零打造，沒有套 WordPress 或任何現成的 CMS。
這不是因為某個大神特別厲害，而是因為工具鏈進化了。
現在的全端框架已經成熟到一個人就能處理快取、背景工作、即時通訊，不用額外架一堆服務。部署工具讓上線變成一行指令。AI coding 工具讓你在不熟悉的領域也能快速產出可用的程式碼。
但工具只是工具。讓這些專案真正能上線、能維護的，是背後的軟體工程思維：知道什麼時候該寫規格、什麼時候該寫測試、什麼時候該建 CI pipeline、什麼時候該做壓力測試。
AI 放大的是你原本就有的能力。如果你只有 Vibe，AI 放大的就是 Vibe。如果你有工程紀律，AI 放大的就是工程紀律。
我們習慣買，不習慣造
講完技術，聊聊產業。
台灣的 IT 產業有一個很深的結構性問題：我們太習慣買軟體，不習慣造軟體。
醫院被綁在 Oracle、SAP 或特定廠商的 HIS 系統上，開發者的日常不是設計系統，而是維運別人的系統。企業要解決一個問題，第一反應是「有沒有套裝軟體可以買」，不是「我們能不能自己建」。久而久之，開發者的角色從 Builder 變成了系統管理員，從「創造者」變成了「維護者」。
這不是個人能力的問題，是整個生態系統的慣性。當你的工作環境裡只有商業軟體和封閉系統，你很難想像「自己從零開始打造一個系統」是什麼感覺。不是不會，是沒有機會。
這個枷鎖在 AI 時代變得特別危險。
當全世界的開發者都在用 AI 工具一個人交付完整產品的時候，台灣的開發者還被困在 vendor lock-in 裡，每天的工作是幫商業軟體打補丁、寫客製化報表、處理廠商的 bug。技術能力沒有消失，但被壓抑了。像一把被封印的劍。
你可以自己建
我不是說商業軟體不好。在很多場景下，買成熟的解決方案是對的選擇。
但你應該有選擇的能力。
「這個需求，我可以自己建」和「這個需求，我只能等廠商報價」，是完全不同的處境。前者讓你擁有主動權，後者讓你永遠在等。
AI 工具降低了自建的門檻。成熟的全端框架降低了技術複雜度。現代化的部署工具降低了維運負擔。這些加在一起，讓「一個人或一個小團隊從零打造系統」變得前所未有地可行。
但前提是，你得有軟體工程思維。
不是只會 Vibe Coding 讓 AI 幫你生出一個 prototype，而是知道怎麼把一個 prototype 變成一個可以持續運作的系統。知道什麼是規格驅動開發、什麼是持續整合、什麼是 zero-downtime 部署、什麼是資料備份策略。
這些東西聽起來很 old school，但它們就是讓系統活下去的基礎工程。AI 沒有改變這個事實，AI 只是讓你有更多時間去做這些重要的事。
所以，真的還需要前後分離嗎？
前後分離是大團隊時代的產物。當一個人就能處理前端、後端、部署、維運的時候，硬拆成兩邊，反而是在製造不必要的複雜度。
對大公司、大團隊來說，可能還是需要。但對越來越多的個人開發者和小團隊來說，答案正在改變。
Vibe Coding 讓每個人都能體驗「做出東西」的感覺，這是好事。但如果你想做的不只是 demo，你需要的不只是 Vibe。
AI 時代的 Fullstack 不是什麼都會一點的半吊子，而是一個人能把事情從頭到尾做完的 Builder。差別在腦袋裡有沒有那套軟體工程思維。