AI应用开发全景：6组件模型+MCP/Skills/Hooks三层脚手架，从入门到能动手

AI 应用开发全景：从 LLM 原理到工具生态

2026 年，作为一个 Java 后端开发者，我开始学 AI 应用开发。最初的问题不是"怎么训练模型"——而是"这么多概念，从哪开始？"花了一个月梳理出一张全景地图，这篇文章就是那张地图。

阅读约 18 分钟 | 系列第 1/12 篇

---

前言：为什么学 AI 应用开发

2024-2026 年，AI 领域发生了根本性变化：大模型能力从"能用"到"好用"，开发门槛从"需要 PhD + GPU 集群"降到"会调 API 就能搭应用"。对后端开发来说，这不是可选项——AI 应用开发正在成为和数据库、缓存、消息队列一样的基础技能。

AI 应用开发的能力分层：

层次	描述	能力定位
用过 AI 工具	"我用 ChatGPT/Claude 写代码"	基础操作
系统化使用 AI	"AI 辅助全流程：需求→设计→编码→审查"	有方法论
基于大模型开发应用	"我用 Agent + RAG 搭建了 AI 应用"	核心目标层
微调/训练模型	"用 LoRA 微调了领域模型"	算法工程师方向

本文档的目标是从第二层跨越到第三层——不是泛泛了解概念，而是能讲清楚代码实现、设计决策和工程权衡。

阅读建议：

• 如果你刚接触 AI 开发：按顺序阅读，全文约 25 分钟
• 如果你已有基础：跳读 §1.2（六组件模型）和 §2.3-2.5（MCP/Skills/Hooks）

---

一、AI 背景与基础概念

1.1 AI 是什么：从人工智能到大语言模型

人工智能（AI, Artificial Intelligence） 是一个宽泛的学科领域，目标是让机器表现出类似人类的智能行为——理解语言、识别图像、做出决策、解决问题。它不是单一技术，而是一组技术的统称。

理解 AI 的最佳方式是看它的层级包含关系：

人工智能（AI）                       ← 最大的范畴：一切让机器"看起来智能"的技术
  └── 机器学习（ML）                  ← AI 的子集：不靠人写规则，靠从数据中学习规律
        └── 神经网络                  ← ML 的子集：模拟人脑神经元连接的计算模型
              └── 深度学习            ← 神经网络的子集：层数多、参数多、数据多
                    ├── CNN          ← 图像领域：卷积神经网络
                    ├── RNN/LSTM     ← 序列领域：循环神经网络
                    ├── Transformer  ← 2017年诞生，当前主流架构
                    │     └── GPT/Claude/DeepSeek/GLM...  ← 大语言模型
                    └── Diffusion    ← 图像生成：Stable Diffusion/Midjourney
                                         （扩散模型内部也使用 Transformer/UNet 作为去噪网络）

每一层的核心区别：

层级	代表技术	输入 → 输出	人需要做什么	典型应用
AI（规则系统）	专家系统	事实 → 推理结论	人写全部规则	早期医疗诊断
机器学习	SVM/XGBoost	特征向量 → 分类/回归	人设计特征	垃圾邮件过滤、信用评分
深度学习	CNN/Transformer	原始数据 → 结果	人设计网络结构	人脸识别、机器翻译
大语言模型	GPT/Claude	自然语言 → 自然语言	人描述需求	代码生成、智能问答、Agent

关键跃迁：从 AI 到大语言模型，每一步都在减少"人的参与"——人写规则 → 人设计特征 → 人设计网络 → 人描述需求。大语言模型是当前 AI 领域中与应用开发关系最密切的子集。

---

1.2 大模型的构成：六组件工厂模型

理解了"大模型在 AI 家族中的位置"之后，下一步是搞清楚它由哪些部件组成、各部件如何协作。可以把一个大语言模型比作一个"工厂"：

