標籤: AI 工具

  • 96 個 Gemini Agent 幫你寫系統?

    96 個 Gemini Agent 幫你寫系統?

    📌 本文重點

    • 多 Agent 可複製「多人分工」開發流程
    • Runtime 設計比單純換更大模型更關鍵
    • 用開源工具就能打造迷你版 Antigravity

    用一群 Agent 代替「一個工程師慢慢寫」,解決的是:複雜專案要靠多人分工,AI 也可以用 Runtime + 多代理系統做到同樣的協作和自動化。

    核心觀念先講白:模型戰爭差不多打完了,現在比的是誰的 Agent Runtime 能把「模型能力」變成可落地的、多步驟的自動化工作流。

    Google 在 I/O 上展示的 Antigravity 2.0 + Gemini 3.5 Flash 是一個很極端的例子:

    • 96 個子代理分工
    • 12 小時寫完一套從零開始的作業系統
    • Token 成本不到 1,000 美金
    • OS 還能跑《Doom》

    💡 關鍵: 多代理 + 強 Runtime 已經能在「12 小時、不到 1,000 美金」內完成從零開發 OS,顯示關鍵瓶頸不再是模型本身,而是協作與流程設計。

    這不是叫你明天也去做一個 OS,而是提供一個「如何設計多 Agent 開發流程」的範本。下面我們拆成三件你可以直接抄的事:

    1. 多代理分工設計:任務 → 子任務 → Agent 編隊
    2. 強健 Runtime:重試、檢查點、錯誤恢復
    3. 平價版本實作:在你自己的專案做一個「迷你 Antigravity」

    核心功能:Antigravity 2.0 給開發者的三個啟示

    1. 多代理分工:任務 → 子任務 → Agent 編隊

    Antigravity 的做法,其實很像你帶一個遠端工程團隊:

    • 架構師 Agent:決定 OS 的模組切分(檔案系統、排程、驅動、UI…)
    • 模組作者 Agent:各自負責某一個模組的程式碼生成
    • 測試員 Agent:寫測試、跑測試、收斂錯誤
    • 整合者 Agent:把各模組組合、處理相依性、打包成可啟動的系統

    對你來說,可直接套用成一個通用流程:

    1. 寫一個頂層任務描述
      例:建立一個 RESTful CRUD 服務,管理任務(待辦事項),含 API、DB schema、簡單前端。

    2. 讓「架構師 Agent」自動拆解:

    3. API 設計與 OpenAPI spec

    4. 後端框架與資料庫層
    5. 前端 UI
    6. 測試與 CI script

    7. 為每個子任務設計 Agent 角色:

    8. api-architect-agent:只產出 API spec

    9. backend-agent:根據 spec 產生程式碼
    10. frontend-agent:負責 UI
    11. tester-agent:生成並執行測試
    12. integrator-agent:檢查專案結構、跑 build / lint

    13. 在 Runtime 中定義工作流:

    14. 任務圖(DAG):架構師 → 模組作者 → 測試員 → 整合者

    15. 每個節點定義輸入/輸出檔案、工具(Git、DB、HTTP client)

    可行動步驟:

    • 選一個你熟的框架(例如 FastAPI / Next.js)
    • 用自然語言寫清楚「最終可交付物」
    • 為這個專案定義 3–5 個 Agent 角色,明確限制各自輸入輸出

    2. Runtime 比模型重要:90% 成功率在多步任務會變災難

    多步任務有一個殘酷數學:

    • 假設每一步成功率 90%
    • 要跑 20 步,整體成功率 ≈ 0.9^20 ≈ 12%

    💡 關鍵: 即使單步有 90% 成功率,20 步工作流成功率只剩約 12%,所以不加 Runtime 管控,多步任務幾乎註定失敗。

    這就是為什麼像 Forge 這種開源 guardrails 會被重視:作者實測,一個 8B 模型在多步代理任務上,從 53% 提到 99% 成功率,完全不改模型,只改 Runtime。

    你在自己的「迷你 Antigravity」裡,要做三件事:

    1. 重試與 nudging

    2. 為每個步驟設 max_retries(例如 3 次)

    3. 失敗時自動加上「修正提示」,例如:上一步測試失敗,錯誤訊息如下,請修正而不是重寫整檔。

    4. 檢查點(checkpoint)

    5. 每完成一個重要子任務,就把中間產出存到 Git / DB

    6. 失敗時從最近的檢查點重跑,而不是重頭來

    7. 錯誤恢復流程

    8. 專門的 debug-agent:只看錯誤訊息 & log,產出修復建議

    9. Runtime 層做:自動建立 bug report、開 issue、指派給對應 Agent

    如果你用 Forge,它已內建:

    • Tool-agnostic 重試策略
    • 步驟執行強制與錯誤恢復
    • VRAM-aware context 管理(對本地模型很重要)
    • 評估套件與 Dashboard,可量化成功率

    可行動步驟:

    • 先把現有「單 Agent 自動流程」改成有重試與 checkpoint
    • 對每個任務記錄:總步數、失敗點、重試次數,在 Dashboard 裡看瓶頸

    3. 平價版本:你也能做一個「迷你 Antigravity」

    你不需要 Gemini 3.5 Flash + Google 內部 Runtime 才能玩多 Agent。下面這些工具可以在自家專案做一個縮小版:

    名稱 核心功能 免費方案 適合誰
    Forge 多步代理 guardrails、重試、Dashboard 開源 想提升本地 / 自架 LLM 可靠性的工程師
    llama.cpp + Qwen 本地 Agent 在個人電腦跑本地模型 + 簡易工具調用 開源 想省雲端費用、在內網跑 Agent 的團隊
    MCP 生態(如 OpenAI MCP、各種 server) 統一的工具協議,讓 Agent 調用資料庫、API 等 多數開源 / 免費 想把既有系統暴露為 Agent 工具的後端工程師

    一個實用組合示例:

    • 模型:Qwen 2.5 7B / 14B(透過 llama.cpp 或 Ollama 跑)
    • Runtime:Forge 當 guardrails
    • 工具層:一組 MCP server(例如 PostgreSQL、HTTP、Filesystem)

    你可以先做一個「自動搭建 CRUD 服務」的迷你 Antigravity:

    1. 使用者輸入需求(自然語言)
    2. architect-agent 產出設計 + 任務拆解
    3. backend-agent + frontend-agent 寫程式碼
    4. tester-agent 自動開發 & 執行測試
    5. integrator-agent 跑 build 並回報狀態

    適合誰用:三種典型場景

    1. 後端 / 全端工程師:自動化 CRUD 小專案

    你可以把「打造新微服務」變成一個表單:

    • 輸入資料模型 + 幾個業務規則
    • 多 Agent 流程負責 scaffold、API、測試、docker-compose

    行動:從一個只需要 3–5 小時就能手刻完的小服務開始,先讓多 Agent 幫你做到 70–80%,你只負責 code review。


    2. 資料團隊:資料管線與 ETL 任務

    • planner-agent:解析需求、拆成抽取/轉換/載入步驟
    • sql-agent:產生查詢與 view
    • check-agent:比對 row count、品質指標

    行動:挑一個每天都在重複手動跑的 ETL 任務,做成標準流程,讓 Agent 幫你自動生成 SQL + 驗證報表。


    3. 產品 / PM:快速驗證 Side Project

    • 搭配 Gemini 3.5(雲端)或本地 LLM
    • 定義一個「最小可行功能」(例如 landing page + 簡單 API)
    • 用多 Agent 完成第一版,再丟給工程師接手

    行動:每次新點子,給自己一個規則:「先讓多 Agent 寫一版 Demo,我只在最後 2 小時調整。」


    怎麼開始:一個最小可行範例

    這裡給一條「3–5 小時內可完成」的路線,你可以直接照做:

    步驟 1:選模型 + Agent 框架

    • 模型:
    • 想省錢/本地:Qwen 2.5 7B(透過 llama.cpp 或 Ollama)
    • 想雲端無痛:Gemini 3.5 Flash(透過 Google AI Studio)
    • Runtime / 框架:
    • 想要 guardrails:裝 Forge
    • 想用現成 MCP:選一個支援 MCP 的 Agent 框架(如 OpenAI 官方 Agent SDK)

    步驟 2:挑一個小系統

    條件:

    • 單服務、沒有第三方整合
    • 你自己寫大約 3–5 小時能完成

    例:任務管理 CRUD API + 簡單 React 前端

    步驟 3:設計任務拆分與 Agent 角色

    1. 任務描述寫成一個 markdown 檔(會給 architect-agent 看)
    2. 在 Runtime 中註冊 4 個 Agent:
    3. architect
    4. backend
    5. frontend
    6. tester/integrator
    7. 為每個 Agent 明確:
    8. 可用工具(Git、Filesystem、HTTP…)
    9. 輸入(上一個 Agent 的輸出 / 檔案)
    10. 必須產出什麼檔案

    步驟 4:加上監控 Dashboard

    • 如果用 Forge:直接啟用它的 Dashboard,看每次工作流的步驟成功率
    • 若自己實作:
    • 為每個步驟記錄:開始時間、結束時間、是否重試
    • 每次失敗時存 log + 輸入輸出到一個資料夾

    步驟 5:只做一件事的迭代

    • 第一版只要求「能跑起來」,不追求漂亮結構
    • 每次失敗,你只調整:
    • 任務拆分是否太粗/太細
    • Agent 提示是否太模糊
    • 重試與 checkpoint 是否設太少

    等到這個小系統穩定後,你才讓 Runtime 去碰更大的專案。


    小結:Runtime 是你的「AI 開發主管」

    Antigravity 2.0 用 96 個 Gemini Agent 寫出一套能跑《Doom》 的 OS,看起來很遠,但背後用到的概念其實都可落在你今天的 side project 上:

    • 把任務拆成 Agent 可接手的小單位
    • 用 Runtime 管控流程,而不是寄望模型每次都猜對
    • 利用開源工具(Forge、llama.cpp、MCP)做出自己的「迷你 Antigravity」

    💡 關鍵: 關鍵不是再換一個更大的模型,而是把現有模型放進可靠的 Runtime,讓它真的「交付」可用產物。

    關鍵不是再換一個更大的模型,而是先把你手上的模型,放進一個可靠的 Runtime 裡,讓它真的幫你「交付」東西。

    🚀 你現在可以做的事

    • 在 GitHub 上看看 Forge 專案,了解多步代理的 guardrails 怎麼設計
    • 挑一個 3–5 小時能手刻完的 CRUD 小服務,照文中的 4 個 Agent 角色拆任務實作一次
    • 把既有的單 Agent 自動化腳本,加上 max_retries 和簡單 checkpoint 機制,量化成功率變化
  • Gemini Spark:24 小時幫你管信與帳的 AI 管家

    Gemini Spark:24 小時幫你管信與帳的 AI 管家

    📌 本文重點

    • Gemini Spark 是深度整合 Gmail / Workspace 的 24/7 AI 管家
    • 透過規則 + 對話自動幫你篩信、寫信、追專案與整理帳單
    • 未來可藉由 MCP 串接各種第三方 App,跨服務自動協作
    • 適合重度依賴 Gmail / Docs 的自由工作者、PM 與一般用戶

    一句話:Gemini Spark 就是常駐在你 Gmail / Workspace 裡的 24 小時 AI 管家,幫你篩信、寫回信、盯專案、看帳單,減少你開 Email、開表單處理瑣事的時間。

    官方介紹與技術背景可參考:Google I/O 報導(The Verge:連結、TechCrunch:連結)。


    為什麼大家都在做 24/7 Agent?Spark 與 OpenClaw 有何不同?

    最近一堆「24 小時 AI Agent」:OpenClaw、各種自動 Agent 平台,核心概念都一樣:不用你每次開聊天框下指令,AI 自己在背景幫你盯事情。

    差別在:

    • OpenClaw 類產品:偏「開發者 / 愛折騰」路線,要自己設計任務、接 API。
    • Gemini Spark:直接長在 Google 生態裡,主打:
    • 深度整合 Gmail / Docs / Sheets / Calendar 等 Workspace
    • 不用寫程式,用「規則 + 對話」就能開啟 workflow
    • 未來可用 Model Context Protocol (MCP) 串接其他服務(如任務管理、財務 App)。

    如果你工作幾乎都在 Gmail + Docs 上,Spark 比自己搭一套 OpenClaw workflow 更省時間、阻力更小。

    💡 關鍵: Spark 把「24/7 Agent」做成內建在你日常工具裡的功能,而不是一個需要你額外架設與維護的系統。


    核心功能 1:Gmail & Workspace 自動化

    Spark 最直接的價值:幫你打理每天那一坨 Email 和文件。

    能做什麼?

    1. 自動幫你篩信、分類
    2. 標記「待回覆」「重要客戶」「帳單 / 訂閱」
    3. 把專案相關信件整理到指定標籤或共用資料夾

    4. 自動草擬回信

    5. 依照你的語氣、常用模板,先寫好草稿
    6. 幫你整理長串對話重點,附在回信開頭

    7. 整理文件與表單

    8. 收到表單回覆,Spark 自動更新一份 Sheet
    9. 根據信件附件(合約、簡報)整理成專案說明 Doc

    你可以這樣設:

    • 在 Spark 裡建立規則(概念跟 Filter 很像):
    • 「凡是寄到 @client.com 的信 → 標記『客戶 A』,加上『待處理』,並讓 Spark 草擬回信」
    • 「標題含 ‘Invoice’ 或 ‘Receipt’ → 丟進『報帳』標籤,抄送到財務信箱」

    實作建議:

    • 先只設 1~2 個簡單規則(例如:重要客戶 + 帳單),一週後再慢慢擴充,不然一開始會被通知轟炸。

    核心功能 2:主動提醒與任務追蹤(Information Agents)

    根據 TechCrunch 的說法,Google 這波推出的是一整類「information agents」,可以在背景幫你監控資訊並主動提醒你更新狀態。

    能做什麼?

    1. 盯專案 Deadline、會議後待辦
    2. 讀你的行事曆 + 信件內容
    3. 抓出「需要你回覆 / 決策」的項目,列成待辦
    4. 開會後自動整理會議紀錄,變成「下一步行動清單」

    5. 監控帳單與訂閱扣款(Wired 舉的例子)

    6. 讀信用卡對帳單、訂閱通知信
    7. 找出「新出現的訂閱」「金額異常」
    8. 提醒你哪個訂閱快到期、要漲價

    9. 主動推送重要變化

    10. 類似:
      • 「這週有 3 封同一客戶追問進度,是否要統一回覆?」
      • 「今天有 2 筆金額較大的扣款,是否要確認?」

    你可以這樣設:

    • 設定每日 / 每週摘要:
    • 每天 17:00:一封「今日重要信件 + 待回覆清單」
    • 每週五:一份「本週專案進度 + 下週待辦」
    • 針對帳單:
    • 關鍵字觸發:「含 ‘Payment received’、‘Invoice’、‘Receipt’ → 丟給 Spark 分類 + 每月 1 號幫我整理上個月支出摘要」

    💡 關鍵: 把 Spark 當成「自動生成待辦清單的人」,讓你只在關鍵節點做決策,而不是自己翻信找事做。


    核心功能 3:跨服務協作(靠 MCP 串其他 App)

    Gemini Spark 未來會透過 Model Context Protocol (MCP),把不同 App 的資料拉到同一個「腦袋」裡處理(見 The Verge 報導)。

    意思是:

    • Spark 不只看 Gmail / Docs,可同時讀你在其他服務的內容
    • 比方:Notion、Asana、財務或 CRM 工具(視各家支援情況)

    能做什麼?

    • 新客戶來信 → Spark:
    • 在 CRM 建立客戶資料
    • 開一個 Asana / Jira 任務
    • 建一份 Google Doc 專案說明,丟到共用資料夾

    • 訂閱扣款被偵測到 → Spark:

    • 在你的個人記帳 App / Sheet 新增一筆支出
    • 標注「本月新增訂閱」,月底提醒你是否要取消

    目前這些整合會隨 MCP 生態擴大而補上,你可以優先關注:

    • 你常用的任務管理 / 筆記 App 是否推出「支援 Gemini Spark / MCP」
    • 一旦支援,就可以在 Spark 設定畫面裡授權該服務,讓 Spark 讀取與寫入資料。

    💡 關鍵: MCP 讓 Spark 變成跨 App 的「中樞神經」,未來可以一次處理信件、任務、財務資料,而不是各管各的。


    適合誰用?三個具體場景

    1. Freelancer:用 Spark 管專案信件與合約

    具體做法:

    • 專案信件管線
    • 設定規則:來自特定網域或標題含「Proposal」「Quote」→ 標籤「新案洽談」
    • Spark 自動草擬回信版本:

      • A 版:詢問需求細節
      • B 版:附上報價與時程
    • 合約 / 發票整理

    • Spark 自動把附件中的合約檔案存到對應 Drive 資料夾
    • 依合約內容(時程、金額)生成一列 Sheet:

      • 專案名稱 / 客戶 / 金額 / 付款節點 / 合約到期日
    • 每週專案總覽

    • 每週五 Spark 自動寄給你一份 Doc:
      • 每個專案的最新信件狀態
      • 待你回覆的客戶
      • 即將到期的付款 / 交付

    2. PM:用 Spark 維護「自動更新」專案說明文件

    具體做法:

    • 為每個專案建立一份「Project Brief」Google Doc
    • 跟 Spark 說:
    • 「這份文件是 X 專案的說明書,請未來根據相關 Gmail、會議紀錄、Drive 檔案,自動更新:

      • 成員名單
      • 時程 / 里程碑
      • 需求變更紀錄
      • 風險與依賴」
    • Spark 會:

    • 把會議邀請、會議記錄、需求更動 Email 轉成文件更新
    • 例如:會議後自動新增一段「2026/05/21 需求變更:結帳流程新增 Apple Pay」

    • 你要做的事:

    • 只在 review 時修正重要錯誤
    • 把這份 Doc 當成「單一真實來源」丟給新成員看

    3. 個人:用 Spark 監控訂閱扣款與信用卡帳

    具體做法:

    • 把信用卡帳單寄到固定 Gmail
    • 設定 Spark:
    • 「閱讀所有來自銀行 / 金融機構的信,整理出:
      • 每月訂閱(Netflix、Spotify、雲端服務等)
      • 單筆金額超過 X 元的交易
    • 每月 3 號產一份 Sheet + 一封摘要信送給我。」

    • 實際效果:

    • 你不用每月自己翻 PDF 帳單
    • 一眼看到:新增了哪些訂閱?哪筆支出特別大?要不要取消 / 確認?

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

    依目前公開資訊,Spark 會逐步在 Gemini App 與 Workspace 釋出,實際入口以你的帳號權限與地區為準。

    步驟一:在 Gemini App / Workspace 開啟 Spark

    1. 更新手機上的 Gemini App 或在瀏覽器開啟 Gemini。
    2. 找「Spark」或「Agents」相關入口(通常在側邊欄或設定)。
    3. 若你是 Workspace 使用者,管理員可能要先在後台啟用 Gemini / Spark 功能。

    步驟二:授權 Gmail / Calendar / Drive

    1. 依畫面指示,授權 Spark 存取:
    2. Gmail(讀 / 寫信)
    3. Calendar(讀行程)
    4. Drive(讀 / 建立 Docs、Sheets 等)
    5. 建議做法:
    6. 先只開 Gmail + Calendar,確定運作 OK 再讓 Spark 讀更多資料夾。
    7. 對特別敏感的資料夾,可以
      • 分開到另一個帳號
      • 或在 Drive 設定權限,避免 Spark 看到。

    步驟三:先設 2–3 個「實用預設 workflow」

    先從以下三個開始,感受到價值後再慢慢加:

    1. 自動草擬回信
    2. 規則:
      • 來自特定客戶網域,或標記為「重要」的信 → Spark 產生草稿
    3. 設定你的語氣偏好:正式 / 口語 / 簡短版

    4. 每天 17:00 匯總今日重要信件

    5. 內容包含:

      • 你今天沒有回覆的信
      • 含「deadline」「due」「reminder」等關鍵字的信
      • Spark 生成的回覆建議
    6. 每週專案週報

    7. 若你有固定專案標籤(例如「[Project X]」):
      • 每週五 Spark 讀所有相關信件 + 文件變化
      • 產出一份 Doc:
      • 本週完成事項
      • 開放中的問題
      • 下週計畫建議

    權限與隱私:幾個實務建議

    1. 工作帳號與私人帳號分開
    2. 不要讓 Spark 在同一帳號裡同時看到公司機密 + 私人財務。

    3. 先從低風險資料開始授權

    4. 先讓它管 Newsletter、一般通知信,不要一開始就丟完整信用卡帳單。

    5. 定期檢查 Spark 建立的文件 / 表單

    6. 每週抽查 1–2 份自動產生的 Doc / Sheet,確定沒有誤解或洩漏給錯對象。

    7. 關閉你不需要的來源

    8. 如果覺得 Spark 讀太多東西,就到設定關掉某些資料夾或服務授權。

    結論:如果你每天都被 Gmail 和各種帳單 / 專案信件追著跑,Gemini Spark 的價值不是「會聊天」,而是能在你沒開電腦的時候,幫你持續整理與提醒,讓你只需要在關鍵節點做決定,其他都交給它自動化處理。

    🚀 你現在可以做的事

    • 打開你的 Gmail,先規劃 1–2 個想讓 Spark 自動處理的信件情境(例如:帳單、重要客戶)
    • 在 Gemini / Workspace 中尋找 Spark 入口,完成 Gmail + Calendar 的最低授權並設好這 2 個情境
    • 每週挑固定時間檢查 Spark 自動生成的文件與摘要,根據實際效果微調規則與授權範圍
  • Argyph:在本機幫 AI 裝上程式碼大腦

    Argyph:在本機幫 AI 裝上程式碼大腦

    📌 本文重點

    • Argyph 把你的專案變成本機「程式碼大腦」
    • 三層索引:檔案、symbol graph、向量檢索完全離線
    • 可接 Claude / MCP,協助 debug、refactor、大型專案導覽

    你可以把 Argyph 想成「替你的 AI 助理裝一個本機程式碼大腦」,讓它在大專案裡不再只會 grep 和亂抓檔案。

    Argyph GitHub 專案連結|原始 Reddit 介紹


    為什麼需要一個「程式碼大腦」?

    一般 AI 助理(包含 Claude、各種 MCP 代理)在大專案裡常見幾個痛點:

    • 只會用關鍵字搜尋(grep),找不到真正關鍵的函式或類別
    • 動不動就把整個檔案塞進 context,還是看不懂整個呼叫鏈
    • 要用語義查詢,就得把程式碼丟上雲端向量庫,卡在隱私與延遲

    Argyph 解決的是:在完全本機的前提下,讓 AI 可以精準定位「哪個函式、在哪個檔、被誰呼叫」,再搭配向量檢索補上語義理解。

    💡 關鍵: Argyph 讓 AI 在本機就能理解整個專案結構,不必依賴雲端向量庫或大量 context 塞資料。


    核心功能:三層索引的本機程式碼大腦

    1. 檔案索引:先搞清楚專案長什麼樣

    Argyph 的第一層是「檔案清單」,會掃描整個專案,把所有檔案路徑與基本資訊建成索引。

    你可以立刻拿來做這些事:

    • 問 AI:列出這個 monorepo 裡所有包含 payment 的資料夾與檔案,幫我分類前端 / 後端 / infra
    • 快速導覽:請 AI 幫你列出「所有 migration 檔」、「所有含 config 的檔案」,再逐步打開看

    這一層幾乎等於「強化版 tree + grep」,但 AI 不用自己亂找,它有一份完整的檔案地圖可以參考。

    2. Symbol Graph:函式、類別、呼叫鏈一次串起來

    第二層是重點:Argyph 用 tree-sitter 解析程式碼,建立一個 symbol graph(符號圖):

    • 每個函式、類別、變數變成一個節點
    • 誰呼叫誰、誰繼承誰、誰 import 誰,變成邊

    這代表 AI 不再只看到「文字」,而是有:

    • get_user() 在哪個檔、哪一行
    • 它被哪些 API handler 呼叫
    • 這個 class 的 method 被哪些 service 用到

    你可以這樣用:

    • 問:列出所有呼叫 process_payment 的函式,照檔案列出並解釋呼叫差異
    • 問:幫我畫出 UserService 相關的呼叫鏈,從 HTTP handler 到 DB 層

    這對 debug / refactor / 新人 onboarding 都很實用,因為 AI 能「走呼叫鏈」,不是只看單一檔案。

    💡 關鍵: 有了 symbol graph,AI 可以沿著呼叫鏈追蹤影響範圍,適合用在風險評估與大規模重構。

    3. 向量索引:在本機做語義搜尋

    第三層是向量索引:

    • Argyph 內建向量資料庫與嵌入模型
    • 完全離線,不需要任何 API key

    這允許你用自然語言查詢「概念」而不是關鍵字,例如:

    • 找出專案裡所有處理權限驗證的邏輯,依風險高低幫我摘要
    • 幫我找所有寫死 API key 或憑證的地方,並列出檔案與行號

    向量搜尋是建立在 symbol graph 之上的:AI 可以先找到語義上相近的函式,再搭配呼叫鏈,給出比較完整的分析。

    💡 關鍵: 語義搜尋結合 symbol graph,讓 AI 查的是「概念 + 實際呼叫點」,而不只是模糊的文字相似度。


    適合誰用?三個具體場景

    1. 大型專案導覽與理解舊 codebase

    如果你正在接手一個幾萬行、幾百個檔的專案:

    • 問 AI:幫我整理這個專案的主要模組結構,列出每個模組的 entry point
    • 問 AI:找出所有 user login 流程相關的函式與檔案,畫出流程順序

    實際效果:你不用一個一個資料夾展開找,只要問問題,AI 會用 Argyph 的索引幫你拉出結構化的地圖。

    2. 搭配 Claude / MCP 做 refactor 或 bug trace

    Argyph 是一個 MCP server,可以直接接在支援 MCP 的代理上,例如:

    • Claude Desktop / Claude for Web(啟用 MCP)
    • 其他支援 MCP 的本機代理

    實際操作可以是:

    • 問:這個 bug 是某個 API 回傳格式變了,幫我找出所有依賴該 API 回傳結果的地方,評估改動風險
    • 問:我要把舊的 logging library 換成新的,列出所有使用舊 library 的呼叫點,並給我一個逐步 refactor 計畫

    AI 會:

    1. 用 symbol graph 找到所有相關函式與呼叫點
    2. 用向量搜尋補充語義相似的地方(例如命名不一致的 logging)
    3. 把結果給你看,或協助生成 patch(視你的代理能力而定)

    3. 公司內部需要嚴格保護原始碼

    很多團隊不願意把全專案丟上雲端向量庫(法遵 / NDA / 產業規範等):

    • Argyph 是單一 binary,本機跑、不會把程式碼傳到任何外部服務
    • 只做只讀索引:不會幫你修改、commit 或執行程式碼

    適合:

    • 金融、醫療等需嚴格控管原始碼的公司
    • 只允許在內網跑工具的團隊
    • 想先在個人機器上試驗「AI + codebase」的工程師

    你可以放心地讓 AI 在專案裡查來查去,但知道一切都留在你自己的機器或公司網路。


    和一般 AI 助理 / 雲端向量庫怎麼比?

    如果你現在已經在用「AI + 專案」的工具,可以參考這個比較。

    名稱 核心功能 免費方案 適合誰
    一般 AI 助理(無) 單純依靠上下文 + grep 視服務而定 小專案、單檔問題
    雲端向量檢索工具 把程式碼上傳雲端做語義搜尋 多有免費層級 不介意程式碼上雲端的團隊
    Argyph 本機三層索引(檔案 + symbol + 向量) 開源免費 想要本機、隱私保護又要強檢索的工程師

    怎麼開始:從安裝到接上 Claude / MCP

    以下是一條「最快能跑起來」的路徑,你可以照著做。

    步驟 1:安裝 Argyph(Rust 單一 binary)

    1. 前往 GitHub Releases
    2. 下載對應你系統的 binary(macOS / Linux / Windows)
    3. 將檔案改名為 argyph(可選),並移到你的 $PATH 例如:
    chmod +x argyph
    mv argyph /usr/local/bin/
    

    若你有 Rust 環境,也可以選擇 cargo install(以官方 README 為準)。

    步驟 2:對你的專案建立索引

    在專案根目錄執行:

    cd /path/to/your/project
    argyph index
    

    接著會發生:

    1. 立即建立檔案索引(可用來問檔案結構)
    2. 持續建立 symbol graph(可用來問呼叫鏈)
    3. 背景生成向量索引(可用來做語義搜尋)

    你可以邊等邊用,因為 Argyph 的設計是每一層建好就能用,不必等全部完成。

    步驟 3:在 Claude / MCP 代理中啟用 Argyph

    以 Claude(支援 MCP)為例,整體步驟大致如下(細節以官方文件為準):

    1. 打開 Claude 的 MCP 設定檔,例如 mcp.config.json
    2. 加入一個 Argyph server 設定:
    {
      "servers": {
        "argyph": {
          "command": "argyph",
          "args": ["server"],
          "env": {
            "ARGYPH_PROJECT_ROOT": "/path/to/your/project"
          }
        }
      }
    }
    
    1. 重新啟動 Claude 或重新載入 MCP 設定

    之後在 Claude 裡,你可以直接用自然語言要求它「用 Argyph 的 context」來回答與專案相關的問題(多數 MCP 代理會自動挑選需要的工具)。


    實用查詢範例:馬上能用的 prompt

    你可以照抄以下查詢,稍微改一下專案名就能套用。

    範例 1:找出所有調用某 API 的地方並總結風險

    「請用 Argyph 的索引幫我:
    1. 找出專案裡所有呼叫 createPaymentSession 的地方,列出檔案路徑與行數。
    2. 對每個呼叫點,說明它在什麼情境被呼叫(例如:checkout、訂閱續費)。
    3. 總結如果我修改這個 API 的回傳格式,可能影響的功能與風險。」

    範例 2:整理某個 domain 的完整呼叫鏈

    「這個專案是單一體 monolith,請用 Argyph 的 symbol graph 幫我:
    1. 找出所有跟 user onboarding 相關的函式與 class。
    2. 以『從 HTTP endpoint → service layer → DB layer』的順序,列出呼叫鏈。
    3. 幫我總結每一層主要職責,方便我之後 refactor。」


    總結:把 AI 當「懂專案的夥伴」,而不是「會寫程式的 autocomplete」

    Argyph 的價值在於:讓 AI 真正理解你的專案結構,而不是在一堆檔案裡瞎猜。

    如果你有一個中大型 codebase,又想保持程式碼只待在本機或公司內網,建議可以:

    1. 把 Argyph 裝起來
    2. 對你的主專案掃一輪索引
    3. 在 Claude / MCP 代理裡接上它,從「幫我畫出這個專案的主要模組」這種問題開始試

    你會發現,AI 從「會寫程式」變成了「懂這個專案的同事」。

    🚀 你現在可以做的事

    • 去 Argyph GitHub Releases 下載並安裝 argyph binary
    • 在你主要的專案根目錄執行 argyph index 建立三層索引
    • 打開你的 mcp.config.json,加入 Argyph server 設定並在 Claude / MCP 裡實際問幾個專案問題
  • Cursor Composer 2.5:平價 GPT-5.5 程式助手?

    Cursor Composer 2.5:平價 GPT-5.5 程式助手?

    📌 本文重點

    • Composer 2.5 以更低成本提供接近 GPT‑5.5 / Opus 的程式能力
    • 深度整合 Cursor,可做跨檔與整庫重構
    • 適合接手 70% 可驗證的日常開發任務,替代昂貴模型

    只要用 Cursor 選擇 Composer 2.5,你就能用接近 GPT‑5.5 / Opus 等級的程式助理處理日常開發工作,但花更少的錢。

    參考:Cursor 官方 X 貼文、The Decoder 報導


    核心功能:為什麼說它是「低成本高性能」

    1. 基於 Kimi K2.5,對準「寫程式」這件事

    Composer 2.5 建在 Kimi K2.5 模型上,Cursor 官方說明它在訓練時加入了 比前一代多 25 倍的合成任務(synthetic tasks),重點就是:

    💡 關鍵: 多 25 倍合成任務,代表模型在「讀/寫/改程式碼」這類可控任務上被專門強化,而非泛用聊天。

    • 訓練內容更聚焦在「寫程式、改程式、讀程式」這三件事
    • 對多檔案專案、跨語言呼叫(例如 Python + TypeScript)理解更好
    • 對「先看懂再動手改」的任務(重構、查 bug)特別有幫助

    你可以做的事:

    • 把舊專案整個丟進 Cursor workspace,直接問:

      「幫我概述這個專案的資料流,從 API 到 DB。」

    • 預期它對跨檔案邏輯的掌握會比一般純聊天模型更穩定。

    2. 性能接近 GPT‑5.5 / Opus 4.7,但成本更低

    根據 The Decoder 報導,Composer 2.5 在多項基準測試中 接近 GPT‑5.5、Anthropic Opus 4.7 的程式能力,但使用成本卻只要一小部分。

    💡 關鍵: 以「一小部分成本」換到接近 GPT‑5.5 / Opus 水準的程式能力,意味著同樣預算可以支撐更多開發量與更多輪迭代。

    實際體感上,你會得到:

    • 長對話與長檔案表現穩定:不容易「忘記前文」,適合大專案
    • 生成程式碼較少離題:CRUD / API 類需求比較不會「寫歪」
    • 多輪修改成本可控:不用每次都叫 GPT/Claude 出來燒 token

    你可以做的事:

    • 把日常「寫 API、修小 bug、重構單檔」改用 Composer 2.5;
    • 把「產品需求討論、架構設計」這類高風險決策,才交給 GPT‑4.1 / Claude,節省昂貴模型的用量。

    3. 深度整合 Cursor IDE:跨檔讀寫、整庫重構

    Composer 2.5 是為 Cursor 量身調校的模型,搭配 IDE 使用,可以:

    • 跨檔案查找與修改:一次改一整個 feature 涉及的檔案
    • 支援多語言專案:例如前端 React + 後端 Node + Infra IaC 同時理解
    • 直接在側邊欄展示 diff:你可以逐行檢查 AI 提案再決定要不要套用

    你可以做的事:

    • 在專案根目錄使用「Composer」面板,下指令:

      「在不破壞現有 API 行為的前提下,把整個 user 模組改成使用 repository pattern,並維持測試通過。」


    適合誰用?三個具體場景

    1. 日常 CRUD / API 寫作 & 重構舊專案

    典型需求:

    • 寫 RESTful API / GraphQL resolver
    • 加上簡單驗證 / 分頁 / 排序
    • 把舊的 callback / promise code 改成 async/await

    在 Cursor 編輯器中,你可以這樣用:

    1. 選取一段老舊程式碼,按 Cmd+K(或右鍵選 AI Command)。
    2. 輸入 prompt:

      「重構這段程式碼:改用 async/await,避免重複邏輯,並維持現有行為不變。」

    3. 檢查 diff,如果 OK 就套用。

    小技巧:對整個檔案重構可用:

    「重構這個檔案並維持測試通過,不要改動對外 export 的介面名稱。」

    — 這句話能提醒模型「不要亂改對外 API」,減少你後面修爆錯誤。


    2. 搭配 Cursor 做「整庫重構」與大規模查改

    當你需要:

    • 把整個專案從 Express 換成 Fastify
    • 把所有 any 慢慢補成正確 TypeScript 型別
    • 把一堆散落函式集中到 service class

    Composer 2.5 的用法會是:

    1. 在 Cursor 開啟專案,確保整個 repo 都在 workspace。
    2. 打開 Composer 面板(左側「火箭」圖示),選擇 Composer 2.5 模型。
    3. 下指令:

      「在整個專案中,將所有 express 相關使用改成 Fastify,保留 API 路徑與回應格式,並更新相關型別定義。每一組改動請分開 commit 欄位說明。」

    Cursor 會:

    • 找出相關檔案
    • 給出一組可檢查的改動

    搭配 git 避免「一鍵改爆」:

    建議流程:

    1. 新開分支
      bash
      git checkout -b refactor/use-fastify
    2. 每次只讓 Composer 改一小塊(例如一個模組、一個資料夾)。
    3. 跑測試再 commit:
      bash
      pnpm test # 或 npm/yarn
      git add .
      git commit -m "refactor: migrate auth module to Fastify"
    4. 改壞了就 git restore . 或 git reset --hard 回到上一次測試通過的點。

    3. 用它取代部分 GPT / Claude 編碼任務,降成本

    你不需要把 GPT / Claude 整個換掉,而是:用 Composer 2.5 接手「可預測、可驗證」的程式任務。

    💡 關鍵: 把約 70% 可驗證的編碼工作交給 Composer 2.5,可在不改工作流程的情況下顯著壓低高價模型帳單。

    適合交給 Composer 2.5 的任務:

    • 寫 CRUD / API handler
    • 轉寫語言(Python ↔ Node、JS ↔ TS)
    • 單檔重構、加 log、補型別
    • 根據錯誤訊息嘗試修 bug(你再跑測試驗證)

    保留給 GPT / Claude 的任務:

    • 探討產品需求、技術決策
    • 大型架構設計、權衡方案
    • 需要多領域知識的解題(例如演算法 + 數學 + 故事情節)

    實作建議:

    • 在 Cursor 預設模型選 Composer 2.5,讓日常操作都走它
    • 只有在遇到明顯超出範圍的需求,再手動切換到 GPT‑4.1 / Claude

    這樣你可以在不改變工作習慣的情況下,實際降低高價模型用量。


    怎麼開始:3 分鐘完成安裝與設定

    1. 安裝 Cursor 與建立 Workspace

    1. 前往官網下載 Cursor:https://www.cursor.com
    2. 安裝後登入(支援 GitHub / Google 帳號)。
    3. File → Open Folder 打開你的專案,Cursor 會自動建立 workspace。

    建議:第一個試驗專案先選有測試的 repo,方便驗證 AI 修改的結果。


    2. 選擇 Composer 2.5 模型

    1. 在右上角模型選單中,選擇 Composer 2.5。
    2. 在聊天視窗 / Composer 面板,都可以確認當前使用模型名稱。

    之後你在:

    • Cmd+K 觸發的 inline 指令
    • 側邊欄聊天
    • Composer「在整個專案上操作」

    預設都會走 Composer 2.5(除非你手動切換)。


    3. 實用 prompt 模板:直接複製就能用

    下面幾組可以直接貼在 Cursor 裡,記得根據專案語言調整細節:

    1. 單檔重構 + 保證測試

      「重構這個檔案並維持測試通過:
      1. 保留對外 export 的 function 名稱與參數型別;
      2. 移除重複邏輯,適度抽取 helper;
      3. 將 callback 風格改為 async/await。」

    2. 新增 CRUD API

      「在這個專案的風格下,為 Article 資源新增 CRUD API:
      – 使用現有的 router / controller 架構;
      – 套用與 User 相同的驗證與錯誤處理方式;
      – 寫對應的單元測試並保持現有測試通過。」

    3. 全專案查改 + 小範圍提交
      在 Composer 面板:

      「在整個專案中,把所有 console.log 改成使用既有 logger(src/lib/logger.ts),
      每次只修改單一 module,並清楚標註將被修改的檔案清單。」

    搭配 git 分支與測試,你可以逐步、安全地享受「整庫 AI 重構」,而不是被「一鍵改爆」。


    小結:Composer 2.5 值得你怎麼用?

    • 當作「日常程式夥伴」:CRUD / API、重構舊檔案全部交給它
    • 搭配 Cursor 做跨檔案重構與查改,善用 diff + 測試守門
    • 把昂貴的 GPT / Claude 留給真正需要高思考密度的任務

    如果你已經在支付 OpenAI / Anthropic 的帳單,現在就試著把一週內 70% 的程式任務改交給 Cursor 的 Composer 2.5,實際比較「完成同一個需求時的成本差」,你會更清楚它在你的團隊裡能省下多少錢。

    🚀 你現在可以做的事

    • 下載並安裝 Cursor,建立一個有測試的專案 workspace 試跑 Composer 2.5
    • 在 Cursor 將預設模型改為 Composer 2.5,挑一個舊模組交給它重構並用測試驗證
    • 往後一週刻意記錄「同一類任務用 Composer 2.5 vs GPT/Claude」的實際 token 與時間成本差異
  • 用 GlycemicGPT 把血糖變成可讀故事

    用 GlycemicGPT 把血糖變成可讀故事

    📌 本文重點

    • 把複雜血糖數據轉成「可讀故事」
    • 不碰醫療決策,只做分析與提醒
    • 可自託管,延伸到睡眠、運動等健康指標
    • 工程師與非工程師都有明確上手路徑

    這是一個把連續血糖、胰島素泵、Nightscout 和聊天式分析整合在一起的開源 AI 健康管家,但不碰醫療決策,專心把你的血糖數據講成聽得懂的故事。

    專案連結:GlycemicGPT GitHub


    核心功能:它到底幫你做什麼?

    1. 把一天血糖變成「可讀摘要」

    解決的問題:連續血糖監測(CGM)數據很多,但圖表看了還是不知道:今天到底穩不穩?哪一段出問題?

    GlycemicGPT 的做法:
    – 從 Dexcom G7、Nightscout 等來源抓你的 24 小時血糖紀錄
    – 分成「夜間」「白天」「運動前後」「高低血糖事件」等片段
    – 生成一段自然語言摘要,例如:
    – 「昨晚 2–4 點有兩次低血糖,可能和睡前校正注射有關」
    – 「早餐後 1–2 小時血糖上升幅度較大,建議檢視碳水估算」

    💡 關鍵: 把一整天密密麻麻的血糖數據濃縮成幾句話,讓你一眼看出哪個時段最需要注意。

    你可以馬上做的事:
    – 每天固定時間(例如睡前)看一次摘要,記一條「明天要嘗試的調整」:
    – 減少某餐碳水
    – 提前運動時間
    – 記錄一個你想問醫師的問題


    2. 餐後血糖分析:把「這餐」跟「那餐」比較出來

    解決的問題:你可能知道「麵會讓我高」,但很難量化:這碗麵 vs 這碗飯,到底差多少?

    GlycemicGPT 的做法:
    – 從 Nightscout 或手動輸入的「餐點紀錄」對應到餐後血糖曲線
    – 幫你計算:
    – 餐後 1 小時、2 小時的血糖變化
    – 每道菜、不同時間吃同一餐的差異
    – 用自然語言生成結論:
    – 「相較於 5 月 1 號午餐,同樣是義大利麵,今天餐前血糖較高,使得峰值提高約 20 mg/dL」

    💡 關鍵: 透過具體數字比較不同餐次,幫你找出「同一道菜、不同吃法」帶來的血糖差異。

    你可以馬上做的事:
    – 選一個常吃的餐(例如便當店),連續 3 次記:
    – 吃什麼
    – 大概時間
    – 用 GlycemicGPT 問:「幫我比較這 3 次便當餐後血糖差異」
    – 找出:
    – 是否晚吃一小時就特別高
    – 是否換一種配菜更穩


    3. 聊天式 Q&A 與預警:把醫囑變成「日常提醒」

    解決的問題:醫院給的講義很厚,但日常遇到的小問題(例如「今天運動前 30 分鐘血糖是 90,合理嗎?」)很難即時問人。

    GlycemicGPT 的做法:
    – 使用 RAG(從可信來源取資料再回答),連結臨床指南、糖尿病教育資料
    – 你可以問:
    – 「這週夜間低血糖發生幾次?」
    – 「最近是否有高血糖時間變長?」
    – 設定預警:
    – 當血糖連續一段時間偏高/偏低時,以你設定的方式提醒(例如透過 Nightscout 或其他通知系統)

    安全邊界(很重要):
    – GlycemicGPT 不控制胰島素泵,不會自動調整劑量
    – 它是「分析與提醒工具」,任何治療改變都應與醫師討論

    💡 關鍵: 系統刻意不碰胰島素劑量,只做「看懂與提醒」,讓使用更安全、也更符合醫療規範。

    你可以馬上做的事:
    – 選一個你常擔心的情境,例如:「運動前低血糖」
    – 問 GlycemicGPT:
    – 「過去兩週,我運動前 2 小時內有低血糖的情況嗎?」
    – 把得到的結論帶去門診,跟醫師一起確認需不需要調整


    適合誰用?三種典型場景

    1. 糖尿病患者:把自我管理變成「對話」

    適合:已經在用 Dexcom G7、Nightscout 或胰島素泵的 1 型/2 型患者。

    可以怎麼用:
    – 每週固定生成一份「一週血糖報告」
    – 把報告存在雲端或印出,在門診時直接給醫師看
    – 平常遇到疑問先在 GlycemicGPT 裡「排練」問題,再整理 2–3 個重點問醫師


    2. 家屬與照護者:遠端關心但不干擾

    適合:家裡有小孩、長輩正在使用 CGM 或胰島素泵。

    可以怎麼用:
    – 由患者端自託管 GlycemicGPT,授權家屬查看摘要
    – 家屬每週只看一次「高低血糖事件概況」,避免盯得太緊造成壓力
    – 把預警設定為「只在連續幾天異常時通知」,減少過度打擾


    3. 醫療團隊:作為視覺化與溝通工具

    適合:願意嘗試資料驅動照護的診所、醫師、糖尿病衛教師。

    可以怎麼用:
    – 在院內一台伺服器上自託管,連接部分願意參與的患者 Nightscout
    – 診間中開 GlycemicGPT 的每日摘要,當作溝通起點:
    – 「這裡可以看到你這一週夜間血糖偏低,我們一起討論原因」

    再次提醒:治療決策仍然由醫師與患者共同做出,GlycemicGPT 只是把資料講清楚。


    延伸思路:用同一套架構做「睡眠 / 運動 / 壓力」Agent

    就算你不是糖尿病患者,也可以從 GlycemicGPT 學到一套「個人健康 Agent」的設計模板:

    1. 資料來源:
    2. 睡眠:Apple Watch、Oura Ring、床墊感測器
    3. 運動:Garmin、Strava、健身房紀錄
    4. 壓力:心率變異度(HRV)、自我打分
    5. 管道層(類似 Nightscout):
    6. 建一個簡單的時間序列資料庫(例如 InfluxDB、TimescaleDB)
    7. AI 分析層:
    8. 用類似 GlycemicGPT 的方式:
      • 每日摘要
      • 特定事件分析(熬夜、重訓日)
      • 聊天式 Q&A

    具體行動建議:
    – 先選一個最在意的指標(例如「睡眠中途醒來」)
    – 用 Notion / Google Sheet 先手動記一週
    – 再思考要怎麼把它自動化收集,最後才上 AI 分析層


    怎麼開始:非工程師 vs 工程師兩條路

    非工程師:先找到願意幫你部署的人

    目前 GlycemicGPT 是一個自託管專案,沒有一鍵雲端 SaaS,可以照這個路線:

    1. 準備好問題清單:
    2. 想解決什麼?(例如「看懂 Dexcom 圖表」「整理給醫師的報告」)
    3. 請技術朋友或社群幫忙部署:
    4. 把這個連結丟給對方:https://github.com/GlycemicGPT/GlycemicGPT
    5. 請他們依 README 在以下任一環境部署:
      • VPS(例如 Hetzner、DigitalOcean)
      • 家用 NAS / 自架伺服器
      • 樹莓派(性能較有限,但可做測試)
    6. 確認三件事再上線:
    7. 資料只存在你控制的機器
    8. 只有你(和你信任的人)有權登入
    9. 不啟用任何自動控制胰島素的機制

    如未來專案提供雲端部署模板(例如 Docker Compose + 一鍵部署到某雲平台),可直接使用模板,仍建議由你信任的技術人員操作。


    工程師:自己 clone、自己玩(含模擬數據)

    步驟 1:Clone 專案

    git clone https://github.com/GlycemicGPT/GlycemicGPT.git
    cd GlycemicGPT
    

    步驟 2:設定資料來源

    你有三種常見選項:
    – Dexcom G7:
    – 依 README 取得雲端 API 權限
    – Tandem t:slim X2 / Mobi:
    – 透過 BLE 連線(需支援藍牙的裝置)
    – Nightscout:
    – 指向你現有的 Nightscout URL 和 API key
    – 沒有真實設備也沒關係:
    – 使用專案提供的模擬數據(或自己寫一段腳本產生假資料),先跑通流程

    步驟 3:選擇 LLM:本地或雲端

    • 本地模型(例如搭配 Ollama):
    • 適合:在意隱私、手邊有一台效能還可以的電腦
    • 做法:
      bash
      # 安裝 Ollama(依官網步驟)
      ollama pull llama3
    • 在 GlycemicGPT 設定檔中改成指向本地 Ollama 的 API

    • 雲端 LLM(OpenAI、Anthropic 等):

    • 適合:先追求穩定與效果
    • 做法:
      • 取得 API Key
      • 在環境變數或設定檔中填上

    步驟 4:跑起第一個每日摘要

    • 啟動服務(依 README,多半是 docker-compose up 或類似指令)
    • 匯入一段 24 小時的血糖資料
    • 在 Web 介面或命令列呼叫「Daily brief」功能

    你應該會看到類似:

    「過去 24 小時,Time in Range 為 72%,夜間低血糖兩次,主要集中在 2–3 AM。」

    從這裡開始,你可以:
    – 修改提示詞(prompt)讓語氣更符合自己
    – 加入自訂指標(例如:運動前 2 小時血糖平均值)


    實務提醒:隱私、醫療決策與客製指標

    1. 隱私與自託管:
    2. 血糖與醫療資料是極具敏感性的個資
    3. 優先考慮:

      • 自己控制的伺服器
      • 本地模型(如 Ollama)
      • 關閉不必要的遙測或第三方整合
    4. 與醫師討論後再調整治療:

    5. GlycemicGPT 可以提出「假設」:
      • 「這段時間似乎與晚餐進食時間延後有關」
    6. 但任何:
      • 胰島素劑量修改
      • 藥物新增或減少
      • 大幅飲食調整
    7. 都應先與醫師或糖尿病衛教師確認

    8. 迭代客製自己的健康指標:

    9. 起點:先用官方常見指標(Time in Range、低血糖事件次數)
    10. 接著加上個人化指標,例如:
      • 「健身日前後 12 小時的血糖穩定度」
      • 「出差期間 vs 非出差期間的平均血糖」
    11. 每一輪調整只增加 1–2 個新指標,避免系統變得看不懂

    延伸閱讀與靈感來源

    如果你正在想「AI 到底能在我的健康管理中做到哪裡」,GlycemicGPT 是一個很好的起點:
    – 它先專注把資料變成可讀故事
    – 把決策留給你和醫師
    – 同時也給了我們一套可複製到其他健康領域的架構範本。

    🚀 你現在可以做的事

    • 打開 GlycemicGPT GitHub 專案,確認自己屬於「非工程師」還是「工程師」路線
    • 選一個近期最在意的情境(例如「夜間低血糖」或「某個常吃的便當」),準備一週的相關紀錄
    • 找一位可信任的技術朋友,或自己依 README 部署雛形,先跑出第一份「24 小時血糖摘要」再逐步優化
  • 5 分鐘做出你的 Claude 專屬小 Agent

    5 分鐘做出你的 Claude 專屬小 Agent

    📌 本文重點

    • Claude Skills 是一包可重用的 Python 技能模組
    • 只要寫幾個函式就能讓 Claude 自動串起工作流
    • 10 分鐘內可跑起第一個實用小 Agent

    用一句話講清楚:Claude Skills 就是一包現成可重用的 Python「技能模組」,幫你把讀檔、叫 API、發 Slack 這種瑣事交給 AI 自動跑。

    下面的重點是:看完你應該要「馬上能照著做,跑起一個自己的小 Agent」。


    什麼是 Claude Skills?

    原始專案:https://github.com/anthropics/skills

    用人話解釋:

    • 每一個 Skill 就是一個 Python 函式,包住「一件具體可重複的任務」,例如:
    • 讀 / 寫某個資料夾的檔案
    • 呼叫外部 HTTP API
    • 用 pandas 處理 CSV / JSON
    • 串起一小段工作流程(抓資料 → 清洗 → 寫檔 → 發通知)
    • 這些函式會被包裝成 工具(tools),讓 Claude 之類的模型「自動決定要不要呼叫、用哪個參數」。
    • 你的工作:
    • 選幾個 skills
    • 配好權限與 API key
    • 用一個簡單的 Agent shell 把它們掛上去

    結果就是:你不用自己手刻複雜 Agent 架構,只要寫幾個普通的 Python 函式,Claude 就能幫你組成自動化流程。


    核心功能:你可以拿來做什麼

    1. 內建技能類型:檔案、API、資料處理、簡單工作流

    在 anthropics/skills 裡,你可以看到各種已經寫好的 skills(名稱可能持續調整,但類型大致如下):

    • 檔案相關:
    • 讀寫本機檔案(通常限定在某個資料夾)
    • 列出目錄、建立新檔、更新內容
    • API 呼叫:
    • 通用 HTTP request(GET / POST)
    • 幫你處理 headers、JSON encode / decode
    • 資料處理:
    • 讀寫 CSV / JSON
    • 用 pandas 做簡單統計與篩選
    • 工作流協調:
    • 把多個 skills 串起來:例如「每天定時抓 API → 整理 → 寫報表 → 發通知」

    💡 關鍵: 多數常見「讀檔、叫 API、整理資料」的雜務,其實已經有現成 skill,可以直接拿來組合,而不用從零寫 Agent 架構。

    你可以立刻做的事:

    1. 打開 repo 的 skills/ 資料夾(或類似目錄),挑幾個你看得懂的 Python 檔。
    2. 看每個 skill 的 docstring,理解它預期的輸入、輸出是什麼。
    3. 想一件自己平常重複做的事,先用一個 skill 就好(例如:讀一個 CSV 幫你整理)。

    2. 如何跟你現有專案整合

    Skills 的設計很單純:

    • 你可以把整個 repo 當作 依賴套件 安裝,或直接把單一 skill 檔案 copy 進你專案。
    • 在你自己的 Agent 程式裡,把這些 functions 包成工具,丟給 Claude 使用。

    一個極簡示意(結構可能與實際 repo 有差異,但概念相似):

    from skills.files import read_file, write_file
    from anthropic import Anthropic
    
    client = Anthropic(api_key="YOUR_API_KEY")
    
    TOOLS = [read_file.tool_def, write_file.tool_def]
    
    resp = client.messages.create(
        model="claude-3-7-sonnet-20250219",
        max_tokens=1024,
        tools=TOOLS,
        messages=[{
            "role": "user",
            "content": "請幫我打開 data/report.csv,整理成重點摘要,回給我。"
        }]
    )
    

    Claude 看到 tools 後,會自己決定:

    • 要不要執行 read_file
    • 執行後用結果做後續推理

    你可以立刻做的事:

    • 如果你已經有在用 Claude API,先挑 1–2 個 skills 加進你的工具列表,看看 Claude 會怎樣使用它們。

    3. 搭配其他開源專案:拉出一條多代理 workflow

    有兩個常被一起提到的專案,很適合拿來串:

    名稱 核心功能 免費方案 適合誰
    Claude Skills 可重用的 Python 任務模組,給 Agent 當工具用 開源、自架 想快速做實用 Agent 的開發者、技術 PM
    scientific-agent-skills 研究、工程、金融、寫作等專業領域的技能集 開源、自架 科研團隊、量化分析、技術寫作者
    Personal_AI_Infrastructure 個人 AI 代理基礎架構、多代理協作 開源、自架 想打造個人 AI 工作桌面、內部 Agent 平台的人

    實際串法可以是:

    • 用 Personal_AI_Infrastructure 當「總控台」與排程器
    • 把 Claude Skills + scientific-agent-skills 當作不同專業領域的「工具箱」
    • 例如:
    • Agent A:每天抓研究資料(API + 檔案 download)
    • Agent B:用 scientific-agent-skills 做統計分析
    • Agent C:把結果用 Claude Skills 寫成報告,發到 Slack

    你可以立刻做的事:

    • 先單純在本機跑 Claude Skills,確認流程順暢後,再考慮拉入 Personal_AI_Infrastructure 做多 Agent 編排。

    適合誰用:三種常見場景

    1. 個人開發者 side project:資料整理 bot、FAQ 助理

    具體可以做:

    • 資料整理 bot:
    • 每天從某個 API 抓資料
    • 存成 CSV
    • 請 Claude 用 skills 幫你做摘要或簡單圖表
    • 客服 FAQ 助理:
    • 讀本機的 FAQ 檔案 + 客戶紀錄
    • 自動整理常見問題、生成回覆模板

    行動建議:

    • 先挑「你每天重複做、但不用太精準」的任務,例如:整理 log、閱讀報表。

    2. 小團隊:內部自動化腳本

    適合處理:

    • 例行報表產出
    • 專案進度彙整
    • Jira / GitHub issue 摘要

    作法:

    1. 把資料源(API、CSV)包成 2–3 個自訂 skills。
    2. 寫一個簡單 CLI 或 cron job,每天叫 Claude 跑一次。

    3. 結合其他開源專案:多步驟分析 + 報告

    對研究團隊、數據團隊特別實用:

    • 用 scientific-agent-skills 做嚴謹分析
    • 用 Claude Skills 負責「收資料 / 寫結果 / 發報告」

    行動建議:

    • 先把你現有的分析腳本包一層成 skill,讓 AI 能呼叫;不需要一開始就全部自動化。

    怎麼開始:10 分鐘跑起一個本地小 Agent

    以下示意流程假設你已經有 Claude API key,且會用基本的命令列。

    💡 關鍵: 只要準備 API key、安裝 repo,再加上兩三個簡單 skills,大約 5–10 分鐘內就能跑起第一個可用的本地 Agent。

    步驟 1:Clone 專案 + 安裝依賴

    git clone https://github.com/anthropics/skills.git
    cd skills
    
    # 依照專案說明,可能是
    pip install -e .
    # 或
    pip install -r requirements.txt
    

    行動:確認 python -m skills 或範例指令能跑起來(依官方 README 為準)。


    步驟 2:設定 API Key

    export ANTHROPIC_API_KEY="你的 Claude API key"
    

    Windows PowerShell:

    $env:ANTHROPIC_API_KEY="你的 Claude API key"
    

    行動:用 repo 提供的最小範例(例如 examples/basic_agent.py)跑一次,看 Claude 能不能成功呼叫某個內建 skill。


    步驟 3:本機執行一個範例技能

    假設有一個簡單範例(名稱依實際 repo 為準):

    python examples/list_files_agent.py
    

    你可能會看到:

    • 問你「要在哪個資料夾工作」
    • Claude 自動呼叫 list_files、read_file 等 skills

    行動:換一個你自己的資料夾(例如放了一些 CSV 報表),觀察 Claude 如何使用 skills 幫你瀏覽、整理。


    步驟 4:改成自己的任務——每天抓一個 API、整理、丟 Slack

    目標:

    1. 每天叫一個公開 API(例如匯率、Crypto 價格)
    2. 整理成簡單文字報表
    3. 發成訊息到 Slack 頻道

    實作方向:

    1. 寫一個自訂 skill:
    # skills/custom/fetch_rates.py
    import requests
    
    from skills.core import skill  # 依實際框架命名
    
    @skill
    def fetch_rates(base: str = "USD"):
        """從匯率 API 取得最新匯率資料。"""
        url = f"https://api.exchangerate.host/latest?base={base}"
        r = requests.get(url, timeout=10)
        r.raise_for_status()
        return r.json()
    
    1. 再寫一個發 Slack 的 skill(用 webhook 即可):
    # skills/custom/post_to_slack.py
    import os
    import requests
    from skills.core import skill
    
    WEBHOOK = os.environ["SLACK_WEBHOOK_URL"]
    
    @skill
    def post_to_slack(text: str):
        """把文字訊息丟到預設 Slack 頻道。"""
        r = requests.post(WEBHOOK, json={"text": text}, timeout=10)
        r.raise_for_status()
        return {"status": "ok"}
    
    1. 寫一個小 Agent 腳本:
    from anthropic import Anthropic
    from skills.custom.fetch_rates import fetch_rates
    from skills.custom.post_to_slack import post_to_slack
    
    client = Anthropic()
    
    TOOLS = [fetch_rates.tool_def, post_to_slack.tool_def]
    
    prompt = """
    你是一個匯率小助理:
    1. 先用工具抓最新 USD 匯率
    2. 挑出 3 個對我們重要的幣別(EUR, JPY, TWD)
    3. 排版成一段適合 Slack 的中文簡報
    4. 用工具發到 Slack
    """
    
    resp = client.messages.create(
        model="claude-3-7-sonnet-20250219",
        max_tokens=1024,
        tools=TOOLS,
        messages=[{"role": "user", "content": prompt}]
    )
    
    1. 排程:

    2. Linux / macOS:用 cron 每天跑一次這個腳本

    3. Windows:用排程工作排每日執行

    到這裡,你就已經有一個「完全實用」的小 Agent,在幫你做每天的資訊整理與通知。


    最佳實踐:權限、安全與成本

    1. 限制權限:不要讓 Agent 隨便亂動

    • 檔案操作技能:
    • 設定 專用工作資料夾,例如 ./agent_workspace,只給這個路徑的讀寫權限。
    • API skills:
    • 把 API key 存在環境變數或 secret manager,不要寫死在程式碼。

    2. 記錄 log:看得出 Agent 做了什麼

    • 為每個 skill 加上基本 logging:
    • 呼叫時間
    • 參數(敏感資訊略過)
    • 成功 / 失敗
    • 方便之後調整 prompt 或參數,避免 Agent 做無用功。

    3. 控制成本:避免 runaway cost

    • 在建立 Claude 訊息時:
    • 設 max_tokens 合理上限
    • 控制 context 長度(不要丟整個專案 repo,先丟必要檔案)
    • 如果是排程任務:
    • 從「每天一次」開始
    • 先跑一週看看用量,再決定要不要加頻率或多任務

    💡 關鍵: 先以低頻率、小 context、適中 max_tokens 測試一陣子,再逐步放大規模,可以有效避免成本爆衝。


    總結

    如果你:

    • 會一點 Python
    • 有一些重複的資訊工作
    • 不想研究整套 Agent 框架

    那以 Claude Skills 作為工具層,加上 Claude API 當腦,就足以在 5–10 分鐘內生出一個實用的小 Agent。先從一個最簡單、最無害的任務開始,把整個流程跑順,之後要擴充成多代理、多專案,只是多加幾個 skills 與排程而已。


    🚀 你現在可以做的事

    • 打開 anthropics/skills 並瀏覽 skills/ 目錄,挑 1–2 個看得懂的 skill 研究輸入輸出
    • 在本機依照文中步驟安裝 repo、設定 ANTHROPIC_API_KEY,跑一次官方範例 agent
    • 依照「匯率 + Slack」示例,改寫成你自己的每天例行任務(例如拉報表、整理 log、寄出摘要)
  • 讓 Notion 變成你的 AI Agent 中樞

    讓 Notion 變成你的 AI Agent 中樞

    📌 本文重點

    • Notion 成為托管多個 AI Agent 的工作台
    • 以狀態變化與欄位更新觸發各種自動化工作流
    • 結合外部 SaaS,打造從資料拉取到 AI 清洗的資料管線

    只要把 Agent 綁在 Notion 頁面和資料庫上,你就能用原本的工作區,托管多個 AI 助手,自動整理內容、跑專案流程、甚至接上外部 SaaS 資料管線。

    參考:Notion 開發者平台介紹(TechCrunch 報導)
    https://techcrunch.com/2026/05/13/notion-just-turned-its-workspace-into-a-hub-for-ai-agents/


    核心功能:Notion 現在是「Agent 工作台」

    💡 關鍵: 把 Agent 綁定在「頁面 / 資料庫」上,等於讓 Notion 變成專屬 AI 助手的工作台,而不是單純筆記工具。

    1. 在頁面 / 資料庫綁定 Agent

    你可以把 Agent 視為「住在某個頁面或資料庫裡的專屬助手」:

    • 每個資料庫都能指定一個或多個 Agent,負責:
    • 自動摘要新頁面內容
    • 解析出行動項(Action items)
    • 幫你填欄位(負責人、優先級、標籤)
    • 每個重要頁面(像 PRD、會議紀錄)可以加上「頁面專屬 Agent」,只處理這一頁的內容與後續追蹤。

    你可以做的事:

    • 為「Meeting Notes」資料庫新增一個 會議整理 Agent,設定規則:只要有新筆記,就產出摘要+行動項目,寫回同一筆紀錄的欄位。

    2. 依「狀態改變」自動執行工作流

    Notion 的資料庫欄位(Status、Select、Checkbox 等)可以變成觸發條件:

    • 例:任務狀態從 Todo → In progress:
    • Agent 自動產生子任務(切分工作)
    • 寫一段「本週進度更新」到更新紀錄欄位
    • 例:狀態改為 Done:
    • Agent 生成 Retro 小結
    • 自動發 Slack 通知給相關頻道

    你可以做的事:

    • 在「專案任務」資料庫加一個 狀態更新 Agent,規則:
    • 當 Status 改成 In progress 時,自動新增 3–5 個子任務欄位建議,讓你選擇採用。

    3. 連接外部 API & 自家服務,變成資料管線

    透過 Notion 開發者平台,你可以把外部 SaaS 當作資料來源,丟進 Notion 再交給 Agent 清洗:

    • 從 CRM(如 HubSpot)、工單系統、回饋表單拉資料進一個「集中資料庫」
    • Agent 負責:
    • 解析文字欄位(工單描述、回饋內容)
    • 自動分類(類別、產品線、嚴重程度)
    • 加標籤或指派負責人

    你可以做的事:

    • 建一個 客戶回饋 資料庫,接上 HubSpot API,讓 Agent 自動幫每則回饋打標籤:功能請求 / Bug / 體驗問題。

    三種實戰場景:從內容、專案到資料管線

    💡 關鍵: 最穩起手式是「先在 Notion 裡把資料結構化」,再讓 Agent 針對欄位與內容運轉,而不是一開始就做複雜自動化。

    1)內容與知識管理:自動整理 PRD、會議紀錄

    典型設定方式:

    1. 建立一個 PRD 資料庫,每個 PRD 是一筆資料。
    2. 為這個資料庫綁定 產品文件 Agent,定義任務:
    3. 讀取 PRD 內容區塊
    4. 生成:
      • 300 字內摘要
      • 主要風險與假設
      • 需要決策的問題清單
    5. 生成內容寫回欄位(Summary / Risks / Decisions)。

    會議紀錄也一樣:

    • Meeting Notes 資料庫 + 會議助手 Agent:
    • 生成摘要
    • 抽取行動項目
    • 自動填入 Owner、Due date 欄位(依你設定的規則或會議參與者)。

    你可以馬上做的事:
    挑一個你最常用的會議紀錄資料庫,新增一個文本欄位 AI 摘要,再設定一個 Agent 規則:新紀錄建立後 1 分鐘內,自動寫入摘要。


    2)專案與工作流:從狀態變化觸發自動化

    想像 Notion = Trello + AI 助手:

    例:產品開發看板

    • 資料庫欄位:Status、Assignee、Priority、更新紀錄 等。
    • 綁定 專案 Agent 規則:
    • 當 Status 從 Design → Dev:Agent 讀整個卡片內容,
      • 自動產出測試清單(Test cases)
      • 寫入 更新紀錄:@QA 並貼測試重點
    • 當 Status → Ready for Release:
      • Agent 產生一段英文 / 中文 release note 草稿
      • 寄出或貼到 Slack 產品頻道。

    你可以馬上做的事:

    • 在專案資料庫加一個 Release note draft 欄位,設定 Agent:只要任務進入 Ready for Release,就根據「變更內容」欄位自動生成初稿。

    3)資料管線:外部工具 → Notion → Agent 清洗

    把 Notion 當成「中間站」:

    範例流程:HubSpot → Notion → AI 標註

    1. 用 Notion developer platform 建立一個簡單整合:
    2. 定期呼叫 HubSpot API 拉新聯絡人 / 回饋
    3. 寫進 Notion Leads 或 Feedback 資料庫
    4. 綁定 銷售線索 Agent 或 回饋分析 Agent:
    5. 解析文字欄位(詢問內容、工單描述)
    6. 填 機會大小、產品類別、優先級 欄位。

    工單系統也類似:

    • 從 Zendesk / Jira Service Management 拉工單進 Notion
    • Agent 自動:
    • 判斷是否為緊急問題
    • 建議指派對象
    • 生出對客戶的回覆草稿。

    你可以馬上做的事:

    • 先選一個來源(如 HubSpot),只同步最小的一個表格(例如最近 50 筆 leads),專心把「自動分類與優先級」這一步做好,再往後串通知或報表。

    怎麼開始:從零到第一個「週報 Agent」

    💡 關鍵: 從一個很小、明確的用例(例如週報)開始,比一次導入整個專案管理更容易落地與調整。

    步驟 1:開啟 Notion 開發者平台權限

    1. 進入工作區 Settings & members。
    2. 在 Integrations / Developers 區塊啟用開發者平台(某些方案需管理員權限)。
    3. 建立一個新 Integration,取得:
    4. Integration ID / Secret
    5. 可存取的資料庫與頁面範圍(務必限制在必要範圍)。

    官方入口:https://www.notion.so/my-integrations (依實際帳號會導向對應頁面)

    行動建議:
    先只開放一個「實驗用」工作區或資料庫給這個 Integration,避免一開始就讓 Agent 看到整個公司內容。


    步驟 2:建立你的第一個 Agent ——「週報助手」

    目標:你在 Notion 填一週做了什麼,Agent 自動:

    • 產出精簡週報
    • 幫你分欄:本週亮點 / 風險 / 下週計畫

    設計方式:

    1. 建立一個 Weekly Report 資料庫,欄位:
    2. Week(日期 / 文字)
    3. Raw notes(你隨便輸入的本週記錄)
    4. Summary(AI 產生)
    5. Highlights、Risks、Next week。
    6. 在開發者平台中,創建一個 週報 Agent:
    7. 觸發條件:Raw notes 更新
    8. 任務:讀取 Raw notes,用固定模板輸出 3 段內容,分別寫入三個欄位。

    你可以馬上做的事:
    找一週你真的很忙的那週,貼入原始 notes(甚至可以是 Slack 摘錄),讓 Agent 幫你整理,看輸出是否能直接拿去給主管或團隊。


    步驟 3:接一個常用 SaaS,從「一句需求」到「實際 automation」

    假設你想要:

    「每天把 HubSpot 新增的高潛力 leads 拉進 Notion,並且自動生成一段聯絡話術。」

    拆成執行步驟:

    1. 自然語言需求 → 規格
    2. 描述給你內部的 AI 或開發同事:
      • 資料來源:HubSpot 新增 leads
      • 條件:lead_score > 80
      • 寫入:Notion Leads 資料庫(Name / Company / Note)
      • Agent 任務:為每一筆產生一段 100 字內的開場訊息。
    3. 實作連接腳本(Node / Python 皆可):
    4. 呼叫 HubSpot API 抓資料
    5. 使用 Notion API 建立資料庫項目
    6. 在 Notion 綁定 銷售話術 Agent:
    7. 觸發:新 lead 建立
    8. 利用 lead 的欄位內容,生成個人化的聯絡訊息,寫入 Opening message 欄位。

    行動建議:
    先把這個流程做成「每天一次批次」而不是即時,方便你人工 review,一兩週成熟後再改成即時自動化。


    與 Zapier / Make 的差別在哪?

    工具類型 名稱 實際核心功能 免費方案 適合誰
    自動化平台 Zapier 連接上百種 SaaS,依事件觸發工作流 有,步數與任務量有限 以「事件轉發」為主的自動化(如表單 → Slack)
    自動化平台 Make 視覺化流程設計、條件分支豐富 有,執行次數有限 複雜條件、自定義 API 整合多
    Agent 中樞 Notion + Agents 在內容上下文中運行 Agent,直接操作頁面 / 資料庫 視方案與工作區設定而定 已把工作放在 Notion,上下文豐富、需要 AI 理解內容的人

    關鍵差異:

    • Zapier / Make:強在「事件與資料欄位」,邏輯清楚但不懂內容。
    • Notion + Agent:強在「內容與上下文」,適合需要理解長文、文件關係的自動化(PRD、會議、工單描述)。

    最實用的做法通常是:

    • 讓 Zapier / Make 負責「資料搬運」
    • 讓 Notion Agent 負責「讀懂內容、整理與生成」。

    安全與權限:啟用前要先想好的事

    在公司導入前,至少做這三件事:

    1. 縮小可見範圍:
    2. 為每個 Agent 建立專用資料庫與頁面,不要一開始就給整個 workspace 權限。
    3. 區分測試與正式環境:
    4. 先在 sandbox workspace 測試 prompt、輸出格式,再搬到正式專案。
    5. 記錄與監控:
    6. 保留 Agent 執行紀錄(可考慮接像 Voker.ai 這類 agent analytics 工具)
    7. 定期 review Agent 產出,調整規則與權限。

    只要你把權限、資料範圍與監控設計好,Notion 就不再只是筆記本,而會變成團隊所有 AI Agent 的中樞:每天在你已經習慣的頁面和資料庫裡,默默跑完一堆你本來要手動做的事。


    🚀 你現在可以做的事

    • 在現有的 Meeting Notes 資料庫新增 AI 摘要 欄位,綁定一個簡單的會議整理 Agent 測試輸出品質
    • 建一個獨立的 Weekly Report 資料庫,實作文中「週報 Agent」流程,實際跑一週看看是否減少整理時間
    • 選一個你常用的 SaaS(如 HubSpot / Zendesk),只同步一小部分資料到 Notion,讓 Agent 做分類與摘要清洗實驗
  • Needle:把工具調用 Agent 塞進手機

    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(伪碼):

    1. 語音 → 文字
    2. 行動裝置用本地或雲端 ASR:
    3. speech.wav -> transcript = "幫我找台北明天不下雨的戶外咖啡廳"

    4. Needle 選工具

    5. 工具例:search_weather, search_places 兩個 API。
    6. needle.route_tools(transcript, tools) → 回傳要先查天氣再查地點的參數 JSON。

    7. 實際 API 呼叫

    8. 你的後端或 App 依 Needle 給的 JSON,分別呼叫天氣 API、地點 API,整理出可用候選。

    9. 大模型生成回覆(可選)

    10. 把 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 之間,實測延遲與成本差異
  • 用瀏覽器跑 Gemma 4 控機器人

    用瀏覽器跑 Gemma 4 控機器人

    📌 本文重點

    • 只用瀏覽器即可完全離線跑 Gemma 4
    • 結合 WebSerial 可直接控制機器人與 IoT
    • 純前端即可實作迷你 AI agent 控制硬體

    不想把資料丟雲端、又想用 LLM 控機器人?Gemma 4 + Transformers.js + WebGPU 讓你只靠瀏覽器就能離線跑模型、還能直接控制硬體。

    參考實作影片:Gemma 4 fully offline + WebGPU + Reachy Mini(Reddit)
    https://www.reddit.com/r/LocalLLaMA/comments/1ta9mmd/gemma_4_running_fully_offline_on_webgpu_with/


    核心功能:一台電腦 + 一個瀏覽器就夠

    1. 完全離線的瀏覽器 LLM

    這套組合的核心是:

    • Gemma 4:Google 開源 LLM 系列,支援多種量化格式(GGUF / ONNX / JS)。
    • Transformers.js:在瀏覽器裡跑 Hugging Face 模型的 JavaScript 函式庫。
    • WebGPU:用你電腦的顯示卡在「前端」跑推理,不用後端伺服器。

    你可以做的事:

    1. 在本機開啟支援 WebGPU 的瀏覽器(Chrome / Edge / Brave)。
    2. 把公司文件、程式碼丟進前端頁面,讓 Gemma 4 在本機推理,不經過任何外部 API。

    實際效果:隱私資料留在電腦裡,沒有雲端 API log,也不需要申請 OpenAI Key 或部署後端。

    💡 關鍵: 只要一台支援 WebGPU 的電腦與瀏覽器,就能完成完全離線、無雲端依賴的 LLM 推理與控制。


    2. 透過 WebSerial 控制機器人 / IoT

    Reddit 的 demo 裡,用 Transformers.js 跑 Gemma 4,搭配 WebSerial API 直接控制 Reachy Mini 機器人。

    流程概念:

    1. 使用者在瀏覽器輸入:「向右揮手打招呼」。
    2. Gemma 4 把自然語言轉成一段控制指令(例如 JSON 或簡單 DSL)。
    3. JavaScript 把指令透過 WebSerial 傳給機器人控制板(例如 Arduino / microcontroller)。

    你可以照做的行動:

    • 先用 Arduino + USB 線,把一顆 LED 或伺服馬達接到電腦。
    • 寫個簡單的序列通訊協議,像:LED_ON、LED_OFF、SERVO:45。
    • 在網頁裡用 JavaScript:

    js
    const port = await navigator.serial.requestPort();
    await port.open({ baudRate: 115200 });
    // 把 LLM 產生的指令寫進 serial

    先從「LLM 控燈」,再慢慢升級到「LLM 控機器人手臂」。


    3. 純前端的迷你 AI Agent

    有了本地 LLM + WebSerial,你可以在瀏覽器裡做一個小型 AI agent。

    • 理解任務:使用者輸入「每 10 分鐘幫我量一次溫度」。
    • 規劃步驟:Gemma 4 產生一段 JSON 計畫,例如:

    json
    {
    "action": "loop",
    "interval": 600,
    "task": "read_temp"
    }

    • 執行控制:前端 JS 解析 JSON,呼叫對應的 serial 指令。

    可以做的練習:

    1. 先讓 LLM 只輸出固定格式 JSON(用 system prompt 約束)。
    2. 前端寫一個 parser,檢查 JSON 格式合法才發送給硬體。
    3. 加上「模擬模式」(不連接硬體),先在 console 測試 agent 邏輯。

    適合誰用?三種場景舉例

    1. 教學場景:高中 / 大學生的 AI + 機器人課

    • 不用架伺服器,電腦教室只要能開 Chrome。
    • 學生可以:
    • 改 prompt 看機器人動作改變。
    • 寫自己的小指令語言(例如 MOVE LEFT 10)。
    • 觀察 LLM 如何把自然語言轉成這套語言。

    行動建議:

    • 用一台 Reachy Mini 或任何 Arduino 小車當教材。
    • 提供學生一個預先寫好的 HTML + JS 專案,只讓他們改 prompt 和指令 mapping。

    2. 實驗場景:研究邊緣運算 / 隱私的工程師

    • 需要在醫療、工廠、或無網路環境下跑 LLM。
    • 想測試「模型就在裝置上」的延遲和可靠性。

    行動建議:

    • 把現有的 Python LLM pipeline,拆成:
    • 前端:Transformers.js + WebGPU 跑推理。
    • 後端(選配):只收集匿名統計,不傳原始輸入。
    • 對比雲端 API 與本地推理在速度、穩定度上的差異。

    💡 關鍵: 在醫療或工廠等高隱私、高可靠場景,本地 LLM 能在不傳輸原始資料的情況下提供近乎即時的推理與控制。


    3. 家用場景:DIY 簡易家電自動化

    • 例如:
    • 「用自然語言控制窗簾、風扇」
    • 「讓 LLM 幫你排家中設備的定時腳本」

    行動建議:

    • 先用 USB 連接一塊 ESP32 / Arduino 開發板,只控制一顆繼電器或 LED。
    • 設計簡單語句:
    • 「晚上 10 點關燈」→ 轉成 SCHEDULE:22:00:OFF。
    • 用 LLM 把上面這種語句自動產生,再由 JS 解讀和排程。

    怎麼開始:從開啟 WebGPU 到控制第一顆 LED

    步驟一:開啟瀏覽器 WebGPU

    以 Chrome 為例:

    1. 更新到最新版(至少 120 以上會較穩定)。
    2. 在網址列輸入 chrome://flags。
    3. 搜尋「WebGPU」,啟用:
    4. WebGPU(或 Unsafe WebGPU 視版本而定)。
    5. 重新啟動瀏覽器。

    行動檢查:


    步驟二:從 Hugging Face 抓 Gemma 4 模型

    常見三種格式:

    格式 名稱示例 特點 適合誰
    GGUF gemma-4b-it-q4_0.gguf 量化後較小,適合 CPU/GPU 混合 已熟悉 ggml / llama.cpp 生態的人
    ONNX gemma-4b-it.onnx 通用,很多推理引擎支援 想跨平台跑推理的開發者
    JS Transformers.js 專用權重 直接在瀏覽器載入 前端工程師、想快速起跑的人

    操作建議:

    1. 到 Hugging Face 搜尋「Gemma 4」模型庫(例如 google/gemma-2-2b-it,實際名稱依官方更新為準)。
    2. 找到有 transformers.js 或 onnx 標籤的 repo。
    3. 把權重檔放在自己的靜態網站(或本機 dev server)供前端載入。

    Transformers.js 官方文件:
    https://huggingface.co/docs/transformers.js

    💡 關鍵: 透過 Transformers.js 專用權重,可直接在瀏覽器載入 Gemma 4,省去自建推理後端的成本與複雜度。


    步驟三:在瀏覽器跑起簡單 Chatbot

    最低限度的前端結構:

    <script type="module">
      import { pipeline } from '@xenova/transformers';
    
      const chat = await pipeline('text-generation', 'path/to/gemma4/model');
    
      async function ask(prompt) {
        const out = await chat(prompt, { max_new_tokens: 128 });
        console.log(out[0].generated_text);
      }
    
      ask('你現在是一個 Arduino 助理,請用 JSON 說明如何讓 LED 閃爍。');
    </script>
    

    行動建議:

    • 先在 console 裡確認模型可以正常回答,再加上簡單的 <textarea> + <button> 當聊天介面。

    步驟四:把 Chatbot 接到 WebSerial(Arduino)

    1. Arduino 端草稿:

    “`cpp
    void setup() {
    Serial.begin(115200);
    pinMode(13, OUTPUT);
    }

    void loop() {
    if (Serial.available()) {
    String cmd = Serial.readStringUntil(‘\n’);
    if (cmd == “LED_ON”) digitalWrite(13, HIGH);
    if (cmd == “LED_OFF”) digitalWrite(13, LOW);
    }
    }
    “`

    1. 前端 WebSerial + LLM:

    “`js
    async function connectSerial() {
    const port = await navigator.serial.requestPort();
    await port.open({ baudRate: 115200 });
    const writer = port.writable.getWriter();
    return writer;
    }

    async function sendCommandFromLLM(userText, writer) {
    const response = await chat(使用者的指令:${userText}
    請只回應一行指令,LED_ON 或 LED_OFF
    );
    const cmd = response[0].generated_text.trim();
    await writer.write(new TextEncoder().encode(cmd + ‘\n’));
    }
    “`

    1. 實際試用:

    2. 在頁面輸入「開燈」→ LLM 產生 LED_ON → 燈亮。

    3. 在頁面輸入「關燈」→ LLM 產生 LED_OFF → 燈熄。

    這就是從「純前端 LLM」到「瀏覽器裡的迷你 AI agent」的第一步。


    小結:從簡單控制開始,一步步加功能

    建議的練習路線:

    1. 第一階段:在瀏覽器跑起 Gemma 4 chatbot,確認 WebGPU 正常。
    2. 第二階段:用 WebSerial 控制一顆 LED 或一個伺服馬達,先用固定按鈕測試。
    3. 第三階段:讓 LLM 產生中介指令(JSON 或簡單 DSL),由 JS 驗證後再送給硬體。
    4. 第四階段:加入簡單記憶和排程,做出「瀏覽器內的小型 AI agent」。

    只要一台支援 WebGPU 的電腦、一顆開發板,就能在客廳或教室裡體驗「完全離線的 LLM 控機器人」。


    🚀 你現在可以做的事

    • 到 Hugging Face 下載一個支援 Transformers.js 的 Gemma 4 模型,放到本機靜態伺服器測試載入
    • 依文中示例寫一個最簡單的前端 Chatbot,確認在你的瀏覽器上能透過 WebGPU 正常推理
    • 準備一塊 Arduino 或 ESP32,照示例建立 LED_ON / LED_OFF 協議,實作第一個「LLM 控燈」實驗
  • 本地 AI 代理寫程式,也要有 AI 幫你審 PR

    本地 AI 代理寫程式,也要有 AI 幫你審 PR

    📌 本文重點

    • AI 寫程式一定要搭配 AI 審查流程
    • adamsreview 提供多代理、分階段 PR 審查
    • React Doctor 專治 AI 產出的 React 小雷
    • 組合成「AI 寫 + AI 審 + 人類決策」完整 workflow

    當你開始大量用 AI 寫程式時,真正的風險不在「寫不出來」,而在「錯誤、壞味道、性能坑」靜靜被合進主幹,所以現在比起寫程式,更需要好的 AI 審查與補救工具。

    下面用兩個最近爆紅的開源工具 adamsreview 和 React Doctor,帶你組一條「AI 寫程式 + AI 審 PR/修 bug」的實戰流程。


    核心功能:兩個工具,一條龍

    工具總覽

    名稱 核心功能 免費方案 適合誰
    adamsreview 多代理分工的 PR 審查,深度檢查邏輯與安全 完全開源 用 GitHub / GitLab、有 PR 流程的後端或全端團隊
    React Doctor 自動檢測、修正 AI 產出的 React 程式碼 完全開源 用 Claude/ChatGPT 產生 React/TSX 的前端團隊

    接下來分別講清楚:

    1. adamsreview 怎麼把 PR 審查拆給多個 AI 代理,使錯誤更難漏掉。
    2. React Doctor 怎麼專門處理「AI 產生 React code 一堆小雷」這件事。
    3. 最後用這兩個工具,組裝一條可直接抄走的開發 workflow。

    一、adamsreview:多代理分工的嚴謹 PR 審查

    核心功能

    adamsreview 是一個專為 Claude Code 設計的插件(slash commands),重點是:

    1. 多階段、多代理 PR 審查
    2. 不是一次跑完,而是分成好幾個階段:整體變更 → 文件/測試 → 安全/性能 → 修正建議。
    3. 每個階段可啟動平行子代理(sub-agents),例如一個看 API 變更,一個看錯誤處理。
    4. 審查狀態存在本地 JSON 裡,可以在不同命令之間保持上下文。

    5. 更少漏網 bug、更少誤報

    作者在 HN 上提到,它在實戰中比:

    • Claude 內建 /review、/ultrareview
    • CodeRabbit、Greptile

    更常抓到真實 bug,同時少講廢話。

    實際上常被抓到的包括:

    • 新增邏輯沒有對錯誤狀況做邊界檢查
    • 漏更新單元測試或 fixture
    • API 變更與文件不一致
    • 可預期的性能問題(例如重複查詢、無 cache)

    💡 關鍵: 多階段、多代理的拆解方式,讓 adamsreview 比一般單次 /review 更容易抓到真正 bug,且減少冗長誤報。

    1. 直接嵌入現有 PR 工作流
    2. 提供像 /review、/codex-review、/fix 等命令,照著你原本用 Claude Code 的習慣延伸。
    3. 可搭配 Codex CLI 與 PR bot,在 PR 上直接留下 AI 審查留言。
    4. 狀態存在檔案裡,方便在 CI 或本地反覆跑不同階段的檢查。

    適合誰用

    幾個具體場景:

    • 有正式 PR 流程的後端/平台團隊

    例如:用本地 LLM 或 Claude 幫你生成 service / handler,透過 adamsreview 做一輪「AI 審 PR」,再交給人類最後確認。

    • 資深工程師很忙的小團隊

    初階工程師用 AI 寫功能,先交給 adamsreview 初審,減少 reviewer 花時間抓基礎錯誤。

    • 正在導入 AI coding,但怕品質失控的團隊

    讓「AI 生成程式碼」必須經過「AI 多代理審查」,有規則可循,而不是全憑 reviewer 心情。

    怎麼開始:最小安裝步驟

    原始專案:https://github.com/adamjgmiller/adamsreview

    以下是一個「最短路徑」,讓你在現有 GitHub PR 流程中接上 adamsreview:

    1. 準備環境

    2. 需要:

      • 有權使用 Claude Code 並可安裝插件(通常是付費方案)。
      • 本機有 git + Node.js(或作者指定的執行環境)。
    3. 安裝與設定

    在你的開發機或開發容器中:

    bash
    git clone https://github.com/adamjgmiller/adamsreview
    cd adamsreview
    # 若有提供安裝腳本
    npm install # 或 pnpm/yarn

    • 依照 repo README 設定環境變數(通常包含 Claude/Codex API key)。

    • 在 Claude Code 中載入插件

    • 打開 Claude Code(或支援的 IDE 插件)。

    • 依 README 說明匯入 slash commands。
    • 你會看到新增的命令,例如:/review、/fix。

    • 在 CI / PR 流程中接上(GitHub Actions 範例)

    在 .github/workflows/pr-review.yml 增加一個簡化版 workflow:

    “`yaml
    name: AI PR Review

    on:
    pull_request:
    types: [opened, synchronize]

    jobs:
    ai-review:
    runs-on: ubuntu-latest

       steps:
         - name: Checkout
           uses: actions/checkout@v4
    
         - name: Setup Node
           uses: actions/setup-node@v4
           with:
             node-version: '20'
    
         - name: Install adamsreview
           run: |
             git clone https://github.com/adamjgmiller/adamsreview
             cd adamsreview && npm install
    
         - name: Run adamsreview
           env:
             CLAUDE_API_KEY: ${{ secrets.CLAUDE_API_KEY }}
           run: |
             cd adamsreview
             # 依專案提供的 CLI 指令
             npm run review -- ../
    

    “`

    這樣每次有人開 PR,就會自動觸發 AI 審查並在 PR 留言(實際指令依 repo 說明調整)。


    二、React Doctor:專治 AI 產出的 React 小雷

    官方 repo:https://github.com/millionco/react-doctor

    它在 README 的第一句就是:「Your agent writes bad React. This catches it」。重點就是:AI 幫你產生的 React/TSX 常常「能跑,但不安心」。

    核心功能

    1. 針對 React/TSX 的靜態檢測與修復

    2. 專門用來掃描 React 專案(JSX/TSX),找到常見的壞味道與 bug。

    3. 例如:
      • 在 useEffect 中漏依賴
      • 不必要的 re-render
      • 不穩定的 key
      • props 型別不一致
    4. 部分問題可以自動產生修正 patch,直接套用。

    5. 和 AI 代理配合運作

    它假設你已經在用 AI(Claude、ChatGPT、Cursor 等)生成元件或 hook:

    • 先讓 AI 產出 code
    • commit 前跑 React Doctor:快速找出「AI style 錯誤」
    • 必要時讓 React Doctor 幫你修補。

    • TypeScript 友善

    • 專案本身用 TypeScript 寫,也善用現有型別資訊。

    • 如果你本來就用 TS + React,導入成本很低,直接把現有 tsconfig、型別檔當基礎。

    💡 關鍵: React Doctor 把「AI 寫得能跑」提升到「依 React/TS 最佳實務可維護」,特別適合大量由 AI 生成的 UI 程式碼。

    適合誰用

    幾個典型情境:

    • 用 Claude/ChatGPT 幫你生 UI 元件

    例如設計稿轉 React Component:

    • AI 負責「寫得出來」。
    • React Doctor 負責「寫得對、好維護」。

    • React 新手 + AI 輔助開發

    新手可能看不出 AI 產生的 code 有哪些壞習慣,React Doctor 可以當成「自動 code review 老師」。

    • 已有大型 TypeScript + React 專案

    部分模組開始用 AI 重構或新增功能,用 React Doctor 當 Safety Net,避免 AI 把舊 code 改壞。

    怎麼開始:在 TS 專案快速啟用

    假設你有一個現成的 React + TypeScript 專案:

    1. 安裝 React Doctor

    專案目錄下:

    bash
    npm install react-doctor --save-dev
    # 或
    pnpm add -D react-doctor

    1. 新增設定檔(若有需要)

    參考 repo 中的樣板(實際檔名跟範例以官方 README 為準):

    bash
    npx react-doctor init

    這通常會產生一個設定檔,例如 react-doctor.config.ts,你可以指定:

    • 要掃描的資料夾(例如 src)
    • 要啟用的規則

    • 在 package.json 加上腳本

    json
    {
    "scripts": {
    "doctor": "react-doctor check src",
    "doctor:fix": "react-doctor fix src"
    }
    }

    1. 在 Git hooks / CI 中啟用

    2. 透過 Husky 或 lint-staged,在 pre-commit 或 pre-push 跑:

      bash
      npx react-doctor check src

    3. 或在 GitHub Actions 加一個 job:

      yaml
      - name: React Doctor
      run: npm run doctor

    這樣每次有人把 AI 產的 React code 推上來,就會被 React Doctor 先掃過一次。


    三、組裝一條「AI coding + AI code review/repair」工作流

    最後用文字幫你拼成一個可以直接採用的流程,從「AI 寫 code」到「AI 審查 + 修正」:

    1. 開發階段:AI 寫程式

    2. 使用本地 LLM、Claude Code 或 ChatGPT:

      • 讓 AI 產出後端 handler、service、React 元件。
      • 人類工程師只負責寫 prompt + 調整架構。
    3. 前端部分:React Doctor 抓小雷

    4. 每次 AI 生成或修改 React/TSX 檔案:

      • 本地跑 npm run doctor 檢查。
      • 對於可自動修正的問題,跑 npm run doctor:fix。
    5. 把這個步驟固定在:

      • pre-commit hook
      • 或 VS Code Task / npm script
    6. 提交 PR:adamsreview 做多階段 PR 審查

    7. 開 PR 後,GitHub Actions 觸發 adamsreview:

      • 階段 1:總覽差異,找出風險區域。
      • 階段 2:針對測試、錯誤處理、安全性做專門檢查。
      • 階段 3:產生具體修正建議或 patch。
    8. PR 上自動留下 AI comment,方便 reviewer 快速聚焦真正問題。

    9. 人類最後把關

    10. Reviewer 看:

      • React Doctor 的報告(前端)
      • adamsreview 的 PR 評論(後端/全端)
    11. 決定哪些建議要採用,哪些視情況忽略。
    12. 合併前至少確保:
      • 所有必跑的 React Doctor / adamsreview 任務都綠燈。

    💡 關鍵: 重點不是「全自動合併」,而是用 AI 把最耗時、最容易忽略的細節掃一遍,再由人類做最後決策。

    這條工作流的重點不是「全自動」,而是:

    • 把 AI 寫程式變成可控的流程,而不是隨意貼 paste code。
    • 把最耗時、最容易忽略的細節(React 小雷、邊界條件、安全性)交給專門的 AI 工具來抓。

    實作上,你可以先選一個小模組試行:

    • 前端導入 React Doctor。
    • 後端/全端導入 adamsreview。
    • 兩週後檢查:PR 審查時間、有 bug 的 PR 比例是否下降,再決定要不要擴大到整個 repo。

    用 AI 寫程式已經變成常態,下一步是在你的團隊裡,建立一套 「AI 寫 + AI 審 + 人類決策」的固定流程,讓速度與品質可以同時兼顧。

    🚀 你現在可以做的事

    • 打開 GitHub,分別把 adamsreview 與 React Doctor repo 加到你的星標與閱讀清單
    • 在一個側專案或小模組上,先實驗接上 React Doctor 的 npm run doctor / doctor:fix 腳本
    • 在現有 repo 新增一個簡單 GitHub Actions workflow,試跑一次 adamsreview 的 AI PR 審查流程