by Rain Chu | 7 月 28, 2026 | AI , skills , Tool , 圖型處理
AI Agent 很會理解「月份、營收、百分比變化」代表什麼,卻不一定能穩定處理座標軸、刻度、色階、標籤間距與版面配置,直接要求模型輸出完整 Vega-Lite 或 ECharts 規格,常見結果不是設定冗長,就是參數彼此衝突,甚至渲染後只得到空白畫布。
Flint Chart 的做法,是讓 AI 只負責描述資料的意義與圖表意圖,再由確定性的編譯器完成幾何與渲染細節 ,這不只是圖表工具的改良,也是一種值得用在 AI Agent 系統的架構。模型產生小型、可驗證的中介格式,程式再負責執行可重現的工作。
如果你正在用 Codex 製作視覺內容,可以先參考站內的Codex 動態圖表與短影音工作流程 ,Flint 則更專注在資料圖表的語意、驗證與多後端輸出。
Flint Chart 是什麼
Flint 是微軟研究院與中國人民大學 IDEAS Lab 合作開發的開源視覺化中介語言,它不是另一套直接把圖畫到畫布上的函式庫,而是位在 AI Agent 與 Vega-Lite、Apache ECharts、Chart.js、Plotly、Excel 之間的語意層。
AI Agent 判斷欄位代表月份、價格、利潤、國家、排名或百分比變化
Flint 規格 保存資料、語意型別、圖表種類與欄位映射
Flint 編譯器 推導日期解析、聚合、刻度、色彩、標籤與版面
繪圖後端 接收原生規格並渲染互動圖表、PNG、SVG 或 Excel 原生圖表
截至 2026 年 7 月 28 日,官方 GitHub 顯示 JavaScript 與 TypeScript 函式庫已能輸出 Vega-Lite、ECharts、Chart.js、Plotly 與 Office.js 使用的 Excel 原生圖表。7 月 11 日的 iThome 報導只列出前三種,是因為後續 0.4.0 版才加入 38 種 Plotly 圖表與 18 種可編輯 Excel 範本。
為什麼 AI 直接產生圖表容易失敗
製作圖表其實包含兩種不同工作。第一種是理解語意,例如 revenue 是金額,month 是年月,growth 是百分比變化。第二種是安排幾何,例如軸的範圍、刻度密度、文字旋轉、圖例位置與色彩映射。
語言模型擅長第一種工作,第二種工作卻牽涉許多互相依賴的數值與規則。Flint 把兩者拆開後,AI 不必一次猜完所有低階設定。規格也從難以檢查的大段設定,縮成可閱讀、可修改、可在渲染前驗證的小型 JSON。
模型負責意義,編譯器負責數學。真正的價值不是少寫幾行,而是讓每一步都能被驗證與重現。
Flint 規格的三個核心部分
一份 Flint 輸入主要由資料、semantic_types 與 chart_spec 組成。下面用季度營收長條圖示範最小結構。
{
"data": {
"values": [
{ "quarter": "Q1", "revenue": 1200 },
{ "quarter": "Q2", "revenue": 1450 },
{ "quarter": "Q3", "revenue": 980 },
{ "quarter": "Q4", "revenue": 1800 }
]
},
"semantic_types": {
"quarter": "Quarter",
"revenue": "Price"
},
"chart_spec": {
"chartType": "Bar Chart",
"encodings": {
"x": { "field": "quarter" },
"y": { "field": "revenue" }
},
"baseSize": { "width": 480, "height": 320 }
}
}
data 可以直接放入列資料,也能在本機 MCP 模式下引用 JSON、CSV 或 TSV 檔案。semantic_types 告訴編譯器每個欄位的實際意義。chart_spec 則決定圖表種類,以及欄位要放在 x、y、color、size、shape、column、row、group 或 detail 等通道。
語意型別可以重複使用。探索同一份資料時,多半只要更換 chart_spec。例如把 Quantity 改成 PercentageChange,編譯器就能改用適合正負變化的發散色階、百分比格式與對應的軸設定。這比每次都讓模型重新生成完整圖表設定更穩定。
在 Codex 安裝 Flint MCP
本機版本需要 Node.js 18 以上。Codex 可以用一行命令加入 stdio MCP 伺服器。
codex mcp add flint -- npx -y flint-chart-mcp
接著確認伺服器是否已經出現在清單。
codex mcp list
如果資料不需要從本機檔案讀取,可以關閉檔案引用。這個設定要求代理把資料列直接放進 data.values,能縮小不受信任工作流程的檔案存取範圍。
codex mcp add flint-safe -- npx -y flint-chart-mcp --disable-file-reference
官方也提供遠端 MCP 端點,適合只能連接 HTTP MCP 的客戶端。處理私有資料時,仍建議優先選擇本機 stdio 版本。
codex mcp add flint-remote --url https://flint.data-formulator.ai/mcp
第一次使用的提示詞
安裝後不要只下「幫我畫圖」。把資料來源、語意、圖表目的、驗證方式與輸出格式一起交代,結果會更可靠。
請載入 flint://agent-skill,並呼叫 list_chart_types 檢查 vegalite 後端是否可用。讀取目前資料夾的 sales.csv,把 month 判定為 YearMonth,revenue 判定為 Price,growth 判定為 PercentageChange。先用 validate_chart 驗證,再建立每月營收折線圖,並用顏色標示成長率。若支援 MCP Apps 就使用 create_chart_view,否則用 render_chart 輸出 SVG。最後列出所有警告與被截斷的資料。
Flint MCP 提供五個主要工具。create_chart_view 適合互動調整,validate_chart 用來檢查規格與警告,render_chart 產生 PNG 或 SVG,compile_chart 回傳後端原生 JSON,list_chart_types 則用來確認可用的圖表與通道。
這套做法和讓 Codex 用 Playwright CLI 操作瀏覽器 有相同精神。模型不必自己模擬每個底層步驟,而是呼叫邊界清楚、結果可檢查的工具。
在 JavaScript 與 TypeScript 專案使用
若你正在開發產品,而不是只在對話中產生圖表,可以直接安裝函式庫。
npm install flint-chart
import { assembleVegaLite } from "flint-chart"
const input = {
data: { values: myData },
semantic_types: {
weight: "Quantity",
mpg: "Quantity",
origin: "Country"
},
chart_spec: {
chartType: "Scatter Plot",
encodings: {
x: { field: "weight" },
y: { field: "mpg" },
color: { field: "origin" }
},
baseSize: { width: 400, height: 300 }
}
}
const spec = assembleVegaLite(input)
相同輸入可以交給 assembleECharts、assembleChartjs、assemblePlotly 或 assembleExcel。後端若不支援指定圖表,組裝器會在渲染前拋出錯誤,因此產品端應先查詢範本支援狀態,再把錯誤與警告顯示給使用者。
Excel 原生圖表特別適合需要後續人工編輯的報表工作。如果工作流程還包含 Word、PowerPoint 或試算表處理,可以延伸閱讀OfficeCLI 與 AI Agent 的 Office 自動化教學 。
Flint、Vega-Lite、Mermaid 與一般 Chart MCP 的差異
工具 主要用途 AI 要處理的細節 適合情境 Flint 語意中介格式與編譯 資料意義、圖表意圖與欄位映射 需要可靠生成、多後端與可驗證規格 Vega-Lite 統計視覺化文法 較完整的編碼、比例尺與版面設定 需要精細控制與成熟生態 Mermaid 流程圖與軟體圖解 節點、關係與圖形語法 架構圖、流程圖與文件 一般 Chart MCP 把特定繪圖服務包成工具 視工具設計而定 已有固定渲染服務或單一後端
Flint 並不是 Vega-Lite 的替代品,因為它可以直接編譯成 Vega-Lite 規格。它處理的是更前面的一層,讓模型先表達「這些資料是什麼」,再由編譯器決定「如何正確畫出來」。
目前限制與使用前要知道的事
仍是研究專案 官方論文尚未正式公開,產品決策不能只靠宣傳數字
Python 套件尚未發布 目前只有原始碼預覽,正式套件仍以 JavaScript 與 TypeScript 為主
後端支援並不完全相同 同一圖表不一定能在所有後端輸出,MCP 指南目前列出的編譯後端仍以 Vega-Lite、ECharts 與 Chart.js 為主
Flint 不負責完整資料整理 聚合、過濾、關聯、樞紐與衍生欄位最好先在上游完成
自動版面可能截斷資料 離散項目超過空間預算時會套用保留策略,整合端必須顯示 _warnings
本機渲染仍要管理權限 預設會讀取代理指定的本機檔案,不受信任的環境應啟用 –disable-file-reference
iThome 整理的測試顯示,Flint 在 GPT-5.1、GPT-5-mini 與 GPT-4.1 三組 LLM 評分中,都優於直接產生完整 Vega-Lite 規格的 DirectVL。不過官方仍標示研究論文即將公開,因此比較結果適合視為早期證據,不能取代自己的資料集與視覺驗收。
真正值得帶走的是代理系統的分工方式
Flint 最值得學習的不只是圖表規格,而是代理系統的分工。讓模型輸出小型、結構化、可以先驗證的意圖,再讓確定性程式負責計算、渲染與錯誤處理。這個模式也能延伸到 UI 元件、文件排版、測試流程與自動化操作。
但「成功回傳 JSON」不等於任務完成。視覺工作必須真的渲染,再檢查畫布是否空白、文字是否重疊、顏色是否誤導、資料是否被截斷。AI Agent 的可靠性,來自可驗證的中介格式與最後一哩的實際驗收,而不是更長的提示詞。
常見問題
Flint 可以取代 ECharts 或 Vega-Lite 嗎
不會。Flint 是位在 AI 與繪圖函式庫之間的中介語言,最後仍會輸出 ECharts、Vega-Lite 等後端可使用的原生規格。
Flint MCP 會把資料上傳到外部服務嗎
本機 stdio 版本會在主機上執行,內嵌資料與本機檔案不會送到遠端渲染服務。若改用官方 HTTP 端點,資料會透過遠端連線處理,因此敏感資料仍應優先採用本機版本。
Codex 看不到互動圖表怎麼辦
create_chart_view 需要客戶端支援 MCP Apps。若目前介面不支援,可以要求 Flint 使用 render_chart 輸出 SVG 或 PNG,再直接檢查成品。
Flint 適合什麼工作
它適合需要大量產生資料圖表、希望規格可被人工修改、需要切換不同後端,或不能接受偶發空白與錯誤圖表的 Agent 工作流程。若只是一次性的簡單圖表,現有大型模型或熟悉的圖表函式庫可能已經足夠。
參考資料
by Rain Chu | 7 月 20, 2026 | Agent , AI , API , Tool
Cloudflare Workers AI 拿來接 Claude Code 的做法很簡單:Cloudflare 跑模型,LiteLLM 在本機當轉接橋,Claude Code 只需要改 Anthropic 相關環境變數,就能把請求送到本機 proxy。
這篇整理的是一個比較務實的路線。它不是要你把所有模型成本都消失,而是讓你知道免費額度在哪裡、帳單風險在哪裡、命令怎麼下、哪些設定一定要看清楚。
先講結論
Cloudflare Workers AI 有免費額度,官方價格頁寫明 Free plan 每天有 10,000 Neurons,GLM 5.2 目前也在 Cloudflare Workers AI 模型列表裡,可以透過 Cloudflare API 呼叫。這代表你可以把 Claude Code 的模型入口改成本機 LiteLLM proxy,再由 LiteLLM 轉送到 Cloudflare 的 @cf/zai-org/glm-5.2。
但「免費」不是「無限」,Cloudflare 的計費單位是 Neurons,免費額度用完後會受到方案限制,更重要的是,Cloudflare AI Gateway 也能接外部模型,如果你把 OpenAI 或 Anthropic 這類外部模型接進去,那就不再是 Cloudflare Workers AI 的免費模型邏輯,帳單會回到外部供應商那邊。
Claude Code 只改成本機 Anthropic 入口,真正的模型請求由 LiteLLM 轉到 Cloudflare Workers AI。
這個架構在解什麼問題
Claude Code 很好用,但長時間寫程式、重構、跑測試、修錯時,模型成本會變得很有感。若只是一些低風險任務,例如產生腳手架、改小工具、做簡單 demo、先跑一輪想法,Cloudflare Workers AI 的免費額度可以拿來當低成本緩衝層。
這和 用 Claude Code 搭配 LM Studio 與 Ollama 的思路很像,只是這次不是跑本地模型,而是把免費雲端額度接進本機開發流程。若你的工作流已經在用 Claude Code、Codex 和 skill 組合工作流 ,這種 proxy 入口會很有彈性。
完整操作命令
下面命令以 macOS 或 Linux 為主。你需要先有 Cloudflare 帳號,並在 Cloudflare dashboard 取得 Account ID 和 API Token。API Token 建議只給 Workers AI 需要的最小權限,不要用過度寬鬆的全域 token。
0. 安裝 Claude Code
npm install -g @anthropic-ai/claude-code
1. 用 curl 單測 GLM 5.2
先確認 Cloudflare 端可以呼叫模型。把 `你的ACCOUNT_ID` 和 `你的API_TOKEN` 換成自己的值。
curl https://api.cloudflare.com/client/v4/accounts/你的ACCOUNT_ID/ai/run/@cf/zai-org/glm-5.2 \
-H "Authorization: Bearer 你的API_TOKEN" \
-d '{"messages":[{"role":"user","content":"用一句話介紹你自己"}]}'
2. 安裝 uv
LiteLLM proxy 用 uvx 跑,可以固定 Python 3.12,避開較新 Python 版本造成的編譯問題。
curl -LsSf https://astral.sh/uv/install.sh | sh
3. 驗證 LiteLLM 能跑
uvx --python 3.12 --from 'litellm[proxy]' litellm --version
4. 建立 cf-config.yaml
建立 `cf-config.yaml`。`你的ACCOUNT_ID` 有兩處要換。`cf-glm-5.2` 給 Claude Code 主要模型用,`cf-small` 給較輕量任務用。
model_list:
- model_name: cf-glm-5.2
litellm_params:
model: openai/@cf/zai-org/glm-5.2
api_base: https://api.cloudflare.com/client/v4/accounts/你的ACCOUNT_ID/ai/v1
api_key: os.environ/CLOUDFLARE_API_TOKEN
- model_name: cf-small
litellm_params:
model: openai/@cf/meta/llama-3.1-8b-instruct-fp8
api_base: https://api.cloudflare.com/client/v4/accounts/你的ACCOUNT_ID/ai/v1
api_key: os.environ/CLOUDFLARE_API_TOKEN
litellm_settings:
use_chat_completions_url_for_anthropic_messages: true
5. 啟動 LiteLLM 翻譯橋
這個終端視窗要保持開啟。Claude Code 之後會連到 `localhost:4000`。
export CLOUDFLARE_API_TOKEN=你的token
uvx --python 3.12 --from 'litellm[proxy]' litellm --config cf-config.yaml --port 4000
6. 新開視窗測 proxy
curl http://localhost:4000/v1/models -H 'Authorization: Bearer sk-1234'
7. 把 Claude Code 指到本機 proxy
export ANTHROPIC_BASE_URL=http://localhost:4000
export ANTHROPIC_AUTH_TOKEN=sk-1234
export ANTHROPIC_MODEL=cf-glm-5.2
export ANTHROPIC_DEFAULT_HAIKU_MODEL=cf-small
接著啟動 Claude Code,若跳出自訂 API 設定就選是。進入後用 `/status` 確認 Base URL 指向 `localhost:4000`。
8. 把設定寫進 shell profile
如果你確定要長期使用,可以把上面四行 `ANTHROPIC_` export 加到 `~/.zshrc` 或 `~/.bashrc`。我會建議先手動跑幾次確認沒有問題,再寫進 profile。
Windows PowerShell 寫法
PowerShell 不用 `export`,改用 `$env:`。
$env:ANTHROPIC_BASE_URL="http://localhost:4000"
$env:ANTHROPIC_AUTH_TOKEN="sk-1234"
$env:ANTHROPIC_MODEL="cf-glm-5.2"
$env:ANTHROPIC_DEFAULT_HAIKU_MODEL="cf-small"
若要永久保存,放進 PowerShell 的 `$PROFILE`。Windows 跑 AI Agent 時,環境隔離也很重要,可以延伸看 Windows 跑 AI Agent 為什麼要用 WSL 。
保命提醒:不要把外部模型當免費額度
最容易出事的地方,是把 Cloudflare Workers AI、Cloudflare AI Gateway、OpenAI、Anthropic 混在一起。這篇的低成本前提,是 Cloudflare config 裡的模型走 `@cf/` 開頭,例如 `@cf/zai-org/glm-5.2`。這類模型用的是 Cloudflare Workers AI 額度。
如果你把 Gateway 接到 GPT 或 Claude,那些請求可能會回到 OpenAI 或 Anthropic 的帳單。Cloudflare 只是通道,不代表外部模型突然免費。真正要保命,就是把模型名稱、api_base、API key 來源逐一檢查,並在 Cloudflare 後台看用量。
官方價格頁目前寫得很明確:Free plan 每天 10,000 Neurons,Paid plan 也有每天 10,000 Neurons 免費額度,超出後依 Neurons 計費。免費方案超出額度通常是操作失敗,不是自動無限跑。這點比「無限免費」四個字重要太多。
省額度的三個做法
第一,任務分層。小任務用 `cf-small`,複雜推理再用 `cf-glm-5.2`。第二,讓 Agent 先輸出計畫再執行,避免一次丟太長上下文。第三,把重複流程寫成腳本或 skill,減少模型反覆讀同一批資料。
這也是我一直看好的方向:不要只追求模型本身,而是把模型接到穩定工具鏈。像 Playwright CLI 讓 Codex 操作瀏覽器 ,或 讓 Agent 自己搜尋和使用 skills ,本質上都是把昂貴推理留給真正需要判斷的地方。
我會怎麼用
我不會把這套當成主力模型的完全替代品,而是當成低成本實驗層。適合拿來跑 demo、試 prompt、生成小工具、做簡單 code review、補文件、處理一次性腳本。真正重要的架構決策、複雜除錯、長上下文專案,還是要保留更強模型或本地大模型選項。
如果你已經在用 Codex 和 ChatGPT Work 這類 AI 代理工作流 ,這套 Cloudflare Workers AI + LiteLLM 的做法可以當成另一個模型入口。它的價值不是讓你省到零,而是讓你有更多成本可控的實驗空間。
延伸資源
FAQ
Cloudflare Workers AI 接 Claude Code 真的免費嗎?
不是無限免費。Cloudflare Workers AI 有每日免費 Neurons 額度,超出後會依方案限制或計費。要把它當成低成本額度,不要當成沒有上限的模型。
為什麼需要 LiteLLM?
LiteLLM 在本機當 proxy,把 Claude Code 發出的 Anthropic 入口請求轉成 Cloudflare Workers AI 可接受的 OpenAI 相容請求。
最容易踩到哪個帳單風險?
最容易把 Cloudflare AI Gateway 接到外部 GPT 或 Claude,卻以為仍在用 Cloudflare 免費 @cf 模型。設定時要確認模型名稱是 `@cf/` 開頭,並檢查 API key 來源。
這套適合取代主力 Claude 嗎?
不建議直接取代。它比較適合低成本實驗、簡單任務、小工具和批次工作。複雜架構、長上下文和高風險任務,仍應保留更強模型。
by Rain Chu | 7 月 20, 2026 | AI , skills , Tool
OfficeCLI 把 Word、Excel、PowerPoint 這三種常見文件,變成 AI Agent 可以穩定讀取、修改、驗證和預覽的工程接口。
以前要讓 AI 幫你處理 Office 文件,常見做法是丟給 Python 套件,例如 python-docx、openpyxl、python-pptx。這些工具很有用,但每種格式各自一套 API,版面問題也很難用純文字確認。OfficeCLI 的方向則比較像給 Agent 一支專門的文件手臂,用 CLI 和 JSON 把文件操作標準化。
先講結論
OfficeCLI 是 iOfficeAI 開源的 Office 文件命令列工具,主打給 AI Agent 使用。它可以建立、讀取、修改和驗證 docx、xlsx、pptx,不需要安裝 Microsoft Office,也不需要額外 runtime,官方定位是 single binary。
我會把它放在 Playwright CLI 同一類思路裡,Playwright CLI 是讓 Agent 操作瀏覽器,OfficeCLI 則是讓 Agent 操作文件,兩者共同點都是把原本依賴 GUI 或複雜 library 的任務,改成可重複、可檢查、可寫進 skill 的 CLI 工作流。
OfficeCLI 的價值在於讓 Agent 形成讀取、修改、驗證、修正的文件處理閉環。
為什麼 Agent 需要 OfficeCLI
文件不是只有文字,Word 有段落、樣式、頁首頁尾、註腳、目錄和追蹤修訂。
Excel 有公式、表格、樞紐分析、條件格式和資料驗證。P
owerPoint 有投影片、形狀、圖表、圖片、動畫和轉場。這些東西如果只轉成純文字,Agent 很容易看漏版面和結構。
OfficeCLI 的關鍵設計,是把文件轉成 Agent 能理解的結構化輸出,也能渲染成 HTML 或 PNG,這讓 Agent 不只知道文件裡有什麼文字,也能檢查排版結果。對需要交付正式報告、簡報、表格的人來說,這個 render → look → fix 的迴圈非常重要。
一行指令取代很多樣板程式碼
傳統 Python 套件通常要先 import library、建立物件、找到段落或投影片、設定屬性,最後再存檔,OfficeCLI 把這些操作變成像 shell command 一樣的命令。例如建立簡報、加入投影片、設定文字、讀取 outline、輸出 JSON,都可以用命令完成。
officecli create deck.pptx
officecli add deck.pptx / --type slide --prop title="Q4 Report"
officecli view deck.pptx outline
officecli get deck.pptx /slide[1] --json
這種形式對 Codex、Claude Code、Cursor、GitHub Copilot 這類 coding agent 很友善。Agent 不需要在不同文件格式之間背很多 Python API,只要知道 OfficeCLI 的命令和路徑規則,就能用一致方式操作三種 Office 文件。
OfficeCLI 能做哪些事
OfficeCLI 的命令不只 create 和 view。官方文件列出的核心能力包含 get、query、set、add、remove、move、swap、validate、batch、dump、merge、watch、mcp、raw 和 raw-set。這代表它不只是產生文件,也能讀取現有文件、定位元素、修改內容、驗證問題、批次處理和啟動 MCP server。
格式 可做的事 適合場景 Word 段落、樣式、表格、圖片、註腳、目錄、追蹤修訂 報告、自動合約、專案文件、審稿流程 Excel 儲存格、公式、表格、排序、條件格式、圖表、樞紐分析 月報、資料清理、預算表、營運儀表板 PowerPoint 投影片、形狀、圖片、表格、圖表、動畫、轉場 簡報初稿、銷售 deck、課程投影片、專案提案
如果你的工作已經在用 MarkItDown 把 Office 文件轉成 AI 可讀 Markdown ,OfficeCLI 可以補上另一半。MarkItDown 偏向讀取和轉換,OfficeCLI 更偏向讀寫修改和驗證。
最重要的是可視化回饋
Agent 產生文件最常見的問題,是內容看起來對,但交付檔打開後版面歪掉。OfficeCLI 的 built-in rendering engine 可以把 docx、xlsx、pptx 渲染成 HTML 或 PNG,再讓 Agent 檢查畫面。這對簡報和報告特別有用,因為很多錯誤不是純文字能看出來的。
例如 Agent 做完簡報後,可以先用 `officecli view deck.pptx html` 或 `officecli watch deck.pptx` 看預覽,再用 `officecli view deck.pptx issues –json` 找問題。這會讓文件生成變成工程流程,而不是一次性產出後靠人工開檔檢查。
安裝方式
OfficeCLI 官方提供多種安裝路線。AI Agent 可以先讀 skill file,讓 Agent 自己理解如何安裝和使用。一般開發者也可以直接跑安裝腳本,或透過 npm 安裝。
curl -fsSL https://officecli.ai/SKILL.md
curl -fsSL https://raw.githubusercontent.com/iOfficeAI/OfficeCLI/main/install.sh | bash
npm install -g @officecli/officecli
Windows 則可以用 PowerShell 安裝。它的核心好處是 single binary,文件處理不必依賴本機有沒有安裝 Office。這對伺服器、CI、Docker 或 Agent 執行環境很重要。
跟 Python 套件和 LibreOffice 怎麼選
python-docx、openpyxl、python-pptx 還是很實用,尤其是你已經有固定資料結構和成熟程式碼時,LibreOffice headless 也適合某些批次轉檔需求,OfficeCLI 的優勢,是它把三種 Office 文件收斂成同一套 CLI、JSON 和路徑模型,對 Agent 來說比較容易自我修正。
我會這樣選。如果只是固定模板套資料,Python 套件仍然簡單。如果要讓 Agent 自己讀一份未知文件、理解結構、修改局部、檢查品質,再回頭修正,OfficeCLI 會更接近 AI-native 的工作方式。如果團隊正在做 Codex 與 AI 代理工作流 ,這種工具就很值得放進標準工具箱。
可以怎麼接到 Codex
最務實的做法,是先把 OfficeCLI 當成專案工具使用。讓 Codex 讀文件、產生命令、執行修改,再用 validate 和 issues 做回饋。等流程穩定後,再寫成 skill。這和 讓 Agent 自己發現和使用 skills 的方向很一致。
舉例來說,可以做一個「每週報告 skill」。輸入資料來源後,Agent 先產生 Excel 摘要,再把重點轉成 PowerPoint,最後輸出 Word 報告。OfficeCLI 負責文件讀寫與驗證,Codex 負責資料整理、判斷和修正。若還需要把團隊知識一起查進來,也可以搭配 OpenWiki 這類 Agent 共用知識庫 。
我的判斷
OfficeCLI 的真正價值,是把 Office 文件從「人打開 GUI 慢慢改」變成「Agent 可以讀、改、看、驗證、再修正」的循環。它不一定取代所有 Python library,但很適合補上 AI Agent 在文件處理裡最缺的一塊:穩定操作接口加可視化回饋。
如果你的工作常常要做報表、合約、簡報、月報、批次文件修改,這類工具會越來越重要。未來的文件自動化不只是產生文字,而是讓 Agent 能理解文件結構,知道自己改了哪裡,也能在交付前先檢查成果。
延伸資源
FAQ
OfficeCLI 是什麼?
OfficeCLI 是給 AI Agent 和開發者使用的 Office 文件 CLI,可以建立、讀取、修改和驗證 Word、Excel、PowerPoint 文件。
OfficeCLI 需要安裝 Microsoft Office 嗎?
不需要。官方主打 single binary,不依賴本機 Office 安裝,適合伺服器、CI 和 Agent 執行環境。
OfficeCLI 和 python-docx、openpyxl 差在哪裡?
Python 套件適合固定程式流程。OfficeCLI 更適合 AI Agent,因為它提供一致的 CLI、JSON 輸出、路徑式元素定位、文件驗證和 HTML 或 PNG 預覽。
Codex 可以用 OfficeCLI 嗎?
可以。Codex 可以透過終端執行 OfficeCLI 命令。若把常用流程寫成 skill,就能讓 Codex 更穩定地處理報告、簡報和表格。
by Rain Chu | 7 月 20, 2026 | AI , Tool
Orca 是 AI coding agent 的控制台,它把 Codex、Claude Code、OpenCode、Pi 這些 CLI agent 放進同一個開發環境,並且用 Git worktree 把每個任務隔離開來。這對已經開始同時使用多個 AI 編程工具的人很關鍵。
單一 Agent 的時代,問題通常是模型會不會寫,多 Agent 的時代,問題變成誰負責哪個分支、誰改了哪些檔案、怎麼比較成果、怎麼把最好的解法合回主線,Orca 想解的是後面這一段。
先講結論
Orca 是 stablyai 開源的 AI Development Environment,官方用法是把 Codex、Claude Code、OpenCode、Oh My Pi(OMP) 或其他 CLI agent 並排跑起來,每個 Agent 都在自己的 Git worktree 裡工作,最後由使用者比較差異、審查結果,再決定要合併哪一版。
我會把 Orca 看成 OpenWork 這類 OpenCode 工作台 的更完整版本,OpenWork 偏向把本地 Agent 工作桌面化,Orca 則更強調多 Agent orchestration、worktree 隔離、手機 companion、任務恢復和差異審查。
Orca 的核心不是多開終端,而是讓每個 Agent 有隔離環境,最後可以比較成果再合併。
Orca 解決的是多 Agent 失控問題
只跑一個 Codex 或 Claude Code 時,管理成本還可以接受,但當你同時讓三個 Agent 嘗試三種解法,麻煩就來了,檔案會互相覆蓋,終端輸出會混在一起,分支會弄亂,最後還要靠人回頭找哪一版比較好。
Orca 的做法是把每個 Agent 放進獨立 worktree。你可以把同一個 prompt 丟給多個 Agent,讓它們各自改一份程式碼,互不干擾。這很適合用在 bug 修復、重構、UI 改版、測試補齊和規格探索。
這和 用 Superpowers 建立 AI 開發紀律 的方向很接近。差別是 Superpowers 偏向規範和方法,Orca 偏向把這些工作流做進工具介面。
支援哪些 Agent
官方 README 的說法很直接:只要是能在 terminal 裡跑的 CLI agent,就可以放進 Orca。目前官方列出的包含 Claude Code、Codex、GitHub Copilot CLI、OpenCode、OpenClaude、OMP、Hermes Agent 等。這表示 Orca 不是綁定單一模型,而是把現有工具收進同一個 cockpit。
Agent Orca 裡的角色 適合任務 Codex 通用 coding agent 改程式、跑測試、整理專案 Claude Code 強推理與長任務 重構、架構判斷、需求拆解 OpenCode 本地或自訂模型入口 低成本實驗、本地 agent 工作流 OMP、Hermes 等 其他 CLI agent 特定工具或特定模型路線
如果你已經在用 Codex 與 ChatGPT Work 的 AI 代理工作流 ,Orca 的價值會更明顯。它不是要取代 Codex,而是讓 Codex 可以和其他 Agent 同場協作。
Parallel Worktrees 是核心
Orca 最重要的功能是 Parallel Worktrees。你可以把同一個需求發給多個 Agent,讓它們各自在不同 Git worktree 裡完成任務。完成後再比較 diff、測試結果和實作品質。這比在同一個 working tree 裡輪流叫不同 Agent 改檔安全很多。
我會把它想成「平行探索」。不是每個 Agent 都要成功,而是讓不同模型或不同 prompt 策略同時試錯。最後人做判斷,挑一個最好的版本進主線。這比盲信單一 Agent 更符合真實工程工作。
Terminal Splits 和任務恢復
Orca 也把多面板和多終端做進介面。Terminal Splits 讓你可以把多個 Agent、測試、伺服器和 logs 並排放著看。對前端專案、後端 API、資料庫 migration 這類需要同時觀察多個輸出的任務,這會比一直切 tab 順很多。
任務恢復也很重要。AI coding agent 常常不是一次跑完,尤其遇到長時間編譯、測試失敗、rate limit 或你臨時離開電腦。Orca 把任務狀態集中管理,讓你能回到原本的 Agent session,而不是重新猜它剛剛做到哪裡。
手機遠端和語音輸入不是噱頭
Mobile Companion 乍看像附加功能,但對長時間 Agent 任務其實很實用,你可以在手機上看 Agent 是否完成,收到通知後補一句 follow-up,或遠端啟動下一個任務。這讓 AI coding 從坐在電腦前等待,變成可以非同步監看。
語音輸入也類似,很多時候我們不是缺鍵盤,而是缺一個快速把想法丟給 Agent 的入口,若搭配清楚的任務模板,語音輸入可以用來快速交代需求、補充限制或要求重跑測試。
GitHub Issue 和定時審查
Orca 官方也強調 GitHub 和 Linear 的原生整合。你可以在 app 裡看 issue、PR、project board,並從任務直接開 worktree。這讓「看任務 → 啟動 Agent → 產生改動 → review diff」變成一條線,而不是在瀏覽器、終端、IDE、Git UI 之間來回切。
定時審查 repository 是另一個有意思的方向,它適合拿來做每日或每週檢查,例如 dependency 更新、測試覆蓋率、錯誤 logs、未完成 issue、重複程式碼。這類任務不一定需要最強模型,但需要穩定排程和可追蹤結果。
和 Playwright CLI、OpenWork 怎麼搭
Orca 管的是多 Agent 和 worktree。Playwright CLI 管的是瀏覽器自動化。OpenWork 管的是 OpenCode 和本地 Agent 桌面工作台。這些工具其實不是互斥,而是分別解決 AI 開發流程中的不同層級。
我的理想組合會是:Orca 負責多 Agent 任務隔離,Codex 或 Claude Code 負責實作,Playwright CLI 負責跑 UI 驗證,Graphify 或 OpenWiki 負責專案知識。這樣 Agent 就不是聊天框,而是完整開發系統的一部分。
安裝與使用入口
Orca 官方下載入口在 onOrca.dev,支援 macOS、Windows、Linux。Windows 使用者官方 README 也提醒可以抓較新的 RC 版本,因為有 Windows fixes。手機 companion 則提供 iOS App Store、TestFlight 和 Android APK。
桌面版:到 onOrca.dev/download 下載
原始碼:stablyai/orca GitHub
手機 companion:官方 README 提供 iOS、TestFlight 和 Android APK 連結
支援 Agent:Codex、Claude Code、OpenCode、GitHub Copilot CLI、Pi、Hermes Agent 和其他 CLI agent
我的判斷
Orca 的價值,不是讓你同時叫五個 Agent 然後期待奇蹟發生。真正有用的是隔離、比較、恢復、審查和合併,多 Agent 不是數量遊戲,而是工程流程問題。
如果你只是偶爾用 Codex 改一兩個檔案,Orca 可能有點重,但如果你已經常常同時開 Claude Code、Codex、OpenCode,或想把 issue 修復、UI 測試、code review 分配給不同 Agent,Orca 就值得試,它比較像從單兵作戰進入小隊協作。
延伸資源
FAQ
Orca ADE 是什麼?
Orca 是 AI Development Environment,可以把 Codex、Claude Code、OpenCode、Pi 等 CLI agent 放在同一個介面裡並行工作。
Orca 為什麼要用 Git worktree?
Git worktree 可以讓每個 Agent 在獨立工作區修改程式碼,避免互相覆蓋檔案,也方便最後比較 diff 和測試結果。
Orca 適合所有開發者嗎?
如果只是偶爾用一個 Agent 改小檔案,Orca 可能太重。若你常用多個 Agent、需要任務隔離、差異比較、手機遠端和任務恢復,Orca 就很適合。
by Rain Chu | 7 月 15, 2026 | AI , skills , Tool
Graphify 最有價值的地方,是把「讀專案」這件事從一次性的上下文塞爆,改成可以重複查詢的知識圖譜, Codex、Claude Code、OpenCode、Cursor、Gemini CLI 這類 AI coding assistant 來說,最大的浪費常常不是寫程式,而是每次都重新理解同一個 codebase。
如果 OpenWiki 解決的是 Agent wiki 和文件記憶,Graphify 更像是把整個資料夾編譯成一張可追蹤的圖,它可以處理程式碼、SQL schema、R script、shell script、文件、論文、圖片,甚至影片和音訊,最後輸出 `graph.html`、`GRAPH_REPORT.md` 和 `graph.json`。
先講結論
Graphify 不是向量資料庫,也不是單純 RAG。官方說得很直接,它不用 embeddings,也不放 vector store,而是建立一張可以 traverse 的真實 graph,你可以問一個概念是什麼,也可以追兩個概念之間的 shortest path,或要求它回答某個問題時只返回相關 subgraph。
這對 coding agent 很重要,因為大型專案裡的關係不是只有語意相似,還有 import、call、inherit、mix in、schema、設定檔、文件註解和設計決策,Graphify 把這些關係轉成節點和邊,讓 Agent 不必每次都用 grep 或全文讀取重新猜。
Graphify 是什麼
Graphify 是一個 AI coding assistant skill,安裝後可以在支援的平台裡輸入 `/graphify .`,Codex 則使用 `$graphify`。它會掃描當前資料夾,把程式碼、文件、PDF、圖片和影片整理成知識圖譜。
官方快速開始很短,重點是 PyPI 套件名稱叫 `graphifyy`,不是 `graphify`。這點要記住,因為 README 特別提醒其他 `graphify*` 套件不是官方套件。
uv tool install graphifyy # install the CLI (or: pipx install graphifyy)
graphify install # register the skill with your AI assistant
之後在 AI assistant 裡執行。
為什麼它不是一般 RAG
一般 RAG 常見做法是切 chunk、做 embedding、進 vector store,再用語意相似度找片段。這對文件問答很好用,但對程式碼架構不一定夠。因為程式碼最重要的線索常常是顯式關係,例如某個 class 被誰繼承,某個 function 被哪裡呼叫,某個 schema 影響哪個 API。
Graphify 對 code maps 採 local-first。程式碼透過 tree-sitter AST 解析, deterministic,不需要 LLM,也不會把程式碼送出本機。文件、PDF、圖片和影片這類語義 pass 才會使用 assistant model 或你設定的 API key。
EXTRACTED 和 INFERRED 是關鍵
Graphify 很值得學的一點,是它會標記每條邊的來源。`EXTRACTED` 代表關係明確存在於來源裡,`INFERRED` 代表由 Graphify 推導出來。這比單純把答案講得很肯定更重要,因為 Agent 常犯的錯不是沒有答案,而是不知道哪些是看到的,哪些是猜的。
aivi 的整理還提到第三類 `AMBIGUOUS`,代表不確定的關係要留給人工審查。這種設計很適合放進團隊工作流,因為架構理解不該只追求自動化,也要保留可審計性。
輸出檔案怎麼看
一次執行後,最核心的是三個檔案。
檔案 用途 我會怎麼用 graph.html 互動式圖譜 快速看社群、節點和跨模組關係 GRAPH_REPORT.md 摘要報告 讓 Agent 先讀專案重點和建議問題 graph.json 完整圖資料 後續 query、path、explain 不必重讀所有檔案
Graphify 的核心流程是偵測檔案、抽取關係、建立 graph、切分社群,最後讓 Agent 可以 query、path、explain。
最適合哪些場景
我會優先用在三種情境。
第一,接手陌生 codebase,需要先知道核心節點和模組邊界。
第二,專案同時有 app code、database schema、infra script 和文件,單純全文搜尋很難看出關係。第
三,研究資料夾裡有論文、截圖、筆記和實驗程式,需要把概念關係串起來。
這和我前面整理的 OpenWiki 可以搭配。OpenWiki 偏向替 Agent 建立 wiki 記憶,Graphify 偏向把來源資料拆成可查詢 graph。兩者放在一起,就是文件記憶加關係推理。
Benchmark 怎麼解讀
官方 README 摘要裡列了幾個 benchmark。LOCOMO recall@10 是 0.497,對照 mem0 的 0.048 和 supermemory 的 0.149,差距很大。LOCOMO QA accuracy 是 45.3%,低於 supermemory 的 49.7%,但高於 mem0 的 27.3%。LongMemEval-S QA accuracy 則是 76%,官方標註和 dense RAG tied。
這些數字適合當成方向參考。Graphify 的價值不只是單點 QA,而是能把關係路徑保存下來讓 Agent 反覆查詢。
Codex 使用要注意什麼
Graphify 支援 20 個以上 assistant 平台。對 Codex 使用者來說,官方特別提到 Codex 用 `$graphify`,不是 `/graphify`。另外如果要做 parallel extraction,需要在 `~/.codex/config.toml` 的 `[features]` 下設定 `multi_agent = true`。
這點和 Codex 作為 AI 代理 的方向很搭。Codex 如果只靠當下上下文,很容易在大型 repo 裡反覆找檔案。Graphify 可以先把核心結構整理好,讓後續任務更像查地圖,而不是每次重新探路。
可以匯出到 Obsidian、Neo4j 和 MCP
aivi 的整理提到 Graphify 有很多可選輸出,包括 Obsidian、SVG、GraphML、Neo4j Cypher、直接推送 Neo4j、MCP server 和 wiki 風格 Markdown。這代表它不是只服務某一個 assistant,而是可以把 graph 變成團隊知識資產。
如果你已經有 GraphRAG 使用本地 Ollama 的經驗,可以把 Graphify 看成更偏工程專案的知識圖譜入口。它不是取代 GraphRAG,而是把 repo、文件與工程關係先整理成一個可操作的圖。
我會怎麼導入
第一步只跑 code。因為 code map 是 local-first,不需要 LLM token,風險最低。
第二步打開 `graph.html` 看社群是否合理,再讀 `GRAPH_REPORT.md`,確認 god nodes 和 surprising connections 是否真的有幫助。
第三步才把 docs、PDF、圖片或影片加進來,並明確估算語義 pass 會用到哪個模型和多少成本。
如果是私有專案,我會先禁用媒體語義分析,只讓 tree-sitter 解析程式碼。等到確定 graph 有價值,再逐步開文件和圖片。這樣比較符合安全直覺,也不會一開始就把整個公司資料夾丟進模型。
我的判斷
Graphify 的核心價值不是炫酷的圖,而是讓 Agent 對大型專案有可追溯的結構記憶。它把「讀懂專案」變成一個可重複、可更新、可查詢的輸出,而不是每次都靠模型臨場發揮。
我會把它放進 AI coding 工作流的前置步驟。陌生 repo 先 Graphify,需求進來前先看 graph report,修改前查 path,修改後用 hook 或 watch 更新圖譜。這樣 Agent 比較不會只看局部檔案就亂改。
延伸資源
FAQ
Graphify 和 RAG 有什麼不同?
RAG 常用向量相似度找片段,Graphify 建立可 traversal 的知識圖譜。它更重視 import、call、inherit、文件引用和設計決策這類關係。
Graphify 會把程式碼送到雲端嗎?
程式碼 map 是 local-first,透過 tree-sitter AST 解析,不需要 LLM。文件、PDF、圖片和影片的語義分析才會使用 assistant model 或你設定的 backend。
Codex 可以用 Graphify 嗎?
可以。官方支援 Codex,並提醒 Codex 使用 `$graphify`。若要 parallel extraction,需要在 Codex config 啟用 `multi_agent = true`。
Graphify 適合私有專案嗎?
適合先從程式碼圖譜開始,因為 code parsing 可以本地完成。若要分析文件、圖片或影片,建議先確認使用的模型和資料外送邊界。
by Rain Chu | 7 月 15, 2026 | AI , skills , Tool
OpenWiki 最值得看的地方是它把 Agent 需要的上下文整理成可以持續更新的本地 wiki,對每天用 Codex、Claude Code、Hermes 或其他 coding agent 的人來說,真正麻煩的不是模型不夠聰明,而是每次開工都要重新解釋專案背景、設計理由、檔案位置和過去踩過的坑。
OpenWiki 的定位很清楚,它是一個 CLI,會替 codebase 或個人知識來源寫出 agent wiki,更精準一點說,它不是給人類慢慢翻的漂亮文件站,而是替 Agent 準備的第二大腦。
先講結論
OpenWiki 解決的是上下文斷裂,Code mode 會在目前 repository 產生 `openwiki/` 文件,並維護 `AGENTS.md` 和 `CLAUDE.md`,讓 coding agent 知道要先看 wiki。Personal mode 則把本地 repo、Notion、Gmail、Web Search、Hacker News、X 等來源整理成 `~/.openwiki/wiki`,比較像個人知識庫。
我會把它放在 Codex 與 GPT-5.6 合體成 AI 代理 之後的下一步,Agent 能不能做事,除了模型能力,也取決於它拿到的記憶是不是乾淨、穩定、可追溯。OpenWiki 就是在補這一層。
OpenWiki 是什麼
OpenWiki 是 LangChain 推出的 CLI,官方 README 的描述是,它會替 codebase 或 purpose memory 寫出並維護 agent wiki,也能透過內建 connectors 或 git repositories 擷取本地知識來源,再合成成本地 wiki。
它有兩種主要模式。Code mode 是針對目前程式碼倉庫,建立 repository documentation。Personal mode 是針對個人知識來源,建立本地 personal brain wiki。這兩個模式很像,但適合的工作不一樣。
模式 輸出位置 適合用途 我會怎麼用 Code mode `openwiki/` 替單一 repo 建立 Agent 文件 每個專案都放一份,搭配 Codex 和 Claude Code Personal mode `~/.openwiki/wiki` 整理個人知識、郵件、Notion、Web Search 做跨專案的研究記憶與決策索引
它不是 Obsidian 換皮
如果只看個人知識庫,Obsidian 加 Git 加 Claude CLI 確實能做到很多事情,但 OpenWiki 真正有差異的地方是 code mode,它會跟 repository 放在一起,程式碼變動後可以更新文件,甚至透過 CI 開 PR 或 merge request,讓文件跟著專案一起走。
這和一般筆記最大不同在於責任邊界。Obsidian 很適合人類整理想法,但 coding agent 更需要可被任務流程穩定引用的專案上下文。OpenWiki 會維護 `AGENTS.md` 和 `CLAUDE.md` 裡自己的區塊,讓 Agent 進 repo 後知道要先參考 wiki,而不是每次都重新掃整個專案。
OpenWiki 的重點不是單次產生文件,而是讓資料來源、wiki、Agent 和 CI 更新形成循環。
資料飛輪怎麼形成
OpenWiki 的資料飛輪可以拆成四步。
第一,把本地 repo、Notion、Gmail、Web Search、Hacker News 或 X 這些來源接進來。
第二,connector 先把 raw data 和 manifest 寫到本機。
第三,由 Agent 把來源資料整理成 wiki。
第四,下一次 Codex 或 Claude Code 做事時,先讀 wiki,再開始改 code。
這個流程可以降低「每次都從零開始理解專案」的成本,你之前如果有把 Claude Code、Codex、Hermes 放進同一個 AI 工作流 ,OpenWiki 就像是替這些工具加上一個共用的專案記憶層。
支援 ChatGPT login 這點很關鍵
OpenWiki 官方 README 裡有一段很重要。它支援 `openai-chatgpt` provider,可以透過 ChatGPT login 呼叫 OpenAI 的 Codex backend。也就是說,如果你有 ChatGPT Plus、Pro 或 Team 的 Codex 使用量,可以走訂閱方案裡的額度,而不是每次都用 OpenAI API token 計費。
OpenWiki 的設定方式是用 `OPENWIKI_PROVIDER=openai-chatgpt openwiki code –init` 或 `OPENWIKI_PROVIDER=openai-chatgpt openwiki personal –init` 進入 setup wizard,完成瀏覽器登入後,token 會存在 `~/.openwiki/.env`。refresh token 要當成密碼看待,不要同步到 Git,也不要放進任何公開筆記。
本地模型能不能拿來整理 wiki
個人 wiki 可能包含私密資料,全部丟給閉源模型不一定舒服,而且資料量一大,token 成本也會變成長期開銷。OpenWiki 支援 openai-compatible provider,所以理論上可以接 LiteLLM gateway、本地推理服務或任何 OpenAI 相容 endpoint。
但本地模型不是只看能不能跑。wiki 任務真正需要的是長上下文理解、文件分段、引用來源、去重、摘要穩定度和低幻覺。我的測法會很簡單:拿同一個 repo 跑 code mode,檢查它產出的模組邊界、安裝步驟、資料流、風險說明是否和實際程式一致。再拿一組故意放錯的文件,看模型會不會照抄錯誤資訊。
如果要走本地模型,我會先從 Qwen、DeepSeek 或其他長上下文模型開始,並搭配 本地大模型推理框架比較 裡提到的推理服務來測延遲和成本。若知識庫偏圖表、截圖或 PDF,再把 Docling 文件解析 這類工具放到前處理層。
資料要放同一個 wiki 還是分開
不是所有資料都應該塞進同一個知識庫。Code mode 的 wiki 應該跟 repo 綁定,保存專案架構、重要決策、開發流程、CI 和部署資訊。Personal mode 則放跨專案知識,例如研究筆記、工具比較、常用 prompt、會議記錄和文章素材。
如果全部混在一起,Agent 很容易在錯誤上下文裡找答案,比較好的做法是把 wiki 當成多個 source instance,而不是一個巨大雜物箱。OpenWiki 的 connector 設計也支援這種想法,例如可以建立不同的 Web Search source,一個追 AI research,一個追別的主題。
CI 自動更新才是重點
OpenWiki 支援把 update workflow 放進 GitHub Actions、GitLab CI 或 Bitbucket Pipelines。對我來說,這比第一次產生 wiki 更重要。因為文件真正會壞掉的地方,不是第一天沒寫,而是第三十天程式已經改了五輪,文件還停在舊狀態。
如果你的工作流已經開始讓 AI Agent 直接改程式,那文件也應該跟著 PR 更新,這可以和 讓 AI Agent 開工前先問清楚需求 放在一起看。前者讓需求更清楚,OpenWiki 則讓專案記憶更穩定。
第一次可以這樣試
安裝方式很直接。
針對目前 repository 建立 code wiki。
openwiki --init
openwiki --update
如果要測 ChatGPT login,則用 provider 指定。
OPENWIKI_PROVIDER=openai-chatgpt openwiki code --init
如果要更新個人知識庫,用 personal mode。
openwiki personal --init
openwiki personal --update
我的判斷
OpenWiki 比較像 Agent 工作流裡的基礎設施,而不是單純的筆記產品,如果你只有一個人、一個小專案,Obsidian 加 Git 可能已經夠用。但只要你開始讓多個 Agent 工具輪流碰同一個 repo,或想讓個人研究資料變成可重複使用的任務上下文,OpenWiki 就值得試。
我最看重的是 code mode、CI 更新、ChatGPT login 和 openai-compatible provider,這四個點合在一起,代表它可以同時服務雲端模型、本地模型、訂閱制 Codex 使用量,以及團隊裡的多 Agent 協作。
延伸資源
FAQ
OpenWiki 和 Obsidian 最大差異是什麼?
Obsidian 偏人類筆記,OpenWiki 偏 Agent 可讀的工作上下文。OpenWiki 的 code mode 會和 repository 綁定,並維護讓 Agent 參考 wiki 的提示文件。
OpenWiki 可以不用 OpenAI API key 嗎?
可以。官方支援 `openai-chatgpt` provider,可以用 ChatGPT login 走 Codex backend。它也支援 openai-compatible provider,可以接相容 endpoint。
個人資料適合放進 OpenWiki 嗎?
可以,但要先想清楚 provider 和資料邊界。私密資料建議優先測本地模型或可信任的私有 endpoint,並避免把 `~/.openwiki/.env` 同步到 Git。
OpenWiki 適合團隊使用嗎?
適合用在程式碼專案。搭配 GitHub Actions 或 GitLab CI,可以讓文件跟著程式碼更新,降低 Agent 和新人讀錯舊文件的機率。
近期留言