也说说Vibe Coding

发表于 分类于

一天下午，公司某部门的 Director 把我和 IT 运维团队拉进了一个会议。他们部门的一名员工使用 AI 开发出了一个能够支撑部门某业务的网页应用，希望和我们一起讨论如何部署。

1. Vibe Coding的殷切期盼

会上，他展示了应用的前端页面和业务交互逻辑，并介绍说，部门内部对这个应用的热情很高。如果能够投入生产，将有望减少大量沟通成本和人工操作时间。

这种热情，从该部门与会的 Sr. Manager 的表情中就能明显感受到。这个应用正是她团队成员使用 AI 开发出来的。显然，她们已经在部门内部多次 Review 过这个应用，并且对它充满期待。

这是一个业务场景相对简单的应用：有登录页、角色管理，前端页面也比较流畅，主要功能看起来都能够正常使用。于是，我们讨论的重点落在了如何支撑部署上。

在了解了具体使用场景和用户规模后，我开始询问应用的技术架构。

业务部门的管理层不了解技术架构，这很正常。负责开发网页应用的同事人在越南，也没有参加这次会议。于是，我提议先直接对代码进行 Review。

2. 黑客友好型的代码

第二天早上，我收到了这个网页应用的代码。

代码非常简单：二十多个前后端文件全部放在同一个目录下。除了两个 Python 文件之外，其余基本都是前端文件。至于那两个 Python 文件，一个是应用入口，另一个文件则包含了约 2,000 行后端业务逻辑。文件脱敏如下：

xx网页应用/
├── backend_main.py # Flask 主应用与 API
├── backend_entry.py # WSGI 生产启动入口
├── dependencies_prod.txt # 生产依赖
├── dependencies_dev.txt # 开发依赖
│
├── page_home.html # 首页
├── page_role_a_login.html # role A登录
├── page_role_b_login.html # role B登录
├── page_role_a_portal.html # role A门户
├── page_role_a_detail.html # role A详情
├── page_role_b_home.html # role B主页
├── page_role_b_dashboard.html # role B看板
├── ……
├── page_role_b_upload.html # 文件上传
├── page_admin.html # 管理员页面
├── page_activity.html # 活动记录
└── page_archive.html # 归档管理
│
├── common_styles.css # 公共样式
├── …
└── demo_data.js # 示例数据

我心中一惊，意识到这件事可能并没有我们想象得那么简单。

很明显，该应用使用 Python Flask 开发。对于简单场景来说，Flask 本身完全可以胜任。

数据库配置呢…没有使用数据库，全部信息直接写进JSON文件。我心中又是一惊。赶紧打开唯一的后端逻辑代码文件，发现了大量问题：

  1. 鉴权缺失：多数业务 API 没有权限校验；
  2. 越权访问：接口通过 URL 参数访问用户、年份和条目，未校验资源归属；
  3. 未授权数据变更：上传、审核、修改、归档、删除等写操作可被未登录请求调用；
  4. 任意文件写入风险：存在路径穿越和任意文件写入风险；
  5. CSRF 防护缺失：基于 Cookie Session 的状态变更接口未配置 CSRF Token；
  6. 缺少OSS：存在上传和保存大量文件的场景，但上传文件保存在本地磁盘；
  7. 缺少数据库：数据保存在JSON文件中，无法保证读改写事务的原子性；
  8. …

问题可以说是一箩筐，主要集中在安全性和可靠性两个方面。以目前的架构和安全状态来看，这个应用显然不具备直接上线的条件。很明显，这是一个黑客友好型应用，也完全不足以支撑300个业务用户。

我对问题进行了初步梳理，并向负责开发的业务同事及相关管理层逐步解释了这些问题可能带来的影响。同时，我也花了一些时间向他们介绍一个应用从原型走向生产通常需要经历的过程：

需求 -> 设计 -> 开发 -> 测试 -> 运维

这个应用目前最多只能算是一个通过 Vibe Coding 快速完成的功能原型，而不是经过工程化验证的生产系统。如果想要投入生产，还需要由有经验的开发人员进行全面的架构调整、代码重构、安全加固和测试验证。

3. 折射出的问题

在会议中我还了解到，使用 AI 开发这个应用的同事没有计算机专业背景，也缺乏安全和性能方面的知识。她们与 LLM 沟通时，关注点主要集中在页面逻辑和视觉呈现上。

对她们来说，只要页面看起来没有问题、应用能够成功运行，就意味着这是一个“好应用”。

这至少折射出 Vibe Coding 当前存在的两个矛盾：

  1. 用户对 Vibe Coding 的高涨热情，与其缺乏驾驭复杂软件工程问题所需专业知识之间的矛盾；
  2. 用户对 Vibe Coding 智能化程度的殷切期待和完全信任，与当前 LLM 尚未具备完全自主开发和验证能力之间的矛盾。

这两个矛盾共同导致了一种常见现象：Vibe Coding 生成的应用往往能够较好地贴合用户对页面和业务流程的直观需求（导致用户自信心爆棚），却容易忽视安全性、并发性、可维护性、可观测性和灾难恢复等专业领域的重要要求。

更值得注意的是，缺乏相关专业知识的用户，通常很难察觉这些问题。

这一现象并非个例。2026 年开展的一项大规模实证研究分析了来自 6,299 个 GitHub 仓库的 302,579 个 AI 生成代码提交，发现其中 5,142 个提交在 1,643 个仓库中引入了 22,687 个安全问题；此外，AI 编程助手引入的安全问题数量约为其修复数量的 1.5 倍，表明当前 AI 辅助编程在安全性方面仍存在普遍且持续的风险。[1]

记录这件事，并不是因为我对 Vibe Coding 的应用持悲观态度。恰恰相反，LLM 正越来越广泛地进入我们的工作和生活，而这更提醒我们：对于 LLM 生成的结果，还不能百分之百信任。 尤其是在自己不熟悉的专业领域，更应该尊重专业意见，并通过多方验证来确认结果。切不可把 LLM 生成的内容当成“圣经”。

引用

[1] Liu, Y., Widyasari, R., Zhao, Y., Irsan, I. C., Chen, J., & Lo, D. (2026). Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild. arXiv. https://doi.org/10.48550/arXiv.2603.28592