AI 工程化實戰：不學算法也能用好的 LLM 指南

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

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

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

一. 大模型

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

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

}

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

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

機器學習：擬合復雜的函數

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

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

1. 預測：模型基于當前參數對輸入數據做出預測（初始階段基本是隨機“瞎猜”）。

2. 反饋：當發現預測值與真實標簽不符時（例如將貓誤認為狗），算法會計算兩者之間的誤差。

3. 微調：利用數學方法（反向傳播）回溯并微調內部的權重參數，目標是減小誤差，讓下一次預測更準。

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

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

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

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

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

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

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

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

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

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

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

二. 提示詞工程

什么是 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 次重試，或者在重試時把錯誤信息返還給模型（“你剛才返回的格式錯了，請修正”）。

三. 檢索增強生成

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

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

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

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

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

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

• 開卷模式（RAG）：

• 1. 翻書（檢索）：當用戶提問時，系統先去內部文檔庫里搜索相關的段落。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

四. 工具調用

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

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

當讓它發封郵件，它會抱歉地說：“我沒有操作權限。”

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

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

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

2. 參數生成：調用這個工具需要什么參數？

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

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

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

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

   • 函數叫什么名字

   • 函數是干什么的

   • 需要什么參數

   • 參數的類型是什么

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

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

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

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

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

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

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

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

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

4. 最終回復：

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

五. 模型上下文協議

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）都能立即接管并使用它們。

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

總結

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

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

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

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

• MCP（模型上下文協議） ：解決了"如何讓 AI 生態互聯"。

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