> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 软件工程师转AI：2026路线图
- URL: https://www.hubwiz.com/blog/software-engineer-to-ai-2026-roadmap/
- Published: 2026-06-06T02:05:22.000Z
- Updated: 2026-06-06T02:05:22.000Z
- Description: 一个三层路线图，包含真实代码、真实用例，零空谈。
- Author: admin
- Tags: JOB MARKET, #Import 2026-10-14 14:41

如果你是一名软件工程师，正注视着AI领域，你大概注意到了这个问题：每门课程要么从线性代数开始，永远到不了你能交付的东西；要么从"用10行LangChain构建聊天机器人"开始，而当它在生产环境中出问题时，你却无法调试任何东西。

有一条更理性的路径。它看起来是这样的：

1. **Transformers** → 向量 → 注意力 → FFNN
2. **RAG** → 分块 → 向量数据库 → 重排序
3. **智能体** → 工具 → MCP → 记忆

注意这个列表中*没有*什么：从头训练模型、GPU优化、在笔记本电脑上微调LLaMA。作为一名*AI工程师*（而非ML研究员），你的工作是将这些原语组合成产品。本文将用我实际构建或正在构建的用例来带你走完这个序列。

## 1、Transformers：一切所承载的底层

你不需要从头实现一个transformer。你*需要*对三件事有一个可运作的心智模型，因为你将来要调试的每个奇怪的LLM行为都可以追溯到其中之一。

### 1.1 向量（嵌入）

嵌入只是一组数字，捕获了一段文本的*含义*。含义相似的两个句子在这个高维空间中彼此靠近；两个不相关的句子则相距甚远。

```
from sentence_transformers import SentenceTransformer

model = SentenceTransformer("all-MiniLM-L6-v2")
vectors = model.encode([
    "format this JSON",
    "pretty print my JSON payload",
    "calculate compound interest",
])
# vectors[0] and vectors[1] are nearly identical.
# vectors[2] is far from both.

```

**真实用例——DevUtil.dev搜索：** 我运营一个包含30+工具的开发者工具包（JSON格式化器、正则测试器、JWT解码器等）。关键词搜索很脆弱——如果我只做字符串匹配，用户输入"make my JSON pretty"不会匹配到名为"JSON Formatter"的工具。将工具描述嵌入一次，然后在查询时做余弦相似度，就能把一个笨拙的搜索框变成感觉像真正理解意图的东西。

### 1.2 注意力

注意力是transformer在生成下一个token时决定*之前哪些token重要*的方式。著名的"the animal didn't cross the street because **it** was too tired"——注意力就是让模型弄清楚"it"指的是"animal"而非"street"的机制。

你不需要推导softmax(QK^T/√d)V才有用。你需要内化两个后果：

- **上下文窗口是有限的且呈二次方增长。** 输入翻倍，计算量大约翻四倍。这就是为什么你不能简单地把整个代码库塞进提示中然后祈祷。
- **模型每一步都会关注*整个*上下文。** 这就是为什么提示注入有效，为什么"忽略之前的指令"是一个真正的攻击，以及为什么把最重要的指令放在长提示的*末尾*通常有帮助。

### 1.3 前馈网络（FFNN）

在注意力搞清楚*看什么*之后，FFNN层对每个token进行实际的"思考"——转换、重组、检索烘焙在权重中的知识。最近的可解释性工作（Anthropic等）越来越多地指出FFNN层是*事实*所在，而注意力是*路由*。

**为什么这对作为工程师的你很重要：** 当LLM"幻觉"出一个不存在的库函数时，那是FFNN自信地检索出一个在统计上匹配的模式——但没有扎根于现实。修复方法不是更好的提示。修复方法是下一层：RAG。

## 2、RAG：给模型它没有的事实

检索增强生成是你作为AI工程师能学到的杠杆最高的单一技术。生产中90%的"AI产品"就是RAG加一个UI。

流程：

```
user query → embed → search vector DB → top-K chunks → stuff into prompt → LLM answer

```

