当前位置：首页 > news >正文

后端转 AI 高薪岗知识地图：从基础到上岸，每一步学什么我都讲透

news 2026/8/13 4:17:39

后台天天有人问我：我是 Java/Go 后端，工作三五年，想转 AI，到底该学什么？从哪开始？学到什么程度才算够用？转过去能拿多少？

这个问题我前后回答了不下几百遍。今天不藏了，把「后端转 AI 高薪岗知识地图」完整版一次性整理出来——从基础认知、工程能力、项目实战、面试突围，到求职策略，每一步学什么、学到什么火候、踩过哪些坑，我尽量讲透。

先说句大实话：市面上 90% 的「转 AI 教程」都在教你调 API、跑通一个本地知识库，然后就没了。等你真去面试，面试官一问「你这个 RAG 上线后怎么灰度、成本怎么归因、bad case 怎么评测」，当场卡壳。这篇要解决的，就是这种「学了像没学」的尴尬。

建议先收藏，照着走，能帮你少走至少半年弯路。

先排三个最常见的坑

避开它们，你已经超过 90% 的转行选手。

误区一：把「学 Python」当成转 AI。 Python 只是工具语言，企业招的是能把 AI 落进业务、扛得住生产流量的人，不是会写脚本的。你本来就是后端，语言不是瓶颈，思维和工程能力才是。

误区二：只会调 API 就觉得会了。调个 GPT / 通义接口谁都会，值钱的是超时控制、重试、检索质量、效果评测、成本归因这些工程化能力。同样一个问答功能，Demo 版和能上线扛流量的版本，差着几个数量级的功夫。

误区三：没有真项目。简历写满「学习笔记」「跟着教程做的小项目」，没有一个能写进简历、扛得住深挖的生产级项目。面试官见多了，一眼就虚。

下面正式上地图。整张图分五关：基础认知 → 工程能力 → 项目实战 → 面试突围 → 求职策略。顺序别乱，前一关是后一关的地基。

第一关：基础认知——理解原理，但别当算法研究员

转 AI 不要求你手推 Transformer 公式、不发论文，但必须建立正确的心智模型。否则后面全是黑盒，出了问题你连往哪猜都不知道。

大模型到底是什么

本质是一句话：基于 Transformer 的自回归生成模型——吃一串 token，预测下一个 token，再把预测出来的 token 接在后面，继续预测，直到结束。

理解「生成式 = 不断预测下一个字」这件事，能帮你解释一大半现象：

幻觉：模型预测下一个 token 时，是按概率「编」出最可能衔接的内容，而不是在查数据库。它不知道什么是真、什么是假，只是让句子「读起来通顺」。
复读 / 循环：采样参数没调好，模型陷入高概率循环。
截断：输出长度到了上限，话没说完就被切了。

所以你跟模型说话，不是在「问一个答案」，是在「引导它把一段合理的话生成出来」。这个认知，决定了你后面会不会写出好 prompt。

Transformer 的直觉（不用推公式）

你只需要记住三件事：

自注意力（Self-Attention）：每个 token 在生成时，都会去「看」序列里其他所有 token，并给它们分配不同的关注度。这就是为什么模型能理解「它」指代的是前文哪个人。
位置编码（Position Embedding）：Transformer 本身不天然知道词序，靠位置编码告诉模型「谁在前谁在后」。这也是为什么打乱顺序，意思就变了。
预训练 ≠ 推理：模型在训练阶段把海量文本「压缩」成了参数里的知识；推理阶段只是用这些参数去生成。你后面做的 RAG、微调，都是在「推理阶段」给模型补上下文或改行为。

Tokenizer 与 token

模型不是按「字」也不是按「词」算的，是按 token。中文一般 1 个汉字 ≈ 1–2 个 token，英文一个词可能拆成多个 token。

为什么要关心这个？

计费：API 按 token 数收费，输入 + 输出都算。
长度限制：上下文窗口是按 token 算的，不是按字数。
截断风险：你塞了 10 万字文档，超过窗口就被切掉，模型根本看不到后半段。

主流模型怎么分层

闭源旗舰：GPT-4o / Claude / Gemini，能力强但贵，适合打样、做效果上限参考。
国产闭源：通义千问、DeepSeek、智谱 GLM，中文好、性价比高，是国内业务首选。
开源系列：Qwen、Llama、DeepSeek 开源版，可私有化部署，数据不出门。

后端转 AI，建议先把手感练在「闭源打样、开源兜底」的组合上：用闭源快速验证效果，用开源做私有化 / 降本。

