分類: AI 工具

  • 用 openai-agents-python 搭一個 AI 小團隊

    用 openai-agents-python 搭一個 AI 小團隊

    📌 本文重點

    • 用多個專職 agent 分工處理一個大任務
    • 透過 orchestrator 串起明確的多步驟流程
    • 將既有 API / 工具包成 @tool 打造可落地工作流
    • 先做最小 demo,再逐步擴展到既有系統

    只靠一個聊天機器人常常做出「四不像」的結果,而 openai‑agents‑python 要解決的,就是讓你把一個大任務拆給多個各司其職的 AI 代理人,像一個小團隊一樣協作完成。

    GitHub 專案連結:https://github.com/openai/openai-agents-python


    核心功能:把一個大任務拆給多個 AI

    1. 定義多個專長不同的 Agent

    你可以在程式裡定義多個「角色」:

    • 資料蒐集 agent:負責上網查資料、整理重點
    • 寫作/寫程式 agent:負責產出初稿或程式碼
    • 審稿 agent:負責檢查結構、風格、錯字或潛在 bug

    這些都用 Python class 或函式就能描述,像這樣:

    from openai_agents import Agent
    
    researcher = Agent(
        name="researcher",
        instructions="你負責閱讀提供的資料,整理三個重點與參考連結。",
    )
    
    writer = Agent(
        name="writer",
        instructions="你負責寫出條列清楚的技術部落格草稿,語氣教學向。",
    )
    
    reviewer = Agent(
        name="reviewer",
        instructions="你負責審稿,只給出修改建議與需要補充的段落。",
    )
    

    行動:先想一個你日常會做的「三步驟」任務,直接對應成三個 agent 的職責。


    2. 設計任務流程:交接、審查、協作

    openai‑agents‑python 的重點不只是「多個 agent」,而是讓你把流程寫清楚:誰先做、誰接手、誰審查。

    例如做一個「自動寫技術部落格」的流程:

    1. researcher:根據題目蒐集資料,產出重點摘要
    2. writer:根據摘要寫出完整草稿
    3. reviewer:審稿,給出修改建議

    💡 關鍵: 把一長串需求拆成 2–3 個明確步驟,比一次丟給單一聊天模型更穩定、可控。

    在框架裡你可以用一個 orchestrator(像主揪)來控制:

    from openai_agents import Orchestrator
    
    orchestrator = Orchestrator(agents=[researcher, writer, reviewer])
    
    async def run_blog_flow(topic: str):
        research_notes = await orchestrator.run("researcher", input={"topic": topic})
        draft = await orchestrator.run("writer", input={"topic": topic, "notes": research_notes})
        review = await orchestrator.run("reviewer", input={"draft": draft})
        return {"draft": draft, "review": review}
    

    行動:把你現在用 ChatGPT 一次請他「幫我想題目、寫文、修稿」的流程,拆成 2–3 個步驟,寫在紙上,對應到上面這種 orchestrator 程式碼結構。


    3. 串接外部工具與 API,變成真的工作流

    openai‑agents‑python 支援 agent 呼叫你自定義的工具函式,例如:

    • 網頁爬蟲(requestsPlaywright
    • 存取資料庫或 Google Sheets
    • 操作檔案系統,輸出成 Excel / CSV

    你先寫好 Python 函式,再把它註冊給 agent 使用:

    import requests
    from openai_agents import tool
    
    @tool
    def fetch_url(url: str) -> str:
        """抓取指定網址的 HTML"""
        return requests.get(url, timeout=10).text
    
    scraper = Agent(
        name="scraper",
        instructions="根據給定網址抓網頁內容並擷取需要的欄位。",
        tools=[fetch_url],
    )
    

    行動:先選一個你常用的 API(例如某個內部 HTTP API、Notion API),包成一個最小的 @tool 函式,讓 agent 能直接呼叫。


    Demo:一晚內做完的「自動寫技術部落格」小團隊

    這裡做一個最小可用版本:輸入一個主題,幫你:

    1. 蒐集重點
    2. 產生技術部落格草稿
    3. reviewer 做一次審查,輸出建議

    步驟 0:安裝與環境準備

    pip install openai-agents-python openai
    

    在專案根目錄建立 .env(或直接用環境變數):

    export OPENAI_API_KEY="你的 API Key"
    

    💡 關鍵: 只要設定好 OPENAI_API_KEY,就能在一晚內跑起一個可用的多 agent 小流程。

    步驟 1:建立第一個 writer agent

    新增 agents_blog.py

    from openai_agents import Agent
    
    writer = Agent(
        name="writer",
        instructions=(
            "你是技術部落客,請用繁體中文寫 1200 字內的教學文,"
            "條列清楚、加上小標題,讀者是有基礎的工程師。"
        ),
    )
    

    先單獨測試這個 agent:

    import asyncio
    from agents_blog import writer
    
    async def main():
        result = await writer.run({"topic": "Python logging 實戰"})
        print(result)
    
    if __name__ == "__main__":
        asyncio.run(main())
    

    行動:先確保「單一 agent + 單一呼叫」正常運作,看到一篇文章草稿再往下加複雜度。


    步驟 2:加上 researcher + reviewer

    修改 agents_blog.py

    from openai_agents import Agent
    
    researcher = Agent(
        name="researcher",
        instructions=(
            "你負責針對主題列出 5 個實用重點與常見坑,"
            "輸出 JSON 格式:{\"key_points\": [...]}。"
        ),
    )
    
    writer = Agent(
        name="writer",
        instructions=(
            "根據 research.key_points 寫技術部落格,"
            "包含簡介、實作步驟與常見錯誤排查。"
        ),
    )
    
    reviewer = Agent(
        name="reviewer",
        instructions=(
            "你是嚴格的技術編輯,檢查草稿是否:1) 結構清楚、"
            "2) 範例正確、3) 沒有太多空話。輸出建議清單。"
        ),
    )
    

    再加一個 orchestrator 流程(新檔 run_blog.py):

    import asyncio
    from openai_agents import Orchestrator
    from agents_blog import researcher, writer, reviewer
    
    orchestrator = Orchestrator(agents=[researcher, writer, reviewer])
    
    async def run_blog(topic: str):
        research_notes = await orchestrator.run("researcher", input={"topic": topic})
        draft = await orchestrator.run("writer", input={"topic": topic, "research": research_notes})
        review_notes = await orchestrator.run("reviewer", input={"draft": draft})
    
        print("=== 草稿 ===\n")
        print(draft)
        print("\n=== 審稿建議 ===\n")
        print(review_notes)
    
    if __name__ == "__main__":
        topic = input("輸入技術主題:")
        asyncio.run(run_blog(topic))
    

    行動:實際輸入你下週想寫的一個主題,看這個流程能不能生成一份你「願意再改一版就能上 blog」的草稿。


    步驟 3:做成簡單 CLI 或排程

    CLI(已經算一種):

    python run_blog.py
    

    若要每天自動產出草稿,可以用 crontab:

    crontab -e
    # 每天早上 9 點產出一篇關於 Python 的文章
    0 9 * * * cd /path/to/project && OPENAI_API_KEY=xxx python run_blog.py <<EOF
    Python 非同步程式設計實戰
    EOF
    

    行動:先用 CLI 手動跑幾次,確認品質與 token 消耗,再考慮排程自動化。


    適合誰用?幾個具體場景

    • 工程師/資料工程師
    • 資料抓取 → 清洗 → 產出報表(多個 agent 分別負責)
    • 專案 scaffold 生成 → 單元測試撰寫 → reviewer 檢查風險
    • 技術寫作者 / Developer Advocate
    • 自動產出技術部落格初稿、Release Note、API 範例
    • 內部平台團隊
    • 把既有的 CI/CD、監控 API 包成工具,讓 AI agent 幫忙查 log、整理 incident 報告

    💡 關鍵: 只要你習慣在 ChatGPT 下一長串指令,就幾乎一定能拆成 multi‑agent workflow 減少來回與手動操作。

    只要你目前已經在用 ChatGPT 做「一長串指令」,就適合把流程拆成 multi‑agent workflow 測試看看。


    延伸應用:部署、成本控制、整合現有系統

    1. 部署到雲端

    • 用 FastAPI 或 Flask 包一層 HTTP API,把 orchestrator 暴露成 /run_flow endpoint
    • 部署到 Render / Railway / Fly.io / 自家 Kubernetes,都只是一般 Python Web 服務部署流程

    2. 控制成本與錯誤

    • 限制 max_tokens / 模型:對只負責小任務的 agent 用較便宜的模型
    • 加上 retry + logging:為 orchestrator 跑的每一步記錄 prompt、輸出與 token 使用
    • 設定明確 instructions:讓 reviewer 僅輸出「建議清單」,避免重複生成整篇文章浪費 token

    3. 與既有後端或 Slack Bot 整合

    • 既有後端:在服務裡呼叫 orchestrator,把結果回寫資料庫或觸發其他工作
    • Slack Bot:
    • 用 Slack API 建一個 slash command /ai-team
    • 收到指令後,把文字丟給 orchestrator,完成後再貼回頻道

    行動:先選一個「已在跑的」後端流程(例如每週報表),先只把其中一段換成 agent 完成,觀察穩定度與成本。


    怎麼開始:最快上手路徑

    1. 看 GitHub READMEhttps://github.com/openai/openai-agents-python
    2. 先實作一個最小 demo:如本文的 blog flow 或「抓網頁 → 清洗 → 匯出 CSV」
    3. 再慢慢拆更多 agent:把你原本寫在同一個 prompt 或腳本裡的步驟,一個一個拆成獨立角色

    只要先完成一個「今晚就能跑起來」的小流程,你之後會很自然開始想:還有哪些工作可以交給這個 AI 小團隊做。

    🚀 你現在可以做的事

    • 打開專案,實作一個最小的 writer agent 並用單一呼叫產出一篇草稿
    • 把你常用的一個內部或公開 HTTP API 包成 @tool,讓 agent 能直接呼叫
    • 依照文中的 researcher → writer → reviewer 範例,寫出自己的第一個 orchestrator 流程並在本機跑一次
  • 3 小時做出專屬雲端 AI 小幫手

    3 小時做出專屬雲端 AI 小幫手

    📌 本文重點

    • open-agents 是給前端工程師用的雲端 AI Agent 腳手架
    • 幫你處理好 Agent 架構、工具整合與雲端部署樣板
    • 3 小時內就能做出可上線、會調 API 的 AI 小幫手

    用一句話說清楚:Vercel 的開源專案 open-agents 是一套「前端工程師也能駕馭的雲端 AI Agent 腳手架」,幫你處理好架構、模型與工具整合,以及雲端部署樣板,3 小時內就能把一個可上線的 AI 小幫手跑起來。

    💡 關鍵: open-agents 把「3 小時內做出可上線 Agent」變成合理門檻,適合用來做快速 MVP 驗證。


    核心功能:open-agents 幫你省掉哪些麻煩?

    1. 標準化的 Agent 架構:不用自己設計「大腦」骨架

    在 open-agents 裡,你會碰到三個核心概念:

    • Agent:像「大腦」,負責看使用者輸入、決定要不要用工具、整理最後回答。
    • Tool:可以是 REST API、資料庫查詢、檔案讀寫等,Agent 可以選擇呼叫它們。
    • Memory:用來記住上下文或歷史對話,讓 Agent 回答更連貫。

    open-agents 做好的事:

    • 幫你定義好 Agent 的 TypeScript 介面與執行流程
    • 提供現成的 tool 呼叫機制(類似 OpenAI Agents SDK 的工具系統)
    • Memory 設計已經整合到框架中,不用自己處理 token 管理

    你可以做的行動

    • 把原本散落在專案裡的「AI 回答」「API 呼叫」邏輯收斂成一支 Agent
    • 把「查 FAQ」「查內部 API」「整理結果」交給同一個 Agent 流程,而不是寫一堆 if-else

    2. 工具 / 模型整合:一支 Agent 同時用多個 API

    open-agents 預設支援多家模型服務(含 OpenAI,對應最新的 Agents SDK 概念),也很容易接:

    • 便宜模型(例如 OpenAI 最新較低價型號)
    • 你現有的 REST API / GraphQL / 內部服務

    你只要:

    1. .env 放入 API Key(例如 OPENAI_API_KEY
    2. 在程式裡註冊工具,例如一個查訂單狀態的 REST API
    3. 把工具掛在 Agent 上,Agent 自己會決定何時呼叫

    你可以做的行動(兩個實用 workflow 範例):

    1. 客服 FAQ + 後端 API 查詢自動回覆 Bot
    2. FAQ:丟成向量資料或直接塞 prompt
    3. 工具:GET /orders/:id 查訂單,GET /user/:id 查會員
    4. Agent 邏輯:先看能不能從 FAQ 回答,不行再調 API,最後回傳整理好的訊息。

    5. 團隊內部文件檢索 + 任務整理助理

    6. Memory:保留本週的對話與任務
    7. 工具:一支「搜尋 Notion / Google Drive / 自家知識庫」的 API
    8. Agent:自動整理「這週待辦」「文件連結」,丟回 Slack/前端介面

    💡 關鍵: 一支 Agent 就能同時整合多個 API 和便宜模型,讓你用低成本做出實用的自動化工作流程。


    3. 雲端部署樣板:Next.js + Vercel 直接起飛

    open-agents 專案 本身就是一個可以部署到 Vercel 的樣板:

    • 內建 API routes,可以當成你的 Agent 後端
    • 前端可以用 Next.js / React 串同一支 Agent API
    • 與 Vercel 部署流程打通:GitHub 綁定 → 自動 CI/CD

    你可以做的行動

    • 先只改後端的 Agent + tool,保持前端 UI 簡單
    • 驗證 Agent 工作流程沒問題後,再慢慢優化 UI/權限

    適合誰用?幾個具體場景

    1. 前端工程師:想要一個「會用 API 的聊天小幫手」

    你手上可能已經有:

    • 一些 REST API(訂單、會員、專案、ticket…)
    • 一個 React/Next.js 專案

    只要把 open-agents 當成「AI 後端模板」,你就能做出:

    • 客服頁面裡的 FAQ + 訂單查詢 bot
    • 專案管理頁面的「自然語言查詢資料」側邊欄

    2. 團隊技術 owner:要做 MVP 的 AI 助理,但不想先上 MCP 這種大型架構

    根據「MCP for Backend Engineers」那篇文章的建議:

    1 app · 1 team · 1 toolset → 用簡單的 tool calling 就好,MCP 是 scaling 決策,不是起步點。

    如果你目前只有:

    • 一個 Web App
    • 一兩個後端服務

    那 open-agents 就剛好:

    • 架構不重,適合 MVP
    • 想擴展到多工具、多系統再慢慢抽象

    3. 產品/營運團隊身邊的「懂一點前端」的人

    只要會基本 TypeScript/React,照樣可以:

    • 改現有範例成「文件搜尋 + 任務整理」內部助手
    • 讓團隊先用起來,再決定要不要投入更多資源

    怎麼開始:3 小時完成「會調 API 的 AI 小助手」

    下面以「客服 FAQ + 訂單查詢 Bot」為例,走一次從 0 到可部署的流程。

    前提:你會基本 Git、Node.js、TypeScript,並有一個 GitHub 帳號。

    步驟 0:成本 & 免費方案心裡有底

    • open-agents 本身是免費開源
    • 模型費用:可使用 OpenAI 較低價模型,成本通常是每月幾美元起(視流量)
    • 部署:Vercel 有免費方案,適合開發 / 小流量 MVP

    💡 關鍵: 開源 + 便宜模型 + 免費部署方案,讓你可以「先上線再優化」,不必一開始就投入大量預算。


    步驟 1:從 GitHub 模板拉起專案

    1. 打開專案:https://github.com/vercel-labs/open-agents
    2. 點右上角 Use this template → Create a new repository
    3. 在自己的 GitHub 底下建立 repo
    4. 本機 clone:

    bash
    git clone https://github.com/<你的帳號>/<你的-repo>
    cd <你的-repo>
    pnpm install # 或 npm install / yarn

    1. 新增 .env.local,放入:

    bash
    OPENAI_API_KEY=sk-...

    此時行動pnpm dev 跑起來,確認預設的 Agent Demo 正常回覆。


    步驟 2:配置一個模型 + 建立簡單 REST Tool

    假設你要讓 Agent 查詢 GET https://api.example.com/orders/:id

    1. src/tools/orderTool.ts 新增:

    “`ts
    import { z } from “zod”;

    export const orderTool = {
    name: “get_order_status”,
    description: “根據訂單編號查詢訂單狀態”,
    parameters: z.object({
    orderId: z.string().describe(“訂單編號”)
    }),
    execute: async ({ orderId }: { orderId: string }) => {
    const res = await fetch(https://api.example.com/orders/${orderId});
    if (!res.ok) throw new Error(“查詢失敗”);
    const data = await res.json();
    return {
    status: data.status,
    items: data.items,
    total: data.total,
    };
    },
    };
    “`

    1. 在 Agent 定義中(例如 src/agents/supportAgent.ts),把這個 tool 加進去:

    “`ts
    import { createAgent } from “./baseAgent”;
    import { orderTool } from “../tools/orderTool”;

    export const supportAgent = createAgent({
    name: “support”,
    systemPrompt:
    “你是客服小幫手,先用 FAQ 回答,如果使用者提到訂單編號(像是 #12345),再用工具查詢訂單狀態,最後用中文整理回答。”,
    tools: [orderTool],
    });
    “`

    1. 模型設定通常在 baseAgent 或 config 檔裡(視專案結構),選一個便宜模型,例如:

    ts
    model: "gpt-4.1-mini" // 範例,視官方文件更新調整

    此時行動:在本機跑 server,從 Agent API 打一個 request,例如:

    「我有一筆訂單 #12345 ,請幫我看目前出貨狀態」

    觀察 log,確認 Agent 會:

    • 自動偵測訂單編號
    • 呼叫 get_order_status 工具
    • 整理成可讀中文回答

    步驟 3:接一個簡單前端(Next.js / React)

    如果你用 Next.js

    1. /app/api/chat/route.ts 建一個 API route,轉發到 supportAgent

    “`ts
    import { NextResponse } from “next/server”;
    import { supportAgent } from “@/agents/supportAgent”;

    export async function POST(req: Request) {
    const { message } = await req.json();
    const reply = await supportAgent.run({ input: message });
    return NextResponse.json({ reply });
    }
    “`

    1. 在前端頁面建一個最簡聊天 UI:

    “`tsx
    “use client”;
    import { useState } from “react”;

    export default function ChatPage() {
    const [input, setInput] = useState(“”);
    const [messages, setMessages] = useState([]);

     const send = async () => {
       const res = await fetch("/api/chat", {
         method: "POST",
         headers: { "Content-Type": "application/json" },
         body: JSON.stringify({ message: input }),
       });
       const data = await res.json();
       setMessages((m) => [...m, `你:${input}`, `Bot:${data.reply}`]);
       setInput("");
     };
    
     return (
       <div>
         <div>{messages.map((m, i) => (
           <div key={i}>{m}</div>
         ))}</div>
         <input value={input} onChange={(e) => setInput(e.target.value)} />
         <button onClick={send}>送出</button>
       </div>
     );
    

    }
    “`

    此時行動:在本機 UI 輸入訂單問題,看是否能走完整流程「輸入問題 → Agent 決定要不要調 API → 回傳整理後答案」。


    步驟 4:一鍵部署到 Vercel

    1. 把程式 push 到 GitHub
    2. Vercel 登入 → New Project → 選你的 repo
    3. 在 Vercel Project 的 Environment Variables 中填入:
    4. OPENAI_API_KEY
    5. 其他內部 API 的 token(若有)
    6. 部署完成後,拿到一個網址,例如 https://your-agent.vercel.app

    成本提示

    • 小流量下 Vercel 免費方案通常足夠
    • 模型費主要取決於:使用人數 × 對話長度 × 模型單價
    • 有預算疑慮時,可以先用小模型做 MVP,流量上來再調整

    延伸玩法 & 心智模型

    • 想接更多內部系統?就把每個系統包成一個 tool,掛在同一個 Agent 或拆成多個 Agent。
    • 想做內部文件助理?多加一個「文件搜尋 API」,Agent 再負責整理成待辦或重點摘要。
    • 覺得專案變大、團隊變多?再考慮引入 MCP / API Gateway,把目前的 tools 重構即可。

    如果你今天只想要「一個會用你的 API 的雲端 AI 小幫手」,照著上面四個步驟做完,你就已經比大多數還停在概念階段的人,多了一個真正跑在雲端的 Agent。動手開一個 open-agents 專案,從一個最簡單的 tool 開始,就行了。

    🚀 你現在可以做的事

    • 開啟 open-agents GitHub 專案,用 Use this template 建一個自己的 repo
    • 在專案裡實作一個最簡單的 REST tool(例如查訂單或查專案狀態),掛到一支自訂 Agent 上
    • 用 Vercel 免費方案部署這個 Agent,丟給團隊實際試用並收集回饋
  • 把 ChatGPT 搬進 iPhone:Gemma 4 實戰

    把 ChatGPT 搬進 iPhone:Gemma 4 實戰

    一句話定位:Gemma 4 讓你在 iPhone 上離線享受「接近 ChatGPT」的體驗,所有資料留在手機裡不出門。

    📌 本文重點

    • 在 iPhone 本地跑 Gemma 4,可離線又保護隱私
    • 用 Gemma 4 做聊天、翻譯、PDF/筆記問答與日記分析
    • 依照步驟完成「PDF/筆記 → 總結 + 問答」 workflow
    • 開發者可在手機上做無後端的 LLM 原型實驗

    下面的內容會帶你搞清楚:為什麼要在手機本地跑 Gemma 4、它能做什麼、適合哪些人用,以及最重要的——怎麼一步步在 iPhone 上跑起來,做到「把 PDF/筆記丟進去就能問答」

    參考:Gemma 4 本地推理在 iPhone 上的討論,可見 Gizmoweek 報導 與 Hacker News 熱門串。


    核心差異:為什麼要在 iPhone 本地跑 Gemma 4?

    先把雲端模型(ChatGPT、Gemini)和本地 Gemma 4 的差異講清楚:

    • 隱私
    • 雲端:你的對話、上傳檔案會經過伺服器。
    • 本地:模型在 iPhone 上推理,日記、醫療筆記、合同草案都不離開手機

    • 離線可用

    • 雲端:沒網路、飛機上、海外被限制時就完全失效。
    • 本地:Gemma 4 可以在飛機、公車、海外出差時照常回覆、翻譯、寫作。

    • 延遲穩定

    • 雲端:高峰期會卡、會 timeout,速度跟網路品質綁死。
    • 本地:只看你 iPhone 效能,體感像打字機,多數短文秒回

    💡 關鍵: 把 Gemma 4 放在 iPhone 本地跑,可以在無網路狀態下,用接近 ChatGPT 的體驗處理高度隱私與長文內容。

    如果你有「這些東西我不想丟到雲端」的內容,或常常沒網路,Gemma 4 在 iPhone 上會立刻變成高頻工具,而不是備胎。


    核心功能:你在 iPhone 上實際能做什麼?

    1. 對話與寫作助手(接近 ChatGPT 體驗)

    在支援本地 LLM 的 App 裡載好 Gemma 4 後,你就能:

    • 像聊天一樣問問題、整理想法
    • 寫 email 草稿、會議摘要、腳本、貼文
    • 讓它用你的語氣重寫文字(例如「幫我改成比較口語」)

    行動建議: 安裝一個本地 LLM App(下面「怎麼開始」會列),先用 Gemma 4 當純文字聊天助手,感受速度與溫度、耗電,再決定要不要開更大的模型。

    2. 本地長文與知識庫分析

    Gemma 4 支援長上下文版本(有社群實測用 26B + 256k context 分析十萬字日記,見 Reddit 分享),放在 iPhone 上就可以做:

    • 整本 PDF 報告丟進去請它重點整理
    • 長期筆記/子彈筆記匯總,問它「幫我找出過去一年我最常抱怨的三件事」
    • 針對整個專案文件問答(而不是只看一頁)

    💡 關鍵: 長上下文的 Gemma 4 能處理十萬字等級的內容,適合把整本報告或多年日記一次交給手機上的模型分析。

    行動建議: 準備 1–2 份你真正在看的 PDF(研究報告、投影片),等下在 workflow 範例中會用到。

    3. 手機端開發實驗(快捷指令 + 簡單 App)

    對開發者或自動化玩家,Gemma 4 在 iPhone 上的價值在於:

    • 不用伺服器,就能在手機上測試 LLM 原型
    • 用 iOS 快捷指令 + 本地 LLM App 做簡單 Agent:
    • 選取文字 → 呼叫 Gemma 4 重新整理/翻譯
    • Share Sheet 把檔案丟給 Gemma 4 總結
    • 若走原生路線,可用 Core ML / Metal 把轉好的 Gemma 4 模型 embed 到 Xcode 專案裡

    行動建議: 如果你是 iOS 開發者,先用現成 App 測試好 prompt 與模型尺寸,再考慮用 Core ML 導入;這樣可以避免一開始就卡在部署。相關量化思路可對照 Google 在 Apple Silicon 上的 TurboQuant 技術介紹(參考 Towards AI 文章)。


    適合誰用?三個典型場景

    1)個人知識庫與日記:所有東西都留在手機

    適合這些人:

    • 有多年日記、心理諮商紀錄、醫療紀錄
    • 研究生、創作者,有大量私人筆記
    • 對雲端隱私完全不放心

    可以做的事:

    • 把日記匯出成純文字 / Markdown,分段丟給 Gemma 4:
    • 「找出我反覆提到但沒有行動的目標」
    • 「整理這一年,我對工作的情緒變化」
    • 對敏感筆記做聚合搜尋與摘要,不經過任何第三方伺服器。

    立即行動: 先在 iPhone 裡整理一個「私人 LLM 資料夾」,放日記匯出檔、健康紀錄,後面 workflow 直接用這個資料夾測試。

    2)出差 / 通勤沒網路的翻譯與寫作

    適合這些人:

    • 常飛機、常坐高鐵/地鐵、跨國出差
    • 在國外有網路限制,雲端 AI 不穩

    可以做的事:

    • 把待回的英文信貼進去:「幫我寫一封比較禮貌但堅決的英文回覆」
    • 開會前在車上,用 Gemma 4 把簡報講稿縮短成 5 個 bullet
    • 旅行時拍照 + OCR 轉文字後,丟給 Gemma 4 做即時翻譯與說明

    立即行動: 下次搭車前,把常用的翻譯/寫作 prompt 存成備忘錄,沒網路時直接複製給 Gemma 4 用。

    3)開發者在手機上做原型與小工具實驗

    適合這些人:

    • iOS 工程師、快捷指令玩家
    • 想做「不需要後端」的 AI 小工具

    可以做的事:

    • 寫一個快捷指令:
    • 取得目前剪貼簿文字
    • 傳給本地 Gemma 4 App
    • 回傳整理後文字,直接覆蓋剪貼簿
    • 在 Xcode 專案中,用 Core ML 模型當 offline 助手(例如:程式碼註解生成、App 內 FAQ 問答)

    立即行動: 先在本地 LLM App 裡找到「URL Scheme / x-callback-url」或「Shortcut 支援」,確認能否被快捷指令呼叫,這會是你所有原型的入口。


    怎麼開始:在 iPhone 上跑 Gemma 4 的最短路徑

    先給一個工具選擇對照表(以 2026 年常見方案為例,實際名稱請依 App Store 為準):

    名稱(示例) 核心功能 免費方案 適合誰
    LM Studio Mobile 下載並在本地跑 LLM(含 Gemma 4)、聊天介面、檔案上傳 常見為免費 + 內購 想要「裝好就能用」的一般使用者
    MlcChat for iOS 基於 MLX / MLC 的高效本地推理,支援多模型 通常開源、免費 想試不同模型、在意性能的玩家
    自建 Core ML App 直接在 App 內嵌 Gemma 4 Core ML 模型 自行開發 iOS 開發者,要做產品原型

    實際請搜尋「local LLM」「offline AI」關鍵字,並確認是否支援 Gemma 4 款式或通用 GGUF / MLC 格式。

    步驟 1:選一個 App + 安裝

    1. 打開 App Store,搜尋:local LLMoffline AIMLC Chat 等關鍵字。
    2. 看描述裡有沒有提到 Gemma 4 或「自訂模型 / GGUF / MLC」支援。
    3. 安裝後確認:
    4. 是否有「下載模型」功能
    5. 是否支援「匯入檔案」或「knowledge base / documents」

    步驟 2:選擇合適尺寸的 Gemma 4 模型

    iPhone 上不要一開始就上最大顆,會太熱又太慢。可依照:

    • 中階機種(A15 / A16、基本容量)
    • 建議:Gemma 4 2B–4B 量化模型(例如 Q4 / Q5
    • 用途:聊天、筆記整理、短文翻譯

    • 高階 Pro / Max(A18 Pro 類級別,RAM 8GB+)

    • 建議:Gemma 4 9B 左右的量化模型,若 App 支援可試長上下文版本
    • 用途:較長文章摘要、本地知識庫問答

    行動建議: 先下載一個 2B–4B 模型,跑幾分鐘聊天測試溫度。如果手機發燙明顯,就把 thread 數調低或換更小模型。

    步驟 3:測試性能、溫度與耗電

    1. 開啟 App,載入 Gemma 4 模型。
    2. 問它一個中等長度 prompt,例如:

    「請用條列整理 Netflix 訂閱變貴時,使用者常見的三種反應,控制在 200 字內。」

    1. 觀察:
    2. 生成 200 字大約需要幾秒?
    3. 手機背面溫度明顯變熱嗎?
    4. 連續用 10 分鐘後,電量大約掉多少?

    5. 在 App 設定中調整:

    6. 推理 thread(有時稱為「CPU 核心數」「推理執行緒」)
    7. 最大輸出 token 數(不必要就別一次開超大)

    目標狀態

    • 你可以連續聊 10–15 分鐘,手機只是微熱,耗電還在可接受範圍。

    步驟 4:實戰 Workflow —— 把 PDF/筆記丟給 Gemma 4 做總結與問答

    示範一個你可以直接照做的流程:

    1. 準備檔案
    2. 在檔案 App 建一個資料夾:LLM-Inbox
    3. 把一份 PDF(例如 20–30 頁的報告)或匯出的日記 .txt 放進去。

    4. 在 App 裡建立「知識庫」或上傳文件

    5. 打開你的本地 LLM App,找到「Documents / Knowledge / Files」等選項。
    6. 選擇 LLM-Inbox 裡那個檔案上傳或索引。

    7. 設定一個專門對話空間

    8. 新建一個對話,命名成「某某報告 Q&A」。
    9. 在 system prompt(如果有)寫上:

      「你只能根據我上傳的文件回答問題,不要憑空猜測。回答用繁體中文。」

    10. 實際問問題

    11. 「請用 300 字總結這份報告的主要結論。」
    12. 「作者提出的三個建議是什麼?幫我用自己的話改寫。」
    13. 「如果我要做 5 分鐘簡報,應該只挑哪三個 key slide?」

    14. 優化體驗

    15. 如果覺得速度太慢:
      • 換更小的 Gemma 4 模型
      • 限制回答字數,例如「控制在 150 字內」
    16. 如果回答常飄走:
      • 再加一句規則:「如果文件沒有提到,就回答『文件未提及』。」

    完成這個 workflow 後,你就已經不是「玩玩看」而是把 Gemma 4 變成日常讀書 / 工作輔助工具。接下來才是微調 prompt、換更大模型或試試手機端原型開發。

    💡 關鍵: 只要先打通「PDF/筆記 → 總結 + 問答」,Gemma 4 就能穩定接手你日常的讀書、報告與資料整理工作。


    總結:先把一件小事做通,再考慮玩更大

    在 iPhone 本地跑 Gemma 4,不需要一次搞懂所有量化格式、Core ML 細節。建議你照這個順序:

    1. 找一個支援本地模型的 iOS App
    2. 下 1 個中等大小的 Gemma 4 模型
    3. 完成「PDF/筆記 → 總結 + 問答」這個 workflow
    4. 覺得穩定好用,再往日記分析、快捷指令、自建 App 擴展

    做到第 3 步,你就已經把「接近 ChatGPT 的體驗搬進 iPhone,而且可離線」真正落地了。

    🚀 你現在可以做的事

    • 打開 App Store 搜尋「local LLM / offline AI」,安裝一個支援 Gemma 4 或 GGUF 的 App
    • 準備一個 LLM-Inbox 資料夾,把一份 PDF 或日記 .txt 放進去,按文中步驟跑完一次總結 + 問答
    • 觀察 10–15 分鐘使用時的速度與溫度,調整模型大小與 thread 設定,找出最適合你 iPhone 的組合
  • 把常用 Prompt 變成一鍵技能:Chrome AI Skills 實測

    把常用 Prompt 變成一鍵技能:Chrome AI Skills 實測

    📌 本文重點

    • Chrome Skills:把常用 Prompt 變成一鍵工具
    • 可跨網站、多分頁套用同一個 Skill
    • 非技術同事也能用的標準化 AI 工作流程
    • 適合團隊共用固定模板與報表解讀

    一句話先說清楚:Chrome 的「AI Skills」= 把你常用的 Prompt,變成可以隨時一鍵呼叫的小工具,不用再到處找、複製貼上。

    官方介紹: Turn your best AI prompts into one-click tools in Chrome(Google AI Blog)


    核心功能:把 Prompt 做成「可重複的一鍵技能」

    1. 儲存 / 命名 / 重用你的 Skills

    你在 Gemini 側邊欄打的任何 Prompt,都可以存成一個 Skill:

    • 操作概念
    • 先在側邊欄對 Gemini 下指令(例:請幫我用禮貌英文回覆客戶…)。
    • 覺得這個 Prompt 之後會常用,就直接存成 Skill。
    • 下次在任何網頁,只要一鍵點這個 Skill,就能套用到當前頁面的內容。

    • 能客製化的部分:

    • 幫 Skill 取一個好記的名字(例:「英文客服回覆」、「報表解讀」)。
    • 說明它是拿來做什麼的,方便同事看得懂。

    💡 關鍵: 把高頻重複的 Prompt 存成 Skill,可以用「一鍵點擊」取代每次複製貼上與重寫指令。

    你可以立刻做的事
    先想 3 個你每天都會重複貼給 AI 的 Prompt,等一下在「怎麼開始」小節,直接把它們變成 Skills。

    2. 官方預設技能庫:先用現成的再改

    Google 在 Chrome 的 Gemini 側邊欄,內建了一批「預設 Skills」,常見例子(見 Wired 介紹):

    • 食譜優化:例如「最大化蛋白質含量」或改成純素、低卡版。
    • YouTube / 長文總結:幫你抓重點,整理成條列。

    你可以:

    • 先直接用這些現成 Skills。
    • 再把你調整過的 Prompt 版本,存成自己的自訂 Skills(Google 官方文也強調可「discover, save and remix AI workflows」)。

    你可以立刻做的事
    打開 Gemini 側邊欄,先試用 1 個預設 Skill(例如「Summarize this video」),再把回答風格微調後存成自己的版本。

    3. 在任何網頁側邊欄一鍵呼叫

    根據 TechCrunch 與 The Verge 的說明,Skills 的重點是:

    • 跨網站、跨分頁 使用同一個 Skill。
    • 勾選多個 Tab,一次對多個頁面跑同一個 Skill(例如一口氣總結 3 則產品更新頁)。

    實際效果:

    • 你不用再:
    • 開 Notion / Google Docs 找那段老 Prompt。
    • 複製貼上到 Gemini。
    • 只需要:
    • 打開側邊欄 → 點你命名好的 Skill → 選擇要套用的分頁。

    你可以立刻做的事
    打開 2–3 個需要處理的頁面(例如不同客戶信、不同產品頁),試一次「同一 Skill 跑多個分頁」。


    適合誰用?4 個實際場景示範

    1. 批改英文 Email:固定語氣、固定格式

    使用方式:

    1. 在 Gemini 側邊欄寫一個完整 Prompt,例如:

      「請幫我把選取的英文 Email 改寫成禮貌、簡潔、B2B 科技公司口吻,保留原本資訊,但語氣更友善、用詞自然。」

    2. 存成 Skill:命名為「英文客服回信優化」。
    3. 之後每封英文信:
    4. 在 Gmail 開信 → 開側邊欄 → 點這個 Skill → 貼入草稿內容或讓它讀取頁面內容。

    行動建議:
    – 先為 「英文回覆」和「英文道歉信」 分別各做一個 Skill,之後全部照這兩種模板改。

    2. 食譜轉成低卡 / 純素版

    The Verge 舉例,過去你每換一個食譜頁面,就要重新輸入「幫我改成純素版」。現在可以:

    1. 建立 Skill:

      「閱讀這個網頁中的食譜,將其改寫成純素版本,提出必要的食材替代方案,並計算每份大致卡路里。」

    2. 命名為「純素 & 低卡改寫」。
    3. 之後遇到任何食譜頁面,只要一鍵點這個 Skill。

    行動建議:
    – 如果你有特定飲食需求(低醣、高蛋白),為每種飲食習慣做一個專屬 Skill。

    3. 總結長文 / YouTube:變成「固定摘要格式」

    基於 Wired 的範例,你可以把「摘要」做得更標準化:

    1. 在一篇長文章或 YouTube 頁面上,對 Gemini 說:

      「請用繁體中文,幫我整理為:1)三點重點;2)一段 100 字內摘要;3)列出適合轉貼到 Slack 的一句話。」

    2. 存成 Skill「內容三段式摘要」。
    3. 之後任何長文 / 影片都可以套用同樣格式。

    行動建議:
    – 為「給自己看的摘要」和「給團隊看的摘要」各自定義格式,做成兩個 Skills。

    4. 固定格式報表 → 自動生成解讀摘要

    你可能每週都要解讀一份長得很像的數據報表(GA4、廣告報表、CRM 匯出):

    1. 建立 Skill Prompt:

      「閱讀當前頁面的數據表格,幫我用以下格式解讀:
      1)本週 vs 上週差異;2)異常指標與可能原因(列出 3 點假設);3)下週建議行動(列出 3 個具體操作)。請用條列,長度控制在 300 字內。」

    2. 命名為「每週數據解讀 300 字」。
    3. 套用在每週固定打開的報表分頁上。

    行動建議:
    – 先選一份你 最常被問要解釋的報表,為它設計一個專用 Skill,讓 AI 先產出初稿,再微調。


    Workflow 範例:為公司建立一套「團隊共用 Skills」

    雖然 Google 尚未完全打開「公開 Skill 市集」,但你可以先用很簡單的方法做「團隊半共用」。

    1. 客服回覆模板

    1. 在文件中定義好客服回覆規則,例如:
    2. 語氣(專業、溫和、不推責)。
    3. 固定結尾句(例如邀請進一步聯絡)。
    4. 把這段規則寫進 Prompt,存成 Skill「客服標準回覆」。
    5. 把這段 Prompt 原文和「如何新增 Skill」的教學,傳給全團隊,讓大家在各自的 Chrome 裡建一模一樣的 Skill。

    2. 產品 Changelog 生成流程

    假設你每次發版,都要:

    • 從 issue tracker / Git log 撈出變更。
    • 寫成「用戶看得懂的版本更新說明」。

    可以這樣設計 Skill:

    「根據這個頁面的變更紀錄,幫我生成一份產品 Changelog,格式為:1)標題一句話;2)三個重點功能更新;3)一段給現有用戶看的說明(100 字內);4)一段給內部同事看的技術摘要(150 字內)。」

    流程建議:

    1. PM 在自己瀏覽器裡先調到滿意的 Prompt,再存成 Skill。
    2. 把 Prompt 原文放進團隊知識庫(Notion / Confluence),讓其他同事照樣建立。

    你可以立刻做的事
    選一個你們團隊「每週都會重複做、但內容每次都不一樣」的工作(公告、週報、教學信),先為它寫一個完整 Prompt,再交給全員自己建 Skill。


    實作教學:如何在 Chrome 開啟、建立與使用 Skills

    注意:Skills 目前在 桌面版 Chrome 並搭配 Gemini 側邊欄 的環境下提供,實際入口可能會隨版本更新微調,以下以官方 Blog 和多家媒體描述整理出典型流程。

    1. 在哪裡開啟 Skills(設定路徑)

    1. 更新 Chrome 至最新版本。
    2. 登入你的 Google 帳號。
    3. 在右上角找到 Gemini 圖示 或從側邊欄開啟 Gemini(有些版本是「使用 Gemini」按鈕)。
    4. 若已開放 Skills 功能,會在側邊欄看到 Skills 區塊或「Save as Skill」類似選項(可持續留意:TechCrunch 報導)。

    行動建議:
    – 先確認你能在 Chrome 裡正常使用 Gemini 側邊欄,再來找 Skills 相關選項。

    2. 如何從現有 Prompt 儲存成 Skill

    1. 打開任一網頁(例如 Gmail、文件、報表)。
    2. 開啟 Gemini 側邊欄,輸入你想重複使用的 Prompt,先讓它跑一次,調整到你滿意的回答風格。
    3. 在這則對話附近,尋找「Save as Skill」或「Create Skill」按鈕(介面可能是三點選單裡的選項)。
    4. 設定:
    5. Skill 名稱(簡短但具體,例如「GA4 每週報告摘要」)。
    6. 說明 / Tag(方便未來辨識)。
    7. 儲存後,它就會出現在 Skills 清單中。

    行動建議:
    – 第一次先存 1 個 Skill,不要一次做太多,確保你真的會用它,之後再慢慢擴充。

    3. 如何在多個 Tab 上使用 Skills

    根據 The Verge 的說明,Skills 可以在多個分頁上重複使用,典型操作如下:

    1. 開啟多個相關分頁,例如:3 篇產品更新文章、或 3 份不同客戶的簡報頁。
    2. 打開 Gemini 側邊欄 → 選擇你要用的 Skill。
    3. 在 Skills 介面中,選擇要套用的 Tab(有些版本可能支援勾選多個)。
    4. 按下執行,AI 會依序對每個分頁運行該 Skill,生成各自的結果。

    行動建議:
    – 嘗試在 兩個很相似的頁面(例如兩個競品產品頁)使用同一個 Skill 做比較分析,快速得到可對照的結果。


    與「複製貼上 Prompt」相比的優勢

    傳統做法

    • 在 Notion / Google Docs / 備忘錄保存一堆 Prompt。
    • 每次要用時:切換視窗 → 複製 → 回到瀏覽器 → 貼上 → 再調整。

    用 Skills 的差別

    1. 少一步切換工具:Prompt 就在 Chrome 裡,直接點名字就套用。
    2. 減少 Version 混亂:不用在多個文件裡找「最新版 Prompt」,你只維護同一個 Skill。
    3. 跨分頁一致性:同一個 Skill 直接套在不同頁面,輸出風格一致,特別適合報表解讀、客服回覆、摘要格式。
    4. 更適合非技術同事:他們不需要理解什麼是 Prompt Engineering,只要知道「遇到這種工作,就點這個 Skill」。

    💡 關鍵: 把分散在文件裡的常用 Prompt 收斂成少量核心 Skills,可以同時解決「效率低」與「輸出不一致」兩個問題。

    你可以立刻做的事
    – 把你目前收藏 Prompt 的文件打開,挑出 最常用的前 3 個,優先轉成 Skills,其餘的保持在文件裡即可。


    和其他瀏覽器 AI 外掛有什麼不同?

    目前許多 AI 外掛(如各種 ChatGPT / Gemini / Claude 插件)也能在網頁上跑 Prompt,但 Chrome 原生 Skills 有幾個實際差異:

    比較項目 Chrome AI Skills 一般瀏覽器 AI 外掛
    整合程度 直接整合在 Chrome 與 Gemini 側邊欄 需額外安裝擴充功能
    Prompt 儲存方式 以「Skill」形式命名、可跨分頁一鍵呼叫 多為歷史記錄或簡單書籤,重用流程較散亂
    多分頁操作 官方說明可對多個 Tab 套用同一 Skill 多數外掛只對目前分頁或需逐一操作
    團隊共用 目前以「共用 Prompt 文本、各自建立 Skill」為主 有些外掛有雲端模板共享,但使用體驗不一
    安全與權限 跟隨 Google 帳號與官方隱私設定 視外掛開發者而定,需額外確認權限

    如果你已經習慣用某個外掛,可以:

    • 把外掛裡最常用的 Prompt,手動搬到 Chrome 的 Skills,讓「真正會每天用到的那幾個」留在瀏覽器原生工作流程中。

    💡 關鍵: Skills 的優勢不是「功能更多」,而是「離真實工作場景更近」,把 AI 變成瀏覽器內建的工作按鈕。


    怎麼開始:3 步驟快速上手

    1. 確認環境
    2. 更新 Chrome → 登入 Google 帳號。
    3. 確認你能在瀏覽器右側打開 Gemini 側邊欄。

    4. 選出你的「前三名常用 Prompt」

    5. 例如:
      • 英文 Email 改寫。
      • 報表摘要。
      • 網頁 / 影片整理成重點筆記。
    6. 先在 Gemini 裡照平常方式下指令,調整到滿意。

    7. 存成 Skills 並實際跑一次

    8. 用前面教的方式,將這三個 Prompt 各存成一個 Skill。
    9. 立刻在兩種不同頁面上試跑(例如兩封不同的信件、兩篇不同文章),看輸出是否符合期待,必要時再回頭微調 Prompt。

    這樣設定完,你之後在 Chrome 裡看到任何「值得用 AI 幫忙處理」的頁面,就不用思考要怎麼下指令,只要想:「這件事有沒有對應的 Skill 可以點?」

    🚀 你現在可以做的事

    • 打開你存 Prompt 的 Notion 或文件,挑出 3 個最高頻使用的指令,準備轉成 Skills
    • 在桌面版 Chrome 更新並登入 Google 帳號,確認 Gemini 側邊欄與 Skills 入口是否已可使用
    • 選一個固定重複的工作(如週報、Email 模板),寫成完整 Prompt,存成第一個可重複使用的 Skill
  • 用 Claude Code routines 把修 Bug 和審 PR 自動化

    用 Claude Code routines 把修 Bug 和審 PR 自動化

    📌 本文重點

    • 用程式碼定義 routine,讓 Claude 自動跑開發流程
    • 支援排程、API、GitHub webhook 等多種觸發方式
    • 適合 CI、PR 初審、重構、錯誤偵測等自動化場景
    • 建議先從「只讀建議」開始,逐步放權到自動修正

    一句話先說清楚:Claude Code routines 就是「用程式碼把 Claude 變成你的自動化開發助理」,幫你在雲端自動跑修 Bug、審 PR、開 issue 等重複工作。

    官方文件:https://code.claude.com/docs/en/routines


    核心功能:用程式碼定義多步驟任務

    routines 的概念很簡單:你先用程式碼把「要怎麼用 Claude 做事」寫成一個流程,之後就讓它自動在雲端重複跑。

    典型一個 routine 可以長這樣:

    1. 拉特定 repo(支援 GitHub 等連接器)
    2. 用 Claude 分析程式碼變更或錯誤
    3. 修改程式碼、產生 patch 或直接開 PR
    4. 把結果回報到 GitHub、Slack 或你的 CI 系統

    根據官方說明和社群分享(Reddit):

    • 多步驟流程可程式化:你不是丟一句 prompt 就結束,而是用程式碼描述整個 pipeline,例如:

    ts
    // 偽程式碼示意:定義一個 routine
    const routine = defineRoutine({
    name: 'lint-and-suggest',
    repo: 'github://my-org/my-repo',
    steps: [
    cloneRepo(),
    runESLint(),
    askClaudeForFixes(),
    commentOnPullRequest(),
    ],
    })

    • 三種觸發方式(都在雲端跑,電腦可關機):
    • 固定排程:例如每天凌晨跑一次重構建議
    • API 呼叫:每個 routine 會有一個 endpoint,你可以從自家服務打 API 觸發
    • GitHub webhook:例如「新 PR 建立時就讓 routine 自動跑審查」

    💡 關鍵: routines 把「一次性的 prompt」變成「可重複觸發的程式化流程」,而且全部在雲端執行,不綁你的電腦在線。

    你可以馬上做的事:

    • 想一個你最常重複做的開發流程(例如「每次 PR 都要跑 lint + 給建議」),把它拆成 3–5 個步驟,列成清單,等等在「怎麼開始」直接照這份清單寫成 routine。

    適合誰用:4 個典型場景

    1. CI 流程自動跑靜態分析 + 修正建議

    場景:你現在的 CI 只會跑 lint / type check,但錯誤一堆,只丟紅燈不給解法。

    用 routines 可以:

    • 在 CI 裡呼叫一個 API routine
    • routine 拉 PR 的 diff,跑 ESLint / mypy 等工具
    • 把錯誤丟給 Claude,讓它:
    • 用自然語言解釋錯誤來源
    • 產生建議修正(甚至 patch)
    • 把結果直接貼回 PR comment

    可執行動作:

    • 選一個語言(例如 TypeScript),從你現有 CI 裡加一個步驟:呼叫 routines API,把 PR 編號、branch、diff 傳給它,讓 routines 回傳「修正建議文字」或「patch 檔」。

    2. PR 自動初審:先讓 AI 篩一輪

    場景:團隊 PR 多,但 Reviewer 不想浪費時間在命名、註解、重複邏輯這種「低階問題」。

    routine 可以幫你:

    • 透過 GitHub webhook,在 PR 開啟時觸發
    • 讀取 diff + 相關檔案
    • 按你定義的規則檢查:
    • 是否有測試
    • 是否破壞既有 API
    • 命名 / 註解 / logging 是否符合約定
    • 自動在 PR 下面留一串初步 review comment

    可執行動作:

    • 先在文件裡列出你希望「PR 初審」檢查的 checklist(3–7 項就好),之後在 routine 的 prompt 中直接貼入這份 checklist,讓 AI 依此審查。

    3. 例行重構 / 格式化:排程交給 AI 擬方案

    場景:技術債知道很多,但沒空系統性整理。

    排程 routine 可以:

    • 每週固定拉主分支
    • 掃特定目錄(例如 /legacy/**
    • 讓 Claude:
    • 找出重複程式碼、過長 function、潛在性能瓶頸
    • 產出「重構提案」文件,列出建議與風險
    • 適度產生小 patch(例如只做格式、抽小 function)

    可執行動作:

    • 挑一個最頭痛的模組,設定一個每週 routine,讓 AI 每週只做一件事:產出一份 markdown 報告 docs/refactor-suggestions.md,你每週開會時直接打開看。

    4. Crash 時自動開 issue + 初步定位

    場景:線上服務 crash,Log 一堆,沒人第一時間看。

    你可以:

    • 在監控系統(如 Datadog、Sentry、自家 APM)裡,當發生特定錯誤時,呼叫 routines API
    • routine 取得:錯誤訊息、stack trace、關聯 log
    • 讓 Claude:
    • 用固定模版在 GitHub / Jira 開 issue
    • 附上「可能原因、優先查看檔案、建議排查步驟」

    可執行動作:

    • 把你目前手動開 issue 的模版貼出來,照樣套到 routine:把欄位(背景、重現步驟、log、可能原因)寫進 prompt,讓 AI 自動填。

    進階玩法:多代理 + DevOps 工具鏈串接

    多代理平行工作:一個負責測試、一個負責安全

    Anthropic 在桌面版 Claude Code 已經支援多代理平行工作(Reddit 範例),在 routines 概念上,你可以照抄這個思路:

    • routine A:專門寫測試
    • 拉 PR diff
    • 找出新增 / 修改的 function
    • 為這些 function 產測試檔 / 測試 case
    • routine B:專門做安全檢查
    • 用「安全檢查 prompt」掃過相同 diff
    • 找 SQL injection、硬編 API key、不安全的反序列化等

    你在 CI / webhook 流程裡:

    • 對同一個 PR 同時觸發 routine A 和 B
    • 兩邊結果都留言回 PR,Reviewer 一次看完

    可執行動作:

    • 先從「拆成兩個 routine」開始:複製一份 PR 初審 routine,一份改成只談測試、一份改成只談安全。兩個端點都掛在同一個 GitHub webhook 上平行觸發。

    💡 關鍵: 把不同責任拆成多個 routine 平行跑,比讓一個超大 prompt 包山包海更穩定、也更好維護。


    和 GitHub Actions / 自家 CI 組合

    根據官方說明,每個 routine 都有自己的 API endpoint,你可以:

    • 在 GitHub Actions 新增一個 step:

    yaml
    - name: Call Claude routine
    run: |
    curl -X POST "$ROUTINE_ENDPOINT" \
    -H "Authorization: Bearer $ROUTINE_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{"pr_number": "${{ github.event.pull_request.number }}"}'

    • 在自家 CI(GitLab CI、Jenkins 等)同樣用 curl / http client 呼叫

    可執行動作:

    • 挑一個已存在、每次都必跑的 workflow(例如 ci.yml 中的 lint job),在最後加上一個 step 呼叫 routines,把 log 或 diff 丟給它,先從「只產出建議、不寫檔」開始。

    怎麼開始:從一個「最小可用」 routine 起步

    1. 在哪裡開啟 Claude Code routines?

    前提:需要 Claude 付費帳號(根據 官方公告)。

    步驟概念(介面可能會隨時間微調):

    1. 登入 https://code.claude.com
    2. 在側邊欄找到 Routines 或類似入口
    3. Create routineNew routine
    4. 選擇:
    5. 要連接的 repo(GitHub / 本地鏡像等)
    6. 要用的 connector(例如 Slack、GitHub)
    7. routine 的觸發方式(排程 / API / GitHub webhook)

    可執行動作:

    • 現在就登入 Claude Code,看你的帳號是否已開 routines,確認你公司 repo 是否能被安全地接入(先選一個 side project 測試)。

    2. 寫一個「最小可用」 lint & 建議 routine

    目標:對指定 repo 做 lint,請 Claude 用自然語言給建議,不動任何程式碼。

    流程示意(概念層級):

    1. 新建 routine:ts-lint-advisor
    2. 設定:
    3. Repo:github://your-org/your-repo
    4. 觸發:API(先手動呼叫)
    5. 在 routine 腳本中:
    6. Step 1:git clone 對應 branch
    7. Step 2:跑 pnpm lintnpm run lint,把輸出存成文字
    8. Step 3:呼叫 Claude,把 lint log + 相關檔案片段丟給它,prompt 約略:

      你是一位 TypeScript 專案維護者。根據以下 ESLint 輸出,請:
      1. 依錯誤類型分組
      2. 解釋造成這些錯誤的程式風格 / 設計問題
      3. 提出 3–5 條優先修正建議(包含具體檔案與規則)

    9. 回傳結果:只輸出 markdown 報告,不修改 repo

    可執行動作:

    • 先做一版「只讀不寫」的 lint 報告 routine,確定你喜歡它的輸出風格,再考慮讓 routine 產 patch 或自動發 PR。

    💡 關鍵: 先用「只讀報告」驗證 routine 的品質與風格,比直接讓它改碼、開 PR 安全得多。


    3. 設定 GitHub webhook:新 PR 自動觸發

    當你有一個穩定的 PR 初審 routine 之後,可以這樣接 GitHub:

    1. 在 routines 介面確認此 routine 的 API endpoint
    2. 到 GitHub 專案 Settings → Webhooks
    3. Payload URL:貼上 routines endpoint
    4. Content type:application/json
    5. Which events:勾選「Pull requests」
    6. 在 routine 的程式裡解析 GitHub webhook payload:
    7. 取得 pull_request.numberhead.refbase.ref
    8. 用這些資訊去抓 diff + 檔案內容

    可執行動作:

    • 先對「一個測試 repo」開 webhook,不要直接上 production monorepo;等確認 routine 不會亂刷 comment、沒權限問題,再複製設定到正式專案。

    風險提示與 Best Practices

    1. 權限控制:不要讓 Agent 直接推到 main

    routines 能改程式碼,也能開 PR。建議:

    • 對 routines 用的 GitHub Token:
    • 禁止直接 push 到 main / master
    • 只給「開 PR」和「留言」的權限
    • 在 Org Policy 中明定:AI 開的 PR 一律需要人審核才能合併

    可執行動作:

    • 立刻確認你準備給 routines 用的 GitHub PAT / App 權限,把 push to protected branches 關掉。

    2. 改動記錄與審計:每一個 AI 動作都要有跡可循

    為了避免「不知道是哪個 routine 改了什麼」:

    • 統一規範 AI 開 PR 的 branch 命名,例如:ai/routine-name/feature-x
    • PR 描述固定包含:
    • 使用的 routine 名稱 & version
    • 執行時間、輸入參數(例如針對哪個 issue / PR)
    • 可以在 routine 程式裡主動把自己的輸出寫入一個 log 檔或 S3 / DB,供日後查詢。

    可執行動作:

    • 寫一個簡單規範:所有 routines 在 PR 描述最上方都要加一段固定訊息,例如:[Generated by routine: pr-initial-review v0.3],方便日後搜尋、回溯。

    3. 慢慢放權:先從「建議」再到「自動修改」

    導入策略可以分三層:

    1. 只讀模式:只產報告 / 建議,不動任何檔案
    2. Patch 模式:產生 patch 檔、開 PR,但不自動合併
    3. 半自動修正:對低風險項目(格式化、註解)允許自動合併,高風險項目仍需人工

    可執行動作:

    • 先列出「允許 AI 自動處理」與「必須人工審核」的改動類型(例如:格式化、註解 vs. 核心業務邏輯、資料庫 schema),在 routine 的 prompt 裡明寫清楚。

    小結:從一個 routine 開始,把最煩的事交給 Claude

    你可以把 Claude Code routines 當成「可編程的 AI Bot 平台」:

    • 把你每天重複做的開發流程拆成步驟
    • 用程式碼和 prompt 變成 routine
    • 用排程、API 或 GitHub webhook 觸發

    最實際的下一步

    1. 選一個最討厭但規則清楚的工作(例如 PR 初步檢查命名和註解)。
    2. 在 Claude Code 裡建一個 routine,先只產出文字建議。
    3. 跑一週,觀察輸出品質,再決定要不要進一步讓它產 patch、開 PR。

    從一個小 routine 開始,你就能感受到「用程式碼把 Claude 變成你的自動化開發助理」的威力。

    🚀 你現在可以做的事

    • 打開一個 side project repo,列出 3–5 步驟的「最煩例行工作」,照文中流程設計第一個 routine
    • 在 CI 或 GitHub Actions 中加上一個「只讀建議」的 routines 呼叫 step,觀察一週效果
    • 為 routines 設計權限與審計規範(Token 權限、branch 命名、PR 描述格式),再逐步放權到 patch / 開 PR
  • 一行指令接上多模態 AI:MMX-CLI 實戰

    一行指令接上多模態 AI:MMX-CLI 實戰

    用一句話講清楚:MMX-CLI 讓你用一行指令,就能在本機腳本或 Agent 裡,直接調用文字、圖片、影片、語音、音樂、視覺分析與搜尋等多模態 AI 能力,而且輸出格式乾淨,好串自動化。

    📌 本文重點

    • 一套 mmx CLI 管文字、圖片、影片等七種多模態能力
    • stdout / stderr 分流設計,超適合腳本與 CI 自動化
    • 支援語義錯誤碼與 async,穩定掛在長鏈式工作流後面
    • Node / JS 友善,當「通用多模態 AI 插件」掛在任何工具裡

    專案來源:Reddit 介紹帖(含原始連結):https://www.reddit.com/r/LocalLLaMA/comments/1skfhix/minimax_released_mmxcli_one_cli_for_text_image/


    核心功能:為「會寫指令的人」準備的多模態外掛

    💡 關鍵: 一套 mmx 前綴的 CLI 就涵蓋七種多模態能力,大幅減少安裝與學習不同 SDK 的成本

    1. 七大多模態指令組:一套 CLI 管全部

    MMX-CLI 的指令前綴都是 mmx,再接子指令:

    • mmx text:文字生成功能(寫文案、草稿)
    • mmx image:圖片生成、批次生成
    • mmx video:影片生成(支援非同步)
    • mmx speech:文字轉語音 / 語音相關
    • mmx music:音樂生成
    • mmx vision:圖片理解、標註、OCR 類任務
    • mmx search:網路搜尋 / 檢索

    可行動重點

    • 想做「終端裡直接問圖」、「批量出圖」或「自動生成影片」,都只要學一個 mmx 開頭的 CLI 即可,不必各裝一套 SDK。
    • 在腳本中只要換子指令,就能把文字流程擴充到圖像、影音,不用改整個架構。

    2. stderr/stdout 分流:為自動化管線設計的輸出

    多數 AI CLI 會把提示訊息、JSON 結果都塞在一起,要解析結果時只好寫一堆正則。MMX-CLI 的設計直接幫你分好:

    • stdout:只輸出「乾淨結果」,例如 JSON、檔案路徑
    • stderr:UI 提示、進度條、debug 訊息

    💡 關鍵: 把結果與提示嚴格分流,讓你在 CI / 腳本裡直接吃 JSON,不用再寫正則清洗輸出

    這代表你可以這樣用:

    mmx image generate \
      --prompt "一張藍底白字的活動宣傳圖" \
      --json \
      1> result.json \
      2> log.txt
    
    • result.json:可直接被 jq、Python、Node 解析
    • log.txt:留給人類看錯誤、進度

    可行動重點

    • 在任何 Shell/CI pipeline 裡,用 1>2> 就能區分機器要吃的結果、跟人類要看的訊息,少很多「切字串」的工作。

    3. 語義錯誤碼與 async:穩定接在長鏈式工作流後面

    MMX-CLI 有兩個很適合自動化的設計:

    1. 語義錯誤碼(semantic exit codes)
    2. 不只是 0/1,而是用不同 exit code 表示不同錯誤類型(如:授權、配額、參數錯誤等)。
    3. 你可以在腳本裡根據 $? 做分支處理,而不是只知道「失敗」兩個字。

    4. async 影片與圖片一致性

    5. mmx video 支援 --async--no-wait,提交生成後直接結束,不會在終端卡很久。
    6. 產生的任務 ID 可存起來,之後再查詢結果,適合長影片或大量任務情境。
    7. mmx image 支援像 --subject-ref 這類選項,可讓同一批生成的圖片保持主體一致(同一個角色、同一個風格),方便做系列素材。

    💡 關鍵: 用語義錯誤碼搭配 async 任務查詢,可以在長鏈式自動化裡做精細錯誤分流,又不會堵住整條 pipeline

    可行動重點

    • 在 CI / 排程任務中,影片生成用 --async,後面接一個輪詢/查詢腳本,不會讓 pipeline 掛住。
    • 社群素材、產品圖需要「同一個角色」時,在同一批任務加入主體參考參數,減少後期修圖重工。

    適合誰用:把 MMX-CLI 當「通用 AI 插件」來掛

    1. 本機腳本與自動化 pipeline:用 CLI 批量做內容

    典型用法:每天自動生成社群素材(文字 + 配圖)。例如一個簡單的 cron 任務:

    1. mmx text 生成今天要發的貼文文案。
    2. 把文案丟給 mmx image 生成對應主圖。
    3. 結果存到指定資料夾 + JSON 清單。

    Shell 示例:

    #!/usr/bin/env bash
    set -e
    
    # 1. 生成文案
    caption=$(mmx text generate --prompt "替科技品牌寫一則今日 IG 貼文,50 字內,口吻輕鬆" --plain)
    
    # 2. 生成圖片(輸出 JSON,內含檔案路徑)
    mmx image generate \
      --prompt "$caption" \
      --json 1> image.json 2> /dev/null
    
    image_path=$(jq -r '.outputs[0].path' image.json)
    
    echo "文案:$caption"
    echo "圖片:$image_path"
    

    可行動重點

    • 任何原本用 Bash / Python 後面接 curl + OpenAI API 的地方,都可以試著改成 mmx text/image/...,讓指令更短、錯誤處理更好做。

    2. 在 Claude Code / Cursor / OpenClaw 裡當「外掛能力」

    MMX-CLI 可以直接被這些 Agent/IDE 工具當成外部命令調用,不需要額外架 MCP Server:

    • Claude Code / Cursor:程式碼助手可以呼叫系統指令(例如 !mmx ... 或 task runner),把多模態功能塞進 coding workflow。
    • OpenClaw 等 Agent 框架:把 mmx 視為一個 tool,交給 Agent 自己 decide 什麼時候用圖像、影片、搜尋能力。

    範例 workflow(以 Cursor 為例):

    1. 在專案的 script 區塊新增一條:「mmx vision analyze 對當前專案的 UI 截圖做說明」。
    2. 用自然語言跟 Cursor 說:「請幫我分析 screenshot.png,找出 UI 過於擁擠的區域」,由 Cursor 呼叫該 script,再回傳結果給你。

    可行動重點

    • 如果你已經在用 Claude Code / Cursor,試著加一條腳本(後面會給最小範例)讓它能調用 mmx vision,等於幫 Agent 長出「看圖」能力。

    3. 想要簡化多模態 API 整合的工程師 / Side project 作者

    MMX-CLI 用 TypeScript 寫成,跑在 Node.js 18+ 上:

    • 對前端 / JS 工程師特別友善,可以輕鬆串到 Node 腳本、Electron、Next.js 後端。
    • 不想碰太多 SDK,單純想「能被命令行叫起來,回傳 JSON」,就很適合直接用這一套。

    可行動重點

    • 當你在 side project 裡只需要一兩個 AI 能力(例如:上傳照片 → 生成說明文字),優先考慮用 child_process 呼叫 mmx,先把功能打通,再考慮要不要換成直接 API。

    怎麼開始:3 分鐘跑通你的第一個多模態任務

    1. 環境需求與安裝方式

    基本需求:

    • Node.js 18+(建議直接裝 LTS 版本)
    • npm / npx 可用

    安裝成全域「技能」:

    npx skills add MiniMax-AI/cli -y -g
    

    或一般全域安裝(若專案說明有提供 npm package):

    npm install -g @minimax-ai/mmx-cli   # 依官方實際名稱調整
    

    最新安裝指令以官方 README 為準,可從 Reddit 原文往下點到 GitHub 或官網。

    可行動重點

    • 先確認 node -v 是 18 以上;若不是,先更新 Node,再來跑 npx skills add ...

    2. 最小可執行範例:一行文字 → 一張圖片

    安裝完後,先試一個最簡單的生成任務:

    mmx image generate \
      --prompt "一張極簡風格的藍底白字技術活動海報" \
      --json
    

    預期行為:

    • 終端 stdout 輸出一段 JSON,其中會包含生成圖片的本地路徑或 URL。
    • stderr 會有模型載入、進度等訊息,不會干擾 JSON。

    若只想要檔案路徑,可以接 jq

    mmx image generate \
      --prompt "一張極簡風格的藍底白字技術活動海報" \
      --json 2>/dev/null | jq -r '.outputs[0].path'
    

    可行動重點

    • 改幾個不同 prompt(例如品牌名稱、活動主題),就能快速做出一批風格一致的海報草稿。

    3. Node 腳本範例:用 JS 串多模態流程

    如果你想直接在 Node 專案裡用 MMX-CLI,下面是一個「讀文字 → 生成語音檔」的最小範例:

    // file: tts.js
    import { execFile } from 'node:child_process';
    
    function runMMX(args) {
      return new Promise((resolve, reject) => {
        execFile('mmx', args, { maxBuffer: 1024 * 1024 }, (error, stdout, stderr) => {
          if (error) {
            console.error('MMX stderr:', stderr);
            return reject(error);
          }
          try {
            const json = JSON.parse(stdout);
            resolve(json);
          } catch (e) {
            reject(e);
          }
        });
      });
    }
    
    (async () => {
      const text = '歡迎使用 MMX-CLI,這是一個多模態 AI 的命令列工具。';
      const result = await runMMX([
        'speech',
        'generate',
        '--text', text,
        '--json'
      ]);
    
      console.log('生成的音檔路徑:', result.outputs[0].path);
    })();
    

    執行:

    node tts.js
    

    可行動重點

    • 把這支腳本換成 vision analyzevideo generate,你就能在 Node 專案裡快速測出多模態能力,不用先研究一整套 API。

    小結:MMX-CLI 的定位與你可以立刻做的三件事

    MMX-CLI 適合被當成「通用多模態 AI 插件」掛在任何能呼叫命令列的地方:腳本、CI、Agent、IDE。

    你現在可以立刻做的三件事:

    1. 安裝並跑通最小範例:升級 Node → npx skills add MiniMax-AI/cli -y -g → 跑一個 mmx image generate
    2. 在現有腳本裡替換一個原本用 curl + API 的地方,改用一條 mmx text,感受 stderr/stdout 分流帶來的差異。
    3. 在 Claude Code / Cursor 專案裡加一條呼叫 mmx vision 的 script,讓你的程式碼助手從「只會看文字」變成「看得懂圖片」。

    只要能打開終端,你就能用 MMX-CLI 把多模態 AI 接到任何地方。

    🚀 你現在可以做的事

    • 打開終端,確認 node -v 版本後,依文中指令安裝 mmx 並跑一次圖片生成
    • 挑一個現有 Bash / Node 腳本,把其中一段 curl + API 改寫成對應的 mmx textmmx image
    • 在你的 Claude Code / Cursor 專案設定裡新增一條腳本,讓它可以呼叫 mmx vision analyze 來查看專案截圖
  • 用 Claude Cookbooks 做出你的第一個 AI 小工具

    用 Claude Cookbooks 做出你的第一個 AI 小工具

    📌 本文重點

    • Claude Cookbooks 是一套可直接照抄的實戰 Notebook
    • 非工程師可當高級提示模板庫直接用
    • 工程師可快速接 API 做聊天機器人與 RAG 助手
    • 最快五步就能跑出自己的 AI 小工具

    用一句話說清楚:Claude Cookbooks 是一套「Claude 實戰菜單」,照著 Notebook 抄一遍,你今天就能做出自己的聊天機器人、文件助手或程式碼助手。

    原始專案連結:👉 anthropics/claude-cookbooks


    核心功能:這套「菜單」可以幫你做什麼?

    1. 清楚的 Repo 結構:先選你要的「菜」

    進到 GitHub 專案後,你大致會看到這幾類資料夾(名稱可能會略有調整,但概念相近):

    • notebooks/:主要範例,都用 Jupyter Notebook 寫好
    • basic_examples/:最簡單的對話、提示工程示範
    • tools_and_workflows/:工具呼叫、工作流程自動化
    • rag/:RAG(檢索增強生成),用你自己的文件做問答
    • agents/ 或類似資料夾:多步驟任務、小型 Agent 範例

    可以做的事,對應你能採取的行動:

    • 如果你完全沒寫過程式 → 先看標題含有 conversationprompting 的 Notebook,當成「高級版提示語模板」,直接複製到 Claude 網頁版使用。
    • 如果你會一點 Python → 跑 basic_examples 裡的 Notebook,先確認你能成功打出第一個 API 回應。
    • 如果你想做內部工具或 Agent → 從 tools_and_workflowsrag 開始,把範例裡的「假資料」換成你公司的文件或 API。

    2. Notebook 類型:從聊天到自動化,一路拆給你

    Cookbooks 裡的 Notebook 大致可以分成四類,每一類都可以直接改成你的專案:

    1. 對話 / 提示工程 Notebook
    2. 示範怎麼寫系統提示(system prompt)、角色設定、回覆風格控制。
    3. 行動:把裡面的 system prompt 複製出來,替換成你的場景,例如:

      • 把「你是一位友善的 AI 助手」改成「你是一位專門回答退貨政策的客服人員」。
    4. 工具調用(Tool Use)Notebook

    5. 示範怎麼讓 Claude 主動呼叫你定義好的函式,例如查訂單、算報表。
    6. 行動:照著 Notebook 裡的結構定義一個簡單工具:

      python
      def get_order_status(order_id: str) -> dict:
      # TODO: 這裡先寫死假資料,之後再接真的 DB
      return {"order_id": order_id, "status": "shipped"}

      然後讓 Claude 根據使用者輸入決定要不要呼叫這個工具。

    7. RAG(文件問答)Notebook

    8. 示範怎麼把 PDF、Markdown、內網文件先「切片 + 向量化」,再讓 Claude 根據搜尋結果回答。
    9. 行動:先不管效果好不好,拿一份你真的會用到的文件(公司 FAQ、課程教材)丟進範例 Notebook,看能不能成功問出答案。

    10. 工作流程自動化 / Agent Notebook

    11. 示範多步驟流程,例如:解析需求 → 查資料 → 產出報告 → 修稿。
    12. 行動:把裡面的流程步驟改成你的工作,例如「整理每日客服問題 → 匯總成報表」。

    💡 關鍵: 這些 Notebook 的真正價值在於「可直接照抄運行」,先跑出結果再改一兩行,就能快速變成你的專案雛形。

    這些 Notebook 的重點不是「看懂內部原理」,而是先照抄跑出結果,再從中挑一兩行改成自己的業務語句


    3. 拿 Cookbooks 當提示工程與 API 練習教材

    你可以把整個 repo 當成一套免費教材:

    • 練提示工程
    • 每次只做一件事:挑一個 Notebook,只改 system prompt,觀察回覆差異。
    • 練習把「模糊指令」改成「具體條件」,例如:

      • 從「請你幫我改寫」改成「請幫我改寫成 300 字以內、用條列式、適合放在 EDM 裡」。
    • 練 API 使用

    • 大多數 Notebook 只需要你把 api_key 換成自己的,就能跑起來。
    • 把官方文件 + Cookbooks Notebook 打開對照看,很快就能理解 messagestools 等欄位用法。

    適合誰用:非工程師、工程師都能上手

    1. 非工程師:直接拿 Prompt 模板做你的專屬助手

    你不用會 Python,也能從 Cookbooks 撈出超實用的提示模板:

    適合的場景與行動:

    • 客服:
    • 找對話範例 Notebook,看 system prompt 區塊,改成:
      • 「你是某某品牌的客服,回答只能根據以下政策文件,不要自己杜撰。」
    • 把這串 prompt 複製到 Claude 官網或任何支援 Claude 的聊天界面使用。

    • 教學 / 內訓:

    • 找「教學型」prompt(通常會強調分步驟解釋),改成你的主題:

      • 例如從「解釋 Python 基礎」改成「解釋公司新制度給新進同仁」。
    • 內容產生:

    • 使用「內容規劃」「格式控制」相關的 prompt,限制輸出格式,例如:
      • 「每篇貼文必須含有標題、三個重點、CTA 一句。」

    你可以完全忽略程式碼,只把 Notebook 當作「可複製的提示語範本庫」。


    2. 工程師:照範例接後端、做簡單 Agent 或內部工具

    如果你會基本的 JavaScript / Python,Cookbooks 就是現成腳手架:

    • 接後端 API
    • 參考工具調用 Notebook,把你現有的 REST API 包成一個 tool,讓 Claude 負責決定何時呼叫。

    • 做簡單 Agent

    • 用工作流程 Notebook,把「找資料 → 分析 → 生報告」這種流程拆成數個函式,交給模型逐步完成。

    • 配合其他工具

    • 例如搭配 gsd-build/get-shit-done 這類 meta-prompting 框架,把你在 Cookbooks 練出來的 prompt 模板,包成可重用的規格驅動開發模組。

    怎麼開始:5 步跑出你的第一個 AI 小工具

    以下示範用「本機 + 最實用 Notebook」的最短上手路徑。

    步驟 0:準備一支 Claude API Key

    1. 前往 Anthropic 官方平台(依區域而定,通常是 Anthropic Console)。
    2. 建立帳號,進入 API 區域,建立一支 API Key。
    3. 暫存好這串金鑰,等等要寫進環境變數或 Notebook。

    步驟 1:Fork 專案 + 下載到本機

    1. 打開 repo:https://github.com/anthropics/claude-cookbooks
    2. 右上角點選 Fork,建立自己的副本,方便之後修改。
    3. 在終端機輸入:

    bash
    git clone https://github.com/<你的帳號>/claude-cookbooks.git
    cd claude-cookbooks

    如果你不想在本機操作,也可以直接用雲端 Notebook(例如 GitHub Codespaces、Colab)打開 repo,步驟類似,只是不用 git clone


    步驟 2:安裝環境 + 設定 API Key

    1. 建議建立虛擬環境:

    bash
    python -m venv venv
    source venv/bin/activate # Windows 用 venv\Scripts\activate

    1. 安裝依賴(專案內通常有 requirements.txtpyproject.toml):

    bash
    pip install -r requirements.txt

    1. 設定環境變數(以 macOS / Linux 為例):

    bash
    export ANTHROPIC_API_KEY="你的_API_Key"

    Windows PowerShell 則是:

    powershell
    setx ANTHROPIC_API_KEY "你的_API_Key"

    💡 關鍵: 只要正確設定 ANTHROPIC_API_KEY 環境變數,大部分 Notebook 幾乎「零修改」就能直接跑起來。


    步驟 3:啟動 Jupyter Notebook

    在專案根目錄啟動:

    jupyter notebook
    

    瀏覽器會打開一個頁面,看到專案檔案結構,接下來只要點進想學的 Notebook 即可。


    實戰示範 1:照抄一個「聊天機器人」 Notebook

    以一個最簡單的對話 Notebook 為例(名稱可能類似 basic_chat.ipynb):

    1. 打開 Notebook,找到這幾段:
    2. 匯入套件(通常是 from anthropic import Anthropic
    3. 建立 client:client = Anthropic()
    4. 呼叫模型的程式碼:

      python
      response = client.messages.create(
      model="claude-3-5-sonnet-latest",
      max_tokens=256,
      messages=[
      {"role": "user", "content": "你好,幫我想三個 IG 貼文主題"}
      ],
      )
      print(response.content[0].text)

    5. 直接執行所有 Cell,確認能拿到一段回覆。

    6. 第一個客製化改動
    7. messages 改成你要的 system + user:

      python
      messages=[
      {
      "role": "system",
      "content": "你是一位專門幫新創品牌寫社群貼文的內容策劃,回覆一律用繁體中文,語氣自然口語。"
      },
      {
      "role": "user",
      "content": "我們是做手沖咖啡器材的,幫我想三個 IG 貼文主題。"
      }
      ]

    8. 再跑一次,這就是你的第一個「內容策劃小幫手」。

    延伸修改方向:

    • 把 user input 改成 input(),讓程式變成簡單的 CLI 聊天機器人。
    • 限制輸出格式:要求 Claude 回傳 JSON,方便之後接到前端或自動排程工具。

    實戰示範 2:照抄一個「文件助手」 RAG Notebook

    找一個 RAG 相關 Notebook(例如 basic_rag.ipynb),你可以這樣照做:

    1. 找到「載入文件」的 Cell,把原來的 sample text 改成你自己的 FAQ 或產品說明。
    2. 跟著 Notebook 步驟做:
    3. 切分文件 → 建立向量索引 → 根據提問檢索相關片段。
    4. 在最後呼叫 Claude 的地方,確認有把「檢索結果」放進 prompt 裡,例如:

    “`python
    prompt = f”””
    根據以下文件內容回答使用者問題,如果文件裡沒有答案,就老實說不知道:

    {retrieved_chunks}

    問題:{user_question}
    “””
    “`

    1. 執行後,你就得到一個最簡單版的「文件問答助手」。

    延伸修改方向:

    • 把檔案來源改成公司內部 SOP 或 Notion 匯出的 Markdown。
    • 在回覆前加上一段「引用來源」,列出這次回答用到哪些文件標題。

    小結:先抄,再改,最後變成你的專屬 Cookbooks

    使用 Claude Cookbooks 有一個簡單心法:

    1. 先選一個最貼近你需求的 Notebook(聊天 / 文件 / 工具調用)。
    2. 照著跑一次,不改任何東西,只確認能成功呼叫 API。
    3. 從 system prompt 開始改成你的場景,再逐步替換資料來源、工具函式。

    💡 關鍵: 當你能順手改兩三個 Notebook,你實際上已經掌握提示設計、API 呼叫與簡單 Agent 的完整流程。

    當你能順手改兩三個 Notebook,你實際上已經會:

    • 寫出能穩定工作的提示語
    • 呼叫 Claude API,做出自己的 AI 小工具
    • 把文件、後端 API、工作流程接進來,做出簡單 Agent

    接下來,你就可以把自己的版本再 push 回 GitHub,變成「你公司的 Claude Cookbooks」。


    🚀 你現在可以做的事

    • 打開 anthropics/claude-cookbooks,先挑一個最貼近你需求的 Notebook
    • 依照文中步驟設定 ANTHROPIC_API_KEY,完整跑通一個聊天或 RAG 範例
    • 把其中一個 Notebook 的 system prompt 改成你的實際場景,存成你自己的第一個 Cookbooks 版本
  • 🚀 Gemini 網頁版太難用?神級 Chrome 擴充套件「Voyager」讓效率飆升 500%

    🚀 Gemini 網頁版太難用?神級 Chrome 擴充套件「Voyager」讓效率飆升 500%

    隨著 AI 工具的普及,Gemini 已經成為許多人工作、寫程式與學習的得力助手。但老實說,Gemini 網頁版原生的使用體驗真的讓人不敢恭維!身為重度使用者的你,是否也常常遇到以下抓狂的狀況:

    • 對話紀錄像一本爛帳: 左側欄完全沒有資料夾分類,想找幾天前有價值的對話簡直像大海撈針。
    • 長對話翻找純屬折磨: 跟 Gemini 深度探討一個專案後,想回頭找前幾段的某個回答,滑鼠滾輪滑到快起火還是找不到。
    • 偶發的資料遺失: 辛辛苦苦調教出來的絕佳回答,隔天居然神秘消失?

    如果你對這些痛點也深有同感,那麼今天我要大推的這款完全免費的瀏覽器擴充套件——Voyager,絕對是你必裝的生產力「救星」!裝上它之後,上述的反人類設計不僅迎刃而解,還能讓你的 AI 詠唱效率直接翻倍。

    🛠 Voyager 核心功能全解析:把陽春網頁變身專業級 AI 工作台

    1. 📂 告別混亂:無限層級資料夾管理

    原生 Gemini 最讓人頭痛的就是毫無組織的歷史紀錄。Voyager 直接在介面左側植入了非常強大的資料夾功能。你不僅可以隨意新增資料夾,甚至支援建立「子資料夾」來達成多層級的精細分類。

    • 操作極度直覺: 只需選取或直接「拖曳」聊天紀錄,就能將工作、學習、生活分門別類,再也不用瞎找。
    • 多帳號隔離模式: 若你同時持有多個 Gemini 帳號(例如公司用與私人用),點擊右上角人像圖示即可開啟隔離模式。每個帳號的資料夾設定都是獨立的,完全不打架!

    2. ☁️ 無縫跨機作業:雲端同步與本地備份

    在公司電腦好不容易設定好的分類,回家還要重弄一次嗎?完全不用!

    • Google 雲端同步: 點擊「上傳到雲端」,綁定你的 Google 帳號後,即可將設定檔同步到雲端硬碟。到另一台電腦下載擴充功能後,一鍵就能恢復所有熟悉的環境。
    • 本地備份: 如果你高度注重隱私、不想上傳雲端也沒關係,Voyager 支援一鍵匯出至本地端備份,給足你滿滿的安全感。

    3. ⚡️ 生產力外掛:專屬「常用提示詞(Prompt)」面板

    安裝 Voyager 後,介面上會多出一個不遮擋視線的綠色懸浮圖示。點開它,這就是為你準備的專屬 Prompt 彈藥庫!

    • 一鍵呼叫: 你可以將自己高頻率使用的提示詞(例如特定翻譯指令、文章改寫模板或程式碼 debug 起手式)新增進去並打上標籤。下次要用時,一鍵點擊就能直接貼上對話框,省下大量複製貼上的重複勞動。
    • 格式匯出: 這些提示詞可以匯出成 JSON 格式,方便你管理或無縫套用到其他的 AI 工具上。

    4. 🔍 深度探討必備:引用回覆 & Fork 話題分岔

    當對話越來越深入,這兩個進階功能絕對會讓你愛不釋手:

    • 引用回覆: 以往要請 Gemini 針對某段話深入解釋,只能手動反白、複製、貼上再提問。現在只需選取目標文字,上方會自動彈出「引用回覆」按鈕,點擊即可帶入對話框,體驗極佳。
    • Fork(話題分叉): 跟 AI 聊到一半想追問一個「支線問題」,又怕破壞原本完美的主線脈絡?只要開啟 Fork 功能,點擊對話旁的圖示,Voyager 會幫你自動開啓一個新分頁,並無縫帶入前文脈絡。主線支線分開聊,思路再也不混亂!

    5. ⏳ 終結滾輪地獄:可拖曳時間軸導航

    進行長篇對話時,這是最具革命性的痛點殺手!開啟功能後,右側會出現一條時間軸。

    • 時間軸上的每一個「節點」代表你輸入過的一道指令。
    • 滑鼠懸停可以預覽文字,點擊節點就能直接跳轉到該段對話的位置。就像是這篇對話的「迷你目錄」,徹底拯救你的滑鼠滾輪與眼力!

    6. 💾 資料防護網:一鍵完整匯出對話

    有價值的對話心血,一定要掌握在自己手裡!現在只要將滑鼠移動到對話區左上角的 Gemini Logo 上,就會浮現下載圖示。支援將對話完整匯出為 JSON、PDF、圖片等多種格式,再也不怕系統當機吃掉你的心血結晶。

    📥 如何安裝 Voyager?

    這款強大的神級工具安裝非常簡單,且目前完全免費:

    1. Chrome 用戶: 點擊瀏覽器右上角選單 ➡️ 擴充功能 ➡️ 前往 Chrome 線上應用程式商店。
    2. 搜尋「Voyager」即可一鍵安裝。
    3. 重新整理 Gemini 頁面,將擴充功能「釘選」在瀏覽器頂部,馬上享受極致的 AI 體驗!

    💡 小提醒:除了 Chrome 之外,Firefox、Safari 等主流瀏覽器也都支援這款套件喔!

    🎯 結語

    總結來說,Voyager 這款擴充套件完美填補了 Gemini 原生介面的各種缺陷,一次解決了混亂、難找、操作繁瑣等絕大多數的痛點。如果你希望把 AI 真正變成提升生產力的利器,少走一點彎路,強烈建議你立刻安裝體驗!

    👇 讀者互動時間

    你在使用 AI 工具時,還有遇過哪些讓你抓狂的反人類設計呢?或者你手邊有什麼私藏的神仙擴充套件?歡迎在下方留言區跟大家分享交流喔!

  • 【開源神器】受夠了 Windows 越用越卡?GitHub 萬星工具一鍵解鎖效能,附站長實測深度分析!

    【開源神器】受夠了 Windows 越用越卡?GitHub 萬星工具一鍵解鎖效能,附站長實測深度分析!

    每當我們買了新電腦或是剛重灌完 Windows 系統,打開工作管理員的瞬間,往往會感到一陣無力——後台不僅堆滿了幾乎不會用的「全家桶」預裝軟體,還有各種關不掉的隱私數據採集程式,無時無刻都在偷偷吞噬著你的電腦效能。

    想手動優化?改系統設定往往治標不治本,改登錄檔(Registry)又怕把系統搞崩潰。

    如果你也有這些困擾,今天這篇文章將為你介紹一款在 GitHub 上斬獲萬星級別的神級開源專案——Winutil。它被無數資深玩家譽為「Windows 的終極外掛」,我不僅會教你怎麼用,更會附上我實際測試後的「深度自我分析」,帶你看看這款工具到底適不適合你!

    🚀 為什麼你必須認識「Winutil」?

    這款由頂級技術大神開發的工具,其最硬核、最讓人驚豔的設計邏輯在於:它完全不需要下載任何安裝檔!

    這意味著你永遠不用擔心在網路上隨便下載軟體會中標,也不用怕被偷偷安裝流氓軟體。它是一支直接運行在記憶體裡的腳本,用完即走,關閉視窗後就徹底消失,深藏功與名,不會在你的硬碟裡留下任何垃圾文件或常駐後台。

    🛠️ 四大核心功能拆解,把 Windows 變成完全體

    1. Install(軟體安裝):像「點餐」一樣安裝純淨軟體

    重灌系統後,到各個官網一個個下載常用軟體簡直是體力活,還要隨時提防下載按鈕旁邊的假廣告陷阱。Winutil 透過底層調用微軟官方的 winget 或開源的 Chocolatey 引擎,提供了一個極度直覺的「勾選選單」。

    你只需要把需要的瀏覽器、播放器、開發工具打勾,點擊開始安裝,系統就會自動從官方庫抓取最新版本並「靜默安裝」。安全、純淨、全自動!

    2. Tweaks(系統優化):拆除臃腫贅肉,釋放極致效能

    如果把 Windows 比喻成過度裝潢的實品屋,那 Tweaks 就是幫你拆除無用隔間的鐵錘。

    • 一鍵去冗餘:強行卸載那些系統原本「死活不讓你刪」的自帶 App 與過時組件。
    • 隱私保護與效能釋放:關閉後台的遙測數據採集與廣告彈窗,這不僅讓系統清爽,更能實打實地降低 CPU 與記憶體的佔用率。
    • 傻瓜式操作:你不需要懂艱澀的技術細節,只需點擊頂部的 Standard(標準)預設方案,就能完成大滿貫級別的優化。

    3. Updates(更新管理):把升級主導權從微軟手中搶回來

    大家一定都有過這種崩潰體驗:工作做到一半,系統突然提示即將強制重啟更新!在這裡,你可以對 Windows 更新進行「精細化接管」。你可以選擇只接收「安全性更新」,或者徹底暫停更新功能。既保證了系統底層安全,又把升級新功能的權利拿回自己手裡。

    4. Win11 Creator(進階玩家專屬):打造客製化純淨系統

    它能在安裝系統前,就把臃腫軟體、Edge 瀏覽器,甚至是讓老電腦無法升級 Windows 11 的 TPM 限制全部從安裝映像檔中剔除。生成的精簡版系統體積更小、速度更快,讓十幾年前的老電腦也能流暢運行。

    🧐 【站長深度解析】這款工具真的完美嗎?我的實測與自我分析

    作為一個重度依賴電腦效能的部落客與開發者,我親自對這款工具進行了為期一週的極限測試。以下是我的客觀分析與評估:

    優勢分析 (Pros)

    極致的「無痕」體驗:市面上很多號稱優化的軟體(如某某衛士、某某管家),本身就是最大的系統毒瘤。Winutil 採用 PowerShell 記憶體加載,這種「用完即焚」的邏輯才是一個系統工具該有的職業道德。

    開源透明化:這點非常重要。所有程式碼都在 GitHub 上公開接受全球開發者的檢驗,杜絕了後門與惡意代碼的風險。

    效能提升肉眼可見:在我的備用舊筆電(8GB RAM)上實測,執行完 Standard 優化後,開機常駐記憶體佔用從原本的 4.2GB 降到了 2.8GB,系統反應速度明顯變快。

    風險與缺點分析 (Cons)

    缺乏中文友善介面:目前全英文的介面對於一般非技術背景的用戶來說,可能會產生一定的心理門檻。

    過度優化的風險:自由度極高也意味著破壞力強。如果你在不知情的情況下亂勾選進階配置(例如關閉了某些必要的系統服務),極有可能導致部分專業軟體(如虛擬機、老遊戲)無法正常運行。

    📊 站長給你的適用人群建議

    強烈建議使用:受夠了系統卡頓的老電腦用戶、追求極致幀數的電競玩家、剛買新筆電想清除原廠預裝垃圾的人。

    不建議使用:完全不懂電腦基礎操作的純小白、公司配發受嚴格管制的企業級電腦。

    👨‍💻 極客級的新手教學:兩步啟動魔法

    要召喚這個神器,完全不用去亂找下載點,只需要跟著以下兩步操作:

    1. 開啟終端機:按下快捷鍵 Win + X。如果你是 Windows 10,請選擇「以系統管理員身分開啟 PowerShell」;如果是 Windows 11,則選擇「以系統管理員身分開啟終端機」。

    2. 輸入啟動指令:前往該專案的 GitHub 官方頁面(搜尋 Winutil),複製其官方提供的一行 PowerShell 啟動指令,貼上到你的終端機視窗並按下 Enter 回車。

    等待幾秒鐘的下載與加載後,清爽的圖形化介面就會自動彈出!

    ⚠️ 站長最後的強烈警告

    在進行任何系統級別的優化前,請務必點擊工具介面上的「Create Restore Point」(建立還原點)!給自己留一條後路,即使不小心關錯了東西,也能一鍵反悔,這才是成熟玩家的作風。

    Windows 其實並不是不好用,只是微軟預設塞給我們的冗餘資訊太多了。透過 Winutil 這個「開源手術刀」,你絕對能找回那個乾淨、純粹且飛快的作業系統體驗。現在就打開你的終端機,親自感受一下「解鎖效能」的快感吧!

  • 單卡也能練 100B+:MegaTrain 實戰

    📌 本文重點

    • MegaTrain 讓單卡也能訓練 10B~100B 大模型
    • 核心作法是把參數與 optimizer 全部 offload 到 CPU RAM
    • 雙緩衝 + 無狀態層模板,兼顧效能與顯存節省

    只要有一張 80GB 級 GPU 加上一台大 RAM 主機,用 MegaTrain 就能在單機上訓練 10B~100B 等級的大模型,而不是被「沒有多卡集群」卡死。

    論文連結:MegaTrain: Full Precision Training of 100B+ Parameter Large Language Models on a Single GPU


    核心功能:單卡撐起 100B+ 的三個關鍵

    1. 參數與 optimizer 全部搬到 CPU RAM

    MegaTrain 的核心思路:GPU 只當計算核心,所有「長期佔位」的東西都丟回主記憶體

    它做了什麼?

    • 模型參數存在 CPU RAM,不長駐 GPU
    • optimizer 狀態(如 Adam 的一階、二階矩)也在 RAM
    • GPU 上只保留當前 layer 計算必要的 tensor

    你可以怎麼用這個概念?

    • 檢查你現有訓練腳本:
    • 如果用 DeepSpeed ZeRO-3 + CPU offload:你已經在做「部分 offload」,MegaTrain 走的是全面 offload +更緊湊排程
    • 如果是純 PyTorch:之後改 MegaTrain 時,
      • model.to(device) 改成 layer 粒度的「載入 → 計算 → 卸載」
      • optimizer 狀態建立在 CPU torch.device('cpu')

    硬體評估行動

    • 把「模型參數 + optimizer 狀態」估一遍:
    • full precision(FP32)粗估:參數大小 × 4 倍(含 optimizer)
    • 例如 70B 參數:70B × 4 byte × 約 4 ≒ 1.1 TB RAM

    💡 關鍵: 70B 模型全量訓練大約需要 1.1TB RAM,這將決定你主機級別,而不是 GPU 數量。

    • 結論:你需要的是 80GB+ GPU + 1TB 級 RAM 主機,不是多卡伺服器。

    2. 雙緩衝 + 多 CUDA stream:把 PCIe 瓶頸藏起來

    參數放 RAM,麻煩在於 CPU-GPU 傳輸很慢。MegaTrain 用的是「雙緩衝 + 多 stream 管線」

    • buffer A:GPU 正在用來算第 L 層
    • buffer B:同時從 RAM 預先把第 L+1 層的參數搬過來
    • 反向時計算梯度的同時,把上一層用完的梯度再搬回 RAM

    這樣 GPU 幾乎不閒著,傳輸時間被隱藏在計算裡。

    你在現有程式裡可以怎麼調整?

    • 若你自己寫 training loop(PyTorch 為例):
    • for layer in model.layers: 改成:
      • 用兩份 cuda_buffer[0/1] 輪流存放 layer 權重
      • 使用兩個以上 torch.cuda.Stream()
      • stream 0:當前 layer 的 forward/backward
      • stream 1:下一層參數 prefetch + 前一層梯度 offload
    • 若使用框架後續的 MegaTrain 實作:
    • 你要確認的行動點是:
      • 是否支援雙緩衝 / pipeline 配置
      • 監控 GPU 利用率(nvidia-smi)是否接近飽和,而不是卡在 PCIe bandwidth

    💡 關鍵: 透過雙緩衝 + 多 stream,把 PCIe 傳輸隱藏在計算內,才能讓單卡 GPU 不被 offload 拖慢。


    3. 無狀態層模板:不用保留巨大的 Autograd Graph

    巨大模型的另一個顯存殺手,是自動微分系統保存的計算圖和中間 activations。MegaTrain 改成「無狀態層模板」

    • 每一層是一個可重建的「模板」,而不是擁有完整狀態的 module
    • 前向只保留少量必要資訊,反向時再依模板重建需要的計算

    這對你的訓練流程有兩個具體影響:

    1. 更小的 GPU peak memory

    2. 你可以用更大的 batch size 或更長的 context(論文展示了 7B 模型訓練 512K context)

    3. 程式設計方式會改變

    4. 不再依賴 PyTorch 默認 autograd.backward() 幫你全包

    5. 多數情況會透過 MegaTrain 提供的 layer 寫法(例如自訂 forward() + 專用 backward kernel 或模板)

    你可以採取的行動

    • 若你目前已用「手寫 backward / custom autograd function」,遷移難度會低很多
    • 下次設計模型時,把「layer 寫成無狀態模板」當成目標:
    • 像 functional API(F.linearF.layer_norm),避免在 module 裡堆很多狀態

    💡 關鍵: 無狀態層模板讓 7B@512K 這種超長 context 也能在單卡上訓練,核心就是大幅壓縮 activation 佔用。


    適合誰用:三種典型場景

    1. 個人或小團隊:想微調 10B+ 模型

    情境:

    • 你有一台工作站:
    • GPU:A100 80GB / H100 / H200 / RTX 6000 Ada 類似等級
    • RAM:512GB~1.5TB
    • 想做:
    • 微調 LLaMA 3 70BMixtral 8x22B 等級模型
    • 但沒錢租多機集群

    可行操作:

    • 先用現成框架(DeepSpeed、FSDP)跑 7B8B 體驗流程
    • 評估機器 RAM 是否夠容納 70B full precision + optimizer(照前面方法估算)
    • 有 MegaTrain 實作後,把原本的:
    • model/optimizer 建立 & load checkpoint
    • training loop
      改接 MegaTrain 的 API,就可以在單卡上跑 10B+ 微調。

    2. 企業內部:只給一台工作站,卻要做專域模型訓練

    情境:

    • 內部政策:資料不能出機房,只能用本地 GPU 工作站
    • 給你:1 台 H100 + 1TB RAM 主機
    • 任務:訓練 20B~50B 的專域中文模型

    你可以:

    • 用 MegaTrain 架構跑全量訓練或深度微調,而不是只做 LoRA
    • 利用 RAM 空間分多個數據集階段(通用語料 → 專域語料),中間 checkpoint 全在本地

    行動建議:

    • 評估內部是否允許安裝額外系統(Docker / Singularity)
    • 把現有訓練腳本模組化,做出「backend abstraction」,後端可以切:
    • 既有多卡(生產)
    • 單卡 + MegaTrain(實驗和保密數據)

    3. 超長上下文需求:例如 7B 訓練 512K context

    情境:

    • 做法律、財報、長技術文檔 QA,需要模型原生支援 256K~512K context
    • 傳統方案在多卡上容易被 activation / KV cache 顯存吃光

    MegaTrain 的效果:

    • 論文展示:7B 模型、512K context 可以在單張 H200 上完成訓練
    • 背後靠的就是:
    • 無狀態層模板降低 activation 占用
    • 全部 offload 到 RAM,讓 GPU 重複使用顯存

    你可以做的:

    • 現在就先用你熟悉的框架(如 vLLM、LongRoPE)做 inference 測試長上下文
    • 待 MegaTrain 有開源實作時,把這類長 context 的配置轉到 MegaTrain pipeline 中,專門訓練「超長上下文版本」。

    怎麼開始:從現有訓練腳本到 MegaTrain

    1. 先讀系統架構,再對照自己腳本的三個位置

    建議先看論文的 system overview 圖(ArXiv 連結再貼一次:https://arxiv.org/abs/2604.05091),然後對照你現有程式,找出要改的三段:

    1. 參數 offload

    2. 目前:

      • model = Model().to(device) 一次性放上 GPU
    3. 改成:

      • 模型參數 initial 在 CPU
      • 每層 forward 前:從 CPU load 權重到 GPU buffer(雙緩衝)
      • backward 後:梯度寫回 CPU
    4. scheduler / pipeline 控制

    5. 目前:

      • 用標準 optimizer.step() + lr_scheduler.step(),沒管傳輸 vs 計算
    6. 改成:

      • 在 training loop 內顯式管理 pipeline:
      • 啟動多個 CUDA stream
      • 對齊「預取下一層權重」「現在這層算 forward/backward」「上一層把梯度 offload」的時序
    7. batch / context 設定

    8. 目前:

      • 根據 GPU 顯存決定 batch size、sequence length
    9. 改成:
      • 以「PCIe 與 GPU 算力的瓶頸」為核心:
      • 指標:GPU 利用率是否高、PCIe 帶寬是否打滿
      • 行動:
        • 在不 OOM 的前提下先拉長 context
        • 再微調 global batch(可以使用 gradient accumulation)

    2. 單機環境檢查清單與參考配置

    硬體參考配置(入門能練 10B+)

    • GPU:H100 / H200 / A100 80GB / RTX 6000 Ada(越新越好)
    • CPU:至少 32 實體核心,支援高記憶體頻寬
    • RAM:512GB 起跳,建議 1TB 以上(70B+ 更安心)
    • 儲存:NVMe SSD 4TB+(存 dataset + checkpoints)
    • 介面:PCIe 4.0/5.0 x16(關乎 CPU-GPU 帶寬)

    軟體環境檢查清單

    • [ ] OS:Linux(Ubuntu 20.04+ 或等級相當)
    • [ ] NVIDIA driver + CUDA 對應 GPU 型號
    • [ ] PyTorch(建議 2.x
    • [ ] 有條件的話:安裝 NCCL、cuBLAS 等 GPU 加速庫
    • [ ] 預備一份你現有的 LLM 訓練腳本(DeepSpeed / FSDP / 純 PyTorch)做「對照改造」。

    3. 遷移現有訓練流程的實作步驟

    1. Step 1:在小模型上模擬 offload 思路

    2. 選一個 1B~3B 模型(如 LLaMA 2 7B 子集或自訂小模型)

    3. 手動實作:
      • layer 粒度的「CPU → GPU → CPU」權重搬移
      • 用兩個 CUDA stream 做簡易雙緩衝
    4. 目標:

      • 看懂 pipeline 行為 + 確認自己不會被資料同步 bug 卡住
    5. Step 2:把這套方式嵌進你原本的 training loop

    6. 保留原本的:

      • loss 計算
      • optimizer / scheduler 更新邏輯
    7. 替換的:

      • model 前向/反向部分,改成 MegaTrain style 的 streaming
    8. Step 3:放大模型 & 長上下文實測

    9. 按照 RAM 預算,選擇 7B → 13B → 30B → 70B 漸進放大

    10. 每次放大:
      • 用 profiler 觀察:
      • GPU 利用率
      • PCIe 傳輸
      • CPU 負載
    11. 逐步調:
      • batch size
      • context length
      • gradient accumulation step

    小結:單卡練大模型,不再只是理論

    MegaTrain 給的不是「又一個分散式訓練框架」,而是一個很直接的選項:

    若你有一張高階 GPU + 超大 RAM 主機,可以用記憶體為中心的設計,在單卡做原本要多卡才能完成的 10B~100B 級訓練,包含超長上下文任務。

    接下來的實際行動:

    1. 估算你目標模型的 RAM 需求
    2. 準備一份可修改的 PyTorch/DeepSpeed 訓練腳本
    3. 按本文三步(offload、scheduler、batch/context)逐步引入 MegaTrain 的設計思路

    當你能在 7B 模型上穩定跑 512K context,單卡訓練 10B+ 其實就不遠了。

    🚀 你現在可以做的事

    • 用文中公式估算你目標模型(例如 20B 或 70B)的 RAM 需求,確認現有主機是否足夠
    • 拿一個 1B~3B 模型,在現有 PyTorch 訓練腳本中實作簡單的 CPU↔GPU offload + 雙 CUDA stream
    • 打開論文 MegaTrain: Full Precision Training of 100B+ Parameter LLMs,對照你腳本中的 offload、scheduler、batch/context 三個區塊做標註,為未來遷移預留介面