折叠思维折叠思维
返回学习路线

AI 学习路线 · 深入

额外篇 · 2026 年 AI 应用开发必学的 5 项成熟技术

从近半年爆发的技术里，挑出已经过了尝鲜期、能真正用在项目里的 5 项：推理模型、MCP、多模态、GraphRAG、AI 编程工具链，每项都给到能跑通的代码。

AI 工程实践

这一站是"追新但不追热"：从近半年爆发的技术里，挑出已经过了尝鲜期、能真正用在项目里的 5 项，每项都给到能跑通的代码。

不是新闻盘点，是学完就能用的实战指南。

Section 1 · 推理模型：从"直接答"到"先想再答"

Subsection 1 · 亲眼看到推理模型的区别

用同一个问题分别问普通模型和推理模型：

问题：一个球和一个球拍一共 1.10 元，球拍比球贵 1 元，球多少钱？

普通模型（如 qwen-plus）大概率直接答"0.10 元"（错的，正确是 0.05 元）。 推理模型（如 deepseek-reasoner、o3）会先输出一段思考过程，再给出正确答案。

记住：推理模型不是"更聪明的普通模型"，是多了一个"思考"阶段的模型。它会在内部走思维链，验证后再给答案。

Subsection 2 · 记推理模型的适用场景

备忘录写：

推理模型适合： 数学/逻辑题、代码调试、复杂推理 需要多步验证的任务（数据分析、方案对比） 对答案准确性要求高的场景推理模型不适合： 简单问答（浪费 token，响应慢） 创意写作（思考过程会限制创造力） 实时对话（思考阶段耗时 5-30 秒）

Subsection 3 · 跑通推理模型调用

DeepSeek 提供了 deepseek-reasoner 模型，用 OpenAI 兼容格式调用：

python
from openai import OpenAIclient = OpenAI(    api_key="你的DEEPSEEK_API_KEY",    base_url="https://api.deepseek.com",)response = client.chat.completions.create(    model="deepseek-reasoner",    messages=[{"role": "user", "content": "一个球和一个球拍一共1.10元，球拍比球贵1元，球多少钱？"}],)print("思考过程:", response.choices[0].message.reasoning_content)print("最终答案:", response.choices[0].message.content)

预期看到：先输出一段推理过程（“设球为x元，球拍为x+1元…”），然后给出"0.05元"。

关键理解：推理模型的返回里多了 reasoning_content 字段，这是它的思考过程。生产环境可以把思考过程存日志，但不要展示给用户（又长又绕）。

Subsection 4 · 推理模型的成本控制

推理模型的 token 消耗是普通模型的 3-10 倍（因为思考过程也要算 token）。控制成本的两个方法：

  1. 分级路由：简单问题用普通模型，复杂问题才用推理模型。可以用一个小模型先判断问题难度。
  2. 限制思考长度：部分推理模型支持 max_completion_tokens，限制总输出长度（思考+答案）。

过关：能说出推理模型和普通模型的区别、适用场景、能跑通调用代码 = Section 1 完成。

Section 2 · MCP：AI 世界的 USB-C

Subsection 1 · 为什么 MCP 是 2026 年最重要的基础设施

一组数据：

  • 2024 年 11 月 Anthropic 发布 MCP
  • 2025 年 12 月捐赠给 Linux 基金会（和 Kubernetes、PyTorch 同级治理）
  • 2026 年 9 月，公开 MCP Server 超 10000 个，SDK 月下载量近 1 亿次
  • Claude Desktop、ChatGPT、Cursor、Gemini、VS Code 全部原生支持

MCP 解决的问题：在 MCP 之前，每个 Agent 框架有自己的工具定义格式，换框架就要重写工具。MCP 像 USB-C 一样，工具一次定义，所有兼容 MCP 的客户端都能用。

Subsection 2 · 记 MCP 的三个核心概念

