Kerwin AI Information

分類: AI 工具

  • TrendRadar：一句話問清今天網路在吵什麼

    TrendRadar：一句話問清今天網路在吵什麼

    📌 本文重點

    • TrendRadar 幫你每天自動整理「值得在意的事」
    • 透過多平台聚合 + AI 翻譯與情感分析過濾雜訊
    • 可與 ChatGPT/Claude 分工整合，從監控到決策一條龍
    • 開源專案，支援 Docker 快速自架部署

    每天打開社群、新聞、論壇一堆訊息轟炸，TrendRadar 的用途只有一個：幫你先把「今天值得在意的事」整理好，讓你用一句話就能問清楚今天網路在吵什麼。

    專案連結：https://github.com/sansan0/TrendRadar

    核心功能：把資訊過濾、翻譯、分析到位

    1. 多平台聚合：RSS + 關鍵字一次收攏

    TrendRadar 的第一步，就是幫你「收集」：

    • 支援 RSS 訂閱：新聞網站、部落格、論壇，只要有 RSS 都能加
    • 支援多平台來源：可以接常見內容源（Twitter/X、Telegram 頻道、各類資訊流等，具體依你配置的 RSS 和接口而定）
    • 關鍵字篩選：只保留跟你在意的議題相關的內容

    你可以這樣實際操作：

    1. 列出你真的在乎的 3–5 個主題：
    2. 例：品牌名稱、競品名稱、關鍵技術（LLM、RAG）、產業關鍵詞（電商、SaaS、生成式 AI）
    3. 找到對應的 RSS 或資訊源：
    4. 媒體：TechCrunch、36kr、Inside、數位時代等
    5. 技術：Hacker News、Product Hunt、GitHub Trending
    6. 在 TrendRadar 的設定檔中，把 RSS URL 和關鍵字寫進去（下文有具體步驟）。

    💡 關鍵： 先選好 3–5 個核心主題，再讓系統自動過濾，能最大幅度減少你每天要處理的雜訊量。

    效果：每天系統自動幫你從海量資訊中，先過一輪「話題相關性」的篩選，你只看自己訂的幾條線。

    2. AI 翻譯 + 情感分析：跨語言、看氣氛

    TrendRadar 不是只推原文連結，而是會先用內建的 AI 分析：

    • 自動翻譯：把英文、日文等新聞翻成中文摘要
    • 情感分析：判斷內容情緒（正面 / 負面 / 中性）
    • 概要整理：用幾句話抓出重點

    具體可以怎麼用：

    • 品牌輿情：
    • 快速看今天關於你品牌的討論是偏正面還是負面
    • 先看 AI 摘要，再決定要不要點進原文細讀
    • 技術動態：
    • GitHub Trending 上出現的新專案，先用中文看懂做什麼
    • 挑出「跟你技術棧有關」且熱度在上升的專案

    實際行動：

    1. 在 TrendRadar 設定好要做情感分析的關鍵字（例如你的品牌名、產品名）。
    2. 啟用 AI 翻譯與摘要（專案中已預設支持，依 README 配好 API Key 或本地模型）。
    3. 每天在通訊工具裡看一眼「今日摘要」，不用再一篇篇翻。

    3. 多通訊工具推送 + MCP：變成你自己的「輿情機器人」

    TrendRadar 支援把整理過的結果，推送到你已經在用的工具：

    • 微信
    • 飛書
    • 釘釋
    • Telegram
    • Slack
    • Email / ntfy / Bark 等

    你可以把它當成一個「只會講重點的資訊機器人」，每天固定時間或有關鍵事件時推播給你。

    更關鍵的是：TrendRadar 支援 MCP（Model Context Protocol），可以讓它和你現有的 AI 助手（例如 ChatGPT、Claude）整合：

    • TrendRadar 負責：收集、過濾、打標（情感、主題）
    • ChatGPT/Claude 負責：深度分析、寫彙整報告、產生回應草稿

    實際可做的 workflow：

    1. TrendRadar 把今天跟品牌相關的負面事件整理成一份 JSON / 簡報式摘要。
    2. 在支援 MCP 的 AI 助手中，呼叫 TrendRadar 工具：「請分析今天的負面輿情，幫我寫一份回應策略與 Q&A 草稿」。
    3. 得到可以直接丟給 PR 團隊修改的版本。

    💡 關鍵： 讓 TrendRadar 負責「聽與記錄」，AI 助手負責「想與表達」，能把你每天需要親自處理的工作壓到最低。

    適合誰用？三個具體場景

    1. 品牌輿情追蹤：先知道「今天有沒有燒起來」

    角色：行銷、公關、品牌經理。

    設定方式：

    • 關鍵字：品牌名、CEO 名字、產品名、常見錯別字
    • 來源：
    • 新聞 RSS（產業媒體 + 大眾媒體）
    • 論壇 / 社群聚合 RSS（若有）
    • 推送頻率：
    • 每天早上 9 點彙總
    • 一有高負面情感的內容就即時推送

    日常用法：

    • 在 Slack/微信 建一個 #brand-alert 群組，只放 TrendRadar。
    • 每天固定看一眼，看今天有沒有需要回應的聲音。
    • 把其中幾則交給 ChatGPT：
    • 「請用溫和但不卑不亢的語氣，回覆這篇負面評論，給出三種版本。」

    2. 競品 / 技術趨勢監控：避開資訊焦慮，只看真正相關的

    角色：產品經理、技術主管、創業者。

    設定方式：

    • 關鍵字：
    • 競品名稱 + 公司名
    • 技術關鍵字（如 RAG、vector DB、serverless LLM）
    • 來源：
    • GitHub Trending（配合關鍵字過濾）
    • Product Hunt / Hacker News
    • 主要技術媒體 RSS

    日常用法：

    • 每天收到一份「競品 / 新技術」摘要：
    • 新發佈的功能 / 產品
    • 高熱度技術文章 / 專案
    • 再把摘要丟給 Claude：
    • 「整理成 5 點，說明這些變化對我們產品路線的影響，按緊急程度排序。」

    3. 內容創作者：每日素材雷達

    角色：寫 newsletter、拍 YouTube、寫部落格或社群的人。

    設定方式：

    • 關鍵字：
    • 你頻道聚焦的主題（AI 工具、遠端工作、投資、行銷等）
    • 來源：
    • 國外媒體 RSS
    • Twitter/X 清單轉 RSS（或間接服務）
    • 技術 / 產業部落格

    日常用法：

    • 每天早上收一份「今日 10 則值得寫的素材」，每則附：
    • 中文重點摘要
    • 推估情緒（這件事觀眾會興奮、焦慮、好奇？）
    • 把其中 1–2 則交給 ChatGPT：
    • 「幫我把這則趨勢寫成 5 條適合 IG / 小紅書的貼文金句。」

    TrendRadar + ChatGPT/Claude：兩工具分工實戰

    名稱 核心功能 免費方案 適合誰
    TrendRadar 多平台聚合、輿情監控、AI 摘要 開源，自架即免費 要持續監控品牌、競品、技術的人
    ChatGPT / Claude 深度分析、寫作、策略思考 有免費/試用方案 要把資訊變成企劃、回應、內容的人

    建議分工：

    • TrendRadar：
    • 24 小時自動收集與過濾
    • 做第一層翻譯、情感分析、摘要
    • ChatGPT/Claude：
    • 根據 TrendRadar 產出的內容，做二次加工
    • 產生 PR 草稿、簡報大綱、內容腳本

    操作示例：

    1. 在 Slack 接收 TrendRadar 的每日報告。
    2. 把報告內容複製到 ChatGPT：
    3. 指令範例：「請依照這份 TrendRadar 摘要，幫我生成一頁簡報的大綱，分成『今天發生什麼』『為何重要』『我們該怎麼做』。」

    怎麼開始：用 Docker 快速拉起 TrendRadar

    TrendRadar 是開源專案，支援 Docker 部署，你可以在本機或雲端（例如自家伺服器、雲主機）跑起來。

    1. 基本前置：準備環境

    必備條件：

    • 已安裝 Docker（和 docker-compose，如果專案使用）
    • 一台可以長時間運作的機器（本機、NAS 或雲主機都可）

    實際行動：

    • 安裝 Docker：
    • macOS / Windows：安裝 Docker Desktop
    • Linux：依發行版安裝（Ubuntu 可用 apt install docker.io 等）

    2. 拉取專案並啟動服務

    以下為通用步驟，具體以官方 README 為準（https://github.com/sansan0/TrendRadar）：

    # 1. 取得程式碼
