AI

这两年很多同学在准备测试开发、后端开发、AI 应用工程、LLM 工程相关岗位时，都会遇到一个很现实的问题：

我知道“大模型很火”，也知道 RAG、Agent、Prompt、评测这些词经常出现在 JD 里，但如果真让我说“应该学什么”，脑子里还是有点散。

有人会担心：

• 是不是必须去学机器学习底层理论
• 是不是一定要会训练模型
• 是不是要先啃很多论文

如果你的目标更偏 AI 应用、LLM 工程、Agent 应用落地方向，我先说结论：

大多数情况下，不需要一上来就把自己培养成算法研究员。

企业更需要的，往往是下面这种能力组合：

• 会接模型 API
• 会做一个可运行的 AI 应用
• 理解 RAG 和 Agent 的基本工作方式
• 知道怎么做工程化落地
• 知道怎么评估效果、怎么持续迭代

这篇文章就系统讲一下，如果你未来想做更偏 AI 应用、LLM 工程、Agent 应用的方向，最值得优先补的能力到底有哪些，以及每一块应该学到什么程度。

---

一、先明确：AI 应用方向到底在做什么

和传统的算法岗、大模型训练岗相比，AI 应用方向更偏：

• 模型能力接入
• 产品功能落地
• 工程系统搭建
• 质量评估和效果迭代

说得更直白一点：

训练模型的人更关心：

• 参数量
• loss
• 训练策略
• 对齐方式

而做 AI 应用的人更关心：

• 这个功能能不能上线
• 响应快不快
• 成本高不高
• 回答稳不稳
• 检索准不准
• 用户体验好不好

所以如果你走 AI 应用、LLM 工程、Agent 工程方向，学习重点通常不是“底层训练”，而是“应用能力 + 工程能力 + 评测能力”。

---

二、第一块：模型 API 使用

这是最基础、也是最先应该补的一块。

因为你要做 AI 应用，首先得会和模型打交道。

1. 为什么模型 API 是起点

很多人一开始学习 AI 应用，会把注意力放在各种新概念上，比如：

• Prompt 工程
• RAG
• Agent
• 工作流

但这些东西真正跑起来的前提，是你要先会：

• 调模型
• 接返回
• 处理上下文
• 处理错误

如果连最基本的模型调用都不熟，后面很多能力其实是空中楼阁。

2. 至少要熟悉哪些能力

建议你至少熟悉下面几种能力。

chat

这是最基础的对话调用方式。

你需要知道：

• 什么是 system prompt
• 什么是 user message
• 什么是 assistant message
• 多轮对话历史怎么传
• 长对话为什么会越来越贵、越来越慢

这部分是所有 AI 应用的基本盘。

embedding

很多人刚开始学 AI 应用时，会忽略 embedding，但它在 RAG 里几乎是核心角色。

你至少要知道：

• embedding 是把文本变成向量表示
• 向量的作用是让机器能计算语义相似度
• 为什么 RAG 不是直接拿原文去比，而是先向量化

不需要一开始就深究所有数学细节，但要理解它的工程用途。

流式输出

也就是用户边看边出字的那种体验。

这部分为什么重要：

• 直接影响用户体验
• 可以显著降低“用户觉得很慢”的感觉
• 很多聊天类产品都需要支持

你至少要理解：

• 流式输出和一次性返回的区别
• 前端和后端如何配合处理流式内容
• 流式输出时错误怎么处理

tool calling / function calling

这部分在 Agent 应用里非常关键。

它的核心不是“模型更聪明”，而是：

模型不只会生成文本，还能决定什么时候调用外部工具。

比如：

• 查天气
• 查数据库
• 调内部接口
• 发邮件
• 调日历

这意味着模型从“回答问题”变成了“决定下一步动作”。

3. 模型 API 学到什么程度算够用

我建议至少做到下面这几个层次：

入门层

• 能调通一个 chat 接口
• 能传 system prompt
• 能拿到模型返回结果

进阶层