┌────────────────────────────────────────────────────┐
│                    大语言模型"工厂"                     │
│                                                    │
│  ①训练数据          ②Tokenizer          ③Transformer │
│  ┌──────────┐     ┌──────────┐     ┌──────────────┐ │
│  │ 互联网文本  │ ──→ │ 文本→ID   │ ──→ │ 多层神经网络   │ │
│  │ 书籍/论文  │     │ (BPE分词) │     │ (注意力机制)    │ │
│  │ 代码仓库   │     └──────────┘     │ 逐层提取特征   │ │
│  │ ...       │           ↓          │ 预测下一个词   │ │
│  └──────────┘      ④词表映射         └──────┬───────┘ │
│                      (ID↔向量)              │         │
│                                            ↓         │
│  ⑥推理引擎 ◄──────────────────── ⑤模型参数            │
│  ┌──────────┐                  ┌──────────┐         │
│  │ 加载参数   │                  │ 权重矩阵   │         │
│  │ 运行计算   │                  │ ~几百亿个  │         │
│  │ 输出Token  │                  │ 浮点数    │         │
│  └──────────┘                  └──────────┘         │
└────────────────────────────────────────────────────┘

下面逐一拆解六个组件：

① 训练数据 —— 模型的"教科书"

大语言模型不是"学会推理"的，而是从海量文本中"统计出规律"的。训练数据的规模和多样性直接决定了模型的能力上限。

• GPT-4 的训练数据据推测约 13 万亿 token（OpenAI 未公开确切数字，此值为业界估算；相当于数千万本书）
• DeepSeek-V3 约 14.8 万亿 token
• 来源：互联网公开文本、书籍、论文、代码仓库、维基百科等

类比：训练数据就像工厂的"原材料"。原材料不够或质量差，工厂设备再先进也产不出好产品。

② Tokenizer（分词器）—— 把文本切成"最小处理单元"

模型不是逐字读文本的，而是先把文本切成 Token。Token 是模型处理的最小粒度。

输入文本："大语言模型如何工作？"
    → Tokenizer 切分 → ["大", "语言", "模型", "如何", "工作", "？"]
    → 映射为 ID     → [12847, 9315, 5632, 2910, 1783, 62]

• 1 个中文约 1-2 个 Token，1 个英文单词约 1-2 个 Token
• Tokenizer 使用 BPE（Byte Pair Encoding）算法，自动发现高频词根
• 同一个 Tokenizer 必须用于训练和推理——换 Tokenizer 等于换"语言"

类比：Tokenizer 是工厂的"分拣机"——把原材料切分成统一规格的零件，后续流水线才能处理。

③ Transformer —— 模型的核心"计算流水线"

Transformer 是 2017 年 Google 提出的神经网络架构，当前所有主流大语言模型都基于它或其变体。它的核心创新是自注意力机制（Self-Attention） ：

传统 RNN 处理序列：
  词1 → 词2 → 词3 → ...        ← 必须按顺序，不能并行，长文本会"遗忘"开头
​
Transformer 自注意力：
  输入所有词 → 每个词同时看所有其他词 → 计算关系权重 → 输出
  词1 ←→ 词2
    ↕    ↕                      ← 所有词两两计算关联度，完全并行
  词3 ←→ 词4

自注意力的直觉理解：

• 输入："她把苹果放进冰箱，然后坐下来吃了一个___"
• 要预测横线上的词，模型需要关注前面的"吃"和"苹果"（不是"冰箱"）
• 自注意力机制自动为每对词计算"关联分数"——"苹果"和"吃"的分数高，"冰箱"和"吃"的分数低

Transformer 由多层（通常几十到上百层）堆叠而成，每层逐步提取更抽象的特征——底层识别词汇和语法，中层理解语义和逻辑，高层进行推理和生成。

类比：Transformer 是工厂的"核心流水线"——原材料经过几十道工序逐级加工，最终产出成品。

④ 词表（Vocabulary）—— 把数字还原为意义

词表是一个巨大的映射表，将 Token ID 映射为向量（一串浮点数）：

• Tokenizer 将文本转为 ID
• 词表将 ID 转为向量（Embedding），例如 ID=12847 → [0.023, -0.154, 0.891, ...]（几千维）
• 这个向量承载了语义信息——语义相近的词，向量也接近

词表大小通常在 5 万到 20 万之间（即模型认识的"词"的数量）。Embedding 向量维度通常在 1024 到 8192 之间。

类比：词表是工厂的"原材料编码手册"——每个零件编号对应一个规格参数表。

