Klaviyo 兩週做出 356 個內部 App：K:Forge 如何讓 512 名員工安全開發？
Klaviyo 讓 512 名員工在兩週部署 356 個內部 App。本文拆解 K:Forge 的三分鐘上線、安全護欄、80/20 分工與導入風險。
Klaviyo 與 Vercel 在 2026 年 9 月公開一個引人注意的企業案例：Klaviyo 建立內部平台 K:Forge，開放員工用自然語言製作 App。計畫開始後兩週，512 名員工部署 356 個 App，其中 196 個是有自己資料庫的 full-stack App。
Full-stack App 是同時包含使用者介面、伺服器邏輯和資料處理的完整應用程式，不只是單頁網站。比數字更值得研究的是，Klaviyo 沒有把安全檢查交給每一位新手自行設定。平台預先套用公司登入、私有網路、機密變數與安全掃描，讓 App 預設只能在內部使用。
這是 Vercel 的客戶案例，數字與「三分鐘上線」來自 Vercel 和 Klaviyo 的說法，沒有第三方獨立驗證。356 個已部署 App 也不等於 356 個都被長期使用、節省相同工時或進入正式核心流程。
我的判斷是謹慎偏多。K:Forge 示範了企業推動 citizen developer 的合理方向：把護欄做進平台，而不是只發一個 AI 工具給全公司。Citizen developer 指不是專職工程師，但能用低程式碼、AI 或範本製作工作應用的人。這套模式是否成功，還要看 App 的使用率、維護責任、退場機制與事故紀錄。
356 個 App 是怎麼來的？先看統計口徑
Vercel 官方案例表示，Klaviyo 有超過 2,000 名員工。K:Forge 的 citizen developer 計畫開放後兩週，共有 512 名 builder 部署 356 個 App。這裡的 512 是參與製作的人數，不代表每人各完成一個 App，也不能從公開資料判斷同一 App 有多少協作者。
356 個被描述為 live apps 或 shipped projects，表示已部署成可存取的應用。官方進一步說，其中 196 個為 full-stack App，連接自己的資料庫。法律、行銷與人資團隊也參與製作，不再只有工程部門能交付軟體。
這些數字能證明大量員工在短時間內完成部署，不能單獨證明 App 的品質、活躍度或商業成效。要評估實際價值，仍需知道每個 App 的週活躍使用者、節省時間、維護成本、重複率與停用比例。
K:Forge 是什麼？從一句需求到私有 App
K:Forge 是 Klaviyo 自建的內部 App 平台，底層使用 Vercel SDK 與部署能力。SDK 是 Software Development Kit 的縮寫，也就是讓開發者能用程式整合平台功能的一組工具。
員工可以從 K:Forge 首頁提出新想法，也能帶入在其他 AI 工具製作的專案，或直接上傳單一 HTML 檔。官方案例還提到，需求可以從 Slack、Claude 或 Cursor 開始，以自然語言描述想做什麼。
K:Forge 接手後會建立 GitHub 儲存庫、部署到 Vercel、透過私有連線接上資料，並套用安全預設。使用者不必自己處理雲端基礎設施。需要修改時，也能在 Slack 對話中描述變更，讓系統更新並重新部署。
Klaviyo 表示，從想法到一個已上線、受公司登入保護的 App 可以少於三分鐘。這個時間應理解為平台已經準備好、需求規模適合、且使用既有護欄時的官方案例，不是所有企業照做都能達到的通用保證。
AI 只是入口，預設安全護欄才是關鍵
如果讓數千名員工自行部署 App，畫面品質只是表層問題。更大的風險是敏感資料、帳號權限與未受管控的服務散落各處。這類未經公司管理的工具常被稱為 shadow IT，也就是影子資訊科技。
Klaviyo 的做法是把安全要求放進平台預設值。官方列出的控制包括：
- 所有 App 預設為 private，必須通過 Okta SSO 才能登入。
- builder 由公司的 identity provider 管理，透過 Vercel Enterprise Managed Users 套用身分。
- 敏感 environment variables 由團隊層級設定，builder 無法直接取得。
- 每個專案繼承 Klaviyo 已強化的 GitHub 安全設定。
- Wiz 掃描所有專案，發現的問題送進公司 SIEM。
- 對外公開必須逐案核准，內部工具不會自行暴露到公網。
SSO 是 Single Sign-On，中文常稱單一登入。員工使用公司身分登入多個服務，帳號停用與權限政策可以集中管理。Environment variables 是提供程式設定與機密資訊的環境變數。SIEM 則是集中收集和分析安全事件的系統。
這些護欄的價值，在於一般員工不必每次重新做正確選擇。公開網路、登入、資料庫密碼與安全掃描都有預設政策，只有例外情況才提高權限。
Secure Compute 如何讓 App 連到公司資料？
內部 App 真正有用，通常要讀寫 CRM、營運或客戶資料。若資料流量要經過公開網路，就需要額外處理 IP 白名單、加密、金鑰與暴露風險。
Vercel Secure Compute 在 Vercel 部署與 Klaviyo 基礎設施之間建立私有網路路徑。官方表示，K:Forge App 可透過這條路徑讀寫 Klaviyo 資料庫，流量不經公開網路。這也是 Klaviyo 選擇 Vercel，而不是其他曾評估工具的重要原因。
私有網路能縮小攻擊面，不能取代資料權限。每個 App 仍應只取得完成工作所需的資料表和操作能力。查詢客戶名單的工具，不應順便擁有修改付款紀錄的權限。最小權限、稽核紀錄、資料保留與個資遮蔽仍需另外設計。
三分鐘部署背後，平台替使用者做了哪些事？
| 階段 | K:Forge 自動處理 | 公司仍要負責 |
|---|---|---|
| 建立 | 建 GitHub repo、產生或匯入程式 | 確認需求、資料分類與 App owner |
| 部署 | 建立 Vercel 專案與預覽環境 | 定義成本、區域與可用性政策 |
| 身分 | 預設套用 Okta SSO 與企業帳號 | 決定角色、群組與離職停權流程 |
| 資料 | 透過 Secure Compute 連線 | 最小權限、資料用途與保留期限 |
| 安全 | 繼承 GitHub 設定、Wiz 掃描並送 SIEM | 處理告警、例外與事件回應 |
| 對外 | 預設 private | 逐案審核公開與客戶分享 |
這張表也說明，AI 只是輸入方式。真正讓大量員工安全部署的，是身分、網路、程式碼、安全掃描與例外審核被整合成同一條 pipeline。Pipeline 是把一連串步驟自動化的流程。
若企業只複製「用自然語言做 App」，卻沒有複製預設私有、集中身分與安全掃描，就會得到更多 shadow IT，而不是更高生產力。
80/20 模式：非工程師做到八成，平台團隊收尾
Klaviyo 並沒有說 citizen developer 完全取代工程師。較大型 App 由一般員工先完成約 80%，平台團隊再處理最後 20% 的微調與安全審查。
這種分工讓最了解問題的人先做出需求和可用原型，工程師則集中在跨系統整合、可靠性、安全與正式交付。平台團隊從每個需求的起點，移到最後的品質關卡。
但 80/20 不是固定比例，也不一定適合高風險系統。涉及付款、法規、個資、核心資料寫入或大量外部流量時，工程與安全團隊應更早介入。若等到最後才發現架構或權限方向錯誤，重做成本可能高於原本流程。
大量內部 App 會帶來哪些新問題？
App 氾濫與功能重複
356 個 App 可能包含非常有價值的工具，也可能有多個團隊重複解決相同問題。公司需要目錄、搜尋、標籤與合併機制，避免每個人都建立自己的客戶查詢或活動報名工具。
沒有人維護的孤兒 App
建立者調職或離職後，App 仍可能讀取資料或被同事使用。每個 App 應有 owner、備援負責人、最後使用日期和停用條件，不能只依賴最初建立者。
AI 產生程式的品質差異
能部署不代表程式碼可靠。錯誤處理、輸入驗證、資料一致性與套件漏洞仍需檢查。對高使用量或高風險 App，應設定測試、程式碼審查與變更審批門檻。
成本與治理負擔轉移
平台減少每個 App 的啟動成本，也會增加總數。運算、資料庫、日誌、安全掃描、支援與清理都會累積。若沒有使用量與成本儀表板，快速建立可能變成長期維護債務。
想複製 K:Forge，企業應先準備什麼？
先不要把目標訂成兩週做 356 個 App。更合理的第一階段，是選一個部門、20 名使用者與 5 個低風險需求，建立可重複的安全預設。
每個 App 至少要有六項資料：用途、owner、資料分類、使用者群組、依賴服務與停用日期。平台則要能集中管理登入、機密、網路、掃描、日誌與公開例外。
測試時同時記錄三類指標。速度包括從需求到可用 App 的時間。品質包括錯誤、回滾和人工重做。採用包括週活躍使用者、重複 App、節省工時與 30 天後仍有人使用的比例。
若建立速度變快，但資安告警、重複工具與孤兒 App 同步增加，就不應擴大全公司。若 5 個試點都能在既有政策內安全運作，而且負責人和停用流程清楚，再逐步增加範圍。
Klaviyo K:Forge 常見問題
512 名員工做了 356 個 App，代表每人一個嗎？
不是。官方資料只說 512 名 builder 參與並部署 356 個 App，沒有提供每位 builder 的分布或協作人數。
356 個全部是 full-stack App 嗎？
不是。官方表示其中 196 個為有自己資料庫的 full-stack App，其餘可能是前端工具、微型網站或其他較輕量專案。
每個 App 真的都能三分鐘完成嗎？
三分鐘是 Klaviyo 對 K:Forge 從想法到已部署私有 App 的官方說法，不是所有需求的獨立基準測試。複雜整合、安全審查與正式維護仍需要更多時間。
SSO 和私有網路就足夠安全嗎？
不夠。它們能降低公開暴露和帳號管理風險，但資料最小權限、程式漏洞、日誌、審查、事件回應與 App 退場仍要處理。
非工程師做 App 會取代工程師嗎？
案例呈現的是分工改變。非工程師先完成需求與大部分 App，平台和工程團隊負責安全、微調、可靠性與較複雜的正式交付。
結語：企業要複製的不是 356，而是護欄
Klaviyo 的案例證明，當部署、身分、私有網路、機密與安全掃描都有統一預設，非工程師能把想法更快變成可用 App。512 名 builder 在兩週部署 356 個 App，是這條平台管線降低門檻的明顯訊號。
企業不應只追求相同數量。更重要的是每個 App 都有 owner、最小權限、使用紀錄、維護方式和退場條件。部署速度如果沒有治理，最後只會把瓶頸從開發移到安全與維護。
先用少量低風險需求驗證平台預設，再看 30 天後的活躍度、事故、重複率和節省工時。只有這些指標一起改善，citizen developer 才是生產力策略，而不是短期 Demo 活動。
