上周，有个搞“氛围编程”的家伙说他的SaaS（软件即服务）被黑了，然后这事儿在X（可能是某个社交平台）上炸开了锅。
他的生意完全靠人工智能帮忙，一点代码都没自己写，结果遇到了订阅被绕过、API密钥被用完、数据库被搞坏这些问题。
后来他承认了一个挺有意思的点：“你们也知道，我不是搞技术的，所以我花了好长时间才弄明白怎么回事。”
作为一个整天跟人工智能生成代码打交道的人，我看着这事儿发展，心里既同情又有点郁闷。我得说清楚——我不反对用人工智能帮忙开发。我自己做的工具也是为了提高代码生成的质量。但现在有些人越来越危险地认为，在这个新的人工智能世界里，懂不懂技术都无所谓。
看了很多类似的（虽然没这么公开的）安全灾难后，我得出了一个有点争议的结论：氛围编程不仅效率低，还可能带来灾难。
氛围编程的谎言
最近，我正在解决一个特别麻烦的代码生成问题，突然一个在旧金山的老朋友发消息说：“兄弟，你见过这个吗？我刚启动了我的业余项目，一行代码都没写。简直就是编程的氛围！”
他给我看了他的屏幕——一个看起来很漂亮的SaaS产品，帮小公司搞职业发展。界面简洁，功能实用。这些都是他告诉Windsurf（可能是某个AI工具）他想要什么，偶尔觉得不爽，改进提示，但从来没理解过底层技术。
“太棒了，”我真心佩服地说。“你们做了哪些安全措施？”
他那茫然的眼神说明了一切。
过了一段时间，他的API密钥被从AI不小心暴露的客户端代码里抓走了。他不得不跟OpenAI商量免掉账单。
现在，他的“副项目”下线了，他正在从头学身份验证和安全。
当代码不工作时，氛围编程的梦想就变成了噩梦；当代码运行得足够好以至于带来危险时，氛围编程的梦想也变成了噩梦。
（看不见的）复杂性差距
问题不在于AI工具不能生成安全代码——只要有正确的提示，它们通常可以做到。问题在于，如果你不了解自己在建什么，你就不知道自己不知道什么。
我帮另一个朋友调试他AI生成的教师SaaS时，亲眼看到了这一点。看了代码后，我发现：
- - 登录尝试没有速率限制
- - API密钥不安全
- - 管理功能只靠前端路由保护
- - 从前端直接操作数据库
我指出这些时，他真的很困惑。“但它工作正常！我已经测试好几个星期了！”
这就是我说的氛围编程的“看不见的复杂性差距”——“在我机器上运行良好”和“在生产环境中安全”之间的区别。这种差距存在是因为现代开发工具，尤其是AI助手，非常擅长隐藏复杂性，让事情看起来比实际简单。
AI不会警告你不知道该问的安全漏洞。完美的循环陷阱：你无法保护你不了解的东西，你也不了解AI为你建的东西。
当氛围编程适得其反时
上周Reddit上有个帖子火了，经验丰富的开发者们得意地说“我早就告诉过你们了”——但这没啥用。现实是，我们正进入一个越来越多人想开发软件的时代，而AI以前所未有的方式让这成为可能。
但安全故障的后果越来越严重。上周，那个氛围编程者的SaaS被黑时，真金白银都损失了。这一切都是因为有人觉得了解工具是可选的。
我不是说每个人都要成为安全专家或底层程序员。但负责任地部署处理他人数据的软件需要最低限度的知识，而AI并没有消除这个要求——它只是掩盖了它。
氛围编程者现在能做什么
如果你现在正在用AI辅助开发，并且在这篇文章里认出了自己，别慌。以下是你现在可以做的事：
首先，要有学习的心态。你不需要理解每一行代码，但你应该了解架构——数据怎么在系统里流动、存在哪儿、怎么保护。
其次，用AI来教育自己，而不仅仅是实现功能。当Cursor、ChatGPT或Claude给你生成代码时，让它解释安全隐患。问问它可能出什么问题。问问你漏了什么。
第三，从一开始就实施基本的安全措施——适当的身份验证、全站HTTPS、机密的环境变量、至少定期备份。我正在写另一本关于“氛围编程者的安全要点”的指南。如果你想看，在X上告诉我。
对很多人来说这不可能，但在启动任何处理敏感数据的项目前，考虑找个专家做安全审查。即使花几个小时跟知道该找什么的人聊聊，也能让你免于灾难。如果你真找不到人，随时给我发邮件或在Twitter上私信我，如果我有时间，我会尽力帮忙。
氛围编程的未来
对每个读到这儿觉得被冒犯或防御的氛围编程者——我理解。你想构建东西没错。传统学编程的路子确实有点排外。AI用美妙的方式让创造变得民主化。
但创造的民主化也意味着责任的民主化。
现在这波氛围编程工具是为了即时满足需求：让东西马上工作。下一代工具需要优化以实现可持续的理解：让东西随着时间的推移可靠地工作。
AI编码工具最革命的地方不是让你跳过理解，而是把多年的学习压缩到几个月。它们不会取代学习过程，而是加速它。
让我们拥抱这种加速，同时拒绝我们可以完全外包理解的幻想。未来属于那些把AI当作强大工具而不是知识替代品的人。
不只是氛围。氛围加上知识。
这才是我们创造持久东西的方式。
网友：
1、人们确实会因为糟糕的系统而被起诉，你不能只是泄露人们的个人信息或信用卡信息，然后说“哎呀，我在用 vibe 编码”
2、“氛围编码”这个名字听起来就让人觉得你根本不知道自己在干嘛。想象一下，如果有人自称是“氛围外科医生”或者“氛围律师”，你会怎么想？这难道不像是一个完全不懂行却觉得自己能神奇地在做手术或者打官司的时候瞎猜的人吗？
3、因为富士通的Horizon会计软件出了故障，邮局错误地指控了700多个邮政分局局长偷钱或者诈骗。这么多年，邮局一直不承认系统有问题，结果导致很多人破产、被冤枉定罪，甚至有人自杀了。直到2019年法院判了，再加上最近一部电视剧的播出，才终于揭开了这个被掩盖的真相，引发了大家的愤怒，也开始（慢慢地）给受害者赔偿。可是，真相大白的时间拖得太久了。
这里的问题不在于最初的错误，而在于人类毫无理由地否认系统存在故障。
大部分责任应该归咎于那些在没有进行适当的彻底测试的情况下批准购买和实施的人，以及那些在使用后忽视反馈或问题报告的人。
4、我以前也遇到过这种事。我之前在一家公司工作，他们有个“绝妙”的想法，就是用Google Web工具包搞一个客户服务前端，客户可以在上面下单，还能从一堆乱七八糟的后端API下载数据。他们把所有的身份验证和输入检查都放在了前端代码里——也就是客户浏览器上运行的那部分。
这家公司用了jmeter做了很多测试，但jmeter根本不会运行前端代码。我经常用jmeter的代理功能来设置测试，还得在浏览器里装个jmeter生成的证书来处理SSL身份验证。
我完全是偶然发现这个问题的，因为公司会把随机客户数据塞到测试数据库里，而且客户ID是硬编码的。我在跑测试之前就意识到这点了，本来以为会失败（因为客户已经不存在了），结果却惊讶地发现它居然成功了。经过一番测试实验，我发现我可以在不同客户的管理账户下创建子用户，基本上可以随便冒充任何客户下订单，只要我能猜到他们按顺序递增的客户ID。或者，你懂的，直接往数据库里塞一堆随机生成的记录，登录进去看看我到底在冒充谁。
我把这个问题归类为重大漏洞，结果程序员回复说：“哦，你只是直接调用了后端！没人会这么干的！”
5、这听起来就像我们过去20年里听那些敏捷顾问说的：“你只是没把敏捷做对。”
这就像个悖论。如果你不懂怎么编码，氛围编程很危险，你不该用它。但如果你懂编码，氛围编程又纯粹是浪费时间。可奇怪的是，尽管所有证据都表明氛围编程最后会搞得一团糟，但总有人说有一种“正确的方式”可以做到。
6、氛围编码并不新鲜。当我刚开始工作时，一位资深程序员承认，他 90 年代中期编写的代码可能是半醉半醒时编写的，因为他当时正在经历一场痛苦的离婚。我猜他用氛围编码