30分钟攻破一家诊所系统：AI“氛围编程”把医疗数据送上了网
一家诊所的“效率革命”，差点变成隐私灾难
这两年，科技圈最流行的一句话大概是：不会写代码也没关系，AI 会帮你写。听起来很美，像是软件开发第一次真正走向“全民化”。但问题也恰恰出在这里——当“会生成代码”被误解成“会做软件工程”，悲剧往往只是时间问题。
瑞士技术作者 Tobias Brunner 最近写下了一段让人后背发凉的经历。他去看病时，被接待人员兴致勃勃地聊起一段视频：如今任何人都能用 AI 轻松做软件。于是，这家机构没有继续使用成熟的行业方案，而是自己用 AI coding agent 现做了一个患者管理系统，把原有患者数据导了进去，还直接部署到了互联网上。更“聪明”的一笔是，他们加了个自动化功能：就诊时录音，再把音频发送给两家 AI 服务做转写和摘要，省掉人工记笔记。
如果这是一部黑色幽默短片，观众大概已经知道结局了。Brunner 说，他稍微研究了一下，30 分钟之内就拿到了全部患者数据的读写权限。没有加密，没有有效访问控制，所有内容几乎就摆在公网上。更夸张的是，对方在接到提醒后的回复，还是一封明显由 AI 生成的“标准感谢信”，说已经加了基础认证、轮换了几个密钥，仿佛事情就算处理完了。那一刻，真正令人不安的不是一个漏洞，而是系统的建设者根本不知道自己到底造了什么。
漏洞不是高深黑客术，而是把门锁画在了纸上
从技术细节看，这起事件并不是什么电影级别的复杂攻击，反而是最典型、也最令人无奈的那种“低级失误叠满”。整个应用居然只是一个单一 HTML 文件，JavaScript、CSS 和页面结构全都内嵌。后端使用的是托管数据库服务，但没有配置访问控制，没有行级安全策略，也没有真正的权限隔离。所谓“访问控制”，几乎全写在前端 JavaScript 里。
这是什么意思？翻译成人话就是：门禁系统装在门外，而且钥匙说明书还贴在墙上。只要有人愿意看一眼网络请求，或者直接用一条 curl 命令，就能把数据拿下来。对于稍有经验的开发者来说，这不是“可能有风险”，而是“几乎一定会出事”。
更麻烦的还不是数据库本身，而是数据流向。患者录音被直接发给美国的 AI 公司做转写和总结，数据存储也在美国服务器上，而且作者提到并不存在相应的数据处理协议。在医疗场景里，这已经不仅仅是“工程做得粗糙”，而是在法律、伦理和职业规范的边缘疯狂试探。患者通常默认自己是在和医生、诊所沟通，而不是在不知情的情况下，把声音和病历一并喂给海外云端模型。
这也是为什么这件事格外刺耳。因为它不是某个地下黑客组织作恶，而是一群看起来“想提升效率的人”，在 AI 鼓励式产品体验的推动下，轻率地跨过了原本应该有的专业边界。
“氛围编程”最大的问题，不是代码写得烂，而是责任感消失了
“Vibe coding”这个词最近很火，大意是开发者不再逐行理解代码，而是用自然语言和 AI 对话，靠感觉一路往前做，先把东西跑起来再说。对于做原型、写脚本、验证点子，它确实很好用，我自己也不觉得它原罪深重。问题在于，一旦进入真实世界，尤其涉及医疗、金融、教育、政府这些高敏感领域，软件就不再是一个能跑就行的小玩具。
真正的软件工程，从来不只是把功能拼出来。它包括权限模型、数据最小化、日志审计、密钥管理、合规边界、异常处理、备份恢复、第三方供应商管理，以及上线后出了事到底谁负责。AI 可以在几分钟里帮你生成一个“像那么回事”的系统，却不会替你承担后果。甚至更糟的是，它会制造一种危险的错觉：界面能点、按钮会亮、数据能保存，于是人就相信这套东西“差不多可以用了”。
这几年类似事故其实并不少见。有人把公司的私有源代码直接贴进公共模型，有人用 AI 生成数据库脚本后误删生产数据，也有人把内部客服系统接上大模型，却忘了脱敏，结果把用户隐私暴露给外部 API。AI 让开发门槛下降，这是事实；但它也把“犯大错的门槛”一起拉低了。以前至少还要会一点后端、权限、部署，才能把系统送上公网。现在，一个能操作提示词的人，也许就足够制造一场事故。
医疗行业为什么尤其不能“先上线再修”
医疗数据和普通互联网产品的数据不是一个量级。你购物记录泄露，很烦；你体检结果、诊断信息、就诊录音泄露，可能会影响保险、就业、家庭关系，甚至个人尊严。病人坐在诊室里时，默认的是一种高度信任关系。这个空间里说出的很多话，可能一辈子都不会对别人说第二遍。
所以医疗软件行业看起来总是“慢吞吞”的。流程多、审查严、采购保守，体验也常常谈不上时髦。很多人抱怨传统医疗 IT 又贵又老旧，这种抱怨并非没有道理。但从另一个角度说，正因为出事的代价太高，它才不能像消费级 App 那样一路试错。行业成熟方案之所以显得笨重，往往不是因为厂商不懂创新，而是因为它们踩过坑、交过罚款、挨过审计。
Brunner 这篇文章最有力量的地方，就在于它没有把矛头简单指向 AI，而是点出了一个更现实的问题：当非专业人员在 AI 的帮助下开始“自建关键系统”，社会其实还没准备好相应的安全教育和责任机制。我们当然希望基层医疗机构能更便宜地获得数字化工具，但“便宜”和“快速”不能建立在患者不知情、数据无保护的前提上。
这里还有一个更值得追问的问题：如果未来越来越多中小机构用 AI 自己拼装业务系统，监管应该盯住谁？是模型提供方、云服务商、部署者，还是最终使用机构？今天这类边界仍然模糊，而模糊往往意味着出事后所有人都说自己只是“提供工具”。
AI 能帮人写代码，但不能替人理解边界
这起事件让我想到一个有些残酷的现实：AI 正在缩短“做出一个系统”和“做对一个系统”之间的时间差，但并没有消除两者之间的鸿沟。很多人以前没有能力快速建系统，现在有了；可他们依然没有能力判断这套系统是否安全、合规、可维护。于是，软件世界第一次出现了大规模“不会游泳的人开快艇”的场面。
这不是说我们就该回到纯手工编码时代。相反，AI coding agent 会成为未来开发流程的标配，几乎没有悬念。真正的分水岭在于，它应该是副驾驶，而不是替你决定航线的自动驾驶。开发者可以让 AI 生成 CRUD、写测试、补文档、做重构，但当项目触及真实用户数据，尤其是医疗隐私，最后那道关必须由懂架构、懂安全、懂合规的人来把。
说得再直白一点：能把功能做出来，不等于有资格把它上线。行业这几年太沉迷于“十分钟做个 App”的爽感，却很少宣传另外一句更重要的话——十分钟做出来的东西，也可能让你用十年去还债。
Brunner 文章结尾说，这不是他期待的 AI 未来。我很认同。一个健康的 AI 软件时代，应该让专业人士更高效，让普通人更容易表达需求，而不是让所有人误以为“需求 + 提示词 = 可交付系统”。技术的民主化当然是好事，但前提是不能把风险也民主化到每一个毫无防备的病人身上。我们真正需要的，不只是更强的代码生成器，而是更清楚的红线：哪些系统不能随便做，哪些数据不能随便传，哪些责任不能一句“这是 AI 生成的”就轻轻带过。
如果说这则故事有什么价值，它像是一记及时的冷水。AI 不是魔法棒，医疗软件也不是乐高。把两者混在一起，拼出来的可能不是未来，而是一场本可避免的事故。