標籤: 免費 AI 工具推薦

用文字畫 3D：Adam 實戰指南
📌 本文重點
- Adam 把自然語言變成可編輯的 OpenSCAD 程式碼與 3D 模型
- 用「文字 + 滑桿」就能調整尺寸與設計邏輯
- 雲端試用簡單，也能用 CADAM 自架整合到現有流程
一句話先講結論：Adam 讓你用一句自然語言描述零件，就能拿到可編輯的 OpenSCAD 程式碼和 3D 模型，用滑桿或文字微調尺寸，直接接到現有 CAD／3D 列印流程。

官網 / Demo：https://adam.new
開源專案（CADAM）：https://github.com/Adam-CAD/CADAM

核心功能：從文字到 CAD 程式碼

Adam 圍繞一條實際工作流程設計：「文字描述零件 → 生成 CAD 程式碼 → 視覺化 3D 模型 → 滑桿 / 文字微調 → 導出到現有流程」。

💡 關鍵： 這條流程的重點是輸出「可維護的程式碼 + 模型」，而不是單次不可重用的模型檔。

1. 兩種模式：參數化建模 vs 網格生成

進入 Adam 介面後，先選模式：
- 參數化建模（Text → OpenSCAD）
- 輸入：
  - 例：「一個 20×40 mm 的 L 形支架，厚度 3 mm，兩邊各有 2 個直徑 4 mm 的螺絲孔，孔中心離邊 8 mm。」
- 輸出：
  - 可編輯的 OpenSCAD 程式碼
  - 內建參數滑桿（長度、厚度、孔徑等）
- 適合：
  - 要做多尺寸版本、後續要改尺寸的零件
- 網格生成（Text → Mesh）
- 輸入：較偏形狀描述，如「帶有圓角的桌角保護套，可套在 20 mm 厚桌板上」。
- 輸出：
  - 一個可下載的網格（通常是 STL 或類似格式）
- 適合：
  - 只要快速 3D 列印，不打算日後精細改版的形狀件
實際操作行動：
1. 先想清楚這個零件未來會不會「常改尺寸」。
2. 會改 → 選「參數化建模」；一次性打樣 → 可試「網格生成」。
2. 滑桿調參 + 文本修改：像寫程式一樣調零件

Adam 的核心體驗是「文字 + 滑桿」雙軌控制：
1. 第一次生成：
2. 在文字框輸入需求，按下生成。
3. Adam 會：
  - 呼叫 AI 生成 OpenSCAD 程式碼
  - 解析出關鍵尺寸，放成可拖曳的滑桿
4. 用滑桿調整尺寸：
5. 介面右側是 3D 模型預覽，左側或下方是參數列表：
  - length、width、thickness、hole_diameter 等。
6. 你可以直接拖拉滑桿，看模型即時更新。
7. 適用情境：
  - 客戶說「再厚一點」
  - 3D 列印測試後只想調整孔徑、間距
8. 用文字改需求：
9. 覺得形狀邏輯要變，例如：
  - 原本「兩個孔」，改成「三個等距孔」。
10. 直接在文字框補一句：「改成三個等距螺絲孔，孔徑 5 mm。」
11. Adam 會重新生成程式碼，並保留參數化結構。
💡 關鍵： 數值用滑桿、邏輯用文字，能把「一次性建模」變成「可持續迭代的設計流程」。

實際操作行動：
- 每次修改先問自己：「這是數值調整，還是設計邏輯變更？」
- 數值：用滑桿或直接改參數欄位數字。
- 邏輯：用文字提示重新生成，然後再微調滑桿。
3. Text → Code：產出可讀的 OpenSCAD

Adam 的底層策略是「Text → Code → CAD」：
- 你得到的不是黑盒模型，而是完整 OpenSCAD 程式碼：
- 具名變數：bracket_length、wall_thickness、hole_offset …
- 結構清楚的 module() 函式。
- 你可以：
- 直接把程式碼複製到本機 OpenSCAD 編輯。
- 放進 Git 版本控制。
- 用腳本批次修改某些參數再輸出多版本。
實際操作行動：
1. 生成完成後，打開程式碼面板，把 OpenSCAD 內容存成 part.scad。
2. 用 Git 建版（例如 v1.0、v1.1），把 AI 產生的 CAD 正式納入工程專案。
適合誰用？三個具體場景

1. 機構工程師：快速打樣支架 / 夾具

常見痛點：
- 為測試治具、感測器支架畫模型，來回改尺寸耗時間。
用 Adam 的 workflow：
1. 文字描述：
2. 「一個可以夾在 20 mm 厚鋁板上的 U 形夾具，內側貼合，外側有一個 5 mm 穿孔用來鎖 M5 螺絲。」
3. 選「參數化建模」，生成模型和程式碼。
4. 滑桿調整：板厚、公差、螺絲孔位置。
5. 導出 STL，送去 3D 列印測試。
建議做法：把專案常用尺寸（例如板厚、公差）命名成變數，後續專案只改變數就能重用設計。

2. 3D 列印工作室：一次生成多尺寸版本