git clone https://github.com/sansan0/TrendRadar.git
cd TrendRadar

# 2. 建立環境設定（通常會有 .env.example 或 config 檔）
cp .env.example .env
# 編輯 .env，填入必要的 API Key（如翻譯 / LLM 模型）

# 3. 使用 Docker 啟動
docker compose up -d

    啟動後，可以依 README 提供的網址（通常是 http://localhost:xxxx）打開管理介面或 API。

    💡 關鍵： 利用 Docker 一次配置好環境，之後只需重啟服務即可持續運作與更新。

    3. 設定第一組關鍵字與訂閱來源

    實際配置方式會依專案版本稍有差異，大致流程如下：

    1. 打開 TrendRadar 設定頁或編輯配置檔（例如 config.yaml）：
    2. 新增一個「監控主題」（如 brand_watch、ai_trend）。
    3. 在主題下設定：
      • keywords: 你要追的關鍵字列表
      • sources: RSS 或其他來源 URL 列表
    4. 設定推送渠道：
    5. 在設定檔中填入 Slack Webhook URL、Telegram bot token 或微信/飛書機器人配置。
    6. 指定這個主題要推送到哪個渠道、頻率（例如每 6 小時一次）。
    7. 重新啟動或重新載入配置：
    docker compose restart

    檢查：等 10–30 分鐘，看通訊工具裡是否開始收到 TrendRadar 的摘要訊息。

    用一句話開始：把 TrendRadar 當成你的「每日第一問」

    當 TrendRadar 跑起來之後，你可以把每天的第一件事，改成問 AI：

    「根據 TrendRadar 的資料，今天跟我品牌 / 產業最有關的三件事是什麼？幫我說給非技術同事聽。」

    TrendRadar 負責幫你把訊息世界「縮小成可理解的摘要」，再交給 ChatGPT 或 Claude 做深度分析，你只要把最後的洞察做決策、做內容，就能在資訊過載的世界裡，保留大腦給真正重要的事情。

    🚀 你現在可以做的事

    • 開啟 TrendRadar 專案頁：https://github.com/sansan0/TrendRadar，照 README 在本機用 Docker 跑起來
    • 列出你最在意的 3–5 個主題，設定第一組 keywords 和 RSS sources 做實驗
    • 在常用通訊工具（Slack、微信等）建立一個專用頻道，把 TrendRadar 摘要接進來，明天早上開始用它看「今天在吵什麼」
  • 用 Vercel Skills 把 AI 變成你的命令列工具箱

    用 Vercel Skills 把 AI 變成你的命令列工具箱

    📌 本文重點

    • Vercel Skills 把 AI Agent 打包成可安裝的 CLI 工具
    • 一行 npx skills 就能體驗預設技能並接到自動化流程
    • 每個 skill 可在不同專案與 CI/CD 中重複使用與串聯
    • 適合開發者、行銷、DevOps 做文字與流程自動化

    用一句話說清楚：Vercel Skills 讓你用一行 npx skills，把一整包 AI Agent 當成可安裝的命令列工具，快速接到你的開發與自動化流程裡。

    專案連結：vercel-labs/skills on GitHub

    核心功能：把「AI 能力」做成可重用的 Skill 模組

    1. 一行指令啟動預設技能：npx skills

    想先感受效果，不想碰程式碼，可以直接這樣做：

    npx skills@latest

    執行後會：

    • 問你要使用哪些預設技能（例如：文件總結、PR 說明、自動整理 issue 等）
    • 在終端機互動式詢問你輸入內容或指定檔案
    • 把 AI 結果輸出在終端機，必要時也會幫你生成檔案

    你可以把它當成「AI 強化版 CLI 工具集」，用一次就知道哪些任務適合被 AI 自動化。

    💡 關鍵： 一行 npx skills@latest 就能體驗整套預設 AI 技能，是評估哪些工作可以自動化的最快方式。

    2. 每個 skill 就是一個可複用的 Agent 模組

    在 Skills 的設計裡：

    • 一個 skill = 一件具體可自動化的工作
    • 例如：summarize-doc（總結文件）、pr-description（產生 PR 描述）、rewrite-copy（改寫文案）
    • 實作上：一個 skill 就是一個 TypeScript/Node.js 模組，負責：
    • 接收輸入（檔案路徑、文字、Git diff 等）
    • 呼叫 LLM（預設走 Vercel AI SDK，可接 OpenAI / Vercel 等）
    • 回傳結構化結果（可以寫回檔案、回傳 JSON、或印在 CLI）

    這種設計的好處是：

    • 你可以在不同專案重複使用同一個 skill
    • 一個專案裡可以組合多個 skill 變成「串聯流程」（例如：先用一個 skill 擷取重點，再用另一個 skill 生成測試案例）

    💡 關鍵： 把每個任務抽象成 skill 模組後，你可以在多個專案與流程中重複組裝同一套 AI 邏輯，維護成本更低。

    3. 兩種使用方式：CLI 與程式內呼叫

    你可以把 Skills 當成：

    1. 命令列工具（CLI）：適合快速手動使用、寫腳本

    2. 例如：
      bash
      # 執行某個 skill
      npx skills run summarize-doc ./docs/api.md

    3. 程式內呼叫（Node.js / TypeScript）：適合接到 CI/CD、背景工作、Bot

    4. 基本結構類似：
      “`ts
      import { runSkill } from “skills”;

      const result = await runSkill(“summarize-doc”, {
      path: “./docs/api.md”,
      });

      console.log(result.summary);
      “`

    這讓 Skills 不只是一個「玩具 CLI」，而是可以被真正嵌入系統裡的 AI 自動化模組。

    💡 關鍵： 同一個 skill 既能在 CLI 使用，也能在程式碼中透過 runSkill 呼叫，降低從實驗到正式上線的落差。

    適合誰用：幾個具體場景

    1. 開發者：減少重複性的開發瑣事

    可以嘗試這幾類 skill：

    • 自動產出 PR 描述
    • CI 裡加入：檢查 PR 的 diff，用 skill 生成清楚的變更說明
    • 好處：大家不再花時間想描述格式，Reviewer 一眼看完重點
    • 整理 issue / ticket
    • 拉取標題 + 描述，讓 skill 自動標記類型、估計複雜度、抽出待辦項目
    • 好處：產品、工程、PM 都看到一致結構的內容
    • 生成測試案例
    • 針對關鍵函式或 API 定義，讓 skill 幫你列出可能的測試情境
    • 再由你挑選重要的手動補完

    可以做的行動：

    • 先用 npx skills 跑一輪預設技能
    • 想想你專案裡最常被抱怨「麻煩但又必須做」的步驟，選 1 個先做成 skill

    2. 內容與行銷：批次改寫與整理文字

    如果你常做這些事，Skills 很適合：

    • 批次改寫文案
    • 輸入一批產品描述，統一改寫成：短版、長版、社群貼文版
    • 可以客製 skill：輸入 CSV / JSON，輸出同格式檔案
    • 整理長文件摘要
    • 對內部文件（產品規格、研究報告）做摘要 + 重點 bullet points
    • 適合接到定時腳本：每天把新文件丟給 skill，產出摘要寄到 Slack

    可以做的行動：

    • 先準備一個資料夾，放你常用的範本文案或長文
    • 用 npx skills 裡的 summary / rewrite 類 skill 試一次，感受輸出品質

    3. DevOps / 自動化工程師：接到 CI/CD、排程腳本

    你可以把 Skills 當成「AI 版 shell script 函式庫」：

    • 在 GitHub Actions 或 GitLab CI 裡：
    • Pull Request 建立時自動跑 npx skills run pr-description
    • Release 前跑一次 npx skills run summarize-changelog 整理修改內容
    • 在 cron / 定時腳本 裡：
    • 每天抓 issue / log / 監控報表丟給某個 skill，整理成一份人類可讀的摘要

    可以做的行動：

    • 在現有 CI pipeline 裡挑一個步驟，加一個額外 job 試跑 Skills
    • 先只在非必要流程執行，觀察穩定度與輸出品質

    怎麼開始：從預設技能到自訂 skill

    1. 安裝與首次執行

    前置需求：

    • Node.js（建議 18+）
    • 一個可用的 LLM API（例如 OpenAI 或 Vercel AI）

    第一步：直接執行 CLI（免全域安裝）：

    npx skills@latest

    依照互動式提示：

    1. 選擇或設定你的模型提供者（可能會要求設定 API key）
    2. 選擇一個想先試的 skill（例如 summarize / pr-description）
    3. 依照提示輸入文字、選檔或指定路徑

    這一步的目標：先確認環境 OK + 大概知道 skill 的輸出長什麼樣子。

    2. 看一個最簡單自訂 skill 的程式結構

    接下來你可以把專案 clone 下來：

    git clone https://github.com/vercel-labs/skills.git