• 能做多轮对话
• 能做流式输出
• 能处理超时、重试和限流

实战层

• 能调用 embedding
• 能接 function calling
• 能把模型能力接进自己的服务

4. 项目里最常踩的坑

这一块最常见的问题包括：

• 上下文越传越长，成本越来越高
• 错误处理没做好，模型调用一失败整个服务就挂
• 没做重试和超时处理
• 只会本地调通，不会接服务层

所以如果你在学模型 API，不要只停留在“会写一个 demo”，要尽量往“可运行的小服务”方向走。

---

三、第二块：RAG 基础

RAG 几乎是 AI 应用方向最常见的落地场景之一。

很多企业做 AI，不是做纯聊天，而是做：

• 知识库问答
• 企业文档问答
• 内部 SOP 助手
• FAQ 机器人
• 面向业务文档的问答系统

这些场景里，RAG 出现得非常频繁。

1. RAG 是什么

RAG 可以简单理解成：

先检索相关知识，再把检索结果交给模型生成答案。

它解决的问题是：

• 模型本身知识可能过期
• 企业私有知识不在模型训练数据里
• 纯靠模型“猜”容易幻觉

所以 RAG 的目标不是让模型变更强，而是让模型“说话更有依据”。

2. RAG 里最值得先理解的关键词

chunk

chunk 可以理解成“切片后的文档块”。

为什么要切：

• 原文档太长，不能整篇直接丢给模型
• 检索时需要更细粒度

你要理解的重点不是切片语法，而是：

• 切太大，检索不精确
• 切太小，上下文可能不完整

这其实是一个效果和上下文成本的平衡问题。

embedding

前面提过，这里再强调一次。

在 RAG 里，embedding 的作用是：

• 把 chunk 转成向量
• 把用户 query 也转成向量
• 然后通过向量相似度找最相关内容

vector store

也就是向量库。

它的作用可以理解成：

存储所有文档向量，并支持相似度检索。

你不一定要一开始就熟悉所有向量数据库，但至少要知道它在 RAG 架构中的位置。

top-k

意思是：

• 检索时取最相关的前 K 条结果

为什么它重要：

• 取太少，容易漏信息
• 取太多，会引入噪声，反而让模型答偏

metadata

metadata 就是附加信息。

比如一段文档对应的：

• 标题
• 来源
• 文件名
• 时间
• 部门
• 文档类型

它为什么重要：

• 方便过滤
• 方便追溯来源
• 方便做更精准检索

rerank

rerank 可以理解成“重排序”。

一个常见流程是：

1. 先通过向量检索取回一批候选文档
2. 再用更强的相关性模型重新排序
3. 最后把更相关的结果送给大模型

它的意义在于：

• 提高召回结果的相关性
• 减少噪声

3. RAG 学到什么程度算够用

建议至少做到：

入门层

• 能讲清楚 RAG 的基本链路
• 能解释 chunk、embedding、vector store 的作用

进阶层

• 能自己做一个最小 RAG Demo
• 能导入文档、切分、索引、检索、回答

实战层

• 能分析效果不好时问题出在哪
• 能做 chunk 调整、top-k 调整、metadata 过滤
• 知道什么时候需要 rerank

4. RAG 最常见的问题

很多项目里 RAG 效果差，不一定是模型不行，而可能是：

• 切片策略不合理
• embedding 模型不合适
• 向量库过滤没做好
• query 改写不行
• top-k 取值不合理
• 召回结果噪声太多

所以面试里如果被问“RAG 为什么失败”，你千万不要只答“模型不准”。

更好的答法应该体现你知道这是一个完整链路问题。

---

四、第三块：Agent / 工作流基础

这是最近很热的一块，但也是最容易被“概念化”的一块。

很多人提 Agent 时，喜欢只讲愿景，却讲不清工程实现。

1. Agent 不是“会聊天”那么简单

如果只会问答，它还只是一个聊天模型。

Agent 的关键在于：

• 能理解目标
• 能决定下一步动作
• 能调用工具
• 能多步骤执行任务

