有次在星巴克,鄰桌坐著幾位從新加坡來台灣找機會的軟體工程師,正和一位台灣的技術主管熱烈地聊著。
他們興奮地討論一件事:既然現在用 AI 協同開發,能大幅加快寫程式的速度,而 ERP 又是每家公司都用得到的系統——那有沒有可能,乾脆「vibe」出一套 ERP?
我在一旁聽著,心裡浮現的卻是另一個念頭:他們興奮的是「開發速度」,但 ERP 真正的瓶頸,從來就不在程式碼。
能。一個週末,你就能 vibe 出一套會動的進銷存。
但它過不了會計師那一關——而過不了那一關,就不算數。
我自己做 Oracle ERP 導入,讓我說清楚:這件事真正的難處,從來不是寫程式。
🧱 第一道牆|你交付的是程式,會計師審的是「可信的廠商」
每一位查核會計師心裡,都有一張清單,定義什麼叫「一套可靠的 ERP」:產品開發有沒有規範、有沒有跟上最新的 IFRS、符不符合資安要求、能不能持續更新與維護。
這些不是功能,而是一張「可信任廠商」的入場券——大廠花了數十年,買的就是這張票。
而 ERP 真正扛起的,是整份財報最源頭的任務:把一張一張原始憑證收進來、留存、串成一條可被查核的軌跡。財報,就長在這之上。
換句話說,你的成品得先通過會計師那張清單,才談得上「做出一套 ERP」。
🧱 第二道牆|大廠賣的不是軟體,是被驗證過數十年的「最佳實踐」
SAP 與 Oracle 的 Best Practice 模板,並不是工程師憑空寫出來的,而是產品走過數十年,在嚴酷的商業、法律與財務環境中反覆檢驗,才長出來的最佳路徑。它本身就像一位企業管理顧問,告訴你每一個流程該怎麼走才對。
而 vibe coding 的本質,是順著感覺——「覺得這樣可行」就動手。
大廠賣的,恰恰是「覺得可行」的相反:被市場、法律與財務一再驗證過的「這樣做才對」。
這兩者之間的距離,就是數十年。
🤖 更關鍵的問題|拿著 AI 的,是誰?
先把名詞分清楚。工程師借助 LLM 一起開發,但仍親自掌握架構、審查每一段產出,這叫「LLM 協同開發」,是一種專業實作;而真正的 vibe coding,是順著感覺、幾乎不讀程式就接受結果。兩者相去甚遠。
但關鍵在於:即便是最嚴謹的 LLM 協同開發,只要少了領域專家,結果仍會出問題。AI 拿掉的是「打字」的成本,卻拿不掉「你得知道要做什麼」的成本。工程師能把看得見的八成做出來——訂單、開票、庫存;卻會漏掉那讓它「成為 ERP」、而非「華麗試算表」的關鍵兩成:期末結帳、外幣重評、審計軌跡、職責分離、集團內沖銷。
而 AI 不會主動提醒你漏了什麼。你沒問,它就不說。於是你得到一個會 demo、能編譯、看起來完整,實則「自信地不完整」的產物。
反過來,若拿著 AI 的是懂業務的人(會計師、ERP 顧問),情況就好得多。規格本就在你腦中,你清楚邊際案例、知道「對」長什麼樣子,也能驗證 AI 的產出——而這正是最稀缺、AI 又最補不上的那塊輸入。
但話別說得太滿。一套好的軟體產品,不只需要正確的財務邏輯,還需要妥善的資安規範、規劃得宜的 API 與擴充機制、撐得住的架構,以及能長期維護的底子——這些都不是財務或會計單一職能規劃得來的。
產品,終究靠的是一個團隊,而不是一種職能。
所以真正的解方,不是「專家取代工程師」,而是「AI 讓一支更精簡的跨職能團隊,做到過去做不到的事」——並把領域判斷,從事後外掛,變成團隊裡不可或缺的核心。
🔑 一句判準
這項產品的輸出,需不需要被第三方——查核會計師、主管機關、稅局——所信任?
需要 → 你就避不開領域專家,也避不開那整套廠商信任機制(這正是綁著 IPO、上市櫃的公司,幾乎只敢用大廠的原因)。
不需要、純粹是內部營運的便利 → 那麼工程師加上 AI 的工具,就綽綽有餘。
🏆 那大廠會被掀掉嗎?
短期內並不容易。事實上,AI 更可能鞏固大廠,而非顛覆。手握資料、最佳實踐模板與既有信任的人,正是最有本錢把 AI 吃進自家產品的那一群;這個產業也和許多產業一樣,頭部廠商早已賺走了大半市場。
真要有破口,會從下方來——大廠嫌太小、服務不周的極小企業與利基垂直市場。而那把鑰匙,握在懂業務的人手上,不在只懂技術的人手上。
💡 回到星巴克那一桌
他們把 ERP 想像成一堆 CRUD 的堆疊,以為只要加快開發速度,問題就迎刃而解。
但 ERP 的門檻從來不是程式碼,而是那張會計師的清單、那數十年的最佳實踐,以及「由誰來扛對錯」這件事。
AI 真正改變的,是把這一切的重心,從「會寫程式的人」,移向「懂業務、扛得起對錯的人」。
AI 越會寫程式,「懂業務、又扛得起對錯」的人,就越值錢。