前面第 08 篇《Local LLM 部署：用 Ollama》介紹了 Ollama 這一款工具，但很多人會發現：本地跑大模型的工具其實有很多種，名字聽起來都差不多。為什麼需要這麼多工具？它們有什麼不同？我該選哪個？ 這篇就是來回答這個問題。

先講結論：沒有所謂「最好」的工具，只有最適合你需求的工具。有人想要一行命令快速上手，有人想要點一點就有圖形介面，有人想要最強功能願意折騰。下面從「背後的共同原理」講到「各工具差異」，最後給你一張決策表。

如果你只想用 Ollama，直接回頭看 Local LLM 部署：用 Ollama 就好；這篇則帶你看完整生態。

為什麼有多種本地工具？

因為大家的需求不一樣，主要分成幾個取向上：

• 圖形介面（GUI）vs 命令列（CLI）：有人喜歡點按鈕、拖模型；有人習慣終端機一行指令，適合接進腳本與自動化。
• 簡單 vs 可控：有人只想「跑起來聊天」；有人想要微調模型、接 API、做圖片生成、擴充插件。
• 硬體限制：有人用高階 Mac 或 NVIDIA 顯卡，有人只有普通筆電，對效率與相容性要求不同。

這些取向的差異，就催生了不同的工具。而它們大多建立在同一套底層技術上——接下來解釋這個關鍵概念。

背後的共同原理：llama.cpp 與 GGUF

理解這一點，你就懂為什麼工具這麼多還長得很像。

llama.cpp 是一個用 C/C++ 寫成的開源引擎，能在各種硬體（包含只有 CPU 的電腦）上執行大語言模型。它幾乎是「本地模型」這領域的基礎設施——Ollama、LM Studio 等大多數圖形工具，底層調用的就是 llama.cpp。

而模型的檔案格式叫 GGUF（llama.cpp 提出的格式）。你從各處下載的本地模型，幾乎都是 GGUF 檔。這就像：llama.cpp 是「引擎」，GGUF 是「燃料規格」，各家工具只是換了不同的「車體與儀表板」。

了解這個之後，再看各工具的差異就清楚多了：它們大多共用同一套引擎，差別在於包裝、功能與易用性。

主流工具介紹

以下四個是 2026 年最具代表性的本地模型工具。

Ollama — 最簡單，開發者首選

Ollama 用命令列為主，一行指令就能下載並跑模型（ollama run qwen3:8b），還內建 OpenAI 相容的本地 API，接進自己的程式或開發工具都方便。**詳細用法見 Local LLM 部署：用 Ollama**。

• 優點：安裝與使用最簡單、文件多、開發者生態最強（接 API、接 Claude Code／OpenCode 等代理都方便）。
• 缺點：原生沒有漂亮的圖形介面（雖然後來加了輕量視窗），進階功能較少。
• 適合：開發者、想接程式、習慣命令列的人。

LM Studio — 圖形介面最順，新手友好

LM Studio 是我最推薦給「想要 GUI 又不想折騰」的人。它現在不只是下載模型的瀏覽器，還整合成能處理工作與程式的 agent，底層同時支援 MLX（Mac 高效運算）與 llama.cpp，跨 Mac／Windows／Linux。除了點點點的介面，也提供命令列 lms 與 SDK，對開發者也算友善。內建模型庫可以直接搜、直接下，免費離線、重視隱私。

• 優點：介面清晰、模型庫好找、圖形操作順、同時有 CLI/SDK、Mac 效能佳。
• 缺點：功能深度不及 TextGen（例如進階微調、圖片生成較弱）。
• 適合：想要好用 GUI、又想兼顧一點開發需求的人。

TextGen（oobabooga）— 功能最強大，進階玩家最愛

TextGen（原名 Text Generation WebUI，由 oobabooga 維護）是功能最全面的一個。它不只是文字對話，還能做圖片生成、視覺理解、工具調用、提供 API、LoRA 微調模型，並有大量擴充插件。它提供易用的桌面 App 與瀏覽器 Web UI，後端還支援多種引擎，適合想深度玩本地模型的人。

• 優點：功能最完整、擴充性強、能微調與做多模態。
• 缺點：設定較複雜、文件偏技術、對新手不太友善。
• 適合：進階玩家、研究者、想要一站式（文字＋圖片＋微調）的人。

