我对2026年MCP和AI辅助编码的预测
Source: Dev.to
请提供您希望翻译的正文内容，我将为您翻译成简体中文。
介绍
我写下这些时完全意识到，关于 AI 的预测往往很快就会过时。
我不想听起来像那些自信宣称 AI 将在六个月内取代工程师的 CEO，结果当什么都没发生时又悄悄推迟时间表。相反，这只是一次个人的思考实验。
我自从 AI 辅助编码仍被视为禁忌时就开始尝试。2021 年我在 GitHub 工作时开始，帮助开发者通过 GitHub Copilot 了解精心编写提示的价值。
我是 ChatGPT 的早期用户之一，同时使用 Claude 和许多其他工具，早在 提示工程 成为独立学科之前。
如今，我是 goose 的 Developer Advocate，它是 Model Context Protocol (MCP) 的参考实现，也是首批 MCP 客户端之一。我每天使用多个 MCP 服务器来解决实际问题。
所有这些让我对事物未来可能的走向有了一定的感知。
于是，我决定对 2026 做出一些预测，主要是为了磨练自己的远见能力。这些预测会实现吗？一年后我会对它们进行调整吗？让我们拭目以待。
这些是我的个人观点。我并不代表我的雇主或我参与的任何项目发言。
预测 1：AI 代码审查得到解决
到 2026 年底，我相信我们将破解 AI 驱动的代码审查。
目前，软件开发——尤其是开源领域——面临的最大瓶颈之一是审查能力。人们借助 AI 生成代码的速度前所未有，但这种速度把压力转移到了下游。维护者、技术负责人和工程经理现在要面对更多的 Pull Request、更多的 diff，以及更大的验证工作量。
我们已经看到 AI 驱动的代码审查工具，但没有一个能够完全满足需求。它们常常显得噪音太大、过于僵硬，或与真实的开发者工作流脱节，导致采用率参差不齐。
最近，Aiden Bai 公开分享了深思熟虑且建设性的反馈，指出像 CodeRabbit 这样的 AI 代码审查工具可以改进的地方。除了围绕 CodeRabbit 响应方式的争议之外，他的推文所获得的关注表明了一件重要的事：开发者们正积极期待更好的解决方案。
到 2026 年，我预计要么现有产品会显著升级，要么会有新公司进入该领域并把它做好。这是该领域最紧迫的问题之一，我认为业界会把解决它放在优先位置。
如果你想跟踪 AI 代码审查的最新进展，建议关注 Nnenna Ndukwe。
Prediction 2: MCP Apps 成为默认
我认为 MCP Apps 将成为人们与 AI 代理交互的核心部分。
MCP Apps 是 MCP‑UI 的继任者，后者首次展示了代理不必仅以文本回应，而是可以直接在宿主环境中渲染交互式界面——比如嵌入式网页 UI、按钮、切换开关和选择项。用户通过交互而非解释来表达意图。
随着这种模式获得关注，显而易见交互式界面需要在协议本身中获得一等支持。MCP Apps 在此基础上继续发展，并已被纳入 MCP 标准。
这不仅关系到开发者的使用体验。多年来，公司试图通过嵌入式聊天机器人把用户留在自己的应用中，期望提升“黏性”从而带来收入，但这种做法从未彻底奏效。与此同时，用户行为发生了转变：人们现在直接使用 ChatGPT 等 AI 工具获取答案，而不是浏览网站，即使他们并非工程师。
MCP Apps 颠覆了这一模型。 与其把用户拉进你的应用，你的应用则在用户的 AI 环境中与他们相遇。
我们已经看到早期采纳：
- OpenAI 正在通过 ChatGPT Apps SDK 向此方向前进。
- goose 早期采用了 MCP‑UI（YouTube short），并接近推出完整的 MCP Apps 支持。
- 其他平台也在采取类似的举措。
想了解更多关于 MCP Apps 的信息，请查看这篇 blog post。
预测 3：代理跨平台可移植
我认为代理会跟随用户到他们工作的任何地方。
如今，MCP 服务器使得将代理连接到工具和系统成为可能，我也大量使用它们。但仍然存在摩擦。许多用户对特定代理产生依赖，希望它能在不同环境中使用，而无需不断重新配置。
这就是 Agent Client Protocol (ACP) 变得有趣的地方。ACP 允许代理在任何支持该协议的编辑器或环境中运行，而不必与特定插件或扩展紧密耦合。
我们在使用 goose 时亲身感受到了这种痛点。维护 VS Code 扩展非常困难：goose 会不断演进，而扩展却滞后，导致用户频繁遇到破坏。ACP 改变了这种局面。代理不再与插件紧耦合，编辑器本身充当客户端。
- Zed Industries 引入了这种模型。当我在 Zed 编辑器中尝试 goose 时，体验明显更流畅。
- 来自 JetBrains 的编辑器也已采用该协议。
ACP 相较于 MCP 获得的关注更少，部分原因是它不够炫目，部分原因是其缩写与其他代理相关协议重叠。即便如此，它的影响是真实存在的。
展望未来： 我认为这不会止步于编辑器。随着时间推移，代理的可移植性可能会扩展到设计工具、浏览器以及其他平台。我可以想象将 goose、Codex 或 Claude Code 直接带入 Figma 等工具，而无需每次都重新构建集成。这部分更具推测性，但方向是合理的。
Prediction 4: DIY Agent Configuration Hits a Ceiling
这句话说出来感觉更冒险
(原文在此处被截断；预测未完成。)
对 AI 代理配置的思考
“我们最终会摆脱繁重的上下文工程和过度的配置。”
目前，我们通过添加结构层来弥补模型的局限性：
- 规则文件
- 记忆文件
- 子代理
- 可复用技能
- 系统提示覆盖
- 开关和切换
所有这些都有助于代理更可靠地行为，在许多情况下它们是必需的——尤其是对于大型代码库、遗留系统以及高影响力的代码更改。
为什么我感到兴奋
作为一名工程师，配置我的环境让我有参与感。我喜欢塑造代理的推理和响应方式。调校行为而不是把 AI 当作黑箱，能带来满足感。
另一面
每周都会出现新的“最佳实践”。又一条规则。又一种配置，用户感到必须采用。到某个时候，开销可能超过收益。人们不再专注于构建，而是花更多时间去配置构建的过程。
我已经看到开发者选择退出。有些人因为早期体验不佳而拒绝 AI。还有人因为过程让人疲惫而拒绝。他们只想写代码。
与 Kubernetes 的类比
当 Kubernetes 被广泛采用时，它释放了巨大的力量，但也让开发者面对他们本不该管理的基础设施复杂性。解决方案不是让每个开发者都成为 Kubernetes 专家，而是引入 平台团队、DevOps 角色 和 抽象层 来吸收这些复杂性。
两条可能的前进路径
- 工具改进，以至于大多数配置淡出视野。
- 公司正式化围绕 AI 赋能的角色。
- 我们已经看到这种早期形态：内部 AI 冠军和赋能小组（由我的经理 Angie Jones 领导），帮助团队安全、有效地使用代理。
我的期望
我希望保持平衡。我喜欢配置和深度，但如果每个仓库都需要复杂的设置才能开始，我认为生产力难以提升。
Predictions for 2026
- 降低摩擦：配置将大多自动化或隐藏在直观的 UI/UX 背后。
- AI 赋能团队：专职角色（AI 冠军、平台工程师）将在大型组织中成为标准配置。
- 标准化最佳实践套件：可复用、经过审查的配置，可最小化工作量直接放入代码库。
- 更高的采纳率：由于“疲劳”因素减弱，选择不使用的开发者会更少。
“让我们一年后再回顾，看看哪些仍然有效。”
您的预测是什么？
- 您如何看待可配置性与可用性之间的平衡演变？
- 您是否认同上述的两条路径，还是设想其他的轨迹？
期待听到您的想法！