Select Page
Flint Chart 是什麼？讓 AI Agent 用語意規格可靠產生圖表

Flint Chart 是什麼？讓 AI Agent 用語意規格可靠產生圖表

by | 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 工作流程。若只是一次性的簡單圖表，現有大型模型或熟悉的圖表函式庫可能已經足夠。

參考資料

OfficeCLI 是什麼？讓 AI Agent 操作 Word、Excel、PowerPoint

OfficeCLI 是什麼？讓 AI Agent 操作 Word、Excel、PowerPoint

by | 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 讓 AI Agent 讀取修改驗證和修正 Office 文件的流程圖
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 更穩定地處理報告、簡報和表格。

Playwright CLI 是什麼？讓 Codex 用 CLI 操作瀏覽器

Playwright CLI 是什麼？讓 Codex 用 CLI 操作瀏覽器

by | 7 月 15, 2026 | AI, skills

Playwright CLI 這個方向很值得注意，因為它把瀏覽器自動化從「大型工具協議」拉回成 coding agent 很擅長使用的 CLI 指令，對 Codex、Claude Code、GitHub Copilot 這類工具來說，差別不只是能不能操作網頁，而是能不能用更少上下文、更少 token、更穩定地完成重複任務。

以前要讓 Agent 操作瀏覽器，常見做法是 MCP、Chrome extension、CDP debug port，或直接寫 Playwright 程式。這些方法各有好處，但也都有代價，Playwright CLI 的取向很清楚：把常見瀏覽器操作包成簡短命令，搭配 skill 讓 Agent 知道怎麼用。

先講結論

Playwright CLI 是 Microsoft 推出的 Playwright 命令列工具，我們以前常常用他的程式庫，也有用過他的 MCP ，現在官方 README 直接寫它是 Playwright CLI with SKILLS，它可以 open、goto、click、type、snapshot、find、screenshot、console、requests、trace、video，也有 `show` dashboard 可以觀察背景裡的 browser sessions。

我會把它定位成 AI coding agent 的瀏覽器手腳，MCP 比較像完整工具層，Playwright CLI 則像可被 Agent 快速呼叫的瀏覽器 shell。大型專案裡，Agent 一邊改程式、一邊跑 UI、一邊截圖驗證，CLI 路線通常更省上下文。

為什麼 CLI 比 MCP 更省

官方 README 對這點講得很清楚，CLI 加 skill 的好處，是不需要把大型 tool schema 和冗長 accessibility tree 塞進模型上下文。Agent 只要呼叫目的明確的命令，再讀回 snapshot 或輸出檔，就能完成下一步。

這也解釋了為什麼有人把原本基於 Chrome Dev MCP 的 skill 改成 Playwright Python 或 CLI 流程後，速度可以明顯變快。核心不是 Playwright 比 MCP 神奇，而是把探索階段標準化成腳本後，就不需要每次都消耗大量 token 重新推理。

Playwright CLI 和 MCP 在 coding agent 工作流中的差異圖
CLI 加 skill 適合高頻、可標準化的瀏覽器任務。MCP 仍適合需要長時間持續狀態與豐富頁面 introspection 的探索型工作。

它能做什麼

Playwright CLI 的命令很完整，已經不是只打開網頁和截圖而已。核心操作包含 `open`、`goto`、`type`、`click`、`fill`、`drag`、`hover`、`select`、`upload`、`check`、`snapshot`、`find`、`eval`。也有 console、network requests、trace、video 和 locator 生成。

這讓它不只是測試工具，也可以變成瀏覽器自動化框架。舉例來說，Agent 可以先 `open` 網頁，再用 `snapshot` 取得頁面狀態，用 `find` 找文字或元素，用 `click` 和 `fill` 操作表單，最後 `screenshot` 留存結果。這種流程很適合寫進 skill，之後重複執行。

自動發文、自動測試、社群互動

