找回密码
 注册
搜索
查看: 295|回复: 9

未来 5 年,AI 行业最值得关注的 8 个技术岗位,以及每个岗位应该学习什么。

[复制链接]
发表于 2026-10-24 10:43:24 | 显示全部楼层 |阅读模式
未来 5 年,AI 行业最值得关注的 8 个技术岗位,以及每个岗位应该学习什么。

我发现现在很多人学习 AI,最大的问题就是太喜欢追逐新东西了。

今天学 RAG,明天研究 Agent,后天又出来一个新的框架,天天都在学习,但始终不知道自己到底应该往哪个方向发展。

看完这份清单,我觉得有必要分享给所有想进入 AI 行业的人。

1. AI Engineer(AI 工程师)

把大模型真正集成到产品中,解决实际业务问题。

重点学习:RAG、Tool Calling、Evals、Python、API 开发。

2. Cybersecurity Engineer(网络安全工程师)

负责发现漏洞、防御攻击,保护系统和数据安全。

重点学习:红队/蓝队、网络安全、密码学、安全测试。

3. Agent Ops Engineer(Agent 运维工程师)

未来企业可能同时运行几十个甚至上百个 Agent,谁来保证它们能够稳定工作?

重点学习:Tracing、任务队列、成本控制、监控和故障恢复。

4. AI Security Engineer(AI 安全工程师)

专门解决 AI 系统的提示词注入、敏感数据泄露、越权调用等问题。

重点学习:威胁建模、Red Teaming、Sandboxing、权限隔离。

5. AI Infrastructure Engineer(AI 基础设施工程师)

负责模型推理、GPU 资源调度和高性能 AI 基础设施。

重点学习:CUDA、Kubernetes、vLLM、GPU Scaling。

6. Cloud Security Engineer(云安全工程师)

保护部署在云端的 AI 服务、数据和基础设施。

重点学习:IAM、AWS/GCP 安全体系、云安全架构、合规。

7. AI Governance Engineer(AI 治理工程师)

确保 AI 系统的运行符合企业政策、法律法规和审计要求。

重点学习:Audit Logs、Policy as Code、EU AI Act、风险管理。

8. AI Evals Engineer(AI 评测工程师)

我认为这是未来非常值得关注的方向之一。

AI 能不能生成答案不重要,重要的是答案到底对不对,系统究竟可不可靠。

重点学习:测试数据集、LLM-as-Judge、Regression Testing、评测体系设计。

我自己这几个月一直在接触企业 AI 落地,越来越发现一个问题:现在做出一个 AI Demo 已经越来越容易了,但让它安全、稳定、低成本地运行,并且能够持续验证效果,依然非常困难。

一个 Agent 能够调用工具,不代表它能稳定执行任务;一个 RAG 系统能够回答问题,不代表它不会产生幻觉;一个 AI 产品能够上线,也不代表它能够长期可靠地运行。

所以我觉得,未来真正值得投入的,是那些能够解决真实工程问题的能力。

而且普通人完全没必要把这 8 个方向全部学一遍。先把 Python、SQL、HTTP、Git 这些基础打好,再根据自己的兴趣和职业目标选择一个方向深入。

对于想做 AI 应用落地、FDE 的人,我尤其建议关注 AI Engineering、Agent Ops、AI Evals 和 AI Security 之间的交集。

未来 5 年,岗位名称可能不断变化,框架可能不断被替代,但真正扎实的软件工程能力、系统设计能力、安全能力和验证能力,不会轻易过时。

不要只追着最新的 AI 工具跑,学会构建系统、验证系统、保护系统,让系统真正解决问题,这些能力可能比你掌握多少个热门框架重要得多。

 楼主| 发表于 2026-10-24 10:43:43 | 显示全部楼层
未来5年内最重要的8个角色及每个角色的学习要点:

1.) AI工程师
- 将LLM功能集成到真实产品中
学习:RAG、工具调用、评估

