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

讓開發(fā)人員保持最高效的狀態(tài)

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

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

MCP：為IDE帶來上下文的協(xié)議

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

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

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

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

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

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

? 使用Linear MCP服務(wù)器獲取任務(wù)單詳情;

? 使用Slack MCP服務(wù)器顯示相關(guān)對話;

? 使用Glean MCP服務(wù)器獲取相關(guān)文檔;

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

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

? 通過Rootly MCP服務(wù)器獲取事件信息;

? 通過Sentry MCP服務(wù)器檢索追蹤數(shù)據(jù);

? 通過Chronosphere MCP服務(wù)器導(dǎo)入可觀測性指標(biāo);

? 要求Claude Deskop解決導(dǎo)致該事件的系統(tǒng)漏洞。

太陽底下無新事

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

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

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

MCP可能尚未做好企業(yè)級應(yīng)用的準(zhǔn)備

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

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

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

減少頻繁切換，專注軟件開發(fā)

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

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

對于任何依賴軟件交付的企業(yè)來說，都應(yīng)該仔細(xì)審視開發(fā)人員的一天是如何度過的，你可能會對自己的發(fā)現(xiàn)感到驚訝。