⑤ 模型参数 —— 模型学到的"知识"

参数是模型在训练过程中学习到的数以亿计的浮点数（权重）。它们存在于 Transformer 的每一层、每一个注意力头和每一个前馈网络中。

• DeepSeek-V3：6710 亿总参数，每次推理激活约 370 亿（MoE 架构）
• Qwen2.5-7B：70 亿参数，全激活
• 参数量大致决定了模型的"知识容量"，但不是线性关系——架构、数据质量同样重要

参数文件在磁盘上通常以数十到数百 GB 的形式存储（如 .safetensors 或 .gguf），推理时加载到显存或内存中。

类比：参数是工厂的"工艺配方"——同样的流水线（架构），不同的配方（训练出来的参数），产出的产品完全不同。

⑥ 推理引擎 —— 运行模型的"发动机"

推理引擎是加载模型参数并实际执行计算的软件。常见的推理引擎：

引擎	特点	适合场景
Ollama	一键下载量化模型，CPU 友好	本地开发、测试
vLLM	PagedAttention 显存优化，吞吐提升 10-20 倍	生产部署
llama.cpp	C++ 实现，纯 CPU 可运行	嵌入式、边缘设备
云 API	厂商托管，无需自建	快速上线、个人项目

类比：推理引擎就像汽车的发动机——参数是图纸，推理引擎是引擎本体；同一个引擎可以搭配不同的参数（模型），同一个参数也可以在不同的引擎上运行。

六个组件如何协作：一次完整的问答流程

你输入："什么是 AQS？"
    ↓
① Tokenizer 将文本切分为 Token → [688, 312, 9766, 5342, 62]
    ↓
② 词表将每个 Token ID 映射为向量 → 5 个向量，每个 1024 维
    ↓
③ Transformer（堆叠数十层）逐层计算：
    第 1-10 层：理解词义和语法结构
    第 11-30 层：捕捉语义关系和逻辑推理
    第 31-N 层：规划输出内容和顺序
    ↓
④ 输出层产生下一个 Token 的概率分布
    例如：Token "AQS" 后面最可能是 "是"（概率 0.73）、"全称"（概率 0.19）...
    ↓
⑤ 选择概率最高的 Token → 输出 "是" → 将 "是" 添加到输入末尾 → 重复步骤 ③-⑤
    逐 Token 生成，直到输出结束标记（EOS）
    ↓
⑥ 最终输出："AQS 是 AbstractQueuedSynchronizer 的缩写，是 Java 并发包中..."

关键认知：模型不是一次性输出整段回答，而是逐 Token 预测下一个最可能是什么——这个过程重复成千上万次，直到输出终止标记。

---

1.3 从规则到大模型：AI 的四次范式转移

理解 AI 的发展脉络，有助于把握当前技术所处的位置和演进方向。

第一代：符号 AI（1950s-1980s）
  代表：专家系统
  思路：人写规则 → 机器执行
  问题：规则爆炸，无法覆盖开放场景
​
第二代：统计机器学习（1990s-2010s）
  代表：SVM、随机森林、XGBoost
  思路：人设计特征 → 机器学权重
  问题：特征工程依赖专家，泛化能力有限
​
第三代：深度学习（2012-2018）
  代表：CNN、RNN、Transformer
  思路：人设计网络结构 → 机器学特征+权重
  突破：不再需要手工特征，端到端学习
​
第四代：大语言模型 / 基础模型（2018-至今）
  代表：GPT-4、Claude、DeepSeek、GLM
  思路：海量数据预训练 → 自然语言交互 → 涌现推理能力
  突破：单一模型处理数百种任务，不需要为每个任务训练专用模型
  关键转变：从"编程解决问题"到"对话解决问题"

AI 的发展本质上就是不断减少"人工"、增加"智能"的过程——从人写规则到人设计特征，再到人设计网络结构，现在是人描述需求。

1.4 大语言模型的训练与推理

一个模型的完整生命周期分为三个阶段：

第一阶段：预训练（Pre-training）——"学会语言"

在海量文本上做"完形填空"：给前半句预测后半句。训练过程遍历数万亿 token 的文本，用数千张 GPU 运行数周到数月。这个阶段模型学到了语言模式、世界知识、推理能力。