llama.cpp — 給想要完全控制的人

就是前面提到的那個引擎本身。如果你不想依賴任何圖形工具，想自己編譯、自訂參數、在特殊硬體上最佳化，可以直接用 llama.cpp 的命令列。它是「最原始」的選擇。

• 優點：完全可控、效率最高、相容性最廣（CPU/GPU/Mac 都能跑）。
• 缺點：沒有圖形介面，需要命令列與技術背景。
• 適合：開發者、研究者、想徹底理解或最佳化效能的人。

該選哪個？看這張表

如果還是猶豫，我的建議是：開發者用 Ollama，一般使用者用 LM Studio。這兩個能涵蓋九成情境，也是本篇前面幾篇已經深入介紹過的工具。

小結

• 本地模型工具很多，但大多共用同一套底層 llama.cpp 與 GGUF 格式，差別在包裝與功能。
• Ollama 最簡單、開發者最愛；LM Studio 圖形介面最順；TextGen 功能最強；llama.cpp 給想要完全控制的人。
• 選型關鍵看三件事：要不要 GUI、需不需要進階功能、是不是開發者。
• 只想用 Ollama？回頭看 Local LLM 部署：用 Ollama，那篇會帶你把一個工具玩透。

《AI 新時代》系列第 14 篇。相關：Local LLM 部署（Ollama）

前面我們學了：RAG 讓 AI「讀資料」（第 06 篇）、Function Calling 讓 AI「調工具」（第 07 篇）。當這些能力串起來、讓模型自己決定下一步該做什麼，就變成了 AI Agent（智能體）——這可能是今年最重要的應用方向。

什麼是 Agent？

傳統的 AI 你問一句、它答一句。Agent 則是有「自主性」的 AI：給你一個高層目標，它會自己拆解步驟、選擇工具、執行、檢查結果，直到完成。

比喻：

• 一般 LLM = 會回答問題的專家。
• Agent = 給它一個任務、資源和工具，它能像助理一樣自己安排做完。

Agent 的三個核心元件

有了這三個，Agent 才能「思考 → 行動 → 觀察 → 再思考」。

ReAct：最主流的 Agent 模式

ReAct = Reasoning（推理）+ Acting（行動）。它把過程明確分成循環：

1

思考 (Think) → 行動 (Act) → 觀察 (Observe) → 思考 → …… → 結論

舉例：目標是「幫我做一趟東京旅行的規劃」：

1. Think：「我需要知道東京的熱門景點。」→ 行動：呼叫旅遊 API。
2. Observe：拿到景點清單。
3. Think：「再查交通票券。」→ 行動：呼叫訂票工具。
4. Observe：拿到票券資訊與價格。
5. Think：「整合成一日行程表。」→ 輸出最終結果。

每一步都「邊想邊做、根據回饋調整」，所以比一次生成的答案更可靠。

用框架來實作

自己從零寫 Agent 很繁瑣，通常用現成框架：

• LangChain / LangGraph：Python／JS 最流行，工具與鏈結方便，適合各種場景。
• AutoGen（Microsoft）：強調多Agent對話，讓多個有不同角色的 agent 協作完成任務。
• CrewAI、LlamaIndex：各自在團隊協作、資料檢索上有專長。

對你這種有 Java／Python 背景的人，從 LangChain 入手最順。

實際應用案例

• 程式開發 Agent：讀整個 repo、自動修 bug、寫測試、做重構（接第 04 篇的 Claude Code、OpenCode）。
• 資料分析：連資料庫、跑查詢、生成報表與圖表。
• 自動化工作流：監控郵件 → 分類 → 摘要 → 發通知。
• 研究助理：多網站查資料 → 交叉驗證 → 整理成報告（結合 RAG）。

要注意的現實問題

• 會跑飛：Agent 可能執行與目標無關的操作，一定要設邊界、可中斷。
• 累積錯誤：步驟越多，前面錯一步後面全歪的風險越高。
• 成本與速度：每一步都是一次模型請求，多步 Agent 的 token 消耗快。
• 安全：能執行指令／改檔案的 Agent，權限要收緊，避免被提示注入（prompt injection）操縱去做惡意動作。

