分類: AI 工具

  • 用 North Mini Code 打造自己的 Coding Agent

    用 North Mini Code 打造自己的 Coding Agent

    📌 本文重點

    • North Mini Code 是針對程式碼與 Agent 優化的 30B 開源模型
    • 可在本地或內網部署,避免程式碼外流與雲端綁定
    • 透過 vLLM / FastAPI 等,可接到 IDE 當自家 Copilot
    • 可擴展成自動重構、產 PR 的完整 Code Agent workflow

    雲端 Copilot 很好用,但貴、會上傳程式碼、也被綁在特定平台;North Mini Code 讓你用一顆開源小模型,在自己機器上做出專屬的 AI 程式碼 Agent。

    模型連結:Hugging Face – CohereLabs/North-Mini-Code-1.0
    https://huggingface.co/CohereLabs/North-Mini-Code-1.0


    核心功能:這顆模型能幹嘛?

    1. 專門為「程式碼 + Agent」調過的 30 億參數模型

    • 參數規模:30B(約 3B active),重點是 效能 / 顯示記憶體比很友善。
    • 授權:Apache 2.0,可商用、可改、可包進你的產品,不用談授權費。
    • 能力:在人工程式碼分析指標(Artificial Analysis Coding Index)拿到 33.4 分,與同級模型競爭力接近。
    • 官方定位:Cohere 把它稱為 開源 Agentic Coding Model,也就是特別優化「一步一步推理、呼叫工具、改檔案」這種工作流程。

    💡 關鍵: 這顆 30B 模型以約 3B active 參數達到 33.4 分表現,代表在顯存友善的前提下仍具同級競爭力。

    可以做的事:

    • 寫與理解多語言程式碼(Python、TypeScript、Go…)。
    • 幫你拆解需求 → 拆任務 → 生出具體修改建議與 patch。
    • 當成 Agent 的「大腦」,搭配工具去讀檔案、改檔案、送 Pull Request。

    行動建議:先到 Hugging Face 頁面按下 Duplicate in Space 或在 Web UI 裡試幾個自己的 code snippet,確認風格合不合胃口。


    適合誰用?幾個具體場景

    • 公司不方便把原始碼丟上雲端:金融、醫療、政府專案,用雲端 Copilot 有合規壓力,North Mini Code 可以放在內網 GPU 或伺服器裡使用。
    • Side project 想省錢又想有 Copilot 感覺:自己架一顆模型,用 Cursor、Claude Code 或自製 VSCode 插件連上去,平常寫 side project 就靠它輔助。
    • 想做自家產品的「內嵌 Coding Agent」:SaaS、DevOps 工具、内部平台,想加「一鍵重構」「一鍵產生自動化 script」,可以直接把這顆模型包進去,不用每月燒雲端 API。
    • 研究 / 教學單位:開課教 AI for Programming,可以讓學生直接在本地玩 Agent,而不是只調用雲端 API。

    怎麼開始(一):最快速的入門方式

    這一層目標:先看到模型實際寫程式碼的樣子,不用寫太多 infra。

    1. 直接在 Hugging Face 線上試

    1. 開啟模型頁:https://huggingface.co/CohereLabs/North-Mini-Code-1.0
    2. 找到 Inference 或 Spaces Demo 區塊。
    3. 貼上一段自己的函式,輸入提示:

    text
    你是一位資深後端工程師,請重構以下 Python 函式,要求:
    1. 拆成小函式
    2. 加上型別註記
    3. 解釋主要修改點

    1. 看輸出是否符合你平常期待的 coding style。

    行動目標:至少用你現在在做的專案語言(例如 TypeScript + NestJS / Python + FastAPI),試 3 個 prompt,確認模型對你主力技術棧的理解能力。

    2. 用現成推理伺服器跑起來(TGI / vLLM)

    如果你手上有一台有 GPU 的機器,可以用現成的推理伺服器:

    • text-generation-inference (TGI):Hugging Face 官方推,部署簡單。
    • vLLM:效能好、支援 OpenAI-style API。

    以 vLLM + Docker 為例(概念示意):

    docker run --gpus all -p 8000:8000 \
      vllm/vllm-openai:latest \
      --model CohereLabs/North-Mini-Code-1.0 \
      --download-dir /models
    

    跑起來後,你就有一個 OpenAI 相容的 /v1/chat/completions API 可以 call。

    行動目標:用你最熟悉的推理方案(TGI 或 vLLM 選一個)先在伺服器上跑起來,用 curl 或 Postman 成功打到一次 API。


    怎麼開始(二):包成 OpenAI-style API,接到 IDE 裡

    這一層目標:讓 North Mini Code 像 OpenAI 一樣被 Cursor、Claude Code 或自製 VSCode 插件當作後端使用。

    假設你已經用 vLLM 把模型跑在 localhost:8000,現在可以再包一層簡單的 Python 代理 API,對外維持 OpenAI 介面(方便未來切換模型)。

    1. 用 Python FastAPI 做一個薄封裝

    # app.py
    from fastapi import FastAPI
    from pydantic import BaseModel
    import requests
    
    OPENAI_COMPAT_URL = "http://localhost:8000/v1/chat/completions"  # vLLM
    
    app = FastAPI()
    
    class Message(BaseModel):
        role: str
        content: str
    
    class ChatRequest(BaseModel):
        model: str
        messages: list[Message]
        temperature: float | None = 0.2
    
    @app.post("/v1/chat/completions")
    async def chat(req: ChatRequest):
        payload = {
            "model": "CohereLabs/North-Mini-Code-1.0",
            "messages": [m.model_dump() for m in req.messages],
            "temperature": req.temperature,
        }
        r = requests.post(OPENAI_COMPAT_URL, json=payload)
        return r.json()
    

    啟動:

    uvicorn app:app --host 0.0.0.0 --port 3000
    

    現在,http://localhost:3000/v1/chat/completions 就是一個「自家版 OpenAI API」。

    2. 接到 Cursor / VSCode / 自製工具

    以 Cursor 為例:

    1. 打開 Cursor 設定 → Models → 自訂 API。
    2. 填寫:
    3. Base URL: http://localhost:3000/v1
    4. API Key:隨便填一個(例如 local-north-mini),因為你自己的服務可以忽略驗證。
    5. 選擇此自訂模型作為預設 Coding 模型。

    之後你在 Cursor 內:

    • Tab 補全、聊天寫 code、改檔案的請求,全部都會走到你這顆本地的 North Mini Code。

    行動目標:把 IDE(Cursor 或 VSCode 插件)接到你剛剛包好的 API,嘗試用它完成一個小功能(例如寫一個簡單的 REST API route)。


    怎麼開始(三):變成真正的 Code Agent Workflow

    這一層目標:不是只有「聊天寫 code」,而是讓模型能 看專案、給重構建議、自己產生 PR 草稿。

    💡 關鍵: 當模型被嵌入自動讀檔、產 diff、送 PR 的流程時,才真正從「聊天輔助」升級為完整 Code Agent。

    範例 Workflow:從 Git repo → 重構建議 → PR 草稿

    流程拆解:

    1. 從 Git repo 讀取指定資料夾的檔案內容。
    2. 用 North Mini Code 產生重構建議與 patch(例如 unified diff)。
    3. 建立分支、套用 patch、產生 commit 和 PR 草稿(或 MR)。

    簡化版 Python 範例(偏偽碼):

    from git import Repo
    import openai  # 指向你自己的 /v1
    
    openai.api_base = "http://localhost:3000/v1"
    openai.api_key = "local-north-mini"
    
    repo = Repo("./your-project")
    files = ["app/service/user_service.py", "app/api/user_routes.py"]
    
    code_snippets = []
    for path in files:
        content = (repo.working_tree_dir + "/" + path)
        with open(content, "r", encoding="utf-8") as f:
            code_snippets.append(f"# FILE: {path}\n" + f.read())
    
    prompt = """
    你是一位資深後端工程師與程式碼重構專家。
    請針對下列檔案:
    1. 給出具體重構建議
    2. 產生 unified diff 格式的 patch(只包含必要修改)
    3. 每個修改前加上簡短註解(英文)
    
    注意:
    - 保持對外介面不變
    - 如果不需要改,請明確說明原因
    """ + "\n\n".join(code_snippets)
    
    resp = openai.ChatCompletion.create(
        model="north-mini-code",
        messages=[{"role": "user", "content": prompt}],
    )
    patch = resp["choices"][0]["message"]["content"]
    
    # 接下來可以用 `git apply` 或 python-git 應用 patch,然後用 GitHub / GitLab API 建 PR
    

    這裡的關鍵不是 Git 操作細節,而是:

    • 把「讀檔案」「套 patch」「建分支與 PR」都寫在程式裡。
    • North Mini Code 只負責做它擅長的事:理解現有 code → 給出修改 diff。

    搭 SkillSpector + agentsview:安全與使用監控

    你一旦開始寫 Agent,下一步就是 安全與觀察。這裡可以搭兩個開源專案:

    名稱 核心功能 免費方案 適合誰
    SkillSpector 掃描 Agent 的「技能」或工具,找出可能的安全漏洞與惡意模式 開源 有多個自動化工具、會對 Repo/GCP/AWS 操作的團隊
    agentsview 本地優先的 Coding Agent 會話分析與使用監控,支援 Claude Code、Codex 等 開源 想看「Agent 整天在幹嘛」、算 Token 用量與失敗率的團隊

    實際做法:

    • 用 SkillSpector 扫描你寫給 Agent 用的工具(例如「自動 apply patch」「執行 migration」),避免權限過大或不安全操作。
    • 用 agentsview 紀錄 coding agent 的 session:prompt / 回應 / 結果,方便 debug 與觀察模型在專案上的實際表現。

    行動目標:挑一個小專案,寫一個「自動產生重構 PR 草稿」的 Agent,然後用 SkillSpector 檢查工具安全,並用 agentsview 觀察它的使用行為。


    實務建議:硬體需求與小顯卡怎麼玩

    最低硬體需求(實務向)

    North Mini Code 是 30B 級別模型,原生 FP16 會非常吃顯存,一般建議:

    • 順暢推理:
    • 1 張 24GB GPU(如 RTX 4090 / A5000)+ 量化(例如 4-bit)
    • 或 2 張 16GB 以上多卡,使用 tensor parallel(如 vLLM、TGI 支援)。
    • CPU-only:可以,但速度會很慢,只適合測試 API,不適合作 coding 時的即時補全。

    💡 關鍵: 若有 24GB 級 GPU 搭配 4-bit 量化,就能在單機上實現接近雲端 Copilot 的流暢體驗。

    只有一張小顯卡怎麼量化部署?

    如果你只有 12GB / 16GB 等級的顯卡,可以這樣做:

    1. 使用量化權重:在 Hugging Face 上搜尋是否有 North Mini Code 的 GPTQ、GGUF 或 AWQ 版本。
    2. 用 Ollama / llama.cpp 類工具載入 GGUF:
    3. 例如:
      bash
      ollama create north-mini-code -f Modelfile
      # Modelfile 內容需指向 CohereLabs 的 GGUF 權重
    4. 再用 ollama serve + ollama run north-mini-code 來提供本地服務。
    5. 降低 context 長度與 batch size:在 vLLM / TGI 設定裡調低 max_tokens / max_seq_len 與 batch,換取顯存空間。

    如果你的顯卡只有 8GB:

    • 建議作為 離線工具 使用(例如一次性重構 / 安全掃描),不要期待「即時 Copilot 感受」。
    • 或改把模型部署在公司內部一台較大的伺服器上,自己本機透過 VPN 或內網連線使用。

    行動目標:確認自己機器的 GPU 型號與顯存,選一套適合的部署方式:

    • ≥24GB:直接 vLLM + 4-bit 量化,當日常 Copilot。
    • 12–16GB:找量化權重 + 降 context,當「按需叫用」的 Agent。
    • 只有 CPU:拿來跑批次任務或試驗,工作時還是接遠端伺服器。

    總結

    如果你:

    • 不想再冒險把私有程式碼丟到雲端,
    • 不想被單一 Copilot / API 鎖死,
    • 又想要一顆可以放進自己 workflow 裡的程式碼 Agent 大腦,

    那麼 Cohere North Mini Code 提供了:開源授權、針對程式碼與 Agent 工作流優化、可在本地或私有雲部署的折衷選項。從 Hugging Face 線上試用,到接進 IDE,再到自動產生 PR 的完整 Agent,你可以一步步把它變成你團隊自己的「內建 Copilot」。

    🚀 你現在可以做的事

    • 到 Hugging Face 下載或在線試用 CohereLabs/North-Mini-Code-1.0,用你的主力語言丟 3 段程式碼測試
    • 用 vLLM 或 TGI 在一台有 GPU 的機器上跑起來,並用 FastAPI 包成 OpenAI-style API 接到 Cursor / VSCode
    • 選一個小專案,實作「自動重構並產生 PR 草稿」的 Agent,搭配 SkillSpector 與 agentsview 做安全與使用監控
  • 在 Mac 上跑容器版 macOS 虛擬機

    在 Mac 上跑容器版 macOS 虛擬機

    📌 本文重點

    • macOS Container Machines 是「整台 macOS 的類容器」
    • 用指令快速建立、多開、快照還原乾淨 macOS
    • 特別適合多專案隔離、本地 LLM 與簡易 CI

    用一句話先說清楚:macOS Container Machines 不是一般 Docker,而是把整個 macOS 放進「類容器」裡跑起來的新形態虛擬機,讓你在一台 Mac 上快速啟動多個乾淨系統環境做開發與測試。

    官方文件:apple/container GitHub 專案


    核心功能:用指令玩出多個乾淨 macOS

    1. 用簡單指令建立 / 啟動 / 銷毀 macOS Container Machine

    macOS Container Machines 的操作模式很接近 Docker,但底下跑的是完整 macOS 系統:

    • 建立一個 macOS Container Machine(指定 macOS 版本與名稱):
    # 建立一台名為 dev-14-5 的 macOS 14.5 Container Machine
    containerctl machine create \
      --name dev-14-5 \
      --system-version 14.5 \
      --disk-size 60G \
      --memory 8G \
      --cpu-count 4
    

    💡 關鍵: 以 containerctl machine create 指定版本與資源,就能快速拉起一台完全隔離的 macOS 環境。

    • 啟動並進入這台 Machine(類似 docker start + exec):
    # 啟動
    containerctl machine start dev-14-5
    
    # 用 SSH 登入(預設會產生使用者,可在設定檔中客製)
    containerctl machine ssh dev-14-5
    
    • 停止與銷毀:
    containerctl machine stop dev-14-5
    containerctl machine delete dev-14-5
    

    可以把它想成:containerctl machine 是管理整台「容器版 macOS」,你在裡面再跑普通的 app、服務、測試工具。

    實際指令名稱與旗標以最新官方文件為準,上面是方便理解的指令模板。


    2. 支援的 macOS 版本、資源隔離與快照

    (1)支援哪些 macOS 版本?
    目前設計是讓你在 Apple silicon Mac 上跑 Apple silicon macOS 映像,常見會用到:

    • macOS 14.x(Sonoma)
    • 未來會陸續支援更新版本(請看 GitHub 文件對應 --system-version 或 image tag)

    實務建議:

    • 平常開發用:選 跟主機一樣或略新的版本(例如主機 14.4,Machine 用 14.5)
    • 回溯測試:專門起一台 舊版本 macOS 做回歸測試

    (2)資源隔離(CPU / 記憶體 / 磁碟)
    每台 Machine 建立時都可以指定:

    --cpu-count 4    # CPU 核心數
    --memory 8G      # 記憶體
    --disk-size 60G  # 磁碟容量
    

    實際效果:

    • 它會像一台獨立 Mac,有自己的檔案系統
    • 不會直接動到你宿主機的 /usr、/System
    • 可以用共享資料夾或網路服務跟宿主機互相傳檔

    💡 關鍵: CPU、記憶體與磁碟都可獨立配置,確保每台 Machine 之間與宿主機互不污染。

    (3)快照 / 回滾能力
    最實用的是可以對整個 macOS Machine 做快照,踩壞環境直接回復:

    # 在乾淨狀態建立快照
    containerctl machine snapshot create dev-14-5 --name clean
    
    # 玩壞了環境?一鍵回到快照狀態
    containerctl machine snapshot restore dev-14-5 --name clean
    

    適合:

    • 試裝一堆實驗性工具、framework
    • 跑「破壞性」測試(改系統設定、測 uninstall 流程)

    適合誰用:4 個實戰場景

    1. 前端 / 後端多版本環境測試

    情境:你在 Mac 上要同時維護多個專案:

    • 專案 A:Node 16 + 舊版 Xcode
    • 專案 B:Node 22 + 全新工具鏈

    傳統做法:在同一台 macOS 裝一堆 Node 版本管理 + 手動切換,容易互相污染。

    用 macOS Container Machines 的做法:

    1. 為每個專案開一台 Machine:

    bash
    containerctl machine create --name proj-a --system-version 14.4 --cpu-count 4 --memory 8G
    containerctl machine create --name proj-b --system-version 14.5 --cpu-count 6 --memory 12G

    1. 在各自的 Machine 裡用 nvm 或 asdf 裝需要的 Node / Java / Python。
    2. 專案測試完,直接 stop,需要時再 start。

    好處:專案 A 和 B 的依賴完全隔離,卸載 / 升級不怕互相影響。


    2. 多語言開發環境:Python / Node / Java 各一台

    如果你本機環境常被 Python 套件或 Java SDK 搞壞,可以直接用「一語言一 Machine」的策略:

    • py-dev:專門裝 miniconda / poetry,跑資料科學、AI 專案
    • node-dev:專門跑 Next.js、Vite、前端工具鏈
    • java-dev:裝不同 JDK、Maven / Gradle

    指令示例:

    containerctl machine create --name py-dev --system-version 14.5 --memory 8G
    containerctl machine create --name node-dev --system-version 14.5 --memory 8G
    containerctl machine create --name java-dev --system-version 14.5 --memory 8G
    

    這樣你在 py-dev 裝到壞掉(例如亂動 /usr/local),直接用快照回滾,不影響其他語言環境。


    3. 本地部署 LLM / Agent 場景測試

    很多本地 LLM/Agent 方案都需要:

    • 安裝特定版本 Python + 一堆 C/C++ 編譯依賴
    • 開多個後端服務(向量資料庫、API gateway、觀測工具)

    你可以用 macOS Container Machines 建立一台 llm-lab:

    containerctl machine create \
      --name llm-lab \
      --system-version 14.5 \
      --cpu-count 8 \
      --memory 24G \
      --disk-size 200G
    

    裡面專心裝:

    • Ollama / LM Studio / text-generation-webui 類工具
    • Qdrant / Milvus 等向量資料庫
    • 觀測與日誌工具

    你可以同時開兩台 Machine:

    • llm-lab-a:測 A 套框架 + A 套模型
    • llm-lab-b:測 B 套框架

    切換只要 start 不同 Machine,不需要在同一系統裡反覆安裝/移除。


    4. 在自己 Mac 上做「簡易本地 CI 流水線」

    沒有 CI 伺服器,也可以在 Mac 上模擬一套:

    1. 建立一台 ci-runner Machine:

    bash
    containerctl machine create --name ci-runner --system-version 14.5 --cpu-count 6 --memory 12G

    1. 在裡面裝:
    2. git
    3. 自動化腳本(bash / Python)
    4. 測試工具(jest、pytest、JUnit 等)

    5. 在宿主機寫一個腳本:

    bash
    # run-ci.sh
    set -e
    containerctl machine start ci-runner
    containerctl machine ssh ci-runner "cd /ci/project && git pull && ./run-tests.sh"
    containerctl machine stop ci-runner

    這樣你每次 push 前跑 ./run-ci.sh,就等於在「乾淨 macOS 環境」重做一次安裝與測試,類似本地版 CI。


    怎麼開始:10 分鐘跑起第一個 macOS Container Machine

    1. 前置條件檢查

    先確認你的 Mac:

    1. 硬體:Apple silicon(M1 / M2 / M3)
    2. 系統版本:建議 macOS 14(Sonoma)以上
    3. 啟用虛擬化:
    4. 系統偏好設定 → 隱私權與安全性 → 開發者模式 / 虛擬化(依版本可能不同)
    5. 終端機確認:

      bash
      sysctl kern.hv_support

      若輸出包含 kern.hv_support: 1,代表已支援 Hypervisor。

    6. 命令列工具:

    bash
    xcode-select --install # 安裝 Command Line Tools


    2. 取得專案與安裝 CLI

    1. 取得專案來源(目前在 Apple GitHub):
      👉 https://github.com/apple/container

    2. 安裝 CLI(實際安裝方式以官方文件為準):

    常見方式會是:

    bash
    git clone https://github.com/apple/container.git
    cd container
    make install # 或官方指定的安裝指令

    1. 安裝完成後確認:

    bash
    containerctl --help

    能看到 machine 相關子命令,就表示工具已就緒。


    3. 10 分鐘內啟動第一台 macOS Container Machine

    以下是一套可以直接照抄、調整參數就能用的流程。

    Step 1:拉一個基礎 macOS Image(如有提供)

    containerctl image pull macos:14.5   # 實際名稱以官方為準
    

    Step 2:建立一台開發用 Machine

    containerctl machine create \
      --name my-dev-mac \
      --system-version 14.5 \
      --cpu-count 4 \
      --memory 8G \
      --disk-size 80G
    

    Step 3:啟動並登入

    containerctl machine start my-dev-mac
    containerctl machine ssh my-dev-mac
    

    進去後你就像在操控另一台 Mac:可以 xcode-select --install、brew install、建立專案…

    Step 4:建立初始快照

    設定好你想要的「標準開發環境」後:

    containerctl machine snapshot create my-dev-mac --name baseline
    

    以後只要環境被弄亂:

    containerctl machine snapshot restore my-dev-mac --name baseline
    

    💡 關鍵: 用一個 baseline 快照當標準模板,可以無限次還原與複製穩定的開發環境。


    4. 常見坑與排查方式

    1)磁碟空間不夠

    • 每台 Machine 都要單獨配置磁碟(例如 60–200 GB),很容易占滿主機
    • 檢查:

    bash
    df -h

    • 建議:
    • 專案和資料盡量放在共享資料夾(掛載宿主機目錄)
    • 不用的 Machine 記得 containerctl machine delete 刪掉

    2)網路問題(Machine 連不到外網 / 宿主機)

    常見症狀:Machine 裡 curl、git clone 失敗。

    排查:

    1. 先確認宿主機本身有網路。
    2. 看 container 網路設定(NAT / bridge),官方文件通常會提供:

    bash
    containerctl network list

    1. 若要從宿主機存取 Machine 內服務(例如在 Machine 跑一個 Web 伺服器),要確認:
    2. Machine 內服務綁在 0.0.0.0
    3. 有對應 port mapping 或可透過 Machine IP 存取

    3)權限問題(安裝 / 授權失敗)

    • 安裝 CLI 需要 sudo 權限時,請用管理员帳號
    • Machine 內如果需要 Full Disk Access、相機、麥克風等權限,目前會比本機更受限制 —— 適合做 CLI / server 端開發,比較不適合高度依賴 GUI 的 App 測試

    小結

    如果你在 Mac 上經常遇到「環境裝一裝就亂掉」「不同專案依賴互相打架」,macOS Container Machines 提供一個新的選項:直接在一台 Mac 上開多台「容器版 macOS」來做隔離與測試。

    先從一台 my-dev-mac 開始,練習建立 / 啟動 / 快照 / 回滾,熟悉之後再把日常專案慢慢搬進不同 Machine,你會更敢大膽試新工具,也更容易維持一個乾淨穩定的主機環境。

    🚀 你現在可以做的事

    • 到 apple/container 看最新安裝方式與 containerctl 子命令說明
    • 照文中流程建立一台 my-dev-mac,實際練習啟動、SSH 登入與建立快照
    • 挑一個現有專案,為它專門開一台 Machine,體驗依賴完全隔離的開發流程
  • NotebookLM 大升級:把 Gemini 變成你的研究員

    NotebookLM 大升級:把 Gemini 變成你的研究員

    📌 本文重點

    • NotebookLM 把閱讀、整理、寫程式整合在同一工作空間
    • 內建雲端 sandbox,可直接跑 Python 做資料分析
    • 透過 Agent 自動查網路資料,像一位會 Google 的研究員

    用一句話說 NotebookLM:把你的文件、網頁跟程式碼交給一個會自己查資料、寫筆記、跑程式的 AI 研究員,幫你把「看資料 + 做筆記 + 寫程式」整合在同一個工作空間。

    官方介紹與註冊入口:https://notebooklm.google.com
    相關報導:The Decoder(連結)、The Verge(連結)


    核心功能:現在的 NotebookLM 到底多了什麼?

    1. Gemini 3.5:回覆更準、少亂講

    這次 NotebookLM 底層模型換成 Gemini 3.5 Flash,重點不是名字,而是實際效果:

    • 引用來源更清楚:問問題時,NotebookLM 會標記是從哪一份 PDF、哪一頁、哪一段抓出來的。
    • 和你自己的資料對齊:它只會優先根據你匯入的檔案回答,而不是憑空編故事。
    • 支援多文件綜合:你可以丟 10 篇論文、3 份簡報,直接問「幫我整理共同結論」。

    💡 關鍵: NotebookLM 會優先根據你匯入的資料回答問題,大幅降低「亂講」和憑空編造內容的風險。

    你可以怎麼用:

    • 把課程講義、公司簡報、研究論文丟進一個 Notebook,直接問:
    • 「請用 300 字整理這些文件的重點,分成三個小節。」
    • 「列出文件裡提到的所有關鍵術語,做成小抄。」

    2. 內建雲端 sandbox:直接在 Notebook 裡跑程式

    根據 The Decoder 報導,NotebookLM 現在有自己的 雲端電腦環境,可以:

    • 執行 Python / 程式碼片段,不用本機安裝任何東西。
    • 讓 AI 自己寫程式、執行、看結果,再調整程式碼。
    • 做資料分析:匯入 CSV、跑統計、畫圖,全在瀏覽器裡完成。

    💡 關鍵: 內建雲端 sandbox 讓你不用開 Jupyter 或設定環境,就能在瀏覽器裡完成程式與資料分析工作。

    你可以怎麼用:

    • 上傳一份 CSV 報表,在對話框輸入:
    • 「幫我用 Python 讀取這個檔案,算出每個產品線的月營收,並畫出折線圖。」
    • 有一段不熟悉的程式碼,直接貼進 Notebook:
    • 「解釋這段程式在做什麼,幫我加上註解,並用更易懂的寫法重構。」

    NotebookLM 會在它的雲端 sandbox 裡跑程式,再把結果和程式碼一起貼給你。

    3. Agent 式自動查資料:會自己 Google 的研究員

    新版 NotebookLM 加入了 Agent 式研究能力:

    • 可以直接叫它「去幫我找資料」,它會透過 Google 搜尋 找來源。
    • 不用一開始就匯入檔案,也能從「空白」開始一個研究計畫。
    • 它會把找到的網頁、PDF 當成新的資料來源,整理成摘要或報告。

    The Verge 指出,現在你可以直接在 NotebookLM 裡啟動研究,而不是先手動找資料再貼進來。

    你可以怎麼用:

    • 問:
    • 「請幫我找三篇 2023 年後關於 LLM 應用在教育的研究,整理出研究問題、方法、結論。」
    • 要求:
    • 「所有引用請附上原始連結,最後用一段話提醒我這些研究的限制。」

    適合誰用:三個具體場景

    1. 學生:整理課堂講義與論文

    常見痛點:

    • 上課講義 + 教科書 + 老師 PDF + 論文,多到爆炸,很難整理成考前筆記。
    • 讀英文論文速度慢,抓不到重點。

    NotebookLM 的用法:

    1. 建立一個 Notebook,例如「機器學習期末」。
    2. 匯入:課程講義 PDF、指定閱讀論文、老師提供的投影片。
    3. 問:
    4. 「請用中文整理這份 Notebook 的期末考重點,照章節分類。」
    5. 「幫我做一份 10 題選擇題,題目來自這些文件,並給出解析。」
    6. 「這篇論文的實驗設計和 limitation 是什麼?用口語說明。」

    可立即採取的行動:

    • 把這學期最頭痛的一門課資料丟進 NotebookLM,直接讓它幫你做考前總整理。

    2. 產品經理:整理競品資料與市場研究

    常見痛點:

    • 競品官網、新聞稿、使用條款、App 介紹分散各處。
    • 每次開會都在重做一樣的「功能比較表」。

    NotebookLM 的用法:

    1. 新建 Notebook:「2024 Q3 競品研究」。
    2. 匯入:競品官網截圖 PDF、功能說明文件、先前做過的簡報。
    3. 啟用 Agent 查資料:
    4. 「幫我搜尋 3 家同類型 SaaS 產品的定價頁面,整理成表格。」
    5. 再問:
    6. 「針對我們現有產品,列出 5 個值得抄的功能點,並附上來源連結。」

    可立即採取的行動:

    • 建立你的「競品知識庫 Notebook」,每天丟一兩個新連結進去,讓 NotebookLM 幫你維護最新的競品視圖。

    3. 工程師:技術備忘錄 + 資料分析助手

    常見痛點:

    • 專案文件分散在 Confluence、Google Docs、GitHub Wiki。
    • 每次查舊專案架構或業務規則,都要重看一堆文件。
    • 做小型資料分析還得開 Jupyter、整理環境。

    NotebookLM 的用法:

    1. 建立 Notebook:「後端服務 A 技術文件」。
    2. 匯入:設計文件 PDF、API spec、README、部分程式碼片段。
    3. 提問:
    4. 「這個服務的主要資料表有哪些?幫我畫一個簡化的 ER 圖描述文字。」
    5. 「從這份 API 文件裡,整理一份給新同事看的 onboarding 指南。」
    6. 把日常 log / CSV 丟進去:
    7. 「用 Python 幫我分析這份 log,找出錯誤頻率最高的三個 endpoint,畫 bar chart。」

    可立即採取的行動:

    • 先選一個你最常被問的專案,把所有設計文件丟進 NotebookLM,之後把新同事導向 NotebookLM 問問題。

    怎麼開始:10 分鐘完成第一個 Notebook 專案

    步驟 1:開啟 NotebookLM

    1. 用 Chrome 或任一瀏覽器開啟:https://notebooklm.google.com
    2. 用你的 Google 帳號登入。
    3. 若地區未開放,可以先用 VPN 嘗試(注意公司政策)。

    步驟 2:建立第一本 Notebook

    1. 點選「New notebook」。
    2. 幫它取一個明確的名字,例如:
    3. 「行銷簡報整理」
    4. 「碩士論文文獻庫」
    5. 按「Add sources」,開始匯入資料。

    步驟 3:匯入 PDF / Docs / 網頁

    NotebookLM 支援:

    • 上傳 PDF、TXT、部分 Office 檔。
    • 直接選 Google Docs、Slides、Sheets。
    • 貼上網址,讓它自己抓取網頁內容(官網、部落格、新聞稿)。

    建議:先匯入 3–5 份你最近真的會用到的文件,不要一次丟 50 份,方便你先熟悉操作。

    💡 關鍵: 一開始只匯入 3–5 份核心文件,比一次丟 50 份更容易看出 NotebookLM 的效果並建立使用習慣。

    步驟 4:試用這 3 個 Prompt 模板

    以下是你可以直接複製貼上的實戰模板:

    模板 1:快速總整理

    你是一位擅長教學的筆記整理員。請根據這本 Notebook 內所有來源資料,整理一份 800 字以內的重點摘要,
    1. 先列出 5 個最重要的概念
    2. 每個概念用不超過 3 句話說明
    3. 最後用一段話提醒我考試或簡報時最容易忽略的地方

    模板 2:給不同對象的說明稿

    根據 Notebook 內的資料,分別寫兩版說明:
    1. 給完全沒有背景的新手,限制 300 字,盡量口語化
    2. 給同領域專業人士,限制 300 字,可以使用專業術語
    每一版都請標註引用的來源文件與頁碼(若有)。

    模板 3:資料 + 程式分析

    我上傳了一份 CSV 檔案,請你:
    1. 先用 Python 讀取資料並描述欄位
    2. 幫我算出各類別的平均值與標準差
    3. 畫出一張適合的圖表(你自己決定類型),並解釋為什麼這樣比較好讀
    請貼出完整的 Python 程式碼與分析結論。


    結語:把 NotebookLM 當成「專案專屬研究員」

    使用 NotebookLM 最重要的觀念是:為每個專案建一本 Notebook,讓它跟著專案一起長大。

    • 學生:每門課一冊,所有講義與筆記都放進去。
    • 產品經理:每個產品線或競品一冊,讓它幫你維護最新情資。
    • 工程師:每個系統或專案一冊,變成活的技術備忘錄 + 分析環境。

    你只需要準備好資料,NotebookLM 會幫你查、幫你寫、幫你跑程式,真正變成「專案專屬的 Gemini 研究員」。

    🚀 你現在可以做的事

    • 登入 NotebookLM,為你目前最重要的專案建立第一本 Notebook
    • 先匯入 3–5 份你最近真的會用到的文件,實測上文提供的 3 個 Prompt 模板
    • 挑一個課程 / 產品線 / 專案,每次產出新文件就丟進 NotebookLM,開始養成「一專案一 Notebook」的習慣
  • Lens 超輕量圖像生成實戰指南

    Lens 超輕量圖像生成實戰指南

    📌 本文重點

    • 小模型搭配高品質描述也能畫得好
    • Lens 完整開源,可在本機或雲端部署
    • 用 GPT 先整理資料,可微調出專屬圖像模型
    • 先用 Demo 試 prompt,再決定是否自建 API

    用一台普通筆電就能跑的開源圖像模型 Lens,把「小模型也能畫得好」這件事變成現實,適合想在本機或雲端快速搭一個可用圖像生成系統的人。

    原始研究與開源專案可見 Microsoft Research 公告與程式碼倉庫(可從 The Decoder 報導 追蹤連結)。


    核心功能:小模型,靠好資料撐起來

    1. 3.8B 參數也能畫出細節圖

    Lens 的參數量只有約 38 億,比主流閉源大模型小很多,但在多個圖像生成基準測試中,成績可以追上甚至超過體型更大的模型。關鍵不是「堆參數」,而是訓練資料:

    • 使用約 8 億筆、由 GPT‑4.1 產生的高品質圖像描述
    • 描述內容細到「光源方向、鏡頭焦段、材質、構圖」,不是只寫「一隻貓坐在桌子上」
    • 小模型可以在這些精準標註上更有效學習

    💡 關鍵: 約 38 億參數配上 8 億筆精準描述,證明小模型只要資料夠好,也能接近甚至超過大模型表現。

    你可以怎麼用這個優勢?

    在實際 prompt 時,多寫一點細節,Lens 特別吃「具體描述」:

    一個極簡風格的手機 App 圖標,白色背景,中間是扁平化的藍色雲朵,
    線條乾淨,無陰影,適合放在 iOS 主畫面。
    

    比起只寫「雲朵圖標」,具體描述會更接近 Lens 當初訓練時看到的高質量 caption,使輸出品質更穩定。


    2. 完整開源:程式碼 + 權重 + 資料流程

    Lens 的程式碼與模型權重開源,你可以:

    • 在本機部署,不經過第三方雲端
    • 在自己的伺服器上做內網圖像生成 API
    • 自行微調,適配特定風格(例如公司品牌視覺)

    可行動的做法:

    • 把 Lens 當作「公司內部版 Midjourney」,搭配簡單前端頁面給同事用
    • 在產品原型工具(如 Figma 插件、內部 dashboard)後端接上 Lens API

    3. 訓練思路可複用:用 GPT 先把資料變好

    Lens 的另一個重點,是用 GPT‑4.1 先幫原始圖像資料寫出高品質描述,再拿來訓練。對個人或團隊來說,這給了很實際的路線:

    • 收集自家產品圖(例如鞋子、包包、介面截圖)
    • 用 GPT‑4.x 幫每張圖生成細緻描述
    • 用這批資料微調 Lens,得到一個「專門懂你家產品」的圖像模型

    你可以馬上做的實驗:

    1. 拿 50 張自家產品圖
    2. 用 ChatGPT / Azure OpenAI 幫每張圖寫 3–4 句的超詳細描述
    3. 把這批圖 + 描述存成 JSON / CSV
    4. 未來如需微調 Lens,就已經有一批乾淨資料可以用

    💡 關鍵: 先用大型語言模型替資料加上高品質描述,可以顯著降低後續訓練或微調的成本,讓小模型也具備專領域能力。


    適合誰用:三個典型場景

    1. App 圖標與 UI 草圖

    需求:快速生出幾十款圖標概念,不想每次都手動畫。

    Lens 可以:

    • 輸出風格統一的 App 圖標草稿
    • 為不同功能模組快速生成 icon 系列

    範例 prompt:

    為一款習慣追蹤 App 生成 4 個圖標提案:
    扁平化風格,柔和配色,每個圖標有明確象徵:
    打卡用打勾符號、番茄鐘用簡化的時鐘、
    統計用長條圖、個人設定用簡化人物輪廓。
    背景簡潔,適合 iOS 風格。
    

    2. 行銷素材:社群貼文、Banner 草圖

    需求:行銷團隊需要快速產出視覺草案,交給設計師再精修。

    Lens 可以:

    • 生成不同構圖的社群貼文底圖
    • 幫你先找到「方向」,再請設計師改

    實際使用方式:

    1. 將產品賣點寫成 2–3 句描述
    2. 指定風格(例如「韓系清新」、「科技感藍紫配」)
    3. 產出 5–10 張圖,挑 1–2 張給設計師重製

    3. 產品原型圖:硬體外觀、介面草稿

    需求:先有一組「看得懂」的圖,再進行工業設計或 UI 設計。

    Lens 可以:

    • 幫你畫出不同外型的裝置草案(例如智慧音箱、耳機)
    • 幫 App 原型搭配大致配色與版型

    範例 prompt:

    一款家用智慧音箱的產品概念圖,
    圓柱形機身,霧面白色塑膠材質,上半部有細密圓孔,
    底部有一圈柔和的 LED 光環,放在木質桌面上,
    整體風格偏向北歐極簡風。
    

    怎麼開始:最低摩擦上手路線

    路線 1:完全不寫程式,先用 Hugging Face Demo Space

    如果你只是想試看畫得如何,最簡單是使用 Hugging Face 上的 Demo(搜尋「Lens text-to-image」即可,或從 The Decoder 報導頁面 追過去)。

    步驟:

    1. 開啟 Demo Space 頁面
    2. 在文字框輸入中文或英文 prompt
    3. 選擇解析度與步數(預設即可)
    4. 點擊 Generate

    適合:

    • 行銷或產品同事想先測試效果
    • 還沒有決定要不要自己部署

    小技巧:

    • 先用 Demo 找到你喜歡的 prompt 模板
    • 再複製這些 prompt 到你自己的部署裡使用

    路線 2:會寫程式,用 Transformers 建自己的圖像生成 API

    如果你熟悉 Python,建議直接用 Hugging Face Transformers 在本機或雲端跑 Lens,幾行程式碼就能得到一個可呼叫的 API。

    以下假設你已安裝 Python 3.10+。

    1. 安裝必要套件

    pip install torch torchvision --index-url https://download.pytorch.org/whl/cpu
    pip install transformers accelerate safetensors
    

    如果你有 NVIDIA GPU,可改用官方 CUDA 版 PyTorch 安裝指令。

    2. 下載並載入 Lens 模型

    以 Transformers 為例(假設模型名稱為 microsoft/lens-3.8b,實際名稱請依 Hugging Face Hub 為準):

    from transformers import AutoTokenizer, AutoModelForCausalLM
    import torch
    
    model_id = "microsoft/lens-3.8b"
    
    tokenizer = AutoTokenizer.from_pretrained(model_id)
    model = AutoModelForCausalLM.from_pretrained(
        model_id,
        torch_dtype=torch.float16,
        device_map="auto"
    )
    
    prompt = "a minimal blue and white app icon of a cloud on a white background, flat design, no shadows"
    inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
    
    with torch.no_grad():
        outputs = model.generate(**inputs, max_new_tokens=256)
    
    # 假設模型會輸出圖像 latent,再解碼成圖片
    # 這部分請依官方範例加入解碼步驟
    

    因為 Lens 是影像模型,實際程式碼會包含「文字 -> 影像 latent -> 圖檔」三階段;建議直接參考官方 repo 的 inference.py 或示範 notebook,把其中的 inference 函數包一層 API。

    3. 快速包一個本機 API(Flask 範例)

    from flask import Flask, request, send_file
    from io import BytesIO
    
    app = Flask(__name__)
    
    @app.post("/generate")
    def generate():
        data = request.get_json()
        prompt = data.get("prompt", "")
        # 呼叫 Lens 推理函數,回傳 PIL Image
        image = run_lens(prompt)
    
        buf = BytesIO()
        image.save(buf, format="PNG")
        buf.seek(0)
        return send_file(buf, mimetype="image/png")
    
    if __name__ == "__main__":
        app.run(host="0.0.0.0", port=8000)
    

    有了這個 API,你就可以:

    • 在前端或 no-code 工具(如 Bubble、Retool)裡直接呼叫
    • 在 CI pipeline 裡自動生成 demo 圖像

    💡 關鍵: 先用 Hugging Face Demo 測試,再用短短數十行程式碼包成 API,可以在普通硬體上快速搭起團隊可用的圖像生成服務。


    最低摩擦指南:你現在可以做什麼

    1. 先用 Hugging Face Demo 試出一組好用 prompt:
    2. 各準備一組 App 圖標、行銷素材、產品原型的 prompt 模板
    3. 決定部署路線:
    4. 只需要偶爾用 → 繼續用 Demo
    5. 團隊要每天用 → 自己在雲端或本機起一個 Lens API
    6. 把 prompt 模板寫進文件:
    7. 給團隊共用,確保風格一致

    Lens 的真正價值,不只是「輕量」這一點,而是用高品質 GPT‑4.1 描述資料換來的「小而準」行為。只要你願意在描述上多花一點心思,就能在普通硬體上,得到足夠好用的圖像生成系統。

    🚀 你現在可以做的事

    • 打開 Hugging Face 搜尋「Lens text-to-image」,實際輸入 3 組 prompt 測試效果
    • 在一台開發機上依照文中步驟安裝 Transformers,跑通一個簡單的 Lens API
    • 收集 20–50 張自家產品圖,配合 GPT‑4.x 產生描述,準備未來微調用的資料集
  • 把整個 Google 變成你的 AI Agent

    把整個 Google 變成你的 AI Agent

    📌 本文重點

    • google/skills 是 Google 產品專用的 AI Agent 工具箱
    • 透過現成 skills,LLM 可直接操作 Gmail / Calendar / Drive
    • 幾十行 Python 就能做出實用的 Workspace 自動化 Agent
    • 重視權限、安全與流程設計,才能放心在公司環境使用

    用一句話說清楚:google/skills 是一個專門替 Google 產品包好的「AI Agent 工具箱」,讓 LLM 不只會聊天,還能直接幫你操作 Gmail、Calendar、Drive 等服務。

    專案連結:https://github.com/google/skills


    google/skills 是什麼?可以幹嘛?

    用開發者的語言講:

    • 這是一組 Python 套件 + 一堆已實作好的「工具(skills)」
    • 每個 skill 就是一個可被 LLM 呼叫的函式,背後已幫你處理好 Google API 認證、資料結構、錯誤處理
    • 你只要把這些 skills 接到你熟悉的 Agent 框架(或自己寫個 loop),LLM 就能:
    • 在 Gmail 搜尋、讀取、回覆郵件
    • 在 Google Calendar 建立、更新、刪除行程
    • 從 Google Drive 找檔案、讀內容
    • 以及其他 Google 產品(例如 Docs / Sheets / Tasks 等)

    💡 關鍵: 把繁瑣的 Google API 細節封裝成 skills,讓你專注在設計 Agent 流程,而不是處理認證與資料結構。

    目前常見支援的產品與典型技能

    以 GitHub 專案內容與官方範例為主,目前重點集中在 Workspace 產品:

    • Gmail:搜尋郵件、讀取內容、標記已讀、建立草稿、送出郵件
    • Calendar:建立事件、更新時間/地點、取消會議、查詢空檔
    • Drive:列出檔案、搜尋、下載內容、讀取檔案文字(搭配 API 或其他工具)
    • Tasks / Docs / Sheets:視版本與模組更新擴充,作為實驗性 skills 提供

    你可以把它想成:「Google 幫你寫好一堆『LLM 可安全使用的 Google API wrapper』,你只要負責接到自己的 Agent。」


    核心功能:讓 LLM 真的「動手做事」

    下面用三個代表性技能,拆開來看它怎麼組成一條完整工作流。

    1. Gmail:搜尋 + 回覆郵件

    能做的事

    • 根據條件(發信人、標題關鍵字、時間)搜尋郵件
    • 讀取郵件主旨、內容、附件資訊
    • 由 LLM 生成人性化回覆,再用 skill 建草稿或直接寄出

    你可以怎麼用

    • 自動整理每日「待回覆」郵件清單
    • 給 Agent 一句自然語言指令:
    • 「幫我找這週所有含『報價』的客戶信,產出一封統一回覆草稿」

    2. Calendar:建立 / 修改行程

    能做的事

    • 建立新事件(時間、地點、參與者、線上會議)
    • 更新時間或加入備註
    • 查詢某段時間的空檔

    你可以怎麼用

    • 讓 LLM 從郵件裡抓出「時間 + 地點 + 主題」,自動變成 Calendar 事件
    • 用一句話:
    • 「把明天 3–5 點標成『專注工作』,不要排會議」

    3. Drive:從檔案抓資料

    能做的事

    • 依檔名、類型、擁有者搜尋檔案
    • 下載或讀取檔案(再交給 LLM 摘要)

    你可以怎麼用

    • 找到昨天產出的報表,請 LLM 摘要要點後寄給主管
    • 自動從會議紀錄整理 action items,寫回 Google Docs

    把它們串起來:一條完整工作流範例

    例子:自動從郵件抓會議資訊 → 建行程 → 建備忘錄

    1. Agent 用 Gmail skill 搜尋主題含「Meeting」「邀請」的未讀信
    2. LLM 解析郵件內容,抽出:會議主題、時間、地點、參與者
    3. 用 Calendar skill 建立事件,寫入摘要與會議連結
    4. 用 Drive/Docs skill 建一份「Meeting Notes」文件,寫入議程、預先問題

    你只要負責描述「整體目標」,LLM 會自己決定何時呼叫哪個 skill。你的程式碼變得像是在描述流程,而不是在寫一堆 API 呼叫細節。

    💡 關鍵: 一旦 workflow 串起來,同一套 skills 可以重複組裝出不同的自動化場景,大幅降低開發新 Agent 的成本。


    實戰場景:把散落在 Workspace 的動作串起來

    下面是幾個可以立即實作的場景,每一個都對應到你可以「今天就試做」的腳本。

    1. 個人行程助理

    需求:每天早上想知道今天有哪些會議、重要信件、待辦。

    可以怎麼做

    • Gmail:抓「星號」或加標籤的關鍵郵件
    • Calendar:列出今天所有會議與空檔
    • Tasks / Drive:列出今日到期的任務與文件
    • LLM 整理成一封「每日簡報」,寄到 Gmail 或 Slack

    👉 可行動:用本文後面的「每日早上報告 Agent」最小範例修改即可。

    2. 客服工單整理

    需求:客服信都在 Gmail,手工整理太慢。

    技能組合

    • Gmail:抓取特定 label(例如 support)的所有新信
    • LLM:
    • 自動分類(bug、退款、帳號問題)
    • 抽出關鍵欄位(客戶、產品、影響範圍)
    • Drive/Sheets skill:寫入 Google 試算表,讓團隊追蹤

    3. 銷售線索追蹤

    需求:商務開發信散落在 Gmail、會議安排在 Calendar、紀錄在 Drive。

    技能組合

    • Gmail:搜尋含「報價」「demo」關鍵字的信
    • Calendar:對應已有 / 尚未安排會議的線索
    • Drive:讀取對應的提案文件
    • LLM:產出「Sales pipeline 摘要」,再寄給業務團隊

    4. 團隊報表自動彙總

    需求:每週要整理多份 Google Sheets / Docs 的數據與摘要。

    技能組合

    • Drive:搜尋指定資料夾裡的所有報表
    • Sheets/Docs skill:抓出指定欄位/段落
    • LLM:彙整成一份「本週關鍵指標 + 亮點 + 風險」
    • Gmail:寄給管理層

    每個場景本質上都是:用 skills 拉資料 → LLM 處理 → 再用 skills 寫回 Google 生態。

    💡 關鍵: 只要 Workspace 流程是「讀資料 → 分類/摘要 → 回寫」,幾乎都能用同一套模式快速自動化。


    怎麼開始:從零到一的小 Agent(Python)

    這段寫給已經會基本 Python 的讀者。目標是做一個:

    「每日早上 9 點,整理今天的會議與重要郵件,寄一封報告給自己」

    步驟一:安裝套件與專案結構

    pip install google-skills openai  # 或你要用的 LLM 客戶端
    

    一個最小專案結構可以是:

    project/
      main.py          # 主程式,Agent 邏輯
      skills_config.py # Google skills 初始化
      .env             # 儲存 API Key 等環境變數
    

    步驟二:設定 Google API 憑證與權限

    1. 前往 https://console.cloud.google.com/
    2. 建立專案,啟用:
    3. Gmail API
    4. Calendar API
    5. (若需 Drive,就再開啟 Drive API)
    6. 建立 OAuth 用戶端 / Service Account 憑證
    7. 下載憑證 JSON,放進你的專案中,路徑寫在環境變數(例如 GOOGLE_APPLICATION_CREDENTIALS)

    google/skills 會讀這些設定,幫你處理 OAuth 流程。第一次執行會要你開瀏覽器認證,通過後就可以長期使用。

    步驟三:初始化 skills

    # skills_config.py
    from google.skills import GmailSkill, CalendarSkill
    
    gmail_skill = GmailSkill(scopes=[
        "https://www.googleapis.com/auth/gmail.readonly",
        "https://www.googleapis.com/auth/gmail.send",
    ])
    
    calendar_skill = CalendarSkill(scopes=[
        "https://www.googleapis.com/auth/calendar",
    ])
    
    TOOLS = {
        "gmail": gmail_skill,
        "calendar": calendar_skill,
    }
    

    (實際類名與參數以官方 GitHub 為準,這裡是示意寫法。)

    步驟四:寫一個最小「每日報告」 Agent

    下面示意一個 純 Python + LLM + skills 的簡易 loop:

    # main.py
    import datetime as dt
    from skills_config import TOOLS
    from openai import OpenAI
    
    client = OpenAI()
    
    
    def get_today_summary():
        today = dt.date.today().isoformat()
    
        # 1) 用 Gmail skill 抓今天重要信件(實際用法依官方 API)
        important_emails = TOOLS["gmail"].search_messages(
            query="label:STARRED newer_than:1d"
        )
    
        # 2) 用 Calendar skill 抓今天所有事件
        events = TOOLS["calendar"].list_events(
            time_min=today + "T00:00:00Z",
            time_max=today + "T23:59:59Z",
        )
    
        prompt = f"""
    你是一個助理,請用條列整理以下資訊:
    1. 今日重要郵件(寄件人 + 主題)
    2. 今日會議(時間 + 標題)
    
    重要郵件:{important_emails}
    今日行程:{events}
    """
    
        resp = client.chat.completions.create(
            model="gpt-4o-mini",  # 或你使用的其他 LLM
            messages=[{"role": "user", "content": prompt}],
        )
        return resp.choices[0].message.content
    
    
    def send_daily_report():
        summary = get_today_summary()
        TOOLS["gmail"].send_message(
            to="your_email@example.com",
            subject="今日工作總覽",
            body=summary,
        )
    
    
    if __name__ == "__main__":
        send_daily_report()
    

    接下來只要用 crontab 或任一排程工具,每天早上 9 點跑一次 python main.py,你就有一個真正會「用 Gmail + Calendar 幫你工作」的小 Agent 了。


    延伸玩法:接到 LangGraph / MCP / 自建 loop

    google/skills 本身只是一組工具,你可以自由接到任何 Agent 框架。

    常見接法比較

    名稱 核心功能 免費方案 適合誰
    LangGraph 圖形化定義 Agent workflow、狀態機 開源 要做複雜流程 / 多工具協作
    MCP 標準化「工具伺服器」協議 規格開源 想讓多個模型共用同一組工具
    Simple loop(自建) while-loop + tool call + LLM 只要有 LLM 即可 想快速測試、腳本導向

    怎麼接 google/skills?

    • LangGraph:把 Gmail/Calendar skill 包成「tool node」,用 graph 描繪整條流程(例如:先讀 mail → 判斷 → 建行程)。
    • MCP:把 google/skills 包成 MCP 工具伺服器,就像 Reddit 上有人把產品目錄接到 Claude 一樣,任何支援 MCP 的 Agent 都能呼叫這組 Google 工具。
    • 自建 loop:如前面的 send_daily_report(),自己在程式裡控制什麼時候 call 哪個 skill。

    實務注意事項:安全、權限與 rate limit

    在公司環境用 google/skills,這幾點非常重要:

    1. 最小權限原則:
    2. 只開啟必要的 scopes,例如只讀 Gmail 就不要給 send 權限
    3. 針對不同 Agent 建不同憑證,避免權限過大
    4. 審計與日誌:
    5. 記錄每次工具呼叫(誰、什麼時候、對哪個帳號)
    6. 公司內部可用 SIEM / 日誌系統統一管理
    7. Rate limit 與配額:
    8. Google API 有配額,批次任務要加上 sleep / retry
    9. 測試環境與正式環境要分開憑證,避免測試爆掉正式配額
    10. LLM 安全邏輯:
    11. 對「寫入」類操作(寄信、刪除事件)加上確認步驟
    12. 可用 rule-based filter:例如禁止刪除某些標籤信件

    總結:把「會聊天的 LLM」變成「會用 Google 的助理」

    如果你已經每天活在 Gmail、Calendar、Drive 裡,google/skills 的價值很單純:

    • 你不用再對著 Google API 文件苦讀,只要調用現成的 skills
    • LLM 能真的幫你「按按鈕、拉資料、寫回去」,而不是只給你建議
    • 從個人行程助理,到團隊報表自動化,都可以在幾十行 Python 內完成第一個版本

    先從一個小腳本開始:「每日早上發報告」,跑通一次之後,你就會自然開始想把更多 Workspace 工作交給你的 Agent。

    🚀 你現在可以做的事

    • 打開 google/skills GitHub 專案,瀏覽支援的 skills 清單與範例程式
    • 依照文中的「每日報告 Agent」範例,在本機建立一個最小 Python 專案跑通一次
    • 在你的 Workspace 工作流中,挑一個「讀資料 → 整理 → 寄出」流程,試著用 google/skills + LLM 自動化它
  • 一句話就能寫的 iPhone 自動化

    一句話就能寫的 iPhone 自動化

    📌 本文重點

    • 新版捷徑可用自然語言生成跨 App 自動化
    • Siri in Camera 支援拍帳單自動分帳與付款
    • Safari、Photos 等 AI 功能都能串成工作流程

    講一句話,iPhone 幫你把一連串跨 App 的操作變成自動化流程,這就是新版 捷徑(Shortcuts)AI 工作流生成功能 + Siri AI 要解決的事。

    參考:Shortcuts 新功能報導(TechCrunch)▶︎ https://techcrunch.com/2026/06/08/apple-will-let-you-build-workflows-using-ai-in-its-new-shortcuts-app/


    核心功能:現在「講需求」就能生出捷徑

    1. 用自然語言生成捷徑:一句話變一條 workflow

    以前做捷徑,要一個一個 Action 拖拉;現在你可以直接在 Shortcuts 裡打字或跟 Siri 說:

    • 「幫我整理今天拍的照片到『今日精選』相簿,然後把 3 張最好看的用 Reframe 調整成適合 IG 的比例。」
    • 「以後 Gmail 收到標題含『發票』的信,把附件 PDF 存到 iCloud Drive 的『發票/2026』資料夾。」
    • 「每天晚上 10 點,把今天新增的照片做成 5 張圖文日記草稿存在備忘錄。」

    系統會做的事(你實際會看到):

    • 自動幫你建立一條捷徑,裡面已經串好「取得照片 → 篩選 → Photos Reframe → 存到相簿」等步驟。
    • 針對 Email/雲端檔案,會自動找對應的 Mail、檔案 App Action 串起來。
    • 你可以再手動微調條件,例如日期、相簿名稱、檔案夾位置。

    💡 關鍵: 只要一句自然語言描述,就能自動拆解成完整的捷徑工作流程,大幅降低設定門檻。

    可以馬上試的三句話(打進捷徑的 AI 提示框):

    • 「每天早上 8 點總結昨天的重要 email,用中文整理成 3 點重點,傳到我的備忘錄。」
    • 「下載我 Gmail 中今天所有附件,存到 iCloud Drive/工作/今天日期。」
    • 「每週一早上 9 點,把行事曆上本週的會議整理成列表,寄給自己。」

    行動建議:

    • 打開 捷徑 App → 新增 → 使用 AI 建立工作流程(以實際 iOS 介面為準),直接把上面其中一句貼進去,看它怎麼幫你拆解步驟。

    2. Siri in Camera 分帳:拍帳單 → 點菜 → 自動算錢

    這是新 Siri AI 最「有感」的實戰功能之一,官方示範在這裡:https://techcrunch.com/2026/06/08/apple-is-fixing-the-headache-of-splitting-the-bill-with-its-new-siri-in-camera-feature/

    流程拆解成你可以照做的步驟:

    1. 先準備
    2. 更新到支援 Siri AI 的 iOS 版本(見文末「怎麼開始」小節)。
    3. 在「設定 → 錢包與 Apple Pay」裡開好 Apple Cash,綁定帳戶或信用卡。

    4. 啟用 Siri in Camera

    5. 打開系統「設定」→ Siri → 確認有開啟「Siri in Camera」或類似選項(名稱以正式版為準)。

    6. 實際分帳操作

    7. 在餐廳結帳時:

      • 打開 相機 App,對準紙本帳單。
      • 長按畫面或點右下角出現的 Siri 圖示,啟動「Siri in Camera」。
      • 螢幕會標示出每一項餐點與金額,你:
      • 點選自己點的菜
      • 確認要不要平均分服務費、小費等
      • Siri 算出你應付的金額後,會跳出「使用 Apple Cash 支付給 XXX」的選單。
      • 按一下就完成付款。
    8. 進階:配合捷徑做「分帳記帳」

    9. 你可以另外建立一條捷徑:「當我用 Apple Cash 付錢給某位朋友時,自動在備忘錄『聚餐記錄』裡新增一條記錄(日期、金額、對象)。」
    10. 作法:
      • 在捷徑中搜尋 Apple Cash 相關 Action(或直接用自然語言生成:
      • 「當我用 Apple Cash 付款時,幫我記錄一條支出到備忘錄。」)

    行動建議:

    • 下次聚餐前先把 Apple Cash 設好,實際用 Siri in Camera 分一次帳,回家再用捷徑補上「記帳自動化」。

    💡 關鍵: Siri in Camera 把「看帳單 → 算錢 → 轉帳」這串麻煩流程壓縮成拍一次照、按一次確認。


    3. 其他 AI 功能:Safari 補字、照片 Reframe,都能變成 workflow 的一段

    根據 TechCrunch 報導,Safari、捷徑、密碼等系統 App 都接上了 AI:https://techcrunch.com/2026/06/08/apple-just-taught-your-iphone-to-finish-your-sentences-your-photos-and-your-workflows/

    這裡挑兩個最容易跟捷徑串在一起的:

    Safari:自動補文字 & 生成草稿

    Safari 內文輸入框(例如表單、留言)會有 AI 提示,可以:

    • 根據你已輸入的開頭,自動補完句子。
    • 根據網頁內容,產生回覆草稿(例如回客服信、填意見回饋)。

    怎麼跟捷徑配合?

    • 建一條捷徑:「當我在分享選單裡選擇『AI 回覆草稿』時,
      1)把目前網頁內容摘要 → 2)用 Siri AI 生成一段 100 字內中文回覆 → 3)複製到剪貼簿。」
    • 用自然語言下指令:
    • 「建立一個捷徑,從 Safari 分享頁取得文章內容,幫我寫一段禮貌回覆放到剪貼簿。」

    💡 關鍵: 把 Safari AI 補字和捷徑結合,可一鍵從網頁生成短版回覆,減少重複打字。

    Photos Reframe:一鍵重構照片構圖

    Photos 多了 Reframe,可以:

    • 把橫幅照片重構成直幅,重抓主體構圖。
    • 幫照片轉成適合 IG、限動等比例。

    搭配捷徑的用法:

    • 「選 10 張今天新拍的照片,用 Reframe 變成 9:16 比例,存到相簿『IG 候選』。」
    • 這句直接丟給 Shortcuts 的 AI,就會幫你串好:取得今天照片 → Reframe → 存到指定相簿。

    小工具一覽:哪個負責哪件事?

    資訊綜合自 TechCrunch、The Verge、Wired 報導:Siri AI、Shortcuts AI、Siri App

    名稱 核心功能 免費方案 適合誰
    捷徑(Shortcuts)AI 工作流 用自然語言生成跨 App 自動化流程 內建免費 想把重複操作變自動化的 iPhone 使用者
    Siri AI 新版 Siri,可讀螢幕、跨 App 操作、個人化互動 內建免費 習慣用語音/文字跟手機互動、要「講需求」就完成的人
    Siri in Camera 對著帳單拍照就能 AI 分帳 + Apple Cash 支付 內建免費(支付依銀行手續費) 常聚餐分帳、懶得算錢的人

    適合誰用?三種典型使用者

    1. 每天都在重複一樣操作的上班族
    2. 下班打卡 → 開導航回家 → 播放固定 Podcast → 開啟家裡的 HomeKit 燈具。
    3. 行動:把這句完整話丟給捷徑 AI,讓它幫你把這條「下班儀式」自動化。

    4. 拍很多照片、想要整理成內容的人

    5. 每天拍一堆照片,但懶得整理、寫日記、挑圖。
    6. 行動:做一條「晚上 10 點整理照片+日記草稿」的捷徑,讓 AI 每天幫你先挑、先寫,再來人工微調。

    7. 會議、課程超多的知識工作者 / 學生

    8. 常忘記開勿擾、錄音,或者會後才在找資料。
    9. 行動:用自然語言生一條「會議前 10 分鐘自動開勿擾+錄音」的捷徑,配合行事曆事件觸發。

    怎麼開始:版本需求、入口在哪裡?

    1. 需要哪個 iOS 版本?

    以目前公開資訊,這些功能會隨 新一代 Apple Intelligence / Siri AI 更新 推出:

    • 確認方式:
    • 到「設定 → 一般 → 軟體更新」看是否有標示 Siri AI / Apple Intelligence 相關更新。
    • 通常會需要最新主版本(例如 iOS 20 這級別),以及較新的 iPhone 型號。

    2. 哪裡打開新版 Shortcuts 與 Siri App?

    • 捷徑 Shortcuts:
    • 已內建在 iOS,找不到就到 App Store 搜「Shortcuts」。
    • 開啟後,點右上角「+」→ 留意有沒有「用 AI 建立捷徑」或類似按鈕。
    • Siri App(獨立版):
    • 更新後,主畫面會多一個 Siri App 圖示。也可以在 App 資料庫搜尋「Siri」。
    • 開啟後可以直接用文字或語音下指令,而不一定要喊「嘿 Siri」。

    推薦先練的 3 條小自動化(附自然語言模板)

    直接把以下句子丟給捷徑的 AI 入口就能開始:

    1. 下班自動開導航回家 + 播放 Podcast

    「當我離開公司地點時,自動在 Google Maps(或 Apple 地圖)開啟回家的導航,並在 Spotify(或 Podcast App)播放我最新一集的路上要聽的節目。」

    微調建議:

    • 把「公司地點」換成具體地址或地標。
    • 把播放 App 換成你實際使用的。

    2. 每晚 10 點整理今天照片+輸出日記

    「每天晚上 10 點,把今天新增的相片挑 10 張代表性的,用簡短文字說明今天發生什麼事,整理成一則備忘錄日記。」

    AI 會:

    • 自動拉出今天照片
    • 生成簡短摘要文字
    • 存成一則新備忘錄

    3. 會議開始前 10 分鐘自動開勿擾+錄音

    「當行事曆上有標成『會議』或『Meeting』的事件時,在開始前 10 分鐘自動開啟勿擾模式,並在會議時間內用語音備忘錄錄音。」

    你可以再加:會後寄一封含錄音連結的 Email 給自己。


    思考模板:如何把手動操作,轉成一句自然語言需求?

    只要照這四格填空,就能寫出一條適合丟給捷徑 AI 的句子:

    「在_情境 / 時間_,幫我自動_動作 A_,接著_動作 B_,最後把結果存到_位置 / App_。」

    幾個範例:

    • 「在每天早上 8 點,幫我自動把今天的行事曆整理成文字摘要,接著傳到 Slack 的 #daily 頻道。」
    • 「當我連上公司 Wi‑Fi,幫我自動開啟勿擾模式,接著打開公司 VPN App。」
    • 「當我在Safari 分享一篇文章時,幫我自動生成 3 點中文重點,最後把結果存到Notion 的『閱讀筆記』資料庫。」

    你要做的,就是把自己每天重複做的動作,照這個模板說出來,然後丟給 Shortcuts 或 Siri AI 來「幫你寫程式」。


    🚀 你現在可以做的事

    • 到「設定 → 一般 → 軟體更新」確認是否已支援 Apple Intelligence / Siri AI,並完成更新
    • 打開捷徑 App,使用「用 AI 建立工作流程」,貼上文中任一自然語言範例實測一次
    • 在下一次聚餐前設定好 Apple Cash,實際用 Siri in Camera 完成一次拍照分帳+付款流程
  • 一行指令組好自己的 AI 代理團隊

    一行指令組好自己的 AI 代理團隊

    📌 本文重點

    • 把每個 Agent 當成可版本控制的 Git repo
    • 用 AGENTS.md 與 skills/ 拆開角色與能力
    • .agentlas/ 管理記憶與設定,輕鬆切換模型
    • 用一行 CLI 指令生成並維護多代理 AI 團隊

    只用一行指令,你就能建立一個「像程式專案一樣可版本控制」的多代理 AI 團隊,解決長期記憶混亂、每次對話都要重講一遍的痛點。

    參考架構原文(作者在 Reddit 分享):https://www.reddit.com/r/artificial/comments/1twmhya/an_opensource_agent_architecture_that_solves_the/


    核心功能:把 Agent 當成一個 repo,而不是一段 prompt

    這套開源架構的關鍵想法:每個 Agent 是一個 Git 倉庫,而不是存在聊天框裡的一段系統 prompt。

    💡 關鍵: 把 Agent 轉成可版控的 Git repo,可以用熟悉的軟體開發流程(PR、review、版本管理)來調整 AI 行為,而不是每次重寫 prompt。

    1. AGENTS.md:把「人設 + 任務範圍」寫成文件,而不是憑記憶

    AGENTS.md 是這個架構的核心說明書,裡面通常會包含:

    • 每個代理的角色定位
    • 能做什麼(scope) / 不能做什麼(限制)
    • 彼此如何協作(誰丟任務給誰、輸出長什麼樣)

    你可以做的事:

    1. 在任意資料夾新增 AGENTS.md,用這樣的格式寫第一個代理:

    “`markdown
    # Agents

    ## doc_assistant
    – 角色:技術文件整理員
    – 任務:整理長篇文件、產生摘要與目錄
    – 輸出格式:Markdown,必須包含「摘要」「重點條列」「待釐清問題」三段

    ## code_reviewer
    – 角色:程式碼審查員
    – 任務:針對 Pull Request 提出具體修改建議
    – 限制:不直接改動程式,只提出建議與風險說明
    “`

    1. 把這個 repo 推上 Git(GitHub / GitLab),之後團隊改需求只改這份文件。

    2. skills/:把「能力」拆成工具,而不是糊在一大段 prompt 裡

    傳統代理常見問題是:所有指令、規則、流程都揉在一段很長的系統 prompt 中,改一行就怕爆。

    在這個架構裡,每個能力是一個 skill 檔案,放在 skills/ 資料夾,例如:

    • skills/summarize_docs.md:怎麼讀、怎麼切段、輸出格式
    • skills/review_pr.md:審查步驟、要檢查的細項
    • skills/fetch_urls.md:如何抓網頁、處理錯誤

    你可以做的事:

    1. 新增資料夾 skills/,寫一個最小可用的 skill:

    “`markdown
    # summarize_docs

    步驟:
    1. 讀取輸入文件
    2. 把文件拆成 3–7 個主題
    3. 每個主題用 3 行內說清楚

    輸出格式(Markdown):
    – 一句總結
    – 主題列表(子彈點)
    “`

    1. 在 AGENTS.md 裡指定某個 agent 可以使用 summarize_docs 這個 skill。

    3. .agentlas/:把「記憶和設定」存在檔案,而不是模型腦袋

    .agentlas/ 是這套系統自己的設定與記憶資料夾,用來存:

    • 各代理的偏好設定(語氣、輸出格式)
    • 長期記憶索引(不是直接塞進模型,而是存成檔、用時再讀)
    • 已完成任務的 metadata(方便日後追蹤與再訓練)

    這樣的好處是:

    • 不會把所有對話硬塞進「長期記憶」變成噪音
    • 每次執行前可以用規則選擇要載入哪一段內容

    你可以做的事:

    • 在 .agentlas/config.yaml 加上最基本設定(示意):

    yaml
    default_model: claude
    memory:
    enabled: true
    strategy: recent-and-related
    max_items: 50


    適合誰用:3 個具體場景

    1. 文件整理 + 程式碼審查:建立雙代理 pipeline

    目標:

    • 代理 A 整理設計文件
    • 代理 B 以文件為準則,審查 PR 是否符合設計

    你可以怎麼做:

    1. 在 AGENTS.md 定義兩個代理:

    “`markdown
    ## doc_assistant
    – skills: [summarize_docs]

    ## code_reviewer
    – skills: [review_pr]
    – 會先讀 doc_assistant 的輸出再開始審查
    “`

    1. 把專案文件放在 docs/、程式碼在 src/,PR diff 存到 pr/123.patch。

    2. 在終端機執行(以架構作者的描述為例):

    bash
    agentlas run doc_assistant "整理 docs/ 裡的文件,產出開發規範摘要"
    agentlas run code_reviewer "根據最新開發規範,審查 pr/123.patch"

    1. 審查邏輯日後有變,就更新 skills/review_pr.md,而不是重新教一次模型。

    2. 資料抓取 + 報表生成:自動化情報小幫手

    目標:

    • 代理 C 負責抓網站、清洗文字
    • 代理 D 讀整理後資料,輸出報表(例如每週競品動態)

    步驟:

    1. 在 skills/fetch_urls.md 寫清楚:怎麼從列表讀網址、輸出 JSON 或 Markdown 表格。

    2. 定義兩個 agent:

    “`markdown
    ## data_collector
    – skills: [fetch_urls]

    ## report_writer
    – skills: [summarize_docs]
    – 輸出格式:週報(含「本週重點」「風險」「下週觀察」)
    “`

    1. 每週只需要:

    bash
    agentlas run data_collector "從 urls.txt 抓內容,輸出到 data/this_week.md"
    agentlas run report_writer "讀 data/this_week.md,生成 weekly_report.md"

    1. 週報模板要改,就改 skills/summarize_docs.md 或另開 skills/weekly_report.md。

    3. 多人團隊:把「AI 同事」當成共同維護的 repo

    你可以把這個代理倉庫當成一個共享 AI SOP:

    • PM 改 AGENTS.md 描述角色與流程
    • 開發者在 skills/ 補上新的工具使用說明(例如專案腳本、內部 API)
    • 新同事只要 clone 下來,就能直接用同一套 AI 工作流

    實際做法:

    1. 建一個 GitHub repo:company-ai-agents。

    2. 定一條規則:

    3. 改 Agent 行為 = 改 AGENTS.md / skills/,必須走 PR 流程

    4. 不再使用的 Agent 要標記 deprecated,避免沒人知道它還在跑

    5. 在 README 裡寫清楚「如何在本機執行 agentlas、如何切換模型」。


    怎麼開始:一行指令 + 接上你習慣的模型

    這個架構的一大好處是:不綁特定模型,可以跑在 Claude Code、Codex、Gemini CLI 等環境。

    💡 關鍵: 架構與模型解耦,讓你能在不改 AGENTS.md 和 skills/ 的情況下,自由切換到成本更低或能力更強的模型。

    1. 安裝指令(假設已提供 CLI:agentlas)

    作者在 Reddit 說明,整套系統可以透過一行安裝:

    pip install agentlas  # 或作者實際提供的套件名稱
    

    接著在任意資料夾初始化:

    agentlas init
    

    這通常會自動產生:

    • AGENTS.md
    • skills/
    • .agentlas/

    你可以做的事:

    • 直接在一個新資料夾跑 agentlas init,把它當成「AI 同事模板專案」。

    2. 接上常見模型:Claude / Codex / Gemini CLI

    根據作者說明,這個架構支援多個 runtime,不鎖在某一家:

    • 想用 Claude:在 .agentlas/config.yaml 設定 runtime: claude_code
    • 想用 OpenAI / Codex:設為 runtime: codex
    • 想用 Gemini CLI:設為 runtime: gemini_cli

    範例設定:

    runtime: claude_code
    model: claude-3-5-sonnet
    api_key_env: ANTHROPIC_API_KEY
    

    你可以做的事:

    1. 先用你現在線上付費的模型(例如 Claude)跑通第一個 agent。

    2. 之後想切換模型,只改 config,不改 AGENTS.md 和 skills/ 的內容。

    3. 一句描述,讓系統自動幫你生出代理團隊

    根據 Reddit 原文描述,你可以直接用一句話生成整個代理團隊,例如:

    agentlas new "幫我建立一個:整理產品需求文件 + 產出技術任務清單的雙代理工作流"
    

    CLI 會:

    • 生成初版 AGENTS.md(定義 2 個代理)
    • 建好對應的 skills 檔案
    • 幫你填入基本步驟和輸出格式,之後你再微調

    你可以做的事:

    • 先讓工具幫你生一個「80 分」版本,再用 Git 慢慢調整到「95 分」。

    延伸閱讀:為什麼要從「串 prompt」升級到「Agent 專案」?

    如果你還在用 LangChain 式的「串 prompt + 自己管工具 schema」,可以參考這兩篇:

    這套開源架構跟 MCP 的共通點是:都把 Agent 當成一個長期維護的系統,而不是當場臨時寫的 prompt。

    差別在於,這裡用「實際檔案 + repo」把行為和記憶拆開,讓你可以用熟悉的 Git 流程維護整套 AI 工作流。

    現在你可以做的最後一件事:

    • 開一個新 repo,跑一次 agentlas init,寫一個最小的 AGENTS.md
    • 選一個你每天真的會用到的小流程(例如「整理會議紀錄」)
    • 把它做成第一個可版本控制的 AI 代理

    之後,每次你覺得「這件事好像可以交給 AI」,就把需求寫進 AGENTS.md 和 skills/,你自己的多代理 AI 團隊就會越長越完整。

    🚀 你現在可以做的事

    • 在本機建立新資料夾,執行 agentlas init,產出第一版 AGENTS.md 與 skills/
    • 選一個日常流程(如整理會議紀錄),寫進 AGENTS.md 並建立對應的 skills/xxx.md
    • 建一個 company-ai-agents repo,推上 GitHub,讓團隊透過 PR 共同維護你的 AI 代理 SOP
  • Gemini Spark 實測:讓 AI 幫你24小時跑腿

    Gemini Spark 實測:讓 AI 幫你24小時跑腿

    📌 本文重點

    • Gemini Spark 能在背景執行多步驟任務
    • 可長時間記住上下文並自動接續任務
    • 透過確認機制與權限設計平衡自動化與安全

    用一句話講白:Gemini Spark 就是一個 24/7 在背景幫你跑多步驟任務的 AI 小幫手,不用你一直開著聊天視窗盯著它。

    測試參考:The Verge 的實測與旅遊規劃體驗:Hands-on 1、Hands-on 2


    核心功能:跟「傳統聊天機器人」差在哪

    1. 主動在背景幫你跑多步驟任務

    傳統聊天機器人:

    • 你問它才回你
    • 一次只做一小段,關掉網頁就「記憶掰掰」

    Gemini Spark:你給他一個任務,它可以自己在背景跑完多步驟流程,再回來跟你報告。

    實際可以怎麼用:

    • 旅遊規劃 + 比價
      指令示例:

      「幫我規劃 10 月中從台北去東京 5 天家庭旅行,預算中等,要有 2 天親子行程。請:1)找出 3 個機票選項,考慮總飛行時間與轉機;2)比 3 家飯店,近地鐵、評價 4.3 以上;3)做出每日行程表。你可以在背景慢慢查,整理好再一次給我。」

    行動建議:第一次用 Spark 就拿「下一趟旅行」開刀,給它明確條件 + 步驟,讓它自己去跑,體驗差異最大。

    💡 關鍵: Spark 最大差異是能在背景獨立完成多步驟任務,最後一次性給你結果,而不是每一步都要你手動盯著。


    2. 長時間記得你在做什麼,自己幫你接續

    Spark 的另一個重點,是上下文可以拉得比較長,不只是當下這一輪對話。

    它會記得:

    • 你最近在規劃什麼(例如那趟東京行)
    • 你之前給過的偏好(例如「我不想一早就排景點」)
    • 它自己尚未完成的任務

    你可以這樣用:

    「接續之前的東京行程,幫我加上 1 天只逛博物館和書店的行程,然後把所有訂票與景點的連結整理成一封 email 草稿給我。」

    Spark 不用你重新貼所有內容,它自己接上前一次任務,把新要求整合進去。

    行動建議:遇到「要改舊計畫」時,不要重講一遍,直接說「接續上次 XX 任務,幫我多做……」,讓 Spark 幫你維護脈絡。


    3. 重要步驟前會停下來問你

    The Verge 的實測中提到:Spark 在敏感動作前會跳出確認,而不是默默幫你亂動。

    常見的確認點會包括:

    • 要寄出 email 前
    • 要變更行事曆 前
    • 要存取新服務或帳號 時

    使用方式:

    • 把 Spark 想像成「實習生」:
    • 你可以說:「先幫我草擬,不要真的送出。」
    • 或:「這類會議邀請之後可以直接幫我接受。」

    行動建議:第一次設定時,刻意跟它說清楚:

    「所有會寄出去給別人的內容,一律先給我草稿,不要自動送。」

    這樣你就能享受自動化,又不會被它「幫過頭」。


    適合誰用?3 個具體場景

    1. 旅行規劃:從「列點子」變成「整包交辦」

    The Verge 的旅行實測裡,作者說 Spark 是第一個讓他覺得旅遊規劃真的可以交給 AI 的工具,因為它會:

    • 不只列景點,還會看交通、預約限制、開放時間
    • 幫你平衡:太緊湊 / 太鬆、戶外 / 室內、購物 / 觀光

    你可以照抄這個 workflow:

    任務目標:幫我規劃 4 天 3 夜的首爾行程,預算偏省,重點是美食跟咖啡廳。
    限制:
    - 不要一早 9 點前的行程
    - 每天最多排 2 個需要事先訂位的地方
    - 交通以地鐵為主
    請:
    1. 先問我出發時間與大概預算
    2. 自己在背景查資料,整理成表格(時間 / 地點 / 交通 / 必點餐點或特色)
    3. 把所有需要訂位的頁面連結整理,獨立列出清單給我。
    

    行動建議:把旅遊需求拆成「目標+限制+要輸出的格式」,這樣 Spark 做出來的東西比較接近可以直接用的版本。


    2. 跨時區會議統整:讓 Spark 當你的時區翻譯機

    如果你常跟美國、歐洲同事開會,Spark 可以做的事情包括:

    • 幫你把一串 email 往來整理成待辦清單
    • 自動換算時區,找幾個可行的會議時間
    • 產生英文 / 中文雙語的會議邀請草稿

    指令示例:

    「我等等會轉寄給你一整串關於新專案的 email。請幫我:1)整理每個人各自承諾要做的事;2)找出下週台北時間 9:00–11:00、倫敦時間 9:00–18:00 之間都可行的 3 個時間;3)根據這串內容寫一封英文會議邀請草稿給團隊。」

    行動建議:

    • 寫指令時,先描述要的結果,再說你會提供什麼資料(例如會轉寄 email)。
    • 用「台北時間」「倫敦時間」等明確描述,避免只寫「我早上」。

    3. 日常代辦追蹤:把「總是忘記回信」交給它

    Spark 比較實用的一點是:它可以「掛在那裡幫你盯」,而不是你想到才去查。

    你可以把它當作:

    • Email 回覆提醒
    • 文件閱讀與摘要助手
    • 日常待辦整理員

    範例指令:

    「從今天開始,幫我追蹤 Gmail 裡標成星號的信:
    1)每天下午 5 點,整理一份『還沒回覆的星號信』列表給我,包含:寄件人、主題、收到時間、你建議的 1 句回覆重點;
    2)對於你有把握的簡單信件,可以先幫我產生回覆草稿。」

    行動建議:

    • 先選「一個小範圍」讓 Spark 幫你追(例如星號信),不要一開始就全信箱開放。
    • 每週檢查一次它生成的草稿,你會越來越知道怎麼跟它講需求。

    優點與限制:實測感受整理

    優點

    • 真的可以放著不管:The Verge 的體驗中,Spark 在你離線時也會繼續查資料、比對選項,最後給你整理好的結果。
    • 願意多問幾句確認:不像很多 Agent 一次衝到底,Spark 會分段跟你確認,讓你改方向。
    • 整合 Google 服務有優勢:像 Gmail、Calendar、Docs 等,對已在 Google 生態系的人尤其方便。

    限制與風險

    • 速度不一定快:多步驟任務,等 5–15 分鐘甚至更久是常態,不適合「立刻要答案」。
    • 隱私顧慮:要讓它看 Gmail、行事曆,等於多了一個能讀你資料的「人」。The Verge 也特別提醒了這點。
    • 目前功能和價格仍在調整中:不同地區可能有功能差異,也可能需要訂閱 Gemini 付費方案才用得到完整版。

    行動建議:

    • 先從「不那麼敏感」的任務測試(旅行規劃、公開資訊整理),習慣它的行為再逐步開放更多權限。

    💡 關鍵: Spark 適合放在「不急但複雜」的任務上,接受它可能要 5–15 分鐘換來的是你少了大量瑣事。


    怎麼開始:開通、免費用到哪裡、權限怎麼設

    以一般個人使用者為例,實際介面可能會隨時間更新,建議以官方說明為準:https://gemini.google/overview/agent/spark

    1. 快速開通與入口

    大致流程會長這樣:

    1. 登入 Google 帳號(建議用你平常收信、排行程那個帳號)。
    2. 前往 Gemini 頁面,找到 Spark 開關或切換(Chat ↔ Spark)。
    3. 按提示完成初始設定:
    4. 選擇語言、地區
    5. 勾選同意條款
    6. 決定是否要讓它讀 Gmail / Calendar 等

    行動建議:初次設定時,能跳過的權限先跳過,等確定要用再打開。


    2. 哪裡能免費用到?

    Google 目前的作法通常是:

    • 基本 Gemini 功能提供免費層級
    • 進階功能或高用量則綁定 Gemini Advanced / Google One AI Premium 類型訂閱

    Spark 很可能會:

    • 在部分地區提供測試或限量免費
    • 或綁在付費方案裡,讓你有更高配額與完整 Agent 能力

    行動建議:

    • 先確認你所在的地區是否開放 Spark,並在 Gemini 介面查看是否需要升級方案。
    • 如果有試用期,先集中在那段時間安排幾個「真實任務」給它做,評估值不值得付費。

    3. 權限與通知:好用但不要被吵

    要兼顧方便與不打擾,可以這樣設:

    (1)資料權限:

    • 先只開 Gmail / Calendar 的「讀取」權限,不給「全自動修改」。
    • 明確跟它說:

      「除非我說可以,否則不要自動變更行事曆或寄出任何 email。」

    (2)通知策略:

    • 手機端:
    • 保留「任務完成摘要」通知
    • 關閉「每一步都提醒」的通知
    • 你可以設一個固定時間:

      「每天晚上 9 點幫我整理今天你做了什麼、一件概要就好。」

    行動建議:把 Spark 當成「一天回報一兩次的助理」,而不是 Slack 機器人那樣每十分鐘跳出來吵你。

    💡 關鍵: 先給 Spark 讀取多於寫入的權限,並限制通知頻率,可以在安全邊界內體驗自動化。


    總結:怎麼寫出 Spark 用得懂、又做得好的指令?

    可以記這個模板:

    目標 + 限制條件 + 步驟 / 輸出格式 + 背景運作說明

    範例:

    「目標:整理我這週所有會議記錄,變成一份 1 頁的執行摘要。
    限制:只用我提供的文件,不要自己亂查資料。
    步驟:1)讀完我丟給你的 5 份會議記錄;2)列出所有待辦與負責人;3)寫一段 200 字內的總結。
    背景:你可以在背景慢慢做,完成後一次給我,不用中途打擾。」

    從一兩個小任務開始,習慣這種「把事交給 AI 跑完再回報」的工作方式,你會很快感受到:Spark 的價值不在於多會聊天,而是在於很多你不想做、但又非得有人做的細碎工作,它可以默默幫你扛掉。

    🚀 你現在可以做的事

    • 挑一個即將到來的旅程,照文中的「目標+限制+格式」模板寫一個 Spark 指令
    • 從 Gmail 星號信中選一小段範圍,讓 Spark 嘗試幫你追蹤與產生回覆草稿
    • 依照文中的權限與通知建議,在 Gemini 介面中完成 Spark 的初始設定與權限調整
  • 用 Claude+n8n 打造會自己跑的 AI 工作流

    用 Claude+n8n 打造會自己跑的 AI 工作流

    📌 本文重點

    • 用 Claude /goal、/loop 自動化長流程任務
    • 用 n8n 串 API、Email、DB 打造完整工作流
    • 一定要保留「人工審核閘」避免 AI 誤發內容

    用 Claude 搭配 n8n,你可以把「每週拉數據、寫報告、發信或更新網站」這種例行公事交給 AI 自動跑完,只在最後一關人工點頭即可。


    核心功能:這套組合幫你做什麼?

    1. Claude 長任務指令:/goal、/loop 讓 AI 自己把事做完

    先理解 Claude 的幾個關鍵指令(在 Claude Code 或支援指令的環境使用):

    • /goal:一次講清楚最終目標,讓 AI 自己拆步驟、規劃流程、按順序執行。
    • /loop:針對一批項目重複跑同一種處理,例如對 50 個關鍵字依序寫摘要、產出標題。
    • /batch:一次處理多筆輸入,適合批次內容生成或批次分析。

    可參考這篇詳細說明:Claude Code: The Autonomous Commands…

    你可以馬上做的事:

    • 在 Claude 裡建一個新專案,貼上你常做的流程(例如「每週 SEO 報表」),試著用這個提示:

    /goal
    目標:我想把「每週 SEO 報表」變成一個自動流程。
    請你:
    1. 問我目前是怎麼做(包含用到哪些工具、檔案格式)
    2. 拆成清楚步驟,分出「AI 可以做」和「一定要人工做」
    3. 用適合 /loop 或 /batch 的地方標註出來


    2. n8n:把 API、Email、資料庫都接在一起

    n8n 是一個開源自動化工具(像是開源版 Zapier),負責把「資料源 → Claude → 發送結果」串起來。

    常用節點大概就是:

    • Trigger:時間觸發(Cron),例如每週一早上 9 點跑一次。
    • HTTP Request / API 節點:去叫 Google Search Console、SEO 工具、你的內部系統。
    • Claude / OpenAI 類節點:把資料丟給 Claude 分析或生成內容。
    • Email / Slack / Notion 節點:把結果送到你或客戶手上。

    你可以馬上做的事:

    • 註冊 n8n(雲端版)或用 Docker 在本機跑:https://n8n.io
    • 開一個最簡單 workflow:
    • Cron → HTTP Request → Email
    • HTTP Request 隨便先叫一個公開 API(例如 Github trending),收回結果後,用 Email 節點寄給自己,確認「API → 自己」這條管線沒問題。

    3. 人工審核閘:一定要保留的「最後一關」

    這一步是整篇文章最重要的重點。

    在一篇實戰分享裡,作者用 Claude + n8n + SE Ranking API 自動產出客戶 SEO 週報,為了省 token 做了一個「優化」:當某些欄位沒資料時,讓 Claude 自己補。結果 Claude 開始用其他客戶的品牌數據去補空缺,還一臉正常,差點寄給一整串客戶,最後是靠人工審核節點擋住了災難(原文連結)。

    💡 關鍵: 再「聰明」的自動化流程也可能補錯資料,最後一關一定要由人審核才能避免嚴重誤發。

    結論:千萬不要把最後的人審自動化掉。

    你可以馬上做的事:

    • 在 n8n 裡加一個「人審」節點(可以是):
    • 把報告先丟到 Slack 私訊給你,附兩個按鈕:Approve / Reject。
    • 或者寄到你 Email,只有你手動轉寄給客戶才算「送出」。
    • 規則很簡單:
    • AI 可以草擬與整理,
    • 你來決定要不要「正式送出」。

    實戰案例:自動 SEO 週報(含人審)

    參考 Reddit 上「Claude is my entire SEO team」的做法(原文),我們做一個最小可行版本:

    流程圖(文字版)

    1. Cron 觸發:每週一 09:00。
    2. 抓數據:n8n 呼叫 Google Search Console / SE Ranking / GA4 API。
    3. 整理成 JSON/CSV:在 n8n 做基本清洗、欄位統一。
    4. 丟給 Claude:
    5. 提示大意:

      “`
      你是一位 SEO 分析師。請根據以下資料:
      – 找出本週與上週的主要變化(曝光、點擊、CTR、排名)
      – 標記前三個值得關注的關鍵字或頁面
      – 用「給客戶看的語氣」寫一份 300-500 字報告
      – 最後用 bullet points 給出下週三個具體行動建議

      資料如下(JSON):
      {{data}}
      “`

    6. 產出報告草稿:Claude 回傳 Markdown 或 HTML。

    7. 人工審核閘:
    8. n8n 把草稿丟到 Slack 或 Email。
    9. 你檢查內容、改幾句,手動按「OK」。
    10. 正式發送:
    11. n8n 把最終版本寄給客戶,存一份到 Notion/GDrive。

    你可以馬上做的事:

    • 先不接 API,把第 2 步改成「從 Google Search Console 下載 CSV,手動上傳到 n8n」:
    • n8n workflow:Manual Trigger → Upload(Webhook / Form)→ Claude → Email to yourself。
    • 等流程穩定,再把手動上傳改成 API 自動抓。

    多代理與 MCP:什麼時候要用,什麼時候別急著上

    當你開始想:

    • 一個 Agent 負責抓資料
    • 一個 Agent 負責分析
    • 一個 Agent 負責 QA / 測試

    就會踩到「多代理系統」與 MCP(Model Context Protocol)的世界。

    有人已經用 Claude Agent SDK + MCP 做出:

    • 看板(Kanban)每張卡片就是一個開發任務
    • Cron 定時啟動 Claude,為每張卡開一個隔離環境,
    • 拉 repo → 寫 code → Git 提交 → Vercel 建預覽 → 第二個 Claude 做 QA 測試 → 不過就自動重試(案例影片)。

    但實務上,多代理+多個 MCP server 很容易變成:

    • 工具太多、描述太長,模型不斷選錯工具。
    • 每次調用都把全部工具 schema 塞進 context,token 成本暴漲(有研究與實務案例顯示,長 agent run 可能是一般聊天的 1000 倍 token)。

    💡 關鍵: 多代理與 MCP 雖強大,但會大幅拉高複雜度與 token 成本,先把單一流程跑穩再擴充效益最高。

    建議:先把單一流程 + 人審做好,再考慮多代理。

    你可以馬上做的事:

    • 若你不是工程背景,目前只要記得兩件事:
    • MCP = 讓 AI 直接操作一堆內部工具的「插座規格」。
    • 「工具越多越好」是錯誤想像,實務上要刻意減少工具數量,讓 AI 比較不會選錯。

    適合誰用:三種典型場景

    角色 / 團隊類型 痛點 可以先做的第一條工作流
    個人創業者 / 獨立站長 每週 SEO 數據、內容企劃很花時間 自動 SEO 週報 + 下週內容建議(保留人審)
    接案顧問 / 行銷代理商 多個客戶週報、月報內容高度重複 客戶週報模板 + 客製評論區,由 Claude 先填、你負責最後一段「專業觀點」
    內容團隊主編 多篇文章排程、更新 meta、內鏈整理 用 /loop 對多篇文章產出標題、描述,n8n 更新到 CMS 草稿,人工再審核發佈

    工具比較:Claude、n8n 以及類似選項

    名稱 核心功能 免費方案 適合誰
    Claude (Claude Code) 長任務指令(/goal、/loop)、多代理、強文字與程式處理 有免費網頁版與有限額度 需要寫報告、寫程式、設計長流程的人
    n8n 視覺化工作流、自動化各種 API/Email/DB 有自架免費版,雲端有免費層 想用「拖拉方式」把不同工具串起來的人
    Zapier/Make SaaS 自動化平台,介面更友善,內建大量整合 有免費層但步數較少 不想部署系統,只想快點測試概念的人

    💡 關鍵: Claude 負責「想與寫」,n8n 和 Zapier/Make 負責「串與送」,搭配起來才能形成真正的自動化流水線。


    怎麼開始:從「一個安全的流程」練起

    按照這個順序,你可以在半天內完成第一條「會自己跑,但有你把關」的 AI 工作流:

    1. 開通帳號
    2. 註冊 Claude 帳號:https://claude.ai
    3. 註冊 n8n(雲端或自架):https://n8n.io

    4. 在 Claude 裡寫清楚你的「流程說明書」

    5. 建一個專屬專案,新增檔案 WORKFLOW.md,內容包含:

      • 你每週報告的步驟
      • 用到資料來源
      • 哪些步驟你不想讓 AI 自動做(例如「最後寄給客戶」)
    6. 做第一個最小工作流(本機測試版)

    7. n8n:Manual Trigger → 手動貼 CSV → Claude → Email 給自己。
    8. 實際跑一次,看 Claude 生成的報告是否接近你平常寫的內容。

    9. 加上人工審核閘

    10. 把收件人改成你的 Slack / 私人 Email。
    11. 只有你手動確認後,才另外轉寄給客戶或上線。

    12. 再考慮進階:API、自動抓數據、多客戶分流

    13. 等你對這條流量和錯誤模式有感覺後,再把手動步驟替換成 API。

    只要守住「AI 做草稿,人做決定」這一條線,你就可以放心把「會自己跑」的工作流丟給 Claude 和 n8n,真正把時間留給需要判斷與創意的事情。

    🚀 你現在可以做的事

    • 在 Claude 建一個專案,照文中範例貼上你的「每週報表流程」並用 /goal 讓它幫你拆步驟
    • 在 n8n 建立「Cron → HTTP Request → Email」或「Manual Trigger → Claude → Email」的最小工作流
    • 為現有任一例行報告加上一個「人工審核閘」,先從「AI 草擬、人來定稿」開始運行
  • Gemma 4 12B:16GB 筆電就能跑的多模態模型

    Gemma 4 12B:16GB 筆電就能跑的多模態模型

    📌 本文重點

    • Gemma 4 12B 可在 16GB 筆電本地跑起多模態助理
    • 支援 256K tokens 長上下文與 140+ 種語言
    • 多種推理框架與量化選項,依硬體彈性部署

    只要一台 16GB RAM 的筆電,你就能在本地跑起能看圖、懂多語言、支援長上下文的開源模型 Gemma 4 12B,當自己的離線 AI 助理。

    官方與模型頁:
    – Google DeepMind 介紹(英):The Decoder 報導
    – 模型權重:google/gemma-4-12b(Hugging Face)


    核心功能:這顆模型為什麼值得你在本地跑

    1. 多模態:同時處理文字、圖片,部分變體還支援音訊

    Gemma 4 12B 是 Google DeepMind 釋出的開放權重模型,可以:

    • 文字 → 文字:聊天、摘要、寫程式
    • 圖片 → 文字:看截圖、PPT、流程圖說明內容
    • (部分 12B 變體)音訊 → 文字:理解語音內容(需支援音訊版模型,見 Hugging Face 說明)

    你可以馬上實作:

    • 把專案架構圖或 UI 截圖丟給 Gemma 請它「用條列解釋每一塊的功能」
    • 拍下白板會議內容,請它整理成待辦清單 + 行動項目

    模型介紹討論可參考 Reddit:google/gemma-4-12B · Hugging Face


    2. 超長上下文:最多 256K tokens,做「整個資料夾」級別的助理

    Gemma 4 系列支援最高 256K tokens 上下文,適合處理:

    • 整本 PDF、技術規格書
    • 一整個 repo 的多檔案閱讀
    • 長對話紀錄與多輪推理

    能做的實際事情:

    • 丟一本 300 頁 PDF:請它依「章節 + 行動建議」整理摘要
    • 為專案整個 docs/ 資料夾建一個「本地 FAQ 助理」,用自然語言查文件

    進階提示:長上下文會吃 RAM,你在本地使用時可先把 context window 設在 16K~32K,等硬體 OK 再拉高。

    💡 關鍵: 高達 256K tokens 的上下文,讓你可以一次處理整本書或整個專案,而不用頻繁切段或換檔。


    3. 多語言 + 商用授權:可以直接放進產品

    根據 Google 與社群測試,Gemma 4 支援 140+ 種語言,在英文之外,中文、日文、歐洲語言表現都夠用;
    同時採用 Apache 2.0 授權,可用於商業產品(只需保留版權聲明)。

    你可以馬上行動:

    • 做一個「中英雙語客服 FAQ Bot」,在公司內網跑,不要雲端 API
    • 把它包成內部工具,處理公司文件、程式碼審閱,不用擔心資料外流

    授權與開源定位說明,可參考 The Decoder 報導與 Reddit 貼文:
    – The Decoder:Gemma 4 12B
    – Google just dropped Gemma 4 12B on your laptop!!

    💡 關鍵: Apache 2.0 商用授權加上 140+ 語言支援,讓 Gemma 4 12B 可以直接被放進正式產品中,而不只是一個玩具模型。


    適合誰用:三個實戰場景

    1. 本地文件助理:讀 PDF、企業知識庫、不出網就能查

    典型流程:

    1. 把 PDF/Markdown/Word 轉成純文字
    2. 用向量資料庫或簡單關鍵字搜尋切成小段
    3. 把相關段落 + 問題一起送進 Gemma 4 12B

    具體可以做:

    • 法律條款查詢:輸入「幫我比較第 5 條和第 8 條的差異,列成表格」
    • 公司內訓教材:輸入「只針對新進工程師,整理第一章的必讀重點」

    行動建議:

    • 不想寫程式:用桌面端 UI 工具(例如 LM Studio)載入 Gemma 4 12B 的 GGUF 量化版,搭配內建「本地檔案知識庫」功能。
    • 能寫 Python:用 transformers + chromadb 或 llamaindex 搭一個最小可用的 RAG 查詢腳本。

    2. 圖片理解:看設計稿、截圖除錯、手寫筆記整理

    Gemma 4 12B 的多模態版本可以直接吃圖片:

    可以做的事:

    • 把前端 UI 截圖給模型:「列出這個畫面的功能區塊,以及可能漏掉的錯誤狀態」
    • 拍課堂黑板或手寫筆記:「幫我轉成 Markdown 大綱,並補上可能缺的步驟」

    行動建議:

    • 使用 Ollama:安裝後直接用
      bash
      ollama pull gemma4:12b
      ollama run gemma4:12b

      再在聊天 UI 裡丟圖片與文字問題。

    • 若走 transformers:選用多模態 checkpoint(Hugging Face 上會標示 image / vision 支援),用官方範例載入 processor + model 後送入 images + texts。


    3. 簡單程式輔助與本地 Coding Agent

    在 Reddit 測試中,有人把 Gemma 4 12B 接進 VSCodium + Pi Agent,讓它:

    寫一個 Python 腳本:讀取 log 檔 → 抓出 error module → 統計後輸出 JSON,還自己產 mock data、在終端測試,一次成功。(案例連結)

    你可以:

    • 在 VS Code 裝本地 LLM 外掛(如 Continue / Pi Agent 等),指定後端使用本地 Gemma 4 12B
    • 常見用法:
    • 「寫一個腳本批次重命名資料夾裡的圖片」
    • 「讀這個函式庫的 README,給我最小可行 demo」

    行動建議:

    • 若你有 NVIDIA GPU(如 3060 以上):用 mistral.rs 或 llama.cpp + CUDA,可以得到更順暢的互動速度。

    推理框架比較:Ollama / Transformers / llama.cpp / mistral.rs

    下表給你一眼看懂各工具適合誰:

    名稱 核心功能 免費方案 適合誰
    Ollama 一行指令拉模型、簡單本地聊天 UI 免費 想最快跑起 Gemma 4、只想用不想調參的人
    Transformers 直接操作 Hugging Face 權重 免費 Python 開發者、要客製 RAG / Agent 的人
    llama.cpp CPU/GPU 皆可的輕量推理框架 免費 只有 CPU 或老 GPU、需要 GGUF 量化的人
    mistral.rs 針對 CUDA 極速優化的推理框架 免費 有 NVIDIA GPU,追求吞吐和延遲的進階玩家

    補充:mistral.rs v0.8.2 在 Gemma 4 上,對多種 GPU(GB10 / B200 / H100)推理速度可比 llama.cpp 快到 2.8 倍(來源)。

    💡 關鍵: 若你有 NVIDIA GPU,mistral.rs 在 Gemma 4 上可達到比 llama.cpp 快約 2.8 倍的推理速度,大幅縮短互動延遲。


    硬體需求與量化:16GB 筆電怎麼選

    Gemma 4 12B 是 120 億參數等級的模型,但經過量化後可以塞進 16GB RAM 甚至更小機器上。

    基本建議:

    • 16GB RAM / 無獨顯:
    • 量化:4-bit(如 Q4_K / Q4_0)
    • 框架:Ollama、llama.cpp GGUF
    • 用途:文件整理、輕量對話、簡單程式輔助

    • 16GB RAM + 6–8GB VRAM(如 3060 Laptop):

    • 量化:4-bit 或 8-bit(看 VRAM 是否足夠)
    • 框架:mistral.rs(CUDA)、llama.cpp(GPU offload)、Ollama(自動 GPU 利用)
    • 用途:多輪對話、圖片理解、較密集的程式輔助

    若不確定自己機器能跑多大模型,可以用社群做的互動網站(類似「選模型大小 + 量化 → 即時計算 VRAM」工具,來源自 這篇 Reddit 貼文),先估算記憶體需求,再決定下載哪一個量化版本。


    怎麼開始:最簡路線 3 步驟

    路線 A:用 Ollama,三分鐘跑起 Gemma 4 12B

    適合:Mac / Windows / Linux,一行指令就想用的人。

    1. 安裝 Ollama:到 ollama.com 下載並安裝
    2. 在終端執行:
      bash
      ollama pull gemma4:12b
    3. 開始對話:
      bash
      ollama run gemma4:12b

      在對話中可以直接貼文字、上傳圖片,嘗試:
    4. 「幫我把這份 PDF 的重點整理成五條」
    5. 「看這張 UI 截圖,列出使用者可能會卡關的地方」

    路線 B:用 Hugging Face Transformers,做自家工具的核心模型

    適合:會 Python、想整合到後端或自製 UI 的開發者。

    1. 安裝套件:
      bash
      pip install transformers accelerate safetensors
    2. 在程式裡載入(以文字模式為例):
      “`python
      from transformers import AutoModelForCausalLM, AutoTokenizer

    model_id = “google/gemma-4-12b-it” # instruction-tuned 版本

    tokenizer = AutoTokenizer.from_pretrained(model_id)
    model = AutoModelForCausalLM.from_pretrained(
    model_id,
    device_map=”auto”,
    torch_dtype=”auto”,
    )

    prompt = “請用條列幫我整理這段技術文件的重點:…”
    inputs = tokenizer(prompt, return_tensors=”pt”).to(model.device)
    outputs = model.generate(**inputs, max_new_tokens=512)
    print(tokenizer.decode(outputs[0], skip_special_tokens=True))
    ``
    3. 若要圖片理解:選擇 Hugging Face 上標示支援 vision 的變體,搭配對應
    processor` 載入即可。


    路線 C:追求速度,用 mistral.rs / llama.cpp 跑量化版

    適合:有 NVIDIA GPU、想把延遲壓到最低的人。

    大致流程:

    1. 到 Hugging Face 找到 Gemma 4 12B 的 GGUF 或量化權重(搜尋 gemma-4-12b gguf 等)
    2. 安裝框架之一:
    3. mistral.rs
    4. llama.cpp
    5. 用官方 README 範例載入模型後,設定:
    6. n_gpu_layers 或類似參數,把前幾層放 GPU
    7. context_length:先從 16K 開始測試,再視記憶體往上調

    操作上可以先用簡單指令測試:

    ./main -m gemma4-12b-q4.gguf -p "幫我用三點整理這段文字的重點:..."
    

    確認速度和記憶體使用量,再決定是否改用更高精度的量化。


    如果你已經習慣雲端 LLM,Gemma 4 12B 是一個很好的起點,讓你在只靠 16GB 筆電的情況下,把「看圖、讀文件、寫程式」這三件事拉回自己機器上運行;從現在起,你可以把它當成本地端的多模態助手,按照上面的三條路線選一條裝起來,今晚就能實際用在手邊專案上。

    🚀 你現在可以做的事

    • 到 ollama.com 安裝 Ollama,執行 ollama pull gemma4:12b 在本地跑起模型
    • 前往 Hugging Face 搜尋 google/gemma-4-12b,挑選一個適合你硬體的量化版本下載
    • 在 VS Code 安裝本地 LLM 外掛(如 Continue / Pi Agent),後端連接本地 Gemma 4 12B 做程式輔助