cd skills
pnpm install # 或 npm / yarn

    假設你要做一個最簡單的「文案改寫」 skill，概念結構會像這樣（簡化示意）：

    // ./skills/rewrite-copy/index.ts
import { defineSkill } from "skills";
import { generateText } from "ai-sdk"; // 具體以官方範例為準

export default defineSkill({
  name: "rewrite-copy",
  description: "改寫一段文案，維持原意但更口語/正式。",
  inputs: {
    text: {
      type: "string",
      description: "要改寫的原始文案",
      required: true,
    },
    tone: {
      type: "string",
      description: "語氣：casual 或 formal",
      default: "casual",
    },
  },
  async run({ inputs, model }) {
    const prompt = `請用${inputs.tone} 語氣改寫以下文案，但保留原本資訊：\n\n${inputs.text}`;

    const result = await generateText({
      model,
      prompt,
    });

    return {
      rewritten: result.text,
    };
  },
});

    接著，你可以在本地 CLI 裡直接呼叫：

    npx skills run rewrite-copy --text "原始文案內容" --tone casual

    這就是 Skills 的基本模式：

    1. 用 defineSkill 宣告輸入/輸出與執行邏輯
    2. 在 run 裡呼叫你喜歡的模型
    3. 回傳一個乾淨的結果物件，方便 CLI 或其他程式接

    3. 在你的專案裡以 API / CLI 串接

    有兩種常見方式：

    方式 A：在 CI / script 裡用 CLI

    以 GitHub Actions 為例，在 .github/workflows/pr-description.yml 加上：

    jobs:
  generate-pr-description:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npx skills@latest run pr-description --diff "$(git diff origin/main)"
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}

    這樣每次開 PR 就會自動產生一段描述，印在 log 或寫到你指定的地方。

    方式 B：在 Node.js 應用程式裡呼叫

    在你自己的專案中安裝：

    npm install skills

    然後在程式裡：

    import { runSkill } from "skills";