第二阶段：对齐（Alignment）——"学会好好说话"

预训练后的模型"什么都懂但不会好好说话"。对齐阶段用人类偏好数据教模型：什么是有用的回答、什么是安全的回答、什么该拒绝。主流对齐方法 DPO（Direct Preference Optimization）直接用好/坏回答对优化，替代了传统复杂的 RLHF。

第三阶段：推理（Inference）——"回答问题"

即每一次调用模型的过程。关键认知：每次推理是独立的——模型不记忆和你的对话，对话记忆是应用层管理的（把历史消息重新发回去）。这也是 Token 消耗的核心——对话越长，每次推理越贵。

预训练决定了模型的 "知识天花板"，对齐决定了模型的 "表达方式"，推理则是应用开发者和模型交互的唯一接口。大部分 AI 应用开发工作集中在推理阶段——如何构造 Prompt、如何管理上下文、如何解析输出。

1.5 核心概念速查

以下为 AI 应用开发必须掌握的核心概念：

概念	一句话	工程意义
LLM	在海量文本上预训练的大规模神经网络，通过预测下一个 token 来理解和生成文本	AI 应用的核心引擎。本质是概率模型，不可 100% 信赖
Token	AI 处理文本的最小粒度，1 中文≈1-2 token，按 token 计费	决定了 API 调用的成本和上下文管理策略
上下文窗口	模型一次能"看到"的最大文本量	决定了信息加载策略——不能无脑塞全量文档
Embedding	把文本映射成一串数字（向量），语义相近的文本向量距离近	RAG 的根基。不同 Embedding 模型产生的向量不可混用
幻觉	AI 自信地编造不存在的事实、API、引用	AI 应用的第一大风险。应对策略：RAG 绑定来源、结构化输出约束格式
思维链（CoT）	让 AI 一步步推理而非直接给答案	复杂推理任务的标配。DeepSeek-R1 内置推理，普通模型可在 Prompt 中手动触发
Agent	AI 自主规划→调工具→观察结果→调整→完成任务	从"聊天机器人"到"能干活的系统"的关键跃升
RAG	先检索相关文档，再基于文档生成回答	解决 LLM 知识截止日期和幻觉问题的首选方案
MCP	Model Context Protocol，AI 与外部工具的统一连接协议	让 AI 工具从"N×M 次一对一集成"变成"N+M 次统一对接"
Function Calling	Agent 调用工具的底层机制——模型输出结构化 JSON 指定调哪个函数	Agent 的"手"——没有它 AI 只能聊天

进阶概念（了解即可）：

概念	全称/含义	一句话	属于
MoE	Mixture of Experts	总参数大但每次只激活一小部分，DeepSeek 的标志性架构	模型架构
LoRA	Low-Rank Adaptation	不改原模型参数，在旁路训练极小参数包。全量微调=重写整本书，LoRA=贴便签纸	模型微调
QLoRA	Quantized LoRA	LoRA 的省钱版——先把模型压到 4-bit 再贴便签纸	模型微调
DPO	Direct Preference Optimization	直接用好/坏回答对优化模型，替代复杂的 RLHF	模型对齐
vLLM	—	开源推理引擎，PagedAttention 显存优化 + Continuous Batching	模型部署
量化	Quantization	FP16→INT4，体积缩 4 倍、速度提 2-4 倍。Ollama 默认 Q4_K_M	模型部署
语义缓存	Semantic Cache	不是缓存 key-value，是缓存"语义相似的问题"——相似度>0.95 直接返回	成本优化
结构化输出	JSON Schema 约束	LLM 按预定义 Schema 返回 JSON，确保下游代码可解析	输出控制
BYOK	Bring Your Own Key	平台不提供模型额度，用户自带 API Key	架构模式

---

二、AI 模型与工具生态

⚠️ 时效性提示：模型版本迭代极快（通常 3-6 个月一次大版本更新）。下表基于 2026 年 7 月的信息，阅读时请以各厂商最新公告为准。建议关注模型的能力定位（而非具体版本号）。

2.1 主流模型对比与选型

国外模型

