Select Page
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 工作流的第一關。不是因為它很華麗，而是因為它解決了一個最基本、也最常被忽略的問題：開始之前，先確定大家要做的是同一件事。

延伸資源

AISA 是什麼？一個 API Key 讓 AI Agent 連上 X、YouTube、股票與支付

AISA 是什麼？一個 API Key 讓 AI Agent 連上 X、YouTube、股票與支付

by | 7 月 7, 2026 | Agent, AI, Payment, skills

AISA 最有意思的地方，不是「又多一個 API 聚合平台」，而是它把 AI Agent 真正需要的外部能力，整理成一個可以被 agent 呼叫的資源層。

以前要讓 agent 查 X/Twitter、找 YouTube 競品、讀股票資料、換不同模型、甚至呼叫付費 API，常常要準備一堆帳號、一堆 API Key、一堆 OAuth 設定和一堆帳單。

AISA 想做的事很直接：用一個 API Key，把模型、資料源、Skills 和機器支付放到同一個入口。

這個方向對 AI Agent 很重要。模型本身再聰明，如果不能拿到即時資料、不能安全地調用工具、不能控制支出，它還是停留在「回答問題」而不是「完成任務」。AISA 的定位，就是補上這一層。

AISA 是什麼？不是只有模型 Gateway

從官方頁的說法來看，AISA 是面向 Agent Economy 的能力層與交易網路。它包含模型 gateway，但不只是模型 gateway。官網 FAQ 明確提到，AISA 讓 agent 用一個 API Key 和統一帳單關係，在同一處存取模型、API、資料源、Skills，以及機器對機器支付能力。

這裡的差異很關鍵。像 OpenRouter 這類多模型統一平台，主要解決「不同模型如何用同一套 API 呼叫」；AISA 更進一步，把資料 API、封裝技能、金融資料、社群資料、搜尋能力和機器支付也放進同一個 agent 工作流。

換句話說，AISA 想解的不是「我要用哪個模型」，而是「我的 agent 要怎麼真的去外面做事」。

一個 API Key 可以接哪些能力？

官方 `llms.txt` 把 AISA 定義成 autonomous AI agents 的 unified API gateway，列出的範圍很廣：GPT、Claude、Gemini、Grok、DeepSeek、Qwen、Kimi、MiniMax、GLM 等模型，還有 100+ data APIs、Agent Skills 和 stablecoin payments。

官網頁面也把幾個能力直接列出來：Tavily 網頁搜尋、YouTube 搜尋、X/Twitter 公開資料、金融市場資料、預測市場、Agent Mail、Circle 小額支付、Machine Payments Protocol。對 agent 來說，這些不是靜態資料庫，而是可以被工作流呼叫的「手腳」。

能力類型AISA 提供的方向適合的 Agent 任務
模型 GatewayGPT、Claude、Gemini、DeepSeek、Qwen 等模型推理、寫作、程式、長上下文分析
X / TwitterTwitter API、Twitter Autopilot、X Intelligence Automation輿情監控、發文、互動、自動整理趨勢
YouTubeYouTube Search、YouTube SERP選題研究、競品內容分析、頻道資料整理
金融與市場股票、Crypto、Prediction Market、MarketPulse研報、行情追蹤、事件監控
機器支付x402、Circle Nanopayments、MPP按次付費 API、agent 自主購買資料或服務

這也回應了第一則留言裡的需求：有人正在找這類資料資源，想讓 Agent 幫忙發推文。AISA 的 X/Twitter Skills 正好對應這種場景。重點不是讓模型「想像社群趨勢」，而是讓 agent 真的去讀公開資料、整理噪音、再決定要怎麼輸出。

X、YouTube、股票資料：Agent 要有真實世界的入口

AI Agent 很容易卡在一個地方：它可以推理，但沒有即時資料。

