Adrian Twarog：为企业 Vibe Coding 铺一条可治理的上线路径

公司只要有一个治理不善的应用，就可能让客户数据面临风险。如果你负责技术或安全，挑战已经不限于工程团队做出的软件。董事会一推动采用 AI，编程工具就会交到销售、财务和运营手里，IT 还没审查，几百个应用已经冒了出来。

这些应用仍然需要存放数据的地方、运行的地方，以及验证用户身份的办法。如果每个数据库或每次部署都要开一张工程工单，人们就会自行变通：个人账户密钥、公开分享链接、无人跟踪的数据库，都成了把应用跑起来的捷径。与此同时，让开发变快的同一波 AI 进展，也在增强攻击者的能力。

想靠禁止员工使用这些工具来解决问题，恐怕行不通。我们需要一条可靠的上线路径：业务团队可以构建，安全团队定规则，应用遵守这些规则。一位 Global 2000 公司的 CIO 曾说，几百名非工程师在用消费级工具做应用，而 IT 既看不见这些应用，也看不见不断扩大的攻击面。

设想一家公司正在推广 Claude Code，鼓励每个人把自己的工作自动化。销售部的 Maya 想要一个 Salesforce 仪表板，同事们想要报销工具和工单系统。这些都是平常、有用的想法。真正的问题是：这类活动在整个组织里同时发生，速度快过传统 IT 团队逐个检查每个应用。

业务用户未必意识到，把个人数据库密钥交给应用，或把密钥分享给同事，会有什么后果。安全团队既要处理由此而来的暴露，又要应对越来越强的 AI 辅助攻击。与此同时，每个应用都要配数据库、登录和运行环境，IT 就变成拖慢所有人的排队窗口。

我在看 Superblocks，是因为它把业务应用创建和集中治理放进了同一套系统。Lovable、Replit 这类工具让快速做原型变得容易，Claude 也越来越多地进入工作流。对企业来说，问题是 IT 和安全如何继续掌控最终上线的东西，尤其是在医疗、金融服务这类受监管的行业。

这里讲的部署模式，把应用及其数据留在公司自己的 AWS 账户里。应用发布时，平台可以跑多项安全策略：检查代码里有没有暴露的密钥和可注入的数据库查询，检查函数和端点，并对照已知漏洞核验软件包。技术和安全团队还可以用通俗的语言写出本组织特有的策略。

这些策略给组织内部做出的应用提供一套共同要求。一旦查出问题，AI 可以帮忙修复。关键是把安全嵌进应用在平台上走的那条路，而不是指望另一支安全团队去手工发现、审查员工做出来的每一个工具。

开发者可以通过 Superblocks MCP 继续在 Claude Code 里工作。他们可以连到已批准的 Postgres 数据库或组织的 AWS 资源，对着测试数据开发。到了上线时，由 IT 提供生产连接。在我讲的这套流程里，访问走 Superblocks，Claude 不必拿到底层凭据，应用仍然要接受平台的检查。

数据库之所以重要，是因为你若不提供受支持的选项，人们也会自己找地方存数据——哪怕一张电子表格也能变成存储层。Superblocks 可以在公司的 AWS 账户里运行应用数据库。每个应用都有自己隔离的 Postgres 数据库，开发和生产实例分开，团队就不必把数据散落到各自挑选的厂商服务里。

这样安排，IT 就有一个集中的地方来管理应用访问、安全和成本。策略智能体会检查应用，Security Center 能把新发现的漏洞呈现出来，活动也会记入日志。管理员看得见正在做什么、授了哪些权限。员工各自用消费级编程工具做企业应用时，我发现缺的正是这种组织层面的可见性。

登录之后，Superblocks 首页提供基于提示词的应用构建器、已有应用、集成和安全管理。这次演示里，我想做一份员工通讯录，方便大家在组织里找同事。我把提示词接到一个 Postgres 集成上：这个集成我只配置过一次，并共享给相关用户组，其他人可以基于这个连接开发，却看不到凭据。

