AI 工程化實戰(zhàn)：不學(xué)算法也能用好的 LLM 指南

本文全面介紹了大模型相關(guān)知識，包括大模型（LLM）、提示詞工程（PE）、檢索增強(qiáng)生成（RAG）、工具調(diào)用（Function Calling）、模型上下文協(xié)議（MCP） 等，適合零基礎(chǔ)小白入門。

近些年，AI 的發(fā)展速度越來越快，越來越多的業(yè)務(wù)開始尋求“AI 賦能”。面對這個黑盒，很多研發(fā)人員的反應(yīng)是疑惑：“我需要學(xué)習(xí)神經(jīng)網(wǎng)絡(luò)算法嗎？我要懂 Transformer 架構(gòu)嗎？”

其實，對于非算法人員，我們不需要成為研發(fā)「發(fā)動機(jī)」的算法科學(xué)家，而是要成為能夠駕馭「賽車」的 AI 工程師。我們無需深究底層的數(shù)學(xué)原理，但必須洞察它的能力邊界，知道如何將這個“黑盒能力”高效、穩(wěn)定地融入到我們的業(yè)務(wù)系統(tǒng)中。

一. 大模型

傳統(tǒng)編程：顯式的邏輯規(guī)則

作為研發(fā)人員，我們的日常工作本質(zhì)上就是在定義各種函數(shù)。在傳統(tǒng)的軟件工程中，這些函數(shù)的內(nèi)部邏輯是確定性的。比如判斷一個人是否成年，可以寫出以下函數(shù)：

}

在這種模式下，我們明確知道輸入什么參數(shù)，經(jīng)過怎樣的判斷，一定會得到確定的輸出。

但當(dāng)我們面對“識別圖片中是貓還是狗”或“總結(jié)一篇文檔”這類任務(wù)時，規(guī)則變得極其復(fù)雜且模糊，此時我們無法寫一個確定性的函數(shù)來完成對應(yīng)的任務(wù)。

機(jī)器學(xué)習(xí)：擬合復(fù)雜的函數(shù)

既然無法手寫復(fù)雜規(guī)則，機(jī)器學(xué)習(xí)便放棄了“直接定義邏輯”的思路，轉(zhuǎn)而通過算法讓機(jī)器在大規(guī)模數(shù)據(jù)中自動尋找規(guī)律，從而擬合出那個極其復(fù)雜的函數(shù)。

具體而言，機(jī)器學(xué)習(xí)會首先構(gòu)建一個巨大的數(shù)學(xué)模型（神經(jīng)網(wǎng)絡(luò)），通過訓(xùn)練來修正模型內(nèi)部的權(quán)重和偏差。訓(xùn)練的過程，本質(zhì)上是一個迭代“試錯”的過程：

1. 預(yù)測：模型基于當(dāng)前參數(shù)對輸入數(shù)據(jù)做出預(yù)測（初始階段基本是隨機(jī)“瞎猜”）。

2. 反饋：當(dāng)發(fā)現(xiàn)預(yù)測值與真實標(biāo)簽不符時（例如將貓誤認(rèn)為狗），算法會計算兩者之間的誤差。

3. 微調(diào)：利用數(shù)學(xué)方法（反向傳播）回溯并微調(diào)內(nèi)部的權(quán)重參數(shù)，目標(biāo)是減小誤差，讓下一次預(yù)測更準(zhǔn)。

經(jīng)過數(shù)百萬次的重復(fù)訓(xùn)練，模型最終能基本精準(zhǔn)地將輸入映射到輸出。此時，我們便得到了一個擬合好的函數(shù)。即便面對從未見過的數(shù)據(jù)，它也能根據(jù)從海量樣本中提取出的特征規(guī)律，給出相應(yīng)的判斷。

需要注意的是： 機(jī)器學(xué)習(xí)得到的函數(shù)是一個概率模型。它不像傳統(tǒng)代碼那樣保證 100% 的絕對準(zhǔn)確，而是在統(tǒng)計學(xué)上不斷逼近正確答案。因此它天然存在出錯的可能——即便是一張清晰的貓，模型仍有極小的概率產(chǎn)生偏差，將其識別成狗。

大模型（LLM）：量變引起的“涌現(xiàn)”

在傳統(tǒng)機(jī)器學(xué)習(xí)時代，參數(shù)量通常在幾百萬到幾億級別，且大多是專用型的：識圖模型無法處理翻譯任務(wù)，翻譯模型無法編寫代碼等。

