大模型 AI 编程概念全景图

AI 编程生态的概念全景图，从基础大模型层到应用工程层、工具扩展层和开发范式层，梳理 LLM、Token、Embedding、RAG、Tool Calling、MCP、Agent、SDD 等核心概念的定义与层级关系。

目录

章节	说明
基础大模型层	Model、Token、Context Window
人机接口层	Prompt、Prompt Template、System Prompt、Rules
语义表示层	Embedding、Vector Store、语义相似度
知识增强层：RAG vs 微调	外部知识注入和模型参数调整
应用集成层	Structured Output、Tool Calling、Evaluation
能力扩展层	Function Calling、MCP、Skill
开发范式层	Vibe Coding、Spec Coding / SDD
智能自主层	AI Agent、Multi-Agent、Agentic Engineering
概念关系图	核心概念的分层关系
AI 编程范式演进时间轴	AI 编程模式的演进
概念定位速查表	高频概念对比

基础大模型层

AI Model（AI 模型）

AI 模型是处理和生成信息的算法系统。按输入输出类型可以分为：

模型类型	输入	输出	典型用途
Language Model	文本	文本	对话、代码生成、摘要、问答
Image Model	文本/图片	图片	文生图、图像编辑
Audio Model	音频/文本	文本/音频	语音识别、语音合成
Embedding Model	文本/图片/视频	向量	语义检索、推荐、分类、RAG

AI 编程主要依赖 Language Model，但工程应用通常还会组合 Embedding Model 和向量数据库。

大语言模型（LLM）

大语言模型是 AI 编程的核心引擎。其关键特性：

• 预训练：GPT 中的 P 指 Pre-trained，模型先从大规模数据中学习通用模式，再用于具体任务
• 知识截止日期：训练数据有时效性，无法天然感知最新信息
• 概率输出：生成文本本质是对 token 的概率采样，非确定性
• 幻觉（Hallucination）：可能自信地输出错误信息

一句话定位：LLM 是通用能力底座，但它默认没有你的私有知识、实时数据和业务上下文。

Token（词元）

Token 是模型处理文本的基本单位。输入时文本被切分成 token，输出时模型再把 token 还原为文本。

Token 有三个工程含义：

• 成本单位：多数托管模型按输入 token + 输出 token 计费
• 容量单位：模型一次请求能处理的 token 数有限
• 设计约束：长文档、代码库、历史对话都需要被压缩、切块或检索后再放入上下文

Context Window（上下文窗口）

Context Window 是模型单次请求能处理的最大 token 数，是 AI 编程的核心约束：

• 影响模型能读取的代码量、文档量和对话历史长度
• 超出窗口的内容不会被模型处理
• 上下文越长不等于效果越好，低信噪比内容会稀释注意力

上下文工程（Context Engineering） 是当前 AI 编程的核心竞争力：如何把最有价值的信息装入有限窗口，让模型拿到足够且准确的任务上下文。

人机接口层

Prompt（提示词）

Prompt 是发送给模型的语言输入，用来设定任务、上下文和输出要求。它不只是用户在对话框里输入的一句话，现代 Chat API 通常会把 prompt 拆成多条带角色的 message。

角色	作用
System	定义模型行为、边界、风格和长期约束
User	用户当前请求
Assistant	模型历史回复，用于多轮对话上下文
Tool	工具调用结果，供模型继续推理

Prompt Engineering（提示工程）

提示工程是设计和优化输入以获得更好输出的方法集合：

• Few-shot：给模型几个输入输出示例
• Chain-of-Thought / Step-by-step：引导模型分步骤推理
• Role-playing：指定模型扮演某类专家角色
• Output constraint：明确输出结构、边界和禁止事项

提示工程不是“咒语”，本质是用自然语言 API 调用概率模型。任务越复杂，越需要把目标、上下文、约束、示例和验收标准写清楚。

Prompt Template（提示词模板）

Prompt Template 是把稳定的提示结构参数化，让变量在运行时注入。

Tell me a {adjective} joke about {content}.

