標籤: 開源模型

  • moonshine 實戰:10 行程式碼做語音代理

    moonshine 實戰:10 行程式碼做語音代理

    📌 本文重點

    • moonshine 是可本地部署的低延遲語音代理 C++ pipeline
    • 一條 pipeline 完成 STT、意圖辨識與 TTS
    • 適合客服熱線、語音面板與 IoT 離線語音控制
    • 可直接接上任意 REST API 打造專屬語音 agent

    只想做一個語音版 ChatGPT、客服機器人,卻不想被雲端 API 綁死、每月付帳單?moonshine 就是那套「自己裝在機器上、一次搞定語音輸入+理解+回覆」的 C++ pipeline。

    原始碼在 GitHub:https://github.com/moonshine-ai/moonshine


    核心功能:一條語音 pipeline,全都自己掌控

    moonshine 的定位很直接:

    Very low latency speech to text, intent recognition, and text to speech, for building voice agents and interfaces.

    你可以把它想成「本地版語音代理引擎」——不是雲端服務,而是一個可以編譯進你自己程式的 C++ library/工具。

    💡 關鍵: moonshine 把 STT、意圖辨識與 TTS 串成單一低延遲 pipeline,從輸入到輸出都在你自己的機器上完成。

    1. 語音輸入:低延遲 STT(Speech-to-Text)

    • 功能:把麥克風語音即時轉成文字,延遲低,適合對話場景。
    • 實際效果:跑在桌機或中高階單板機上,可以做到「你講一句,它同時開始辨識」的互動感。
    • 你可以立刻做的事:
    • 把它接到客服電話錄音,轉成文字後送到 FAQ 引擎。
    • 接到操作面板上,用語音替代滑鼠點選。

    2. 意圖辨識:Intent Recognition

    • 功能:從文字中判斷「使用者想做什麼」,例如:查訂單、開支援 ticket、關燈、查庫存。
    • moonshine 的做法:把語音轉文字後,丟進意圖模型(可換成你自己訓練的分類器/LLM)。
    • 你可以立刻做的事:
    • 自訂幾個意圖(如 查訂單、問價格、人工轉接),用簡單規則或模型判斷要打到哪個 API。

    3. 語音輸出:TTS(Text-to-Speech)

    • 功能:把系統回覆文字轉成語音,直接播放給使用者。
    • 實際效果:完成一個「講話→理解→查資料→講回來」的完整迴路,不需要外接雲端 TTS。
    • 你可以立刻做的事:
    • 做一個「語音 FAQ 機器人」,接電話後用 TTS 讀出答案。
    • 做桌面語音助理,說出系統通知或報表摘要。

    適合誰用:三種典型場景

    1. 客服/熱線:電話接起來就有語音機器人

    問題情境:

    • 只想讓機器人先接電話、回答常見問題或先收集基本資料,但不想把所有通話丟到雲端 AI。

    moonshine 的用法:

    • 把語音輸入接到電話系統的音訊流(VoIP/SIP 方案都可),用 STT 轉文字。
    • 用意圖辨識判斷是「查訂單」「問營業時間」「真人客服」。
    • 走不同後端 API,最後用 TTS 回覆。

    你可以立刻做的實驗:

    • 先不接真正電話,用錄音檔或麥克風假裝客戶提問,串一個「FAQ 搜尋 API」,測試回答流程。

    2. 語音面板:替既有系統加一層「講話就能操作」

    問題情境:

    • 你有一套 SaaS 或內部系統(CRM、ERP、工單系統),想讓使用者用「語音」查資料、下指令,但不想大改前端。

    moonshine 的用法:

    • 在桌面 app 或 web 前端旁放一個小語音代理程式:
    • 監聽麥克風 → STT → 判斷意圖 → 呼叫既有 REST API → 整理結果 → TTS 講回來或貼在 UI。

    你可以立刻做的實驗:

    • 選一個已有的 REST API(例如:查客戶資訊),用下方「10 行程式碼」範例改成語音查詢。

    3. IoT/嵌入式:低資源設備上的離線語音控制

    問題情境:

    • 想做離線語音控制:開關設備、切換模式,但硬體算力有限、網路不穩。

    moonshine 的用法:

    • 把精簡版模型放在裝置上(例如 ARM 單板機),只做幾個固定意圖:
    • 「開燈」「關燈」「設定 25 度」等,直接對接硬體控制程式。

    💡 關鍵: 在 IoT 裝置離線情境下,moonshine 可只保留少數固定意圖,大幅降低對算力與網路的依賴。

    你可以立刻做的實驗:

    • 在一台樹莓派或小型工控機上跑最簡 demo,先做「聽到關燈就印出 turn_off_light」的文字,再接上 GPIO 控制。

    怎麼開始:從 GitHub clone 到第一個語音 agent

    💡 關鍵: 從 git clone 到可用 demo,大致只需一次編譯與模型下載,就能完整體驗整條語音 pipeline。

    1. 先把專案拉下來、編譯成功

    1. 安裝基本依賴(以 Ubuntu 為例):

    bash
    sudo apt update
    sudo apt install -y git cmake build-essential

    1. Clone 專案:

    bash
    git clone https://github.com/moonshine-ai/moonshine.git
    cd moonshine

    1. 編譯:

    bash
    mkdir build && cd build
    cmake ..
    make -j$(nproc)

    完成後,你會得到可以執行的示範程式(名稱以官方 repo 為準,一般會有 demo/example 可跑)。

    2. 跑最簡 demo:確認 STT / TTS pipeline

    官方 repo 一般會提供類似:

    ./moonshine_demo --input mic --output speaker
    

    典型流程會是:

    1. 啟動程式,指定輸入為麥克風、輸出為喇叭。
    2. 程式下載或載入預設 STT/TTS 模型(通常第一次跑會需要網路)。
    3. 你講一句話,終端機顯示辨識出的文字,並用 TTS 回覆一句預設回答。

    具體參數以官方 README 為準,重點是:先確認你機器上的音訊裝置、模型下載都 OK。

    3. 配置模型:STT / TTS / Intent 拆清楚

    在實際專案中,你要決定三件事:

    1. STT 模型:
    2. 選語系(中文/英文等)和大小(依你設備算力)。
    3. moonshine 通常會支援多種 backend,可以在 config 檔或啟動參數指定。
    4. TTS 模型:
    5. 選擇語音風格(男聲/女聲)和延遲表現。
    6. 在設定中指定 model path 或使用預設 URL 拉取。
    7. Intent 模型或規則:
    8. 簡單做法:先用關鍵字+正則,把意圖分成幾類。
    9. 進階做法:接上本地 LLM(例如使用你現有的推論服務)做意圖分類。

    你可以建立一個簡單的 config.json:

    {
      "stt_model": "models/stt_zh_small.bin",
      "tts_model": "models/tts_zh_small.bin",
      "intent_backend": "http://localhost:8000/intent"
    }
    

    程式啟動時讀取這個 config,就能自由替換模型和意圖服務。

    4. 10 行程式碼:把任何 REST API 包成語音代理

    以下用「C++ + moonshine + 一個任意 REST API」示意,把核心流程壓縮成約 10 行邏輯。實際使用時需依官方 API 做正確呼叫。

    #include "moonshine.h"      // 假設提供 STT / TTS 接口
    #include <httplib.h>         // 用任意 HTTP client
    
    int main() {
        MoonshineAgent agent{"config.json"};              // 載入 STT/TTS 設定
        httplib::Client api("https://api.yourservice.com");
    
        while (true) {
            std::string text = agent.listen();             // 1. 麥克風→文字
            auto res = api.Get("/search?query=" + text);  // 2. 呼叫任意 REST API
            std::string reply = res->body;                 // 3. 取回文字結果
            agent.speak(reply);                            // 4. TTS 語音回覆
        }
    }
    

    這個基本版就已經是一個「語音代理壓在你自己的後端」:

    • 你說話 → STT -> text
    • 丟到你預先寫好的 API(可以是 FAQ 搜尋、工單建立、資料查詢)
    • 回傳文字 → 用 TTS 說回來

    你可以改幾行,就變成不同場景:

    • 客服熱線:把 text 先送進意圖辨識 API,再決定要打哪一個後端。
    • 語音面板:把 reply 不是用 TTS,而是顯示在 UI,TTS 只讀重點。
    • IoT 控制:把 api.Get(...) 換成控制硬體的函式,例如 set_light(false)。

    小結:想自己掌控語音代理,就先把 moonshine 跑起來

    如果你:

    • 不想被雲端 STT/TTS 綁約
    • 想在桌面 app、行動裝置或後端服務內嵌語音代理

    那 moonshine 提供的就是一個單純、可編譯進你程式的 C++ 語音 pipeline。從 GitHub clone 下來,先跑官方 demo,再按照上面範例把你的 REST API 接上去,你就能在一台機器上完成第一個「可用的語音 agent」。

    🚀 你現在可以做的事

    • 前往 moonshine GitHub 專案 clone 並完成一次編譯與官方 demo 執行
    • 寫一個簡單的 config.json,指定本地 STT/TTS 模型與一個測試用意圖服務 endpoint
    • 按照文中「10 行程式碼」範例,挑一個現有 REST API,實作一個可對答的語音查詢小工具
  • 用 Whisper+Ollama 做一個本地語音助理

    用 Whisper+Ollama 做一個本地語音助理

    📌 本文重點

    • 用 Whisper+Ollama 做完全本地語音助理
    • 語音→文字→LLM→語音的完整閉環
    • 30 分鐘內跑起最小可行版本
    • 資料與聲音全留在自己機器上

    一句話就能叫得動電腦,而你的聲音和資料完全留在自己機器上,這就是用 Whisper+Ollama 做本地語音助理要解決的問題。

    參考原文:Build a Fully Local Voice Assistant With Whisper and Ollama(Towards AI)
    https://pub.towardsai.net/build-a-fully-local-voice-assistant-with-whisper-and-ollama-e5e6f713a220


    核心架構:一句話進,AI 一句話回

    這個本地語音助理由三塊組成:

    1. Whisper:把「語音 → 文字」(Speech-to-Text)
    2. Ollama + 本地 LLM:負責理解與生成文字回應
    3. 任一 TTS(Text-to-Speech):把「文字 → 語音」再念出來

    整體流程:

    1. 按快捷鍵開始錄音
    2. Whisper 辨識成文字指令
    3. 文字送到本地 LLM(透過 Ollama)推理
    4. 回傳文字答案,再由 TTS 念出

    💡 關鍵: Whisper+Ollama+TTS 組成「完全本地、無需雲端」的語音互動閉環。

    下文會先講三個核心功能,再看哪些人適合用,最後給一個可以在 30 分鐘內跑起來的最小範例。


    核心功能:你可以用聲音做什麼

    1. 聲控指令:一句話叫電腦做事

    你可以用自然語言下達指令,背後由 LLM 把「人話」轉成實際操作(shell 指令、API 呼叫或執行特定程式)。

    可做的事例如:

    • 「幫我開啟 VS Code 並打開 project 資料夾」
    • 「開始錄音會議,結束時幫我整理重點」
    • 「幫我查今天的天氣,再念給我聽」

    實作上,你可以:

    • 在 LLM 回應中約定一個格式,例如輸出 {"action": "open_app", "target": "VSCode"}
    • 程式解析 JSON,對應到不同的系統操作(Python 用 subprocess、Node 用 child_process)

    2. 問答與解說:本地 ChatGPT,用嘴巴問

    Ollama 支援多種本地模型(如 Llama、Qwen),你可以當成「只在本地跑的 ChatGPT」:

    • 「用白話講一次這段程式在做什麼」
    • 「幫我設計一個 3 天東京行程,預算一天 5000 台幣」
    • 「這篇英文信幫我改寫得更禮貌」

    如果你在意隱私(公司機密、未發表研究),這類內容只會停留在你的機器,不會上雲端。

    💡 關鍵: 對隱私敏感的程式碼、文件與會議內容,都可以在本地模型中處理而不外流。

    3. 筆記與總結:會議錄完直接變摘要

    結合 Whisper 長錄音能力,你可以:

    • 開會時一直錄音,會後自動產出:
    • 決議事項
    • 待辦清單
    • 各參與者的責任分工
    • 學習影片邊聽邊錄,最後生成「重點整理 + 閱讀筆記」

    做法:

    1. 持續錄音,分段送 Whisper 辨識
    2. 把完整文字餵給 LLM,提示詞(prompt)中要求輸出特定格式:例如「請用 5 點整理會議重點,並列出行動項目」

    適合誰用:具體場景示例

    1. 常開線上會議的知識工作者

    使用方式:

    • 開會前按快捷鍵啟動錄音
    • 會議中不必手寫紀錄
    • 開完會輸出「摘要+待辦」,貼回 Notion / Obsidian

    好處:

    • 不用依賴雲端錄音服務
    • 內部機密內容留在公司內網或個人電腦

    2. 開發者的語音 Coding 小助手

    使用方式:

    • 「幫我生成一個 Python 函數,讀取 CSV 並輸出 JSON」
    • 「這段錯誤訊息說什麼?幫我猜可能原因」
    • 「把這段程式重構成 class 寫法」

    你可以直接把 LLM 回應輸出到檔案,或搭配編輯器 API 完成簡單的自動插入。

    3. 家庭中控 / 桌面自動化

    使用方式:

    • 「關掉 Spotify,改播 YouTube 音樂」
    • 「打開家裡 NAS 的網頁介面」
    • 「查一下電價 API,現在是不是離峰」

    背後是:

    • LLM 產生要呼叫的 API 名稱 + 參數
    • 程式把它映射到實際的 REST API or Shell 指令

    工具比較:Whisper、Ollama、TTS

    名稱 核心功能 免費方案 適合誰
    Whisper 語音轉文字(STT) 開源、免費 要離線語音辨識的人
    Ollama 管理與執行本地 LLM 開源、免費 想在本地跑各種模型的人
    Coqui TTS 本地語音合成(TTS) 開源、免費 想客製化聲音的開發者
    pyttsx3 / edge-tts 簡單 TTS,快速上手 免費 只要能聽到回應即可的人

    Whisper GitHub:https://github.com/openai/whisper
    Ollama 官網:https://ollama.com


    怎麼開始:30 分鐘跑起一個最小版本

    下面以 Python+Whisper+Ollama+簡單 TTS 為例,目標是做到:

    按快捷鍵 → 說話 → AI 在本地回答並念出來

    💡 關鍵: 只要有 8GB RAM 和 Python 環境,大多數電腦在約 30 分鐘內就能完成這套本地語音助理的基本版。

    1. 最小硬體與環境需求

    • 作業系統:macOS / Linux / Windows(建議 10 以上)
    • RAM:至少 8 GB(12–16 GB 更順)
    • GPU:有當然更快,沒有也可跑小模型
    • Python 3.10+(或 Node 也可以,本文用 Python)

    2. 安裝 Ollama 與模型

    1. 到 https://ollama.com 下載並安裝
    2. 開啟終端機,拉一個小模型(例如 llama3.2 或 qwen2.5):
    ollama pull llama3.2
    # 或
    ollama pull qwen2.5
    
    1. 測試一次:
    ollama run llama3.2
    

    能對話就表示後面 Python 可以直接透過 HTTP 使用它。

    3. 安裝 Whisper 與 TTS

    建立虛擬環境(可選,但建議):

    python -m venv venv
    source venv/bin/activate  # Windows: venv\Scripts\activate
    

    安裝必要套件:

    pip install openai-whisper sounddevice numpy requests pyttsx3
    

    說明:

    • openai-whisper:Whisper STT
    • sounddevice:錄音
    • pyttsx3:離線 TTS(Windows/macOS/Linux 都可用)
    • requests:呼叫 Ollama HTTP API

    4. 最小可行 main.py

    下面是一個簡化範例:按 Enter 開始錄音,Ctrl+C 結束程式。你可以之後再綁定系統快捷鍵(如 AutoHotkey、Karabiner)。

    import sounddevice as sd
    import numpy as np
    import whisper
    import requests
    import pyttsx3
    
    MODEL_NAME = "llama3.2"  # 或改成 "qwen2.5" 等你已拉下的模型
    OLLAMA_URL = "http://localhost:11434/api/generate"
    
    whisper_model = whisper.load_model("small")  # 可換 tiny / base / small / medium
    engine = pyttsx3.init()
    
    SAMPLE_RATE = 16000
    DURATION = 5  # 錄音秒數,可改成你想要的
    
    
    def record_audio(duration=DURATION):
        print("開始錄音,請說話...")
        audio = sd.rec(int(duration * SAMPLE_RATE), samplerate=SAMPLE_RATE, channels=1)
        sd.wait()
        print("錄音結束")
        return np.squeeze(audio)
    
    
    def speech_to_text(audio):
        print("正在轉文字...")
        result = whisper_model.transcribe(audio, fp16=False)
        text = result["text"].strip()
        print(f"你說:{text}")
        return text
    
    
    def call_ollama(prompt):
        print("正在思考...")
        resp = requests.post(
            OLLAMA_URL,
            json={"model": MODEL_NAME, "prompt": prompt},
            stream=False,
        )
        data = resp.json()
        answer = data.get("response", "")
        print(f"AI:{answer}")
        return answer
    
    
    def speak(text):
        engine.say(text)
        engine.runAndWait()
    
    
    if __name__ == "__main__":
        try:
            while True:
                input("按 Enter 開始錄音(Ctrl+C 結束):")
                audio = record_audio()
                text = speech_to_text(audio)
                if not text:
                    continue
                answer = call_ollama(text)
                speak(answer)
        except KeyboardInterrupt:
            print("\n結束程式")
    

    執行:

    python main.py
    

    流程:

    1. 按 Enter → 錄音 5 秒
    2. Whisper 轉文字 → 顯示你說的話
    3. 文字送到 Ollama → LLM 回答
    4. pyttsx3 把文字念出來

    你已經完成一個基本版「本地語音 ChatGPT」。接下來就可以:

    • 把錄音時間改成動態(按住鍵才錄)
    • 在 call_ollama 的 prompt 中加入系統指令,例如:「你是一個會輸出 JSON 指令的系統助手」
    • 在 answer 中解析 JSON,呼叫不同的系統功能

    換成本地 Qwen、Llama 模型與低配機調整建議

    換模型:Qwen、Llama 等

    Ollama 已經預設支援多個模型,換模型只要:

    1. 先拉模型:
    ollama pull qwen2.5
    ollama pull llama3.1
    
    1. 把 MODEL_NAME 改成相對應名稱,例如:
    MODEL_NAME = "qwen2.5"
    # 或
    MODEL_NAME = "llama3.1"
    
    1. 重新執行 main.py 即可。

    低配機(8GB RAM / 無 GPU)調優建議

    • Whisper 模型:改用 tiny 或 base:
      python
      whisper_model = whisper.load_model("tiny")
    • LLM 模型:優先選擇 *-mini 或 3B 以內的小模型(例如 llama3.2 small 版)
    • TTS:選 pyttsx3 這種輕量離線 TTS,避免重型神經網路 TTS
    • 錄音長度:縮短單次錄音(例如 3–5 秒),減少 STT 負載
    • 批次模式:需要長會議紀錄時,可先用系統錄音軟體錄整段,之後分段丟給 Whisper 處理

    總結:把「叫電腦做事」變成一句話

    你現在已經有一套可以在本地跑的語音助理:

    • Whisper 負責聽懂你說什麼
    • Ollama+本地模型負責思考與生成回應
    • TTS 負責把答案念出來

    從這個最小版本開始,你可以一步步加上:「控制應用程式」、「呼叫 API」、「自動整理會議紀錄」,最後變成一個完全客製化的本地語音中控系統。

    🚀 你現在可以做的事

    • 安裝 Ollama 並拉下 llama3.2 或 qwen2.5 模型,在終端測試對話
    • 建立 Python 虛擬環境,安裝 openai-whisper、sounddevice、pyttsx3 等套件後跑起 main.py
    • 改寫 call_ollama 部分,讓回應輸出 JSON 指令,開始用語音控制你的桌面或 API
  • 用 AVA 自架語音總機

    用 AVA 自架語音總機

    📌 本文重點

    • AVA 可直接接在既有 Asterisk/FreePBX 上
    • 先用雲端 STT/LLM/TTS 做 PoC 再考慮本地化
    • 適合中小企業與研發團隊快速測試語音 AI 總機

    AVA 是一套能接在 Asterisk/FreePBX 上的開源語音客服引擎,讓你不用買 SaaS,也能自己搭一個會接電話、回答問題、轉分機的 AI 總機。

    想先看專案,可直接開 AVA GitHub。如果你手上已經有 FreePBX,這類型工具最實際的價值不是「聊天」,而是把既有電話流量接進 STT、LLM、TTS 流程,先做出可測的 PoC,再決定要不要擴到正式客服。


    核心功能

    1. 直接接進 Asterisk,不用重做整套電話系統

    AVA 的架構很直白:Asterisk 用原生 Audiosocket 或 RTP 收到來電,把音訊送到 Python 引擎;Python 再依序呼叫語音轉文字(STT)、大型語言模型(LLM)、文字轉語音(TTS),最後把回覆送回通話。

    這代表你可以保留現有 SIP、分機、IVR 與 FreePBX 管理介面,只替換「講話的那一段」。

    2. 雲端模型先上線,本地模型後續再換

    AVA 內建支援 OpenAI、Gemini、Grok、ElevenLabs,也能自訂 STT/LLM/TTS 組合。最快的做法是先用雲端 API 跑第一版,例如 OpenAI 做 STT+LLM、ElevenLabs 做 TTS;如果後續遇到隱私或成本問題,再改成本地模型。

    💡 關鍵: 先用雲端組合上線 PoC,再視隱私與成本需求改成本地模型,是風險最低的導入路徑。

    官方也提到,若有 25GB 以上 GPU,可走全本地即時語音代理。

    3. 適合做可控腳本,不只自由聊天

    電話客服的重點不是模型多聰明,而是流程穩不穩。AVA 適合把提示詞、FAQ、分機規則、營業時間、留言流程都寫成明確腳本,例如:

    • 「辨識來意後轉接 201 業務部」
    • 「下班時間改成留言並發通知」

    先把流程規則化,測試會比直接放任模型自由發揮穩很多。


    適合誰用

    如果你是中小企業 IT、SI、通訊整合商,手上已有 Asterisk 或 FreePBX,AVA 很適合拿來做低成本 PoC:一台伺服器、一組 API key、幾個分機規則,就能讓公司總機先有基本問答與轉接能力。

    💡 關鍵: 利用現有 Asterisk/FreePBX,只要加一台伺服器與一組 API key,就能快速驗證語音 AI 總機可行性。

    如果你是實驗室或研發團隊,AVA 的價值在於可替換性。你可以先用雲端模型驗證流程,再逐步把 STT、LLM、TTS 換成本地推論,測試隱私保護、工具呼叫、資料落地等需求。

    這比直接綁定單一 SaaS 平台更容易控制。

    下面這組搭配最適合先做測試:

    名稱 核心功能 免費方案 適合誰
    AVA 串接 Asterisk 的語音代理框架 開源免費 要自架語音客服的人
    OpenAI / Gemini / Grok STT、LLM 問答 多數為試用額度或按量計費 想最快上線 PoC 的團隊
    ElevenLabs 高品質英文與多語 TTS 有試用額度 重視語音自然度的客服場景

    怎麼開始

    最快路徑是用 Docker 把 AVA 部署在一台 Linux 伺服器,並接到現有 FreePBX。實作上可照這個順序做:

    1. 準備一台可連到 Asterisk 的伺服器,先安裝 Docker。
    2. 從 AVA GitHub 依範例啟動容器,填入 OpenAI 或 Gemini、ElevenLabs 的 API key。
    3. 在 FreePBX 建一個測試路由,讓指定 DID 或分機把來電導到 Audiosocket/RTP 對應的 AVA 服務。
    4. 先只做一個簡單腳本:自我介紹、詢問需求、依關鍵字轉接分機或播放 FAQ。
    5. 拿真實電話測試 20 到 30 通,記錄辨識錯誤、等待時間與轉接成功率,再調提示詞。

    💡 關鍵: 先用 20–30 通真實來電測試腳本與提示詞,比盲目擴大量更能看出系統穩定度與實用性。

    你可以先做兩個最有感的場景。

    第一個是公司語音 IVR:例如「按 1 找業務」改成自然語音,來電者直接說「我要報價」就轉接業務分機,同時能回答地址、營業時間、付款方式。

    第二個是 24 小時留言與簡單 FAQ:下班後由 AI 先接聽,回答常見問題,必要時收姓名、電話、需求摘要,再寄送到信箱或寫入工單。


    成本與進階玩法

    PoC 階段最主要的成本是語音與模型 API,用量低時通常比買整套 SaaS 便宜,尤其你已經有 Asterisk 時更明顯;但一旦通話量大,TTS 與即時 LLM 成本會開始浮現,所以建議先限制場景,只做總機問答、留言與分流。

    如果你有隱私要求,下一步就是把部分流程換成本地模型:例如本地 STT、本地 LLM,只把 TTS 留在雲端,或直接全本地化。

    另一個值得做的進階項目是客製對話腳本,把「業務、客服、總務」拆成不同代理,分別設定提示詞、FAQ 和轉接規則,測試效果會比單一通用客服更好。

    對已經有電話系統的團隊來說,AVA 最實際的切入點不是一次取代客服,而是先把一條來電流程自動化,讓你用自己的基礎設施,快速驗證語音 AI 到底能不能真正接電話。

    🚀 你現在可以做的事

    • 打開 AVA GitHub 專案頁,閱讀 README 並確認環境需求
    • 在現有 FreePBX 上規劃一條測試路由,準備 1 個具代表性的來電場景腳本
    • 申請 OpenAI/Gemini 與 ElevenLabs 的 API key,實作一個 20–30 通的 PoC 測試流程
  • 在手機跑 27B 模型:Bonsai 27B 實戰上手

    在手機跑 27B 模型:Bonsai 27B 實戰上手

    📌 本文重點

    • 27B 模型壓到 3.8GB
    • 本地跑在 iPhone 與瀏覽器
    • 數學與程式推理仍可用
    • 適合隱私優先的 AI 場景

    用一句話說完:Bonsai 27B 讓一個原本要 50GB 以上的大型推理模型,縮到不到 4GB,在你的 iPhone 或瀏覽器裡本地跑推理。

    原始資訊與 Demo:


    核心功能:為什麼 1-bit、4GB、WebGPU 很關鍵?

    1. 1-bit dense 量化:54GB 壓到 3.8GB,還保留 90% 能力

    Bonsai 27B 原始是 27B 參數的大模型,正常 fp16 大概要 50GB 以上。PrismML 用自家的 1-bit dense 量化,直接把模型縮到約 3.8GB(-93%),官方與社群測試顯示:

    • 整體表現:約保留 90% 原始性能
    • 在數學與程式碼推理上的分數,幾乎不受影響

    💡 關鍵: 27B 級模型從 50GB+ 壓到 3.8GB,代表大型模型首次更接近一般裝置可本地部署的範圍。

    這對你代表什麼?

    • 一般高階筆電、桌機的 GPU/WebGPU 就能跑 27B 級模型
    • iPhone 等手機只要有足夠 RAM,也能載得下整個模型
    • 做產品 PoC 時,不用再想「我要租幾張雲端 GPU」才能展示效果

    你可以立刻做的事:

    2. 本機 / 手機 / 瀏覽器推理:速度與隱私的平衡點

    Bonsai 27B 的壓縮搭配 WebGPU + 客製 Kernel,讓它可以在:

    • 桌機瀏覽器(Chrome、Edge、Arc 等支援 WebGPU 的版本)直接跑
    • iPhone 上透過支援 WebGPU 的瀏覽器或 App 跑本地推理

    實際體感: 依硬體而異,但大致區間如下:

    • 答案生成速度:中高階筆電可達 20~40 tokens/s,接近雲端中階模型
    • 手機上:會慢一些,但仍能用於聊天、寫作輔助、簡易程式碼推理

    💡 關鍵: 本地推理不只是能跑,速度已進到可互動使用的區間,隱私與延遲也因此開始有實際優勢。

    隱私優勢:

    • 所有輸入(聊天內容、筆記、程式碼)都留在裝置上,不經過雲端 API
    • 適合公司內部敏感資料、個人私密日記、會議記錄摘要等情境

    你可以立刻做的事:

    • 打開支援 WebGPU 的瀏覽器,跑官方 Demo:確認你的硬體大概能跑到什麼速度(Demo 入口通常在 PrismML 新聞頁或 Hugging Face Space)。

    3. 數學與程式碼推理表現:不只是「能跑」,而是「能用」

    依據 PrismML 自家基準測試(見 Reddit 討論:https://www.reddit.com/r/LocalLLaMA/comments/1uwm2hd/prismmls_bonsai27b_benchmarks/),Bonsai 27B 的量化版本:

    • 在數學、程式碼題目上的分數,與原始模型接近
    • 部分測試甚至優於廣為討論的 Qwen 3.7 27B 量化版本

    💡 關鍵: 有趣的是,這類極端壓縮不一定先犧牲數學與程式碼推理,實際上它在這兩類任務仍維持可用水準。

    實際體感上,它適合:

    • 解 LeetCode 等級的題目、協助理解他人程式碼
    • 做數學證明草稿、檢查推理步驟是否有漏洞

    你可以立刻做的事:

    • 準備一段你自己寫的程式碼或演算法題目,在 Demo 裡測試它的 debug 能力,看它能不能說出具體修改建議。

    適合誰用?具體場景與做法

    1. 個人使用:離線寫作、私密筆記與聊天

    場景:

    • 不想把日記、心理對話丟到雲端模型
    • 在飛機、車上等無網路環境寫作

    可以怎麼用:

    • 在桌機瀏覽器開 Bonsai 27B WebGPU Demo,寫文章時讓它幫你改標題、想小節架構
    • 在支援的手機上安裝對應 App 或透過瀏覽器,做離線聊天與筆記整理

    2. 開發者:簡易 coding 助手與邊緣 AI PoC

    場景:

    • 做一個「本地程式碼助手」Side project
    • 想給客戶看「產品內嵌 on-device 聊天/推理」的原型

    可以怎麼用:

    • 使用 Bonsai 27B 的 gguf 版本,搭配像 llama.cpp 或其他本地推理框架,在筆電上跑一個命令列助手
    • 在 Web 前端整合官方 WebGPU 推理程式碼,做一個「瀏覽器內跑的大模型聊天框」,無需後端 GPU

    3. 產品團隊:在 App 裡塞 on-device 聊天 / 推理

    場景:

    • 筆記 App 想加「在本機摘要筆記」功能
    • 知識庫產品想做「邊緣 FAQ 助手」,部署在客戶內網而不是雲端

    可以怎麼用:

    • 以 WebGPU 版 Bonsai 27B 做前端推理引擎,後端只處理權限與資料存取
    • 在 iOS App 裡預載或動態下載壓縮模型,讓使用者自主選擇是否開啟「完全本地 AI 模式」

    什麼時候考慮不用它?

    • 若你需要 GPT-4 級別的長上下文寫作、極高準確度的工具調用
    • 若手機使用者硬體普遍較舊,無法提供足夠 RAM 或 WebGPU 支援

    怎麼開始:從 WebGPU Demo 到 iPhone 實跑

    Step 1:在桌機用 WebGPU Demo 跑起來

    1. 確認瀏覽器支援 WebGPU
    2. Chrome / Edge:版本需在 113+,建議更新到最新穩定版
    3. 在 chrome://flags 搜尋 WebGPU,確保已啟用(某些平台預設已開)

    4. 進入 Demo 網頁

    5. 從 PrismML 新聞頁:https://prismml.com/news/bonsai-27b 找到 WebGPU Demo 連結
    6. 或在 Hugging Face 上搜尋 Bonsai 27B WebGPU 找到 Space

    7. 測試推理

    8. 選擇 Bonsai-27B 1-bit 模型版本
    9. 輸入一個你熟悉的程式題目或寫作題目,觀察回答速度與品質

    常見坑:若載入卡住或速度極慢,通常是 WebGPU 未啟用,或顯示卡太舊。換瀏覽器或更新驅動是第一步。

    Step 2:在 iPhone 嘗試跑 Bonsai 27B

    目前 iPhone 端的整合仍在快速變動階段,Apple 也被報導正在測試 PrismML 技術(參考:https://www.reddit.com/r/LocalLLaMA/comments/1ux4cn2/apple_in_talks_with_startup_prismml_that_shrinks/)。以下是一般建議路線:

    1. 確認機型與系統
    2. 建議使用 A17 / M 系列晶片的機型,RAM 越大越好(Pro 機型優先)
    3. iOS 更新到最新版本,以取得最佳 WebGPU / Metal 支援

    4. 嘗試透過瀏覽器 Demo

    5. 使用支援 WebGPU 的 iOS 瀏覽器(未來 Safari 正式支援後會更穩定)
    6. 開啟 Bonsai 27B Web Demo,選最低階參數設定,測試生成速度

    7. 留意記憶體與耗電

    8. 模型雖然不到 4GB,但推理仍會吃 RAM;建議在單一 App 裡跑,不要開太多背景程式
    9. 長時間推理會發熱,適合短對話與輕量寫作,而非長時間批量任務

    常見坑:

    • 推理中 App 被 iOS 回收:代表 RAM 不足,只能調小 context 長度或改用桌機。
    • 首次載入模型時間偏長:正常現象,可考慮在 App 中做「背景預載」。

    Step 3:整合到你的應用(基本架構示意)

    以 Web 應用為例,一般做法是:

    使用者瀏覽器
     ├─ UI:聊天框 / 筆記編輯器
     ├─ WebGPU 推理:載入 Bonsai 27B 壓縮模型
     └─ 本地記憶體:暫存對話與提示
    
    後端伺服器
     ├─ 使用者認證 & 權限
     ├─ 資料索引(向量庫、文檔)
     └─ 僅在用戶同意時返回資料,讓前端本地推理
    

    你可以:

    • 直接參考 PrismML 提供的 WebGPU Kernel 實作,把它包成一個 JS/TS SDK
    • 將模型檔放在 CDN,首次使用時下載到瀏覽器 IndexedDB 或 App 沙盒中

    本地 Bonsai 27B vs 雲端 API:成本與隱私快速比較

    項目 Bonsai 27B 本地推理 雲端 API(如 GPT-4)
    成本 一次下載模型,之後幾乎零邊際成本,主要是硬體耗電 依 tokens 計費,流量大時費用顯著
    延遲 裝置好時可達 20–40 tokens/s,無網路也能用 需經網路與伺服器排隊,遇高峰時延遲高
    隱私 所有內容留在本機,適合敏感資料 對話上傳到雲端,需信任供應商
    維護 需自己管理模型更新與相容性 供應商幫你維持最新模型與基礎設施

    簡單判斷:

    • 若你重視隱私、成本可控、願意接受略低於頂級雲端模型的效果,Bonsai 27B 是合適的本地方案。
    • 若你的產品主打極高準確度、長上下文、工具調用整合,仍需要雲端 API 作為主力,Bonsai 27B 可做輔助或離線備份模式。

    小結:下一步你可以做什麼?

    1. 用桌機開 Bonsai 27B WebGPU Demo,測試寫作與程式碼題目,感受性能。
    2. 若你是開發者,下載 Hugging Face 量化模型,在本地框架中跑一個簡單聊天助手。
    3. 思考你的產品裡哪個功能最需要「本地推理+隱私」,從那一點開始嘗試嵌入 Bonsai 27B。

    🚀 你現在可以做的事

    • 打開 PrismML 官方新聞頁,直接進 WebGPU Demo 測你的裝置速度
    • 到 Hugging Face 搜尋 prism-ml/Bonsai-27B-gguf,下載量化模型做本地測試
    • 拿一段你自己的程式碼、筆記或寫作題目,驗證它是否符合你的實際場景
  • OvisOCR2:在筆電本地跑的文件結構化神器

    OvisOCR2:在筆電本地跑的文件結構化神器

    📌 本文重點

    • OvisOCR2 在本地將整份 PDF 直接轉成結構化 Markdown
    • 對表格、公式與讀取順序有針對性優化
    • 適合內網文件、學術論文與財報合約結構化
    • 0.8B 模型可在筆電或小伺服器上順跑

    OvisOCR2 的定位很單純:在你自己電腦上,把整份 PDF / 掃描件直接變成乾淨、有結構的 Markdown,不丟雲端、不拆頁、不東拼西湊。

    模型頁面:https://huggingface.co/ATH-MaaS/OvisOCR2

    Reddit 討論串:https://www.reddit.com/r/LocalLLaMA/comments/1uv88co/ovisocr2_a_promising_08b_local_document_parser/


    核心功能:從「整頁」到「可用的 Markdown」

    這邊只看跟你工作直接有關的 3 件事:

    1. 端到端整頁解析:丟 PDF / 圖片,直接出 Markdown

    OvisOCR2 是基於 Qwen3.5-0.8B 的端到端文件解析模型,不是傳統那種「先做 OCR 再用別的模型理解」的兩段式流程。

    它的輸出直接是 Markdown,包含:

    • 標題、段落層級(#、## 等)
    • 粗體、斜體等基本格式
    • 清單、引用等常見排版

    你可以馬上做的事:

    • 把公司內部的 PDF 手冊、SOP 丟進去,拿到 可編輯的 Markdown,再丟進 Notion、Confluence 或 Git repo 管理
    • 把舊專案的掃描說明書轉成文字,方便全文搜尋

    模型在常見文件基準上表現:

    • OmniDocBench v1.6:96.58 分
    • PureDocBench:75.06 分

    💡 關鍵: 在標準文件基準上拿到 90+ 分,代表它對一般報表與說明文件的結構理解已足夠直接納入實際工作流程測試。

    這代表它對一般報表、說明文件的結構理解已經有相當水準,適合直接放進工作流程測試。

    2. 表格、公式還原:不只讀得懂,還能「還原格式」

    OvisOCR2 的重點不是只認出字,而是把表格和公式變回「可運算」的東西:

    • 表格 → Markdown 表格(| a | b | 那種),貼到 Notion、GitHub README 都能正常顯示
    • 公式 → 以 LaTeX 或接近格式輸出,方便貼回論文、簡報或 Obsidian

    你可以馬上做的事:

    • 把財報 PDF 轉成 Markdown,表格直接貼到 Excel / Google Sheets 做後續處理
    • 把學術論文中的公式拉出來,貼回 LaTeX 文件或投影片,不用一條條重打

    3. 讀取順序:不再被兩欄排版搞瘋

    很多 PDF(尤其是:財報、學術期刊、政府報告)都有這些特徵:

    • 雙欄排版
    • 頁首頁尾反覆出現的小字
    • 複雜圖文混排

    傳統 OCR 常會變成:

    • 把左欄整段讀完,再接右欄,導致段落亂序
    • 頁碼、版權資訊被插進正文裡

    OvisOCR2 針對「讀取順序」有訓練,能比較好地還原成人類閱讀的順序,包括:

    • 正文優先,頁碼/頁眉多半排除或放在不干擾的位置
    • 圖表標題和內容靠在一起,不會被打散

    你可以馬上做的事:

    • 把年度報告、研究報告丟進去,得到可以直接丟給大語言模型總結的乾淨 Markdown
    • 省掉「先用 Acrobat 導出文字再手動整理」的痛苦步驟

    適合誰用:三種典型場景

    1. 公司內網文件數位化:需要「不出內網」的方案

    如果你在這些情境:

    • 金融、醫療、政府等對資料敏感的產業
    • 有一堆 PDF 合約、掃描件、紙本表單
    • 不允許把文件丟到雲端 OCR 服務

    OvisOCR2 很適合當成內網文件結構化引擎:

    • 0.8B 模型,記憶體需求相對溫和,可以放在:
    • 中小型伺服器
    • 部門共用工作站
    • Apache 2.0 授權,方便整合到自家系統

    可以實做的具體流程:

    1. 把部門的 PDF 檔放進內網檔案伺服器
    2. 用 OvisOCR2 解析成 Markdown / JSON
    3. 把結果丟進 ElasticSearch / OpenSearch / Meilisearch 做全文搜尋
    4. 再接一個內網 LLM(例如本地 Qwen 或 Llama)做問答

    2. 學術論文整理:從 PDF 到筆記庫

    研究生、工程師、PM 常見的需求:

    • 一次下載一堆 PDF 論文
    • 想要在 Obsidian / Notion / Logseq 裡統一管理

    OvisOCR2 可以幫你:

    • 把論文的標題、章節、公式、圖表說明整合成 Markdown
    • 保留結構(例如 # Abstract、## Method),方便之後全文搜尋或做自動總結

    可以實做的工作流:

    1. 建一個 papers/ 資料夾放 PDF
    2. 寫一個小腳本,用 OvisOCR2 把每篇論文轉成 .md
    3. 輸出時附上原始 PDF 路徑、bibtex key 等 metadata
    4. 直接把 .md 丟進 Obsidian 資料庫

    3. 財報與合約結構化:先結構化,再丟給 LLM

    財務、法務、投研人員常做的事:

    • 從財報裡抓關鍵表格
    • 從合約裡抓特定條款(付款條件、違約金…)

    OvisOCR2 可以先把內容整理成清楚的 Markdown / 結構化文本,接著:

    • 用本地或雲端 LLM 做:
    • 指標彙總
    • 條款比較
    • 風險條款標記

    這樣的好處是:

    • 原始 PDF 不用離開你的環境
    • 只有經過清理的文字,才會送到雲端 LLM(如果你選擇這樣做)

    為什麼 0.8B 模型適合在筆電或小伺服器上跑?

    0.8B(8 億)參數的級別,落在一個很實用的區間。

    • 硬體需求友善:
    • 8–12GB VRAM 的顯示卡即可順跑
    • 或者用 CPU 推理,速度會慢一些,但足夠跑批次任務
    • 記憶體壓力較低:
    • 不需要 80GB A100 等級的 GPU
    • 適合中小企業和個人開發者

    💡 關鍵: 0.8B 等級模型在 8–12GB 顯示卡上即可運行,讓「整份文件結構化」這種原本需要大型服務的工作,可以在一般筆電或中小企業伺服器內網完成。

    這個大小對「文件結構化」剛好夠用:

    • 任務相對專一(解析版面與內容)
    • 不需要像聊天大模型那樣超強的開放式生成能力

    如果你已經有一台:

    • RTX 3060 / 4060 級別的筆電
    • 或一台 16–32GB RAM 的小伺服器

    基本上都可以實際跑起來做實驗。


    怎麼開始:從 Hugging Face 到「丟 PDF 拿 Markdown」

    下面給一條最短路徑:不談訓練,只談拿來用。

    步驟 0:你需要準備什麼?

    • 作業系統:Linux / macOS / Windows 都可
    • Python 3.10+(盡量用虛擬環境)
    • 建議有 GPU(但非必須)

    步驟 1:下載模型

    到 Hugging Face 模型頁:

    做兩件事:

    1. 登入 Hugging Face 帳號(免費)
    2. 在本機安裝 huggingface_hub 方便下載:
    ypip install "huggingface_hub[cli]" transformers accelerate
    huggingface-cli download ATH-MaaS/OvisOCR2 --local-dir ./OvisOCR2
    

    如果你不想預先下載,也可以在程式裡直接用模型名稱自動拉取。

    步驟 2:用 vLLM 跑起 OvisOCR2(建議)

    OvisOCR2 支援 vLLM,適合要做批次處理或服務化部署的情境。

    先安裝 vLLM:

    ypip install vllm
    

    啟動一個本地 server(假設你有支援 CUDA 的 GPU):

    python -m vllm.entrypoints.openai.api_server \
      --model ATH-MaaS/OvisOCR2 \
      --port 8000
    

    啟動後,你就有一個 OpenAI 相容 API,可以從任何語言呼叫。

    步驟 3:寫一個「丟 PDF → 拿 Markdown」的小腳本

    以下示範用 Python,把單頁 PDF 先轉成圖片,再送進 OvisOCR2,拿回 Markdown:

    提醒:實務上多頁 PDF 要迭代處理,每頁送一次,最後把 Markdown 串起來。

    安裝必要套件:

    ypip install pillow pypdfium2 requests
    

    簡易腳本(假設 vLLM server 在 http://localhost:8000):

    import base64
    import io
    import requests
    from PIL import Image
    import pypdfium2 as pdfium
    
    OPENAI_API_BASE = "http://localhost:8000/v1"
    OPENAI_MODEL = "ATH-MaaS/OvisOCR2"
    
    
    def pdf_page_to_image(pdf_path, page_index=0):
        pdf = pdfium.PdfDocument(pdf_path)
        page = pdf.get_page(page_index)
        pil_image = page.render(scale=2).to_pil()
        return pil_image
    
    
    def image_to_base64(image: Image.Image) -> str:
        buf = io.BytesIO()
        image.save(buf, format="PNG")
        return base64.b64encode(buf.getvalue()).decode("utf-8")
    
    
    def ovisocr2_parse_image(img: Image.Image) -> str:
        img_b64 = image_to_base64(img)
        payload = {
            "model": OPENAI_MODEL,
            "messages": [
                {
                    "role": "user",
                    "content": [
                        {"type": "text", "text": "Parse this page to Markdown."},
                        {
                            "type": "image_url",
                            "image_url": {"url": f"data:image/png;base64,{img_b64}"},
                        },
                    ],
                }
            ],
        }
    
        resp = requests.post(f"{OPENAI_API_BASE}/chat/completions", json=payload)
        resp.raise_for_status()
        return resp.json()["choices"][0]["message"]["content"]
    
    
    if __name__ == "__main__":
        pdf_path = "sample.pdf"  # 換成你的 PDF 路徑
        img = pdf_page_to_image(pdf_path, page_index=0)
        markdown = ovisocr2_parse_image(img)
    
        with open("output_page1.md", "w", encoding="utf-8") as f:
            f.write(markdown)
    
        print("已輸出:output_page1.md")
    

    改進方向:

    • 迭代所有頁面,輸出成 page_01.md、page_02.md 再合併
    • 把檔名、頁碼寫在 Markdown 裡,方便追溯

    步驟 4:搭配雲端 LLM 的 workflow 範例

    OvisOCR2 本地做的是「結構化清洗」,你可以再串雲端 LLM 做「理解與生成」:

    1. 本地:
    2. OvisOCR2 把 PDF → Markdown
    3. 雲端(例如 OpenAI、Gemini 等):
    4. 把 Markdown 分段丟給 LLM,做:
      • 自動摘要
      • 關鍵條款整理
      • 生成簡報大綱

    好處是:

    • 原始掃描件、敏感欄位留在內網
    • 真正上雲的是整理過的文字,方便做權限控管與脫敏處理

    小結:先用一個資料夾試跑

    最簡單的開始方式:

    1. 選一個專案資料夾(例如 ./docs_to_parse)
    2. 選 10–20 份代表性的 PDF
    3. 用本文的腳本跑一輪,觀察:
    4. 文字正確率
    5. 表格還原情況
    6. 讀取順序是不是能接受
    7. 再決定要不要擴大到整個部門或公司文件庫

    💡 關鍵: 小規模試跑可以快速評估在你實際文件類型上的效果,再決定是否投資整合到正式內網與搜尋系統。

    OvisOCR2 不會替你完成所有事,但可以把「文件數位化+結構化」這一步做得足夠穩定,讓後面的搜尋、分析、LLM 問答都有乾淨的輸入可以用。

    🚀 你現在可以做的事

    • 到 Hugging Face 下載 ATH-MaaS/OvisOCR2,在本機用 vLLM 跑一個測試 API server
    • 選 10–20 份你常用的 PDF(財報、論文、合約),用示範腳本轉成 Markdown 檔觀察品質
    • 把輸出的 Markdown 接到 Obsidian 或 ElasticSearch,試做一個小型「內網知識庫+搜尋/總結」流程
  • Graphify:讓 AI 助手看懂整個專案

    Graphify:讓 AI 助手看懂整個專案

    📌 本文重點

    • Graphify 把整個專案轉成可查詢的知識圖譜
    • 讓 Claude Code、Cursor 等助手理解「整個系統」而非單檔
    • 特別適合接手專案、Code review、排錯與重構場景

    Graphify 就是替 Claude Code、Cursor 等 AI 編碼助手建立專案的知識底層,把程式碼、SQL、腳本、文件通通轉成可查詢的圖譜,讓 AI 回答不再只看單檔,而是理解整個系統。

    專案連結:Graphify-Labs/graphify(GitHub)


    核心功能:把「專案」變成可對話的地圖

    1. 把任何專案資料夾變成知識圖譜

    Graphify 支援:

    • 程式碼:Python、JavaScript 等一般 repo
    • 資料庫:SQL schema
    • 腳本:R、shell scripts
    • 文件:docs、論文
    • 多媒體:圖片、影片(以檔案與路徑資訊的形式收錄)

    實際可做的事:

    1. 選一個專案資料夾,例如 ~/projects/legacy-crm
    2. 讓 Graphify 掃描後生成知識圖譜
    3. 把「圖譜」接到你的 AI 助手,開始用自然語言查專案

    效果:你可以問 AI:

    • 「這個專案所有跟訂單狀態相關的函式和 SQL 表有哪些?」
    • 「從 API 收到請求到入庫,整個流程經過哪些檔案?」

    行動建議:先挑一個你覺得難接手的專案,當作 Graphify 的第一個練習對象。


    2. 一次整合:程式碼 + DB schema + 基礎設施

    Graphify 強調的是「整個系統放進同一張圖」:

    • App code:API、service、models
    • Database schema:tables、relations
    • Infrastructure:scripts、部署設定、CI/CD

    這意味著 AI 助手不只看到某個函式,而是可以沿著圖譜一路追:

    • 「這支 API 最後寫進哪個資料表?」
    • 「這張資料表在哪裡被讀取/更新?」
    • 「這個 Cron job 觸發哪些腳本,再改變哪些表?」

    💡 關鍵: 把代碼、資料庫與基礎設施放進同一張圖,才能讓 AI 追蹤完整的請求與資料流向。

    行動建議:如果你常在大型專案裡迷路,優先把 App code + DB schema 一起餵給 Graphify,請 AI 幫你畫出「從前端到資料庫」的完整路徑。


    3. 支援主流 AI 編碼助手與本地模型

    Graphify 自稱是「AI coding assistant skill」,專門替各種助手提供專案知識底層,目前支援:

    • Claude Code
    • Cursor
    • Codex / OpenCode
    • Gemini CLI
    • 以及其他可透過 CLI / API 串接的助手

    好處是:你不用換開發工具,只是多了一層「專案圖譜」,讓原本的 AI 助手變得更懂上下文。

    行動建議:先選一個你已經在用的助手(例如 Cursor),只做一件事:把 Graphify 生成的圖譜加進你的 Prompt 或工具設定,看 AI 回答專案問題的精準度差異。


    適合誰用:3 個具體場景

    1. 接手大型專案:用 Graphify 做「三小時系統導覽」

    接手舊專案最常遇到:

    • 文件缺失
    • 系統邏輯分散在各層
    • 找不到「這個功能到底怎麼跑」

    操作範例:

    1. 從 Git 拉下專案:

    bash
    git clone <your-legacy-repo>
    cd <your-legacy-repo>

    1. 用 Graphify 掃描整個 repo,生成圖譜(假設有 CLI 指令 graphify scan):

    bash
    graphify scan . -o graph.json

    1. 在 Claude Code 或 Cursor 裡,附上 graph.json(或指向 Graphify server),向 AI 提問:
    2. 「列出與『會員等級計算』相關的所有檔案與流程,並畫文字流程圖。」
    3. 「說明訂單取消從 API 到資料庫寫入的完整路徑。」

    行動建議:把你接手的新專案都跑一次 Graphify,強制自己在第一天就用 AI 做一輪「系統導覽問答」。


    2. Code review:從「看單檔」變成「看整條影響路徑」

    傳統 Code review 很容易只盯著 diff,看不到改動在整個系統的影響。

    用 Graphify 的方式:

    1. 在 PR 對應的分支跑 graphify scan,生成該版本的圖譜。
    2. 在 AI 助手裡,輸入:
    3. 「這個 PR 修改的函式,影響到哪些上游呼叫點與下游資料表?」
    4. 「幫我列出這個改動所有可能破壞的流程。」

    AI 可以沿著圖譜追蹤呼叫鏈、資料流向,給你一份「改動影響報告」,你再決定要多測哪些地方。

    💡 關鍵: 利用圖譜讓 AI 做「改動影響分析」,可以系統性找出需要回歸測試的區域,而不是只憑經驗猜。

    行動建議:選一個你覺得風險高的 PR,讓 Graphify + AI 助手一起做一次「影響分析」,當作試驗。


    3. 排錯與系統重構:先畫圖,再動手

    排錯時最痛苦的是:

    • 找不到錯誤在哪條鏈路上爆
    • 重構時不敢動,怕牽一髮動全身

    Graphify 的知識圖譜可以幫你:

    • 快速列出某個錯誤堆疊涉及的所有節點(檔案、函式、表)
    • 在重構前問 AI:「我要拆分 user_service,請列出所有依賴它的模組與路徑。」

    實戰問句示例:

    • 「根據圖譜,payment_timeout_error 這個錯誤從觸發到記錄經過哪些模組?幫我列出路徑。」
    • 「如果我要把 orders 表拆成兩張表,請告訴我所有讀寫 orders 的程式碼位置。」

    行動建議:下一次遇到棘手 bug,不要先改碼,先用 Graphify + AI 把「錯誤路徑」問清楚,再決定從哪個節點下手。


    工具與助手比較:怎麼搭配使用?

    以下是 Graphify 與常見 AI 編碼助手的定位差異與搭配方式:

    名稱 核心功能 免費方案 適合誰
    Graphify 專案知識圖譜;整合代碼、DB、腳本等 開源,GitHub 可用 想讓 AI 助手「看懂整個專案」的人
    Claude Code 雲端 AI 編碼助手,強自然語言理解 有免費使用額度 想用對話方式改碼/理解代碼的人
    Cursor VS Code 風格編輯器 + AI 補全與聊天 有免費方案 想把 AI 深度融入 IDE 的工程師
    Gemini CLI Google Gemini 命令列助手 有免費配額 喜歡在終端機用 AI 的開發者

    行動建議:先選一個你主要的開發環境(例如 Cursor),再把 Graphify 當成「增強模組」接上去,而不是全部一起嘗試,降低學習成本。


    怎麼開始:從 GitHub 到「可用工作流」

    官方入口:https://github.com/Graphify-Labs/graphify

    以下示範兩個「從零到可用」的最短路徑,以你已有的開發工具為中心來設計。


    工作流 1:接手專案 + Claude Code 問答

    步驟一:安裝與掃描專案

    1. 安裝(假設使用 Python pip,依實際 README 為準):

    bash
    pip install graphify

    1. 進入你的專案目錄,掃描並輸出圖譜:

    bash
    cd ~/projects/legacy-crm
    graphify scan . -o graph.json

    步驟二:把圖譜交給 Claude Code

    1. 在 Claude Code 裡開啟專案,將 graph.json 上傳或貼到系統提示(System Prompt),例如:

    「你可以使用以下專案知識圖譜回答問題。請依圖譜中的檔案關係、表結構與腳本依賴,協助我理解和修改系統。」

    1. 問第一組問題:

    2. 「請整理出『會員等級計算』相關的所有模塊與資料表。」

    3. 「依據圖譜,畫出從前端呼叫到 DB 的完整流程(文字版即可)。」

    做到這一步,你就完成了:接手專案 → 建立圖譜 → 用 AI 做系統導覽 的基本工作流。

    💡 關鍵: 把圖譜丟給 AI 之後,每一個新問題都在累積你對整個系統的結構化理解。


    工作流 2:Cursor 裡做 Code review 影響分析

    步驟一:在 PR 分支生成圖譜

    1. 切換到 PR 對應分支:

    bash
    git checkout feature/new-pricing

    1. 跑 Graphify:

    bash
    graphify scan . -o pr-graph.json

    步驟二:在 Cursor 裡使用圖譜

    1. 打開 Cursor,載入這個專案,並在 AI 設定中把 pr-graph.json 放進系統提示,說明:

    「這是目前分支的專案知識圖譜。做 Code review 時,請根據圖譜分析改動的上游呼叫和下游資料影響。」

    1. 在看 diff 的同時詢問 Cursor:

    2. 「這次修改的 calculate_discount 函式,上游有哪些呼叫者?下游有哪些寫入或查詢動作?」

    3. 「依據圖譜,列出最需要回歸測試的 5 個功能。」

    這樣你就有一套:看 diff → 問圖譜 → 寫測試計畫 的 Code review 工作流。

    行動建議:先把上述其中一個工作流完整跑一次,感受「AI 從看單檔」變成「看整個系統圖」的差異,再決定要不要把 Graphify變成團隊標準工具。


    小結:把 AI 助手升級成「系統顧問」

    Graphify 的本質,是幫你的 AI 助手補上一層「專案整體結構」:

    • 不再只依靠目前開啟的 1–2 個檔案
    • 而是能沿著代碼、資料庫、腳本和設定,追到整條路徑

    如果你已經在用 Claude Code、Cursor 這類助手,下一步值得做的事,就是讓它們不只會寫函式,而是真的看懂你的系統——Graphify 正好是那一層缺少的底座。

    🚀 你現在可以做的事

    • 到 Graphify GitHub 把專案 clone 下來並跑一次 graphify scan
    • 挑一個現有專案,把產生的圖譜接到你最常用的 AI 助手(如 Cursor 或 Claude Code)
    • 在下一次接手專案或處理高風險 PR 時,用 Graphify + AI 做一次完整的系統導覽或影響分析
  • 用 Frugon+開源模型,把 AI 帳單砍半

    用 Frugon+開源模型,把 AI 帳單砍半

    📌 本文重點

    • 用 Frugon 分析 LLM 使用紀錄與成本結構
    • 比較便宜/開源與高價模型的品質差異
    • 產生模型路由建議,讓簡單任務改用便宜模型

    只要你大量用 GPT/Claude 跑程式與 Agent 工作流,Frugon 要解決的,就是「到底哪些請求可以改用便宜或開源模型」,讓帳單直接往下掉。


    核心功能:把「模型選錯」找出來

    1. 讀取 API 日誌,算出你真實的模型成本結構

    Frugon 是一個本機 CLI 工具,核心第一步就是把你的 LLM 使用紀錄抓進來,算出每種任務到底花了多少錢。

    可採取的行動:

    1. 在你常用的 AI 平台(OpenAI / Anthropic)導出使用紀錄:
    2. OpenAI:到 Usage 頁面,下載帳單/log 檔(或透過 API 取得 responses.jsonl 類似格式)。
    3. Anthropic:到帳務或使用頁面,匯出調用紀錄(通常是 JSON 或 CSV)。
    4. 在本機安裝 frugon:
      bash
      pip install frugon
    5. 在有日誌檔的資料夾執行:
      bash
      frugon analyze --logs ./logs

    Frugon 會讀取「OpenAI-style」的日誌格式,統計:

    • 各模型的使用次數、token 用量
    • 各任務類型(例如:搜尋、程式生成、摘要)的大致成本占比

    💡 關鍵: 透過實際日誌統計,你可以精確看到成本主要消耗在哪些模型與任務,而不是憑印象猜測。

    你會看到一個很直接的事實:大量錢其實花在一些很簡單的請求上,而不是最難的那 5% 任務。


    2. 對同一任務測試不同模型,估算品質差異

    真正的重點,是 Frugon 不只算錢,它會幫你試:同一個 prompt,如果改用便宜模型、甚至改用本地開源模型,結果差多少。

    可採取的行動:

    1. 準備你想比較的模型,例如:
    2. 雲端:gpt-4.1-mini、gpt-4.1、claude-3.5-sonnet、claude-3-haiku
    3. 本地(透過 Ollama 或 vLLM):glm-4、glm-5.2、phi-4、qwen2.5 等
    4. 在 Frugon 設定中,把不同模型接到同一組任務樣本:
      bash
      frugon compare \
      --logs ./logs \
      --models gpt-4.1-mini,gpt-4.1,glm-5.2 \
      --provider-config ./providers.yaml
    5. 查看報告:Frugon 會對每個任務類型輸出:
    6. 成本:每千 token 價格,預估每月支出
    7. 品質:用自動評估(例如比較回覆結構、關鍵字覆蓋率,或你自定的評分規則)估算「能否接受」

    實際效果:

    • 你會發現像 Databricks 報告提到的 pi-coding-agent、GLM 5.2 等模型,在程式碼任務上,成本大幅低於主流付費模型,但通過率相近甚至更好(參考:https://www.reddit.com/r/LocalLLaMA/comments/1usrek0/)。
    • 對於簡單篩選、摘要、規則轉換類任務,gpt-4.1-mini 或開源模型往往「好到足夠」,沒必要動用最貴那一檔。

    💡 關鍵: 對相同任務批量 AB 測試不同模型,可以找到「成本明顯較低但品質仍達標」的替代方案。


    3. 自動給出「可以改用便宜模型」的路由建議

    分析完日誌與模型表現後,Frugon 會告訴你:哪些呼叫可以安全地改路由到便宜模型,還能估出你能省下的大致比例。

    可採取的行動:

    1. 在分析後產出的建議中,鎖定成本最高的前幾個任務類型,例如:
    2. code_generation_draft(寫樣板、測試腳架)
    3. search_scan(大量文本掃描、RAG 初步檢索)
    4. bulk_copywriting(批量行銷文案)
    5. 將這些任務標記為「可路由到便宜模型」,輸出為一份路由規則 YAML 或 JSON:
      “`yaml
      routes:

      • task_type: code_generation_draft
        preferred_model: glm-5.2
        fallback_model: gpt-4.1
      • task_type: search_scan
        preferred_model: gpt-4.1-mini
        fallback_model: claude-3.5-sonnet
        “`
    6. 在你的 Agent 或服務端程式裡,導入這份規則,改成:
    7. 先看任務類型(或 prompt tag)
    8. 符合路由規則時用便宜/開源模型
    9. 只有在評分不夠好時才回退到主力高價模型

    這就是 Towards AI 提到的「模型路由+編排(orchestration)」的實作方式:成本問題不是模型本身,而是你怎麼調度它們(參考:https://pub.towardsai.net/your-ai-coding-bill-is-not-a-model-problem-its-an-orchestration-problem-eeeacb340d1e)。

    💡 關鍵: 透過明確的路由規則,先用便宜模型處理大部分請求,再在需要時回退到高價模型,可以在不犧牲品質的前提下大幅壓低帳單。


    適合誰用:幾個很具體的場景

    1. 公司內部 Coding Agent/AI 助理

    如果你有:

    • 內部的程式碼自動補全、重構、寫測試的 Agent
    • 或自己用 GPT/Claude 當主力 coding 助理

    可採取的行動:

    1. 用 Frugon 分析最近一個月的 coding 相關 API 日誌。
    2. 把任務粗分為:
    3. 簡單工作:自動補全、樣板代碼、註解、測試腳架
    4. 困難工作:跨模組設計、大重構、疑難除錯
    5. 參考 Towards AI 的策略:讓簡單工作全部路由到本地開源模型(例如 GLM 5.2、phi-4),只在困難工作時才叫 GPT-4.1/Claude 3.5。(https://pub.towardsai.net/how-to-cut-your-ai-coding-bill-without-giving-up-the-frontier-model-870469d0d27d)

    2. 批量文案生成服務

    如果你在做:

    • 大量短文案(社群貼文、電郵片段)
    • SEO 標題、meta 描述、A/B 測試版本

    可採取的行動:

    1. 把最近的批量文案請求丟給 Frugon 分析,看哪幾類 prompt 消耗最多 token。
    2. 用較便宜模型(例如 gpt-4.1-mini 或本地 qwen2.5)重跑一部分樣本,看品質是否能接受。
    3. 把「可接受的任務類型」在路由規則裡標記為便宜模型優先,主力模型只負責:
    4. 重要 campaign 的首稿
    5. 關鍵頁面(首頁/定價頁)的文案

    3. RAG 查詢服務、搜尋掃描類應用

    如果你有:

    • 內部知識庫問答網站
    • 客戶支援聊天機器人

    大多數成本在於「長上下文+大量查詢」,而不是最終回答的語氣。

    可採取的行動:

    1. 用 Frugon 找出所有包含超長 context 的調用(RAG 問答)。
    2. 評估:檢索+初步摘要能否先用便宜模型處理,再將壓縮後的內容交給高階模型發 final 回覆。
    3. 實作一條省錢路徑:
    4. 便宜模型/開源模型:負責檢索結果摘要、濾掉不相關段落(上下文壓縮)。
    5. 高階模型:只在最後一次,基於壓縮後資訊生成答案。

    怎麼開始:從第一次分析報告,到省錢工作流

    步驟 1:在本機安裝 Frugon

    Frugon 是 MIT 授權、可本地離線跑的 CLI 工具:

    pip install frugon
    frugon --help
    

    建議在專用虛擬環境裡安裝,方便後續更新和管理:

    python -m venv .venv
    source .venv/bin/activate  # Windows 用 .venv\Scripts\activate
    pip install frugon
    

    步驟 2:導出並載入 OpenAI/Anthropic 使用紀錄

    1. 從各平台匯出最近 2–4 週的 API 使用紀錄到 ./logs 目錄。
    2. 若格式不同,可先轉成近似 OpenAI responses JSON 結構(Frugon 文件裡有範例結構,可在 GitHub repo 查看)。
    3. 跑第一次分析:
      bash
      frugon analyze --logs ./logs --out report.json

    完成後你會拿到:

    • 各模型的 token 用量和估算費用
    • 各任務類型的成本分布

    步驟 3:設定模型比較與路由建議

    1. 建一個 providers.yaml,配置多家模型來源:
      yaml
      openai:
      api_key: $OPENAI_API_KEY
      anthropic:
      api_key: $ANTHROPIC_API_KEY
      ollama:
      host: http://localhost:11434
    2. 跑比較:
      bash
      frugon compare \
      --logs ./logs \
      --models gpt-4.1-mini,gpt-4.1,glm-5.2,phi-4 \
      --provider-config ./providers.yaml \
      --out routing_suggestions.yaml
    3. 根據輸出的 routing_suggestions.yaml,在你的後端服務加上簡單的模型路由:
    4. 以 task_type、max_tokens 或 importance_level 作為分流條件
    5. 優先走便宜/本地模型,必要時再升級到高價模型

    步驟 4:用表格想清楚你的模型池搭配

    為了方便設計工作流,你可以把常用模型與工具列成表格:

    名稱 核心功能 免費方案 適合誰
    Frugon 讀取日誌、算成本、模型比較 開源 MIT,本機 有 API 日誌的開發者/團隊
    GLM 5.2 程式碼生成、一般助手 開源,可本地 內部 coding agent、IDE 助理
    pi-coding-agent 精簡 Bash 工具的 coding agent 依託基礎模型 想要低成本自動化寫程式的人
    GPT-4.1-mini 通用任務、便宜高效 依使用計費 批量文案、RAG 前處理
    Claude 3.5 高難度推理、長上下文 有免費層+計費 關鍵決策、難題除錯

    你不需要一次全換,只要先挑:

    • 成本最高的任務類型
    • 品質要求相對沒那麼嚴苛的場景

    用 Frugon 跑一輪比較,按表格逐步把這些流量導到更便宜或本地的模型,就能把 AI 帳單穩定壓下來,而不用放棄你熟悉的 GPT/Claude 主力模型。


    🚀 你現在可以做的事

    • 到 Frugon GitHub 將 frugon 安裝在本機,並準備最近 2–4 週的 API 日誌
    • 匯出 OpenAI/Anthropic 使用紀錄到 ./logs,執行 frugon analyze 與 frugon compare 產生第一版報告
    • 根據產出的 routing_suggestions.yaml,在你的後端或 Agent 加入模型路由邏輯,先讓一兩個任務類型切換到便宜或本地模型
  • Flint:讓 AI 也畫得出專業圖表

    Flint:讓 AI 也畫得出專業圖表

    📌 本文重點

    • Flint 讓 LLM 用簡單 JSON 就能畫出專業圖表
    • 透過中介視覺語言,把美觀與排版細節交給 Flint
    • 搭配 Data Formulator/MCP,可在多種場景自動出圖

    多數 LLM 雖然會「描述圖」,卻很難畫出乾淨、專業、可維護的圖表,Flint 就是專門幫 AI 接手這段「從文字到好圖」的工作。


    為什麼一般 LLM 畫圖總是歪掉?

    如果你用過 LLM 直接輸出 Vega-Lite、ECharts、Matplotlib,大概遇過這些情況:

    • 圖是畫出來了,但:
    • 顏色、比例亂選,看起來很業餘
    • 標軸標籤打錯、重疊、或被擠出畫面
    • 圖例、格線沒有依照人類習慣排版
    • 為了避免出錯,只敢給 LLM 很簡單的設定 → 圖表品質又退回系統預設
    • 一旦你說「把折線圖改成雙軸圖,多加一條移動平均」,整段 spec 幾乎要重寫

    Flint 的切入點是:不是 LLM 太笨,而是現有圖表語言太「底層」,逼模型做太多視覺細節決策。Flint 改成「中介視覺語言 + 自動排版引擎」,讓 LLM 只說高階意圖,低階美觀細節交給 Flint。

    💡 關鍵: Flint 把圖表設計拆成高階意圖與低階排版,讓 LLM 專心決策「畫什麼」,而 Flint 負責「怎麼畫得好看」。


    核心功能:Flint 幫 AI 補完「設計力」

    1. 中介視覺語言:LLM 只需要說人話版的圖表需求

    Flint 把圖表拆成幾個高階概念:

    • data: 用哪些欄位
    • mapping: 哪個欄位對應到 x、y、顏色、大小
    • mark: 用折線、長條、區域等標記
    • layout & style: 留給 Flint 自動排版與預設樣式

    LLM 只要輸出一份簡潔的 JSON,Flint 會負責:

    • 均衡配色
    • 合理的軸刻度、標籤格式
    • 避免文字重疊、圖例遮擋

    你可以做的事:在自己的 LLM 工具裡,把「請幫我生出完整 ECharts/Vega spec」改成「請輸出 Flint JSON」,再由後端把 Flint JSON 丟給 Flint 編譯成最終圖表。

    2. 與 Data Formulator 深度整合:圖表可以點一點改

    Data Formulator 是微軟另一個開源專案,可以視覺化地編輯 Flint 圖表:

    • 左邊是資料表
    • 中間是圖表
    • 右邊是 Flint 規格(JSON)

    你可以:

    • 讓 LLM 先產出 Flint 規格
    • 使用者在 Data Formulator 裡微調(拖拉欄位、改顏色)
    • 再把調整後的 Flint JSON 存回系統 → 變成可持久化的「報表模版」

    你可以做的事:把 Data Formulator 部署在內網,給資料分析團隊當「AI 生成初版圖表,人手最後調整」的工作台。

    3. MCP 伺服器:任何 Agent 都能叫 Flint 畫圖

    Flint 官方提供了符合 Model Context Protocol (MCP) 的伺服器,意思是:

    • 你用哪一家的 LLM / Agent 幾乎都不重要
    • 只要支援 MCP,就能把 Flint 當成「畫圖工具」來呼叫

    流程通常是:

    1. Agent 讀取你給的資料
    2. Agent 生成 Flint JSON
    3. 呼叫 Flint MCP 伺服器 → 回傳可嵌入網頁的圖表(或 Vega spec 等)

    你可以做的事:在自家 Agent(如 OpenAI, Claude, 自建 Llama)中,註冊 Flint MCP 工具,讓 Agent 回答問題時順手出圖,而不是只給一長段文字分析。


    適合誰用?三個具體場景

    1. 資料分析報告自動出圖

    情境:你每週要交「流量報告」、「營收報表」,但每次調整維度、時間區間都得重畫圖。

    用法:

    • 把數據放在資料庫或 CSV
    • 讓 LLM 讀取後,產出 Flint JSON
    • Flint 編譯成固定風格的圖,嵌入到報告模板(Notion、Confluence、內部系統)

    可行操作:

    • 建立一個簡單的 HTTP 服務 /generate-chart:
    • 輸入:分析問題 + 資料表名稱
    • 中間:LLM → Flint JSON → Flint 編譯
    • 輸出:圖表 URL 或 HTML Snippet

    💡 關鍵: 用 /generate-chart 這類服務,把「問問題 → 自動出圖」變成標準流程,可大幅減少手動報表製作時間。

    2. 內部 BI 助理

    情境:同事問「上個月付費轉換率怎麼樣?」,你不想每次都打開 Power BI 重拉圖。

    用法:

    • 建立一個聊天機器人(Slack / Teams / Line)
    • 後端讓 Bot 可以:
    • 查詢資料庫
    • 呼叫 LLM 產生 Flint JSON
    • 用 Flint 生成圖,回傳為圖片或互動式圖表連結

    可行操作:

    • 在 Bot 指令中加入:/chart 近三個月 活躍用戶 與 付費人數
    • Bot 回覆一張趨勢折線圖,並附上描述文字

    3. 技術文件中的動態圖表

    情境:你寫 SDK / API 文件,需要展示效能、流量、版本差異,數據常更新。

    用法:

    • 文檔系統只存「Flint JSON + 資料來源」
    • 每次讀者開啟頁面,後端動態用 Flint 產生最新圖表

    可行操作:

    • 在 docs 中嵌入一個 <iframe src="/docs/charts/latency">
    • 這個 endpoint 背後:查資料 → Flint render → 回傳 SVG / PNG

    實際長什麼樣?Flint JSON 範例

    以下是一個最小可用的 Flint 規格,畫出「每月營收折線圖」:

    {
      "data": {
        "fields": [
          { "name": "month", "type": "temporal" },
          { "name": "revenue", "type": "quantitative" }
        ],
        "values": [
          { "month": "2024-01", "revenue": 120000 },
          { "month": "2024-02", "revenue": 135000 },
          { "month": "2024-03", "revenue": 128000 }
        ]
      },
      "mark": "line",
      "encoding": {
        "x": { "field": "month", "type": "temporal" },
        "y": { "field": "revenue", "type": "quantitative" }
      },
      "title": "2024 Q1 每月營收"
    }
    

    LLM 只要穩定產出這樣結構清楚、語意正確的 JSON,Flint 就會幫你做出排版乾淨的圖,之後你想改顏色、字型、軸設定,都可以在 Data Formulator 介面上調整。


    怎麼開始?30 分鐘內畫出第一張 AI 圖

    1. 部署 Flint:本機或雲端

    官方文件與 Demo:https://microsoft.github.io/flint-chart/#/

    本機(開發測試)

    1. 安裝 Node.js(建議 18+)
    2. Clone 專案:
      bash
      git clone https://github.com/microsoft/flint-chart.git
      cd flint-chart
    3. 安裝依賴並啟動示例:
      bash
      npm install
      npm run dev
    4. 瀏覽器打開 http://localhost:5173,可以看到範例圖表與 Flint Spec。

    雲端部署(給團隊用)

    • 打包為 Docker image(視官方 repo 指引)
    • 部署在自家 Kubernetes / VM 上,對外提供 REST API:
    • POST /render → 輸入 Flint JSON,回傳圖表

    2. 使用現成範例,串接任一主流 LLM / Agent

    基本流程:

    1. 在後端寫一個函式 askLLMForFlintSpec(prompt, data_schema)
    2. 提示詞約束:
    3. 請只輸出 JSON,不要加解釋文字
    4. JSON 結構遵守 Flint Spec(可把官方 schema 一併塞進 system prompt)
    5. 把 LLM 回傳的 Flint JSON 送到 Flint API:
    import requests, json
    
    flint_spec = llm_generate_flint_spec(user_query, data_schema)
    res = requests.post(
        "http://localhost:8000/render",
        json={"spec": flint_spec}
    )
    with open("chart.svg", "wb") as f:
        f.write(res.content)
    
    1. 前端直接顯示 chart.svg,或轉 PNG 給報告系統使用。

    3. MCP 整合:丟給你的 Agent 用

    若你使用支援 MCP 的 Agent(例如部分新一代 IDE 助理、Agent Framework),步驟大致是:

    1. 啟動 Flint MCP server(依官方 repo 指示)
    2. 在 Agent 設定檔中註冊 Flint MCP endpoint
    3. 在系統提示詞中說清楚:
    4. 何時該呼叫 Flint(遇到需要圖表的問題)
    5. 如何構造 Flint JSON

    完成後,你就可以在對話中自然問:「幫我畫一張 2024 各季度營收與毛利率的組合圖」,讓 Agent 自行決定查數據、生成 Flint JSON、再回傳圖表。


    Flint 與其他「讓 AI 變強」工具怎麼搭配?

    下面用一個表快速對比本文提到的工具角色:

    名稱 核心功能 免費方案 適合誰
    Flint 中介視覺語言,幫 LLM 生高品質圖表 開源 需要報表 / 圖表自動化的開發者
    Data Formulator 可視化編輯 Flint 圖表的前端工具 開源 想在瀏覽器調整 AI 圖表的資料分析師
    VisionBridge1 讓純文字 LLM 具備視覺理解能力的代理 開源 想給本地 LLM 加上看圖能力的開發者

    你可以把它們組成一條完整流水線:VisionBridge 提供「看圖」能力、LLM 做推理與產生 Flint JSON、Flint+Data Formulator 負責「畫好圖」與人類微調。


    結語:先讓 AI「畫得出像樣的圖」再談自動化報表

    如果你已經在用 LLM 做資料分析、寫 BI 查詢,下一步就是讓結果不是只停在文字。Flint 幫你用很低的開發成本,把「專業圖表」變成 AI 回答的一部分,而且保留 JSON 規格,後續要改樣式、改資料源,都能持續演進。

    最實際的建議:花 30 分鐘跑起官方 Demo,拿文中的範例 JSON 改成自己的資料,先做出第一張「AI 自動生成、你看得順眼、同事也改得動」的圖表,再來思考要怎麼把它嵌進你的報表、內部工具或 Agent 流程裡。

    🚀 你現在可以做的事

    • 打開 https://microsoft.github.io/flint-chart/#/,跑起官方 Demo 並試著改用自己的資料
    • 在後端實作一個簡單的 /generate-chart 服務,讓 LLM 產生 Flint JSON 再交給 Flint 渲染
    • 部署 Data Formulator,讓資料分析同事用瀏覽器微調 LLM 生成的 Flint 圖表並存成報表模版
  • 開源 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 決策,照範例格式寫好丟進議會讓它辯論一次
    • 如果你有在用多代理框架,嘗試把「高智議會」當成決策模組接入現有工作流