a16z：Git 将被取代，AI 时代的 9 种全新软件开发模式

AI 原生 Git：

为 AI Agent 重塑版本控制

这个想法一开始可能听起来很疯狂，但听我说完。现在AI Agent越来越多地编写或修改应用程序代码的大部分，开发者关心的东西开始发生变化。我们不再纠结于一行一行写了什么代码，而是关心输出是否按预期运行。改动通过测试了吗？应用还像预期那样工作吗？

这里有个很有趣的现象，我称之为「真相的上移」。以前，源代码就是真相。现在，prompt和测试组合才是真相。想想看，如果我告诉你「用React写一个待办列表应用」，然后AI Agent生成了1000行代码，你真的在乎每一行代码具体怎么写的吗？还是更在乎它是不是真的能用？

这颠覆了一个长期存在的思维模式。Git被设计用来跟踪手写代码的精确历史，但是有了编程AI Agent，这种粒度变得不那么有意义了。开发者通常不会审核每一个差异——尤其是当改动很大或者是自动生成的——他们只是想知道新行为是否符合预期结果。

这让我想起了软件工程的一个基本原则：抽象。我们总是在寻找合适的抽象层。汇编语言太低级，所以我们有了高级语言。机器码太难懂，所以我们有了编译器。现在，一行一行的代码可能也太低级了，我们需要新的抽象。

结果是，Git SHA——曾经是「代码库状态」的标准参考——开始失去一些语义价值。SHA只是告诉你有东西改变了，但不告诉你为什么或者是否有效。在AI优先的工作流中，更有用的真相单元可能是生成代码的prompt和验证其行为的测试的组合。

在这个世界里，你的应用的「状态」可能更好地由生成的输入（prompt、规范、约束）和一套通过的断言来表示，而不是一个冻结的提交哈希。想象一下，未来的开发者可能会说：「给我看看prompt v3.1的测试覆盖率」，而不是「给我看看commit SHA abc123的diff」。

实际上，我们最终可能会将prompt+测试包作为本身可版本化的单元来跟踪，Git被降级为跟踪这些包，而不仅仅是原始源代码。这就是我所说的「意图驱动的版本控制」。我们不是在版本控制代码，而是在版本控制意图。

更进一步说，在AI Agent驱动的工作流中，真相的来源可能会向上游转移到prompt、数据架构、API合约和架构意图。代码成为这些输入的副产品，更像编译的工件而不是手动编写的源码。在这个世界里，Git开始更少地充当工作区，更多地充当工件日志——一个不仅跟踪什么改变了，还跟踪为什么改变以及由谁改变的地方。

想想这个场景：你正在debug一个问题，你不是在查找「谁在什么时候改了这行代码」，而是在问「哪个AI Agent基于什么prompt做了这个决定，人类审核者在哪里签字确认了？」这就是未来的代码考古学。

这是一个我觉得被严重低估的趋势。多年来，仪表板一直是与复杂系统交互的主要界面，比如可观测性堆栈、分析平台、云控制台（想想AWS）等等。但它们的设计常常遭受UX过载的困扰：太多的旋钮、图表和标签页，迫使用户既要寻找信息，又要搞清楚如何处理它。

我有个朋友是运维工程师，他告诉我他花了一半时间在各种仪表板之间切换，试图拼凑出系统到底出了什么问题。这完全是信息过载的问题，不是缺乏数据，而是数据太多了，不知道怎么整理。

尤其对于非高级用户或者跨团队使用，这些仪表板可能变得令人生畏或者效率低下。用户知道他们想达成什么，但不知道该看哪里或者应用哪些过滤器才能到达目的地。这就像在一个巨大的工具箱里找一个特定的螺丝刀，但所有工具都长得差不多。

最新一代的AI模型提供了一个潜在的转变。我们可以在仪表板上添加搜索和交互功能，而不是把它们当作僵硬的画布。现在LLM可以帮助用户找到正确的控制（「哪里可以调整这个API的限流设置？ 」）；将整屏数据合成为易于理解的洞察（「总结过去24小时内预发布环境所有服务的错误趋势」）；并浮现未知的未知("基于你对我业务的了解，生成一个我这个季度应该关注的指标列表")。

这里有个很酷的概念，我称之为「上下文化的数据展示」。传统仪表板是静态的：它们展示固定的指标，用固定的方式。但AI驱动的仪表板可以根据你当前的任务、你的角色、甚至你过去的行为模式来重新配置自己。

我们已经看到像Assistant UI这样的技术解决方案，使AI Agent能够将React组件用作工具。就像内容变得动态和个性化一样，UI本身也可以变得自适应和对话式。在一个基于自然语言的界面面前，纯粹的静态仪表板可能很快显得过时，这种界面会根据用户意图重新配置。