在应用工程里，Prompt Template 类似 Spring MVC 的 View：模板定义结构，模型对象填充变量，最终渲染出的字符串或 messages 才会发送给 AI 模型。

System Prompt（系统提示词）

System Prompt 是预设给 AI 的基础指令，用来定义 AI 的角色、行为、约束和安全边界，用户通常不可见。Rules 通常通过 System Prompt 或等价机制注入模型上下文。

Rules（规则）

Rules 是人类制定的长期行为约束，用来提高模型输出符合项目规范和团队偏好的概率。

• 全局生效、持续约束，无需每次重复
• 通常通过 System Prompt、项目记忆或工具配置注入上下文
• 在工具中的体现：Cursor Rules、CatPaw Rules、Windsurf Rules、AGENTS.md、CLAUDE.md
• Rule 约束“必须遵守什么”，Spec 约束“这次任务要做什么”

语义表示层

Embedding（嵌入向量）

Embedding 是文本、图片或视频的数值化表示。模型把输入转换成浮点数数组，也就是向量，用来表达语义特征。

Embedding 的核心作用：

• 把自然语言变成可计算的向量
• 用向量距离衡量语义相似度
• 支持语义搜索、文本分类、推荐、聚类和 RAG

Vector Store（向量数据库）

Vector Store 用来存储 embedding，并提供相似度检索能力。

RAG 中的典型数据流：

文档 -> 切分 Chunk -> Embedding -> 写入 Vector Store
用户问题 -> Embedding -> 相似度检索 -> 相关 Chunk -> 放入 Prompt -> LLM 生成答案

Chunk（文本切块）

Chunk 是把长文档拆成较小片段后的检索单位。切块质量直接影响 RAG 效果。

好的切块策略：

• 保留语义边界，不要把段落、表格、代码方法从中间切断
• 控制 chunk 大小，让检索结果能放进模型上下文窗口
• 根据文档类型选择不同策略，代码、Markdown、表格、日志不应一刀切

知识增强层：RAG vs 微调

RAG（检索增强生成）

给博学的助手配一个随时可查的资料库。

RAG 不改变模型参数，而是在请求时检索外部知识，把相关内容塞进 prompt，再让模型基于这些上下文生成答案。

适合场景：

• 需要最新信息
• 需要私有知识库、项目文档、代码库上下文
• 知识更新频繁，不适合频繁训练模型
• 需要答案可追溯到原始资料

在 AI 编程中的体现：项目知识库、AGENTS.md、CLAUDE.md、代码索引、文档检索、Spring AI 的 QuestionAnswerAdvisor。

Prompt Stuffing（上下文填充）

Prompt Stuffing 是把外部数据直接放进 prompt 的朴素做法。RAG 可以理解为它的工程化版本：先检索最相关内容，再把有限且高价值的内容填入上下文窗口。

关键问题不是“能不能塞”，而是：

• 塞哪些内容
• 内容是否可信
• 内容是否过期
• 内容是否会挤掉更重要的上下文

微调（Fine-tuning）

让模型参加专项训练，改变其内部权重。

微调会调整模型参数，让模型学习特定风格、领域术语或固定输出模式。

适合场景：

• 输出风格高度固定
• 任务模式稳定且样本充足
• 需要减少 prompt 长度或提高特定任务一致性

不适合把频繁变化的业务知识直接塞进模型参数。多数应用优先选择 RAG 保证知识准确，再考虑 微调优化任务表现。

应用集成层

Structured Output（结构化输出）

模型默认输出通常是字符串。即使要求“返回 JSON”，得到的也只是看起来像 JSON 的文本，不天然等于应用可直接使用的数据结构。

结构化输出要解决三个问题：

• 格式约束：让模型按 JSON、表格、对象字段等结构输出
• 解析转换：把字符串转换为 Java 对象、DTO 或业务数据结构
• 失败处理：输出不合法时重试、修复或降级

在工程实践中，结构化输出是 AI 应用从“聊天玩具”走向“系统组件”的关键。

Tool Calling（工具调用）

