我不转 Python：把 AI 塞进手上这套 Java 工程里
这是我"Java 转 AI 工程"系列的第 1 篇。这一篇没有代码，交代的是动手之前我逼着自己回答的三个问题：形势到底变了什么、Java 开发者在这个方向上真实的位置在哪、以及我为什么把路线押在 Spring AI / Spring AI Alibaba 而不是去学 Python。第 3 篇开始上手写工作流，这篇先把判断摊开。
一、让我坐不住的是一次评审会
需求本身不大。产品希望运营在后台直接敲一句话------"看下华东仓最近两周哪些 SKU 可能断货"------然后把结果导成一张表交差。
评审席上安静了几秒。我脑子里冒出来的第一版方案，还是熟悉的配方：建三个报表页面，把口径写死在 SQL 里，再加一个下拉框让人选维度。产品问能不能"下次换个维度不用发版"，我说这个得排期。
那一刻我挺难受的。因为这套东西在企业里已经不算新需求了。而我作为后端，能给出的最优解还停留在"多写几个接口"。
回去我把招聘软件上自己那档薪资区间的 JD 重新翻了一遍，越翻越确定：让我难受的不是某个新框架要学，而是我这些年攒下来的东西，正在从"竞争力"变成"及格线"。
还有一件更小的事。会开到后半段，产品问"这个能不能让 AI 做"，我听到自己回了一句"这个不太适合"。可我判断不了它适不适合------因为我手上没有过任何一个接了大模型的业务链路。那一刻的不适感，比"传统后端岗位竞争越来越激烈"这种话真实得多。
二、岗位那边真实发生了什么
下面这张表是我整理出来的四类 Java 岗位（口径来自讲义里那页招聘需求分析），我把它们并排放，是因为单看任何一行都得不出结论：
| 岗位类型 | 区间 | 要求里让我停下来的那一条 |
|---|---|---|
| Java AI Agent 岗 | 25--50K·16 薪 | Agent 架构设计、上下文工程、RAG 解决方案；还要求"了解深度学习算法"；Java 经验只卡 2 年以上 |
| 高级 Java 开发 | 25--45K·16 薪 | "尝试过 AI 新技术"被直接写进优先录用条件 |
| Java AI 方向岗 | 15--22K·15 薪 | 明确要看主流大模型开发平台的使用经验和应用开发经历 |
| 普通 Java 后端 | 20--30K | 参与过 AI 平台研发成为重要加分项 |
四行并排，结论只有一个：AI 不再是某个岗位的标题，而是所有 Java 岗位 JD 里多出来的那一列。 而且门槛的方向变了------从"你会不会写这个类"变成"你有没有真的把大模型接进过一条业务链路，并且让它可控"。
值得注意的是 Java AI Agent 岗那行：它并不要求你是算法出身，Java 经验只卡两年，真正卡人的是 Agent 架构、上下文工程、RAG 这三样工程味的东西。这对我们这些写了很多年业务代码的人是个信号：这条路的入口比我以为的宽。
四份 JD 摊开之后，我把反复出现的要求归成四类------也就是我要给自己排的四门课：
- Agent 架构设计：多个节点 + 共享状态 + 决策分支怎么搭，而不是"调一次大模型"这么简单。
- 上下文工程：怎么在有限的窗口里塞进刚好够用的信息。这一条几乎没人系统讲，全是踩出来的。
- RAG 解决方案：企业内部知识库问答这一整类需求的统称，重点在"解决"两个字------召回了但答错，一样不能上线。
- 大模型平台的使用经验：用过哪家、踩过什么坑，比能背出概念重要。
这四条的主语全是系统，不是模型。唯一沾算法的那句是"了解深度学习算法"，而"了解"这两个字说明它要的是能看懂别人在做什么，不是让我去复现。
至于讲义里另外那几个数字------市场规模、年增长率、AI 岗比传统 Java 岗高百分之多少、高级工程师年薪多少万------我不在这里当论据用。这类数字要么无法核对，要么是把最好和最坏的情况平均之后的产物，我不想把自己的职业判断建在它上面。真正让我改变计划的，是上面那张表里"要求列"的变化，那个是可以一个字一个字验证的东西。
还有一点我也记着：讲义提到部分企业已经在用 AI 替代前端工程师的岗位。被替代的从来不是某门语言，而是"只会把需求一字不差翻译成代码"的那部分工作。
三、Java 开发者做 AI：优势和短板都得说实话
我的做法是把手上的牌和缺的牌分开列，别互相安慰。
| 我不用学就有的 | 我必须从零补的 |
|---|---|
| 企业级工程的肌肉记忆：分层、事务、幂等、限流降级 | 大模型的基本心智：token、上下文窗口、温度，以及它为什么会幻觉 |
| 数据源和接口本来就在我这侧：库存、订单、ERP、消息中心 | 工作流编排模型：状态怎么流动、节点怎么拆、循环和分支怎么收敛 |
| 可观测可运维那一套：日志、链路追踪、告警、灰度发布 | 提示词与上下文工程------这活儿没有编译器给你报错 |
| 高并发、高可用、安全性这些指标我天天背 | RAG 整条链：切分、召回、重排，以及怎么判断"召回得准不准" |
| Java 在企业级开发里仍是主流，招聘盘子就在这儿 | 深度学习算法至少要"了解"，不然 JD 上那一条就卡人 |
最大的短板我觉得不是语言，而是心智模型 。CRUD 的世界是确定的：同样输入必得同样输出，所以我们的全部工程习惯都建立在"复现"之上。Agent 的世界是概率的，同一句提示词两次给出两个答案。传统 Java 工程师的第一反应是加 try-catch 加重试------可一旦模型一本正经地胡说八道，重试救不了你，你真正要做的是在链路中间插一个"停下来让人看一眼再决定走哪条路"的口子。
这个转向比换语言难得多，也值钱得多。因为它意味着岗位进化：从代码编写者，变成 AI 解决方案的设计者。而所谓复合能力里最难的一项，我认为是会指导 AI 写代码------这玩意儿不是把提示词写漂亮，是你能不能把自己对系统的约束讲清楚。
反过来讲，有三件事是我这两年白攒的，也是大多数 AI 应用团队缺的：
- 成本与限流：模型调用按 token 计价，一次自然语言查询背后可能是几十次调用。谁调的、调了多少、超了怎么办，得有人负责。
- 幂等与回滚：AI 建议调拨两百件库存，接口被重试了两次怎么办。这类问题在 demo 里永远不会暴露出来。
- 权限与审计：谁允许 AI 看这批数据、AI 给了什么建议、最后谁批的------这三问必须有答案，不然功能根本上不了线。
它们和"会不会写提示词"没太大关系，却是同一个系统里最贵的部分。这也是我判断"企业级开发经验可以直接迁移"的依据：迁移过来的从来不是代码，是这些责任。
四、路线取舍：为什么不转 Python，为什么是企业侧
先说为什么不转 Python。
Python 是研究侧和模型侧的通用语，我要是想训练、微调模型，非它不可。但我判断自己抢不过那个赛道：那边拼的是数学底子和论文跟进速度，我进去就是分母。
反过来看企业这边，落地的瓶颈从来不是"没人能训练模型"，而是模型和公司内部的账号体系、权限模型、数据源、审批流接不上 。这部分活儿恰好是 Java 的主场，而且 Spring AI 这类框架已经把路修通了------讲义的说法叫"Java 到 AI 开发的无缝转型"，我的说法更保守一点：至少我不用把工程那一半重学一遍。 分层、事务、容器、发布、监控全部照旧，新增的只是链路里那几个会猜的节点。
再说为什么是 Spring AI / Spring AI Alibaba。我给自己列了四条验收标准，达不到就换路线：
- 能进企业工程：产物是可单测、可发布的服务，不是一个 notebook。低代码平台我后面一章会单独比较。
- 有工作流编排能力 ：业务流程一旦掺进模型调用，分支就不再确定，必须有一张"图"来承载状态和决策，而不是把它塞进
if-else。 - 模型接得上国产生态，也能换：既能对接国产大模型和 OpenAI 协议，也能整条链路换成私有化部署。
- 版本线清楚：Spring AI 和 Spring AI Alibaba 是两条独立版本线，得配套使用；文档和社区要跟得上，不然每个星期都在改 API。
私有化部署这件事我要单独拎出来说。企业数据出内网是绕不过去的坎------这也是我在这条路线上最满意的一点：它把"调第三方大模型"和"部署自己的模型"都当成一等公民，而不是只给你一条云端 API。
至于押企业侧而不押算法侧，理由一句话就说完：我不打算跟科班出身的人比谁的损失函数调得好，我比的是谁能把一个不确定的东西装进一个必须给 SLA 的系统里。这个赛道上，我这几年攒的脏活儿经验是资产，不是包袱。
另外，不把被我否掉的路线写出来，这个选择就等于没做过判断：
| 备选路线 | 我为什么先否掉 |
|---|---|
| 转算法 / 模型训练 | 拼的是数学底子和跟进论文的速度，我没优势；那个岗位要的是能改结构的人，不是能读业务需求的人 |
| 一头扎进 C 端 AI 应用 | 由流量和创意驱动，我这些年攒的企业系统经验几乎用不上，等于清零重来 |
| 停在低代码平台上 | 上手最快，但需求一变就撞到平台给定的边界。这条我不是一刀否掉的，下一篇单独算账 |
| 换 Go / Node 再找机会 | 换语言解决不了"没做过 Agent"这个根问题，只是把同一个短板换个地方暴露 |
五、我打算用哪两个项目验证这个判断
选项目我的标准很功利：能不能对着业务讲清楚、有没有可优化的地方、面试官会不会顺着往下追问。按这个标准我准备做两件事，它们分别对应我上面说的两个短板。
智能库存调拨 Agent。 自动分析销售数据和库存状况，生成调拨建议，发出审核邮件，支持采纳/拒绝的交互决策。我看中的偏偏不是"全自动"，而是审核邮件 + 采纳/拒绝那一步：它正好是概率系统进入企业流程时唯一负责任的做法，也是我作为一个后端必须亲手解决的东西------幂等、状态回写、超时没人回复怎么办。
自然语言报表 BI Agent。 运营用一句自然语言提查询需求，系统输出结构化的 Excel 报表，直接服务商业分析和决策。我看中的是它天然带着企业侧最难的两件事：权限口径 （这个人能看哪些数据）和结果可信度（生成的 SQL 到底对不对）。
我特意要两个而不是一个：一个纵向够深，链路长，要和审批流、真实库存数据死磕；一个横向够宽，要面对一堆口径不确定、权限也不确定的提问。两个摆在一起，才能同时回答面试官一定会问的两类问题------"你的链路是怎么设计的"，和"你怎么保证结果是可信的"。
这两个项目都绕不开安全性、并发处理、系统可用性这三个硬指标，所以我给自己的要求是按生产标准做，而不是跑通就算完。另外一个习惯我也保留下来：项目做完必须能列出一张"我改了什么、为什么改"的清单------面试里真正能加分的是这张清单，而不是项目名字。
至于适用人群，我现在的判断是：从初级到中高级的 Java 开发者都接得住，因为起点就是业务代码；而想进校招的学生反而更该早点碰，AI 项目在校招里的区分度正在变高。
六、这篇说完，我现在信了三件事
- AI 不是给 Java 简历加一个词，而是把"写代码"在整件事里的位置往后挪了一格。 我的产出越来越多是"设计和约束一个会猜的系统"，代码只是约束的载体。
- 这条路径不用跳车。 Java 后端 → AI Agent 工程师 → AI 解决方案架构师，每一步都还踩在 Java 上，只是责任范围在扩大，而不是转行。
- 护城河不是"我会三个框架"，而是"我能在一个概率系统上给出企业级的确定性"。 讲义里说这类技术竞争力能保五年十年，这个我不敢信；但"复合能力"这四个字我认。
这个判断里我最没底的一条，放在这里是：我不确定提示词工程会不会在两年后被框架彻底封装掉，变成不需要人写的配置。我的对冲办法是把精力放在框架替不了我决定的一侧------状态怎么设计、链路怎么观测、成本怎么控、人在哪一步介入。这四件事不管封装层级怎么变，都得有人负责。
下一篇（第 2 章）我打算先把"AI 工作流开发到底有几条路"这件事掰扯清楚。目前我看到的是三条：一是 Dify / Coze 这类低代码平台，拖拽出流程图就能跑，非技术同学也能上手；二是各家自己造轮子，控制力最强但成本也最重；三是 Spring AI Alibaba 的 Graph------把流程图画在代码里，既保住可视化和编排能力，又塞得进企业工程。下一篇我会把三条路各自的适用边界讲清楚，包括什么情况下我会回头选第一条，以及在第一条路上我会怎么把需求接住。
本系列是我从 Java 后端往 AI Agent 方向转的学习记录，本篇是判断和选型，没有代码；观点会随着后面动手的结果继续修正。文中的岗位区间与要求是我从看到的招聘口径里整理出来的样本，没有逐个独立核实，只用来支撑"要求那一列正在变"这个结论。所有技术结论以我本地跑通的 Spring AI Alibaba 工程为准，第 3 篇开始手写 Graph 工作流。