比如，用户可以说「显示上周末欧洲的异常情况」，仪表板就会重塑以显示该视图，包括总结的趋势和相关日志。或者，更强大的是，「为什么我们的NPS评分上周下降了？」，AI可能会提取调查情绪，将其与产品部署相关联，并生成一个简短的诊断叙述。

但这里还有一个更深层的转变：仪表板不再只是为人类设计的。AI Agent也需要「看」和「理解」系统状态。这意味着我们可能需要双模式界面：一个人类友好的，一个Agent友好的。想想这个场景：一个AI Agent正在监控你的系统，它不需要漂亮的图表，它需要结构化的数据和可执行的上下文。

这就像为不同的感官设计：人类用眼睛看，Agent用API「感知」。未来的仪表板可能需要同时服务这两种「物种」，这是一个全新的设计挑战。

文档正在成为工具、索引和交互式知识库的混合体

这个转变让我兴奋不已。开发者在文档方面的行为正在发生转变。与其阅读目录或从上往下扫描，用户现在从一个问题开始。心理模式不再是「让我研究这个规范」，而是「按照我喜欢的方式重新整理这些信息」。

我记得刚开始编程的时候，我会花几个小时阅读API文档，从头到尾。现在呢？我打开文档，直接搜索我想要的东西，或者问AI「怎么用这个库做X」。这不是懒惰，而是效率的进化。

这个微妙的转变——从被动阅读到主动查询——正在改变文档需要成为什么。它们不再只是静态的HTML或markdown页面，而是正在成为交互式知识系统，由索引、嵌入和工具感知的AI Agent支撑。

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

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

这里有个很有趣的趋势，我称之为 「文档的双重性格」。人类读者需要上下文、例子和解释。AI Agent需要结构化数据、明确的规则和可执行的指令。好的文档需要同时满足这两种需求。

未来的文档可能会有三个层次：人类阅读层（有故事性和解释）、AI消费层（结构化和精确）、交互层（允许询问和探索）。这就像为不同的学习风格设计教材，但这次是为不同的「思维方式」设计。

从模板到生成：

vibe coding 取代 create-react-app

这个趋势让我想起了工业革命到数字革命的转变。过去，开始一个项目意味着选择一个静态模板，比如样板GitHub仓库或者像create-react-app、next init或rails new这样的CLI。这些模板作为新应用的脚手架，提供一致性但缺少定制性。

开发者要么顺应框架提供的任何默认值，要么冒着大量手动重构的风险。这就像工业时代的标准化生产：你可以有任何颜色的汽车，只要它是黑色的。

现在，随着像Replit、Same.dev、Loveable、Convex的Chef和Bolt这样的文本到应用平台的出现，以及像Cursor这样的AI IDE，这种动态正在发生变化。开发者可以描述他们想要什么（比如「一个带有Supabase、Clerk和Stripe的TypeScript API服务器」），并在几秒钟内得到一个定制的项目脚手架。

结果是一个不是通用的，而是个性化和有目的的启动器，反映了开发者的意图和他们选择的技术栈。这就像从工业化生产转向大规模定制化。每个项目都可以有独特的起始点，而不是从相同的模板开始。

这在生态系统中解锁了一个新的分发模式。与其让少数框架坐拥长尾，我们可能会看到可组合的、特定于堆栈的生成更广泛的分布，工具和架构被动态地混合和匹配。这更多的是描述一个结果，AI可以围绕它构建一个堆栈，而不是选择一个框架。

但这里有个有趣的副作用，我称之为「框架民主化」。以前，选择框架是一个重大决定，因为切换成本很高。现在，框架选择变得更像选择今天穿什么衣服：可以随时改变。

当然，这也带来了新的挑战。标准化有它的优势——团队协作更容易，troubleshooting更简单，知识传播更快。但随着AI Agent能够理解项目意图并执行大规模重构，实验的成本显著降低。

这意味着我们可能会看到一个更加流动的技术栈生态系统，其中选择不再是永久性的决定，而是演化的起点。

超越 .env：

在 AI Agent 驱动的世界中管理秘密

这是一个很多人忽视但极其重要的问题。几十年来，.env文件一直是开发者在本地管理秘密（比如API密钥、数据库URL和服务令牌）的默认方式。它们简单、便携、对开发者友好。但在AI Agent驱动的世界中，这个范式开始崩溃。

想想这个场景：你有一个AI Agent在帮你写代码，它需要连接到你的数据库。你真的要把数据库密码直接给它吗？如果是这样，谁对数据泄露负责？AI agent？你？还是AI agent的提供商？

