AI“氛围式编程”正在制造新的安全与技术债危机

安全风险：更多漏洞进入生产系统

安全问题是工程师最担心的部分。

安全研究人员已经发现，AI 生成代码正在增加漏洞进入软件生态系统的概率。

例如，研究人员统计漏洞披露数据发现：仅 2026 年 3 月，就有至少 35 个新的 CVE 条目与 AI 生成代码直接相关。

由于很多项目不会记录 AI 使用痕迹，真实数量可能更高。

多项测试还发现，大模型在生成代码时经常复制训练数据中的不安全模式。例如：

• 大约 45% 的 AI 生成代码样本包含常见安全漏洞
• 许多漏洞属于 OWASP Top 10 类型，如注入、认证错误等

这些问题在多个模型测试中持续存在。

另一个明显风险是 凭证泄露。

对真实开发流程的分析显示：

• AI 辅助提交中 3.2% 会暴露凭证
• 纯人工提交的比例为 1.5%

也就是说，AI 相关代码泄露密钥的概率 超过两倍。

随着代码量快速增长，这些问题更容易被带入生产环境。

OpenClaw案例：当AI代理暴露在互联网

这些风险在 AI 代理系统中尤其明显。

开源 AI 助手平台 OpenClaw 就成为安全研究中的典型案例。研究发现，互联网上存在 数万台公开可访问的 OpenClaw 实例，许多由于配置错误或软件过期而存在接管风险。

在一次扫描中，研究人员发现 21,000 多个公开实例直接暴露在互联网中。

其中一些系统泄露了：

• API 密钥
• OAuth 令牌
• 明文凭证

问题不仅存在于部署环境，还出现在扩展生态中。

研究人员扫描 OpenClaw 的技能（skills）市场约 4000 个插件后发现：

• 283 个插件存在关键凭证处理漏洞
• 占整个生态 约 7.1%

这些漏洞可能导致 API 密钥或敏感数据被暴露。

这类事件说明了一个更广泛的问题：

如果强大的 AI 代理在缺乏安全实践的情况下部署，它们实际上会变成连接多个系统的公开控制台。

工程师为什么担心“不会写代码的人”

许多开发者强调，真正的风险并不是 AI 本身，而是 使用方式。

传统软件开发默认一个前提：

写代码的人理解代码的结构、依赖和安全边界。

但氛围式编程打破了这个前提。

如果用户无法阅读或理解生成代码，他们仍然可能部署一个看起来正常运行的应用，但可能无法发现：

• 隐藏漏洞
• 不安全的认证流程
• 不可信依赖链
• 边缘条件下的逻辑错误

工程师通常把这种系统称为 “happy‑path software”——只在理想条件下运行的软件。

演示时看起来很好，但现实环境中很容易崩溃。

长期成本：指数增长的技术债

即使 AI 生成代码功能正确，也可能迅速积累技术债。

原因很简单：

AI 让每个开发者生成的代码量大幅增加。

如果这些代码包含：

• 重复逻辑
• 不一致的设计模式
• 缺乏文档

那么未来修改和维护成本就会迅速上升。

安全研究人员甚至提出 “安全债”（security debt） 的概念：

漏洞增长速度可能超过组织修复漏洞的能力。

换句话说：

• 生产力提升是立即的
• 维护成本是延迟出现的

类似问题正在进入科研领域

这种“生成便宜、验证昂贵”的结构问题，也开始出现在科学研究中。

AI 已经被用于：

• 文献检索
• 假设生成
• 论文草稿撰写
• 同行评审辅助

相关研究综述表明，这类工具正快速进入科研流程。

在一些实验中，大语言模型确实可以提出有价值甚至新颖的科学假设。

但更大规模研究发现，当这些假设真正接受实验验证时，AI 生成的假设平均表现仍低于人类研究者提出的假设。

学术界因此开始担心一种类似“AI slop”的现象。

2026 年《Science》杂志的一篇社论警告，如果论文写作中过度或不透明地使用 AI，可能削弱学术记录的可靠性。

真正的瓶颈仍然是人类判断

无论是软件工程还是科学研究，核心问题其实相同。

AI 极大降低了 生产内容的成本：

• 代码
• 论文
• 假设
• 设计

但 评估这些内容的成本仍然依赖专家。

当生成几乎免费，而评估仍然稀缺时，系统就会被大量“看起来合理但不一定可靠”的内容淹没。

在软件世界，这表现为：

• 不安全代码
• 脆弱系统
• 巨量技术债

在科学领域，则可能表现为：

• 大量质量参差的假设
• 低价值论文
• 过载的同行评审体系

真正的挑战已经不再只是“使用 AI”，而是建立 新的审查流程、安全实践和治理机制，以防止 AI 带来的内容洪流最终演变成真正的 “vibe slop”。