当业务人员开始写代码，传统研发流程还适用吗？

事情的经过

最近，我们团队经历了一次典型的 AI 辅助开发上线事故。

运营部的一位同事借助 AI 编写了一个 PHP 小项目，用于业务 Demo 展示。整个过程几乎没有开发人员参与：描述需求、生成页面、编写后端逻辑、设计数据库结构、修复运行报错，都通过与 AI 多轮对话完成，最终得到了一套能够在本地正常运行的完整项目。

由于公司测试服务器尚未搭建 PHP 运行环境，而业务又希望尽快看到线上效果，于是请前端同事协助部署。前端同事按照平时托管静态网页的方式，直接将整个项目上传到了对象存储，并绑定了业务域名。

问题随之出现。

访问域名地址可以直接下载 .php 文件；更严重的是，项目根目录中的 .env 配置文件也可以被直接访问下载，数据库账号、密码等敏感配置全部暴露在公网。

仅仅几分钟后，该域名便被微信判定存在安全风险并封禁。

一个原本只是为了快速验证业务想法的小项目，从部署到下线，不过短短几分钟，却经历了敏感信息泄露、域名封禁、紧急改密、事故复盘等一系列连锁反应。

---

AI 带来的真实便利

这次事故虽然暴露了不少问题，但也让我们看到了 AI 在软件开发中的巨大价值。

这位运营同事此前并没有系统学习过编程，却能够通过不断描述业务需求，让 AI 生成 HTML、CSS、PHP、SQL 等完整代码；遇到运行报错时，也能够直接将错误信息反馈给 AI，并快速得到修复方案。

最终，一个过去需要开发人员参与才能完成的小工具，仅依靠业务人员与 AI 的协作，就成功搭建出了可运行的原型。

如果放在几年前，这几乎难以想象。

过去，一个简单的内部工具往往需要经历需求沟通、开发排期、联调测试等多个环节，周期少则几天，多则数周。而现在，从一个想法到一个能够演示的原型，往往只需要几个小时，甚至几十分钟。

AI 极大降低了软件开发的门槛，让更多业务人员具备了快速验证创意的能力。

对于内部工具、活动页面、数据展示、流程验证等轻量级场景，这种效率提升是真实且显著的。

---

容易被忽视的认知盲区

真正的问题，并不是 AI 会不会写代码，而是很多人误以为代码能够运行，就意味着项目可以上线。

事实上，一个应用从本地运行到正式部署，中间隔着大量工程化工作，而这些恰恰是 AI 最容易被忽略的部分。

AI 生成的是开发代码，不是部署方案

AI 默认生成的是一个"能够跑起来"的项目，而不是"能够安全上线"的项目。

例如这次事故中的 PHP 项目，本应部署在支持 PHP 的 Web 服务器上，由 Nginx 或 Apache 将请求转发给 PHP-FPM，再由 Web Server 对入口目录、静态资源以及敏感文件进行访问控制。

而对象存储本质上只是一个静态文件服务器，它不会解析 PHP，更不会帮你屏蔽 .env、.git 等敏感文件。

于是，所有源码都被当作普通文件直接暴露给了公网。

开发环境、部署环境、生产环境，本就是三个完全不同的概念，而 AI 并不会主动告诉你这些差异。

---

AI 默认追求"能实现"，而不是"够安全"

AI 更擅长帮助开发者快速完成业务逻辑。

至于是否开启 SQL 预编译、是否进行输入校验、是否增加权限控制、是否限制访问频率、是否做好异常处理、是否隐藏敏感信息，这些通常只有在用户主动询问时，AI 才会进一步补充。

换句话说：

AI 默认帮助你完成的是 Happy Path（正常流程），而不是 Secure Path（安全流程）。

对于缺乏开发经验的业务人员而言，很容易误以为"AI 给出的代码就是最佳实践"，直接部署上线，从而埋下大量安全隐患。

---

AI 并不了解实时的平台规则

AI 的知识来源于训练数据，而很多互联网平台的安全策略却是持续变化的。

例如：

• 微信会检测是否能够访问 .env

• 是否存在源码泄露

• 是否存在恶意下载文件

• 是否存在异常跳转

• 是否存在高危目录暴露

这些策略可能今天有效，明天就发生调整。

AI 无法实时感知这些变化，也不会主动提醒"你的部署方式可能触发平台风控"。

因此，AI 能告诉你应该如何开发，却无法保证今天这样部署一定安全。

---

更深层的问题：AI 改变了能力边界，却没有改变责任边界

事故发生后，团队内部讨论最多的问题其实不是技术，而是责任。

运营同事利用 AI 写出了代码；前端同事只是协助上传文件；真正导致问题的是部署方式。那么，这次事故究竟应该由谁负责？

如果放在传统研发流程中，这类问题通常不会出现。

需求经过评审，开发负责实现，测试负责验证，运维负责上线，每个环节都有明确的职责划分。

但 AI 出现之后，"生成代码"已经不再是开发人员的专属能力。

越来越多的产品、运营、设计甚至销售，都能够借助 AI 快速完成一个 Demo。

问题在于，能力被下放了，责任却没有同步转移。

一个人可以不会写代码，却能够生成代码；可以不会部署，却能够完成上线；可以不了解安全，却能够把系统发布到公网。

于是，原本由专业工程师承担的风险，也开始随着 AI 的普及扩散到整个组织。

因此，这次事故真正值得反思的，并不是"谁操作失误了"，而是：

当 AI 让每个人都拥有开发能力之后，组织是否也建立了相应的安全规范、上线流程和风险控制机制？

如果没有，那么 AI 带来的效率提升，很可能会被一次又一次的线上事故所抵消。

---

写在最后

幸运的是，这次事故并没有造成实际的数据损失。

暴露的是测试环境数据库，相关账号密码也在第一时间完成了修改，但域名被微信封禁带来的影响依然是真实存在的。

这次经历也让我重新认识了 AI 在软件开发中的定位。

AI 能够帮助一个不会写代码的人快速搭建应用，也能够帮助专业开发者显著提升开发效率；但它并不会替代工程经验，更不会替代部署规范、安全意识和上线流程。

AI 改变的是能力边界，而不是责任边界。

未来，真正的竞争力或许已经不再只是"会不会写代码"，而是能否理解软件工程背后的完整链路：知道哪些事情可以交给 AI，哪些事情必须由人来负责。

AI 可以帮你更快地完成代码，但系统最终是否安全、是否稳定、是否能够承担业务责任，答案仍然掌握在人手里。