AWS把氛围编程塞进企业私有云：Superblocks想成为AI应用时代的“安全工厂”

氛围编程最初流行时，画面通常很轻松：一个人对着AI描述想法，几分钟后就得到一个可以运行的网页、应用或自动化工具。它削弱了“会不会写代码”的门槛，也制造了一个很容易被忽略的问题——当这种能力进入大型企业，生成出来的软件究竟运行在哪里、接触什么数据、由谁授权、出了事故谁能追溯？

个人开发者可以容忍一个原型连接外部数据库、调用第三方模型并使用临时账号；银行、医院、航空公司和大型互联网企业不能。

这正是Superblocks与Amazon Web Services达成多年联合市场合作的背景。合作后，AWS企业客户可以把Superblocks直接部署在自己的私有云环境里：应用使用企业AWS账户中的网络与身份体系，数据留在VPC内，数据库可以落在Amazon Aurora，模型推理通过Amazon Bedrock完成，审计、加密、网络策略和权限控制继续由企业IT团队掌握。

表面上，这是AWS帮助一家约50人、累计融资约6000万美元的创业公司拓展企业客户；更深一层，它标志着氛围编程正在经历第二阶段：从“让人快速做出软件”，转向“让企业允许更多人安全地做出软件”。

Superblocks押注的不是代码生成模型本身，而是代码生成之后那套更难、更昂贵、也更接近企业预算中心的基础设施。

企业真正害怕的不是员工不会写代码，而是员工突然都会写

传统企业软件开发的瓶颈很明确：业务部门有需求，工程团队排期，IT与安全团队审核，数周或数月后才能得到一个内部工具。氛围编程把第一步压缩到几分钟，需求方可以直接生成审批系统、运营面板、客户支持工具和数据查询应用。

速度提高后，旧流程并没有消失，只是被绕过去了。

业务人员可能使用Lovable、Replit、Claude或其他AI工具生成一个应用，把数据存入外部Supabase实例，将API密钥写入配置文件，再通过个人账号上线。应用能工作，但企业不知道它存在；安全团队看不到它访问了哪些数据；员工离职后权限可能仍然有效；模型供应商是否接触敏感信息也难以判断。

这就是“影子AI应用”。它与早年的影子IT类似，却更快、更分散，也更容易触及生产数据。过去，一个未经审批的SaaS工具至少需要采购和配置；现在，一名业务员工可能在午休时间生成一套看似完整的内部系统。

Superblocks给出的答案并不是禁止业务人员使用AI，而是把生成行为放进一个企业预先控制的工厂。IT团队配置身份、角色、数据库连接、密钥、审计、设计系统和部署政策，之后每个由AI生成的应用自动继承这些规则。

它试图让“谁都能做应用”和“企业仍然可治理”同时成立。

从低代码工具，到企业氛围编程的控制平面

Superblocks由Brad Menezes和Ran Ma在2021年创办。早期产品定位更接近可编程的内部工具平台：工程团队使用组件、SQL、JavaScript、Python、API和工作流，快速构建运营后台、审批工具和定时任务。

这个市场并不新鲜。Retool、Appsmith、Mendix、Microsoft Power Apps等产品都在减少内部软件开发成本。Superblocks最初的差异化，是在可视化构建之外保留开发者级扩展能力，并通过本地代理、权限与审计适配大型企业。

生成式AI改变了它的用户边界。Superblocks推出名为Clark的AI Agent，用户可以用自然语言生成应用、工作流和任务，输出React和TypeScript代码，并允许工程师继续查看、修改和扩展。平台从“帮助开发者少写一部分代码”，走向“让非开发者也能启动软件生产”。

但Superblocks没有把自己包装成一个更聪明的聊天框。它把产品分成三部分：负责理解需求和生成软件的AI Agent；负责连接数据库、SaaS、内部API与身份系统的运行时；负责权限、审计、密钥、版本和部署的治理层。

这三部分构成了它真正的战略位置。模型可以替换，界面可以变化，但企业应用一旦接入真实业务，谁掌握连接、权限和运行记录，谁就掌握持续价值。

AWS合作解决的不是“能不能生成”，而是“能不能进入生产”

根据合作安排，Superblocks可以嵌入AWS客户的私有云。应用不需要把业务数据发送到外部模型商或外部数据库，而是在企业自己的AWS账户内调用资源。数据可以存放在Aurora，推理可以走Bedrock，身份与权限沿用IAM和企业既有体系，网络访问受VPC策略约束。

