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 | 7 月 7, 2026 | AI , 影片製作
AI 影片工具正在從「生成一段漂亮畫面」往「協助完成一套可控工作流」移動。OiiOii 主打的不是單純丟一句提示詞生成影片,而是協助創作者把故事拆成分鏡,再銜接 AI 動畫生成工具,讓短影音、廣告概念片或角色動態 demo 更快進入可測試階段。
圖:AI 動畫分鏡與多 Agent 工作流示意
OiiOii 真正吸引人的地方:先做分鏡,再做動畫
多數 AI 影片工具最大的痛點,不是「能不能生成」,而是「能不能穩定重複出接近導演想法的畫面」。一支看起來完整的動畫,通常需要角色設定、場景氣氛、鏡頭運動、景別切換、節奏、轉場與連續性。如果每一幕都靠手動提示詞硬拚,創作者很快就會被版本管理與反覆修稿拖住。這也是為什麼單看 AI 影片生成工具 的畫質還不夠,前期分鏡與流程設計會直接影響成片穩定度。
OiiOii 這類工具的價值,正在於把「動畫生成」前面那一段拆解工作流程化:先把概念拆成可執行的分鏡,再把每個鏡頭轉成更具體的生成指令。對短影片創作者來說,這可以降低起步門檻;對已經熟悉剪輯與分鏡的人來說,它則像是一個快速前期製作助手。
OiiOii 的核心功能亮點
OiiOii 的核心不是把一句提示詞變成一段漂亮畫面,而是把 AI 動畫創作中最難控的「分鏡」拉到流程中心。真正讓一支動畫短片成立的,通常不是單張畫面多精緻,而是鏡頭如何切換、情緒如何遞進、角色與場景如何在不同畫面之間保持連續。
在實際創作流程上,OiiOii 先讓創作者選擇視覺方向,再把故事概念拆成可操作的生成任務。它的風格庫涵蓋 AI 真人、上海美術電影、Kpop 女團 CG 風等方向,也包含真人、3D、2D 等不同類型。對創作者來說,這代表一開始就能先確定影像語氣,而不是等生成失敗後才回頭修正風格。
比較值得注意的是它的多 Agent 流程。OiiOii 把前期製作拆給不同角色處理,像是藝術總監、編劇、設計師等;流程會先確認片長與情緒關鍵字,再進到劇本轉寫、人物場景生成與分鏡設計。這讓它更像是一套「陪你完成前期製作」的協作系統,而不是只把提示詞丟給影片模型。若把它放到更大的 AI 工作流 脈絡來看,它處理的是創意落地前最容易失控的拆解階段。
分鏡編輯是另一個關鍵亮點。創作者可以用多圖參考模式先生成分鏡圖,再針對單一格子修改;例如角色朝向不對時,不必整張重做,而是選中那一格、輸入提示詞修正。更關鍵的是,分鏡提示詞可以細到秒,包含角色聲音、每一秒音效與情緒設計;這正是它和傳統「一次生成一段影片」工具的差別。
它比較適合誰?
想快速測試 AI 動畫概念,但還沒有成熟分鏡能力的創作者。
需要把腳本拆成多個鏡頭,再交給 Seedance、即夢或其他 AI 影片模型生成的人。
正在製作短影音、MV 概念片、產品廣告草案、角色展示片的人。
想把「一句提示詞」升級成「可反覆修改的工作流」的人。
但如果你的需求是完全精準的商業級動畫,或每一個鏡頭都要有高度可控的表演、構圖與轉場,這類工具目前更像是加速器,不是全自動替代品。
使用前要注意的成本與限制
這類工具最容易被行銷成「一鍵爆款」,但實際導入前更應該先評估成本、穩定性與售後支援。需要注意的問題包括:流程中仍可能遇到 bug,補償與客服體驗不一定成熟;費用也未必會比即夢等工具低,而且生成、修改、重跑每一步都可能產生成本。這代表它並不是免費魔法,而是一套需要評估投入產出的製作流程。
另一個關鍵提醒是:即使工具能把流程模組化,最後仍然需要創作者自己把提示詞、鏡頭語言與修改方向寫清楚。分鏡工具可以幫你建立骨架,但骨架能不能長出好看的影片,仍取決於題材設定、審美判斷與反覆調整。
和即夢、Seedance 這類工具的關係
OiiOii 更適合被理解成創作流程中的「前期規劃與工作流層」,而不是單一底層影片模型。你可以把它理解成:OiiOii 協助你想清楚鏡頭與分鏡,Seedance 或其他影片模型負責生成具體影像。
這種分工會越來越常見。AI 影片模型越強,越需要上層工具幫創作者管理腳本、鏡頭、角色一致性與生成參數。真正的競爭點不只是哪個模型畫面最漂亮,而是誰能讓創作者用更少試錯完成更穩定的作品。像 AI Agent 自動剪輯 這類工具,也是在把影片創作從單點生成推向可編排、可重複的流程。
使用前可以先問自己的 5 個問題
我需要的是靈感 demo,還是可交付的商業成片?
每個鏡頭反覆生成的費用,是否在可接受範圍內?
我是否有能力判斷分鏡、轉場與節奏好壞?
如果工具產生 bug 或結果不穩,是否有備用流程?
我是否已準備好角色設定、故事大綱與視覺參考?
如果這五題都答得出來,OiiOii 這類工具就值得測試;如果還答不出來,建議先用一個短腳本做小規模實驗,不要一開始就把完整專案押上去。
爆款不是按鈕,分鏡才是槓桿
OiiOii 值得注意的地方,不是它承諾「一鍵爆款」,而是它碰到 AI 影片創作真正的瓶頸:如何把創意拆成可執行、可修改、可重複的鏡頭流程。對創作者來說,這比單次生成一段炫技畫面更重要。
目前更務實的看法是:把 OiiOii 當成 AI 動畫前期製作助手,而不是全自動導演。它能幫你縮短分鏡與試片時間,但成本、bug、提示詞品質與剪輯判斷仍然需要人來掌控。真正能產出好作品的,不會只是會按生成鍵的人,而是能把故事、鏡頭與工具串成完整工作流的人。
FAQ
OiiOii 是 AI 影片模型嗎?
OiiOii 更像是協助 AI 動畫分鏡與工作流規劃的工具,不一定等同於底層影片生成模型。
OiiOii 適合新手嗎?
適合用來快速理解分鏡流程與測試短片概念,但新手仍需要學會提示詞、鏡頭語言與基本剪輯判斷。
使用 OiiOii 會不會很貴?
使用這類工具時,每一步生成、修改與重跑都可能產生成本,費用也未必會比即夢等工具低。建議先用短腳本測試,再決定是否投入完整專案。
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
by Rain Chu | 6 月 6, 2026 | AI , 圖型處理
2026 年最受矚目的 AI 繪圖模型之一,莫過於 Ideogram 團隊正式釋出的:
Ideogram 4
這是 Ideogram 首次公開模型權重(Open Weight),也是目前開源陣營中,在:
文字生成(Text Rendering)
海報設計
品牌廣告
排版控制
JSON 結構化提示詞
官方 資料顯示,Ideogram 4 採用 9.3B 參數的單流 Diffusion Transformer(DiT)架構,並支援原生 2K 圖像生成。
本篇將帶你使用 ComfyUI,在本機部署 Ideogram 4。
系統需求
官方模型共有兩個版本:
版本 量化 Ideogram 4 FP8 品質最佳 Ideogram 4 NF4 VRAM需求較低
目前 ComfyUI 官方整合版本主要使用:
其中 FP8 畫質最佳。
第一步:下載模型
ComfyUI 專用模型
官方:
Comfy-Org Ideogram-4
原始模型:
Ideogram 4 FP8 官方 模型
第二步:放置模型檔案
依照官方說明建立目錄。
ComfyUI
│
├─ models
│ ├─ diffusion_models
│ │ ├─ ideogram4_fp8_scaled.safetensors
│ │ └─ ideogram4_unconditional_fp8_scaled.safetensors
│ │
│ ├─ text_encoders
│ │ └─ qwen3vl_8b_fp8_scaled.safetensors
│ │
│ └─ vae
│ └─ flux2-vae.safetensors
第三步:了解每個模型用途
ideogram4_fp8_scaled
主模型
負責:
ideogram4_unconditional_fp8_scaled
CFG 引導模型
負責:
提升細節
強化 Prompt Follow
改善品質
官方建議兩個模型一起使用。若只載入主模型雖可運作,但畫質會下降。
qwen3vl_8b_fp8_scaled
文字編碼器
負責:
Prompt 理解
JSON 理解
空間推理
海報版面配置
flux2-vae
VAE 解碼器
負責將 Latent 轉換成圖片。
第四步:更新 ComfyUI
Ideogram 4 需要最新版本的 ComfyUI。
更新方式:
或:
官方於 Day-0 即已原生支援 Ideogram 4。
第五步:載入官方 Workflow
ComfyUI 官方已提供範例工作流。
建議直接從:
Comfy Blog
下載 Workflow 。
基礎工作流架構
Prompt
↓
Qwen3-VL Encoder
↓
Ideogram 4
↓
Sampler
↓
Flux VAE Decode
↓
Save Image
第六步:第一張圖片
測試 Prompt:
A futuristic cyberpunk city at night,
neon signs in Chinese,
cinematic lighting,
ultra detailed,
high contrast,
8k photography
生成尺寸:
推理模式:
第七步:體驗 JSON Prompt
Ideogram 4 最大特色就是:
Structured JSON Prompt
官方模型訓練時即使用 JSON Caption。
範例:海報設計
{
"scene_summary": "Professional technology conference poster",
"background": {
"description": "Modern convention center stage with blue ambient lighting, large LED screen, clean professional environment"
},
"style": {
"description": "Corporate marketing design, professional conference poster, clean typography, premium branding, modern layout"
},
"objects": [
{
"description": "Conference stage",
"bbox": [100, 150, 900, 850],
"colors": ["#0A2540", "#1E88E5", "#FFFFFF"]
}
],
"text_elements": [
{
"text": "AI SUMMIT 2026",
"bbox": [150, 120, 850, 260],
"style": "Large bold white sans-serif title"
},
{
"text": "Future of Artificial Intelligence",
"bbox": [180, 280, 820, 350],
"style": "Medium white subtitle"
},
{
"text": "Taipei International Conference Center",
"bbox": [180, 1050, 820, 1120],
"style": "Small white footer text"
}
]
}
Bounding Box 控制
可直接指定位置。
{
"text_elements":[
{
"text":"SALE 50%",
"bbox":[100,100,500,300]
}
]
}
座標範圍:
原點:
這是目前 FLUX 與 Stable Diffusion 所不具備的能力。
色彩盤控制
品牌設計超級好用。
{
"color_palette":[
"#FF6600",
"#FFFFFF",
"#000000"
]
}
官方支援:
與 FLUX 比較
FLUX 強項
Ideogram 4 強項
Logo
海報
Banner
電商素材
排版設計
中文文字生成
若你是:
Ideogram 4 很可能比 FLUX 更適合。
結論
Ideogram 4 不只是另一個 AI 繪圖模型。
它最大的創新在於:
把 Prompt 從自然語言升級為結構化設計規格。
透過:
Qwen3-VL
Diffusion Transformer
JSON Prompt
Bounding Box
Color Palette
使用者終於可以像操作 Figma 一樣控制 AI 生成內容。
對於需要:
海報設計
品牌素材
Banner 製作
AI Agent 自動產圖
的開發者來說,Ideogram 4 是目前最值得研究與部署的開源模型之一。
by Rain Chu | 5 月 25, 2026 | AI , claude , 模型
Claude Code 已經不只是「在終端機裡幫你寫程式的 AI」。根據 Anthropic 官方說明,Claude Code 是一個能理解整個程式碼庫、編輯檔案、執行命令,並協助開發者完成修 Bug、加功能、自動化開發任務的 agentic coding assistant。
而近期 AI 開發社群開始討論一個更進階的概念:Claude Code Workflow 。
它的核心不是「再寫一段更長的 Prompt」,而是把一整套開發流程變成可以重複執行、可以追蹤、可以驗證、可以復跑的工作流。換句話說,Workflow 讓 AI 編程從「模型臨場建議」進一步走向「工程化編排」。
這對開發者、技術主管、架構師與 AI Agent 使用者來說,是非常重要的一步。
什麼是 Claude Code Workflow?
Claude Code Workflow 可以理解成一種「把 AI Agent 工作流程寫成程式」的方式。
過去我們使用 Claude Code,通常是這樣:
請幫我分析這個 GitHub 專案,找出架構問題,並提出改善建議。
這種方式雖然方便,但有幾個問題:
第一,每次執行結果可能不完全一致。 第二,很難知道每個 Agent 到底做了哪些步驟。 第三,不容易重複使用在下一個專案。 第四,流程本身大多存在 Prompt 裡,而不是程式碼裡。 第五,無法像 CI/CD 或測試腳本一樣被版本控制、審查與維護。
Workflow 的價值就在這裡:它把流程變成代碼,而不是只靠 Prompt。
一個 Workflow 通常會包含三個核心部分:
export default { meta: { name: "workflow-name", description: "說明這個 workflow 要做什麼" }, async run() { const result = await agent("請執行某個任務"); return result; }}
概念上,一個 Workflow 至少會有:
meta:定義名稱與描述
agent():至少呼叫一個 Agent 執行任務
return:把結構化結果傳回主流程
這代表 Workflow 不只是「提示詞模板」,而是一個可以持久化、版本化、重複執行的 AI 編排腳本。
為什麼 Workflow 很重要?
Claude Code 官方文件目前已經提供許多常見工作流程,例如探索程式碼、修 Bug、重構、測試、處理 PR、撰寫文件、平行 Session、Plan Mode,以及把 Claude 接進腳本與 CI 批次處理。
但 Workflow 的想像更進一步:它不是只告訴 Claude「請照這些步驟做」,而是把這些步驟寫成可執行邏輯。
這會帶來幾個關鍵改變:
1. 可重複使用
同一個 PR Review Workflow,可以套用到不同 GitHub Repository。
同一個 Deep Research Workflow,可以套用到不同技術主題。
同一個架構評審 Workflow,可以套用到不同系統設計案。
2. 可追蹤
Workflow 可以明確知道:
哪個 Agent 負責分析安全性? 哪個 Agent 負責效能? 哪個 Agent 負責測試覆蓋率? 哪個 Agent 負責最終彙整?
這比單純 Prompt 更接近真正的軟體工程流程。
3. 可驗證
Workflow 可以設計成多階段驗證。
例如:
第一個 Agent 產生答案。 第二個 Agent 檢查是否有錯誤。 第三個 Agent 用反方角度挑戰結論。 最後由 Judge Agent 統整可信結果。
這種方式可以降低 AI 幻覺,特別適合程式碼審查、資安報告、技術研究與商業決策文件。
4. 可復跑
如果 Workflow 是 JS 腳本,它就能像程式碼一樣被 Git 管理。
你可以:
保存版本 比較差異 建立標準流程 在不同專案重跑 放進團隊內部工具鏈 整合 Codex CLI、Claude Code、CI/CD 或內部自動化平台
這代表 AI Agent 的使用方式,正在從「聊天」變成「工程系統」。
如何開啟 Claude Code Workflow 實驗功能?
以下指令來自社群實測內容,目前不屬於 Anthropic 官方正式文件中明確宣告的穩定功能。因此建議把它視為「實驗性功能」,不要直接用在正式 Production 流程。
macOS / Linux
export CLAUDE_CODE_WORKFLOWS=1
接著啟動 Claude Code CLI:
Windows
SET CLAUDE_CODE_WORKFLOWS=1
接著啟動:
啟動多 Agent Workflow 的範例 Prompt
ultrawork 請為 GitHub 專案 XXX 啟動 multi agent workflow,分析程式碼品質、安全性、架構、測試覆蓋率與可維護性,最後輸出一份結構化 Review 報告。
查看 Workflow
產生或管理 Subagents
Workflow、Subagents、Skills、Agent Teams 有什麼不同?
這是最容易混淆的地方。
Claude Code 官方文件已經明確說明 Subagents、Skills、Agent Teams 的用途。Subagents 是專門處理特定任務的 AI 助手,每個 subagent 有自己的 context window、自訂系統提示、工具權限與獨立權限,適合把支線任務從主對話中分離出去。
Skills 則是透過 SKILL.md 擴充 Claude 的能力,適合把常用指令、檢查清單、多步驟程序變成可重複呼叫的技能。官方文件也提到 Skills 可以在需要時被載入,避免長篇指令一直佔用主要上下文。
Agent Teams 則是多個 Claude Code Session 的協作模式,由一個 lead session 協調工作,其他 teammate 各自在獨立 context window 中工作,並且可以彼此溝通。官方文件也明確指出,Agent Teams 與 Subagents 的差異在於:Subagents 主要回報給主 Agent,而 Agent Teams 的成員可以彼此直接溝通。
下面用簡單方式比較:
類型 核心概念 適合用途 本質 Prompt 臨時指令 單次任務、快速問答 自然語言 Skills 可重複使用的能力包 常用檢查清單、格式化、特定任務 SOP SKILL.md 指令與資源Subagents 專門任務助手 安全審查、測試分析、文件整理 獨立上下文的 AI 助手 Agent Teams 多個 Claude Code Session 協作 大型專案、多模組開發、跨層協作 多 Session 團隊 Workflow 用程式碼編排 Agent 流程 PR Review、研究、驗證、評審、循環改進 腳本化流程
最重要的差異是:
Skills 是讓 Claude 學會一種能力;Subagents 是讓 Claude 派出專門助手;Workflow 則是把整個流程寫成代碼。
Workflow 與 Subagents 的差異
Subagents 比較像「專業分工」。
例如:
一個 security-reviewer subagent 專門看資安問題。 一個 test-writer subagent 專門補測試。 一個 docs-writer subagent 專門寫文件。
但 Workflow 是「流程編排」。
它可以決定:
先讓 Agent A 分析架構。 同時讓 Agent B 分析安全性。 等 A、B、C 都完成後,由 Agent D 彙整。 再讓 Agent E 反向驗證。 最後輸出 JSON 結果。
所以可以這樣理解:
Subagents 是工作者,Workflow 是工頭加流程圖。
Workflow 與 Skills 的差異
Skills 比較像「可重複使用的操作說明」。
例如:
/code-review/debug/loop/verify
Claude Code 官方文件也提到,Skills 可以透過 SKILL.md 建立,並在相關情境自動載入或手動呼叫。
但 Workflow 更像「可執行的流程腳本」。
Skills 通常重點在「教 Claude 怎麼做」。 Workflow 則重點在「用程式控制 Claude 何時做、誰來做、如何彙整、如何驗證、如何回傳結果」。
所以差異可以簡化成:
Skills 是能力;Workflow 是編排。 Skills 偏向 Prompt 與知識包;Workflow 偏向 JS 腳本與結構化輸出。 Skills 告訴 Claude 怎麼做;Workflow 規定整個流程怎麼跑。
Claude Code Workflow 支援的 6 種常見型態
以下是目前最值得關注的 6 種 Workflow 型態。
Claude Code Workflow 6 types
1. Pipeline 流水線
Pipeline 是最基本的工作流型態。
它的概念是把任務拆成多個階段,前一階段的輸出會成為下一階段的輸入。
例如:
讀取需求 → 分析程式碼 → 修改程式 → 產生測試 → 執行測試 → 輸出報告
適合用在:
新功能開發 Bug 修復 重構流程 文件產生 部署前檢查
範例:
請建立一個 pipeline workflow:1. 分析目前 Repository 架構2. 找出最可能影響效能的模組3. 產生優化建議4. 修改程式碼5. 補上測試6. 回傳修改摘要
2. Parallel + Barrier 同步聚合
這種模式會同時啟動多個 Agent,等所有 Agent 都完成後,再進入下一階段。
它很適合用在需要多角度分析的任務。
例如 PR Review:
Agent A:檢查安全性Agent B:檢查效能Agent C:檢查可讀性Agent D:檢查測試覆蓋率Agent E:檢查架構風險Barrier:等待所有結果完成Aggregator:去重複、交叉驗證、輸出總結
適合用在:
PR 深度 Review 大型重構前評估 資安檢查 技術選型比較 競品研究
這種模式的重點是「同步聚合」。它不是誰先完成就直接輸出,而是等所有結果回來後再統整。
3. Adversarial Verify 對抗驗證
Adversarial Verify 是用來降低 AI 幻覺的重要模式。
做法是讓一個 Agent 產生答案,另一個 Agent 扮演反方、審查者或攻擊者,專門找錯。
例如:
Agent A:提出架構改善建議Agent B:找出 Agent A 的錯誤、過度假設與風險Agent C:根據 A 與 B 的結果,輸出可信版本
適合用在:
程式碼審查 資安報告 法務文件初稿 技術研究 投資或商業分析 政府標案文件
這種模式的價值在於:不要只相信第一個 AI 回答,而是讓另一個 AI 專門挑戰它。
4. Judge Panel 評審制度
Judge Panel 很適合用在「沒有唯一正確答案」的任務。
例如:
產品命名 品牌文案 UI 設計 技術架構 資料庫 Schema API 命名 Landing Page 文案
你可以設計多個評審:
Judge A:從工程可維護性評分Judge B:從使用者體驗評分Judge C:從 SEO 角度評分Judge D:從商業轉換率評分Judge E:從品牌一致性評分
最後由總評審輸出:
最佳方案 各方案優缺點 分數 風險 建議採用版本
這比單一 Agent 給建議更穩定,也更適合團隊決策。
5. Loop until X 累積式收斂
Loop until X 的概念是:不斷循環改善,直到達到某個條件。
例如:
產生方案 → 評分 → 修改 → 再評分 → 達到 90 分或預算用完 → 輸出
適合用在:
文案優化 測試覆蓋率提升 程式效能調校 SEO 文章改寫 Prompt 優化 UI 設計迭代
這種模式的重點是「預算控制」。
例如你可以設定:
最多跑 5 輪 最多花 20 分鐘 分數達 90 分就停止 測試全部通過就停止 沒有新增有效改善就停止
這讓 AI 工作流不會無限制消耗 token 或時間。
6. Nested Workflow 分層正交
Nested Workflow 是最高階的用法。
它允許一個大 Workflow 裡面再呼叫小 Workflow。
例如:
主 Workflow:完整 SaaS 專案審查子 Workflow A:前端架構審查子 Workflow B:後端 API 審查子 Workflow C:資料庫審查子 Workflow D:資安審查子 Workflow E:DevOps 審查子 Workflow F:成本與可擴展性審查
這種方式非常適合大型專案。
因為大型任務如果全部塞進一個 Prompt,很容易失控。Nested Workflow 則可以把任務切成多個正交模組,每個模組有自己的輸入、輸出與驗證方式。
Claude Code Workflow 的常見使用場景
場景 1:GitHub PR 深度 Review
這是最典型的 Workflow 應用。
你可以讓 Workflow 自動:
分析 PR diff 檢查安全漏洞 檢查效能問題 檢查命名與可讀性 檢查測試是否足夠 檢查是否破壞既有架構 輸出 Review Comment
範例 Prompt:
ultrawork 請針對 GitHub PR XXX 啟動 multi agent workflow,分別從安全性、效能、可維護性、測試覆蓋率與架構一致性進行審查,最後輸出一份可以貼到 PR 的 Review 報告。
場景 2:Deep Research 技術調研
Workflow 非常適合做技術研究。
例如你要研究:
LangGraph vs CrewAI vs Claude Agent SDK GCP Cloud Run vs Kubernetes PostgreSQL vs MySQL Redis Queue vs Cloud Tasks Claude Code vs Codex CLI
Workflow 可以讓不同 Agent 分別研究:
官方文件 GitHub Repo 社群案例 限制與成本 導入風險 實作難度
最後再由彙整 Agent 輸出結論。
場景 3:Harness Engineering 技術調研
如果你正在做企業級 AI Agent 平台,Workflow 可以變成一種 Harness Engineering 工具。
它可以負責:
建立研究任務 拆分技術問題 派出多個 Agent 收集結果 交叉驗證 產生決策文件 輸出 JSON 或 Markdown 報告
這讓技術調研不只是「問 AI 一個問題」,而是變成一套可重複執行的工程流程。
場景 4:大型重構前的風險評估
在修改大型系統前,可以先跑一個重構評估 Workflow。
例如:
請建立一個 workflow,分析目前專案是否適合把 monolith 拆成 service,請從資料庫耦合、API 邊界、部署複雜度、測試風險與團隊維護成本評估。
Workflow 可以輸出:
可重構區塊 高風險檔案 依賴關係 測試缺口 建議順序 不建議改動區域
場景 5:SEO 文章自動產製與審查
Workflow 不只適合寫程式,也可以用在內容產製。
例如:
Agent A:產生 SEO 大綱Agent B:研究搜尋意圖Agent C:撰寫文章Agent D:檢查繁體中文語氣Agent E:產生 meta descriptionAgent F:評估是否符合 E-E-A-T
最後輸出:
WordPress 文章 SEO 標題 Meta Description 標籤 FAQ 內部連結建議
場景 6:AI 產品功能規格書產生
你可以把 Workflow 用在產品開發初期。
例如:
輸入一個產品想法,Workflow 自動產生:1. PRD2. User Stories3. API 規格4. Database Schema5. 前端頁面列表6. 測試案例7. 開發任務切分
這對 AI SaaS、內部系統、WordPress 外掛、企業工具都很實用。
場景 7:安全性與合規檢查
Workflow 可以設計成安全審查管線。
例如:
Agent A:檢查硬編碼密碼Agent B:檢查 SQL InjectionAgent C:檢查 XSSAgent D:檢查權限控管Agent E:檢查 Docker / CI/CD 設定Agent F:產生修補建議
適合用在:
上線前檢查 客戶交付前審查 政府標案資安文件 內部稽核 DevSecOps 流程
場景 8:創意應用:AI 製作人工作流
如果你正在做 AI 音樂、AI 內容或 AI 製作人系統,Workflow 也可以派上用場。
例如一首歌的產製流程可以變成:
Agent A:分析歌曲主題Agent B:產生歌詞方向Agent C:設計 Suno PromptAgent D:檢查曲風一致性Agent E:產生封面圖 PromptAgent F:產生社群貼文Judge Panel:從商業性、情緒、記憶點、品牌一致性評分
這種方式可以把創意流程產品化,不再只是單次生成。
Workflow 的核心價值:把 AI 協作變成工程資產
Claude Code Workflow 真正重要的地方,不是它多了一個指令,也不是它可以叫很多 Agent。
真正的重點是:
Workflow 讓 AI 協作流程本身變成可以保存、維護、優化與版本控制的工程資產。
這跟過去的 Prompt Engineering 很不一樣。
Prompt Engineering 重點是「如何問得更好」。 Workflow Engineering 重點是「如何把 AI 工作流程工程化」。
未來團隊很可能會出現這些檔案:
.github/workflows/ai-pr-review.js.claude/workflows/security-audit.js.claude/workflows/deep-research.js.claude/workflows/refactor-planner.js.claude/workflows/seo-content-pipeline.js
這些 Workflow 會像今天的 CI/CD、Lint、Test、Build Script 一樣,成為開發流程的一部分。
實務導入建議
如果你想開始使用 Claude Code Workflow,可以先從低風險場景開始。
建議順序如下:
第一階段:研究與報告
先用 Workflow 做:
技術調研 文件整理 架構比較 PR 摘要 SEO 文章初稿
這類任務即使輸出有誤,也比較容易人工修正。
第二階段:Review 與驗證
接著導入:
PR Review 資安檢查 測試覆蓋率分析 架構風險評估 文件一致性檢查
這時候建議搭配 Adversarial Verify,讓另一個 Agent 專門挑錯。
第三階段:半自動修改程式碼
最後再導入:
自動修 Bug 自動補測試 自動重構 自動產生 API 自動修改文件
但這個階段一定要搭配 Git、測試、人工 Review 與權限控管。
使用 Claude Code Workflow 要注意什麼?
1. 目前仍應視為實驗功能
你提供的 CLAUDE_CODE_WORKFLOWS=1、ultrawork、/workflows 等內容,目前我沒有在 Anthropic 官方穩定文件中確認到完整正式公告。
因此建議文章中不要把它寫成「官方正式發布」,而是描述為:
「影片與社群實測發現的實驗性功能」 「可能尚未正式開放或仍在測試」 「實際可用性可能依 Claude Code 版本而異」
2. 不要讓 Workflow 直接碰 Production
Workflow 可以很強,但也代表風險更高。
建議:
只在 Git branch 執行 先跑 dry-run 要求輸出 diff 要求測試通過 不要自動部署 敏感操作需要人工確認
3. 結構化輸出很重要
Workflow 最好不要只輸出一段文章。
建議輸出:
{ "summary": "", "findings": [], "risks": [], "recommendations": [], "files_changed": [], "tests": [], "confidence": 0.87}
這樣才能被其他工具、CI/CD、Dashboard 或自動化系統接續使用。
4. 成本與 Token 要控管
多 Agent 工作流很容易消耗大量 Token。
尤其是:
Parallel + Barrier Judge Panel Loop until X Nested Workflow
這些模式都可能比單一 Claude Code Session 更昂貴。
所以一定要設定:
最大輪數 最大 Agent 數量 最大輸出長度 停止條件 預算限制
Claude Code 下載與官方資源
Claude 官方下載頁目前提供 macOS、Windows、Windows ARM64、iOS、Android,以及 Claude Code 的 Terminal、VS Code、JetBrains、Slack 等環境入口。官方頁面也顯示 Linux 桌面版目前不可用,但 Claude Code Terminal 可透過官方入口安裝。
Claude Code 官方文件也提供 Common workflows、Skills、Subagents、Agent Teams 等開發者文件,可作為學習 Claude Code 工作模式的基礎。
Workflow 是 Claude Code 繼 MCP、Skills、Subagents 之後的重要演進
Claude Code Workflow 的概念,代表 AI 編程正在進入下一個階段。
第一階段是聊天式 AI:你問,它答。 第二階段是 Agentic Coding:AI 可以讀檔、改檔、跑命令。 第三階段是 Skills 與 Subagents:AI 可以載入能力,並派出專門助手。 第四階段就是 Workflow:AI 工作流程本身可以被程式化、版本化、驗證與重複執行。
如果說 Prompt 是個人技巧,Workflow 就是團隊工程資產。
未來 GitHub 上很可能會出現大量開源 Claude Code Workflow,例如:
PR Review Workflow Security Audit Workflow Deep Research Workflow Refactor Workflow SEO Content Workflow DevOps Check Workflow AI Product Planning Workflow
對開發者來說,這不只是多一個 Claude Code 小技巧,而是 AI Agent 工程化的重要方向。
Claude Code Workflow 的關鍵價值可以濃縮成一句話:
把 AI 編程從「一次性的對話」升級成「可重複、可追蹤、可驗證、可復跑的工程流程」。
這也是 AI 編程真正走向團隊化、標準化與產品化的開始。
近期留言