從 Vibe Coding 風險治理
到 BI 實戰落地

先從一份國際研究報告談起。McKinsey 於 2026 年 8 月發表 《The State of AI in 2026: On the Road to ROI》，調查涵蓋全球 97 個國家、1,719 位受訪者。報告有一項數據，讓我特別有感。

這代表什麼？兩者背後的思維截然不同：

對中小企業而言，這是一個巨大的機會。因為很多部門真正需要的，不一定是功能龐大、價格昂貴的 ERP 或 BI 系統，而是一個能夠解決特定問題的小工具。

例如，HR 希望整合各部門的人力與加班資料，財務希望快速比較不同月份的營運數字，業務希望即時了解產品銷售表現。這些需求如果能透過 Vibe Coding 快速實現，確實可以降低開發門檻，讓企業更有能力回應內部需求。

不過，接下來才是真正的挑戰。

軟體開發的速度可以交給 AI，但軟體安全的責任，仍然必須由人承擔。

很多人第一次使用 AI Coding 工具，都會有一種驚喜：「哇！我只是描述一下需求，它竟然真的幫我把系統做出來了！」

但楊老師要提醒大家，畫面漂亮、功能正常、按鈕可以點擊，並不等於這個系統已經通過資安檢查。2026 年的多項研究，讓我們看見這個問題有多值得重視。

功能正確與資安安全，完全是兩回事

2026 年 9 月發表的研究 《SusVibes: Is Vibe Coding Safe?》，以真實開源專案中的歷史漏洞任務評估 AI Coding Agent。研究顯示，在特定測試條件下，即使 AI 成功產生功能正常的程式，仍有接近八成的解答未通過安全驗證。

另外，Veracode 的生成式 AI 程式碼安全研究也顯示，AI 在程式語法與功能生成方面已有相當高的能力，但安全測試仍有明顯落差。

這告訴我們一件很重要的事情：AI 非常擅長讓程式「看起來可以用」，卻不代表它能自動考慮所有安全邊界。當程式涉及登入驗證、不同使用者的資料存取、外部 API 或資料庫權限時，風險就可能被隱藏在正常運作的畫面背後。

從 Lovable 案例看見授權漏洞

2026 年初有一個資安案例非常經典，它來自許多初學者喜歡使用的 AI 架站平台 Lovable。

它的狀況是這樣的：2026 年 2 月，Lovable 的一次後端更新出現回歸錯誤，把原本已經關閉的權限又打開了。從 2 月 3 日到 4 月 20 日，只要是登入的 Lovable 使用者，拿到別人「公開專案」的連結，就能讀取對方的原始碼與完整的 AI 對話紀錄。很多人在跟 AI 對話時，會順手貼上資料庫金鑰、API Key，甚至客戶資料，這些內容也就跟著暴露。

更值得警惕的是，資安研究人員從 2 月 22 日起就陸續透過漏洞通報管道回報，卻因為內部文件仍把「公開專案的對話可見」寫成正常設計，通報被直接結案。一直到 4 月 20 日研究人員公開揭露，Lovable 才在兩小時內修正，並把現有的公開專案全部改為私人。

這讓我們要理解，這就是 BOLA（Broken Object Level Authorization，物件層級授權失效）：系統確認了「你是誰」，卻沒有檢查「這筆資料是不是你的」。它屬於「存取控制失效」，也就是 OWASP 網頁應用十大風險排名第一的類別；在 OWASP API Security Top 10 中，BOLA 更是直接高居第一（API1）。

放到企業內部系統來看，當員工登入公司內部系統時，系統允許他查看自己的資料。但如果員工只要修改網址或 API 參數，就能讀取其他員工的薪資、考績或個人資料，這代表系統雖然有登入機制，卻缺少必要的物件存取權限檢查。

「你有登入」不代表「你有權限看所有資料」。

這正是企業資訊系統非常重要的安全觀念。若系統使用 Supabase 等資料庫服務，就必須正確設計 RLS（Row Level Security，資料列級別安全性），讓資料庫依據使用者身分與權限，限制可以讀取或修改哪些資料。

除了授權漏洞，Vibe Coding 還有哪些常見風險？楊老師在課程中，特別介紹幾項與 OWASP、CWE 安全分類有關的問題。

第四項風險尤其值得注意。GitGuardian《State of Secrets Sprawl 2026》指出：

更值得警惕的是，研究追蹤部分過去已確認外洩的有效憑證，發現多年後仍有相當比例尚未撤銷。這表示企業面臨的問題，不只是金鑰可能外洩，更包括外洩之後，有沒有建立及時發現、撤銷與更新的管理制度。