Prompt 工程（你必须会，不是背模板）

核心心法只有一句：模型只看得见你给的上下文，你给得越明确、越结构化，结果越稳。

要掌握的几种写法：

零样本（Zero-shot）：直接下指令，不举例。
少样本（Few-shot）：给 2–3 个示例，让模型照着格式来，复杂任务效果立竿见影。
角色设定：「你是一名资深后端工程师，负责 code review」。
结构化输出：明确要求返回 JSON，并给 schema，方便程序解析。
思维链（CoT）：「请一步步思考后再给出结论」，复杂推理任务准确率明显提升。

几个必须分清的概念（面试必问）

RAG vs 微调：绝大多数业务用 RAG 就够了——把知识塞进上下文，成本低、可更新、可解释。微调是改模型权重，适合「风格 / 特定格式 / 小语种」等场景，成本高、数据难备。别一上来就微调。
Embedding：把文本变成一串向量，语义相近的文本向量也相近，这是检索的基础。
量化：用更低精度（如 FP16 → INT4）跑模型，省显存、提速度，代价是轻微掉点。
参数规模 7B / 13B / 70B：不是越大越好，要看任务、显存和成本。多数业务 7B–14B 量化后就能跑，70B 留给强推理场景。

上下文工程：比背 prompt 模板更重要

模型没有记忆，每一次调用都是「失忆」的——它只看见你这一次请求里塞进去的内容。所以「怎么组织上下文」决定了上限。这叫上下文工程（Context Engineering），2024 年后越来越被重视。

几个实操原则：

把系统提示（system prompt）当产品规格写：角色、目标、约束、输出格式、禁止事项，一条条列清，像写接口契约。
相关信息前置、干扰信息后置：模型对开头和结尾的内容更「上心」，核心指令放首尾。
该忘的忘：历史对话很长时，别全塞进去。用摘要压缩旧轮次，只保留当前任务需要的。
给模型「思考空间」：复杂任务让它先列步骤再答，比直接要答案稳。
少样本要典型：给的示例要覆盖边界情况，别只给happy path。

幻觉怎么应对（不是靠「别瞎编」这种指令）

你写「请勿编造」模型并不会因此就不编。真正有效的手段是工程层的：

RAG 兜底：让回答 anchored 在检索到的资料上，并要求「资料里没有就回答不知道」。
引用来源：要求模型输出时带上引用的文档片段，你就能校验它有没有乱说。
置信度提示：让模型在不确定时显式说「不确定」，而不是硬编一个。
关键结论二次校验：对数字、专有名词，用工具（如检索、代码执行）再核一遍。

模型能力边界清单（转岗前要有数）

不擅长：实时信息（除非接搜索/工具）、精确算术、严格逻辑推理、长链条规划。
擅长：文本生成、摘要、分类、翻译、代码补全、根据示例模仿格式。
会「讨好你」：你暗示一个错误结论，它可能顺着你说。所以评测不能只看「像不像对」，要看「对不对」。

这一关学到什么程度够用：能用自己的话讲清「什么是 token、RAG 和微调的区别、为什么长上下文贵、模型为什么会产生幻觉、上下文工程在干什么」。不要求推导注意力公式，但要知道它大致在干什么、以及你该往上下文里塞什么。

第二关：工程能力——这才是分水岭

这是后端转 AI 真正值钱的地方，也是面试深挖的主战场。前面是「懂不懂」，这一关是「能不能造出来、扛不扛得住」。

API 调用（入门，但你得写出生产级）

后端同学上手最快，但别停在curl一下就完事。生产级调用要包含：

流式输出（SSE）：用户等不起「想三秒才吐字」，要一个字一个字往外蹦。
错误处理与重试：限流（429）、超时、服务端 5xx，都要有退避重试。
鉴权与安全：key 不能写前端、不能进代码仓库，走环境变量或密钥管理。
超时与熔断：模型慢了不能拖垮你的主流程。

一个最小健壮调用的伪代码思路：

retry with exponential backoff on 429 -> wait and retry on timeout -> fallback to smaller model or cached answer on success -> stream tokens to client

Prompt 进阶：把模型当「不可信的外部依赖」

你写代码调用数据库，会做参数校验、超时、异常兜底。调模型更要这样，因为模型比数据库更不可控：

要求返回 JSON，但模型可能返回带 markdown 代码块的 JSON，或者多说一句废话 → 要解析兜底。
要求只输出数字，它可能输出「答案是 42」→ 要正则抽取。
长任务要求一步步来，它可能跳步 → 要流程拆分 / 校验点。