Playwright CLI 最容易落地的場景，是把每天都要重複打開瀏覽器完成的事，變成可檢查、可重跑、可留紀錄的工作流。它可以用在自動發文，例如登入 WordPress、填標題、貼上 Gutenberg HTML、上傳圖片、儲存草稿。這不一定要取代 API，而是當某些後台沒有好用 API 時，讓 Agent 仍然能用瀏覽器完成同一件事。

第二個場景是自動測試。Agent 可以開啟本機開發站、測登入流程、點選主要按鈕、檢查表單錯誤、看 console、抓 network requests、最後截圖留存。這種流程很適合接在 Codex 修改程式之後，讓它不是只改完程式就停下來，而是自己打開畫面驗證一次。

第三個場景是社群互動。以 Facebook 為例，它可以幫你打開指定頁面、整理新貼文、判斷哪些內容和你關心的主題相關，再把候選清單列出來讓你確認。確認後再執行點讚、收藏或回覆，會比完全自動亂點安全很多，也比較不容易違反平台規範。

我會把這類流程設計成「Agent 先整理，人再批准，Agent 再執行」。自動發文可以先存草稿，自動測試可以直接跑，自動社群互動則最好保留人工確認。這樣 Playwright CLI 才不是單純的瀏覽器代點工具，而是把人的判斷和 Agent 的執行力接在一起。

安裝方式

官方安裝方式很直接，Node.js 需要 18 以上。

npm install -g @playwright/cli@latest
playwright-cli --help

如果要讓 Claude Code、GitHub Copilot 等工具讀到本機 skill，可以執行。

playwright-cli install --skills

最小 demo 可以這樣跑。

playwright-cli open https://demo.playwright.dev/todomvc/ --headed
playwright-cli type "Buy groceries"
playwright-cli press Enter
playwright-cli screenshot

但 codex 他不會也一起安裝，記得將 ~/.claude/skills/playwright-cli 手動複製一份到 ~/.codex/skills/playwright-cli

Session 是實用關鍵

Playwright CLI 預設會在記憶體裡保留 browser profile，也就是說，同一個 session 裡 cookies 和 storage state 可以跨 CLI calls 保留，但瀏覽器關掉後會消失。如果需要跨重啟保留登入狀態，可以加 `–persistent`。

這對日常 Web 工具很有用。很多雲端服務沒有 API，或 API 權限很麻煩，但網頁端功能完整。只要能穩定接管已登入的 browser session，Agent 就能把一段 GUI 操作變成 CLI 流程，再逐步沉澱成可重複腳本。

playwright-cli -s=work open https://example.com --persistent
PLAYWRIGHT_CLI_SESSION=work claude .

Dashboard 讓你能接管 Agent 的手

`playwright-cli show` 是我很喜歡的一個設計。它會開啟 visual dashboard，讓你看到所有 running browser sessions，有 grid view 和 session detail，當 Agent 在背景操作時，你可以觀察它走到哪裡，也可以接管滑鼠鍵盤介入。

這比完全黑箱的自動化舒服很多，尤其是登入、二階段驗證、付款頁、複雜後台這類任務，最好不要讓 Agent 完全盲跑。Dashboard 讓人和 Agent 可以輪流掌控同一個 browser session。

跟 Chrome extension、CDP、Browser MCP 怎麼選

這幾條路線我會這樣分。Chrome extension 適合直接接你的日常瀏覽器，登入態和擴充功能都在，但穩定性和權限邊界要看實作。CDP debug port 很直接，也常被大型模型理解，但安全邊界要自己管。Browser MCP 適合需要豐富頁面 introspection 的任務，但上下文成本可能比較高。

Playwright CLI 的定位則是把常見動作變成可觀察、可重複、可腳本化的命令。它不一定取代所有方案，但很適合放在 Codex 作為 AI 代理 的日常工作流裡，需要更高階的瀏覽器自動化，也可以對照 Stagehand 的 AI 瀏覽器自動化。

真正的價值是把 GUI 操作沉澱成 Skill