再加上 AI Coding 工具經常自動引入第三方套件，企業還得面對軟體供應鏈的風險。所以，未來的程式開發不能只是確認功能是否正常，還必須知道：

談到軟體安全，就不能忽略 OWASP（Open Worldwide Application Security Project）。這是一個推動開放、安全軟體開發與應用程式安全最佳實務的國際非營利組織。

過去我們可能比較熟悉 OWASP Top 10 網頁應用程式安全風險，隨著生成式 AI 發展，相關安全討論也延伸到 LLM、API 與 AI Agent 等領域。

對企業而言，OWASP 最重要的價值，不只是列出十大風險，而是提供一個國際共通的安全語言，讓開發者、資訊人員、資安主管與企業經營者，可以站在共同架構上討論問題。

而其中有一項觀念，我認為非常適合運用在 Vibe Coding：

Secure by Design，安全始於設計。

傳統開發模式可能是在系統完成後才進行資安檢查。但 AI Coding 的速度太快，如果等到系統已經開發完成、資料也已經上傳，才開始思考安全問題，往往為時已晚。因此，企業應該在需求設計時，就先確認：

這些問題不是 AI 能自行決定的，而是企業管理與治理的責任。

講到這裡，可能有人會問：「楊老師，既然 Vibe Coding 有這麼多風險，那企業是不是乾脆禁止員工使用？」

我的看法是，企業真正需要的不是全面禁止，而是建立清楚的安全邊界與管理制度。因為員工使用 AI 的目的，往往是希望提升效率、解決問題。如果企業只禁止，卻沒有提供安全可行的替代方案，反而可能讓員工透過未經核准的工具私下開發，形成 Shadow IT（影子資訊系統）。

六個治理面向

這六項治理，涵蓋了從使用工具、處理資料、開發程式，到正式部署及持續營運的完整生命週期。

Vibe Coding 三級管理制度

但楊老師認為，企業也不需要所有應用都採取相同的審查強度。一個純前端、完全離線的計算工具，與一套連接 ERP、處理客戶個資的 AI Agent，不應該套用完全相同的管理標準。

風險越高，治理強度越高；風險可控，創新才有空間。這才是企業真正可持續的 AI 導入方式。

這次課程另一個重要觀念，是讓 AI 不只扮演開發者，也協助擔任安全檢查員。例如，使用 Claude Code 等 AI Coding 工具時，可以要求 AI 先檢視專案架構，評估適合執行哪些資安檢查，再提出風險與改善建議。

1. SASTStatic Application Security Testing
   靜態應用程式安全測試：不執行程式，直接從原始碼找出可能的漏洞。
2. SCASoftware Composition Analysis
   軟體組成分析：盤點用了哪些第三方套件，以及是否有已知弱點。
3. Secret Scanning機密憑證掃描
   找出被寫進程式碼或版本紀錄中的 API Key、Token 與密碼。
4. DASTDynamic Application Security Testing
   必要時進行動態應用程式安全測試：在程式執行狀態下，從外部模擬攻擊。

但這裡有兩個原則非常重要：

即使 AI 能協助完成初步安全檢查，也不能因此取代獨立的安全驗證，以及高風險系統所需的專業審查。AI 可以協助找出風險，但最終的責任與核准權，仍必須保留在人身上。

這就是 Human-in-the-Loop（人在決策迴路中）的重要性。

講完資安風險與企業治理，接下來才是我最希望學員真正帶回工作現場的部分：在安全邊界清楚的前提下，親手用 AI 做出能解決業務問題的工具。

這次我設計了一個中型科技製造企業的 HRM 人才運用分析案例。假設這家公司約有 120 名員工，隨著營運成長，各部門逐漸出現人力配置不均、加班增加及績效差異等問題。

HR 每個月都會整理員工資料、出勤工時及績效報表，但是資料分散在不同 Excel 檔案中。想要了解哪個部門缺人、哪個部門加班過多、哪些單位的人力效能需要改善，主管往往需要花很多時間交叉比對。

這時候，Vibe Coding 就能發揮價值。我們不一定要採購一套新的大型管理系統，而是可以利用現有資料，打造一套符合部門需求的互動式 BI 儀表板。不過，我刻意安排了一個與一般 AI Coding 課程不同的步驟：不是拿到 Excel 就直接上傳 AI，而是先處理資料安全。

這次使用的資料包括員工主檔、每月工時出勤、季度績效及部門編制等四個資料表。其中可能包含員工姓名、個人識別資訊，以及企業不適合直接提供給外部平台的內部營運數據。