RAG 全流程（核心，要能独立做出来）

文档加载 → 切分（chunk）→ 嵌入（embedding）→ 写入向量库 → 检索 → 重排（rerank）→ 拼进 prompt 生成。每一步都有坑：

切分策略

按段落切：保语义，但段落长短不一。
按固定长度切（如 500 字 + 100 字重叠）：可控，但可能切断句子。
按语义切分（用模型判断边界）：最准，但成本高。

经验值：中文一般 200–500 字 / chunk 起步调，chunk 太大检索不精准、太小丢上下文。重叠（overlap）一般取 chunk 的 10%–20%，避免边界信息丢失。

嵌入模型选型

中文场景优先 bge / bce / gte 系列，效果比通用 OpenAI embedding 在中文上更稳。
维度不是越高越好，要看检索速度和存储。

混合检索（生产级标配）

纯向量检索容易漏掉「关键词精确匹配」的情况（比如专有名词、报错码）。正确做法是向量检索 + BM25 关键词检索融合（RRF 或加权），比纯向量准得多。这是区分 Demo 和生产的硬指标。

重排序（rerank）

检索出 topN（如 20）后，用 cross-encoder 重排再取 topK（如 5），质量明显提升。很多团队忽略这步，结果「检索回来了但排错了」，问答自然烂。

效果评测

别靠「我觉得还行」。要做：

Recall@K：相关文档有没有进前 K。
人工标注集：攒 50–100 条真实问答，作为回归测试，每次改策略都跑一遍。
端到端准确率：直接看最终回答对不对。

一个最小可跑的 RAG 检索片段（原生写法，不依赖重框架，方便你理解每一步）：

# 1) 切分：固定长度 + 重叠 def split_text(text, size=400, overlap=80): chunks, start = [], 0 while start < len(text): chunks.append(text[start:start+size]) start += size - overlap return chunks # 2) 嵌入 + 写入向量库（伪代码，实际用 bge / gte + Qdrant） vectors = embed_model.encode(chunks) qdrant.upsert(vectors, payloads=[{"text": c} for c in chunks]) # 3) 混合检索：向量召回 top20 + BM25 召回 top20，RRF 融合取 top5 vec_hits = qdrant.search(embed_model.encode(query), top_k=20) bm25_hits = bm25.search(query, top_k=20) fused = rrf_merge(vec_hits, bm25_hits, k=60)[:5] # 4) 重排：cross-encoder 对 query+chunk 打分，取 top3 reranked = reranker.rank(query, [h.payload["text"] for h in fused])[:3] # 5) 拼 prompt 生成 context = "/n".join(reranked) answer = llm.generate(f"基于以下资料回答：/n{context}/n/n问题：{query}")

这段代码覆盖了「切分 → 嵌入 → 混合检索 → 重排 → 生成」全链路。你照着把每一步换成你选的组件，就有一个能讲清楚的 RAG 了。

向量库选型（要会对比，面试常问）

向量库	适合场景	优点	注意
Milvus	大规模、高性能	分布式、性能好	运维重
Qdrant	RAG 友好	易部署、过滤强	超大集群弱于 Milvus
pgvector	已有 Postgres	不引入新技术栈	超大量级性能一般
Chroma	本地原型	上手快	生产需补运维

选型看三件事：数据量、是否已有 PG、团队运维成本。别为了「看起来厉害」上 Milvus，结果一半精力在养集群。

Agent 编排（高阶，慎碰框架）

Function Calling：让模型决定调哪个工具、传什么参数。这是 Agent 的骨架。
ReAct：思考 → 行动 → 观察 → 再思考的循环，适合多步任务。
工具定义与描述：工具的描述写得好不好，直接决定模型调不调得对。描述是给模型看的「说明书」，要像写 API 文档一样认真。

一个 function calling 的工具定义示例（关键是把参数 schema 写严谨，并加枚举和说明）：

{ "name": "query_order", "description": "根据用户ID和订单号查询订单状态，仅用于已登录用户", "parameters": { "type": "object", "properties": { "user_id": {"type": "string", "description": "用户唯一ID"}, "order_id": {"type": "string", "description": "订单号，格式 ORD+数字"}, "status": {"type": "string", "enum": ["paid","shipped","done","refund"], "description": "可选过滤状态，不填返回全部"} }, "required": ["user_id", "order_id"] } }

