作者: kerwin77106

  • MiniMax M3:一口吃下百萬字長文的開源模型

    MiniMax M3:一口吃下百萬字長文的開源模型

    📌 本文重點

    • M3 支援 100 萬 token 長上下文與多模態輸入
    • 專門處理長文件、整個程式庫與 Agent 工作流
    • 可雲端快速試用,也能本地自架整合現有工具鏈
    • 先從一個最痛的長文或專案開始導入

    用一句話說:MiniMax M3 是一個開放權重、支援 100 萬 token 長上下文 + 多模態輸入 的模型,專門幫你處理「報告太長、程式碼庫太大、Agent 工作流太複雜」這三種麻煩事。

    💡 關鍵: 100 萬 token 長上下文代表可以一次塞進整份大型專案文件或程式庫索引,而不必自己切 chunk 或做向量搜尋。

    官方介紹與下載:https://www.minimax.io/models/text/m3(The Decoder 報導:https://the-decoder.com/minimax-m3-open-weight-model-with-a-million-token-context-challenges-proprietary-leaders/)


    核心功能:長文、程式碼、Agent 一次處理

    1. 100 萬 token 長上下文:整份專案文件一次丟進去

    能做什麼?

    • 一次放入:完整專案文件夾匯出的 Markdown、法規 PDF、產品說明書、研究報告
    • 不用切段:不必自己分 chunk、做向量搜尋,直接把「全部內容」交給模型
    • 查詢風格:像在問一位看完整專案的同事

    怎麼用(長文閱讀 Prompt 範本)

    1. 準備一個壓縮檔 / 合併文件,例如 project_docs.md(可用腳本把多個 Markdown / txt 串成一個檔案)。
    2. 在推理介面(API、Notebook 或 Web UI)中,把全文貼進 system / user 區。

    範例 Prompt 模板:

    你是一位技術專案經理。以下是整個專案的所有文件(需求、設計、會議紀錄、API 文件):
    
    --- 專案全文開始 ---
    {{整份文件內容}}
    --- 專案全文結束 ---
    
    請依照以下格式輸出:
    1. 專案一句話摘要(不超過 30 字)
    2. 3 個主要目標
    3. 5 個關鍵風險(附來源段落或章節名稱)
    4. 下一步行動建議(列出 5–10 條,可直接貼進 Jira 當任務)
    

    實際行動: 找一份你手上最頭痛、超長的專案文件,直接用上面模板測一次。


    2. 原生多模態:文字 + 圖像一起理解

    M3 支援把文字與圖片一起丟進上下文。例如:

    • 產品 PRD + UI 圖稿,一次請它找出規格與設計不一致之處
    • 報告 PDF 截圖 + 補充說明文字,一起整理重點

    圖片搭配 Prompt 範本:

    以下是某個產品的文字需求說明,以及對應的 UI 設計稿截圖(多張):
    
    文字需求:
    {{需求文字}}
    
    圖片:
    - image_1:登入頁
    - image_2:帳號設定頁
    - image_3:權限管理頁
    
    請列出:
    1. 每張圖和文字需求的對應關係
    2. 不符合需求或缺漏的地方
    3. 建議 UI 或流程調整(用條列)
    

    實際行動: 把一份 PRD + 幾張 Figma 匯出的 PNG 丟給 M3,看它幫你做「設計對規格」檢查。


    3. 為程式碼與 Agent 優化:整 repo 理解 + 多輪工具調用

    根據社群測試與官方說明,M3 在程式碼生成與 Agent 任務上做了特別優化:

    • 長上下文讓它能一次「看完整個 repo 的索引」
    • 可以在一個對話裡做多輪「工具調用→讀結果→改方案」

    💡 關鍵: 對整個 repo 建立「程式碼地圖」再交給 M3,可以讓它在第一次對話就掌握系統結構並規劃重構與 Agent 工作流。

    整個 repo 程式碼導覽 Prompt

    1. 先用腳本產生「程式碼地圖」,例如:
    # 只列出檔名 + 前幾行註解/類別宣告
    python scripts/make_repo_index.py > repo_index.txt
    
    1. 把 repo_index.txt + 關鍵檔案內容一起貼給 M3:
    你是一位資深軟體工程師。以下是某個專案的程式碼地圖與部分檔案內容。
    
    --- repo index ---
    {{repo_index.txt}}
    --- end repo index ---
    
    問題:
    1. 幫我畫出系統主要模組與資料流(用文字 + 簡單 ASCII 圖)
    2. 指出如果要「加入 OAuth 登入」,可能要改動的檔案與大致步驟
    3. 給出最小修改範圍的 refactor 計畫(列出任務清單)
    

    Agent 工作流拆解 Prompt

    把它當成「任務拆解器 + 工具 orchestrator」的腦:

    你是一個 AI Agent 系統的規劃師。你可以使用以下工具:
    - tool_search_issues:搜尋 Jira issue
    - tool_run_tests:執行 CI 測試
    - tool_open_pr:建立 Pull Request
    
    需求:
    「每天自動檢查新的 bug issue,找出影響登入流程的,跑測試,通過就開 PR。」
    
    請輸出:
    1. 將需求拆成 5–10 個可實作的 Agent 步驟
    2. 每個步驟會用到的工具(如有)
    3. 對 orchestrator 的假想 DSL / YAML 配置範例
    

    實際行動: 選一個你常做的重複開發流程,用上面模板請 M3 幫你轉成可實作的 Agent 腳本草稿。


    適合誰用:三種典型場景

    1. PM / 研究員:長報告與專案文件總結

    使用方式:

    • 把所有會議紀錄、需求文件、Excel 轉成文字(或貼 PDF OCR 結果),合併成一份長文
    • 用「長文閱讀模板」請 M3:
    • 整理專案脈絡與時間線
    • 整理「決策原因」與「未決事項」
    • 產出可以直接貼進 Notion / Confluence 的摘要

    行動建議: 對每個專案建立一份「M3 專案總結」,讓新成員用它快速上手。


    2. 後端 / 全端工程師:整 repo 理解與重構

    使用方式:

    • 新接手專案,先用腳本生成 repo index → 丟給 M3 產生系統說明
    • 要重構時,請它根據長上下文:
    • 找出高度耦合模組
    • 給出重構順序與風險點
    • 產生對應的 Git 分支與 PR 策略建議

    行動建議: 每次大改版前,用 M3 先產一份「重構設計」,再與團隊人工過一遍。


    3. 自動化 / AI Agent 開發者:多輪工具調用工作流

    使用方式:

    • 把你現有的工具清單(API spec、CLI 說明)全部貼給 M3
    • 要求它:
    • 定義任務拆解(如報表產出、自動回覆客服)
    • 設計工具調用順序與錯誤處理策略

    行動建議: 先挑一個「每天會做,但步驟固定」的流程,例如:生成日報、同步任務狀態,讓 M3 幫你設計第一版 Agent workflow。


    怎麼開始:雲端 / 本地快速跑起來

    1. 雲端:直接用官方 / 社群 API

    如果你只是想先試效果:

    1. 到官方頁面申請:https://www.minimax.io/models/text/m3
    2. 拿到 API key 後,在自己的腳本或 Postman 裡調用:
    curl https://api.minimax.io/v1/chat/completions \
      -H "Authorization: Bearer $MINIMAX_API_KEY" \
      -H "Content-Type: application/json" \
      -d '{
        "model": "m3",
        "messages": [
          {"role": "user", "content": "幫我總結以下專案文件..."}
        ]
      }'
    

    適合: 想驗證長上下文/多模態效果、不急著本地部署的團隊。


    2. 本地 / 自架:Hugging Face + 官方 Docker

    A. 用 Hugging Face + vLLM / Ollama(範例)

    1. 在 Hugging Face 搜尋 MiniMax/M3(實際名稱以官方為準)。
    2. 用 vLLM 啟動:
    pip install vllm
    vllm serve MiniMax/M3 --port 8000 --dtype bfloat16
    
    1. 測試:
    curl http://localhost:8000/v1/chat/completions \
      -H "Content-Type: application/json" \
      -d '{
        "model": "MiniMax/M3",
        "messages": [{"role": "user", "content": "你好,幫我總結這份文件"}]
      }'
    

    B. 用官方 Docker 快速跑起

    1. 下載官方映像(名稱以官方文件為準):
    docker pull minimax/m3:latest
    
    1. 啟動:
    docker run -d --gpus all -p 8000:8000 minimax/m3:latest
    
    1. 之後的使用方式就和一般 OpenAI 相容 API 類似。

    實際行動: 用 Docker 跑起來後,先跑一個「長文閱讀模板」,確認你的 GPU 記憶體足夠,觀察響應時間。

    💡 關鍵: 若你已採用 OpenAI 相容 API,將 base_url 換成 M3 服務即可快速 A/B 測試長上下文任務的效果。


    3. 跟現有工具鏈整合:VS Code、Orchestrator、CLI

    VS Code:當成本地 Copilot

    1. 安裝任一個支援自訂 LLM endpoint 的 VS Code 擴充套件(如 Code GPT、Continue)。
    2. 將模型 endpoint 設為你自架的 M3 伺服器 URL。
    3. 專案開啟後:
    4. 用「整 repo 導覽」prompt 請它解釋架構
    5. 在單檔內請它重寫函式、加註解

    與開源 orchestrator 整合

    你可以在以下框架中把 M3 當成主要「腦」:

    • LangChain / LlamaIndex:用它處理長上下文和工具調用規劃
    • CrewAI / OpenAI-compatible orchestrators:直接把 OPENAI_BASE_URL 指到你的 M3 伺服器

    簡單 YAML 範例(假想):

    llm:
      type: openai-compatible
      base_url: http://localhost:8000/v1
      model: MiniMax/M3
    
    agent:
      tools:
        - search_issues
        - run_tests
      max_iterations: 10
    

    實際行動: 在你現有的 Agent 專案,把原本的 gpt-4 或其他模型,先在「規劃/總結」節點換成 M3,測試對長上下文任務的改善。


    小結:先從一個最痛的長文或程式庫開始

    不用一次把所有流程都搬到 M3。挑一個:

    • 最長、最難讀的一份文件
    • 或你最不熟的一個 codebase

    用上面給的三組模板(長文閱讀、程式碼導覽、Agent 任務拆解)跑一次,你就能感受到「百萬 token 長上下文 + 開放權重」在實際工作中的差別。

    🚀 你現在可以做的事

    • 挑選一份最頭痛的長報告或專案文件,套用「長文閱讀模板」實測 M3
    • 對一個新接手的 repo 生成 repo_index.txt,用「整個 repo 導覽 Prompt」請 M3 說明架構
    • 在現有 Agent 專案中,把規劃/總結節點的模型改成 M3,觀察長上下文任務表現差異
  • Anthropic 上市:安全招牌與資本邏輯的正面衝突

    Anthropic 上市:安全招牌與資本邏輯的正面衝突

    📌 本文重點

    • Anthropic IPO 將「安全敘事」拉進華爾街季度壓力測試
    • 資本市場會把算力軍備、封閉生態與客戶鎖定推向極致
    • 「AI 安全」恐被重寫成成本項與行銷話術,而非實質約束

    Anthropic 準備 IPO,真正被拋進市場壓力測試的,不是估值,而是它「安全派 AI」的品牌承諾。 一旦從實驗室走進 華爾街季度財報劇本,對齊、安全與風險管控就不再是道德姿態,而是會被寫進或抹除在 KPI 裡的成本項。這不是一家公司的財經新聞,而是:我們是否準備好,讓基礎模型的社會風險,交給短期回報驅動的資本市場來決定?


    一、從「好人角色」到「成長股」:Anthropic 的結構性矛盾

    Anthropic 一開始賣的是「安全敘事」:Constitutional AI、alignment-first、比 OpenAI 更在乎風險。 這套敘事在私募階段非常有效——吸引了願意為「較負責任的 AGI 開發者」買單的資本與企業客戶。但 IPO 之後,遊戲規則會變兩件事:

    1. 股東結構從「可以接受長期賭注的機構與巨頭」,變成「需要流動性與季度故事的大眾股東」。
    2. 公司目標不可避免地要往「估值故事」傾斜。 Reddit 上已在流傳 「Anthropic 要在 2027 年衝向 10 兆美元公司」 的說法,這種敘事本身就與「謹慎放量、審慎釋出能力」是相衝突的。

    💡 關鍵: 將「2027 年衝向 10 兆美元公司」當目標,代表成長與估值敘事可能會壓過「放慢、審查、延後釋出」的安全承諾。

    問題在於:

    • AI 安全需要的是「放慢、審查、延後釋出」,甚至在模型太強時,選擇不商業化。
    • 上市公司被期待的是「加速釋出、壓低邊際成本、快速搶市占」,否則就會被分析師貼上「成長趨緩」標籤。

    當 Anthropic 需要同時向 SEC、風險投資人、企業客戶與 AI 安全社群交代 時,它勢必得選擇其中某一方先被犧牲。歷史經驗(從社群平台到廣告科技)一再顯示:在季度財報面前,被犧牲的幾乎從來不是成長曲線,而是抽象的社會風險。


    二、雙寡頭衝向資本市場:算力軍備與產業鎖死

    Anthropic 與 OpenAI 幾乎同步奔向 IPO,實質上是在把「算力軍備競賽」寫進招股書。 一旦上市,它們的下一個 KPI 不會是「能否安全停車」,而是:

    • 訓練成本與算力支出成為可歌可泣的投資故事:
    • 「我們今年在 GPU 上燒掉了 X 十億美元,比對手多 30%,因此技術領先。」
    • 投資人會獎勵這種敘事,因為它暗示了未來壟斷地位。

    • 對產業結構的兩個直接後果:

    • 雲端+基模雙頭壟斷:
      • Anthropic 綁 Amazon、Google;OpenAI 緊靠微軟 Azure,IPO 之後,這些戰略關係只會更緊密。
      • 對大型企業客戶來說,「用 AI」將越來越等於「鎖進兩大雲+兩大基模」,轉移成本被刻意放大。
    • 開源與中小模型商被擠壓:
      • 當華爾街預期的是「AGI 型全能模型吃下所有任務」,管理層就有誘因 把產品路線朝「一體化超大模型 + 封閉 API」推,而不是維持多樣、可組裝的模型生態。
      • 中小模型商與開源專案,能活下來的空間會越來越「邊緣化」,只能在極少數垂直場景苟存。

    💡 關鍵: 算力軍備一旦被包裝成「比對手多燒 30% GPU」的投資亮點,將強化雙頭壟斷與封閉生態,進一步抬高產業轉移與創新成本。

    表面看起來,IPO 帶來的是資金與創新加速;本質上卻可能是把基礎模型產業,推向「算力比燒 + 封閉生態 + 客戶鎖定」的終局布局。


    三、定價、產品與開放度:安全會不會被寫進「折舊費用」?

    IPO 之後,Anthropic 不可避免地要把營收成長率、毛利率寫進路演簡報。在這個框架下,「安全」與「對社會負責」會被重寫成幾個具體的 trade-off:

    1. 安全機制 vs. 商業轉換率
    2. 嚴格的安全防線意味著:更多 red-teaming、更多拒絕回應、更多延遲釋出。這些在財務模型裡是「成本+少賺到的錢」。
    3. 當管理層面對的是「本季營收成長只有 18%,低於市場預期 25%」時,最先被砍的通常是難以量化的風險檢測與研究預算,而不是 marketing spend。

    4. 免費層與研究開放度,會被視為「可壓縮空間」

    5. 免費層是拉新工具,但也是伺服器成本;上市公司 CFO 的直覺,是 收緊免費額度、提高門檻、把更多流量轉成付費。
    6. 對研究社群與獨立開發者來說,這會直接把他們推向:

      • 更昂貴的 API(OpenAI/Anthropic 雙寡頭),或
      • 更便宜但政治與資料主權風險較高的中國模型(如 DeepSeek、Qwen),抑或
      • 品質稍低但可控的開源模型(Llama、Mistral 等)。
    7. 全球 AI 使用成本被推高,風險外溢到其他體系
      Reddit 上已有討論:當 OpenAI、Anthropic 一起 IPO、一起漲價,很多預算吃緊、對合規沒那麼敏感的企業部門,很可能直接買「最便宜、夠用就好」的方案——不論供應商在中國還是其他國家。

    結構性結果是:

    • 華爾街對兩家美國 AI 巨頭的定價壓力,可能反而刺激了中國模型與開源方案在全球企業端的採用。
    • 我們不是降低了風險,而是把風險分散到更多監管難以觸及的角落,讓整體治理難度上升。

    💡 關鍵: 當頭部模型商為了毛利率同步漲價,全球 AI 使用成本上升,反而可能把需求推向監管較弱與風險更難控的模型體系。

    換句話說,資本市場要求的毛利率,可能會以「全球 AI 使用門票變貴」為代價實現,而且未必帶來更安全的使用環境。


    四、治理與監管:當 SEC 跟社會風險吵架時,Anthropic 會站哪邊?

    Anthropic 長期把自己定位為「重視 AI 對社會風險的公司」。問題在於,一旦上市,它需要面對的是:

    • SEC 與證交所:關心的是資訊揭露是否充分、財報是否真實、是否有誤導投資人。
    • 監管機關與公眾:關心的是 AI 是否增加失業、強化不平等、擴散錯誤資訊、產生國安風險。

    這兩者之間,並沒有自然對齊:

    • 如果某次內部 red-team 發現新模型在生物武器、網攻能力上有重大風險,延後發布符合社會利益,但可能讓季度營收 miss target;
    • 如果公司選擇「照計畫發布」,只是補幾句風險揭露文字,SEC 會滿意,股東短期也開心,但社會風險被外包給整個世界。

    Anthropic 早期設計過特殊治理結構,試圖避免「OpenAI 董事會風波 2.0」,但在接上公開資本市場後,任何超出一般股東權利結構的安排,最後都會面臨壓力:

    • 只要治理機制作出顯著壓制股價或成長的決策,就會被貼上「對股東不負責」,甚至遭遇法律挑戰。

    如果我們不及早介入設計新的治理框架,Anthropic 的「安全招牌」最終只會淪為 IPO 路演的差異化話術,而不是能在關鍵時刻踩煞車的機制。


    結論:開發者與使用者不能再當吃瓜群眾

    Anthropic 上市,真正被測試的是我們整個社會是否願意、也是否有能力,對基礎模型產業設計「超越股價」的約束框架。 如果沒有:

    • AI 對齊與安全將被默默轉寫成「行銷差異化」,而不是產品節奏與能力釋出的實質約束。
    • 人類集體風險,會被打包進成長股 ETF 裡,被視為「可承受的系統性風險」。

    對開發者與企業使用者,我的具體建議是:

    1. 技術選型時,把「治理與可轉移性」當成硬指標:
    2. 不要只看模型能力與單價,還要問:換供應商的成本多高?是否支援開源 fallback?資料與權限是否能抽離?
    3. 刻意維持「多供應商 + 一定比例開源」結構:
    4. 即便 Anthropic / OpenAI 當下最好用,也不要讓自己完全鎖進單一閉源體系。
    5. 在產業協會、開發者社群中,壓力政策制定者:
    6. 要求針對基礎模型公司推出新的治理機制,例如:
      • 強制公開安全審查流程與重大風險披露;
      • 在治理架構中納入「公共利益董事」;
      • 對超大規模訓練與釋出設定「預先通報與冷卻期」。

    如果我們現在不動手,未來五年內,AI 產業的基本秩序將由幾份招股書和幾次財報電話會議決定,而不是由公共辯論與民主治理決定。Anthropic IPO 是一個轉折點——錯過這一次,我們很可能錯失對基礎模型產業最後的實質約束機會。

    🚀 你現在可以做的事

    • 檢查你或公司現有 AI 技術堆疊,評估是否有「多供應商+一定比例開源」的備援結構
    • 在選型文件或 RFP 中,新增「治理與可轉移性」相關條款,例如資料可抽離、支援開源 fallback
    • 參與所在產業協會或開發者社群,推動對基礎模型公司的安全揭露與治理機制討論與倡議
  • autoswarm 自我優化本地 Agent 實戰

    autoswarm 自我優化本地 Agent 實戰

    📌 本文重點

    • 本地 Agent 痛點在於行為難以持續優化與自動化
    • autoswarm 透過 reflect → rewrite → evaluate → write-back 形成閉環
    • skills.yaml + 驗證集讓 Agent 行為像「可訓練參數」持續調整
    • 先從可量化任務(coding/CLI/FAQ)導入 autoswarm 成效最佳

    本地 Agent 最大的痛點不是「模型不夠強」,而是行為難以持續調整:你改了一堆 prompt、skills,效果好壞全憑體感,難以複製、更難自動化。autoswarm 類的自我優化流程,把這件事工程化:讓 Agent 自己從對話紀錄學習、反思、改寫技能檔,並用驗證集嚴格篩選只留下「真有幫助」的改動。

    💡 關鍵: autoswarm 把「調 prompt 靠手感」變成「技能檔可度量、可回滾的工程流程」。

    換句話說,你不再手動調 prompt,而是給 Agent 一套 reflect → rewrite → evaluate → write-back 的閉環,讓本地 coding 助手、CLI 助手、企業 FAQ agent 在你睡覺時自己變強。


    重點說明

    1. autoswarm 關鍵架構:從對話到技能檔

    典型 autoswarm 流程可以拆成四個模組,每個都可以獨立嵌進現有系統:

    1. 對話記錄收集(logs)
    2. 來源:真實使用對話、benchmark(如 TerminalBench)、內部工單。
    3. 形式:(task, context, agent_action, outcome),最好能標註 success/fail 或 score。

    4. 反思(reflect)

    5. 用一個「較強或同級」的 LLM 對失敗例子做事後檢討。
    6. 產出:錯誤原因、改進方向、需要修改的 skill 名稱/段落。

    7. 技能候選改寫(rewrite)

    8. 以 skills.yaml 內容為條件,請 LLM 產生有界改動:新增/刪除/替換特定節點,而不是整檔轟掉重寫。
    9. 借鏡 SkillOpt:每個改動要有 diff 形式 與 rationale,方便審核與回滾。

    10. 驗證集評估 + 寫回(evaluate & write-back)

    11. 對每個候選 skills 版本,跑一輪驗證集,計算 明確的 success metric(accuracy、任務完成率、延遲等)。
    12. 只有 嚴格提升 才寫回主線 skills.yaml,其餘丟棄;可選擇保留失敗改動作為「負樣本」提示未來避免。

    💡 關鍵: 整體流程等同「技能檔梯度下降」,用驗證集決定每次改寫是否保留。

    整體就是一個離線/準線上的 技能檔梯度下降:技能檔被當成可訓練參數,用反覆試錯 + 驗證集擇優更新。


    2. skills.yaml schema 與 success metric 設計

    要讓 autoswarm 好養,技能檔要易於定位、易於局部修改。一個實用的 YAML schema 可以長這樣:

    version: 3
    meta:
      agent_name: local_cli_helper
      description: "CLI + coding local agent"
    
    skills:
      - id: shell_exec
        type: tool
        trigger: ["terminal", "bash", "cli"]
        prompt: |
          你是一個嚴謹的 CLI 助手。只執行使用者要求的指令:
          - 先用自然語言解釋你要做什麼
          - 再給出具體指令
          - 不要執行具有破壞性的指令(rm -rf 等)
        guardrails:
          forbidden_patterns:
            - "rm -rf /"
            - ":(){ :|:& };:"
    
      - id: code_edit
        type: coding
        languages: ["python", "bash"]
        prompt: |
          你是一個本地 code 編輯助手:
          - 優先最小改動
          - 保留原有註解
          - 回傳可直接貼上的 patch
    
      - id: faq_lookup
        type: retrieval
        index: "internal_faq.jsonl"
        prompt: |
          你是企業 FAQ 助理,回答時:
          - 引用文件來源 id
          - 若找不到答案,要明確說明而不是亂猜
    

    幾個關鍵點:

    • id 必須穩定:autoswarm 透過 id 來定位要改哪個 skill。
    • 把行為拆成多個 skill,而不是一個 mega prompt,讓 autoswarm 有「局部調參」的空間。
    • 為每個 skill 準備可計算的 success metric,例如:
    • coding:測試通過數 / 單元測試覆蓋率提升。
    • CLI:命令 exit code == 0 且輸出包含 expected pattern。
    • FAQ:答案包含 ground truth 片段、或人工標註 score。

    💡 關鍵: 每個 skill 綁一個可量化 metric,才能自動決定「這次改寫有沒有真的變好」。


    3. 驗證集與回放:怎麼自動化

    關鍵是把「我覺得好」變成可計算的 pass/fail:

    • 來源:
    • 基準測試(TerminalBench、內部腳本集)。
    • 真的使用者對話 + 事後標註(成功:1、失敗:0)。
    • 半自動生成:用模型自己產 task,再請另一模型打分。

    • 回放機制:

    • 對每個驗證樣本 (input, expected),在新 skills.yaml 下跑一次 Agent,產生 output。
    • 用簡單的 scorer 函數 計算分數,例如:
      • coding:跑 pytest,看全部通過比例。
      • CLI:比對 stdout 是否包含關鍵字,exit code 是否為 0。
      • FAQ:用一個 judge LLM(或傳統 NLP 指標)評估是否回答到點。

    這層其實就是一個小型 harness:把「模型+skills」包成可測試的函式,對照 Deepseek 提出的觀點,就是那層讓 LLM 變成 Agent 的 runtime code。


    4. 如何嵌進現有本地 Agent(MCP/子代理/skills-based)

    不需要重寫整個 Agent,只要插入兩個 hook:

    1. log hook:在 MCP server、子代理 router 或 skills selector 前後,記錄輸入、選到的 skill、輸出、評分。
    2. offline autoswarm worker:定期(例如每天)跑反思-重寫-評估 loop,更新一個新的 skills_version,下次重啟 agent 或熱更新時載入。

    常見集成方式:

    • MCP:把 skills.yaml 當作 MCP tool 的配置,autoswarm 只負責改 YAML,MCP server 本身不改。
    • 多代理框架(如 revfactory/harness):autoswarm 對每個 agent 的 skill 檔做優化,讓「meta-agent」負責決定何時切版本。
    • 傳統 skills-based 系統:把原本寫死在程式碼裡的 prompt 抽到 YAML,才能用 autoswarm 自動調參。

    實作範例:最小可行 autoswarm(Python + YAML + Ollama)

    下面是一個極簡版的 autoswarm:針對單一 skill(faq_lookup),用對話紀錄做反思、改寫 YAML,然後用驗證集評估是否接受改動。

    1. 專案結構

    project/
      skills.yaml
      logs.jsonl         # 真實對話紀錄
      val_set.jsonl      # 驗證集
      autoswarm.py
    

    skills.yaml 示意(只保留 FAQ skill):

    skills:
      - id: faq_lookup
        type: retrieval
        prompt: |
          你是 FAQ 助理,只能根據提供的文件回答。
          若找不到答案,就回答「找不到」。
    

    2. Python:反思 → 重寫 → 評估 loop

    # autoswarm.py
    import json, copy, subprocess, textwrap
    from pathlib import Path
    import yaml
    
    SKILLS_PATH = Path("skills.yaml")
    VAL_PATH = Path("val_set.jsonl")
    LOGS_PATH = Path("logs.jsonl")
    
    # --- 基礎調用 Ollama ---
    
    def call_ollama(prompt: str, model="llama3.1") -> str:
        res = subprocess.run(
            ["ollama", "run", model],
            input=prompt.encode("utf-8"),
            stdout=subprocess.PIPE,
            check=True,
        )
        return res.stdout.decode("utf-8").strip()
    
    # --- Step 1: 從失敗 log 產生改進建議 ---
    
    def load_failed_examples(limit=5):
        examples = []
        with LOGS_PATH.open() as f:
            for line in f:
                obj = json.loads(line)
                if obj.get("success") is False:
                    examples.append(obj)
                if len(examples) >= limit:
                    break
        return examples
    
    
    def reflect_on_failures(examples):
        prompt = """你是資深 prompt engineer。以下是 FAQ agent 的失敗案例:
    
    {cases}
    
    目前 FAQ skill 的行為描述較弱,請提出如何修改 skill prompt 才能避免這些錯誤。
    
    輸出格式:
    - mistakes: 一段文字說明主要錯誤
    - patch: 改寫後的完整 prompt 內容(繁體中文)
    """
        cases_txt = "\n\n".join(
            [
                f"[CASE]\nquestion: {c['input']}\nwrong_answer: {c['output']}\nexpected: {c['expected']}"
                for c in examples
            ]
        )
        resp = call_ollama(prompt.format(cases=cases_txt))
        return resp
    
    # --- Step 2: 產生候選 skills 版本 ---
    
    def generate_candidate_skills():
        skills = yaml.safe_load(SKILLS_PATH.read_text())
        base_skills = copy.deepcopy(skills)
    
        failed = load_failed_examples()
        if not failed:
            print("no failed examples; skip")
            return None
    
        reflection = reflect_on_failures(failed)
    
        # 簡化處理:從 LLM 回應中用標記擷取 patch 區塊
        if "patch:" in reflection:
            patch = reflection.split("patch:", 1)[1].strip()
        else:
            patch = reflection
    
        # 套用到 faq_lookup
        for s in base_skills["skills"]:
            if s["id"] == "faq_lookup":
                s["prompt"] = patch
    
        return base_skills
    
    # --- Step 3: 評估一個 skills 版本 ---
    
    def run_agent(question: str, skills_obj) -> str:
        faq_skill = next(s for s in skills_obj["skills"] if s["id"] == "faq_lookup")
        sys_prompt = faq_skill["prompt"]
        full_prompt = textwrap.dedent(f"""
        系統指令:
        {sys_prompt}
    
        使用者問題:{question}
        請直接回答。
        """)
        return call_ollama(full_prompt)
    
    
    def score_skills(skills_obj) -> float:
        total, ok = 0, 0
        with VAL_PATH.open() as f:
            for line in f:
                obj = json.loads(line)
                question = obj["input"]
                expected = obj["expected"]
                out = run_agent(question, skills_obj)
                total += 1
                if expected.strip() in out:
                    ok += 1
        return ok / total if total else 0.0
    
    # --- 主流程 ---
    
    def main():
        current_skills = yaml.safe_load(SKILLS_PATH.read_text())
        base_score = score_skills(current_skills)
        print("base_score:", base_score)
    
        cand = generate_candidate_skills()
        if cand is None:
            return
    
        cand_score = score_skills(cand)
        print("candidate_score:", cand_score)
    
        if cand_score > base_score:
            backup = SKILLS_PATH.with_suffix(".bak.yaml")
            backup.write_text(SKILLS_PATH.read_text())
            SKILLS_PATH.write_text(yaml.dump(cand, allow_unicode=True))
            print("updated skills.yaml (backup saved)")
        else:
            print("candidate rejected; no improvement")
    
    
    if __name__ == "__main__":
        main()
    

    這個最小範例已經包含核心閉環:

    • 反思:reflect_on_failures 用 LLM 分析失敗案例。
    • 重寫:generate_candidate_skills 產出新的 FAQ skill prompt。
    • 評估:score_skills 在驗證集上打分。
    • 寫回 + 回滾:只有 score 提升才覆蓋 skills.yaml,並保留 .bak 方便回滾。

    你可以把 run_agent 換成實際的 MCP 調用、子代理 router,整套邏輯依然成立。


    建議與注意事項

    1. 避免過度擬合驗證集

    問題:skills 慢慢只會在 val_set 上變強,實戰反而變差。

    建議:

    • 拆 train / val / live 三層:
    • train:用來產生候選改動。
    • val:只決定是否接受改動。
    • live:真實流量,週期性抽樣評估是否「線上變好」。
    • 定期替換驗證集樣本,避免被「背題」。

    2. 技能檔膨脹與行為漂移

    問題:LLM 每輪都喜歡加條款、加例外,skills.yaml 越寫越厚,最後誰也看不懂。

    建議:

    • 為 autoswarm 的 rewrite prompt 加上硬性約束:字數上限、禁止新增無根據規則。
    • 定期跑「壓縮輪」:請模型把冗長 skill 壓縮成短版,再用同一驗證集確認不降分。
    • 每個 skill 保持一個簡短的 design doc(目的、scope、anti-goals),避免 autoswarm 把 skill「學壞」。

    3. 無標準答案任務的侷限

    在開放式對話、創作任務上,很難定義客觀 success metric。

    可以考慮:

    • 使用一個獨立 judge 模型,給 1–5 分,才算作 metric。
    • 只對「明確可評」技能開 autoswarm(如 coding、CLI、FAQ),聊天維持手動設計。
    • 針對負面行為(安全、合規)單獨設計 守門驗證集,只要出現就直接拒絕 candidate。

    4. 版本控制與回滾策略

    • 版本號:在 skills.yaml 加 version 欄位,每次 autoswarm 成功更新 +1。
    • Git 管理:把 skills 連同 autoswarm logs 一起 commit,方便 bisect。
    • 多版本 AB 測試:對企業內部 Agent,可同時跑兩個 skills 版本,對比使用者滿意度或工單解決率。

    實際好處總結:

    • 對本地 coding 助手:用單元測試當驗證集,讓 Agent 自動學會你的專案風格與工具鏈。
    • 對 CLI 助手:從錯誤指令和 crash log 中反覆學習,逐步降低「爆炸指令」風險。
    • 對企業 FAQ/ops agent:用真實工單與 FAQ 命中率做閉環,減少大家輪流調 prompt 的人工成本。

    核心心態是:把 skills.yaml 當成模型參數來訓練,而不是只在 README 裡手動修改的一段文案。有了 autoswarm loop,你的本地 Agent 就能在既有硬體上持續「自我優化」,而不是每天重訓一個新模型。

    🚀 你現在可以做的事

    • 把現有 Agent 的系統 prompt 抽成 skills.yaml,為每個 skill 補上穩定 id 與對應 metric
    • 寫一個最小版 autoswarm.py,先針對單一 skill(例如 faq_lookup)跑 reflect → rewrite → evaluate loop
    • 準備一小批驗證集(10–20 筆即可起步),接上 CI 或排程,讓 skills 每天自動小幅優化
  • 自託管 Airi:把 AI 養在自己電腦裡

    自託管 Airi:把 AI 養在自己電腦裡

    📌 本文重點

    • Airi 可完全自託管,長駐你自己的機器
    • 支援即時語音與遊戲互動,像住在電腦裡的同伴
    • 可接本地 LLM 或雲端 API,自訂人格與長期記憶

    Airi 解決的是:想要一個「常駐在自己電腦裡」、能語音聊天、陪你打遊戲,又不把隱私丟給雲端的大型 AI 代理人。

    Airi GitHub:https://github.com/moeru-ai/airi


    核心功能:把 Airi「養」在自己機器上

    1. 自託管架構:本地 / 伺服器都能養

    Airi 是完全自託管的專案,你可以:

    • 裝在自己電腦:當成桌面語音助理、遊戲副駕駛
    • 架在家裡 NAS / 伺服器:多台裝置共用同一個 Airi
    • 放到雲端 VPS:人不在家也能連回自己的 AI

    實際能做的事:

    • 重要對話、長期記憶都留在你控制的機器
    • 想換模型、換人格、換語音,都自己改,不受商業服務限制

    你可以現在先做:

    1. 開啟 GitHub 專案頁:https://github.com/moeru-ai/airi
    2. 在 README 看「Installation」區段,決定你要:
    3. docker-compose 一鍵跑,或
    4. 用腳本 / 原始碼自己起服務

    2. 即時語音通話:真的像「住在你電腦裡的人」

    Airi 內建語音通話功能,可以做到:

    • 按一個按鈕就跟 Airi 說話,低延遲雙向語音
    • 語音輸入 + 語音輸出,像在跟 Discord 語音室裡的人聊天
    • 長時間掛在背景,隨時叫一下就回應你

    這比一般聊天機器人多了兩件事:

    • 不用切視窗打字,邊寫程式邊講話就能查資料、記 To-do
    • 遊戲全螢幕時仍可用語音讓 Airi 幫你查攻略、算資源

    你可以先準備:

    • 一個麥克風(筆電內建也可)
    • 耳機(避免回授回音)

    安裝好後,在 Airi 的 Web 或桌面客戶端裡,找到 Voice / Call / Talk 類選項,試著說一句:

    「幫我記一下,10 點要去打王。」

    確認 Airi 能聽懂、重複你剛說的提醒,就代表語音通路打通了。

    💡 關鍵: 長時間低延遲語音掛機,讓 Airi 更像常駐同事,而不是臨時叫用的聊天機器人。


    3. 跟遊戲雙向互動:Minecraft、Factorio 副駕駛

    Airi 的另一個重點,是能直接連到遊戲伺服器,讀取資訊、發送指令,目前官方強調支援:

    • Minecraft:
    • 讀取聊天、座標、玩家狀態
    • 讓 Airi 發聊天訊息、執行伺服器指令
    • 能當「伺服器管理員」、「新手顧問」或「劇情 NPC」
    • Factorio:
    • 掃描工廠狀態、產線 bottleneck
    • 建議你要擴產哪條線、缺哪種物資

    實際玩法舉例:

    • Minecraft 裡打 /askairi 我怎麼做一個自動農場?
    • Airi 在遊戲聊天裡回你步驟,同時用語音對你講解

    你可以安排一個晚上做這件事:

    1. 準備一個 Minecraft 伺服器(本地或雲端都可)
    2. 依 Airi README 中的 Minecraft / Factorio 插件說明:
    3. 在伺服器裝上 Airi 提供的插件 / 模組
    4. 在 Airi 設定檔填入伺服器位址與 API 金鑰
    5. 重新啟動伺服器並進入遊戲,測試呼叫 Airi

    4. 多平台客戶端 + 多種 LLM 後端

    Airi 支援:

    • Web 介面:瀏覽器直接用,管理設定、對話、記憶
    • macOS / Windows 客戶端:
    • 固定在桌面右下角、選單列
    • 快捷鍵喚出,直接講話或輸入文字

    LLM 後端則非常彈性:

    • 本地開源模型(透過 Ollama、LM Studio 等)
    • 雲端 API:OpenAI、Anthropic、Qwen、Gemini…(依 README 支援)

    對於想要「免費 / 低成本玩起來」的讀者,建議:

    • 若有 16GB RAM 以上 + 顯示卡:考慮用 Qwen 3.x 7B / 14B 這種偏擅長 Agent 任務的模型
    • 若硬體較弱:先用 雲端 API 的小模型(如 gpt-4o-mini 類),避開本地推論壓力

    💡 關鍵: 有 16GB RAM 加獨顯時,本地模型就能順跑,真正做到零額外流量費與隱私全在自己機器。

    你現在可以做:

    • 選擇你要的模型來源,準備好:
    • 本地:先安裝 Ollama,拉一個模型 ollama pull qwen2.5:latest
    • 雲端:到 OpenAI / Anthropic 後台申請 API Key
    • 在 Airi 設定檔裡填入:模型名稱、API Key、base URL

    適合誰用:幾個具體場景

    1. 桌面語音助理:在你電腦旁邊工作的「同事」

    可以這樣用:

    • 開會前對 Airi 說:「幫我整理這份 PDF 的重點。」
    • 寫程式時問:「這段 TypeScript 為什麼報錯?」
    • 長時間聊天:讓 Airi 記住你正在進行的專案、偏好工具

    搭配其他工具:

    • 結合 Claude Code / Cursor / codegraph 之類開發環境,把「寫程式」交給 IDE,把「討論設計、備忘錄」交給 Airi

    行動建議: 安裝好後先定義一個簡單工作流,例如:

    每天早上請 Airi 根據行事曆排三件最重要的事,晚上讓它跟你一起檢討完成度。


    2. 遊戲副駕駛:策略腦 + 資源小管家

    在 Minecraft / Factorio / 其他支援的遊戲裡:

    • 讓 Airi 記住你的長期目標(例:一週內完成終界龍擊殺 / 火車自動物流)
    • 每次登入時請它提醒:現在缺什麼資源、下一步該做什麼
    • 遊戲裡臨時問:「我現在要去哪裡刷 X 資源效率最高?」

    高級玩法:

    • 讓 Airi 按固定節奏掃描伺服器狀態,自己發現問題
    • 例如:箱子爆滿、產線堵塞,就自動在聊天頻道喊你

    行動建議: 設計一個明確角色給 Airi,例如:

    「你是我們伺服器的資源總管,只關心是否缺料,缺了就通知我並給出最短補貨路線。」

    把這段人格設定寫進 Airi 的系統提示 / persona 設定中。


    3. 長陪伴聊天夥伴 + 跨工具 Agent

    如果你想要一個可以長期記住你喜好、過去對話的 AI:

    • 利用 Airi 的記憶系統,讓它記:
    • 你常玩的遊戲
    • 你的工作類型、平常的困擾
    • 你的目標(練英文、學某個框架…)
    • 長期和它聊,讓它慢慢形成「認識你」的狀態

    再往上,可以接其他 Agent 平台:

    • 例如:
    • Airi 作為前端「主對話窗口」
    • 後面串 zero.xyz 去調用 ~8000 個工具、API
    • 串 Phasr 類工作流引擎,讓它一次跑多個任務而不丟上下文

    行動建議: 想一個你真的會常用的主題,例如「學習 Rust」,把它寫成 Airi 的長期任務:

    「你的任務是陪我在三個月內學會 Rust,定期出作業、review、提醒我寫 code。」

    💡 關鍵: 把長期學習或遊戲目標寫成任務與記憶,Airi 才能持續主動「記得你」而不是每次重來。


    怎麼開始:一個晚上就能跑起自己的 Airi

    1. 推薦最低硬體配置

    • CPU:四核心以上
    • RAM:16GB 起跳(跑本地 LLM 比較穩;如果只用雲端 API,8GB 也可)
    • 儲存:至少預留 20GB(模型 + 日誌 + 記憶)
    • 顯示卡:有獨顯最好(跑本地模型會輕鬆很多),沒有也能用雲端 API

    2. 用 Docker 一鍵跑起來

    以常見流程簡化示意(實際請以官方 README 為準):

    # 1. 先裝好 Docker & Docker Compose
    # 2. 在你想放 Airi 的資料夾裡:
    
    git clone https://github.com/moeru-ai/airi.git
    cd airi
    
    # 3. 啟動服務
    docker compose up -d
    

    接著:

    1. 瀏覽器開 http://localhost:PORT(PORT 依 README 為準)
    2. 看到 Airi 的 Web 介面後,先建立一個帳號 / 角色
    3. 在設定頁:
    4. 選擇 LLM 後端(本地或雲端)
    5. 設好語音輸入輸出

    如果你不熟 Docker,專案通常也會提供一鍵腳本(如 run.sh / start.ps1 類),照 README 指示執行即可。


    3. 配一個免費 / 便宜的模型

    兩條路線擇一:

    路線 A:本地開源模型(零額外成本,壓力在硬體)

    1. 安裝 Ollama:https://ollama.com
    2. 下載一個中小型模型,例如:

    bash
    ollama pull qwen2.5

    1. 在 Airi 設定裡把 LLM URL 指向 http://localhost:11434,模型名稱填 qwen2.5

    路線 B:雲端 API(硬體負擔低,按量計費)

    1. 到你喜歡的 LLM 服務註冊帳號(如 OpenAI)
    2. 建立 API Key
    3. 在 Airi 介面填入:
    4. API Key
    5. 模型名稱(例如 gpt-4o-mini)

    測試是否成功: 在 Airi 裡輸入一句:「幫我用條列整理一下 Airi 是什麼?」看能否正常回覆。


    4. 進階玩法:Minecraft 綁語音 + 自訂人格與長期記憶

    (1) Minecraft + 語音副駕駛

    大致步驟(細節以 Airi README 中的 Minecraft 節為準):

    1. 在你的 Minecraft 伺服器安裝 Airi 專用插件 / Mod
    2. 在 Airi 後台新增一個「Minecraft 連線」,填入:
    3. 伺服器位址
    4. 驗證金鑰
    5. 設定一個提示模板,例如:

    你是這個伺服器的導遊,會用中文在遊戲聊天和語音裡同時回應玩家問題。

    測試:在遊戲裡打 /airi 這附近有什麼資源?,看聊天與語音是否同步回應。

    (2) 自訂人格 + 長期記憶

    在 Airi 的 persona 或 system prompt 區裡,可以寫:

    • 身份:

      你是住在我電腦裡的 AI 室友,平常會關心我的工作進度和遊戲計畫。

    • 口吻:

      輕鬆、直接,避免太官方的說話方式。

    • 記憶策略:

      遇到我的偏好、長期目標、常見問題時,請寫入長期記憶,下次主動提起。

    接著在 Web 介面裡,偶爾去「記憶 / memories」頁面檢查:

    • 刪掉已過時的資訊
    • 補充重要但沒被好好記錄的背景

    這樣 Airi 就會越來越像一個真的「老朋友」,而不是每次都從零開始的聊天機器人。


    最後,建議你空出一個完整晚上,按這個節奏走:

    1. 用 Docker 跑起 Airi
    2. 選一個模型 + 打通語音
    3. 寫一段屬於你的 persona
    4. 如果有 Minecraft 伺服器,再綁一次遊戲互動

    做到這四步,你就真正「把一個 AI 養在自己的電腦裡」,之後只需要慢慢調人格、調記憶,讓它變成最懂你的那一個。

    🚀 你現在可以做的事

    • 打開 Airi GitHub 專案,按照 README 用 docker compose up -d 跑起第一個實例
    • 在 Airi 設定中接上一個模型(本地 qwen2.5 或雲端 gpt-4o-mini),並測試一句對話是否正常
    • 寫一段簡短 persona(例如「AI 同事」或「伺服器資源總管」),儲存後連續跟它聊幾天觀察效果
  • Claude Code 動態工作流實戰指南

    Claude Code 動態工作流實戰指南

    📌 本文重點

    • 動態工作流讓 Claude Code 變成能總包整個 repo 的工程助手
    • Opus 4.8 提升程式推理與錯誤自查效率,並提供快速模式省時省錢
    • Ultracode 把大規模 code review 與安全審計變成一個指令可完成

    用一句話講清楚:Claude Code 的「動態工作流」讓你把「重構整個 repo、語言遷移、資安審計」交給一個會自己拆分任務、開數百個子 Agent 平行跑、還會自我驗證結果的代碼工地總包商。


    核心功能:從「聊天寫程式」升級成「工程總包」

    1. 動態工作流:自動拆分、平行執行、自己驗收

    Anthropic 在 Claude Code 中加的 dynamic workflows,關鍵不是「多 Agent」本身,而是:

    • 由模型自己寫協調腳本(orchestration scripts)
    • 自動把工作拆成數十到數百個子任務
    • 每個子任務對應一個子 Agent 平行跑
    • 結束前先做一輪自我驗證,只把過檢的結果給你

    最典型的實戰案例,是 Bun 作者用它做 Zig→Rust 遷移:

    近 75 萬行代碼、約 11 天完成,測試通過率 99.8%(來源:Reddit 動態工作流介紹)

    💡 關鍵: 對接近 75 萬行程式碼的遷移專案來說,11 天達到 99.8% 測試通過率,代表這套動態工作流足以接住大型、原本高風險的重構工程。

    實際會怎麼跑? 以「整個 repo 重構」為例,dynamic workflows 大致會:

    1. 掃描 repo,產生檔案與模組地圖
    2. 規劃任務圖(Task graph):例如先改 domain 層,再跑 API 層,最後是 UI
    3. 平行啟動子 Agent:每個 Agent 負責一組檔案或一類修改(型別調整、logging 統一、錯誤處理強化…)
    4. 在背景自動做 diff、測試、靜態檢查
    5. 聚合結果,過一輪總審查後才丟回給你

    你可以這樣用(行動建議):

    • 想重構:
    • 在 Claude Code(或 API)裡給它:
      • 專案簡介 + 技術棧
      • 現在的痛點(例如:循環依賴、例外亂飛、型別不嚴謹)
      • 你願意接受的改動範圍(例如:可以改 public API?可以拆模組嗎?)
    • 下指令像:「為這個 monorepo 設計一個 2 週內可以完成的重構計畫,用動態工作流分批執行。」

    • 想做資安審計:

    • 給它 repo,說明:框架、使用的雲服務、資料敏感區
    • 指令示例:「用動態工作流做一次安全掃描,重點找:未驗證的輸入、SQL injection 風險、憑證硬編碼、弱 JWT 驗證。」

    2. Opus 4.8:程式推理更穩、錯誤自查率變 4 倍

    根據 Anthropic 官方與社群測試(如 Decoder 報導 和 r/artificial 整理):

    • 程式錯誤檢測能力較 4.7 提升約 4 倍:更容易自己指出「這裡可能 NPE」「這裡 race condition」「這裡忽略錯誤」。
    • 在瀏覽器 / 電腦代理 benchmark(Online-Mind2Web)上,Opus 4.8 優於 GPT-5.5,也就是比較會自己「操作工具」而不是只寫字。
    • 使用者回報的特點:更常誠實承認「沒做完」「這裡有風險」,對長流程開發很重要。

    更關鍵的是新增了「快速模式」(fast mode):

    • 約 2.5 倍速度
    • 成本約是完整模式的 1/3 左右(數字隨官方調整,但量級在這附近,來源:r/ClaudeAI)

    💡 關鍵: 在程式錯誤檢測提升約 4 倍的同時,fast mode 還能以約 1/3 成本提供 2.5 倍速度,讓你可以先用低成本掃全 repo,再用完整模式精修關鍵部分。

    怎麼選模式才划算?

    • 用快速模式的情境:
    • 寫 template、樣板 code(CRUD、UI 元件鋪排)
    • 大量簡單檔案轉換(例如 config 重排、註解補齊)
    • 先跑一輪粗略掃描(安全 / style / dead code)

    • 改用完整(非快速)模式的情境:

    • 棘手 bug 定位(多執行緒、邊界條件)
    • 關鍵底層邏輯(交易撮合、金流、權限系統)
    • 產出要長期維護的設計文件或核心 API 介面

    實作建議:先用快速模式跑全 repo 掃描 → 把它標出的高風險區塊,再交給完整模式精修。


    3. Ultracode:把「大規模 code review」變成一個指令

    Ultracode 是 Claude Code 裡針對程式碼審查的強化工作流(參考 r/ClaudeAI 討論):

    • 你只需要丟一個 diff、Pull Request 或整個子資料夾
    • Ultracode 會在背景開子工作流做:
    • 分檔案審查
    • 風險排序(安全 > 穩定性 > 可維護性)
    • 驗證自己的意見是否一致,再回傳整理過的 review

    實際效果偏向:一個很嚴格、沒情緒的資深工程師,會吐槽你 data2 這種變數名(參考「讓 Claude 審查 Claude」的案例)。

    你可以這樣用(行動建議):

    • 小團隊 / Side project:把 PR 丟給 Ultracode,要求:
    • 「請只標出會導致 bug / 安全問題的變更,逐一解釋原因。」
    • 「另外列一份『可選優化清單』,讓我有時間再慢慢改。」

    • 個人練功:

    • 把自己最近寫的一個模組丟給 Ultracode,問:
      • 「請假裝你是 code reviewer,列出你會擔心的 10 個點。」
      • 把每個問題的建議重構方式具體寫出來,附簡短範例。

    適合誰用?幾種典型場景

    1. 重寫或升級舊系統

    典型痛點:老專案沒測試、沒文件、沒人敢動。

    可以這樣切:

    1. 用 Claude Code 建一份系統地圖:
    2. 指令:「為這個 repo 建一份架構圖,包含模組依賴、資料流、外部服務。」
    3. 問它「若想把 A 模組替換成 B 技術棧,請設計一個最小風險的遷移計畫」,讓它給分批 PR 設計。
    4. 啟用動態工作流分批套改(例如先把 logging 換掉,再換 ORM)。

    2. 大規模代碼審計與安全掃描

    結合 dynamic workflows + Ultracode:

    • 全 repo 掃描:
    • 找硬編碼密鑰、弱加密、未驗證輸入
    • 為每類問題產生「修復模板」和自動修正 PR 草案

    • 持續使用方式:

    • 在 CI 加一步,用 Claude API 對每個 PR 跑 Ultracode 審查(可參考 Cloudflare 的 AI code review 實務 思路)。

    3. 多語言遷移(Zig→Rust、Python→TypeScript 等)

    Bun 的 Zig→Rust 遷移是一個極端例子,你可以用同樣思路做「比較小但現實」的版本:

    • Python backend → TypeScript(Express / Nest / tRPC)
    • JS 老專案 → TypeScript + stricter ESLint
    • PHP legacy → Laravel / Symfony 新專案

    實作建議:

    1. 先選一個獨立、低風險模組試轉,例如:
    2. 「通知系統」「報表匯出」「第三方 API 包裝」
    3. 指令示例:
    4. 「把這個 Python 資料轉換模組遷移到 TypeScript,目標環境是 Node 20 + TypeScript 5,型別要寫滿。」
    5. 測試穩了,再用動態工作流把相同 pattern 套到其他模組。

    4. 一人公司 / Side Project 的開發流程

    把 Claude Code 當作:

    • 一個幫你拉腳手架、寫樣板、整理測試的 junior dev
    • 再加上一個幫你審 PR、找安全洞的 senior reviewer

    你可以設計一個固定節奏:

    1. 功能草圖 → 讓 Claude 產生目錄結構與初版 code
    2. 自己補關鍵業務邏輯
    3. 用 Ultracode 做一次 code review + 測試覆蓋率建議
    4. 每個 sprint 最後,用動態工作流掃一次「錯誤處理 / logging / metrics 是否一致」

    怎麼開始:從免費聊天到整 repo 動態工作流

    1. 最低門檻:claude.ai 免費方案能做到什麼?

    入口:https://claude.ai

    目前免費帳號:

    • 可以使用新版模型(通常是 Sonnet / 部分場景下可用 Opus fast)
    • 適合:
    • 單檔 / 小模組的重構、bug debug
    • 讓它幫你讀一份錯誤訊息、log、或小型程式片段

    實際用法建議:

    1. 先貼一個單檔(或小於幾百行的檔案),請它:
    2. 「幫我找 bug / 重構 / 改風格」
    3. 再貼一個小 repo 的 zip / 關鍵檔案集合,問:
    4. 「請幫我畫出這個專案的架構圖與資料流程。」

    當你開始需要:

    • 長時間、多輪的代碼工作
    • 跑動態工作流、Ultracode、Opus 4.8 完整能力

    就會需要升級到 Claude Pro / Max / Team 或企業方案(具體功能以官方頁面為準)。


    2. 在終端安裝開源版 anthropics/claude-code

    GitHub:https://github.com/anthropics/claude-code

    基本安裝流程(概念):

    # 1. 安裝
    pip install claude-code  # 或依照 repo README 指示
    
    # 2. 設定 API Key(以官方 Claude API 為例)
    export ANTHROPIC_API_KEY="你的 API Key"
    
    # 3. 在專案根目錄啟動
    cd 你的專案目錄
    claude-code
    

    然後你就可以在終端跟它對話:

    > 幫我找出 src 下面所有可能的 race condition,並建議重構方式。
    > 幫我寫一個腳本,批次把 React class component 改成 function + hooks。
    

    動態工作流、Ultracode 會隨著你帳號權限與版本逐步釋出;用開源終端版的好處是:更容易和你自己的工具鏈(git、CI、測試框架)接軌。


    3. 透過 API / Bedrock / Vertex AI 調用動態工作流

    如果你要把這些能力塞進自己的內部平台或 CI:

    • Claude API:https://www.anthropic.com/api
    • Amazon Bedrock:在 Bedrock 控制台選擇 Claude Opus / Claude Code 相關 model
    • Google Vertex AI:在 Model Garden 選擇 Claude / Claude Code

    動態工作流目前通常以「研究預覽」方式提供給 Max / Team / Enterprise,透過:

    • 在請求中指定對應的 model / capability 標誌
    • 或使用官方提供的 workflow endpoint / 模板(需看當下文件)

    工程整合建議:

    • 在 CI 裡新增一個步驟:
    • 將本次 PR 的 patch / diff 打包
    • 呼叫 Ultracode / dynamic workflows 做審查
    • 把審查結果回寫成 bot comment

    4. 一個「從小到大」的漸進式實驗腳本

    你可以照這個順序,逐步加深依賴,而不會一開始就把整個 repo 丟給它:

    1. 單檔小任務(claude.ai 免費即可)
    2. 目標:讓它幫你修一個 bug / 重構一個 utility
    3. 檢查點:看它產出的 code 是否可讀、是否真的有幫你省時間。

    4. 小 repo(1–3 個模組) + Claude Code 終端版

    5. 目標:讓它在終端幫你跑測試、改幾個檔案、整理 commit
    6. 指令示例:「設計一組 PR,把這個小專案升級到最新框架版本。」

    7. 整個代碼庫 + 動態工作流 / Ultracode

    8. 目標:一次性做一個「人力不想做」的大工程:
      • 全 repo 錯誤處理統一
      • 安全掃描 + 自動修復草案
      • 語言 / 框架遷移的一個大模組
    9. 檢查點:
      • 先在 staging / feature branch 跑
      • 用你自己的測試 + Claude 的自我驗證雙重把關

    照這個步驟,你會很快感受到:Claude Code 已經不只是「幫你補幾行程式碼」,而是可以接下「這個季度我們一直不想動的那一坨技術債」,而你只需要負責決策方向與最後拍板。

    🚀 你現在可以做的事

    • 到 claude.ai 用免費帳號先丟一個單檔,實測一次 bug 修正或小重構流程
    • 在自己的專案根目錄安裝並啟動 anthropics/claude-code,讓它對一個小模組跑動態工作流或 Ultracode
    • 在現有 CI 流程中,挑一條非關鍵分支試接 Claude API,讓 Ultracode 對 PR 自動產生第一次 code review 評語
  • Anthropic 一兆估值:AI 基建寡頭的成形時刻

    Anthropic 一兆估值:AI 基建寡頭的成形時刻

    📌 本文重點

    • Anthropic 正被定價成「AI 公用事業」級別基礎設施
    • 工具鏈與 SDK 集中化,正加速開發者與企業被鎖死
    • 安全與監管話語權,正在被少數估值超高的寡頭掌控

    Anthropic 在 H 輪融資中拿下 650 億美元、估值 9650 億美元,這已經不是「新創成功」的故事,而是「AI 基礎設施寡頭」正式成形的時間點。我對技術本身是偏多的,但對這種幾乎貼近 AGI 級別 的估值,抱持非常高的資本過熱警戒。這一輪不是單純泡沫,而是 AI 從產品競賽走向基建壟斷預期的轉折。


    ① 這不再是 SaaS 估值,而是「AI 基礎設施壟斷預期」

    先看幾個關鍵數字:

    • 估值:9650 億美元,逼近 1 兆(Series H 後市值,TechCrunch / Anthropic 官方)
    • 新資金:650 億美元,這不是「成長輪」,而是直接在堆砌一座算力發電廠
    • 年化收入:約 470 億美元(CFO Krishna Rao 對外說法)

    💡 關鍵: 估值 9650 億 + 年化收入約 470 億,代表市場已把 Anthropic 當成未來 AI 公用事業與基礎設施寡頭在定價,而非一般 SaaS 公司。

    把這組數字丟進任何傳統 SaaS / 雲服務估值模型,都會直接當機。這個估值隱含的不是「多賣幾倍 API」、也不是「辦公室軟體雲端化」,而是資本市場在押一個更極端的敘事:

    未來的通用 AI 能力,就像電力、自來水與雲端計算,是由少數幾家超級供應商長期壟斷。Anthropic 被定價成其中一根 AI 高壓電塔。

    從產業結構來看,這個估值是在預支三層「壟斷紅利」:

    1. 算力基建壟斷:650 億美元會大幅砸向 GPU、資料中心、專用加速器。這不是一般公司「多買幾張 A100」,而是 直接在底層算力上卡位,與雲端巨頭一起把未來十年的 AI 生產資料中心「先買斷」。

    2. 模型層壟斷:當 Anthropic、OpenAI、Google 成為唯三能穩定訓練頂級 frontier model 的公司,整個產業會從「百模爭鳴」回到 少數幾個國際標準(就像行動 OS 最後只剩 iOS / Android)。

    3. 生態位壟斷:不只模型,連 SDK、代理框架、企業集成標準都被同一批玩家掌控,形成 從晶片 → 模型 → SDK → 工具鏈 → Marketplace 的垂直封閉鏈條。

    這就是為什麼 Anthropic 能拿到接近一兆估值:市場不是在買「一間做聊天機器人的公司」,而是在買「未來 AI 公用事業公司」的門票。 這對技術長期發展是利多,對競爭與治理則是警訊。


    ② 對開發者與企業:技術路線被鎖定,談判權往上游集中

    這一輪最值得開發者警戒的,不是模型多強,而是 誰在握工具鏈。

    根據 Towards AI 報導,Anthropic 收購了一家為 OpenAI、Google、Meta、Cloudflare、Cerebras 等提供 SDK 編譯器的關鍵基礎設施公司。這件事目前業界還沒大吵,但含義非常清楚:

    誰掌握 SDK,就掌握開發者的預設路線。

    在實務上,這會導致幾個結構性變化:

    1. 工具鏈集中化:一兩家廠商握住大部分 AI SDK/agent framework

    開發者不是直接「選模型」,而是先選框架、SDK,再被默默導向某幾家預設供應商。當 Anthropic 同時是模型供應商 + SDK gatekeeper,就等於在談判桌上多了一層槓桿:

    • 價格可以透過「綑綁方案」來模糊上漲
    • 預設選項可以讓競品被放在體驗次優的角落

    • 技術路線鎖定:從「多雲多模」變成「事實上的單一供應商」

    理論上大家都說要 multi-model / multi-cloud,但當你的內部工具、workflow、自動化代理全綁在某家 SDK 上,切換成本就從「換 API key」變成「重寫整個 AI 工程堆疊」。企業 IT 會發現:

    • 法務覺得多簽幾家供應商很安全
    • 工程團隊卻被工具鏈默默鎖在一兩家大廠之內

    • 中小模型與開源被擠壓在「次級市場」

    如果 SDK 預設支援的是 Anthropic + 少數幾家頭部模型,那麼:

    • 開源模型、地端模型被 relegated 成「高摩擦實驗選項」
    • 真正做到自訓 / 混合架構的公司,會被迫投入更多 infra 成本

    💡 關鍵: 當 SDK 與工具鏈被少數模型供應商整合,企業的「multi-cloud / multi-model」常會淪為紙上談兵,實際上是高成本的單一供應商依賴。

    開發者接下來要做的,不再只是「選哪家模型」的問題,而是要主動抵抗工具鏈的單一化。 實務建議:

    • 在架構設計上,務必自建一層「模型抽象層」(例如自行封裝一個 internal LLM client,而不是直接寫死某家 SDK)

    • 優先選擇 自家可控、開源或至少多供應商支援的 orchestration / agent framework

    • 企業決策層要認真看待 vendor lock-in 風險,不要被「先上先贏」的 FOMO 氛圍推著跑


    ③ 對使用者與社會:最有錢的公司,也握著「安全」話語權

    Anthropic 一直主打「安全對齊」與「憲法式 AI」,這在技術與理念上值得肯定。然而當一家估值逼近一兆、手握前沿模型的公司,同時掌控 AI 安全話語權,就產生了一個微妙的結構:

    安全,不再只是學術與公共議題,而是 IPO 前的重要敘事資產。

    幾個結構性風險會逐步浮現:

    1. 監管節奏被資本市場綁架

    當前沿公司接近 IPO、年化收入被報到 470 億美元 這個量級時,「成長故事」會壓過一切。管理層在實務上會面臨:

    • 安全研究與治理機制,會被要求「不要拖慢產品 shipping」
    • 對外談風險,要「夠負責」,但不能真的踩到 增長剎車

    • 安全標準與價格結構,被同一批寡頭定義

    當 Anthropic、OpenAI、Google 同時是:

    • 模型供應商
    • SDK / 生態平台主宰者
    • 「AI 安全」與「對齊框架」的主流制定者

    那麼「什麼是負責任的 AI」、「什麼是合理的成本與價格」就會被預設成少數美國大型公司認為合理的樣子。這會帶來:

    • 全球南方國家、中小企業對 AI 的 可負擔性問題 被邊緣化
    • 安全門檻有可能被用來 合理化高價與高門檻接入(例如更嚴格審核、但實際上是市場篩選機制)

    • 真正多元的治理聲音被擠出場外

    資本會偏好「能跟監管機構好好說話的大公司」,於是:

    • 小型安全研究組織、獨立開源社群的影響力相對下降
    • 監管機關更習慣「諮詢幾家巨頭」,將其視為代表整個產業

    💡 關鍵: 當「安全」變成高估值公司手中的敘事資產時,安全與增長之間的取捨,很可能由少數寡頭在封閉談判桌上決定,而不是公開多元的社會討論。

    當 AI 走到「寡頭基建」階段,風險不在於技術進步,而在於誰有權定義「安全、合理、公平」。現在是資本與治理權高度重疊的時刻。


    結論:這不是泡沫尾聲,而是寡頭基建開場,我們要做什麼?

    我不認為 Anthropic 這一兆估值 是單純的狂熱泡沫——這裡面確實反映了通用模型在各產業的 長期基建價值。但更關鍵的是:

    AI 正從「創業故事」轉向「寡頭基建」階段;現在缺的不是更多 FOMO,而是更成熟的監管與競爭設計。

    對不同角色,我的具體建議是:

    • 對開發者:
    • 把「避免深度 vendor lock-in」當成架構設計的一等公民
    • 優先學會 跨模型、跨雲的抽象設計,不要只做某家 API 的高級使用者
    • 主動支持並參與 開源工具鏈與模型評測,在生態裡維持一條可行的備用路線

    • 對企業決策者:

    • 在採用 Anthropic / OpenAI / Google 時,把集中風險寫進風險評估與合約條件,而不是事後才補課
    • 預留預算與人力實驗 開源與地端模型,即使短期 ROI 不明顯

    • 對政策與監管單位:

    • 將 工具鏈整合與 SDK 收購 視為反壟斷與競爭政策的重點,而不是只盯模型參數大小
    • 設計讓 中小模型供應商與開源社群 有制度性發聲與參與標準制定的機制

    技術值得看多,估值需要冷靜。如果我們放任 AI 基建完全在少數幾家「最有錢又掌握安全話語權」的公司手裡定義,十年後爭論的就不只是誰的模型比較聰明,而是誰還有資格接入這個新基礎設施。現在是把遊戲規則寫好的最後窗口期。

    🚀 你現在可以做的事

    • 審視現有專案中與特定 AI 廠商深度綁定的 SDK / 工具鏈,評估是否需要加一層自建抽象層
    • 去 GitHub 搜尋並試用至少一個多模型支援的開源 agent / orchestration 專案,作為未來備援方案
    • 若你在企業或政策相關單位,將「AI 工具鏈集中化與 SDK 收購」列入下一輪風險評估或政策討論議程
  • AI Middleware 控制層實戰指南

    AI Middleware 控制層實戰指南

    📌 本文重點

    • 直接在業務程式碼呼叫 LLM API 是反模式
    • 需要獨立 AI Middleware 控制層集中治理
    • 控制層是從 demo 到 production 的關鍵分水嶺
    • 多代理與記憶治理必須納入審計與安全設計

    先講結論:直接在產品程式碼裡 fetch('https://api.llm.com') 是一種反模式。當功能從「問答」長成「多工具、多代理、多租戶」時,你會需要一層專門的 AI Middleware 控制層,把:

    • 模型路由與選型
    • Tool / Agent 協調
    • log / trace / metrics
    • 成本與速率限制
    • cache / 重試策略
    • 合規與安全策略注入

    從業務程式碼中抽出來,集中治理。這一層就是 LLM 應用從 demo 到 production 的分水嶺。

    💡 關鍵: 把所有 LLM / Tool / Agent 呼叫收斂到單一控制層,是從玩具 demo 變成可維運產品的必要條件


    重點說明:為什麼要獨立 AI Middleware 控制層?

    1. 從「直接 call 模型」到「控制層」

    傳統 Web 三層:UI 層 → Service 層 → DB 層。

    LLM 應用如果是:UI → 直接呼叫模型 API,你會發現:

    • 想加 多模型路由(如 GPT + Claude + 本地模型)時,只能四處找出 openai.chat.completions.create 逐一改。
    • 想統一 重試 / 超時 / 灰階 / rollback,根本沒有共同入口可以掛。
    • 想做 成本統計、用戶配額,只剩 trace log 回頭瞎猜。

    控制層的做法是:

    Product Code → AI Middleware(控制層)→ 各家模型 / 工具 / Agent

    所有模型呼叫先經過這一層,才能實作像 API Gateway + Service Mesh 那種集中治理能力。

    2. 控制層的核心職責拆解

    實務上,控制層至少要負責這幾件事(建議直接當 checklist):

    1. 路由與模型選擇
    2. 依 任務類型、租戶、成本上限、延遲預算 選擇具體模型。
    3. 範例策略:summary 走便宜模型;寫 SQL 走更準確模型;UGC 敏感類先加安全模型前置審查。

    4. Tool / Agent 協調

    5. 統一管理 工具 registry、Tool 調用權限、Agent orchestration。
    6. 在多代理系統中,把「誰能叫什麼工具」和「記憶寫入策略」集中配置,而不是散落在各 Agent 類別裡。

    7. 觀測與追蹤(logs / traces / metrics)

    8. 每個 LLM 請求、工具呼叫、記憶讀寫 都要有 trace id。
    9. 對接 OpenTelemetry 或 APM:把 token 數量、延遲、錯誤碼、cache 命中等變成可查詢的 metrics。

    10. 成本與速率限制

    11. 按 user / org / feature 做 token 配額與 qps 限制。
    12. 將成本計算邏輯(model 單價、權重)集中在控制層。

    13. cache 與重試策略

    14. 根據 prompt 指紋 + 入參 做 deterministic 回答的 cache。
    15. 定義 哪些錯誤可重試、最大重試次數、退避策略,避免在業務層各自實作。

    16. 合規與安全策略注入

    17. 對接 DLP、敏感詞檢測、角色權限,把 prompt / tool call / output 走同一條審查管線。
    18. 企業內部可在這裡插入 審批流(human-in-the-loop)。

    💡 關鍵: 成本、風險與合規控制若不集中在控制層,很難在日後擴展時補強而不「大重構」

    3. 審計追蹤與記憶治理:多代理系統必備

    多代理系統與企業場景最常見的兩個雷:

    • 沒有審計 trail:agent 到處點擊、下單、寫 ticket,最後出了事誰也說不清「是第幾步決定下單」?
      → 參考 Reddit 討論:AI agents 比起更多自主性,更需要完整 audit trail。控制層就是自然的落點。

    • 記憶污染嚴重:所有 agent 都能隨意寫向量庫,久了之後充滿過期決策、敏感資料。
      → 引入 Memory Curator 概念:worker agent 只能發出 記憶事件,由專門的記憶治理層決定要不要寫入、寫到哪個 scope(個人 / 團隊 / 專案 / 會話)。

    這兩件事如果不在控制層規範好,就會像 Reddit 上那位開發者形容的:「前三週一切正常,之後 retrieval 變成噪音地獄」。


    實作範例:用 Genkit 與 Vercel AI Gateway 搭 Node / Python 控制層

    下面用兩個路線示範:

    • Node:Google Genkit + Vercel AI Gateway
    • Python:簡易自製 Middleware(搭配 OpenTelemetry)

    範例一:Node + Genkit Middleware(含 model 路由與 observability)

    安裝與基礎設定(簡化示意):

    npm install @genkit-ai/core @genkit-ai/openai @genkit-ai/firebase
    npm install @opentelemetry/api @opentelemetry/sdk-node
    

    建立 aiClient.ts 當控制層入口:

    // aiClient.ts
    import { genkit, z } from "@genkit-ai/core";
    import { openai } from "@genkit-ai/openai";
    
    const ai = genkit({
      plugins: [openai()],
    });
    
    // 定義模型路由策略
    const pickModel = (task: string) => {
      if (task === "summary") return "gpt-4.1-mini";
      if (task === "sql") return "gpt-4.1";
      return "gpt-4o";
    };
    
    // 中央統一的生成函數
    export async function generateText(req: {
      task: "summary" | "sql" | "general";
      input: string;
      userId: string;
    }) {
      const model = pickModel(req.task);
    
      // observability: 附上 trace metadata
      const traceMeta = {
        userId: req.userId,
        task: req.task,
        model,
      };
    
      return ai.generate(
        {
          model,
          prompt: req.input,
        },
        {
          // middleware hooks: 可插 retry / cache / logging
          trace: traceMeta,
        }
      );
    }
    

    在 Genkit middleware hooks 中加入 cache / retry / 安全策略(概念程式):

    // middleware.ts
    import { registerMiddleware } from "@genkit-ai/core";
    
    registerMiddleware(async (ctx, next) => {
      const key = hashPrompt(ctx.request);
    
      // 1. Cache 命中
      const cached = await cacheGet(key);
      if (cached) {
        ctx.log.info("cache-hit", { key });
        return cached;
      }
    
      // 2. 成本與速率限制
      await enforceQuota(ctx.trace.userId, ctx.request.model);
    
      // 3. 安全策略:例如 DLP 檢查
      await checkPromptPolicy(ctx.request.prompt);
    
      // 4. 重試包一層
      return retry(async () => {
        const res = await next();
        await cacheSet(key, res);
        return res;
      }, { retries: 2, backoffMs: 200 });
    });
    

    前端 / 服務層就只呼叫 generateText,完全不碰 openai.chat 類 API。未來換模型、加灰階、接別家供應商,只要改控制層即可。

    範例二:Node + Vercel AI Gateway 作為集中入口

    Vercel AI Gateway 提供 統一 endpoint + 多模型路由 + 速率限制 + 規則引擎,很適合當外部控制層。

    基本設定(vercel.json 或 UI 設定):

    • 建立一個 Gateway route,例如:https://ai.yourdomain.com/v1/chat。
    • 配置 providers:OpenAI / Anthropic / 自建模型。
    • 寫 routing rule:
    • if (task == 'summary') -> openai:gpt-4.1-mini
    • if (tenant == 'premium') -> anthropic:claude-3.7

    前端程式碼(Next.js 伺服器端)只需要呼叫單一 gateway:

    // app/api/ai/route.ts
    import { NextRequest, NextResponse } from "next/server";
    
    export async function POST(req: NextRequest) {
      const body = await req.json();
    
      const res = await fetch(process.env.AI_GATEWAY_URL!, {
        method: "POST",
        headers: {
          "Content-Type": "application/json",
          "X-Tenant": body.tenantId,
          "X-Task": body.task,
        },
        body: JSON.stringify({
          messages: body.messages,
          stream: body.stream ?? false,
        }),
      });
    
      // 這裡可以加 audit log / trace id
      return new NextResponse(res.body, { status: res.status });
    }
    

    優點:

    • 速率限制、成本統計、提供者 failover 直接用 Vercel 的 console 配。
    • 灰階與回滾:改 routing rule 即可,比如 10% 流量導到新模型。

    💡 關鍵: 把流量管理與模型路由交給 gateway,可用設定檔與後台調整,而不必每次動到應用程式碼

    範例三:Python 控制層 + 記憶治理(Memory Curator)

    假設你在做多代理系統,希望 worker agent 不能直接寫入向量庫。

    # ai_control_layer.py
    from dataclasses import dataclass
    from typing import Literal, Dict, Any
    
    Scope = Literal["agent", "team", "project", "session"]
    
    @dataclass
    class MemoryEvent:
      scope: Scope
      content: str
      evidence: Dict[str, Any]
      actor: str  # 哪個 agent
    
    class MemoryCurator:
      def __init__(self, store):
        self.store = store
    
      def decide(self, event: MemoryEvent):
        # 簡單篩選:過長、含敏感資訊則拒絕
        if len(event.content) > 2000:
          return "discard"
        if "password" in event.content.lower():
          return "discard"
    
        # 不同 scope 寫不同 index
        index_name = {
          "agent": f"agent-{event.actor}",
          "team": "team-shared",
          "project": "project-global",
          "session": None,  # 只放在 runtime context
        }[event.scope]
    
        if index_name:
          self.store.write(index_name, event.content, event.evidence)
          return f"written:{index_name}"
        else:
          # session-only: 不寫 durable store
          return "session-only"
    
    # worker agent 不直接調 store
    curator = MemoryCurator(store=vectordb)
    
    async def worker_store_memory(proposed_content: str, actor: str):
      event = MemoryEvent(
        scope="project",
        content=proposed_content,
        evidence={"source": "task_result"},
        actor=actor,
      )
      result = curator.decide(event)
      return result
    

    在這個架構下:

    • 所有記憶寫入 都經過 MemoryCurator,可審計、可控。
    • 之後要加 審計 log / OpenTelemetry span 也只改這一處。

    建議與注意事項:常見踩坑與實戰指引

    1. 不要把控制層寫成巨大 God Service

    常見錯誤:

    把所有邏輯(模型路由、prompt 模板、tool orchestration、記憶管理、審批流)塞進同一個 ai_service.ts。

    結果:

    • 難以測試、難以灰階、任何小改都要全 redeploy。
    • 無法對特定職責做獨立 scaling(例如工具呼叫爆量時)。

    建議:依職責拆模組,例如:

    • ModelRouter
    • ToolRegistry
    • RetryPolicy
    • QuotaManager
    • MemoryCurator

    控制層本身只是一個 薄 orchestration 層,組裝這些模組,不要變成 monolith。

    2. 一開始就設計可觀測性 schema

    很多團隊是到事故發生後才加 log,結果 schema 雜亂無章,完全無法統計。

    最低限度,請在控制層統一定義以下欄位:

    • trace_id / span_id:串起同一個 user request 下的所有模型與工具呼叫。
    • user_id / tenant_id / feature_name:方便做成本報表與配額控制。
    • model_name / provider / tokens_in / tokens_out / latency_ms:跑出模型性能與成本比較。
    • cache_hit / retry_count / policy_blocked (bool):分析策略的實際效果。

    搭配 OpenTelemetry:

    • 在 control layer 的入口建立 root span。
    • 每個 model_call、tool_call、memory_write 建子 span。
    • 把上述欄位當 attributes 寫入。

    3. 灰階與回滾機制不要事後補

    Anthropic 的觀察顯示:非程式碼型 agent 在 production 常常因為資料與流程難控而失敗。這不是模型問題,而是缺乏 安全試錯機制。

    在控制層預先設計:

    • 灰階發布:例如新增模型時,只讓 5% 的流量使用;表現不好立即切回。
    • 可以在 Vercel AI Gateway 或內部 router 實作簡單的百分比路由。
    • 策略回滾:策略(例如更嚴格的 DLP、不同記憶寫入規則)要抽成 可配置,而不是寫死在程式裡。
    • 配合 feature flag 平台(LaunchDarkly 等)效果更佳。

    4. 把 audit trail 當成產品需求,不是附加功能

    對多步 agent 流程,請明確要求:

    • 每一步 「想做什麼 → 實際做了什麼 → 結果如何」 都寫 audit log。
    • 在 UI(或 admin console)內提供「代理執行歷史」頁面,讓使用者能依 trace id 看到整條鏈。

    這件事最好放在控制層完成:

    • 所有 tool_call 都經過控制層。
    • 控制層負責序列化成統一格式:

    json
    {
    "trace_id": "...",
    "step": 3,
    "actor": "billing_agent",
    "tool": "update_invoice",
    "input": {"invoice_id": 123},
    "output": {"status": "ok"},
    "started_at": "...",
    "duration_ms": 532
    }

    這直接提升企業客戶的信任度,也方便日後做合規稽核。


    總結: 如果你的專案準備從「demo 給老闆看」變成「真的要上線給客戶用」,請先停下來,把所有 LLM / Tool / Agent 呼叫集中收斂到一個 AI Middleware 控制層。路由、觀測、策略、記憶治理都放在這裡,才能控制成本、降低事故、加快迭代速度。

    🚀 你現在可以做的事

    • 整理專案中所有 openai.chat / fetch('llm') 呼叫點,設計一個統一的控制層介面(如 generateText())
    • 在控制層導入基本的 trace_id、user_id、model_name log schema,並串接 OpenTelemetry 或現有 APM
    • 為現有的多代理或 RAG 系統設計一個 MemoryCurator 類別,強制所有記憶寫入都經過同一治理入口
  • 把你的 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」
    – 記憶體至少 16GB(8GB 也能跑小模型,但體驗會受限)

    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 區先各自為 research、write、edit 建立對應 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 輸出到外部工具」的完整工作流
  • 讓 Claude 幫你刷卡之前:誰在替 Robinhood 扛風險?

    讓 Claude 幫你刷卡之前:誰在替 Robinhood 扛風險?

    📌 本文重點

    • Robinhood 把可被遠端操控的 AI 代理直接接到刷卡與交易權限
    • 平台用技術切割資金,卻刻意模糊責任邊界與風控機制
    • 在可稽核帳本、細粒度授權與責任分攤未到位前,不該放手讓 AI 動真錢

    Robinhood 把 Anthropic 的 Claude 接到刷卡與下單權限上,不只是「又一個酷炫 feature」,而是第一次把「可被遠端操控的 AI 多代理系統」直接連到零售金融與消費支付。 這一步在技術上順理成章,在風險上卻是把本來應該由平台與監管承擔的系統性風險,轉嫁給最末端的散戶與一般用戶。


    一、從「聊天」到「刷卡」:Robinhood 正在測試的邊界

    先把產品拆開看:

    • 多代理 / MCP 架構:Robinhood 讓你把像 Claude 這類 AI agent 接到一個獨立投資帳戶與專屬錢包,透過 MCP(Model Context Protocol)調用券商、信用卡等工具。
    • 資金層級的授權:
    • 股票:agent 可以在這個帳戶裡 自動買賣,實現「agentic trading」。
    • 消費:部分實作更允許 agent 用你的 信用卡進行購物與支付。
    • 風險切割的說法:
    • Robinhood 對外主打「獨立帳戶」「預置資金上限」來降低風險。
    • 同時又提醒這不適合所有用戶,投入資金可能完全損失。

    💡 關鍵: 把可被 prompt 操作與攻擊的軟體代理接到真實刷卡與交易權限上,讓最末端用戶承擔原屬於平台與監管的系統性風險。

    表面看起來像是更自動化的量化交易 + 智慧消費,實際上 Robinhood 做的是:

    把一個可被 prompt、可被攻擊、可被他人操縱的軟體代理,直接掛到合規要求最嚴格的金融與支付基礎設施上,卻沒有同步升級責任、稽核與安全模型。

    這才是這件事真正危險的地方。


    二、「誰負責」被刻意模糊:合約寫得清楚,責任卻寫得含糊

    AI 代理進入金融業,第一個問題本來就應該是:誰為它的行為負責?

    Robinhood 用了幾個典型的模糊技術:

    1. 產品語言把責任推回使用者

    在宣傳裡,agent 被描述為「幫你監控產業、重新平衡投組的自動化工具」。聽起來像智能助理,但實際權限是 直接下單、直接刷卡。當代理做出離譜交易時,平台可以輕易退回一句:「是你授權的策略與 agent。」

    1. 技術結構被包裝成風險隔離,而不是責任分攤

    2. 「獨立帳戶」「預置錢包」的確在損失金額上畫了邊界。

    3. 但在責任邊界上卻沒有任何清楚設計:

      • 若因為 agent 被投毒、或底層依賴的 開源框架漏洞(如 Starlette 那類事件) 導致憑證外洩,誰買單?
      • 若 Claude 的模型行為偏誤,導致系統性錯誤交易,Anthropic、Robinhood、用戶各自的責任比例是什麼?
    4. 監管空窗下的「默許」創新

    美國 FINRA 已經點名 agentic trading 是新風險區,但現有規範多針對:

    • 人為操盤、演算法交易、黑箱策略披露。

    對於「由第三方大模型驅動、由多代理協調、可跨場域調用支付工具」這種架構,責任主體與適格性審查都還沒寫進條文裡。

    實務上,這會導致一個非常實際的結果:

    出事時,平台可以拿出一疊風險揭露文件;模型公司可以引用使用條款;真正實際承受金錢損失與信用風險的,是那個按下「同意授權 AI 代理」的普通用戶。


    三、風控與 IR Playbook 還停留在「伺服器時代」,沒人真的在看代理行為

    把資安與風控角度拉進來,問題更明顯。

    Sygnia 2026 CISO 調查的幾個數字很關鍵:

    • 73% 的 CISO 認為組織還沒準備好應對重大攻擊。
    • 只 約三分之一 覺得自己能妥善調查「AI 代理事件」。
    • 有 88% 部署 AI 代理的企業 在過去 12 個月有確認或疑似相關資安事件。

    💡 關鍵: 即使在專業組織中,仍有 73% 的 CISO 自認無法應對重大攻擊,顯示整體安全治理遠落後於 AI 代理實際授權範圍。

    原因很直接:

    過去的事件應變流程(IR playbook)是為「伺服器被入侵、帳密被盜」設計的,不是為「一群會互相對話、會記住憑證、會自己下單的代理」設計的。

    AI 代理具備幾個讓傳統風控失效的特徵:

    • 跨會話保存憑證與記憶:代理可以在很多天、很多任務裡重複使用同一組 API key 或 session,讓憑證洩漏的危害時間大幅拉長。
    • 自然語言互動易被投毒:系統不再只看 IP 與封包,而是要看「這段對話是不是惡意引導」,大多數 SOC 與風控系統根本沒這個能力。
    • 多步驟、自主規劃:代理可以自行「發現新工具 → 取得更多權限 → 發送轉帳指令」,整個路徑在傳統監控裡看起來都「合法」。

    再把 開源供應鏈風險 疊上來:

    • Starlette 漏洞 事件提醒我們:一個在 FastAPI、生態工具中被廣泛採用的 ASGI 框架出 bug,就能讓跑在上面的 數百萬 AI 代理與 MCP 工具暴露憑證與數據。
    • 金融代理通常會握有:
    • 券商 API token
    • 銀行帳戶存取權
    • 信用卡支付憑證

    在這種結構下讓代理去刷卡、去下單,本質上是在做一件事:

    把交易與支付風險,疊加在一個安全治理成熟度遠低於傳統金融核心系統的「新技術堆疊」上。

    Google Cloud COO Francis de Souza 最近說「AI 安全應該進董事會,不只是機房」,Robinhood 這類產品設計,正好反向佐證:

    • 產品與增長團隊把 AI 代理視為「新的 engagement tool」。
    • 但多數公司的董事會與風控委員會,根本沒把「自主 AI 行為」列為一級風險源。

    四、從券商複製到 BNPL:系統性風險會沿著產品抄作業

    Robinhood 的這一步,一旦被證明「有黏著度、有交易量」,會很快被其他玩家複製:

    • 券商與新創銀行:
    • 讓 agent 幫你做期權策略、槓桿 ETF 調倉。
    • 把「日內交易 + AI」包裝成散戶可享的量化工具。
    • 電商與信用卡發卡行:
    • 「幫我自動 re-order 最划算的日用品」→ 背後其實是 agent 掌控你的卡號與地址。
    • 「自動比價 + 下單」→ 只差一個 prompt injection 就變成攻擊者的洗錢工具。
    • BNPL(先買後付)與小額信貸:
    • agent 可以根據「你的消費習慣」幫你評估要不要分期、要不要借款。
    • 一旦信用決策與自動下單綁死,等於允許一個黑箱模型代理,替你在負債表上簽名。

    這裡的系統性風險不在於「一個人被盜刷」,而在於:

    1. 同一類 prompt injection / 供應鏈漏洞,可以同時打到成千上萬個代理,造成大規模同步錯誤交易與支付。
    2. 當越來越多資金流與風險決策被委託給代理,人類使用者變成「最後一個知道發生什麼事的人」,卻還要承擔大部分合約責任。

    從監管角度看,EU AI Act 已經給出一個方向:

    • 法案不只管 AI 開發團隊,更會沿著 供應鏈往上游追責。
    • 未來若一個高風險 AI 系統(金融風險明顯屬此類)出了問題,
    • 提供模型的、
    • 提供代理框架與工具的、
    • 提供終端金流與硬體的,
      都可能被拉進責任鏈。

    這跟現在 Robinhood 模式形成強烈對比:

    產品端快速把授權往下推給用戶,監管端卻開始試圖把責任往供應鏈上收。中間這段空窗,就是最大風險區。


    結語:在三件事到位之前,AI 代理不該直接動你的錢

    從產業方向來看,Robinhood 的產品路線是不可逆的:AI 代理遲早會變成金融與支付的主流介面,就像當年 API 自動交易終究打敗電話下單。但現在的問題是節奏:責任與安全機制完全跟不上授權範圍。

    對開發者與產品決策者,我的具體判斷是:

    在以下三件事沒有設計清楚之前,不應該讓 AI 代理直接動用真實個人資金──更不要是信用卡與負債工具。

    1. 可稽核、可追溯的「代理行為帳本」

    2. 每次代理下單、調用支付、調整策略,都要有 結構化 log:觸發來源、工具、金額、模型版本、關鍵 prompt。

    3. 必須能在事後重建「這筆錢是怎麼被花掉的」,讓用戶、監管與第三方稽核都看得懂。

    4. 一鍵撤銷的細粒度授權機制

    5. 不只是「停用這個 agent」,而是:

      • 可限制交易品種(例如只能買 ETF,不可買期權)。
      • 可設定金額、頻率上限。
      • 可精準撤銷某個工具(例如暫停用信用卡,但保留投組分析)。
    6. 明確的賠償與責任分攤制度

    7. 對於模型錯誤、供應鏈漏洞、平台控管失當,要有清楚的賠償條款,而不是通通寫進「你已理解風險」。

    8. 用戶應該知道:什麼情況算是「你自己策略的錯」,什麼情況算是「系統或模型方的責任」。

    在這三件事落地之前,把刷卡權、交易權交給 AI 代理,本質上就是:

    把系統風險外包給缺乏談判能力與專業知識的散戶與一般消費者。

    身為開發者,你要做的不是搶先在首頁掛上「支援 AI 代理」,而是先問一句:如果這個代理瘋狂買進錯誤資產或被攻擊者操控,我們願意賠到什麼程度?
    如果這個答案說不出口,那就代表產品還沒準備好讓 AI 幫任何人刷卡。

    🚀 你現在可以做的事

    • 審視自己產品中所有 AI 代理權限,列出「能動哪些錢」「持有哪些憑證」並盤點風險
    • 為現有或規劃中的金融 / 支付代理設計「行為帳本」與「一鍵撤銷」機制雛形
    • 檢查條款與風險揭露文件,明確標示模型錯誤與供應鏈漏洞時的平台與用戶責任邊界