本文全面介紹了大模型相關知識，包括大模型（LLM）、提示詞工程（PE）、檢索增強生成（RAG）、工具調用（Function Calling）、模型上下文協議（MCP） 等，適合零基礎小白入門。

近些年，AI 的發展速度越來越快，越來越多的業務開始尋求“AI 賦能”。面對這個黑盒，很多研發人員的反應是疑惑：“我需要學習神經網絡算法嗎？我要懂 Transformer 架構嗎？”

其實，對於非算法人員，我們不需要成為研發“發動機”的算法科學家，而是要成為能夠駕馭“賽車”的 AI 工程師。我們無需深究底層的數學原理，但必須洞察它的能力邊界，知道如何將這個“黑盒能力”高效、穩定地融入到我們的業務系統中。

一. LLM（大模型）

傳統編程：顯式的邏輯規則

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

def is_adult(age) {
    return age >= 18
}

在這種模式下，我們明確知道輸入什麼參數，經過怎樣的判斷，一定會得到確定的輸出。

但當我們面對“識別圖片中是貓還是狗”或“總結一篇文檔”這類任務時，規則變得極其複雜且模糊，此時我們無法寫一個確定性的$f(x)$函數來完成對應的任務。

機器學習：擬合複雜的 f(x)

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

具體而言，機器學習會首先構建一個巨大的數學模型（神經網絡），通過訓練來修正模型內部的權重 ($w$) 和 偏差 ($b$)。訓練的過程，本質上是一個迭代“試錯”的過程：

1. 預測：模型基於當前參數對輸入數據做出預測（初始階段基本是隨機“瞎猜”）。
2. 反饋：當發現預測值與真實標籤不符時（例如將貓誤認為狗），算法會計算兩者之間的誤差。
3. 微調：利用數學方法（反向傳播）回溯並微調內部的權重參數，目標是減小誤差，讓下一次預測更準。

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

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

大模型（LLM）：量變引起的“涌現”

在傳統機器學習時代，參數量通常在幾百萬到幾億級別，且大多是專用型的：識圖模型無法處理翻譯任務，翻譯模型無法編寫代碼等。

而當參數量和訓練數據突破臨界點（如 GPT-3的千億級參數）時，發生了神奇的“涌現現象”，模型的能力發生了質的飛躍（這類大參數量模型被稱為大模型）：

• 通用性：在學習預測萬億級語料的過程中，它自然而然地掌握了摘要、翻譯、代碼編寫等多種能力，成為了一個可以處理幾乎所有自然語言任務的“通用大腦”。
• 上下文學習：不需要修改模型參數，只需在提示詞（Prompt）裏給出幾個示例（Few-Shot），模型就能憑藉強大的學習能力，快速適配新任務並執行。

以 GPT (Generative Pre-trained Transformer) 為例，儘管其功能看似複雜，但底層核心機制十分純粹，類似於“成語接龍”：

• 輸入：用户的提示詞 + 模型已經生成的上文（比如 “牀前明月”）。
• 預測：模型在詞表中計算下一個最可能出現的詞的概率分佈（就像接龍時想 “牀前明月” 後面該接 “光”）。
• 輸出：模型通常選取概率最高的詞（例如輸出 “光”），將該詞拼接到原有輸入中，形成新的上下文（“牀前明月光”），再進入下一輪預測，直至觸發結束標誌。

二. PE（提示詞工程）

什麼是 PE?

我們已經知道 LLM 本質上是一個“概率預測機”，它讀取文本，計算概率，預測下一個詞，循環往復。在這個過程中，我們給 LLM 的所有輸入統稱為 Prompt（提示詞）。

但這裏有個工程難題：如果輸入是發散的，輸出必然也是發散的。

舉個例子，我們想讓 LLM 判斷用户反饋是正面還是負面：

寫法 A：這條評論是正面的還是負面的？用户説界面太醜了，卸載了。

LLM 可能這樣回答：

• "是負面的。"
• "負面情緒"
• "這條評論表達了用户的負面情緒，因為他説界面太醜，還卸載了應用。"

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

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

這一次 LLM 的輸出就很穩定：負面。

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

這就是提示詞工程（Prompt Engineering）的核心：通過精心設計 Prompt，讓 LLM 的輸出更穩定、更準確、更符合業務需求。

在聊天場景下，我們和 LLM 對話是"發散"的，它可能會説很多無關緊要的話，輸出格式也可能隨機變化。但一旦要把 LLM 接入業務系統，問題就來了：程序需要解析 LLM 的返回結果，一個格式不對的 JSON 就能讓整個系統崩潰。

因此，PE 的核心目標是從“自由對話”轉向“工程化協議”，就像調用 API 需要構造請求參數、定義返回格式一樣，Prompt 就是這個"人機接口的協議" 。

