AWS 将 Superblocks 引入私有云，重塑亚马逊与谷歌的 AI 竞赛

AWS 在亚马逊与谷歌的云竞争中采取了一项不同寻常的举措：帮助 Superblocks 完全运行在客户的私有 AWS 环境中。这一安排让第三方 vibe coding 平台更贴近企业数据、安全控制和采购体系，也挑战了这样一种假设：AI 应用必须始终依附于帮助创建它的模型公司。

Superblocks 于 2026 年 8 月 3 日宣布与 AWS 建立合作伙伴关系，并同时发布 Superblocks 3.0。其平台允许员工通过自然语言指令创建业务应用，这种做法通常被称为 vibe coding。关键变化在于，这些应用、提示词、模型及配套资源能够在何处运行。

根据新的部署模式，Superblocks 表示，其平台运行在客户的 AWS 账户内，并使用 Amazon Bedrock 进行 AI 推理。AWS 提供基础设施边界和模型网关，Superblocks 则提供应用构建与治理层。

这一架构带来的压力不止于拥挤的 AI 编程工具市场。它让 AWS 有机会承接由 OpenAI、Anthropic、Replit、Lovable 等产品创建的应用。Google Cloud 也通过 Vertex AI 面临同样的战略问题：承载应用的云，是否会比生成应用的模型更重要？

答案取决于企业是否接受 Superblocks 作为一条从原型到生产环境的受控路径，也取决于其私有部署主张能否经受真实的安全、运营和合规审查。

Superblocks 3.0 将 Vibe Coding 置于 AWS 边界之内

核心变化并非又一个编程助手，而是一条将 AI 生成的应用迁入由企业 IT 控制的基础设施的托管路径。

Superblocks 将其 Cloud-Prem 架构描述为部署在客户 AWS 账户内的专属单租户环境。单租户部署为单一客户提供隔离实例，而非与其他组织共享应用环境。

该公司表示，该部署包含其控制平面、数据平面和 Clark AI 推理。控制平面管理应用和策略，数据平面则执行代码并连接私有业务系统。

AI 请求通过 Amazon Bedrock 发送，并使用由客户批准的模型和区域。应用连接至位于客户私有数据附近的 Superblocks 数据平面。该公司称，此举可在保持区域隔离的同时减少数据移动。

Cloud-Prem 架构还利用现有的 AWS 身份、网络、加密和审计控制。员工通过组织的身份提供商进行认证，管理员则应用既有访问策略。

这不同于仅将托管应用构建器连接到企业数据库。根据 Superblocks 的说法，完整的应用构建环境都位于客户的云边界内。

当员工要求某个应用存储数据时，Superblocks 表示，该平台可以在该边界内配置 Amazon Aurora 或 Amazon S3 资源。当应用从开发阶段进入生产环境时，它也可以运行数据库迁移。

这些操作至关重要，因为生成的代码只是可运行业务应用的一个组成部分。生产级软件还需要数据库、身份、权限、网络路径、部署阶段、日志以及明确的责任主体。

Superblocks 正试图将这些组件打包成一条业务员工可用的路径，同时避免赋予他们不受限制的云访问权限。安全和平台团队则通过 Superblocks 与 AWS 控制台保留监督权。

其 8 月的公告还介绍了一项导入功能，可导入使用 ChatGPT、Claude、Replit、Lovable 和原始代码创建的原型。导入后的应用将进入 Superblocks 环境，团队可在其中将其连接至获批准的数据和部署流程。

这使该产品不再那么依赖于充当创意起点。Superblocks 反而可以成为实验性应用转为正式运行应用的受控落点。

该公司的 Superblocks 3.0 公告将其定位为首席信息官和首席安全官的一条中间路径。他们不必禁止员工自建应用，也无需让这些应用游离于常规治理之外。

这一表述来自 Superblocks，而非独立安全评估。不过，背后的问题并不陌生。生成式编程工具让员工创建软件的速度，超过了许多公司盘点、审查或支持这些软件的能力。

