現在很多 AI 展示都很迷人。你貼一段需求，十分鐘後就有一個看起來像樣的介紹頁、一個能按能切的 dashboard，甚至一個可以走幾步流程的 demo。這件事確實很重要。它把想法變成畫面的門檻拉低了，也讓討論產品變得更快。
也因為畫面出來得太快，很多人會在這個階段停下來，誤以為產品已經差不多完成。對我來說，demo 的完成度和產品的完成度，本來就是兩件不同的事。真正稀缺的，是在畫面產出之後，讓它變成可上線、可維運、可承擔真實服務的能力。
如果你的目標只是做一個展示頁、活動頁，AI 現在確實很好用。可是一旦目標變成「要給真實使用者使用」「要接真資料」「要有人持續維護」，問題就不再只是畫面做不做得出來，而是整個系統能不能穩定活下去。
TL;DR
- AI 讓 demo 變得更快，但 demo 的完成度從來不等於產品的完成度。
- 真正稀缺的能力，往往藏在畫面之後的資料、權限、錯誤處理、部署與維護。
- vibe coding 很適合做驗證、提案與低風險雛形，但只要要接真實使用者與真資料，就不能跳過工程判斷。
為什麼 demo 變得這麼快？
因為 AI 很擅長幫人跨過最容易看見的那一段。
文案、版型、配色、區塊結構、按鈕互動、表單外觀、假資料卡片，這些東西現在都可以很快被生成。對介紹頁尤其明顯，因為介紹頁的成功條件通常很直觀：好不好看、像不像樣、能不能快速傳達一個概念。
這就是為什麼很多人第一次接觸所謂的 vibe coding，會感覺很震撼。以前要花幾天甚至幾週才看得到雛形，現在幾個來回就有畫面。這種速度本身就有價值。它很適合拿來做方向驗證、提案溝通、概念展示，也很適合把腦中的模糊想法先拉到桌面上。
問題不在這裡。問題在於，很多人把「畫面很快做出來」直接等同於「產品快做完了」。中間那段真正影響上線與維護的工作，反而最容易被忽略。
畫面完成之後，服務才剛開始
展示型 demo 和可上線服務，看起來都像一個網站，實際上承受的是兩種完全不同的壓力。
| 面向 | 展示型 demo | 可上線服務 |
|---|---|---|
| 資料 | 假資料或手動填資料即可 | 要處理真實資料來源、一致性與更新 |
| 使用者 | 通常只有展示者自己操作 | 要處理不同角色、權限與操作邊界 |
| 錯誤 | 大多可以忽略或手動重整 | 要面對逾時、失敗、重試、例外情境 |
| 部署 | 能打開就好 | 要考慮環境、版本、回滾與穩定性 |
| 維護 | 改一次就結束 | 需求會變、服務會壞、資料會長大 |
| 成本 | 多半只算開發時間 | 要一起算維護、監控、溝通與風險成本 |
這也是很多 AI 作品會給人一種「幾乎完成」的錯覺。因為最容易被看見的部分，恰好也是現在最容易被快速生成的部分。可是真正讓服務站得住的，通常都藏在畫面背後。
從 demo 到可上線，中間至少還有哪幾層？
如果今天有人拿一個 demo 給我看，我腦中通常會立刻往下追這幾層。這幾層沒有被說清楚，我不會把它當成接近完成的產品。
- 問題定義與邊界：
這個東西到底要服務誰？要解決哪一段工作？哪些情境不處理？很多 demo 之所以看起來很順，是因為它只走了一條最漂亮的路徑。 - 資料結構與單一事實來源：
資料從哪裡來？誰能改？改了之後哪裡會同步？只要牽涉真資料，資料模型與欄位設計就會立刻變成核心問題。 - 身份、權限與操作邊界：
誰可以看、誰可以改、誰可以刪、誰只能審核？這層沒有設計，系統就很容易在真實使用時出事。 - 錯誤處理與例外流程：
API 失敗怎麼辦？表單送出一半怎麼辦？資料格式不對怎麼辦？人類世界充滿例外，demo 通常只展示順利成功的那一刻。 - 部署、監控與回滾：
誰負責上線？出了問題怎麼知道？要回退到哪一版？一個服務真正上線之後，工程工作會從「把它做出來」切換成「讓它持續可用」。 - 維護責任與變更成本：
三個月後需求改了，誰來改？接外部服務的 token 過期了，誰處理？同一段功能要不要重寫三次？產品一旦進到真實世界，變動是常態。
你會發現，這些問題和畫面本身的關係其實不大。它們更接近系統設計、風險預判、責任分工與長期維護。也正是在這些層面，軟體工程經驗開始拉開差距。
vibe coding 有沒有價值？有，而且很高
我並不反對 vibe coding。相反地，我覺得它很有價值。只是它的價值要放在對的位置。
- 它很適合做概念驗證：先確認想法能不能被看懂，方向值不值得走。
- 它很適合做提案溝通：比起只講抽象需求，有畫面更容易對齊理解。
- 它很適合做低風險內部工具雛形：先拿來驗證流程，再決定要不要正式工程化。
- 它很適合做行銷型頁面：介紹頁、活動頁、展示頁本來就比較接近它的強項。
所以我不會把它當成假的能力。我只會提醒，這項能力主要解決的是「把東西快速做得看得見」。如果下一步是上線提供服務，那就要開始切換成另一套判斷標準。
怎麼判斷你手上的東西還是 demo，還是已經接近產品？
我會先問下面五個問題。只要有幾題答不清楚，通常就還在 demo 階段。
- 資料從哪裡來？
如果資料還是手貼、手改、手補，代表真實流程還沒開始。 - 有哪些角色？
如果還沒定義誰能做什麼，權限設計就還沒開始。 - 失敗時會發生什麼事？
一個系統的成熟度，常常不是看成功畫面，而是看它失敗時怎麼處理。 - 上線後誰負責？
沒有維護責任人，很多東西只會停在「現在可以用」。 - 需求一改，影響範圍有多大？
如果改一個欄位就牽動一整串功能，結構通常還不夠穩。
這五題的作用很簡單。它們會逼你從「畫面做出來了沒」轉到「這個東西能不能承受真實使用」。前者是展示問題，後者才是產品問題。
軟體工程經驗的價值，常常在這裡才看得出來
很多人在 demo 階段會低估工程師的價值，因為這個階段最顯眼的是畫面、互動和速度。AI 現在正好把這幾件事做得很亮眼，所以錯覺會更強。
可是一旦要接真實服務，工程經驗的重要性就會立刻浮出來。它體現在需求怎麼收斂、資料怎麼設計、例外怎麼處理、風險怎麼先關起來、部署怎麼不把整站弄壞、未來怎麼讓第二個人接得下去。
這些工作不一定華麗，也很少出現在 demo 影片裡。可是真正讓產品活下來的，往往就是這一層。你可以把它理解成一種把不確定性往下壓的能力。畫面能不能做出來，現在越來越不是最大門檻。真正難的，是讓一個系統在現實世界裡持續運作。
對企業端、顧問型事業、團隊協作型工作尤其如此。因為一旦進到多人使用、多人交接、多人依賴，系統就不只是在服務一個想法，而是在承擔流程、責任與成本。
如果你只是做介紹頁，需要想這麼多嗎？
不一定。
如果你的目標很清楚，就是做一個純展示型頁面、活動資訊頁、品牌介紹頁，那複雜度本來就會低很多。這時候 AI 的確可以幫你省下大量前端與排版時間。
可是一旦頁面開始承接表單、會員、付款、預約、資料查詢、通知或後台管理，它就不再只是介紹頁。它已經開始碰到服務層。從這個節點往後，工程思維就不能缺席。
內部工具也需要這種判斷嗎？
需要，而且常常更需要。
很多內部工具一開始看起來風險不高，所以大家會放鬆標準。可是一旦它接到真資料、參與決策、影響日常工作，風險其實不比對外系統小多少。差別只在於，對外錯了是客戶抱怨，對內錯了是流程失真、資料錯置、責任不清。
所以內部工具可以先用 AI 很快做出雛形，但在變成日常工具之前，還是要補資料、權限、驗證與維護這幾層。這和對外產品沒有本質上的差別。
如果我手上只有一個想法，該先找 AI 做 demo，還是先找工程師談？
這兩件事不衝突。
如果你的需求還很模糊，先用 AI 做出一個能討論的畫面，通常很有效。它可以幫你更快把想法說清楚，也讓你更早發現自己其實還沒定義的地方。
但只要你準備往真實資料、真實使用者、真實服務前進，最好就要讓有工程經驗的人一起進來看。因為這時候討論的重點，已經從畫面延伸到資料、流程、權限、錯誤與維護。這些層面越早釐清，後面返工越少。
結語
AI 改變的是把東西做得看得見的速度，沒有順手把可靠性、治理與維護一起解決。介紹頁、展示頁、互動雛形會越來越容易，這是好事。它讓更多想法有機會被快速看見，也讓前期驗證變得便宜。
真正的挑戰還在後面。當一個畫面要開始承接真資料、真使用者與真實責任，工程問題就會完整浮上來。這也是我會一直把焦點放在工作流程、驗證機制與可維護性上的原因。因為一個東西能不能展示，和它能不能提供服務，從來都不是同一件事。
如果你正在評估手上的 AI demo 到底該不該繼續往下做，先不要急著加功能。先把資料、權限、例外處理、部署與維護責任畫出來。那張圖，通常比新加三個漂亮區塊更接近產品現實。
發佈留言