Tool Calling 让模型可以请求外部系统执行动作或查询数据。典型流程：

1. 应用把工具定义发送给模型，包括名称、描述和参数 schema
2. 模型决定是否调用工具，并返回工具名和参数
3. 应用执行真实工具或业务服务
4. 应用把工具结果返回给模型
5. 模型基于结果生成最终回复

Tool Calling 弥补了 LLM 的两个限制：

• 训练后知识会过期
• 模型默认不能访问或修改外部系统

Evaluation（模型输出评估）

AI 应用不能只看“输出是否流畅”，还要评估：

• 是否回答了用户问题
• 是否忠于给定上下文
• 是否事实正确
• 是否符合格式和安全约束
• 是否可以被业务流程接受

常见方法包括规则校验、人工评审、测试集评估、LLM-as-a-Judge，以及结合向量库上下文做相关性判断。

能力扩展层

Tool Use / Function Calling（函数调用）

Function Calling 是 AI 调用外部函数的底层能力：

模型生成结构化调用请求 -> 执行环境运行函数 -> 结果返回模型 -> 模型继续生成

它是 Tool Calling、Agent 自主执行和 MCP 工具生态的基础。

MCP（Model Context Protocol）

MCP 是 Anthropic 于 2024 年 11 月推出的开放协议标准，用于标准化 AI 模型与外部工具、数据源的连接方式。

• 类比：AI 的 USB 接口
• 一次开发，多处复用
• 可连接文件系统、数据库、浏览器、内部平台、搜索服务等上下文来源

与 Function Calling 的关系：

概念	定位
Function Calling	模型调用工具的底层能力
Tool Calling	应用把业务服务暴露给模型的交互机制
MCP	工具和上下文接入的标准化协议层

Skill（技能）

Skill 是可复用的能力模块，封装“怎么做”的执行步骤、SOP 和最佳实践。

• MCP 解决“能连接什么”
• Tool Calling 解决“怎么调用外部能力”
• Skill 解决“按什么流程完成一类任务”

三者不是替代关系，而是协同关系：MCP 接入能力，Tool Calling 执行动作，Skill 组织方法。

开发范式层

Vibe Coding（氛围编程）

Vibe Coding 由 Andrej Karpathy 在 2025 年 2 月提出，核心是用自然语言描述功能，AI 生成代码，开发者主要凭感觉判断结果。

适合：

• 快速原型
• 个人工具
• 实验性项目
• 非关键业务逻辑

不适合：

• 生产环境核心代码
• 安全敏感系统
• 长期维护项目
• 大型团队协作项目

Spec Coding（规范驱动开发，SDD）

先写清晰、结构化的规范，再基于规范进行开发。

SDD 与 Vibe Coding 相对，强调规格先行：

需求 -> Spec -> Plan -> Tasks -> Implement -> Verify

核心主张：

• 用规格文档描述目标、约束、边界和验收标准
• 每个阶段设置 Checkpoint 供人工审核纠偏
• 让 AI 获得稳定上下文，减少幻觉和记忆丢失

工具实现：

• Kiro：三段式 Spec 工作流
• OpenSpec：双文件夹模型，支持多种 AI 编码助手
• Spec-Kit：围绕规格驱动开发的任务组织方式

智能自主层

AI Agent（AI 代理）

AI Agent 是能够自主规划、执行任务、使用工具并根据结果迭代的 AI 系统。

核心循环：

Reasoning -> Action -> Observation -> Reasoning

Agent 与普通 Chatbot 的区别不在于“会聊天”，而在于能否持续地：

• 拆解目标
• 选择工具
• 执行动作
• 观察结果
• 修正计划
• 直到任务完成或明确失败

Multi-Agent（多智能体）

Multi-Agent 是多个 Agent 协同完成复杂任务的模式。

典型分工：

• 需求分析 Agent
• 架构设计 Agent
• 编码实现 Agent
• 测试 Agent
• Review Agent

关键挑战：

• Agent 间上下文传递
• 任务边界划分
• 结果合并与冲突处理
• 成本、延迟和可观测性

Agentic Engineering（代理工程）