平台会建好工作区，并从规划模式开始，动手之前可能会先提问。它还会取回公司维护的知识，包括组织背景、UI 和设计规范、数据格式约定和安全规则，给智能体一套共用要求，而不用每个员工从零写起。

规划完成后，我切到构建模式，让智能体生成应用。完成后的界面右侧是应用的实时预览，左侧是对话。我随时可以查看生成的代码，必要时也可以拿到别处去用。构建器还提供控件，把应用分享给指定的人，或嵌进别的场景。

我特别喜欢的一个功能是 API 调用视图。在员工通讯录里，我能看到员工查询背后的数据库语句、调用花了多久、返回了什么数据。我操作应用时，界面会跟踪这些调用。普通业务用户也许永远不需要这些细节，但在追查一个应用如何工作时，这正是我想要的可见性。

集成是应用连接组织已有数据库和服务的方式。菜单里有 GitHub、MongoDB 这类选项；这个例子里我选 PostgreSQL。一个连接可以有默认或生产环境，也可以有自定义的开发环境。配置完成后，我测试连接，再在各个应用里复用。

管理区把用户、用户组、权限和安全策略放在一起。从某个用户的条目，我可以查看他做过的应用。我打开一个 Account 360 应用，里面展示各区域的客户账户，作为管理员还能查看底层代码。如果每个人都在个人 Claude Code 账户下各自开发，组织就不会有同样的集中视图。

用户通过公司的单点登录进入，Okta 这类身份系统及其安全组保持同步。用户组可以代表 IT、工程、业务运营或其他团队。管理员、开发者、用户这类角色决定这些组能做什么；角色与权限页面则让组织控制创建、修改、部署和分享应用等操作。

知识库给构建智能体一个地方，去查找组织里的事实和说明。它们可以是直白的 Markdown 文件，介绍公司做什么，或规定 UI 颜色、字体和其他设计约定。我可以查询这些材料，智能体会取回它需要的背景。这种做法像是提供可复用的技能，而不是每条提示词都把同样的指导写一遍。

要添加知识，我可以跟智能体讨论，并选择它属于我、属于整个组织，还是属于某个集成或服务。我通常更愿意直接改 Markdown，因为好维护。个人知识用于我自己的工作；组织知识面向所有用户，不需要时也可以把条目关掉。

策略智能体是系统的另一个核心。应用走向发布时，它们会扫描应用是否符合组织要求。管理员选择每条策略有多严：可以只给建议，可以拦截但留例外机制，也可以直接拦截。策略可以针对特定应用，不过把共同要求铺到整个组织通常更有用。

Security Center 展示这些检查产生的发现。我的账户里，已有几个应用列出了漏洞，我可以先看严重程度，再决定修什么。选择 Fix with Clark，就会把漏洞作为修复任务发给智能体。这样，一条安全发现会进入修改应用的同一套工作流，而不是留在一份孤立的报告里。

回到智能体，我能看到这条发现已标记为已修复，应用也准备好发布。详情视图让我检查受影响的软件包，以及与它们相关的漏洞。如果需要更完整的说明，我可以点进官方漏洞条目。这类信息，如果每个员工的应用都待在各自互不相通的个人工具账户里，IT 会很难汇总起来。

Data Setup 定义部署过程中使用的环境，例如开发、预览和生产。这次演示里，我用开发和生产，各自有自己的配置和 URL。App Databases 把同样的隔离延伸到这些环境以及 Claude MCP 使用的数据库，于是通往生产的路径有明确的阶段，而不是一条不加区分的连接。

审计日志又加了一层可见性，用来查看组织内各应用中的活动。我一直主张记日志，因为有了日志，这些系统怎么运转才看得清。合在一起，应用构建器、管理、策略、数据库管理和日志，展现的就是 AI 做出的软件进入大型企业时，我想要的那种协同监管。