这套架构对大型客户的意义有四层。

第一层是数据驻留。企业不必为了使用氛围编程，把敏感客户数据、财务信息和内部运营数据复制到新的SaaS边界之外。

第二层是模型选择。Bedrock提供多模型入口，企业不必把应用永久绑定在单一模型公司上。今天可以选择Anthropic，明天可以根据成本、延迟、合规或能力切换其他模型，应用层和数据层不需要一起迁移。

第三层是治理继承。新应用在创建时就继承组织的权限、审计、网络和密钥规则，而不是上线后再由安全团队补洞。

第四层是采购与分发。AWS不仅提供基础设施，也通过Marketplace和销售体系帮助Superblocks进入客户。对一家早期创业公司而言，大型企业最难的往往不是产品演示，而是安全审查、供应商准入、合同、账单和跨部门信任。云厂商可以显著缩短这条路径。

因此，这项合作不是简单的“上架AWS”。它让Superblocks从企业外部的开发工具，变成企业云账户内部的一层软件生产能力。

AWS为什么愿意扶持一家自己可能做掉的创业公司

AWS拥有Kiro等面向开发者的AI编程工具，也拥有面向业务用户的AI助手，但还没有完全对应Lovable或Replit的企业业务应用生成产品。与Superblocks合作，可以快速补上这个入口，而不必立刻从零建立产品、生态和客户使用模式。

更重要的是，Superblocks生成的应用会消耗AWS资源。Aurora承载数据，Bedrock承载推理，VPC和IAM承载网络与权限，日志和存储继续留在AWS体系。即使应用构建层由创业公司提供，底层使用量仍回到云平台。

这符合超大规模云厂商在AI时代的共同利益：模型正在商品化，真正稳定的收入来自应用运行、数据存储、网络、安全和推理消耗。云厂商不需要垄断每一个AI应用，只需要确保这些应用在自己的基础设施上生长。

它们也希望企业把模型与应用脚手架分开。单一前沿模型公司如果同时掌握模型、Agent编排、应用运行和企业数据，就可能向云平台上方扩张。多模型架构则让AWS重新成为中立控制层：模型彼此竞争，应用公司彼此竞争，基础设施仍由云厂商提供。

从这个角度看，AWS帮助Superblocks，也是在阻止OpenAI、Anthropic或其他模型厂商独占企业AI应用栈。

模型越来越可替换，应用“脚手架”越来越值钱

企业AI采购正在发生微妙变化。早期客户往往先问“你使用哪一个模型”，仿佛选择模型就等于选择能力。随着模型差距缩小、开源模型成熟、路由与评测工具普及，问题逐渐变成“能否根据任务切换模型”。

Superblocks披露的客户反馈显示，企业对单一模型的执念正在快速减弱。它们希望在编码、客服、人力资源、销售自动化等不同场景中组合前沿闭源模型、美国开源模型和中国开源模型。Vercel等AI网关观察到的开放模型流量增长，也说明多模型不再只是技术团队的保险方案，而正在进入生产使用。

一旦模型可替换，应用价值就向上层迁移。真正难以迁移的是业务逻辑、权限结构、数据连接、审计历史、内部组件、用户习惯和运营流程。

Superblocks所谓“受治理的企业氛围编程”，本质上是在争夺这层粘性。Clark生成代码只是获客入口；企业把数据库、身份系统、内部API和审批流程接入平台后，Superblocks才开始建立长期价值。

这也解释了为什么公司强调其MCP与“可查询的软件系统记录”。当一家企业出现数百个AI生成应用，管理者需要知道谁创建了什么、连接了什么、使用什么权限、是否仍在运行、是否符合政策。应用目录和治理数据可能比单个生成器更重要。

Superblocks要替代的，可能不只是开发工具

氛围编程通常被理解为提高程序员效率，但Superblocks瞄准的是更广泛的企业软件预算。

大量企业流程仍运行在电子表格、邮件、Jenkins表单、旧式SaaS和定制后台里。它们不是没有软件，而是软件与流程不匹配。传统SaaS为了服务最大公约数，功能复杂且价格逐年上涨；定制开发又排不上工程团队的优先级。

如果业务部门可以在受控平台上生成适合自己的应用，企业可能减少购买一部分边缘SaaS，也可能把旧系统逐步替换成小型定制工具。Superblocks官网直接把“替代昂贵SaaS”“消灭电子表格流程”“把原型安全推入生产”列为核心场景，说明它不满足于做辅助开发工具，而希望成为内部软件工厂。