AWS 部署为这些公司提供了另一种选择。它们可以尝试将员工的实验性工作纳入同一技术边界，而这一边界原本已用于治理成熟工作负载。

亚马逊与谷歌的竞争为何正转向模型层之上

亚马逊和谷歌日益争夺成为应用之下持久运行层的地位，即使首选 AI 模型由另一家公司提供。

早期的生成式 AI 竞争围绕模型质量展开。企业比较基准测试、上下文限制、编程表现和响应速度。这些指标仍然重要，但变化频繁。

企业应用的寿命通常长于其最初的模型优势。相比模型端点，其数据连接、审批工作流、身份规则和运营历史更难替换。

当客户将 Bedrock 视为这些应用之下的稳定网关时，AWS 将从中受益。Bedrock 通过托管接口和 AWS 治理控制，提供来自 Amazon 及外部供应商的模型。

AWS 表示，其模型选择工具可让客户评估和更换模型，无需重写整个应用。这一承诺并不能消除所有迁移问题。模型在提示词、工具使用、输出格式、行为和区域可用性方面仍存在差异。

不过，方向已经明确。AWS 希望模型选择成为在 AWS 内部管理的基础设施决策，而不是每个应用与某一家模型供应商之间的永久关系。

Google 也采取了类似立场。Vertex AI Model Garden 将 Google 模型、开放模型和部分第三方产品汇集于同一平台。

Google 表示，Model Garden为发现、测试、定制和部署模型提供了通用模式。Vertex AI 还将模型访问与评估、服务和组织策略相连接。

因此，亚马逊与谷歌的竞争已超越 Nova 与 Gemini 之间的较量。两家云服务商都希望客户构建能够使用多种模型的应用系统，同时保留一个云平台作为控制点。

Superblocks 为 AWS 提供了进入这场竞争的分发路径。这家初创公司提供员工能够理解的应用层，而 AWS 则提供企业技术团队熟悉的基础设施。

这种分工可以帮助两家公司。Superblocks 获得了已将敏感工作负载托付给 AWS 的客户；AWS 则获得了会消耗存储、数据库、日志、网络、安全服务和模型推理能力的应用。

模型提供商未必会消失。运行在 AWS 内的应用仍可使用通过 Bedrock 提供的第三方模型。只是商业和运营重心转向了承载应用的云。

Google 也可以借助 Vertex AI 及其自身的私有部署选项提出同样的论点。它面临的挑战不只是说服企业 Gemini 表现出色，还必须让 Google Cloud 成为在任何地方生成的应用的首选落点。

Microsoft 通过 Azure、GitHub 和其模型目录面临着同等任务。不过，亚马逊与谷歌的竞争最清楚地揭示了更广泛的战略模式，因为两家公司都拥有庞大的云和 AI 产品组合。

云服务商不需要拥有每一个胜出的模型，才能掌握周边工作负载。它需要的是数据库、身份系统、网络策略、日志、应用运行时以及采购关系。

这正是 Superblocks 合作关系的影响超出一家初创公司的原因。它让应用环境更易在模型供应商之间迁移，同时也让底层云关系更具价值。

AWS 正将模型灵活性转化为应用引力

将应用与单个模型解耦，可以减少一种依赖形式，却可能加深对协调一切的云平台的依赖。

Superblocks 将其 AI 代理称为 Clark。在 AWS 部署中，Clark 可以通过 Bedrock 使用由组织管理员选定的模型发送推理请求。

该公司还介绍了一种 Smart Router，可将复杂的应用请求拆分为更小的任务。它可以将困难的规划工作导向一种模型，并将常规编程工作导向另一种模型。

Superblocks 声称，这种路由可在不降低最终应用质量的情况下，将推理成本最多降低 30%。这一数字是公司估算，尚未在多样化的企业工作负载中得到独立验证。

更重要的理念是任务级模型路由。应用构建器不再需要由单一模型处理规划、代码生成、测试和修订的每一个阶段。

