图片来源：a16z

Z Highlights

• 与其说有几个框架主导了整个生态系统，不如说我们将看到更多的可组合、栈特定的生成方式，其中工具和架构可以动态组合。

• Agent不再需要点击像素位置或抓取DOM，而是可以像辅助技术一样——从语义上观察应用程序。

• MCP客户端和服务器是逻辑上的边界，而不是物理边界。

开发者们已经不再将AI仅仅视为工具，而是开始将其视为构建软件的新基础。我们曾经理所当然接受的许多核心概念——版本控制、模板、文档，甚至用户的概念——由Agent驱动的workflow面前，它正在被重新思考。

Agent正在兼具合作者、消费者的身份，我们预计基础开发工具会发生变化。prompt语可以像源代码一样对待，仪表板可以变得像对话一样，文档既是为人类写的，也是为机器编写的。MCP（模型上下文协议）和IDE（AI本土集成开发环境）指向开发循环本身的更深层次重构：我们不仅仅在编写代码，更在为一个Agent完全参与软件循环的世界设计工具。

接下来，我们将探讨九种前瞻性的开发者模式，尽管它们仍处于早期阶段，但它们扎根于实际的痛点，并展露出未来可能出现的趋势。这些模式包括重新思考AI生成代码的版本控制，基于大语言模型（LLM）的用户界面和文档等。

让我们深入了解每个模式，并通过开发者社区的示例和见解进行分析。

AI本土Git：重新思考AI Agent的版本控制

现在，AI Agent越来越多地编写或修改应用程序代码的大部分内容，开发者关心的事情开始发生变化。我们不再专注于逐行编写的代码，而是关注输出是否按预期行为运行。更改通过测试了吗？应用程序仍按预期工作吗？

这颠覆了一个长期存在的思维模型：Git设计用来跟踪手工编写代码的精确历史，但在有编码Agent的情况下，这种精细度变得不那么重要。开发者通常不会审查每个差异——尤其是当更改较大或自动生成时——他们只关心新行为是否与预期结果一致。因此，Git SHA——曾经是“代码库状态”的标准引用——开始失去一些语义价值。

一个SHA告诉你某些内容已更改，但并未告诉你为什么更改，或者它是否有效。在以AI为主的workflow中，一个更有用的unit of truth可能是生成代码的prompt和验证其行为的测试的组合。在这种情况下，你的应用程序“状态”可能更好地通过生成输入（prompt、规范、约束）和一套通过的断言来表示，而不是一个冻结的commit hash。我们最终可能会将prompt+测试包作为可版本控制的单元来追踪，而Git则被用来追踪这些包，而不仅仅是原始源代码。

更进一步：在Agent驱动的workflow中，source of truth可能会上移到prompt、数据模式、API合同和架构意图。代码成为这些输入的副产品，更像是编译后的工件，而不是手动编写的源代码。在这个世界里，Git开始不再作为工作空间，而更多地作为一个工件日志——用于跟踪不仅是什么发生了变化，还要追踪变化的原因和是谁做的。我们可能会开始添加更丰富的元数据，例如哪个Agent或模型进行了更改，哪些部分是受保护的，以及哪些地方需要人工监督——或者像Diamond这样的AI审阅者可以介入循环。

为了使这一点更加具体，以下是一个AI本土Git工作流的实践效果图：

图片来源：a16z

数据看板 -> 综合：动态AI驱动的界面

多年来，数据看板一直作为与复杂系统（如可观察性堆栈、分析工具、云控制台（例如AWS）等）进行交互的主要界面。但它们的设计往往存在用户体验过载的问题：有太多的旋钮、图表和标签，迫使用户既要寻找信息，又要弄清楚如何采取行动。特别是对于非高级用户或跨团队使用者，这些数据看板可能变得令人生畏或效率低下。用户知道自己想要达成什么目标，但却不知道应该在哪里查看，或应该应用哪些过滤器才能达到目标。

最新一代的AI模型提供了潜在的变革。可以不再将数据看板视为僵化的界面，而是将搜索和交互功能叠加进去。LLM现在可以帮助用户找到合适的控制项（例如：“我在哪里可以调整这个API的速率限制设置？”）；将全屏的数据综合成可消化的洞察（例如：“总结过去24小时内所有服务在预发布环境中的错误趋势”）；并揭示未知的未知（例如：“根据你对我的业务的了解，生成我应该关注的本季度指标清单”）。

