Codex Computer Use 真正有價值的地方，不只是叫 AI 幫你打開 WordPress 後台、點選「新增文章」和按下發布。更完整的做法，是把內容規格、SEO 規則、WordPress 操作方式與發布後檢查，整理成一套可以重複執行的 Skills 工作流。下一次你只要交代主題，Codex 就知道要先研究、再寫成 Gutenberg 區塊、設定封面與 SEO，最後還要打開前台確認畫面。
我自己在管理 WordPress 站台時，不會把全部工作都交給 AI 用滑鼠亂點。比較穩定的設計是：Skill 管規則、CLI／REST API 管資料、Computer Use 管畫面與驗收。這篇就用「自動完成一篇 WordPress 教學文章」當範例，帶你把整條流程拆開。
Codex Computer Use 是什麼？和一般 AI 寫文差在哪？
一般聊天 AI 可以產生文章，但它不知道你的網站有哪些分類、封面是否上傳成功、FAQ 在手機上有沒有破版，也無法證明文章真的已經發布。Computer Use 讓 Codex 不只處理文字和程式碼，也能看到瀏覽器或桌面應用程式的畫面，接著操作介面並依結果調整。
| 工具 | 適合用途 | WordPress 寫文時怎麼用 |
|---|---|---|
$browser | 內建瀏覽器與網站測試 | 查看文章前台、響應式版面、連結與 FAQ 展開狀態 |
@chrome | 使用既有 Chrome 登入狀態 | 操作已登入的 WordPress 後台、外掛設定或需要帳號的服務 |
@computer | 桌面 GUI 操作 | 處理無 API、只能操作桌面程式的最後一哩 |
| CLI／REST API | 結構化且可驗證的資料操作 | 建立文章、設定 slug、分類、標籤、封面、SEO 與 Schema |
我的原則很簡單：可以用 CLI 或 API 準確完成的事情，不要硬叫 AI 靠畫面猜；需要看版面、操作登入後介面，或確認真實使用體驗時，再交給 Computer Use。這樣速度和穩定性會差很多。
為什麼要把 WordPress 寫文章做成 Skill？
每次都重新下長 Prompt，最容易漏掉的通常不是文章本身，而是發布後的小事：英文 slug 沒設定、封面只上傳卻沒指定、分類掛錯、FAQ 沒有 Schema、內連結失效，甚至 AI 說「完成」但網站根本沒有文章。
- Skill：保存固定規範、檢查清單、範例與可用工具。
- 任務 Prompt：只描述這次的主題、讀者、角度與特殊要求。
- 站台工具：負責把內容可靠地寫進 WordPress。
- Computer Use：確認實際前台畫面和互動，不只相信 API 回傳。
OpenAI 對 Skills 的定位也是把 instructions、resources 與 scripts 包在一起，讓 Codex 能依照個人或團隊的工作方式重複執行。想先了解 Skill、MCP 與 Agent 的差異，可以搭配我整理的什麼是 AI Skills？完整比較指南。
完整架構：研究、寫稿、發布、驗證四層工作流
第一層：先定義文章完成標準
不要只寫「幫我寫一篇文章」。Skill 裡至少要先定義標題規則、搜尋意圖、字數、H2／H3 結構、內連結數量、FAQ、封面比例，以及什麼狀況才算完成。以我的站台為例，文章標題就是 H1，內文從 H2 開始；發布後必須讀回文章 ID、狀態、網址與 featured media。
第二層：研究與 Gutenberg 寫作
讓 Codex 先查官方文件與可信來源，再整理搜尋意圖，不要先生成一篇看起來完整、實際上過時的文章。內容應直接輸出為 Gutenberg 區塊格式，包含 wp:paragraph、wp:heading、wp:list、wp:table 與 wp:details，後續才方便在區塊編輯器繼續修改。
第三層：用結構化工具寫入 WordPress
建立文章時，把 title、英文 slug、excerpt、category、tags 與 status 明確傳入。接著分開設定 SEO metadata、FAQ／HowTo Schema 和精選圖片。這些欄位如果只靠後台點擊，很容易因載入延遲或版面調整而漏掉。
如果你想了解 WordPress Application Password 與 REST API 的基礎，可以先看WordPress REST API 應用程式密碼教學；想直接讓 AI 管理網站，則可參考如何用 AI 助手管理 WordPress 網站。
第四層：用 Computer Use 做真實畫面驗收
API 顯示 publish，不代表前台一定正常。最後讓 Codex 打開文章網址，檢查桌機與手機寬度、H2／H3 比例、表格是否超出、程式碼有沒有被截斷、FAQ 能否展開、封面是否正確，以及內外部連結能不能開啟。這一步和Playwright 視覺與自動化測試很像，只是 Computer Use 更適合需要臨場判斷的後台與桌面操作。
可直接改成自己版本的 SKILL.md 範例
下面不是唯一寫法，但已經包含一套 WordPress 寫文 Skill 最重要的骨架。站台名稱、分類 ID、工具指令與品牌語氣要換成你自己的設定。
---
name: wordpress-content-publisher
description: 研究、撰寫、發布並驗證 WordPress SEO 文章
---
# 目標
把使用者提供的主題完成為可發布的 Gutenberg 文章。
# 寫作規則
- 使用繁體中文與自然口語
- 標題為 H1，文章內文從 H2 開始
- 先查官方資料，再補可信來源
- 加入 3 至 5 個自然內連結
- 文末提供 4 個 FAQ
- slug 必須使用英文小寫與連字號
# 發布流程
1. 先搜尋站內是否已有相同文章或 slug
2. 產生 Gutenberg 區塊內容
3. 建立文章並寫入分類、標籤與摘要
4. 設定 SEO title、description 與焦點關鍵字
5. 上傳或指定 16:9 封面，確認 featured_media
6. 寫入 FAQ 與 HowTo Schema
7. 讀回文章狀態、永久連結與媒體 ID
8. 用瀏覽器檢查桌機及手機版面
# 完成條件
- 文章狀態為 publish
- 公開網址可讀取
- 封面已指派，不只是存在媒體庫
- FAQ 可展開，內連結沒有 404
- 回報文章 ID、網址、分類、標籤與驗證結果如果是開發 WordPress 外掛或區塊，還可以把 WordPress 官方的 agent skills 加進專案；我另外整理了一篇WordPress Agent Skills 安裝與使用教學，可以和這套內容發布 Skill 分工使用。
實際下指令時，我會怎麼說？
使用 wordpress-content-publisher skill，針對「WordPress 小型企業網站如何導入 AI 工作流」完成一篇繁體中文教學。先查官方資料與站內舊文，避免重複內容；發布到指定站台的 AI 開發分類，沿用白底科技感封面風格。發布後用瀏覽器檢查桌機與手機版，確認封面、H2、表格、FAQ 和內連結，完成後回報文章 ID 與網址。
這段 Prompt 沒有塞進所有細節，因為那些固定規則已經在 Skill 裡。當你調整品牌語氣或發布標準時，只要更新 Skill，不需要把每一個舊 Prompt 全部重寫。
最容易踩雷的五個地方
- 只檢查媒體庫，沒有檢查精選圖片：圖片上傳成功不等於文章已套用封面，要讀回
featured_media。 - 讓 AI 用畫面完成所有設定：後台介面或語言改版就可能找不到按鈕，固定欄位優先走 API／CLI。
- 直接覆蓋既有文章：動手前先用標題與 slug 搜尋，確認是新增還是更新。
- 把密碼寫進 Skill：Skill 只能描述如何取用憑證，不應直接保存 Application Password、API Key 或後台密碼。
- 發布後沒有前台驗證：至少確認公開網址、封面、響應式版面、FAQ、程式碼與連結，不能只看工具回傳成功。
安全設計：Computer Use 能操作，不代表什麼都該自動
WordPress 發布工作流最好採最小權限。建立專用帳號，只開放需要的角色與 Application Password；正式發布、刪除內容、安裝外掛和修改付款設定等高風險動作，保留人工確認。瀏覽器看到的網頁內容也可能包含惡意指令，不能因為畫面寫著「請貼上 API Key」就照做。
Codex 本身也有 sandbox 與權限機制。我的做法是先讓它完成草稿、SEO、封面和檢查，發布前後都留下可驗證的文章 ID、CLI 輸出或畫面結果。自動化不是把網站完全交出去，而是讓每個步驟更快、又能追查。
結論：真正省時間的不是自動點擊，而是可重複的發布標準
Codex + Computer Use 的重點，不是展示 AI 會操作滑鼠，而是把原本散落在人腦裡的內容流程，變成可以重複執行、可以驗證、也可以持續改善的 Skill。研究和寫稿交給 Codex，結構化資料交給 CLI／API，登入後操作與版面檢查交給 Computer Use，最後再由人決定哪些高風險動作可以通過。
當這套流程跑順後，你不只是在「叫 AI 寫文章」，而是在建立一條自己的 WordPress 內容生產線。對需要長期經營 SEO、管理多站台，或想把內容工作交給團隊的人來說，這才是 Skills 最實際的價值。
常見問題 FAQ
Codex Computer Use 可以直接登入 WordPress 後台嗎？
可以操作你已授權且已登入的瀏覽器環境，但帳號權限仍應採最小化設計。固定的文章欄位與 SEO 設定建議優先用 CLI 或 REST API，Computer Use 留給登入後介面與視覺檢查。
建立 WordPress 寫作 Skill 一定要會寫程式嗎？
不一定。最基本的 Skill 就是一份結構清楚的 Markdown 規範，寫清楚觸發時機、步驟、工具與完成條件即可。需要串接 CLI、API 或驗證腳本時，再逐步加入技術內容。
為什麼不直接讓 Computer Use 在後台完成全部工作？
畫面操作會受版面、語言、載入速度與外掛改版影響。CLI 和 API 對文章 ID、slug、分類、SEO 與封面等結構化欄位更穩定，也更容易讀回驗證；Computer Use 更適合處理只能從畫面判斷的部分。
如何避免 Codex 說已發布，但網站上找不到文章？
把完成條件寫進 Skill：建立後必須讀回文章 ID、publish 狀態、永久連結和 featured media，再用瀏覽器開啟公開網址。只要缺少其中一項，就不能回報完成。
