標籤: AI 工具

  • 把你的 Mac 變成本地 AI 工作站

    把你的 Mac 變成本地 AI 工作站

    想在 Mac 上跑 AI,又不想把程式碼、合約、研究資料傳到雲端?Conifer 要做的,就是把你的 Apple Silicon Mac 變成一台真正可離線工作的 AI 工作站。

    📌 本文重點

    • Conifer 把 Apple Silicon Mac 變成本地 AI 工作站
    • 支援本地檔案與應用程式存取,權限由系統控管
    • 開源免費 beta,適合開發本地 Agent 與高隱私場景

    專案連結:Conifer 在 r/artificial 的介紹


    核心功能:把「雲端用法」搬回本地

    1. 專為 Apple Silicon + Rust 寫的本地推論引擎

    Conifer 是一個用 Rust 寫的開源本地推論引擎,底層核心手寫優化,針對 Apple Silicon(M1 / M2 / M3)調教。

    能做什麼:
    – 在 M 系列 Mac 上,比一般沒調教的框架更穩定地跑小到中型 LLM
    – 同一台機器跑多個任務(寫程式、整理文件)時,效能比較不容易「卡住」

    💡 關鍵: 只要是 Apple M1/M2/M3 且有足夠記憶體,你就能在單機上穩定跑小到中型 LLM。

    你可以馬上採取的行動:
    – 檢查自己 Mac:
     > 關於本機 → 處理器是否為「Apple M1/M2/M3」
    – 記憶體至少 16GB8GB 也能跑小模型,但體驗會受限)

    2. 支援本地檔案 / 應用存取,搭配系統權限控管

    Conifer 的設計目標之一,是支援「本地 Agent」:
    – 可以讀寫你的本地檔案(PDF、Markdown、程式碼)
    – 可以呼叫本機應用(例如開啟檔案、寫入資料夾)
    – 權限由作業系統核心層強制管理,避免 AI 亂碰不該動的資料

    這意味著,你可以做:
    – 「幫我整理這個資料夾裡所有 PDF,產出一份摘要」
    – 「讀這個專案的程式碼,幫我改這支函式」

    你可以馬上採取的行動:
    – 想一個你願意讓 AI 自動操作的「專用資料夾」,例如:~/AI_workspace,等等示範 workflow 會用到。

    3. 開源、免費、適合做本地 Agent 原型

    依照開發者在 Reddit 上的說法:
    – 專案是開源、免費,會持續維持這個狀態
    – 團隊目前在招募約 100 位 beta 使用者,一對一協助寫工具、做效能調校

    💡 關鍵: 現階段參與 beta 可以免費獲得一對一協助,讓工具更貼近你的實際需求場景。

    你可以馬上採取的行動:
    – 如果你是開發者或技術使用者,可以考慮加入 beta:
    – 到 Reddit 貼文底下留言說明你的使用情境
    – 或看貼文中是否有 waitlist 表單連結(之後版本有可能會直接公開在 GitHub)


    適合誰用:三種典型場景

    1. 開發者:在本機跑程式碼助手 / 文檔 QA / 客服原型

    具體能做的事:
    – 在 VS Code / JetBrains 旁邊,跑一個本地程式碼助手
    – 把專案文件(Markdown、API spec)丟進一個資料夾,做「本地文件問答」
    – 跑一個簡單客服 bot 原型,用你自己的 FAQ PDF 當知識庫

    你可以馬上採取的行動:
    – 先挑一個你想用 AI 幫忙的專案:
    – 例如一個 Node.js 後端專案資料夾
    – 再準備一個 docs/ 放所有設計文件
    – 之後就能用 Conifer + 本地模型,對這個目錄做 Chat / 查詢。

    2. 內容創作者:離線寫作、改稿、摘要

    如果你常在咖啡廳、出差途中、或沒有穩定網路的地方寫作,Conifer 的價值很明顯:
    – 不連網也能:改寫段落、列大綱、做摘要、翻譯
    – 不用把稿件上傳到第三方雲端

    你可以馬上採取的行動:
    – 建立一個 ~/AI_workspace/articles/ 資料夾
    – 把你正在寫的文章 .md / .docx 匯出成 .txt.md 放進去
    – 稍後我們會示範 workflow:「請本地 AI 幫你整理這個資料夾裡所有文章」。

    3. 高隱私需求行業:法律 / 研究 / 內部知識庫 QA

    結合 Reddit 上法律工作者用本地叢集做草案撰寫的案例,可以把 Conifer 看成「單機版的縮小版叢集」:
    – 法律:讀本地條款、判決書、內部範本,生成草案初稿
    – 研究:整理本地 PDF 論文庫,做摘要、整理引用
    – 公司內部:拿內網手冊和 SOP 做 QA,不經任何雲端 API

    💡 關鍵: 對法律與企業內部知識庫場景,Conifer 讓資料全程留在內網與單機上更容易符合合規要求。

    你可以馬上採取的行動:
    – 準備一個「可以讓 AI 讀」的資料夾,例如 ~/AI_workspace/legal_docs/
    – 先只放不含敏感客戶資料的檔案,確認工具行為和權限再逐步擴大範圍。


    跟其他本地方案比,Conifer 的位置在哪?

    如果你已經在用像 Ollama 這類工具,Conifer 比較像是「更貼近系統、偏工程師向」的一層。

    名稱 核心功能 免費方案 適合誰
    Conifer Apple Silicon 本地推論引擎 + 本地 Agent 支援 開源免費 beta 想做本地 Agent、需要檔案/應用權限控制的技術用戶
    Ollama 一行指令拉模型、快速啟動本地聊天 開源免費 想快速在本機試模型、不需太深度系統整合的使用者

    補充:如果你要的是「只要打開就能聊」的體驗,Ollama 比較接近一般使用者工具;如果你想做「讀檔案、動應用程式」的本地 Agent,Conifer 會比較合適。


    怎麼開始:從安裝到第一次對話

    注意:目前 Conifer 正在 beta 階段,實際命令可能會隨版本調整,下列流程是給你一個「從 0 到能跑」的具體心智模型,細節以官方說明為準。

    步驟 1:從 GitHub 取得 Conifer

    1. 進入專案頁(之後應會公佈在 GitHub,現在可以先從 Reddit 貼文追蹤):
    2. Conifer 介紹貼文
    3. 找到:
    4. GitHub 連結
    5. 或 beta 測試申請表單
    6. 申請 beta:
    7. 簡單說明你的機器規格、預計使用情境(例如:本地程式碼助手 + 文件 QA)

    步驟 2:在 Mac 上安裝(示意流程)

    拿最典型的 CLI 安裝方式舉例,你可以預期會類似這樣:

    # 1. 安裝 Rust(若尚未安裝)
    curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
    
    # 2. 從 GitHub clone 專案
    git clone https://github.com/<team>/conifer.git
    cd conifer
    
    # 3. 編譯執行檔
    cargo build --release
    
    # 4. 把執行檔加入 PATH(依專案說明為準)
    cp target/release/conifer /usr/local/bin/
    

    你可以馬上採取的行動:
    – 確認自己是否能順利用 cargo build 編譯一個 Rust 專案(沒問題的話,跑 Conifer 會順暢很多)。

    步驟 3:下載一個示範模型

    在 beta 階段,團隊通常會推薦一組「測試穩定」的小模型,方便你先確認引擎和權限系統是否正常。

    假設他們提供一個 qwen-3b-conifer.gguf 模型,你可以這樣做:

    mkdir -p ~/conifer-models
    cd ~/conifer-models
    curl -O https://models.conifer.ai/qwen-3b-conifer.gguf
    

    你可以馬上採取的行動:
    – 留意兩件事:Mac 的可用磁碟空間(模型可能是數 GB)、網路下載速度(第一次拉模型比較久)。

    步驟 4:跑起你的第一個本地對話

    完成模型下載後,啟動一個簡單的 CLI 對話伺服器,例如:

    conifer run \
      --model ~/conifer-models/qwen-3b-conifer.gguf \
      --mode chat
    

    接著在終端機輸入:

    你現在在我的 Mac 本機上跑,不連網路。請回覆「已啟動」,並告訴我你能幫我做什麼。
    

    如果模型正常回覆,代表:
    – 推論引擎 OK
    – 模型載入 OK
    – 不需任何雲端 API,就能跑起一個基本聊天助手


    示範 workflow:本地 AI 幫你整理指定資料夾文件

    下面是一個你可以實際用得上的簡單 workflow,示意 Conifer 的「本地檔案 + 權限」能力。

    目標

    給 Conifer 一個資料夾路徑,讓它:
    1. 掃描裡面的 .txt / .md 檔案
    2. 為每個檔案產一段摘要
    3. 輸出成一個 summary.md 報告

    準備

    1. 建立資料夾:
      bash
      mkdir -p ~/AI_workspace/articles
    2. 放入幾個測試檔案 article1.md, article2.md

    可能的 Conifer Agent 方式(概念示例)

    未來 Conifer 會提供類似「工具 + 權限」的設定,你可以:

    1. 在設定檔中開啟檔案系統工具,限定路徑:
      toml
      [tools.files]
      enabled = true
      allowed_dirs = ["/Users/你/AI_workspace/articles"]
    2. 啟動一個「文件整理 Agent」:
      bash
      conifer run \
      --model ~/conifer-models/qwen-3b-conifer.gguf \
      --agent file-summarizer.toml
    3. 發出任務:
      text
      請在 /Users/你/AI_workspace/articles
      讀取所有 .md 檔案,為每個檔案產 3–5 行摘要,
      把結果整理成一個 summary.md 存在同一個資料夾。

    這個流程的重點是:
    – 檔案存取範圍你自己限制
    – AI 只在你指定的資料夾裡讀寫
    – 全程在你的 Mac 上完成,不透過外部伺服器

    你可以馬上採取的行動:
    – 先想清楚:你願意開放給 AI 長期讀寫的 1–2 個「工作資料夾」,其他一律不給權限。


    Beta 現況:怎麼加入與回饋問題

    依照 Reddit 貼文資訊,Conifer 團隊目前:
    – 正招募約 100 位免費 beta 使用者
    – 會跟這些使用者一對一合作:了解需求、寫專用工具、做效能最佳化

    你可以這樣參與:

    1. 到這篇 Reddit 貼文:
      👉 Building Conifer, an open-source local inference runtime
    2. 在留言中說明:
    3. 你的機器(例如:M2 Pro + 32GB RAM
    4. 你打算怎麼用(例如:本地程式碼助手 + 法律文書草案)
    5. 開始測試後,把你遇到的:
    6. Crash log
    7. 效能瓶頸(例如某模型載入太慢)
    8. 需要的工具(例如:想要一個自動讀 PDF 的工具)
      回報給開發團隊

    這樣做的好處是:
    – 你可以在第一時間拿到更穩定、貼近實務需求的版本
    – 你的需求(例如法律、研究場景)會直接影響這個本地 AI 引擎未來的功能優先順序


    如果你已經習慣雲端模型的便利,下一步值得嘗試的,就是把其中一個工作流程搬回本地,在自己的 Mac 上用 Conifer 跑一次,感受「完全不經過網路」的 AI 工作站體驗。

    🚀 你現在可以做的事

    • 檢查自己的 Mac 規格(Apple M 系列 + 至少 16GB RAM),並預留數 GB 空間放模型
    • 建立一個 ~/AI_workspace/,準備好願意給 AI 操作的專用資料夾與測試文件
    • 前往 Reddit 貼文關注 Conifer 專案進展,視需求申請 beta 並規劃你的第一個本地 Agent 用例
  • 把 Claude 變成你的主力工作代理人

    把 Claude 變成你的主力工作代理人

    📌 本文重點

    • 把 Claude 當「可配置代理人」,而非一次性問答工具
    • 善用 Claude.md、Skills、Subagents、Plugins 建立工作流程
    • 針對身份配置專屬 workflow,讓重複工作自動化

    一句話定位:不是再多寫一個 prompt,而是把 Claude 配好「記憶+流程+工具」,變成每天幫你跑任務的主力工作代理人。


    核心功能:先理解這 4 個積木

    目標:看完這一節,你要能說出「Claude 現在在哪裡記東西、怎麼做事、怎麼叫外部工具」。


    1. Claude.md:給代理人一個「長期腦袋」

    • 角色:你的私人知識庫與工作說明書(system prompt 的升級版)。
    • 放什麼:
    • 你的背景(職位、產業、常用技術棧)
    • 任務偏好(寫作語氣、程式碼風格、專案管理習慣)
    • 長期專案的關鍵資訊、慣用模板
    • 使用效果:每次新對話,Claude 自動帶著這份設定,不用再重複解釋自己。

    💡 關鍵: 善用 Claude.md,可以一次設定、長期沿用,省去每次從零解釋背景與偏好的時間成本。

    可以馬上做的事:

    1. claude.ai 登入。
    2. 在設定或 Workspace 設定裡找到 Claude.md 或類似「AI 配置檔」。
    3. 寫第一版內容(建議結構):

    “`markdown
    # 關於我
    – 角色:B2B SaaS 產品經理
    – 常用語言:繁體中文 + 英文技術文件

    # 工作偏好
    – 寫作:偏實用教學,少形容詞,多步驟
    – 文件格式:盡量用 Markdown,標題層級清楚

    # 長期專案
    – 專案 A:AI 產品內部知識庫
    – 專案 B:每週技術選型評估報告
    “`

    1. 日後只要養成習慣:有長期沿用的規則/資訊,就補進 Claude.md,而不是每次對話再講一次。

    2. Skills:可重用的「任務模板」

    • 角色:把你常做的工作,變成一顆一鍵呼叫的小程式。
    • 適合類型:
    • 每週重複的報告(例:每週產品更新摘要)
    • 固定格式的輸出(例:Code review 指南、文章大綱格式)
    • 需要多步驟的任務(例:先讀文件 → 列出問題 → 提出修改建議)

    一個簡單 Skill 範例:專案讀書筆記器

    邏輯:給 Claude 一篇文章連結或貼上內容,Skill 幫你產出固定結構的筆記。

    Skill 內容可以長這樣(概念示意):

    # 技能名稱:research_note
    
    ## 功能
    將一篇文章整理成結構化研究筆記。
    
    ## 輸入
    - `content`: 文章全文或重點摘錄
    
    ## 任務步驟
    1. 先用 3 句話摘要內容。
    2. 條列:關鍵概念、重要數據、引用來源。
    3. 給出:
       - 對我目前專案的啟發
       - 後續可以延伸研究的 3 個問題
    
    ## 輸出格式
    使用 Markdown:
    - 概覽
    - 關鍵概念
    - 數據與引用
    - 對專案的啟發
    - 後續問題
    

    可以馬上做的事:

    1. 在 Claude 介面中找到 Skills(通常在左邊或設定的 Skills / Tools 區)。
    2. 新增一個 Skill,把上面範例貼進去並調整成你的語氣與領域。
    3. 之後看到文章,直接對 Claude 說:

    research_note 幫我整理這篇,內容在下面:


    3. Subagents:把大任務拆給專職小幫手

    • 角色:一個大代理人(你平常在聊的 Claude),底下可以派出「專職分身」。
    • 適合情境:
    • 寫作:資料研究 agent、結構調整 agent、潤稿 agent 各司其職
    • 工程:debug agent、測試覆蓋率 agent、文件撰寫 agent
    • 專案管理:需求整理 agent、風險盤點 agent、會議紀錄 agent

    參考 多代理系統實作文章 的做法,你可以這樣配置:

    • ResearchAgent:只負責找資料、整理重點,不下結論。
    • WriterAgent:只根據整理好的重點寫初稿。
    • EditorAgent:只負責風格、語氣、構優化。

    可以馬上做的事:

    1. 在 Skills 區先各自為 researchwriteedit 建立對應 Skill。
    2. 建一個「總控 Skill」,流程像這樣:

    markdown
    1. 呼叫 ResearchAgent Skill,輸入主題。
    2. 將輸出傳給 WriterAgent Skill,生成草稿。
    3. 將草稿丟給 EditorAgent Skill,優化文稿。

    1. 你對 Claude 下命令就只剩一句:

    用你的寫作工作流幫我處理這個主題:XXX

    這呼應了「Plan 模式比一次搞定更重要」的思路(可參考 這篇 Plan mode 深入解析)。


    4. Plugins / MCP:把 Notion、GitHub、日曆接進來

    • Plugins(或 MCP 伺服器):讓 Claude 能「去別的服務做事」,而不是只在聊天室輸出文字。
    • 常見接法:
    • Notion:讀寫頁面、幫你整理研究筆記
    • GitHub:查 issue、看 PR、寫 review 建議
    • 日曆:生成待辦、排會議時間

    可以馬上做的事:

    1. 在 Claude 設定中找到「Plugins」或「MCP」管理頁面。
    2. 授權你常用的工具(例如 Notion / GitHub)。
    3. 測試一個實用指令:
    4. Notion:

      幫我把這篇研究筆記整理成 Notion 新頁面,放在資料庫「AI Research」底下。

    5. GitHub:

      幫我看這個 PR,先列出潛在風險,再寫一段給同事看的 review。連結在這裡:XXX


    適合誰用:3 種典型配置範例

    目標:對照自己的身份,直接抄一套設定起來。


    1. 個人工作者:寫作 / 研究 / 專案管理

    建議配置:

    • Claude.md
    • 明確定義你的寫作風格、常用結構(例如所有教學文都用「背景 → 步驟 → 範例 → 常見錯誤」)。
    • Skills:
    • research_note:文章/論文筆記
    • outline_builder:輸入主題,自動給 2–3 個不同角度的大綱
    • meeting_minute:貼原始會議筆記,輸出「決策/待辦/風險」三欄
    • MCP / Plugins:
    • Notion 或 Obsidian 相關工具,讓筆記自動進入你的知識庫。

    日常 workflow 範例:

    1. 丟 3–5 篇相關資料給 Claude,用 research_note 各自整理。
    2. outline_builder 產出文章大綱,選一版改一改。
    3. 完稿後請 Claude 依指定格式,寫成 Notion 新頁面並歸檔。

    2. 工程師:Code Review + 多 repo 協作

    建議配置:

    • Claude.md
    • 寫清楚專案技術棧、程式碼風格規範、測試原則。
    • Skills:
    • code_review:給 PR 連結或 patch,輸出:問題清單、風險點、建議 commit 清單。
    • test_case_generator:根據函式/API,幫你列出缺的測試案例。
    • Subagents:
    • ArchitectureAgent:只看架構與邏輯。
    • StyleAgent:只看命名、風格、一致性。
    • MCP / Plugins:
    • GitHub / GitLab 工具,直接讀 PR diff、issue 歷史。

    日常 workflow 範例:

    1. 對 Claude 說:

    幫我用你的 code_review 工作流檢查這個 PR:XXX

    1. Claude 讀 GitHub diff,先由 ArchitectureAgent 看設計,再由 StyleAgent 補充風格問題,最後合併成一份可直接貼回 PR 的 review。

    3. 小團隊:共用一組技能與工作流

    建議配置:

    • 共用 Workspace 的 Claude.md
    • 放團隊寫作規範、技術決策原則、產品定位。
    • 共用 Skills:
    • weekly_update:所有人都用同一個模板輸出週報。
    • spec_template:PRD / 技術規格文件的標準結構。
    • MCP / Plugins:
    • 共用的 Notion、Jira、GitHub 專案權限。

    操作方式:

    1. 由一人負責整理團隊的 Claude.md 和 Skills。
    2. 其他成員只需要:
    3. 在週報時輸入:

      weekly_update 幫我整理這週的進度,重點在 XXX。

    4. 寫新功能時:

      spec_template 幫我產生這個功能的 PRD 初稿,功能說明如下:XXX。


    一小時內用起來:實戰 workflow 示範

    目標:照這段做完,你就有「從資料收集 → 產出大綱 → 自動整理到知識庫」的一套日常代理人流程。


    Step 1:開啟並寫好第一版 Claude.md(10 分鐘)

    1. 打開 claude.ai → 設定 → Claude.md
    2. 貼入這個模板再依需求修改:

    “`markdown
    # 關於我
    – 角色:__
    – 主要領域:
    ____

    # 工作偏好
    – 回覆語言:繁體中文
    – 文件格式:預設使用 Markdown
    – 風格:先給結論,再拆解步驟

    # 長期專案
    – 專案 1:__(簡述目的與目前進度)
    – 專案 2:
    ____
    “`


    Step 2:建立第一個 Skill:研究筆記(10 分鐘)

    1. 到 Skills 管理頁,新增 Skill research_note
    2. 使用前面提供的 research_note 範本,改成你的領域語氣。
    3. 找一篇你最近在看的文章,把內容貼給 Claude,指定使用 research_note

    Step 3:讓 Subagent 接手子任務:大綱生成(15 分鐘)

    1. 新增 Skill outline_builder,內容類似:

    “`markdown
    # 技能名稱:outline_builder

    ## 功能
    針對一個主題,產生 2–3 個不同角度的大綱,每個大綱最多 5 個主標。

    ## 步驟
    1. 簡要理解主題與目標讀者。
    2. 提出 2–3 種切入角度。
    3. 針對每種角度,列出主標與一句說明。
    “`

    1. 建立一個「寫作工作流 Skill」,流程:
    2. 先呼叫 research_note 消化資料。
    3. 再把研究結果摘要丟給 outline_builder
    4. 你只要給主題 + 資料清單,就能一次拿到整理後的研究+多版本大綱。

    💡 關鍵:research_note + outline_builder 串成 workflow,一次輸入主題就能從資料整理到多版本大綱,大幅降低起稿門檻。


    Step 4:接上 Notion,自動寫入知識庫(15–25 分鐘)

    1. 在 Plugins / MCP 介面中,啟用 Notion 並完成授權。
    2. 建一個 Notion 資料庫,叫做「AI 研究庫」。
    3. 對 Claude 下指令:

    從現在開始,所有用 research_note 產出的內容,幫我整理成 Notion 新頁面,放在「AI 研究庫」,標題用日期+主題。

    1. 測試一次完整流程:
    2. 丢一篇文章 → 用 research_note 整理。
    3. 要求 Claude 寫入 Notion。
    4. 打開 Notion 確認格式與欄位是否符合期待,必要時微調規則。

    延伸工具:如果想把多個 AI 輸出集中管理

    如果你平常 Claude / ChatGPT / Gemini 都會用,可以考慮配合像 Coffer 這類工具,把所有 AI 回覆存進一個可搜尋的 vault(原作者分享在 Reddit)。

    名稱 核心功能 免費方案 適合誰
    Claude 主力工作代理人:Claude.md + Skills + MCP 想把 AI 當長期工作夥伴的人
    Coffer 儲存多家 AI 回應到本地可搜尋知識庫 重度問 AI、怕內容散佈的人

    💡 關鍵: 把多家 AI 的回應集中到同一個可搜尋知識庫,可以避免資訊分散在不同聊天裡,長期累積成真正可用的資產。


    只要先把 Claude 當成「可以配置的代理人」,而不只是「一次性的問答工具」,從 Claude.md、Skills 到 Subagents、Plugins 一步步搭起來,你就會開始感受到:每天重複的工作,有越來越多可以丟給它接手。

    🚀 你現在可以做的事

    • 登入 claude.ai,建立並填好你的第一版 Claude.md
    • 新增一個 research_note Skill,實際拿一篇文章讓 Claude 幫你整理研究筆記
    • 啟用 Notion 或 GitHub Plugin,測試一次「從 Skill 輸出到外部工具」的完整工作流
  • NuExtract3:把 PDF 截圖變成乾淨資料

    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,欄位有 datevendortotal_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,驗證能否接到現有流程
  • 把 NVIDIA Deep Research 當實習生用

    把 NVIDIA Deep Research 當實習生用

    📌 本文重點

    • NVIDIA Deep Research Agent 是「會自己調研與寫報告」的 AI 實習生
    • 能自動上網搜尋、整理來源並產出可追溯的研究報告
    • 以「專案工作空間」形式運作,適合市場研究與技術選型等場景

    用一句話講清楚:NVIDIA Deep Research Agent 就是「會自己上網查資料、存筆記、整理報告、附上引用來源」的 AI 實習生,比一般只能聊天的機器人,更接近一個真的研究助理。

    專案連結(GitHub):https://github.com/NVIDIA/GenerativeAIExamples/tree/main/agents/deep-research


    核心功能:比一般聊天機器人多了什麼?

    1. 會自己規劃調研流程,而不是只回一段答案

    一般聊天機器人:

    • 你問:「幫我看 2024 台灣電動車市場發展?」
    • 它直接生成一段「看起來合理」的摘要,但可能沒查新資料,來源不明。

    Deep Research Agent 的做法:

    1. 先把問題拆成子任務:市場規模、主要品牌、政策、關鍵數據…
    2. 逐步上網搜索,每一步都記錄查到的內容
    3. 整理成「研究筆記檔」,最後再寫成報告

    💡 關鍵: Deep Research 不是只回一段答案,而是走完整「拆題 → 搜尋 → 做筆記 → 成稿」流程。

    你可以做的事:

    • 在 prompt 裡直接下達研究任務,例如:
    • 「請做一份 5 頁的市場研究:主題是台灣 2024 電動車市場,列出主要品牌、市佔估計、最近一年重要新聞,最後整理成簡短建議。」
    • 把它當「會自己查資料的實習生」,而不是問答機器人。

    2. 自動搜尋 + 整理來源,幫你做「可追溯」的研究

    Deep Research Agent 會:

    • 主動呼叫搜尋工具(預設走網路 search API)
    • 讀取多個網站內容,過濾重複與雜訊
    • 把每條資訊連同來源網址存起來
    • 最後在報告中附上清楚引用(像研究報告的 reference 區)

    對比一般聊天機器人:

    • 回答多半是「綜合模型訓練時學到的知識」,很難知道哪一段是最新、哪一段來自哪個來源。

    💡 關鍵: 每個關鍵結論都對應具體網址,讓你可以抽查與追溯,而不是盲目信任模型輸出。

    你可以做的事:

    • 要求它在輸出中固定附上引用區,例如:
    • 「請在每個關鍵結論後標注 [來源 1] [來源 2],並在文末列出完整網址。」
    • 用這些引用,手動抽查 1–2 個關鍵數據,確保內容可信。

    延伸閱讀:NVIDIA 開源介紹文章(Towards AI)
    https://pub.towardsai.net/nvidia-open-sourced-a-deep-research-agent-that-beat-openai-on-its-own-benchmarks-5339b3f547fb


    3. 有「工作空間」的 Agent,而不是沒記憶的聊天框

    很多非程式碼 Agent 做不好,很大原因是沒有穩定工作空間——這點在 Reddit 討論裡講得很清楚:non-coding agents should also live in file systems

    Deep Research Agent 的設計比較像一個「專案資料夾」:

    • 每個研究任務會形成一組檔案:
    • 原始搜尋結果
    • 中途整理的筆記
    • 最終報告
    • Agent 可以反覆讀寫這些檔案,再繼續深化研究

    💡 關鍵: 用「檔案與專案」當記憶體,讓 Agent 可以多輪迭代深化同一主題,而不是每次從零開始聊。

    你可以做的事:

    • 把每一個「問它的大問題」當成一個專案,例如:
    • project: EV-market-tw-2024
    • project: crm-tools-comparison
    • 把產出的 Markdown 報告直接丟進你的筆記軟體(Obsidian、Notion)當專案檔案。

    適合誰用?幾個實際場景

    1. 市場研究 / 會前簡報

    需求:你要開一場客戶會議,得先快速了解對方產業現況。

    操作示例:

    • 任務描述:
    • 「客戶是做 B2B SaaS CRM 的,幫我整理 2022–2024 全球 B2B CRM 市場趨勢、主要玩家、常見商業模式,最後整理一句話電梯簡報 + 5 項我應該問的問題。」
    • 把 Deep Research Agent 的報告:
    • 直接 copy 成 PowerPoint 大綱
    • 或貼到 Notion,當成會前 brief

    2. 競品分析 / 工具選型

    需求:你在選 CRM、客服系統、A/B test 平台。

    操作示例:

    • 任務描述:
    • 「幫我比較 Intercom、Zendesk、Freshdesk 三個工具,重點看價格方案、支援語言、整合 API 能力,做成表格,最後給出 3 種不同規模公司(10 人、50 人、200 人)的建議。」
    • 你要做的:
    • 把輸出的表格貼進你團隊的提案文件
    • 把引用網址交給實習生或同事做二次驗證

    3. 技術選型調研

    需求:你在選擇 LLM、RAG 架構或 MCP agent 框架要上線到產品(可參考這篇實戰文:https://pub.towardsai.net/i-shipped-a-rag-mcp-agent-to-production-five-things-broke-0f030ff6f3f9)。

    操作示例:

    • 任務描述:
    • 「整理目前主流的 RAG + MCP agent 開源方案,要求列出:GitHub 星數、是否支援雲端 / 本地部署、常見踩坑與評估建議,重點對象是要上 production 的 SaaS 團隊。」
    • 接著你可以:
    • 用報告當作技術評估會議的初稿
    • 在每個風險點上再請 Deep Research Agent 深挖,反覆迭代。

    怎麼開始:從安裝到接上你的知識庫

    1. 準備環境與 API Key

    最低需求:

    • Python 3.10+ 環境(本機或雲端都可)
    • 一張 NVIDIA GPU 會更順(但也可只用雲端 API)
    • 至少一個可用的 LLM API Key,例如:
    • NVIDIA NIM / NVIDIA API
    • 或其他支援的雲端模型供應商

    你要做的事:

    1. 申請 NVIDIA API 帳號(若使用他們的模型):https://build.nvidia.com
    2. 拿到 API Key,寫入 .env 或環境變數,例如:

    bash
    export NVIDIA_API_KEY="你的 key"


    2. 安裝與在本機快速跑起來

    以 GitHub 專案為主線:

    git clone https://github.com/NVIDIA/GenerativeAIExamples.git
    cd GenerativeAIExamples/agents/deep-research
    
    # 建議開一個虛擬環境
    python -m venv .venv
    source .venv/bin/activate  # Windows 用 .venv\Scripts\activate
    
    pip install -r requirements.txt
    

    通常範例專案會提供一個 demo 指令(名稱可能略有變化,依 README 為準):

    python deep_research.py \
      --query "請分析台灣 2024 電動車市場的主要趨勢與廠商" \
      --output ./outputs/ev-market-tw-2024.md
    

    你要做的事:

    • 改掉 --query 裡的內容,直接換成你現在真正在做的專案題目
    • 執行後,到 outputs/ 夾裡打開 Markdown 報告

    3. 在雲端(Colab / VS Code Remote)跑

    如果你本機沒有 GPU 或懶得裝環境,可以:

    • 找一份針對 NVIDIA Deep Research Agent 的 Colab notebook(通常社群會有人整理)
    • 或在雲端 VM(如 AWS、GCP、Azure)裡跑上述安裝流程

    你要做的事:

    • 儲存好 notebook,當成你的「研究模板」
    • 每次只改問題與輸出檔名,就能重複使用。

    4. 串接到你的筆記 / 知識庫工作流

    目標:建立一條「從問題 → 調研 → 報告」的固定管線。

    最簡單做法:

    1. 輸出格式固定用 Markdown
    2. 在啟動腳本中加入:--format markdown(若有此選項)
    3. 指定輸出資料夾對應到筆記工具
    4. Obsidian:把 outputs/ 變成一個 vault 內的資料夾
    5. Notion:用 Notion API 定期把 outputs/*.md 同步上去
    6. 在筆記裡建立「研究模版」
    7. 標題:{{專案名稱}} Deep Research 報告
    8. 區塊:背景、發現、數據表、風險、建議、來源連結

    你可以立刻做的事:

    • 為你接下來一週要決定的「一個重要選項」(例如要不要換 CRM)建一個專案資料夾
    • 用 Deep Research Agent 生成第一版調研報告
    • 用你自己的專業重新整理重點後,發給團隊當決策前閱讀材料。

    小結:把它當「會查資料的實習生」,而不是魔法

    使用 NVIDIA Deep Research Agent 的正確心態:

    • 它擅長的是幫你大量收集與初步整理,節省你 60–80% 搜集資料的時間
    • 你仍然要:
    • 選題、定義問題
    • 抽查關鍵引用
    • 把輸出整理成真正要對外發表的報告或簡報

    💡 關鍵: 把 60–80% 搜資料的時間交給 Agent,你可以把精力放在判斷與決策上。

    只要先從一個你本來就要做的調研開始,你很快就會感受到,把 AI 當實習生用,和「只是多一個聊天機器人」有多大差別。

    🚀 你現在可以做的事

    • 打開 GitHub 專案並依照 README 完成安裝,跑一次示範指令
    • 挑一個你這週真的要做的決策議題,寫成 --query 給 Deep Research Agent
    • 把產出的第一版報告整理進 Obsidian 或 Notion,當作團隊會議前閱讀材料
  • RTK 終端機 AI 助手:少花 90% Token

    RTK 終端機 AI 助手:少花 90% Token

    📌 本文重點

    • RTK 用結構化壓縮幫你減少重複丟給模型的 Token
    • 常用專案可重用上下文,問越多次平均越省
    • 在終端開發流程中無痛接入,五分鐘內可上手

    你現在用 AI 幫忙寫程式,很可能有一大半錢都燒在「重複丟給模型看的 Token」上,而 RTK 要做的,就是在終端機幫你把這些多餘 Token 全部擠乾。

    專案連結:https://github.com/rtk-ai/rtk


    核心功能:RTK 怎麼幫你少丟 Token?

    1. Prompt 壓縮:把廢話變成精簡結構

    一般你在終端機複製錯誤訊息、整段程式碼給 AI,看起來沒幾行,實際 Token 超多。RTK 做的事是:

    • 先在本地做「結構化」:分出錯誤訊息、檔案片段、指令上下文
    • 用短 Prompt 模板描述需求,例如:
    • 錯誤訊息 + 詢問目標(幫我找 bug)
    • 這段程式 + 修改要求(改成 async)
    • 最後送給模型的內容會是高度壓縮的結構,而不是你手動貼的一大坨文字

    你可以這樣行動:

    • 不要再打長篇自然語言 Prompt,改用 RTK 的命令別名(例如 rtk fix, rtk explain),把「要做什麼」交給 RTK 的模板處理。

    2. 上下文重用:同一個專案不重講第二次

    平常你每問一次 AI:「這個專案是做什麼的?」「這個模組是幹嘛?」都在重複付費。RTK 會:

    • 對常問的目標(例如某個目錄、特定檔案)做一次「結構化摘要」
    • 接下來跟同一個會話相關的指令,就重用這些摘要,而不是把整份檔案再丟一次

    具體效果:

    • 問同一個 repo 的問題越多次,平均每次的 Token 消耗越低
    • 對超過數萬行的專案,差異會特別明顯

    💡 關鍵: 專案越大、問越多次,RTK 的上下文重用機制帶來的平均 Token 成本下降就越明顯。

    你可以這樣行動:

    • 針對常用專案建立一個 RTK 會話,之後都在這個會話裡問問題,而不是每次都「一次性丟完所有檔案」。

    3. 結構化輸入 / 輸出:減少「看懂答案」的成本

    RTK 不只壓縮你給模型的內容,也會讓模型的回答更結構化,例如:

    • 要求模型輸出固定格式:原因 / 修復步驟 / 建議指令,而不是亂聊一通
    • 要模型只返回「要改的那幾行」,而不是整份檔案,減少輸出 Token

    你可以這樣行動:

    • 習慣用 RTK 指令,而不是「請用條列式說明」這種自然語言;RTK 已經替你定義好能省 Token 又好讀的輸出格式。

    RTK 當 CLI 代理:三種高頻使用場景

    1. 日常開發:錯誤訊息、修小段程式、產生命令

    在日常開發中,你大概會一直做這幾件事:

    1. 看錯誤訊息:不知道哪裡爆
    2. 改小段程式:加 log、改型別、改函式簽名
    3. 產生命令:不知道某個工具的 CLI 參數要怎麼下

    RTK 的典型玩法:

    • 看錯誤訊息

    bash
    # 把上一個命令的錯誤訊息丟給 RTK 解釋
    some-command-that-fails 2>error.log
    rtk explain-error < error.log

    行動:把原本你會貼到 ChatGPT / Claude 的 error log,改成用 rtk explain-error,RTK 會用短 Prompt + 結構化提問幫你省 Token。

    • 改小段程式

    bash
    # 針對某個檔案的一小段範圍做修改建議
    rtk edit src/main.rs --range 20-60 --ask "改成 async/await 風格,保留原本邏輯"

    行動:只給 RTK「相關的幾十行」,不要整支檔案,RTK 會幫你把上下文描述給模型,降低 Token。

    • 產生命令

    bash
    # 根據需求生成 shell 指令,不用自己翻 man page
    rtk cmd "把 logs 資料夾裡 7 天前的 .log 壓成一個 tar.gz,檔名帶日期"

    行動:用自然語言描述「你想做什麼」,讓 RTK 負責用精簡 Prompt 跟模型談,輸出最終的 shell 指令。


    2. 讀專案:總結檔案、生成說明、快速問代碼

    當你接手一個新 repo,通常會做:

    • 看 README 還是不懂整體架構
    • 想知道某個模組的職責
    • 想快速問「這個函式在哪裡用到」

    RTK 的用法可以是:

    • 總結檔案 / 目錄

    “`bash
    # 總結一個檔案在幹嘛
    rtk summarize src/lib.rs

    # 總結一個目錄的主要模組與職責
    rtk summarize src/handlers/
    “`

    • 生成說明文件

    bash
    # 幫某個模組產生說明文字(例如供 PR 或文件用)
    rtk doc src/services/user.rs --format markdown

    • 快速問代碼

    bash
    # 在 repo 裡問問題,RTK 只會選關聯檔案給模型看
    rtk ask "登入流程中,token 驗證主要在哪幾個檔案處理?"

    行動:把「整個 repo 丟進 AI」改成「用 rtk summarizertk ask 針對性查詢」,每次只給必要檔案,Token 消耗會明顯下降。


    3. 結合 tmux / fzf / git workflow:變成隨叫隨用 AI 幫手

    RTK 的本質是單一 CLI binary,很適合跟你現有的終端機工具整合:

    • 搭配 tmux:固定一個 pane 做 RTK 聊天視窗

    bash
    # tmux 裡開一個新 pane 專門跑 rtk chat
    rtk chat

    行動:在 tmux 裡維持一個長期會話,RTK 可以反覆重用上下文,越聊越省 Token。

    • 搭配 fzf:選檔後丟給 RTK

    bash
    # 用 fzf 選一個檔案丟給 RTK 總結
    rtk summarize "$(fzf)"

    • 搭配 git workflow:讓 AI 看 diff 而不是整檔

    bash
    # 只把當前變更的 diff 丟給 RTK 請他協助寫 PR 說明
    git diff > /tmp/diff.patch
    rtk explain-diff < /tmp/diff.patch

    行動:在你的 shell 設定(例如 .zshrc.bashrc)裡建立幾個 alias,把平常會複製貼上的工作改用 RTK 處理:

    alias rpr="git diff | rtk explain-diff"
    alias rerr="rtk explain-error"
    

    適合誰用?三種典型開發者

    • 1. 每天都開著 AI 編輯器(Cursor、Claude Code)的工程師
      你已經習慣「寫一寫就問 AI」,RTK 適合接在你終端機工作流的空白處:看 log、看 diff、產生命令,這些在編輯器之外的操作用 RTK 承接,Token 花在真正需要的地方。

    • 2. 維護大型專案或多 repo 的開發者
      尤其是 Rust / Java / monorepo,檔案多、型別長、錯誤訊息又臭又長,用 RTK 的結構化摘要 + 上下文重用,可以顯著減少「每次都要把半個專案丟給 AI」的情況。

    • 3. 自費用 API Key 的個人開發者 / Side project 作者
      如果你是自己刷卡買 OpenAI / Anthropic / 其他 LLM Token,用 RTK 是直接對帳單有感的程度;原本一個月 30–50 美金的,也許可以壓到 10–20 美金。

    💡 關鍵: 若你自己付模型費,用 RTK 把「貼錯誤 / 貼整檔 / 貼 diff」改成結構化對話,帳單級別的節省會非常直接。


    5 分鐘開始用 RTK:安裝、設定、跑幾個指令

    1. 安裝單一 binary

    到 GitHub Releases 頁下載對應平台的 binary:

    • 進入 https://github.com/rtk-ai/rtk
    • 點選右側 Releases
    • 下載對應系統檔案(例如 rtk-x86_64-unknown-linux-gnurtk-aarch64-apple-darwin
    • 賦予執行權限並放到 PATH 裡,例如:
    chmod +x rtk-x86_64-unknown-linux-gnu
    sudo mv rtk-x86_64-unknown-linux-gnu /usr/local/bin/rtk
    

    2. 設定 API Key

    RTK 本身不附模型,你需要設定自己的 LLM 供應商 API key(例如 OpenAI / Anthropic 等,依官方文件為準):

    export OPENAI_API_KEY="你的 key"
    # 或依照 RTK 說明設定 RTK 專用環境變數,例如:
    export RTK_MODEL_PROVIDER=openai
    export RTK_MODEL=gpt-4.1-mini
    

    建議:

    • 選一個便宜的小模型當預設(例如 gpt-4.x-mini / o3-mini 類型),RTK 本身就已經會幫你省 Token,小模型更划算。

    💡 關鍵:RTK_MODEL 設成較便宜的小模型,再搭配 Prompt 壓縮,能在不明顯犧牲效果的前提下把成本再壓一截。


    3. 試跑幾個典型指令

    照著下面三步走,你大概五分鐘內就能感受到 RTK 的節奏:

    1. 解讀錯誤訊息

    bash
    cargo build 2>error.log
    rtk explain-error < error.log

    1. 總結專案主檔案

    bash
    rtk summarize src/main.rs

    1. 生成一個命令

    bash
    rtk cmd "找出今天修改過的 .rs 檔,列出檔名和變更行數"


    怎麼量化:你到底省了多少 Token?

    如果你是自己付費買 API,建議直接用「帳單」來感受 RTK 的效果,而不是只看官方說的 60–90%。你可以:

    1. 先觀察一週的原始用量
    2. 不改工作流程,照常用 Cursor / Claude Code / ChatGPT 開發
    3. 記下這週在模型供應商後台的 Token 用量 / 金額

    4. 下一週加上 RTK

    5. 日常 terminal 問題全部改用 RTK(錯誤、log、diff、命令)
    6. 大型專案閱讀改用 rtk summarizertk ask

    7. 對比兩週帳單

    8. 如果你平常大量貼錯誤訊息、整檔 code、diff 給 AI,看起來會有 30–50% 甚至更多的節省

    進階做法:

    • 把 RTK 指令加上 --verbose 或開啟 debug log(依官方說明),讓它輸出實際的 Token 用量,對照供應商後台的數字,清楚看到壓縮前後的差異。

    RTK 的重點不是「多一個聊天機器人」,而是把你原本就會做的事——貼錯誤、貼代碼、貼 diff 問 AI——改成一種對 Token 比較友善的方式。如果你現在已經很依賴 AI 寫程式,那麼把這些對話搬進 RTK,大概是最省時、也最省錢的下一步。

    🚀 你現在可以做的事

    • 進入 RTK GitHub Releases 下載對應平台的 rtk binary 並加入 PATH
    • 在 shell 設定中加入 OPENAI_API_KEYRTK_MODEL 等環境變數,設好預設小模型
    • 建立幾個常用 alias(例如 rerr, rpr),並用 rtk explain-errorrtk summarize 開始取代貼到聊天機器人的動作
  • 用 Claude.md 做一個不會爛掉的長跑代理

    用 Claude.md 做一個不會爛掉的長跑代理

    📌 本文重點

    • CLAUDE.md 嚴格約束代理行為,避免長跑爛掉
    • 核心原則是「行動+證據」,禁止空談與無限迴圈
    • 透過上下文壓力自查與簡潔憲法,讓代理長時間穩定運作

    用一份不到 100 行的 CLAUDE.md,就能讓你的 Claude 代理連跑幾小時都不會開始胡言亂語、卡住不動或重複修同一個 bug。

    參考原作者在 Reddit 的分享:
    – 長跑 Claude Code 代理的設定檔開源文:https://www.reddit.com/r/ClaudeAI/comments/1tjy3sk/i_opensourced_the_operating_file_that_keeps_my/
    – 100 條個人 AI 代理實戰心得:https://www.reddit.com/r/ClaudeAI/comments/1thi6nh/100_tips_tricks_for_building_your_own_personal_ai/


    核心功能:這份 CLAUDE.md 到底做了什麼?

    1. 只允許「行動與證據」,禁止長篇空談

    長跑代理會爛掉,通常是這三個症狀:

    1. 開始寫「我將會…」「接下來我要…」但不真的執行工具
    2. 一直說「應該已修好」但沒有測試結果
    3. 花很多篇幅重複解釋計畫,實際變更很少

    CLAUDE.md 的核心規則,就是把這些行為全部關掉:

    • 輸出只允許三種型態
    • 已完成的動作(例如:檔案修改、指令執行、API 呼叫)
    • 具體問題 / 需要決策的提問
    • 極短的進度摘要
    • 聲稱「完成」前要附證據:如測試輸出、報表截圖路徑、命令列結果

    💡 關鍵: 將輸出限制為「行動+證據」,能大幅減少長篇空談與無效迴圈,讓長跑代理真正持續推進任務

    你可以做的事
    – 在你的專案根目錄放一份 CLAUDE.md,明確寫出:
    – 「不要描述你要做什麼,只要直接做並回報結果」
    – 「任何『應該已修好』前,必須貼出測試輸出」

    2. 內建「上下文壓力」自我檢查

    長跑幾小時後,對話上下文會變超長,Claude 開始:

    • 忘記早期需求
    • 無法把握目前專案狀態
    • 回答變模糊或重覆

    原作者在 CLAUDE.md 裡加了一條關鍵原則:

    代理要定期自查上下文壓力:發現自己搞不清狀態,就主動整理摘要、刪除多餘上下文、或要求人類幫它重設現狀。

    具體做法通常包含:

    • 每完成一個階段任務,就輸出一個「短摘要 + 關鍵檔案清單」
    • 長度過大時,優先保留:
    • 最新的決策
    • 目前版本的檔案 / 結構
    • 尚未完成的待辦

    你可以做的事
    – 在 CLAUDE.md 寫明:
    – 「當你感覺自己不確定目前狀態時,先輸出一份 10 行內的現況摘要,再繼續工作。」
    – 「如需要,可要求人類提供『目前唯一真實狀態』說明,並用這份說明覆蓋舊假設。」

    3. 任務憲法:不靠「一長串 Prompt」,靠幾條簡潔原則

    多數人用代理會寫一大段 prompt,結果 Claude 讀不完、也記不住。CLAUDE.md 的思路是:

    • 用 10–20 條簡短規則,定義這個代理的「憲法」
    • 每條都要能對應到實際行為約束,例如:
    • 「若有工具可以做某事,優先用工具,不要手寫模擬輸出」
    • 「對同一錯誤連續嘗試 3 次仍失敗,就停下來請人類決策,不要無限迴圈」

    💡 關鍵: 把 10–20 條行為規則寫成固定「憲法」,比灌輸一大段單次 prompt 更能在長跑中維持穩定行為

    參考 Reddit 另一篇實戰文:https://www.reddit.com/r/ClaudeAI/comments/1thi6nh/100_tips_tricks_for_building_your_own_personal_ai/

    你可以做的事
    – 先列出你的代理最常「爛掉」的 3 個行為,逐條寫進 CLAUDE.md,用「禁止 / 應改為」的格式:
    – 「禁止:連續兩次貼出幾乎相同的錯誤訊息。應改為:第二次失敗時,整理你已試過的方法,請人類選下一步。」


    適合誰用:3 個實戰場景

    1. 單機腳本型代理:排程任務、批次資料處理

    你有這些需求時,很適合:

    • 每晚跑一次報表轉檔腳本
    • 每週整理一批 CSV / Excel 檔,把欄位標準化
    • 定期爬某個網站的資料、存到本地或資料庫

    做法:

    1. 用 Claude Code 或本地腳本,讓代理可以:
    2. 讀寫特定資料夾
    3. 執行 shell 指令(或以 PowerShell / bash 包一層)
    4. CLAUDE.md 放在專案根目錄,寫清楚:
    5. 允許改動哪些檔案
    6. 批次任務完成的判定方式(例如輸出檔案數量、檔名規則)
    7. 用排程工具觸發:
    8. macOS / Linux:cron 或 systemd timer
    9. Windows:排程工作排程器 + 命令列啟動代理腳本

    2. 長連線開發代理:Claude Code / VS Code / Cursor 類工作流

    如果你常用 Claude 來寫程式、改大型專案,長時間開著一個 session,很容易出現:

    • 忘記三小時前的設計決定
    • 重複修同一支檔案
    • 一直在講解架構,但實際 commit 很少

    這時 CLAUDE.md 非常好用:

    實際操作:

    1. 在 VS Code 專案根目錄新增 CLAUDE.md,內容包含:
    2. 專案簡述
    3. 允許的工具(例如:跑測試、執行 npm testpytest 等)
    4. 「行動 > 敘述」與「證據 > 猜測」等規則
    5. 在 Claude Code / Cursor 內重新開啟專案,確保代理會讀到這個檔案
    6. 開發時明確下指令:
    7. 「請遵守 CLAUDE.md,連續工作直到完成以下任務…」
    8. 「每完成一個子任務,產出最多 5 行的進度摘要」

    進階:也可以搭配多代理流程,參考:https://www.reddit.com/r/ClaudeAI/comments/1thi16y/how_i_built_a_9agent_team_where_my_agents/

    3. 自建小型自動化服務:抓報表、清理資料

    你想做一些「半自動」小工具,例如:

    • 每週自動登入內部系統下載報表
    • 讀取資料夾裡的新檔案,做資料清洗 / 格式標準化
    • 根據最新資料,產出簡短摘要寄 Email

    可用的整合方式:

    • MCP / shell 指令
    • 透過 Model Context Protocol 暴露一組工具給 Claude,例如:
      • list_files, read_file, run_command
    • 規則寫進 CLAUDE.md

      • 「處理檔案時,一律用工具列出檔名,不要從記憶猜」
    • Power Automate

    • 由 Power Automate 排程觸發 HTTP / CLI,呼叫你的 Claude 代理後端
    • 回傳的結果可再串 Outlook 寄信、寫入 Excel、更新 SharePoint

    你可以做的事
    – 先選一個最小自動化任務,例如「每週整理銷售報表」,只把這一個流程寫入 CLAUDE.md,確保跑穩,再慢慢加其他任務。


    10 分鐘上手:從 fork 到跑起你自己的代理

    以下是一條「10 分鐘內能動起來」的最短路徑,你可以依你使用的工具微調。

    Step 1:fork 開源專案

    1. 前往 Reddit 原文查看作者提供的 repo(通常會在貼文內):https://www.reddit.com/r/ClaudeAI/comments/1tjy3sk/i_opensourced_the_operating_file_that_keeps_my/
    2. 在 GitHub 上 fork 到自己的帳號
    3. 本地 git clone 下來

    Step 2:複製 CLAUDE.md 到你的專案

    1. 打開作者的 CLAUDE.md,通讀一遍規則
    2. 複製到你自己的專案根目錄
    3. 只做三種修改:
    4. 把專案描述改成你的任務(例如:財報整理、數據清洗、網站爬蟲)
    5. 調整允許使用的工具(例如是否允許 rm / 刪檔)
    6. 加上 2–3 條你最在意的「不准爛掉」條款

    💡 關鍵: 只動專案描述、工具白名單與 2–3 條關鍵禁令,能在 10 分鐘內把通用 CLAUDE.md 變成專屬代理憲法

    Step 3:綁定你常用的工作環境

    依你用的平台選一條:

    • Claude Code / VS Code / Cursor
    • 在這個專案資料夾內開啟編輯器
    • 確認工具(跑測試、shell、檔案操作)已啟用
    • 對 Claude 說:「請讀 CLAUDE.md 並照裡面的規則長時間工作」

    • MCP + shell 指令

    • 建立一個 MCP server,提供 run_shell, read_file, write_file 等工具
    • CLAUDE.md 明確寫出「所有系統操作一律經由 MCP 工具」
    • 用你偏好的前端(例如自寫 CLI、簡單 Web)呼叫 Claude

    • Power Automate / 其他自動化

    • 建一個小型後端服務(可用 Python FastAPI / Node.js)包住 Claude API
    • 後端每次呼叫 Claude 時,都把專案檔案+CLAUDE.md 帶入 context
    • 用 Power Automate 定期觸發這個 API

    Step 4:跑一個「能觀察的」任務,調整規則

    1. 選一個 30–60 分鐘的任務給代理連續跑(例如重構某一個資料夾的程式碼)
    2. 觀察:
    3. 什麼時候開始廢話變多?
    4. 哪種情況會卡在同一個錯誤?
    5. 直接把這些「失敗模式」寫回 CLAUDE.md 變成新條款

    重複兩三輪,你會得到一份專屬於你工作流、而且真的能「長跑不爛」的代理憲法。


    小結:先管好行為,再管工具

    長跑 AI 代理很容易越跑越爛,通常問題不在模型,而在缺乏清楚的行為規則。透過一份設計良好的 CLAUDE.md

    • 把輸出限制在「行動+證據」
    • 讓代理主動監控上下文壓力
    • 用幾條簡單原則當作「憲法」

    你可以在單機腳本、開發環境、多工具自動化裡,得到一個穩定得多的 Claude 代理。

    建議從今天開始:先為你最常用的一個專案寫一份 CLAUDE.md,跑一個完整任務,看看它能連續跑多久還保持專注。那會是你感受到「長跑代理真的可用」的第一步。

    🚀 你現在可以做的事

    • 在一個常用專案根目錄新建 CLAUDE.md,寫入「行動+證據」與上下文自查規則後實際跑一次長任務
    • 從 Reddit 原文 fork 作者 repo,閱讀並複製其中 CLAUDE.md,依你的工作流做 2–3 處客製調整
    • 列出你代理常見的 3 個「爛掉模式」,逐條轉寫成禁止條款加進 CLAUDE.md,並在下一次工作中觀察效果
  • 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.cppOllama 跑)
    • Runtime:Forge 當 guardrails
    • 工具層:一組 MCP server(例如 PostgreSQL、HTTP、Filesystem)

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

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

    適合誰用:三種典型場景

    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.cppOllama
    • 想雲端無痛: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 與時間成本差異