从 Java 全栈转向 AI 应用开发，并不是把过去经验推倒重来。真正能迁移的是业务建模、服务分层、数据可靠性、系统对接和交付意识。AI 应用多了模型调用、Prompt、检索和评估，但它仍然需要清晰的工程边界。
可迁移的是工程判断
传统业务系统会问：用户是谁、流程怎么走、数据如何沉淀、异常怎么处理。AI 应用同样需要这些问题，只是中间多了一个概率性组件。模型会生成内容，但产品仍然要决定输入、上下文、工具、权限和输出格式。
过去做高校科研平台定制交付时，我需要把客户需求拆成模块、流程、表结构、接口和交付计划。现在做 AI 应用时，这套拆解能力会迁移为场景定义、Prompt 约束、检索素材、模型路由和评估规则。
从业务建模到上下文建模
Java 项目中的实体、状态和业务规则，对应到 AI 应用里就是上下文结构。比如识礼小记里的沟通场景，不只是一个标题，而是用户目标、关系类型、角色设定、隐藏规则和评分维度的组合。
上下文建模越清楚，Prompt 就越少依赖临场发挥。模型知道自己扮演谁、不能做什么、应该按什么标准输出，产品也更容易把结果复盘给用户。
- • 业务对象迁移为上下文字段和检索过滤条件。
- • 流程状态迁移为对话阶段、任务状态和 fallback 状态。
- • 业务规则迁移为 Prompt 约束、输出 schema 和后处理校验。
从服务分层到 AI 链路分层
Spring Boot 项目里常见的 controller / service / repository 分层，在 AI 应用里仍然有价值。只不过 service 层会多出模型网关、检索器、重排器、评估器和工具调用编排。
我更倾向于把 Provider 细节隔离在适配层，把业务入口保持为稳定接口。这样无论后续切换 OpenAI-compatible 云模型、国产模型还是本地 Ollama，都不需要让页面和核心业务跟着大改。
- • 模型 Provider 是基础设施，不应直接占据业务入口。
- • Prompt、检索、重排、生成和评估应该能独立测试。
- • 降级文案、超时和错误处理需要和正常回答同等重视。
数据经验迁移到 RAG
做业务系统时，MySQL、Redis、索引、缓存和消息队列解决的是数据组织与可靠性问题。RAG 里的文档解析、切片、向量索引、关键词检索、重排和引用，本质上也是数据工程问题。
RAG 不只是把文档塞进向量库。它需要明确哪些材料能公开、哪些材料要脱敏、哪些材料不应该进入知识库；还要处理召回不足、来源引用、答案无法确认等边界。
下一步的能力拼图
我现在的方向是把 Java 全栈经验和 AI 工程实践组合起来：云端个人站负责展示和访问控制，Spring Boot 后端负责业务 API 与 AI 请求转发，本地 Python RAG 服务负责知识库检索和生成。
这条路线能展示传统工程能力，也能展示 AI 转型所需的检索、生成、评估和安全边界。对我来说，AI 应用开发不是只会调模型，而是把模型放进可维护、可验证、可交付的系统里。