注意三点：description 写清「什么时候用、限制是什么」；参数加类型、枚举、说明；required 标全。模型靠这些信息决定「调不调、怎么填」。少了这些，模型容易瞎填或调错接口——这就是工程化兜底要兜的地方。

框架上 LangChain / LlamaIndex 能加速，但我更建议你先理解原生 HTTP 调用怎么玩，再碰框架。不然框架一封装，出问题你连请求长啥样都不知道，排错全靠猜。

微调：什么时候该微调（多数时候不该）

满足下面任意一条再考虑：

需要固定的输出风格 / 格式，prompt 压不住。
领域术语极多，RAG 检索噪声大。
数据闭环已经跑通，有稳定高质量语料。

方式上优先 LoRA / QLoRA（只训小部分参数，显存友好）。但务必记住：微调解决不了「知识过时」，解决的是「行为 / 风格」。业务知识还是靠 RAG 喂。

推理优化（降本关键）

量化：INT8 / INT4 跑开源模型，显存直接砍半。
vLLM / TGI：连续批处理（continuous batching），吞吐量翻几倍。
模型路由：简单问题用 7B，难问题才上 70B，成本立降。

工程化必修课（拉开差距的地方）

这些和后端写接口是一个道理，但很多 AI 项目偏偏缺：

超时 / 重试 / 熔断 / 降级：模型是外部不可信依赖，必须有兜底。
可观测性：每一步输入输出、耗时、token 数都要能 trace、能回放。线上答错了，你要能还原「当时喂了什么」。
成本控制：请求级归因——这次回答烧了多少 token、花了多少钱。没有归因，老板问「为什么这个月 AI 账单涨了 3 倍」你答不上来。

评测集怎么建（5 步，别跳过）

没有评测集，你改任何策略都是在「凭感觉」，面试也答不出「凭什么说变好了」。

攒真实问题：从用户反馈、客服记录、内部提问里收集 50–100 条真实问题，覆盖高频和边界。
标注标准答案 / 相关文档：每条问题标出「应该检索到的文档」和「理想回答要点」。
定指标：检索用 Recall@K，生成用「是否覆盖要点」「是否有幻觉」「是否引用来源」。
自动化跑：每次改切分 / embedding / 重排，都重跑一遍，生成对比报告。
人工抽检：机器指标过了，再抽 10 条人工看，防止「指标好看但答非所问」。

成本归因怎么落地（具体做法）

每次请求记一笔：user_id / 业务线 / 接口名 / 模型名 / 输入 token / 输出 token / 耗时 / 花费。
聚合看板：按业务线汇总，谁在烧钱一目了然。老板问「为什么涨了」，你能定位到「是 A 业务量涨了，还是某人把 max_tokens 设太大」。
设预算与告警：单请求超阈值、单日超预算，自动告警。
降本手段：缓存高频问答、简单问题路由小模型、长上下文只在必要时拼接。

这一关学到什么程度够用：能独立做一个带混合检索 + 重排 + 可观测 + 成本归因 + 评测集的 RAG 系统；工具调用会加 schema 校验和失败兜底；能把模型当「不可信外部依赖」写进你的错误处理体系；能拿出一份「改策略前后指标对比」的报告。

第三关：项目实战——做一个生产级项目，不是 Demo

教程里的「知识库问答」是 Demo：上传 PDF、切分、向量化、检索、丢给大模型。这东西 2024 年就会了，面试官看到「基于 LangChain 做知识库问答」眼皮都不抬。

Demo 和生产级的差距（对比表）

维度	Demo	生产级
检索	纯向量，topK 拍脑袋	混合检索 + 重排，有评测集
发布	改完就上	策略热加载 + 灰度发布
质量	没标准	有质量门禁 + 效果指标
回滚	没有	一键回滚
成本	不算	请求级归因
可观测	无	全链路 trace

一句话：Demo 解决「能不能跑通」，生产级解决「能不能跑稳、跑便宜、跑得有人敢负责」。

四个适合后端背景做的项目方向

RAG 检索治理平台（策略中心 / 评测中心 / 检索实验室 / 成本归因）——最贴后端工程能力，强烈推荐。
AI 客服 / Agent 工作流：多工具编排 + 人工兜底，体现「系统思维」。
自然语言转 SQL / 代码助手：结合你已有的数据库、后端经验，上手快、说服力足。
文档智能处理流水线：抽取、结构化、审核，适合有业务系统经验的你。

一个完整项目拆解示例（RAG 检索治理平台）