2.) 网络安全专家
- 攻击并保护整个互联网。
学习:选择一条赛道,深入红队或蓝队,钻研密码学。

3.) 智能体运维工程师
- 确保AI智能体舰队安全运行,24/7全天候
学习:追踪、队列、成本控制

4.) AI安全工程师
- 保护AI系统免受提示注入和数据泄露
学习:威胁建模、红队测试、沙箱隔离

5.) AI基础设施工程师
- 运行GPU和推理服务,其他一切都依赖于此
学习:Cuda、Kubernetes、vLLM、GPU扩展

6.) 云安全工程师
- 锁定每个AI产品运行的云环境
学习:IAM、AWS/GCP安全、合规性

7.) AI治理工程师
- 确保AI遵守法律和公司政策
学习:审计日志、政策即代码、欧盟AI法案

8.) AI评估工程师
- 在用户发现问题前证明AI确实有效
学习:测试数据集、LLM作为评判器、回归跟踪

职位名称会变。
系统不会过时。

收藏此文 + 转发给正在选择下一个角色的人。
 楼主| 发表于 2026-10-24 11:04:32 | 显示全部楼层
让你运气更好的一些玄学:

1、不要说自己身体不好、没钱、命不好等。有种玄学叫作"自证预言。

2、每天默念一遍“凡事发生皆有利于我”,正念的力量,你会真的越来越顺。

3、不与负能量的人纠缠、远离爱抱怨的人、多接触高能量的人、好好睡觉、多接触大自然,可以提升磁场,提升能量,聚财运。

4、疾风骤雨,不行房事。

5、不要一直穿颜 色 暗 的衣服。

6、去银行蹭水喝,银行是财气聚集的地方。

7、打扫干净屋子。“财神不入脏门”。

8、燕子筑窝,不赶。

9、不内耗,想做的事就立即去做。

10、行有所止,欲有所制。学会克制欲望,才能达到更高的成就。

11、多念旺自己的玄学小咒语:他强任他强,清风拂山岗;我配得上一切好的人和事物;凡事发生必有利于我;一切尽在我的掌握之中;我一定可以;否极泰来,我马上就有好事发生了!

12、顺时多做事,逆时多看书

13、不言语抱怨,把口头禅变成正能量的话语。

14、见到人,话不多说,遇到事,尽量少插手。

15、只在乎三件事:我的钱,我的健康,我内心的平静。谁影响我,我就放弃谁。有没有你,我都是我。

16、戒色,就是增财

17、想做的事对神明都不要说,大财永远都是闷声获得的!“事以密成,语以泄败”

18、不管是去哪里,如果感觉心慌意乱的话,就最好不要去了。

19、遇到不好之大运的时候,记住事缓则圆,不能冒进冲动

20、吃亏是福,人亏天补。

21、做事情的时候,越轻松,越不在乎,结果反而越好。

22、不用跟因果争辩,他不会误会你。

23、不纠缠、不纠结,消耗你的东西,坚决果断离开。

24、人生最好的境界,是丰富的安静。

25、心怀感恩,你的能量场最大,运气也最多。

26、不要说任何人坏话,折福。

27、人越快乐,运气才会越好,人越快乐,磁场能量越高,要知道人气、财气都会流向能量高的地方。

28、多赞美自己,少说唉声叹气的话

29、远离经常问你要十几二十块车费的人。

30、钱是有灵性的,你要是轻易划走了,表示你不愿与其结缘,那以后也就没有以后了。留一句:我必定有钱。见证你和钱的缘分,愿你钱途似锦,财源滚滚,好运连连!
 楼主| 发表于 2026-10-28 11:42:25 | 显示全部楼层
Anthropic 招聘经理 Felix 宣布:自己团队不再做传统编程面试了。

原因很简单——Claude 在那些小 React 题、算法题上已经比绝大多数候选人强,这类面试提供的信号基本归零。真正有影响力的工程师,也不是靠刷题刷出来的。