一次性的瀏覽器操作不稀奇。真正有價值的是，Agent 第一次探索成功後，把流程改寫成 CLI 或 Python 腳本，下次就不用再讓模型從頭看畫面。這也是留言裡很有用的一個實測方向：原本要跑很久又吃 token 的流程，改成標準化腳本後，可以變成十幾秒完成。

這和 讓 Agent 自己搜尋和安裝 skills 的方向可以接起來。Skill 不只是教學文件，而是把成功流程變成下一次可以直接使用的能力。

我會怎麼導入

第一步先拿一個低風險網站測 `open`、`snapshot`、`find`、`click`、`screenshot`。不要一開始就碰重要帳號。第二步把常用流程拆成固定腳本，例如登入後查狀態、下載報表、填表單、截圖回報。第三步才把流程寫成專案 skill，讓 Codex 或 Claude Code 在需要時自動呼叫。

如果是團隊環境，我會把 session 名稱固定，例如 `qa-app`、`admin-staging`、`docs-preview`。這樣 Agent 不會混用瀏覽器狀態，也比較容易透過 dashboard 觀察。這和 多 Agent 協作工作流 也很搭。

我的判斷

Playwright CLI 的重點不是多一個瀏覽器控制工具，而是把 Agent 做 GUI automation 的方式變得更工程化。先探索，再標準化，再變成 skill。這條路線會比讓模型每次重看整個頁面更可靠，也更省。

如果你平常會讓 Codex 幫你跑網頁測試、填後台、截圖、查 console、看 network request，Playwright CLI 很值得放進工具箱。MCP 仍有價值，但 CLI 加 skill 會是很多高頻任務更輕的解法。

延伸資源

FAQ

Playwright CLI 和 Playwright MCP 差在哪裡？

Playwright CLI 偏向簡短命令和 skill 工作流，適合高頻 coding agent 任務。Playwright MCP 更適合需要持續狀態、豐富頁面 introspection 和長時間探索的任務。

Playwright CLI 可以保留登入狀態嗎？

可以。同一個 session 內 cookies 和 storage state 會保留。如果要跨瀏覽器重啟保存，可以用 `–persistent`。

Codex 可以使用 Playwright CLI 嗎？

可以。Playwright CLI 是命令列工具，Codex 可以透過終端指令使用它。若搭配 skill，Agent 更容易知道該怎麼拆解瀏覽器操作流程。

什麼任務最適合用 Playwright CLI？

最適合可重複、可腳本化的網頁任務，例如表單操作、UI 測試、截圖驗證、console 檢查、network request 檢查和後台例行操作。

Graphify 是什麼？把專案變成 AI 可查詢知識圖譜

Graphify 是什麼？把專案變成 AI 可查詢知識圖譜

by | 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 裡執行。

/graphify .

為什麼它不是一般 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 把資料夾轉成可查詢知識圖譜的流程圖
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 benchmark 摘要圖，包含 LOCOMO recall 和 QA accuracy
這些數字適合當成方向參考。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 可以本地完成。若要分析文件、圖片或影片，建議先確認使用的模型和資料外送邊界。

Grill Me 是什麼？讓 AI Agent 開工前先問清楚需求

Grill Me 是什麼？讓 AI Agent 開工前先問清楚需求

by | 7 月 9, 2026 | AI, skills

很多 AI Agent 做不好，不是因為模型太弱，而是任務在一開始就太模糊，使用者一句「幫我做一個工具」、「幫我寫一個遊戲」、「幫我規劃一個工作流」，Agent 會很認真地往前衝，但它其實是在替你補完一堆你沒有講清楚的決策。

Grill Me 這類 skill 的價值，就在於把「開工前的需求訪談」變成固定流程，它不急著執行，而是先反過來問你：目標是什麼？使用者是誰？限制在哪裡？哪些選項還沒決定？什麼事情一定不能做？這一步看起來慢，實際上是在幫你省掉後面反覆重做的時間。

