當對手還在用 Change Set，我們已經讓 AI Agent 寫 Apex：台灣 Salesforce 導入的世代代差

摘要

• 核心命題：台灣多數 Salesforce 導入仍停留在 Change Set 手動部署的 2015 年工程世代；我們已經讓 Git-Native CI/CD、Hutte Org Pool、Claude AI Agent 三根支柱接管整個交付鏈路。
• 傳統模式四個你以為解決了、其實沒解決的問題：Change Set 沒有版本記憶、Git 只當備份用、共用 Sandbox 互相覆蓋、部署黑盒到上線才知道會不會炸。
• 易凱的三根支柱：Git Repo 是唯一事實來源；Hutte 把 Scratch Org 變隨需服務，5 人 5 Org 並行；Claude AI Agent 嵌入需求 → 程式碼 → metadata → UAT 四個節點。
• 可量化的差距：上線週期 −67%、人月成本 −55%、UAT 缺陷密度 −70%、緊急修復時間從 2~5 天降到 2 小時內。

一、台灣 Salesforce 市場的「時間靜止」現象

過去十年，全球的軟體交付方式經歷了完整一輪典範轉移：從手動部署到 CI/CD、從共用環境到 Ephemeral Environment、從人工 QA 到自動化測試金字塔，再到今天 AI Agent 全面進入工程師的日常工作流。

但若你今天走進台灣大多數導入中的 Salesforce 專案現場，會發現一個讓人錯愕的畫面——顧問仍然在 Outbound Change Set 裡手動勾選 Custom Object，再從 Sandbox 一個一個發到 Production；驗證失敗後，再花半天人工排錯。沒有 Git，或者只有「把每次部署完的 Metadata 用 sfdx 拉下來丟到 Bitbucket」的初期 Git。版本控制在這裡只是一個「歸檔工具」，不是「協作工具」。

這就是台灣本土 Salesforce 導入的時間靜止現象：客戶花了上千萬的授權費與顧問費，背後支撐的卻是 2015 年的工程方式。當 IT 主管問顧問：「為什麼這個改動要排到下個月才能上？」答案永遠是「我們在等部署窗口」、「測試環境被別的功能佔住了」、「Change Set 帶不過去」。這些理由在 2026 年聽起來，已經不該是答案。

易凱科技存在的理由，就是要終結這種理由。本文要說的不只是「我們用了什麼工具」，而是我們用什麼樣的工程理念，把客戶從「等待型導入」帶到「演進型交付」。

二、傳統導入方式的真實樣貌：四個你以為解決了，但其實沒解決的問題

在進入易凱的方法論之前，必須先誠實地拆解今天台灣大多數本土 Salesforce 顧問公司的工程現況。我們不是在嘲笑誰，而是要指出一個產業現實：很多痛點之所以一直存在，是因為大家把「習慣了」當成「解決了」。

2.1 Change Set：那不是版本控制，那是壓縮檔的搬運工

Change Set 的本質，是一個跨 Org 的 Metadata 拷貝機制。它沒有 diff、沒有 history、沒有 merge、沒有 rollback。你今天送出去的 Change Set 一旦部署完成，下一秒它就消失在系統裡——沒有任何證據能告訴你：這次改動到底動了什麼、為什麼動、誰批准的。

在 Production 出問題的那一刻，所有人圍著電腦看著對方，問的都是同一句話：「上週是誰改的？改了什麼？」沒有人能精確回答。Change Set 是一種沒有記憶的部署，它讓組織把所有改動的責任，全部推給「人腦中的記憶」。

2.2 沒有 Git 或初期 Git：版本控制只是歸檔工具

有些公司會說：「我們有 Git 啊，我們把 metadata 都放在 Bitbucket。」但你仔細看就會發現：那不是 Git 工作流，那只是把 Salesforce 當作 Source of Truth，把 Git 當作備份磁碟。

真正的 Git-Native 工作流，意味著：開發者寫 code 之前要先 git checkout -b feature/xxx，所有的設定變更（包含 Validation Rule、Flow、Permission Set）都要產生對應的 metadata 檔案、提交 Pull Request、經過 Code Review、跑過 CI、合併進主幹。但在台灣大多數案場，Git 是「事後備份」而不是「事前協作」——這意味著兩個開發者改同一個 Field 的時候，根本沒有 merge conflict 提醒，最後一個推上 Sandbox 的會默默蓋掉前一個。

2.3 共用 Sandbox：開發者互相覆蓋的日常

因為 Sandbox 數量有限（一個 Full Sandbox 一年要十幾萬台幣的授權成本），絕大多數導入專案讓 5、6 個開發者共用一個 Dev Sandbox。後果是：A 改 Account Layout、B 改同一個 Layout 的時候，B 看到的是 A 改一半的版本。功能還沒驗收，環境就已經污染。