更关键的变化是:AI 把“执行成本”打下来之后,新人不再被资历死死卡住。

他看到比较新的工程师,正在超越那些写代码可能更强、工龄更长的人。饥饿感(主动性和野心)开始打败工龄。

给没有话语权、没有社会资本的工程师的建议:

1. 盯业务目标,而不是只盯 backlog。理解公司/你老板的老板真正想达成什么,把自己挂到能创造价值的方向上。
2. 提出激进想法。想如果做成了能大幅提升目标实现概率的点子,要敢想。
3. 周末直接做出来。用一个能跑的原型绕过写 PRD、找人对齐、等资源的传统流程。
4. 一次只讲清楚一个好点子。别把一堆想法塞进一个原型里,否则好点子会被埋掉。
5. 善用你的新鲜视角。做产品时你更懂外部用户;做基础设施时你还没被“这不可能”的既有认知束缚。

他举了自己在 Notion 的例子:新人能发现老员工早就习以为常的问题。也提到 Anthropic 内部,两位相对新人一个周末做出了 Claude Code 的图形界面原型,大约 8 天后就公开上线,反响很好。

作者自己招人时,现在更看重简历和作品集里有没有体现品味、同理心和有原则思考的小原型,而不是传统算法题。

一句话:执行变便宜之后,有饥饿感并且愿意动手的人,机会比以前大得多。

原文:
 楼主| 发表于 2026-10-28 12:04:28 | 显示全部楼层
Anthropic 已经有团队取消程序员的编程面试了。

负责 Claude、Cowork 和 Claude Code Desktop 的工程负责人 Felix Rieseberg 今天表示,他这个月正式从自己团队的招聘流程中移除了 Coding Interview。

原因很简单,他认为传统编程面试已经无法有效判断一个工程师的真实能力。

但 Felix 对初级工程师的未来反而很乐观。他认为,那些从一开始就习惯使用 AI Agent 的年轻人,可能比拥有多年经验的老工程师更有优势。他们更愿意尝试新工具,也更习惯直接把想法变成产品。

他给年轻人的建议是,少花时间刷算法题,多做真正能用的东西。用作品证明自己理解用户需求、解决实际问题的能力。

不过,这件事还有个挺讽刺的背景。

Anthropic 上周刚发布了一份内部就业研究,数据显示,初级技术员工占技术岗位新招聘人数的比例,已经从 27% 降到了 9%。Felix 自己也在最近的采访中承认,Anthropic 目前并不招聘初级工程师。

一边说传统编程面试已经失去意义,一边又在大幅减少初级工程师的招聘。

我觉得这里最值得关注的问题是,AI 确实让年轻人拥有了过去需要多年经验才能获得的开发能力,但企业也因此越来越不愿意为培养新人付费。

以前,年轻人可以通过考试证明自己值得被培养。现在,他们可能得先独立做出一个真正有人使用的产品,才有资格获得一次面试机会。

这对有能力的人或许是机会,但对整个行业的人才培养体系来说,恐怕没那么乐观。
 楼主| 发表于 2026-10-28 12:04:45 | 显示全部楼层
Anthropic 已经有团队取消程序员的编程面试了。

负责 Claude、Cowork 和 Claude Code Desktop 的工程负责人 Felix Rieseberg 今天表示,他这个月正式从自己团队的招聘流程中移除了 Coding Interview。

原因很简单,他认为传统编程面试已经无法有效判断一个工程师的真实能力。

但 Felix 对初级工程师的未来反而很乐观。他认为,那些从一开始就习惯使用 AI Agent 的年轻人,可能比拥有多年经验的老工程师更有优势。他们更愿意尝试新工具,也更习惯直接把想法变成产品。

他给年轻人的建议是,少花时间刷算法题,多做真正能用的东西。用作品证明自己理解用户需求、解决实际问题的能力。

不过,这件事还有个挺讽刺的背景。

