by Rain Chu 9 月 15, 2026 | Apple , Mac
Mac 空間快滿時，我會先找出到底是哪些資料夾變大，再決定要清快取、移除軟體，還是整理下載過的 AI 模型。
Mole 把這些工作集中在終端機裡，輸入 mo 就能用方向鍵操作，涵蓋磁碟分析、清理、解除安裝、系統維護與即時監控。
對已經使用 Homebrew、Codex 或本地模型的 Mac 使用者，Mole 很適合當作日常維護工具，它能協助回收空間、找出資源占用，但清掉檔案並不代表 CPU 會自動變快。先知道瓶頸在哪裡，才不會刪了一堆快取，最後只是讓軟體重新下載相同資料。
Mole 免費嗎，終端機版和 DMG App 差在哪裡
目前的 Mole GitHub 專案 是免費開源 CLI，採 GPL-3.0 授權。
Mole for Mac 繁體中文官網 提供的是另外一款付費原生圖形介面 App。免費開源的說法應對應 CLI，不能套用到所有同名版本。
CLI 適合用鍵盤操作、希望檢查原始碼，或要把結果交給其他程式處理的人，原生 App 則提供視覺化磁碟樹狀圖、App 管理、選單列狀態等操作介面，對不想開終端機的人更直覺，官方目前標示 App 為一次購買、終身更新，一份授權可用於兩台 Mac，實際價格和條款以購買頁為準。本文以下以免費 CLI 為主。
安裝 Mole，先確認 Homebrew 能使用
按下 Command 加空白鍵，搜尋「終端機」。如果已安裝 Homebrew，先檢查版本，再安裝 Mole。
brew --version
brew install mole
mo --version
mo還沒裝 Homebrew，可以到 Homebrew 官網 取得安裝命令。安裝完成後，照終端機顯示的 Next steps 設定環境，再重新開啟終端機。Apple Silicon 和 Intel 的安裝位置可能不同，直接照自己電腦輸出的步驟最穩。
輸入管理員密碼時，終端機通常不會顯示字元或星號，輸入完按 Enter 即可。Mole 只有在操作需要較高權限時才會提出要求，不必把每一條命令都加上 sudo。
第一次使用，我會從 Analyze 開始
先執行磁碟分析，沿著最大的資料夾往下查看。比起直接啟動清理，這一步更容易理解自己的硬碟用在哪裡。
mo analyze也可以指定範圍，縮小到下載資料夾或外接磁碟。外接磁碟不包含在預設總覽裡，要另外指定。
mo analyze ~/Downloads
mo analyze /Volumes使用方向鍵瀏覽，需要判斷內容時在 Finder 開啟對應位置。Analyze 內的移除操作會在確認後將所選項目移到垃圾桶，這和部分清理命令的刪除行為不同。要立即回收實際空間，還要考慮垃圾桶是否已清空。操作快捷鍵以畫面下方提示為準。
AI 模型快取很大，但它不一定是垃圾
本地 AI 工作流常會保存多個模型版本、量化格式與下載快取，依照 Hugging Face 官方快取說明 ，Hub 檔案快取預設位於 ~/.cache/huggingface/hub，設定過 HF_HOME 或 HF_HUB_CACHE 時則可能在別處。可以先用 Mole 查看預設快取的上層資料夾。
mo analyze ~/.cache/huggingface模型檔值得保留與否，取決於近期是否還會使用，以及重新下載的成本。你可以先列出每個模型的用途，保留常用版本，再逐一移除已淘汰的模型。不同快取版本可能共用檔案，適合搭配模型下載工具自身的管理功能，避免只刪掉某個片段後留下不完整模型。
如果你正在比較 llama.cpp、MLX 與 Ollama 的本地推理方式 ，要特別留意不同工具可能各自保存權重。整理時先確認模型屬於哪個工具，才知道之後要從哪裡重新取得。
做 ComfyUI 本地影音工作流 時也一樣，模型、輸入素材和生成成果應分開管理。尚未交付的成品有保留價值，不能只因為容量大就把整個輸出目錄視為可刪快取。
Clean 清快取，先看 dry-run 結果
準備清理時，先預覽會處理哪些路徑。需要保留的快取可以加入保護清單，再執行清理。
mo clean --dry-run
mo clean --whitelist確認預覽內容後，以下命令會實際進行清理。
mo clean清理範圍包括符合規則的快取、日誌、暫存與已移除 App 的殘留。清理後部分軟體第一次開啟可能要重建快取或重新下載資料，這是規劃清理時間時需要考慮的成本。Mole 的保護規則可以減少誤操作，但仍要自己確認預覽清單是否包含工作需要的資料。
瀏覽器也要分清楚快取和設定。Chrome 擴充功能的存放位置 和一般網頁快取用途不同，不要自行把整個 Chrome 使用者資料夾都當成垃圾刪除。
需要追查剛才做了什麼，可以查看操作紀錄。
mo history
mo history --jsonUninstall 移除 App，也檢查相關殘留
不用的軟體可以交給 Uninstall，一起檢查能明確對應到該 App 的相關檔案。先做預覽，確認選取的是正確程式與版本。
mo uninstall --dry-run確定要解除安裝後，再執行下方命令並選取 App。
mo uninstall如果 App 本體早已刪除，改用 mo clean 檢查殘留比較合適。同一套軟體的不同版本可能共用資料，所以「完整移除」不能理解成所有相似名稱的資料夾都應一起消失，仍在使用的共用資料需要保留。
Optimize 與 Status，分別處理維護和觀察
遇到縮圖、搜尋或系統服務異常，可以先預覽 Optimize 的維護項目。它會依系統狀況略過不適用的工作，不能把它當成每台 Mac 都會得到相同效果的加速按鈕。
mo optimize --dry-run確認項目後才執行實際維護，需要排除的工作可用保護設定管理。
mo optimize --whitelist
mo optimize只想了解目前 CPU、記憶體、磁碟、網路與電力狀態時，用唯讀的 Status 儀表板即可。按 q 可以離開。
mo status對跑本地模型的人來說，可以在載入模型前後觀察記憶體壓力，再在生成內容時看 CPU 和磁碟活動。如果空間回收了，運算仍然慢，就應繼續檢查模型大小、同時執行的工作與記憶體，而不是反覆清理相同快取。
開發者可以用 Purge 整理專案產物
許多舊專案占空間，是因為 node_modules、target、build 或 dist 長期保留。Purge 會以專案為單位整理候選項目，先設定要掃描的資料夾，再做預覽。
mo purge --paths
mo purge --dry-run看清楚清單後，實際清理使用以下命令。
mo purgePurge 會永久刪除你確認的項目 。原則上這些產物能重新建立，但自己的專案可能把手工修改內容或唯一成品放進 build 或 dist，所以仍需先核對。清掉依賴後，下一次開發也要重新安裝，應保留套件清單與 lockfile。
下載資料夾裡的舊安裝包則交給 Installer。先確認是否還需要離線重裝，再決定移除。
mo installer --dry-run以下會進入安裝包的實際移除流程。
mo installerMole 常用命令速查
工作 起手命令 使用重點 查看空間 mo analyze 先瀏覽，移除需確認 查看狀態 mo status 唯讀監控 清理快取 mo clean –dry-run 先預覽，再執行 clean 移除 App mo uninstall –dry-run 先確認程式與殘留 系統維護 mo optimize –dry-run 先確認維護項目 專案產物 mo purge –dry-run 正式執行可能永久刪除 舊安裝包 mo installer –dry-run 先確認是否仍需保存
先從查看與預覽開始，再依需要執行對應操作 整合 Raycast，減少每天開終端機的步驟
Mole 官方提供快速啟動器腳本，可以加入 Clean、Uninstall、Optimize、Analyze 與 Status。以下命令請逐行操作，先下載官方腳本，用 less 閱讀內容，按 q 離開閱讀畫面，確認後才執行最後一行。
curl -fsSL https://raw.githubusercontent.com/tw93/Mole/main/scripts/setup-quick-launchers.sh -o setup-mole-launchers.sh
less setup-mole-launchers.sh
bash setup-mole-launchers.sh
開啟 Raycast Settings，進入 Extensions 的 Script Commands
新增腳本目錄 ~/Library/Application Support/Raycast/script-commands
執行 Reload Script Directories 重新載入
在 Raycast 搜尋 analyze 或 status，開啟相應功能
清理指令仍然會啟動 Mole 本身的操作流程。快速啟動器的價值在於少打字，並不代表能略過對清理範圍的判斷。官方腳本在找到 Alfred 設定時，也會建立對應 workflow。
讓 Codex 協助讀取磁碟報告
Mole 已有 JSON 輸出，適合把資料交給 Codex 整理。可以請 Codex 解釋哪些資料夾占空間，以及哪些是模型、快取、安裝包或專案產物，再由自己決定下一步。
mo analyze --json ~/Documents
mo status --json
mo history --json可以這樣下提示詞。以下是整理報告的範例，並不會自動開始刪除。
請使用 Mole 的唯讀分析與 JSON 輸出，整理我指定資料夾的空間占用。按模型檔、專案依賴、生成成果與安裝包分類，列出路徑、容量與可能用途。請保留正在使用的模型和唯一成品，先提供清理建議，等我指定項目後再執行刪除。
JSON 報告可能包含使用者名稱與專案路徑。把它交給雲端服務時，就和 Mole 本身在本機掃描是兩個不同的資料處理步驟，可以先限制分析範圍。
更新、移除與常見錯誤
用 Homebrew 安裝的版本，更新時指定 Mole 即可。
brew update
brew upgrade mole不再需要這個工具時，用原本的套件管理方式解除安裝。
brew uninstall mole如果用官方安裝腳本安裝，則使用 mo update 更新與 mo remove 移除工具本身。不要把 mo uninstall 和 mo remove 混在一起，前者是管理其他 App，後者是移除 Mole。
遇到 Bundled status binary not found，先確認版本與命令位置。如果原本是 Homebrew 安裝，可用以下方式重新安裝套件，恢復遺失的執行檔。
command -v mo
mo --version
brew reinstall mole原本使用官方腳本安裝時，依錯誤訊息執行 mo update，或重新執行官方安裝流程。若電腦同時裝了兩個版本，先整理命令搜尋路徑，避免更新了一份，實際卻執行另一份。
FAQ
Mole 可以完全免費使用嗎
CLI 版可以，GitHub 專案採 GPL-3.0 開源授權。原生 Mole for Mac App 是另外的付費產品，兩者的授權和介面不同。
Mole 清理後一定會讓 Mac 變快嗎
不一定。它可以協助回收空間與處理部分維護工作，效能是否改善仍取決於磁碟剩餘空間、記憶體壓力、背景程序和實際工作負載。
Mole 有 Windows 版嗎
主要產品針對 macOS，官方 GitHub 目前另有實驗性的 windows 分支。不要把 Mac 的 Homebrew 命令與清理規則直接套到 Windows，也不要假設兩邊功能完全相同。
Analyze 和 Clean 都會刪除檔案嗎
Analyze 主要供瀏覽分析，選取移除後會確認並移到垃圾桶。Clean 會按清理規則實際刪除資料，第一次操作先使用 dry-run 預覽。
我會怎麼把 Mole 放進日常工作
第一次先跑 Analyze 和 Status，弄清楚容量與資源占用。空間不足時再預覽 Clean，需要移除 App 時用 Uninstall，舊專案交給 Purge。這樣比較容易把每次清理和實際問題對上，也能保留常用模型與工作成果。
我很喜歡 Mole 把路徑、大小與操作結果攤開的方式。對經常下載模型、建立測試專案與輸出影音素材的人，能知道硬碟裡放了什麼，比每次容量不足才四處翻資料夾方便得多。
功能與命令依 Mole 官方文件 核對，原生 App 資訊可看 繁體中文官網 ，清理行為的保護範圍可參考 官方安全說明 。
by Rain Chu 7 月 8, 2026 | Agent , AI
OpenCode 和 OpenWork 這組工具，真正值得看的地方不是「又一個 Claude Code 替代品」而已，而是它把 AI Agent 從純命令列往桌面工作台推了一步, OpenCode 負責 agentic coding 的核心能力，OpenWork 則把工作目錄、Session、Skill、Plugin、MCP、權限確認和遠端 worker 包成比較容易操作的圖形介面。
這條路線剛好踩在很多人的痛點上：Claude Code 好用，但成本、封閉性和模型選擇會卡住；Codex 很適合開發工作，但一般辦公流程、跨工具流程、團隊共享設定，還需要另一層產品化介面, OpenWork 的企圖就是把 opencode 這套底層能力包成「可以給團隊重複使用的 Agent 工作流」。
如果你之前已經在看 OpenCode 如何使用本地端模型 ，這篇可以當成下一步：不只讓模型接進來，而是把 skills、plugins、MCP 和權限流程一起整理成可操作的工作台。
OpenWork 是 opencode 的桌面層，不是另一個單純聊天 App
OpenWork 官方把自己定位成 Claude Cowork 和 Codex 的開源替代方案，它是一個 local-first 的桌面 app，背後 powered by opencode 你可以在本機跑 host mode，也可以用 client mode 連到既有 OpenCode server, 之後透過 UI 管理 session、看 streaming event、處理 permission request、管理 templates、安裝 skills 和 plugins。
這個定位很重要。OpenWork 不是要取代 OpenCode，而是把 OpenCode 原本比較偏開發者的 CLI 體驗，變成更像工作台的產品。OpenCode 擅長讀檔、改檔、跑工具、處理任務；OpenWork 則負責讓這些能力變得可視化、可審核、可分享。
這也是我覺得它和 用 AI 組一家公司 那篇可以放在一起看：真正有價值的不是單一模型多會回答，而是能不能把一套工作流程產品化，讓人、Agent、工具和權限一起運作。
OpenCode 和 OpenWork 的分工
這兩者的分工：
項目 OpenCode OpenWork 核心角色 AI coding agent 與 CLI/Server 核心 桌面工作台與協作介面 使用者體驗 偏工程師、命令列、設定檔 偏圖形介面、session、權限與模板 擴充方式 plugins、agents、SDK、生態資源 skills manager、plugins、MCP、templates 適合場景 開發、專案自動化、終端機工作流 把 Agent 流程包成團隊可重複使用的工作台
OpenWork README 裡有一句很關鍵：它是 ejectable 意思是就算 UI 還沒包到某個能力，只要底層 OpenCode 能做，理論上還是可以回到底層去做。這是開源工具很重要的特性，因為你不會被單一 UI 的產品進度完全卡死。
安裝與模式：先分清楚桌面 App、Host mode、Client mode
OpenWork 有幾種使用方式。最直覺的是下載桌面 app；如果你想自己 build，就要準備 Node.js、pnpm、Bun、Rust/Tauri、OpenCode CLI 官方 source build 流程大致是：
git clone https://github.com/different-ai/openwork
cd openwork
git checkout dev
pnpm install --frozen-lockfile
pnpm dev 如果只想跑 CLI host，也可以用 OpenWork Orchestrator：
npm install -g openwork-orchestrator
openwork start --workspace /path/to/workspace --approval auto
這裡要注意一件事：OpenWork 的 Host mode 會在本機跑 host stack，預設綁在 127.0.0.1 Client mode 則是連到既有的 OpenCode server，如果你看到 ready 是灰色、New task 不能按，第一個方向不是懷疑模型，而是檢查工作目錄、host stack、OpenCode server、provider key 或本地模型連線是否真的準備好。
Skills、Plugins、MCP：OpenWork 真正有用的地方
OpenWork 的 Skills manager 可以列出 `.opencode/skills`，也能把本地 skill folder 匯入到 `.opencode/skills/<skill-name>` 這個方向很像 Claude Code / Codex 的 skills 概念：把常用工作流程寫成可重複使用的操作說明，讓 Agent 每次做事不用從零開始猜。
如果你站上看過 用 skill-creator 建立 Skill ，OpenWork 這裡的邏輯也很接近：與其每次都寫一長串 prompt，不如把工作流程變成可安裝、可分享、可版本化的能力。
Plugin 則是 OpenCode 的原生擴充方式。OpenWork 會讀寫 `opencode.json`，Project scope 在工作目錄的 `opencode.json`，Global scope 通常在 `~/.config/opencode/opencode.json`。
awesome-opencode 這個 repo 則像是生態目錄，整理了 plugins、themes、agents、projects 和 resources 它不是核心工具，但很適合用來觀察 opencode 生態正在長出哪些周邊能力。
Build Mode 和 Plan Mode：不要一開始就讓 Agent 放手改
OpenCode 這類 agentic tool 最容易出問題的地方，是使用者還沒搞清楚任務邊界，就直接讓 Agent 進入執行狀態。比較穩的做法是先用 Plan Mode 讓它讀資料、拆任務、確認工具與風險，再進 Build Mode 讓它動手。
我會把它想成兩層：
Plan Mode ：先觀察、讀檔、列步驟、找不確定性、提出執行順序。Build Mode ：開始改檔、跑命令、安裝依賴、呼叫工具、產出結果。
這和 Claude Code Workflow 裡的做法一致：先讓 Agent 把路線講清楚，再授權它動手。
AI Agent 的效率不是靠更衝，而是靠每一步都能回頭檢查。
本地模型與 Ollama：重點在 provider 設定，不是只裝好模型
很多人以為「Ollama 已經能跑模型」就等於 OpenWork 會自動看到它，但中間還差 provider 設定、base URL、模型名稱，以及 OpenCode / OpenWork 讀取設定檔的位置。
原則上，你要確認三件事：
Ollama server 已經在跑，常見位置是 `http://localhost:11434`，遠端機器則要確定防火牆與 bind address。
OpenCode 的 provider 設定有指到 Ollama 或 OpenAI-compatible endpoint。
OpenWork 使用的 workspace / dev-mode / global config，和你實際編輯的設定檔是同一份。
這部分可以搭配 Ollama 遠端連線教學 和 LM Studio 與 Ollama 的零 API 成本環境 一起看 OpenWork 不是魔法入口，它還是要靠底層 provider 設定把模型接起來。
Token 成本：免費模型不等於無限使用
免費通常代表某段時間、某個額度、某個服務條款下不用付費，不代表可以無限燒，也不代表 latency、rate limit、上下文長度和品質都沒有代價。
OpenCode / OpenWork 這種工具特別容易消耗 token，因為 Agent 會讀檔、反覆規劃、呼叫工具、看輸出、再修正你讓它處理一個大型 workspace，成本不是只有最後回答那幾百字，而是整個工作循環。
所以比較實際的策略是：
簡單查詢與短任務用便宜或本地模型。
高風險修改、跨檔案重構、複雜判斷再用強模型。
能寫成 skill / template 的流程就固化，減少每次重新解釋。
先 Plan 後 Build，避免 Agent 一路試錯燒成本。
Windows 使用者要先注意的幾個坑
Windows 問題不少，這也很符合這類 Tauri / Node / CLI 混合工具的現況。
OpenWork README 也有提到，Windows access 有一部分是透過 paid support plan；source build 則會牽涉 Node、pnpm、Bun、Rust、Tauri 和 OpenCode CLI。這不是一般雙擊安裝就結束的輕工具。
Ready 灰色 ：先檢查 host stack 是否啟動、workspace 是否選對、provider 是否可用。New task 灰色 ：通常表示前置狀態未完成，例如沒有有效 session、工作目錄或 worker 尚未 ready。nul 檔案問題 ：Windows 下 `nul` 是特殊裝置名，如果工具誤產生同名檔，刪除會很麻煩。這種問題要優先回報 issue，並避免在重要目錄直接測不穩定版本。`.config` 目錄看起來不對 ：要確認你看的到底是 OpenCode global config、workspace config，還是 dev-mode 隔離狀態。
這裡我會建議用比較保守的方式測：先開一個乾淨測試資料夾，不要直接指到重要專案；先確認 session、provider、permission、簡單讀寫任務都正常，再把 OpenWork 放進真正的工作流程。
OpenWork 適合誰？
OpenWork 現階段比較適合三種人。
第一種是想把 OpenCode 圖形化的人。 你已經接受 agentic coding，但希望有 session、permission、skills、plugins 的視覺工作台。第二種是想把 Agent 工作流交給團隊的人。 Templates、skills、remote sharing 這些能力，重點都是讓流程可以重複與分享。第三種是正在比較 Claude Code、Codex、OpenCode 生態的人。 OpenWork 讓 opencode 不只停留在 CLI，而是開始往產品化入口走。
但如果你現在只想要一個穩定、少設定、打開就能工作的辦公 AI，OpenWork 可能還會讓你覺得太工程化。它的價值在於可控與可擴充，不在於完全隱藏複雜度。
資源整理
截至我整理資料時，OpenWork GitHub repo 約 1.6 萬 stars，awesome-opencode 約 8 千多 stars 這代表生態正在被快速關注，但也代表文件、Windows 體驗、plugin 相容性和錯誤處理還會持續變動。用它之前要有「早期開源工具」的心理預期。
OpenWork 把 OpenCode 從工具變成工作台
OpenCode 已經回答了「AI Agent 能不能在 terminal 裡幫我做事」；OpenWork 想回答的是下一題：「這套能力能不能被包成一個可視化、可分享、可審核的工作台？」
現階段最好的用法，是先用 OpenCode 跑穩本地模型、provider、skills 和 plugins，再用 OpenWork 管理 session、權限、template 與團隊共享流程。
OpenWork 的重點不是多一個聊天視窗，而是讓 opencode 的 Agent 能力開始變成「可交付的工作流程」。這會是 2026 年 AI 工具很重要的一條線。
FAQ
OpenWork 是什麼？
OpenWork 是 powered by opencode 的開源桌面工作台，讓使用者在本機或遠端 server 上管理 AI Agent session、skills、plugins、MCP、templates 與權限確認。
OpenWork 和 OpenCode 有什麼差別？
OpenCode 是底層 AI coding agent 與 CLI/Server 核心；OpenWork 是圖形化桌面層，負責把 session、權限、skills、plugins、templates 與工作目錄變得更容易操作。
by Rain Chu 7 月 8, 2026 | AI , 影片製作
OpenMontage 最吸引我的地方，不是「一句話自動做完 AI 影片」這種口號，而是它把 AI 影片製作拆成一套比較像真實片廠的工程流程：研究、提案、腳本、分鏡、素材、剪輯、合成、檢查，全部交給 coding agent 去編排。
這件事有意思，因為現在很多 AI 影片工具其實只是在「生成幾段畫面」或「把幾張圖做動」, OpenMontage 的方向不太一樣，它把影片看成一個專案，而不是單一模型輸出, 你可以用生成式素材，也可以走免費素材檢索，也可以讓 Remotion、HyperFrames、FFmpeg、TTS、字幕工具一起工作。
如果你之前看過我寫的 HyperFrames 用 HTML 寫影片 ，OpenMontage 可以理解成更上層的總控：HyperFrames 或 Remotion 是渲染舞台，OpenMontage 則負責決定要演哪一齣、需要哪些素材、哪個管線比較適合。
先講結論：它不是單一工具，而是一套 agentic video workflow
OpenMontage 官方把它定位成 open-source agentic video production system。
這句話翻成白話就是：你不是打開一個剪輯軟體慢慢拉時間軸，而是把需求丟給 AI coding assistant，讓它在專案裡呼叫一串工具，最後產出可渲染的影片專案。
它目前主打 12 條 production pipelines、52 個 production tools、數百個 agent skills。這些數字先不用神化，真正重要的是架構：OpenMontage 把「做影片」拆成管線選擇問題。要做動畫解說、紀錄片蒙太奇、動態文字、產品廣告、Podcast repurpose、字幕翻譯，走的流程不應該一樣。
這也很符合我對 AI Agent 的看法。真正能落地的 Agent，不是一直聊天，而是能選工具、讀檔、跑命令、檢查輸出、失敗後改路線。這點跟我前面整理過的 Ornith 35B 與 Hermes 工作流 是同一個方向：模型不是主角，流程控制才是主角。
本地部署的基本盤：Python、Node、FFmpeg，再加一個 AI coding assistant
OpenMontage 的安裝門檻不算低，但也沒有到很誇張。官方 README 的 Quick Start 是：
git clone https://github.com/calesthio/OpenMontage.git
cd OpenMontage
make setup 如果是在 Windows 環境，配套筆記把步驟拆得更實際：先裝 Git、Python 3.11、Node.js；建立 venv；安裝 Python requirements；進 remotion-composer 跑 npm install；再預熱 HyperFrames。簡化後大概是這樣：
git clone https://github.com/calesthio/OpenMontage
cd OpenMontage
python -m venv venv
venv\Scripts\activate
python -m pip install -r requirements.txt
cd remotion-composer
npm install
cd ..
npx --yes hyperframes --version OpenMontage 不是只有 Python 腳本，它會用 Remotion 做 React 影片渲染，也會用 HyperFrames 做 HTML/GSAP 類型的動態文字與 motion graphics，也就是說，它本質上是一個跨 Python、Node、前端渲染、影音處理的混合專案。
如果你本來就在研究 AI 影片生成模型，可以延伸看 Wan 2.1 的整理 ，OpenMontage 不是要取代這些模型，而是把模型、素材庫、TTS、剪輯和渲染器放進同一條可控流程。
零 API Key 可以玩，但不要把零成本理解錯
OpenMontage 官方 README 有一段很重要：沒有付費 API key 也能做東西。它可以用 Piper TTS、本地字幕、FFmpeg、Remotion、HyperFrames，以及 Archive.org、NASA、Wikimedia Commons 這類開放素材來源，配套筆記則建議本地中文配音可以接 dots.tts，走 OpenAI 相容的本地 API 服務。
但我會把這件事講精準一點：零 API Key 不等於零成本。你省下的是雲端生成 API 的帳單，但仍然有時間成本、硬碟成本、顯卡成本、網路下載成本，以及 Agent 跑錯路線後的重跑成本。
比較正確的理解是：OpenMontage 讓你有機會把成本從「每次生成都付費」改成「本地工具與免費素材優先，必要時才接付費 provider」。這也是我喜歡本地 AI 工作流的原因，重點不是假裝不用花錢，而是你可以決定錢花在哪裡。
如果你對本地 TTS 有興趣，可以接著看 VoxelCPM 本地 TTS 與離線部署 。OpenMontage 這類工具能不能舒服使用，中文配音品質其實會大幅影響成品觀感。
三條路線：生成類、檢索類、動態文字類
真正開始用 OpenMontage 時，我覺得要先把題目分成三種，不要一律丟給同一條管線。
生成類 ：適合知識動畫、概念解釋、抽象主題。重點是腳本、旁白、視覺生成與字幕。檢索類 ：適合森林、海浪、城市、科技感、自然景觀這種通用氛圍題。重點是免費素材庫與剪輯節奏。動態文字類 ：適合頻道預告、產品短片、宣傳片、資訊卡。重點是排版、節奏、字卡與音樂。
這裡最大的坑是「題目和管線不匹配」。例如你想做歷史事件、特定人物、某次火箭發射、某個實驗室場景，免費素材庫不一定找得到精準畫面。這種題目硬走檢索管線，很容易找到一堆氣氛接近但內容對不上的 B-roll。
相反地，如果題目是「地球的呼吸」「雨夜城市」「森林甦醒」這類氛圍型主題，檢索管線就很適合。因為它不需要某個唯一正確鏡頭，只要找到情緒與節奏對的真實素材，就能剪成一支完整作品。
這點也可以和 OiiOii 動畫分鏡工作流 放在一起看。AI 影片的關鍵不只是模型，而是你能不能在生成前就把「題目、鏡頭、節奏、素材來源」講清楚。
OpenMontage 最值得記下來的 6 個坑
這次配套筆記最有價值的地方，是把幾個踩坑點寫得很直接。我整理成實作時應該先記在旁邊的清單。
不要亂加逐詞字幕。 動畫解說如果要求逐字、逐詞字幕，切詞可能會很碎。普通字幕反而比較乾淨。檢索管線要避開大規模 corpus builder。 直接把 NASA、Archive.org 整段抓下來建語料庫，很容易下載失控。快速路線是 direct_clip_search，只用 Pexels / Pixabay，720p，限制槽位。不要讓 Agent 自己亂翻中文搜尋詞。 檢索素材時，最好把每個鏡頭先翻成 5 個字以內的英文短語，例如 misty forest valley、ocean waves、city rain night。提示詞會影響管線選擇。 如果你寫「科普、旁白、TTS、中文字幕」，系統很可能走 animated-explainer；如果你要真實素材蒙太奇，就要明確寫 documentary montage、real footage only、direct_clip_search、no narration。8GB 顯卡不適合硬衝本地影片生成。 能塞進去的模型選擇有限，還要 CPU offload，最後可能等很久只得到短短幾秒低解析片段。免費素材路線適合通用題，不適合特定命名物。 森林、城市、海浪很好找；某個具名歷史場景或特定設備就不要硬搜。
OpenMontage 現階段最合理的期待值：可以跑通，可以做出東西，但要用對題目、用對管線、不要期待它第一次就像成熟商業剪輯工具。
我會怎麼下 prompt：先鎖管線，再鎖素材來源
OpenMontage 不是越自由越好用。你如果只寫「幫我做一支很酷的 AI 影片」，Agent 會需要猜太多東西：要不要旁白？要不要真實素材？要不要生成圖片？要不要字幕？要用 Remotion 還是 HyperFrames？
比較穩的 prompt 應該長這樣：
製作一支 60 秒紀錄片蒙太奇，主題是「地球的呼吸」。
管線：documentary-montage。
素材：只用真實素材，只從 Pexels / Pixabay 搜尋，走 direct_clip_search，不要 Archive.org，不要 NASA，不要 corpus_builder。
音訊：不要旁白，只放背景音樂。
畫面：720p，10 個素材槽位。
搜尋詞：每個槽位用我給的英文短語，不要自行改寫。
輸出：Remotion 渲染，三段中文畫面文字卡，淡入淡出。 如果要做動態文字宣傳片，就要反過來鎖死：不要檢索、不要生成圖片、全部用程序化排版文字、渲染引擎用 HyperFrames/GSAP。這樣 Agent 才不會跑去找素材，或突然把簡單字卡做成一堆不必要的生成圖。
這也是我覺得 OpenMontage 適合搭配 Codex 這類 coding interface 的原因。它需要的是能讀專案、跑命令、改檔案、看錯誤、重新執行的環境，不只是單純聊天介面。
8GB 顯卡可以玩嗎？可以，但不要從本地影片生成開始
本地影片生成性價比偏低，Wan2.1-1.3B 這類模型可以勉強塞，但要開 CPU offload；輸出通常短、解析度不高，等待時間也不短。圖生影片若不小心切到更大的 14B 模型，8GB 顯卡直接爆掉也不奇怪。
所以如果你的硬體只有 8GB VRAM，我會建議先走三條比較務實的路：
用免費素材庫做真實素材蒙太奇。
用 Remotion / HyperFrames 做程序化動畫與動態文字。
把本地 TTS、字幕、剪輯、自動化流程先跑順。
等流程穩了，再評估要不要加付費 API 或升級硬體，如果你正在考慮 AI 工作站，RTX PRO 6000 Blackwell 顯卡選購 那篇可以搭配看，OpenMontage 這種工作流很吃「整體系統」，不只是顯卡型號而已。
適合願意把影片當工程專案的人
OpenMontage 現在比較適合三種人。
第一種是技術型創作者 ：你願意看 log、改 prompt、裝依賴、調管線，OpenMontage 會給你很大的控制權。第二種是想把內容流程自動化的人： 例如固定產出知識動畫、短片、宣傳片、字幕版本，這套管線可以慢慢沉澱成自己的模板。第三種是正在研究 AI Agent 的人： OpenMontage 很適合觀察 Agent 如何做工具選擇、階段驗證、失敗重試與輸出檢查。
但如果你期待的是「打一句話、三分鐘後給我商業級成片」，它目前不會是最好的選擇，它更像一個正在快速演化的開源片廠骨架，需要你願意進去調教。
資源與安全連結整理
OpenMontage 的價值在「可編排」，不是魔法
我會把 OpenMontage 看成 AI 影片製作的 agentic framework，而不是一個單純的 AI 影片生成器。它真正有價值的地方，是把影片製作拆成可選管線、可替換工具、可檢查輸出的流程。
它現在最適合的打法，是先從零 API Key 或低成本路線開始：本地 TTS、免費素材庫、Remotion、HyperFrames、FFmpeg，等流程跑通，再依照題目決定要不要加 Veo、Kling、FLUX、OpenAI TTS 或其他 provider。
一句話總結：OpenMontage 不是把創作變成不用思考，而是把創作變成可以被 Agent 執行、被人類審核、被工程流程反覆改進的系統。這條路如果走通，AI 影片工具會從「生成一段畫面」進化成「管理一個製作流程」。
FAQ
OpenMontage 是什麼？
OpenMontage 是一套開源的 agentic video production system，讓 AI coding assistant 透過管線方式處理研究、腳本、素材、剪輯、渲染與檢查，不只是單一影片生成模型。
OpenMontage 可以不用付費 API Key 嗎？
可以。它可以使用本地 TTS、免費素材庫、Remotion、HyperFrames、FFmpeg 等工具先跑出作品。不過零 API Key 不等於零成本，仍然有硬體、時間、下載與維護成本。
OpenMontage 適合用在哪些題目？
通用氛圍類題目適合走真實素材檢索，知識解釋適合走動畫解說，產品或頻道宣傳適合走動態文字。特定歷史事件、具名人物或稀有場景，不適合硬走免費素材檢索。
by Rain Chu 7 月 7, 2026 | Agent , AI , RAG , 簡報製作 , 語音合成
如果你常把 PDF、論文、產業報告或內部文件丟進 AI 工具整理，Google NotebookLM 確實很方便；但只要資料牽涉商業機密、未公開研究、客戶內容或公司內部知識庫，雲端上傳與模型選擇限制就會變成真正的門檻，Open Notebook 的定位，正是把 NotebookLM 類型的文件理解、問答、摘要與 Podcast 生成，搬到更可控、更可自訂的開源工作流裡。
圖:Open Notebook 私有 AI 研究工作流示意 Open Notebook 解決的是什麼問題？
傳統文件型 AI 助手最容易卡在兩件事：資料放在哪裡，以及模型能不能換。對個人研究來說，把公開文章交給雲端 AI 問答通常沒什麼壓力；但對企業團隊、顧問、研究員或寫作者來說，資料可能包含未公開策略、訪談紀錄、合約、財務數據或客戶文件。這時候，能否自架、能否控制資料歸屬、能否選用自己的模型，就不只是偏好，而是能不能導入的前提。
Open Notebook 的優勢在於，它不是只做一個聊天視窗，而是把「文件匯入、知識庫整理、跨文件問答、來源引用、Podcast 生成、模型配置」串成一套私有 AI 研究工作流。官方 GitHub 專案 lfnovo/open-notebook 目前採 MIT 授權，官方說明也把它定位為一個 privacy-focused alternative to Google NotebookLM，截至 2026-07-07，GitHub API 顯示約 35K stars，最新 release 為 v1.10.0。
核心亮點一：資料主權回到自己手上
Open Notebook 最吸引人的地方，是它把資料控制權從平台端拉回使用者端。你可以把文件、音訊、多媒體檔案、網頁等素材放進自己掌控的環境，再用 AI 做摘要、檢索與問答。對需要處理敏感研究、公司內部文件或客戶資料的人來說，這比「功能多一點」更重要。
這也讓 Open Notebook 很適合搭配文件前處理工具。例如需要先把 PDF、Word、PPT 轉成 AI 更容易讀的文字格式時，可以參考我之前寫過的 MarkItDown 教學 ，先把原始文件整理成更乾淨的資料，再交給知識庫系統分析。
核心亮點二：模型不再被單一供應商綁住
NotebookLM 的好處是省事，但限制也很明顯：使用者基本上跟著 Google 的模型與產品設計走。Open Notebook 則主打 18+ AI provider，官方 README 提到支援 OpenAI、Anthropic、Ollama、LM Studio 等供應商。這代表同一套知識庫可以依任務切換模型：便宜模型做初步整理，強模型做深入推理，本地模型處理敏感資料。
如果你的工作流已經開始用 Ollama 或本地模型，Open Notebook 的價值會更明顯。它可以成為文件層的操作介面，而模型層則交給你自己的 AI server，想走本地端路線的人，也可以延伸看 GraphRAG 使用本地端的 Ollama 或 Ollama 遠端連線教學 ，把模型部署與文件分析分開思考。
核心亮點三：Podcast 生成更像內容製作工具
Podcast 生成是 NotebookLM 很受歡迎的功能，但固定雙人對談也限制了內容形式。Open Notebook 的方向更偏向內容製作工具：可以做 1 到 4 位 speaker，並調整角色設定與對話形式。這讓它不只適合做「兩人解說」，也能做單人旁白、三人圓桌、多人辯論或不同角色的知識導覽。
對自媒體、研究型內容創作者或企業內訓來說，這點很實用。你可以先把一批文件整理成知識庫，再把其中的核心結論轉成 Podcast 腳本，甚至為不同聽眾設計不同敘事角色。它不是單純把文字念出來，而是把文件理解、腳本結構與音訊內容生產接在一起。
核心亮點四：Ask 模式更適合跨文件研究
Open Notebook 的 Ask 模式適合處理「不是問單一文件，而是要整合一批資料」的任務。例如你有 20 份產業報告，真正想問的不是某一頁寫了什麼，而是不同報告之間是否有共同趨勢、矛盾、缺口與可引用依據。這時候，單純的檢索式問答會不夠，需要能跨文件整理、比對與引用來源的研究流程。
這也是 RAG 類工具接下來會越來越重要的原因：文件不是只被「搜尋」，而是要被組織成可以反覆推理的知識庫。Open Notebook 提供的是比較完整的操作層；而像 GraphRAG、向量資料庫、本地模型與文件轉換工具，則是可以接在底下的技術層。把這些組起來，才會形成真正可重複的 AI 工作流 。
Open Notebook 和 NotebookLM 怎麼選？
比較面向 Open Notebook NotebookLM 資料控制 可自架，資料在自己掌控的環境 以 Google 雲端服務為主 模型選擇 可接多家 provider，也可接 Ollama / LM Studio 主要使用 Google 模型 Podcast 形式 可做 1-4 位 speaker 與自訂角色 以固定形式為主 部署方式 Docker、雲端或本地部署 直接使用雲端產品 適合對象 重視隱私、模型自由、工作流整合的人 重視上手速度、不想部署的人
簡單說，如果你要的是「馬上可以用」，NotebookLM 仍然很省事；如果你要的是「資料可控、模型可換、流程可自訂」，Open Notebook 會更有想像空間。它不是每個人都需要的工具，但對研究、顧問、內容團隊與企業知識庫來說，很值得放進評估清單。
導入前要先確認的限制
Open Notebook 的自由度比較高，但也代表它不是完全零門檻。最基本的前提是你要能接受 Docker 或自架環境；如果公司電腦不能裝 Docker，或 IT 政策不允許本機服務，導入就會比較麻煩
Docker 新手可以先看 如何使用 Docker 跟用 command line 一樣 ，先把容器概念補起來。
算力也要看你的模型選擇。如果只是用雲端 provider，主要成本會落在 API；如果想完全本地跑模型，就要準備足夠的 GPU、記憶體與模型部署能力。換句話說，Open Notebook 降低的是資料與模型綁定，不是把所有基礎設施成本變成零。
誰最適合用 Open Notebook？
研究員：需要整理大量論文、報告、訪談與來源引用。
內容創作者：需要把資料轉成腳本、長文、Podcast 或系列內容。
學生與知識工作者：需要把課堂筆記、PDF、網頁資料統一管理。
企業團隊：需要建立內部知識庫，又不希望敏感文件全部交給外部雲端。
Open Notebook 適合把 AI 研究流程變成私有工作台
Open Notebook 的價值，不只是「開源版 NotebookLM」這麼簡單。它真正有意思的地方，是把資料主權、模型自由、Podcast 生成、跨文件研究與自架部署放在同一個工作台裡。對只想偶爾整理公開資料的人來說，它可能稍微重了一點；但對需要長期累積知識庫、處理敏感文件、或把 AI 研究流程變成團隊基礎設施的人來說，它是一個值得測試的選項。
Open Notebook Github
FAQ
Open Notebook 是 NotebookLM 的替代品嗎？
它可以被視為 NotebookLM 的開源替代方案，但重點不只是功能相似，而是提供自架、模型選擇、資料控制與更多自訂能力。
Open Notebook 一定要很強的電腦才能用嗎？
不一定。如果使用雲端模型，主要需要 Docker 與 API 設定；如果要完全本地跑大型模型，才需要更強的 GPU、記憶體與部署能力。
Open Notebook 適合企業內部知識庫嗎？
適合放進評估清單，尤其是重視資料控制、模型彈性與自架部署的團隊。不過正式導入前，仍要評估權限管理、備份、資安政策與維運成本。
by Rain Chu 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 模型各司其職、發揮所長。在我們的架構中，主要由以下三位核心成員組成：
董事長（你，唯一的人類）： 負責定大方向、提供靈感、拍板決策、把控最終產品質量。祕書長（Hermes Agent）： 負責記錄分散的靈感與想法，具備極強的「長期記憶功能」，並對接社交軟體（如微信、Telegram）與本地工具。CEO 執行長（Claude Code）： 負責公司的統籌規劃、任務分配、邏輯思考與實際開發落地。代碼審查員（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
近期留言