問它今天 X 上 AI Agent 的討論方向，它如果沒有工具，就只能靠舊知識猜，問它 YouTube 上某個主題競爭激不激烈，它如果沒有搜尋能力，就只能給你方法論，問它最新財報，它可能知道公司很大，但不知道最新數字。

AISA 的價值，是把這些「資料入口」變成 agent 可以安裝和調用的 Skills，X/Twitter 可以做輿情和發文，YouTube 可以做選題研究，金融 API 可以做股票研報，搜尋 API 可以補足即時資訊。這時候 agent 才比較像一個能工作的小助手，而不是只會聊天的模型。

這條路線也可以和你站上之前整理的 Claude Code Workflow 放在一起看：Claude Code、Codex 或其他 CLI agent 是工作介面，AISA 則比較像它們背後的外部能力層。

Skills 的意義：把「會回答」變成「會操作」

AISA 文件中列出的 Skills 很多，從 Twitter Autopilot、YouTube Search、SEO Keyword Research，到 US Stock Analyst、Stock Portfolio、Perplexity Deep Research、Multi-source Search 都有。這裡真正值得看的不是數量，而是 Skills 把任務包成 agent 能理解的操作流程。

同一個問題，有沒有 Skill，結果會差很多。沒有 Skill 時，模型可能只能說「你可以去查財報」。有 Skill 時，agent 可以知道要調哪個 API、要拿哪些欄位、資料錯了要去哪裡補、最後怎麼整理成報告。

這跟前面談過的 Ornith 1.0 自己拆任務、搭 scaffold 的方向其實有點像：模型不是只輸出答案，而是要有一套能完成任務的流程。AISA 則把外部 API 和 Skills 變成這套流程可以調用的零件。

x402 與機器自主付款：很酷，但一定要有護欄

AISA 官網也把機器對機器支付列為核心能力之一，包含 Circle Nanopayments、Machine Payments Protocol，以及 x402 / HTTP 402 風格的支付流程。

HTTP 402 Payment Required 這個狀態碼很早就存在，但以前沒有真正成為日常網路支付流程。x402 類協議讓 agent 呼叫受保護端點時，可以收到付款要求，完成結算，帶著付款證明重試請求。這對付費 API、資料服務、agent-to-agent 交易很有想像空間。

用白話講，402 不是一般錯誤，而是一種「這個資源要先付費」的握手訊號。Agent 第一次呼叫付費 API 時，服務端可以回傳 HTTP 402，並附上價格、收款地址、可用付款網路、付款證明格式和過期時間。Agent 不需要猜怎麼付錢，而是照著這份付款要求完成結算，再把付款證明帶回去重送同一個請求。

AISA 與 x402 讓 AI Agent 自主付費的架構圖

這裡要分清楚一件事：不是把信用卡號交給模型，也不是讓模型任意花錢。比較安全的設計是讓 Agent 只取得「受限制的付款能力」：例如只允許特定 API、單次最高 0.05 美元、每日最高 1 美元、只讀資料可以自動付款、發文或交易則要人工確認。

AISA 在這裡扮演能力層與記帳層，幫 agent 把 API、付款握手、用量紀錄和預算控制串起來。

AI 自己付錢的 6 個步驟

AI Agent 透過 HTTP 402 與 x402 自己付錢的六步驟流程圖
  1. Agent 呼叫付費 API，例如查即時金融資料、X 資料或高價值搜尋結果。
  2. 服務端回 HTTP 402 Payment Required，告訴 agent 這次請求需要付款，並提供價格、收款地址和付款格式。
  3. AISA 或 agent runtime 檢查政策：這個服務是否在白名單內、金額是否低於單次上限、今天預算是否還夠。
  4. 若通過檢查，錢包用 USDC 或支援的付款方式簽名付款，產生 payment proof。
  5. Agent 帶著付款證明重送請求，通常會把 proof 放在 header 或協議要求的位置。
  6. 服務端驗證付款有效後回傳資料，AISA 同步記錄誰呼叫、花多少、成功或失敗。