Tools（工具）    可执行的操作，相当于函数调用Resources（资源）  可读的数据，相当于文件/数据库记录Prompts（提示词）  可复用的提示词模板

传输方式：JSON-RPC over stdio（本地工具）或 HTTP/SSE（远程工具）。

Subsection 3 · 写一个最小 MCP Server

用官方 Python SDK：

bash
pip install mcp

新建 weather_mcp_server.py：

python
from mcp.server.fastmcp import FastMCPmcp = FastMCP("天气查询")@mcp.tool()def get_weather(city: str) -> str:    """查询指定城市的天气。    Args:        city: 城市名称，比如"北京"、"上海"    """    # 实际项目里这里调真实天气 API    weather_data = {        "北京": "晴 25℃",        "上海": "多云 28℃",        "苏州": "小雨 24℃",    }    return weather_data.get(city, f"暂无 {city} 的天气数据")if __name__ == "__main__":    mcp.run()

运行：

bash
python weather_mcp_server.py

然后在 Claude Desktop 或 Cursor 的 MCP 配置里加上这个 Server，就能让 AI 直接调用你的天气工具。

预期看到：AI 问"苏州天气怎么样"时，会自动调用 get_weather 工具，返回"小雨 24℃"。

关键理解：MCP Server 是一个独立进程，通过 stdio 和 AI 客户端通信。你不需要改 AI 客户端的代码，只需要在配置文件里注册 Server 路径。

Subsection 4 · 什么时候该用 MCP，什么时候不用

用 MCP： 工具需要被多个 AI 客户端共享（Claude + Cursor + 自己的 Agent） 工具提供方和使用方是不同团队 工具需要远程部署（HTTP 传输）不用 MCP： 个人项目，工具只给自己用 工具逻辑简单，直接写函数更快 需要深度定制工具调用流程

过关：能说出 MCP 的三个核心概念、能写一个最小 Server、能判断什么时候该用 = Section 2 完成。

Section 3 · 多模态大模型：不只是"能看图"

Subsection 1 · 多模态已经不是加分项，是标配

2026 年的主流模型全部原生支持多模态：

  • GPT-4o / o3：文本 + 图像 + 音频
  • Gemini 2.5 / Omni：文本 + 图像 + 音频 + 视频
  • Qwen-VL / 豆包：文本 + 图像 + 文档理解

"多模态"不再是"能发图片"这么简单，而是统一理解：模型把文本、图像、音频都转成同一种表示，在同一个空间里做推理。

Subsection 2 · 跑通图文理解

用 DashScope 的 qwen-vl 模型（OpenAI 兼容格式）：

