a16z最新分享：AI时代的9大新兴开发模式

/ 01 /

AI原生Git：为AI代理重新构想版本控制

随着AI代理越来越多地编写或修改应用程序中的大量代码，开发者所关注的重点也开始发生变化。我们不再执着于每一行代码是如何被写出来的，而更关心输出的行为是否符合预期：这次更改通过了测试吗？应用是否仍然按照预期运行？

这颠覆了一个长期存在的思维模型：Git的设计初衷是为了追踪手动编写的代码精确的历史变更，但在引入编码代理之后，这种细粒度的追踪开始变得不那么有意义。

开发者通常不会再去逐行审核每一个差异——尤其当改动很大或者是由AI自动生成的时候 —— 他们只关心新行为是否与预期一致。因此，曾经作为“代码库状态”权威标识的 Git SHA 开始逐渐失去其语义上的意义。

一个SHA只能告诉你某些东西发生了变化，但无法说明原因，也无法判断是否正确。在以AI为核心的开发流程中，一个更有用的“真实单元”可能是生成这段代码的提示词（prompt）和验证其行为的测试组合。

在这种模式下，“代码状态”可能更适合由生成代码的输入（如提示词、规范、约束条件）以及一组通过的断言来表示，而不是一个固定的提交哈希值。事实上，我们最终可能会将 prompt+test打包成可版本控制的独立单元，并让Git来追踪这些打包后的单元，而非仅仅是原始源码。

进一步来看：在由AI代理驱动的工作流中，事实的源头可能会向上游转移，转向提示词、数据结构、API合约和架构意图。

代码则成为这些输入的副产品，更像是一个编译产物，而非人工撰写的源码。在这种世界里，Git 的功能会逐渐从协作工作区转变为一个产物日志 —— 一个不仅记录“什么改变了”，还记录“为什么改变”、“是谁操作的”的地方。

我们可能会开始加入更丰富的元数据，例如是哪个代理或模型进行了更改、哪些部分受到保护、在哪些地方需要人工审查 —— 或者像 Diamond 这样的 AI 审查员何时应该介入流程。

为了让这个概念更具体一些，下面是一个模拟图，展示了一个 AI 原生的 Git 工作流在实际中可能的样子：

/ 02 /

仪表盘->综合：动态AI驱动界面

多年来，仪表盘一直是与复杂系统交互的主要界面，例如可观测性堆栈、分析工具、云控制台（比 AWS）等等。

但它们的设计常常面临用户体验过载的问题：太多旋钮、图表和标签页，迫使用户既要“寻找信息”，又要“弄清楚如何使用”。

尤其是对于非专业用户或跨团队协作来说，这些仪表盘可能会显得令人望而生畏或效率低下。用户知道自己想要达成什么目标，却不知道从哪里入手，也不知道应该应用哪些过滤条件才能找到答案。

最新一代AI模型为我们带来了可能的转变。与其将仪表盘视为固定不变的画布，不如在其之上叠加搜索和交互能力。

如今的大语言模型（LLMs）可以帮助用户找到正确的控制选项（例如：“我应该在哪里调整这个API的限流设置？”）；可以将整个屏幕的数据综合成易于理解的洞察（例如：“总结过去 24 小时内所有预发布服务的错误趋势”）；甚至可以揭示那些用户尚未意识到的问题（例如：“根据你对我业务的了解，生成一份本季度我应关注的关键指标清单”）。

我们已经看到一些技术方案，如Assistant UI，使代理能够利用React组件作为工具。就像内容变得动态化和个性化一样，UI本身也可以变得自适应和对话式。

相比起一个由自然语言驱动、能根据用户意图重新配置的界面，纯粹静态的仪表盘很快就会显得过时。例如，用户不必再手动点击五层过滤器来筛选特定指标，只需说一句：“显示上周末欧洲地区的异常数据。”仪表盘便会自动重组以展示该视图，并附带汇总的趋势和相关日志。

更强大的是，用户还可以问：“上周我们的 NPS 分数为什么下降了？”AI可能会调出调查情绪数据，将其与一次产品上线进行关联，并生成一段简短的诊断分析。

从更大的角度看，如果代理现在也成为软件的使用者，我们也需要重新思考“仪表盘”的本质以及它的目标用户是谁。例如，仪表盘可以渲染成更适合代理体验的视图——结构化的、可编程访问的界面，帮助代理感知系统状态、做出决策并执行操作。