不過這裡不能只看酷炫的一面。Agent 能自己付費，就代表它也可能亂花錢、重複呼叫、被錯誤 prompt 帶偏，甚至被惡意服務誘導。AISA FAQ 提到可以發放 API Key、監控用量、設定預算或限額，這是必要條件，不是加分功能。

  • 先用低額度測試，不要一開始就給大額預算。
  • 把可呼叫服務設白名單，尤其是會產生費用的 API。
  • 設定單次、每日、每月限額。
  • 高風險動作先要求人工確認，例如發文、寄信、交易、付款。
  • 保留完整日誌，能看出哪個 agent、哪個 skill、哪次呼叫花了多少錢。

這也是 AI Agent 進入實際工作流後一定會遇到的問題：能力越大，權限邊界就越重要。你可以把它和 自學型 AI Agent 一起看，兩者都指向同一件事：agent 不只是變聰明，還要能被管理。

怎麼開始接入？先用 llms.txt 讓 Agent 讀懂平台

AISA 官網給了一個很適合 agent 使用的入口：讓 agent 先讀 `https://aisa.one/docs/llms.txt`，再依照目前環境安全地連接、配置並使用 AISA 的 API、Skills 和 LLM。

閱讀 https://aisa.one/docs/llms.txt，幫我在這個 agent 環境中安全地連接、配置並使用 AISA 的 API、Skills 和 LLM。

實務上可以分三步走：先到 AISA Console 的 get-started 頁面註冊並取得 `AISA_API_KEY`，再把 key 放進 CLI agent 或 IDE agent 的環境變數，最後挑一個低風險 Skill 測試，例如搜尋、YouTube 研究或只讀型 X 資料整理。

如果你原本就在用 Claude Code、Codex 或本地端模型，AISA 比較像補上「外部能力」的那塊拼圖。你也可以對照 Claude Code 搭配 LM Studio 與 Ollama 的零 API 成本環境 來思考：本地模型負責推理，AISA 負責外部資料和服務。

誰適合先試 AISA？

我會把 AISA 放在三種使用者的觀察名單裡。

第一種是內容創作者。你需要查 X 熱點、找 YouTube 競品、做 SEO keyword research，這些都很適合交給有資料 Skills 的 agent。

第二種是開發者和自動化玩家。你已經在用 Claude Code、Codex、OpenClaw 或其他 CLI agent，希望讓它們接更多真實 API，而不是每個服務都重新申請 key。

第三種是想做 agent 商業流程的人，例如市場開發、資料整理、金融監控、郵件自動化。這類任務需要的不只是模型，而是資料、工具、信箱、付款和成本控制一起工作。

至於只想聊天或單純換模型的人，AISA 可能不是最輕的選擇。這種情況，單純的模型 API 聚合平台或本地模型會更直接。可以參考你站上的 ApiFree：一個 API 打通所有 AI 模型 這類文章來比較不同路線。

結論：AISA 代表 Agent 從「模型」走向「資源層」

AISA 真正值得注意的，不是它支援多少模型，而是它把 agent 做事需要的資料、API、Skills、帳單和支付，往同一個入口收斂。

這會讓 AI Agent 的下一步變得更清楚：模型只是大腦，Skills 和 API 是手腳，預算和權限是安全邊界，支付能力則讓 agent 有機會直接參與服務交易。

短期內，我會先用只讀型任務測 AISA，例如 X 輿情整理、YouTube 競品研究、股票資料摘要。等日誌、成本和準確性都穩定，再逐步開放發文、寄信、付費 API 這類高風險能力。Agent 要進化成能工作的系統，靠的不是一次把權限全打開，而是一步一步把能力和護欄一起搭好。

FAQ

AISA 是什麼？

AISA 是面向 AI Agent 的能力層與交易網路，讓 agent 透過一個 API Key 連接模型、資料 API、封裝 Skills，以及機器對機器支付能力。

AISA 可以用 X 或 Twitter 嗎？