我们已经看到了像Assistant UI这样的技术解决方案，让Agent能够将React组件作为工具使用。就像内容已经变得动态和个性化一样，UI本身也可以变得适应性强和具有对话性。一个完全静态的数据看板很快就会显得过时，尤其是在与基于自然语言驱动的界面相比时，后者会根据用户的意图重新配置。例如，用户不必通过点击五个过滤器来隔离指标，而是可能会说：“显示上周末在欧洲的异常情况”，数据看板会重新调整以显示该视图，并附上总结的趋势和相关日志。或者，更强大的是，用户说：“为什么我们的NPS得分在上周下降？”AI可能会提取调查情感数据，将其与产品部署相关联，并生成一份简短的诊断报告。

在更大的规模上，如果Agent现在是软件的使用者，我们可能还需要重新思考“数据看板”是什么，或者它们是为谁设计的。例如，数据看板可以呈现出优化的Agent体验视图——结构化的、可编程访问的界面，旨在帮助Agent感知系统状态、做出决策并采取行动。这可能会导致双模式界面：一个面向人类，另一个面向Agent，二者共享相同的状态，但根据不同的使用方式进行定制。

在某些方面，Agent正在取代以前由警报、定时任务或基于条件的自动化所承担的角色，但它们提供了更多的上下文和灵活性。它们可能会称：“错误率正在上升，这是可能的原因、受影响的服务以及提出的修复方案。”而不是像传统的预先设定的逻辑（例如“如果错误率 > 阈值，则发送警报”）。在这个世界里，数据看板不仅仅是观察的地方；它们是人类和Agent协作、综合并采取行动的地方。

图片来源：a16z

图片来源：a16z

图片来源：a16z

仪表板如何发展以支持人类和AI Agent的viewer

文档正在成为工具、索引和互动知识库的结合体

在文档的使用方式上，开发者的行为正在发生变化。用户不再通过查阅目录或从上到下地浏览，而是从一个问题开始。思维模型不再是“让我研究这个规范”，而是“以我喜欢的方式重新整理这些信息”。这种微妙的转变——从被动阅读到主动查询——正在改变文档的性质。文档不再仅仅是静态的HTML或Markdown页面，而是变成了互动知识系统，背后有索引、嵌入和工具感知Agent的支持。

因此，我们看到像Mintlify这样的产品崛起，它不仅将文档结构化为语义可搜索的数据库，还充当跨平台代码Agent的上下文来源。Mintlify页面现在经常被AI编码Agent引用——无论是在AI IDE、VS Code扩展，还是终端Agent中——因为编码Agent使用最新的文档作为生成的基础上下文。

这改变了文档的目的：它们不再仅仅是供人类读者使用，而是也供Agent消费者使用。在这种新动态中，文档界面变得像是AI Agent的指令。它不仅仅暴露原始内容，还解释了如何正确使用系统。

图片来源：a16z

这是一张来自Mintlify的截图，用户可以通过cmd+k快捷键打开AI聊天窗口，进行关于Mintlify文档的问答。

从模板到生成：Vibe编码替代create-react-app

过去，启动一个项目意味着选择一个静态模板，如GitHub上的一个脚手架仓库，或者像create-react-app、next init、rails new这样的命令行工具。这些模板作为新应用的框架，提供了一致性，但定制性较差。开发人员只能按照框架提供的默认设置进行开发，或者要冒进行大量手动重构的风险。

现在，随着Replit、Same.dev、Loveable、Convex的Chef和Bolt等文本到应用平台的出现，以及Cursor等AI IDE的兴起，这一动态正在发生变化。开发人员可以描述他们想要的内容（例如：“一个包含Supabase、Clerk和Stripe的TypeScript API服务器”），然后在几秒钟内生成一个定制化的项目框架。结果是一个个性化且有目的的启动框架，既反映了开发人员的意图，也体现了他们选择的技术栈。

这为生态系统带来了新的分发模式。与其说有几个框架主导了整个生态系统，不如说我们将看到更多的可组合、栈特定的生成方式，其中工具和架构可以动态组合。开发者不再只需要选择一个框架，而是描述一个结果，AI可以围绕这个结果构建技术栈。一个工程师可能使用Next.js和tRPC创建一个应用，而另一个则使用Vite和React开始，但他们都会立刻获得一个可用的框架。

当然，这样的变化也有其权衡。标准化栈带来了实际的优势，包括提高团队生产力、改善新成员入职以及简化跨组织的故障排除。跨框架重构不仅仅是技术上的挑战，它还涉及到产品决策、基础设施限制和团队的专业能力。但正在发生变化的是，切换框架或从没有框架开始的成本大大降低。随着能够理解项目意图并能半自动执行大规模重构的AI Agent的出现，实验变得更加可行——如果需要的话，也可以轻松逆转。

