AI让糟糕的产品决策看起来像成品软件

当前的AI工具能够在几分钟内生成带有登录页面、仪表盘、设置界面甚至结账流程的软件外壳。因为外观连贯，人们往往以为重要决策已经完成——但实际远非如此。这些系统看似完整，实则缺乏数据隔离、错误恢复、访问控制及基本的运维边界，产品判断力几乎为零。

这种“氛围编码”在原型之外变得危险。生成式工具产出的软件外观速度超过了团队定义所有权、隐私规则、故障行为和支持边界的能力。代码由模型编写而构建者无法理解，这种代码在第一天就成了遗留代码。编程不仅是语法，更是理论构建：你需要理解各部分如何配合、它们做了哪些假设以及边界在哪里。生成模型能写出代码，却无法产生理解，因此界面看似充实，系统却概念空洞。

AI会乐于选择默认行为，无视政策权衡，产出在演示时效果完美却在真实系统中崩溃的结果。软件团队此前已有类似问题——高保真原型能欺骗非技术人员，但如今原型往往连接真实数据库并部署在公开域名上，表面行为不再只是“看着真实”，而是“真实到危险”。这给团队施加了跳过工程评审的压力，一旦将半生不熟的原型投入生产，缺失的产品决策就会变成运营事故。

安全影响并非理论。审计发现部署平台上存在38万个公开暴露资产，其中5000个包含敏感企业数据。漏洞CVE-2025-48757指出AI助手的应用中缺乏数据库行级安全策略，影响超过170个应用，允许未认证者读写数据库。这是因为系统在核心政策决策存在前就已“完成”——AI能构建界面，但无法决定谁拥有哪条记录、如何隔离客户数据、以及什么必须留在服务器内。

WIRED将此风险类比为开源依赖问题，但缺乏明确的责任线。手工代码通常比生成代码更明确地表达假设，未经正式审查的遗漏可能直到代价高昂时才被发现。这也是交付问题：DORA报告显示AI采用提高个人效率的同时，25%的AI采用率提升与软件交付吞吐量下降1.5%、稳定性下降7.2%相关。更快的代码生成并不意味更好的交付，它可能只是让组织在思考之前产生更多代码。用户导向的组织表现高出40%，否则AI只会催生更快的功能工厂，而非更多价值。

有效的应对是围绕生成工作建立纪律。DORA的平台工程指南建议自动执行安全检查、测试协议和部署护栏。AI辅助开发不可避免，但其速度要求更严格的验证。生成的界面应启动产品讨论，而非终结它。