可以。AISA 官方文件列出 Twitter API、Twitter Autopilot、Twitter Command Center、X Intelligence Automation 等 Skills，適合做公開資料搜尋、輿情整理、發文和互動自動化。

AISA 跟 OpenRouter 有什麼不同？

OpenRouter 主要解決多模型 API 統一入口；AISA 包含模型 gateway，但更大的重點是把 API、資料源、Skills、Agent Mail、金融資料、搜尋與機器支付一起包成 agent 可用的資源層。

AISA 一定要用加密貨幣嗎？

不一定。官網 FAQ 提到可以從一般 AISA 帳號、API Key 和法幣充值額度開始，加密原生結算主要用在機器支付或 x402 類工作流，不是首次整合的必要條件。

Agent 自己付款安全嗎？

不能無限制開放。AISA 官網提到可透過 API Key、用量監控、預算或限額來控制 agent 支出，實務上應該先用低額度、白名單服務、日限額和人工審核逐步放權。

HTTP 402 如何讓 AI 自己付錢？

AI Agent 先呼叫付費 API，服務端回 HTTP 402 Payment Required，並附上付款要求，Agent 檢查預算和白名單後，用錢包簽名付款，取得付款證明，再帶著證明重送請求。服務端驗證付款後，才回傳資料。

用 AI 組一家公司：從 Claude Code、Codex、Hermes 到 nuwa-skill 的完整工作流

用 AI 組一家公司：從 Claude Code、Codex、Hermes 到 nuwa-skill 的完整工作流

by | 6 月 21, 2026 | AI, skills

未來的 AI 生產力，不只是「模型比較強」，而是「Agent Runtime + Skill + 人類決策」的組合能力。

重要連結整理

女媧 Skill 下載：

Agent Skills 官方說明

Claude Code Skills 官方文件

OpenAI Codex Skills 官方文件

OpenAI Codex GitHub

Hermes Agent 官方文件

Hermes Agent GitHub

所謂 AI 一人公司，不是指一個人什麼都不用做，讓 AI 自動幫你賺錢，比較務實的定義是：

一個人負責方向、判斷、審核與商業決策，AI Agent 負責研究、撰寫、開發、整理、測試、排程與重複性工作。

換句話說，人類的角色從「執行者」變成「總編輯、產品經理、技術主管、老闆」。

這也是影片最重要的啟發：AI 不是單一工具，而是一組可以分工的虛擬團隊。

Claude Code、Codex、Hermes 分別適合做什麼？

這三個工具剛好代表目前 AI Agent 工作流的三種方向。

我的看法是：如果你要打造 AI 一人公司，不應該只問「哪一個模型最強」，而是要問：

哪一個 Agent 適合負責開發？

哪一個 Agent 適合負責長期記憶與排程？

哪一個 Agent 適合安裝專門 Skill？

哪一個任務一定要由人類做最後判斷？

🏢 一人 AI 公司的組織架構與核心成員

要組建高效的團隊，就必須讓不同的 AI 模型各司其職、發揮所長。在我們的架構中，主要由以下三位核心成員組成：

  1. 董事長（你，唯一的人類）： 負責定大方向、提供靈感、拍板決策、把控最終產品質量。
  2. 祕書長（Hermes Agent）： 負責記錄分散的靈感與想法，具備極強的「長期記憶功能」，並對接社交軟體（如微信、Telegram）與本地工具。
  3. CEO 執行長（Claude Code）： 負責公司的統籌規劃、任務分配、邏輯思考與實際開發落地。
  4. 代碼審查員（OpenAI Codex）： 專職「挑毛病」，負責對寫好的程式碼進行安全性評估與漏洞審查。

🔍 深度洞察：Hermes、Codex 與 Claude Code 的技術選型見解