模型系列	核心优势	短板	适合场景
Claude 系列	Agent 能力最强，多文件理解+安全设计	国内访问不便	大型重构、项目级 Agent
GPT 系列	推理深度最强	贵、国内访问不便	高难度算法、架构评审
Gemini 系列	多模态最强（图+视频+代码）	中文弱	多模态场景、Google 生态
Llama 系列（开源）	可本地部署，数据不出域	编码能力约闭源 70%	数据合规、二次训练、金融场景

国内模型

模型系列	核心优势	适合场景
DeepSeek 系列	性价比之王（约 GPT 1/70 价格），中文编程最优	日常编码首选
GLM 系列（智谱）	国产合规首选，政务/金融信创认证	信创合规项目
Qwen 系列（阿里）	阿里云生态集成好	阿里云技术栈
Kimi 系列（月之暗面）	超长上下文（可达 200 万字），长文档分析突出	需求评审、代码库理解

选型决策框架

日常编码 / SQL 优化 → DeepSeek 系列（性价比+中文编程）
大型重构 / 多文件修改 → Claude 系列（Agent 能力最强）
复杂算法推理 → GPT 系列 / DeepSeek R1 系列（思维链深度）
长文档分析 → Kimi 系列（超长上下文）
信创合规 → GLM 系列 + 本地部署（国产化认证）
​
推荐组合：DeepSeek（日常）+ Claude（复杂）+ Kimi（长文档）

常见误区：

• 最强模型 ≠ 最适合（CRUD 用最贵模型是浪费）
• 开源模型 ≠ 免费（GPU 月租 5000+）
• 没有一个模型在所有维度最好——组合策略是最优解

2.2 AI 编程助手

工具	定位	一句话评价
Claude Code	Agent 级 CLI	项目级理解+多文件编辑+MCP 扩展，Agent 能力最强
GitHub Copilot	IDE 行级补全	"猜下一行"最准，行级补全王者
Cursor	AI-native IDE	IDE 深度集成 Agent，体验流畅
Cline	VS Code 插件	开源 Agent，多模型支持
Aider	CLI 开源	自动 git 提交

选择原则：日常编码 Claude Code，快速补全 Copilot，前端调试 Cursor。没有银弹——根据任务切换工具。

---

大模型的"脚手架"：MCP、Skills、Hooks

如果把大模型比作一台发动机，那么它要真正"驱动一辆车"，还需要三样东西：

• MCP：连接外部世界的"管道"——让 AI 能访问数据库、调用 API、操作文件
• Skills：标准化的"操作手册"——把常见任务封装成可复用的工作流
• Hooks：自动化的"安全护栏"——在关键节点自动检查和拦截

三者共同构成大模型的工程化脚手架。它们不是模型的一部分，但没有它们，模型只能停留在"聊天界面"里。

---

2.3 MCP — 连接 AI 与工具的通用协议

概念：MCP 是什么

MCP（Model Context Protocol）是 Anthropic 于 2024 年 11 月发布的开放标准协议，目标是成为"AI 应用的 USB 协议"——正如 USB 让任何外设都能接入任何电脑，MCP 让任何工具都能被任何 AI 应用调用。

没有 MCP 时：每接入一个新工具（数据库、文件系统、搜索引擎、API），开发者都要为每个 AI 应用单独写适配代码。N 个 AI 应用 × M 个工具 = N×M 次集成。

有 MCP 后：工具只需实现一次 MCP Server，所有支持 MCP 的 AI 应用自动可用。N 个 AI 应用 + M 个工具 = N+M 次对接。

架构与原理

MCP 采用经典的 Client-Server 架构，基于 JSON-RPC 2.0 协议通信：

┌─────────────┐                    ┌──────────────────┐
│  MCP Host   │  ── JSON-RPC ──►  │   MCP Server     │
│  (Claude/   │  ◄── 双向通信 ──  │                  │
│   Cursor/   │                    │  实现三个原语：    │
│   自研 App)  │  tools/list        │  • Tools（工具）   │
│             │  tools/call        │  • Resources（资源）│
│             │  resources/read    │  • Prompts（模板）  │
│             │  prompts/get       │                  │
└─────────────┘                    └──────────────────┘

三个核心原语（MCP 暴露给 AI 的三类能力）：