如果你已經在用 Codex、Claude Code、Cursor、Windsurf 或 OpenCode 這類工具，這篇可以當成一個提醒：真正拉開成果差距的，不只是模型版本，而是你有沒有一套讓 Agent 開始前先釐清需求的工作流。站上之前整理過 OpenWork / OpenCode 桌面工作台，那偏向執行環境，這篇談的是執行前的需求對齊。

先講結論：不要太快叫 Agent 開始做事

AI Agent 最常見的失控點，是使用者以為自己已經講清楚，但其實只講了一個方向，人類同事遇到模糊需求，可能會回頭問你，Agent 則常常直接開做，做出一個看起來完整、但不是你真正想要的東西。

Grill Me 的做法很簡單：在實作前先訪談。它會針對任務目標、使用場景、輸出格式、限制條件、技術選擇、驗收標準一路追問，直到這個任務足夠明確，Agent 才開始真正執行。

這不是把 prompt 寫長而已，而是把「需求還沒完成」這件事明確暴露出來，對我來說，這是使用 AI Agent 很重要的一個分水嶺：你不是把一段模糊想法丟給模型猜，而是先和模型一起把決策樹走完。

Grill Me 是什麼？

Grill Me 來自 Matt Pocock 的 skills 倉庫，這個倉庫不是單一工具，而是一組可安裝到 AI coding agent 裡的工作流程 skill，包含需求訪談、文件對齊、規格整理、TDD、debugging、code review 等。

我在 2026 年 7 月 9 日查看 GitHub API 時，這個倉庫已經超過 16 萬顆星，授權是 MIT，README 裡的定位也很明確：這些 skill 是小型、可調整、可組合的流程，而不是把整個開發過程交給一套巨大框架接管。

Grill Me 本身很短，核心是啟動一段 grilling session，也就是讓 Agent 對你的計畫或設計進行密集訪談。它不是替你做決策，而是逼你把原本藏在腦袋裡的決策說出來。

為什麼「需求訪談」會讓結果差很多？

用「做一個側邊欄貪食蛇遊戲」這種需求來看，沒有訪談時，Agent 也能做出一個可玩的版本。它可能有開始按鈕、分數、速度調整，也能用鍵盤操作。表面上看起來不差。

但只要開始追問，需求會變得完全不一樣：這個側邊欄是 Codex 裡的小工具，還是瀏覽器側邊欄？它是一次性 demo，還是要固定留下來？等待 Agent 工作時能不能玩？鍵盤焦點可能不在遊戲上，是否需要畫面按鈕保底？撞牆要不要死亡？分數要不要保存？記錄要不要能清除？

這些問題不是細枝末節，而是產品體驗的骨架。當它們沒有被問出來，Agent 只能照自己的預設做，當它們被問出來，Agent 才能把設計、互動、資料保存、通知機制都接到同一個使用情境上。

一個好用的 Grill Me 流程，應該問哪些問題？

我會把這類訪談問題分成七組。你不一定要每次問滿，但至少要讓 Agent 在開工前碰過這些維度。

  • 目標：這次任務真正要改善什麼？成功之後看起來是什麼樣子？
  • 受眾：誰會使用這個成果？是自己用、團隊用、客戶用，還是公開產品？
  • 場景：使用者會在什麼時間、什麼裝置、什麼流程裡使用它？
  • 限制：不能用哪些技術？不能改哪些檔案？不能花太多時間在哪裡？
  • 輸出：最後要交付文章、程式、規格、PRD、測試、圖片，還是一組可執行步驟？
  • 驗收：怎樣才算完成？要不要測試？要不要截圖？要不要能回滾？
  • 禁區：哪些事情不要做？哪些語氣、設計、依賴、資料來源要避開？

站上之前寫過 CO-STAR prompt 框架，那套方法適合把指令寫得更完整；Grill Me 則更像互動式版本，讓 Agent 透過追問幫你補齊缺口。

Matt skills 倉庫才是核心資源

Matt Pocock 的 skills 倉庫。這個連結比一般工具推薦更重要，因為 Grill Me 不是孤立存在，它其實是整套工作流的一個入口。

