AI 還不會取代軟體（至少目前還是如此）

2026 年初，軟體類股股價大幅下跌，市場開始出現一種聲音：AI 會不會取代傳統軟體？我們也看到大量案例，展示 AI 能以過去難以想像的速度生成軟體。

這就是未來嗎？每個人都能隨時依需求生成自己需要的軟體？或者，乾脆直接叫 AI 完成原本由軟體處理的工作？

AI 寫程式帶來的興奮感

我有 25 年的軟體開發經驗。今年這一波 AI 寫程式工具，例如 Claude Code，讓我著迷了好一陣子。我喜歡開發軟體、創造新東西；對我來說，AI 寫程式就像電腦遊戲和手機遊戲一樣讓人上癮。除了 Ragic 的工作之外，我也為了好玩、測試 AI 寫程式的能力，開始做了不少個人小專案。我甚至和我 14 歲和 12 歲的兩個小孩（都不會寫程式）一起用 AI 開發遊戲，當作一項有趣的實驗。我也想藉此了解，vibe coding 對非開發者而言究竟有多實用。

我們根據一部年代久遠的小說，做了一款相當復古、類似《勇者鬥惡龍》的網頁 RPG（這樣就沒有版權問題，而且已有完整的故事背景）。我們完全把自己當作不懂程式的人，完全不看 AI 產生的程式碼，只負責測試，然後告訴 AI 想增加哪些功能、哪些地方需要修正。

才過 15 分鐘，我們就有了一款包含好幾個畫面的遊戲，可以四處走動、跟 NPC 對話、查看道具，甚至打開寶箱！真的很酷，也讓人很興奮。就像每次 vibe coding 一樣，做出這麼酷的東西，總會想立刻分享給其他人。

Vibe Coding 過程中浮現的問題

很自然地會想：「15 分鐘就能做到這樣，那再花個幾天，還能做出什麼？」於是，我們開始加入更多地圖、戰鬥系統、升級系統、物品欄系統與技能系統。遊戲很快就越來越像一款完整的 RPG。

剛開始，我們請 AI 修正某個問題時，通常很快就能完成，而且第一次就能修好。但隨著我們加入更多地點、NPC 和不同模組，漸漸發現 AI 修正問題需要的時間越來越長，而且常常沒辦法一次修對。

我們開始請 AI 建立自動化測試系統，讓它能不斷循環測試遊戲、修正問題，直到確認問題已經解決。但 AI 花在修正問題上的時間越來越長（消耗的 token 也多了很多！），卻還是經常修不好。最糟的是，修好了問題 A，問題 B 就冒出來；修好了問題 B，問題 A 和 C 又跑出來！簡直像在打地鼠！

檢視 AI 產生的程式碼

這實在太挫折了，我決定自己進去看看程式碼，看到底出了什麼問題。我發現 ... AI 產生的程式碼有一些重大、結構性的設計問題。舉例來說，玩家會透過一連串地點在遊戲世界裡移動。當玩家從地點 A 的右側離開，就會出現在下一個地點 B 的左側；如果再從地點 B 左側往回走，就應該出現在地點 A 的右側。這很符合直覺，而且一開始確實運作正常。

不過，隨著地點增加，這個機制開始出錯；當地點數超過 100 個，要確保每個地點之間的連接都正確，就變得非常困難。查看程式碼後，我發現：每張地圖都分別設定了出口的位置，以及各個出口通往哪張地圖。但玩家進入新地圖後，應該出現在哪個位置，卻又是另外獨立設定的。這樣的設計其實很容易出問題，也很難維護。因為每次新增地圖，都必須確保其他相關地圖的設定同步更新，才能讓整個遊戲的邏輯保持一致。

有經驗的開發者如果從一開始就掌握系統全貌，就會採取不同的設計方式。他們會讓地圖的出口，以及玩家進入地圖時的出現位置，都能透過程式規則自動判定（例如採用網格系統 grid system），而不是分別設定。

這類問題必須在開發初期就處理好，否則隨著系統越來越龐大，就會與其他數百個類似問題相互牽連，變得越來越難解決。等到程式碼規模大到連個別模組都無法完整放進 AI 的上下文視窗（context window）時，即使是 AI，也很難再有效管理整個系統。

我這才恍然大悟：「喔！這就是優秀的軟體架構師和軟體管理者在做的事。」他們了解整體全貌，再據此規劃、建構系統，讓系統容易管理，並減少重複的程式碼，以避免這類問題。

為什麼 AI 還不會取代軟體

AI 能做出這樣的設計嗎？當然可以！但 AI 能不能在與一個完全沒有軟體開發經驗的人合作時，也建立出好的軟體架構？這才是讓我開始存疑的地方。而且看起來，這個問題短期內並不容易解決。

AI 確實能輕鬆做出很好的設計、遵循最佳實務，但如果盲目照單全收每一條最佳實務，就會做出龐大、過度工程（over-engineered）的軟體，反而形成另一個更大的問題。畢竟，蓋一棟房子不需要每次都打摩天大樓等級的地基。

真正可行的方向，是某種護欄機制：提供一個平台，讓非開發者能反覆描述、調整需求，而不必擔心系統「怎麼」實作。AI 寫程式對有經驗的開發者仍然非常好用，但對非開發者來說，如果要建立的不是簡單的小專案，而是預計使用、維護多年的系統，這樣的護欄就極有幫助。AI 讓建立複雜系統變得便宜，但「維護」本身仍然昂貴。

同樣的問題在企業資訊系統裡可能更加嚴重，因為業務邏輯同樣複雜（甚至更複雜），而軟體出錯的後果也更嚴重——尤其涉及資料安全、法規遵循以及金流交易時。若一開始沒有仔細向 AI 說明系統全貌，先前遊戲設計遇到的問題，就會隨著應用系統的發展不斷浮現。沒有專業軟體架構師參與的 AI 開發，往往會在專案規模成長到某個程度時碰到瓶頸。遲早會撞牆，維護成本也會越來越高。AI 並沒有辦法神奇地修好龐大的程式碼庫。

No-Code 如何成為 AI 的護欄

這正是「No-Code（無程式碼）」應用想要解決的問題。應該讓非開發者能只描述「業務邏輯」，完全不需要做任何軟體架構或技術實作決策——不只不用寫程式，也不需要討論技術細節。No-Code 工具應該針對使用者想建立的應用類型來設計，例如 CRM、專案管理系統、ERP 等「資料庫應用系統」。

這就是像 Ragic 這樣的 No-Code 工具能發揮作用的地方。當企業使用者在 Ragic 上描述自己的應用系統應該做什麼時，只需要說明銷售流程如何運作，或專案如何管理，而不需要解釋資料要如何儲存、存在哪個資料庫裡。

在 Ragic 這類 No-Code 工具中，透過 AI 輔助建立系統時，不需要自行假設業務流程在技術上該如何實作。平台會將使用者需求直接轉換成系統設定，而不需要使用者做技術設計決策。No-Code 工具因此成為非開發者與 AI 設計系統時的護欄，不只能確保系統在技術上合理、安全、穩健，也能讓 UI/UX 保持一致、清楚——這件事對沒有開發背景、靠 vibe coding 建立系統的人來說，往往比想像中更難。

結果就是，即使透過 AI 持續開發、維護系統，系統也不會失控膨脹。同時，它也提供一定程度的透明度，讓使用者不必閱讀或理解程式碼，就能直接查看應用系統的設計。使用者可以透過 No-Code 工具完整掌握當前的業務邏輯，並在需要時不用寫程式，也能自行修改、維護系統。