小結

• Agent = 有自主性、能自己規劃並用工具完成多步任務的 AI。
• 三元件：規劃 + 工具調用 + 記憶；主流模式是 ReAct。
• 用 LangChain / AutoGen 等框架加速開發。
• 潛力大但要設邊界，注意跑飛、累積錯誤、成本與安全。

這是把前面所有能力整合的終極形態。最後一篇，我們退後一步看全局：AI 趨勢展望與倫理議題。

《AI 新時代》系列第 11 篇。上一篇：AI 影片與語音 · 下一篇預告：AI 趨勢與倫理

付費 API 雖然方便，但有兩個痛點：用多了要花錢，而且資料會傳到別人伺服器。如果你重視隱私、想免費測試、或需要離線環境，本地部署大模型就是答案。

這篇文章帶你用 Ollama（目前最流行的本地模型工具）在自己的電腦跑起來。你之前看過《Mac 安裝 ComfyUI》，這篇的步驟同樣簡單。

為什麼要本地部署？

• 隱私：資料永遠留在自己機器，不上傳。
• 免費：不用付 API token 費用（只有電費與硬體成本）。
• 離線可用：沒有網路也能用。
• 開發測試：接進自己的程式做原型，不用付錢調來調去。

安裝 Ollama

1. 到 https://ollama.com 下載對應作業版本的安裝包並安裝。
2. 安裝後開啟終端機（Mac/Linux 的 Terminal），Ollama 會自動在背景執行。
3. 驗證：輸入 ollama 或 ollama list，沒報錯就成功了。

選一個模型跑起來

Ollama 上有大量開放權重模型。2026 年較熱門的幾個（依 Ollama 排行）：

初次使用建議從小尺寸開始（例如 Qwen3 的 8B 級，約 5GB），確認硬體跟得上再換大的。想測試能「看圖」的多模態模型，可以試 Llama 4（Maverick 版約 67GB，記憶體要夠）。

一行命令下載並執行

1
2
3
4
5

# 入門：小、快，適合大多數電腦
ollama run qwen3:8b

# 多模態（能理解圖片），硬體要求較高
ollama run llama4:16x17b

跑起來後，終端機就會變成一個聊天視窗，直接打字提問即可。按 Ctrl+D 或輸入 /exit 離開。

常用指令：

1
2
3

ollama list          # 列出已下載的模型
ollama pull qwen3:8b # 只下載不立即對話
ollama rm qwen3:8b   # 刪除模型

你的硬體跟得上嗎？

本地跑模型最看重 RAM（記憶體） 與 VRAM（顯存，若有 NVIDIA 卡）。規則大致是：

• 模型參數越大，需要的記憶體越多。一個大概估算法：7B 模型約需 4～6GB，70B 則要 40GB 以上。
• Mac 使用者：統一記憶體（Unified Memory）越大越好，M 系列晶片對本地模型支援佳。
• 跑不動大模型？ 用較小尺寸或「量化版」（檔名常帶 :b 或 :q），犧牲一點精度換更小佔用。

接進自己的程式（OpenAI 相容 API）

Ollama 內建一個 OpenAI 相容的本地 API，所以上一篇寫的程式碼幾乎不用改就能改用本地模型：

1
2

# 預設監聽 localhost:11434
ollama serve

Python 呼叫範例（把 base_url 指向本地）：

1
2
3
4
5
6
7
8
9
10
11
12

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama",  # 本地模型隨便填
)

response = client.chat.completions.create(
    model="qwen3:8b",
    messages=[{"role": "user", "content": "解釋什麼是向量資料庫"}],
)
print(response.choices[0].message.content)

這樣你就用免費、離線的模型跑出了跟 OpenAI 一樣的程式。

接進開發工具

Ollama 也能直接接進編輯器與 AI 開發代理（例如 Claude Code、OpenCode），在 ollama 的整合清單裡就能看到。設定後，寫碼時調用的就是你本地的模型，既免費又隱私。

小結

• Ollama 是本地上線大模型最簡單的工具，一行命令即可。
• 2026 熱門本地模型：Qwen3（入門）、Llama 4（多模態），依硬體選尺寸。
• 重點看硬體（RAM/VRAM），跑不動就換小尺寸或量化版。
• 內建 OpenAI 相容 API，上一篇的程式碼幾乎不用改就能本地化。