這套 skill 大致分成 engineering 和 productivity，Grill Me 屬於 productivity，適合非程式任務或早期想法釐清；Grill with Docs 則偏 engineering，會把訪談結果延伸到專案文件、domain model、ADR 等長期維護資料。

這也呼應我之前整理的 Matt Pocock Skills 工作流：真正有價值的不是某個單點技巧，而是把訪談、規格、測試、程式碼審查變成一套固定節奏。

Grill Me 不是讓 AI 變聰明，而是讓任務變清楚

用了 Grill Me，不代表模型突然變成更高階版本，也不代表結果一定完美，它真正改善的是「任務定義品質」。

模糊任務的問題在於，Agent 會把大量隱性選擇變成自己的預設，比方說你說「做一個工具」，它要猜是網頁、CLI、桌面 app 還是瀏覽器插件；你說「幫我寫文章」，它要猜讀者是新手、工程師、主管還是 SEO 流量；你說「做得好看」，它要猜品牌、風格、資訊密度、互動狀態。

Grill Me 把這些猜測改成問題。當問題被回答，Agent 的輸出就不再只是「通用答案」，而會更貼近你的真實情境。

我會怎麼把 Grill Me 放進自己的 Codex 流程？

如果是新專案，我會把流程拆成四步。

  • 第一步，用 Grill Me 釐清需求。先不要寫程式，先讓 Agent 問到目標、限制、驗收方式都清楚。
  • 第二步，把訪談整理成規格。可以轉成 PRD、spec 或 issue，避免後面上下文掉失。
  • 第三步，用 TDD 或驗收清單鎖住品質。讓 Agent 先知道什麼叫完成，而不是做完才補救。
  • 第四步，讓 code review / debug 流程收尾。不要把「看起來能跑」當成完成。

這條路線和 用 Superpowers 建立 AI 開發紀律的方向很接近：不要把 Agent 當一次性神諭，而是把它放進一套有檢查點、有回饋、有驗收的流程。

安裝 skill 前，先想清楚你要它解決什麼問題

很多人看到 skill 倉庫，第一反應會是全部安裝。這可以，但我更建議先從自己的痛點倒推。

如果你常常覺得 Agent 做出來的東西方向不對，先試 Grill Me。若你已經有專案文件，但 Agent 老是誤解術語和架構，可以研究 Grill with Docs。若你遇到的是改一處壞三處，TDD 和 debugging 類 skill 會更有幫助。

如果你想自己建立類似流程，也可以回頭看 用 skill-creator 建立自訂技能。真正好用的 skill，通常不是把所有規則塞滿，而是把一個高頻問題變成可重複執行的流程。

可以直接拿去用的 Grill Me 提示詞

如果你還沒安裝 skill，也可以先用下面這段作為替代版，它不如正式 skill 可維護，但已經能改善很多「太快開工」的問題。

在開始執行前，請先訪談我。
你要把我的需求問清楚，而不是直接開始做。

請一次只問 1 到 3 個最關鍵的問題。
每個問題請附上你的推薦答案，以及為什麼你推薦這樣選。
當你認為需求、限制、輸出格式、驗收標準都足夠清楚後，
請先整理一份任務規格給我確認。
等我明確說「開始執行」之後，你才可以動手。

這段的重點有三個：一次不要問太多、問題要附推薦答案、最後要整理成規格再等確認，這樣做可以避免 AI 把訪談變成問卷疲勞，也能讓使用者比較快做決策。

AI Agent 的品質，常常卡在開工前

Grill Me 給我的最大提醒是：不要把所有問題都歸咎於模型。很多時候，Agent 不是不會做，而是它根本不知道你真正要的是哪一種成果。

需求訪談不是形式，它是把模糊想法變成可執行任務的過程。當目標、場景、限制、輸出和驗收都被問清楚，Agent 才有機會交出真正能用的結果。

我會把 Grill Me 放在 AI Agent 工作流的第一關。不是因為它很華麗，而是因為它解決了一個最基本、也最常被忽略的問題：開始之前，先確定大家要做的是同一件事。

延伸資源