尧图网站建设 
做 Java 后端这几年CRUD 这个词基本绕不开。虽然大家有时候会拿 CRUD 开玩笑但真正做过业务系统的人都知道CRUD 并不只是增删改查那么简单。一个看起来普通的接口背后可能有权限、状态流转、事务、缓存、消息通知、幂等、日志、异常处理还有一堆业务规则。所以我并不觉得 CRUD 低级。相反很多稳定运行的业务系统本质上都是大量 CRUD 和业务规则堆出来的。不过最近开始看 AI 应用开发后我确实感觉到它和传统 CRUD 的开发方式有一些明显不同。不是说完全换了一套东西而是系统里多了一个“智能但不完全确定”的环节。这个变化会影响我们设计接口、组织数据、处理结果的方式。只从一个 Java 后端开发者的角度聊聊我目前对 AI 应用开发和传统 CRUD 的区别理解。 传统CRUD 更像是规则驱动我们平时写后端接口大部分逻辑是比较确定的。比如一个订单查询接口GetMapping(/orders/{id}) public OrderVO getOrder(PathVariable Long id) { Order order orderService.getById(id); return orderConverter.toVO(order); }当然真实业务不会这么简单。可能还要判断用户权限、订单状态、数据范围、是否命中缓存、是否需要脱敏。但整体来说它还是规则驱动的。用户传什么参数后端按照代码里的规则执行查数据库组装结果然后返回。只要数据不变、代码不变同样的请求大概率会得到同样的结果。这也是传统后端开发比较强调的地方确定性。接口要稳定返回要明确异常要可控数据要一致。我们会花很多精力去保证系统不要出现模糊结果。比如参数不合法就直接返回错误查不到数据就返回空或者指定错误码状态不允许就阻止操作数据更新失败就回滚事务第三方接口异常就重试或降级这些都是后端开发很熟悉的东西。AI 应用多了一个“不确定”的能力源AI 应用不一样的地方在于它接入了大模型。大模型不像普通函数也不像普通第三方接口。你给它一段输入它会生成一段输出但这个输出不一定每次都完全一样也不一定总是严格按照你想要的格式来。比如你让它总结一段用户反馈它可能总结得很好但你让它只返回 JSON它有时候可能会多加一句解释。你让它回答某个业务问题它可能回答得像那么回事但里面有些细节其实并不准确。这就是 AI 应用开发里比较特殊的地方模型很强但不能完全当成确定性代码来用。所以后端开发者在接入大模型时不能只想着“调一个接口拿结果”。更重要的是要考虑怎么把这个不确定的能力包装成一个相对稳定的业务服务。比如我们需要考虑Prompt 怎么写才能让模型更接近预期输出格式怎么约束方便后端解析结果不符合格式时怎么重试回答内容是否需要引用知识库模型超时或失败时怎么降级用户输入恶意内容时怎么处理调用成本和频率怎么控制这些问题和传统后端经验是能接上的。CRUD 主要围绕数据AI 应用更围绕上下文传统业务系统里核心通常是数据。我们设计表结构写 Mapper封装 Service控制事务最后通过接口把数据提供出去。很多需求的关键就是把数据存对、查准、改稳。AI 应用当然也需要数据但它更强调“上下文”。比如一个普通查询接口只需要用户传订单号后端就可以查订单表。但如果是一个 AI 助手用户可能会这样问“我上周买的那个耳机到哪了”这个问题对系统来说就复杂多了。它需要知道当前用户是谁“上周”对应哪个时间范围用户买过哪些商品“那个耳机”指的是哪一笔订单查询订单状态应该调用哪个接口最后怎么用自然语言回答用户这里面就不只是简单的 CRUD 了而是要把用户问题、用户身份、历史对话、业务数据、接口能力组合起来。从后端角度看AI 应用里的上下文可能来自很多地方用户当前输入历史聊天记录数据库里的业务数据Redis 里的会话状态文档知识库里的内容系统提前设定的 Prompt后端可调用的业务接口这些内容拼在一起才构成模型真正看到的输入。所以做 AI 应用时一个很重要的能力就是怎么组织上下文。## 接口返回值也变得不一样了传统接口返回值一般比较固定。比如{ code: 200, message: success, data: { orderId: 1001, status: 已发货 } }前端拿到以后按字段展示就行。但 AI 应用里返回内容可能是一段自然语言你上周购买的耳机已经发货目前正在运输中预计明天下午送达。这个结果更像“面向用户的回答”而不是单纯的数据返回。这带来一个问题后端到底应该返回原始数据还是返回模型生成后的文本我的理解是要看场景。如果是后台管理系统很多时候还是应该保留结构化数据。因为运营、客服、管理员需要准确字段不能只看一句自然语言。如果是聊天助手、智能客服、知识库问答模型生成的自然语言就比较有价值因为用户希望直接得到答案而不是自己看一堆字段。更实际一点的做法可能是两者都保留后端内部仍然维护结构化数据同时对用户展示模型生成的回答。这样既方便系统处理也方便用户理解。AI 应用不是少写代码而是代码职责变了有些人刚接触 AI 时可能会觉得有了大模型是不是很多代码不用写了我现在的感受是不是代码少了而是代码的职责变了。传统 CRUD 里代码主要负责明确的业务逻辑。比如订单状态怎么流转、库存怎么扣减、优惠券怎么计算。AI 应用里代码除了处理这些确定性逻辑还要负责管理模型调用链路。比如组装 Prompt管理上下文选择模型调用模型接口解析模型返回处理失败和重试记录对话日志控制 token 消耗接入知识库检索决定是否调用业务接口这些工作并不轻松而且很后端。拿 Spring Boot 项目来说可能还是 Controller、Service、Repository 这一套结构只是 Service 里多了模型调用、知识检索、上下文管理这些逻辑。所以 AI 应用开发并不是完全脱离 Java 后端而是在原有后端能力上扩展了一层。对 Java 后端来说切入点在哪里如果让我现在从零开始做 AI 应用我不会一上来就研究很深的算法也不会马上去训练模型。我会先从几个后端能落地的小点开始。第一个是大模型 API 接入。用 Spring Boot 封装一个简单的 AI 问答接口先把请求链路跑通。这个阶段重点是理解模型调用参数、返回结构、超时处理和异常处理。第二个是对话上下文。把用户的历史消息存到数据库或者 Redis 里让系统支持连续对话。这里其实很像我们以前做登录态、会话、操作记录只是数据形态变成了聊天消息。第三个是知识库问答。把文档内容解析、切分、向量化再根据用户问题召回相关内容最后交给模型回答。这个过程会涉及向量数据库但从整体流程看还是数据处理和检索增强。第四个是业务接口调用。让 AI 不只是回答问题还能根据用户意图调用后端已有接口。比如查订单、查库存、生成报表、创建工单。这一步就开始和传统业务系统结合得比较紧了。这些方向都比较适合 Java 后端逐步切入。最后AI 应用开发和传统 CRUD 最大的不同我觉得不是技术名词变多了而是系统里多了一个会“生成内容”的能力。传统 CRUD 更强调确定性AI 应用则需要在不确定的模型输出和稳定的业务系统之间做平衡。对 Java 后端来说这既是新东西也不是完全陌生的东西。接口设计、数据处理、缓存、日志、异常、权限、限流、系统稳定性这些经验在 AI 应用里依然有用。只是以后我们可能不只是在写“查数据、改数据”的接口还会写一些能理解用户问题、组织上下文、调用模型和业务能力的接口。下一篇我准备聊聊后端程序员学习 AI真的需要一上来就啃算法吗 AI 应用开发：它和传统 CRUD 到底有什么不同？
做 Java 后端这几年CRUD 这个词基本绕不开。虽然大家有时候会拿 CRUD 开玩笑但真正做过业务系统的人都知道CRUD 并不只是增删改查那么简单。一个看起来普通的接口背后可能有权限、状态流转、事务、缓存、消息通知、幂等、日志、异常处理还有一堆业务规则。所以我并不觉得 CRUD 低级。相反很多稳定运行的业务系统本质上都是大量 CRUD 和业务规则堆出来的。不过最近开始看 AI 应用开发后我确实感觉到它和传统 CRUD 的开发方式有一些明显不同。不是说完全换了一套东西而是系统里多了一个“智能但不完全确定”的环节。这个变化会影响我们设计接口、组织数据、处理结果的方式。只从一个 Java 后端开发者的角度聊聊我目前对 AI 应用开发和传统 CRUD 的区别理解。 传统CRUD 更像是规则驱动我们平时写后端接口大部分逻辑是比较确定的。比如一个订单查询接口GetMapping(/orders/{id}) public OrderVO getOrder(PathVariable Long id) { Order order orderService.getById(id); return orderConverter.toVO(order); }当然真实业务不会这么简单。可能还要判断用户权限、订单状态、数据范围、是否命中缓存、是否需要脱敏。但整体来说它还是规则驱动的。用户传什么参数后端按照代码里的规则执行查数据库组装结果然后返回。只要数据不变、代码不变同样的请求大概率会得到同样的结果。这也是传统后端开发比较强调的地方确定性。接口要稳定返回要明确异常要可控数据要一致。我们会花很多精力去保证系统不要出现模糊结果。比如参数不合法就直接返回错误查不到数据就返回空或者指定错误码状态不允许就阻止操作数据更新失败就回滚事务第三方接口异常就重试或降级这些都是后端开发很熟悉的东西。AI 应用多了一个“不确定”的能力源AI 应用不一样的地方在于它接入了大模型。大模型不像普通函数也不像普通第三方接口。你给它一段输入它会生成一段输出但这个输出不一定每次都完全一样也不一定总是严格按照你想要的格式来。比如你让它总结一段用户反馈它可能总结得很好但你让它只返回 JSON它有时候可能会多加一句解释。你让它回答某个业务问题它可能回答得像那么回事但里面有些细节其实并不准确。这就是 AI 应用开发里比较特殊的地方模型很强但不能完全当成确定性代码来用。所以后端开发者在接入大模型时不能只想着“调一个接口拿结果”。更重要的是要考虑怎么把这个不确定的能力包装成一个相对稳定的业务服务。比如我们需要考虑Prompt 怎么写才能让模型更接近预期输出格式怎么约束方便后端解析结果不符合格式时怎么重试回答内容是否需要引用知识库模型超时或失败时怎么降级用户输入恶意内容时怎么处理调用成本和频率怎么控制这些问题和传统后端经验是能接上的。CRUD 主要围绕数据AI 应用更围绕上下文传统业务系统里核心通常是数据。我们设计表结构写 Mapper封装 Service控制事务最后通过接口把数据提供出去。很多需求的关键就是把数据存对、查准、改稳。AI 应用当然也需要数据但它更强调“上下文”。比如一个普通查询接口只需要用户传订单号后端就可以查订单表。但如果是一个 AI 助手用户可能会这样问“我上周买的那个耳机到哪了”这个问题对系统来说就复杂多了。它需要知道当前用户是谁“上周”对应哪个时间范围用户买过哪些商品“那个耳机”指的是哪一笔订单查询订单状态应该调用哪个接口最后怎么用自然语言回答用户这里面就不只是简单的 CRUD 了而是要把用户问题、用户身份、历史对话、业务数据、接口能力组合起来。从后端角度看AI 应用里的上下文可能来自很多地方用户当前输入历史聊天记录数据库里的业务数据Redis 里的会话状态文档知识库里的内容系统提前设定的 Prompt后端可调用的业务接口这些内容拼在一起才构成模型真正看到的输入。所以做 AI 应用时一个很重要的能力就是怎么组织上下文。## 接口返回值也变得不一样了传统接口返回值一般比较固定。比如{ code: 200, message: success, data: { orderId: 1001, status: 已发货 } }前端拿到以后按字段展示就行。但 AI 应用里返回内容可能是一段自然语言你上周购买的耳机已经发货目前正在运输中预计明天下午送达。这个结果更像“面向用户的回答”而不是单纯的数据返回。这带来一个问题后端到底应该返回原始数据还是返回模型生成后的文本我的理解是要看场景。如果是后台管理系统很多时候还是应该保留结构化数据。因为运营、客服、管理员需要准确字段不能只看一句自然语言。如果是聊天助手、智能客服、知识库问答模型生成的自然语言就比较有价值因为用户希望直接得到答案而不是自己看一堆字段。更实际一点的做法可能是两者都保留后端内部仍然维护结构化数据同时对用户展示模型生成的回答。这样既方便系统处理也方便用户理解。AI 应用不是少写代码而是代码职责变了有些人刚接触 AI 时可能会觉得有了大模型是不是很多代码不用写了我现在的感受是不是代码少了而是代码的职责变了。传统 CRUD 里代码主要负责明确的业务逻辑。比如订单状态怎么流转、库存怎么扣减、优惠券怎么计算。AI 应用里代码除了处理这些确定性逻辑还要负责管理模型调用链路。比如组装 Prompt管理上下文选择模型调用模型接口解析模型返回处理失败和重试记录对话日志控制 token 消耗接入知识库检索决定是否调用业务接口这些工作并不轻松而且很后端。拿 Spring Boot 项目来说可能还是 Controller、Service、Repository 这一套结构只是 Service 里多了模型调用、知识检索、上下文管理这些逻辑。所以 AI 应用开发并不是完全脱离 Java 后端而是在原有后端能力上扩展了一层。对 Java 后端来说切入点在哪里如果让我现在从零开始做 AI 应用我不会一上来就研究很深的算法也不会马上去训练模型。我会先从几个后端能落地的小点开始。第一个是大模型 API 接入。用 Spring Boot 封装一个简单的 AI 问答接口先把请求链路跑通。这个阶段重点是理解模型调用参数、返回结构、超时处理和异常处理。第二个是对话上下文。把用户的历史消息存到数据库或者 Redis 里让系统支持连续对话。这里其实很像我们以前做登录态、会话、操作记录只是数据形态变成了聊天消息。第三个是知识库问答。把文档内容解析、切分、向量化再根据用户问题召回相关内容最后交给模型回答。这个过程会涉及向量数据库但从整体流程看还是数据处理和检索增强。第四个是业务接口调用。让 AI 不只是回答问题还能根据用户意图调用后端已有接口。比如查订单、查库存、生成报表、创建工单。这一步就开始和传统业务系统结合得比较紧了。这些方向都比较适合 Java 后端逐步切入。最后AI 应用开发和传统 CRUD 最大的不同我觉得不是技术名词变多了而是系统里多了一个会“生成内容”的能力。传统 CRUD 更强调确定性AI 应用则需要在不确定的模型输出和稳定的业务系统之间做平衡。对 Java 后端来说这既是新东西也不是完全陌生的东西。接口设计、数据处理、缓存、日志、异常、权限、限流、系统稳定性这些经验在 AI 应用里依然有用。只是以后我们可能不只是在写“查数据、改数据”的接口还会写一些能理解用户问题、组织上下文、调用模型和业务能力的接口。下一篇我准备聊聊后端程序员学习 AI真的需要一上来就啃算法吗