IDC 一份產業研究報告指出，大多數軟體開發人員的工作時間，其實都花在「非程式碼編寫」相關作業上，即程式維護、平台營運與任務支援等工作，平均時間佔比達到了驚人的 84%，而程式碼撰寫僅佔 16%。
隨著 AI 時代到來，許多軟體開發團隊正在面臨「少花錢，多辦事」的巨大壓力，尤其企業老闆更喜歡對「AI 協助撰寫程式碼如何改進員工作業效率」有所吹噓。
不過對於工程師來說，真正重要的事情仍是：如何透過 AI 針對佔據 84% 時間的主要工作進行效率優化。
總是被分心且難以專注的工程師
《哈佛商業評論》指出，數位工作者平均每天在應用程式和網站之間，來回切換近 1,200 次，嚴重干擾作業專注度。這種頻繁的「環境切換」（context switch）現象，隨著建立和發佈軟體所需要的工具、平台越來越多，狀況也變得越來越嚴重。
此外加州大學的研究亦發現，當數位工作者每遭遇一次專注力中斷，大約都需要 23 分鐘時間，才能完全重新恢復注意力，甚至有近 30% 遭到中斷的任務，從來沒被工作者重新掌握，就直接切換到了下一件事情。
因此當人類正式邁入 AI 時代，企業總是希望找出方法賦能員工，透過人工智慧使他們事半功倍。只不過，有能力驅動這項任務的 AI 工具，卻不僅僅是大型語言模型而已。
美國金融技術公司 Brex 首席工程師 Jarrod Ruhland 就認為，唯有當開發人員專注於「整合開發環境」（IDE）的改進時，才有可能讓工程師們發揮出最大價值，其中由 Anthropic 提出的「模型上下文協議」（MCP）很可能成為關鍵。
當 AI 程式開發，遇上潛力無窮的 MCP
目前市面上流行的 AI 程式開發平台，例如 Cursor、Copilot 與 Windsurf 等，皆是基於 LLM 的 IDE，並以前所未有的速度普及於整個科技產業。
以 Cursor 來說，它已經成為歷史上成長速度最快的 SaaS 平台，即使推出不到 12 個月時間，其年度經常性收入（ARR）仍達到了 1 億美元；至於微軟 Copilot 則吸引了高達 70% 的《財星》500 強企業採用。
然而，無論 Cursor 或 Copilot，這些 AI 程式開發平台的主要能力，基本上都僅限於「協助人類撰寫程式碼」，無法有效幫助開發人員解決環境切換問題，直到 Anthropic 於 2024 年 11 月發表了 MCP 後，事情才出現了一線曙光。
MCP 的目標是促進 AI 系統，尤其是基於 LLM 的人工智慧應用，跟外部工具與資料來源之間密切整合；過去 6 個以來，全球新設立的 MCP 伺服器數量，已大幅增加高達 500%。
同時 MCP 最具影響力的應用之一，就是它能夠將 AI 程式碼撰寫平台，直接連接到開發人員每天依賴的各種工具上，從而簡化工作流程並顯著減少環境切換。
MCP 如何提高軟體開發者的專注力？
若以單純的功能開發為例，傳統上軟體開發者得在多個系統之間來回切換，比方說於專案追蹤器中閱讀工單，透過通訊軟體查看跟同事的技術對話，並在資料庫中尋找 API 詳細資訊等，最後才是打開 IDE 實際撰寫程式碼。
然而，上述每個步驟其實都分散在不同視窗、不同平台、不同軟體之中，導致工程師必須不斷轉換思維，從而降低了功能開發速度。但是在借助 MCP 與當代 AI 助手，例如 Anthropic Claude 等工具之後，整個過程都將可以在 IDE 內完成，其具體實作將變成：
首先使用 Linear MCP 伺服器提取工單資料；接著透過 Slack MCP 伺服器顯示跟同事的對話；然後借助 Glean MCP 伺服器找到正確的技術文檔；最後利用 Cursor 要求 Claude 為新功能撰寫程式碼。
當然，相同的方法與原則，亦適用於其他工程師常見的工作流程，比方說網站可靠性工程（SRE）相關任務，其 MCP 與 AI 應用的整合流程就會是：
首先透過 Rootly MCP 伺服器拉取網站事件；再透過 Sentry MCP 伺服器檢索追蹤數據；然後利用 Chronosphere MCP 伺服器匯入觀察性指標；接著向 Claude 詢問相關錯誤的解決方法。
以 Slack 曾經帶來的工作革新為借鏡
雖然 AI 與 MCP 互相結合的工作流程，表面上看似十分新穎，但事實上卻有類似案例可循，例如在過去十年之間，Slack 平台已成為數百家企業、數百款應用程式的「中心」，徹底改變了工作場所的生產力，讓員工無需離開聊天視窗，即可輕鬆管理各種作業任務。
遊戲開發商 Riot Games 就曾經指出，公司仰賴近 1,000 個 Slack 應用程序，讓工程師發現、測試和迭代程式碼所需要的時間，大幅減少達 27%，發掘新錯誤的速度也加快了 22%，新功能上線成功率亦提高了 24%。
Riot Games 表示，前述進步全都要歸功於更加簡化的工作流程，以及 Slack 平台有效減少工程師日常作業的環境切換。
隨著 MCP 成為人工智慧模型連接外部工具的主要橋樑，軟體開發領域正在發生類似的轉變，未來 IDE 可能會成為工程師新的一體化指揮中心，就像 Slack 之於普通知識工作者一樣。
MCP 仍有痛點：安全性、超載處理與自動化
只不過 AI 與 MCP 也並非一開始就臻至完美，身為相對新興的標準，安全性方面 MCP 並沒有內建的身份驗證或權限模型，只能依賴仍在不斷發展的外部解決方案。
此外，MCP 在身分稽核方面也存在模糊性，因為該協定無法明確區分，究竟某個操作是由人類使用者或其他 AI 觸發，這使得在缺乏額外解決方案的情況下，問責和存取控制相對困難。
另一個 MCP 的應用限制則在於數量，即開發者同時連接過多 MCP 工具或伺服器時，可能會發生效能問題。由於每個 MCP 伺服器都包含各種描述與參數，讓連接的 AI 模型得以調用相關功能，當數十個 MCP 伺服器同時被單一 AI 模型存取時，上下文視窗處理就容易出現超載。
隨著 MCP 伺服器數量不斷增加，未來 AI 模型需要載入的參數將越來越多，處理效能自然會明顯下降；因此，部分 IDE 選擇實施硬性限制，例如 Cursor 僅開放連接約 40 個 MCP，OpenAI 則限制約 20 個，藉此防止提示詞過度灌入，膨脹到超出 AI 模型的處理能力。
目前業界仍然沒有開發出有效方式，讓 AI 模型自動選擇，或者根據上下文調用正確的 MCP 伺服器和工具，因此開發人員通常必須手動切換、管理，才能確保作業順利進行，這對企業始終希望 AI 自動化處理工作，減少人類干預以提升效率的目標來說，將是需要獲得解決的關鍵痛點。
MCP 減少環境切換，生產力自然提升
無論是即時推送更新的 Slack 頻道，或者「收件匣清零」的郵件管理方法，甚至是整合式的工程平台儀表板，綜觀過去十年的科技發展，企業已經充分理解到「將任務主動交到勞工手上」的重要價值。
如今，隨著 AI 成為全新利器，企業將有機會透過 MCP，賦予軟體開發人員更高效能的生產力，進一步令 AI 程式碼開發平台成為軟體創作的主要中心，匯聚各種相關內容與協作者，有效減少環境切換，使開發人員始終保持專注。
本圖/文由「Techorange科技報橘」授權刊登，非經同意不得任意轉載。
原文出處：工程師每天分心 1,200 次！AI 與 MCP 如何幫開發者「專心」？