这意味着框架决策变得更加可逆。开发人员可能会从Next.js开始，但后来决定迁移到Remix和Vite，并请求AI Agent处理大部分重构工作。这减少了框架曾经强加的锁定效应，鼓励了更多的实验，尤其是在项目的早期阶段。它还降低了尝试意见化栈的门槛，因为之后切换不再是巨大的投资。

图片来源：a16z

超越 .env：在Agent驱动的世界中管理密钥

几十年来，.env文件一直是开发者管理密钥（例如API密钥、数据库URL和服务Token）的一种默认方式，它们简单、便携且对开发者友好。然而，在一个Agent驱动的世界中，这种范式开始出现问题。当AI IDE或Agent代替我们编写代码、部署服务并协调环境时，.env文件的拥有权变得不再明确。

我们可以看到一些可能的发展方向。例如，最新的MCP规范包含了基于OAuth 2.1的授权框架，暗示着可能会转向为AI Agent提供具有作用域、可撤销的Token，而不是原始密钥。可以设想这样的场景：AI Agent不会获取你实际的AWS密钥，而是获得一个短期凭证或一个能力Token，让它执行一个特定定义的操作。

另一种可能的趋势是本地密钥Agent的兴起——这些服务运行在你的机器上或与你的应用程序并行，充当Agent与敏感凭证之间的中介。Agent不再将密钥注入.env文件或硬编码到框架中，而是可以请求访问某个能力（例如“部署到预生产环境”或“将日志发送到Sentry”），然后由Agent判断是否授予访问权限——这一过程是即时的，并且具有完全的可审计性。这种方式将密钥访问与静态文件系统解耦，使密钥管理更像是API授权而不是环境配置。

图片来源：a16z

一个关于以Agent为中心的秘密Agent流程在CLI中的示例

可访问性作为通用接口：从LLM的视角看应用程序

我们开始看到一类新的应用程序（例如Granola和Highlight），它们请求访问macOS的可访问性设置，但不是为了传统的可访问性使用场景，而是为了让AI Agent观察和与界面互动。然而，这并不是一种黑客行为，而是对更深层次变化的窥视。

可访问性API是为了帮助有视觉或运动障碍的用户导航数字系统而构建的。但当这些API被有意义地扩展时，它们可能成为Agent的通用接口层。Agent不再需要点击像素位置或抓取DOM，而是可以像辅助技术一样——从语义上观察应用程序。可访问性树已经暴露了诸如按钮、标题和输入框等结构化元素。如果通过元数据（例如意图、角色和可操作性）扩展，这可能成为Agent的首选接口，让它们能够有目的、有精准地感知和操作应用程序。

有几个潜在方向：

• 上下文提取：一种标准方法，允许LLM Agent通过可访问性或语义API查询屏幕上的内容、它可以互动的元素以及用户正在做什么；

• 有意图的执行：与其让Agent手动链式调用多个API，不如暴露一个高层次的端点，让它声明目标（“将物品加入购物车，选择最快的运输方式”），然后让后端处理步骤；

• LLM的回退UI：可访问性特性为LLM提供了回退UI。任何暴露了屏幕的应用程序都可以被Agent使用，即使它没有公开的API。对于开发人员来说，这暗示了一种新的“渲染表面”——不仅仅是视觉或DOM层，而是Agent可访问的上下文，可能通过结构化注释或以可访问性为优先的组件定义。

Asynchronous Agent工作崛起

随着开发人员与编码Agent的协作变得更加流畅，我们正在看到一种自然的转变：向异步workflow发展，Agent在后台运行，执行并行工作线程，并在取得进展时反馈。这种交互方式开始看起来不像成对编程，更像任务编排：你委派一个目标，让Agent执行，然后稍后再检查进展。

关键是，这不仅仅是将工作量外包出去；它还压缩了协调的时间。开发人员不再需要联系其他团队来更新配置文件、处理错误或重构组件，而是可以将这些任务直接分配给Agent，Agent会根据他们的意图在后台执行。曾经需要同步会议、跨职能交接或漫长的审查周期的任务，可能变成一个请求、生成和验证的循环。

Agent交互的界面也在不断扩展。开发人员不再总是通过IDE或CLI进行prompt，而是可以通过以下方式与Agent互动，例如：

• 发送消息到Slack；

• 在Figma设计图上发表评论；

• 在代码差异或PR中创建内联注释（例如，Graphite的审查助手）；

• 基于部署的应用预览提供反馈；

• 利用语音或通话接口，开发人员可以口头描述变更。