如何寫好 PE？

寫 Prompt 就像給實習生布置任務：你説得越清楚，他幹得越靠譜。我們繼續用"判斷用户反饋情感"這個例子，看看如何逐步優化。

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

第一步是“定義人設”，告訴 LLM：你是誰，要做什麼。在 API 開發中，這通常通過 System Prompt（系統提示詞） 來實現。

• 角色定義："你是一個情感分析專家"——這樣 LLM 會自動調整"專業程度"，知道要從用户反饋中提取情感信號。
• 任務指令："請判斷用户反饋的情感傾向"——不要讓 LLM 去猜你想幹什麼，直接説清楚。

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

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

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

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

就像給實習生一個"參考答案模板"，他看了幾個例子，自然就明白該怎麼幹了。而且這不需要重新訓練模型，完全靠 LLM 強大的"上下文學習能力"，給它幾個例子，它就能學會新任務的規律。

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

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

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

LLM 的內部邏輯流會變為：

1. 關鍵詞提取：“界面漂亮”（正）、“反應慢”（負）、“想卸載”（極負）。
2. 意圖分析：雖然有視覺上的誇讚，但最終行為是卸載，表達了強烈的挫敗感。
3. 最終結論：負面。

核心邏輯： 強迫 LLM 先把推理過程寫出來，這個過程會成為後續生成的“上下文”，相當於模型在“自我檢查”，確保結論是推導出來的，而不是“猜”出來的。

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

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

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

業務系統中，我們通常希望 LLM 返回 JSON 這種結構化數據。但 LLM 是個“話癆”，你讓它返回 JSON，它可能隨口回一句：“好的，這是你要的結果：{…}”。這多出來的幾個字，就會導致 json.loads() 直接報錯。

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

1. 結構化 Prompt（事前約束）

• 直接給模型一個標準的 JSON 模板，並約束它不要輸出多餘的解釋。

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

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

• 原生 JSON 模式：調用 API 時開啓模型自帶的 response_format: { "type": "json_object" } 模式，強制模型輸出。（如果平台支持的話）。
• 自動修復（Repair）：使用類似 json_repair 的庫。這些庫利用算法修復模型輸出中缺失的引號、括號或多餘的解釋語。
• 重試機制（Retry）：如果解析失敗，自動進行 2-3 次重試，或者在重試時把錯誤信息返還給模型（“你剛才返回的格式錯了，請修正”）。

三. RAG（檢索增強生成）

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

• 幻覺（一本正經的胡説八道）：無論我們對大模型説些什麼，它都會通過“概率預測”生成一段回答，這段回答看起來很專業，但可能完全是錯誤的，就像學生在考試時遇到不會的題，憑藉“直覺”編一個聽起來像樣的答案。
• 知識滯後（不知道最新的事）：LLM 無法實時獲取信息。無法用它來查詢公司最新的內部文檔或今天的實時銷售數據。

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

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

• 閉卷模式：由於模型沒學過公司的私有文檔，它只能憑直覺“編”。
• 開卷模式（RAG）：

1. 翻書（檢索）：當用户提問時，系統先去內部文檔庫裏搜索相關的段落。
2. 摘抄（增強）：把找到的準確信息“抄”在 Prompt 裏，作為背景參考資料。
3. 作答（生成）：最後讓大模型根據這些“參考資料”來組織語言回答。

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

第一步：準備階段 —— 語義向量化

計算機讀不懂文字，它只懂數字。我們需要把文字轉換成一種數學表達，這就是 Embedding（詞嵌入）。

• Embedding 模型：這是一種特殊的模型，它能把文本映射成一串高維數組（向量）。
• 核心邏輯：語義相近的文本，在數學空間裏的“距離”也更近。 比如，“貓”和“小貓”的向量距離，會比“貓”和“挖掘機”近得多。這使得“語義搜索”成為可能。

第二步：檢索階段 —— 向量數據庫

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

• 入庫：我們將公司文檔切割成一個個小段（Chunking），算出向量，存入向量數據庫。
• 查詢：當用户問“怎麼申請年假？”時，系統先算出這個問題的向量。
• 搜索：向量數據庫會瞬間找出倉庫裏和該問題“空間距離最近”的文檔段落（這就是 Top-K 檢索）。

第三步：生成階段 —— Prompt 增強

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

四. Function Calling（工具調用）

如果説 PE（提示詞工程）讓大模型學會了“説話”，RAG（檢索增強生成）讓大模型擁有了“知識”，那麼此時的大模型更像是一個“軍師”，只能在對話框裏指點江山，卻無法替你出門辦事。

