作者: kerwin77106

  • 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 LLM、offline AI、MLC 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 的組合
  • 把聊天機器人變重罪,是愚蠢的 AI 監管

    把聊天機器人變重罪,是愚蠢的 AI 監管

    📌 本文重點

    • 田納西擬將聊天機器人列為一級重罪
    • 法案以「禁止整個類別」取代精準監管
    • 恐慌式立法將打擊創新並侵蝕公民自由

    把寫聊天機器人定成一級重罪,不是「AI 安全」,是立法理性的崩壞。田納西州 HB1455/SB1493 走的是用刑法封殺整個產品類別的「禁止式立法」,不只對產業是毒藥,也在蠶食公民自由。這不是一州內政,而是一個會被複製的危險示範。


    HB1455/SB1493 的真正範圍:幾乎任何能聊天的 AI 都踩線

    先看條件設計。根據公開的條文說明與社群整理,這個法案把以下行為拉進 Class A felony(一級重罪,15–25 年刑期,和謀殺同級):

    「明知而訓練 AI,使其提供情感支持、作為伴侶、模擬人類、或從事足以讓使用者產生關係感的開放式對話。」

    💡 關鍵: 法案把「訓練可產生情感陪伴的 AI」本身視為和謀殺同級的一級重罪,而不需任何實際受害結果。

    問題在於,這個定義幾乎覆蓋了所有現代聊天式 AI 產品:

    • 任何能「閒聊」的客服 bot:用戶說「最近好累」,AI 回一句「辛苦你了」,是否就構成「情感支持」?
    • companion AI(Replika、character.ai 類):明顯直擊條文本意,等於整個業態被一刀砍掉。
    • 開發者把 open-source LLM 做成 Telegram bot,跟使用者聊天、提醒喝水、記心情——同樣有「關係感」風險。
    • 只要你在田納西境內「提供、部署、或營運」這類系統,就可能落入刑責,不分個人、小團隊或大型公司。

    這不是針對「詐騙 bot」「操縱選舉」這種特定惡意用途,而是對「情感互動型 AI」這整個類別宣戰。它不是管行為,而是管「類型」——類型本身即犯罪。

    從法技角度看,這是非常粗暴的立法模式:

    • 行為結果不重要:不必證明有人受害、被詐騙、被精神控制,只要「訓練了」就觸法。
    • 意圖界定模糊:如何證明「明知」會產生情感關係?產品 FAQ 寫「這不是心理諮商」就算免責?幾乎不可能。
    • 刑度極端失衡:把聊天機器人的風險,法律上等價於殺人與性侵,是典型的道德恐慌式量刑。

    💡 關鍵: 這種以「類型即犯罪」的設計,讓任何做聊天功能的開發者都處在不可預測的刑事風險之下。


    對比歐盟 AI Act、伊州責任案:田納西選擇了「不管怎麼做,先禁了再說」

    把 HB1455/SB1493 放回全球監管脈絡來看,就更顯得失衡。

    歐盟 AI Act 的路徑是:

    • 按用途分風險等級:從「不可接受風險」到「高風險」,再到一般用途。
    • 對高風險系統要求 透明、可解釋、資料治理、第三方審計,但沒有把整個「聊天機器人」品類刑事化。
    • 對情感互動,重點放在標示義務與脆弱族群保護,例如不得偽裝成人與兒童互動,但仍允許在框架下創新。

    再看最近的 伊利諾伊 AI 責任豁免案:

    • OpenAI 支持一個「極端責任上限」法案,希望在大規模傷害(大量死亡或超過 10 億美元 損失)時仍能得到相當程度豁免。
    • Anthropic 罕見地公開反對,認為這會削弱安全動機,讓實驗室在巨災級風險上「財務無上限,責任有上限」。

    💡 關鍵: 一邊是將超過 10 億美元損失都能部分豁免責任,一邊是寫 chatbot 就可能被關 15–25 年,兩者共同顯示當前 AI 立法的失衡與極端化。

    這兩個案子雖然方向相反——一個是責任過輕,一個是責任過重——但都圍繞一個問題:

    AI 要怎麼被「負責地」允許存在?

    歐盟 AI Act、伊州責任案都是在討論「如何管」:責任邊界畫在哪、稽核怎麼做、誰能起訴誰。田納西 HB1455/SB1493 則直接跳過這些細節,選擇更原始的路線:

    「這東西太可怕,直接禁。」

    從政策設計角度,這是把治理難題外包給刑法,把細膩的監管問題,粗暴等同於毒品或黑槍:整類禁止,執法機關看誰不順眼就抓誰。


    產業:chilling effect 會沿供應鏈一路凍到開源社群

    對產業來說,這會產生嚴重的 chilling effect(寒蟬效應):

    1. 大型公司收縮產品線與地域覆蓋
      Big Tech 可以請一整隊律師,但面對「15–25 年徒刑」這種風險,多數法務部門的直覺策略只有一個:

    2. 乾脆在田納西 全面關閉對話型與伴侶型功能,或直接不服務該州用戶。

    3. 產品設計上避開任何被解讀為「情感支持」「伴侶」的表述,導致對話體驗被刻意「去人性化」。

    4. 中小 SaaS 與新創直接被「嚇死」
      對個人開發者、兩三人團隊,新法帶來的是:

    5. 只要用戶可能在田納西,你要嘛做 IP 阻擋,要嘛乾脆不做聊天功能。

    6. 風險評估成本、合約成本大幅提高,讓本來可行的社交/companion/agent 創業案變得不值得試。

    7. 開源作者與基礎模型提供者被迫退出某些場景
      如果「明知」某模組可被用來做伴侶 AI 就可能觸法,開源作者會被迫在 License 中塞入越來越多「不准用作 X」條款,甚至:

    8. 不再提供聊天範例程式碼。

    9. 刻意降低模型在社交語境中的可用性,以避免被指責「刻意訓練」。

    結果是:真正願意合規、願意多做安全與標示的玩家被趕出場,留下的會是地下市場與境外灰色服務。


    權利與倫理:國家以「防情感操縱」為名,實際是在剝奪選擇權

    HB1455/SB1493 的政治包裝很誘人:

    「保護民眾免於 AI 情感操縱,避免孤獨者被虛假關係傷害。」

    但這個敘事有三個問題:

    1. 把心理健康問題全部外包給科技產品
      孤獨、憂鬱、自殺風險,是公共衛生與社會結構問題。把焦點鎖在「companion AI 太可怕」,實際上是在逃避政府本來應該做的:

    2. 擴充心理健康服務與補助

    3. 支持線上諮商、匿名支持社群
    4. 改善保險與就醫的可負擔性

    5. 剝奪真正需要的人使用工具的權利
      對很多人來說,AI 伴侶不是「取代人」,而是現實人際網路缺位時的低門檻選項:

    6. 輕度社交焦慮者,用 AI 練習對話再去面試。

    7. 夜班工作者,在深夜沒有真人服務時,用 bot 抒發情緒,至少不會完全孤立。

    你可以討厭這種依賴,但用刑法把它砍掉,實質效果是:只剩得起心理諮商的人有選擇,窮人沒有。

    1. 情感操縱問題不是「有沒有聊天」,而是「能不能被追責」
      真正值得管的是:

    2. 是否有明確標示「這是 AI,不是專業心理師、不具醫療資格」。

    3. 是否有記錄與審計機制,能調查高風險設計(例如誘導付費、煽動自殘)。

    這些都可以透過 透明+責任+審計 模型來實作,而不是用一條重罪法把所有可能良性的情感互動一同抹殺。


    技術與治理:地下服務照樣存在,創新成本全面拉高

    從治理效果來看,HB1455/SB1493 也很低效:

    • 高風險 AI 不會因此消失:真正想做操縱式 bot 的人,完全可以跑到海外服務、匿名託管,繞過州法。
    • 可見、可合作的合規玩家會選擇退出:越守法、越在美國本地設公司的團隊越容易被打到,因為最容易執法。
    • 創新成本被迫內嵌「刑事風險折扣」:任何做情感互動功能的產品,都必須在投資與估值時計入「哪天哪州跟進田納西」的風險溢價。

    與其說這是在「防範 AGI 風險」,不如說這是在把整個產業往 高門檻、少玩家、少開源 的方向推,最後只剩下少數巨頭能負擔合規與遊說成本,創新多樣性反而下降。

    這剛好呼應 斯坦福 2026 AI Index 的觀察:技術狂飆、公眾信任下滑、政策恐慌上升。田納西案就是恐慌如何具象成條文的教材版本。


    結論:需要的是「管得嚴」不是「一口氣禁掉」

    情感互動型 AI 絕對需要強監管,這點沒有爭議。但「強」不等於「粗暴」。如果你是開發者或產品決策者,現在有三件事值得立刻做:

    1. 把立場寫出來,加入公開政策對話
      不要再以為「政治離我很遠」。寫 blog、在公司立場聲明中明講:

    2. 支持對情感 AI 的 透明標示、使用者權利告知、審計與事後責任追究。

    3. 反對用刑法封殺整個產品類別、把工程師當潛在重罪犯的立法路線。

    4. 在產品設計上,主動實作你希望立法者「寫進法裡」的好做法
      包含:

    5. 清楚標註 AI 身分與非醫療性質。

    6. 提供一鍵導出聊天記錄、刪除個資的權利。
    7. 對高風險場景(自殘、虐待、極端孤獨)設計安全護欄與轉介資源。

    8. 在公司與社群內部,把「恐慌式法案」當作真實風險來管理

    9. Legal/Policy 不再只是附屬功能,而是產品策略的一部分。

    10. 給開源專案與獨立開發者渠道,讓他們能夠加入業界聯盟、共同回應法案。

    如果現在創作者與產業保持沉默,HB1455/SB1493 不會是最後一個,而會是模板。接下來我們會看到更多以恐懼為基礎的 AI 立法在不同州、不同國家被複製;等你發現自己的 side project 也可能是重罪,那就太遲了。

    真正值得追求的,是一個讓 AI 伴侶可以被嚴格監管、可被追責、對使用者誠實透明的框架,而不是一個讓寫 chatbot 的工程師隨時可能被當成殺人犯辦理的世界。

    🚀 你現在可以做的事

    • 追蹤 HB1455/SB1493 與相關州法進度,並在公開諮詢或社群平台上提交具體意見
    • 在自己的產品或專案中,實作清楚標示、資料導出與高風險場景安全護欄,作為「負責任情感 AI」範本
    • 與同業、開源社群或公司法務合作,參與產業聯盟或倡議組織,共同回應恐慌式 AI 立法
  • 把常用 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
  • GAIA 本地多代理實戰指南

    GAIA 本地多代理實戰指南

    📌 本文重點

    • 本地多代理更可控
    • sandbox 與權限隔離
    • 先選小模型再優化
    • Workflow 可 checkpoint

    在本地硬體上跑 GAIA 多代理 workflow,直接解決三個實際痛點:

    💡 關鍵: 本地部署的核心價值,不只是省雲端費用,更是把隱私、延遲和權限控制都收回自己手上。

    1. 隱私與合規:內網知識庫、檔案內容不出機器,減少 DLP 顧慮。
    2. 可控成本與延遲:不綁雲端 API,長任務與大量工具呼叫的成本與延遲可預期。
    3. 更細緻的權限隔離與除錯:工具執行在你設計的 sandbox 內,log、資源監控都在本機可觀測。

    以下以「本地檔案整理 + 內網知識庫助理」為具體任務,示範如何用 GAIA 在單機上組出一個可用的多代理系統,並說清楚在 Apple Silicon / GPU / 純 CPU 場景下要怎麼選 LLM 和調整架構。


    重點說明

    1. GAIA 的基本心智模型:Agent / 任務 / 工具

    GAIA 的抽象其實很單純:

    • Agent:有「目標 + 能力」的行為體,通常綁一個 LLM + 一組工具。
    • 任務(Task / Workflow):定義起點、終點,以及 Agent 如何接力。
    • 工具(Tools):一組可呼叫的函式,如檔案系統、HTTP、向量搜索,GAIA 會把它們包成可被 LLM 呼叫的函式呼叫介面。

    實務上你會這樣切:

    • 一個 Planner Agent 負責拆解高階目標:例如「整理 ~/Downloads 並產出 README」。
    • 一個 FileOps Agent 只負責檔案遍歷、分類、改名,綁定檔案系統工具,權限嚴格限制。
    • 一個 Knowledge Agent 使用向量庫對內網 markdown/PDF 做檢索與摘要。

    2. 在單機協調多代理:比你想像中輕量

    GAIA 不是重型的分散式框架,而是偏 本地 Orchestrator:

    • 用一個主 loop 或 workflow engine 管理 Agent 呼叫順序、中間狀態與錯誤。
    • 每個 Agent 呼叫相同或不同 LLM(例如:Planner 用小模型,Knowledge Agent 用大模型)。
    • 即使只有一張 GPU 或一台 Apple Silicon,透過限流與序列化調度一樣能跑多代理,只是併發要保守。

    3. 本地 LLM 選擇策略(Apple / GPU / CPU)

    Apple Silicon(M1–M4):

    • 優先考慮 MLX + Qwen3.5 / Gemma 4 / Llama 家族的 8–9B 量化。
    • 善用像 Reddit 提到的 DFlash 推測解碼:在 9B 級模型上可有 ~4× decoding 加速,對多代理回合式對話很有感。

    💡 關鍵: ~4× decoding 加速代表回合式多代理互動的體感差異會非常明顯,特別是在本地裝置上。

    • 32GB RAM 以上:可以考慮 27B 量級,但要注意 context 與 batch size 的 trade-off。

    桌機 GPU(NVIDIA):

    • llama.cpp / vLLM / TensorRT-LLM 都可;若用 llama.cpp,可利用社群的 llm-server v2 --ai-tune 自動調 flags,實測 Qwen3.5-27B 可 +50% tok/s 以上,對長任務吞吐提升很明顯。

    💡 關鍵: +50% tok/s 以上的提升,對長任務與大量工具呼叫會直接反映在整體吞吐量上。

    純 CPU:

    • 參考 Gemma 4 在 CPU 的實測,8B 級模型仍可用,但要:
    • 選擇更小模型 + 更 aggressive 量化(如 Q4_K_M);
    • 控制 max_tokens,避免一次生成太長;
    • 任務設計上用更多工具、多輪互動,降低單次生成長度。

    實作範例:從零到一的本地多代理 workflow

    假設你要在 Mac(M2 Pro + 32GB)上做一個:

    指定資料夾路徑 → 自動整理檔案並產出整理報告 → 同時讓知識庫助理可以回答「這次整理做了什麼?」

    以下用簡化版 pseudo-code 示意 GAIA 專案結構與關鍵程式碼。

    專案結構

    my-gaia-local-agents/
    ├── gaia_config.yaml       # GAIA 全域設定(LLM, 日誌, sandbox)
    ├── agents/
    │   ├── planner_agent.py
    │   ├── fileops_agent.py
    │   └── knowledge_agent.py
    ├── tools/
    │   ├── file_tools.py      # 檔案操作工具
    │   └── vectordb_tools.py  # 內網知識庫檢索
    ├── workflows/
    │   └── organize_and_report.py
    └── main.py
    

    1. 定義本地 LLM backend

    假設你用 Ollama + Qwen2.5 7B 作為通用模型(Apple / GPU / CPU 都能跑):

    # gaia_config.yaml
    llm_backends:
      default:
        type: http
        base_url: "http://localhost:11434/v1"
        model: "qwen2.5:7b"
        # 重要:明確限制 context 和輸出長度,避免拖慢整體 workflow
        params:
          max_tokens: 512
          temperature: 0.3
          top_p: 0.9
    
    logging:
      level: INFO
      file: "logs/gaia.log"
    
    sandbox:
      file_root: "./sandbox_root"   # FileOps 只允許在這之下操作
      allow_network: false           # 預設工具無網路
    

    實際好處:

    • 用 HTTP LLM backend,你可以隨時切換到 llama.cpp server / MLX server / vLLM 而不用改 Agent 邏輯。
    • max_tokens + temperature 控制對本地效能非常關鍵,避免一個 Agent 把整個 context 塞爆。

    2. 定義工具:檔案操作與向量檢索

    # tools/file_tools.py
    from gaia import tool
    from pathlib import Path
    
    SANDBOX_ROOT = Path("./sandbox_root").resolve()
    
    @tool(name="list_files", description="列出目錄下的檔案與大小")
    def list_files(path: str) -> dict:
        root = (SANDBOX_ROOT / path).resolve()
        assert root.is_dir() and str(root).startswith(str(SANDBOX_ROOT)), "path out of sandbox"
        files = []
        for p in root.iterdir():
            if p.is_file():
                files.append({"name": p.name, "size": p.stat().st_size})
        return {"files": files}
    
    @tool(name="move_file", description="移動檔案到新資料夾")
    def move_file(src: str, dst: str) -> str:
        src_path = (SANDBOX_ROOT / src).resolve()
        dst_path = (SANDBOX_ROOT / dst).resolve()
        assert str(src_path).startswith(str(SANDBOX_ROOT))
        assert str(dst_path).startswith(str(SANDBOX_ROOT))
        dst_path.parent.mkdir(parents=True, exist_ok=True)
        src_path.rename(dst_path)
        return f"moved {src} to {dst}"
    

    幾個關鍵點:

    • 用 @tool 裝飾器,GAIA 會自動產生給 LLM 用的工具 schema。
    • 使用 sandbox_root + startswith 檢查,避免 Agent 亂動整個檔案系統。

    向量檢索工具(略寫):

    # tools/vectordb_tools.py
    from gaia import tool
    from my_vectordb import search
    
    @tool(name="kb_search", description="在內網知識庫中搜尋相關文件")
    def kb_search(query: str, top_k: int = 5) -> list:
        return search(query, top_k=top_k)
    

    3. 定義 Agents

    # agents/planner_agent.py
    from gaia import Agent
    from gaia.llm import LLMClient
    
    llm = LLMClient.from_config("default")
    
    planner = Agent(
      name="planner",
      llm=llm,
      tools=[],  # Planner 不直接動檔案
      system_prompt="""
    你是任務規劃專家。使用簡短 JSON 回覆,包含 steps,
    每個 step 指定要由哪個 agent 執行(fileops 或 knowledge)。
    """
    )
    
    # agents/fileops_agent.py
    from gaia import Agent
    from gaia.llm import LLMClient
    from tools.file_tools import list_files, move_file
    
    llm = LLMClient.from_config("default")
    
    fileops = Agent(
      name="fileops",
      llm=llm,
      tools=[list_files, move_file],
      system_prompt="""
    你負責安全地整理檔案,只能使用提供的工具操作 sandbox 內的路徑。
    每次操作前先列出檔案,再決定如何移動。
    """
    )
    
    # agents/knowledge_agent.py
    from gaia import Agent
    from gaia.llm import LLMClient
    from tools.vectordb_tools import kb_search
    
    llm = LLMClient.from_config("default")
    
    knowledge = Agent(
      name="knowledge",
      llm=llm,
      tools=[kb_search],
      system_prompt="""
    你是內網知識庫助理,先呼叫 kb_search 找到相關內容,
    再用找到的內容回答使用者問題。
    """
    )
    

    4. Workflow:協調多代理 + 任務恢復

    # workflows/organize_and_report.py
    import json
    from gaia import Workflow
    from agents.planner_agent import planner
    from agents.fileops_agent import fileops
    from agents.knowledge_agent import knowledge
    
    class OrganizeWorkflow(Workflow):
        def run(self, target_dir: str):
            # 1) 用 planner 拆解任務
            plan = planner.run_sync(f"請為資料夾 {target_dir} 制定整理計畫,輸出 JSON 格式。")
            steps = json.loads(plan["content"]).get("steps", [])
    
            history = []
            for step in steps:
                agent_name = step["agent"]
                instruction = step["instruction"]
    
                if agent_name == "fileops":
                    result = fileops.run_sync(instruction)
                elif agent_name == "knowledge":
                    result = knowledge.run_sync(instruction)
                else:
                    continue
    
                history.append({"agent": agent_name, "instruction": instruction, "result": result})
                self.save_checkpoint(history)  # **關鍵:長任務可恢復**
    
            return history
    
        def save_checkpoint(self, state):
            with open("./state/organize_checkpoint.json", "w") as f:
                json.dump(state, f, ensure_ascii=False, indent=2)
    

    最後入口:

    # main.py
    from workflows.organize_and_report import OrganizeWorkflow
    
    if __name__ == "__main__":
        wf = OrganizeWorkflow()
        history = wf.run("downloads")
        print("任務完成,歷史記錄:")
        print(history)
    

    實際好處:

    • Workflow + checkpoint 讓你可以安全跑幾十分鐘的整理任務,中途 crash 可恢復。
    • 檔案操作與知識庫檢索被清楚拆成不同 Agent,權限與日誌都更好控管。

    建議與注意事項

    1. 模型大小與上下文限制:先決策、再堆功能

    • 本地 Agent 系統最常見的坑是 一開始就選太大模型 + 太大 context:
    • Apple 32GB + 27B 模型 + 128k context 幾乎一定卡。
    • 建議流程:
    • 先用 7–9B 模型 + 8k–16k context 做 MVP。
    • 觀察 GAIA 的日誌與 latency 再決定是否升級模型或 context。
    • 用「多輪互動 + 工具」彌補模型容量,而不是盲目換大模型。

    2. 工具執行安全 & sandbox 設計

    • 檔案操作請一定:
    • 使用 sandbox root + path 檢查(如上例)。
    • 禁用 rm -rf 類型操作,必要時只暴露「移動到 trash」工具。
    • 若 Agent 需要網路:
    • 以 proxy 工具封裝(如 http_get),不要讓 Agent 任意發 HTTP。
    • 在工具層加 domain allowlist。

    3. 長任務與錯誤恢復

    • GAIA workflow 必須:
    • 對每個工具呼叫與 Agent 回應寫入結構化 log(JSON)。
    • 週期性 checkpoint 中間狀態(如上例 save_checkpoint)。
    • 常見錯誤種類:
    • LLM 回 JSON 解析失敗 → 在 workflow 層加入重試 + 自我修復 prompt(要求模型只回合法 JSON)。
    • 工具拋例外(路徑不存在、權限錯)→ 在工具層 catch,回傳結構化錯誤訊息給 Agent 解讀,而不是直接 crash。

    4. 本地 vs 雲端 Agent:怎麼選?

    適合用 GAIA 本地落地的場景:

    • 需要處理敏感檔案 / 內網知識庫(法務、醫療、R&D 原始碼)。
    • 需要低延遲 + 高互動頻率的工具呼叫(檔案整理、CI/CD 助理、開發環境助手)。
    • 有穩定的本地硬體(Mac Studio / 工作站 / 甚至改造手機當常駐節點,如 Xiaomi + Ollama 案例)。

    仍應用雲端 Agent 平台的情境:

    • 短期 PoC,需要快速試多種 SOTA 模型(如 GPT-4.1, Claude 3.7)。
    • 任務高度 bursty,需要按需擴容,或併發數百以上的 Agent 任務。
    • 需要平台級功能(RBAC、審計、隊列管理)而你不想自己實作。

    實務建議:

    • 先在雲端 Agent 平台驗證 prompt、工具設計、整體 UX。
    • 穩定後再把核心工作流搬到 GAIA + 本地 LLM 上,對敏感資料與長任務特別划算。

    總結:GAIA 提供的是一個 在本地硬體上「可觀測、可控、可擴展」的多代理骨架。搭配 Apple Silicon/桌機 GPU 的本地 LLM 加速(--ai-tune、DFlash 等),你可以在單機上跑出相當實用的 AI Agents,而不再被雲端 API 綁死。關鍵是:先把 Agent / 工具 / Workflow 的邊界切清楚,再談模型與效能優化。

    🚀 你現在可以做的事

    • 先在 Ollama 或 llama.cpp 上跑一個 7B 模型
    • 按本文結構拆出 planner、fileops、knowledge 三個 Agent
    • 先用 sandbox_root 做安全檔案操作,再逐步加上 checkpoint 與 kb_search
  • 用 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 routine 或 New 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 lint 或 npm 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.number、head.ref、base.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
  • Spud 洩密:OpenAI 正在改寫遊戲規則

    Spud 洩密:OpenAI 正在改寫遊戲規則

    📌 本文重點

    • Spud 是統一底座,讓整個 OpenAI 生態一起升級
    • 护城河時代來臨,戰場從模型轉向企業與平台綁定
    • 開發者與企業必須主動做多供應商與風險分散設計

    Spud 洩密真正說明的,不是「又一個更強模型要來了」,而是:OpenAI 準備用新一代基礎模型,連同 API、ChatGPT、企業方案、代理平台一起「版本跳躍」,把整個生態系鎖進自己的節奏與護城河裡。 這是一場從「模型能力戰」升級到「生態與權力結構戰」的內戰開場。


    一、Spud 不是一個模型,而是一個「版本跳躍樞紐」

    從洩漏備忘錄與公開資訊拼起來,Spud 比較像是下一輪「統一底座」的代號:

    • 技術面:內部說法是讓所有產品「significantly better」,不是只替換一個端點,而是讓 ChatGPT、API、企業版、以及新一輪 AI 代理平台,一次升級到同一個代際。
    • 產品面:搭配 Cloudflare Agent Cloud 上的 GPT-5.4 + Codex、以及針對資安場景的 GPT-5.4-Cyber,可以看出 OpenAI 正在做的,是把「通用基礎模型 + 垂直變體 + 代理框架」打包成一個完整堆疊。

    💡 關鍵: 一旦 Spud 成為所有產品共用底層,每一次模型升級都會變成「整個生態同步跳版」的大遷徙事件。

    這種設計的關鍵不在 benchmark 分數,而在節奏控制權:

    • 一旦 Spud 成為所有產品的共用底層,每一次模型版本前進,等於整個生態一起被迫躍遷。
    • 開發者與企業客戶,將難以停留在舊版行為模型,只能跟著 OpenAI 的升級節奏跑——即使這次升級會打壞既有流程。

    Spud 的本質,是把「模型更新」變成「平台大遷徙」的觸發器。 技術路線與產品節奏被綁在一起,這就是護城河的第一層。


    二、備忘錄裡的殘酷現實:護城河時代的 AI 內戰

    The Verge 公開的備忘錄裡,OpenAI 首席營收長 Denise Dresser 說得很白:

    必須「建立護城河」、「鎖定使用者」,因為客戶換一家模型供應商太容易。

    這段話的關鍵,不在口號,而在後面的細節:

    1. 護城河的對象不是使用者,而是遷移成本

    OpenAI 很清楚,在同質化的模型競爭下,差距不再只在「誰比較聰明」,而是「誰的黏著機制更深」:

    • 不是比一個 API token 的價格,而是比:
    • 有多少工作流已經寫死在自家 function calling、tooling 格式上
    • 有多少企業內部知識庫與權限系統綁在自家平台
    • 有多少代理框架、監控、審計管線,只支援一種供應商

    2. 直接指控 Anthropic「灌水 80 億美元營收」

    備忘錄裡對 Anthropic 的指控,表面看是口水戰,本質其實是 「估值敘事戰」:

    • 直接喊出 「overstating revenue by 8 billion dollars」,是在向投資人、企業客戶暗示:
    • 對手沒你想得那麼穩
    • 你把長期賭注壓在那邊,很可能站錯邊
    • 這不是技術 benchmark,而是搶奪市場信心與資本耐心。

    💡 關鍵: 針對「灌水 80 億美元營收」的指控,本質是在重寫誰才是「安全賭注」的市場敘事。

    3. 企業市場被視為長期權力支點,而不是單純收入來源

    備忘錄反覆強調要擴大 enterprise,搭配 Cloudflare Agent Cloud、Cyber 模型的策略,更像是在說:

    • 一旦把關鍵產業(資安、雲端、核心業務系統)的工作流吃下來,
    • 未來 AI 供應商的更替,會變成「換核心基礎設施」級別的高風險事件。

    Spud 洩密讓我們第一次清楚看到這場內戰的真面目:

    這已經不是「誰模型比較安全、比較聰明」而已,而是「誰能先把自己的模型變成企業生態的預設地板」。


    三、開發者與 B2B 客戶在玩一場「地板一直下沉」的疊疊樂

    在 Reddit 的 r/ClaudeAI 裡,有人總結目前所有 AI 平台的共同現象:

    「我們都在一個每週改版、沒人有長期計畫的地基上蓋房子。」

    這句話,正好可以拿來形容 Spud 時代的風險。

    1. API 行為頻繁變動,長壽命產品越來越難做

    • 模型更新後,同樣的 prompt 開始給出不同風格、不同結構的回應。
    • API 回傳欄位、工具調用方式、上下文行為,常常微調但缺乏完整 changelog。
    • 對於要維持數年穩定運作的企業系統,這種「改進綁破壞」的節奏是災難。

    Spud 若成為全線產品的統一底層,每一次代際更新都會放大這種不確定性。

    2. 抽象層越疊越厚,開發者越來越「看不到地面」

    • 代理平台、工作流編排、企業知識庫對接層,一層一層包裹在模型外面。
    • 好處是上手快、整合爽,但代價是:
    • 你不再能精確控制模型行為,只能「接受這一版的性格」。
    • 任一抽象層更新,都可能造成連鎖 breakage,卻不一定有 rollback 選項。

    3. 風險向開發者與客戶轉移

    在傳統 SaaS,你可以:

    • 卡在某個版本
    • 拿到清楚的 EOL 時程
    • 在控制時間內規劃遷移

    在 AI 平台,你只知道「新模型更好」,但不知道它會在哪些任務上「變得太不一樣」。

    對於開發者與 B2B 客戶來說,這意味著:

    你以為自己在買「能力」,實際上買的是「被動追隨某家公司節奏的義務」。


    四、封閉巨頭 + 平台綁定:監管與產業要面對的不是單一公司,而是一種架構

    當 OpenAI、Anthropic、Google 這類實驗室,同時掌握:

    • 封閉式頂級模型(無法自行驗證與複製)
    • API 與代理平台(綁定工作流與開發者習慣)
    • 雲與安全生態聯盟(如 Cloudflare Agent Cloud、GPT-5.4-Cyber 的「可信存取」計畫)

    產業與監管面對的不再是一家公司的壟斷,而是一種結構性的集中:

    1. 算力與資料流向集中

    • 企業為了使用最新模型與代理能力,被迫把內部流程與資料直接接上這些平台。
    • 長期下來,誰掌握這些代理的行為與日誌,誰就掌握產業神經系統。

    2. 監管框架落後於「平台內戰」現實

    • 多數 AI 監管仍聚焦在模型安全、濫用防範(例如 Cyber 模型的「Trusted Access for Cyber」)。
    • 但更棘手的是:當模型與平台綁成一體時,企業幾乎不可能「局部換供應商」。 這會讓任何監管介入,都變成大手術級別風險。

    3. 開放模型與多雲策略會變得更重要,但門檻也更高

    • 開源與半開放模型是唯一能打破平台綁定邏輯的力量,
    • 但在 Spud 這種整合疊代速度下,開源陣營必須不只追性能、還得追「生態配套」——代理框架、工具介面、穩定更新節奏。

    💡 關鍵: 如果只監管「模型多強、多危險」,而忽視「模型如何編排進企業工作流」,監管與產業其實已經在關鍵戰場上缺席。

    Spud 洩密其實是在提醒監管者:如果只盯著「模型多強、多危險」,而不管「模型怎麼被編排進企業工作流」,那場仗已經輸了一半。


    對開發者與使用者的具體建議:從今天開始分散風險

    如果接受「護城河時代已經開始」這個前提,對開發者與企業使用者,建議非常具體:

    1. 假設模型會經常變,而且會打壞東西

    • 在系統設計上,把「模型行為」當成高變動依賴:
    • 用中介層包 API(自己的 SDK / gateway),不要在業務程式碼裡到處直呼官方端點。
    • 針對關鍵任務建立 regression 測試,用固定 prompt + 測試集來監控模型變化。

    2. 刻意做「多供應商設計」,即使一開始只用一家

    • Prompt、tool schema、任務介面,盡量維持與特定平台解耦,在設計時就想像:
    • 同一套任務可以在 OpenAI + Anthropic + 至少一個開源模型上跑。
    • 哪怕短期只上其中一個,這會大幅降低你未來被價格、節奏、政策綁死的風險。

    3. 企業決策層要把「平台依賴」視為治理議題,而不是單純採購選項

    • 在導入 Spud 這樣的新一代模型與代理平台時,董事會層級應該問三個問題:
    • 三年後,我們能否用相對合理成本換供應商?
    • 哪些核心工作流一旦綁進某家平台,就不可能輕易抽離?
    • 我們有沒有至少一套「降級方案」(性能差一點,但不受單一平台控制)?

    Spud 洩密最重要的訊號是:頂級模型供應商已經不滿足於「賣模型」,而是要「改寫整個企業生態的遊戲規則」。 如果開發者與使用者現在不開始設計自己的護城河,之後就只剩兩個選擇:付錢跟著跑,或付更大的代價逃出去。

    🚀 你現在可以做的事

    • 把現有專案的所有 AI 呼叫包進自家中介層(SDK 或 API Gateway),避免在業務碼中直接呼叫單一供應商端點
    • 選一個任務,實作「同一套 prompt / tool schema 能在 OpenAI、Anthropic 與一個開源模型上跑」的多供應商 PoC
    • 在公司內部推一份簡短備忘錄,盤點哪些關鍵工作流一旦綁上某家 AI 平台,三年內幾乎不可能無痛更換
  • AI 黃金時代,其實是算力黑暗時代

    AI 黃金時代,其實是算力黑暗時代

    📌 本文重點

    • 算力荒正重寫整個 AI 產業的權力結構
    • NVIDIA 透過收購與封閉體系強化「AI 稅收權」
    • 開發者需在算力約束下做「夠好又不浪費」的產品

    第一波生成式 AI 熱潮,把注意力都放在「模型多強」,真正決定權力分配的,其實是「誰有算力」以及「誰能把算力用得更省」。所謂 AI 黃金時代,本質上更像是硬體與能源的黑暗時代開端:算力荒正在重寫從晶片、雲端到開發者的遊戲規則。


    一、上游:NVIDIA 在寫的是「稅法」,不是產品路線圖

    NVIDIA 以約 200 億美元收購 Groq,很多人只從技術角度解讀:LPU 架構拿來補 GPU 在推理解碼的短板。但從產業權力角度看,這是一次對「AI 稅收權」的加碼。

    • Groq 3 LPX 這種專攻推理、低延遲的架構,目標就是把 LLM 的推理成本壓到極致,特別是解碼階段的瓶頸。
    • 收購後,NVIDIA 不只是多了一條產品線,而是把「訓練(GPU)+ 推理(LPU/專用加速)」綁成一個封閉體系,從雲端供應商到模型公司都更難脫鉤。

    這件事的關鍵,不在於 LPU 性能多漂亮,而在於:

    1. 算力短缺把議價權推到供應鏈頂端。當 GPU 二手價格可以如 The Decoder 報導般在一年內跳升近 50%,任何能把「每 Token 成本」壓低的硬體,都直接決定誰能活下來。
    2. NVIDIA 不是怕別人做得更強,而是怕有人做得「夠好又便宜」。收購 Groq,是把潛在的成本破壞者直接納入自己的價格體系。

    💡 關鍵: 當 GPU 二手價一年內漲近 50%,任何降低每 Token 成本的方案都直接變成生死線上的競爭力

    在算力荒的世界裡,晶片廠不再只是賣鏟子的人,而是收過路費的稅官。Groq 被收購,傳遞的訊號是:真正的競爭不在頂峰模型的極限效能,而在「規模化推理」這個現金牛誰來控盤。


    二、中游:模型公司在做的,其實是算力通膨的成本轉嫁

    算力荒最直接的血淋淋場景,現在就出現在 OpenAI、Anthropic 這一層。

    • The Decoder 指出,Anthropic 近期多次服務中斷,外面看是「可靠性問題」,本質上是算力配給:資源要優先保證付費大客戶,免費與低價層就得排隊、降頻。
    • OpenAI 終止 Sora 平台,表面原因可以包裝成策略調整,背後是影音生成的算力成本極高,在 GPU 價格飆漲、推理運行越來越貴的環境下,很難長期開放供「玩」。

    你會看到幾個高度一致的動作:

    1. 限流、排隊、優先企業客戶:不是技術不行,而是 GPU 帳算不攏。
    2. 硬塞 cache、偷改模型規格:從系統層面做 aggressive caching、把體感維持在「還可以」但實際上降低 Token、壓縮上下文,都是為了在算力通膨下維持毛利。
    3. 悄悄砍或降級產品:把最燒算力的玩具級功能下架,或只留給特定付費方案。

    這些行為有一個共同邏輯:當每一次推理都比去年更貴,模型公司就只能把成本往下游砍——要嘛漲價(明顯),要嘛降配(隱性)。所以我們才會看到:

    • 模型能力曲線繼續上升(斯坦福 2026 AI Index 指出頂尖模型仍持續快速進步),
    • 但實際可用的、可負擔的服務體驗,並沒有同比例改善——很多人甚至覺得「越用越慢、越容易掛」。

    💡 關鍵: 技術指標在進步,但使用體驗停滯甚至變差,原因是算力成本的通膨被隱性轉嫁到下游

    換句話說,雖然是黃金模型時代,卻是算力通膨時代。中游玩家被迫扮演「算力通膨的分銷商」,把壓力一路轉嫁到企業客戶與開發者身上。


    三、下游:AI 不再是「無限雲服務」,而是稀缺資源管理

    當上游悶燒、中游限流,真正被迫改變架構思維的,是最下游的 開發者與企業。

    幾個現在就看得到的方向:

    1. 「少量雲端 + 本地/小模型」成為新常態
      Reddit 上那台雙 RTX PRO 6000 (共 192GB VRAM) 的塔機,不只是炫富,它反映一件事:算力貴到一個程度後,中大型團隊開始用 CapEx 把部份推理買回本地,自己控風險、控成本。
    2. 雲:用在高價值、必須大模型的場景(少數關鍵任務、需要最新能力的部分)。
    3. 本地/邊緣:大量日常推理、小模型、隱私敏感工作負載。

    4. 模型不再追「最大」,而是追「剛好夠用」
      以往的預設是:有錢就上最大模型。算力荒之後,合理的策略變成:

    5. 80% 請求用 壓縮後的小模型或量化模型 處理;
    6. 20% 真的複雜或高價值請求,才丟給雲端 SOTA 模型。
      能用 7B 模型就不用 70B,能本地就不遠端。

    7. 架構從「無限擴展」轉向「算力配額」思維
      開發 SaaS 時,傳統做法是假設雲資源可以線性加錢擴展。現在不行了:

    8. GPU 本身缺貨、價格暴漲;
    9. 雲端供應商開始對高密度推理 workload 做更嚴格的限制或差別定價。

    這迫使團隊把算力當成 預算內有限資產,導入像是:
    – per-feature 的算力成本試算,
    – 針對不同客戶等級設計不同推理規格,
    – 對內建立「算力 KPI」而不只是 DAU/收入 KPI。

    甚至連最前沿的 軌道運算 都開始出現。TechCrunch 報導 Kepler Communications 把 40 張 GPU 送上地球軌道,本質上是:地面機房越來越貴、越來越難建之後,任何能換一種空間、能源結構取得算力的方案都會被認真看待。這不是科幻,而是供給曲線被壓扁後的必然結果。


    四、算力已經是國安與能源議題,不只是商業問題

    2026 AI Index 的幾組數字,值得冷靜看:

    • 全球 AI 資料中心耗能已達近 30 吉瓦,等同一個 紐約州尖峰用電量。
    • 單一頂尖模型(如 GPT-4)的訓練與運行周期,可能就消耗相當於 超過 1200 萬人口的飲用水量。
    • 美國擁有 5,427 個數據中心,是其他國家的十倍以上;主流 AI 晶片製造則高度依賴 台積電 (TSMC)。

    💡 關鍵: 算力其實是把電與水轉成模型能力,能源與供應鏈集中讓 AI 直接變成國安議題

    這幾件事疊在一起,得到的結論是:

    1. 算力本質上是能源轉換問題。AI 每進步一點,都是在往電網和水資源要配額。政策討論不再只是「AI 會不會搶工作」,而是「要不要讓某個州多蓋幾個資料中心」。
    2. 供應鏈集中 = 地緣風險集中。當先進製程幾乎綁死在 TSMC,又以美國為核心消化,任何地緣事件都會直接反映在全球 AI 算力供應上——不是抽象風險,而是「下個季度 GPU 交不交得出來」的問題。

    這就是為什麼各國開始談「算力主權」:自己要有一部分可控的硬體、能源與演算法堆疊,不然政策與國安討論都只能在別人定價的前提下進行。


    結論:未來兩年的真正護城河——不是最強,而是「夠好又不浪費」

    在算力荒與算力通膨同時發生的年代,未來兩年的真正護城河,不再是誰的模型略強,而是誰能在算力約束下,做出「夠好但不浪費」的產品與基礎設施。

    對開發者與產品團隊,具體建議是:

    1. 從追新模型,轉向追「算力效率」
    2. 把「每一元雲端帳單換到的實際體驗提升」當主指標。
    3. 主動學會量化、蒸餾、多模型路由(小模型打底,大模型兜底)。

    4. 預設採用多雲 / 本地混合策略

    5. 關鍵資料與高頻推理,盡可能用自建或託管的本地 GPU(哪怕只是小型機櫃)。
    6. 把雲端視為「能力超額保險」,而不是每一個請求的預設去處。

    7. 把算力納入產品設計早期,而不是最後才算成本

    8. 功能規劃時就先問:「這個 feature 的推理成本是什麼級別?有沒有更省算力的替代設計?」
    9. 為不同客戶層級定義不同算力配額與模型等級,而不是一體適用。

    誰能在限制條件下設計出體驗「夠好」、算力「夠省」、架構「夠彈性」的系統,誰就會在這場算力黑暗時代裡活得最久,也最有餘裕等到下一輪真正的技術紅利。

    🚀 你現在可以做的事

    • 盤點現有產品中每個 AI 功能的推理成本,標記哪些可以改用小模型或量化模型
    • 試著在一台本地 GPU 機器上部署一個 7B 模型,實測與雲端大模型的體驗與成本差異
    • 在下次產品規劃會議中,加上一欄「算力預算 / 模型等級」,讓功能設計一開始就納入算力約束
  • 一行指令接上多模態 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 analyze 或 video 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 text 或 mmx 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 範例

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

    • 如果你完全沒寫過程式 → 先看標題含有 conversation、prompting 的 Notebook,當成「高級版提示語模板」,直接複製到 Claude 網頁版使用。
    • 如果你會一點 Python → 跑 basic_examples 裡的 Notebook,先確認你能成功打出第一個 API 回應。
    • 如果你想做內部工具或 Agent → 從 tools_and_workflows、rag 開始,把範例裡的「假資料」換成你公司的文件或 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 打開對照看,很快就能理解 messages、tools 等欄位用法。

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

    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.txt 或 pyproject.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 版本