所以 Agent 更像：

带有决策和执行能力的模型应用。

2. 先理解这几个基础概念

状态机

这是非常值得理解的一个概念。

因为很多 Agent 工作流，本质上都可以抽象成：

• 当前状态是什么
• 满足什么条件转到下一步
• 每一步要做什么动作

一旦你理解了状态机，就会发现很多 Agent 并不神秘，本质上是“模型决策 + 流程控制”的组合。

工具编排

Agent 不是自己什么都知道，它往往需要借助工具。

例如：

• 查数据库
• 调搜索接口
• 发消息
• 调内部系统 API

所谓工具编排，本质上就是：

• 什么时候用哪个工具
• 一个工具结果怎么传给下一个步骤
• 工具失败时怎么处理

多步骤任务执行

这点很重要。

很多实际业务任务并不是“一次调用就结束”，而是：

1. 解析用户意图
2. 查信息
3. 判断条件
4. 调多个工具
5. 汇总结果

这就是为什么 Agent 更像“工作流执行器”，而不是单次对话接口。

3. 学 Agent 应该学到什么程度

我建议：

入门层

• 能解释 Agent 和普通聊天的区别
• 知道 function calling / tool calling 的价值

进阶层

• 能做一个简单工具调用 Demo
• 能让模型调用 1 到 2 个外部工具

实战层

• 能把多步骤任务做成清晰的工作流
• 能处理失败重试、超时、状态回退

4. Agent 方向常见误区

很多人最大的问题是：

• 只会堆框架名
• 不理解状态流转
• 不理解错误处理
• 不理解工具失败时怎么办

所以学 Agent 时，不要只背：

• LangChain
• LangGraph
• workflow
• planner

更重要的是你能不能讲清楚：

这个系统一步一步是怎么跑起来的。

---

五、第四块：简单应用工程化

很多同学学 AI 应用时，容易停留在 notebook 或 demo 阶段。

但企业真正需要的，不是一个“本地能跑的样例”，而是一个“可以作为服务运行的应用”。

所以工程化非常关键。

1. 为什么工程化很重要

因为 AI 应用一旦进入真实项目，就会遇到下面这些问题：

• 怎么部署
• 怎么配环境变量
• 怎么记日志
• 怎么处理错误
• 怎么保证接口稳定
• 怎么和前端联调

这些问题如果不会，你就很难把一个 AI 能力真正做成产品功能。

2. FastAPI / Flask 为什么值得学

这两个框架很适合做 AI 应用原型和服务层。

你不一定要把它们学得非常深，但至少要能做到：

• 写一个 API 服务
• 接收请求
• 调模型
• 返回结果

FastAPI 尤其适合：

• 快速搭建服务
• 做接口文档
• 做异步接口

Flask 更轻量，也很适合做最小 demo。

3. Docker 为什么值得学

因为 AI 应用经常涉及：

• 依赖多
• 环境复杂
• 本地能跑，线上不一定能跑

Docker 的价值就是：

• 固定运行环境
• 方便部署
• 方便团队协作

你不需要一开始就非常深入 K8s，但至少建议会：

• 写基础 Dockerfile
• 构建镜像
• 运行容器

4. 环境变量为什么重要

AI 应用里最常见的敏感信息包括：

• API Key
• 数据库地址
• 向量库配置
• 模型服务地址

这些都不应该直接写死在代码里。

所以你要理解：

• .env
• 环境变量注入
• 不同环境配置切换

5. 日志与错误处理为什么必须重视

很多 AI 应用上线后的问题，不是“功能没有”，而是：

• 有时候慢
• 有时候报错
• 有时候答得不对
• 有时候工具调用失败

这时没有日志就很难排查。

所以至少要做到：

• 记录请求输入
• 记录关键处理步骤
• 记录模型调用耗时
• 记录异常信息

同时还要理解：

• 超时处理
• 重试策略
• 降级思路

6. 工程化学到什么程度算够用

建议至少做到：