但每一步都有一个旋钮，旋钮调不好就会毁掉整个系统。

### 2.1 分块

你不能把400页的PDF塞进提示中。你需要把它分成块，嵌入每个块，然后在查询时检索相关的块。*如何*分块决定了你的RAG是好还是垃圾。

- **固定大小分块**（例如512 token，50 token重叠）：快速、简单，适合散文。
- **语义分块**（在段落/节边界处分割）：更适合技术文档。
- **结构感知分块**（按函数分割代码，按标题分割markdown）：最适合源代码、API文档、法律合同。

```
from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=800,
    chunk_overlap=100,
    separators=["\n\n", "\n", ". ", " "],  # prefer paragraph breaks
)
chunks = splitter.split_text(long_document)

```

**真实用例——基于个人笔记的本地JARVIS：** 对于我正在构建的设备端个人助手（Ollama + FastAPI + ChromaDB + 树莓派语音终端），对我的Obsidian笔记进行朴素分块毫无用处——会议记录在句子中间被切断，检索返回的是半截子思路。切换到一个尊重标题层级的markdown感知分割器后，答案从"技术相关"变成了"实际正确"。

### 2.2 向量数据库

这只是一个针对"找到距离此查询向量最近的K个向量"优化的数据库，使用HNSW等ANN（近似最近邻）算法。

