这篇解决的问题是：当 AI 应用门槛骤降，软件工程师如何理解「AI Engineer」这个新身份的边界与机会。

最值得拿走的是三组判断：一是应用层与研究层的分野——API 另一侧的工程师应当把产品特定的数据与评测当作本职，而不是把自己当成半个研究员；二是「先开火，再瞄准」——提示式原型把产品验证成本压低几个数量级，这是 AI 时代的敏捷；三是代码的回归——Software 3.0 不是把人写代码淘汰掉，而是重新确立编排与验证的地位。最容易误读的是把 AI Engineer 等同于提示词技巧，文章明确指出评测、数据与工具链才是专业护城河。

中文读者要读这篇，因为它是「AI Engineer」一词的出处文献，今天国内招聘与社区讨论中的这个头衔都可溯源至此。国内语境要叠加两点：岗位市场对「应用层」与「交付层」的划分比硅谷更模糊，且 2023 年文中的薪资与融资数字已需按当前行情重新校准。

读完建议做一件事：对照文中的挑战清单（模型、工具、研究）盘一遍自己的技能缺口，把评测能力列为下一项投入。

—— FDEChina编辑部 · 实战派

我们正在观察一代人一遇的应用 AI「右移」（shift right），其燃料是基础模型（Foundation Models）的涌现能力与开源/API 可得性。

2013 年需要 5 年时间和一整支研究团队才能完成的各类 AI 任务，到 2023 年只需要一份 API 文档和一个空闲的下午。

重要提示：API 这条线是可渗透的——AI Engineer 可以向左走去做微调、托管模型，研究工程师也可以向右走基于 API 做构建！这张图也曾因评测（evals）与数据的位置而受到批评；我们完全同意评测是这份工作的重要组成部分！机器学习研究员/机器学习工程师（MLR/MLE）负责基础模型层面的事务——也就是预训练规模的数据与通用基准评测；但 AI Engineer 当然应该把产品特定的数据与评测视为自己的本职工作。

「从数量上说，AI Engineer 很可能会明显多于机器学习工程师 / LLM 工程师。一个人在这个角色里完全可以做得非常成功，而从头到尾不训练任何东西。」——Andrej Karpathy

然而，魔鬼藏在细节里——在成功评测、应用和产品化 AI 的道路上，挑战层出不穷：

  • 模型：从评测最大的 GPT-4 与 Claude，到最小的开源 Huggingface、LLaMA 及其他模型
  • 工具：从最流行的链式编排、检索与向量搜索工具如 LangChain、LlamaIndex、Pinecone，到 Auto-GPT、BabyAGI 等新兴的自主 Agent 领域（Lilian Weng 写过一篇必读综述）
  • 研究/进展：除此之外，每天发表的论文、模型与技术的数量正随着关注和资金的涌入呈指数级增长，以至于跟上这一切几乎是一份全职工作。

我对这句话既认真又按字面意思理解。我认为它就是一份全职工作。我认为软件工程会催生一个新的子学科，专门研究 AI 的应用、并有效驾驭这套新兴技术栈，正如当年「站点可靠性工程师（SRE）」「DevOps 工程师」「数据工程师」「分析工程师」的相继出现。

这个角色正在成型的各种名字里，最不让人尴尬的一个似乎是：AI Engineer（AI 工程师）。

我认识的每一家创业公司都有某种 #discuss-ai 的 Slack 频道。这些频道会从非正式小组变成正式团队，Amplitude、Replit 和 Notion 已经这样做了。成千上万正在把 AI API 和开源模型推向生产的软件工程师——无论用的是公司时间还是夜晚与周末，无论在公司 Slack 里还是在独立开发者的 Discord 里——将会专业化并汇聚到一个头衔上：AI Engineer。这很可能是这十年需求最高的工程岗位。

从微软、谷歌这样最大的公司，到 Figma（通过收购 Diagram）、Vercel（比如 Hassan El Mghari 爆火的 RoomGPT）、Notion（比如 Ivan Zhao 和 Simon Last 做的 Notion AI）这类前沿创业公司，再到 Simon Willison、Pieter Levels（Photo/InteriorAI 的作者）、Riley Goodside（现在 Scale AI）这样的独立黑客，AI Engineer 无处不在。有人在 Anthropic 做提示工程（prompt engineering）年薪 30 万美元，有人在 OpenAI 做软件年薪 90 万美元。他们在周末泡在 AGI House 闷头做创意，在 /r/LocalLLaMA 交流心得。他们的共同点是：把 AI 的进展塑造成数百万人在用的真实产品，而且几乎是一夜之间。