async function summarizeDoc(path: string) {
  const result = await runSkill("summarize-doc", { path });
  return result.summary;
}

    接著你可以：

    • 在後端 API 提供 /summaries endpoint
    • 在排程腳本裡定時呼叫
    • 在 Slack Bot 裡接指令呼叫

    把 Skills 放進你的「AI 自動化工具箱」的建議做法

    建議一日內可以完成的小目標：

    1. 先用 npx skills 跑三個預設技能：文件摘要、PR 描述、文案改寫
    2. 挑一個你每天都會做、卻很耗時間的文字相關工作，寫成一個最小版 skill
    3. 在你現在的 CI 或本地腳本裡，接入這個 skill（先只給自己用）
    4. 一週後觀察：
    5. 節省了哪些手動步驟？
    6. 哪些輸出需要調 prompt 或加後處理？

    只要跑完這一輪，你就等於有了一個可持續擴充的「AI 自動化工具箱」，之後每多一個 skill，就是少一個你自己要反覆做的瑣事。

    專案連結再附一次：https://github.com/vercel-labs/skills

    想像一下：未來你新增工具，不是寫一串 shell script，而是新增一個 skill，讓 AI 幫你處理掉更多「人做很累、AI 卻很擅長」的工作。

    🚀 你現在可以做的事

    • 在本機直接執行 npx skills@latest，跑一輪預設技能體驗輸出
    • git clone 官方專案並閱讀 skills 目錄下的範例，試著複製一個改成自己的 skill
    • 在一個現有 CI pipeline（如 GitHub Actions）中，加上一個使用 npx skills run pr-description 的非關鍵實驗步驟
  • 把 VS Code 變成自動寫程式助手：cline 實戰

    把 VS Code 變成自動寫程式助手：cline 實戰

    📌 本文重點

    • cline 是裝在 VS Code 裡的自主程式碼 Agent
    • 可批次改檔、跑指令、查文件，但每步都需授權
    • 搭配版本控制與測試，可成為安全的半自動 pair programmer

    cline 要解決的問題很直接：讓一個「在你本機 IDE 裡跑的自主程式碼 Agent」，幫你改檔、跑指令、查文件，但所有動作都要你按下同意鍵才會執行。

    專案連結：github.com/cline/cline

    cline 是什麼？一句話定位

    cline = 安裝在 VS Code 裡的自主程式碼 Agent，可以：

    • 建立 / 編輯專案檔案
    • 執行終端機指令（build、test、lint 等）
    • 啟動瀏覽器幫你查文件
    • 但每一步都會先列出具體操作，等你按「允許」才真的動手

    它的定位不是「幫你寫一個函式就結束」的 Copilot，而是能帶著你一步步完成一個功能或重構任務的半自動 pair programmer。

    核心功能：它到底能幹嘛？

    1. 批次改檔、搭 scaffold

    適合情境：

    • 重構一個舊專案，把同樣的 pattern 套到多個檔案
    • 快速搭一個新專案的骨架（資料夾結構、基本檔案）

    你可以這樣用：

    1. 在 VS Code 裡打開專案資料夾。
    2. 開啟 cline 面板，輸入指令，例如：

      幫我把 src/ 底下所有 React class component 改成 function component，並保留原本 props 型別。

    3. cline 會：
    4. 先掃專案，列出會動到的檔案
    5. 給你一份「變更計畫」與 diff 預覽
    6. 每個檔案修改前都問你要不要執行

    效果：一次性重構多個檔案，但仍保留「你是 code review 者」的掌控感。

    💡 關鍵： 用 cline 做批次重構時，每個變更都先 review，再執行，可以同時兼顧效率與安全。

    2. 查 bug、跑測試、看 log

    適合情境：

    • 接手別人寫的遺留專案
    • 單元測試一堆紅字懶得一個個追

    操作步驟：

    1. 把錯誤訊息貼給 cline，例如：

      Jest 測試 UserService 全掛了，請找出原因並修正。

    2. cline 會：
    3. 根據錯誤訊息定位到相關檔案
    4. 提出一個修正方案（含預計修改的檔案列表）
    5. 要你確認後才修改
    6. 自動幫你呼叫 npm test 或 pnpm test，再讀測試結果

    你可以要求它：

    每一次修正只改一小步，測試通過後再進下一步。

    這樣你就得到一個測試驅動的 AI 助手，不會一次改爆整個 codebase。

    3. 幫你查文件、Google / Docs 查詢

    cline 內建「用瀏覽器查資料」的能力（具體依你設定的模型與工具支援而定），常見用法：

    • 不熟的框架 API
    • 某個 CLI 旗標
    • 某個錯誤碼

    例子：

    有一段 webpack 設定報 deprecated 警告，請幫我找到官方文件，並提供對應的 config 調整建議，改動前先給我 diff。

    cline 會：

    1. 打開瀏覽器工具查官方文件
    2. 摘要關鍵片段
    3. 提出「建議改法 + diff」
    4. 再次問你要不要套用

    關鍵點：所有網頁行為和檔案修改，都會顯示在面板上，必須經你同意。

    安全設計：每一步都要你確認

    agent 工具最怕兩件事：

    • 誤刪 / 誤改檔案
    • 執行奇怪的 shell 指令

    cline 的設計剛好反過來：

    • 每次改檔會顯示 diff，你可以逐行檢查
    • 每次跑指令會顯示 完整命令，例如 rm -rf 這種你一看就會擋
    • 每次讀/寫新檔案，會明確說明路徑

    使用時務必做到：

    • 只把權限給當前專案資料夾
    • 不要在有機敏資料（憑證、prod config）的 repo 直接放手讓它改
    • 先在一個「測試用 repo」練習上述流程

    💡 關鍵： 把 cline 當成需要你簽名才能動手的助手，用「授權前必看 diff / 指令」這個習慣來降低風險。

    適合誰用？三種常見場景

    1. 中小專案重構 / 遺留專案接手

    典型痛點：

    • 接手一個 1–3 年歷史的 Node / Django 專案
    • 設計不統一，命名風格混亂
    • 文件過時

    cline 可以幫你：

    • 產生一份「現有結構地圖」：掃描目錄，生成 docs/ARCHITECTURE.md
    • 逐步統一命名規則（例如全部改用 camelCase）
    • 把散落在 code 的註解整理成文件

    行動建議：

    1. 開一個新 branch（例如 refactor/with-cline）。
    2. 讓 cline 先生成「重構計畫」，內容包含：
    3. 優先修哪些模組
    4. 預計拆出哪些共用函式
    5. 需要補哪些測試
    6. 你確認計畫後，再讓它照計畫一項項執行。

    2. 日常重複開發工作

    常見重複工作：

    • 每次新專案都要搭一套相同骨架
    • CRUD api 的樣板重複貼
    • 測試檔案格式一樣，只是名字和 case 不同

    cline 的價值在於：

    • 把這些「手很痠的工作」變成一段腳本
    • 你只要給它「任務描述 + 確認」，不用自己一檔檔複製

    建議做法：

    • 為你的團隊定義一份「標準專案骨架」描述，像：

      對新的 React 專案：使用 Vite、設定 ESLint + Prettier、建立 src/components, src/hooks, src/pages 目錄，並生成基本範例檔案。

    • 之後每一次開新 repo 直接把這段 prompt 丟給 cline，讓它自動完成。

    3. 半自動 pair programming（搭配本地 / 雲端模型）

    在 Reddit 上有不少人分享，把本地模型（例如 Qwen3.6 35B）搭配 agent 框架（如 little-coder、PI Coding Agent），透過「plan-first」工作流，讓本地模型在 Polyglot benchmark 上接近雲端模型表現。

    參考：
    – Qwen3.6-35B + little-coder 實測
    – PI Coding Agent + Qwen3.6 35B 實戰心得

    cline 做的是類似事情：

    • 把「計畫 → 分解任務 → 執行」這套流程搬進 IDE
    • 你可以接雲端模型（例如 Claude、OpenAI），也可以接本地模型（透過 OpenAI 相容 API）

    這樣你得到的是一個永遠不搶鍵盤、每步先跟你報告的 pair programmer。

    跟其他 VS Code Agent 工具怎麼選？

    名稱 核心功能 免費方案 適合誰
    cline (GitHub) 單一自主程式碼 Agent，內建檔案操作、終端機、瀏覽器，強調「每步需授權」 工具本身開源；需自備模型 API（金鑰可用免費額度） 想要在現有 VS Code 工作流中加一個安全的半自動助手
    Roo Code (GitHub) 多 Agent 協作，模擬「一整個開發團隊」，支援自動化測試、部署 開源；同樣需自備模型 API 想要嘗試多代理協作、較複雜工作流的進階使用者
    claude-context (GitHub) 把整個 codebase 變成 Claude 的上下文（MCP 工具） 開源；需有 Claude 帳號 重度使用 Claude Code，希望提升大專案上下文理解的人

    如果你只是想讓自己的 IDE 多一個「會聽話的 AI 助手」，cline 的上手成本最低。

    💡 關鍵： 已有模型 API 的使用者，只要裝好 cline，就能用很低成本把 IDE 升級成具備自主能力的開發環境。

    怎麼開始？最快上手路徑

    步驟一：安裝 cline

    最簡單方式是從 VS Code Extension 安裝：

    1. 打開 VS Code 的 Extensions 面板。
    2. 搜尋 cline，作者為 cline。
    3. 點選 Install。

    也可以從 GitHub 直接找到相關安裝說明：https://github.com/cline/cline

    （若未來提供 npm/CLI 版本，可以在 README 看到詳細指引。）

    步驟二：連接你的模型 API

    cline 不自帶模型，你需要自己準備一個：

    常見選項：

    • Claude（Anthropic）
    • OpenAI
    • 本地模型（透過 OpenAI 相容 API，如 Ollama、自架伺服器）

    設定方式（概念流程）：

    1. 在 cline 設定面板填入：
    2. API Base URL（例如 https://api.openai.com/v1 或你的本地 endpoint）
    3. API Key
    4. 模型名稱（例如 gpt-4.1、claude-3.5、或你自訂的本地模型名）
    5. 測試一個簡單 prompt：

      嗨，幫我列出這個專案的主要資料夾結構。

    6. 確認能讀到檔案與回覆，表示連線成功。

    步驟三：直接可用的「plan-first」工作流程 Prompt

    下面這段可以直接複製，當成你和 cline 的標準開場白，每次要做較大的變更都先貼一次：

    你是一個在 VS Code 裡運行的程式碼 Agent，請嚴格遵守以下工作流程：