需求：
- 同一個產品，需要 10、20、30、40 mm 四種尺寸給不同客戶。
做法：
1. 在 Adam 生成一個參數化模型，例如「桌角保護套」，把關鍵尺寸寫成變數 edge_size。
2. 將 OpenSCAD 程式碼複製回本機，寫簡單迴圈：
scad for (s = [10, 20, 30, 40]) { edge_size = s; // 呼叫 Adam 生成的 module corner_protector(edge_size=edge_size); }
1. 在 OpenSCAD 中分別導出不同尺寸 STL。
替代做法：懶得寫程式時，可在 Adam 的滑桿上手動切四個尺寸，分別匯出四個 STL，適合量少時使用。

💡 關鍵： 把尺寸參數化後，同一份程式碼就能覆蓋多個規格，大幅減少重畫模型的時間成本。

3. 軟體工程師：用文字產出可讀 CAD

痛點：
- 不熟 3D CAD，但懂程式，希望能為 Side Project 做外殼或支架。
用 Adam 的方式：
1. 用你熟悉的軟體語言思維來描述零件：
2. 「為一塊 100×80 mm 的 PCB 做一個盒子，上方預留 10 mm 高空間，下方有 4 個 M3 鎖孔，孔位與 PCB 四角對齊。」
3. Adam 會產生具名變數與模組化程式碼：
4. 很像在讀一個乾淨的程式檔案。
5. 你可以把 part.scad 放進專案 repo：
6. hardware/case_v1.scad
7. 在 CI 裡加註解：「生成 STL 時請用 OpenSCAD 2024.x 以上版本。」
實際操作行動：團隊中沒有機構工程師時，讓軟體工程師先用 Adam 做「可用但不完美」的機構草稿，再請專業設計師基於 OpenSCAD 程式碼優化。

怎麼開始：雲端體驗到本機部署

1. 直接在線上玩 Demo（最快）
1. 開啟：https://adam.new
2. 用 Google / GitHub 帳號註冊或以訪客登入（以實際介面為準）。
3. 選擇模式：
4. 多尺寸零件 → 「參數化建模」
5. 只要快速 3D 打樣形狀 → 「網格生成」
6. 在文字框輸入第一個零件描述，按生成。
7. 試著：
8. 拖拉滑桿，觀察模型變化。
9. 切到程式碼頁籤，複製 OpenSCAD 程式碼。
目標：第一次使用，用 10 分鐘做出一個「有螺絲孔的簡單支架」並匯出 STL。

2. 在本機部署開源 CADAM

如果你想要自架服務（內網使用、接私有模型），可以部署開源專案 CADAM：

GitHub：https://github.com/Adam-CAD/CADAM

CADAM 是一個 React + Supabase 的 web app，大致步驟：
1. 準備環境（本機或伺服器）：
2. Node.js（建議 18+）
3. pnpm 或 npm
4. Docker（選用，如果你要用容器）
5. Clone 專案：
bash git clone https://github.com/Adam-CAD/CADAM.git cd CADAM
1. 安裝依賴：
bash pnpm install # 或 npm install
1. 設定環境變數：
2. 依照 README 建立 .env 檔：
  - Supabase 金鑰 / URL
  - OpenAI 或相容 LLM 的 API Key（若要自接模型，依說明調整）
3. 啟動開發伺服器：
bash pnpm dev

在瀏覽器打開 http://localhost:3000 即可使用。

行動建議：先在線上版熟悉介面，再決定是否要自架；部署前從 GitHub 的 issue / README 確認當前支援的模型與功能狀態。

3. 接到 OpenSCAD / CAM / 生產流程

Adam 的輸出是程式碼 + 模型，你可以這樣接入現有流程：

3.1 接 OpenSCAD
1. 從 Adam 介面複製生成的 OpenSCAD 程式碼。
2. 在本機用 OpenSCAD 打開，進行：
3. 更進階的布林運算（差集、交集）
4. 加入你自己的 library / module
5. 用 OpenSCAD 導出 STL / STEP，交給下游軟體。
3.2 接 CAM / CNC / 3D 列印
- 3D 列印：
- 從 Adam 或 OpenSCAD 匯出 STL。
- 在 Cura / PrusaSlicer / Bambu Studio 裡切片，設定填充率、支撐等。
- CNC / CAM：
- 如果需要 STEP/IGES，可先用其他工具把 STL 轉 B-rep（或改用能輸出 STEP 的 CAD 路線）。
- 在 Fusion 360 / SolidWorks / FreeCAD 裡做 CAM 規劃，生成刀具路徑。
實際操作行動：選一個目前專案中的小零件，用 Adam 生成 → 用 OpenSCAD 調整 → 匯出 STL → 3D 列印，完整跑一次小型「文字到實物」流程，確認團隊能接得住輸出格式。

小結：下一步可以做什麼？

如果你是：
- 機構工程師：先把常用的支架 / 夾具模板交給 Adam 生成 OpenSCAD 草稿，日後改尺寸只改變數。
- 3D 列印工作室：用 Adam 做參數化模型，批次產生多尺寸版本，減少重畫時間。
- 軟體工程師 / Maker：把 CAD 當程式寫，用 Git 管理 .scad，讓硬體外殼也成為可維護的程式碼資產。
下一步，開啟 https://adam.new，用一句話描述你今天最想偷懶不想畫的零件，看看 Adam 能幫你省掉多少建模時間。
🚀 你現在可以做的事
- 上 https://adam.new，用一句話生出一個含螺絲孔的小支架並匯出 STL
- 把生成的 OpenSCAD 存成 part.scad，放進 Git repo 當作第一個「程式化 CAD」檔案
- 到 https://github.com/Adam-CAD/CADAM 看 README，評估是否在團隊內部自架一套 Adam/CADAM 服務
2026 年 6 月 18 日
NotebookLM 大升級：把 Gemini 變成你的研究員
📌 本文重點
- NotebookLM 把閱讀、整理、寫程式整合在同一工作空間
- 內建雲端 sandbox，可直接跑 Python 做資料分析
- 透過 Agent 自動查網路資料，像一位會 Google 的研究員
用一句話說 NotebookLM：把你的文件、網頁跟程式碼交給一個會自己查資料、寫筆記、跑程式的 AI 研究員，幫你把「看資料 + 做筆記 + 寫程式」整合在同一個工作空間。

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

核心功能：現在的 NotebookLM 到底多了什麼？

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

這次 NotebookLM 底層模型換成 Gemini 3.5 Flash，重點不是名字，而是實際效果：
- 引用來源更清楚：問問題時，NotebookLM 會標記是從哪一份 PDF、哪一頁、哪一段抓出來的。
- 和你自己的資料對齊：它只會優先根據你匯入的檔案回答，而不是憑空編故事。
- 支援多文件綜合：你可以丟 10 篇論文、3 份簡報，直接問「幫我整理共同結論」。
💡 關鍵： NotebookLM 會優先根據你匯入的資料回答問題，大幅降低「亂講」和憑空編造內容的風險。

你可以怎麼用：
- 把課程講義、公司簡報、研究論文丟進一個 Notebook，直接問：
- 「請用 300 字整理這些文件的重點，分成三個小節。」
- 「列出文件裡提到的所有關鍵術語，做成小抄。」
2. 內建雲端 sandbox：直接在 Notebook 裡跑程式

根據 The Decoder 報導，NotebookLM 現在有自己的 雲端電腦環境，可以：
- 執行 Python / 程式碼片段，不用本機安裝任何東西。
- 讓 AI 自己寫程式、執行、看結果，再調整程式碼。
- 做資料分析：匯入 CSV、跑統計、畫圖，全在瀏覽器裡完成。
💡 關鍵： 內建雲端 sandbox 讓你不用開 Jupyter 或設定環境，就能在瀏覽器裡完成程式與資料分析工作。

你可以怎麼用：
- 上傳一份 CSV 報表，在對話框輸入：
- 「幫我用 Python 讀取這個檔案，算出每個產品線的月營收，並畫出折線圖。」
- 有一段不熟悉的程式碼，直接貼進 Notebook：
- 「解釋這段程式在做什麼，幫我加上註解，並用更易懂的寫法重構。」
NotebookLM 會在它的雲端 sandbox 裡跑程式，再把結果和程式碼一起貼給你。

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

新版 NotebookLM 加入了 Agent 式研究能力：
- 可以直接叫它「去幫我找資料」，它會透過 Google 搜尋 找來源。
- 不用一開始就匯入檔案，也能從「空白」開始一個研究計畫。
- 它會把找到的網頁、PDF 當成新的資料來源，整理成摘要或報告。
The Verge 指出，現在你可以直接在 NotebookLM 裡啟動研究，而不是先手動找資料再貼進來。

你可以怎麼用：
- 問：
- 「請幫我找三篇 2023 年後關於 LLM 應用在教育的研究，整理出研究問題、方法、結論。」
- 要求：
- 「所有引用請附上原始連結，最後用一段話提醒我這些研究的限制。」
適合誰用：三個具體場景

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

常見痛點：
- 上課講義 + 教科書 + 老師 PDF + 論文，多到爆炸，很難整理成考前筆記。
- 讀英文論文速度慢，抓不到重點。
NotebookLM 的用法：
1. 建立一個 Notebook，例如「機器學習期末」。
2. 匯入：課程講義 PDF、指定閱讀論文、老師提供的投影片。
3. 問：
4. 「請用中文整理這份 Notebook 的期末考重點，照章節分類。」
5. 「幫我做一份 10 題選擇題，題目來自這些文件，並給出解析。」
6. 「這篇論文的實驗設計和 limitation 是什麼？用口語說明。」
可立即採取的行動：
- 把這學期最頭痛的一門課資料丟進 NotebookLM，直接讓它幫你做考前總整理。
2. 產品經理：整理競品資料與市場研究

常見痛點：
- 競品官網、新聞稿、使用條款、App 介紹分散各處。
- 每次開會都在重做一樣的「功能比較表」。
NotebookLM 的用法：
1. 新建 Notebook：「2024 Q3 競品研究」。
2. 匯入：競品官網截圖 PDF、功能說明文件、先前做過的簡報。
3. 啟用 Agent 查資料：
4. 「幫我搜尋 3 家同類型 SaaS 產品的定價頁面，整理成表格。」
5. 再問：
6. 「針對我們現有產品，列出 5 個值得抄的功能點，並附上來源連結。」
可立即採取的行動：
- 建立你的「競品知識庫 Notebook」，每天丟一兩個新連結進去，讓 NotebookLM 幫你維護最新的競品視圖。
3. 工程師：技術備忘錄 + 資料分析助手

常見痛點：
- 專案文件分散在 Confluence、Google Docs、GitHub Wiki。
- 每次查舊專案架構或業務規則，都要重看一堆文件。
- 做小型資料分析還得開 Jupyter、整理環境。
NotebookLM 的用法：
1. 建立 Notebook：「後端服務 A 技術文件」。
2. 匯入：設計文件 PDF、API spec、README、部分程式碼片段。
3. 提問：
4. 「這個服務的主要資料表有哪些？幫我畫一個簡化的 ER 圖描述文字。」
5. 「從這份 API 文件裡，整理一份給新同事看的 onboarding 指南。」
6. 把日常 log / CSV 丟進去：
7. 「用 Python 幫我分析這份 log，找出錯誤頻率最高的三個 endpoint，畫 bar chart。」
可立即採取的行動：
- 先選一個你最常被問的專案，把所有設計文件丟進 NotebookLM，之後把新同事導向 NotebookLM 問問題。
怎麼開始：10 分鐘完成第一個 Notebook 專案

步驟 1：開啟 NotebookLM
1. 用 Chrome 或任一瀏覽器開啟：https://notebooklm.google.com
2. 用你的 Google 帳號登入。
3. 若地區未開放，可以先用 VPN 嘗試（注意公司政策）。
步驟 2：建立第一本 Notebook
1. 點選「New notebook」。
2. 幫它取一個明確的名字，例如：
3. 「行銷簡報整理」
4. 「碩士論文文獻庫」
5. 按「Add sources」，開始匯入資料。
步驟 3：匯入 PDF / Docs / 網頁

NotebookLM 支援：
- 上傳 PDF、TXT、部分 Office 檔。
- 直接選 Google Docs、Slides、Sheets。
- 貼上網址，讓它自己抓取網頁內容（官網、部落格、新聞稿）。
建議：先匯入 3–5 份你最近真的會用到的文件，不要一次丟 50 份，方便你先熟悉操作。

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

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

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

模板 1：快速總整理

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

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

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

模板 3：資料 + 程式分析

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

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

使用 NotebookLM 最重要的觀念是：為每個專案建一本 Notebook，讓它跟著專案一起長大。
- 學生：每門課一冊，所有講義與筆記都放進去。
- 產品經理：每個產品線或競品一冊，讓它幫你維護最新情資。
- 工程師：每個系統或專案一冊，變成活的技術備忘錄 + 分析環境。
你只需要準備好資料，NotebookLM 會幫你查、幫你寫、幫你跑程式，真正變成「專案專屬的 Gemini 研究員」。
🚀 你現在可以做的事
- 登入 NotebookLM，為你目前最重要的專案建立第一本 Notebook
- 先匯入 3–5 份你最近真的會用到的文件，實測上文提供的 3 個 Prompt 模板
- 挑一個課程 / 產品線 / 專案，每次產出新文件就丟進 NotebookLM，開始養成「一專案一 Notebook」的習慣
2026 年 6 月 11 日
Lens 超輕量圖像生成實戰指南
📌 本文重點
- 小模型搭配高品質描述也能畫得好
- Lens 完整開源，可在本機或雲端部署
- 用 GPT 先整理資料，可微調出專屬圖像模型
- 先用 Demo 試 prompt，再決定是否自建 API
用一台普通筆電就能跑的開源圖像模型 Lens，把「小模型也能畫得好」這件事變成現實，適合想在本機或雲端快速搭一個可用圖像生成系統的人。

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

核心功能：小模型，靠好資料撐起來

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

Lens 的參數量只有約 38 億，比主流閉源大模型小很多，但在多個圖像生成基準測試中，成績可以追上甚至超過體型更大的模型。關鍵不是「堆參數」，而是訓練資料：
- 使用約 8 億筆、由 GPT‑4.1 產生的高品質圖像描述
- 描述內容細到「光源方向、鏡頭焦段、材質、構圖」，不是只寫「一隻貓坐在桌子上」
- 小模型可以在這些精準標註上更有效學習
💡 關鍵： 約 38 億參數配上 8 億筆精準描述，證明小模型只要資料夠好，也能接近甚至超過大模型表現。

你可以怎麼用這個優勢？

在實際 prompt 時，多寫一點細節，Lens 特別吃「具體描述」：
```
一個極簡風格的手機 App 圖標，白色背景，中間是扁平化的藍色雲朵，
線條乾淨，無陰影，適合放在 iOS 主畫面。
```
比起只寫「雲朵圖標」，具體描述會更接近 Lens 當初訓練時看到的高質量 caption，使輸出品質更穩定。

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

Lens 的程式碼與模型權重開源，你可以：
- 在本機部署，不經過第三方雲端
- 在自己的伺服器上做內網圖像生成 API
- 自行微調，適配特定風格（例如公司品牌視覺）
可行動的做法：
- 把 Lens 當作「公司內部版 Midjourney」，搭配簡單前端頁面給同事用
- 在產品原型工具（如 Figma 插件、內部 dashboard）後端接上 Lens API
3. 訓練思路可複用：用 GPT 先把資料變好

Lens 的另一個重點，是用 GPT‑4.1 先幫原始圖像資料寫出高品質描述，再拿來訓練。對個人或團隊來說，這給了很實際的路線：
- 收集自家產品圖（例如鞋子、包包、介面截圖）
- 用 GPT‑4.x 幫每張圖生成細緻描述
- 用這批資料微調 Lens，得到一個「專門懂你家產品」的圖像模型
你可以馬上做的實驗：
1. 拿 50 張自家產品圖
2. 用 ChatGPT / Azure OpenAI 幫每張圖寫 3–4 句的超詳細描述
3. 把這批圖 + 描述存成 JSON / CSV
4. 未來如需微調 Lens，就已經有一批乾淨資料可以用
💡 關鍵： 先用大型語言模型替資料加上高品質描述，可以顯著降低後續訓練或微調的成本，讓小模型也具備專領域能力。

適合誰用：三個典型場景

1. App 圖標與 UI 草圖

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

Lens 可以：
- 輸出風格統一的 App 圖標草稿
- 為不同功能模組快速生成 icon 系列
範例 prompt：
```
為一款習慣追蹤 App 生成 4 個圖標提案：
扁平化風格，柔和配色，每個圖標有明確象徵：
打卡用打勾符號、番茄鐘用簡化的時鐘、
統計用長條圖、個人設定用簡化人物輪廓。
背景簡潔，適合 iOS 風格。
```
2. 行銷素材：社群貼文、Banner 草圖

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

Lens 可以：
- 生成不同構圖的社群貼文底圖
- 幫你先找到「方向」，再請設計師改
實際使用方式：
1. 將產品賣點寫成 2–3 句描述
2. 指定風格（例如「韓系清新」、「科技感藍紫配」）
3. 產出 5–10 張圖，挑 1–2 張給設計師重製
3. 產品原型圖：硬體外觀、介面草稿

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

Lens 可以：
- 幫你畫出不同外型的裝置草案（例如智慧音箱、耳機）
- 幫 App 原型搭配大致配色與版型
範例 prompt：
```
一款家用智慧音箱的產品概念圖，
圓柱形機身，霧面白色塑膠材質，上半部有細密圓孔，
底部有一圈柔和的 LED 光環，放在木質桌面上，
整體風格偏向北歐極簡風。
```
怎麼開始：最低摩擦上手路線

路線 1：完全不寫程式，先用 Hugging Face Demo Space

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

步驟：
1. 開啟 Demo Space 頁面
2. 在文字框輸入中文或英文 prompt
3. 選擇解析度與步數（預設即可）
4. 點擊 Generate
適合：
- 行銷或產品同事想先測試效果
- 還沒有決定要不要自己部署
小技巧：
- 先用 Demo 找到你喜歡的 prompt 模板
- 再複製這些 prompt 到你自己的部署裡使用
路線 2：會寫程式，用 Transformers 建自己的圖像生成 API

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

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

1. 安裝必要套件
```
pip install torch torchvision --index-url https://download.pytorch.org/whl/cpu
pip install transformers accelerate safetensors
```
如果你有 NVIDIA GPU，可改用官方 CUDA 版 PyTorch 安裝指令。

2. 下載並載入 Lens 模型

以 Transformers 為例（假設模型名稱為 microsoft/lens-3.8b，實際名稱請依 Hugging Face Hub 為準）：
```
from transformers import AutoTokenizer, AutoModelForCausalLM
import torch

model_id = "microsoft/lens-3.8b"

tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
    model_id,
    torch_dtype=torch.float16,
    device_map="auto"
)

prompt = "a minimal blue and white app icon of a cloud on a white background, flat design, no shadows"
inputs = tokenizer(prompt, return_tensors="pt").to(model.device)

with torch.no_grad():
    outputs = model.generate(**inputs, max_new_tokens=256)

# 假設模型會輸出圖像 latent，再解碼成圖片
# 這部分請依官方範例加入解碼步驟
```
因為 Lens 是影像模型，實際程式碼會包含「文字 -> 影像 latent -> 圖檔」三階段；建議直接參考官方 repo 的 inference.py 或示範 notebook，把其中的 inference 函數包一層 API。

3. 快速包一個本機 API（Flask 範例）
```
from flask import Flask, request, send_file
from io import BytesIO

app = Flask(__name__)

@app.post("/generate")
def generate():
    data = request.get_json()
    prompt = data.get("prompt", "")
    # 呼叫 Lens 推理函數，回傳 PIL Image
    image = run_lens(prompt)

    buf = BytesIO()
    image.save(buf, format="PNG")
    buf.seek(0)
    return send_file(buf, mimetype="image/png")

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8000)
```
有了這個 API，你就可以：
- 在前端或 no-code 工具（如 Bubble、Retool）裡直接呼叫
- 在 CI pipeline 裡自動生成 demo 圖像
💡 關鍵： 先用 Hugging Face Demo 測試，再用短短數十行程式碼包成 API，可以在普通硬體上快速搭起團隊可用的圖像生成服務。

最低摩擦指南：你現在可以做什麼
1. 先用 Hugging Face Demo 試出一組好用 prompt：
2. 各準備一組 App 圖標、行銷素材、產品原型的 prompt 模板
3. 決定部署路線：
4. 只需要偶爾用 → 繼續用 Demo
5. 團隊要每天用 → 自己在雲端或本機起一個 Lens API
6. 把 prompt 模板寫進文件：
7. 給團隊共用，確保風格一致
Lens 的真正價值，不只是「輕量」這一點，而是用高品質 GPT‑4.1 描述資料換來的「小而準」行為。只要你願意在描述上多花一點心思，就能在普通硬體上，得到足夠好用的圖像生成系統。
🚀 你現在可以做的事
- 打開 Hugging Face 搜尋「Lens text-to-image」，實際輸入 3 組 prompt 測試效果
- 在一台開發機上依照文中步驟安裝 Transformers，跑通一個簡單的 Lens API
- 收集 20–50 張自家產品圖，配合 GPT‑4.x 產生描述，準備未來微調用的資料集
2026 年 6 月 11 日
Gemini Spark 實測：讓 AI 幫你24小時跑腿
📌 本文重點
- Gemini Spark 能在背景執行多步驟任務
- 可長時間記住上下文並自動接續任務
- 透過確認機制與權限設計平衡自動化與安全
用一句話講白：Gemini Spark 就是一個 24/7 在背景幫你跑多步驟任務的 AI 小幫手，不用你一直開著聊天視窗盯著它。

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

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

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

傳統聊天機器人：
- 你問它才回你
- 一次只做一小段，關掉網頁就「記憶掰掰」
Gemini Spark：你給他一個任務，它可以自己在背景跑完多步驟流程，再回來跟你報告。

實際可以怎麼用：
- 旅遊規劃 + 比價
  指令示例：
  
  「幫我規劃 10 月中從台北去東京 5 天家庭旅行，預算中等，要有 2 天親子行程。請：1）找出 3 個機票選項，考慮總飛行時間與轉機；2）比 3 家飯店，近地鐵、評價 4.3 以上；3）做出每日行程表。你可以在背景慢慢查，整理好再一次給我。」
行動建議：第一次用 Spark 就拿「下一趟旅行」開刀，給它明確條件 + 步驟，讓它自己去跑，體驗差異最大。

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

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

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

它會記得：
- 你最近在規劃什麼（例如那趟東京行）
- 你之前給過的偏好（例如「我不想一早就排景點」）
- 它自己尚未完成的任務
你可以這樣用：

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

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

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

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

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

常見的確認點會包括：
- 要寄出 email 前
- 要變更行事曆 前
- 要存取新服務或帳號 時
使用方式：
- 把 Spark 想像成「實習生」：
- 你可以說：「先幫我草擬，不要真的送出。」
- 或：「這類會議邀請之後可以直接幫我接受。」
行動建議：第一次設定時，刻意跟它說清楚：

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

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

適合誰用？3 個具體場景

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

The Verge 的旅行實測裡，作者說 Spark 是第一個讓他覺得旅遊規劃真的可以交給 AI 的工具，因為它會：
- 不只列景點，還會看交通、預約限制、開放時間
- 幫你平衡：太緊湊 / 太鬆、戶外 / 室內、購物 / 觀光
你可以照抄這個 workflow：
```
任務目標：幫我規劃 4 天 3 夜的首爾行程，預算偏省，重點是美食跟咖啡廳。
限制：
- 不要一早 9 點前的行程
- 每天最多排 2 個需要事先訂位的地方
- 交通以地鐵為主
請：
1. 先問我出發時間與大概預算
2. 自己在背景查資料，整理成表格（時間 / 地點 / 交通 / 必點餐點或特色）
3. 把所有需要訂位的頁面連結整理，獨立列出清單給我。
```
行動建議：把旅遊需求拆成「目標＋限制＋要輸出的格式」，這樣 Spark 做出來的東西比較接近可以直接用的版本。

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

如果你常跟美國、歐洲同事開會，Spark 可以做的事情包括：
- 幫你把一串 email 往來整理成待辦清單
- 自動換算時區，找幾個可行的會議時間
- 產生英文 / 中文雙語的會議邀請草稿
指令示例：

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

行動建議：
- 寫指令時，先描述要的結果，再說你會提供什麼資料（例如會轉寄 email）。
- 用「台北時間」「倫敦時間」等明確描述，避免只寫「我早上」。
3. 日常代辦追蹤：把「總是忘記回信」交給它

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

你可以把它當作：
- Email 回覆提醒
- 文件閱讀與摘要助手
- 日常待辦整理員
範例指令：

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

行動建議：
- 先選「一個小範圍」讓 Spark 幫你追（例如星號信），不要一開始就全信箱開放。
- 每週檢查一次它生成的草稿，你會越來越知道怎麼跟它講需求。
優點與限制：實測感受整理

優點
- 真的可以放著不管：The Verge 的體驗中，Spark 在你離線時也會繼續查資料、比對選項，最後給你整理好的結果。
- 願意多問幾句確認：不像很多 Agent 一次衝到底，Spark 會分段跟你確認，讓你改方向。
- 整合 Google 服務有優勢：像 Gmail、Calendar、Docs 等，對已在 Google 生態系的人尤其方便。
限制與風險
- 速度不一定快：多步驟任務，等 5–15 分鐘甚至更久是常態，不適合「立刻要答案」。
- 隱私顧慮：要讓它看 Gmail、行事曆，等於多了一個能讀你資料的「人」。The Verge 也特別提醒了這點。
- 目前功能和價格仍在調整中：不同地區可能有功能差異，也可能需要訂閱 Gemini 付費方案才用得到完整版。
行動建議：
- 先從「不那麼敏感」的任務測試（旅行規劃、公開資訊整理），習慣它的行為再逐步開放更多權限。
💡 關鍵： Spark 適合放在「不急但複雜」的任務上，接受它可能要 5–15 分鐘換來的是你少了大量瑣事。

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

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

1. 快速開通與入口

大致流程會長這樣：
1. 登入 Google 帳號（建議用你平常收信、排行程那個帳號）。
2. 前往 Gemini 頁面，找到 Spark 開關或切換（Chat ↔ Spark）。
3. 按提示完成初始設定：
4. 選擇語言、地區
5. 勾選同意條款
6. 決定是否要讓它讀 Gmail / Calendar 等
行動建議：初次設定時，能跳過的權限先跳過，等確定要用再打開。

2. 哪裡能免費用到？

Google 目前的作法通常是：
- 基本 Gemini 功能提供免費層級
- 進階功能或高用量則綁定 Gemini Advanced / Google One AI Premium 類型訂閱
Spark 很可能會：
- 在部分地區提供測試或限量免費
- 或綁在付費方案裡，讓你有更高配額與完整 Agent 能力
行動建議：
- 先確認你所在的地區是否開放 Spark，並在 Gemini 介面查看是否需要升級方案。
- 如果有試用期，先集中在那段時間安排幾個「真實任務」給它做，評估值不值得付費。
3. 權限與通知：好用但不要被吵

要兼顧方便與不打擾，可以這樣設：

（1）資料權限：
- 先只開 Gmail / Calendar 的「讀取」權限，不給「全自動修改」。
- 明確跟它說：
  
  「除非我說可以，否則不要自動變更行事曆或寄出任何 email。」
（2）通知策略：
- 手機端：
- 保留「任務完成摘要」通知
- 關閉「每一步都提醒」的通知
- 你可以設一個固定時間：
  
  「每天晚上 9 點幫我整理今天你做了什麼、一件概要就好。」
行動建議：把 Spark 當成「一天回報一兩次的助理」，而不是 Slack 機器人那樣每十分鐘跳出來吵你。

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

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

可以記這個模板：

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

範例：

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

從一兩個小任務開始，習慣這種「把事交給 AI 跑完再回報」的工作方式，你會很快感受到：Spark 的價值不在於多會聊天，而是在於很多你不想做、但又非得有人做的細碎工作，它可以默默幫你扛掉。
🚀 你現在可以做的事
- 挑一個即將到來的旅程，照文中的「目標＋限制＋格式」模板寫一個 Spark 指令
- 從 Gmail 星號信中選一小段範圍，讓 Spark 嘗試幫你追蹤與產生回覆草稿
- 依照文中的權限與通知建議，在 Gemini 介面中完成 Spark 的初始設定與權限調整
2026 年 6 月 6 日

用 Mellum2 排程你的 AI 工作流

一句話先說清楚：Mellum2 是一顆專門幫你「排班、調度」其他大模型和工具的小模型，用來做 routing、任務拆解與工具選擇，讓 AI 工作流更便宜、更穩定。

📌 本文重點

Mellum2 是專門做「決策與調度」的小模型

適合負責 routing、任務拆解和工具選擇

能幫多模型、多工具的工作流壓成本、提穩定度

很適合拿來做 AI agent 的中樞大腦

官方介紹與原始碼：https://blog.jetbrains.com/ai/2026/06/mellum2-goes-open-source-a-fast-model-for-ai-workflows/

核心功能：先讓 Mellum2 當你的「AI 排班主管」

1. 低延遲的小模型，適合做決策層

Mellum2 本身不是 GPT-4o 那種萬能助手，它更像是負責「決定下一步要幹嘛」的主管：

模型體積小、推理快，適合放在整個 pipeline 的最前面或中間層
每次呼叫成本低，很適合頻繁決策：用哪個工具？要不要再拆一步？該重試還是直接回覆？

💡 關鍵： 把高頻率、邏輯性的「決定怎麼做」交給便宜小模型，昂貴大模型只負責「實際做」，能讓整體成本大幅下降。

你可以怎麼用？

把「判斷任務類型 → 選模型 → 選工具」這段邏輯，從你程式碼的 if-else 搬到 Mellum2
所有複雜 workflow 的分支規則，盡量改成 prompt + Mellum2 來決定，減少硬寫規則

2. 多步推理：讓它負責拆任務、串工具

JetBrains 把 Mellum2 設計成適合多步推理（multi-step reasoning）的模型，也就是它擅長做：

任務拆解：把「寫一份技術規格書」拆成「補資料 → 查 API → 產出草稿 → 校對」
步驟規劃：決定每一步要用哪支工具或哪個 LLM
狀態更新：根據上一個工具的輸出，動態調整下一步

你可以怎麼用？

把你現有的工具（爬網頁、查資料庫、呼叫商用 LLM）列成一張「工具清單」給 Mellum2
請 Mellum2 每次都輸出「下一步要用的工具 + 工具參數」，你的程式只負責照做

3. Routing + 工具選擇：讓 GPT、Claude、開源 LLM 都變成「插件」

Mellum2 最實用的角色，就是做模型路由（model routing）和工具選擇（tool selection）：

你可以在後面接：GPT-4.1、Claude 3.7、Llama、Qwen 等
Mellum2 根據需求幫你選：「這題要便宜模型」還是「這題要高準確度」

💡 關鍵： 當你同時使用多個 LLM 供應商時，用 Mellum2 做路由，可以在「品質不明顯下降」的前提下，讓大量請求自動落在較便宜的模型上。

可以這樣設計一個簡單策略

查資料類問題 → 用便宜/開源 LLM + 搜尋工具
寫程式、寫長文 → 用 GPT-4.1 或 Claude 3.7
簡單 Q&A → 用本地 LLM，節省 API 費用

你的程式不用管細節，只要：

收到使用者請求
把請求 + 目前可用模型列表丟給 Mellum2
照 Mellum2 的輸出去呼叫對應模型

適合誰用：三種典型場景

1. 你在做「AI 助手」或 Agent 系統

如果你在做：

產品內建 AI 助手（客服、知識庫問答）
自動化 Agent（幫你查資料、寫報告）

問題通常會是：

使用者問題差異很大，單一模型不是太貴就是太弱
工具越加越多，判斷流程 if-else 爆炸

Mellum2 能幫你：

把「選模型、選工具、拆步驟」集中到一顆小模型管理
你只要維護工具清單和觀察 Mellum2 的決策是否合理

可以實作的行動：

先挑三個最常用工具：RAG 搜尋、商用 LLM、本地 LLM
寫一個 Mellum2 prompt，要求它根據需求選 1-3 個步驟完成任務

2. 你有多個 LLM 供應商，要壓成本又要穩定

典型狀況：

公司已經有 OpenAI 帳號，也在測 Claude，還有自家的 vLLM 服務
主管希望「多用便宜模型，但品質不能掉太多」

Mellum2 的用法：

給它模型清單：
gpt-4.1: 高成本、高品質
gpt-4o-mini: 中等品質、便宜
local-llama: 最便宜、品質較不穩
附帶一些示例（few-shot），教 Mellum2 什麼情境選哪個

💡 關鍵： 先在開發環境裡讓所有請求經過 Mellum2 路由，實際觀察不同任務落在昂貴與便宜模型的比例，再調整規則，比一開始就死寫策略安全得多。

可以實作的行動：

先在開發環境改成「所有請求都要經過 Mellum2 路由」
觀察一週：不同任務下，商用 LLM 和本地 LLM 的占比、成本變化

3. 你要做「穩定的 AI Pipeline」而不是單次聊天

像是：

每天自動爬資料 → 摘要 → 存進 Notion
每次有 Pull Request → 產生 code review 建議

這種 Pipeline 常見問題：

某個 LLM 偶爾出錯，整條流程掛掉
你需要 fallback 策略：失敗就換模型、換 prompt、換工具

Mellum2 可以：

監看每一步工具回傳結果（成功 / 失敗 / 異常訊息）
根據結果決定下一步：
重試同一步驟
改用另外一個模型
回報錯誤給人類

可以實作的行動：

把 Pipeline 的每一步都包成「工具」
每一步的錯誤，也當作輸入回饋給 Mellum2，讓它決定接下來的補救策略

怎麼開始：從安裝到最小可行範例

以下流程以「你會用 Docker 或 Python，且已經有至少一個 LLM API（OpenAI / Anthropic / 本地 vLLM）」為前提。

1. 安裝 Mellum2：Docker 或程式庫二選一

先到官方部落格或 Repo：https://blog.jetbrains.com/ai/2026/06/mellum2-goes-open-source-a-fast-model-for-ai-workflows/

選項 A：用 Docker 跑起 Mellum2 服務

安裝 Docker / Docker Compose
拉取 Mellum2 映像（以官方 README 為準，示意）：

bash docker pull jetbrains/mellum2:latest

啟動服務（假設開在 8000 port）：

bash docker run -p 8000:8000 jetbrains/mellum2:latest

用 curl 測試：

bash curl -X POST http://localhost:8000/infer \ -H "Content-Type: application/json" \ -d '{"input": "你是任務規劃器，請幫我決定下一步要用什麼工具"}'

適合： 想先用 HTTP API 串現有後端的人。

選項 B：在程式裡直接呼叫 Mellum2

如果官方有 Python 套件（假設為 mellum2）：

pip install mellum2

簡單測試：

from mellum2 import MellumClient

client = MellumClient(base_url="http://localhost:8000")  # 或直接用雲端端點

resp = client.infer("你是任務規劃器，收到任務後要輸出下一步計畫")
print(resp)

適合： 你準備把 Mellum2 深度嵌到自家服務裡。

2. 示範：Mellum2 做 Router + 任務規劃的最小 workflow

下面是一個最小可行例子：

你有兩個底層 LLM：
gpt-4.1（高品質）
local-llama（便宜）
有一個簡單工具：web_search（用來查網路）
目標：收到使用者問題，由 Mellum2 決定：
要不要先搜尋
要用哪個模型產生最終答案

Step 1：定義給 Mellum2 的「工具/模型清單」

TOOLS = [
    {
        "name": "web_search",
        "type": "tool",
        "desc": "適合需要即時或最新資訊的問題，例如股票、新聞、價格。"
    },
]

MODELS = [
    {
        "name": "gpt-4.1",
        "cost": "high",
        "quality": "best",
        "desc": "用在需要高準確度、長文、程式碼的回答。"
    },
    {
        "name": "local-llama",
        "cost": "low",
        "quality": "medium",
        "desc": "用在一般聊天、簡單問答。"
    }
]

Step 2：設計 Mellum2 Prompt，請它輸出「計畫 JSON」

SYSTEM_PROMPT = """
你是 AI 工作流調度器，負責：
1. 判斷使用者需求
2. 決定是否要先使用工具
3. 選擇要使用的底層 LLM

請只輸出 JSON，不要多餘文字，格式：
{
  "steps": [
    {"action": "tool" | "model", "name": "...", "input_from": "user" | "prev_result"}
  ]
}

可用工具：
{tools}

可用模型：
{models}
""".format(tools=TOOLS, models=MODELS)

Step 3：呼叫 Mellum2，拿到決策後執行

import json
from mellum2 import MellumClient

mellum = MellumClient(base_url="http://localhost:8000")

user_query = "幫我分析最近 NVIDIA 股價的變化，順便預測未來一季可能走勢。"

planning_prompt = SYSTEM_PROMPT + f"\n使用者問題：{user_query}"

plan_resp = mellum.infer(planning_prompt)
plan = json.loads(plan_resp["text"])  # 依實際回傳欄位調整

result_cache = None
for step in plan["steps"]:
    if step["action"] == "tool" and step["name"] == "web_search":
        query = user_query if step["input_from"] == "user" else result_cache
        result_cache = call_web_search(query)  # 這是你自己實作的搜尋功能

    if step["action"] == "model":
        model_name = step["name"]
        model_input = user_query if step["input_from"] == "user" else result_cache
        result_cache = call_llm(model_name, model_input)  # 依照名稱選擇 gpt / llama

print("最終回答：", result_cache)

這樣，你已經有了一個：

Mellum2 做「任務規劃 + 模型/工具選擇」
後端只負責執行計畫的最小可行 workflow

接下來要擴充，只要：

在 TOOLS / MODELS 裡再加項目
用 few-shot 例子微調 Mellum2 的決策邏輯

Mellum2 在你的工具箱裡，扮演什麼角色？

如果從「AI 工作流」角度看，目前常見的組合大致是：

名稱	核心功能	免費方案	適合誰
Mellum2	工作流調度、routing、任務拆解	開源可自架	想自己組 AI pipeline，需要細控成本與流程的人
OpenAI GPT	高品質通用 LLM	有免費額度	需要高品質輸出、但不想自己訓練模型的人
Claude / Sonnet	對話 & 程式能力強的商用 LLM	有試用	重度寫作、程式輔助、長上下文需求
本地 LLM（Llama/Qwen）	私有部署、低成本推理	視模型而定	在意隱私或有大批量推理需求的團隊

Mellum2 並不是另一個「跟你聊天的模型」，而是用來把上面這些工具串起來、排程好、決定誰在什麼時候上場的小模型。

你可以從一個最小的 routing + 任務規劃範例開始，先讓 Mellum2 管理兩個模型、一支工具，跑順了再往外擴。

🚀 你現在可以做的事

打開官方文章與 Repo，確認 Mellum2 的最新安裝方式與 API 規格：https://blog.jetbrains.com/ai/2026/06/mellum2-goes-open-source-a-fast-model-for-ai-workflows/

在你的專案裡挑出兩個 LLM + 一個工具，依文中範例實作一個最小 routing workflow

收集一週實際流量，觀察 Mellum2 的模型選擇與成本變化，再用 few-shot 逐步調整決策邏輯

2026 年 6 月 2 日

NuExtract3：把 PDF 截圖變成乾淨資料
📌 本文重點
- NuExtract3 專門做「影像 / PDF → 結構化文字」
- 直接輸出 JSON / Markdown，省掉後續清洗
- 可自架本地部署，敏感資料不用上雲
- 用 prompt 自訂欄位 schema，方便接到現有 workflow
把亂七八糟的 PDF、發票截圖、表格照片，丟進 NuExtract3，就能直接拿到乾淨的 JSON / Markdown 結構化資料，方便你後續丟進 Notion、Google Sheet 或資料庫繼續用。

官方開源介紹（含 Demo 連結）：Reddit：NuExtract3 released

核心功能：三件事講完 NuExtract3

1. 多種文件型態，一次搞定

NuExtract3 是基於 Qwen3.5-4B 訓練的開源多模態模型（Apache-2.0 授權），主打「影像 / PDF → 結構化文字」。實際可以拿來處理：
- 多頁 PDF：報表、合約、研究報告
- 發票、收據、報銷單：紙本拍照、掃描檔
- 表格：Excel 匯出成 PDF、紙本表單的掃描
- 表單截圖：Google Form 結果頁、線上後台報表截圖
你只要準備：
- 一個檔案（PDF / 圖片）
- 一個「你想要的結構」描述（例如：請輸出成 JSON，欄位有 date、vendor、total_amount）
就能讓它幫你把畫面裡的內容拉成乾淨結構。

💡 關鍵： 只要定義好欄位結構，NuExtract3 就能把任何格式雜亂的文件，轉成統一結構的資料，後續處理成本會大幅下降。

2. 直接輸出 JSON / Markdown，少一個清洗步驟

NuExtract3 的設計重點不是「純 OCR」，而是「OCR + 結構化輸出」。實際測試時，你可以要求：
- 輸出 JSON：適合丟進程式、API、資料庫
- 輸出 Markdown：適合整理筆記、放進 Notion、Obsidian
例如你給他一張發票照片，提示可以這樣寫：
```
你是一個資料錄入助手。從這張發票中擷取欄位，並輸出 JSON：
{
  "date": "發票日期 (YYYY-MM-DD)",
  "vendor": "商家名稱",
  "invoice_number": "發票號碼",
  "items": [
    {"name": "品項名稱", "quantity": 數量, "unit_price": 單價, "amount": 金額}
  ],
  "subtotal": 小計,
  "tax": 稅額,
  "total": 總金額
}
如果沒有某個欄位，填 null。
```
輸出就會直接是可用的 JSON，不用再寫額外的字串處理把文字拆欄位。

3. 本地部署，自已控管資料隱私

NuExtract3 以「開源權重、自架」為主：
- 模型權重可下載，Apache-2.0 授權，可商用
- 可以在自己筆電、公司伺服器上跑
- 不需要把發票、合約等敏感文件上傳到第三方雲端
你可以先在官方 Hugging Face Space 線上試，用得順手再搬回本地。

線上 Demo（免註冊）：搜「NuExtract3」即可在 Hugging Face Spaces 上找到官方 Space。

💡 關鍵： 在合約、財務等敏感場景，自架 + 開源授權讓你既能自動化，又不必冒資料外流風險。

適合誰用：三個典型場景

1. 財務 / 行政：發票、報銷單半自動錄入

適用情境：
- 同事每個月丟一堆發票照片、PDF 報銷單
- 你要把日期、金額、商家、發票號碼一筆筆打進系統或 Excel
可以這樣用：
1. 把所有發票照片存進一個資料夾
2. 用腳本逐張丟給 NuExtract3，要求輸出統一格式的 JSON
3. 把 JSON 轉成 CSV，匯入到：
4. 公司報銷系統
5. Google Sheet 統計報表
立即可做的行動：
– 把你現有的 2–3 張發票/收據，丟進官方 Space，測試能不能抓出你要的欄位（日期/金額/店名）。

2. 自媒體 / 法務：整理掃描合約、條款重點

適用情境：
- 合作合約只有掃描版 PDF
- 你只關心「合約雙方」「金額」「期限」「解約條件」「付款節點」
你可以：
1. 把 PDF 上傳 NuExtract3
2. 用自然語言指定要的欄位，例如：
```
請閱讀這份合約，並用 JSON 回答：
{
  "party_a": "甲方名稱",
  "party_b": "乙方名稱",
  "contract_term": "合約期間（文字說明）",
  "payment_terms": "付款條件摘要",
  "termination_clause": "解約條款摘要"
}
```
1. 把輸出貼進 Notion，或丟給 ChatGPT / 其他 LLM 再做風險檢查
立即可做的行動：
– 找一份你平常會反覆查的合約掃描檔，試著用 NuExtract3 生成「合約摘要 Markdown」，看可讀性如何。

3. 數據分析師：報表、問卷結果結構化

適用情境：
- 手上有 PDF 報表、問卷紙本掃描
- 想要的，是一張可以直接做分析的表格
使用方式：
1. 對著一頁表格截圖
2. 提示要求輸出成「每列一筆紀錄」的 JSON 陣列
```
把這頁問卷結果表格，轉成 JSON 陣列，每列是一位受訪者：
[
  {
    "id": "編號",
    "age": 年齡,
    "gender": "性別",
    "q1": "問題1答案",
    "q2": "問題2答案"
  }
]
```
1. 把 JSON 轉成 CSV 後丟進 Python / R / Excel 分析
立即可做的行動：
– 拿一頁報表截圖，試著讓 NuExtract3 幫你還原成表格，再貼進 Google Sheet 看欄位是否正確。

怎麼開始：五分鐘上手路線

步驟 0：先線上玩一次（不用裝任何東西）
1. 打開瀏覽器，前往 Hugging Face Space（搜尋 NuExtract3）
2. 上傳一張發票 / 合約 / 表格截圖
3. 在「指令」欄位輸入你想要的輸出格式（JSON / Markdown + 欄位定義）
4. 看輸出結果是否符合你平常的工作需求
如果這步已經感覺能用，再考慮搬回本機或公司伺服器。

💡 關鍵： 先用線上 Demo 驗證「欄位抓得準不準」，再投入時間做 Docker 與腳本整合，能避免白做工。

步驟 1：在本機 / 伺服器用 Docker 跑起服務

以下是假設官方提供 Docker 映像的典型流程（實際請以官方 README 為準）：
```
# 1. 拉取映像
docker pull numind/nuextract3:latest

# 2. 啟動服務（假設開在 8000 port）
docker run -d \
  --gpus all \
  -p 8000:8000 \
  --name nuextract3 \
  numind/nuextract3:latest
```
啟動後通常會有一個簡單 API，例如：
```
curl -X POST http://localhost:8000/extract \
  -F "file=@invoice.jpg" \
  -F 'prompt=請擷取發票資訊並輸出 JSON，欄位：date, vendor, total_amount'
```
回傳的就是 JSON 結果，可以直接被腳本處理。

步驟 2：用簡單 Python Script 跑推論

如果你偏好直接在 Python 裡呼叫（例如透過 vLLM / Transformers），典型流程會像這樣（範例示意）：
```
from PIL import Image
import requests
import json

API_URL = "http://localhost:8000/extract"

image_path = "./samples/invoice.jpg"
prompt = "請從這張發票擷取日期(date)、商家(vendor)、總金額(total_amount)，並輸出 JSON。"

files = {"file": open(image_path, "rb")}
data = {"prompt": prompt}

resp = requests.post(API_URL, files=files, data=data)
result = resp.json()

print(json.dumps(result, ensure_ascii=False, indent=2))
```
這段可以直接嵌入到你現有的報表處理、RPA 流程裡。

步驟 3：自訂你的欄位 schema

NuExtract3 沒有「固定欄位」，而是靠你的提示（prompt）決定要萃取什麼。實作時可以：
1. 先在 Notion / Google Sheet 寫好你要的欄位列表，例如：
2. date
3. vendor
4. category
5. subtotal
6. tax
7. total
8. 在提示裡把這些欄位寫成 JSON 模板，明確說明格式
9. 要求：
10. 用固定欄位名稱
11. 金額用數字，不要加貨幣符號
12. 缺失欄位填 null
這樣輸出就更穩定，後續程式處理也比較不容易爆炸。

步驟 4：組一個簡單 workflow：NuExtract3 + Google Sheet / Notion

你可以很快做出一個「半自動錄入」流程：

發票例子：
1. 把所有發票照片放進 invoices/ 資料夾
2. 用 Python 跑一個簡單批次處理：
3. 逐張呼叫 NuExtract3 API
4. 收集 JSON 結果
5. 把 JSON 轉成 CSV：
6. 用 pandas 寫入 Google Sheet（透過 Google API）
7. 或匯出 CSV 手動上傳
概念範例：
```
import os, json, requests, csv

API_URL = "http://localhost:8000/extract"

rows = []
for fname in os.listdir("./invoices"):
  with open(os.path.join("./invoices", fname), "rb") as f:
    resp = requests.post(
      API_URL,
      files={"file": f},
      data={"prompt": "請輸出 JSON，欄位：date, vendor, total_amount"}
    )
  data = resp.json()
  rows.append([data["date"], data["vendor"], data["total_amount"]])

with open("invoices.csv", "w", newline="", encoding="utf-8") as fp:
  writer = csv.writer(fp)
  writer.writerow(["date", "vendor", "total_amount"])
  writer.writerows(rows)
```
Notion 的話，則可以用 Notion API 建立資料庫頁面，把每一筆 JSON 轉成一筆資料列。

小結：什麼時候值得用 NuExtract3？
- 你有大量掃描檔、截圖要轉成結構化資料
- 內容多是表格、發票、收據、合約這類「格式固定但樣式雜」的文件
- 你在意 資料不能丟到雲端，希望自架
先在 Hugging Face Space 玩 10 分鐘，如果覺得可用，再花半天把 Docker + 簡單腳本接起來，你就多了一個專門幫你「把亂檔變乾淨資料」的本地工具。
🚀 你現在可以做的事
- 上 Hugging Face 搜尋 NuExtract3，用 2–3 張發票或表格截圖測試輸出 JSON / Markdown
- 在 Notion 或 Google Sheet 列出你常用的欄位 schema，順手寫一個對應的 prompt 模板
- 在本機用 Docker 跑起 nuextract3，照文中的 curl 或 Python 範例打一次 API，驗證能否接到現有流程
2026 年 5 月 26 日

Needle：把工具調用 Agent 塞進手機

📌 本文重點

Needle 是專門負責工具選擇與參數填充的小型中控模型

能在手機級硬體離線、高吞吐運行，降低雲端大模型成本

最適合當工具路由器 / 前置規劃器，輸出穩定 JSON 給其他系統

Needle 就是一顆專門幫大模型「只負責選工具、組參數、吐 JSON」的超小中控腦，讓工具調用 Agent 能在手機級硬體離線或低延遲運作。

原始專案在 GitHub：https://github.com/cactus-compute/needle

核心功能：專心當「工具路由中樞」的 26M 模型

1. 26M 參數 + 純 Attention：為工具調用瘦身

Needle 的設計很直接：

只有約 2600 萬參數（26M），比動輒數十億參數的聊天模型小一到兩個數量級。
結構是 Simple Attention Network：只有 attention + gating，沒有 MLP/FFN 層。
目標任務只有一件事：
讀取指令 + 工具列表描述
選擇要用哪個工具（或多個）
從指令中抽出參數
輸出工具調用 JSON

💡 關鍵： 只有約 2600 萬參數的 Needle，能在極小成本下專門負責工具路由與參數抽取，是取代通用大模型做 function calling 決策的關鍵。

這代表你的行動步驟是：

如果你現在是用 GPT / Gemini / Claude 來做工具決策（例如 function calling），可以把「決定用什麼工具」這一步改交給 Needle，減少大模型 token 消耗與延遲。

2. 專門為工具調用預訓與微調

Needle 的訓練重點不是聊天對話，而是「工具使用」：

先在 200 億 token 上預訓練語言能力。
再用約 20 億條合成函數調用資料微調，來源是模擬 Gemini style 工具（例如鬧鐘、導航、日曆、筆記等）。

💡 關鍵： 針對 20 億條函數調用資料微調，讓 Needle 在工具選擇與參數解析上比同尺寸聊天模型穩定得多。

實際上，它不負責長篇推理，而是非常擅長：

從口語指令中抓出結構化欄位（時間、地點、標題…）。
在多個工具之間做正確匹配。
輸出符合 schema 的 JSON 給你直接丟進 API。

行動建議：

如果你已經有一組工具 schema（例如 OpenAPI、function calling 定義），可以直接拿來給 Needle，讓它幫你產生調用 payload，再由你自己的程式實際發 API。

3. 手機級硬體也能跑的高吞吐

作者實測在「消費級裝置」可達：

約 6000 tok/s prefill
約 1200 tok/s decode

💡 關鍵： 在一般消費級裝置上就能達到 6000 tok/s prefill、1200 tok/s decode，讓 Needle 可以長駐於手機與邊緣設備當本地 Agent 大腦。

翻成白話：

放在中階手機、平板、開發板（如樹莓派級別 SoC）上，當離線工具路由器是可行的。
可以把 Needle 當作 永遠常駐的本地 Agent 大腦，大模型只在真正需要複雜推理／生成時才被叫起。

行動建議：

如果你正在做行動 App 或智慧硬體（耳機、車機、家電），可以先用 Laptop 上測試 Needle 的工具選擇邏輯，再評估移植到裝置端做本地推理。

適合誰用：三種典型場景

1. 行動裝置上的離線 / 低延遲 Agent

典型案例：

「早上 7 點幫我叫醒，順便播固定歌單」→ Needle 決定：set_alarm + play_playlist
「開車回家，避開高速公路」→ Needle 決定：navigate，並填好目的地與偏好
「幫我記一條：明天 meeting 要問預算」→ Needle 決定：create_note，抽出時間與內容

做法：

語音 → 本地 ASR（或雲端 Transcription）
文字指令 + 工具列表 → Needle → 工具 JSON
裝置端程式依 JSON 實際調起鬧鐘、導航、筆記 App

適合：行動 App 團隊、智慧手錶 / 車機 / AR 眼鏡、想要弱網路或離線也能用的指令助手。

2. 雲端大模型前面加一層「本地工具路由器」

你可能遇過這種成本問題：

每個使用者點一個按鈕，就丟完整上下文給 GPT 讓它幫你：
看要不要查資料庫
看要不要 call search API
看要不要調 CRM
結果大部分情況都只是在查一個欄位，卻要跑一整輪大模型推理。

用 Needle 可以：

由 Needle 先判斷：這次是否需要工具？用哪個？
只有當需要長推理 / 文本生成時，才叫雲端 LLM。

這樣能直接對應到多代理系統常被提到的「orchestration tax」問題：減少不必要的 LLM orchestration 回合數。

適合：SaaS 後端、API 產品、任何大量使用 function calling 的服務，希望降成本 + 降延遲。

3. MCP / Function Calling 之前的一層「前置規劃器」

如果你已經在用：

OpenAI / Gemini / Claude 的 Tool Use / Function Calling
或是某種 MCP（Multi-Channel Prompting 或 Model Context Protocol）架構

Needle 可以扮演：

用戶輸入 → Needle 選擇：
要走哪一條 MCP channel
要用哪個 Function / Tool
再把整理好的工具調用意圖，交給聊天模型做：
實際回應文案
或進一步分解子任務

差別在於：

一般微型聊天模型：
會嘗試「理解＋回答＋決定工具」，但在複雜工具 schema 上容易出錯或 hallucinate。
Needle：
不負責聊天，只專注在「選工具＋填參數＋吐 JSON」。

適合：已經有多工具、多 Agent 架構的團隊，需要一個可控、可本地跑的規劃器 / 路由器。

Needle vs 一般微型聊天模型

名稱	核心功能	免費方案	適合誰
Needle	工具選擇＋參數抽取＋輸出 JSON	完全開源，自架	行動 App、硬體端、本地 Agent
微型聊天模型	閒聊、簡單問答	多數可免費測試	想要基本對話、不重工具調用的人

關鍵差異：

Needle 的輸出預期是結構化工具調用，不是自然語言回答。
在工具 schema 清楚的情況下，Needle 通常比同尺寸聊天模型更穩定地填參數、遵守格式。

行動建議：

若你只需要「會聊天」：選一般微型聊天模型。
若你需要「穩定地依 schema 呼叫工具」：可以試 Needle 當前置規劃器，再用大模型生成回覆文案。

怎麼開始：從 clone Repo 到跑出第一個工具調用

1. 抓下專案與模型

# 1. clone repo
git clone https://github.com/cactus-compute/needle.git
cd needle

# 2. 建議先建立虛擬環境
python -m venv .venv
source .venv/bin/activate  # Windows 用 .venv\Scripts\activate

# 3. 安裝依賴
pip install -r requirements.txt

模型本體會在首次推理時自動下載（或依 README 指示手動下載權重）。

2. 用現成推理腳本跑官方 demo

Repo 裡提供了簡單的推理範例（實際檔名可能隨版本變動，可在 examples/ 或 README 中找到）：

python examples/simple_tool_calling.py

通常你需要提供：

工具 schema（JSON / Python dict）
使用者指令文字

腳本會回傳一段包含工具名稱與參數的 JSON，確認能跑通是第一步。

行動建議：

先照官方 demo 跑一遍，不改任何 schema，只看 Needle 如何選工具。

3. 定義自己的工具 schema

假設你要做一個簡單的鬧鐘 + 記事 Agent，可以這樣定義工具（示意）：

tools = [
  {
    "name": "set_alarm",
    "description": "設定鬧鐘時間（24 小時制）",
    "parameters": {
      "type": "object",
      "properties": {
        "time": {"type": "string", "description": "例如 07:30"},
        "label": {"type": "string", "description": "鬧鐘備註"}
      },
      "required": ["time"]
    }
  },
  {
    "name": "create_note",
    "description": "建立一則文字筆記",
    "parameters": {
      "type": "object",
      "properties": {
        "title": {"type": "string"},
        "content": {"type": "string"}
      },
      "required": ["content"]
    }
  }
]

接著丟給 Needle：

from needle import NeedleModel

model = NeedleModel.from_pretrained("cactus/needle-base")

user_query = "明天早上七點叫我起床，順便幫我記：早會要問預算"

result = model.route_tools(query=user_query, tools=tools)
print(result)

預期會拿到類似：

[
  {
    "tool": "set_alarm",
    "arguments": {"time": "07:00", "label": "早會"}
  },
  {
    "tool": "create_note",
    "arguments": {"title": "早會", "content": "早會要問預算"}
  }
]

接下來只要用你熟悉的語言（Swift / Kotlin / Node / Python），依這個 JSON 實際呼叫 OS API 或雲端 API 即可。

4. 把 Needle 接在現有 LLM 後面，做一條簡單 workflow

以下是一條最小可行的 workflow（伪碼）：

語音 → 文字
行動裝置用本地或雲端 ASR：
speech.wav -> transcript = "幫我找台北明天不下雨的戶外咖啡廳"
Needle 選工具
工具例：search_weather, search_places 兩個 API。
needle.route_tools(transcript, tools) → 回傳要先查天氣再查地點的參數 JSON。
實際 API 呼叫
你的後端或 App 依 Needle 給的 JSON，分別呼叫天氣 API、地點 API，整理出可用候選。
大模型生成回覆（可選）
把 API 結果 + 原始指令送給 GPT / Gemini / Claude，只讓它負責自然語言回覆：「幫你找到三間明天不預測下雨的咖啡廳…」。

這種分工方式：

Needle：做工具決策＋參數解析
LLM：只在真正需要「說人話」的最後一步出現

能同時達到：成本可控、延遲更低、邊緣裝置也能預先處理大量決策。

適合誰現在就試用 Needle？

行動 App 開發者：想做語音指令、快捷操作、離線助手，又不想每次都打雲端 LLM。
硬體產品團隊：智慧手錶、車機、家電、AR 眼鏡，需要一顆小而穩定的本地「工具路由中樞」。
個人自架 Agent 系統玩家：已經有多工具、多 Agent，正在煩惱 orchestration 成本和延遲的人。

只要你場景的核心在「選工具＋填參數」，而不是長篇聊天，Needle 值得你花一個下午跑起 demo，直接把它塞到你的 workflow 裡測一次。更多細節與最新腳本可以在 GitHub 查看：https://github.com/cactus-compute/needle

🚀 你現在可以做的事

先 clone Needle 專案並跑一次官方 demo：git clone https://github.com/cactus-compute/needle.git

把你現有的 function calling / OpenAPI schema 丟給 Needle，觀察它產生的工具 JSON

在一個實際專案裡，嘗試用 Needle 接在 ASR 和雲端 LLM 之間，實測延遲與成本差異

2026 年 5 月 14 日

用 goose AI Agent 開一隻全能小幫手
📌 本文重點
- goose 是用 Rust 寫的開源 AI Agent 框架
- 讓 LLM 真的能跑指令、改檔案、寫測試而不只聊天
- 可接任意 LLM，並透過 workflow 自動化多步驟任務
- 很適合 DevOps / 開發者做日常開發與部署自動化
用一句話說清楚：goose 是一個用 Rust 寫的開源 AI Agent 框架，可以讓 LLM 不只聊天，而是真的幫你在電腦上安裝套件、跑指令、改程式碼、寫測試，變成一個可以自動執行任務的「全能小幫手」。

GitHub 專案：https://github.com/aaif-goose/goose

goose 和一般聊天機器人有什麼不同？

一般 ChatGPT / Claude 類工具，多半停在「給你建議」：
- 產生程式碼片段
- 幫你想測試案例
- 告訴你下一步可以怎麼做
goose 的差別在於：它可以自己動手做。

透過 goose，你可以讓模型：
- 在你的環境裡 執行殼層指令（shell commands）
- 直接修改專案檔案、重構程式碼
- 跑測試、根據結果再修正
- 用 plugin / tool 的形式接上你自己的 API 或腳本
換句話說，它比較像一個「可編程的 AI 工具人」，而不是純聊天機器人。

💡 關鍵： goose 不只回覆文字，而是能在你的實際環境中「讀檔案、下指令、改程式」，真正把建議變成動作。

核心功能：你可以拿 goose 來做什麼？

1. 調用殼層指令：讓 LLM 幫你按命令行上的按鈕

goose 內建「可以執行 shell 指令」的能力。

你可以叫 agent 做這些事：
- 安裝套件：apt-get, brew, pip, cargo…
- 拉專案：git clone、切分支、pull 最新版
- 跑工具：npm test、cargo test、pytest、make build
你要做的行動：
- 想一件你平常常打的一串指令（例如部署前要跑的 3–5 個步驟）
- 把它寫成一句自然語言任務，交給 goose，觀察它如何自己拆解並下指令
2. 程式碼編輯與測試：真的會改你專案的那種

goose 支援對檔案系統操作，讓 LLM 直接：
- 開啟 / 讀取專案中的檔案
- 修改檔案內容（插入、刪除、重構）
- 新增測試檔、更新 README
常見用法：
- 讓 agent 自動幫你 加 log / exception handling
- 要它針對某個 module 補齊單元測試
- 改 config、更新版本號、調整 CI 設定檔
你要做的行動：
- 選一個「可以放心被 AI 改壞」的小 side project
- 用 goose 給它一個任務，例如：「在這個 Rust 專案裡，新增一個 health check endpoint，並幫我補上測試」
3. 自訂工具擴充：把你自己的腳本、API 變成 agent 的能力

goose 的設計重點是 「可擴充的工具」。你可以：
- 把現有的 Python / Bash 腳本包裝成一個 tool
- 把團隊內部 API（如 issue tracker、部署服務）接進來
- 讓 agent 用「呼叫工具」的方式，連續完成更複雜的流程
實際效果：
- LLM 不用自己「想像」怎麼部署，而是呼叫你提供的 deploy_api
- 你可以限制它只能用你認可的工具，控制風險
你要做的行動：
- 列出你工作中最常手動跑的 2–3 個腳本
- 想像它們如果變成一個 deploy_service / create_release 的工具，agent 可以怎麼自動串起來
4. 接任意 LLM：OpenAI、DeepSeek、本地模型都行

goose 標榜 「with any LLM」，實際上就是可以在設定中自由切換 backend：
- OpenAI（如 gpt-4.1）
- DeepSeek API（如 deepseek-coder）
- 透過 OpenAI-compatible API 的本地模型（Ollama、LM Studio…）
這讓你可以：
- 開發時用免費 / 便宜模型測試流程
- 上線到正式環境時再換成更穩定的雲端模型
你要做的行動：
- 先挑一個你現有就有 API Key 的 LLM（例如 OpenAI 或 DeepSeek）
- 決定：
- 「實驗階段」用哪個模型
- 「正式跑自動化」時要不要升級到較貴的模型
💡 關鍵： 透過切換 GOOSE_MODEL 等設定，你可以在成本（本地 / 便宜模型）與效果（雲端高階模型）之間彈性取捨。

適合誰用？三種典型場景

1. DevOps／SRE：日常腳本自動化

例如：
- 部署前：拉最新程式碼 → 跑測試 → build → health check
- 緊急修補：切 branch → 套 patch → 跑 smoke test → 發一版 hotfix
用 goose 的做法：
- 把這些步驟包成一個「任務腳本」（workflow）
- 讓 agent 自己決定下一步要跑哪個指令、根據輸出結果調整
2. 開發者：專案 boilerplate 生成與重構

適用情境：
- 開一個新服務：想要快速產生「專案骨架 + 基本路由 + CI 檔案」
- 老專案：想系統性把某種寫法換成新的 pattern
用 goose 可以這樣玩：
- 指定專案資料夾給 agent
- 給一個任務：「初始化一個 NestJS API 專案，幫我加上 Dockerfile 和 GitHub Actions CI」
3. 團隊工程流程：CI 前自動檢查與修修補補

在 CI 跑之前，先讓 goose 幫你：
- 檢查程式格式、lint 問題
- 嘗試自動修正簡單的錯誤
- 對 PR 產生簡短變更說明
做法：
- 在 CI pipeline 裡加入「goose agent 步驟」
- 給它權限在 CI runner 上修改檔案並 push（或開新 PR）
💡 關鍵： 把 goose 放進 CI / pre-commit，可以在錯誤進到主線分支之前，自動完成一輪整理與簡單修補。

怎麼開始：最快速的上手路徑

1. 用 Docker 跑起官方範例（最快測試）

前提：
- 已安裝 Docker
- 手邊有一個 LLM API Key（例：OPENAI_API_KEY）
步驟：
```
# 1. 拉專案
git clone https://github.com/aaif-goose/goose.git
cd goose

# 2. 建一個 .env，放你的模型設定（簡化示意）
cat << 'EOF' > .env
OPENAI_API_KEY=your_key_here
GOOSE_MODEL=openai/gpt-4.1
EOF

# 3. 用 docker compose 跑起來（實際以 repo 裡的 compose 指令為準）
docker compose up --build
```
跑起來後，通常會有：
- 一個 CLI / HTTP 介面
- 你可以丟：
- 「在這個容器裡安裝 curl 並測試對 google.com 發送請求」
行動建議：先在容器內做「無害」的事情，例如安裝一個套件、建立一個測試檔案，確認 goose 真的有在動你環境。

2. 本機安裝（Rust 使用者）

前提：
- Rust toolchain（rustup）
步驟：
```
# 1. 安裝依賴
cargo install --path .  # 實際請以 README 為準

# 2. 設定環境變數
export OPENAI_API_KEY=your_key_here
export GOOSE_MODEL=openai/gpt-4.1

# 3. 跑 CLI
goose run
```
你可以在終端機裡對 agent 下指令，例如：
- 「列出目前資料夾的檔案，幫我找出所有含有 TODO 的檔案並列出行號」
3. 接上常見模型（OpenAI / DeepSeek / 本地 LLM）

以下是假設性的設定方向（實際請對照 goose README）：

OpenAI
```
export OPENAI_API_KEY=your_key
export GOOSE_MODEL=openai/gpt-4.1
```
DeepSeek

通常會提供 OpenAI 相容 API：
```
export OPENAI_BASE_URL=https://api.deepseek.com/v1
export OPENAI_API_KEY=your_deepseek_key
export GOOSE_MODEL=deepseek-chat
```
本地 LLM（以 Ollama 為例）

啟動 Ollama 後：
```
export OPENAI_BASE_URL=http://127.0.0.1:11434/v1
export OPENAI_API_KEY=dummy
export GOOSE_MODEL=ollama/llama3.1
```
行動建議：先用最簡單、你現在就有的 API Key 接上，確認 goose 的流程跑得通，再考慮搬到本地模型節省成本。

寫一個自己的「任務腳本」：讓 agent 連續完成幾個步驟

goose 的強項在於可以定義「多步驟任務」。概念上，你會有一個 workflow 設定（格式依官方為準，這裡用 pseudo-code 示意）：
```
# workflows/dev_check.toml
name = "dev_precommit_check"

[[steps]]
type = "shell"
command = "git status"

[[steps]]
type = "agent"
prompt = "閱讀 git status，決定要先格式化哪一些檔案，並執行對應指令。"

[[steps]]
type = "shell"
command = "cargo test"

[[steps]]
type = "agent"
prompt = "根據測試結果，如果有簡單錯誤可以直接修，並再次執行對應測試。"
```
用法：
```
goose run-workflow workflows/dev_check.toml
```
這樣，你可以一行命令啟動一個「會看情況調整動作」的前置檢查流程。

你要做的行動：
- 先定義一個超簡單的 workflow：
- Step1：ls 專案
- Step2：請 agent 根據專案結構生成一段簡短說明，寫入 PROJECT_SUMMARY.md
實戰：從零做一個小型自動化 workflow

目標：在一個現有專案裡，做「提交前自動整理 + 簡單修補」流程。

我們要達成：
1. 檢查目前分支變更檔案
2. 對變更檔案跑 formatter / linter
3. 如果有明顯錯誤，由 agent 嘗試自動修改
4. 重新跑測試
Step 1：準備專案與權限
1. 找一個你熟悉、可以接受被改動的專案資料夾
2. 新開一個分支，如 feat/goose-auto-fix
3. 確保 goose 有權限：
4. 讀寫這個資料夾
5. 執行必要的指令（例：npm test、cargo test）
Step 2：定義 workflow（示意）

依 goose 支援的格式建立一個 workflow 檔（假設是 YAML）：
```
name: precommit-helper
steps:
  - type: shell
    command: git diff --name-only
  - type: agent
    prompt: |
      你看到的是目前分支有變更的檔案清單。
      目標：
      1. 對這些檔案執行合適的 formatter / linter 指令（依照檔案類型判斷）。
      2. 若 formatter/linter 回報可自動修復的問題，請修改檔案並重新執行檢查。
  - type: shell
    command: npm test  # 或你專案的測試指令
  - type: agent
    prompt: |
      根據測試輸出，
      - 若是小型邏輯／型別錯誤，嘗試修改相關檔案後再次執行測試。
      - 若錯誤較複雜，請產生簡短說明寫入 precommit_report.md。
```
Step 3：實際執行與調整
1. 在專案根目錄跑：
bash goose run-workflow precommit-helper.yaml
1. 觀察它的行為：
2. 有沒有亂跑你不想要的指令？
3. 修改的檔案是否合理？
4. 根據結果調整：
5. 限制能用的指令範圍（例如只允許 npm test, npm run lint）
6. 在 prompt 裡多加一些「安全護欄」，例如「不要刪除檔案」。
完成後，你就有了一個：
- 可以在提交前幫你「整理 + 修補 + 產生報告」的小型 AI 助理
- 海豚式改進：遇到痛點就稍微改一下 workflow / 工具清單，越用越貼近你團隊習慣
小結：下一步可以怎麼玩？

如果你看到這裡，建議接下來這樣走：
1. 先跑官方範例容器一次，確認 goose 在你機器上可以正常跑指令。
2. 選一個專案資料夾，做一個超小 workflow：只做檔案摘要或自動補 README。
3. 把你現有的一個腳本包成 tool，讓 agent 可以呼叫（例如部署或打包腳本）。
4. 等你有信心後，再把它接進 CI / pre-commit 流程。
完整專案與最新用法請看：https://github.com/aaif-goose/goose

把 goose 想成一個「可編程的 ChatGPT + 指令列機器人」，先從最小、風險最低的自動化開始，你會很快找到適合自己工作流的用法。
🚀 你現在可以做的事
- 打開 <https://github.com/aaif-goose/goose>，用 Docker 照著 README 跑一次官方範例
- 選一個 side project，讓 goose 幫你完成「新增一個 endpoint + 補上測試」的小任務
- 把日常最常用的一個部署或檢查腳本包成 tool，寫一個只包含 2–3 個步驟的簡單 workflow
2026 年 5 月 9 日

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

📌 本文重點

TrendRadar 幫你每天自動整理「值得在意的事」

透過多平台聚合 + AI 翻譯與情感分析過濾雜訊

可與 ChatGPT/Claude 分工整合，從監控到決策一條龍

開源專案，支援 Docker 快速自架部署

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

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

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

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

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

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

你可以這樣實際操作：

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

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

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

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

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

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

具體可以怎麼用：

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

實際行動：

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

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

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

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

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

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

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

實際可做的 workflow：

TrendRadar 把今天跟品牌相關的負面事件整理成一份 JSON / 簡報式摘要。
在支援 MCP 的 AI 助手中，呼叫 TrendRadar 工具：「請分析今天的負面輿情，幫我寫一份回應策略與 Q&A 草稿」。
得到可以直接丟給 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 草稿、簡報大綱、內容腳本

操作示例：

在 Slack 接收 TrendRadar 的每日報告。
把報告內容複製到 ChatGPT：
指令範例：「請依照這份 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. 設定第一組關鍵字與訂閱來源

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

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

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 摘要接進來，明天早上開始用它看「今天在吵什麼」

2026 年 4 月 27 日

用 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 的非關鍵實驗步驟
2026 年 4 月 27 日

標籤: 免費 AI 工具推薦

核心功能：從文字到 CAD 程式碼

1. 兩種模式：參數化建模 vs 網格生成

2. 滑桿調參 + 文本修改：像寫程式一樣調零件

3. Text → Code：產出可讀的 OpenSCAD

適合誰用？三個具體場景

1. 機構工程師：快速打樣支架 / 夾具

2. 3D 列印工作室：一次生成多尺寸版本

3. 軟體工程師：用文字產出可讀 CAD

怎麼開始：雲端體驗到本機部署

1. 直接在線上玩 Demo（最快）

2. 在本機部署開源 CADAM

3. 接到 OpenSCAD / CAM / 生產流程

3.1 接 OpenSCAD

3.2 接 CAM / CNC / 3D 列印

小結：下一步可以做什麼？

核心功能：現在的 NotebookLM 到底多了什麼？

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

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

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

適合誰用：三個具體場景

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

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

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

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

步驟 1：開啟 NotebookLM

步驟 2：建立第一本 Notebook

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

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

模板 1：快速總整理

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

模板 3：資料 + 程式分析

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

核心功能：小模型，靠好資料撐起來

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

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

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

適合誰用：三個典型場景

1. App 圖標與 UI 草圖

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

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

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

路線 1：完全不寫程式，先用 Hugging Face Demo Space

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

1. 安裝必要套件

2. 下載並載入 Lens 模型

3. 快速包一個本機 API（Flask 範例）

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

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

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

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

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

適合誰用？3 個具體場景

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

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

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

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

優點

限制與風險

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

1. 快速開通與入口

2. 哪裡能免費用到？

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

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

核心功能：先讓 Mellum2 當你的「AI 排班主管」

1. 低延遲的小模型，適合做決策層

2. 多步推理：讓它負責拆任務、串工具

3. Routing + 工具選擇：讓 GPT、Claude、開源 LLM 都變成「插件」

可以這樣設計一個簡單策略

適合誰用：三種典型場景

1. 你在做「AI 助手」或 Agent 系統

2. 你有多個 LLM 供應商，要壓成本又要穩定

3. 你要做「穩定的 AI Pipeline」而不是單次聊天

怎麼開始：從安裝到最小可行範例

1. 安裝 Mellum2：Docker 或程式庫二選一

選項 A：用 Docker 跑起 Mellum2 服務

選項 B：在程式裡直接呼叫 Mellum2

2. 示範：Mellum2 做 Router + 任務規劃的最小 workflow

Step 1：定義給 Mellum2 的「工具/模型清單」

Step 2：設計 Mellum2 Prompt，請它輸出「計畫 JSON」