这创造了一种模型，让Agent贯穿整个开发生命周期。它们不仅仅是在编写代码，还在解读设计、回应反馈和跨平台处理错误。开发人员成为了编排者，决定追求、丢弃或合并哪些线程。

也许这种分支和委托给Agent的模式将成为新的Git分支——不仅仅是代码的静态分支，而是一个动态的意图线程，异步运行直到准备好合并。

MCP离成为通用标准又近了一步

我们最近发布了关于MCP的深度分析。自那时以来，势头加速：OpenAI公开采纳了MCP，多个新特性被合并，工具开发者也开始将其作为Agent与现实世界之间的默认接口。

MCP的核心解决了两个大问题：

• 它为LLM提供了完成从未见过的任务所需的正确上下文；

• 它用一个干净、模块化的模型取代了N×M的定制集成，其中工具暴露了标准接口（服务器），任何Agent（客户端）都可以使用。

随着远程MCP和事实上的注册表上线，我们预计会看到更广泛的采用。随着时间的推移，应用程序可能会默认包含MCP接口。

可以想象，API使得SaaS产品能够互相连接，跨工具组合workflow。MCP也可能通过将独立的工具转变为互操作的构建块，实现AI Agent之间的互操作性。一个内置MCP客户端的平台不仅仅是“AI就绪”，它是更大生态系统的一部分，能够立即接入一个不断增长的可由Agent访问的能力网络。

此外，MCP客户端和服务器是逻辑上的边界，而不是物理边界。这意味着任何客户端也可以作为服务器，反之亦然。这理论上可以解锁一个强大的组合能力，通过它，使用MCP客户端来获取上下文的Agent，也可以通过服务器接口暴露自己的能力。例如，一个编码Agent可以作为客户端获取GitHub问题，同时也可以作为服务器，向其他Agent暴露测试覆盖率或代码分析结果。

抽象原语：每个AI Agent都需要身份验证、计费和持久存储

随着虚拟编码Agent的能力越来越强，有一件事变得清晰：Agent可以生成大量代码，但它们仍然需要一些坚实的基础设施来支持。就像人类开发人员依赖Stripe进行支付、Clerk进行身份验证或Supabase进行数据库功能一样，Agent也需要类似干净且可组合的服务原语来搭建可靠的应用程序。

在许多方面，这些服务——具有明确边界的API、符合人体工程学的SDK和合理的默认设置，减少了失败的可能性——越来越多地作为Agent的运行时接口。如果你在构建一个生成SaaS应用的工具，你不希望Agent从零开始编写身份验证系统或计费逻辑；你希望它使用像Clerk和Stripe这样的提供商。

随着这一模式的发展，我们可能会看到服务不仅仅通过暴露API，还有架构、能力元数据和示例流程，帮助Agent更可靠地集成它们。

一些服务甚至可能开始默认提供MCP服务器，将每个核心原语转变为Agent可以直接使用并安全访问的内容。想象一下，Clerk暴露一个MCP服务器，允许Agent查询可用产品、创建新的计费计划或更新客户的订阅——所有权限范围和约束都提前定义。Agent不需要手动编写API调用或翻阅文档，只需说：“创建一个49美元/月的‘Pro’计划，并按使用量收取额外费用”，Clerk的MCP服务器将暴露该能力，验证参数，并安全地处理协调。

就像早期的Web时代需要Rails生成器和rails new来加速开发一样，Agent时代也需要可靠的原语——即插即用的身份、使用追踪、计费逻辑和访问控制——这些原语足够抽象，可以进行生成，但又足够表达，能够随着应用的增长而发展。

结论

这些模式指向了一个更广泛的转变，在这种转变中，新的开发者行为与更强大的基础模型并行出现。作为回应，我们看到像MCP这样的新工具链和协议正在成型。这不仅仅是将AI层叠加到旧的workflow之上，而是重新定义了如何以Agent、上下文和意图为核心构建软件。许多开发工具层面正在发生根本性的变化，我们期待着构建和投资下一代工具。

原地址：Nine Emerging Developer Patterns for the AI Era

https://a16z.com/nine-emerging-developer-patterns-for-the-ai-era/

编译：Christine Liu

请注意，本文编译自文末载明的原始链接，不代表Z Potentials立场。如果您对本文有任何想法或见解，欢迎在评论区留言互动探讨。

Z Potentials将继续提供更多关于人工智能、机器人、全球化等领域的优质内容。我们诚邀对未来充满憧憬的您加入我们的社群，与我们共同分享、学习、成长。

——-

（文：Z Potentials）