老牌數據分析大廠揭AI Coding實戰經驗，要量化AI工具成效與成本

以大數據分析起家的AI軟體大廠SAS也面臨這個課題，SAS全球研發資深副總裁Jared Peterson在本月SAS Innovate 2026大會上受訪時透露，他們的做法是建立一套衡量機制，來追蹤、比較使用AI輔助開發產生的費用，以及工程師與AI協力產出的程式碼品質和合格數量，再調整投資力道。

不只啟動企業級AI採用計畫，也開始衡量AI輔助開發效益

Jared Peterson帶領SAS全球研發團隊，主導SAS資料與AI平臺的產品開發。他表示，早在生成式AI工具普及前，他的團隊就已採用規格驅動開發（SDD）模式，也就是先定義需求和規格，再由AI產生程式碼，工程師再來調整、迭代。

隨著AI Coding工具快速成熟，SAS也持續擴大內部使用。Jared Peterson指出，SAS內部發起一套橫跨全組織的AI輔助開發計畫，不單單針對研發單位，而是涵蓋所有部門。這項計畫除了鼓勵員工使用AI工具，也特別重視AI投資是否產生效益。

以Jared Peterson帶領的研發團隊為例，大部分開發者主要使用GitHub Copilot這套AI輔助開發工具，而部分被認定為高效使用者（Power users）的工程師，則會進一步取得Claude Enterprise授權版本工具。

其中，SAS會比較不同AI Coding工具的成效，比如，同一批工程師使用GitHub Copilot和Claude Enerprise生成程式碼的品質差異。Jared Peterson透露，目前確實觀察到，部分高效使用者，用Claude生成的程式碼品質更高。但他也點出，主因未必是背後的模型能力差異，有可能是工程師懂如何使用AI工具後，能更有效使用這類工具。

與此同時，SAS也會定期追蹤多項AI Coding指標，例如工具使用率、AI生成程式碼被接受的比例（Accepted lines of code），以及相對應增加的雲端成本，來評估AI是否真的提高開發效率。

如何確保模型選對MCP工具？關鍵是情境工程

除了AI輔助開發，Jared Peterson也進一步說明常見的代理型AI（Agentic AI）架構。

他以生成式AI助手Copilot為例，Copilot就像是使用者互動介面（UI）角色，真正執行邏輯與任務協調的，其實是背後的AI代理（AI Agent），而大語言模型（LLM）則負責理解使用者意圖。這些代理可能單一支執行任務，也可能多支合作，但不論如何，為完成執行任務，代理會透過MCP伺服器來選擇、呼叫適合的工具。

不過，企業建立多代理和MCP架構後，往往會遇到選錯工具的問題，比如代理挑錯工具、Copilot可能誤解使用者需求，或是多代理協作流程不如預期。Jared Peterson指出，這時候，企業需要做的是情境工程（Context Engineering）。

他解釋，情境工程是透過指令、文字描述和上下文限制，不斷縮小LLM可使用的資訊空間，讓模型更容易做出符合預期的選擇。

例如在MCP架構中，每個工具都會附帶文字描述，供AI代理和LLM判斷，哪些工具最適合當下的任務。而情境工程的目的，就是持續優化這些上下文資訊與限制條件，降低模型誤判或選錯工具的機率。

Jared Peterson也坦言，自家幾乎所有Agentic AI的產品背後，都大量使用情境工程技術。

代理型AI要有效好用，得先判斷題目的確定性

至於代理型AI能否解決企業問題，Jared Peterson認為，企業在導入前，必須先理解哪些場景可以接受LLM的不確定性，哪些不能，也就是先判斷這個問題是否需要穩定、可重現的答案，即確定性（Deterministic）與不確定性（Non-deterministic）系統的差異。

尤其，在金融、醫療與政府等高度監管領域，企業往往需要可解釋、可驗證、可重現的決策結果，因此Jared Peterson認為，最理想的做法，不是完全依賴LLM，而是將傳統確定論系統和生成式AI能力，都整合在同一平臺中，再依不同需求選擇適合技術，這也是SAS目前主打的可信任AI服務核心，不是完全取代傳統系統，而是讓生成式AI與既有的決策系統共同運作。