而當(dāng)參數(shù)量和訓(xùn)練數(shù)據(jù)突破臨界點(diǎn)（如 GPT-3的千億級參數(shù)）時，發(fā)生了神奇的“涌現(xiàn)現(xiàn)象”，模型的能力發(fā)生了質(zhì)的飛躍（這類大參數(shù)量模型被稱為大模型）：

• 通用性：在學(xué)習(xí)預(yù)測萬億級語料的過程中，它自然而然地掌握了摘要、翻譯、代碼編寫等多種能力，成為了一個可以處理幾乎所有自然語言任務(wù)的“通用大腦”。

• 上下文學(xué)習(xí)：不需要修改模型參數(shù)，只需在提示詞（Prompt）里給出幾個示例（Few-Shot），模型就能憑借強(qiáng)大的學(xué)習(xí)能力，快速適配新任務(wù)并執(zhí)行。

以 GPT (Generative Pre-trained Transformer) 為例，盡管其功能看似復(fù)雜，但底層核心機(jī)制十分純粹，類似于“成語接龍”：

• 輸入：用戶的提示詞 + 模型已經(jīng)生成的上文（比如 “床前明月”）。

• 預(yù)測：模型在詞表中計算下一個最可能出現(xiàn)的詞的概率分布（就像接龍時想 “床前明月” 后面該接 “光”）。

• 輸出：模型通常選取概率最高的詞（例如輸出 “光”），將該詞拼接到原有輸入中，形成新的上下文（“床前明月光”），再進(jìn)入下一輪預(yù)測，直至觸發(fā)結(jié)束標(biāo)志。

二. 提示詞工程

什么是 PE?

我們已經(jīng)知道 LLM 本質(zhì)上是一個“概率預(yù)測機(jī)”，它讀取文本，計算概率，預(yù)測下一個詞，循環(huán)往復(fù)。在這個過程中，我們給 LLM 的所有輸入統(tǒng)稱為 Prompt（提示詞）。

但這里有個工程難題：如果輸入是發(fā)散的，輸出必然也是發(fā)散的。

舉個例子，我們想讓 LLM 判斷用戶反饋是正面還是負(fù)面：

寫法 A：這條評論是正面的還是負(fù)面的？用戶說界面太丑了，卸載了。

LLM 可能這樣回答：

• "是負(fù)面的。"

• "負(fù)面情緒"

• "這條評論表達(dá)了用戶的負(fù)面情緒，因為他說界面太丑，還卸載了應(yīng)用。"

三種回答都對，但格式完全不同。這在聊天時沒問題，但如果你的程序需要解析這個結(jié)果（比如存入數(shù)據(jù)庫、觸發(fā)告警），這種不統(tǒng)一的格式簡直是開發(fā)者的噩夢。

寫法B：你是一個情感分析專家。請判斷以下用戶反饋的情感傾向，只返回"正面"或"負(fù)面"，不要輸出任何解釋：
用戶反饋："界面太丑了，卸載了！"

這一次 LLM 的輸出就很穩(wěn)定：負(fù)面。

為什么？因為寫法 A 模棱兩可，LLM 不知道你想要什么格式；寫法 B 明確了角色、任務(wù)和輸出要求。

這就是提示詞工程（Prompt Engineering）的核心：通過精心設(shè)計 Prompt，讓 LLM 的輸出更穩(wěn)定、更準(zhǔn)確、更符合業(yè)務(wù)需求。

在聊天場景下，我們和 LLM 對話是"發(fā)散"的，它可能會說很多無關(guān)緊要的話，輸出格式也可能隨機(jī)變化。但一旦要把 LLM 接入業(yè)務(wù)系統(tǒng)，問題就來了：程序需要解析 LLM 的返回結(jié)果，一個格式不對的 JSON 就能讓整個系統(tǒng)崩潰。

因此，PE 的核心目標(biāo)是從“自由對話”轉(zhuǎn)向“工程化協(xié)議”，就像調(diào)用 API 需要構(gòu)造請求參數(shù)、定義返回格式一樣，Prompt 就是這個"人機(jī)接口的協(xié)議" 。

如何寫好 PE？

寫 Prompt 就像給實習(xí)生布置任務(wù)：你說得越清楚，他干得越靠譜。我們繼續(xù)用"判斷用戶反饋情感"這個例子，看看如何逐步優(yōu)化。