这条路线的商业价值远高于按席位售卖代码补全。它触及的是企业应用开发、低代码平台、内部工具、集成平台、流程自动化和部分SaaS支出。

但它也会遭遇更强竞争。Microsoft拥有Power Platform、Copilot和Azure，天然掌握企业身份与办公入口；Google可以把Gemini与Workspace、Cloud连接；Salesforce能把Agent能力嵌入数据和CRM；ServiceNow本身就是企业工作流中心。AWS与Superblocks的组合，要证明自己能比这些纵向整合者更开放、更快，同时保持同等级别的治理。

“安全默认”是卖点，也是一项必须被验证的承诺

Superblocks最大的营销主张，是AI生成的每个应用都能安全、可审计、受治理。但企业安全从来不是一个开关。

平台可以提供RBAC、SSO、审计日志、密钥管理和网络策略，却无法自动替企业决定每个岗位应该拥有什么权限。如果最初的角色设计错误，生成速度越快，错误也会扩散得越快。真实用户反馈显示，Superblocks在权限设计、复杂应用调试、单元测试、错误信息、深层自定义和大数据量性能方面仍存在改进空间。

这意味着“默认安全”应被理解为默认提供治理工具，而不是默认不会出问题。

当业务用户用自然语言生成应用时，还会出现新的审查难题：提示词是否成为需求文档？AI自动选择的数据源是否经过授权？生成代码如何测试？应用升级后权限是否漂移？模型切换是否改变输出行为？如果企业一周生成数百个应用，安全团队不可能逐个手工审核。

Superblocks需要把政策变成可执行规则。其方向包括让Clark读取设计系统、代码安全、审计政策等规则文件，并在提交时验证。真正成熟的产品还应提供自动风险分级：只读报表与能修改生产数据库的应用，不能使用同一套审批流程；接触个人健康数据的工具，也不能与普通销售面板共享默认策略。

公司能否把治理自动化做得和生成自动化一样强，将决定它是企业AI时代的基础设施，还是一个包装更完整的低代码平台。

创业公司的机会：不与模型竞争，而是管理模型的后果

Superblocks给AI创业者展示了一条不同路线。过去两年，大量公司试图训练更强模型或封装某个模型能力，但基础模型迭代太快，功能很容易被上游吸收。企业真正愿意长期付费的，往往是把能力带入生产所必需的控制层。

这类机会有几个共同点：模型无关、数据贴近客户、与身份权限深度结合、产生持续运行记录、能在多个业务场景复用。它们看起来没有模型演示那么惊艳，却更接近企业采购的刚性需求。

Superblocks的风险也很清楚。AWS今天是渠道和基础设施伙伴，明天可能推出更直接的竞争产品；模型厂商可能向企业运行时延伸；微软等综合平台可以通过捆绑压低价格。创业公司必须在巨头完成产品拼图之前，积累足够多的应用、连接器、治理模板和客户信任。

其另一项挑战是避免成为纯粹的AWS附属层。虽然此次合作强调AWS私有云，Superblocks仍需要维持跨AWS、Azure、Google Cloud及本地环境的部署能力。大型企业通常是多云的，如果平台价值建立在模型与基础设施中立性上，就不能把自己绑定到单一云厂商。

氛围编程的第二波，属于“允许创新”的基础设施

第一波氛围编程证明，AI可以让更多人快速做出软件。第二波要解决的是：这些软件如何被企业看见、管理、复用和安全运行。

AWS与Superblocks的合作把行业矛盾摆到了台面上。企业并不缺生成应用的能力，缺的是一种在不牺牲数据边界和治理权的情况下释放这种能力的方法。禁止员工使用AI不现实，放任影子应用增长也不可接受，于是“受治理的生成”成为新的平台类别。

Superblocks是否会成为这个类别的赢家仍未确定。它的产品需要在易用性与工程深度、业务自治与IT控制、快速生成与长期维护之间保持平衡。任何一侧走得太远，都会失去另一侧用户。

但这项合作释放的行业信号已经足够清晰：未来企业选择AI开发平台时，不会只比较谁生成界面更快、谁写代码更漂亮，而会比较谁能把生成出来的上百个应用纳入同一个安全边界，谁能让模型自由切换却不让业务系统失控，谁能把软件生产速度变成组织能力，而不是新的技术债务。

在AI让代码越来越便宜之后，控制代码如何进入现实世界，正在变成更昂贵的生意。

RecodeX 极客视