这可能是AI开发最容易被误解的一件事

最近如果你经常用AI写代码，很容易产生一种感觉：

做软件，好像突然变简单了。

告诉AI需求。

它开始创建文件。

写页面。

写接口。

连接数据库。

发现报错以后，把错误继续扔给AI。

AI再修改。

最后浏览器打开。

登录成功。

页面也能跳转。

数据也能保存。

看到这里，大多数人的第一反应都会是：

这不是已经做完了吗？

但如果你把这个项目拿给一个真正需要负责上线的人看，

他可能会告诉你：

“还早。”

为什么？

图片：已经能跑了，为什么还不能上线？

一个能跑的软件，到底离上线还有多远？

先举一个很简单的例子。

假设AI帮你做了一个商城。

现在已经实现：

注册。

登录。

商品列表。

购物车。

下单。

后台管理。

你自己测试一遍。

没问题。

然后准备上线。

第一个问题来了：

用户连续点击两次“提交订单”。

会不会产生两个订单？

第二个问题：

库存只剩1件。

两个用户同时购买。

最后谁成功？

第三个问题：

用户已经支付成功。

但是你的服务器刚好超时。

订单到底算：

已支付？

还是未支付？

第四个问题：

管理员误删商品。

以前的历史订单还能不能正常查看？

你会发现：

真正的软件问题往往不是：

“有没有这个页面。”

而是：

当事情没有按照正常流程发生的时候，系统怎么办？

AI最容易做好的，是“正常流程”

比如告诉AI：

用户登录。

进入首页。

选择商品。

点击购买。

创建订单。

这一条路径非常明确。

AI很容易完成。

但真实世界不会永远按照：

A → B → C → D

运行。

网络会断。

接口会超时。

用户会重复点击。

第三方服务会失败。

数据会出现异常。

有人会输入你完全没想到的内容。

真正能够上线的软件，

必须回答这些问题。

第一个容易被忽略的问题：权限

这个问题在很多后台系统里非常常见。

假设系统有：

超级管理员。

普通管理员。

商家。

员工。

第一眼看起来很简单。

给每个角色配置不同菜单。

但是实际业务可能是：

A商家不能看到B商家的订单。

普通管理员不能修改系统配置。

员工只能看到自己门店的数据。

离职员工应该立即失去权限。

如果系统只是：

“把菜单隐藏起来了。”

但接口本身没有真正限制权限。

那就不是页面问题。

而是：

安全问题。

第二个问题：数据

Demo阶段的数据通常非常干净。

3个用户。

10个商品。

20个订单。

一切运行正常。

正式上线以后可能变成：

10万用户。

100万订单。

大量图片。

大量日志。

大量并发请求。

这时候原来：

0.1秒打开的页面。

可能突然变成：

5秒。

甚至打不开。

原来一个简单的数据库查询没有任何问题。

当数据量上来以后，

可能直接把数据库拖慢。

这时候才会真正涉及：

数据库索引。

缓存。

分页。

并发。

查询优化。

数据结构。

这些东西，在：

“先让AI生成一个能跑的系统。”

这个阶段非常容易被忽略。

第三个问题：异常流程

一个正常订单非常简单：

创建订单。

支付。

成功。

结束。

但真实项目会出现：

支付失败。

支付超时。

重复支付。

订单取消。

支付成功但回调失败。

退款失败。

第三方接口异常。

每一种异常，都需要系统知道：

下一步应该怎么办。

这也是商业系统越来越复杂的原因之一。

不是正常流程复杂。

而是：

异常情况太多。

第四个问题：代码以后还能不能改？

这是我觉得AI项目特别值得关注的一点。

第一版的时候：

AI非常爽。

你说：

“增加一个优惠券功能。”

它开始修改。

第二次：

“再增加一个积分功能。”

继续改。

第三次：

“会员还要分三级。”

继续改。

当项目越来越大以后，

如果前面的架构没有规划好，

非常容易出现一种情况：

修改一个功能，另外三个地方出问题。

这时候最可怕的其实不是Bug。

而是：

没人真正知道这套代码为什么会变成现在这样。

所以我现在看一个AI项目，会先问一句

不是：

“AI写了多少代码？”

而是：

半年以后，这个项目还能不能继续改？

软件几乎不可能一次开发完成以后，就永远不变。

只要真的进入运营，

需求一定会继续增加。

今天只有一个管理员。

以后可能需要多门店。

今天只有一个支付方式。

以后可能增加其他支付渠道。

今天只有国内用户。

以后可能开始做海外。

如果第一天为了快，

把所有东西全部写死，

前期确实很快。

后期可能越来越难。

“能跑”和“能上线”，中间到底差什么？

差的其实不只是几个Bug。

而是：

工程能力。

图片：从能跑到能上线，中间差的是工程能力

包括：

1. 权限控制

谁能看。

谁能改。

谁能删除。

2. 数据一致性

订单。

支付。

库存。

用户数据。

不能各自出现不同结果。

3. 异常流程

超时。

失败。

重复提交。

回滚。

都需要考虑。

4. 性能稳定性

10个人使用没问题。

10000个人同时使用还能不能正常？

5. 可维护性

今天做完以后。

半年后还能不能继续开发？

这些才是真正决定一个系统能不能长期运行的东西。

这是不是说明AI不能做正式项目？

并不是。

恰恰相反。

我现在越来越愿意让AI参与正式开发。

因为它在很多环节确实非常高效。

比如：

AI写接口。

人审核业务逻辑。

AI生成测试用例。

人补充关键异常场景。

AI修改代码。

人控制整体架构。

AI帮你提升速度。

但是：

最终必须有人对结果负责。

我认为这才是现在比较合理的AI开发模式。

AI真正改变的，可能是团队结构

以前一个项目里，大量人力会被使用在：

重复开发。

查询资料。

写基础代码。

机械测试。

整理文档。

现在这些事情，越来越可以让AI帮助完成。

那么同样一个团队，

就可以把更多精力放到：

产品。

业务。

体验。

质量。

架构。

这才是AI真正值得关注的地方。

不是：

AI突然变成了一个万能程序员。

而是：

它让一个本来就会做软件的人，效率变得非常高。

写在最后

AI正在让：

“做出一个软件”

越来越容易。

这是好事。

因为以前很多想法由于开发成本太高，根本没有机会被验证。

现在一个人就可以快速做出原型。

但是与此同时，

我们也需要重新理解一件事情：

软件开发的价值，从来不只是把代码写出来。

AI让写代码越来越便宜。

未来真正值钱的，

可能会变成：

判断什么该做。

设计怎么做。

知道哪里可能出问题。

以及最后：

真正把产品交付出去。

下一篇我准备继续做一个实验：

如果程序员自己不写代码，只允许指挥AI，一个人到底能不能完成以前一个小团队的工作？

如果你也对这种AI真实开发实验感兴趣，可以关注。

后面继续实测。