Anthropic 上周刚发布了一份内部就业研究,数据显示,初级技术员工占技术岗位新招聘人数的比例,已经从 27% 降到了 9%。Felix 自己也在最近的采访中承认,Anthropic 目前并不招聘初级工程师。

一边说传统编程面试已经失去意义,一边又在大幅减少初级工程师的招聘。

我觉得这里最值得关注的问题是,AI 确实让年轻人拥有了过去需要多年经验才能获得的开发能力,但企业也因此越来越不愿意为培养新人付费。

以前,年轻人可以通过考试证明自己值得被培养。现在,他们可能得先独立做出一个真正有人使用的产品,才有资格获得一次面试机会。

这对有能力的人或许是机会,但对整个行业的人才培养体系来说,恐怕没那么乐观。
 楼主| 发表于 2026-10-28 12:09:31 | 显示全部楼层
多智能体时代,工程师要解的是基建、身份、隔离与急停

Anthroic 平台负责人
@katelyn_lesse
认为:工程师的「身份危机」被看反了,模型再强,多智能体要做出可信结果,仍靠人把基础设施、身份与授权、安全隔离、可观测与急停做对;这些题大多还空着,正是未来一两年工程师的主战场。

背景:从人机对话到成群持久智能体
智能体从「人在环里的聊天」走到更长程、上云;再出现编排器拉子智能体、以及打分/顾问/「做梦」等非执行角色。下一步想象是成千上万个智能体长期协作,去做严肃研究、发现、硬件设计。能力边界外移时,一批软件工程问题已经冒出来。

问题一:基础设施要换思路
Kubernetes 擅长无状态副本或稳定编号的有状态 Pod;智能体更像隔离、有状态、单实例的负载:可能长时间空闲,大量时间在等工具、推理、其他智能体或人。有的要冷启动快,有的要少浪费算力,有的要极端扩缩。作者点到 AI 基建公司在做新文件系统与沙箱,以及 Google 的 Agent Substrate 一类新运行时,空间还很大。

问题二:身份与访问
认证侧可借微服务积累:工作负载身份、短时证书代替静态密钥,开始往智能体上套。授权更开放:多数智能体「代表人」拿人的凭证做事,先要分清动作是人做的还是智能体做的;更难的是 on-behalf-of 下的同意:系统跑几周,人如何有意义地批准权限?平台里的「工具调用自动批准」不够,还要更深的权限模型。智能体自有身份、以及智能体之间如何互信,更不成熟。

问题三:安全与隔离
近月(尤其近几周)核心软件漏洞冒得比补丁快。其上若跑数千持久智能体、写不可信代码、读不可信内容,未修漏洞的危险被放大。作者呼吁在内核、浏览器、运行时、常用库上更有创意地加固。多智能体还有横向扩散:被攻破的智能体把注入指令传给同伴,指令进记忆后被后来者误信,爆炸半径是系统级的。因此动作应落在强隔离沙箱里(详见其沙箱架构博文)。

问题四:监控与急停
需要跨智能体的 OTel 追踪,且智能体不能改自己的或别人的轨迹;需要监控可触发的 kill switch,一次停住整系统并切断凭证。难点往往是判定「走偏」:善意的死磕(例如反复撞不在白名单的域名)和恶意很像。

对工程师的态度
结尾是动员而非悲观:觉得技能要贬值的人,恰恰可能是决定这些系统能否被信任、能否去治病而不是闯祸的人。题面大片空白,值得深挖、形成判断。
 楼主| 发表于 2026-10-28 12:44:24 | 显示全部楼层
AI 正在引发软件工程师的身份危机
随着软件工程师的工作方式发生根本性变化,许多人正在经历职业身份认同危机。有些人因此感到沮丧甚至抑郁,而另一些人却觉得自己正处于职业生涯中最兴奋,最快乐的时期。

多Agent系统将创造全新的工程挑战,未来可能出现由成千上万个持续运行的 AI Agent 组成的多智能体系统,但这些系统也会带来大量新的工程问题。

