軟件開(kāi)發(fā)者大部分時(shí)間并非在編寫代碼；最新行業(yè)研究發(fā)現(xiàn)，實(shí)際編程僅占開(kāi)發(fā)者工作時(shí)間的16%，其余84%都被運(yùn)營(yíng)和支持性任務(wù)占用。當(dāng)工程團(tuán)隊(duì)被要求"用更少資源做更多事情"，CEO們吹噓他們的代碼庫(kù)有多少由AI編寫時(shí)，一個(gè)問(wèn)題仍然存在：如何優(yōu)化工程師們工作的其余84%的任務(wù)？

讓開(kāi)發(fā)者保持在最高效的狀態(tài)

影響開(kāi)發(fā)者生產(chǎn)力的主要因素是上下文切換：在構(gòu)建和交付軟件所需的日益增長(zhǎng)的工具和平臺(tái)之間不斷跳轉(zhuǎn)。哈佛商業(yè)評(píng)論研究發(fā)現(xiàn)，普通數(shù)字工作者每天在應(yīng)用程序和網(wǎng)站之間切換近1200次。每次中斷都很重要。加州大學(xué)發(fā)現(xiàn)，完全從單次中斷中重新獲得專注需要約23分鐘，有時(shí)更糟，因?yàn)榻?0%的被中斷任務(wù)永遠(yuǎn)不會(huì)被重新開(kāi)始。上下文切換實(shí)際上是DORA這一最受歡迎的軟件開(kāi)發(fā)性能框架的核心。

在AI驅(qū)動(dòng)的公司試圖讓員工用更少資源做更多事情的時(shí)代，除了"僅僅"給他們提供大語(yǔ)言模型訪問(wèn)權(quán)限外，一些趨勢(shì)正在涌現(xiàn)。例如，Brex首席工程師Jarrod Ruhland假設(shè)"開(kāi)發(fā)者在專注于集成開(kāi)發(fā)環(huán)境(IDE)時(shí)能交付最高價(jià)值"?；谶@一想法，他決定尋找新方法來(lái)實(shí)現(xiàn)這一點(diǎn)，而Anthropic的新協(xié)議可能是關(guān)鍵之一。

MCP：將上下文引入IDE的協(xié)議

編程助手，如由大語(yǔ)言模型驅(qū)動(dòng)的IDE（如Cursor、Copilot和Windsurf），正處于開(kāi)發(fā)者復(fù)興的中心。它們的采用速度前所未有。Cursor成為歷史上增長(zhǎng)最快的SaaS，在推出12個(gè)月內(nèi)就達(dá)到了1億美元的年度經(jīng)常性收入，財(cái)富500強(qiáng)公司中有70%使用Microsoft Copilot。

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

MCP最具影響力的應(yīng)用之一是能夠?qū)I編程助手直接連接到開(kāi)發(fā)者每天依賴的工具，簡(jiǎn)化工作流程并大幅減少上下文切換。

以功能開(kāi)發(fā)為例。傳統(tǒng)上，這涉及在多個(gè)系統(tǒng)之間跳轉(zhuǎn)：在項(xiàng)目跟蹤器中讀取工單、查看與團(tuán)隊(duì)成員的對(duì)話以獲得澄清、搜索文檔獲取API詳細(xì)信息，最后打開(kāi)IDE開(kāi)始編碼。每個(gè)步驟都在不同的標(biāo)簽頁(yè)中，需要心理轉(zhuǎn)換，這會(huì)拖慢開(kāi)發(fā)者的速度。

有了MCP和現(xiàn)代AI助手如Anthropic的Claude，整個(gè)過(guò)程可以在編輯器內(nèi)完成。例如，在編程助手內(nèi)實(shí)現(xiàn)功能的過(guò)程變?yōu)椋?/p>

- 使用Linear MCP服務(wù)器提取工單詳情；

- 使用Slack MCP服務(wù)器展示相關(guān)對(duì)話；

- 使用Glean MCP服務(wù)器引入正確的文檔；

- 通過(guò)詢問(wèn)Cursor為其編寫腳手架來(lái)編寫功能。

同樣的原理可以應(yīng)用于許多其他工程師工作流程，例如SRE的事件響應(yīng)可能如下：

- 通過(guò)Rootly MCP服務(wù)器提取事件；

- 通過(guò)Sentry MCP服務(wù)器檢索跟蹤數(shù)據(jù)；

- 通過(guò)Chronosphere MCP服務(wù)器導(dǎo)入可觀察性指標(biāo)；

- 通過(guò)詢問(wèn)Claude Desktop解決導(dǎo)致事件的錯(cuò)誤。

沒(méi)有什么新鮮事

我們以前見(jiàn)過(guò)這種模式。在過(guò)去十年中，Slack通過(guò)成為數(shù)百個(gè)應(yīng)用程序的中心來(lái)改變工作場(chǎng)所生產(chǎn)力，使員工能夠在不離開(kāi)聊天窗口的情況下管理各種任務(wù)。Slack的平臺(tái)減少了日常工作流程中的上下文切換。

例如，Riot Games連接了大約1000個(gè)Slack應(yīng)用程序，工程師看到測(cè)試和迭代代碼所需時(shí)間減少了27%，識(shí)別新錯(cuò)誤的時(shí)間加快了22%，功能發(fā)布率提高了24%；這些都?xì)w因于簡(jiǎn)化工作流程和減少工具切換的摩擦。