全场看不到一个博士。要做 AI 产品，你想要的是工程师，不是研究员。

AI Engineer 与 ML Engineer 的「权力交替」

我是在为一个已经发生的趋势正名，而不是发起它。在 Indeed 上，机器学习工程师的职位数量是 AI Engineer 的 10 倍，但「AI」更高的增速让我预测：这个比例会在 5 年内反转。

所有职位头衔都有缺陷，但有些是有用的。我们对 AI 与 ML 之间无休止的语义之争既警惕又疲惫，也清楚普通「软件工程师」岗位完全有能力构建 AI 软件。但 Hacker News 上一个题为「如何转行做 AI 工程」的提问说明，市场中仍然存在一种根深蒂固的认知：

大多数人仍然把 AI 工程视为机器学习或数据工程的某种形式，于是推荐同样的先修路径。但我敢保证，上面点名的那批高效 AI Engineer，没有几个人做过吴恩达 Coursera 课程同等强度的功课，不会 PyTorch，也说不清数据湖（Data Lake）和数据仓库（Data Warehouse）的区别。

在不久的将来，不会有人再建议你从读《Attention is All You Need》开始学 AI 工程，就像你不会靠研读福特 T 型车的图纸来学开车。当然，理解基本原理和历史总有帮助，也确实能帮你发现尚未进入大众认知的想法和效率/能力增益。但有时候，你完全可以直接上手用产品，在经验中理解它们的性质。

我不指望这场课程体系的「权力交替」一夜发生。往简历里塞东西、往市场地图里填格子、靠引用更深奥的话题来彰显权威，是人的天性。换句话说，在很长一段时间里，提示工程和 AI 工程会在拥有扎实数据科学/ML 背景的人面前显得低人一等。但我相信，纯粹的供需经济学终将占上风。

为什么 AI Engineer 恰在此刻涌现

如果这个角色注定出现，为什么是现在？答案不是单一原因，而是多重条件在同一时间窗口内同时成熟：模型能力溢出到研究圈之外，算力与人才被封装成可租用的服务，开发者的工作流从「先收集数据再建模」倒转为「先做原型再补数据」，工具生态跨出了 Python 单一社区，应用形态也与上一代机器学习彻底分道扬镳。以下五条原因，每一条都在独立地推高对 AI Engineer 的需求。

基础模型是「少样本学习器」

基础模型是「少样本学习器」（few-shot learners），表现出上下文内学习（in-context learning）甚至零样本迁移（zero-shot transfer）能力，其泛化范围超出了模型训练者的原始意图。换句话说，创造模型的人并不完全知道模型能做什么。非 LLM 研究者的人，仅靠花更多时间和模型相处、把它们应用到被研究界低估的领域（比如 Jasper 之于文案写作），就能发现并利用这些能力。

研究人才被「云端出租」

微软、谷歌、Meta 以及各大基础模型实验室把稀缺的研究人才聚拢起来，本质上是在交付「AI 研究即服务」的 API。你雇不到他们，但可以租用他们——前提是你在 API 的另一端有懂得如何与之协作的软件工程师。全世界约有 5000 名 LLM 研究者，却有约 5000 万软件工程师。供给约束决定了一个居间的「AI Engineer」阶层必然崛起以满足需求。

GPU 囤积

当然，OpenAI/微软是第一个这么干的，但 Stability AI 强调自己拥有 4000 张 GPU 的集群，点燃了创业公司的 GPU 军备竞赛。还记得 2022 年 10 月吗？

从那以后，Inflection（13 亿美元）、Mistral（1.13 亿美元）、Reka（5800 万美元）、Poolside（2600 万美元）、Contextual（2000 万美元）这类新创业公司融巨额种子轮来拥有自己的硬件，已成常态。Dan Gross 和 Nat Friedman 甚至宣布了 Andromeda——一个 1 亿美元、10 exaflop 的 GPU 集群，专供他们投资组合里的创业公司使用。全球芯片短缺正在条件反射式地制造更多短缺。在 API 线的另一侧，AI Engineer 将拥有远多得多的算力去使用模型，而不是训练模型。

先开火，再瞄准

传统做法是：数据科学家/机器学习工程师先做一场费力的数据收集运动，再训练一个特定领域的模型，然后投入生产。而现在，产品经理/软件工程师可以先提示一个 LLM，把产品想法构建出来、验证掉，之后再为微调去搞特定数据。