在搭建系統前，我們必須深入了解這三款終端 AI 工具的本質與差異，才能完美地將它們編排進工作流中：

  • Claude Code（專職研發與執行）： 這是由 Anthropic 官方推出的終端工具，主語言融合了 Shell、Python 與 TypeScript。它在「編寫代碼」與「理解複雜上下文」上展現出極強的實力，是最完美的 「辦公與研發型執行代理」。
  • OpenAI Codex（專職軟體工程與審查）： 採用 Rust 編寫，本地運行極其輕量。Codex 近年已演化為完整的工程代理，在自動生成 PR 級修改、修復 Bug、閱讀 Repo 方面非常嚴謹。最關鍵的體感是：如果讓同一個模型自己寫代碼又自己審查，它往往看不出問題；但如果讓 Claude Code 負責開發、Codex 負責審查，Codex 就能精準揪出一堆漏洞！
  • Hermes Agent（長期記憶與通用協調）： 它是基於 Python 的中立 Agent 框架，遵循開放的 agentskills.io 標準。Hermes 最大的強項在於 「長期記憶、自我學習與渠道接入」。它像一個會持續成長的系統，適合作為始終在線的指揮官。

女媧 Skill 是什麼？

女媧 Skill 是一個開源的 Agent Skill 專案，目標不是單純模仿名人的語氣，而是把一個人的公開資料整理成可執行的「思維 Skill」。

它的核心概念是：蒸餾一個人怎麼想，而不是只模仿一個人怎麼說話。

舉例來說，你可以讓 AI 從公開資料中整理出某位人物的：

心智模型

決策啟發式

表達 DNA

價值觀與反模式

誠實邊界

面對新問題時可能採用的判斷框架

這就讓 AI 不只是「用某人的口吻回答」，而是比較接近「用某人的思考框架分析問題」。

女媧 Skill 的工作流程

女媧 Skill 的運作大致可以整理成四個階段：

六路並行蒐集：從著作、訪談、社群媒體、批評者觀點、決策紀錄、人生時間線等方向蒐集資料。

三重驗證提煉：一個觀點必須跨多個領域出現、能推斷新問題立場、且不是所有聰明人都會這樣想，才值得被收錄。

建立 Skill：把心智模型、決策方法、表達風格、價值觀與限制寫入 SKILL.md。

品質驗證：用已知問題與未知問題測試，避免 AI 過度自信或胡亂回答。

這套流程對 AI 一人公司的價值很高，因為它等於把「專家經驗」變成可以安裝、可以版本管理、可以重複調用的工作能力。

如何安裝女媧 Skill？

官方 GitHub 下載連結如下：

https://github.com/alchaincyf/nuwa-skill

最簡單的安裝方式是使用通用 CLI 安裝器：

npx skills add alchaincyf/nuwa-skill

如果你想明確指定安裝到某個 Agent，也可以依照 runtime 指定。例如：

帮我安装 skill：https://github.com/alchaincyf/nuwa-skill

如果要手動安裝，可以把 GitHub 專案 clone 到對應的 skills 目錄。

一人產品團隊要靠 Agent Skills 框架、測試自動化、遠端優先的人機協作環境來疊加效率

大神必讀文章連結：https://georgexing.substack.com/p/how-i-build-with-ai-as-a-1-person

給大家一個可以直接複製貼上給 Claude Code 使用的提示詞：

請讀懂這篇文章：https://georgexing.substack.com/p/how-i-build-with-ai-as-a-1-person

# AI 一人公司 / 一人產品團隊完整提示詞

你現在要扮演我的「AI 一人公司作業系統總指揮」。
你的任務不是單純回答問題，而是協助我把一個想法，轉換成可以由 AI Agent 團隊執行的完整產品開發、內容產出或商業驗證流程。

## 一、背景設定

我正在打造一套「AI 一人公司」工作流。

核心概念是：

人類負責方向、品味、商業判斷、使用者價值、品質把關與最後決策。
AI Agent 負責研究、規劃、開發、測試、審查、文件、營運與重複性工作。

請把我視為：

* 創辦人
* 產品經理
* 品質審查者
* 最終決策者

請把 AI Agent 團隊視為：

