AI Agent 主導 Salesforce 導入：台灣企業該選擇的新一代交付方式

一、台灣 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 變更都靠人腦記憶，當核心顧問離職，整個系統的「為什麼這樣設計」就跟著消失。
• 客戶信任侵蝕：每一次「這個小改動需要兩週」都在告訴客戶：你們的供應商沒有應變能力。
• 架構債務累積：因為改動成本高，業務只敢提「不得不改」的需求，真正能帶來商業價值的優化全部被擱置。

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

三、易凱科技的導入體系：AI Agent 平台貫穿全流程

易凱科技的導入方式，核心不是某一套外部工具，而是我們自行研發的 AI Agent 平台。這套平台把資深 Salesforce 架構師的判斷、交付模板、檢查清單與工程規範，嵌入從初始需求到上線的每一個步驟。它不是只在開發階段「幫忙寫一點 code」，而是在需求理解、方案設計、配置與開發、測試、文件、UAT 與交付治理中持續協助，部分重複性高、規則清楚的節點甚至由 Agent 主導產出第一版，再由顧問與架構師審查。

3.1 從初始需求開始：AI Agent 先整理，再由顧問判斷

在傳統導入裡，需求訪談後最容易失真：會議記錄散在不同文件、User Story 寫法不一致、Acceptance Criteria 不完整，後面每一步都在補洞。易凱的做法是，客戶會議結束後，AI Agent 先讀取會議紀錄、需求描述與既有文件，產出：

• 業務流程摘要與待確認問題
• User Story 與 Acceptance Criteria 草稿
• 資料模型、權限、整合與報表的初步影響分析
• 風險清單與下一輪訪談問題

顧問不再花大量時間整理格式，而是把時間用在判斷：哪些需求真正重要、哪些流程應該用 Salesforce 原生能力完成、哪些地方需要客製。這讓專案一開始就少走彎路。

3.2 設計與開發：AI Agent 草擬，架構師把關

進入設計與開發後，AI Agent 會根據已確認的需求，協助產出資料模型草案、Flow / Permission Set / Validation Rule 建議、Apex / LWC 初稿、測試情境、技術文件與變更說明。重點不是讓 AI 無人監督地交付，而是讓 AI 先完成大量重複、規則清楚、可被檢查的工作，再由資深顧問與架構師審查。

這個模式帶來的差異是：

• 速度更快：顧問不用從空白頁開始，每個交付物都有 Agent 先產出可審查版本。
• 品質更穩：同一套 Agent workflow 會持續套用我們的命名規範、權限檢查、測試要求與文件模板。
• 返工更少：需求、設計、開發與測試被同一套上下文串起來，錯誤更早被發現。
• 成本更低：人力不再耗在低價值重複工作，節省的人月可以回饋到客戶價格。

3.3 測試、UAT 與上線：Agent 協助甚至主導排查

到了測試與 UAT 階段，AI Agent 會協助產出測試案例、分析失敗紀錄、比對需求與實作差異，並把使用者回報翻譯成可追蹤的修正項目。對規則清楚的缺陷，Agent 可以先定位到可能的配置、metadata 或程式碼區塊，甚至產出修正建議；顧問則負責確認商業語意與最終方案。

因此，易凱不是把 AI 放在專案旁邊當輔助工具，而是把 AI Agent 放進專案流程中，讓它在每一步協助、檢查、整理、產出，並在適合的任務上主導第一版交付。

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

四、技術深度對比：差距在「全流程 Agent 化」

前面兩章是建立認知基礎，這一章進入細節層級的對比。差距不是一兩個指標，而是整個導入流程是否被 AI Agent 系統化地加速與把關。我們從需求、交付流程與品質保證三個維度來看。

4.1 需求管理：人工整理 vs Agent 輔助需求工程

需求是整個導入體系的地基。地基歪了，後面的配置、開發與測試都會跟著歪。傳統模式依賴顧問手動整理訪談筆記，品質取決於個人經驗與當天狀態；易凱的模式是先由 AI Agent 結構化需求、找出缺口、產出 User Story / AC / 風險清單，再由顧問判斷與確認。

差距在於：傳統模式常常到 UAT 才發現「原來客戶不是這個意思」；Agent 化需求工程會在專案早期就把模糊點標出來，讓錯誤更早被修正。

4.2 交付流程：人工接力 vs Agent 串起上下文

交付流程是另一個差距最明顯的地方。傳統模式裡，需求文件、設計文件、配置、程式碼、測試與 UAT 回饋常常分散在不同人手上；易凱模式裡，AI Agent 會把同一個需求的上下文串起來，讓每一次設計、開發與測試都有清楚依據。具體對照：

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 從「人海戰術」到「Agent 化智慧協作」

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

易凱的競爭力來自「資深架構師 + 自行研發的 AI Agent 平台」的組合。AI Agent 把架構師的判斷、規範與檢查流程一致地套用到每一個任務，所以交付品質不只取決於某一位顧問當天的狀態。對客戶來說，這代表更穩定、更高品質，也代表更少返工與更低成本。

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

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

易凱的成功定義是「客戶能持續演進」。我們交付的不只是一個 Salesforce Org，更是一整套可被客戶自己維護的工程資產：完整的需求脈絡、設計決策、交付文件、測試套件、AI Agent 工作流與可維護的工程資產。客戶從第一天起就有能力自己改、自己驗、自己上。

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

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

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

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

中型導入專案（涵蓋 Sales Cloud + Service Cloud + 多個客製資料模型與流程），傳統模式典型週期可能需要 9～12 個月，易凱模式可顯著縮短。這不是壓榨人力，而是消除低價值等待與重複工作——需求整理、設計草擬、測試案例、缺陷分析、文件沉澱，都由 AI Agent 先行處理，顧問把時間集中在判斷與決策。

6.2 成本：人月降幅約 55%

同等範圍的功能交付，AI Agent 能大幅減少重複性工程與文件工作，讓資深顧問把時間用在真正需要判斷的地方。人月降低後，客戶不只得到更快交付，也能得到更有競爭力的價格。

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 客戶有第二種選擇。我們不是更便宜的傳統模式，而是用不同世代的方法交付：從初始需求開始，每一步都有 AI Agent 協助、檢查、整理與產出，在適合的節點甚至主導第一版成果。當別人還把 AI 當成單點工具，我們已經把 AI Agent 變成導入方法論本身。

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