这可能导致出现双模式界面：一种面向人类用户，一种面向代理，两者共享同一个状态，但分别针对不同的使用方式进行优化。

在某种程度上，代理正在承担原本由告警、定时任务或基于条件的自动化所扮演的角色，但具备更强的上下文理解和灵活性。不同于传统的预设逻辑（例如：“如果错误率 > 阈值，则发送告警”），代理可以说：“错误率正在上升。这是可能的原因、受影响的服务，以及建议的修复方案。”在这种新世界中，仪表盘不再只是观察系统的场所，而是人类与代理共同协作、整合信息并采取行动的空间。

▲仪表盘的演变：如何更好地服务于人类用户与 AI 代理的双重需求

/ 03 /

文档，工具、索引和交互式知识库的结合体 

开发者在使用文档时的行为正在发生变化。

现在，用户不再是从目录开始逐页阅读或自上而下浏览，而是从一个问题开始：“我该如何完成某项任务？”这种心理模型的转变，意味着文档的角色已经从“让我来学习这份规范”转变为“请帮我以我喜欢的方式重新组织这些信息”。

这一微妙的变化——从被动阅读转向主动查询——正在重塑文档应有的形态。

文档不再仅仅是静态的 HTML 或 Markdown 页面，而是演变为由索引、嵌入（embeddings）和具备工具意识的AI代理支持的交互式知识系统。

因此，我们看到像Mintlify这类产品的兴起：它们不仅将文档结构化为语义可搜索的数据库，还成为跨平台编码代理的重要上下文来源。

如今，在AI集成开发环境（AI IDE）、VS Code插件或终端代理中，Mintlify的内容经常被AI编码代理引用，因为这些代理会利用最新文档作为生成代码的基础背景信息。

这从根本上改变了文档的目的：它不再只是服务于人类读者，也成为AI代理的重要“消费者”内容。在这种新的关系中，文档界面更像是对AI代理的指令说明，它不仅仅展示原始内容，更解释了如何正确地使用一个系统。

/ 04 /

从静态模板到智能生成：Vibe编程正在取代Create React App的时代

在过去，启动一个新项目意味着选择一个静态模板，比如一个样板GitHub仓库，或者使用像 create-react-app、next init、rails new这样的命令行工具。

这些模板为新应用提供了基本框架，带来了统一性，但几乎没有定制空间。开发者只能接受框架提供的默认配置，否则就要冒着大量手动重构的风险。

但现在，随着“文本生成应用”平台（如 Replit、Same.dev、Loveable、Convex 推出的 Chef 和 Bolt）以及 AI 集成开发环境（如 Cursor）的兴起，这种模式正在发生转变。

开发者只需描述自己想要什么（例如：“一个使用 Supabase、Clerk 和 Stripe 的 TypeScript API 服务”），AI就能在几秒钟内生成一个量身定制的项目结构。由此产生的启动模板不再是通用的，而是个性化的、有针对性的，反映了开发者的意图以及他们选择的技术栈。

这为生态系统开启了一种新的分发模式。未来，我们可能不再依赖少数几个主流框架主导长尾市场，而是看到更多可组合的、特定技术栈的生成方式涌现出来，工具与架构可以动态地混合搭配。

重点不再是“选择一个框架”，而是“描述一个目标”，然后由AI围绕这个目标构建合适的技术栈。一位工程师可以用Next.js和tRPC创建一个应用，另一位则从Vite和React开始，但他们都能立即获得可用的初始结构。

当然，这种变化也伴随着权衡。标准技术栈确实有很多优势，比如提升团队效率、简化新人上手流程，以及在组织内部更容易排查问题。

跨框架的重构不仅仅是技术上的挑战，往往还涉及产品决策、基础设施限制和团队技能等多重因素。但如今发生变化的是“切换框架”或“从无框架起步”的成本。借助能够理解项目意图并半自主执行大规模重构的AI代理，实验变得更加可行。

这意味着，框架的选择正变得越来越可逆。一个开发者可能一开始使用Next.js，但后来决定迁移到Remix 和Vite，并让AI代理完成大部分重构工作。这大大降低了框架曾经带来的锁定效应，鼓励了更多的尝试行为，尤其是在项目的早期阶段。这也降低了采用“有特定理念”的技术栈的门槛，因为日后的切换已不再是巨大的投入。

/ 05 /

告别.env：AI代理时代下的新型密钥管理方式

几十年来，.env文件一直是开发者在本地管理敏感信息（如API密钥、数据库URL和服务令牌）的默认方式。