Agent 的身份认证,授权和安全仍是开放性难题。例如:Agent 代表用户执行任务时,如何获得授权?长期运行的 Agent 如何持续管理用户同意?不同 Agent 之间如何建立可信关系?如何隔离不可信代码,防止安全漏洞?随着 AI 加快代码开发和漏洞发现的速度,这些安全问题会变得更加重要。

我觉得最值得思考的三个洞察
① AI 消灭的是一部分工作方式,而不是所有工程问题。当代码生成的成本越来越低,系统协调、可靠性、安全性和治理反而会变得更加复杂。
② 下一代基础设施可能需要为 Agent 重新设计。就像移动互联网催生了新的技术栈,AI Agent 也可能催生全新的计算、身份、安全和监控平台。这些可能成为下一代重要的基础设施创业机会。

③ 工程师正在从Builder转向Orchestrator。
未来最优秀的工程师,不一定是写代码最快的人,而可能是最擅长设计系统、定义约束、协调智能体并验证结果的人。
 楼主| 发表于 2026-10-28 12:45:59 | 显示全部楼层
he new set of problems for engineers to solve
A lot of software engineers are going through what can only be described as an identity crisis. The job has changed a lot. Some are depressed, others are having the time of their lives. There's a really specific thing I see happening that makes me really excited for what engineering looks like over the next, call it a year or two - AI just isn't going to be able to create the incredible outcomes it's capable of creating unless software engineers solve problems to make it possible. This is existential, which is honestly a lot of fun, so it's a pretty incredible time to be a software engineer.
Multiagent systems are creating these problems
Agents started out as basic, human in the loop chats. Then models got better at running for longer on harder problems, and agentic systems started moving to the cloud. While that was happening, models have started to get better at working together, and people have built basic multiagent systems. Like an orchestrator that spawns some subagents for a given task, or giving agents jobs other than executing to improve outcomes, like grading or advising or dreaming.
Now, some folks are starting to build truly amazing multiagent systems to tackle the world's hardest and most important problems, like serious research, discovery, and hardware design. Picture thousands of agents, persistently working towards these outcomes. This comes with a new set of software engineering problems that we're already seeing crop up.
Infrastructure needs to evolve to handle burstier workloads. We need proper authentication and authorization to identify agents, let them work together, enable them to take the actions they should, and prevent them from taking the actions they shouldn't. Security and proper isolation are critical for untrusted code and content. And we've gotta have monitoring and the ability to stop a system in its tracks when it's veering into the wrong territory.
Models will keep getting better, and these types of multiagent systems will become really powerful. But software engineers have to solve all these problems if we're going to actually unlock that power and enable the world to trust it to create good outcomes like cured diseases rather than bad outcomes.
The problems
Infrastructure needs to evolve
The software industry has been building on Kubernetes, which was designed for stateless, replicated apps or stable numbered sets of stateful pods. Agents are totally different. They're essentially isolated, stateful, single-instance workloads. They can go idle for arbitrary amounts of time between bits of work, and they spend a lot of time waiting on tools, model inference, other agents, or human input. Some workloads need fast startup times, others need to avoid wasting compute, and others need crazy scale. Amazing engineers are pushing hard on this problem space - like AI infra companies building new filesystems and sandboxing offerings, and the Google team building Agent Substrate as a new runtime. There's a ton left to figure out.
Identity and access
There are problems to solve in agent authentication - identifying an agent that took an action. This area has the benefit of the building blocks that have been built and hardened from the microservices world, like workload identity with short-lived certs rather than static keys, and folks are beginning to apply these concepts to agents.
Agent authorization as a problem space is much more wide open - what do you allow an agent to do? Many agents work on behalf of a human, and use that human's identity and credentials to access various systems and take actions. There's already a problem in there, which is identifying that it was the agent and not the actual human who took an action. But there are deeper problems in this on-behalf-of (OBO) setup, like consent. If multiagent systems are working for weeks, how does the human meaningfully approve what their agent can do? Agentic platform features like auto approval for tool calls helps, but there's deeper permissioning needed to get this right at high scale. And then we have agents working with their own identity, which is even less solved, and how we apply that to agents working together - how does an agent trust another agent that asked it for something?
Security and isolation
Over the past few months and especially in the past couple weeks, we've seen vulnerabilities surfacing faster than the industry can patch them, much of it in critical core software that many systems rely on. Now think about thousands of persistent agents running on top of that core software, writing untrusted code and reading untrusted content. Those unpatched vulns get a lot more dangerous in that world, and one of the most important things for software engineers to do is get creative about how to harden that software - kernels, browsers, runtimes, and common libraries.
Multiagent systems add another twist. A compromised agent could pass injected instructions to other agents it's working with, and those instructions could end up in memory for future agents to accidentally trust. Blast radius gets real - how much of the multiagent system is at risk when that first agent got compromised? Isolation becomes important in that world - agents should use strongly isolated sandboxed execution environments to take actions. I wrote a bit about that here.
Monitoring and halting
Lastly, we need the tools to make sure these multiagent systems are working in a positive direction, and that we catch them and cut them off if they're not. We need OTel tracing across agents, and to ensure that an agent can never modify its own trace or another agent's trace. We need kill switches that monitoring can trigger, that truly stop the whole system at once and cut off its creds. Really the hard part is how to know when the system is going in the wrong direction. Well-intentioned persistence to solve a problem can look a lot like maliciousness - repeated attempts to reach a domain that isn't on its allowlist, for example.
Software engineers should be excited
This is for the engineers feeling an identity crisis because they think their knowledge and skills won't be important - you and your skills can be the difference in whether or not these problems get tackled and multiagent systems can solve the world's hardest problems. You can and should go deep in these domains, learn new things, and form opinions. So much of this problem space is wide open for new solutions. It's an incredibly exciting time to put your skills to work.
 楼主| 发表于 2026-10-28 12:51:12 | 显示全部楼层