1. 先閱讀專案的主要檔案與目錄，理解目前架構。
2. 針對我提出的需求，先幫我：
   - 列出最多 5 個澄清問題（如果有疑慮）。
   - 擬一份分步計畫（Step 1, Step 2...），每步不超過 2–3 個具體修改。
3. 把這份計畫寫成 `TODO.md` 放在專案根目錄，內容包含：
   - 任務描述
   - 預計修改檔案清單
   - 預計需要執行的指令（例如 test、build）。
4. 在我明確回覆「同意計畫」之前，不要修改任何程式碼。
5. 執行時：
   - 每次只完成 `TODO.md` 中的一個步驟。
   - 修改前先顯示預期變更與影響檔案。
   - 修改後自動幫我執行對應測試指令（若有），並總結結果。
6. 任務結束後，更新 `TODO.md`（標記完成項目），並用要點方式總結你做了什麼。

請先確認你理解上述流程，然後問我：這次要你幫忙的任務是什麼？

    有了這個「plan-first」腳本，你可以避免 Agent 一上來就亂改，先把計畫談好再動手。

    風險控管與實務建議

    最後幾個實際上很重要、但容易被忽略的點：

    • 權限只開專案資料夾：不要在整個 ~/ 或公司共用資料夾上跑；只針對單一 repo。
    • 先在測試 repo 試玩：隨便開一個 new repo，隨便寫一些 demo code，先讓 cline 練習跑 2–3 個任務，熟悉它的行為再用在正式專案。
    • 搭配版本控制：每個大任務都在新 branch 上跑，結束後自己再做一次 diff review。
    • 敏感資訊避免暴露：若你用雲端模型，注意不要讓它讀到含憑證 / 密鑰的設定檔，必要時把這些檔案加入 .gitignore 和 cline 的忽略清單。

    只要這幾個基本安全習慣有做到，cline 就可以很自然地變成你日常開發裡的「安全自動化助手」，從重構到寫測試，幫你把那些重複又耗時間的工作交給 Agent 處理。

    🚀 你現在可以做的事

    • 打開 VS Code 安裝 cline 擴充套件，並在一個測試用 repo 裡試跑 1–2 個小任務
    • 準備好你的模型 API（金鑰與 API Base URL），在 cline 設定面板完成連線測試
    • 建立一個標準的「plan-first」prompt 檔案，之後在每個新專案開頭都先貼給 cline 使用
  • IFTTT MCP：讓 Claude 幫你跑腿自動化

    IFTTT MCP：讓 Claude 幫你跑腿自動化

    📌 本文重點

    • IFTTT MCP 讓 Claude 真正「動手」操作 1000+ App
    • 用自然語言就能設定 Trigger、任務與權限
    • 先從 Gmail → Claude 摘要 → Notion 的簡單流程開始

    一句話定位：IFTTT MCP 就是「IFTTT 版 AI Agent」——讓 Claude 幫你在 1000+ 服務間跑腿，自動處理信件、文件、任務與通知。

    入口：IFTTT 產品頁（含 MCP 介紹）
    https://www.producthunt.com/products/ifttt

    核心功能：把 Claude 變成「會點 App 的助理」

    1. 基於 MCP，讓 LLM 真的「動手做事」

    一般聊天機器人只會給你文字建議；IFTTT MCP + Claude 的組合，是讓 Claude 透過 Model Context Protocol（MCP），直接去操作 IFTTT 已整合的 1000+ 服務：

    • Gmail、Outlook
    • Slack、Teams
    • Notion、Google Docs、Trello
    • Twitter/X、Facebook Page、Instagram（透過對應 App）

    可行動的具體效果：

    • 不是「教你怎麼回信」，而是幫你先讀信、標註、分類。
    • 不是「建議你整理會議重點」，而是幫你寫好摘要塞進 Notion 或 Google Docs。
    • 不是「提醒你看 Slack」，而是把 Slack 重點整理成一封 Email 寄給你。

    你要做的行動：

    • 腦中先列出「我每天重複做、又不需要太多判斷力」的任務，例如：
    • 看客服信件、貼 Label
    • 把 Slack 重要訊息集中在一個地方
    • 把社群留言變成待辦
    • 接下來就用 IFTTT MCP，把這些交給 Claude + IFTTT 處理。

    2. 使用者在 IFTTT MCP 介面上能做什麼？

    你不用寫程式，但要會設定三件事：觸發條件、自然語言任務描述、權限。

    （1）設定觸發條件（Trigger）

    在 IFTTT 介面裡，你可以用類似「IF This Then That」的方式決定：

    • 什麼時候 Claude 要被叫出來：
    • 新的 Gmail 收到、且主旨含「客服」
    • 某個 Slack 頻道有新訊息
    • Notion 資料庫新增一行
    • 每天早上 9 點定時

    行動建議：

    • 先挑 一個入口 App 當 Trigger，例如 Gmail 或 Slack，先做一條最簡單的自動化。

    （2）用自然語言描述要 Claude 做什麼

    接著你會看到類似「讓 Claude 做這件事」的欄位，你只需要用人話寫清楚：

    • 要它讀什麼：例如「請閱讀這封新來的 Gmail 內容」
    • 要它產生什麼：例如「生成 3 行內的中文摘要，附上 3 個關鍵標籤」
    • 要它輸出的格式：例如「用 JSON 回傳：{summary: ..., tags: [...]}」或「輸出純文字段落」

    行動建議：

    • 第一次先寫非常具體的指令，例如：

      請閱讀這封信件內容，判斷是否為客服詢問。若是，寫出：1 段 100 字內摘要 + 3 個標籤（如：退款、帳號問題、技術問題）。只用繁體中文回答。

    （3）權限管理：決定 Claude 能碰到什麼

    IFTTT MCP 會要求你授權：

    • 哪些 App 可以被用在這個 workflow
    • 可以讀哪些資料（例如哪一個 Gmail 帳號、哪個 Notion 資料庫）

    行動建議：

    • 第一次只授權「測試用」資料：
    • 新開一個 Gmail Label 只放測試信
    • 新建一個 Notion 資料庫專門給自動化寫入
    • 確認流程正常後，再慢慢擴大範圍。

    3. 典型自動化範例（辦公族版）

    以下三個工作場景，你可以幾乎照抄設定：

    範例一：客服信件由 Claude 先讀、標註、整理到 Notion

    流程：

    1. Trigger：Gmail 收到新信，且寄到 support@你的網域。
    2. Claude 任務：
    3. 讀信內容
    4. 判斷是詢問、抱怨、錯信、垃圾信
    5. 摘要重點、抽出客戶名稱、公司、需求類型
    6. Action：
    7. IFTTT 把 Claude 輸出的摘要寫入 Notion 資料庫一行
    8. 同時在 Gmail 加上對應 Label（例如「退款」「技術問題」）。

    實際效果：

    • 你每天只要看 Notion 看板，就能看到「已分類好的客服案件」。
    • Gmail 信箱只負責收信，不再是你分類的戰場。

    範例二：每天自動總結 Slack 頻道討論寄到 Email

    流程：

    1. Trigger：每天 18:00 定時。
    2. Claude 任務：
    3. 拉取當天某個 Slack 頻道訊息
    4. 產生「今日重點摘要 + 代辦清單」
    5. Action：IFTTT 把內容寄到你的工作 Email。

    適合：

    • 經理、PM、不常盯 Slack 的主管。

    範例三：社群新留言自動整理成待辦表

    流程：

    1. Trigger：Facebook Page 或 Twitter/X 有新留言或提及。
    2. Claude 任務：
    3. 判斷是否為需要回覆／需要跟進的內容
    4. 抽出「用戶問題」「優先度」「建議回覆方向」
    5. Action：寫入 Notion 或 Trello（建立一張卡片）。

    實際效果：

    • 你每天只要在 Notion 或 Trello 看「待回覆留言清單」，不用一則一則在社群裡翻。

    💡 關鍵： 把「先讀、先分類、先整理」這 80% 的機械流程交給 Claude，人只處理剩下最有價值的 20%。

    適合誰用？

    針對辦公族，可以直接對號入座：

    • 客服 / CS 團隊：先由 Claude 做信件初篩與標註，你只處理「真的需要人工判斷」的 20%。
    • PM / 專案經理：把 Slack、Email、會議紀錄集中到 Notion、Trello，由 Claude 做第一輪摘要與任務拆解。
    • 行銷 / 社群小編：把分散在 IG、Facebook、X 的互動整理成待辦清單與報表。
    • Freelancer / 顧問：固定時間自動整理客戶往來信件、專案進度簡報稿。

    行動建議：

    • 先挑 一個你每天重複 10 次以上 的任務，問自己：
    • 這個任務有沒有明確規則？
    • 給一個夠聰明的助理說明，他能做 80% 嗎？
    • 如果答案是「可以」，就值得用 IFTTT MCP 做一條 workflow 試試。

    💡 關鍵： 每天重複 10 次以上、規則清楚的任務，往往是最適合先被自動化、也最容易看出效益的部分。

    怎麼開始：新手入門 Demo（Gmail → Claude 摘要 → Notion）

    以下是一條最簡單、最好理解的 workflow，實際上線大概 15–30 分鐘。

    💡 關鍵： 先用 15–30 分鐘做出一條跑得動的簡單流程，比花幾小時規劃複雜架構更重要。

    步驟 1：開通 IFTTT MCP

    1. 註冊或登入 IFTTT 帳號：https://ifttt.com
    2. 在服務或探索頁面搜尋「Claude」「MCP」關鍵字，找到帶有 MCP 整合的 Claude 相關服務（實際名稱可能會微調，以 IFTTT 介面為準）。
    3. 啟用該服務，點選「Connect」並同意條款。

    步驟 2：把 Claude 帳號 / 金鑰接進 IFTTT

    1. 在 IFTTT 的 Claude 服務設定頁面，按「Connect」。
    2. 系統會要求：
    3. 登入你的 Claude 帳號，或
    4. 填入 API Key（如果 IFTTT 走 API 金鑰方式）。
    5. 完成授權後，IFTTT 就能代表你呼叫 Claude，執行 MCP workflow。

    行動建議：

    • 如果你公司有統一的 Claude 帳號，先跟 IT / 資安確認使用範圍，避免用個人帳號處理公司敏感資料。

    步驟 3：建立 Gmail → Claude → Notion 的簡單流程

    1. 在 IFTTT 點選「Create」，新增一個 Applet / Workflow。
    2. 設定 Trigger（This）：
    3. 選擇 Gmail 服務 → New email in inbox with search
    4. 搜尋條件輸入：label:auto-summary（你可以先在 Gmail 建這個 Label，手動拉幾封信進來當測試）。
    5. 設定 Claude 步驟：
    6. 加一個 Action，選擇 Claude（MCP）服務。
    7. 在指令欄輸入：
      > 請閱讀這封 Gmail 的主旨與內文，寫出：\n1. 兩段以內的中文摘要（每段不超過 80 字）\n2. 三個關鍵標籤（用逗號分隔）\n3. 若有明確待辦事項，幫我用清單列出。\n請用 Markdown 格式輸出：\n# 摘要\n…\n\n# 標籤\n…\n\n# 待辦\n- …
    8. 設定 Notion 寫入：
    9. 再加一個 Action，選擇 Notion 服務 → Create a database item。
    10. 選擇一個你事先建好的「Email 摘要」資料庫，欄位可包含：標題、內容、日期、標籤。
    11. 把 Claude 的輸出對應到 Notion 的內容欄位，標題可用 Gmail 主旨。

    完成後，每當你把一封 Gmail 加上 auto-summary Label，就會觸發：

    • Claude 讀信 → 產出摘要 → IFTTT 寫進 Notion。

    步驟 4：疊加條件、加入更多服務

    最簡單流程跑起來後，可以這樣升級：

    • 加條件：
    • 只有當信件收件人包含「support@」時才觸發。
    • 信件主旨含「退款」「無法登入」時，標記為高優先。
    • 加服務：
    • 讓 IFTTT 再多一步，把高優先案件同步到 Slack 頻道 ping 客服團隊。
    • 每天自動把當天所有 Notion 中的客服摘要，再請 Claude 生一份「客服日報」，寄給主管。

    行動建議：

    • 每次只加「一個小功能」，例如：多一個條件、多一個 Action。
      不要一次做超複雜 workflow，比較容易除錯，也比較看得出效益。

    小結

    如果你：

    • 不想寫後端、又想讓 AI 幫你動手去各種 App 裡跑腿；
    • 每天被 Email、Slack、社群訊息淹沒；

    那就先從一條 Gmail → Claude 摘要 → Notion 開始，體驗一次「讓 AI 幫你整理世界」的感覺，再慢慢把你的整個工作日，拆成一條條 IFTTT MCP 自動化流程。

    🚀 你現在可以做的事

    • 去 IFTTT 搜尋「Claude」「MCP」，實際啟用一次 Claude 相關服務
    • 在 Gmail 建立 auto-summary Label，挑 3 封信做為第一批測試樣本
    • 在 Notion 建一個「Email 摘要」資料庫，照文中步驟串起第一條 workflow
  • 用 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 呼叫你自定義的工具函式，例如：

    • 網頁爬蟲（requests、Playwright）
    • 存取資料庫或 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 README：https://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 流程並在本機跑一次
  • 把 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 的組合
  • 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，丟給團隊實際試用並收集回饋
  • 把常用 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 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
  • 一行指令接上多模態 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 來查看專案截圖