软件开发人员大部分时间并不在编写代码；最新行业研究发现，实际编码仅占开发者工作时间的16%，其余被运营和支持性任务消耗。当工程团队被迫"以少做多"而CEO们吹嘘有多少代码库由AI生成时，一个问题依然存在：如何优化工程师剩余84%的工作任务？
让开发者留在最高效的领域
开发者生产力的主要杀手是上下文切换：在构建和交付软件所需的日益增长的工具平台间不断跳跃。《哈佛商业评论》研究发现，普通数字工作者每天要在应用和网站间切换近1,200次。每次干扰都影响重大。加州大学研究发现，单次干扰后平均需要23分钟才能完全恢复专注，更糟的是近30%被打断的任务永远不会被继续。上下文切换实际上是DORA（最流行的软件开发性能框架之一）的核心问题。
在AI驱动企业试图让员工"以少做多"的时代，除了"仅仅"提供大语言模型（LLM）访问权限外，一些趋势正在显现。例如Brex首席工程师Jarrod Ruhland提出假设："开发者在集成开发环境（IDE）内专注时能创造最高价值"。基于此，他寻找实现这一目标的新方法，而Anthropic的新协议可能是关键之一。
MCP：为IDE带来上下文的协议
Cursor、Copilot和Windsurf等基于LLM的编码助手正处于开发者复兴的中心。它们的采用速度前所未见——Cursor成为历史上增长最快的SaaS，发布12个月内ARR达1亿美元，70%的财富500强公司使用Microsoft Copilot。
但这些编码助手此前仅限代码库上下文，虽能加速编码却无法解决上下文切换问题。新协议Model Context Protocol（MCP）正解决此问题：这个由Anthropic于2024年11月发布的开源标准，旨在促进AI系统（尤其是基于LLM的工具）与外部工具及数据源的集成。该协议火爆到过去6个月新增MCP服务器增长500%，预计6月下载量达700万次。
MCP最具影响力的应用是能将AI编码助手直接连接开发者日常依赖的工具，从而精简工作流并大幅减少上下文切换。
以功能开发为例：传统流程需要在多个系统间跳转——查看项目跟踪器中的任务单、翻阅队友对话记录澄清需求、搜索API文档，最后才打开IDE开始编码。每个步骤都在不同标签页完成，需要思维转换从而拖慢开发速度。
通过MCP和Anthropic的Claude等现代AI助手，整个流程可在编辑器内完成。例如在编码助手中完整实现功能变为：
该原理同样适用于其他工程师工作流，例如SRE的事件响应可呈现为：
太阳底下无新事
我们曾见证类似模式。过去十年，Slack通过整合数百个应用成为工作生产力中心，让员工无需离开聊天窗口就能处理各类任务。Slack平台减少了日常工作中的上下文切换。
例如Riot Games连接了约1,000个Slack应用后，工程师代码测试迭代时间减少27%，新bug识别速度提升22%，功能发布率提高24%——这些都归功于工作流简化和工具切换摩擦减少。
如今软件开发领域正发生类似变革，AI助手及其MCP集成成为连接外部工具的桥梁。实际上，IDE可能成为工程师的新型一体化指挥中心，就像Slack之于普通知识工作者。
MCP可能尚未达到企业级
MCP仍是较新的标准。例如在安全层面，MCP没有内置身份验证或权限模型，依赖仍在演进的外部实现方案。身份识别和审计方面也存在模糊性——协议无法明确区分操作是由用户还是AI触发，若无额外定制方案则难以实现责任追溯和访问控制。F5网络CTO办公室杰出工程师Lori MacVittie指出，MCP"打破了我们长期持有的核心安全假设"。
另一个实际限制出现在同时使用过多MCP工具或服务器时（例如编码助手中）。每个MCP服务器会广播工具列表及其描述参数供AI模型参考。当可用工具数量激增时，可能压垮模型的上下文窗口。随着工具数量增加，性能明显下降——部分IDE集成已设置硬性限制（如Cursor IDE约40个工具，OpenAI代理约20个工具）以防止提示词膨胀超出模型处理能力。
最后，目前尚无超越简单列举的高级工具自动发现或上下文建议机制，因此开发者常需手动切换或管理活动工具以保持流畅运行。参考Riot Games安装1,000个Slack应用的案例，可以看出其可能不适合企业使用。
减少转椅运动，专注软件开发
过去十年我们已见识到"让工作找人"的价值——从Slack频道推送更新，到"收件箱清零"邮件方法论，再到统一平台工程仪表板。如今借助AI工具，我们有机会让开发者更高效。如果说Slack已成为商业通信中心。
那么编码助手完全有潜力成为软件创作中心——不仅是写代码的场所，更是所有上下文与协作者汇聚之地。通过保持开发者的心流状态，我们消除了长期困扰工程生产力的思维齿轮切换。
任何依赖软件交付的组织都应认真审视开发者的时间分配——你可能会对发现的结果感到惊讶。
Sylvain Kalache现任Rootly人工智能实验室负责人。