(1) 先把話清楚：明確角色和任務(wù)

第一步是“定義人設(shè)”，告訴 LLM：你是誰，要做什么。在 API 開發(fā)中，這通常通過 System Prompt（系統(tǒng)提示詞） 來實現(xiàn)。

• 角色定義："你是一個情感分析專家"——這樣 LLM 會自動調(diào)整"專業(yè)程度"，知道要從用戶反饋中提取情感信號。

• 任務(wù)指令："請判斷用戶反饋的情感傾向"——不要讓 LLM 去猜你想干什么，直接說清楚。

# 角色
你是一個情感分析專家，擅長從用戶反饋中識別情緒。
# 任務(wù)
請判斷用戶反饋的情感傾向，只返回"正面"或"負(fù)面"：

（2）給出模板：讓 LLM 照著做

直接下指令，LLM 有時仍會“放飛自我”。比如你要求“只返回正面或負(fù)面”，它可能會輸出“這條反饋是負(fù)面的”或者“Negative”。這些都是"負(fù)面"的意思，但格式不一致。這時候，給他幾個示例最有效，這叫 少樣本學(xué)習(xí)（Few-Shot Learning）。

# 角色
你是一個情感分析專家，擅長從用戶反饋中識別情緒。
# 任務(wù)
請判斷用戶反饋的情感傾向，只返回"正面"或"負(fù)面"：
# 示例
## 示例1輸入：
這個APP太棒了！
## 示例1輸出：
正面
## 示例2輸入：
用了一天就崩了，垃圾軟件。
## 示例2輸出：
負(fù)面

就像給實習(xí)生一個"參考答案模板"，他看了幾個例子，自然就明白該怎么干了。而且這不需要重新訓(xùn)練模型，完全靠 LLM 強(qiáng)大的"上下文學(xué)習(xí)能力"，給它幾個例子，它就能學(xué)會新任務(wù)的規(guī)律。

（3）讓它慢下來：逐步推理

在處理復(fù)雜情感時（比如陰陽怪氣、轉(zhuǎn)折句），LLM 容易直接“跳步”給錯答案。比如用戶評論：“界面漂亮但反應(yīng)慢、想卸載”。LLM 可能看到“漂亮”就直覺式地判斷為“正面”。

如果加一句話： "請逐步思考（Let's think step by step）" ，準(zhǔn)確率會神奇地提升。這就是 CoT（Chain of Thought，思維鏈）。

LLM 的內(nèi)部邏輯流會變?yōu)椋?/strong>

1. 關(guān)鍵詞提取：“界面漂亮”（正）、“反應(yīng)慢”（負(fù)）、“想卸載”（極負(fù)）。

2. 意圖分析：雖然有視覺上的夸贊，但最終行為是卸載，表達(dá)了強(qiáng)烈的挫敗感。

3. 最終結(jié)論：負(fù)面。

核心邏輯： 強(qiáng)迫 LLM 先把推理過程寫出來，這個過程會成為后續(xù)生成的“上下文”，相當(dāng)于模型在“自我檢查”，確保結(jié)論是推導(dǎo)出來的，而不是“猜”出來的。

# 角色
你是一個情感分析專家，擅長從用戶反饋中識別情緒。
# 任務(wù)
請判斷用戶反饋的情感傾向。請逐步思考后再輸出結(jié)果。只返回"正面"或"負(fù)面"：
# 示例
## 示例1輸入：
這個APP太棒了！
## 示例1輸出：
正面
## 示例2輸入：
用了一天就崩了，垃圾軟件。
## 示例2輸出：
負(fù)面

（4）格式約束：讓程序能讀懂

前面解決的是“答得對”，但在代碼場景下，還有一個關(guān)鍵問題：讓 LLM “答得能被程序解析”。

業(yè)務(wù)系統(tǒng)中，我們通常希望 LLM 返回 JSON 這種結(jié)構(gòu)化數(shù)據(jù)。但 LLM 是個“話癆”，你讓它返回 JSON，它可能隨口回一句：“好的，這是你要的結(jié)果：{...}”。這多出來的幾個字，就會導(dǎo)致 json.loads() 直接報錯。

為了解決這個問題，工程上通常采用“事前約束 + 事后糾錯”的組合拳：

1. 結(jié)構(gòu)化 Prompt（事前約束）

• 直接給模型一個標(biāo)準(zhǔn)的 JSON 模板，并約束它不要輸出多余的解釋。