學會本地模型後，你已經能免費玩各種 AI。下一篇回到創作面向：AI 圖像生成。

《AI 新時代》系列第 08 篇。上一篇：Function Calling · 下一篇預告：AI 圖像生成

RAG 讓 AI 能「讀資料」，但現實中更多工作需要它執行動作：查天氣、訂機票、查庫存、算匯率。這些都在外部系統裡，模型本身做不到。

Function Calling（函式呼叫） 解決這件事：你可以定義一些工具給模型，當它判斷需要時，會回傳「要呼叫哪個函式、參數是什麼」，由你的程式去執行。

為什麼需要 Function Calling？

LLM 訓練完的那一刻，知識就停止了。它不知道：

• 台北現在幾度
• 某支股票現在的價格
• 資料庫裡這個帳號的訂單狀態

但它可以呼叫你提供的函式拿到這些即時資訊，再據此回答。這讓 AI 從「只會聊天」變成「能做事的助理」。

運作原理：一次來回

Function Calling 不是模型自己跑程式，而是兩方配合：

1. 使用者提問：「台北今天天氣如何？」
2. 模型判斷需要天氣資料，回傳一個結構化請求：{"function": "get_weather", "args": {"city": "Taipei"}}。
3. 你的程式收到這個請求，去執行真正的 get_weather API，拿到結果（例如 28°C 晴）。
4. 你把結果回給模型。
5. 模型用真實資料組織成自然語言回答：「台北今天約 28 度，天氣晴朗。」

重點：模型只負責決定「要調哪個工具、參數多少」，實際執行是你的程式。

怎麼定義一個工具？

你需要用 JSON Schema 描述這個函式，讓模型知道有哪些參數、什麼類型：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

{
  "type": "function",
  "function": {
    "name": "get_weather",
    "description": "取得指定城市目前的天氣",
    "parameters": {
      "type": "object",
      "properties": {
        "city": {
          "type": "string",
          "description": "城市名稱，例如 Taipei、Tokyo"
        }
      },
      "required": ["city"]
    }
  }
}

完整實作（Python）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

import os, json
from openai import OpenAI

client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])

# 你的真實工具：實際去呼叫天氣 API
def get_weather(city):
    # 這裡換成真正的 API 呼叫
    return f"{city} 現在 28°C，晴"

tools = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "取得指定城市目前的天氣",
        "parameters": {
            "type": "object",
            "properties": {
                "city": {"type": "string", "description": "城市名稱"}
            },
            "required": ["city"]
        }
    }
}]

# 第一步：送出問題與工具定義
response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "台北今天適合出門嗎？"}],
    tools=tools,
)

message = response.choices[0].message

# 模型決定要呼叫工具
if message.tool_calls:
    for call in message.tool_calls:
        args = json.loads(call.function.arguments)
        # 第二步：你的程式執行真實函式
        result = get_weather(**args)
        # 第三步：把結果回給模型
        messages.append({
            "role": "tool",
            "tool_call_id": call.id,
            "content": result
        })
    # 第四步：讓模型根據實資組織回答
    final = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=messages
    )
    print(final.choices[0].message.content)

實際應用場景

• 查即時資訊：天氣、股價、交通、匯率。
• 操作資料庫：查詢訂單、用戶資料後作答。
• 觸發動作：寄郵件、建立 ticket、發送通知。
• 計算器／程式碼執行：讓模型呼叫計算工具，避免算錯。
• 結合 RAG：RAG 給「讀」的能力，Function Calling 給「做」的能力，兩者常一起用。

注意事項

• 驗證參數：模型可能傳入錯誤或惡意參數，執行前務必檢查。
• 安全邊界：不要給模型能刪除資料、付款等高危工具的未經審查存取。
• 網路延遲：每次工具來回都是一次等待，多輪工具會變慢。
• 成本：每調一次工具就多一次請求，注意 token 累積。

小結

• Function Calling = 定義工具讓模型決定何時呼叫，你的程式負責實際執行。
• 流程：問 → 模型回傳工具請求 → 你執行 → 回結果 → 模型組織回答。
• 用 JSON Schema 描述函式參數。
• 結合 RAG 與 Agent，就能打造能「讀又能做」的完整助理。