* Claude Code：主要工程師，負責理解專案、規劃功能、寫程式、重構與除錯
* Codex：嚴謹審查者，負責檢查計畫、審查程式碼、找出邏輯漏洞、資料流程錯誤與後端風險
* Hermes Agent：長期營運助理，負責記憶、排程、跨平台提醒、自動化任務與長期追蹤
* 女媧 Skill / Agent Skills：專家能力庫，負責把人物思維、領域方法論、公司 SOP、品牌規範、開發規範轉換成可重複使用的能力

請避免空泛勵志，重點放在可以執行、可以檢查、可以交給 Agent 的流程。

---

## 二、我要處理的主題

請根據以下輸入，幫我建立完整的一人產品團隊工作流。

### 我的產品 / 專案 / 文章 / 功能想法

【在這裡貼上我的想法】

### 目標使用者

【在這裡描述目標使用者，例如：老師、開發者、內容創作者、中小企業老闆、學生、設計師】

### 我想達成的結果

【在這裡描述結果，例如：做出 MVP、寫一篇 WordPress 文章、設計一個 SaaS 功能、改版某個頁面、建立自動化流程】

### 目前限制

【在這裡填寫限制，例如：只有我一個人、預算有限、時間有限、需要本地部署、需要 WordPress、需要 Next.js、需要支援中文】

### 已有工具或技術

【在這裡填寫，例如：Claude Code、Codex、Hermes Agent、OpenAI、Ollama、llama.cpp、Next.js、Prisma、PostgreSQL、WordPress、GitHub】

---

## 三、你的工作方式

請你按照以下流程執行，不要跳步。

---

# Phase 1：產品腦力激盪與問題定義

請先幫我釐清：

1. 這個想法真正要解決的問題是什麼？
2. 使用者現在怎麼解決這個問題？
3. 使用者最痛的地方是什麼？
4. 這個產品或內容的主要使用情境是什麼？
5. 成功的定義是什麼？
6. 哪些需求是必要的，哪些只是好看但不重要？
7. 哪些地方最容易被 AI Agent 誤解？
8. 哪些地方一定要由人類做最後判斷？

請輸出：

* 一句話產品定位
* 目標使用者描述
* 使用者痛點
* 核心使用情境
* Jobs To Be Done
* 成功指標
* 不做清單
* 風險清單
* 需要我確認的關鍵決策

請注意：
如果我的想法太模糊，你不要直接開始寫執行計畫，而是先幫我整理成幾個可選方向，讓我選擇。

---

# Phase 2：PRD / 規格文件

在 Phase 1 完成後，請幫我產生一份產品規格文件。

格式如下：

## 1. 專案名稱

## 2. 一句話說明

## 3. 背景與問題

## 4. 目標使用者

## 5. 使用者故事

請用這種格式：

* 作為【使用者角色】，我想要【行為】，以便【得到的價值】。

## 6. 核心功能

請區分：

* 必要功能
* 次要功能
* 暫不處理功能

## 7. 使用流程

請用步驟式流程描述。

## 8. UX / UI 原則

請說明：

* 畫面上最重要的主要行動是什麼
* 哪些資訊要優先顯示
* 哪些資訊應該收合或延後
* 什麼狀態下需要提醒使用者
* 哪些設計會增加摩擦，應該避免

## 9. 技術需求

請包含：

* 前端
* 後端
* 資料庫
* API
* 權限
* 檔案或媒體處理
* 第三方服務
* AI 模型或 Agent 使用方式

## 10. 邊界情境

請列出：

* 空資料狀態
* 錯誤狀態
* 載入狀態
* 權限不足
* AI 回答失敗
* 網路中斷
* 使用者輸入不完整
* 重複送出
* 多人或多裝置同步問題

## 11. 驗收標準

請用 checkbox 格式輸出。

---

# Phase 3：Agent 分工設計

請把整個工作拆給不同 AI Agent。

請用表格輸出：