# 角色
你是一個情感分析專家，擅長從用戶反饋中識別情緒。
# 任務(wù)
請判斷用戶反饋的情感傾向并分析原因。請逐步思考后再輸出結(jié)果。
# 輸入格式
{
"feedback": " <用戶反饋內(nèi)容> "
}
# 輸出格式
{
"sentiment": "正面/負(fù)面",
"reason": " <原因分析> "
}
# 約束
1. 必須僅返回 JSON 數(shù)據(jù)，禁止任何解釋性文字
2. sentiment 字段只能是 "正面" 或 "負(fù)面"
# 示例
## 示例1輸入
{"feedback": "這個APP太棒了！"}
## 示例1輸出
{"sentiment": "正面", "reason": "用戶對產(chǎn)品表示滿意"}
## 示例2輸入
{"feedback": "用了一天就崩了，垃圾軟件。"}
## 示例2輸出
{"sentiment": "負(fù)面", "reason": "用戶遇到穩(wěn)定性問題"}

2. 工程化魯棒性（事后糾錯） 在實際業(yè)務(wù)中，單靠 Prompt 依然會有概率遇到非法格式。研發(fā)通常會引入以下兜底方案：

• 原生 JSON 模式：調(diào)用 API 時開啟模型自帶的 response_format: { "type": "json_object" } 模式，強(qiáng)制模型輸出。（如果平臺支持的話）。

• 自動修復(fù)（Repair）：使用類似 json_repair 的庫。這些庫利用算法修復(fù)模型輸出中缺失的引號、括號或多余的解釋語。

• 重試機(jī)制（Retry）：如果解析失敗，自動進(jìn)行 2-3 次重試，或者在重試時把錯誤信息返還給模型（“你剛才返回的格式錯了，請修正”）。

三. 檢索增強(qiáng)生成

PE（提示詞工程）解決了讓大模型“更聽話”的問題，但即便再會寫 Prompt，大模型本質(zhì)上仍是一個靜態(tài)的知識庫（它的記憶停留在訓(xùn)練結(jié)束的那一天）。它有兩大無法克服的缺陷：幻覺和知識滯后。

• 幻覺（一本正經(jīng)的胡說八道）：無論我們對大模型說些什么，它都會通過“概率預(yù)測”生成一段回答，這段回答看起來很專業(yè)，但可能完全是錯誤的，就像學(xué)生在考試時遇到不會的題，憑借“直覺”編一個聽起來像樣的答案。

• 知識滯后（不知道最新的事）：LLM 無法實時獲取信息。無法用它來查詢公司最新的內(nèi)部文檔或今天的實時銷售數(shù)據(jù)。

為了解決這些問題，就誕生了RAG (Retrieval-Augmented Generation，檢索增強(qiáng)生成) ，它將大模型的“生成能力”與傳統(tǒng)數(shù)據(jù)檢索的“準(zhǔn)確性”結(jié)合起來，給大模型外掛一個“實時更新的知識庫”。

如果把大模型直接回答問題比作“閉卷考試”，那么 RAG 就是讓它變成一個“開卷考試”的學(xué)生。

• 閉卷模式：由于模型沒學(xué)過公司的私有文檔，它只能憑直覺“編”。

• 開卷模式（RAG）：

• 1. 翻書（檢索）：當(dāng)用戶提問時，系統(tǒng)先去內(nèi)部文檔庫里搜索相關(guān)的段落。

  2. 摘抄（增強(qiáng)）：把找到的準(zhǔn)確信息“抄”在 Prompt 里，作為背景參考資料。

  3. 作答（生成）：最后讓大模型根據(jù)這些“參考資料”來組織語言回答。

這樣，AI 就不再是憑空想象，而是“有據(jù)可查”。要把這套“開卷考試”系統(tǒng)跑通，需要經(jīng)歷以下核心步驟：

第一步：準(zhǔn)備階段 —— 語義向量化

計算機(jī)讀不懂文字，它只懂?dāng)?shù)字。我們需要把文字轉(zhuǎn)換成一種數(shù)學(xué)表達(dá)，這就是 Embedding（詞嵌入）。

• Embedding 模型：這是一種特殊的模型，它能把文本映射成一串高維數(shù)組（向量）。

• 核心邏輯：語義相近的文本，在數(shù)學(xué)空間里的“距離”也更近。 比如，“貓”和“小貓”的向量距離，會比“貓”和“挖掘機(jī)”近得多。這使得“語義搜索”成為可能。

