AI写项目,为什么一碰业务逻辑就露馅

这两年，AI写代码的能力肉眼可见地在进步。给它一段需求描述，它能迅速生成项目骨架、数据库表结构、接口定义，甚至一套像模像样的前端页面。很多开发者第一次体验时，都会有一种"以后是不是不用写代码了"的错觉。

但只要真正开始做一个带业务逻辑的项目，这种错觉就会很快消失。

AI写项目，真正不靠谱的地方，从来不是它不会写代码，而是它不知道业务到底该怎么走。

AI写代码的本质，是把一种表达翻译成另一种表达。

你告诉它"做一个用户注册接口，包含手机号、验证码、密码"，它能很快生成对应的控制器、Service、参数校验、返回结构。你让它写一个增删改查模块，它也能把分页、排序、异常处理安排得比较完整。

这类工作有一个共同特点：规则是明确的。

字段叫什么、接口怎么命名、异常怎么返回、数据库怎么建表，这些东西有行业惯例，也有大量公开代码可以参考。AI最擅长的就是这类"从描述到实现"的翻译工作。

但业务逻辑不一样。

业务逻辑往往不是写在需求文档里的，而是藏在很多模糊的地方：

这些问题，表面上看是技术细节，实际上是业务判断。

AI可以帮你写"如果A，则B"，但它很难替你决定：这里的A到底是不是A，B后面还藏着多少个C和D。

很多没有做过复杂业务系统的人，会低估业务逻辑的难度。

他们以为业务开发就是写几个if-else，把需求翻译成代码。但实际上，真正消耗时间的往往不是主流程，而是边界情况。

一个看起来简单的优惠券功能，背后可能涉及：

如果只是让AI写一个"领取优惠券"的接口，它可能几分钟就能给你一段看起来不错的代码。但如果你让它考虑退款时优惠券状态如何恢复、同一用户并发领取时如何防重、活动结束瞬间大量请求如何控制，它给出的答案往往会变得松散、理想化，甚至自相矛盾。

因为这些问题不是靠代码风格解决的，而是靠对业务的理解。

业务逻辑的难点在于，它永远不是单一规则，而是一组规则之间的相互约束。一个地方改了，另一个地方可能就要跟着改。AI能看到局部代码，却很难看到整个业务系统里那些看不见的数据关系、流程依赖和历史包袱。

AI写项目最危险的地方，不是它写不出代码，而是它能写出"看起来很对"的代码。

这种代码往往结构清晰、命名规范、注释完整，甚至单元测试也能跑通。但一到真实业务场景里，就会暴露问题。

比如，AI可能把"订单金额"默认理解为商品总价，但实际业务里，订单金额可能要扣除优惠、加上运费、排除不可用商品，还要考虑税费和折扣顺序。

它可能把"用户状态"简单设计成启用和禁用，但真实系统里，用户可能处于未激活、已认证、冻结、注销中、黑名单、待审核等多种状态，每种状态背后的权限都不一样。

它可能把"审批通过"理解成一个简单的状态变更，但真实流程里，审批通过之后可能还要触发通知、生成合同、扣减预算、同步第三方系统，甚至要处理审批人和创建人不是同一个人的情况。

这些翻车，不是因为AI语法不行，而是因为它缺少业务上下文。

它不知道这个系统是给谁用的，不知道上下游系统之间有什么潜规则，不知道历史数据里埋了多少坑，也不知道客户嘴上说的"简单处理一下"，最后验收时会变成多么复杂的要求。

AI可以成为很好的开发辅助工具。

它可以帮你生成模板代码，减少重复劳动；可以帮你快速搭建项目结构；可以帮你写一些通用逻辑，比如参数校验、异常处理、数据转换；也可以在你已经想清楚业务规则之后，帮你把规则翻译成代码。

但它不能替代开发者对业务的理解。

一个真正能落地的业务项目，需要有人去判断：

这些判断，才是业务开发的核心。

AI能帮你把路铺出来，但往哪条路走、路上哪里有坑、走到一半要不要改方向，仍然需要人来决定。

所以，说"AI写项目不靠谱"，更准确地说，应该是：

AI写没有业务判断的项目，看起来很强；一旦进入真实业务系统，它的能力边界就会非常明显。

它不是不能写代码，而是不能替人理解业务。

它不是不能处理逻辑，而是不能处理那些没有被明确表达出来的逻辑。

它不是不能完成功能，而是不能承担功能背后的责任。

未来，AI在开发中的角色会越来越重要。它可以写更多的脚手架、工具代码、通用模块，也可以帮助开发者更快地验证想法。但对于真正复杂的业务项目来说，开发者的价值并不会因此消失。

相反，当AI把大量重复编码工作接管之后，开发者真正需要强化的能力，反而会更清晰：

不是写代码的速度，而是理解业务的能力；不是记住多少框架，而是判断系统边界的能力；不是让AI生成更多代码，而是知道哪些代码不能随便生成。

AI可以帮你把项目写出来，但只有人，才能决定这个项目到底该长成什么样。