【AIbase 報道】最新行業研究顯示，軟件開發人員實際用於編寫代碼的時間僅佔 16%，其餘 84% 則被運營與支持任務消耗。在“降本增效”的壓力下，AI 編碼助手雖能加速代碼生成，卻無法解決最影響開發效率的問題——上下文切換。

《哈佛商業評論》研究發現，知識工作者平均每天在應用與網站間切換 1，200次，而一次中斷後恢復專注需要 23分鐘，近三成任務甚至永遠無法恢復。加州大學研究同樣指出，這種碎片化切換已成爲開發效率的最大隱形殺手。

MCP

在此背景下，Anthropic 於2024年11月推出的模型上下文協議（MCP） 正受到關注。MCP 是一項開放標準，可讓基於 LLM 的編碼助手（如 Cursor、Copilot、Windsurf）直接接入外部工具和數據源，減少開發者在 IDE 與其他系統之間來回切換。過去半年，MCP 服務器數量增長了 500%，6月下載量預計已達 700萬次。

在 MCP 驅動下，開發者可以在 IDE 內完成從需求讀取、文檔查找到代碼實現的完整流程。例如，功能開發可通過 Linear MCP 拉取工單、Slack MCP 獲取團隊對話、Glean MCP 引入文檔，最後再由 Claude 或 Cursor 自動生成腳手架。同樣，SRE 的事件響應也能在 IDE 內完成，從 Rootly 拉取事件，到 Sentry 檢索追蹤數據，再由 Claude 協助診斷。

這一模式類似十年前 Slack 的崛起:通過聚合上千個應用，Slack 成爲知識工作者的中心樞紐。Riot Games 報告顯示，Slack 集成後工程師代碼迭代效率提升 27%，功能發佈速度提升 24%。如今，IDE 有望藉助 MCP，成爲開發者的新一代“統一指揮中心”。

但 MCP 仍存在侷限。其協議缺乏內置身份認證和權限控制，安全與審計邊界模糊;當工具數量過多時，模型的上下文窗口容易被壓垮，導致性能下降。目前 Cursor 僅允許加載約 40個工具，OpenAI 代理約 20個。此外，MCP 還缺乏智能工具推薦機制，開發者需手動管理工具激活狀態。

儘管挑戰存在，業內普遍認爲 AI 驅動的 IDE 將像 Slack 改變企業溝通一樣，重塑軟件開發模式。減少“旋轉椅效應”，讓開發者在一個平臺內專注創造，可能是下一階段工程生產力的關鍵突破口。