比如當問它：“今天北京天氣怎麼樣？”，它會説：“我無法獲取實時信息。”；當讓它發封郵件，它會抱歉地説：“我沒有操作權限。”

為了解決這個問題，就誕生了Function Calling（函數調用），相當於給大模型裝了一雙“手腳”，讓它從只會聊天的機器人，進化為能夠幹活的智能助手。

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

1. 意圖識別：用户的問題需要調用什麼工具？
2. 參數生成：調用這個工具需要什麼參數？

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

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

1. 工具註冊：在讓大模型使用工具之前，開發者需要先告訴它有哪些工具可以用。開發者會向大模型註冊它能使用的函數，並提供一個嚴格的 JSON Schema。這個 Schema 定義了：

• 函數叫什麼名字

• 函數是幹什麼的

• 需要什麼參數

• 參數的類型是什麼

  這就像給大模型一本"工具説明書"："如果你看到查天氣、發郵件的意圖，你可以調用我註冊的這些函數。"

1. 模型的意圖識別：當用户提問時，大模型會做兩件事：

2. 判斷是否需要調用工具：用户是隻想聊聊天，還是真的需要執行某個操作？

3. 如果需要，生成調用信息：調用哪個函數？參數是什麼？

   關鍵是：大模型不再生成自然語言回答，而是生成一個符合 Schema 的 JSON 結構。舉個例子：

   用户問： "今天北京天氣怎麼樣？"

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

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

   這就是 Function Call 的核心，大模型扮演的是"調度員"，它負責理解意圖、提取參數，但不真正執行操作。

4. 執行函數與結果回傳：服務端接收到這個 JSON，就知道："哦，用户想查北京天氣。此時會執行真正的業務函數，比如調用天氣 API，拿到實時數據："北京今天 15°C，晴。"然後，這個執行結果被打包成文本，作為新的 Prompt 上下文，重新喂回給大模型。

5. 最終回覆：

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

五. MCP（模型上下文協議）

Function Calling 賦予了大模型執行任務的能力，但在實際工程中，開發者面臨着一個巨大的痛苦：協議碎片化。

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

為了實現大規模協作和生態互聯，需要統一的標準和高效的工具。這個時候就誕生了MCP（Model Context Protocol，模型上下文協議） ，可以將其理解為它是 AI 時代的 Type-C 接口或 TCP/IP 協議。

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

• 之前（模型綁定）：工具和數據源往往與特定的模型廠商深度綁定。你想讓模型讀取你的本地文件或數據庫，必須為每個模型量身定製適配層。
• 現在（通用標準）：無論是哪個模型（大腦），只要它支持 MCP 標準，就能像插拔 Type-C 設備一樣，無縫調用任何遵守 MCP 協議的數據源或工具。

對於開發者和企業來説，MCP 協議的出現具有里程碑式的意義：

1. 統一的標準協議： MCP 就像是 AI 領域的 TCP/IP 協議。它定義了一套通用的語言，讓模型能夠以統一的方式發現工具（Tools）、讀取資源（Resources）和查看提示詞模板（Prompts）。
2. 極低的適配成本：

• 以前：如果你有 10 個數據源（數據庫、GitHub、Slack 等）和 3 個主流模型，你可能需要維護 30 套適配邏輯。
• 現在：你只需要讓這 10 個數據源支持 MCP 協議，任何支持 MCP 的模型（如 Claude Desktop 或各類 AI IDE）都能立即接管並使用它們。

1. 生態互聯的基石： MCP 為 AI 生態的爆發奠定了基礎。開發者可以像拼樂高積木一樣，將來自不同供應商的 MCP 服務器（數據源）組合在一起，構建出極其複雜的自動化工作流。

總結

AI 不是黑魔法，它是一個有概率、需要被控制（PE）、需要知識（RAG）、需要執行能力（Function Calling）和標準互聯（MCP）的複雜系統。

• PE（提示詞工程） ：解決了"如何讓 AI 聽話"。
• RAG（檢索增強生成） ：解決了"如何讓 AI 有知識"。
• Function Calling（工具調用） ：解決了"如何讓 AI 能幹活"。
• MCP（模型上下文協議） ：解決了"如何讓 AI 生態互聯"。

寫到最後

目前我在公司主要是做一些 AI 的業務，所以更加理解作為研發人員，需要深入瞭解哪些，而哪些知識只需要簡單瞭解即可。本文主要是作為一個概述，通俗的講一下 AI 相關的名詞概念，後續會更加深入的講一下必要的知識點，比如提示詞工程（PE）、檢索增強（RAG）、工作流（Workflow）、智能體（Agent）、Langchain、Coze、n8n等等。

歡迎關注，一起成為能夠駕馭“賽車”的 AI 工程師。