这种方式将模型视为可替换的计算资源。应用层决定哪种资源适合每项任务，云平台则负责访问、身份、容量和计费。

不过，模型并非真正可以互换。一种模型可能可靠地遵循工具模式，而另一种模型可能生成更好的界面代码。第三种模型或许擅长处理长文档，却难以生成精确的结构化输出。

路由系统必须持续评估这些差异。当模型不可用、行为发生变化，或在所需 AWS 区域不受支持时，它们还需要后备规则。

Superblocks 将自己定位为吸收这种复杂性的层。客户与应用构建系统交互，而非为每一个提示词选择模型。

AWS 将从中受益，因为每一项经路由的请求都可以留在 Bedrock 内。即使所选模型来自外部开发商，AWS 仍参与访问控制、推理交付和运营监控。

这形成了应用引力。一旦组织将 Superblocks 与 AWS 身份、私有数据库、软件包注册表、日志和部署流程连接起来，迁移整个系统就会变得困难。

相比周边控制体系，模型可以更容易地更换。这正是本次交易核心所在的解耦。

这并不意味着供应商锁定的终结，而是锁定累积位置的转移。

一家公司或许可以避免完全依赖 Anthropic、OpenAI 或其他模型开发商，但仍可能深度依赖 Bedrock API、AWS 基础设施和 Superblocks 应用定义。

Superblocks 表示其方法消除了供应商锁定，但这一说法应谨慎看待。将数据保留在客户自有的 AWS 账户中可增强控制力，然而运营可移植性所需的不只是数据所有权。

团队将不得不在其他地方重建身份规则、基础设施定义、应用逻辑、部署流水线、审计历史和模型路由行为。这项工作的难度决定了实际的可移植性水平。

Google 正在构建自己的应用引力版本。Vertex AI 将 Model Garden 与 Google Cloud 网络、数据服务、评估工具和策略控制连接起来。

因此，Amazon Google 之争正演变为对最佳抽象层的竞争。每家提供商都希望客户将模型视为可替换的，同时认为其云控制平面不可或缺。

Superblocks 在这场竞争中强化了 AWS，因为它让技术背景较弱的员工也能参与应用构建流程。更多构建者可以创建更多应用，而每个应用都可能消耗额外的 AWS 服务。

只有当企业能够对这种扩张进行治理时，它才有价值。否则，更快的创建速度只会产生规模更大的、无人支持的内部软件集合。

治理才是产品，但仍需证明

Superblocks 销售的是受控的生产访问能力，而不是不受限制的代码生成；这一承诺需要更高标准的证据支撑。

该公司表示，每一项代码变更在进入生产环境前，都会经过专门的安全代理和确定性扫描器。确定性扫描器通过固定规则查找已知弱点，例如硬编码凭据或不安全的数据流。

据称，安全代理会审查更广泛的应用上下文，包括身份验证、授权、API 和业务逻辑。管理员还可以针对组织特定要求定义策略代理。

Superblocks 表示，其生产控制措施包括私有软件包注册表和软件物料清单。软件物料清单记录应用中包含的组件和依赖项。

据称，该平台会持续扫描已部署的依赖项，以发现新披露的漏洞。当出现相关漏洞时，它可以向应用所有者发出警报。

这些都是有用的控制措施，但它们的存在并不能证明其有效性。安全代理可能遗漏细微的授权问题，批准不安全的生成逻辑，或产生足够多的误报，以至于管理员对其置之不理。

生成的应用也带来了所有权问题。当原始员工调岗、API 发生变化，或模型生成的工作流作出错误的业务决策时，必须有人决定由谁维护该应用。

云隔离无法回答这些问题。将代码和提示词保留在 AWS 账户内可以减少某些暴露路径，但并不能使生成的逻辑变得正确。

现有 IAM 策略也可能包含过多权限。即使应用完全运行在私有云内部，仍可能向错误的员工暴露敏感数据，或修改关键记录。

同样的谨慎也适用于 Superblocks 关于提示词和数据保留在客户安全 AWS 环境内的说法。买家必须核实哪些元数据、诊断信息、支持记录和管理事件会离开该环境。