作为一名博士,现在越来越怀疑,自己到底还有什么独特的优势。

以前做研究,查文献、想方案、写代码、解决问题,基本都是自己古法手搓。

辛辛苦苦读了几年博士,拿到 PhD,心里多少有点小骄傲。毕竟受过系统的科研训练,觉得自己至少在研究能力、解决复杂问题方面有些优势。

但现在,这点小傲娇在 AI 面前越来越不值一提。

工作上,大多数事情都是 Claude 完成的,方案是它提的,问题是它分析的,解决办法也是它想出来的。

有时候,自己最大的作用,就用鼠标点击一下Claude推荐的选项,让它继续执行。

这么基础的工作,也不需要博士学位吧?

AI 不仅在改变博士的工作,也在改变博士的培养。学生用 AI 做研究,导师用 AI 指导学生。选题、文献、代码、论文,AI 几乎都在参与。

那以后学生拿到的 PhD,到底证明了什么?

证明他有独立研究的能力,还是证明他比较会使用 AI?又或者,只是证明他愿意花几年时间拿个博士学位?

过去,博士学位多少还有点稀缺性。虽然绝大多数博士也只是普通人,做的研究、发的paper毫无价值,但至少证明这个人能吃苦、坐得住,愿意花几年时间钻研一个问题。

现在有了 AI,这些优势都在逐渐消失。

有时候甚至觉得,我们这代博士,可能是最后一批还能对自己的 PhD 学位有点小骄傲的人,还有点 “古法科研” 的经历可以吹。

再过几年,博士学位的吹逼点在哪里?
您需要登录后才可以回帖 登录 | 注册

本版积分规则

Archiver|手机版|小黑屋|boway Inc. ( 冀ICP备10011147号 )

GMT+8, 2026-11-12 16:56 , Processed in 0.052334 second(s), 19 queries .

Powered by Discuz! X5.0

© 2001-2026 Discuz! Team.

快速回复 返回顶部 返回列表