更糟的是，當 Change Set 部署到 UAT 失敗，沒人能 100% 復現失敗環境，因為那個 Dev Sandbox 從來沒有「乾淨狀態」可以對照。這不是「開發環境管理」，這是「集體創作互相干擾」。

2.4 部署黑盒：上線前一刻，才知道會不會炸

傳統模式裡，UAT 通過 ≠ Production 一定會通過。因為 UAT 的 Apex Test Coverage 跟 Production 的 Coverage 計算方式可能不同；UAT 沒有的 Permission Set 可能在 Production 是必要的；UAT 的 Profile 可能跟 Production 早已分歧好幾個版本。

結果就是：每一次 Production 上線，都是一次心臟病發作的賭博。週五晚上九點，所有人在會議室裡盯著 Salesforce Setup 一個一個檢查 Validation Rule，然後祈禱明天早上業務不會打電話來。

2.5 隱藏成本：你看不到的，才是最貴的

以上四個痛點，最直接的成本是「時間延遲」與「Production 事故」，但更深層的隱藏成本是：

• 人才流失：優秀的 Salesforce 開發者不願意長期待在沒有 Git、沒有 CI 的環境，因為這意味著他的履歷在停滯。
• 知識斷層：所有 metadata 變更都靠人腦記憶，當核心顧問離職，整個系統的「為什麼這樣設計」就跟著消失。
• 客戶信任侵蝕：每一次「這個小改動需要兩週」都在告訴客戶：你們的供應商沒有應變能力。
• 架構債務累積：因為改動成本高，業務只敢提「不得不改」的需求，真正能帶來商業價值的優化全部被擱置。

⚠️ 這不是「導入慢」，這是「導入的工程基礎設施落後一個世代」。客戶花的不是工具錢，是工程世代的代差錢。

三、易凱科技的導入體系：三根支柱、一個哲學

易凱科技的導入方式，建立在三根技術支柱與一個工程哲學之上。三根支柱分別是 Git-Native CI/CD Develop、Hutte Org Pool、Claude AI Agent。它們不是三個獨立工具，而是一個有機整體：Git 是協作的單一事實來源，Hutte 解決環境隔離的瓶頸，Claude AI 把資深架構師的判斷力放大到每一個工程任務上。

3.1 支柱一：Git-Native CI/CD Develop

在易凱的工程體系裡，Git Repository 是唯一的事實來源（Single Source of Truth）。Salesforce Org 上看到的每一個 Validation Rule、每一行 Apex、每一個 Permission Set，都必須能在 Git 裡找到對應的 metadata 檔案與提交記錄。任何「直接在 Sandbox 點一點」的改動，在我們的流程裡是違規行為。

實務上，這意味著一個典型的需求進來，會經過下列流程：

1. 建立 feature branch：
   git checkout -b feature/EKL-1024-account-credit-limit

2. 開發者在 Hutte 拉一個 Scratch Org，把 metadata 抓下來、改、推上去測

3. 提交 PR：
   - CI 自動跑：sf project deploy validate + 全套 Apex Test
   - 自動跑 PMD / ESLint 靜態檢查
   - 必須兩位 reviewer 通過

4. 合併到 develop → 自動部署到 Integration Sandbox
5. 合併到 release → 自動部署到 UAT
6. 合併到 main → 受控部署到 Production，附帶完整 audit trail

這個流程帶來的根本性差別是：每一個改動都是一個可審計、可重現、可回滾的事件。當 Production 出問題，不再需要問「是誰改的」，因為 git log 已經告訴你了。

3.2 支柱二：Hutte Org Pool（隨需 Scratch Org）

Sandbox 不夠用，是台灣 Salesforce 導入永遠的瓶頸。Hutte 解決的，正是這個瓶頸。

Hutte 是一個專為 Salesforce 設計的 Scratch Org 管理平台，它把 Salesforce DX 的 Scratch Org 機制包裝成一個「隨需開／隨用即關」的服務。在易凱的流程裡，每個開發者只要在 Hutte 介面選擇對應的 Git branch，就能在 5～10 分鐘內得到一個全新、乾淨、與 Production metadata 一致的 Org。開發完成後，Org 自動回收，下次需要再開一個新的。

這帶來三個傳統 Sandbox 模式無法達成的能力：

• 絕對隔離：A 開發者改的東西，永遠不會污染 B 開發者的測試。
• 環境一致性：每個 Org 都從同一個 Git branch 建出來，差異只會來自開發者本人的改動，不會來自「上次別人留下來的垃圾」。
• 並行開發：原本 5 人共用 1 個 Sandbox 的隊形，變成 5 人 5 個獨立 Org 並行推進。同樣的人月，產出量是原本的 3～5 倍。