该公司的架构说明，来自区域数据平面的通信可以仅限出站。组织仍需检查这些出站路径、支持机制、加密安排，以及 Superblocks 的管理权限。

Cloud-Prem 同样是一项托管服务。Superblocks 负责升级、安全补丁、可靠性和支持，而客户控制云级策略和部署边界。

这种分工可以减少运营工作，但也形成了共同责任。买家需要精确了解哪一方可以访问每个组件，以及在事件发生期间会如何处理。

私有部署也可能使升级更加复杂。Superblocks 必须支持具有不同网络限制、区域要求和审批流程的众多客户环境。

该公司表示会规划并执行升级。企业客户仍应测试这些变更是否能保留应用行为、模型路由、策略和集成。

另一个不确定性是采用情况。业务用户可能更偏好消费者编码工具带来的即时自由，而不是带有审查和推广阶段的获批平台。

Superblocks 试图通过导入现有原型来解决这一问题。这让员工能够从熟悉的工具开始，并在应用需要访问生产数据时进入受治理的环境。

这座桥梁在战略上是合理的，但也存在局限。导入的代码可能带来不受支持的软件包、许可不明、薄弱的假设，以及无法与 Superblocks 整齐映射的结构。

安全团队还需要证明应用清单始终完整。受治理的平台无法控制员工从未导入或披露的原型。

因此，Superblocks 论点最有力的版本需要行为改变，而不仅仅是技术部署。员工必须接受获批路径，而 IT 必须让这条路径比非正式替代方案更快。

压力落在编码平台和企业 IT 身上

最直接的失利者，是那些无法在不将应用迁移到其他地方重建的前提下，从快速原型跨越到受治理生产环境的平台。

面向消费者的编码工具降低了产出可运行原型所需的投入。它们通常为希望获得快速视觉反馈和直接部署的个人构建者而优化。

企业生产环境则引入了不同的要求。应用需要以受控方式访问客户记录、财务系统、内部 API 和受监管数据。

它们还需要审计日志、环境隔离、事件处理流程和明确的所有权。视觉效果令人信服的原型并不会自动满足这些条件。

Superblocks 瞄准的正是这两个阶段之间的缺口。它不需要阻止员工在构思期间使用 ChatGPT、Claude、Replit 或 Lovable。它需要掌握进入生产环境的过渡环节。

这一定位迫使其他氛围编码平台加入可比的治理和私有部署选项。否则，它们可能沦为为处理最终运营阶段的平台输送用户的入口。

这种压力也延伸至成熟的内部工具供应商。它们的产品已涵盖权限、数据连接和部署，但 AI 生成改变了谁能构建应用，以及应用数量增长的速度。

这些供应商必须支持非传统构建者，同时不能削弱最初吸引企业客户的控制能力。随着客户避免依赖单一 AI 供应商，它们也需要提供可信的模型灵活性。

云服务提供商面临另一项选择：它们可以构建自己的应用生成环境，或通过市场和销售渠道分发独立产品。

AWS 正通过与 Superblocks 合作采取伙伴路线，同时继续扩展 Bedrock 及其开发者服务。这种做法让 AWS 能够支持专门的应用体验，而不必拥有每一个界面。

Google 可以通过 Vertex AI、其应用开发产品和外部合作伙伴作出回应。Microsoft 可以将 Azure AI 服务与 GitHub 及其商业软件版图结合起来。

更深层的压力落在企业 IT 身上。无论这些工具是否出现在获批目录中，员工已经可以使用编码代理和基于浏览器的应用构建器。

封锁所有工具可能会将开发进一步推向官方监督之外。批准每一个实验则会制造安全和平台团队无法持续承担的审查工作量。

Superblocks 提出以自动化策略执行作为答案。如果其安全代理和部署控制如其所述发挥作用，IT 就可以审查规则和例外情况，而不是手动检查每一行生成的代码。