第二步：檢索階段 —— 向量數(shù)據(jù)庫

有了向量，我們需要一個專門的“倉庫”來存儲和查詢它們。

• 入庫：我們將公司文檔切割成一個個小段（Chunking），算出向量，存入向量數(shù)據(jù)庫。

• 查詢：當(dāng)用戶問“怎么申請年假？”時，系統(tǒng)先算出這個問題的向量。

• 搜索：向量數(shù)據(jù)庫會瞬間找出倉庫里和該問題“空間距離最近”的文檔段落（這就是 Top-K 檢索）。

第三步：生成階段 —— Prompt 增強(qiáng)

這是最關(guān)鍵的一步，當(dāng)系統(tǒng)從向量數(shù)據(jù)庫中檢索出相關(guān)的文檔段落后，需要把這些資料和大模型連接起來。怎么做？很簡單：把檢索到的資料作為"上下文"，嵌入到 Prompt 里。這樣，大模型在回答問題時，就能看到“參考資料”，而不是“憑空編造”。

四. 工具調(diào)用

如果說 PE（提示詞工程）讓大模型學(xué)會了“說話”，RAG（檢索增強(qiáng)生成）讓大模型擁有了“知識”，那么此時的大模型更像是一個“軍師”，只能在對話框里指點(diǎn)江山，卻無法替你出門辦事。

比如當(dāng)問它：“今天北京天氣怎么樣？”它會說：“我無法獲取實時信息。”；

當(dāng)讓它發(fā)封郵件，它會抱歉地說：“我沒有操作權(quán)限。”

為了解決這個問題，就誕生了Function Calling（函數(shù)調(diào)用），相當(dāng)于給大模型裝了一雙“手腳”，讓它從只會聊天的機(jī)器人，進(jìn)化為能夠干活的智能助手。

Function Calling 的核心機(jī)制，是讓大模型具備意圖識別和參數(shù)生成的能力：

1. 意圖識別：用戶的問題需要調(diào)用什么工具？

2. 參數(shù)生成：調(diào)用這個工具需要什么參數(shù)？

很多人會誤解以為大模型親自去查了天氣、發(fā)了郵件。但實際上大模型本身不會“執(zhí)行”任何函數(shù)，它只是告訴服務(wù)端：“我覺得應(yīng)該調(diào)用這個函數(shù)，參數(shù)是這樣的”。真正的執(zhí)行，依然是由你的服務(wù)端程序去完成的。

一個完整的 Function Calling 流程，包括四個步驟：

1. 工具注冊：在讓大模型使用工具之前，開發(fā)者需要先告訴它有哪些工具可以用。開發(fā)者會向大模型注冊它能使用的函數(shù)，并提供一個嚴(yán)格的 JSON Schema。這個 Schema 定義了：

   這就像給大模型一本"工具說明書"："如果你看到查天氣、發(fā)郵件的意圖，你可以調(diào)用我注冊的這些函數(shù)。"

   • 函數(shù)叫什么名字

   • 函數(shù)是干什么的

   • 需要什么參數(shù)

   • 參數(shù)的類型是什么

2. 模型的意圖識別：當(dāng)用戶提問時，大模型會做兩件事：

   關(guān)鍵是：大模型不再生成自然語言回答，而是生成一個符合 Schema 的 JSON 結(jié)構(gòu)。舉個例子：

   用戶問： "今天北京天氣怎么樣？"

   大模型分析后，不會說"我查一下天氣"，而是生成一個 JSON：

   {
   "function": "get_weather",
   "parameters": {
   "city": "北京"
   }
   }

   這就是 Function Call 的核心，大模型扮演的是"調(diào)度員"，它負(fù)責(zé)理解意圖、提取參數(shù)，但不真正執(zhí)行操作。

   1. 判斷是否需要調(diào)用工具：用戶是只想聊聊天，還是真的需要執(zhí)行某個操作？

   2. 如果需要，生成調(diào)用信息：調(diào)用哪個函數(shù)？參數(shù)是什么？

3. 執(zhí)行函數(shù)與結(jié)果回傳：服務(wù)端接收到這個 JSON，就知道："哦，用戶想查北京天氣。此時會執(zhí)行真正的業(yè)務(wù)函數(shù)，比如調(diào)用天氣 API，拿到實時數(shù)據(jù)："北京今天 15°C，晴。"然后，這個執(zhí)行結(jié)果被打包成文本，作為新的 Prompt 上下文，重新喂回給大模型。