學會單個工具後，下一篇我們玩更大的：用 Ollama 在自己的電腦本地部署大模型，完全離線、免費、隱私。

《AI 新時代》系列第 07 篇。上一篇：RAG · 下一篇預告：Local LLM

上一篇學會用 API 呼叫模型，但你會發現一個致命問題：AI 只知道它訓練時學到的知識，不知道你的私人文件、最新資料或公司內部資訊，有時還會「一本正經地胡說八道」（幻覺）。

RAG（Retrieval-Augmented Generation，檢力增強生成） 就是為了解決這個問題而生的技術，也是目前企業應用 AI 最主流的做法。

問題：為什麼模型會不知道你的資料？

有三種方式讓 AI 知道特定內容，各有限制：

RAG 的思路很聰明：不改模型本身，而是在它回答前，先幫它查到相關資料塞進去。

RAG 怎麼運作？兩個階段

階段一：建立索引（離線處理）

當文件進系統時：

1. 切分（Chunking）：把長文件切成一小塊一小塊（例如每段 500 字）。
2. 轉成向量（Embedding）：用 Embedding 模型把文字轉成一串數字（向量）。意思相近的句子，向量在空間裡也接近。
3. 存進向量資料庫：保存這些向量，方便日後比對相似度。

階段二：回答時檢索（線上處理）

當使用者提問時：

1. 把問題也轉成向量。
2. 在資料庫中找出與問題最相似的幾個文件區塊。
3. 把這些區塊 + 問題一起送給 LLM。
4. LLM 就「開著參考資料」作答，答案會附上來源。

比喻：RAG 就像讓員工回答前，先去公司資料庫翻相關檔案，而不是憑記憶瞎猜。

關鍵詞：Embedding 與向量資料庫

• Embedding（嵌入）：把文字轉成能表達「語意」的數字向量。例如「今天很熱」和「天氣很炎熱」的向量會很接近。
• 向量資料庫：專門儲存並快速搜尋相似向量的資料庫，常見的有 Chroma、Pinecone、Qdrant、Weaviate，Python 的 FAISS 也常用。
• 相似度搜尋：找出與問題最相近的文件區塊，是 RAG 品質的關鍵。

最小實作流程（概念碼）

用 Python 大致長這樣（搭配 LangChain 這類框架會更簡單）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

from langchain.document_loaders import TextLoader
from langchain.text_splitter import CharacterTextSplitter
from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import Chroma
from langchain.chains import RetrievalQA

# 1. 讀文件
docs = TextLoader("公司手冊.txt").load()

# 2. 切分區塊
splitter = CharacterTextSplitter(chunk_size=500, chunk_overlap=50)
chunks = splitter.split_documents(docs)

# 3. 建 embedding 並存進向量庫
vectorstore = Chroma.from_documents(chunks, OpenAIEmbeddings())

# 4. 建立檢索問答鏈
qa = RetrievalQA.from_chain_type(
    llm=ChatOpenAI(model="gpt-4o-mini"),
    chain_type="retrieve",
    retriever=vectorstore.as_retriever()
)

print(qa.run("請說明公司的請假規定"))

為什麼企業都愛 RAG？

• 資料私有且即時：用你自己的文件，而且更新文件就好，不用重訓模型。
• 減少幻覺、可溯源：答案有根據，還能標註來源讓使用者查證。
• 成本低：只傳相關的幾區塊，省 token。
• 跨語言／多格式：PDF、Word、網頁都能處理。

要注意的風險

• 檢索失準就答錯：如果沒查到正確文件，答案還是會偏。這稱為「垃圾進、垃圾出」。
• RAG poisoning（投毒）：惡意人在文件中放入誤導內容，可能操縱模型輸出。企業應用要留意資料來源可信度。
• 切分方式影響效果：區塊切太好太壞，直接決定搜尋品質，需要反覆調整。

小結

• RAG = 回答前先檢索相關文件，再結合給模型。
• 核心三步驟：切分 → Embedding → 向量資料庫。
• 優點是資料私有、即時、可溯源、成本低。
• 要注意檢索失準、投毒攻擊、切分品質。

