ERP vibe coding 可以嗎？帳務別自己寫，ERP 之上那一層才是 AI 寫程式的地方
先給結論：ERP vibe coding 可以用在哪裡、不能用在哪裡
ERP vibe coding 的答案分兩半：會計帳、庫存、任何會影響金額的計算，不能用不看程式碼的方式做，也不該自己寫一套 ERP 來取代既有系統；ERP 之上那一層，像報價、缺料試算、訂單履行的編排，可以 AI 協作開發，而且是 AI 寫程式最划算的地方。前提有五個：TO-BE 流程先寫成規格、金額純規則、動作有白名單、每一步留稽核、生效經人確認。
這個立場來自實際使用。依潤謙官網的團隊頁（2026-10-23 查證），潤謙創辦人 Ernie 從 2026 年 4 月起也是 Claude Code 中文社群的創辦人，成員 6,000 多人；我們每天用 AI 寫程式，所以不會告訴你 AI 寫程式不可靠。正因為它真的快，界線才要畫清楚。
這篇會回答四件事：
- AI 寫的程式有多可靠，開發者自己怎麼看，安全研究測到什麼。
- 一次 AI 代理刪掉正式資料庫的事故教了什麼，為什麼教訓是加護欄，禁用解決不了問題。
- 自己開發 ERP、購買 ERP、在既有 ERP 之上加一層，三條路差在哪。
- 台灣的商業會計法與電子會計辦法怎麼規定帳本，為什麼帳本層不能是丟棄式原型。
vibe coding 是什麼，2025 年發生了什麼
氛圍編碼（vibe coding）這個詞由 Andrej Karpathy 在 2025 年 2 月提出，原意是完全交給 AI、不讀它寫的程式碼，連程式碼存在這件事都忘掉；他自己說這種做法用在丟棄式的週末專案還不錯。Simon Willison 在同年 3 月把定義收緊成一句話：
「When I talk about vibe coding I mean building software with an LLM without reviewing the code it writes.」
資料來源：Simon Willison：Not all AI-assisted programming is vibe coding
Willison 同一篇文章把界線講得很清楚：如果 AI 寫了程式，你讀過、測過、能向別人解釋它怎麼運作，那就是軟體開發，用不用 AI 無關緊要。這篇講的「ERP 之上那一層可以 AI 協作開發」，指的是後者；「帳務別 vibe」，指的是前者。
這個詞在一年內走完了從一則貼文到年度詞的路，中間還夾了一次事故：
| 時間 | 事件 | 出處（2026-10-23 查證） |
|---|---|---|
| 2025 年 2 月 | Karpathy 提出 vibe coding 一詞 | Willison 的文章、Wikipedia |
| 2025 年 3 月 | Merriam-Webster 把它列為「slang & trending」 | Wikipedia |
| 2025 年 7 月 | 一個 AI 代理在程式碼凍結期間刪掉正式資料庫 | Fortune |
| 2025 年 | Collins English Dictionary 選為年度詞 | Wikipedia |
依 Wikipedia 的 vibe coding 條目（2026-10-23 查證），Willison 對 Ars Technica 說過，用 vibe coding 一路做成正式環境的程式碼風險很明顯，因為軟體工程的多數工作是在演進既有系統，程式碼的品質與可理解性是關鍵。
證據：AI 寫的程式有多可靠
先看寫程式的人自己怎麼說。依 Stack Overflow 2025 年開發者調查的 AI 章節（2026-10-23 查證），84% 的受訪者正在用或計畫用 AI 工具，51% 的專業開發者每天用；但對 AI 工具輸出的準確度，主動不信任的比信任的多。
同一份調查裡，66% 的開發者說最大的挫折是 AI 給的解法「差一點點對」，45% 說除錯 AI 寫的程式碼更花時間；72% 的受訪者說 vibe coding 不是他們專業開發流程的一部分。每天用、但不太信、而且會自己檢查，這是專業開發者的常態。
安全面的數字更直接。依 Veracode 2025 年 7 月的新聞稿（2026-10-23 查證），他們用 80 個程式任務測了 100 多個模型，45% 的案例引入了安全漏洞，而且安全表現沒有隨模型進步而改善，較大的模型也沒有明顯比較好。放到 ERP 的語境，這些程式碼碰的是帳、庫存與客戶資料，漏洞率要用這個標準來看。
一次真實事故：AI 代理刪掉正式資料庫
2025 年 7 月的一個案例把風險講得比任何研究都具體。依 Fortune 的報導（2026-10-23 查證），一位創業者用 Replit 的 AI 代理做實驗，代理在程式碼與動作凍結期間刪掉了正式資料庫，裡面是 1,200 多位高階主管與 1,190 多家公司的資料；被追問時，代理承認執行了未授權的指令、在查詢回傳空值時慌了、違反了「未經人核准不得行動」的明確指示。它還一度告訴當事人回滾不會有用，當事人自己手動把資料救了回來。
Replit 執行長的回應是這件事不可接受、本來就不該發生，並列出三項補救。每一項都對應到一條護欄，這也是為什麼這篇的結論是加護欄，禁用解決不了問題：
- 開發與正式資料庫自動分離，對應「AI 碰得到的環境與帳本所在的環境要分開」。
- 回滾系統改進，對應「每一個會動到資料的動作都要能退回」。
- 僅規劃模式讓人跟 AI 先討論再動手，對應「生效之前經人確認」。
自建、購買，還是在既有 ERP 之上加一層
ERP 自建還是購買，這個問題常常問錯了，因為它漏掉第三條路。自己開發 ERP、用 AI 做 ERP、購買 ERP，差別在帳務放哪、誰維護、出錯時怎麼辦。
| 做法 | 適合什麼 | 帳務放哪 | 誰維護 | 出錯時怎麼辦 |
|---|---|---|---|---|
| 自己開發 ERP | 有自己的工程團隊，而且願意長期維護帳本層的公司 | 自己寫的帳本程式裡 | 寫它的那個人，或那段對話 | 沒有廠商可找，稽核軌跡要自己建 |
| 購買 ERP | 需要可稽核、有人維護的記錄系統 | 原廠或導入商維護的系統裡 | 原廠、導入商 | 有合約、有升級、有備份 |
| 既有 ERP 之上加一層 | 主檔與財會還可靠，痛點在報價、出貨判斷、缺料 | 留在既有 ERP | 編排層的規則由客戶與潤謙一起定 | 編排層拿掉，ERP 照舊 |
已經有一套用很久的 ERP、主檔與財會還可靠的公司，答案通常是第三條：疊在上面不取代，判斷條件在 Odoo ERP 導入指南裡有完整版本。帳本留在有人維護、可稽核的系統裡，AI 寫的程式只碰上面那一層。這一層放在哪裡、吃進去什麼交出什麼，另一篇講 ERP 流程編排時已經攤開，這篇只講它為什麼適合 AI。
ERP 之上那一層為什麼適合 AI 協作開發
三個理由：薄、規格清楚、錯了擋得住。薄，是因為一條報價流程只有幾個步驟，每一步的輸入輸出都數得出來，AI 產初稿的範圍小、人審得完。規格清楚，是因為這一層照 TO-BE 流程蓋，步驟、誰做、輸入、規則、輸出、例外時怎麼辦寫成一張表就是規格，AI 照表寫，不用猜。錯了擋得住，是因為會影響金額的計算全部是規則、生效要經人確認，AI 寫錯的程式碼在簽核那一關會被看到。
TO-BE 流程寫成規格的長相。表中為範例資料，欄位與文字皆為本文自行編製；AI 照這張表產初稿，例外欄決定它什麼時候停下來等人。
規格從哪裡來？從盤出來的實際流程。潤謙用自己的流程智慧平台 Reefian 做這件事：把訪談與 ERP 等系統資料還原成泳道流程圖與 SIPOC 表，缺口清單排出先解順序，再打包成開發脈絡包交給開發端，TO-BE 流程就是規格。流程與資料基礎要先於 AI，這個順序在智慧製造藍圖那篇講得更完整。
節點與它的 SIPOC：左側是泳道流程圖，右側是選取節點的供應者、輸入、流程、輸出、客戶。畫面是潤謙內部的流程稿，左側的泳道名稱已裁去。
顧問公司在財務領域畫的是同一條線。依 BCG 2026 年的文章（2026-10-23 查證），AI 寫的客製應用是加在上面的一層，可靠性來自把計算放進規則型的程式碼、在受控的環境裡執行，產生財報的流程留在核心系統：
「They do not replace the system of record; instead, they sit on top of it and make the data and insights more accessible, usable, and easier to interpret.」
資料來源：BCG：Vibe Coding Is Coming to Finance. CFOs Need Guardrails
依 Verde 談 vibe coding 與 ERP 的文章（2026-10-23 查證），原則是「Build on top of your ERP, not around it.」：核心商業邏輯、財務資料、法遵流程、系統整合是紅區；讀 ERP 資料然後把有用的東西呈現出來的工具是延伸，自己存一份資料、複製 ERP 已有內容的工具是等著出事的影子 IT。用他們的話說，AI 寫 ERP 的替代品是一個有漂亮前端的負債。
護欄清單：少了任何一條就不要上線
判斷一段 AI 協作開發的程式能不能上線，看六條，少一條就先不要：
- TO-BE 流程先寫成規格，步驟、誰做、輸入、規則、輸出、例外都在表上，AI 照表寫，沒有規格的功能不做。
- 會影響金額的計算全部是純規則，AI 不碰；查不到匯率或稅率直接停下來，不靜默回 0。
- 動作有白名單，每個動作標明影響不影響金額、生效前由誰確認；影響金額的一律人簽核。
- 每一步留稽核紀錄，誰、什麼時候、把哪個值改成什麼，查得出來。
- 生效之前經人確認，而且可以退回，寫回 ERP 失敗要保留原稿。
- 登入權限、測試、備份、版本控制這些被省掉的工程基礎補回來；BCG 把版本控制、資料存取、可稽核性列為財務部門用 AI 寫程式的護欄，影子程式碼跟影子 Excel 一樣危險。
白名單動作表的長相。表中為範例資料，欄位與文字皆為本文自行編製；會影響金額的動作一律純規則計算、人簽核，AI 只碰不影響金額的那幾列。
這六條跟採購判準是同一套邏輯：資料是不是你的、know-how 能不能流程化，傳產數位轉型護城河那篇講的三個判準在這裡照樣適用。做法照順序走，AI 只在第三步寫程式，前後都是人：
- 盤流程產 TO-BE
訪談與 ERP 紀錄還原成泳道圖與 SIPOC - 定規則與白名單
金額純規則，動作標明誰確認 - AI 產初稿
照規格寫，範圍只在這一層 - 人審與測試
讀過、測過、能解釋給別人聽 - 小範圍試跑
用自己的資料，與正式環境分離 - 經人確認後寫回
可退回，寫回失敗保留原稿
台灣的硬錨點：帳本為什麼不能是丟棄式原型
Karpathy 原本設想的 vibe coding 用在丟棄式的週末專案，帳本正好相反，法規要求它真實、要保存、要有人負責。依法務部法規資料庫的商業會計法（2026-10-23 查證），第 33 條這樣規定：
「非根據真實事項，不得造具任何會計憑證，並不得在會計帳簿表冊作任何記錄。」
資料來源：全國法規資料庫：商業會計法
同一部法的第 38 條規定各項會計憑證在年度決算程序辦理終了後至少保存五年，會計帳簿及財務報表至少保存十年；第 72 條規定使用電子方式處理會計資料的商業，相關人員故意登錄或輸入不實資料等情事，處五年以下有期徒刑、拘役或科或併科新臺幣六十萬元以下罰金。這篇不做法律解釋，只指出一件事：一段沒人讀過、沒有設計文件、邏輯活在一段對話裡的程式，碰到「保存十年」「誰輸入的」這兩個要求就站不住。
商業使用電子方式處理會計資料辦法第 3 條（2026-10-23 查證）把要求寫得更具體：使用電子方式處理會計資料應建立內部控制，並以書面規範五件事。每一件對 AI 寫程式都有直接的意思：
| 辦法第 3 條的要求 | 對 AI 寫程式的意思 |
|---|---|
| 組織適切分工 | 寫程式的、確認的、簽核的分開；AI 產初稿，人審、人簽 |
| 會計軟體及資料檔案使用權限之管理監督 | AI 代理的權限只到它負責的那一層，碰不到帳本資料庫 |
| 會計軟體變更之授權與監督 | AI 改的每一版程式要有人授權、有版本控制 |
| 會計資料輸入、處理及輸出之核驗 | 金額純規則，輸入輸出有人核驗，不靜默回 0 |
| 資料備份之儲存及維護 | 開發與正式環境分離，可回滾，備份有人維護 |
帳本層滿足這五件事的方式，是留在有人維護、可稽核的系統裡；上面那一層滿足這五件事的方式，是護欄清單。兩層的做法不同，法規的要求是同一套。哪一段流程值得做成 AI 代理或自動化，先盤流程再決定，潤謙的 AI 解決方案頁講的就是這個順序。
常見問題
ERP 可以 vibe coding 嗎？
核心帳務不行，ERP 之上那一層可以 AI 協作開發，前提是 TO-BE 流程寫成規格、金額純規則、動作白名單、每一步留稽核、生效經人確認。vibe coding 的定義是不看程式碼就把軟體做出來；會計帳、庫存與影響金額的計算在商業會計法的要求下不能這樣做。
自己開發 ERP 划算嗎？
會計、庫存、任何影響金額的計算放在有人維護、可稽核的既有 ERP 裡，自己開發的應該是 ERP 之上那一層。自建、購買、加一層三條路的差別在帳務放哪、誰維護、出錯時怎麼辦；主檔與財會還可靠的公司通常不用換系統，ERP 自建這條路要有自己的工程團隊而且願意長期維護帳本層。
AI 寫的程式可靠嗎？
開發者自己不信任的比信任的多：Stack Overflow 2025 年的調查裡 46% 不信任 AI 工具輸出的準確度、33% 信任、3% 高度信任；Veracode 用 80 個任務測 100 多個模型，45% 的案例引入安全漏洞（2026-10-23 查證）。可靠性來自把計算放進規則與受控環境、人審與測試，模型本身給不了。
AI 代理會不會把資料弄壞？
會。2025 年 7 月就有 AI 代理在程式碼凍結期間刪掉正式資料庫的事故，當事人手動才把資料救回來。教訓是護欄：開發與正式環境分離、每個動作可回滾、先規劃再動手、動作有白名單、生效經人確認。
用 AI 寫 ERP 之上那一層，要先準備什麼？
先把那一段的實際流程攤開，寫成 TO-BE 規格：步驟、誰做、輸入、規則、輸出、例外時怎麼辦，再決定哪些動作 AI 可以碰。訪談與 ERP 紀錄還原成泳道圖與 SIPOC、缺口清單、開發脈絡包，這是 Reefian 交出來的東西；六步從盤流程走到經人確認後寫回。
下一步
如果你已經有一段流程想讓 AI 幫忙寫，卻說不清楚它的規則、例外與誰來簽核，那一段還沒準備好交給 AI。潤謙可以先陪你把那一段攤開成 TO-BE 規格，分出哪些動作 AI 可以碰、哪些要留在 ERP 與人手上，約一次談話從最花人的那一段開始。