4. 最終回復(fù)：

   現(xiàn)在，大模型有了實時數(shù)據(jù)——"北京今天 15°C，晴"，它可以根據(jù)這些信息，生成最終的自然語言回答："北京今天天氣不錯，溫度是 15°C，晴朗。"

五. 模型上下文協(xié)議

Function Calling 賦予了大模型執(zhí)行任務(wù)的能力，但在實際工程中，開發(fā)者面臨著一個巨大的痛苦：協(xié)議碎片化。

想象一下，你為 OpenAI 的模型寫了一套查天氣的工具，但換到 Google 的模型上，這套工具完全不能用，你需要重新寫一遍。這就好像每家手機(jī)廠商都有自己的充電接口，你的充電器只能給自家的手機(jī)充電，換個牌子就沒法用了。

為了實現(xiàn)大規(guī)模協(xié)作和生態(tài)互聯(lián)，需要統(tǒng)一的標(biāo)準(zhǔn)和高效的工具。這個時候就誕生了MCP（Model Context Protocol，模型上下文協(xié)議） ，可以將其理解為它是 AI 時代的 Type-C 接口或 TCP/IP 協(xié)議。

MCP 的核心目標(biāo)是實現(xiàn) “一次開發(fā)，到處可用”。它將 LLM（大腦）與 Context/Tools（知識與工具）徹底解耦。

• 之前（模型綁定）：工具和數(shù)據(jù)源往往與特定的模型廠商深度綁定。你想讓模型讀取你的本地文件或數(shù)據(jù)庫，必須為每個模型量身定制適配層。

• 現(xiàn)在（通用標(biāo)準(zhǔn)）：無論是哪個模型（大腦），只要它支持 MCP 標(biāo)準(zhǔn)，就能像插拔 Type-C 設(shè)備一樣，無縫調(diào)用任何遵守 MCP 協(xié)議的數(shù)據(jù)源或工具。

對于開發(fā)者和企業(yè)來說，MCP 協(xié)議的出現(xiàn)具有里程碑式的意義：

1. 統(tǒng)一的標(biāo)準(zhǔn)協(xié)議： MCP 就像是 AI 領(lǐng)域的 TCP/IP 協(xié)議。它定義了一套通用的語言，讓模型能夠以統(tǒng)一的方式發(fā)現(xiàn)工具（Tools）、讀取資源（Resources）和查看提示詞模板（Prompts）。

2. 極低的適配成本：

   • 以前：如果你有 10 個數(shù)據(jù)源（數(shù)據(jù)庫、GitHub、Slack 等）和 3 個主流模型，你可能需要維護(hù) 30 套適配邏輯。

   • 現(xiàn)在：你只需要讓這 10 個數(shù)據(jù)源支持 MCP 協(xié)議，任何支持 MCP 的模型（如 Claude Desktop 或各類 AI IDE）都能立即接管并使用它們。

3. 生態(tài)互聯(lián)的基石： MCP 為 AI 生態(tài)的爆發(fā)奠定了基礎(chǔ)。開發(fā)者可以像拼樂高積木一樣，將來自不同供應(yīng)商的 MCP 服務(wù)器（數(shù)據(jù)源）組合在一起，構(gòu)建出極其復(fù)雜的自動化工作流。

總結(jié)

AI 不是黑魔法，它是一個有概率、需要被控制（PE）、需要知識（RAG）、需要執(zhí)行能力（Function Calling）和標(biāo)準(zhǔn)互聯(lián)（MCP）的復(fù)雜系統(tǒng)。

• PE（提示詞工程） ：解決了"如何讓 AI 聽話"。

• RAG（檢索增強(qiáng)生成） ：解決了"如何讓 AI 有知識"。

• Function Calling（工具調(diào)用） ：解決了"如何讓 AI 能干活"。

• MCP（模型上下文協(xié)議） ：解決了"如何讓 AI 生態(tài)互聯(lián)"。

本文主要是作為一個概述，通俗的講一下 AI 相關(guān)的名詞概念，后續(xù)會更加深入的講一下必要的知識點(diǎn)，比如提示詞工程（PE）、檢索增強(qiáng)（RAG）、工作流（Workflow）、智能體（Agent）、Langchain、Coze、n8n 等等。