最近和一位做企业信息化的老同学聊天，他感叹公司去年轰轰烈烈成立的AI实验室如今陷入了尴尬境地——投入上千万元训练的行业大模型，在实际业务中居然找不到合适的落地场景。技术团队演示时天花乱坠的业务助理、智能风控等应用，真到上线时却因为与现有系统难以融合而纷纷搁浅。
这让我想起Rod Johnson最近在技术社区分享的观点：真正的AI转型应该建立在现有业务系统之上，而不是另起炉灶。这位Spring框架之父正在深耕AI应用开发领域，他创建的Embabel项目提出了一种务实的思路——让AI从现有业务系统中自然生长出来。
很多企业在谈“AI转型”的时候，喜欢画大饼，动辄就是什么“智能代理全面替代人力”“自动化决策颠覆行业”。这些愿景听上去很热闹，但现实却是，MIT最近的一份报告显示，企业在生成式AI上的投入高达三四百亿美元，可真正得到回报的不到5%。为什么？因为大多数公司都在试图一口吃成个胖子。
大家可能都经历过这种场景：PPT里画着宏伟的AI蓝图，会上领导们点头称是，但等到要落地时，现有系统不兼容，业务逻辑没人敢改，数据孤岛依旧没打通。最后AI项目只能挂在墙上，变成一堆昂贵的试点。Rod Johnson的这篇文章，给我们提了个醒：别急着搞复杂的Agentic Flow（智能代理流程），先把现有的应用AI化，才是走向AI转型的起点。
AI落地的关键，不是“全新”，而是“叠加”
我们先别急着谈什么AI颠覆行业，现实是绝大多数应用已经存在多年，承载着关键的业务逻辑。比如银行的账户系统、旅游公司的订单管理、零售的库存平台。这些软件往往是用Java写的，跑在JVM上，稳定、可靠、难以替代。
那么问题来了：我们要不要为了AI推倒重来？答案当然是否定的。Rod Johnson的观点很朴素：在原有系统里嵌入AI能力，让AI成为增量，而不是革命。
举个例子，如果你是旅游公司的一名客服，客户一来查账户，你需要翻一堆报表看他过去的消费、出行、目的地。有没有可能在点开账户时，系统自动生成一段简洁的总结？比如“张三在过去两年去了5次日本，总消费超过2万，是一名高价值客户”。这就是一个典型的AI增量点：只需要一次LLM调用，就能让人工客服的体验和效率提升一个档次。
这类需求不需要复杂的多轮对话，不需要构建庞大的智能代理，只要在现有应用上加一个小小的组件，就能立即见效。
Spring、JVM与AI的天然契合
文章里提到了一个开源工具——Embabel。它的特别之处在于，它并不是独立的AI平台，而是和JVM深度结合，能无缝嵌入Spring应用。对于已经在企业里跑了十几二十年的Java系统来说，这意味着AI不是“外来者”，而是“扩展模块”。
在代码层面，Embabel让开发者可以通过一个统一的Ai接口调用LLM。比如Rod给出的示例，写了一个ActivitySummarizer，把客户的出行数据交给AI，请它总结成一段文字。逻辑非常清晰：
1. 先从已有的TravelActivityReportingService拿到数据。
2. 把数据对象交给AI。
3. 在Prompt里说明要求，比如多少字、怎么判断高价值客户。
4. AI返回总结，打包成新的Report对象。
整个过程没有破坏原有的业务逻辑，也不依赖AI去做复杂的计算。判断高消费、高频出行这些逻辑，依然是由Java对象的方法（标注了Tool注解）提供，AI只负责组织语言。这样一来，既能利用AI的自然语言能力，又避免了AI在数学和逻辑上的“幻觉”。
为什么说“领域对象”才是AI落地的关键？
很多人觉得用大模型就要全权依赖它去推理、判断。但Rod的思路刚好相反：LLM的强项是语言，不是计算。真正的业务逻辑，依然要依赖我们已有的领域对象。
比如在旅游场景里，客户一年到底算不算高频出行？这不是让AI自己猜，而是通过tripCount()和tripsPerYear()这样的领域方法算出来。AI只需要拿到这些明确的数据，然后把它转化为客服容易理解的总结即可。
这背后其实有个重要的经验：AI要成功落地，必须“尊重领域知识”。而在企业系统里，这些领域知识早已通过对象、接口、数据库建模固化下来了。与其推倒重来，不如让AI站在这些积木的肩膀上。
测试与工程实践，AI也不能例外
很多AI项目在落地时，会忽视一个问题：测试。因为Prompt看似灵活，就觉得没法测试。但Embabel的设计却延续了Spring的传统，让AI调用也能被Mock和验证。Rod举的例子很典型：用Mockito模拟AI接口，让单元测试依然能覆盖“客服总结”逻辑。这样开发团队才能放心迭代，不至于每次修改Prompt都心惊胆战。
换句话说，AI集成不能游离于工程实践之外。没有测试保障的AI功能，只是漂亮的演示，不可能真正进入核心系统。
为什么很多AI项目失败？
Rod最后提到一个核心问题：为什么95%的企业AI投入没有产出？其实原因很简单——大家试图“直接奔向未来”。而真正可持续的路径，应该是“从今天的系统出发”。
大规模的Agentic Flow确实会到来，但它不是一蹴而就的。企业真正需要的，是找到那些切实可行的小切口，在已有应用里嵌入AI，让业务人员立刻感受到效率提升。随着这些点的积累，团队对AI的理解和信任才会逐步建立。
就像Rod说的：“别用PowerPoint画未来，用代码做今天能落地的事。”
写在最后
如果你所在的企业正打算推动AI转型，建议不要一开始就喊着要全面重构系统。先从一个表单、一个报表、一个客服总结开始，把AI能力“缝合”到现有的应用里。
当业务人员开始真正依赖这些功能时，你才算踏上了AI转型的正道。未来的Agentic Flow会很精彩，但它的地基必须是这些小而实用的AI化功能。
Rod Johnson的这篇文章，其实就是在提醒我们：AI不是革命，而是进化。能和你已有的系统、已有的领域知识融为一体的AI，才是真正能跑通、能产生价值的AI。
要点：
企业架构师的 GenAI 落地清单
1、领域建模：让AI站在对象肩膀上
- 保持领域对象的方法，例如：tripCount()、totalSpend()。
- 用 @Tool 注解明确暴露给 LLM，这样模型不会胡乱计算，而是调用可靠数据。
- 领域建模的要求：
- 数据准确（AI依赖的对象必须真实）。
- 方法明确（避免业务含糊，让AI自由发挥）。
2、基础设施：逐步演进
- 依赖管理：在 Spring Boot 加 Embabel Starter 即可，避免额外中间层。
- 事务管理：数据库操作和 AI 调用要 分开事务，避免长事务阻塞。
- 资源管控：先限制调用频率和最大词数，避免成本失控。
3、Prompt工程：结构化而非随意
- Prompt 要包含三类信息：
- 任务角色（“你是旅行社客服助手”）。
- 业务规则（高消费/高频客户的阈值）。
- 数据上下文（由工具方法提供）。
- 使用模板化 Prompt，避免写死逻辑，便于后期调整。