RAG 是我們「用自己的資料」的關鍵技術。下一篇更簡單有趣：Function Calling——讓 AI 學會使用外部工具與 API。

《AI 新時代》系列第 06 篇。上一篇：OpenAI API 入門 · 下一篇預告：Function Calling

上一篇比較了各種 AI 開發工具，這篇開始自己把 AI 接進自己的程式。我們會用 OpenAI API（也就是 ChatGPT 背後的服務）當範例，學會「用程式碼呼叫大模型」這個核心技能。學會之後，換成 Claude、Gemini 或其他 API 的概念幾乎完全相通。

核心概念：你在叫賣什麼？

呼叫 LLM 本質上就是發一個 HTTP 請求，把對話送出去，再把回應拿回來。你付錢買的是 token（模型處理的文字單位），不是次數。

幾個必懂名詞：

• API Key：你的身份憑證，像密碼一樣，絕對不能洩露或提交到 Git。
• Endpoint（端點）：發送請求的網址，例如 https://api.openai.com/v1/chat/completions。
• Model（模型）：指定要用哪個模型，例如 gpt-4o-mini（便宜快）或頂規模型。
• Token：計費單位。大約 1 個 token ≈ 中文 1～2 字、英文約 4 字母。回應會比輸入更長，成本要往高估。

第一步：取得 API Key

1. 前往 OpenAI 官網註冊帳號並登入。
2. 到 API Keys 頁面生成一組 key。
3. 設定計費方式（付費方案）。
4. 立刻把它當成密碼管理，之後會放環境變數裡，不寫死在程式碼中。

第二步：最小可行範例（Python）

安裝套件：

1

pip install openai

最簡單的對話呼叫：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

import os
from openai import OpenAI

client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])

response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": "你是一位友善的程式老師。"},
        {"role": "user", "content": "用一句話解釋什麼是 API。"}
    ],
)

print(response.choices[0].message.content)

重點說明：

• messages 裡每則訊息有 role：system（設定行為）、user（使用者問題）、assistant（AI 回應）。多輪對話就是把歷史都丟回去。
• response.choices[0].message.content 就是模型回的文字。

第三步：最小可行範例（Java）

你的部落格有不少 Java 內容，這裡給一個用原生 HTTP 的範例（不需額外套件）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

import java.net.http.*;
import java.net.URI;
import com.google.gson.*;

public class OpenAiExample {
    public static void main(String[] args) throws Exception {
        HttpClient client = HttpClient.newHttpClient();

        String body = Json.createObjectBuilder()
            .add("model", "gpt-4o-mini")
            .add("messages", Json.createArrayBuilder()
                .add(Json.createObjectBuilder()
                    .add("role", "user")
                    .add("content", "用一句話解釋什麼是 token。"))
                .build())
            .build().toString();

        HttpRequest request = HttpRequest.newBuilder(URI.create("https://api.openai.com/v1/chat/completions"))
            .header("Authorization", "Bearer " + System.getenv("OPENAI_API_KEY"))
            .header("Content-Type", "application/json")
            .POST(HttpRequest.BodyPublishers.ofString(body))
            .build();

        HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());
        JsonObject json = JsonParser.parseString(response.body()).getAsJsonObject();
        System.out.println(json.getAsJsonArray("choices").get(0)
            .getAsJsonObject().getAsJsonObject("message").get("content").getAsString());
    }
}

（這裡假設你已引入 Gson 用於解析 JSON。）

三個你會馬上遇到的設定

• temperature：控制隨機性。0～1。寫程式、要事實 → 調低（如 0.2）；創意寫作 → 調高（如 0.8）。
• max_tokens：限制回應最長長度，控成本用。
• 上下文管理：對話輪數多了，token 會累積到超出「上下文窗口」。實務上要摘要舊對話或只傳最近幾輪。

計費：大概會花多少？

以便宜的 gpt-4o-mini 為例，價格非常低（每百萬 token 約幾美元等級），但請記住：

• 輸入與輸出的 price 不同，通常輸出較貴。
• 長文件、多輪對話會快速累積。
• 建議先在程式裡印出 token 數，掌握成本再上線。

安全紅線（務必遵守）

