軟件開發人員的大部分時間并非用于編寫代碼，近期行業研究發現，實際編碼僅占開發人員工作時間的16%，其余時間則被運營和支持性任務所消耗。隨著工程團隊面臨“用更少的資源做更多的事”的壓力，以及CEO們吹噓其代碼庫有多少是由AI編寫時，一個問題依然存在：如何優化工程師正在處理的其他84%的任務?

讓開發人員保持最高效的狀態

影響開發人員效率的一個主要因素是在工具和平臺之間的切換：即在構建和交付軟件所需不斷增多的工具和平臺之間頻繁切換。哈佛商業評論的一項研究發現，普通數字工作者每天要在應用程序和網站之間切換近1200次，每一次中斷都很重要。加州大學研究發現，在受到一次中斷后，人們需要大約23分鐘才能完全重新集中注意力，有時情況會更糟，因為近30%被中斷的任務永遠無法再繼續。不同工具和平臺之間的切換實際上是DORA(一個最受歡迎的軟件開發性能框架)的核心，DORA即DevOps研究與評估框架。

在AI驅動的公司試圖讓員工“用更少的資源做更多的事”的時代，除了“僅僅”讓他們使用大語言模型(LLM)外，還出現了一些趨勢。例如，Brex的首席工程師Jarrod Ruhland假設“開發人員在其集成開發環境(IDE)中集中精力時，能夠創造最大的價值”。考慮到這一點，他決定尋找新的方法來實現這一目標，而Anthropic的新協議可能就是關鍵之一。

MCP：為IDE帶來上下文的協議

以Cursor、Copilot和Windsurf等由大語言模型驅動的IDE為代表的編碼助手，正處于開發人員復興的核心位置，其普及速度前所未有。Cursor成為歷史上增長最快的SaaS公司，在發布后的12個月內年經常性收入(ARR)就達到了1億美元，而70%的《財富》500強企業都在使用微軟的Copilot。

但這些編碼助手僅限于代碼庫上下文，雖然可以幫助開發人員更快地編寫代碼，但卻無法解決不同工具和平臺之間的切換問題。一項新協議正在解決這一問題：模型上下文協議(Model Context Protocol，MCP)，該協議由Anthropic于2024年11月發布，是一個旨在促進AI系統(特別是基于大語言模型的工具)與外部工具和數據源之間集成的開放標準，該協議非常受歡迎，在過去6個月中，新的MCP服務器數量增長了500%，6月份的下載量估計達到了700萬次。

MCP最具影響力的應用之一是，它能夠將AI編碼助手直接與開發人員日常依賴的工具連接起來，從而簡化工作流程并大幅減少不同工具和平臺之間的切換。

以功能開發為例，傳統上，這需要在多個系統之間來回切換：在項目跟蹤器中閱讀任務單、與團隊成員交談以尋求澄清、搜索文檔以獲取應用程序編程接口(API)詳細信息，最后打開IDE開始編碼。每一步都在不同的標簽頁中進行，需要開發人員進行思維轉換，從而降低效率。

有了MCP和Anthropic的Claude等現代AI助手，整個過程都可以在編輯器內完成。

例如，在編碼助手中實現一個功能的過程如下：

? 使用Linear MCP服務器獲取任務單詳情;

? 使用Slack MCP服務器顯示相關對話;

? 使用Glean MCP服務器獲取相關文檔;

? 要求Cursor為其編寫框架代碼，從而編寫該功能。

同樣的原則也適用于許多其他工程師的工作流程，例如，站點可靠性工程師(SRE)的事件響應流程可能如下：

? 通過Rootly MCP服務器獲取事件信息;

? 通過Sentry MCP服務器檢索追蹤數據;

? 通過Chronosphere MCP服務器導入可觀測性指標;

? 要求Claude Deskop解決導致該事件的系統漏洞。

太陽底下無新事

我們以前見過這種模式，在過去十年中，Slack通過成為數百個應用的中心樞紐，改變了職場生產力，使員工無需離開聊天窗口即可管理各種任務。Slack平臺減少了日常工作流程中的不同工具和平臺之間的切換。

例如，Riot Games連接了約1000個Slack應用，工程師們發現，測試和迭代代碼所需的時間減少了27%，識別新漏洞的速度提高了22%，功能發布率提高了24%，所有這些改善都歸功于工作流程的簡化和工具切換摩擦的減少。

現在，軟件開發領域也正在發生類似的變革，AI助手及其MCP集成成為連接所有這些外部工具的橋梁。實際上，IDE可能會成為工程師新的全能指揮中心，就像Slack對于普通知識工作者一樣。

MCP可能尚未做好企業級應用的準備

MCP是一個相對較新的標準，例如，從安全角度來看，MCP沒有內置的身份驗證或許可模型，而是依賴于仍在不斷發展的外部實現，此外，在身份識別和審計方面也存在模糊性——該協議無法明確區分某個操作是由用戶觸發的還是由AI本身觸發的，因此，如果沒有額外的定制解決方案，就難以實現問責和訪問控制。F5 Networks的首席技術官辦公室杰出工程師兼首席布道師Lori MacVittie表示，MCP正在“打破我們長期以來堅持的核心安全假設”。

另一個實際限制出現在編碼助手內部同時使用過多MCP工具或服務器時。每個MCP服務器都會公布一份工具列表，其中包含描述和參數，供AI模型考慮。用數十個可用工具淹沒模型會使其上下文窗口不堪重負。隨著工具數量的增加，性能會明顯下降，因此一些IDE集成設置了硬性限制(Cursor IDE中約為40個工具，OpenAI代理中約為20個工具)，以防止提示超出模型的處理能力。

最后，除了列出所有工具外，目前還沒有更高級的方法來自動發現或根據上下文建議工具，因此開發人員通常需要手動切換工具或精心挑選要激活的工具，以保持工作流程的順暢。參考Riot Games安裝1000個Slack應用的例子，我們可以看出這可能不適合企業使用。

減少頻繁切換，專注軟件開發

過去十年告訴我們，將工作帶到工作者身邊的價值，從推送更新的Slack頻道到“零收件箱”電子郵件管理方法，再到統一的平臺工程儀表板?，F在，隨著AI成為我們的工具包的一部分，我們有機會讓開發人員更高效地工作。假設Slack已成為商業溝通的中心樞紐。

那么，在這種情況下，編碼助手很有可能成為軟件創建的中心樞紐，不僅是編寫代碼的地方，也是所有上下文和協作者匯聚的地方。通過讓開發人員保持專注，我們消除了長期以來困擾工程生產力的頻繁思維轉換。

對于任何依賴軟件交付的企業來說，都應該仔細審視開發人員的一天是如何度過的，你可能會對自己的發現感到驚訝。