当AI能在10分钟内吐出1万行代码，企业敢不敢直接部署到银行系统？Oracle产品高级副总裁Jenny Tsai-Smith抛出的这个问题，正在变成一场关于"信任"的技术路线之争。

正方：数据库层兜底，让AI代码"天生可信"

打开网易新闻 查看精彩图片

Tsai-Smith的解决方案很直接——把安全 enforcement（强制执行）从应用层下沉到数据库层。

传统架构里，访问控制写在应用代码里。AI动态生成的查询可能绕过这些规则，因为应用层分不清"谁在真正请求数据"。Oracle的做法是把权限规则绑到行和列级别，直接关联终端用户身份。

「无论查询来自人类、大语言模型，还是通过模型上下文协议（Model Context Protocol）连接的AI代理，数据库都会强制执行数据可见范围。」Tsai-Smith解释。

即将推出的Oracle Deep Data Security功能把这种理念产品化：用声明式、数据库原生的控制机制，在AI生成的SQL面前依然生效。开发侧，APEX AI应用生成器会输出人类可读的伪代码，让开发者在最终生成前审查修改——这是故意设置的信任检查点。

反方：速度优先，先跑起来再说

"氛围编程"（vibe coding）的流行本身就说明了一种态度：让AI写代码很爽，验证环节被视为拖慢创新的累赘。

Tsai-Smith的质问戳中了这种心态的软肋：「你能直接部署它、运行它、让它管理你的银行系统吗？不会的。」

企业正在付出代价。跳过验证、安全和生产就绪步骤的公司，正在发现为什么这些环节"和代码生成本身一样核心"。生成式AI民主化了应用开发，但信任危机是附赠的。

判断：信任不是功能，是架构设计

Oracle的赌注在于：信任不能靠"事后检查"补丁，必须在数据层原生构建。Tsai-Smith对"信任"的定义是三层正确性——数据的正确性、访问控制的正确性、使用数据后结果的正确性。

这套逻辑的背后是身份传播的完整性。用户身份从请求发起到数据库执行全程携带，不依赖应用层的"诚实"。对于AI代理场景尤其关键，因为代理可能串联多个工具、生成不可预测的查询模式。

技术路线的分歧实质是风险归属。选择数据库层 enforcement 的，把安全责任压到基础设施；选择应用层控制的，保留了灵活性，但承担了AI绕过规则的可能性。

Tsai-Smith没有明说但暗示的判断是：当代码生成速度突破人类审查极限时，只有架构层的信任机制才能 scale（规模化）。10分钟1万行代码的时代，"先审后跑"的人工流程已经失效。