假设后者的人数是前者的 100-1000 倍，而「先开火再瞄准」的提示式 LLM 原型工作流让你比传统 ML 快 10-100 倍，那么 AI Engineer 验证一个 AI 产品的成本可以便宜 1000-10000 倍。这是瀑布 vs 敏捷的剧情重演。AI 就是敏捷。

Python + JavaScript

数据/AI 领域传统上极度以 Python 为中心，LangChain、LlamaIndex 和 Guardrails 这些最早的 AI 工程工具也出自同一个社区。然而 JavaScript 开发者的数量至少与 Python 相当，所以现在工具正在迎合这个大幅扩张的受众：从 LangChain.js、Transformers.js，到 Vercel 新推出的 AI SDK。可触达市场（TAM）和机会至少扩大了 100%。

生成式 AI vs 分类器式 ML

「生成式 AI」这个词已经有点过气，让位于「推理引擎」之类的类比，但它仍然简洁地说清了既有 MLOps 工具与 ML 从业者群体，和正在崛起的、截然不同的那类最擅长驾驭 LLM 与文生图模型的人物画像之间的区别。上一代 ML 关心的是欺诈风险、推荐系统、异常检测和特征商店（feature store），而 AI Engineer 在做的是写作应用、个性化学习工具、自然语言电子表格，以及类 Factorio 的可视化编程语言。

每当一个子群体拥有完全不同的背景、说着不同的语言、产出一套完全不同的产品、使用一套完全不同的工具时，他们最终都会分裂成自己的群体。

把这五条原因放在一起看，就能理解为什么这个角色的出现几乎不可逆转：模型能力的溢出提供了可能性，算力与 API 把稀缺研究变成了普惠供给，工作流倒转降低了入行门槛，语言生态扩容了候选人才池，而应用形态的差异则给了这个群体独立成军的身份认同。供给、需求与组织认同三者齐备，剩下的只是时间问题。

1+2=3：代码的角色——从 Software 2.0 到 Software 3.0

6 年前，Andrej Karpathy 写过一篇影响深远的长文描述 Software 2.0：一边是精确建模逻辑的手写编程语言「经典技术栈」，一边是近似逻辑的「机器学习」神经网络新栈，它让软件能解决远超人工建模能力的问题。到了 2023 年，他指出最热门的新编程语言是英语，终于把他那张图里当初留白的灰色区域填上了——从 Software 2.0 迈向某种……宽泛得多的东西。

更新：Andrej 回应了！还带着一点不同意！

去年，当人们开始把 GPT-3 和 Stable Diffusion 投入工作时，提示工程是关于「工作将如何改变」的流行答案。人们讥讽 AI 创业公司是「OpenAI 套壳」，担忧 LLM 应用容易被提示注入（prompt injection）和逆向提示工程攻破。护城河在哪里？

但 2023 年最大的主题之一，恰恰是重新确立人写代码在编排与替代 LLM 能力上的地位：从估值超 2 亿美元的庞然大物 LangChain，到英伟达投资的 Voyager 所展示的代码生成与复用的巨大重要性（我最近参加了与 Harrison 的 Chains vs Agents 线上研讨，展开讨论了「Code Core vs LLM Core」应用这篇论点）。

最根本的架构分野是：「智能之上的软件」vs「智能化的软件」。

提示工程既被过度炒作、又会长期存在，而 Software 1.0 范式在 Software 3.0 应用中的回归，既是巨大的机会/混乱之源，也为一大批创业公司留出了空白地带——不画市场地图的 VC 是不存在的。

当然，不会只有人写的代码。我近期折腾的 smol-developer、更大格局的 gpt-engineer，以及 Codium AI、Codegen.ai、Morph/Rift 等代码生成 Agent，会越来越多地进入 AI Engineer 的工具箱。当人类工程师学会驾驭 AI，AI 也会越来越多地去做工程，直到遥远的某一天，我们猛然发现已分不清彼此。

是时候汇聚了——AI Engineer Summit

建造者需要一个聊聊「松节油」的地方。正因如此，在组织了几个月小型聚会之后，我们现在宣布首届独立举办、面向建造者的 AI 大会：AI Engineer Summit！

如果这篇文章里的一切都让你共鸣，我们的目标是把最顶尖的 AI Engineer、创始人和投资人聚到一起：了解最前沿的进展，参加/开设工作坊，找到他们将在工作中用上的牛工具、下一位新同事/联合创始人/下一轮融资。