3.3 支柱三：Claude AI Agent（從需求到 UAT 的全流程加速）

易凱不是「用 AI 寫一點 code 提速」這種淺層整合。我們把 Claude AI Agent 嵌入導入週期的四個關鍵節點，每一個節點都有對應的 Agent 工作流：

節點 1：需求分析與 User Story 撰寫

客戶會議結束後，AI Agent 會直接讀會議逐字稿，產出符合 INVEST 原則的 User Story、AC（Acceptance Criteria）、與 Dependency 對照表。顧問不再花一個下午整理筆記，而是花一個下午審查 AI 整理好的 backlog。

節點 2：Apex / LWC 程式碼生成與 Code Review

Agent 根據 User Story 生成第一版 Apex Trigger / Service / LWC 元件，包含對應的 Apex Test Class（強制要求 75% 以上覆蓋率與 positive/negative/bulk 三類情境）。資深開發者的角色從「寫程式」轉變為「審查 AI 寫的程式」，速度與品質同時拉高。

節點 3：Metadata 設計與配置自動化

Object 結構、Field、Permission Set、Validation Rule、Flow 的設計，由 Agent 根據需求草擬，並產出可直接 commit 進 Git 的 metadata XML。架構師專注在「資料模型對不對」，不再陷入「按鈕該勾哪個」的細節。

節點 4：測試自動化與 UAT 加速

Agent 自動產出 Apex Test、End-to-End 測試腳本（Playwright / Cypress 對應 LWC），並在 UAT 階段協助分析使用者回報的缺陷、定位到具體的 metadata 或程式碼層級。UAT 不再是顧問與業務鬥智，而是 Agent 即時翻譯使用者意圖。

重點不是「AI 取代了顧問」，而是「AI 把顧問從重複勞動中解放，讓他們專注在判斷與設計」。一位易凱的資深架構師，在 AI 加持下的產出，相當於傳統模式裡 3～4 位中階顧問。

四、技術深度對比：世代代差到底在哪裡？

前面兩章是建立認知基礎，這一章我們要進入細節層級的對比。世代代差不是一兩個指標的差距，是整個工程基礎設施的世代差異。我們從三個最核心的維度來看：開發環境、部署流程、品質保證。

4.1 開發環境管理：共用 Sandbox vs 隨需 Org Pool

開發環境是整個工程體系的地基。地基歪了，上面蓋什麼都會塌。傳統模式的「共用 Sandbox」是線性思維：環境是稀缺資源，所以排隊使用。易凱的「Org Pool」是雲端原生思維：環境是可動態供應的服務，每個任務都應該有自己的環境。

並行度的差距：傳統 5 人共用 1 個 Sandbox，並行度趨近於 1；易凱 Hutte 模式下，5 人 5 個獨立 Scratch Org，並行度為 5×5（每人可同時開多個 branch 的 org）。同樣的人月，產出量是原本的 3～5 倍。

4.2 部署與發布：手工搬運 vs 全自動 Pipeline

部署是另一個世代代差最明顯的地方。傳統模式裡，部署是「人工搬運 metadata」的勞動；易凱模式裡，部署是「Git event 觸發的自動工作流」。兩種模式的部署機制具體對照：

4.3 品質保證：人工抽測 vs AI 加持的測試金字塔

傳統模式的品質保證，本質上是「人海戰術」：請 QA 拿著 Excel 跑 100 條測試案例，跑兩天，發現 5 個 Bug，回去修，再跑兩天。改一個 Field 就要重跑一輪。

易凱模式的品質保證，是「測試金字塔 + AI Agent」：底層是大量自動化的 Apex Unit Test 與 LWC Jest Test，中層是 E2E 場景測試，最頂層才是人類驗收。AI Agent 在三層都扮演角色：自動產生測試、自動分析失敗、自動建議修復。

五、理念上的根本差距：四個 mindset shift

工具差距還只是表象，真正讓兩種模式產生「世代代差」的，是背後的工程理念。下面這四個 mindset shift，是易凱與傳統本土顧問公司最深層的不同。

5.1 從「IT 配置員」到「軟體工程實踐」

傳統 Salesforce 顧問把自己定位為「平台配置者」——客戶提需求、我來點按鈕。這個自我定位決定了：他們不需要 Git、不需要 CI、不需要測試自動化，因為「配置又不是 coding」。

易凱的根本立場是：Salesforce 的每一個 Validation Rule、每一個 Flow、每一個 Permission Set，本質上都是程式碼，都應該被軟體工程的全套方法論所管理。我們不是在「做 Salesforce」，我們是在「用 Salesforce 平台做軟體工程」。