当AI IDE或AI Agent代表我们编写代码、部署服务和协调环境时，不再清楚谁拥有.env。更重要的是，传统的 「环境变量」概念本身可能已经过时了。我们需要的是一种能够给予精确权限、可审计、可撤销的秘密管理系统。

我们看到了一些可能的样子的迹象。例如，最新的MCP规范包括一个基于OAuth 2.1的授权框架，暗示着可能转向给AI Agent提供有范围的、可撤销的令牌，而不是原始秘密。我们可以想象这样一个场景：AI Agent不会得到你的实际AWS密钥，而是获得一个短期凭证或能力令牌，让它执行一个狭窄定义的操作。

这可能发展的另一种方式是通过本地秘密代理的兴起——在你的机器上或与你的应用一起运行的服务，充当AI Agent和敏感凭证之间的中介。代理可以请求访问一个能力（「部署到预发布」或「将日志发送到Sentry」），而代理决定是否授予它——实时，并且完全可审计。

我把这种趋势称为「能力导向的安全」。与其给AI Agent钥匙（秘密），我们给它们许可（能力）。这就像从「信任但验证」转向「零信任但启用」。

未来的秘密管理可能看起来更像一个权限系统，每个操作都有明确的范围，每个AI Agent都有明确的角色，所有访问都被记录和审计。这不仅更安全，也更符合AI Agent的工作方式：它们不需要知道所有东西，只需要知道完成任务所需的东西。

无障碍作为通用界面：

通过 LLM 的眼睛看应用

这个趋势让我想起了「意外的创新」理论。我们开始看到一类新的应用（比如Granola和Highlight），它们请求访问macOS上的无障碍设置，不是为了传统的无障碍用例，而是为了让AI Agent能够观察和与界面交互。但这不是一个hack：这是一个更深层次转变的预示。

无障碍API最初是为了帮助有视力或运动障碍的用户导航数字系统而建立的。现在，这些相同的API正在成为AI Agent理解和控制数字环境的通用语言。这就像盲文意外地成为了机器人读取世界的方式。

想想这个：无障碍API已经解决了「如何让机器理解人类界面」的问题。它们提供了语义化的元素描述：这是一个按钮，这是输入框，这是链接。对于AI Agent来说，这就是完美的数据结构。

这里有个很深刻的洞察：我们一直在寻找如何让AI Agent与人类世界交互，但答案可能就在我们面前。无障碍技术已经标准化了，已经在所有主流操作系统中实现，已经经过了十几年的实战检验。

如果经过深思熟虑的扩展，这可能成为AI Agent的通用界面层。AI Agent可以像辅助技术那样语义地观察应用程序，而不是点击像素位置或抓取DOM。无障碍树已经暴露了结构化元素，如按钮、标题和输入框。如果用元数据（如意图、角色和功能）进行扩展，这可能成为AI Agent的第一类接口，让它们有目的和精确地感知和操作应用。

实际上，这个方向有几个可能的发展路径：

第一个是上下文提取，我们需要一种标准方式，让使用无障碍或语义API的LLM Agent能够查询屏幕上有什么，它可以与什么交互，以及用户正在做什么。想象一下，AI agent可以说「告诉我这个屏幕上所有可点击的元素」或「用户现在在什么位置」，并立即得到结构化的答案。

第二个是意图式执行，与其期望AI  Agent手动串联多个API调用，不如暴露一个高层端点，让它声明目标（「将物品添加到购物车，选择最快配送」），然后让后端计算出具体步骤。这就像告诉司机「带我去机场」，而不是给出每一个转弯指令。

第三个是LLM的备用UI，无障碍功能为LLM提供了一个备用UI。任何暴露屏幕的应用都变得对AI Agent可用，即使它没有公开API。对开发者来说，这暗示了一个新的「渲染层」——不仅是视觉或DOM层，而是AI Agent可访问的上下文，可能通过结构化注释或无障碍优先的组件来定义。

这三个方向共同指向一个未来：应用程序不再只为人眼设计，也为AI「眼」设计。每个界面元素都携带丰富的语义信息，不仅描述它看起来是什么，还描述它能做什么，以及如何使用它。

这引出了一个有趣的想法：如果我们把无障碍设计作为「机器可读性」的标准呢？每个新的UI元素，每个新的交互模式，都从一开始就考虑机器理解。这不仅让残障人士受益，也让AI Agent受益。

未来，我们可能会看到一种「双重设计」的趋势：不仅为人类设计，也为AI Agent设计。而无障碍原则可能成为这两者的桥梁。这就像为多文化世界设计语言：不仅考虑母语者，也考虑学习者和翻译者。