它们简单、可移植且对开发者友好。但在一个由AI代理驱动的世界中，这种范式开始变得不再适用。当一个AI IDE或代理在为我们编写代码、部署服务和协调环境时，谁真正拥有这个.env文件，已经不再清晰。

我们已经开始看到一些未来可能形态的迹象。例如，最新的MCP规范（Model Communication Protocol）就包含了一个基于OAuth 2.1的授权框架，这预示着我们可能会转向为AI代理提供有作用域、可撤销的能力令牌（token），而不是直接暴露原始密钥（secrets）。

我们可以设想这样一种场景：AI代理不会直接获得你的AWS密钥，而是获取一个生命周期短、权限受限的凭证或能力令牌，仅允许它执行特定的操作。

另一种可能的发展路径是“本地密钥代理（local secret brokers）”的兴起——这些是运行在你本地机器上或与你的应用并行的服务，作为AI代理与敏感凭据之间的中间人。

代理不再通过.env文件注入密钥，也不再将密钥硬编码进项目结构中，而是可以请求某种操作权限（如“部署到预发布环境”或“将日志发送到 Sentry”），然后由代理服务决定是否即时授予该权限，并全程记录审计日志。

这种方式将密钥访问从静态文件系统中解耦出来，使密钥管理更像是一种API授权行为，而非传统的环境配置流程。

▲以代理为中心的秘密经纪人流程的CLI模型

/ 06 /

A以辅助功能为通用接口：让LLM“看见”的应用界面

我们开始看到一类新型应用的出现（例如Granola和Highlight），它们请求访问macOS的辅助功能设置，但并不是为了传统的无障碍使用场景，而是为了让AI代理能够“观察”和“交互”界面。然而，这并非一种“黑科技”，而是一种更深层次变革的前兆。

辅助功能API最初是为了帮助有视觉或运动障碍的用户更好地操作数字系统而设计的。但如果加以合理扩展，这些API可能会成为AI代理的通用接口层。与其通过像素坐标点击屏幕或解析 DOM结构，AI代理可以像辅助技术一样，以“语义化”的方式来理解和操作应用程序。

当前的辅助功能树（accessibility tree）已经暴露了结构化的元素，比如按钮、标题和输入框。如果再加上一些元数据（如意图 intent、角色role、可操作性affordance），它就可能成为AI代理的一等接口，让代理以更有目的性和精确性的方式感知并操作应用程序。

以下是几个潜在的发展方向：

1.上下文提取（Context Extraction）

为使用辅助功能或语义API的LLM代理提供一种标准化的方式，让它可以查询：

屏幕上显示了什么？

它可以与哪些元素进行交互？

当前用户正在做什么？

这种能力可以让代理真正理解当前的应用状态，并基于上下文做出反应。

2. 有目的的执行（Intentful Execution）

无需让代理手动串联多个 API 调用，而是提供一个高层级的接口，允许它声明目标（intent），例如：“将商品加入购物车，并选择最快的配送方式。”

然后由后端系统负责解析这些目标，并自动规划出实现步骤。这种方式降低了代理对底层UI实现细节的依赖，也提升了抽象层级。

3. LLM 的备用 UI（Fallback UI for LLMs）

辅助功能为LLM提供了一种备用的用户界面。任何能展示界面的应用都可以被AI代理使用，即使它没有公开的API。对开发者而言，这预示着一种新的“渲染层”概念——不仅仅是视觉层或 DOM 结构，而是一个可供代理访问的上下文环境，可能通过结构化注解或以辅助功能优先的组件来定义。

/ 07 /

异步代理工作的兴起

随着开发者与编码代理之间的协作日益流畅，我们正在见证一种自然的转变：工作流程正朝着异步化方向发展。代理可以在后台运行、并行处理多个任务，并在取得进展时主动反馈结果。

这种交互方式正逐渐脱离“结对编程”的模式，而更像是一种“任务编排”：你只需设定一个目标，交给代理去执行，稍后再回来查看进度。

关键在于，这种变化不仅仅是“把工作交给 AI 做”，它还极大地压缩了协调成本。过去，你需要提醒其他团队成员更新配置文件、排查错误或重构组件；而现在，开发者可以将这些任务直接指派给能够理解意图并在后台执行的代理。

原本需要同步会议、跨职能交接或冗长评审周期的工作，现在可能演变为一种持续进行的“请求—生成—验证”循环。

与此同时，与代理交互的方式也在不断扩展。除了在IDE或命令行中输入提示词之外，开发者还可以通过以下方式与代理互动：