Agentic Engineering 是 AI 编程从“工具辅助”走向“Agent 主导端到端工程执行”的趋势。

开发者角色会从“逐行写代码的人”转向：

• 定义目标
• 提供上下文
• 设计约束
• 审核结果
• 管理 Agent 执行过程

真正的能力不只是会让 AI 写代码，而是能把目标、上下文、工具、验证和反馈组织成可靠的工程闭环。

概念关系图

flowchart TD
    A["AI Model<br/>模型底座"] --> B["LLM<br/>语言生成"]
    A --> C["Embedding Model<br/>语义向量"]
    B --> D["Token<br/>成本与容量单位"]
    D --> E["Context Window<br/>上下文窗口"]

    E --> F["Prompt<br/>任务输入"]
    F --> G["Prompt Template<br/>模板化复用"]
    F --> H["System Prompt / Rules<br/>长期约束"]

    C --> I["Vector Store<br/>向量数据库"]
    I --> J["RAG<br/>检索增强生成"]
    E --> J
    J --> K["Prompt Stuffing<br/>上下文填充"]

    B --> L["Structured Output<br/>结构化输出"]
    B --> M["Tool Calling<br/>连接外部系统"]
    M --> N["MCP<br/>标准化工具协议"]
    M --> O["Skill<br/>可复用流程"]

    J --> P["AI Application<br/>AI 应用"]
    L --> P
    M --> P
    P --> Q["Evaluation<br/>输出评估"]

    P --> R["AI Agent<br/>自主执行循环"]
    R --> S["Multi-Agent<br/>多智能体协作"]
    R --> T["Spec Coding / SDD<br/>规格驱动开发"]
    R --> U["Vibe Coding<br/>快速原型"]

    style A fill:#eef,stroke:#446
    style J fill:#efe,stroke:#484
    style M fill:#efe,stroke:#484
    style Q fill:#ffe,stroke:#aa7
    style R fill:#fef,stroke:#848

AI 编程范式演进时间轴

IDE 补全 -> Chat 问答 -> Agent 编码 -> Spec 驱动 -> 多 Agent 协作
  Copilot     ChatGPT      Devin/Claude     Kiro/Spec-Kit       Agent Swarm
  2021        2022-2023    2024-2025        2025-2026           趋势方向

概念定位速查表

概念	核心问题	作用层次	改变参数？	生命周期
AI Model	如何处理和生成信息	模型底座	-	长期
LLM	如何生成语言和代码	基础引擎	-	长期
Token	模型如何计量文本	成本/容量单位	-	单次请求
Context Window	一次能处理多少上下文	模型约束	-	单次请求
Prompt	如何表达任务	人机接口	否	单次请求
Prompt Template	如何复用提示结构	应用工程	否	长期复用
Rules	必须遵守什么约束	行为边界	否	全局持续
Embedding	如何表示语义	语义表示	否	数据处理阶段
Vector Store	如何检索相似内容	知识检索	否	长期存储
RAG	如何获取外部知识	知识增强	否	运行时
微调	如何改变模型行为	模型训练	是	训练后固化
Structured Output	如何让 AI 输出可被程序消费	应用集成	否	单次请求
Tool Calling	如何连接外部系统	应用集成	否	单次请求
MCP	如何标准化工具接入	协议标准	否	长期
Skill	这类任务怎么做	能力封装	否	可复用
Evaluation	如何判断输出是否可用	质量保障	否	开发/运行时
Vibe Coding	如何快速出原型	开发范式	-	感觉驱动
Spec Coding / SDD	如何可靠交付	开发范式	-	规格驱动
Agent	如何自主完成任务	执行主体	否	任务周期
Agentic Engineering	AI 如何主导工程流程	工程范式	-	趋势方向

参考资料

• Spring AI Reference - AI Concepts
• Spec 和 Rules 的区别与联系（Rules 与 Spec 的边界）
• Spec 和 Skill 的区别与联系（Skill 在 AI 编程中的定位）
• AI Agent 开发最佳实践（Agent 架构与工程实践）