03 · 按能力分類
廠商會變，"哪一類模型解決哪一類問題"不會變。這一章是這一篇裡唯一不容易過期的部分——搞清楚這幾類，你才知道自己遇到的問題該找哪一類東西，而不是指望一個模型包打天下。
一張總表
| 類別 | 幹什麼 | 你什麼時候需要它 |
|---|---|---|
| 文本模型（LLM） | 讀文字、寫文字 | 預設的那一類，本書前面講的全是它 |
| 推理模型 | 先想一段再答 | 複雜推理、多條件判斷、數學、難的程式碼 |
| 多模態 · 理解 | 看圖 / 看文件 / 看影片 | 截圖、掃描件、表格圖片、錄屏 |
| 多模態 · 生成 | 出圖 / 出影片 | 配圖、海報、素材、短片 |
| 語音 · 識別（ASR） | 聲音 → 文字 | 會議錄音、訪談、客服錄音 |
| 語音 · 合成（TTS） | 文字 → 聲音 | 有聲內容、播報、語音提示 |
| 語音 · 即時對話 | 直接聽、直接說 | 語音助手、電話機器人 |
| 嵌入模型（Embedding） | 文本 → 一串數字 | 做 RAG、做語義搜尋 |
| 重排模型（Rerank） | 把檢索結果重新排序 | RAG 效果不好時的第一個最佳化點 |
| 程式碼模型 | 專門寫 / 補 / 改程式碼 | 程式設計場景 |
下面逐個說清楚"它到底在幹嘛"和"用它時容易踩的坑"。
文本模型（LLM）
就是入門篇講的那一類：預測下一個字。本書前面五篇講的方法，預設都是對它說的。
選型上唯一值得注意的：同一家通常分三檔——最強的、均衡的、最快最便宜的。別預設永遠用最強那檔：格式轉換、分類、摘要這類活，便宜檔就夠，快還省錢。
推理模型
會先在內部"想"一段（生成一串思考過程）再給答案。
| 普通文本模型 | 推理模型 | |
|---|---|---|
| 速度 | 快 | 慢（要先想） |
| 成本 | 低 | 高（思考過程也算 Token） |
| 難題上 | 一般 | 明顯更強 |
| 簡單任務 | 夠用 | 浪費 |
判斷要不要用它，看一件事：這個任務需不需要"推"。
- 需要：多條件判斷、算賬、找矛盾、複雜程式碼、"這三個方案哪個更划算"。
- 不需要：整理格式、分類、摘要、翻譯、改寫。
用推理模型做格式轉換，就像用跑車送外賣——能送到，但沒必要。
另外：用推理模型時，別再手動寫"請一步步思考"（提示詞篇 04 章），它內建了。但規定具體的分析步驟仍然有效，那是在給分析框架，不是在教它思考。
多模態 · 理解
能"看"東西的模型。三種常見輸入：
圖片：截圖、照片、手繪草圖、圖表。用途很實際——把一張介面截圖丟進去讓它描述結構、把一張手寫便籤轉成文字、把一張圖表讀成資料。
文件：PDF、掃描件、帶複雜排版的表格。這一類和"圖片"的邊界很模糊，但處理邏輯不一樣：文件要保結構（哪些是表頭、哪些是腳註），圖片只要看懂內容。
影片 / 音訊：更少見，但在會議錄屏、操作演示、監控這類場景有用。
一個高頻的坑：解析走樣
入門篇 FAQ 提過這個——"上傳文件"和"貼上文字"，中間隔著一層解析。
PDF 掃描件、多欄排版、合併單元格的表格，解析出來經常缺行錯列。而模型看到的是解析後的結果，你看到的是原文——你以為它讀漏了，其實它壓根沒拿到。
結果不對時，先懷疑解析環節：把關鍵那幾頁手動貼上成純文本再試一次。
多模態 · 生成
出圖、出影片。這一類和前面所有內容的差別很大，值得單說：
它跟"把話說清楚"這套方法的關係沒那麼直接。 影像生成更依賴具體的視覺描述（構圖、光線、風格、鏡頭），而不是本書那套五要素。這是另一門手藝，本書不展開。
但有兩條通用的仍然成立：
- 說清楚比說漂亮重要——"一個人在辦公室"和"一箇中年男性，側身站在落地窗前，背對鏡頭，冷色調，辦公室虛化"，差的是資訊量。
- 給參考圖比寫形容詞管用——這就是 Few-shot 的視覺版。
語音：三件不同的事
這三個經常被統稱為"語音模型"，但解決的是完全不同的問題，別混：
語音識別（ASR）· 聲音 → 文字
會議錄音轉文字、訪談整理、客服質檢。
用的時候注意：轉寫稿是髒材料——沒有標點、說話人混在一起、專有名詞全錯。所以標準做法是兩步：
① ASR 轉寫 → 一坨髒文字
② 文本模型整理 → 結構化紀要第 ② 步就是你在入門篇 08 章做過的那件事。很多人以為"AI 會議紀要"是一個模型乾的，其實是兩類模型串起來的一條 Workflow。
語音合成（TTS）· 文字 → 聲音
有聲內容、播報、語音提示、數字人配音。
近幾年的進步主要在自然度和情感上——早期是"能聽懂"，現在是"聽不出是機器"。選型時聽樣本比看參數有用。
即時語音對話 · 直接聽、直接說
不經過"轉文字 → 處理 → 轉語音"三段，而是端到端地聽和說。差別在延遲和語氣保留：
| 三段式（ASR + LLM + TTS） | 端到端即時 | |
|---|---|---|
| 延遲 | 高，能感覺到卡頓 | 低，接近真人對話 |
| 語氣 / 情緒 | 轉文字時丟掉了 | 能保留 |
| 可控性 | 高（中間那段文字你能看、能改、能加規則） | 低 |
| 排查問題 | 容易（有文字中間產物） | 難 |
做語音應用時，別預設上端到端。
三段式雖然有延遲，但它有一樣端到端沒有的東西：中間那段文字是可見的中間產物——你能看它聽成了什麼、能在中間加校驗、出問題能定位。
需要極低延遲的對話場景（電話、即時助手）才值得上端到端。
嵌入模型（Embedding）與重排（Rerank）
這兩個不生成任何東西，是 RAG 的零件。
嵌入模型：把一段文本變成一串數字，意思相近的文本，數字也相近。RAG 靠它判斷"哪幾段資料跟這個問題有關"。
重排模型：嵌入模型粗篩出二十條，重排模型再精挑出最相關的三條。
RAG 效果不好時，先換這兩個
很多人 RAG 做不好，第一反應是換更強的文本模型。通常沒用——因為問題出在"檢索沒找對資料"，不在"讀資料的那個模型不夠聰明"。
檢索不準，給再強的模型也是白搭。先看嵌入模型是不是適合中文、是不是適合你的領域，再考慮加一個重排。
選嵌入模型時，注意它是不是針對中文最佳化過——這個差別比模型大小明顯。
程式碼模型
專門做程式碼補全、生成、修改的模型。
現在的界限比較模糊：通用文本模型的程式碼能力已經很強，專門的程式碼模型主要在補全速度和小尺寸下的效果上有優勢（比如要在 IDE 裡做即時補全，你需要一個又快又小的）。
日常寫程式碼用通用模型就行，專門的程式碼模型主要給做工具的人用。
怎麼組合
真實場景往往要好幾類一起用。三個例子：
會議紀要：
ASR 轉寫 → 文本模型整理 → 輸出結構化紀要
企業問答：
嵌入模型建索引 → 檢索 → 重排 → 文本模型作答（這就是 RAG）
圖文內容生產：
文本模型寫文案 → 影像模型出配圖 → 文本模型審校注意每一個都是一條 Workflow，不是"一個萬能模型"。這也是為什麼本書把 Workflow 排在 Agent 前面——多數所謂的"AI 能力"，實際是幾類模型串起來的一條線。