現(xiàn)在，軟件開(kāi)發(fā)中正在發(fā)生類似的轉(zhuǎn)變，AI助手及其MCP集成充當(dāng)連接所有這些外部工具的橋梁。實(shí)際上，IDE可能成為工程師的新一體化指揮中心，就像Slack對(duì)一般知識(shí)工作者一樣。

MCP可能還未企業(yè)就緒

MCP是一個(gè)相對(duì)新興的標(biāo)準(zhǔn)，例如，在安全方面，MCP沒(méi)有內(nèi)置的身份驗(yàn)證或權(quán)限模型，依賴于仍在發(fā)展的外部實(shí)現(xiàn)。在身份和審計(jì)方面也存在模糊性——協(xié)議沒(méi)有清楚地區(qū)分動(dòng)作是由用戶還是AI本身觸發(fā)的，這使得在沒(méi)有額外自定義解決方案的情況下，問(wèn)責(zé)制和訪問(wèn)控制變得困難。F5 Networks CTO辦公室的杰出工程師兼首席布道師Lori MacVittie說(shuō)，MCP"打破了我們長(zhǎng)期持有的核心安全假設(shè)"。

另一個(gè)實(shí)際限制出現(xiàn)在同時(shí)使用太多MCP工具或服務(wù)器時(shí)，例如在編程助手內(nèi)部。每個(gè)MCP服務(wù)器都會(huì)公布一個(gè)工具列表，包括AI模型需要考慮的描述和參數(shù)。用數(shù)十個(gè)可用工具淹沒(méi)模型可能會(huì)壓倒其上下文窗口。隨著工具數(shù)量的增長(zhǎng)，性能顯著下降，一些IDE集成已經(jīng)設(shè)置了硬限制（CursorE中約40個(gè)工具，或OpenAI智能體約20個(gè)工具）以防止提示超出模型能處理的范圍。

最后，除了列出所有工具外，沒(méi)有復(fù)雜的方式讓工具被自動(dòng)發(fā)現(xiàn)或根據(jù)上下文建議，因此開(kāi)發(fā)者經(jīng)常必須手動(dòng)切換它們或策劃哪些工具處于活動(dòng)狀態(tài)以保持平穩(wěn)運(yùn)行。參考Riot Games安裝1000個(gè)Slack應(yīng)用程序的例子，我們可以看到這可能不適合企業(yè)使用。

減少轉(zhuǎn)椅操作，增加軟件開(kāi)發(fā)

過(guò)去十年教會(huì)我們將工作帶給工作者的價(jià)值，從傳輸更新的Slack頻道到"收件箱零"電子郵件方法和統(tǒng)一平臺(tái)工程儀表板?，F(xiàn)在，有了AI工具包，我們有機(jī)會(huì)讓開(kāi)發(fā)者更有生產(chǎn)力。如果說(shuō)Slack成為了商業(yè)溝通的中心，那么編程助手很好地定位為軟件創(chuàng)建的中心，不僅是編寫代碼的地方，而且是所有上下文和協(xié)作者匯聚的地方。通過(guò)保持開(kāi)發(fā)者的流暢狀態(tài)，我們消除了困擾工程生產(chǎn)力的持續(xù)心理?yè)Q擋。

對(duì)于任何依賴軟件交付的組織，仔細(xì)審視開(kāi)發(fā)者如何度過(guò)他們的一天；你可能會(huì)對(duì)發(fā)現(xiàn)的情況感到驚訝。

Q&A

Q1：MCP協(xié)議是什么？它能解決什么問(wèn)題？

A：MCP（模型上下文協(xié)議）是Anthropic于2024年11月發(fā)布的開(kāi)放標(biāo)準(zhǔn)，旨在促進(jìn)AI系統(tǒng)與外部工具和數(shù)據(jù)源之間的集成。它主要解決開(kāi)發(fā)者在不同工具間頻繁切換的問(wèn)題，讓開(kāi)發(fā)者能在IDE內(nèi)直接訪問(wèn)項(xiàng)目跟蹤器、聊天工具、文檔等，減少上下文切換。

Q2：開(kāi)發(fā)者為什么需要減少上下文切換？

A：研究發(fā)現(xiàn)開(kāi)發(fā)者每天在應(yīng)用程序和網(wǎng)站之間切換近1200次，每次中斷后需要約23分鐘才能重新獲得專注，而近30%的被中斷任務(wù)永遠(yuǎn)不會(huì)被重新開(kāi)始。實(shí)際編程僅占開(kāi)發(fā)者工作時(shí)間的16%，其余84%被運(yùn)營(yíng)和支持性任務(wù)占用，減少上下文切換能顯著提高生產(chǎn)力。

Q3：MCP協(xié)議在企業(yè)應(yīng)用中有什么限制？

A：MCP目前還不夠企業(yè)就緒，主要限制包括：沒(méi)有內(nèi)置的身份驗(yàn)證或權(quán)限模型；無(wú)法區(qū)分動(dòng)作是由用戶還是AI觸發(fā)，存在安全風(fēng)險(xiǎn)；同時(shí)使用太多工具會(huì)壓倒模型的上下文窗口；缺乏工具的自動(dòng)發(fā)現(xiàn)機(jī)制，需要手動(dòng)管理。