这一主张需要真实的运营证据。团队应衡量有多少应用进入生产环境、策略多久会阻止不安全的变更，以及解决例外情况需要多长时间。

他们还应跟踪被弃用的应用。更快的创建速度可能带来软件杂乱，包括重复的工作流和没有明确维护责任人的工具。

可搜索的工程知识库可以帮助团队保留设计决策、运行手册和应用上下文。它不能取代技术控制，但可以减少围绕员工构建软件的知识流失。

最重要的指标不是生成了多少应用，而是有多少应用能够保持安全、有用、得到维护，并且成本低于它们替代的流程。

如果 Superblocks 能证明这一结果，AWS 就能获得一条通过业务主导开发来扩大云服务消耗的可复制路径。如果做不到，这一合作关系仍将只是一个有吸引力的部署故事，缺乏经过验证的运营模式。

Amazon Google 云竞争的下一步

三个信号将表明，这一合作关系究竟会改变企业应用开发，还是成为另一个有限的私有云选项。

第一个信号是生产采用情况。AWS 和 Superblocks 需要让客户通过 Cloud-Prem 架构运行有实际意义的应用，而不仅仅是评估演示或孤立的试点项目。

有价值的证据包括应用数量、活跃构建者数量、生产使用情况、事件发生率，以及将原型投入使用所需的时间。客户案例研究应区分实际测量结果与 Superblocks 提供的估算。

在受监管行业中的采用将加强这一核心论点。这些组织最有理由要求数据驻留、可审计性和对模型访问的控制。

缓慢的部署则会削弱这一论点。这将表明，私有云安装和治理为 Superblocks 希望服务的员工带来了过多摩擦。

第二个信号是直接的竞争回应。Google、Microsoft、成熟的内部工具供应商和其他氛围编码平台，如今都有理由强化各自从原型到生产的路径。

有意义的回应将结合模型选择、客户控制的基础设施、策略执行和应用生命周期管理。仅仅增加另一个代码生成器无法解决同样的问题。

Google 尤其重要，因为它已提供广泛的模型目录和私有部署能力。如果 Google 将这些资产与同样易于使用的业务应用层连接起来，Amazon Google 之争将进一步加剧。

此类举措将强化这样一种观点：模型正在成为由云控制的应用系统中的组件。反应平淡则表明，竞争对手将 Superblocks 视为更狭窄的内部工具产品。

第三个信号是成功切换模型的证据。Superblocks 和 AWS 主张，组织可以在获批模型之间路由任务，而无需将应用绑定到单一提供商。

客户应在实际的模型升级和替换期间测试这一主张。他们需要衡量输出质量、应用故障、延迟、策略行为，以及每次变更所需的工程工作量。

轻松切换将强化 AWS 的定位。这将表明，Bedrock 和 Superblocks 能够将长期运行的应用与较短的模型周期分离。

频繁故障或大量提示词重写将削弱解耦论点。它们将揭示，即使位于统一的云界面之后，模型特定行为仍嵌入在应用逻辑中。

买家还应审视由此形成的依赖关系图。替换模型可能变得更容易，而替换 AWS 或 Superblocks 则可能变得更困难。

这种权衡并不必然不利。企业往往愿意接受对基础设施的依赖，以换取一致的安全性、支持服务和采购流程。

不过，这一决策应当是明确作出的。私有云部署能够让企业掌控数据的位置和访问权限，但并不保证跨平台的可移植性。

AWS 与 Superblocks 的合作之所以重要，是因为它将 AI 软件的持久价值置于模型本身之上。应用程序、其数据连接和治理机制，可以比最初生成代码的任何模型存续得更久。

这正是 Amazon 与 Google 竞争的走向。云服务提供商希望掌控模型转变为可问责的业务系统的运行环境。

对于开发者和企业买家而言，下一步很务实：先针对一款导入的应用程序，依据真实的安全策略进行测试，然后替换其所使用的模型。结果将揭示，这种架构究竟能否真正带来灵活性，还是仅仅将依赖关系转移到了另一层。