python
from openai import OpenAIclient = OpenAI(    api_key="你的DASHSCOPE_API_KEY",    base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",)response = client.chat.completions.create(    model="qwen-vl-max",    messages=[        {            "role": "user",            "content": [                {"type": "text", "text": "这张图里有什么？详细描述。"},                {"type": "image_url", "image_url": {"url": "https://example.com/test.jpg"}},            ],        }    ],)print(response.choices[0].message.content)

预期看到：模型输出对图片内容的详细描述，包括物体、场景、文字（如果图里有文字）。

关键理解：多模态调用的 content 是一个数组，不是字符串。每个元素有 type 字段（text 或 image_url），可以混合文本和图片。

Subsection 3 · 多模态的三个实战场景

场景 1：文档理解 直接把 PDF/截图发给模型，让它提取表格、总结内容、回答问题。比传统 OCR + 文本解析准确率高很多。

场景 2：UI 自动化测试 把截图发给模型，让它判断页面元素位置、验证 UI 是否符合设计稿。2026 年的 Browser Use 类工具底层就是多模态。

场景 3：代码调试 把报错截图发给模型，它能直接读出错误信息和堆栈，给出修复建议。不用手动复制粘贴。

Subsection 4 · 多模态的坑

  1. 图片 token 消耗大：一张图相当于几百到几千 token，批量处理要算成本。
  2. 本地图片要转 base64：不能直接传本地路径，要转成 data:image/jpeg;base64,... 格式。
  3. 不是所有模型都支持音频/视频：目前图像最成熟，音频和视频还在快速迭代中。

过关：能跑通图文理解调用、能说出三个实战场景、能说出两个坑 = Section 3 完成。

Section 4 · GraphRAG：从"搜片段"到"懂关系"

Subsection 1 · 纯向量 RAG 的天花板

纯向量 RAG（Part 7 学的那种）在 2026 年已经进入瓶颈：

  • 分块策略、Rerank、Query 改写，这些优化大家都在做，差距缩小
  • 面对"全局性问题"（“总结 A 和 B 的关系”、“这个组织的决策链是什么”），向量检索只能搜到零散片段，拼不出全局
  • 微软 2024 年提出的 GraphRAG 在 2026 年已经成熟，成为企业级 RAG 的标配

Subsection 2 · 记 GraphRAG 的核心思路

普通 RAG：文档 → 切块 → 向量化 → 搜最相似的几块 → 拼 PromptGraphRAG：文档 → 提取实体和关系 → 构建知识图谱 → 按问题搜子图 → 拼 Prompt

关键区别：普通 RAG 存的是"文本片段"，GraphRAG 存的是"实体 + 关系"。问"A 和 B 有什么关系"时，GraphRAG 能直接在图上找到 A→B 的路径，而不是靠语义相似度猜。

Subsection 3 · 跑通最小 GraphRAG

用 networkx 构建知识图谱，配合向量检索做混合查询：

bash
pip install networkx
python
import networkx as nx# 1. 从文档中提取实体和关系（实际项目用 LLM 提取）entities = ["张三", "李四", "王五", "技术部", "产品部"]relations = [    ("张三", "李四", "同事"),    ("张三", "技术部", "属于"),    ("李四", "技术部", "属于"),    ("王五", "产品部", "属于"),    ("张三", "王五", "协作"),]# 2. 构建图谱G = nx.Graph()G.add_nodes_from(entities)for src, dst, rel in relations:    G.add_edge(src, dst, relation=rel)# 3. 查询：张三和王五之间有什么关系print("张三的邻居:", list(G.neighbors("张三")))print("张三到王五的路径:", nx.shortest_path(G, "张三", "王五"))

预期看到：

  • 张三的邻居: [‘李四’, ‘技术部’, ‘王五’]
  • 张三到王五的路径: [‘张三’, ‘王五’]

关键理解：这是最小演示。实际项目里，实体和关系由 LLM 从文档中自动提取，图谱存在 Neo4j 或 NetworkX + 持久化里，查询时结合向量检索做混合召回。

Subsection 4 · Hybrid RAG 是正解

不要走极端。2026 年企业级 RAG 的标准做法是 Hybrid RAG：

用户问题  ├── 向量检索 → 召回相关文本片段  ├── 关键词检索（BM25）→ 召回精确匹配  └── 图谱检索 → 召回实体关系      ↓  合并去重 → Rerank 重排序 → Top-K → 拼 Prompt → LLM 生成

向量检索擅长"语义相似"，关键词检索擅长"精确匹配"，图谱检索擅长"关系推理"。三者互补，不是互斥。

过关：能说出 GraphRAG 和普通 RAG 的区别、能跑通最小图谱、能说出 Hybrid RAG 的三路召回 = Section 4 完成。

Section 5 · AI 编程工具链：从"补全"到"代理"

Subsection 1 · AI 编程已经换代了

2023 年：GitHub Copilot，单行补全 2024 年：Cursor / Claude Code，多文件修改、代码库理解 2026 年：AI 编程代理，能自主完成整个功能（读需求→写代码→跑测试→修 bug→提交）

代表工具：

  • Cursor：IDE 形态，Composer 模式做多文件修改
  • Claude Code：终端形态，Agent 模式自主执行任务
  • Windsurf：IDE 形态，Cascade 流式协作
  • Aider：终端形态，开源，Git 原生集成

Subsection 2 · 高效使用 AI 编程工具的三个原则

原则 1：给上下文，不给指令

差的用法：“帮我写一个登录接口” 好的用法：“这个项目用 FastAPI + SQLite，用户表在 models/user.py，登录接口需要校验邮箱格式和密码强度，参考 existing register 接口的写法”

AI 工具的能力上限 = 你给的上下文质量。它不知道你的项目结构、命名规范、错误处理风格，你要告诉它。

原则 2：用 .cursorrules / CLAUDE.md 固化项目规范

在项目根目录建一个规则文件，AI 工具会自动读取：

markdown
# 项目规范## 技术栈- 后端：FastAPI + SQLAlchemy + SQLite- 前端：React + Ant Design- Python 3.13，用 uv 管理依赖## 代码规范- 函数必须有 docstring- 错误处理统一用自定义异常，不裸 raise- API 响应统一格式：{"code": 0, "data": ..., "message": ""}## 禁止- 不要修改 migrations 目录- 不要引入新的依赖，先问我- 不要用 print 调试，用 logging

这样每次 AI 工具启动时都会自动加载这些规则，不用每次重复说。

原则 3：小步提交，让 AI 每次只做一件事

不要让 AI 一次改 10 个文件。拆成小任务：

  1. 先让它改数据模型
  2. 再让它改 API 接口
  3. 再让它写测试
  4. 每步都检查，再继续

大改动容易出幻觉，小步迭代可控。

Subsection 3 · 终端 AI 工具的 Agent 模式

Claude Code 的 Agent 模式可以自主完成整个任务：

bash
# 安装npm install -g @anthropic-ai/claude-code# 启动claude# 输入任务> 帮我给用户模块加一个"修改密码"功能，包括 API 接口、参数校验、测试用例

它会自己：读项目结构 → 找相关文件 → 写代码 → 跑测试 → 修 bug → 提交。你只需要在关键节点确认。

关键理解：Agent 模式不是"更聪明的补全"，是"能自己跑流程的代理"。它会主动调用工具（读文件、写文件、跑命令），不需要你一步步指挥。

Subsection 4 · AI 编程工具的边界

AI 擅长： 样板代码（CRUD、数据模型、API 接口） 测试用例生成 代码重构（重命名、提取函数） Bug 定位（给它报错信息，它能快速定位） 文档生成AI 不擅长： 架构决策（技术选型、模块划分，需要人判断） 业务逻辑（它不懂你的业务，容易想当然） 安全相关代码（鉴权、加密，必须人审） 性能优化（它给的方案可能不是最优的）

记住：AI 是"加速器"，不是"替代者"。它能让你从写代码变成审代码，但最终责任在你。

过关：能说出三个高效使用原则、能配置项目规则文件、能说出 AI 擅长和不擅长的边界 = Section 5 完成。

总结

2026 年 AI 应用开发的技术栈已经从"单点能力"进化到"体系化能力"：

推理模型    → 复杂任务的准确性保障MCP        → 工具调用的标准化协议多模态      → 从文本到图文音视频的统一理解GraphRAG   → 从片段检索到关系推理AI 编程工具 → 从补全到自主代理

这五项不是孤立的，它们会组合使用：

  • 用 MCP 把工具暴露给推理模型
  • 用多模态模型理解文档，提取实体关系构建 GraphRAG
  • 用 AI 编程工具快速搭建整个系统

学习建议：先学 MCP 和推理模型（上手最快、收益最大），再学多模态和 GraphRAG（项目里按需用），AI 编程工具是日常工具，每天都在用。

折叠思维

记录构建、学习和持续思考。

© 2026 折叠思维 · 内容保留署名权Co11ap5e · Folded to unfold better.