![None](https://www.hubwiz.com/blog/content/images/2026/06/1-LXh5LuMR-nGnby0-Zv7g6g.png)

```
import chromadb

client = chromadb.PersistentClient(path="./jarvis_memory")
collection = client.get_or_create_collection("notes")

collection.add(
    documents=chunks,
    embeddings=embeddings,
    ids=[f"chunk_{i}" for i in range(len(chunks))],
    metadatas=[{"source": "meeting_notes_2025_11"} for _ in chunks],
)

results = collection.query(query_texts=["what did we decide about pricing?"], n_results=5)

```

**真实用例——HopeConnect人脸匹配：** 相同的原语（向量相似度），不同的领域。我将失踪人员照片的ArcFace嵌入存储在pgvector中，对新上传的"已找到"照片运行余弦相似度。向量数据库不仅用于文本。

### 2.3 重排序

这是RAG的肮脏秘密：向量搜索检索到的是*相似*的块，不一定是*正确*的块。一个关于"Python列表推导式性能"的查询可能会检索到关于"JavaScript数组性能"的块——形式相同，语言错误。

修复方法是两阶段检索：

1. **廉价检索**：向量数据库拉取top-50候选
2. **昂贵的重排序**：交叉编码器（或小型LLM）重新评分这50个候选，选出top-5

```
from sentence_transformers import CrossEncoder

reranker = CrossEncoder("cross-encoder/ms-marco-MiniLM-L-6-v2")
pairs = [(query, candidate) for candidate in top_50_chunks]
scores = reranker.predict(pairs)
top_5 = [c for _, c in sorted(zip(scores, top_50_chunks), reverse=True)[:5]]

```

添加重排序器通常是你在RAG管道中打好基础后能看到的最大质量飞跃。值得花一周时间。

## 3、智能体：当检索不够用时

RAG回答静态语料库上的问题。智能体*采取行动*：调用API、运行代码、读取文件、浏览、写入数据库。这是AI工程从"更聪明的搜索"变为"构建软件"的地方。

### 3.1 工具（函数调用）

"工具"就是一个你向LLM描述了schema的函数，模型可以决定调用它。运行时执行该函数并将结果反馈给模型。

```
tools = [{
    "name": "get_stock_price",
    "description": "Get current price for an NSE/BSE ticker",
    "input_schema": {
        "type": "object",
        "properties": {"ticker": {"type": "string"}},
        "required": ["ticker"],
    },
}]

```

**真实用例——算法交易智能体：** 我的模拟交易系统暴露了`get_technical_indicators(ticker)`、`compute_position_size(capital, risk_pct)`和`place_paper_order(...)`等工具。LLM不*知道*RELIANCE的交易价格——它调用工具，获取答案，然后在此基础上推理。这是正确的劳动分工：确定性代码负责事实和执行，LLM负责对输出进行推理。

### 3.2 MCP（模型上下文协议）

MCP是Anthropic的开放协议，用于以标准化方式向LLM暴露工具、资源和提示。把它想象为"AI工具的USB-C"——不是每个应用都发明自己的函数调用包装器，而是你构建一次MCP服务器，任何MCP兼容的客户端（Claude Desktop、Cursor、你自己的应用）都可以使用它。

对于2026年的AI工程师来说，学习MCP已经不是可选的了。生态系统正在快速整合。

**真实用例——CognitoAITesting：** 我正在构建一个测试生成智能体，它观察SAP Fiori用户流程并输出Playwright工厂模式测试代码。不是将它紧紧焊接到一个客户端上，繁重的工作（DOM提取、网络捕获、代码生成）放在MCP服务器后面。这意味着*相同*的工具界面可以从Chrome扩展、Cursor命令或CLI中使用——而无需三次重写集成。

### 3.3 记忆

对话记忆是智能体工程中最困难的部分，也是大多数"AI助手"在第二周就崩溃的地方。有三个层级，你几乎总是需要全部三个：

- **短期（工作记忆）：** 上下文窗口内的滚动消息历史。一旦超过限制的约70%，就通过摘要来管理它。
- **长期（情景记忆）：** 过去的对话和结果，通过——出乎意料的是——向量数据库检索。是的，记忆就是对你自己历史做RAG。
- **结构化（语义记忆）：** 你明确记录的关于用户的事实。"Sachin住在印度，构建DevUtil.dev，偏好FastAPI。"将这些存储为键值对或图数据，而不是嵌入，以便确定性地检索。

```
async def respond(user_msg: str, user_id: str):
    facts = await structured_memory.get(user_id)         # who they are
    past = await vector_memory.search(user_id, user_msg) # what's happened before
    recent = working_memory.last_n(user_id, n=10)        # current thread

    prompt = build_prompt(facts, past, recent, user_msg)
    reply = await llm(prompt)

    working_memory.append(user_id, user_msg, reply)
    if is_factual_update(user_msg):
        await structured_memory.upsert(user_id, extract_fact(user_msg))
    return reply

```

**真实用例——JARVIS再版：** 一个每次对话后就忘记一切的语音助手是演示，不是产品。我树莓派上的版本保持结构化事实（"妻子生日是X"，"我服用二甲双胍"）、向量索引的对话历史和一个滚动工作缓冲区。同样的三层模式出现在每一个值得使用的生产级智能体中。

## 4、实际学习路径：按周安排

如果你周一就开始，这是我推荐的顺序：

![None](https://www.hubwiz.com/blog/content/images/2026/06/1-_mKdWkEBIAn_N8wB2ITw5w.png)

两个原则可以为你节省数月时间：

1. **先搭建管道，再优化任何部分。** 一个能工作的丑陋RAG胜过一个漂亮但没有接入检索的分块策略。
2. **评估否则灭亡。** 从第一天起就保持一个20-50个查询/答案对的微小评估集。每次更改都对其打分。没有这个，你就是在猜测。

## 5、结束语

2026年的AI工程不是关于训练模型。它是关于将三个原语——*transformers、检索、智能体*——组合成解决真实用户真实问题的系统。上面的顺序是每一层变得可理解的顺序：在理解向量之前你无法推理RAG，在理解RAG为什么有时对它撒谎之前你无法构建可靠的智能体。

从嵌入开始。交付丑陋版本。然后迭代。

---

原文链接：[How a Software Engineer Should Actually Learn AI Engineering — In the Right Sequence](https://medium.com/codetodeploy/how-a-software-engineer-should-actually-learn-ai-engineering-in-the-right-sequence-d8007f46353e?ref=hubwiz.com)

汇智网翻译整理，转载请标明出处