关于 AI 应用和现在程序员就业的一些看法

前段时间有朋友问我：

“现在 AI 这么火，要不要从 Java 转 AI 应用？”

我当时第一反应是，这两个东西其实就不应该放在一起比较。

有点像几年前问：

“我要不要从 Java 转电商？”

AI 应用是一个方向，Java 是后端的一门语言，本身就不是一个维度的东西。

借这个问题，说一下我目前对 AI 应用、技术栈和程序员就业的一些看法。

都是这两年工作下来的一些个人感受，略带主观。

1. 单一技术栈已经不太够用了

国内 Java 的存量盘依旧很大，这个短时间内不会有什么变化。

但我觉得现在只会 Java，或者把自己完全定义成一个 Java 工程师，已经不太够了。

目前后端我比较建议接触的还是：

Java、Go、Python。

Java 主要还是国内大量存量项目、企业级应用和现有团队技术栈。以后很多传统业务做 AI 赋能，也不可能把原来的东西全部推倒重来。

Go 在高并发、云原生这些场景本身就有优势。现在很多 AI 应用又恰好涉及大量并发、流式输出和长连接，用 Go 也比较合适。

Python 就不用说了。

AI 应用继续往下走，不管是 PyTorch、训练、推理还是 AI Infra，基本都绕不开。

当然我不是说三门语言都要学到一样深。

至少有一门是自己的主语言，真正熟练，其他的能用、能看、能改就行。

现在有 AI 以后，第二门、第三门语言的学习成本其实已经低很多了。

前端也是一样。

以前如果有人问我国内学 Vue 还是 React，我可能会更建议 Vue。

现在我会更建议 React + TypeScript。

主要还是国外生态更大，而且现在 AI Coding 对 React/TS 的支持也更好。

当然结合国内就业，Vue 最好还是得会。

所以我现在对技术栈的看法比较简单：

主技术栈一定要有，但没必要再给自己贴死某一门语言的标签。

2. 一定要高强度使用 AI

这个是我目前最确定的一点。

AI Coding 已经不是“以后会不会普及”的问题了。

已经发生了。

我们目前甚至有一个真实的企业项目，基本就是纯 Vibe Coding 驱动开发。

而且不是 Demo。

项目本身是一个比较复杂的 AI 应用平台，涉及多租户、异步任务、分布式并发控制、实时通信、向量检索、全文检索、消息网关、服务监控和 CI/CD 等。

AI 这块也不只是调一下大模型 API，还涉及 RAG、多模态、ASR、视觉检索，以及 PyTorch、CUDA 相关的推理服务。

并且整个架构从一开始就是按照服务拆分、异步化和后续横向扩展去设计的。

说这些不是想证明这个项目有多复杂。

主要是想说，这是一个有真实工程复杂度、需要长期维护的企业项目，而且大量代码确实是 AI 完成的。

到目前为止，也没有出现所谓“Vibe Coding 到最后完全没法维护”的情况。

所以我现在觉得：

Vibe Coding 本身不是问题，问题是使用 AI 的人有没有工程能力。

前两天我负责对接一个渠道商做兼容性的 RAD 开发。

方案、编码、测试基本全部由 AI 完成。

大概半天。

这个事情如果按照以前的开发方式，我估计至少两三周。

所以对于 AI，我没什么“要不要用”的建议。

一定要用，而且要高强度地用。

方案、编码、测试、Debug、Review、CI/CD，能用就用。

这已经是生产力问题了。

再说句题外话。

我现在觉得 AI 已经不只是开发工具了。

生活里很多需要搜索信息、学习、分析、做决策的事情，我都会先问一下 AI。

不一定听它的，但至少多一个信息源，多一个思考角度。

开发就更不用说了。

现在越来越多公司已经把 AI Coding 当成正常的研发工具，AI 带来的提效也是实打实的。

所以如果你长期处在一些接触不到 AI 的开发环境里，比如部分外包、纯内网、对日或者 ToG 项目，我觉得需要注意一个问题：

你损失的不只是 AI 帮你写代码的那点效率，而是在慢慢错过一套新的研发方式。

短期当然没什么。

但如果三年、五年一直处在这种环境里，而外面的工程师已经习惯用 AI 做方案、编码、测试、Review、Debug，甚至完成整个研发流程，那两边积累下来的工作方式和效率差距会越来越大。

所以如果工作环境确实用不了 AI，我反而更建议自己在工作之外保持使用。

可以不用 AI 写公司的代码，但不要让自己长期脱离 AI。

这也是为什么我一直强调高强度使用 AI。

不是因为现在 AI 火。

而是我觉得，会不会把 AI 真正融入自己的工作流，很可能会逐渐变成工程师的基础能力。

3. AI 越强，基本功反而越重要

这一点我最近感受也比较深。

24 年甚至更早的时候，我们是真的会为了一个环境折腾半天。

碰到一些难调的 Bug，就自己看日志、翻源码、抓包、排调用链，一点一点 Debug。

现在很多问题直接扔给 AI，可能几分钟就解决了。

所以有时候我反而觉得，26 年才开始学编程的人可能更难。

不是因为工具差，恰恰是因为工具太好了。

很多以前必须自己经历的过程，现在可以直接跳过去。但那些过程其实会慢慢形成一些工程直觉。

所以如果你是新人，问我要不要打好基础，我的答案是：

非常有必要。

数据结构、操作系统这些基础该学还是得学。