这是讨论本 newsletter 与播客过去一年覆盖的一切议题的权威大会，包括：

  • AI UX
  • AI 开发者工具
  • AI 基础设施
  • AI Agent
  • 新的 LLM 工具，包括 LangChain、向量数据库等
  • 开源模型（训练、微调、推理、评测）

我运营社区的经验不少，但从没办过 500 人的大会，所以我与 Reactathon 的 Ben Dunphy 联手，要在旧金山（以及线上——他上一场大会有 2 万多人远程观看）办出最好的 AI Engineer 大会。

来 ai.engineer 参加吧！我们同时接受讲师议题征集（CFP）与赞助商（欢迎联系我们）。

我们是建造者

敏锐的读者会注意到，我们已经逐渐把 Latent Space 播客与 newsletter 调整为服务 AI Engineer 这个人物画像。服务这个受众最让我兴奋的，是技术乐观主义与务实精神的结合。Marc Andreessen 最近写道，绝大多数公开的 AI 话语都是「歇斯底里的恐惧与偏执」，并指出有一整个以「AI 安全专家」「AI 伦理学家」「AI 风险研究员」为职业、拿钱唱衰的群体，却没有对应地位的建造者与加速者角色。而光谱的另一端，又有许多不认真的加速主义者和令人生厌的「奇点推友」，整天在 Twitter 上谈论遥远的乌托邦未来，却说不清他们为把它变成现实做了什么。

AI Engineer 会驯服并骑上 Shoggoth（克苏鲁式的大模型隐喻）。

让我们把这件事做成。

感谢 HN 和 Twitter 上大量的评论与提问！我们临时组织了一场 Twitter Space 展开讨论，超过 1000 名 AI Engineer 收听。《AI Engineer 的崛起》也在其他播客中获得了讨论。

作者附注：我特别感谢我的搭档、Decibel 的 Alessio Fanelli，以及 Conviction 的 Sarah Guo 和 Pranav Reddy，他们审阅了本文草稿并给出了关键反馈与宝贵支持。当然还有 Ben Dunphy，谢谢他同意联合创办 AI Engineer 大会系列与社区网络。谢谢你们！

小结与下一步

回看这篇写于 2023 年年中的文章，它对后来三年的预测大体应验：AI Engineer 成为招聘市场上真实存在且持续扩张的头衔，评测与数据被公认为应用层的本职工作，「代码在 AI 应用中的地位」成为核心架构议题。对中文读者而言，最有行动价值的判断有三条：一是应用层的供需缺口远大于研究层，入门不必从读论文开始；二是「先开火再瞄准」的提示式原型工作流把验证成本压低了几个数量级，值得每个团队立即采用；三是评测与数据管线是 AI Engineer 区别于「调提示词的人」的专业护城河。

下一步，建议你结合站内的 FDE 能力模型审视自己的技术栈位置，并在 AI Coding 专题中继续跟踪工具与工作流的演进。

注释

1. 曾考虑过的替代名：「Foundation Model Engineer」「AI API Developer」「LLM Engineer」，但都不够顺口；「Prompt Engineer」对我们正在成形的 Code Core、LLM Shell 形态来说又太局限。还有「MLOps Engineer」，但这是一个历史悠久的成熟社区，传统上关注更底层的 ML 事务——这一区别本文后面会讨论。最后，「AI Tinkerer」因 Alex Gravely（有争议的 Copilot 创造者）而流行，可惜不像一个正式头衔。

2. 我完整的 AI 播客、newsletter 与社区清单维护在 GitHub 上。

3. 而且多半没法在白板上讲清楚 transformer 的原理。

4. Stability 与 AWS 在集群上的关系一直有争议，最好听 Emad 本人怎么说。

5. 我正在为他们俩琢磨数字缩写。g12n？

6. 更准确地说，这是一场英伟达芯片短缺。这正是 George Hotz 的 Tinycorp 重要的原因——它让流行的开源模型能在 AMD 显卡上运行。Mosaic 的 LLMFoundry 也报告了 AMD 兼容性。

7. 还有，谢天谢地，「Gen AI」。

8. 当然，当一个人能把两个学科都玩得很好时，就会得到 Character.ai 这样的离群值——它由 Transformer 论文的共同作者之一创立，却为 LLM 的生成能力找到了绝妙用途。

延伸阅读：想继续了解这个角色与技能体系，可阅读站内 AI Coding 专题与 Agent 专题；关于工程角色的能力框架，参见 FDE 能力模型；更多实践方法可浏览 FDE 实践指南。

本文由 FDEChina 团队翻译自原文，转载已注明出处；如需引用请以原文为准。