本密碼產生器使用瀏覽器內建的加密隨機數（crypto.getRandomValues）生成高强度随机密码，可自定义长度、字元類型（大小寫、數字、符號）、排除易混淆字元，並即時顯示強度。全部在本地執行，密碼不會上傳或記錄。

更多開發工具：QR Code 產生器、台灣測試資料產生器。

本 QR Code 產生器可將任意文字或網址即時轉換為 QR 碼，支援調整尺寸與容錯等級，並可直接下載 PNG 圖檔。全部在瀏覽器前端生成，不會上傳任何資料。

更多開發工具：密碼產生器、JSON 格式化。

台灣統一編號（統編）為 8 位數字，第一位固定為 1，最後一位為自動計算的檢查碼。本工具可隨機產生符合檢查碼規則的统一編號，也能單筆或批次驗證統編是否正確，適合程式開發、資料庫與表單測試使用。

更多資料產生工具：台灣測試資料產生器、身分證產生器。

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

快速產生台灣格式的測試人物資料，包含姓名、身分證字號、生日、手機號碼、Email 與地址，可匯出 CSV 或 JSON，適合網站、APP、資料庫與表單開發測試使用。

上一篇學會用 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 入門

有了好的模型，接下來關鍵在於怎麼問。同樣一個 ChatGPT 或 Claude，有人問出來是神答案，有人問出來是廢話——差異就在「提示詞（Prompt）」。

Prompt Engineering（提示工程）聽起來高深，本質其實是把你要的事情講清楚的技巧。這篇文章教你一套馬上能用的方法。

為什麼「怎麼問」這麼重要？

AI 模型就像一個聰明但讀不懂暗示的同事。你說的越具體、結構越清晰，它輸出越好。含糊的問題只會得到泛泛的答案。

好提示詞的原則只有一句：給足背景與約束，減少它的猜測。

一套能套用的公式

寫提示詞時，照這個結構填空，答案品質會大幅提升：

角色 + 任務 + 背景 + 約束 + 範例（選用）+ 輸出格式

逐項拆解：

1. 角色（Role）

先給模型一個身分，它會自動調整語氣與專業度。

• ❌ 「幫我寫個行銷文案」
• ✅ 「你是一位有 10 年經驗的電商行銷主管，請幫我寫……」

2. 任務（Task）

用動詞清楚說明「要它做什麼」，一個提示只放一個主要任務最穩。

• ❌ 「關於這個……弄一下」
• ✅ 「請總結以下會議記錄的重點結論」

3. 背景（Context）

提供必要的資訊，讓模型不用猜。誰是受眾？用途是什麼？有什麼限制？

4. 約束（Constraints）

這是品質的分水嶺。常見的約束：

• 長度：「控制在 100 字以內」
• 語氣：「專業但親切，不要用術語」
• 格式：「用條列式」「只給表格，不要解釋」
• 不要做什麼：「不要加入假設性的數據」

5. 範例（Few-shot，選用）

給一兩個「輸入→輸出」的範例，模型會照著你的格式模仿。這對統一風格、格式特別有效。

6. 輸出格式（Format）

明確指定你要什麼：段落、條列、JSON、Markdown 表格等。

完整範例對比

模糊的問法：

1

幫我寫個產品介紹

結構化的問法：

1
2
3
4
5
6

你是一位 SaaS 產品的文案經理（角色）。
請為我們的「待辦清單 App」寫一段網站首頁介紹（任務）。
受眾是小型團隊主管，他們常用 Excel 管理任務（背景）。
要求：300 字以內、語氣專業但親切、突出「節省時間」這個賣點、
不要用技術術語（約束）。
最後用 Markdown 標題加三段正文的格式輸出（格式）。

第二版的明顯更好，因為模型不需要做任何猜測。

兩個強效技巧

Few-shot：給範例讓它模仿

當你需要一致的輸出格式時，先給一兩個例子：

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

把以下句子轉成禮貌的客戶回覆。

範例 1：
輸入：你的很慢
輸出：非常抱歉造成您的等待，我們會盡速改善。

範例 2：
輸入：沒貨了
輸出：很遺憾目前該商品暫時缺貨，預計下週補進。

請處理這一句：
輸入：無法出貨

Chain-of-Thought（CoT）：讓它「先想再答」

鼓勵模型一步步推導，能顯著提高邏輯、數學題的正確率。

• ❌ 「這道題答案是多少？」
• ✅ 「請一步一步思考，先列出解題步驟，再給出最終答案。」

重要更新：怎麼對「推理模型」下指令

上一篇提過，2025–2026 主流已是推理模型（Reasoning / Thinking Model）。它們本來就會在內部慢慢想，所以傳統的 CoT 指令對它們效果有限。要用對方法：