异步AI  Agent工作的兴起

这个趋势反映了工作方式的根本转变。随着开发者开始更流畅地与编程AI Agent一起工作，我们看到了向异步工作流的自然转变，AI Agent在后台运行，追求并行的工作线程，并在取得进展时报告回来。

这让我想起了从同步编程到异步编程的转变。一开始，程序都是同步的：做完一件事，再做下一件事。然后我们发现，等待是浪费时间，并发才是王道。现在，我们在人机协作的层面经历同样的转变。

这种交互模式开始看起来不太像结对编程，更像任务编排：你委派一个目标，让AI Agent运行，稍后检查。这就像你有了一个非常能干的实习生，你可以给他一个项目，让他去做，然后你专注于其他事情。

关键是，这不仅仅是卸载努力；它还压缩了协调。与其联系另一个团队更新配置文件、分类错误或重构组件，开发者越来越能够直接将这个任务分配给一个根据他们的意图行动并在后台执行的AI Agent。

这种变化有个深层次的含义：我们正在从同步协作转向异步交响。传统的软件开发像是一场面对面的会议：所有人同时在场，实时讨论。新的模式更像是一场分布式的乐团演奏：每个演奏者（AI Agent）根据总谱（规范）独立演奏，指挥（开发者）协调整体。

AI Agent交互的界面也在扩展。除了总是通过IDE或CLI提示，开发者可以开始通过以下方式与AI Agent互动：

• 向Slack发送消息

• 在Figma模拟图上评论

• 在代码差异或PR上创建内联注释

• 基于部署的应用预览添加反馈

• 以及利用语音或基于通话的界面

• 开发者可以口头描述更改

这创建了一个模型，其中AI Agent贯穿开发的整个生命周期。它们不仅编写代码，还解释设计、响应反馈、并在平台间分类错误。开发者成为决定追求、丢弃或合并哪个线程的协调者。

也许最有趣的是，这种异步模式可能会改变我们对「分支」的理解。传统的Git分支是代码的分叉。未来的「分支」可能是意图的分叉，每个分支由不同的AI Agent以不同的方式探索。开发者不再是合并代码，而是评估和选择不同的解决方案路径。

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

MCP（模型上下文协议）是最近最令人兴奋的协议创新之一。我们最近发布了一份关于MCP的深度分析。从那以后，势头加速了：OpenAI公开采用了MCP，该规范的几个新功能被合并，工具制造商开始聚合在它周围，将其作为AI Agent和现实世界之间的默认接口。

这让我想起了HTTP在90年代的角色。HTTP不是第一个网络协议，也不是最复杂的，但它简单、足够好，得到了广泛支持。现在MCP可能正走在类似的道路上。

在其核心，MCP解决了两个大问题：它为LLM提供了完成可能从未见过的任务的正确上下文集；它用一个干净的、模块化的模型取代了N×M定制集成，在这个模型中，工具暴露标准接口（服务器），可由任何AI Agent（客户端）使用。

这里有个深刻的洞察：我们正在见证「能力标准化」的诞生。就像USB标准化了设备连接，MCP正在标准化AI Agent能力。任何工具都可以暴露自己的功能，任何AI Agent都可以使用这些功能，不需要定制集成。

我们预计随着远程MCP和事实上的注册表上线，会看到更广泛的采用。随着时间的推移，应用可能开始默认附带MCP界面。想想API如何让SaaS产品相互插入并跨工具组合工作流。MCP可以通过将独立工具转化为可互操作的构建块，为AI Agent做同样的事情。

这引出了一个有趣的想法：「能力市场」的出现。想象一下，未来有一个庞大的能力注册表，AI Agent可以发现和使用新能力，就像开发者现在使用npm或PyPI一样。需要发送邮件？有个MCP服务器。需要图像处理？有个MCP服务器。需要自定义业务逻辑？有个MCP服务器。

这不仅仅是技术标准，它是一种新的商业模式：能力即服务（Capabilities as a Service）。任何人都可以创建一个MCP服务器，暴露一个有用的能力，然后让所有AI Agent使用它。这就像云计算的下一个阶段：不仅计算资源商品化了，连能力本身也商品化了。

抽象原语：

每个 AI Agent 都需要认证、计费和持久存储

这个趋势反映了一个基本的进化规律：抽象层次不断提升。随着vibe coding AI Agent变得更强大，有一件事变得清楚：AI Agent可以生成大量代码，但它们仍然需要一些坚实的东西来插入。