同时至少选一门自己的主开发语言，真正学到熟练。不是会写几个接口、会调几个框架就叫熟练，而是真的拿它做过项目、调过问题，对它的运行机制和生态有足够的理解。

因为 AI 可以写代码，也可以 Debug。

但 AI 给你的东西到底对不对，最后还是需要你判断。

事务、并发、幂等、异常、性能、可观测性，包括系统出了问题应该从哪里开始查，这些东西不会因为 AI 出现就消失。

反而是 AI 把编码本身变得越来越便宜以后，这些东西才是真正能拉开工程师深度的地方。

以前没有 AI 的时候，大家卷框架、卷 API、卷谁记得多，我觉得没什么问题，因为当时这些东西确实直接影响开发效率。

但现在很多框架层面的东西，AI 比我们记得更全，写得也更快。

所以我现在反而更建议新人把时间往基础上放一点。

当然，这个建议也不只是给新人。

包括我自己，现在也在重新花更多精力，更专业、更体系化地去学这些基础。

以前很多东西可能是工作里遇到了再学，或者知道怎么用就够了。但现在有了 AI，我反而觉得可以把以前花在记框架、记 API 上的时间拿回来，真正去理解一些更底层、更长期的东西。

有几本书我一直比较推荐：

1. Clean Code
2. The Clean Coder
3. Understanding the Linux Kernel
4. Head First Design Patterns
5. Designing Data-Intensive Applications

当然，书只是一个载体。

我真正想表达的是：

AI 时代不是不需要基本功了，而是以前很多“会用框架”的价值正在被 AI 吃掉，基础和工程判断的价值反而更高了。

AI 可以替你少走很多弯路，但有些路你最好真的走过。

所以我现在越来越觉得，AI 真正放大的不是编码能力。

是判断能力。

4. AI 应用可以转，但现在已经不是做几个 Demo 就好找工作的阶段了

我自己其实算比较早转 AI 应用的。

25 年 10 月，我就从传统开发转到 AI 赛道了。

所以如果提前半年或者一年有人问我：

“会 RAG、做几个 Agent 项目，能不能转 AI 应用？”

我会觉得问题不大。

但现在我的看法已经变了。

不是 AI 应用不值得做，恰恰是因为这个方向太火了，进来的人太多了。

现在很多简历翻来覆去都是：

RAG 知识库、AI 客服、PDF 问答、LangChain、Embedding、Milvus、Rerank……

这些东西当然要会，我自己也在做。

但问题是，会这些东西的人已经太多了。

更现实一点说，现在如果只是拿几个这种项目去找 AI 应用的工作，我觉得已经没有以前那么容易了。

而且关于项目这件事，我可以说得直接一点：

现在国内网上能看到的大量所谓 AI 应用项目，我觉得本质上还是玩具项目。

换一个模型、接一个知识库、套一个 Agent 框架，最后做个聊天页面。

能跑。

但离真正的企业项目还很远。

所以如果现在还准备转 AI 应用，我更建议去看：

真实业务、真实客户、真实场景。

我前公司是做 AI + 教育的。

国内这一块真正落地的东西，无非也是 AI 答疑、AI 批改、OCR/VLM、个性化学习这些。

AI 答疑底层一样可能是 RAG。

区别只是它最后真的要面对学生、老师和学校，真的要解决问题。

所以不是不要学 RAG，也不是不要学 Agent。

这些东西该学还是得学，只是别再把“会 RAG、会调 Agent”本身当成竞争力了。

5. 除了业务深度，还需要一点技术纵深

上面说的是业务。

但只解决“项目别做成 Demo”这一个问题，我觉得还不够。

现在 AI Application / Agent 这个方向已经很热了，而且这个趋势越来越明显。

当大量工程师都开始做 Agent、RAG、工作流、MCP 以后，应用层的技术差异一定会越来越小。

所以除了去做真实业务以外，我现在还有另外一个建议：

适当往下走，给自己增加一点技术纵深。

这也是我自己接下来准备深入 AI Infra 的原因。

我目前比较看好：

后端 / 分布式 + AI Application / Agent + AI Infra。

不是放弃应用层。

恰恰相反，我觉得上层的业务经验很重要，只是在这个基础上继续往模型推理和基础设施走一点。

当然，AI Infra 也别最后学成下一个 RAG。

不是会 Docker、K8s、vLLM，再部署一下 CUDA 环境，就叫 AI Infra。

继续往下还有 Inference Serving、Batching、Scheduling、KV Cache、GPU Memory、PyTorch、CUDA、NCCL、GPU Cluster，以及监控、扩缩容、容错、成本这些东西。

这一块我自己也还在继续学，所以不展开，也不装懂。

我现在的想法其实很简单：

应用层越来越拥挤，就不要只在应用层继续横向堆东西。

业务上往真实场景走，技术上往深处走。

至少目前，我自己准备这么走。

最后其实就两个建议。

1. 高强度使用 AI，别和生产力过不去。

不要只拿 AI 补两行代码。

方案、编码、测试、Debug、Review、CI/CD，能用就用。

2. 如果准备转 AI，别再堆玩具 Demo。

去看真实业务，解决真实问题，再给自己找一个方向往深了走。

至于 Java、Go、Python、React、Vue，该用什么就用什么。

主技术栈要有，工程基本功别丢，AI 狠狠用。

差不多就这些。

听不听随意。