原语	用途	类比	例子
Tools	让 AI 执行操作	函数调用	查数据库、发邮件、创建 Issue
Resources	让 AI 读取数据	GET 请求	读文件内容、查配置、获取日志
Prompts	预定义的提示词模板	快捷指令	"代码审查清单"、"提交信息生成"

传输层——MCP 支持两种通信方式：

方式	通信机制	适合场景	例子
stdio	标准输入/输出，进程间通信	本地工具、CLI 场景	文件系统 Server、Git Server
HTTP + SSE	HTTP 请求 + Server-Sent Events 流式推送	远程服务、多客户端共享	数据库 Server、企业内部 API Server

MCP 的完整生命周期：

1. 初始化（Handshake）
   Client → Server: initialize { clientInfo, capabilities }
   Server → Client: initializeResult { serverInfo, capabilities }
​
2. 能力发现（Discovery）
   Client → Server: tools/list     → Server 返回: [{name, description, inputSchema}, ...]
   Client → Server: resources/list → Server 返回: [{uri, name, mimeType}, ...]
​
3. 操作执行（Operation）
   Client → Server: tools/call { name: "query_db", arguments: { sql: "..." } }
   Server → Client: { content: [{ type: "text", text: "查询结果..." }] }
​
4. 资源读取（Resource Access）
   Client → Server: resources/read { uri: "config://app/settings" }
​
5. 断开（Shutdown）
   Client → Server: notifications/cancelled
   Client → Server: disconnect

用法：如何配置和使用 MCP

以 Claude Code 为例，在 settings.json 中配置 MCP Server：

{
  "mcpServers": {
    "context7": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp@latest"],
      "env": {}
    },
    "postgres": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@anthropic/mcp-server-postgres", "postgresql://localhost/mydb"]
    },
    "github": {
      "type": "http",
      "url": "https://mcp-server.example.com/github",
      "headers": { "Authorization": "Bearer ${GITHUB_TOKEN}" }
    }
  }
}

常用 MCP Server 分类

类别	推荐 Server	一句话功能
文档	Context7	实时查最新版本文档，消除幻觉 API
数据库	PostgreSQL / SQLite / Redis	AI 直连数据库执行查询和 Schema 分析
浏览器	Puppeteer / Chrome DevTools	截图、填表、E2E 自动化测试
开发工具	GitHub / GitLab	PR 审查、Issue 管理、代码搜索
容器	Docker / Kubernetes	容器管理、Pod 日志查询
搜索	Brave Search / Tavily / Exa	实时网络搜索
文件	Filesystem	读写文件、目录遍历

价值：MCP 改变了什么

0. 标准化：工具开发者只需实现一次 MCP Server，所有 AI 应用都能复用
1. 热插拔：新增工具不需要改 AI 应用代码、不需要重新部署
2. 生态效应：社区已有 10000+ MCP Server
3. 安全边界：MCP Server 运行在独立进程中，权限隔离

注意：MCP 的价值在于规模——如果你的应用只有 2-3 个固定工具且短期内不会扩展，Function Calling 足够。当工具数量增长、需要跨应用复用时，MCP 的优势开始显现。

---

2.4 Skills — 封装可复用的 AI 工作流

概念：Skill 是什么

Skill 是把"固定套路"封装成一个可复用的能力包——相当于给 AI 写了一份"标准操作程序（SOP）"。激活 Skill 后，AI 自动获得完成该任务所需的全部上下文、规则和步骤。

类比：Skill 之于 AI，如同"制造工艺卡"之于工厂——不是机器本身的能力，但规定了机器该按什么顺序、用什么参数、检验什么标准来完成特定产品。

原理：Skill 如何工作

加载机制：

用户输入 /skill-name 或 AI 自动匹配
  → 系统读取 SKILL.md（Skill 的核心文件）
  → 内容注入到 System Prompt（优先级高于默认系统提示词）
  → AI 获得该 Skill 的专用知识、规则、工作流
  → 执行过程中严格遵循 Skill 中定义的步骤
  → Skill 执行完毕，专用上下文释放

Skill 的三种来源：