策略中心：切分参数、embedding 模型、检索权重都可配置、热加载，不改代码就能调效果。
评测中心：内置标注集，每次改策略自动跑 Recall@K 和端到端准确率，出报告。
检索实验室：A/B 对比不同检索方案，灰度放量。
成本归因：每个请求记 token、记钱，按业务线 / 接口维度汇总。

这套东西为什么面试官爱问？因为它处处是「工程决策」：参数怎么定、灰度怎么发、成本怎么降——全是你后端老本行，正好发挥。

项目怎么写进简历才值钱

别写「使用 LangChain 实现知识库问答」。写带指标、带决策的：

设计了混合检索（向量 + BM25）+ cross-encoder 重排策略，将检索 Recall@5 从 0.62 提升到 0.88；搭建 Shadow 灰度评测体系，bad case 率下降 40%；落地请求级成本归因，帮团队每月节省约 1.2 万元推理费用。

用工程指标说话，面试官才会追着问「你这个 0.88 怎么测的、灰度怎么发、成本怎么归因」——而这些你正好能答。

开源 vs 自研

别一上来就自己造轮子。先用开源（如 Dify、RAGFlow）跑通业务，理解全链路后，再针对痛点自研关键模块。面试官更看重「你知道哪该自研、哪该用现成的」，而不是「全栈手搓」。

第四关：面试突围——准备高频深挖点

面试官不考你会不会调接口，考你「真做过没有」。准备下面这批，覆盖率很高：

RAG 方向

为什么用混合检索？纯向量在什么场景会翻车？
chunk 大小怎么定？重叠为什么重要？
重排怎么做、用什么模型、为什么能提升？
检索质量怎么评测（Recall@K、人工标注集怎么建）？
知识库更新怎么处理（增量 embedding，还是全量重建）？
语义相同但表述不同的问题，怎么保证都检索到？

Agent 方向

工具返回你校验了吗？不校验会出什么事？
上下文爆了怎么办（短期 / 长期 / 结构化三层记忆怎么分）？
模型调了不存在的接口怎么兜底？
多步规划失败怎么回退？人在环（human-in-the-loop）怎么接？

工程方向

高并发怎么扛（连接池、限流、队列、批处理）？
成本怎么控（缓存、模型路由、量化）？
线上回答错了怎么定位（trace 怎么设计）？
灰度怎么发、指标怎么看、怎么回滚？

开放题（必准备）

你做的 AI 项目最大挑战是什么？
如果检索结果全是噪声怎么办？
老板说「成本太高」你怎么降？
模型偶尔胡说，你怎么不让它伤害用户？

讲项目的套路：用 STAR（背景-任务-行动-结果），但重点准备「行动里你做了什么决策、为什么」，以及「结果用什么指标衡量」。能答清这些，offer 稳一半。

系统设计题：设计一个 RAG 系统（示例回答骨架）

明确场景和数据规模（决定向量库选型）。
文档预处理流水线：解析 → 清洗 → 切分（带重叠）。
嵌入 + 写入向量库，设计元数据过滤字段。
检索：混合检索 + 重排，召回 topK。
生成：拼 prompt + 结构化输出 + 引用来源。
工程化：超时、重试、降级、trace、成本归因。
评测：标注集 + 自动指标 + 人工抽检。

能把这条线讲顺，还主动提到「灰度、回滚、成本」，面试官基本认定你是真做过。

算法 / 八股要不要刷

后端转 AI 应用岗，算法强度低于纯算法岗。但基础数据结构、你目标公司的后端八股（并发、JVM、MySQL、Redis）该有的还得有——因为 JD 往往还是「后端 + AI」。别转了 AI 把老本行丢了。

第五关：求职策略——简历、投递、谈薪

简历包装（不过度）

项目描述用「动作 + 技术 + 指标」：做了什么、用了什么、效果多少。
关键词落「生产级 / 高并发 / 可观测 / 成本归因 / 灰度」。
别吹没做过的：面试官一深挖就露馅，比没有还糟。你预埋的「深挖点」必须真做过。

投递策略

优先看「AI 应用 / 大模型业务」岗，而非纯算法岗（后者要论文和算力，后端转过去吃亏）。
JD 里出现 RAG、Agent、向量库、可观测、MLOps，就是你的菜。
公司类型：大模型厂的应用团队、传统互联网的业务 AI 化团队、SaaS 的 AI 功能组，都在招「会 AI 的后端」。

薪资谈判

