最近，Andrej Karpathy在推特上发布了一篇文章，讨论了2025年构建Web应用的现状。他要说的是很简单：这不再仅仅关乎编写代码，而是关于集成、适配、编排调度和配置。

_> “这根本就不是代码，而是……配置、管道配置、编配、工作流程、最佳做法。”

他说得没错。

要构建一个基本的 web 应用，比如说，你需要拼凑以下内容：

• 前端和后端框架
• 托管服务（CDN、HTTPS、域名）
• 一个数据库
• 认证
• 云存储
• 邮件
• 支付
• 后台任务（任务）
• 监控
• CI/CD
• 密钥
• 等等等等

这不仅仅是令人应接不暇——它还很脆弱。每个连接点都可能成为脆弱的环节。所谓的“简单整合”背后隐藏着配置文件、命令行标志、环境变量等，相关文档和说明则散落于五个浏览器标签页中。

即使你知道该怎么做，让所有部分一起协调工作还是会很头疼。特别是你一旦超出新手指南的范围。

为了方便起见，许多公司建立了垂直平台（垂直一体化平台），提供端到端的解决方案，简化了底层架构。

想想 Firebase、Heroku、Vercel，还包括大型公司内部的开发平台。这些平台的目标是简化整个开发流程：你写一些代码，点一下按钮，一切运行顺畅。

而且这种方法管用——直到某天不管用了。

取舍在于牺牲可组合性。一旦你需要做平台未曾预料到的事情，你就无能为力了。没有出路。你无法轻松更换数据库、定制部署流程或集成公司的内部工具。

在我看来，Kubernetes 赢得容器编排战争的原因是，它并不是最简单的选择。但它是 可组合的。它为团队提供了一个可以扩展和构建的系统。

阿斯派也在采取同样的做法，而是针对整个应用生命周期，而不是单个容器。

Aspire 给你提供了一个模型来描述你的整个应用——不仅代码，还包括所有相关的部分。每一个服务，每一项依赖，以及你应用接触的每一部分基础设施。

这个模型的构建块是资源。每个资源描述系统中的一个组件，例如一个可执行程序、一个容器、一个云服务、一个队列或者一个数据库，等等类似的东西。

这些资源展示了清晰的合约配置——它们是如何被配置的，连接什么，执行和部署的方式是什么。

然后我们把它们接起来。

在 Aspire 里，连接一个 web 应用到数据库不是设置这个环境变量并祈祷一切顺利。这样做：

    builder添加项目("web")  
           .带有引用(postgres);

那个引用不仅仅是一个符号链接（软链接），它是一个契约。系统理解它的意思。当你运行或发布应用时，Aspire 会确保一切都能正确配置：密钥（密钥凭证）、连接字符串、端口映射和卷，以及经常在 YAML 文件或文档中定义的特定于平台的设置。

把Aspire想象成一个相互连接的组件集，而不仅仅只是一个垂直堆叠。

• 你想定义你的组织如何使用 Redis 吗？创建一个 托管集成服务。
• 你想让发送邮件的过程兼具可观测性和自动重试功能吗？将其建模为一个 资源模型。
• 你想将平台的数据库配置流程接入吗？编写一个自定义发布程序。

我们不是在隐藏复杂性，而是在让它变得更像乐高积木，各种组件来自不同的供应商或团队，但拼在一起时肯定能完美匹配。

Aspire不是一个预装一切的平台。它是一个具有扩展点的平台框架。

卡拉帕蒂还强调了另一个重要的观点，比如……

“能够让这款产品开箱即用，无需任何调整，对于人类以及越来越重要的AI来说，特别是对AI来说，能使其‘真正发挥作用’的人，将会赢得许多荣誉。”

我们认为Aspire就是所说的那个平台。

它给人类提供了一个强合约性、易于发现，并且包含可重复利用的构建模块的系统。

这为人工智能提供了一个结构化且可检查的应用程序模型，帮助你构建应用程序。

与其问 LLM “如何将后端连接到PostgreSQL容器上？”，你可以问“这个应用模型中定义了哪些资源?” 或者“你能帮我扩展这个托管服务集成？”

那是一种根本不同的经历。它将我们从修水管带回到设计。

现代 web 应用的复杂性在于功能的多少，而在于各个功能之间的连接。

我们花了几年时间构建更好的组件模型以优化代码。Aspire 的目标是将同样的严谨性与可复用性应用于所有其他部分：基础设施、配置、编排。

其他平台更方便——不过使用灵活性较差。

Aspire追求更大的目标：一个可组合和可扩展的系统，一个与你一起成长的系统。在该平台上，你的应用由可以“拼接在一起”的资源构成，而不是用胶带粘合的脚本和猜测的拼凑。

这就是我们到2025年扩展软件规模的方法——不只是通过掩盖复杂性，而是通过建模来应对。