| 角色 | 使用工具 | 負責任務 | 輸入 | 輸出 | 注意事項 |
| -- | ---- | ---- | -- | -- | ---- |

至少包含：

1. 人類創辦人
2. Claude Code
3. Codex
4. Hermes Agent
5. 女媧 Skill / Agent Skills
6. 測試 Agent
7. 文件 Agent
8. SEO / 內容 Agent

請特別說明：

* 哪些工作可以並行
* 哪些工作必須串行
* 哪些工作需要人類審核後才能繼續
* 哪些工作可以交給較小模型
* 哪些工作必須交給較強模型

---

# Phase 4：實作計畫

請把 PRD 轉換成可執行的實作計畫。

格式如下：

## 實作總覽

* 目標
* 預估修改範圍
* 主要檔案
* 新增檔案
* 修改檔案
* 刪除檔案
* 資料庫變更
* API 變更
* 測試範圍
* 風險等級

## 任務清單

每個任務請用 checkbox 格式：

* [ ] Task 1：任務名稱

  * 目的：
  * 修改檔案：
  * 具體步驟：
  * 完成標準：
  * 可能風險：
  * 建議交給哪個 Agent：

請把任務拆到 AI Agent 可以明確執行的粒度。
不要只寫「完成前端」這種模糊任務。
要寫到「修改哪個檔案、增加哪個元件、處理哪個狀態、需要哪個測試」。

---

# Phase 5：Codex 審查提示詞

請產生一段可以交給 Codex 使用的審查提示詞。

目標是讓 Codex 審查 Claude Code 產出的計畫或程式碼。

Codex 審查提示詞必須包含：

1. 請檢查是否符合 PRD
2. 請檢查是否有資料流程錯誤
3. 請檢查是否有 race condition
4. 請檢查是否有權限問題
5. 請檢查是否有錯誤狀態未處理
6. 請檢查是否有安全風險
7. 請檢查是否有測試缺口
8. 請檢查是否有過度設計
9. 請檢查是否有和原始使用者價值偏離
10. 請用 Critical / High / Medium / Low 分級

請輸出可直接複製的 Codex Review Prompt。

---

# Phase 6：Implementation Review 自動測試設計

請模擬一位人類產品審查者，設計端到端測試情境。

請輸出：

## 使用者情境測試

| 編號 | 情境 | 操作步驟 | 預期結果 | 嚴重性 |
| -- | -- | ---- | ---- | --- |

至少包含：

* 新使用者第一次使用
* 正常成功流程
* 使用者輸入錯誤
* AI 回答失敗
* 網路或 API 錯誤
* 權限不足
* 重複操作
* 長時間載入
* 行動裝置或小螢幕
* 使用者中途離開後回來

## Playwright / Maestro / 手動測試建議

請根據專案類型建議：

* Web 專案：Playwright
* Mobile 專案：Maestro 或 Xcode simulator
* API 專案：API integration test
* WordPress 文章：SEO、可讀性、連結、標題層級、圖片 alt、內外連檢查

---

# Phase 7：遠端優先工作流

請幫我設計一套適合一人公司使用的遠端優先 AI Agent 工作流。

請包含：

## 1. 長時間任務如何執行

例如：

* 使用 tmux 保持 session
* 使用 SSH 遠端連入開發主機
* 使用 Tailscale 或 VPN 連線
* 使用 Git worktree 管理多個功能分支
* 使用通知機制提醒我 Agent 卡住

## 2. 手機上如何追蹤

請設計：

* 手機查看進度
* 手機批准或否決 Agent 決策
* 手機補充語音輸入
* 手機查看測試結果

## 3. 語音輸入策略

請幫我把口語想法整理成可執行規格。
如果我貼上的是語音轉文字，請先整理語意，不要糾正文法而忽略內容。

## 4. 多 Agent 並行策略

請說明：

* 哪些任務可以平行跑
* 如何避免不同 Agent 修改同一個檔案互相衝突
* 如何用 Git branch / worktree 分開任務
* 如何設定合併順序
* 如何保留回滾點