类型	位置	谁维护	范围
项目级	项目的 .claude/skills/	项目团队	当前项目
个人级	用户的 ~/.claude/skills/	个人	所有项目
插件级	通过插件管理器安装	社区/第三方	全局

创建 Skill 的核心原则

0. 一个 Skill 只做一件事——职责单一
1. 站在 AI 的视角写指令——"遇到 X 情况执行 Y 步骤"
2. 包含具体示例——AI 从示例中比从规则中学习得更准确
3. 写清楚失败处理——"如果文件不存在，提示用户检查路径，不要自行创建"

价值：Skill 改变了什么

0. 知识捕获：把"老员工脑子里的经验"变成"新人运行 /skill-name 就能执行的流程"
1. 效率跃升：从人工几十小时降到 AI 自动几分钟完成
2. 质量一致：每次执行同一 Skill，产出物的格式、检查点完全一致
3. 团队杠杆：一人写好 Skill，全团队受益

---

2.5 Hooks — 事件驱动的自动化守卫

概念：Hook 是什么

Hooks 是 AI 操作关键节点上的"自动哨兵" ——到达触发点时自动执行预设的检查脚本，不通过则拦截操作。

类比：Hooks 之于 AI 操作，如同 CI/CD Pipeline 的各个 Gate 之于代码提交——lint 不过不能合入、测试不过不能部署。

四种 Hook 类型

Hook 类型	触发时机	典型用途
PreToolUse	工具执行前	"即将执行 rm -rf，确认目标路径不在保护列表中"
PostToolUse	工具执行后	"写完文件了，自动运行 prettier 格式化"
Stop	会话结束前	"退出前检查：还有未提交的 TODO 吗？测试过了吗？"
SessionStart	会话启动时	"加载项目上下文，注入自定义规则"

Hook 的执行流

用户请求 AI 执行某个操作
  →
┌─ 匹配到 PreToolUse Hook？ ──是──→ 执行 Hook 脚本 ──→ 返回结果
│                                    ├── allow：继续执行
│                                    ├── deny：拦截操作 + 返回原因
│                                    └── modify：修改参数后继续
└─ 未匹配 → 正常执行
  →
AI 操作执行完成
  →
┌─ 匹配到 PostToolUse Hook？ ──是──→ 执行 Hook 脚本（格式化/记录/通知）
└─ 未匹配 → 流程结束

关键特性：Hook 是同步阻塞的——PreToolUse 返回 deny 时，操作不会发生。这是安全的底线设计。

实战模式

模式 1：改文件前自动检查（PreToolUse） ：检查目标文件是否在"受保护文件列表"中（如 production.yml, .env），若是则返回 deny。

模式 2：改完后自动格式化 + 记录（PostToolUse） ：运行 prettier / clang-format，将变更记录追加到 CHANGELOG。

模式 3：会话结束前质量检查（Stop） ：git diff 检查未提交变更、grep 检查遗留 TODO、运行单元测试确认全部通过。

Skill vs Hook 的区别：Skill 是 AI 的"操作手册"（告诉它能做什么、怎么做），Hook 是 AI 的"交通规则"（告诉它什么不能做、做完要检查什么）。Skill 是增强能力，Hook 是约束行为——两者缺一不可。

---

三、Prompt Engineering — 从写提示词到管资产

3.1 Prompt 六要素

个人使用 Prompt 和工程化 Prompt 的区别，就像个人写脚本和团队开发系统——前者能跑就行，后者需要可维护、可测试、可追溯。

六要素模板：

① 角色："你是 5 年 Spring Boot 开发，熟悉金融系统规范"
② 任务：一个 Prompt 只聚焦一个任务
③ 上下文：@引用相关代码 + 业务规则说明
④ 约束："保持现有方法签名不变"、"不要引入新第三方依赖"
⑤ 输出格式：指定结构（正常3个 + 边界2个 + 异常2个）
⑥ 示例：@ExistingTest.java "新测试风格保持一致"

对比：

• ❌ "帮我优化这段代码"
• ✅ "这段代码在 Oracle→OceanBase 迁移中性能下降 50%。分析执行计划，找出瓶颈，给 2-3 种改写方案，保持语义等价。@SlowQuery.sql"

实用技巧：