• 能用 FastAPI 或 Flask 写一个小服务
• 能用环境变量管理 API Key
• 能写基础 Dockerfile
• 能记录日志并做错误处理

到了这个程度，你的 AI 应用已经不只是玩具了。

---

六、第五块：评测和观测

这是很多人最容易忽略、但企业最看重的一块。

因为 AI 应用最大的问题之一就是：

它不像传统接口那样“输入固定、输出固定”。

模型输出可能不稳定，也可能边界模糊，所以你必须学会怎么评估效果。

1. 为什么评测和观测很重要

如果没有评测，你就会遇到这些问题：

• 你不知道模型版本升级后是变好了还是变差了
• 你不知道 Prompt 调整有没有效果
• 你不知道用户投诉的问题是不是偶发个例

所以 AI 应用不能只靠“感觉”，要有评测和观察机制。

2. 什么是 bad case 集

可以把它理解成：

一组你已经知道容易出错的典型问题集合。

例如：

• 容易幻觉的问题
• 多轮对话容易丢上下文的问题
• 特定领域专业术语问题
• 特定格式输出容易错的问题

构建 bad case 集的意义是：

• 用来回归测试
• 用来对比不同模型
• 用来比较不同 Prompt

3. 如何做人工抽检

很多场景下，完全自动化评估并不现实，所以人工抽检很重要。

常见做法包括：

• 每轮上线前抽样检查
• 对高风险问题人工评分
• 针对核心业务问答重点复核

人工抽检不一定要很复杂，关键是要有：

• 抽检样本
• 评分标准
• 结果记录

4. 如何比较两个版本 Prompt 或模型效果

这是非常常见的实际问题。

比如你改了 Prompt，或者换了模型，你怎么证明它更好了？

至少可以这样做：

1. 固定一批测试问题
2. 分别跑版本 A 和版本 B
3. 从准确性、相关性、格式正确率、稳定性等角度对比
4. 记录 bad case 差异

这个过程本质上就是在做最小版本的评测体系。

5. 观测除了看结果，还要看什么

建议至少关注：

• 响应时间
• Token 消耗
• 错误率
• 工具调用成功率
• 用户反馈

因为一个 AI 应用，不仅要“答得像样”，还要：

• 够快
• 够稳
• 成本可控

6. 评测和观测学到什么程度算够用

建议至少做到：

• 会整理一批 bad case
• 会做人工抽检表
• 会比较两个 Prompt 或模型版本
• 会从准确率、稳定性、延迟、成本这几个角度去看效果

---

七、如果你要开始学，推荐的顺序是什么

如果你现在想开始补这条路线，我建议按下面顺序推进。

第一步：先学模型 API

先把：

• chat
• 流式输出
• embedding
• function calling

这些基础能力用起来。

第二步：做一个最小 RAG

不要一上来就追求复杂平台，先完成最小闭环：

• 导入文档
• 切分
• 向量化
• 检索
• 回答

第三步：做一个最小 Agent

例如：

• 查天气
• 查数据库
• 调内部 API

先让模型真的能“调用工具”。

第四步：把它服务化

用 FastAPI 或 Flask 把它做成 API 服务。

第五步：加评测和日志

至少补上：

• bad case 集
• 日志
• Prompt 对比
• 基础观测

如果你能走到这一步，已经比很多“只会说概念”的人强很多了。

---

八、写在最后

如果你未来想做更偏 AI 应用、LLM 工程、Agent 应用的方向，最值得优先补的，不是“最难的底层理论”，而是下面这五块：

1. 模型 API 使用
2. RAG 基础
3. Agent / 工作流基础
4. 简单应用工程化
5. 评测和观测

因为这五块拼起来，才是一个 AI 应用真正落地所需要的最小能力闭环。

如果用一句话总结，我会这样说：

训练模型的人在提升模型本身，做 AI 应用的人在把模型能力变成真正可运行、可评估、可迭代的产品。

而后者，恰恰是现在大量岗位最需要的能力。