1. API Key 放環境變數，不要硬編碼。
2. 加入 .gitignore，避免 key 被推到 GitHub。
3. 後端呼叫，別在前端暴露 key：瀏覽器／手機 App 直接調 API 會讓 key 被人扒走。正確做法是你的伺服器當中繼。
4. 設定花費上限（quota），避免意外刷爆帳單。

小結

• 呼叫 LLM = 發 HTTP 請求帶上 API Key，按 token 計費。
• Python、Java 的最小範例都已實作通過，關鍵是 messages 的 role 設計。
• 用 temperature 控制創造性，用 max_tokens 控成本。
• Key 絕不放前端、不進 Git，這是安全底線。

學會 OpenAI API 後，你已經能接任何一家大模型。下一篇更實用：RAG（檢索增強生成）——讓 AI 讀你自己的私人文件。

《AI 新時代》系列第 05 篇。上一篇：AI Coding 工具比較 · 下一篇預告：RAG

如果你是開發者，AI 最能直接提升效率的場景之一就是「寫程式」。這幾年出現了超多工具，名字容易搞混：GitHub Copilot、Cursor、Claude Code、OpenCode。它們有什麼不同？你之前看過《如何在 Unity 用 Cursor AI》，這篇幫你從更高視角比較整個版圖。

先分清三種型態

這些工具雖然都叫「AI 程式助手」，但運作方式分屬三類：

GitHub Copilot — 最普及的補碼工具

由 GitHub（Microsoft）提供，是這領域的開路先鋒。

• 優點：支援編輯器最多（VS Code、JetBrains、甚至 Unity 的 Rider 等）、整合成熟、免費方案夠用。
• 適合：想在現有開發流程裡「加上補碼」但不想換編輯器的所有人。
• 接上篇：你之前學的《如何在 Unity 用 Cursor AI》是另一條路（換整個編輯器），Copilot 則是不換環境的輕量選擇。

Cursor — 為 AI 而生的編輯器

Cursor 是基於 VS Code 改造的 AI 原生編輯器，把 AI 變成核心而非插件。

• 優點：能理解「整個專案」上下文、一次改多個檔案、有 Chat 面板直接問程式碼、設定簡單（你上一篇已跑通）。
• 適合：想讓 AI 深度參與寫碼、重構、除錯的開發者。
• 缺點：要換掉熟悉的編輯器，需要適應期。

Claude Code — 會自己幹活的 Agent

這是比較新的型態：它不在編輯器裡補碼，而是在終端機裡接任你下指令，自己完成整任務。

• 優點：能讀取整個 repo、主動改檔、執行 git、跑測試、除錯；適合「交一個目標讓它做完」。
• 適合：資深開發者處理複雜重構、批量修改、整合流程。
• 注意：因為它能自動執行指令與改動檔案，使用時要留意變更範圍，建議配合 git 隨時檢查。

OpenCode — 開源的終端 Agent

OpenCode 是近年興起的開源命令列 AI 開發代理，概念與 Claude Code 類似。

• 優點：開源可自訂、能接多種模型（含本地部署的免費模型）、資源消耗相對低。
• 適合：重視隱私、想混用開放模型或本地模型的開發者。
• 搭配：可以連上你架設的 Ollama 本地模型（見後續《Local LLM》篇），完全離線寫碼。

怎麼選？對號入座

幾個實用建議

• 補碼 vs Agent 不衝突：很多人日常用 Copilot/Cursor 補碼，遇到大任務再換 Agent 處理。
• 一定要會 review：AI 產生的程式碼一定會錯或有安全漏洞，務必親自檢查，別全盤信任。
• 配合版本控制：讓它改碼前先 git commit 或善用 diff，出問題能快速復原。
• 注意授權與隱私：確認工具會不會用你的程式碼訓練模型，公司專案尤其要留意。

小結

• 三種型態：補碼（Copilot）、AI 編輯器（Cursor）、終端 Agent（Claude Code、OpenCode）。
• 新手從 Copilot 或 Cursor 入手最順；進階複雜任務再上 Agent。
• 無論哪個工具，審查 AI 的輸出都是不可省略的一步。

下一篇我們進入實作階段：OpenAI API 入門——學習怎麼用自己的程式呼叫 AI。

《AI 新時代》系列第 04 篇。上一篇：Prompt Engineering · 下一篇預告：OpenAI API 入門