在 Slack 中发送消息

在 Figma 设计稿中添加评论

在代码差异或 Pull Request 中插入内联注释（例如 Graphite 的评审助手）

根据部署后的应用预览提供反馈

使用语音或通话接口，用口头描述来进行更改

这形成了一种全新的开发模型：AI代理贯穿整个开发生命周期。它们不只是写代码，还能解读设计、响应反馈、跨平台排查Bug。而开发者则转变为“指挥者”，决定哪些任务线程继续推进、放弃或合并。

也许在未来，这种“分支+委托”的代理模型将成为新的Git分支——不再是静态的代码分叉，而是围绕意图动态运行的异步任务流，直到准备就绪才合并落地。

/ 08 /

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

我们最近发布了一篇关于 MCP（Model Communication Protocol，模型通信协议）的深度解析。自那之后，该领域的发展势头明显加快：

OpenAI公开采用了MCP，规范中也合并了若干新功能，越来越多的工具开发者开始将其视为 AI 代理与现实世界交互的默认接口。

从本质上讲，MCP 解决了两个关键问题：

第一，为 LLM 提供完成任务所需的上下文信息，即便这些任务是它之前从未遇到过的；

第二，取代原本N×M的定制化集成方式，取而代之的是一个清晰、模块化的模型：工具通过暴露标准接口（称为“服务器”），可以被任意代理（“客户端”）使用。

我们预计，随着远程MCP支持和事实上的注册中心（registry）逐步上线，其采用范围将进一步扩大。从长远来看，应用程序可能会默认集成MCP接口，就像今天许多服务默认提供API一样。

想想看，API是如何让SaaS产品之间相互连接，并在不同工具间构建可组合的工作流的。MCP 可以为AI代理实现类似的互联互通 —— 它将原本孤立的工具转变为可互操作的构建模块。一个内置了MCP客户端的平台，不只是“具备 AI 能力”，更是融入了一个更大的生态系统，能够立即接入不断增长的、代理可访问的能力网络。

此外，MCP的客户端和服务器是逻辑边界，而非物理隔离。这意味着，任何客户端也可以作为服务器运行，反之亦然。这种设计理论上可以解锁一种强大的“可组合性”：一个通过MCP客户端获取上下文的代理，也可以通过服务器接口开放自己的功能。

例如，一个编码代理可以作为客户端去获取GitHub上的问题（issues），同时也可以把自己注册为服务器，向其他代理公开测试覆盖率或代码分析结果。

/ 09 /

基础能力模块化

随着氛围编码代理功能日益强大，有一点变得清晰起来：代理可以生成大量代码，但它们仍然需要一些可靠的接口来支持。

就像人类开发者依赖 Stripe 实现支付、使用 Clerk 处理认证、或通过 Supabase获取数据库能力一样，AI 代理也需要类似这样清晰、可组合的服务基础模块，才能构建出稳定可靠的应用。

在很多方面，这些服务——具有明确边界、提供友好SDK、并具备合理默认值以减少出错可能的服务——正日益成为AI代理的运行时接口。

如果你正在构建一个能生成SaaS应用的工具，你肯定不希望你的代理自己写一套认证系统，或者从头实现计费逻辑；你希望它直接使用像 Clerk 和 Stripe 这样的成熟服务。

随着这种模式逐渐成熟，我们可能会看到越来越多的服务开始为AI代理优化自身体验：除了开放API，还提供数据结构定义（schema）、能力元数据（capability metadata）以及示例流程（example flows），帮助代理更稳定地集成和使用这些服务。

一些服务甚至可能默认内置MCP服务器，将每一个核心功能模块转变为AI代理可以直接理解和安全调用的组件。想象一下，Clerk提供了一个MCP服务器，允许代理查询可用产品、创建新的计费计划、或更新客户的订阅信息——所有操作都预先定义了权限范围和约束条件。

这样一来，代理无需手动编写API调用或翻阅文档查找方法，而是可以直接说：“创建一个每月49美元的‘Pro’套餐，并支持基于用量的超额费用。”

而Clerk的MCP服务器会公开这一能力、验证参数并安全地处理编排。

正如早期Web开发时代需要Rails的生成器和rails new来加速开发，AI代理时代也需要值得信赖的基础模块：即插即用的身份系统、使用追踪、计费逻辑和访问控制机制——这些模块不仅要足够抽象以便于代码生成，还要足够灵活，能够随着应用一起成长。