因此，我先帶領學員使用 Gemini，透過自然語言開發一個可以在本地端執行的資料去識別化網頁工具。工具可針對不同欄位採取假名化、遮罩、泛化、數值調整或移除等方式，並盡可能保留後續分析需要的資料關聯。完成後，將網頁工具下載到電腦，在本地端開啟，再進行資料處理。

資料準備完成之後，接著進入 Vibe Coding 的核心。但我沒有讓學員直接對 AI 說：「幫我做一個漂亮的 BI 儀表板。」因為這樣的需求太模糊，AI 雖然可能做出好看的畫面，卻不一定能解決真正的管理問題。

我採用的是 Meta Prompting（後設提示設計）：先讓 AI 協助設計一份完整的開發提示詞，明確定義資料結構、KPI 計算、互動行為與呈現方式，再用這份規格產生應用程式。例如，我們希望儀表板能回答五個管理問題：

1. 人力配置
   哪些部門的在職人數低於核定編制？
2. 加班工時
   哪些部門的加班負荷偏高，是否持續增加？
3. 出勤異常
   遲到、早退或異常缺勤集中在哪些部門？
4. 績效表現
   各部門的績效評分與目標達成率有何差異？
5. 人力效能
   哪些部門同時面臨人力缺口、高加班與績效壓力？

當這些問題被定義清楚，AI 產生的程式才有機會真正支援管理決策。

接下來，利用 Vibe Coding 建立一頁式網頁分析工具。我特別要求設計互動式 KPI 圖卡。例如，主管點擊「平均加班時數」，不只是看到一個數字，而是可以進一步檢視部門比較、月度趨勢，甚至開啟明細視窗。這種設計背後，其實是一個很重要的 BI 觀念：

好的 BI 儀表板，不只是把 Excel 變成圖表，而是讓主管能夠從數據發現值得關注的問題。例如某部門的加班時數偏高，究竟是因為人力編制不足、工作量增加，還是流程效率需要改善？

儀表板可以協助提出線索，但不能單憑數據就認定原因。管理者仍需要結合現場情況、業務需求與專業判斷，才能做出適當決策。這也正是人機協作真正的價值。

經過這次課程，我希望學員帶回去的，不只是一個 HR BI 儀表板，也不只是學會操作 Gemini 或 Claude Code。我更希望大家建立一套完整的 AI 應用思維：

從工作問題出發，定義真正需要解決的管理需求；先確認資料分級與安全邊界，再利用 AI 協助設計與開發；完成工具之後，透過測試、驗證及人工審查，確保它能在適當的環境中安全使用。最後，讓工具產生的數據分析，真正轉化為企業的營運洞察與決策價值。

1. 對主管而言
   重要的不是自己會寫多少程式，而是能否提出正確的問題、定義需求，並判斷 AI 產出的結果是否可信。
2. 對員工而言
   重要的不只是操作工具，而是能否結合自己的專業知識，把每天重複處理的工作，轉變成可持續使用的數位應用。
3. 對企業管理者而言
   必須建立清楚的治理制度，讓創新不至於變成新的資安負擔。

AI 讓人人都有機會成為開發者，但不代表人人都可以跳過安全檢查。

這幾年，我在企業 AI 轉型輔導與人才培訓現場，看見越來越多非資訊背景的同仁，開始用 AI 解決實際工作問題。這是很令人期待的改變。

過去我們常說，數位轉型最大的困難在於技術門檻。但當 AI 正快速降低技術門檻時，另一項能力反而變得更加重要，那就是提出問題、建立規範、驗證成果，以及承擔責任的能力。

所以，企業推動 Vibe Coding，不能只追求「開發速度」，還必須同時建立「安全治理」與「業務價值」這兩條軌道。

我一直相信，真正有價值的 AI 應用，不是把人排除在流程之外，而是讓 AI 協助人完成以前不容易做到的事情。

文章中的國際研究與資安案例，可搭配以下原始資料延伸閱讀：

1. McKinsey — The State of AI in 202632% 企業改變軟體採購決策。
2. SusVibes — Is Vibe Coding Safe?AI Coding 功能正確與安全通過率的落差（proceedings.mlr.press）。
3. Veracode — GenAI Code Security Report 2026約 44% 測試任務產生存在已知安全漏洞的程式碼。
4. GitGuardian — State of Secrets Sprawl 2026機密憑證外洩的規模與持續風險。
5. Lovable — Our Response to the April 2026 Incident官方說明其公開專案存取漏洞的影響與修正。