你是否曾尝试让 AI 帮你调试 Next.js 项目？
说实话，我试过。有一次，我在浏览器里看到一个报错，于是将错误信息复制粘贴给了 Cursor，告诉它“帮我修一下这个错误”。结果 AI 的表现令人失望——它显得一脸茫然，根本不明白我在说什么。
后来我才意识到问题的根源：AI 看不见浏览器。
那些运行时错误、客户端警告、实际渲染出来的组件结构，对 AI 来说完全是个黑盒。它只能看到静态的代码文件，却无法感知代码在浏览器中实际执行时发生了什么。这就好比让一位医生只看病历而不做任何检查，想准确诊断几乎是不可能的。
而这，正是 Next.js 团队在过去一年中着力解决的核心挑战。
问题本质：Agent 的“视觉盲区”
今年早些时候，Next.js 团队在优化开发者工具时，观察到了一个有趣但低效的模式。
他们注意到开发者的典型流程是：首先在浏览器中看到错误，然后手动复制错误详情，再粘贴到某个 AI 编辑器（如 Cursor）中，最后请求 AI 进行修复。
这个过程不仅繁琐，还暴露了一个更深层的问题——AI 对于浏览器内发生的一切是完全盲视的。
浏览器中的运行时错误、客户端 JavaScript 警告、动态渲染的组件树，这些对 AI 均不可见。当你对 AI 说“帮我修复这个错误”时，它甚至无法确定你指的是哪一个错误。
最初，团队尝试了两个小规模的优化：
- 改进了控制台的“复制”按钮，将错误信息结构化为更易 AI 理解的格式。
- 将浏览器日志转发到开发终端中。
但这些措施只是权宜之计，并未触及根本。真正的解决思路应该是：让 Next.js 框架的内部状态对 Agent 变得可见。
初次探索：将 AI 直接塞进浏览器
顺着这个思路，团队萌生了一个大胆的想法：为何不直接在 Next.js 开发环境中内置一个 AI 助手呢？
于是，他们创造了 Vector。
这个听起来很酷的项目，本质上是一个内置于浏览器 DevTools 中的聊天式 AI Agent。它有点类似于 react-grab，但与 Next.js 深度集成。你可以选中页面上的任何 UI 元素，直接查看其对应的源代码，然后通过对话指令让 AI 进行修改。它还内置了 Next.js 的最佳实践知识库，以避免 AI 给出不符合框架规范的“幻觉”回答。
听起来很完美，对吧？
但现实是——开发者们并不买账。
原因在于，Vector 的功能与 Cursor、Claude Code 等主流的通用 AI 编程工具高度重叠。大多数开发者早已习惯了这些成熟工具的工作流，不愿为了 Next.js 单独再去学习和适应另一套界面。Vector 提供的元素选中功能虽然方便，但并未构成不可替代的“刚需”。
因此，Vector 项目最终被搁置了。
然而，这次尝试并非毫无价值。Vector 验证了两个核心价值点，并被团队保留下来：
- 结构化的可见性——让 AI 能够“看到”框架的内部运行时状态。
- 框架专属知识——让 AI 理解并遵循 Next.js 的最佳实践。
团队决定，将这些能力直接“内置”（built-in）到 Next.js 框架本身，而不是作为一个独立工具存在。
转向 MCP：为 Agent 打开“视野”
到了 2025 年 10 月，随着 Next.js v16 的发布临近，问题变得更加尖锐。
当用户请求 AI 协助调试时，最常见的提示（Prompt）是“帮我修复这个错误”。AI 通常会去获取页面的 HTML，但结果却发现——页面看起来完全正常啊？
这是因为运行时错误、浏览器 JavaScript 执行错误、异步加载错误等都发生在浏览器端，而不在服务端返回的初始 HTML 中。实际渲染出的页面、基于布局的组件分段、路由状态、内部 React 状态等，AI 全都无法感知。
就在这时，MCP（Model Context Protocol） 进入了团队的视野。
MCP 提供了一种标准化的协议，用于向 AI Agent 暴露这些内部数据。第一版实现主要暴露了错误堆栈、路由信息、渲染分段等内部状态。但仅仅有数据接口还不够，AI 还需要能够自动发现正在运行的 Next.js 开发服务器并与之建立通信。
于是，next-devtools-mcp 应运而生。
现在，AI 可以做到：
- 查看 Next.js 应用内部的运行时错误和组件状态。
- 获取与当前上下文相关的官方文档片段。
- 执行诸如缓存组件迁移等特定操作。
此外，MCP 服务还内置了一些预设的提示词（prompts）和工具（tools），专门帮助 AI 处理版本升级和代码迁移任务。例如，你可以询问 AI“use cache 是做什么用的？”，它会准确地提供相关的文档和代码上下文，而不是凭空猜测。
核心洞察：将 Agent 视为“一等用户”
MCP 的成功，印证了 Vector 项目带来的深刻教训。
让 Agent 能够“看到” Next.js 在做什么，这固然重要，但只是表象。更深层的启示在于：我们需要将 AI Agent 视为 Next.js 框架的“一等用户”，并从它们的视角出发来重新设计开发者体验。
- AI 在什么场景下需要信息？
- 它需要哪些特定格式的信息？
- 它如何最有效地消费这些信息？
这些问题贯穿了所有后续的设计决策。
既然 AI 在开发时会关注终端输出，那么我们就将 Server Action 的调用日志清晰地打印出来，把浏览器错误实时转发到终端，为 AI 提供充足的调试线索。
既然 AI 难以理解训练数据中未包含的新框架概念，那么我们就提供一个压缩版的文档索引 agents.md，或者设计出结构化的指导工作流（如 Next.js Skills），为 AI 提供比原始文档更精准的上下文。
这些具体需求驱动了所有功能的落地：
- 需要可见性 → 实现更详尽、结构化的日志系统。
- 需要知识 → 创建轻量化的
agents.md 知识索引。
- 需要发现与交互能力 → 开发并集成 MCP 协议。
当你真正将 Agent 视为一等用户，并在它们的工作流中与其“相遇”时，调试就不再是割裂的步骤，而变成了代码、运行时和 AI 之间一个紧密协作的实时反馈循环。
未来展望
目前，团队正致力于让这套方案变得更加易用。
你现在已经可以通过运行 npx @next/codemod 命令来生成最新的文档索引。团队还在扩展测试套件，以覆盖更多 Next.js 16 的新 API，从而更科学地评估哪些信息对 AI 真正有帮助。
更长远的目标，是将这些能力深度集成到 next dev 命令中，让 AI 在无需任何额外配置的情况下，就能自动获得正确的上下文信息。
这确实是一个值得期待的方向。
我们使用了这么多年的 IDE 和调试工具，早已习惯了从“人类开发者”的视角来设计一切。但现在，AI 已经成为开发流程中不可或缺的一部分，框架本身是否也应该为它们进行优化？
Next.js 团队选择的这条路——不是再造一个 AI 工具，而是让整个框架变得对 AI 更加友好——或许触及了更本质的解决方案。
参考链接：
- 原文：Building Next.js for an agentic future
- MCP 集成详情：Next.js MCP Tools
本文技术观点讨论于云栈社区，一个专注于前端框架与人工智能应用的开发者交流平台。
发表于 昨天 07:55
|
查看: 6|
回复: 0