• "一步一步思考" → 触发思维链
• "先给方案，确认后再写代码" → 避免方向错误
• "不对，XXX 应该是 YYY" → AI 根据反馈即时调整

3.2 思维链（CoT）与推理模型

思维链（Chain of Thought）的本质是让模型把隐式的推理过程显式化。研究表明，对于数学推理、逻辑分析等复杂任务，CoT 能将准确率从 30% 提升到 80% 以上。

两种触发方式：

• 手动触发：Prompt 中加"请一步一步思考"或"先分析再给出结论"
• 模型内置：DeepSeek-R1 在训练时就学习了推理模式，调用时自动进行

何时需要 CoT：多步骤推理、多条件权衡。不需要 CoT 时不要硬加——会增加 Token 消耗和延迟。

3.3 结构化输出 + 流式响应

这是 AI 应用输出的两个维度，不是二选一，而是标配：

结构化输出（JSON Schema） ——控制"输出什么格式"：

• 出题：{"type":"选择","stem":"...","options":[...],"answer":"A"}
• 评分：{"score":85,"correctness":4,"weakness":["CAS"]}
• 意图分类：{"intent":"解题","subject":"AQS","difficulty":"中等"}
• 没有结构化输出 → 用正则从自由文本里抠数据 → 脆弱不可靠

流式响应（SSE） ——控制"输出怎么呈现"：

• LLM 逐 token 返回，用户看到文字一个个出现
• 没有流式 → 用户等 10 秒看空白页 → 体验不可接受

两者配合：LLM 流式输出 JSON 字符串 → 前端一边接收 chunks 一边展示 → 收到完整 JSON 后做最终解析和校验。这是当前主流做法。

3.4 Prompt 工程化管理

当你的 AI 应用有 5+ 种场景时，Prompt 就不是"写一段话存备忘录"了——它是一套需要版本管理的代码资产。

PrismAI 的 Prompt 管理实践完整展示了这套体系：

模板分类：出题 / 评估 / 追问 / 简历 / 意图 —— 5 种场景各有独立模板
方向绑定：会计出题提示词 ≠ Java 出题提示词，每个方向可配置专属模板
变量占位符：{{备考方向名称}} {{检索关键词}} {{题型列表}} {{难度}}
版本管理：tb_prompt_template + tb_prompt_version 两张表，每次修改留历史
升级门禁：模板升级前跑离线评估集，Faithfulness 低于阈值不发布
删除保护：被备考方向引用的模板不可直接删除
默认回退：未配置专属模板的方向，使用系统默认模板

工程化带来的好处：

0. 改 prompt 不用发版——管理员后台编辑即可
1. prompt 质量可追溯——版本对比知道"改了哪句话导致质量变化"
2. 知识可复用——"Java 出题提示词 v1.3"可被多个 Java 相关方向共享

---

核心要点回顾

0. 六组件工厂模型（训练数据→Tokenizer→Transformer→词表→参数→推理引擎）是理解任何大模型工作流程的通用框架
1. 模型选型没有银弹——组合策略（DeepSeek日常+Claude复杂+Kimi长文档）是最优解
2. MCP 的生命周期（初始化→发现→执行→断开）比"MCP=USB"这个简单比喻重要得多——实际工程中需要的是前者
3. Skill vs Hook：一个增强能力，一个约束行为——两者配合形成 AI 工程化闭环
4. Prompt 是代码资产——需要模板化、版本化、可测试、可回滚

---

下一篇预告

《RAG 从入门到工程落地》 ——检索增强生成是 AI 应用开发中最核心的技术范式。下一篇将展开：文档切分策略（固定/语义/递归）、Embedding 模型的对比学习原理、混合检索（向量+BM25）、三代 RAG 评估体系、CRAG 的完整工作机制，以及 PrismAI 的 RAG 全链路代码走读。

这篇是全系列的地基。后面 11 篇会把每个组件逐个拆开——RAG、Agent、图片生成、部署、Claude Code，都有代码走读和实战。 点赞+收藏，你的支持是我写完 12 篇的最大动力 🙏 下一篇：《RAG从入门到工程落地：切分/Embedding/CRAG代码走读》 系列合集：掘金AI合集 配套代码：PrismAI