就像人类开发者依赖Stripe进行支付、Clerk进行认证或Supabase进行数据库能力一样，AI Agent需要同样干净和可组合的服务原语来搭建可靠的应用程序。这里有个有趣的观察：AI Agent不是要取代基础设施，而是要更好地利用它。

在很多方面，这些服务——具有清晰边界、符合人体工程学的SDK和减少失败机会的合理默认值的API——越来越多地充当AI Agent的运行时接口。

想想这个场景：你告诉AI Agent「创建一个带有用户认证和订阅管理的SaaS应用」。AI Agent需要什么？它需要一个认证系统（Clerk），一个支付系统（Stripe），一个数据库（Supabase），可能还需要邮件服务、文件存储等等。

这引出了一个深刻的洞察：AI Agent重塑了「框架」的概念。传统框架给你一个结构，你在里面填充逻辑。AI Agent框架给你一套原语，AI  Agent可以组合成任何结构。

随着这种模式的成熟，我们可能开始看到服务通过不仅暴露API，还有架构、能力元数据和帮助AI Agent更可靠地集成它们的示例流程来为AI agent消费进行优化。

这就像从「自底向上」变成「自顶向下」。以前，你从基础设施开始，逐层向上构建。现在，你从意图开始，AI Agent帮你找到合适的构建块。这不是反向工程，而是正向设计。

一些服务甚至可能开始默认附带MCP服务器，将每个核心原语转化为AI Agent可以安全、开箱即用地推理和使用的东西。想象一下，Clerk暴露一个MCP服务器，让AI Agent能够查询可用产品、创建新的计费计划或更新客户订阅——所有这些都预先定义了权限范围和约束。

AI Agent不再需要手写API调用或在文档中搜索，它可以说「为产品X创建一个月费49美元的专业版计划，支持基于使用量的超额收费」，Clerk的MCP服务器会暴露这个能力，验证参数，并安全地处理编排。

这带来了一个有趣的现象，我称之为「声明式基础设施」。AI Agent不需要知道如何实现用户认证，它只需要声明「这个应用需要用户认证」，然后让合适的原语服务处理具体实现。

更深层次的影响是，这可能会导致「即时最佳实践」的出现。这些服务不仅提供功能，还编码了最佳实践。当AI Agent使用Stripe集成时，它自动获得了处理订阅、管理失败付款、处理退款等的最佳实践。

这就像建筑行业的标准化组件。你不需要每次都从零开始设计电气系统，你使用标准的开关、插座和配线方法。AI Agent也不需要每次都从零开始实现认证，它们使用经过验证的、标准化的服务。

最有趣的是这可能创造的「能力生态系统」。随着越来越多的服务变得对AI Agent友好，我们可能会看到一个新的市场出现：专门为AI  Agent设计的原语服务。这些服务的SDK不再针对人类开发者，而是针对AI Agent，用简单的接口和明确的约束来暴露强大的能力。

结语：软件开发的下一章

这九个趋势指向一个更广泛的转变，新的开发者行为正在与更强大的基础模型一起出现。作为回应，我们看到新的工具链和像MCP这样的协议形成。这不仅仅是将AI叠加在旧工作流上，而是对如何在核心由AI Agent、上下文和意图构建软件的重新定义。

我想强调的是，这些趋势不是独立的。它们互相强化，共同构成了一个新的开发者生态系统。AI原生的版本控制系统依赖于标准化的能力接口；合成式界面受益于语义化的无障碍API；异步协作模式需要强大的秘密管理系统。

这让我想起了每一个技术革命的规律：开始时，新技术模仿旧模式；然后，我们开始探索新技术的独特可能性；最后，我们重塑整个系统以充分利用新能力。我们正在经历第二到第三阶段的转变。

许多开发者工具层正在发生根本性转变，这不仅是技术的进步，更是思维方式的革命。我们正在从「编程」转向「意图表达」，从「版本控制」转向「意图追踪」，从「文档」转向「知识神经网络」。

也许最重要的是，这些趋势预示着软件开发角色的根本变化。未来的开发者可能更像交响乐指挥，协调不同AI Agent的工作，而不是像现在这样，更像独立的器乐演奏者。

这个转变既令人兴奋又有些不安。我们正在进入一个未知的领域，新的规则还在形成。但历史告诉我们，每一次技术革命都创造了比它摧毁的更多机会。关键是保持开放的心态，适应变化，同时坚持那些让我们成为优秀开发者的核心价值：解决问题、创造价值、服务用户。

我们很兴奋构建和投资下一代工具，不仅是为了更高效地编程，而是为了解决以前无法解决的问题，创造以前无法想象的可能性。这就是技术进步的真正意义：不仅是做得更快，而是做得更多，做得更好。