5.2 從「客戶等我們」到「我們匹配客戶速度」

傳統模式裡，業務速度被導入速度綁架——客戶說「下週要新增一個欄位給促銷活動用」，顧問說「我們可以排在下個 Sprint，大概兩週後上」。客戶只能說「好吧」，因為沒得選。

在易凱的體系下，這個對話是：「下週要用？OK，我們今天 Pull Request、明天上 UAT、後天上 Production。你要不要乾脆把促銷活動的另外兩個衍生需求一起說？」當部署成本被壓到接近零，業務節奏才能真正被解放。

5.3 從「人海戰術」到「智慧協作」

傳統大型 SI 的競爭力來自「我有 200 位顧問」，本質上是「拼人月」。這個模式下，導入品質受限於每一位顧問當下的狀態，最弱的那一位決定了整體交付的下限。

易凱的競爭力來自「一位資深架構師 + Claude AI Agent」的組合。AI 把架構師的判斷力一致地複製到每一個任務，所以我們不需要 200 位顧問，但我們的下限永遠是「一位資深架構師的水準」。對客戶來說，這是更穩定、更高品質的交付。

5.4 從「上線即交付」到「持續演進」

傳統導入的成功定義是「Go-Live」——上線那一刻，專案結案。客戶上線後的演進，要麼自己摸索、要麼再簽一次大型合約。

易凱的成功定義是「客戶能持續演進」。我們交付的不只是一個 Salesforce Org，更是一整套可被客戶自己維護的工程資產：完整的 Git Repository、CI/CD Pipeline、Hutte 的 Org Pool 配置、AI Agent 的 prompt library、測試套件。客戶從第一天起就有能力自己改、自己驗、自己上。

這四個 mindset shift 加總起來，是一句話：我們不是在賣 Salesforce 的導入勞動，我們是在賣現代軟體工程能力的轉移。

六、對客戶的可量化承諾：時間、成本、品質、可維護性

理念講得再漂亮，最終還是要回到客戶能感受到的具體數字。基於我們在多個導入專案上的實際數據（涵蓋金融、零售、製造、SaaS 等場景），下面是易凱模式相對傳統模式的可量化差距：

6.1 時間：從 12 個月縮到 3～4 個月

中型導入專案（涵蓋 Sales Cloud + Service Cloud + 30 個自定義 Object 規模），傳統模式典型週期 9～12 個月，易凱模式可壓到 3～4 個月。這不是壓榨人力，而是消除等待——等 Sandbox、等 Change Set、等手動驗證、等部署窗口的時間，全部歸零。

6.2 成本：人月降幅約 55%

同等範圍的功能交付，所需人月約為傳統模式的 45%。AI Agent 加速了 60～70% 的重複性工程任務，讓資深顧問把時間用在真正需要判斷的地方。

6.3 品質：UAT 缺陷密度下降 70%

因為每一行 Apex 都有對應的 Test Class、每一個 metadata 改動都過 PMD 與 AI Code Review，UAT 階段才被使用者發現的缺陷數量大幅下降。缺陷被推到開發階段就被攔截。

6.4 可維護性：緊急修復從「天」變「小時」

Production 出問題時，傳統模式要走「Sandbox 重現 → Change Set → 部署窗口」的完整鏈路，至少 2～5 天。易凱模式：git revert + Pipeline 自動跑 + Production 自動部署，2 小時內可以完成上線。對業務來說，這是「事故」與「插曲」的差別。

6.5 一張表看懂兩種世代的差距

七、結語：選擇導入夥伴，等於選擇技術世代

Salesforce 平台本身在過去十年快速演進——Lightning、DX、Flow、Einstein、Agentforce——這些原廠提供的能力，從來沒有上限。真正的上限，永遠是「在這個平台上工作的工程方法」。

當你選擇一家還在用 Change Set 的導入夥伴，你不是省下工具錢，你是把自己的數位轉型節奏押在 2015 年的工程基礎設施上。當業務說「我們的競爭對手已經能 24 小時內回應市場變化」，而你的 IT 說「我們下個部署窗口在三週後」——這個落差，就是技術世代的代差。

易凱科技的存在，是要讓台灣的 Salesforce 客戶有第二種選擇。我們不是更便宜的傳統模式，我們是不同世代的解法。當你的對手還在用 Change Set 搬 metadata，我們已經讓 AI Agent 寫 Apex、Hutte 配環境、Pipeline 自動部署。當你還在等下個 Sprint，我們已經 commit 了第三個版本。

這就是世代代差——而我們相信，台灣的 Salesforce 客戶值得這個世代。