后端转 AI 一般有溢价，但别漫天要价。用「生产级项目经验 + 工程化能力」支撑。
谈的时候亮出你做过的灰度、评测、成本归因——这是普通 CRUD 后端没有的筹码。
用数据说话：「我帮上家把推理成本降了 30%」，比「我能力强」有力一百倍。

模拟面试（强烈建议）

找人 mock 一轮，把项目讲顺、把深挖点答稳。比刷题管用，而且能暴露你「以为自己懂、其实讲不清」的地方。

时间线规划（照着排，别跳关）

3 个月速通版（已有扎实后端基础）

第 1 个月：基础认知 + API 调用 + Prompt 工程，跑通一个带混合检索的 RAG。
第 2 个月：Agent 编排 + 工程化（超时/重试/可观测/成本），把 RAG 做成生产级。
第 3 个月：做 1 个完整项目 + 写进简历 + 刷面试深挖点 + 模拟面试。

6 个月稳妥版（基础一般 / 想冲更好的岗）

前 3 个月同上，但每个模块多留时间做对比实验、攒评测集。
第 4–5 个月：做第 2 个项目（Agent 或 NL2SQL），补算法八股。
第 6 个月：集中投递 + 面试 + 谈薪。

15 个常见坑（建议你逐条对照）

一上来就学 Python，忽略工程能力。
只调 API，不做检索质量、不做评测。
把「知识库问答 Demo」当项目写进简历。
不问成本，token 烧得毫无感知。
忽略超时 / 重试 / 降级，线上一挂全挂。
向量库盲目上 Milvus，一半精力养集群。
纯向量检索，漏掉关键词精确匹配场景。
不做重排，召回对了但排错了。
不做可观测，出问题还原不了现场。
一上来就微调，数据没备齐、成本爆炸。
直接碰 LangChain，原理不懂排错靠猜。
简历吹没做过的，一深挖就露馅。
转了 AI 把后端八股丢了，JD 还是后端 + AI。
不刷面试深挖点，项目讲不顺、指标答不出。
不模拟面试，现场卡壳。

后端技能平移清单：你以为从零开始，其实带了半套装备

很多人转 AI 自卑，觉得「我啥都不会」。其实你后端那几年，至少有一半直接能平移：

接口设计与错误处理 → 直接用在模型调用、工具调用上（超时 / 重试 / 熔断你熟）。
数据库与 SQL → NL2SQL、向量库查询、元数据过滤，全是你的主场。
并发与性能 → 限流、连接池、批处理、缓存，AI 服务一样要。
可观测与排障 → trace / 日志 / 监控，AI 链路只是多了一层「模型黑盒」，你本来就会排。
系统设计 → RAG 系统、Agent 工作流本质都是系统设计题，你练过。
DevOps → 部署、容器、CI/CD，开源模型私有化部署你上手快。

你要补的，主要是「AI 特有的那部分」：模型原理直觉、RAG/Agent 套路、评测与成本意识。这部分本篇已经铺好了路。所以别慌，你不是从零开始。

学习资源与路径（只推荐，不硬广）

官方文档优先：OpenAI / 通义 / 智谱的 API 文档，LangChain / LlamaIndex 的 cookbook，比二手教程准。
动手优先于看课：每个概念学完立刻写一个小 demo，比如「今天学切分，就写个切分对比脚本」。
读论文摘要即可：RAG 相关的论文（如 RRF、rerank 思路）读摘要和图，不必啃公式。
混社区：GitHub 上的 RAG / Agent 开源项目，看别人怎么组织工程，比看书快。
做对比实验：别只跑通，要做 A/B——「混合检索 vs 纯向量」「加 rerank vs 不加」，用评测集说话。

记住：转 AI 是「做项目」不是「刷课」。一个能讲透的生产级项目，顶十张证书。

薪资谈判话术脚本（背下来，现场不慌）

面试官问「你期望薪资多少」或「为什么值这个价」，别只说「我能力强」。用这个结构：

我过去三年是后端，转 AI 后补齐了 RAG、Agent 和生产级工程化能力。我能直接上手的是「把 AI 落进业务、扛住生产」这一层——比如我做过混合检索把 Recall@5 从 0.62 提到 0.88，也落地了请求级成本归因帮团队每月省 1.2 万。这部分是普通 CRUD 后端没有的，也是 AI 应用岗最缺的。基于这个，我的期望是 X。

要点：用具体指标代替形容词，用「生产级 / 成本 / 评测」制造稀缺感。别漫天要价，但也要敢亮筹码。

FAQ 10 问（你大概率也想过）