分類: AI 工具

  • 讓 AI 直接改你的 Word、Excel、PPT

    讓 AI 直接改你的 Word、Excel、PPT

    📌 本文重點

    • 讓 AI 直接操作 Word/Excel/PPT 檔案
    • OfficeCLI 適合與 Agent+腳本整合自動化流程
    • 先用「不心疼的文件」試跑完整讀改寫流程

    只用聊天讓 AI「給建議」還不夠,OfficeCLI 讓模型真的可以打開你的 Word、Excel、PPT,讀內容、改排版、算公式、生成簡報。

    工具連結:OfficeCLI GitHub


    核心功能:讓模型操作 Office 檔案,而不是你自己手動點

    OfficeCLI 是一個命令列工具(CLI),設計給 AI Agent 使用,但你也可以自己在終端機裡直接用。核心可以分成三類:

    1. 操作 Word:讀字+改內容+調樣式

    你可以讓模型:

    • 讀取 .docx 內容變成純文字,丟給 LLM 做摘要、改寫、翻譯
    • 依照模型輸出的指令,直接修改段落文字(新增、刪除、重寫某一章)
    • 調整樣式:標題層級、粗體、顏色、清單格式

    可行動做法:

    • 把一份報告初稿丟給模型,請它「重寫成給主管看的版本」,再用 OfficeCLI 把修改結果寫回原本 Word 檔,而不是你手動 Copy & Paste。

    2. 操作 Excel:讀表+算公式+生成新表

    OfficeCLI 可以讓 Agent:

    • 讀取多個工作表的資料,轉成結構化格式給模型分析
    • 新增欄位、列出關鍵 KPI、填入公式(SUM、AVERAGE、VLOOKUP 等)
    • 依照模型的建議建立新的工作表,用來放整理過的結果或圖表資料源

    可行動做法:

    • 給模型一個「原始交易紀錄」Excel,請它:
    • 建一個新工作表 KPI_Report
    • 幫你算出每月營收、客單價、流失率
    • 把結果整理成適合直接插入圖表的格式

    💡 關鍵: 把「讀原始表 → 算 KPI → 生成新表」整個流程交給 OfficeCLI+LLM,可以把每月重複的報表整理工作變成一鍵腳本。


    3. 操作 PowerPoint:生成與微調簡報

    OfficeCLI 支援 PowerPoint 檔案:

    • 讀取每一頁投影片的標題與內容
    • 新增或刪除投影片
    • 更新某一頁的文字方塊(例如換成模型生成的重點整理)

    可行動做法:

    • 把一份 Excel 月報+幾段文字說明給模型,請它先產出「投影片結構與內容草稿」,再用 OfficeCLI 寫進一份新的 .pptx,生成可直接開啟的簡報檔。

    適合誰用:幾個具體場景

    場景 1:自動產出月報簡報

    你現在的流程:

    1. 每月從系統匯出 Excel 報表
    2. 手動整理數字、貼到 PPT
    3. 想標題、寫重點、調整版面

    用 OfficeCLI+LLM 的新流程:

    1. 把原始 Excel 放在固定資料夾
    2. 寫一個簡單腳本:
    3. 用 OfficeCLI 讀 Excel
    4. 把數據丟給模型請它產出「月報重點+簡報大綱」
    5. 用 OfficeCLI 建立新的 PPT,依模型輸出寫入每一頁內容
    6. 最後只需要開啟 PPT,微調設計與少數文字

    可行動做法:先從「只讓 AI 幫你生成大綱與每頁標題」開始,內容可以再自己補,降低信任門檻。


    場景 2:整理一堆 Excel 原始數據成圖表+分析

    典型情境:行銷、產品、營運會有很多:點擊、轉換、工單、留存數據,全在 Excel。難的是「整理出看得懂的表+圖」。

    用 OfficeCLI,你可以:

    • 指定一個資料夾裡所有 Excel 檔,請 Agent 逐一讀取
    • 讓模型決定要留下哪些欄位、怎麼清洗資料(刪除缺漏、轉成正確型態)
    • 生成一個匯總報表工作表,包含:
    • 每個渠道 / 產品線的指標
    • 建議要畫的圖表(折線圖、長條圖等)所需的資料

    可行動做法:先選一個指標(例如「網站流量 x 轉換率」),用 OfficeCLI 做一個自動匯總報表,跑通一次流程,之後再擴展到更多 KPI。

    💡 關鍵: 先從單一指標的自動匯總起步,比一開始就要全覆蓋所有 KPI,更容易驗證數字正確性與提升團隊信任。


    場景 3:讓客服 Agent 直接更新 FAQ 文件

    很多團隊會有一份 Word FAQ 或知識庫檔:

    • 新問題出現,要有人手動編輯文件
    • 內容常常落後實際客服狀況

    用 OfficeCLI,你可以:

    • 讓客服 Agent 在處理完一批工單後,分析常見問題和回答
    • 自動比對現有 FAQ Word 檔:
    • 如果沒有對應條目,就新增一段 Q&A
    • 如果回答過時,就更新文字

    可行動做法:先讓 Agent 提出「修改建議」存成另一份 Word(例如 FAQ_suggested.docx),由人工審核後再整合到正式 FAQ,逐步建立信任再放權直接改正式檔案。


    怎麼開始:從一個指令讓模型讀 Excel 並生成報表

    1. 安裝 OfficeCLI

    前提:已安裝 Python 3.10+ 和 Git。

    在終端機(Terminal / PowerShell)輸入:

    pip install officecli
    

    安裝完可以先輸入:

    officecli --help
    

    確認有指令可用。


    2. 最簡單示範:讀一個 Excel 並生成報表

    假設你有一個 data/sales_raw.xlsx,想讓模型幫你整理成一個 KPI 報表:

    步驟示意(概念):

    1. 用 OfficeCLI 把 Excel 轉出成 CSV 或 JSON 給 LLM
    2. 讓模型決定要生成的欄位與指標
    3. 用 OfficeCLI 新增一個工作表 KPI_Report,把模型結果寫進去

    範例腳本(Python 語意示意):

    from officecli import excel
    from openai import OpenAI
    
    client = OpenAI()
    
    # 1. 讀取原始 Excel
    wb = excel.load_workbook("data/sales_raw.xlsx")
    sheet_data = excel.sheet_to_dicts(wb["Sheet1"])  # 每列變成 dict
    
    # 2. 丟給模型請它設計報表
    prompt = """
    你是一位數據分析師。以下是銷售原始資料,請幫我整理成一份 KPI 報表,包含:
    - 每月總營收
    - 平均客單價
    - 訂單數量
    請回傳 JSON,格式為:
    {
      "columns": ["month", "revenue", "avg_order_value", "orders"],
      "rows": [ ... ]
    }
    """
    
    resp = client.responses.create(
        model="gpt-4.1-mini",
        input=[{"role": "user", "content": prompt + "\n" + str(sheet_data)}]
    )
    
    kpi = resp.output[0].content[0].text
    
    # 3. 寫回新的工作表
    kpi_wb = excel.create_workbook()
    excel.write_json_to_sheet(kpi_wb, "KPI_Report", kpi)
    excel.save_workbook(kpi_wb, "data/sales_kpi.xlsx")
    

    可行動做法:照這個流程改成你自己的欄位與需求,把第一份「自動 KPI 報表」做出來,確認數字沒有問題後,再考慮加入圖表與文字說明。


    3. 串進自己的 Agent:讓排程每天自動更新 KPI 報表

    要讓這套流程每天自動跑,大致分三步:

    1. 寫好一個腳本:
    2. 用 OfficeCLI 讀當日最新 Excel
    3. 叫 LLM 算 KPI
    4. 用 OfficeCLI 更新指定報表檔(例如 KPI_daily.xlsx)

    5. 加進排程:

    6. Windows:用工作排程器(Task Scheduler)每天 09:00 執行腳本
    7. macOS / Linux:用 cron,例如:

    bash
    0 9 * * * /usr/bin/python /path/to/update_kpi.py

    1. 加一層通知:
    2. 報表生成後發一封 Email 或 Slack 訊息,提醒同事報表已更新

    可行動做法:先把腳本寫好,在終端機手動執行,確認整個 Excel→LLM→Excel 流程沒問題,再加排程,避免每天自動跑出錯卻沒人注意。

    💡 關鍵: 先人工確認幾次排程腳本的輸出,把錯誤風險壓低,再全面自動化,能避免在正式報表上出現難以察覺的錯誤。


    與其他方式的比較

    很多人會用「AI 外掛」或「手動 Copy & Paste」來改 Office 文件,OfficeCLI 的差異在於它是給 Agent 和腳本用的 CLI 工具,適合自動化流程。

    名稱 核心功能 免費方案 適合誰
    OfficeCLI CLI 操作 Word/Excel/PPT 給 Agent 用 開源、免費 想用程式+Agent 自動化的人
    Office 外掛 AI 在 Word/Excel 內聊天生成內容 部分帳號可免費 只想在文件內用聊天的人
    手動 Copy & Paste 人工搬運 AI 生成文字到文件 永遠免費 不寫程式、量很小的使用者

    如果你已經在寫腳本、用 Agent 處理工作流程,OfficeCLI 是目前比較直接、可控的選擇。


    小結:先讓 AI 改一份你不心疼的文件

    第一次用時,建議選一份「可以錯、可以重來」的文件做實驗:

    1. 準備一個 Excel 或 Word 副本
    2. 用 OfficeCLI 讓模型讀、改、寫回
    3. 看結果是否符合預期,再逐步放到正式流程

    當你跑通第一次,就會發現:AI 不只會「給你建議」,而是可以像實習生一樣,直接幫你動手調整文件——只是這次,你用 OfficeCLI 把它變成可以排程、可以重複使用的自動化流程。


    🚀 你現在可以做的事

    • 到 OfficeCLI GitHub 安裝並在終端機輸入 officecli --help 熟悉可用指令
    • 挑一份「月報用的 Excel 副本」,依文中範例腳本實作你的第一個自動 KPI 報表
    • 寫一個簡單排程腳本,先手動每天跑一次 Excel→LLM→Excel 流程,確認穩定後再用 cron 或 Task Scheduler 全面自動化
  • 讓 Claude 看影片:10 分鐘跑起來實戰教學

    讓 Claude 看影片:10 分鐘跑起來實戰教學

    📌 本文重點

    • claude-video 把影片轉成可問答知識庫
    • 下載影片、抽幀、語音轉文字全自動
    • 多模態上下文交給 Claude 做各種分析
    • 10 分鐘跑起來,適合教學、課程、demo、監控

    一句話定位:claude-video 讓 Claude 真的「看見」影片,從下載、抽幀、語音轉文字到多模態分析,全包成一個指令搞定。

    GitHub 專案連結:https://github.com/bradautomates/claude-video


    核心功能:一個指令,讓影片變成可問答的知識庫

    claude-video 的核心做的只有一件事:把「影片」轉成 Claude 能理解的多模態上下文。實際拆開來有 3 個關鍵步驟,每一個你都能拿來做自動化。

    💡 關鍵: 透過影格+逐字稿+影片資訊的打包,任何影片都能變成可搜尋、可摘要、可問答的結構化知識來源。

    1. 自動下載影片 + 抽幀

    你只要給一個網址(目前主要是 YouTube),工具會:

    • 下載原始影片檔
    • 依照設定好的間隔抽出代表性的影格(frames)
    • 這些影格會作為「圖片上下文」送給 Claude

    能做什麼:

    • 只看技術教學影片的關鍵畫面(程式碼、投影片、操作步驟)
    • 分析產品 demo 畫面上的 UI 元素、錯誤提示、流程

    行動建議:

    • 想節省時間,把你常看的教學頻道某一支影片的 YouTube 連結先存起來,待會在「怎麼開始」小節直接拿來測試。

    2. 語音轉文字,變成完整逐字稿

    工具會對影片做語音轉文字,把講者說的內容轉成文字,和影格一起送給 Claude。

    常見效果:

    • 自動生成逐字稿(含時間點)
    • 把講者的講解內容和畫面對應起來,更容易做重點歸納

    行動建議:

    • 準備一支你想要「變成文字教材」的影片,比如線上課程、內訓錄影,後面你可以直接用它跑出教學大綱和筆記。

    3. 打包成多模態上下文交給 Claude

    最後,工具會把:

    • 抽出來的影格(圖片)
    • 語音轉文字的逐字稿
    • 影片的基礎資訊(標題、描述等)

    全部打包成一個多模態 prompt,交給 Claude 分析。你可以自訂要 Claude 做什麼:摘要、生成教學、抓重點、產生 QA 題庫等。

    行動建議:

    • 先想好你最常對影片做的「重複動作」,例如:
    • 幫我整理重點
    • 幫我寫 SOP
    • 幫我做中文摘要

    稍後你可以把這段常用指令寫進腳本裡,變成一個固定 workflow。


    適合誰用:4 個實際場景示範

    情境 1:YouTube 教學影片秒變重點筆記

    場景:你常看 Python / 前端 / 設計 / No-Code 教學影片,但看完就忘。

    用法示例:

    • 把影片連結丟給 claude-video
    • 設定 Claude 指令:
    • 濃縮成 10 條重點
    • 列出關鍵程式碼片段
    • 把操作步驟寫成 checklist

    結果:你得到一份可以直接放進筆記軟體的整理稿,比自己邊看邊記快很多。

    實際行動:

    • 找一支你最近收藏但還沒看的教學影片,稍後用它做第一次測試,順便讓工具幫你「看完」。

    情境 2:線上課程變成可搜尋的知識庫

    場景:公司或個人買了一整套線上課程,內容很多但不容易查找。

    用法示例:

    • 把每一堂課的影片都用 claude-video 跑一次
    • 要 Claude:
    • 將每支影片整理成「課程筆記 + 關鍵字標籤」
    • 產出 5–10 個 QA 題目,當作測驗

    結果:你可以把整理好的文字放到 Notion / Obsidian / 任意知識庫裡,之後用關鍵字就能查到課程中的重點片段。

    💡 關鍵: 只要每支課程影片都跑過一次,整套課程立刻升級成可搜尋、可測驗的知識庫,大幅降低複習與查找成本。

    實際行動:

    • 選 1–2 支課程影片做試驗,先建立最小可用的「課程知識庫」,再看要不要自動化整套課程。

    情境 3:產品 demo 影片自動轉成文件說明

    場景:團隊常錄 demo 影片給客戶、內部成員,但文件補不上。

    用法示例:

    • 用 claude-video 處理 demo 錄影
    • 指定 Claude 任務:
    • 把操作流程寫成逐步教學文件
    • 把畫面上的按鈕、表單欄位整理成功能說明
    • 生成「常見問題」和解答

    結果:每一支 demo 可以在幾分鐘內變成:使用說明、FAQ、給新人的入門文件。

    實際行動:

    • 把你最近一次 demo 錄影拿來跑,看看產出的文件是否已經可以直接發給客戶或新同事。

    情境 4:監控 / 內訓影片做檢索與稽核

    場景:公司有大量監控影片或內部訓練錄影,想快速查某一段內容是否出現。

    用法示例:

    • 用 claude-video 跑監控或內訓影片
    • 詢問 Claude:
    • 某時間段內是否有特定事件(例如:某動作、某流程有沒有照 SOP 做)
    • 把違反規範的段落列出,附時間碼

    結果:你得到可以檢索的文字紀錄與標註,比逐段人工看影片省時間。

    實際行動:

    • 先選一支 5–10 分鐘的內訓影片,測試「違規行為摘要」或「流程是否照 SOP」的任務。

    怎麼開始:10 分鐘跑起來教學

    下面是最短路徑:從零到跑出第一個影片分析結果,大致 10 分鐘內可完成。

    步驟 1:環境準備與 clone 專案

    需求:

    • Python 3.10+(建議)
    • 一個終端機環境(macOS / Linux / Windows 都可)

    指令:

    # 1. 下載專案
    git clone https://github.com/bradautomates/claude-video.git
    cd claude-video
    
    # 2. 建議建立虛擬環境
    python -m venv .venv
    source .venv/bin/activate  # Windows 用 .venv\Scripts\activate
    
    # 3. 安裝依賴
    pip install -r requirements.txt
    

    行動建議:

    • 如果你常跑 Python 專案,建議專門開一個資料夾放各種 AI 工具腳本,claude-video 也一起放進去,日後好維護。

    步驟 2:設定 Claude API Key

    你需要一組 Anthropic Claude 的 API Key(可到官方註冊後取得):

    設定方式通常是:

    export ANTHROPIC_API_KEY="你的_API_Key"
    # 或在 Windows PowerShell:
    setx ANTHROPIC_API_KEY "你的_API_Key"
    

    有些版本會使用 .env 檔,你可以在專案根目錄建立:

    ANTHROPIC_API_KEY=你的_API_Key
    

    行動建議:

    • 先確認你目前的方案是否有多模態權限(支援圖片 + 文字),不然影片影格送進去會失敗或被降級成文字模式。

    步驟 3:跑第一個影片分析任務

    以 YouTube 影片為例,專案通常提供類似 /watch 的指令或腳本(具體以 repo 當前 README 為準)。假設有一個 CLI:

    python watch.py "https://www.youtube.com/watch?v=你的影片ID"
    

    這一步會:

    1. 下載影片
    2. 抽幀與語音轉文字
    3. 把結果送進 Claude,依照預設 prompt 報告分析結果

    輸出可能是:

    • 一段純文字摘要
    • 搭配時間碼的段落整理
    • 對影片內容的 QA 回答

    行動建議:

    • 用你一開始準備的「教學影片」做第一次測試,觀察 Claude 對畫面與講解內容是否理解到位。

    步驟 4:改成你自己的 workflow 步驟

    跑成功一次之後,接下來就看你想把它接到哪個流程裡。以下給一個常見範例:接到影片連結就自動生成「中文摘要+切片提綱」。

    你可以:

    1. 修改專案裡的 prompt 或新增一個配置檔,例如 prompts/summary_zh.txt:
      “`text
      你是一位教學內容整理助理。
      請根據提供的影片影格與逐字稿,輸出:
    2. 以繁體中文撰寫 300–500 字摘要
    3. 列出 8–12 個重點段落,每段附上時間碼
    4. 對每個重點段落寫 1 句適合當剪輯標題的文案
      “`
    5. 在主程式中改成讀這個 prompt,並將輸出寫入檔案:
      bash
      python watch.py "https://www.youtube.com/watch?v=影片ID" \
      --prompt prompts/summary_zh.txt \
      --output output/影片ID_summary.md
    6. 再往前接:
    7. 用表單或簡單網頁,讓同事貼影片連結
    8. 後端直接呼叫這個腳本
    9. 完成後把 Markdown 檔推到 Notion、Git repo 或寄信通知

    行動建議:

    • 先把「中文摘要+切片提綱」這種需求寫成一個固定 prompt,試跑幾支影片調整語氣與格式,穩定後再接到你的自動化流程裡。

    小結

    claude-video 做的事情很直接:讓 Claude 真正能看懂影片,而不只是看標題和描述。

    只要你願意花 10 分鐘:

    • clone 專案
    • 寫好 API Key
    • 跑一支 YouTube 教學影片

    你就能把「看影片、整理重點」這件事交給 Claude 處理,自己只負責看整理好的結果。接下來要擴展到線上課程、產品 demo、監控影片,都只是在同一套流程上微調 prompt 而已。

    🚀 你現在可以做的事

    • 打開終端機,依照教學 clone claude-video 並設定好 ANTHROPIC_API_KEY
    • 找一支你常看的 YouTube 教學影片,實際跑一次 python watch.py "影片連結" 看結果
    • 建立一個 prompts/summary_zh.txt,把你想要的「中文摘要+重點」格式寫進去,開始打造自己的影片整理 workflow
  • Claude Science:科研人專用 AI 瑞士刀

    Claude Science:科研人專用 AI 瑞士刀

    📌 本文重點

    • Claude Science 把科研全流程集中到一個 AI 工作桌
    • 內建 60+ 科學技能與驗證 agent 降低低級失誤
    • 可與本地/HPC 整合,適合處理敏感數據的研究者

    Claude Science 就是「把你原本散落在 Excel、終端機、文獻庫和繪圖工具裡的工作,一口氣塞進同一個 AI 桌面」的研究專用工作臺。

    官方介紹頁面在這裡:https://www.anthropic.com/news/claude-science-ai-workbench(需付費 Claude 帳號才能使用)


    核心功能:把「會出錯的地方」交給 AI 接手


    1. 預設 60+ 科學技能:直接點選就能開工

    Claude Science 不是一個「空白聊天框」,而是一個已經幫你預裝好多個專業助理的工作區。

    根據 Anthropic 對外說明(見 The Decoder 報導),目前內建 60+ 預配置技能,涵蓋:

    • 基因組學:變異註解、差異表現分析結果解讀
    • 計算化學 / 藥物設計:分子性質預測、對接結果摘要
    • 統計與數據分析:實驗設計、統計檢定建議、結果可視化
    • 文獻相關任務:系統性搜尋策略、摘要、引用格式整理

    💡 關鍵: 內建超過 60 種科研技能,讓常見分析工作可以直接點選呼叫而非從零開始設定。

    你可以這樣用:

    1. 建立一個專案 workspace(例如 RNA-seq_2026)。
    2. 從左側 skill 清單中選 Genomics analysis 或類似技能。
    3. 上傳 CSV/TSV(表達量矩陣、變異列表),直接用自然語言下指令:
    4. 「請用 DESeq2 的邏輯幫我看有沒有明顯差異表現基因,並畫出 2 張關鍵圖。」
    5. Claude 會自動呼叫對應工具,在 workspace 內產生分析腳本、輸出圖表與解讀文字。

    行動建議:先挑 1 個你最常做、最重複的分析(例如「畫火山圖」「整理變異註解」),在 Claude Science 建一個 workspace,試著完全用內建技能走一遍流程。


    2. 驗證 agent:幫你檢查公式與引用,不再心驚膽跳

    研究工作中最容易「低級失誤」的兩塊:

    • 欠查一次就會寫錯的計算(p 值、樣本量、轉換單位)
    • 抄來抄去會亂掉的引用與編號

    Claude Science 針對這一點,加入了專門的 verification agent(驗證代理),會在背景幫你:

    • 重新計算文中的公式與統計數字是否一致
    • 檢查引用是否真有其文、年份/作者是否對得上
    • 標記看起來不合理的值,要求你確認

    💡 關鍵: verification agent 相當於自動化的第二校對者,專門檢查數值與引用,降低論文中「低級錯誤」的風險。

    你可以這樣用:

    1. 把你正在寫的論文方法+結果段落貼進 Claude Science。
    2. 下指令:
    3. 「請啟用 verification,檢查所有數值、公式與引用,列出有問題的地方。」
    4. Claude 會回傳一張「疑似錯誤清單」,例如:
    5. 表 2 的樣本數加總與文中 n 不一致
    6. 引用 [15] 的作者和年份與 PubMed 上不符
    7. 你逐項確認修正,再請它重新產出一版「已校正」的段落。

    行動建議:找一篇你已發表或即將投稿的手稿,把最容易出錯的「結果」+「參考文獻」丟進去,感受一次 verification agent 能抓出多少你自己沒注意的細節。


    3. 與本地 / HPC 整合:敏感數據不用丟到雲端

    根據 The Decoder 與 TechCrunch 的報導,Claude Science 的設計重點之一,是可以部署在你自己的基礎設施:

    • 在實驗室伺服器或私有雲上跑 Claude Science workspace
    • 連接現有的 HPC cluster、排程系統與檔案儲存(例如 Slurm + NFS)
    • 敏感基因資料、病人資料不離開內網,由本地工具完成重運算,Claude 只負責協調工作流程與解讀結果

    工作方式有點像「本地算、Claude 指揮」:

    1. 你在 Claude Science 下指令:「針對這批樣本跑全基因組關聯分析。」
    2. Claude 自動組合腳本與 pipeline,提交到你的 HPC queue。
    3. 跑完後再拉回結果(log、summary、圖表),在介面裡幫你整理成易讀報告。

    行動建議:如果你所在機構有 IT/科研計算團隊,先確認:

    • 機構是否允許部屬第三方 AI 服務到內網
    • 既有的 HPC(例如 Slurm、LSF)能否提供 API / 指令介面
    • 再把 Anthropic 的官方技術文件丟給 IT 評估可行性

    適合誰用:3 類典型科研 workflow 範例


    1. 文獻閱讀與摘要:從海量 PDF 到可以直接用的「相關工作」段落

    典型痛點:文獻太多、摘要太花時間、填 related work 又怕漏東漏西。

    在 Claude Science 的做法:

    1. 建一個專案 CAR-T_solid_tumor_review。
    2. 批量上傳你下載的 PDF(可壓成 zip 丟上去)。
    3. 下指令:
    4. 「請針對 2019 之後的臨床試驗,整理一份表格:包含試驗編號、標的、入組人數、主要終點。」
    5. 「再幫我寫一段 800 字的 related work,分成『成功案例』『失敗原因』。」
    6. 啟用 verification,請它檢查每個試驗資料是否與原文一致,並附上引用標記。

    你得到的成果可以直接變成:

    • 初稿表格(貼到 Word/Overleaf)
    • 初版 related work 段落,後續再手動補充與潤飾

    2. 從 CSV / 實驗結果到圖表與方法段落

    這是最多人希望「直接自動化」的一個流程。以一個小型轉錄體學實驗為例:

    1. 在 Claude Science 建 workspace DrugX_RNAseq。
    2. 上傳:
    3. counts_matrix.csv
    4. metadata.csv(樣本組別、批次)
    5. 指令(高階就好):
    6. 「請用 DESeq2 的概念幫我完成差異表達分析,產出:
      1. QC 圖(PCA + sample distance heatmap)
      2. Volcano plot + Top 20 up/down 基因表
      3. 一段 400 字的方法描述,格式接近論文,可貼到 Methods。」
    7. Claude 會:
    8. 自動生成 R 腳本,在本地/HPC 執行(若已整合)
    9. 收集輸出圖檔,插在回覆裡或放到 workspace 檔案區
    10. 根據實際參數(過濾閾值、標準化方法)撰寫方法段落
    11. 啟用 verification,要求:
    12. 「請確認方法描述中的參數與實際使用的 R 腳本一致。」

    你可以直接把:

    • 圖表 → 存成 PNG/SVG,貼入報告或論文
    • 方法段落 → 小修措辭後貼進 manuscript

    3. 設計實驗與寫論文草稿

    以藥物開發為例,MIT Tech Review 報導 指出 Anthropic 自己也用 Claude Science 來研究罕見疾病用藥。你可以類似這樣使用:

    1. 輸入疾病背景、已知靶點、預算與時間限制。
    2. 請 Claude 提出 2–3 套「可實際落地」的實驗設計路線(包含體外、動物實驗)。
    3. 選定其中一條,要求它:
    4. 列出實驗所需試劑與關鍵設備
    5. 預估樣本數並計算統計 power(交給 verification 檢查)
    6. 先寫一版 preprint 草稿的大綱與部分引言

    你得到的是「足夠完整的方案草稿」,可以拿去與 PI 或團隊討論,大幅縮短從 idea 到可行實驗設計的時間。


    Claude Science vs 一般 ChatGPT / Claude:差在哪?

    如果你現在已經在用 ChatGPT 或 Claude 來輔助科研,可以用下表來對照:

    工具名稱 核心功能重點 免費方案 適合誰
    一般 ChatGPT / Claude 純對話式助理,擅長解釋概念、改寫文字、簡單程式碼 有 學生、自學者、早期構思與文稿潤飾
    Claude Science 研究專用工作臺,整合技能、驗證 agent、本地/HPC 工具 無(需付費 Claude 帳號) 有穩定專案、需要嚴謹流程與數據保護的研究人員

    關鍵差異不在「模型本身」,而是:

    • 有沒有固定的 workspace,讓你把同一專案的資料、圖表、腳本放在一起管理
    • 有沒有 verification agent 幫你做第二層檢查
    • 能不能跟你實驗室的 HPC 和內部資料庫直接串在一起跑

    如果你只是:

    • 偶爾問問問題、改寫 email、寫作業 → 一般 ChatGPT / Claude 就夠

    如果你是:

    • 長期跑同一條 data pipeline、要處理敏感資料、要寫嚴謹的論文或申請書 → 才值得把 Claude Science 納入日常研究管線

    💡 關鍵: 一般聊天模型適合零散、輕量任務,Claude Science 則針對長期專案與嚴謹科研流程做了完整工作臺與驗證機制設計。


    怎麼開始:從註冊到導入自己數據


    1. 誰可以用?

    根據公開資訊(MIT Tech Review & The Verge 報導),Claude Science:

    • 對 所有付費 Claude 用戶 開放(需位於支援地區)
    • 適合:實驗室 PI、博士後、研究助理、產業研發人員
    • 不適合:只偶爾需要 AI 幫忙寫作、對 HPC 串接完全沒有需求的人

    2. 上手流程(概略版)

    1. 準備帳號與權限
    2. 申請付費 Claude 帳號:https://claude.ai
    3. 若要與機構 HPC / 內網資料庫整合,先找 IT 問是否能配合(可能需要企業方案)。

    4. 建立第一個 workspace

    5. 進入 Claude Science 入口(通常在 Claude Web 介面或管理後台可見專用入口)。
    6. 建立新 workspace,命名為某個具體專案(例如 Liver_fibrosis_singlecell)。

    7. 導入你的數據與工具

    8. 上傳:CSV、TSV、Excel、PDF 論文、先前的分析 script。
    9. 若已連接 HPC:設定資料夾路徑與計算 queue(可請 IT 協助)。
    10. 在 workspace 中先跑一個「小實驗」:

      • 「從這個 CSV 產生描述性統計與 3 種圖,並寫 200 字結果段落。」
    11. 把它嵌進日常研究節奏

    12. 專案一開始:用 Claude Science 幫你整理文獻與設計實驗。
    13. 中後期:固定用它來跑標準 data pipeline + 生成圖表。
    14. 收尾:把所有結果+方法段落集中在 workspace 裡,請它幫你「組裝」論文初稿。

    行動建議:

    • 先挑一個「風險低、但步驟多」的小專案(例如 lab meeting 報告),完全用 Claude Science 做一次,看看哪些步驟可以固定成模板。
    • 若覺得合用,再考慮跟 IT/PI 討論,把整個實驗室的標準分析 pipeline 搬進 Claude Science,讓新進成員直接使用同一套 AI 工作桌。

    如果你現在已經感受到:在文獻、分析、寫作之間切換很耗腦,但每件事又都有固定套路,那 Claude Science 就是值得你嘗試的一把 AI 瑞士刀——把這些套路交給它,你專心在「決策」與「創新」上就好。

    🚀 你現在可以做的事

    • 到 Claude 官方頁面確認自己帳號是否支援 Claude Science,並建立第一個專案 workspace
    • 選一個現有小專案,嘗試用內建技能與 verification agent 完整跑完一次分析與寫作流程
    • 與實驗室 PI 或 IT 團隊討論,評估將現有 HPC pipeline 串接到 Claude Science 的可行性
  • Langflow:用畫流程圖做自己的 AI Agent

    Langflow:用畫流程圖做自己的 AI Agent

    📌 本文重點

    • Langflow 用拖拉節點設計 AI Agent 工作流
    • 支援記憶、工具調用與 Webhook,讓 Agent 真正能做事
    • 30 分鐘內即可做出第一個可用的內部 Bot 或自動化流程
    • 開源、可自行部署,適合技術團隊掌控環境

    一句話先講清楚:Langflow 就是把「寫 Agent 程式」變成「畫流程圖」,讓你用拖拉方塊的方式,搭出自己的 AI 工作流。

    Langflow GitHub 專案連結


    核心功能:用方塊和線組出一個會動的 AI

    1. 節點(Nodes):把複雜任務拆成小方塊

    在 Langflow 裡,你看到的是一塊畫布,左邊是各種「節點」,右邊是你畫好的流程圖。

    常用節點類型:

    • LLM 節點:呼叫大語言模型(例如 OpenAI、Anthropic、Ollama 等)
    • Prompt 節點:管理提示詞模板,支援變數(如 {{question}})
    • Memory 節點:儲存上下文,例如聊天紀錄或任務狀態
    • Tool / API 節點:呼叫外部服務,像 HTTP Request、Webhook

    你可以做的動作:

    • 打開 Langflow,先拖一個 Chat Model 節點 到畫布上
    • 再拖一個 Prompt 節點,將使用者輸入包裝成模型指令
    • 把 Prompt 的輸出線接到 Chat Model 的輸入,就完成最基本的「問答 bot」骨架

    💡 關鍵: 把任務拆成節點後,你可以像搭積木一樣重組、調整工作流,而不必重寫整段程式。

    2. 連線(Edges):定義資料怎麼流動

    每個節點都有輸入/輸出接口,透過連線把它們接起來,就形成一個 Agent 工作流。

    常見連線方式:

    • 使用者輸入 → Prompt 節點 → LLM 節點 → 回傳結果
    • 文件載入節點 → 向量資料庫節點(檢索)→ LLM 節點(基於文件回答)
    • Webhook 節點 → LLM 節點 → 再呼叫另一個 API 節點回寫結果

    你可以做的動作:

    • 在畫布上嘗試把「使用者輸入」節點接到兩個不同的 Prompt 節點,再接到兩個 LLM 節點,做 A/B 測試不同指令效果

    3. 記憶(Memory):讓 Agent 不只回一題就忘記

    如果只接一個 LLM 節點,你得到的是單輪對話。要做「會記得之前說過什麼」的 Agent,就要加上 Memory 節點。

    在 Langflow 裡常見記憶用法:

    • 把歷史對話存入記憶,讓下一輪 LLM 接收到完整上下文
    • 在流程中保存一些關鍵變數(例如工單號碼、用戶角色),下游節點可以讀取

    你可以做的動作:

    • 新增一個 Conversation Memory 節點,接在「使用者輸入」和「LLM」中間
    • 測試多輪提問,同一個 Agent 能接續前面的內容

    4. 工具調用與 Webhook:讓 Agent 真的「能做事」

    Langflow 不只是聊天,它可以讓 LLM 透過節點呼叫各種工具:

    • HTTP Request / Webhook 節點:連到你的 CRM、工單系統、Google Sheets 或任意 REST API
    • 資料處理節點:對 JSON、文字做轉換,讓輸入輸出更乾淨

    你可以做的動作:

    • 在畫布上加一個 HTTP 節點,設定你公司內部 API URL
    • 讓 LLM 的輸出(例如「請查詢這個訂單狀態:#12345」)轉成 API 查詢,再把結果回傳給使用者

    適合誰用:三個實戰場景

    場景 1:客服自動回覆流程(半自動客服)

    目標:讓客服人員不用自己寫回覆,改成「點選建議」或讓 Agent 先草擬。

    基本流程可以這樣畫:

    1. 使用者訊息輸入節點(接 Web / 聊天介面)
    2. 記憶節點:保存同一位客戶的歷史對話
    3. FAQ 文件載入 + 向量資料庫節點:把常見問題和答案餵給系統
    4. LLM 節點:基於 FAQ 檢索結果產生回覆草稿
    5. Webhook / 前端節點:把草稿送到客服後台,讓人類按「同意 / 修改 / 拒絕」

    你可以採取的行動(30 分鐘內可完成雛形):

    • 匯入一份公司 FAQ PDF 或 Markdown
    • 建一個簡單的「文件檢索 + LLM 回覆」流程
    • 先在 Langflow 介面測試問答,確認準確率,再決定要不要跟正式客服系統串接

    💡 關鍵: 只要一份 FAQ 和一個基本檢索流程,半自動客服雛形在 30 分鐘內就能跑起來。

    場景 2:文件問答 Bot(內部知識庫助理)

    這是最多人用 Langflow 起手式:做一個「問公司內部文件」的 Bot。

    流程示意:

    1. File Loader 節點:載入 PDF、DOCX 或 Markdown
    2. Text Splitter 節點:把長文件切成小片段
    3. Embedding + Vector Store 節點:建立向量索引,支援語意搜尋
    4. Query 節點:根據提問在向量庫中檢索相關片段
    5. LLM 節點:拿檢索到的內容,組合成清楚答案

    你可以採取的行動:

    • 先用幾份內部文件(例如員工手冊、產品說明)做一個小型知識庫
    • 在 Langflow 介面用「如果我請假怎麼申請?」這類問題測試
    • 看輸出是否有文件來源,確認 Agent 沒亂掰(可在 Prompt 裡要求標註來源)

    場景 3:簡單內部自動化任務(通知 / 報表 / 小流程)

    你不一定要做複雜 Agent,很多公司會先從「AI + 小自動化」開始:

    可能流程:

    1. 定時觸發(或外部 Webhook)節點:例如每天早上 9 點跑一次
    2. API 節點:從系統拉出昨日訂單或工單資料
    3. LLM 節點:請模型整理成「今日重點三點」或「需要注意的異常」
    4. Webhook / Email 節點:把結果發到 Slack / Teams / Email

    你可以採取的行動:

    • 選一個你每天手動整理的報表,先用 Langflow 做一個「拉資料 → LLM 整理 → 發通知」的簡化版
    • 先用測試環境 API,確認沒有誤發給正式頻道,再上線

    怎麼開始:從安裝到第一個 Agent

    1. 部署方式:本機 vs 雲端

    Langflow 是開源專案(Python),你有兩種常見用法:

    • 本機部署:適合開發者、內網環境
    • 需要:Python 環境、基本命令列操作
    • 在本機跑,方便串內部服務,不用把資料丟到外部 SaaS

    • 雲端部署:適合團隊協作、多人共用

    • 可用 Docker 或自行丟到雲端 VM
    • 好處:同事可以一起進到同一個 Langflow 介面,共用工作流模板

    你可以採取的行動:

    • 先在自己電腦用 Docker 跑起 Langflow,熟悉介面
    • 等你有第一個可用流程,再考慮搬到公司雲端或內網伺服器

    2. 快速安裝步驟(以本機為例)

    以最常見的方式示意(實際請以官方 README 為準):

    # 建議用虛擬環境或 Docker,這裡以 pip 為例
    pip install langflow
    
    # 安裝完成後啟動服務
    langflow run
    
    # 預設會在 http://localhost:7860 開一個 Web 介面
    

    你可以採取的行動:

    • 安裝後打開瀏覽器進入 http://localhost:7860
    • 新建一個 Flow,拖一個 Chat Model 節點,接一個 Prompt 節點,測試一輪聊天

    3. 接不同 LLM:商用 API 和本地模型

    Langflow 支援多種模型來源:

    • 商用 API:
    • OpenAI、Anthropic 等,只要在設定中填上 API Key
    • 適合需要好的語言品質,又不介意雲端的情境

    • 本地模型:

    • 可透過像 Ollama 之類的本地推論服務來接
    • 適合零信任、不能把程式碼或資料送出公司網路的團隊

    你可以採取的行動:

    • 先在 Langflow 裡設好一組「雲端模型」作為開發時使用
    • 如果公司有安全需求,再加一組「指向 Ollama / 本地推論」的 LLM 節點,測試兩種效果差異

    4. 串第三方服務:Webhook / API 節點配置

    要讓 Agent 動起來,最重要是「能跟外部世界互動」。在 Langflow 裡,你通常會:

    1. 新增一個 HTTP / Webhook 節點
    2. 設定 URL、HTTP 方法(GET / POST)、Headers 和 Body 模板
    3. 把 LLM 節點的輸出接到這個 HTTP 節點,讓模型決定要送什麼資料

    你可以採取的行動:

    • 先串一個你熟悉的服務(例如測試用的 webhook.site 或公司內的 sandbox API)
    • 用很簡單的 payload(例如只送一行文字),確認連線和驗證沒問題

    範例與社群模板:照著做就有第一個 Agent

    Langflow 社群已經累積不少現成 Flow,可以直接匯入再改。

    常見範例類型:

    • FAQ 問答 Bot:已經幫你設好「文件載入 → 檢索 → LLM 回覆」
    • Email 助理:模型幫你改寫、翻譯、整理郵件內容
    • 簡易客訴處理 Agent:先分類情緒,再產出回覆草稿

    你可以採取的行動:

    • 在 Langflow 社群或 GitHub issue / discussions 中搜尋 templates、examples
    • 選一個 Flow 匯入,改掉其中的 API Key、文件路徑,就變成你自己的版本

    延伸:跟其他 Agent 工具的差異

    市面上也有不少 Agent / 工作流工具,若你同時在看其它方案,可以用下面的表格快速比較定位:

    名稱 核心功能 免費方案 適合誰
    Langflow 視覺化設計 AI Agent 工作流,支援 LLM、記憶、工具調用 開源,自行部署 想自己畫流程、控管部署環境的開發者與技術團隊
    LangGraph 用程式碼定義 Agent 圖結構與狀態機,偏工程師導向 開源 Python 套件 喜歡用程式精細控制 Agent 狀態的後端工程師
    Graphify 把程式碼與文件變成知識圖譜,配合 AI 助理檢索 開源,自行部署 想整理程式碼資產、做跨檔案查詢的開發者

    如果你想要「看得見的流程圖 + 自己部署」,Langflow 是目前上手成本相對低的一條路:從拖第一個節點到完成一個能用的 Agent,控制在 30 分鐘內完全合理。

    💡 關鍵: 視覺化流程加開源部署,讓技術團隊既能快速試錯,又能保有環境與資料的掌控權。


    結論很簡單:先用 Langflow 畫出一個最小可行的 AI 工作流,把你手上最煩的一件重複工作丟給它。等你真正看到 Agent 每天幫你省下的時間,再來慢慢加節點、加工具,把流程做厚,這樣學習成本最低、成效也最明顯。

    🚀 你現在可以做的事

    • 用 pip install langflow 或 Docker 在本機跑起 Langflow,打開 http://localhost:7860 熟悉介面
    • 匯入一份公司 FAQ 或內部文件,照文中的「文件檢索 + LLM 回覆」流程畫出第一個 Bot
    • 在 Langflow 社群 / GitHub 上搜尋並匯入一個現成 Flow 範例,改成符合你公司 API 和文件路徑的版本
  • Plurality:在家自架你的 AI 中控台

    Plurality:在家自架你的 AI 中控台

    📌 本文重點

    • Plurality 是本地可自架的 AI 中控台
    • 同一介面整合聊天、腳本自動化與多代理協作
    • 透過沙盒與 MCP 打造安全可控的 AI Runbook 系統

    一句話定位:Plurality 是一個裝在你自己電腦或局域網裡的 AI 中控台,用同一個介面處理聊天、腳本自動化和多代理協作,而且完全開源、可本地部署。

    專案連結:https://github.com/azukaar/plurality (建議邊看文邊打開)


    核心功能:把「聊天 + 自動化 + 安全執行」塞進一個面板

    1. 一個介面同時管「聊天」和「背景自動化」

    Plurality 的定位很像「你自己架的 Slack + Jira + Runbook 執行器」,但全部交給 AI 來動。

    你可以在同一個 Web 介面裡:

    • 和 AI 助理聊天
    • 建立長期存在的 Agent(例如「專案助手」「報表助手」)
    • 為每個 Agent 配好自動化流程(Automation Flow),讓它在背景持續跑

    你可以這樣用:

    • 先在 Plurality 裡創一個「專案助理」Agent
    • 在聊天裡下達指令:「幫我建立一個每日 build 檢查流程」
    • 再把這段需求轉成 automation flow:每天定時跑腳本、整理結果、回報到同一個對話 Thread

    實際效果:你不再需要切來切去——一樣是在「跟 AI 聊天」,但對話可以變成「可重複、自動執行的任務」。

    💡 關鍵: 將常用對話轉成 automation flow,可把「會話」變成每天自動跑的固定任務,減少大量手動重複操作。

    行動建議:想像一下你現在最常對 ChatGPT 說的其中一件事(例如「整理日報」「幫我跑某個腳本」),這會是你在 Plurality 裡第一個要做成 Automation 的任務。


    2. 安全的 CLI + 檔案系統沙盒

    Plurality 支援讓代理在「沙盒環境」裡跑 CLI 命令、操作檔案,但重點是:

    • 可控制範圍:你可以只把某個專案資料夾掛載給該 Agent
    • 可審核:代理要執行敏感命令前,可以設成需要你點擊確認
    • 可記錄:所有命令和檔案操作都在介面裡看得到 log

    這意味著:

    • 開發者可以讓 Agent 幫忙跑測試、打包、整理 log
    • 知識工作者可以讓 Agent 在限定資料夾裡整理檔案、產出報告
    • 家用伺服器使用者可以讓 Agent 只碰 backup 資料夾,不碰其他東西

    你可以這樣設定:

    1. 在 Plurality 的設定中,新增一個「Project」或「Workspace」
    2. 把 /home/你/某個專案 或 NAS 的某個共享資料夾掛載給這個 Workspace
    3. 建立 Agent 並指定它只能使用這個 Workspace
    4. 開啟「命令前需要確認」(如果你怕它亂改東西)

    行動建議:先選一個「就算搞壞也不會心痛」的資料夾,當作 Agent 測試用沙盒,把 CLI 操作和檔案操作都限制在這裡。


    3. 搭配 MCP、多代理協作,變成你的「個人 Jira + Runbook 執行器」

    Plurality 支援 MCP(Model Context Protocol)等多代理協作生態,你可以把它當成一個統一入口,接上:

    • 不同工具的 MCP 伺服器(例如資料庫查詢、Issue 管理、監控系統)
    • 多個 Agent 各自負責不同任務

    用白話來說:

    • 「像 Jira 一樣」:你可以把每個自動化流程當成一個 Ticket / 任務
    • 「像 Runbook 一樣」:每個任務裡,是具體的步驟(腳本、API調用、檔案處理)
    • Plurality 的 Agent 負責:讀任務 → 選工具 → 執行 → 回報結果

    實際用法例子:

    • 一個「監控 Agent」:定時讀監控 API → 判斷是否異常 → 若異常就呼叫「Runbook Agent」
    • 「Runbook Agent」:按你寫好的流程,連線伺服器、跑腳本、紀錄在一個對話 Thread 裡

    行動建議:先想一個你現在「寫在 Notion / Wiki 的 Runbook」,例如「網站掛掉怎麼檢查」,把它拆成步驟,交給 Plurality Agent 來執行一次看看。


    適合誰用?三個具體場景

    1. 開發者:用 Plurality 管專案腳本

    適合這樣的人:

    • 手上有一堆 npm script / Makefile / shell script
    • 常常要:跑測試、打包、部署、整理 log

    實際流程可以長這樣:

    • 在 Plurality 裡建立一個「專案 Dev Agent」
    • 掛載你的專案資料夾(例如 /projects/my-app)
    • 讓 Agent:
    • 用 CLI 跑 npm test,把錯誤訊息整理貼回聊天
    • 根據你的指示修改設定檔或產出新腳本(在沙盒裡)
    • 定時跑 lint + test 並生成報告

    你每天要做的事情,就變成:開 Plurality → 問「今天 CI 有沒有紅?」→ 讓 Agent 調出 log 給你看。

    💡 關鍵: 讓 Agent 接管 npm test、lint 等例行腳本,可把日常 CI/開發檢查集中在單一對話介面完成。


    2. 知識工作者:整理檔案 + 做定時報告

    適合這樣的人:

    • 每週要交固定報告(營運簡報、數據摘要、內容整理)
    • 桌面 / NAS 上堆滿 PDF、Word、報表 CSV

    你可以這樣設計一個 Agent:

    • 掛載「報表資料夾」給它(例如 Reports/Weekly)
    • 每天或每週固定時間:
    • 掃描新檔案
    • 自動分類命名(根據檔名、內容)
    • 生成一份文字摘要(例如本週營運重點、會議紀錄整理)
    • 寄出 Email 或貼到公司內網

    整套流程變成:你只要把資料丟進資料夾,其它交給 Plurality。


    3. 自架家用伺服器:備份 + 監控

    如果你有自己的 NAS 或家用伺服器(例如和 Livinity 這種 homeserver OS 類似的架構),Plurality 很適合當成「AI 管家」。

    可以做的事情:

    • 每天半夜:
    • 檢查共享資料夾是否有新檔
    • 壓縮後備份到另一顆硬碟或雲端
    • 寫 log + 總結備份結果
    • 每小時:
    • 跑監控腳本(例如檢查 Docker 容器、硬碟空間)
    • 若異常,透過 Email / Telegram 通知你

    這些都可以用 Plurality 的 automation flow + CLI 沙盒來完成,而且所有設定都留在你自己的網路裡。

    💡 關鍵: 把備份與監控自動化放進局域網,能在不依賴外部服務的前提下,建立可審計又可控的「AI 管家」流程。


    15 分鐘入門:從 clone 到第一個 Automation Flow

    下面用一個具體目標來帶你:每天抓 RSS → 總結 → 寄信。

    步驟 0:準備環境(2 分鐘)

    需求:

    • 一台可以跑 Docker 的機器(你的電腦、NAS 或家用伺服器)
    • 至少一個可用的模型:
    • 本地:Ollama / LM Studio / 其他本地 LLM 伺服器
    • 雲端:OpenAI / Claude 等(有 API key)

    行動:先確認你有 Docker 和一個模型 API(或已裝好 Ollama)。


    步驟 1:拉 GitHub repo + 啟動(5 分鐘)

    1. 開啟 GitHub 專案:https://github.com/azukaar/plurality
    2. 在你的機器上:
    git clone https://github.com/azukaar/plurality
    cd plurality
    
    1. 使用 Docker(以官方 README 為準,但大致會是):
    docker compose up -d
    
    1. 打開瀏覽器,進入 http://你的機器 IP:PORT(通常 README 會寫預設 port)

    行動:先確認你能看到 Plurality 的 Web 介面,並完成初次設定帳號。


    步驟 2:連上本地或雲端模型(3 分鐘)

    在 Plurality 介面的設定裡(通常是「Models」「LLM Providers」之類):

    • 如果你用本地模型(例如 Ollama):
    • 填入 Ollama 的 URL(例如 http://host.docker.internal:11434)
    • 選一個模型(llama3 等)
    • 如果你用雲端模型:
    • 選 OpenAI / Anthropic 等
    • 貼入 API key

    接著:

    • 建立一個「預設 Agent」
    • 開一個新聊天,隨便問一個問題,確認模型回應正常

    行動:測一次聊天,確定模型接上沒問題,再往下做自動化。


    步驟 3:設定第一個 Automation Flow:RSS → 總結 → 寄信(5 分鐘)

    以概念步驟為主,實際操作依 Plurality 當前 UI 為準(版本更新可能略有差異):

    1. 建立一個 Agent(例如叫 RSS Reporter):
    2. 權限:允許網路請求(抓 RSS)
    3. 若需要寄信,先在設定裡填好 SMTP 或 Webhook(視官方檔案支援的方式)

    4. 建立 Automation Flow:

    5. 觸發條件:每日某個時間(例如 09:00)
    6. 步驟設計(可用自然語言描述給 Agent,再微調):

      1. 抓取指定 RSS(例如科技新聞、公司部落格)
      2. 解析最近 24 小時的新文章
      3. 用模型生成摘要:
        • 列出 3-5 則重點
        • 每則一段話說明「為什麼重要」
      4. 把摘要整理成一封 Email 內容
      5. 呼叫 SMTP/Email 工具寄給你
    7. 測試一次:

    8. 不用等明天,先在介面裡手動 Run 這個 Flow
    9. 檢查 log 和 Email 是否如預期

    行動:先用你最常看的其中一個 RSS 做範例,例如你公司部落格或常看的技術網站。


    小結:把「雜事」搬進你自己的局域網裡

    Plurality 的核心價值在於:

    • 一個介面聚合聊天 + 自動化 + 多代理
    • 可以讓 AI 真正「動手」跑 CLI、操作檔案,但仍在你可控的沙盒裡
    • 搭配 MCP、多代理協作,把原本散在各處的腳本、Runbook 和任務,集中到一個你自己掌控的中控台

    如果你本來就有自架 NAS、家用伺服器,或公司內網伺服器,Plurality 很適合直接變成「AI 操作台」;如果你只是想找個比 ChatGPT 更能「實際做事」的工具,也可以先在自己電腦上跑一個 Plurality,從那個 RSS → 總結 → 寄信的 Flow 開始。

    下一步行動:打開 https://github.com/azukaar/plurality,照本文的 15 分鐘流程做出你的第一個 Automation Flow,之後再慢慢把日常重複工作移進去。

    🚀 你現在可以做的事

    • 打開 Plurality 專案頁,用 git clone 把專案拉到本機或 NAS
    • 準備好一個可用模型(例如設定好 Ollama 或貼入 OpenAI / Claude API key),完成第一次聊天測試
    • 挑一個你每天重複做的流程(如 RSS 摘要、報表整理),在 Plurality 裡實作成第一個 Automation Flow
  • OmniRoute:一個 Endpoint 玩遍 200+ 模型

    OmniRoute:一個 Endpoint 玩遍 200+ 模型

    📌 本文重點

    • OmniRoute 用一個 Endpoint 串接 200+ 模型供應商
    • 內建 RTK + Caveman 壓縮,可節省 15–95% token 成本
    • 支援 MCP / A2A、多代理、多模態 Workflow
    • 適合多模型整合與成本優化的開發者

    用一句話先說清楚:OmniRoute 是一個多雲、多模型的一站式 AI 總機,讓你用同一個 API Endpoint,同時接上 Claude、GPT、Cursor、Copilot 等 200+ 家模型供應商,還順手幫你壓縮 token、自動跳備援模型。

    官方開源庫:https://github.com/diegosouzapw/OmniRoute


    核心功能 1:一個 Endpoint 管理多供應商+自動備援

    傳統做法是:每接一個模型,就要再接一個 SDK / API Key / Base URL。結果是:

    • 前端要切換模型,就得改環境變數
    • 後端要做 fallback,要自己寫 retry + 陣痛的錯誤處理

    OmniRoute 的做法是:所有模型統一走一個 OmniRoute Endpoint,後面怎麼分流、切換供應商、失敗改用誰,全都在 OmniRoute 的設定檔完成。

    💡 關鍵: 把所有模型統一進一個 Endpoint,可以一次解決多家供應商整合與備援問題,前後端只維護單一接點。

    你可以怎麼用

    以「同一個 Code Agent,要能在 Claude / GPT / 本地模型之間切換」為例:

    1. 在 OmniRoute 設定三個 provider:
    2. anthropic/claude-3.5(主力)
    3. openai/gpt-4.1(備援)
    4. local/deepseek(成本最低版)
    5. 設定路由策略:
    6. 主 Endpoint:先走 Claude
    7. 當 Claude timeout 或額度用完,自動 fallback 到 GPT
    8. 夜間批量任務改走本地模型
    9. 在你的程式碼中,只保留一個 OMNIROUTE_API_URL:

    ts
    const response = await fetch(process.env.OMNIROUTE_API_URL, {
    method: "POST",
    headers: {
    "Content-Type": "application/json",
    "Authorization": `Bearer ${process.env.OMNIROUTE_API_KEY}`,
    },
    body: JSON.stringify({
    model: "code-agent", // 這是 OmniRoute 裡定義的邏輯模型名
    messages,
    }),
    });

    可行動建議:

    • 手上的專案如果同時接了 Anthropic + OpenAI + 本地模型,可以先挑一個 API Call 練手,把三個 Base URL 改成一個 OmniRoute URL,測試 auto-fallback 是否生效。

    核心功能 2:RTK + Caveman 壓縮,節省 15–95% token 成本

    OmniRoute 內建兩種壓縮:

    • RTK(Reversible Tokenization Kernel):對常見 prompt 做結構化壓縮,適合長系統提示、多輪聊天歷史
    • Caveman 壓縮:偏「野蠻」但更激進,會重寫聊天記錄,把冗長表述變成精簡語句

    效果:

    • 系統長 prompt:省 15–40% token
    • 帶大量上下文(如文檔 QA):最高可到 95% token 減少

    💡 關鍵: 啟用 RTK 與 Caveman 壓縮後,長上下文任務可大幅降低 15–95% token 成本,直接反映在帳單與模型限額上。

    你可以怎麼用

    以「把整份 API 文檔塞給模型當『長期記憶』」為例:

    1. 在 OmniRoute 後台或設定檔,為 doc-assistant 這條路由開啟壓縮:

    yaml
    routes:
    - id: doc-assistant
    model: anthropic/claude-3.5
    compression:
    rtk: true
    caveman: true

    1. 程式端依然用原本的 messages 結構呼叫,不用自己壓縮:

    jsonc
    {
    "model": "doc-assistant",
    "messages": [
    {"role": "system", "content": "你是某某專案的文檔助手..."},
    {"role": "user", "content": "請根據附件 API 文檔..."}
    ]
    }

    1. OmniRoute 會在轉給底層模型前自動壓縮,再在輸出時解壓(對你來說是透明的)。

    可行動建議:

    • 先挑「最長」的那支 API(例如:聊天歷史超長、帶多篇 PDF 的 QA),在 OmniRoute 上開 RTK+獵人模式(Caveman),觀察一次請求的 token 使用量與帳單變化。

    核心功能 3:MCP / A2A、多代理、多模態 Workflow

    OmniRoute 支援:

    • MCP(Model Context Protocol):讓不同工具 / 代理共享同一套上下文與工具列表
    • A2A(Agent-to-Agent):代理之間可互相呼叫,形成多步驟協作
    • 多模態 API:文字 + 圖片(甚至影音)混合輸入

    這讓你可以把原本散落在不同工具的能力,集中到一條 Workflow 裡。例如:

    • Code Agent 負責寫程式
    • Doc Agent 負責查文件、對比版本
    • Vision Agent 負責讀錯誤截圖

    💡 關鍵: 利用 MCP 與 A2A,可以把多個專職 Agent 串成一條 Workflow,讓 Code、Doc、Vision 等能力在同一上下文中協作。

    你可以怎麼用

    以「Side Project 的 Code Agent + 文檔助手」為例:

    • Code Agent:
    • 模型:Claude 3.5 Sonnet
    • 任務:生成程式碼、重構
    • 文檔助手:
    • 模型:GPT-4.1 / Gemini
    • 任務:閱讀 API 文檔、產生說明
    • 多模態:
    • 模型:如 Gemini / GPT-4o
    • 任務:讀錯誤截圖

    在 OmniRoute 裡定義三條路由,讓 Code Agent 能直接「轉接」給 Doc Agent:

    routes:
      - id: code-agent
        model: anthropic/claude-3.5
        a2a:
          doc-agent: true
          vision-agent: true
      - id: doc-agent
        model: openai/gpt-4.1
      - id: vision-agent
        model: google/gemini-1.5
    

    可行動建議:

    • 先只做兩個代理(Code + Doc),在 OmniRoute 設定 A2A,讓 Code Agent 遇到「不知道 API 用法」時,把問題轉給 Doc Agent,再把結果回傳給使用者。

    實作示範:Side Project 串三家模型的 Code Agent + 文檔助手

    來做一個具體場景:

    需求:在同一個 Side Project 裡,整合三家模型,做一個簡單的「程式碼助理 + 文檔助手」,前端只有一個 Chat UI,後端只有一個 OmniRoute Endpoint。

    架構示意

    • 前端(Next.js / React):
    • 單一聊天框
    • 輸入模式按鈕:寫程式 / 問文檔
    • 後端:
    • 全部請求送到 OMNIROUTE_URL
    • model 欄位用來指定走哪個 logical route(code-agent or doc-assistant)
    • OmniRoute:
    • code-agent → Claude(主)+ GPT(備)
    • doc-assistant → GPT + Caveman 壓縮
    • vision-agent → Gemini,多模態

    前端呼叫範例(TypeScript):

    async function callAgent(mode: "code" | "doc", messages) {
      const model = mode === "code" ? "code-agent" : "doc-assistant";
    
      const resp = await fetch(process.env.NEXT_PUBLIC_OMNIROUTE_URL!, {
        method: "POST",
        headers: {
          "Content-Type": "application/json",
          Authorization: `Bearer ${process.env.NEXT_PUBLIC_OMNIROUTE_KEY}`,
        },
        body: JSON.stringify({ model, messages }),
      });
    
      return resp.json();
    }
    

    後端與前端都不用知道「底下到底是 Claude 還是 GPT」,只認 model: "code-agent" 與 model: "doc-assistant" 兩種邏輯角色即可。


    10 分鐘開箱:從零到第一條 OmniRoute

    以下是一條「最短路徑」,讓你在 10 分鐘內把現有專案換成 OmniRoute。

    1. 註冊與安裝(3 分鐘)

    1. 打開 GitHub 專案:https://github.com/diegosouzapw/OmniRoute
    2. 把 repo 拉下來:

    bash
    git clone https://github.com/diegosouzapw/OmniRoute
    cd OmniRoute
    pnpm install # 或 yarn / npm

    1. 照 README 建一個 .env,填入你現有的 OpenAI / Anthropic 等 API Key。

    2. 啟動 OmniRoute Server(2 分鐘)

    pnpm dev # 或對應的 start 指令
    

    啟動後會有一個本地 URL,例如:http://localhost:8787/v1/chat/completions,這就是你的「總機 Endpoint」。

    3. 設定第一個路由 + 壓縮策略(3 分鐘)

    在 config/routes.yaml(實際以專案為準)中:

    routes:
      - id: code-agent
        model: anthropic/claude-3.5
        fallback:
          - openai/gpt-4.1
        compression:
          rtk: true
          caveman: false
    
      - id: doc-assistant
        model: openai/gpt-4.1
        compression:
          rtk: true
          caveman: true
    

    完成後重新啟動 OmniRoute(若需要)。

    4. 把前端 / 後端改成單一 OmniRoute URL(2 分鐘)

    無論你原本用什麼 SDK(OpenAI, Anthropic, Cursor plugin):

    • 把 baseURL 改成你的 OMNIROUTE_URL
    • 把 model 改成 OmniRoute 裡定義的 id(例如 code-agent)

    以 OpenAI SDK 為例:

    import OpenAI from "openai";
    
    const client = new OpenAI({
      baseURL: process.env.OMNIROUTE_URL,
      apiKey: process.env.OMNIROUTE_KEY,
    });
    
    await client.chat.completions.create({
      model: "code-agent",
      messages,
    });
    

    到這一步,你已經:

    • 用一個 Endpoint 串起至少兩家模型
    • 開啟 basic 的 token 壓縮
    • 為之後加上更多 provider / 代理 / 模態預留位置

    適合誰用?

    使用者類型 具體場景
    獨立開發者 Side Project 同時想用 Claude + GPT + 免費模型,又懶得寫一堆整合
    小團隊 / Startups 想 A/B 測試不同供應商,控制成本,還要有 auto-fallback 防止掛點
    AI Agent Builder 需要多代理協作(Code + Doc + Vision),又希望前端只接一個 Endpoint
    教學 / 實驗環境 需要一鍵切換教學用模型、控制學生 token 使用量

    如果你符合其中一項,可以先把 OmniRoute 當成:

    「把所有 AI 模型集中管理的一支 API Gateway」,再視需要逐步開啟壓縮、A2A、多模態。


    OmniRoute 與其他多模型工具比較

    名稱 核心功能 免費方案 適合誰
    OmniRoute 多供應商整合、auto-fallback、RTK/Caveman 壓縮、MCP/A2A、多模態 開源,支援 50+ 免費供應商 想統一管理多家模型、做複雜 Workflow 的開發者
    直接用 OpenAI 單供應商模型 API 有免費試用額度 只用 GPT 系列、需求簡單的專案
    直接用 Anthropic 單供應商 Claude 模型 有免費試用額度 只想專注 Claude Code / Sonnet

    如果你只接一個模型供應商,OmniRoute 可以先當「統一壓縮 + 路由層」;當你的模型越來越多,它就自然變成你的多雲總機。


    🚀 你現在可以做的事

    • 打開 OmniRoute GitHub 專案,依照 README 在本地啟動一個測試伺服器
    • 挑一支現有的 API 呼叫,將 baseURL 改成 OMNIROUTE_URL,並在 routes.yaml 設好對應的 model id
    • 在同一條路由上開啟 RTK 或 Caveman 壓縮,對比啟用前後的 token 使用量與費用差異
  • 開源 ATS 開箱:先讓機器 HR 幫你看履歷

    開源 ATS 開箱:先讓機器 HR 幫你看履歷

    📌 本文重點

    • 用開源 ATS 在本機跑出「機器 HR」打分
    • 依關鍵字與技能結構優化履歷匹配度
    • 求職者與小團隊都能部署透明可調的初篩系統
    • 先用機器視角迭代履歷再正式投遞

    只要幾行指令,就能在自己電腦跑一套「機器 HR」,用 HackerRank 開源 ATS 先幫你打分履歷,再送出求職申請。

    HackerRank 把自家 ATS 開源的故事原文在這裡,我們直接站在求職者和小團隊 HR 的角度,拆解它怎麼打分,和怎麼自己動手部署。


    核心功能:機器 HR 怎麼看你的履歷

    先弄清楚這套 ATS 的「腦袋」在想什麼,才知道怎麼改履歷讓分數往上。

    1. 關鍵字與職缺匹配

    它會做的事:
    – 把履歷和職缺描述切成一堆 token(關鍵字、詞組)
    – 比較兩邊出現的技能、職稱、技術名詞的重疊程度
    – 依照權重算出一個匹配分數(例如:核心技能比軟性能力更重)

    💡 關鍵: ATS 核心是「關鍵字重疊+權重」,沒有寫出來的技能就等於不存在。

    你可以馬上做的事:
    – 打開你常投的職缺 JD,列出 10–20 個明顯關鍵字(如 React、Kubernetes、CFA)
    – 確認這些詞真的出現在履歷裡,而且出現在工作經驗或技能欄位,不是藏在自我介紹
    – 同一樣技能最好在不同段落被提到 2 次以上(職稱+專案細節),讓匹配度更高

    2. 技能欄位結構化

    它會做的事:
    – 嘗試從履歷中識別「專業技能」「工具」「程式語言」等區塊
    – 把識別出的技能映射到內建或自訂的技能字典
    – 根據技能的完整度和與職缺關聯度加分

    你可以馬上做的事:
    – 把零散的技能文字改成明確的「Skills」區塊,用條列式呈現:
    – Programming: Python, Go, TypeScript
    – Data: SQL, Pandas, Airflow
    – DevOps: Docker, Kubernetes, GitHub Actions
    – 避免寫成長句:「熟悉各種前端技術如 React、Vue 等」改成獨立列出每一項

    3. 格式與可解析度

    它會做的事:
    – 先把 PDF 或 DOCX 轉成純文字
    – 檢查是否有標題層級(Education、Experience、Skills 等)
    – 看日期、公司名稱、職稱是否容易被解析出來

    你可以馬上做的事:
    – 優先使用 簡單排版的 PDF(少用圖表和多欄版面)
    – 每段工作經驗保持統一格式,例如:
    – 公司名稱 | 職稱 | 2020-01 – 2023-06
    – 標題請明寫 Work Experience、Education、Projects,不要用太創意的命名


    適合誰用:兩個典型場景

    場景 1:求職者自己跑 ATS,迭代履歷

    適合你如果:
    – 正在密集投履歷,但不知道為何常被系統一輪刷掉
    – 想在投出去前,先用「機器 HR」視角檢查履歷

    具體可以這樣用:
    1. 在本機或雲端部署 HackerRank 開源 ATS
    2. 匯入你目前版本的履歷 + 目標職缺描述
    3. 看系統產出的匹配分數與分析報告(常見會有:技能命中率、關鍵字缺漏、段落可讀性)
    4. 依照缺漏項目,調整履歷內容:補技能、重寫專案描述
    5. 重跑一次,看分數是否明顯提升

    這種「跑分 → 改履歷 → 再跑分」的迭代,能讓你迅速找出哪些描述是 ATS 看不懂的,避免被系統誤殺。

    💡 關鍵: 把 ATS 當「迭代工具」而不是一次性評分,才能持續拉高履歷表現。

    場景 2:小團隊 / 初創接到自家招聘網站

    適合你如果:
    – 公司還沒預算買商用 ATS,但已經有基本招聘網站或表單
    – 想要自動化「履歷初篩」,又希望演算法透明可調整

    具體可以這樣用:
    1. 把開源 ATS 部署在公司雲端(例如一個獨立的 VM 或 Kubernetes namespace)
    2. 在招募網站的投遞表單,增加一個後端步驟:
    – 收到履歷檔案 -> 呼叫 ATS API -> 存分數與解析結果到資料庫
    3. 對 HR 顯示:
    – 依分數排序的候選人列表
    – 每人的技能命中明細(例如:符合 8/10 必備技能)
    4. HR 可以手動調整各職缺的權重設定,例如:某職缺重視 Python 多於 Java,再重跑分數

    這套流程的好處是:你可以完全看到打分邏輯,調整職缺與技能字典,不會被黑盒演算法綁死。


    怎麼開始:從 GitHub 到第一份跑分履歷

    以下以一般開源 ATS 專案為例,示範本機快速部署與基本操作。實際路徑請以 HackerRank 公佈的 GitHub repo 為準(可以從原文 danunparsed 的文章 追過去)。

    步驟 1:取得程式碼(GitHub)

    1. 確認電腦已安裝:
    2. Git
    3. Docker 或至少 Python 3.9+
    4. 從 GitHub 取得程式碼:

    bash
    git clone https://github.com/hackerrank/open-ats.git
    cd open-ats

    1. 用檔案總管打開專案,先看 README.md,通常會列出:
    2. 必備環境
    3. 快速啟動指令
    4. API 說明

    步驟 2:快速部署(本地或雲端)

    選項 A:本機 Docker 一鍵跑起

    如果 README 提供 Docker Compose:

    docker compose up -d
    

    然後打開瀏覽器到 http://localhost:8000(實際 port 依專案設定),通常會看到:
    – 簡單的 Web 介面可以上傳履歷
    – 或至少有 API 文檔(Swagger / OpenAPI)

    選項 B:雲端輕量部署

    如果想在雲端跑,方便給 HR 或朋友共用:

    1. 在 Render / Railway / Fly.io 之類平台建立新服務
    2. 連接你的 GitHub repo
    3. 在設定中填入:
    4. Build command:如 docker build . 或 pip install -r requirements.txt
    5. Start command:如 uvicorn main:app --host 0.0.0.0 --port 8000
    6. 部署完成後,平台會給你一個公共 URL,當作 ATS API 入口

    💡 關鍵: 雲端部署加一個公共 URL,就能立刻變成多人共用的履歷初篩服務。

    步驟 3:丟入第一份履歷測試

    假設 ATS 提供一個 /score API,可以這樣測試(具體路徑依專案為準):

    curl -X POST \
      https://your-ats-url/score \
      -F "resume=@/path/to/resume.pdf" \
      -F "job_description=@/path/to/jd.txt"
    

    你會拿到一個 JSON 回應,常見欄位可能是:

    {
      "total_score": 82,
      "keyword_match": {
        "required": 10,
        "matched": 8
      },
      "skills": {
        "python": true,
        "docker": false,
        "react": true
      },
      "notes": [
        "Missing keyword: Kubernetes",
        "No explicit mention of SQL",
        "Work experience dates parsed successfully"
      ]
    }
    

    步驟 4:看懂分數,對症調整

    拿到分數後,重點不是「幾分」,而是怎麼據此改履歷:

    1. 先看缺漏的技能與關鍵字
    2. 每個 false 或 missing 的技能,對照職缺 JD 是不是你真的會但沒寫
    3. 能做到的就明確寫進「Skills」或「工作成果」段落
    4. 再看解析失敗的欄位
    5. 如果 notes 提到日期無法解析,調整成標準格式
    6. 公司名、職稱盡量獨立成一行,不要混在長句
    7. 最後看總分變化
    8. 每次改完重跑,記錄分數變化和修改內容
    9. 找到「加分效率最高」的修改方式,往那個方向優化

    總結:先學會用機器 HR 的語言說話

    HackerRank 把自家 ATS 開源,等於把機器 HR 的打分標準攤在你面前。你可以:
    – 當求職者:在本機或雲端跑一套 ATS,先自測履歷再投遞
    – 當小團隊 HR:把 ATS 接到自家網站,建立透明可調整的初篩機制

    真正有用的做法不是「迎合演算法」,而是讓履歷把你的能力說清楚,並且用機器看得懂的結構寫出來。先跑幾次分數,你很快就會掌握那套語言。

    🚀 你現在可以做的事

    • 打開常投職缺 JD,整理出 10–20 個關鍵字,對照並重寫自己的履歷結構
    • 到 GitHub 搜尋 HackerRank 開源 ATS 專案,依 README.md 在本機或雲端部署測試
    • 跑一輪「改履歷 → 用 /score API 重測 → 比較分數變化」,記錄哪類修改最有效
  • 讓費曼幫你開會:高智議會實戰

    讓費曼幫你開會:高智議會實戰

    📌 本文重點

    • 18 位 AI 專家人格協作,幫你拆解困難決策
    • 支援多家 LLM,多模型協同辯論與決策
    • 結構化多輪會議流程,適合產品、工程與職涯抉擇
    • 10 分鐘內可在本機跑起第一個 /council

    一句話定位:Council of High Intelligence 是一個「多人格、多模型的開源決策助手」,讓亞里斯多德、費曼、卡尼曼、Torvalds 等 18 位 AI 專家分工辯論,幫你把困難決策拆開分析。

    GitHub 專案連結:https://github.com/0xNyk/council-of-high-intelligence


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

    1. 18 位 AI 專家人格,替你「開會」

    這個專案內建 18 個 AI persona,例如:

    • 費曼:擅長把複雜問題拆小,用白話解釋
    • 卡尼曼:偏向風險、決策偏誤、心理學角度
    • Torvalds:工程實作與系統設計視角
    • 亞里斯多德:偏向邏輯與倫理推理

    💡 關鍵: 18 位專家人格讓同一個問題從多角度被拆解與辯論,比單一模型更接近真實開會決策。

    你只需要:

    1. 想好你要決策的問題(例如:「我要選哪個前端框架?」)
    2. 用一行指令 /council + 問題
    3. 看不同人格怎麼辯論、反駁、收斂結論

    可行動點:先在腦中列出你最近最卡的一個決策,用一句話描述,等會在「怎麼開始」裡直接拿來當第一條指令。


    2. 多家 LLM 供應商,真正「多模型」討論

    官方描述:

    18 AI personas deliberate your hardest decisions across multiple LLM providers.

    意思是:你可以把不同角色綁到不同家模型,例如:

    • 深度推理角色 → 使用 OpenAI / Claude / DeepSeek
    • 技術細節角色 → 使用本地 Qwen / LLaMA
    • 檢查與總結角色 → 使用另一家 API

    這樣比起「一個模型演完全部人格」,更接近多人開會:不同模型偏好不同風格、推理路線也不同。

    可行動點:先決定你要用哪幾種 LLM 來源:

    • 沒有 GPU:先用雲端(OpenAI、Anthropic、DeepSeek 等)
    • 有本地 GPU:用本地模型 + 雲端模型混用

    在 .env 裡填 API key 即可(下文會示範)。


    3. 結構化多輪討論,不是單次回答

    這不是「問一次、回一段」的聊天,而是預設有多輪辯論流程:

    1. 第一輪:各專家給出初步立場
    2. 中間:互相質疑、補充證據、提出 alternative
    3. 最後:整合成具體建議 + 原因拆解

    你可以把它想成一個腳本化的「會議流程模版」,每次 /council 就是啟動一次完整會議。

    可行動點:在準備問題時,用「決策問題」的格式描述:

    • A vs B 的選擇(框架、技術、工作)
    • 有限制條件(時間、預算、人力)
    • 希望輸出形式(表格、清單、分階段建議)

    適合誰用?三個典型場景

    💡 關鍵: 產品經理、工程師與個人職涯決策者,都可以用同一套會議流程模版,快速得到結構化建議。

    1. 產品經理:產品選型 / 路線決策

    情境:

    • 要在「先做 Web 還是先做 App」中選一個
    • 要評估「自研 vs 採用 SaaS」

    你可以這樣用:

    /council 幫我評估:我們是一個 B2B SaaS,新功能是「客戶成功儀表板」。
    選項 A:在現有產品裡做一個輕量 dashboard。
    選項 B:做成獨立子產品,單獨收費。
    
    條件:
    1. 團隊 6 人,前端 2、後端 2、產品 1、設計 1
    2. 期望 3 個月內能驗證市場
    3. 優先考慮現有客戶的 adoption 風險
    
    請從產品策略、商業模式、技術風險三個角度辯論,最後給一個推薦選項與 roadmap。
    

    行動建議:把你手上的下一個 roadmap 爭議點,寫成「A vs B + 條件」格式,直接餵給 /council。


    2. 工程師:技術方案比較 / 架構選擇

    情境:

    • 要決定「單體服務 vs 微服務」
    • 比較「使用 Rust / Go / Java 實作」

    例如:

    /council 我要設計一個高併發 API 服務, QPS 目標 5k,
    選項 A:使用 Go + Gin + Redis
    選項 B:使用 Rust + Axum + Redis
    
    約束:
    - 團隊目前主要會 Go,沒人寫過 Rust
    - 上線時間壓力大,希望 2 個月內可上線 MVP
    
    請從開發效率、長期維護成本、性能需求三個角度辯論,
    最後給出推薦技術棧與風險清單。
    

    行動建議:先把你準備寫在技術設計文檔裡的「方案對比」,丟給高智議會,看看它會怎麼拆解風險與權衡因素。


    3. 個人:職涯抉擇 / 學習路線

    情境:

    • 「要不要跳槽?」
    • 「要走管理還是繼續寫程式?」

    使用示例:

    /council 我現在是一名 5 年資歷的後端工程師,
    手上有兩個選擇:
    A:留在現在公司,穩定但成長有限
    B:加入一間早期 AI 新創,薪水略高但不確定性大
    
    條件:
    - 已婚,有小孩,家庭支出固定
    - 想在 3 年內成為資深工程師或 Tech Lead
    
    請從職涯風險、技能成長、財務安全三個角度辯論,
    給我具體建議與行動計畫。
    

    行動建議:把你最近在朋友群裡反覆抱怨的那個職涯問題,寫成 A/B 選擇 + 三個條件,讓「高智議會」幫你理一次。


    怎麼開始:從 GitHub clone 到第一個 /council

    以下以一般開發者環境(macOS / Linux)為例,步驟盡量壓縮到 10 分鐘內能跑起來。


    步驟 0:準備環境

    先確認:

    • 已安裝 git
    • 已安裝 Python 3.10+ 或專案要求版本(請以 repo README 為準)
    • 有一組可用的 LLM API key(例如 OpenAI / DeepSeek)

    行動:如果沒有 Python,可以先裝 pyenv 或用你習慣的版本管理工具準備一個環境。


    步驟 1:Clone 專案

    git clone https://github.com/0xNyk/council-of-high-intelligence.git
    cd council-of-high-intelligence
    

    行動:在你常用的開發目錄執行上述指令,打開專案資料夾準備配置。


    步驟 2:建立虛擬環境並安裝依賴

    python -m venv .venv
    source .venv/bin/activate  # Windows 使用 .venv\Scripts\activate
    pip install -r requirements.txt
    

    如果 README 有指定使用 poetry 或其他工具,請以官方文件為準。

    行動:成功後,執行 python -V 確認你現在在虛擬環境內。


    步驟 3:設定 LLM 提供商(API key)

    專案通常會有範例環境檔,例如 .env.example 或 config.example.yaml。

    1. 複製範例檔:
    cp .env.example .env
    
    1. 打開 .env,填入你的 API key,例如:
    OPENAI_API_KEY=sk-xxxx
    # 或使用其他提供商
    DEEPSEEK_API_KEY=xxxx
    ANTHROPIC_API_KEY=xxxx
    
    1. 若專案支援多模型,你可以在設定檔裡定義:

    2. 哪個 persona 用哪個 provider

    3. 模型名稱(例如 gpt-4.1, deepseek-chat 等)

    行動:至少先填一組你最熟悉的 API key,確保可以跑通第一個會議。


    步驟 4:啟動「高智議會」

    依專案設計,啟動方式可能是 CLI 或 TUI,常見格式如下(請對照 README):

    python main.py
    # 或
    council
    

    啟動後,終端可能會顯示類似:

    Welcome to the Council of High Intelligence.
    Type /council to start a new deliberation.
    

    行動:如果啟動失敗,先檢查:

    • Python 版本是否符合
    • requirements.txt 是否安裝完整
    • .env 是否存在且變數名稱拼寫正確

    步驟 5:發出你的第一條決策指令

    在終端中輸入:

    /council 幫我決定,接下來三個月我要把下班時間花在什麼事情上:
    A:寫 side project,目標是做一個小型 SaaS
    B:準備跳槽,用來刷 LeetCode 和整理履歷
    
    條件:
    - 每天大約只有 1.5 小時可用
    - 希望一年後收入有明顯提升
    請從時間投入風險、學習成長、現金回報三個角度辯論,最後給具體計畫。
    

    你應該會看到:

    • 多個角色輪流發言
    • 中間互相質疑、補充
    • 最後一位「主持人」整合結論與行動步驟

    行動:把這次輸出的結論,轉成你今天可以實際做的一件小事(例如:「今晚先列出三個 side project 題目」)。


    延伸:和多代理系統、雙 GPU 的連結

    如果你手上有多 GPU,或對 multi-agent 有興趣,可以參考這兩個方向:

    • 多 GPU 並行推理(參考 r/LocalLLaMA 貼文):
    • 用一個較大模型當 orchestrator,
    • 多個小模型當子代理,平行處理不同 persona。
    • 安全領域應用:像 VulnClaw 這類多代理滲透測試框架,將「多角色協作」搬到資安自動化場景。

    如果你本來就在玩多代理框架(如 MCP、各種 agent 工具),高智議會可以作為「決策模組」,專門負責:

    • 需求澄清與任務拆解
    • 方案比較與風險評估
    • 最後做出一個「可執行決策」交給其他 agent 落地

    最後的可行動點:

    1. 先 clone 下來跑一次 /council
    2. 把你日常最常卡的那種決策(技術選型 / 職涯 / 產品路線),固定丟進去
    3. 觀察 1–2 週,看它是否幫你減少「反覆糾結」的時間

    把開會交給費曼們,你多一點時間去執行。


    🚀 你現在可以做的事

    • 到 GitHub clone 下來 council-of-high-intelligence,依照文中步驟跑起第一個 /council
    • 挑一個你現在最卡的 A/B 決策,照範例格式寫好丟進議會讓它辯論一次
    • 如果你有在用多代理框架,嘗試把「高智議會」當成決策模組接入現有工作流
  • 用瀏覽器跑自己的 AI Agent:peerd 實戰

    用瀏覽器跑自己的 AI Agent:peerd 實戰

    📌 本文重點

    • peerd 把瀏覽器變成本機 AI Agent 執行環境
    • 純前端運作,API Key 不經過第三方伺服器
    • 多 Agent 隔離與瀏覽器自動化,適合個人工作流與 QA 腳本

    用一句話講清楚:peerd 就是把「瀏覽器」變成你的 AI Agent 執行環境,所有腳本、代理邏輯都在本機瀏覽器裡跑,不經過第三方伺服器。

    連結先給你:
    – GitHub / 官方介紹:https://github.com/NotASithLord/peerd
    – Demo / 官網入口:https://peerd.ai


    核心功能:瀏覽器就是沙盒 + 多 Agent 控制台

    1. 純前端 JS,API Key 只在你機器裡

    peerd 是一個瀏覽器擴充套件,用原生 JavaScript 寫成,執行邏輯都在前端:

    • 你自己輸入 OpenAI、Anthropic、Gemini 等 API Key
    • 請求直接從瀏覽器送出,不經過 peerd 的伺服器
    • 不需要額外安裝「AI 瀏覽器」或開一個本地 server

    💡 關鍵: API 呼叫完全在本機瀏覽器完成,你的金鑰與請求內容不會經過第三方後端服務。

    你可以立刻做的事:
    1. 打開 https://peerd.ai,依照說明安裝瀏覽器擴充套件(目前以 Chromium / Chrome 系列最佳)。
    2. 安裝後,在擴充圖示裡找到 peerd,開啟設定頁,填入你現有的 OpenAI / Anthropic / Gemini API Key。
    3. 測試呼叫一次簡單指令(例如:讓 Agent 幫你總結目前開啟頁面的內容),確認 Key 有效。

    2. 多 Agent,彼此隔離在不同 sandbox / worker

    peerd 的設計重點是:一個瀏覽器,多個 Agent,各自有自己的工作空間。

    它利用:

    • 多分頁 / 多視窗
    • Web Worker / Service Worker

    來把不同 Agent 隔離,例如:

    • Agent A:專門抓資料,跑在一個 Worker 裡
    • Agent B:負責整理與寫摘要,跑在另一個 Worker
    • Agent C:只負責觸發 UI 操作

    彼此透過訊息溝通,但記憶體與腳本隔離,減少互相干擾。

    💡 關鍵: 每個 Agent 在獨立的 worker/sandbox 裡執行,降低互相干擾與權限混用風險。

    你可以立刻做的事:
    1. 在 peerd 的控制面板中,建立兩個 Agent:例如「資料收集 Agent」「摘要整理 Agent」。
    2. 設定:「資料收集 Agent」負責打開網站、擷取內容;完成後把文字丟給「摘要整理 Agent」。
    3. 觀察兩個 Agent 的 log(通常 peerd 會有 console / log 面板),確認任務是分開跑的。

    3. 自動化瀏覽、跑 JS 腳本,甚至開 WebAssembly VM

    peerd 不只有「叫模型寫文字」這一招,它可以:

    • 控制瀏覽器行為:
    • 自動打開指定網址
    • 在頁面中執行 DOM 查詢、抓元素文字
    • 觸發按鈕點擊、輸入框填寫
    • 執行 JavaScript 腳本:在 sandbox 內跑程式邏輯,像一個本地化的「Agent 腳本引擎」
    • 啟動 WebAssembly(WASM)虛擬機:甚至可在瀏覽器裡跑一個簡化版的 Linux VM + 網路堆疊

    這代表:

    • 你不用額外架 server 就能做「自動化 QA 腳本」
    • 可以把實驗性 side project 完整關在瀏覽器裡玩,不動你的主機環境

    你可以立刻做的事:
    1. 用 peerd 新增一個「任務腳本」,讓它在分頁裡執行以下行為:
    – 打開一個新聞網站
    – 用 document.querySelectorAll('h1, h2') 抓標題
    – 把標題串成一段文字
    2. 把這段文字交給 LLM,請它生成摘要,顯示在 peerd 的面板中。
    3. 如果你熟 JS,可以把這個流程包成一個可重複執行的腳本,日後一鍵跑。


    適合誰用:三種具體場景

    1. 個人資訊整理 / 研究助手

    使用情境:

    • 你每天會看固定幾個新聞網站或技術部落格
    • 想要「早上開機 → 一鍵跑 → 自動抓標題 → 整理成 一頁摘要」

    可以這樣設計一個 peerd Agent:

    1. 設定一個 URL 清單(例如:三個新聞站 + 一個技術站)。
    2. Agent 依序打開每個網站,抓取首頁標題(或特定區塊)。
    3. 把所有標題與小段落交給 LLM,產出:
    4. 一份今日重點摘要
    5. 分類(國際 / 本地 / 技術 / 商業)
    6. 把結果顯示在 peerd 面板,或存成一段 Markdown,傳回你的筆記系統。

    適合:

    • 喜歡自己控制流程、但不想寫一堆後端程式的人
    • 不想讓瀏覽紀錄、研究內容經過第三方服務的人

    2. 產品 / 網頁 QA 腳本、互動 Demo

    peerd 可以把「瀏覽器自動操作 + LLM」組成 QA 工作流:

    範例:

    1. 定義一組 QA 腳本:
    2. 打開測試環境網址
    3. 自動登入測試帳號
    4. 點幾個主要流程(新增、編輯、刪除),截取畫面文字
    5. Agent 檢查:
    6. 是否有錯誤訊息
    7. 版面文字是否符合規格(例如:翻譯是否正確)
    8. 把結果整理成一份 QA 報告,直接在瀏覽器下載或複製。

    適合:

    • 前端工程師、PM、設計師,想要簡單重複測試
    • 需要做互動 Demo,讓 Agent 自動「操作產品給觀眾看」

    3. 不想碰 DevOps 的 side project / workflow 原型

    如果你平常:

    • 有很多「想做個小工具」的點子
    • 但一想到要架 server、部署,就懶了

    peerd 提供一種做法:全部寫成瀏覽器 Agent 腳本:

    • 把流程寫在 JS 裡(在 peerd 提供的 sandbox 中)
    • 需要呼叫 LLM,就用自己的 Key
    • 存資料可以暫時放在 LocalStorage、下載檔案、或手動貼回 Notion / Obsidian

    適合:

    • 想先驗證「這個工作流值不值得做成正式產品」的人
    • 想建立個人專用工作流,但不想管理伺服器的人

    怎麼開始:從「自動抓新聞標題摘要」實作一路到客製 Agent

    以下是一條最快速的上手路徑,你可以照做一次,確認 peerd 的使用感覺。

    步驟 1:安裝 peerd 擴充 & 準備 API Key

    1. 打開 https://peerd.ai,找到瀏覽器擴充安裝連結(多為 Chrome Web Store 或手動載入)。
    2. 安裝完成後,點右上角擴充圖示 → 找到 peerd → 打開控制面板。
    3. 準備至少一個 LLM 服務:
    4. OpenAI(或相容 API)
    5. Anthropic
    6. Gemini
    7. 在 peerd 設定頁,填入你的 API Key,並測試一個簡單 prompt(例如:「請用 50 字說明你是誰」)。

    💡 關鍵: 先用簡單 prompt 驗證 API Key 設定無誤,可以避免後續腳本除錯時間。

    步驟 2:建立一個「新聞摘要 Agent」

    目標:自動打開幾個新聞站,抓首頁標題,總結成一段簡報。

    可以照以下邏輯:

    1. 在 peerd 新建一個 Agent,命名為 NewsSummarizer。
    2. 設定任務腳本(概念上類似 pseudo-code):

    “`js
    const sites = [
    ‘https://news.ycombinator.com’,
    ‘https://www.bbc.com/news’,
    ‘https://www.ft.com’
    ];

    async function run() {
    const allHeadlines = [];

     for (const url of sites) {
       const page = await openTab(url); // peerd 提供的抽象 API(實際名稱依文件)
       const titles = await page.eval(() => {
         return Array.from(document.querySelectorAll('h1, h2'))
           .map(el => el.innerText)
           .filter(Boolean);
       });
       allHeadlines.push({ url, titles });
     }
    
     const prompt = `請根據以下新聞標題,用繁體中文整理出今日重點摘要,分段列出:\n\n${
       JSON.stringify(allHeadlines, null, 2)
     }`;
    
     const summary = await callLLM(prompt); // 依照你選的 provider
     output(summary);
    

    }

    run();
    “`

    1. 儲存腳本後,按「執行」:
    2. peerd 會依序開啟那些網站
    3. 抓取標題
    4. 呼叫 LLM 總結
    5. 在側邊面板或 console 顯示結果

    你可以依照自己的需求修改:

    • 換成台灣 / 香港 / 日本新聞網站
    • 加上「只保留包含特定關鍵字的標題」
    • 把 summary 轉成 Markdown,方便貼到筆記

    步驟 3:客製自己的 Agent 腳本

    當你跑過一次「新聞摘要 Agent」後,可以開始做這幾件事:

    1. 抽出共用邏輯:例如「開頁+抓標題」寫成一個可重用的 function,日後換站台不用重寫。
    2. 加入排程或手動檔案輸出:
    3. 每次執行後自動下載一個 .md 或 .txt
    4. 或直接在 peerd 面板顯示,手動複製
    5. 改成其他任務:
    6. 產品價格比價(抓不同電商同一商品)
    7. 技術文章整理(從多個 blog 抓標題+摘要)

    步驟 4:注意權限與安全設定

    雖然 peerd 是純前端、API Key 在你機器上,但仍有幾個安全重點:

    1. 網站權限:
    2. 當瀏覽器問「是否允許此擴充存取某些網站」時,只開啟你真的需要的網域。
    3. API Key 保護:
    4. 不要在共享電腦上使用 peerd,或至少不要留下儲存的 Key
    5. 若用公用電腦,建議使用臨時 Key,使用完立刻 revoke
    6. 腳本來源:
    7. 只執行你自己寫的,或來自可信來源的腳本
    8. 不要隨便貼「網友分享的完整腳本」就直接跑,避免讀寫你不想暴露的資料

    peerd 在 AI Agent 工具裡的位置

    目前市面上有不少「Agent 平台」或「AI 瀏覽器」,peerd 的定位比較特別:

    名稱 核心功能 免費方案 適合誰
    peerd 瀏覽器內純前端多 Agent、自動化操作 開源專案,可自架 不想碰後端,只想用瀏覽器的人
    AutoGen 多 Agent Python 框架 開源 已有後端環境的開發者
    AgentHub 類 雲端 Agent 編排平台 多提供免費額度 喜歡 GUI、無法自管 API Key 的人

    如果你的重點是:「所有東西都在我瀏覽器裡跑,不想任何 A2A(Agent-to-Agent)中介干預」,那 peerd 很值得試一次。


    結論:

    • 想要一個「不碰後端、不開伺服器」的 AI Agent 沙盒,peerd 是目前少見的純瀏覽器方案。
    • 它最適合拿來做:個人資訊整理、簡易 QA 腳本、side project 原型。
    • 你可以從一個「新聞標題摘要 Agent」開始,熟悉後再把自己的工作流程慢慢搬進瀏覽器裡。

    🚀 你現在可以做的事

    • 到 peerd 官網 安裝擴充,填入自己的 OpenAI / Anthropic / Gemini API Key 並跑一次測試 prompt
    • 依照文中的範例,建立一個 NewsSummarizer Agent,實作「自動抓新聞標題+摘要」工作流
    • 把現有的一項重複性瀏覽器流程(例如 QA 點測、價格比價),改寫成 peerd Agent 腳本並在本機瀏覽器中試跑
  • MinerU 把爛 PDF 變 AI 神隊友

    MinerU 把爛 PDF 變 AI 神隊友

    📌 本文重點

    • MinerU 專門把 PDF/Office 轉成乾淨結構化文本
    • 讓表格、圖片、公式都能友善餵給 RAG / Agent
    • 開源可本地部署,易嵌入各種 LLM / Agent workflow

    一句話先說結論:MinerU 就是一台「給 LLM / Agent 吃的文件清洗機」——丟 PDF、Word、PPT 進去,吐出乾淨的 Markdown / JSON,直接給 RAG、Chatbot、Agent 用。

    👉 專案連結:https://github.com/opendatalab/MinerU


    核心功能:讓 AI 真的「看懂」你的文件

    1. 直接吃 PDF / Office,多欄位也能拆乾淨

    多數 RAG 失敗,不是模型太笨,而是原始 PDF 太亂。MinerU 的重點是:

    • 支援:PDF、Word、PPT 等常見文件
    • 能處理的麻煩版面:
    • 多欄位排版(例如期刊論文、報表)
    • 頁首/頁尾、頁碼、註腳
    • 混合字型、大小標題、清單

    你可以這樣用:

    1. 把公司內部 PDF / Word 全部放進一個資料夾,例如 ./docs_raw。
    2. 用 MinerU 批次轉成 Markdown,輸出到 ./docs_md。
    3. 接著再用你熟悉的向量庫(如 Milvus、Qdrant、Weaviate)去吃 docs_md。

    這樣做的好處:後面所有 LLM / Agent pipeline,都只面對格式一致的純文字,而不是千奇百怪的 PDF。

    💡 關鍵: 先把所有文件標準化成一致的 Markdown / JSON,可以大幅降低 RAG 出錯率與後續維護成本。


    2. 表格 / 圖片 / 公式抽取,輸出 Markdown / JSON

    對技術文件來說,表格、圖表、公式往往是重點。MinerU 的輸出設計就是「給 LLM 用」:

    • 表格:轉成 Markdown table 或 JSON 結構,便於查詢與切 chunk。
    • 圖片:支援抽圖路徑(搭配 OCR / 圖像模型再處理)。
    • 公式:儘量轉成可讀的文字或 LaTeX 形式,減少重要信息消失。

    你可以依專案需求選擇:

    • Markdown 模式:適合直接塞進向量庫、做長文閱讀、摘要。
    • JSON 模式:適合需要欄位結構的 Agent workflow,例如:
    • 表格 → JSON → 丟給 Agent 做統計、比對
    • 報表 → JSON → 自動生成指標報表

    💡 關鍵: 把表格、公式這類結構化資訊轉成 JSON,可讓 Agent 做統計、比對、生成報表時更精準可控。


    3. 天然適合多代理 / 本地 LLM Workflow

    MinerU 的定位不是一個「雲端 SaaS」,而是一段你可以塞進自己 pipeline 的工具。

    典型的用法是這樣:

    1. 資料前處理 Agent:監控新文件,觸發 MinerU 解析。
    2. 知識庫建置 Agent:把 MinerU 輸出的 Markdown / JSON 切 chunk + 嵌入向量庫。
    3. 問答 / 任務 Agent:收到問題時,到向量庫檢索相關片段,再交給 LLM 回答。

    因為 MinerU 是開源、可本地部署,你可以:

    • 把它丟進 Docker Compose 裡,和本地 LLM(如 Ollama)一起跑。
    • 讓 CI/CD 在文件更新時,自動重新解析。

    💡 關鍵: 開源且可本地部署,意味著你可以在私有環境中標準化所有文件處理流程,符合安全與合規需求。


    適合誰用?三個具體場景

    1. 企業內部文件知識庫、客服 / 內訓 FAQ

    場景:

    • 公司有大量 SOP、內規、產品說明、培訓教材,多數是 PDF / Word。
    • 你想做一個內部 Chatbot,讓同事問問題時,直接查這些文件。

    可實作流程:

    1. 把所有內部文件收集到 ./company_docs。
    2. 用 MinerU 批次轉成 Markdown:
    3. 標記檔案來源(檔名、類別),方便之後做權限或分類。
    4. 把 Markdown 丟進向量庫,接上你選的 LLM(本地或雲端)。
    5. 在公司 Portal 放一個簡單的 Chat UI,查詢時帶出「原文片段」。

    行動建議:先挑 20 份最常被問的文件,跑一次 MinerU,做一個最小可用版本(MVP)給團隊試用。


    2. 技術文件、論文、報表餵給 RAG / Chatbot

    場景:

    • 需要讓模型理解 API 文件、產品白皮書、學術論文。
    • 想要一個「專門讀某份規格書」的 Chatbot。

    可實作流程:

    1. 用 MinerU 把每份技術文件解析成 Markdown:
    2. 確保目錄、標題層級清楚,可用來分段。
    3. 切 chunk 時,可以以「段落 + 小節標題」為單位,而不是固定字數。
    4. 建立索引:保留檔名 + 小節名稱,方便回答時引用。

    行動建議:

    • 先選一份技術文件(例如某 API Reference PDF),用 MinerU 解析後,和「直接用 PDF OCR」比較效果,你會很快看出閱讀品質差異。

    3. 結合本地 LLM / Agent 做長文閱讀、摘要、自動標註

    場景:

    • 想在本地跑 LLM(例如 Ollama + Qwen / Llama),處理長報告、會議紀錄。
    • 希望自動產生標籤、重點整理、摘要。

    可實作流程:

    1. 本地部署 MinerU,解析文件成 Markdown。
    2. 用一個小腳本:
    3. 讀 Markdown → 切段 → 按段落送到本地 LLM。
    4. 讓 LLM 回傳:摘要、關鍵字、分類。
    5. 把結果寫回另一個 JSON 檔,或直接寫入 ElasticSearch / 你用的 DB。

    行動建議:先挑一份 50 頁以上的 PDF,跑 MinerU + 本地 LLM,實測「從原始 PDF 到摘要 JSON」全流程,測時間 & 品質,再決定要不要全量導入。


    怎麼開始:本地快速跑起 MinerU

    以下示範兩種上手方式:Docker 與 pip。使用前建議先看 GitHub 專案 README(隨版本更新):https://github.com/opendatalab/MinerU

    注意:實際指令可能會隨版本更新,請以官方文件為準。下面是典型用法思路,幫你掌握大方向。

    方式一:用 Docker 跑一個典型 PDF Pipeline

    1. 安裝 Docker(Windows / macOS / Linux 都可以)。
    2. 下載專案或直接拉鏡像(以官方 README 為主):
    docker pull opendatalab/mineru:latest
    
    1. 在本機建立兩個資料夾:
    mkdir -p ~/mineru/input ~/mineru/output
    # 把 PDF 放進 input
    cp your.pdf ~/mineru/input/
    
    1. 跑容器:
    docker run --rm \
      -v ~/mineru/input:/data/input \
      -v ~/mineru/output:/data/output \
      opendatalab/mineru \
      mineru \
      --input_dir /data/input \
      --output_dir /data/output \
      --format markdown
    
    1. 檢查輸出:

    2. 在 ~/mineru/output 裡,你會看到對應的 .md 或 .json 檔。

    接下來,你只要把這些 Markdown:

    • 用 Python 讀進來 → 切 chunk → 打 embeddings → 塞進向量庫。
    • 或者直接丟給 Agent 當上下文。

    方式二:用 pip 安裝,嵌入自己的 Python 專案

    如果你想把 MinerU 當成專案的一部分(例如在 FastAPI、Django 裡叫用),可以這樣做:

    1. 建議先建立虛擬環境:
    python -m venv .venv
    source .venv/bin/activate  # Windows 用 .venv\Scripts\activate
    
    1. 安裝 MinerU(以 README 為準):
    pip install mineru
    
    1. 在 Python 裡呼叫(示意):
    from mineru import DocumentParser
    
    parser = DocumentParser(
        output_format="markdown",  # 或 "json"
        lang="zh",                 # 主要語言
    )
    
    parser.parse_dir(
        input_dir="./docs_raw",
        output_dir="./docs_md",
    )
    
    1. 接上你的 RAG pipeline,例如:
    from your_vector_store import add_markdown_docs
    
    add_markdown_docs("./docs_md")
    

    幾個實用配置建議

    1. 語言設定

    • 如果大多數文件是中文,建議在配置中指定 lang=zh,有助於:
    • 正確切段
    • 標題與正文的判斷
    • 混合語言文件(中英夾雜)可先用 MinerU 預設配置,實際跑一份看看效果再微調。

    2. 版面複雜度:先從「最難的」文件測試

    不同文件可能需要不同策略:

    • 多欄位期刊論文
    • 含大量表格的財報
    • 圖片 + 文字混排的簡報

    建議流程:

    1. 先挑 3 種最重要、也最難處理的 PDF 各一份。
    2. 用 MinerU 跑一遍,目視檢查輸出的 Markdown 是否:
    3. 段落順序正確
    4. 表格完整
    5. 標題層級清楚
    6. 再決定是否需要額外的後處理腳本(例如正則清除多餘頁碼)。

    3. 批次處理:一次跑大量文件

    當你要處理成百上千份文件:

    • 使用 --input_dir / parse_dir 直接對整個資料夾處理。
    • 可搭配簡單的排程工具(如 cron、Airflow、Prefect):
    • 每天檢查新文件 → 觸發 MinerU → 更新向量庫。
    • 建議保留:
    • 原始 PDF 路徑
    • 解析時間
    • 解析版本(方便之後換版本重跑)

    小結:MinerU = 文件進 AI 系統前的「洗版」必備

    如果你正為這些事頭痛:

    • PDF 抽不出好用的文字
    • RAG 回答總是抓錯重點
    • Agent Workflow 每次都被「前處理」拖累

    那 MinerU 是值得花一個下午試跑的工具。把它想像成:

    所有文件進 AI 系統前,先經過的一台「格式清洗機」。

    一旦你把這個「洗版」步驟標準化,後續不論是企業知識庫、技術文件 Chatbot,還是本地 LLM 長文閱讀,都會變得穩定許多。



    🚀 你現在可以做的事

    • 到 GitHub 查看 MinerU 專案 README,確認最新安裝與使用方式
    • 選 10–20 份關鍵 PDF/Word,實際跑一次「PDF → Markdown → 向量庫」流程
    • 在你現有的 RAG / Chatbot 專案中,插入 MinerU 作為前處理步驟,評估回答品質提升幅度