• 先開啟思考模式：很多工具需要手動打開 thinking / reasoning 開關，它才會推導。
• 要的是「過程」就要求顯示思考：例如「請把你的推理過程也一起寫出來」。
• 複雜問題才用：簡單任務開推理模式只是更慢更貴（上篇提過）。
• 檢查它的推理：推理模型有時會「想得太自信」，對關鍵事實仍要自行驗證。

常見錯誤清單

小結

• 好提示詞 = 角色 + 任務 + 背景 + 約束 + 格式。
• 原則是減少了模型的猜測。
• 邏輯題用 Chain-of-Thought；格式統一用 Few-shot。
• 對現代推理模型：開啟思考模式、要求顯示過程、複雜問題才用。

提示詞是可以「迭代」的——第一次不好，就根據結果再調整，通常 2～3 輪就能接近理想答案。下一篇進入實作：OpenAI API 入門。

《AI 新時代》系列第 03 篇。上一篇：主流產品比較 · 下一篇預告：OpenAI API 入門

接上篇建立好的概念，這篇實際來比較一下市面上主流的 AI 助理。你大概會常聽到這幾個名字：ChatGPT、Claude、Gemini、DeepSeek，後來還加入了 Qwen、Kimi、Grok。別急着一一記住，我們用「它們各適合誰」的角度來看。

先懂三個比較維度

比 AI 助理時，幾乎都看這幾個面向：

• 上下文長度（Context Length）：一次能讀多少內容。決定它能不能「一口氣讀完一整份文件再做分析」。單位是 token，數字越大越好。
• 程式能力：寫碼、除錯、理解大段程式的表現。開發者最在意。
• 多模態（Multimodal）：能不能同時看文字、圖片、影片、音訊。

另外兩個影響體驗的因素：價格 與 隱私／部署方式。

四大主流產品一覽

ChatGPT — 最全面、生態最強

如果你想要「什麼都能做、工具最多」的選擇，ChatGPT 是最安全的答案。

• 優點：使用者介面成熟、有手機 App、插件與外掛生態豐富、能連網查資料、生成圖片影片功能齊全。
• 適合：一般日常使用、需要各種整合的人、想要「一個 App 解決大部分事」的讀者。
• 注意：進階模型訂閱費用較高，大量使用會累積成本。

Claude — 寫作與程式的偏好生

Claude 在「把話說清楚、寫出好文字」和「處理程式碼」上口碑很好。

• 優點：文章語氣自然流暢、擅長長文整理與改寫；程式對話深入，適合認真開發者；強調安全性與合理性。
• 適合：大量文字工作（寫作、翻譯、摘要）、程式開發與程式碼審查、重視回應品質勝過數量的人。
• 注意：生態整合不如 ChatGPT 多，部分進階功能需付費。

Gemini — 讀得最多、綁定 Google

Gemini 最大的賣點是超大的上下文窗口，有些方案支援到百萬級 token。

• 優點：一次能吃下超長文件；與 Gmail、Google Docs、YouTube、地圖等服務深度整合（例如直接幫你總結一堆郵件）；多模態強，能分析 YouTube 影片內容。
• 適合：重度 Google 生態使用者、需要處理超長文件的人。
• 注意：程式能力稍遜於 Claude/ChatGPT 頂規；與 Google 帳號綁定深，隱私上見仁見智。

DeepSeek — 高 CP 值的實力派

DeepSeek 是來自中國的模型，在 2025 年因推理模型（R1 系列）一舉成名。

• 優點：價格非常便宜甚至部分免費方案；開放權重、可自己架設本地部署；推理能力強，程式與邏輯表現亮眼。
• 適合：預算有限但想要強效能的人、想玩本地部署的開發者、重視資料不上傳的人。
• 注意：生態與介面成熟度不如三大廠；部分功能在存取上需視地區而定。

還有其他選擇

• Qwen（阿里）：開放權重代表，本地部署熱門，多模態強。
• Kimi：以長文件處理著稱的助手。
• Grok（xAI）：結合 X（Twitter）即時資訊，回應較活潑、少限制。

我該怎麼選？依場景對號入座

小結

• 沒有「最好」的模型，只有「最適合你場景」的模型。
• 全面性選 ChatGPT、寫作與程式選 Claude、長文件與 Google 整合選 Gemini、預算與隱私選 DeepSeek。
• 多數工具都有免費額度，建議實際用一週感受差異再決定訂閱哪個。

下一篇我們來學怎麼跟 AI 說話（Prompt Engineering），讓同一個模型發揮兩倍效果——這往往比換模型更重要。

《AI 新時代》系列第 02 篇。上一篇：什麼是生成式 AI？ · 下一篇預告：Prompt Engineering