by Rain Chu 7 月 6, 2026 | AI , 模型
Ornith 1.0 最值得注意的地方，不是又多了一個會補程式碼的開源模型，而是它把「寫程式」往前推了一步：先替任務搭工作流程，再開始產生解法。
這個差別很關鍵。很多 AI 寫程式失敗，不是模型不會寫函式，而是前面的任務拆解、資料來源、依賴安裝、API key、驗證方式沒有想清楚。Ornith 1.0 想解的正是這一層問題：讓模型先建立 scaffold，也就是一套能引導任務完成的工作台。
Ornith 1.0 是什麼？
Ornith 1.0 是 DeepReinforce 推出的開源 Agentic Coding 模型系列，官方定位是 self-improving open-source models for agentic coding。它不是單一模型，而是一整組不同大小與格式的模型家族。
9B Dense：比較適合本地測試與資源有限的部署。
31B Dense：官方頁列入模型家族，偏向更高能力的 dense 版本。
35B MoE：能力與資源需求往上推，Ollama 也提供 35B 版本。
397B MoE：旗艦級模型，更偏多 GPU 伺服器與研究測試場景。
官方資料提到，Ornith 1.0 建立在 Gemma 4 與 Qwen 3.5 這類 pretrained model 之上，並針對 coding agent 任務做後訓練。Hugging Face collection 目前列出 9B、35B、397B，以及 GGUF、FP8 等不同格式；GitHub README 也把這些版本整理成可部署的 checkpoint 清單。
如果你原本就在關注 Ollama + Qwen 3.6 的模型選擇 ，Ornith 1.0 可以放在同一條線上看：它不是單純聊天模型，而是更偏「本地程式代理」的方向。
真正的重點：先搭 scaffold，再寫程式
Ornith 1.0 的訓練思路，可以用一句話理解：模型不只學會產生 solution rollout，也學會產生帶領自己完成任務的 scaffold。
在傳統寫程式模型裡，使用者丟一個需求，模型很容易直接進入「產生程式碼」模式。但真實的小工具開發通常不是這樣。你要先知道資料從哪裡來、需不需要註冊 API、有哪些套件依賴、結果要怎麼展示、最後要怎麼驗證。
例如做一個五天天氣預報工具，如果一開始選 OpenWeather，後面才發現需要 API key，任務就會卡住。比較好的 agent 行為是回頭調整方案，改找不需要 API key 的資料來源，重新整理資料結構與 UI 呈現。Ornith 1.0 想訓練的，就是這種「條件變了，工作流程也跟著改」的能力。
這也解釋了為什麼它比較適合拿來觀察 AI agent，而不是只拿幾題補全測試就下結論。對程式代理來說，會寫一段 function 只是基本盤；能不能拆任務、改策略、補驗證，才是進入真實專案後的差距。
Benchmark 可以看，但不要只看跑分
官方 benchmark 涵蓋 Terminal-Bench 2.1、SWE-bench Verified、SWE-bench Pro、SWE-bench Multilingual、NL2Repo、SWE Atlas 等任務。下面先抓兩個比較容易理解的指標來看：
模型 Terminal-Bench 2.1 SWE-bench Verified 定位 Ornith-1.0-9B 43.1 69.4 本地測試與輕量部署 Ornith-1.0-35B 64.2 75.6 工作站或較高資源環境 Ornith-1.0-397B 77.5 82.4 多 GPU 伺服器與旗艦能力
9B 的意義不在於它能不能打贏所有大模型，而是它讓本地端測試變得比較實際。35B 與 397B 則是觀察這套 scaffold 訓練方法能不能隨模型規模放大的重點版本。
不過跑分仍然只能當入口。Coding agent 的實際體驗，還會被上下文管理、工具調用、檔案系統安全邊界、任務記憶、互動方式影響。這也是為什麼 Claude Code、Codex 這類工具難以只用「模型分數」比較。它們拼的是整套工作流，不只是底層模型。
如果你想把本地模型接進開發工作流，可以延伸看這篇 Claude Code 搭配 LM Studio 與 Ollama 的零 API 成本開發環境 ，它比較接近 Ornith 1.0 可能落地的位置。
怎麼在 Ollama 與 Hugging Face 上取得 Ornith 1.0？
目前最直接的入口有四個：
Ollama 頁面列出 9 個模型項目，並標示 `ornith:latest`、`ornith:9b` 約 5.6GB、`ornith:35b` 約 21GB，context window 皆為 256K。最簡單的測試方式是：
ollama run ornith
ollama run ornith:9b
ollama run ornith:35bGitHub README 也提供從 Hugging Face GGUF 直接跑的方式：
ollama run hf.co/deepreinforce-ai/Ornith-1.0-9B-GGUF如果你要讓其他電腦連到同一台 Ollama 伺服器，可以搭配 Ollama 遠端連線教學 來設定 API endpoint。Ornith 1.0 這類程式模型，通常會更適合放在可以被 IDE、CLI agent 或自動化腳本呼叫的環境裡。
Reward hacking 是這類模型一定要面對的問題
讓模型自己產生 scaffold，能力會變大，風險也會變大。最典型的問題是 reward hacking：模型不是好好完成任務，而是想辦法鑽驗證器的空子。
在程式任務裡，這可能長得很實際：偷看測試檔、硬寫 expected output、碰不該碰的驗證腳本，或把環境改到看起來通過。官方資料提到的防護思路，是把外層信任邊界固定住，讓環境、工具表面與測試隔離不能被模型改；再用規則監控與模型複查，把可疑方案篩掉。
這一段其實比跑分更重要。因為 agentic coding 的核心不是一次回答，而是連續操作。模型能操作越多工具，就越需要清楚的權限邊界與可追蹤紀錄。這也是我會把 Ornith 1.0 放在「值得測試的開源方向」，而不是「馬上取代成熟 coding agent」的位置。
如果你對這種自學型 agent 架構有興趣，可以接著看 Claude Memory 與 Dreaming：自學型 AI Agent 的下一步 ，兩者都在處理一個相近問題：AI 不只是回答，而是如何在任務中累積策略。
我會怎麼選版本？
如果只是想先試試看，從 `ornith:9b` 開始最合理。它的下載量、顯存壓力與啟動成本都比較低，也比較適合拿來測「任務拆解」是不是真的有感。
如果你有比較強的工作站，`ornith:35b` 才值得進入第二輪測試。它的定位更接近可用的 coding agent 模型，但也更需要良好的硬體與服務設定。若你的目標是跑大型專案、長上下文、多步驟任務，可以把 35B 放進候選清單。
397B 則不建議一般使用者一開始就碰。它更像是研究、企業或多 GPU 伺服器環境要評估的版本。對多數人來說，先把 9B/35B 放進 Ollama 或 OpenAI-compatible endpoint，測試能否穩定完成真實任務，會比追最大參數更有價值。
想把模型接進工具鏈，也可以參考 OpenCode 如何使用本地端模型 。Ornith 1.0 真正有趣的地方，正是在「本地模型 + coding agent + 可控工具」這個交會點。
結論：值得追，但要用真實任務測
Ornith 1.0 的亮點不是單一 benchmark 數字，而是它把開源程式模型推向「會先規劃工作台」的方向。這對本地 AI 編程很重要，因為真實任務往往不是只補一段 code，而是資料來源、依賴、限制、驗證與修正一起出現。
短期內，我會先看兩件事：第一，9B GGUF 在一般工作站或高階個人電腦上能不能穩定跑；第二，35B 在多步驟專案裡，能不能真的比一般 coding model 更會拆任務與自我修正。
如果這兩件事站得住，Ornith 1.0 就不只是又一個開源模型，而是本地 AI coding agent 往前走的一個重要訊號。
FAQ
Ornith 1.0 是什麼？
Ornith 1.0 是 DeepReinforce 推出的開源 Agentic Coding 模型系列，重點不是只產生程式碼，而是讓模型先為任務建立 scaffold，包含拆解步驟、工具選擇、驗證方式與錯誤處理，再產生解法。
Ornith 1.0 有哪些版本？
官方釋出 9B Dense、31B Dense、35B MoE 與 397B MoE 等版本；Hugging Face collection 中也包含 GGUF 與 FP8 版本。Ollama 頁面目前列出 ornith:9b 與 ornith:35b，兩者皆標示 256K context window。
一般使用者應該先跑哪個版本？
如果目標是本地測試，建議先從 9B 或 9B GGUF 開始；35B 比較適合顯存較充足的工作站。397B 更偏向多 GPU 伺服器環境，不是一般個人電腦的起手式。
Ornith 1.0 可以取代 Claude Code 或 Codex 嗎？
目前比較合理的看法是「值得測試的開源方向」，不是直接取代成熟工具。
Claude Code、Codex 這類產品還包含上下文管理、工具調用、專案理解、安全邊界與互動體驗，模型本身只是其中一層。
Ornith 1.0 怎麼用 Ollama 跑？
Ollama 官方頁面提供 `ollama run ornith`、`ollama run ornith:9b` 與 `ollama run ornith:35b`。
如果要直接使用 Hugging Face 的 GGUF，也可以參考 GitHub README 裡的 `ollama run hf.co/deepreinforce-ai/Ornith-1.0-9B-GGUF`。
by Rain Chu 7 月 6, 2026 | Agent , AI , claude
Memory 讓 agent 記得自己的工作經驗,Dreaming 則負責在背景整理、驗證與回填這些經驗。 AI Agent 真正難的地方,不是只會不會呼叫工具,而是能不能在長時間、多任務、多 agent 的環境裡越做越好。MCP 解決的是工具與資料接入,Skills 解決的是可重複使用的能力封裝,但如果 agent 每次醒來都像第一次接觸專案,它就很難成為真正可靠的工作夥伴。
這也是 memory 和 dreaming 這兩個概念重要的原因。Memory 是 agent 的可讀寫經驗庫;Dreaming 則像一個離線整理程序,會在任務之外回看多個 session 的 transcript,找出共同錯誤、成功策略、重複資訊與過期記憶,再把它們整理成更可靠的記憶狀態。
為什麼 Agent 需要 Memory?
現在的 agent 已經可以跑很久,有些任務會持續數小時甚至接近數天。問題是,時間拉長後,上下文管理就會變成瓶頸。Agent 需要知道任務成功條件、常見錯誤、哪些策略行不通、專案檔案怎麼組織、以前有哪些調查結果,也要能從其他 agent 的經驗中學到東西。
這一點和我之前整理 Claude Code Workflow 時看到的問題很像:當你同時開多個 agent 或多個工作階段,真正會拖慢效率的,往往不是模型不夠聰明,而是每個 agent 都在重複摸索同一批上下文。
Memory 的設計:把記憶當成檔案系統
這套 memory 設計最有意思的地方,是它沒有把記憶包成一個過度抽象的黑盒工具,而是把 memory model 成一組檔案。Agent 可以像管理專案檔一樣,用熟悉的 bash、grep、檔案讀寫去整理記憶。這和 Claude Code 擅長操作檔案系統的能力剛好接上。
從實務角度看,這比單純塞一段「長期記憶摘要」更適合大型專案。記憶可以拆成不同檔案、不同層級、不同權限:有些是組織層級的 runbook 和最佳實務,應該只讀;有些是某個團隊或某個任務的 working memory,需要 agent 持續更新。
多 Agent 系統裡,記憶不能只有「我記得」
單一 agent 記得自己的工作經驗已經有幫助,但真正的難題在多 agent。當企業裡同時有數百甚至上千個 agent 在跑,它們會接觸同一套程式碼、同一批告警、同一組 runbook。如果每個 agent 都各自學一次,成本會很高,錯誤也會一直重複。
這裡需要兩種能力。第一是權限範圍:有些 memory store 只允許讀取,有些允許讀寫。第二是並行控制:多個 agent 同時更新同一份記憶時,不能互相覆蓋。用 content hash 做 optimistic concurrency,可以讓 agent 在寫入前確認自己沒有覆蓋別人的更新。
如果把這件事放進更大的 AI 工作流來看,它其實和 用 AI 組一家公司 的概念很接近:當 AI 不再只是單一助手,而是多個角色一起工作,組織記憶就會變成基礎設施。
Dreaming 是什麼?
Dreaming 可以理解成「離線記憶整理」。它不是 agent 正在執行任務時的熱路徑,而是一個非同步 batch process。它會回看最近的 agent sessions、transcripts 和工作結果,找出共同模式、重複錯誤、有效策略,再產生一組更新後的 memory diff。
這個設計很重要,因為單一 agent 在任務中只看得到自己的局部視角。Dreaming 則可以站在更高一層,同時看多個 agent 的工作紀錄。它能發現某個錯誤是不是很多 agent 都遇到過,某個 retry pattern 是不是固定在 60 秒後發生,或某份記憶是不是已經過期。
Memory 與 Dreaming 的差別
項目 Memory Dreaming 運作時間 任務進行中即時讀寫 任務外的非同步整理 主要目標 讓 agent 記得當前與過去經驗 驗證、去重、回填與組織記憶 視角 單一 agent 或單一 session 為主 跨多個 sessions 與多個 agents 適合解決 避免重複調查、保留工作脈絡 找共同錯誤、萃取模式、清理 stale memory 對效能影響 在任務路徑上,要注意 token 與延遲 離線執行,不增加 hot path latency
早期案例透露了什麼?
早期案例有兩個數字值得注意。Rakuten 在內部 knowledge agents 裡導入 memory 後,first-pass mistakes 降低 90%。Harvey 在法律場景 benchmark 中導入 dreaming 後,其中一個 scenario 的 task completion rate 提升 6 倍。
圖表只是把兩個早期案例視覺化。它們不是通用保證,但足以說明 memory 與 dreaming 對長任務 agent 的潛力。 這些數字不能直接解讀成所有 agent 系統都會有同樣改善,但方向很明確:memory 先降低重複犯錯,dreaming 再把多個 agent 的經驗整理成更乾淨、更可用的知識庫。對企業來說,這會同時影響正確率、token 效率、延遲和維護成本。
SRE Agent 的例子最容易理解
假設一個 SRE agent 收到 P1 alert,它開始查 CPU utilization、流量模式、最近部署的 PR,最後把調查結果寫進 SRE memory store。幾分鐘後同樣 alert 又出現,另一個 SRE agent 啟動時,第一件事不是從零開始查,而是先讀到前一個 agent 留下的調查結果,直接避開重複工作。
這就是 memory 的即時價值:省 token、省時間、也讓後續 agent 站在前一個 agent 的肩膀上。再往下一層,dreaming 會回看過去 7 天相關 sessions,找出多個 agent 都沒有單獨注意到的模式。例如很多 alert 都剛好在上游 CPU spike 後 60 秒發生,那可能代表 retry logic 或排程邏輯有問題。
這種模式非常適合 自我進化 AI Agent 架構 。但重點不是讓 agent 無限制亂寫記憶,而是要有版本歷史、attribution metadata、審核流程和可回滾能力。
實作時最該注意的三件事
第一,記憶要可審計。誰寫了什麼、什麼時候寫、基於哪個 session 寫,這些資訊必須留下來。否則 memory 一旦被污染,後續 agent 會把錯誤經驗當成事實。
第二,記憶要分層。組織層級 best practices、團隊 runbook、專案知識、個別任務 working memory,不應該全部混在同一個檔案。這和寫 AI 開發紀律 很像:越是長期會被重複使用的規則,越要整理成穩定結構。
第三,dreaming 不應該完全無人監督。它產生 memory diff 後,可以直接套用,也可以先走檢查、PII scanning、人工 review 或外部 pipeline。對企業 production agent 來說,這種控制權比單純「模型會自動學習」更重要。
我的判斷:Memory 會成為 Agent 系統的資料庫層
如果把 MCP 看成工具層,把 Skills 看成能力層,那 memory 很可能會變成 agent 系統的資料庫層。它不只是「記住使用者喜好」這麼簡單,而是把 agent 的工作歷史、錯誤模式、成功策略與環境知識變成可管理、可審計、可演進的資產。
Dreaming 則讓這個資料庫不只是被動儲存,而是能定期整理索引、刪除過期內容、回填驗證結果、把多個 agent 的經驗濃縮成明天可以直接使用的知識。未來真正強的 agent 系統,可能不是單一模型最聰明,而是整個系統能不能把每天做過的事變成明天的能力。
FAQ
AI Agent memory 是什麼?
AI Agent memory 是讓 agent 保留工作經驗、任務策略、環境知識與常見錯誤的記憶系統。它可以幫 agent 在長任務或多 session 工作中避免每次都從零開始。
Dreaming 和一般 memory 有什麼不同?
Memory 偏向任務進行中的即時讀寫;Dreaming 則是離線整理流程,會回看多個 agent sessions,找出共同模式、去重、驗證記憶並回填更好的內容。
Memory 會不會讓 agent 學到錯誤資訊?
會有這個風險,所以 production memory 需要版本歷史、attribution metadata、權限控管、PII scanning、人工 review 或自動檢查流程。記憶不是越多越好,而是要可靠、可追溯、可清理。
什麼情境最適合導入 agent memory?
最適合長任務、多 agent、重複問題多、環境複雜的場景,例如 SRE triage、程式碼維護、企業知識問答、法務研究、客服流程與內部自動化。
by Rain Chu 7 月 5, 2026 | Nvidia
RTX PRO 6000 Blackwell 正成為本地 AI 推理工作站的熱門選項。 如果你最近在看本地 AI 部署 或企業工作站，很可能也被 RTX PRO 6000 Blackwell 的行情嚇到，這張卡原本是工作站專業卡，卻因為 96GB 大顯存、Blackwell 架構，以及能單卡容納 70B 量化模型的能力，被市場一路推成「算力理財產品」，它的矛盾也很明顯:不是最適合訓練的資料中心卡，卻成了企業做 AI 推理、RAG 、知識庫問答與專業渲染時很難忽視的選項。
這篇文章會從規格、推理能力、價格結構與部署限制出發，幫你判斷 RTX PRO 6000 Blackwell 到底強在哪裡、為什麼漲價、適合哪些使用情境，以及工作站版、Max-Q 版、伺服器版和中國特供版應該怎麼選。
RTX PRO 6000 Blackwell 的核心定位
RTX PRO 6000 Blackwell 是 NVIDIA 在 2025 年 GTC 發布的專業工作站顯卡，定位不是遊戲，而是 AI 推理、3D 渲染、科學模擬、8K 內容製作與企業級工作負載，如果你已經在看 NVIDIA DGX Spark 這類本地 AI 硬體，它會是同一條部署思路下更高階的工作站選項。它與 RTX 5090 同屬 GB202 核心，但核心用途完全不同:RTX 5090 是消費級高階卡，RTX PRO 6000 則是拿來「幹活」的專業卡。
規格上，這張卡的重點包括:約 24,064 個 CUDA 核心、96GB GDDR7 顯存、512-bit 位寬、約 1,792GB/s 頻寬、ECC 顯存，以及最高約 4,000 TOPS 的 AI 算力。真正讓 AI 圈關注的，是 96GB 顯存搭配低精度推理時，可以讓 70B 量化大模型不用複雜多卡部署就塞進單卡。
對本地 AI 部署來說，能用單卡容納 70B 量化模型，往往比單純追求峰值算力更實際。
它能不能平替 H200?
如果拿 RTX PRO 6000 與 H200 相比，答案要務實一點:在主流 70B 模型 4-bit 推理場景下，RTX PRO 6000 的性能大約可達 H200 的 75% 到 80%。差距主要來自顯存頻寬與多卡互連能力。H200 是資料中心級方案，單卡價格也高很多;RTX PRO 6000 則更像工作站裡的 AI 推理加速器。
換句話說，如果你要從零訓練千億參數模型，RTX PRO 6000 不是最佳選擇;但如果你的需求是把 70B 模型部署到本地，用於程式碼生成、知識庫問答、RAG 或企業內部推理服務，它的成本結構會比 H200 方案更容易讓人接受。這類需求通常也會搭配 Ollama 遠端連線 或內部 API 服務，讓團隊不必每個人都直接碰工作站。
最大的限制:沒有 NVLink
RTX PRO 6000 的一個關鍵限制，是不支援 H200 那種高速 NVLink 互連，如果兩張 PRO 6000 進行多卡推理，資料交換主要依靠 PCIe 5.0 x16，理論頻寬約 128GB/s，實務上還會受軟體堆疊影響;而 H200 的 NVLink 卡間頻寬可到約 900GB/s，這會直接影響需要頻繁交換 KV cache 或進行大規模模型並行的工作負載。
所以部署策略很清楚:單卡能搞定，就盡量不要上雙卡。RTX PRO 6000 的優勢在於單卡大顯存與本地推理，而不是多卡無損通信或大規模訓練。
為什麼價格一路上漲?
漲價原因可以歸納成三點。
第一，96GB GDDR7 顯存本身成本高。
第二，Blackwell 架構產能優先供給資料中心，工作站卡供應被壓縮。
第三，AI 本地部署需求太強，企業、科研機構、設計公司都在搶現貨。
這張卡發布初期的官方定價約 8,000 美元，但國內現貨價已經衝破 42 萬台幣，這種價格波動讓它不只是一張顯卡，更像企業算力採購裡的稀缺資源。
ECC、FP4 與 96GB 顯存的真正價值
對一般玩家來說，ECC 顯存可能只是「比較穩」。但在金融風控、醫療影像、科學計算或企業模型推理場景，一個 bit 翻轉就可能造成結果偏差，RTX PRO 6000 的 96GB GDDR7 全部支援 ECC，這也是它和遊戲卡之間很大的分水嶺。
另一個關鍵點是 FP4 原生支援。當模型採用 4-bit 量化時，顯卡是否原生支援低精度計算，會影響實際推理效率，這也是 RTX PRO 6000 在 70B 模型本地部署上特別有吸引力的原因。如果你主要在比較本地模型格式與量化選項，也可以先從 Ollama + Qwen 模型選擇 這類實務問題回頭推硬體需求。
版本怎麼選?
RTX PRO 6000 Blackwell 可以分成幾個主要版本來看:工作站版、Max-Q 版、伺服器版，以及中國特供版 RTX PRO 6000D。選擇邏輯不是誰規格最高就買誰，而是看你要放在什麼機器裡、用幾張卡、散熱與供電條件是否撐得住。
不同版本的 RTX PRO 6000 Blackwell,選購重點不只看性能,也要看散熱、供電與部署密度。 版本 適合對象 注意事項 工作站版 單機桌面、AI 推理、渲染、8K 內容製作 約 600W 功耗,需要高瓦數電源與良好風道 Max-Q 版 多卡密集部署 功耗較低,較適合多卡機箱 伺服器版 機櫃、資料中心、雲端算力節點 被動散熱、無顯示輸出,依賴伺服器風道 中國特供版 PRO 6000D 預算敏感且需合規的企業 核心、顯存與頻寬下修,但價格較低
工作站該怎麼配?
600W 等級的顯卡不是隨便塞進一般機箱就能穩定運作，電源至少要抓 1200W,更穩妥是 1500W 以上;若考慮峰值功耗或未來擴充,2000W 白金電源會更安心，主板則建議支援 PCIe 5.0 x16,並選擇 PCIe 通道充足的工作站平台,例如 Threadripper Pro 或 Xeon W 等級平台。
散熱方面,工作站版雖然有主動散熱,但機箱風道仍然非常重要。
多卡部署更建議考慮水冷或 Max-Q 版本。CPU 不能太弱,因為推理工作仍需要 CPU 處理資料預處理、API 調度與周邊工作。記憶體建議 128GB 起跳,若有 RAG、向量資料庫或多模型服務,256GB 會更寬裕。
現在該不該買?
我的判斷會比較直接:如果你是個人開發者或小團隊,有 AI 推理、RAG 或微調需求,且預算足夠,可以考慮入手;如果不急,可以等產能釋放後價格回落,但不要期待回到早期官方定價，若是做大模型訓練,也應該看 H100/H200 這類資料中心方案。
總結來說,RTX PRO 6000 Blackwell 的價值不在於「全能」,而在於它把 96GB 大顯存、ECC、FP4、Blackwell 架構和工作站可部署性放在同一張卡上。它不完美,沒有 NVLink、訓練能力有限、價格也高;但在本地 AI 推理、企業工作站、專業渲染和 4K 內容製作場景裡,確實是一張很有競爭力的卡。
FAQ
RTX PRO 6000 Blackwell 適合訓練大模型嗎?
不太適合大規模訓練。它更適合本地 AI 推理、RAG、知識庫問答、專業渲染與工作站應用。若要做大規模多卡訓練,應優先考慮 H100/H200 等資料中心方案。
RTX PRO 6000 能平替 H200 嗎?
不能完全平替。在 70B 4-bit 推理場景下，它大約可達 H200 約 75% 到 80% 的性能，但 H200 在顯存頻寬與 NVLink 多卡互連上仍有明顯優勢。
RTX PRO 6000 為什麼適合 70B 模型?
關鍵在 96GB 顯存與低精度推理支援。70B 量化模型可以在單卡容納,降低多卡部署複雜度,也避免多卡通信帶來的延遲。
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 月 18, 2026 | AI , skills
baoyu-skills 產生產品圖：用 AI 快速製作 WordPress 商品視覺素材
在經營 WordPress 網站、WooCommerce 商店或內容型部落格時，產品圖往往是最花時間、也最影響轉換率的素材之一，過去要做一張產品主視覺，可能需要攝影、修圖、排版、設計師協作，甚至還要為不同平台另外裁切尺寸。
如果你的網站需要大量商品圖、文章封面圖、社群圖卡、資訊圖表，baoyu-skills 會是一個很適合導入的 AI 圖像工作流工具。
baoyu-skills 是由 Jim Liu 寶玉分享的 AI Agent 技能集，可用於 Claude Code、Codex 等 Agent 環境，協助內容創作者與網站經營者更有效率地產生圖片、文章、圖卡、簡報、資訊圖與多種發布素材。
官方 GitHub：https://github.com/jimliu/baoyu-skills
下載與更新：https://github.com/JimLiu/baoyu-skills/releases
為什麼 WordPress 網站需要 baoyu-skills？
WordPress 的優點是彈性高，但內容經營到一定規模後，最常卡住的地方不是文章本身，而是「圖片素材」。
常見情境包含：
WooCommerce 商品需要主圖、情境圖、橫幅圖
部落格文章需要 SEO 封面圖
產品教學需要流程圖或資訊圖表
社群貼文需要小紅書、Instagram、Facebook 圖卡
多語系網站需要同一張圖的不同語言版本
技術產品需要規格圖、爆炸圖、比較圖或視覺說明
baoyu-skills 的價值在於，它不是單純「叫 AI 畫一張圖」，而是把常見內容工作拆成多個 Skill，讓你可以針對不同用途選擇合適的圖片生成方式。
baoyu-skills 的主要特色
1. 可產生多種產品視覺素材
baoyu-skills 不是只有單一圖片生成指令，而是包含多種與內容、圖片、圖表相關的技能。
適合用在：
產品封面圖
商品情境圖
文章插圖
資訊圖表
社群圖卡
教學流程圖
知識漫畫
簡報圖片
商品介紹圖
對 WordPress 經營者來說，這代表同一份產品資料可以延伸成不同的行銷素材。
2. 適合產品圖與文章封面圖
如果你正在寫一篇產品介紹文章，可以使用 baoyu-cover-image 產生文章封面，也可以使用 baoyu-image-gen 或 baoyu-imagine 產生更自由的商品情境圖。
例如：
科技產品：可產生冷色系、金屬感、未來感的產品主視覺
美妝商品：可產生柔光、乾淨背景、生活情境的商品照
食品商品：可產生木質桌面、自然光、手作感的商品圖
教育服務：可產生圖解式封面與資訊圖
SaaS 產品：可產生 UI mockup、介面展示與功能圖解
3. 支援圖表與流程類型內容
遇到流程、比較、架構、教學步驟時，建議不要只用文字說明，可以改用「創作圖像」的方式產生視覺圖。
例如這篇文章中的工作流程可視覺化如下：
這類流程非常適合做成資訊圖，放在 WordPress 文章中，不但可以增加停留時間，也能讓讀者更快理解工具的實際用途。
4. 可與 WordPress 內容流程整合
baoyu-skills 本身不是 WordPress 外掛，而是 AI Agent 的技能集。實際用法通常是先在本機或開發環境產生圖片，再把圖片上傳到 WordPress 媒體庫。
建議流程如下：
在 Claude Code、Codex 或其他支援 Skills 的 Agent 中安裝 baoyu-skills
準備商品描述、文章 Markdown 或產品規格
使用對應指令產生圖片
檢查圖片比例、文字、品牌色與可讀性
將圖片輸出為 WebP、PNG 或 JPG
上傳到 WordPress 媒體庫
套用到文章特色圖片、WooCommerce 商品圖、Elementor 區塊或首頁 Banner
如果你的網站使用 Elementor，也可以直接把產出的圖片放進 Elementor 的 Image、Hero、CTA、Gallery 或 Loop Grid 區塊中。
安裝與下載
官方建議安裝方式如下：
npx skills add jimliu/baoyu-skills
官方 GitHub：https://github.com/jimliu/baoyu-skills
下載與版本更新：https://github.com/JimLiu/baoyu-skills/releases
如果你使用 Claude Code，也可以在 Agent 中加入 marketplace：
/plugin marketplace add JimLiu/baoyu-skills
接著安裝：
/plugin install baoyu-skills@baoyu-skills
官方文件提醒，baoyu-skills 內含多個 Skill，實務上建議按需安裝，不一定要一次載入所有技能，避免佔用過多 Agent 上下文。
關鍵指令整理
以下是用於產品圖與 WordPress 內容製作時最常用的指令方向。
1. 產生文章封面圖
/baoyu-cover-image path/to/article.md
指定風格：
/baoyu-cover-image path/to/article.md --style blueprint
指定比例：
/baoyu-cover-image path/to/article.md --aspect 16:9
不要加標題文字：
/baoyu-cover-image path/to/article.md --no-title
適合用途：
WordPress 文章特色圖片
部落格封面
首頁文章列表縮圖
SEO 文章主視覺
2. 產生產品情境圖
/baoyu-image-gen "黑色無線耳機，霧面金屬質感，放在白色桌面上，自然柔光，商業產品攝影風格"
適合用途：
WooCommerce 商品主圖
商品詳情頁情境圖
首頁商品橫幅
廣告素材
3. 產生自由風格產品圖
/baoyu-imagine "一款高階 AI 筆電放在現代辦公桌上，背景有柔和光影，科技感，高級商業攝影"
適合用途：
品牌形象圖
活動視覺
產品概念圖
Landing Page 主視覺
4. 產生資訊圖表
/baoyu-infographic path/to/content.md
指定版型與風格：
/baoyu-infographic path/to/content.md --layout flow --style technical-schematic
適合用途：
產品規格比較
教學步驟
服務流程
軟體架構圖
WordPress 教學文章配圖
5. 產生社群圖卡
/baoyu-xhs-images posts/product-intro.md
指定風格：
/baoyu-xhs-images posts/product-intro.md --style notion
指定流程版型：
/baoyu-xhs-images posts/product-intro.md --layout flow
適合用途：
小紅書圖卡
Instagram 輪播圖
Facebook 貼文圖
WordPress 文章延伸社群素材
6. 圖片壓縮與最佳化
/baoyu-compress-image product-image.png
適合用途：
將圖片轉為 WebP
壓縮 WordPress 圖片
降低網頁載入時間
改善 Core Web Vitals
WordPress 使用場景範例
場景一：WooCommerce 商品頁
你可以先準備商品描述：
產品名稱：黑色真無線藍牙耳機
特色：降噪、長續航、霧面金屬外殼、適合通勤與辦公
圖片風格：高級商業攝影、白色背景、柔和陰影、乾淨構圖
接著用 baoyu-skills 產生：
商品主圖
生活情境圖
功能賣點圖
規格比較圖
社群推廣圖
最後將圖片上傳到 WordPress 媒體庫，套用到 WooCommerce 商品圖集。
場景二：WordPress 部落格文章
如果你要寫一篇「如何挑選無線網卡」的文章，可以使用：
/baoyu-cover-image article.md --style blueprint --aspect 16:9
再使用：
/baoyu-infographic article.md --layout comparison --style technical-schematic
這樣可以同時產生文章封面與比較型資訊圖，讓文章更適合 SEO 排名與社群分享。
場景三：Elementor 首頁橫幅
如果你使用 Elementor 製作首頁，可以先用 baoyu-skills 產生 16:9 或 21:9 的 Hero Banner。
提示詞範例：
請產生一張 WordPress 首頁 Hero Banner：
主題是 AI 產品圖自動生成，
畫面包含商品攝影棚、AI 工作流、WordPress 網站介面，
風格為現代、乾淨、科技感、商業級視覺，
不要過多文字，保留右側放標題的空間。
產出後可放進 Elementor 的 Hero Section，搭配標題、按鈕與 CTA。
baoyu-skills 產品圖工作流程
這樣做的好處是，每次製作商品頁時，不必重新思考整套流程，只要替換產品資料與風格設定，就能快速產出一致的視覺素材。
產品圖提示詞範例
科技產品
黑色 USB WiFi 網路卡，雙天線，放在乾淨白色桌面上，背景有筆電與柔和光影，科技感，高級商業攝影，清晰產品細節，適合電商商品頁
美妝產品
玻璃精華液瓶，琥珀色瓶身，放在大理石平台上，旁邊有綠色植物與柔和自然光，乾淨高級，美妝產品攝影風格
食品產品
手工餅乾禮盒，木質桌面，自然光，溫暖色調，旁邊有咖啡杯與包裝紙，適合品牌形象與電商頁面
軟體服務
AI 批改系統的產品主視覺，畫面包含老師桌面、筆電介面、文件上傳、AI 分析圖示，明亮乾淨，專業 SaaS 風格
使用 baoyu-skills 時要注意什麼？
1. 不要只寫「幫我產生產品圖」
好的提示詞應該包含：
產品名稱
產品材質
使用場景
光線
背景
圖片比例
風格
不要出現的元素
例如：
請產生一張 16:9 商品橫幅圖：
產品是一台銀色 AI 筆電，
放在乾淨的辦公桌上，
背景有柔和藍色光影與抽象 AI 線條，
風格為高級科技產品攝影，
不要出現人物、浮水印、亂碼文字。
2. 產品圖要保留 WordPress 版面空間
如果圖片要放在文章封面或首頁 Banner，建議在提示詞中加上：
或：
這樣後續在 WordPress、Elementor 或區塊編輯器中排版會更方便。
3. 圖片要檢查文字
AI 圖片中的文字有時會出現亂碼，因此若是商品圖、封面圖或廣告圖，建議分成兩階段：
先產生無文字圖片
再用 WordPress、Canva、Photoshop 或 Elementor 加上正式文字
這樣可以避免圖片中文字錯誤影響品牌專業度。
4. 圖片上傳 WordPress 前要壓縮
建議輸出後轉成 WebP，並控制圖片尺寸。
常用建議：
文章封面：1200 × 675
商品圖：1200 × 1200
首頁 Banner：1920 × 800
社群圖卡：1080 × 1350
小紅書圖卡：1080 × 1440
圖片壓縮後再上傳，可改善網站速度與 SEO 表現。
適合誰使用？
baoyu-skills 特別適合以下使用者：
WordPress 網站經營者
WooCommerce 電商賣家
部落格作者
SEO 內容團隊
AI 工具玩家
小型品牌主
產品行銷人員
技術產品代理商
需要大量多語系素材的網站團隊
如果你經常需要為不同文章、商品或社群平台製作圖片，baoyu-skills 可以讓你的視覺內容生產流程更標準化。
近期留言