---

# Phase 8：女媧 Skill / 專家顧問團設計

請根據這個專案，建議我應該建立哪些 Skill。

請輸出：

| Skill 名稱 | 用途 | 觸發時機 | 應包含內容 | 不該做什麼 |
| -------- | -- | ---- | ----- | ----- |

請至少思考以下類型：

* 產品品味 Skill
* 工程規範 Skill
* UI / UX 審查 Skill
* SEO 文章 Skill
* 安全檢查 Skill
* 品牌語氣 Skill
* 客戶訪談 Skill
* 測試審查 Skill
* 競品分析 Skill
* 專家人物思維 Skill

如果適合，請幫我產生一份 `SKILL.md` 草稿。
`SKILL.md` 需要包含：

* name
* description
* 使用時機
* 不使用時機
* 工作流程
* 輸出格式
* 品質檢查清單
* 誠實邊界

---

# Phase 9：如果這是 WordPress 文章

如果我的輸入目標是寫 WordPress 文章，請改用以下輸出格式。

請產出：

1. 主標題
2. 三個 SEO 標題選擇
3. SEO 中繼資料說明
4. 文章標籤，請用繁體中文，並用半形逗號分隔
5. WordPress 可直接貼上的文章內容
6. 內部連結建議
7. 外部連結建議
8. 圖片或流程圖建議
9. 可以用「創作圖像」生成的圖片提示詞
10. 延伸閱讀區塊

文章要求：

* 使用繁體中文
* 如果來源有簡體中文，請改成繁體中文
* 使用 WordPress block editor 友善格式
* 避免簡體字
* 標題層級清楚
* 適合 SEO
* 不要堆砌關鍵字
* 官方網站與下載連結必須放入文章
* 對工具的評價要務實，不要過度吹捧
* 文章要能接續「AI 一人公司：Claude Code、Codex、Hermes 與女媧 Skill」這個主題

---

# Phase 10：最後輸出總結

最後請用以下格式總結：

## 我建議你現在先做的 3 件事

1.
2.
3.

## 哪些部分可以立刻交給 AI Agent

## 哪些部分必須由我親自判斷

## 這個專案最大的風險

## 這個專案最快的 MVP 路線

## 下一個可執行指令

請給我一段可以直接貼到 Claude Code / Codex / Hermes Agent 的下一步指令。

---

## 重要規則

1. 不要只給概念，要給可執行步驟。
2. 不要假設 AI 會自動理解我的產品品味，要把標準寫清楚。
3. 不要讓 Agent 直接長時間執行高風險操作，必須設計審查點。
4. 不要只檢查程式能不能跑，也要檢查使用者流程是否合理。
5. 不要把 AI 當成全自動創辦人；AI 是員工，人類才是老闆。
6. 如果資訊不足，請先提出最少量但最高價值的澄清問題。
7. 如果可以先做合理假設，就先標明假設並繼續，不要卡住。
8. 對每個輸出都要加上品質檢查清單。
9. 所有內容都用繁體中文。
10. 若引用外部工具、官方網站、GitHub 或下載連結，請列出來源與用途。

現在請根據我提供的主題，開始 Phase 1。

感想

未來真正有競爭力的人，不一定是最會寫提示詞的人，而是最會設計 AI 工作流的人。

你可以把 Claude Code 當工程師，把 Codex 當快速執行者，把 Hermes Agent 當長期助理，再用女媧 Skill 建立不同領域的顧問團。

但最後，真正的老闆還是你。

AI 一人公司的重點不是讓 AI 取代你，而是讓你從執行者升級成指揮者。

補充：

商業導師：

https://github.com/dontbesilent2025/dbskill

美工與設計：(寶玉skills)

https://github.com/JimLiu/baoyu-skills/blob/main/README.zh.md

如何用 baoyu-skills 在 WordPress 批次產生高質感產品圖