開發人員每日分心達1,200次，MCP鎖定生產力修復方案

軟體開發人員花費在非編碼工作上的時間，遠遠超過實際寫碼的時間。產業研究顯示，直接編程作業可能僅佔開發者工作日的16%，絕大多數時間都被支援性任務與營運事務所佔據。在團隊被要求以更少資源達成更多目標、執行長們大肆宣揚其AI生成程式碼的時代，一個關鍵問題浮現：我們該如何優化工程師工作量中剩餘的84%？

讓開發者專注於最高效的工作領域

開發者生產力最大的消耗源之一是「情境切換」——在日益擴張的軟體開發與部署工具套件及平台間不斷跳轉。哈佛商業評論研究顯示，數位工作者平均每日在應用程式與網站間切換近1,200次。 每次中斷都伴隨代價。加州大學研究指出，單次干擾後需耗時約23分鐘才能完全恢復專注力，更糟的是近30%的中斷任務最終未能完成。情境切換的挑戰如此關鍵，甚至被納入DORA框架——這是當前最廣泛採用的軟體開發績效衡量標準之一。

隨著人工智慧驅動的組織致力於賦能員工以更少資源創造更多價值——超越單純提供大型語言模型（LLMs）的層面——嶄新趨勢正逐漸成形。 Brex首席工程師Jarrod Ruhland認為：「開發者在整合開發環境（IDE）中保持專注時，能創造最高價值。」基於這項原則，他探索實現此目標的新方法，而Anthropic的新協議或許正是解方關鍵。

MCP：為IDE注入情境脈絡的協議

以人工智慧驅動的編碼助手——例如整合Cursor、Copilot及Windsurf等大型語言模型增強型IDE——正引領開發者復興浪潮，其普及速度前所未見。Cursor創下史上成長最迅速的SaaS產品紀錄，上市一年內即達成1億美元年度經常性收入；而《財星》500大企業中，現有70%採用微軟Copilot。

然而這些輔助工具傳統上僅限於程式碼庫情境運作。雖然能幫助開發者加速編寫程式碼，卻未能解決更廣泛的情境切換問題。 新型協議「模型上下文協議」(MCP) 正致力解決此痛點。由Anthropic於2024年11月推出的MCP，是項旨在簡化AI系統（尤其大型語言模型工具）與外部數據源及應用程式整合的開放標準。其普及度正急速攀升，過去六個月新增MCP伺服器數量暴增500%，僅六月單月下載量就達700萬次。

MCP最具影響力的應用之一，在於能將AI程式碼輔助工具直接串接至開發者日常使用的工具，藉此優化工作流程並大幅減少情境切換次數。

以功能開發為例：傳統流程需在多個系統間反覆切換——從專案追蹤器閱讀工單、檢視團隊對話確認細節、查閱文件確認 API 規範，最後開啟 IDE 開始編碼。每個步驟都佔據獨立分頁，頻繁的思維轉換嚴重拖慢進度。

透過 MCP 與 Anthropic 的 Claude 等現代 AI 助手，整個流程可在程式編輯器內完成。

例如，在編碼助手中完整實現功能的流程如下：

• 透過Linear MCP伺服器匯入工單細節；
• 透過 Slack MCP 伺服器匯出相關討論內容；
• 透過Glean MCP伺服器查閱必要文件；
• 透過要求 Cursor 生成初始框架來編寫功能。

此方法同樣適用於其他工程工作流程。以網站可靠性工程師（SRE）的事件應對為例，可能包含：

• 透過 Rootly MCP 伺服器提取事件詳情
• 透過 Sentry MCP 伺服器擷取追蹤資料
• 透過 Chronosphere MCP 伺服器匯入可觀察性指標
• 透過指令讓Claude Desktop解決錯誤

日下無新事

我們早已見識過這套模式。過去十年間，Slack 透過成為數百款應用程式的核心樞紐，徹底革新職場生產力，讓員工無需離開聊天視窗即可管理多元任務。Slack 平台成功降低了日常工作流程中的情境切換頻率。

以Riot Games為例，透過整合近千款Slack應用程式，其工程師報告顯示：程式碼測試與迭代時間縮短27%、新錯誤識別速度提升22%、功能上線率增長24%。這些成效主要歸功於工作流程的精簡化及跨工具切換摩擦的減少。

如今，類似的變革正在軟體開發領域展開。透過MCP整合賦能的人工智慧助理，正成為串聯所有外部工具的橋樑。實際上，整合開發環境（IDE）即將成為工程師的新型全能指揮中心，正如Slack之於一般知識工作者。

MCP可能尚未具備企業級應用能力

MCP作為相對年輕的標準，在安全性層面存在缺陷：既無內建驗證機制亦無權限模型，僅依賴仍在演進的外部實作方案。 身分識別與稽核機制亦存模糊地帶——該協定未能明確區分操作行為源自使用者或AI本身，若無客製化解決方案，將導致責任歸屬與存取控制複雜化。F5 Networks技術長辦公室傑出工程師暨首席推廣專家Lori MacVittie指出，MCP正「顛覆我們長期秉持的核心安全假設」。

當編碼助手同時調用過多MCP工具或伺服器時，另一項實務限制便顯現。每個MCP伺服器皆會發布包含描述與參數的可用工具清單，AI模型必須處理這些資訊。若模型被數十種工具淹沒，其上下文視窗將不堪負荷，導致工具數量增加時性能明顯下降。 部分整合式開發環境（IDE）已實施硬性限制——例如Cursor IDE設限約40個工具，OpenAI代理程式則限制約20個——以防止提示字串膨脹超出模型負荷。

最後，當前尚無精密機制能讓工具自動偵測或依情境建議；工具僅以清單形式呈現。這常迫使開發者手動啟用/停用工具，或精心管理活躍工具組以維持工作流程順暢。回顧先前Riot Games安裝1,000個Slack應用程式的案例，不難理解工具失控擴增將如何對企業應用造成困擾。

減少轉椅，增加軟體

過去十年間，將工作帶到工作者身邊的價值已獲驗證——從集中更新的Slack頻道、實現「收件匣清零」的郵件策略，到統一的工程儀表板。如今隨著AI加入工具箱，我們迎來大幅提升開發者生產力的絕佳契機。若Slack成為商務溝通樞紐，AI程式碼助手則完美定位為軟體創作樞紐——不僅是編寫程式碼的場所，更是所有相關情境與協作匯聚的中心。

透過讓開發者維持高效工作狀態，我們消除了長期阻礙工程產出的頻繁心智切換。

對於任何依賴軟體交付的組織，深入檢視開發人員實際時間分配模式都極具價值。您可能會對發現的結果感到驚訝。

西爾萬·卡拉切（Sylvain Kalache）現任Rootly人工智慧實驗室負責人。