平常我習慣使用 Notion 進行文章創作，從蒐集資料、整理大綱、撰寫內文，到放入配圖，大部分的創作工作都會在 Notion 完成。

但文章寫好、完成配圖設計之後，還有一件與創作無關的事得自己來：上稿進 WordPress。

我要先登入 WordPress 後台，把 Notion 裡的文字複製過去，重新檢查段落與標題格式，再將文章中的圖片下載、壓縮圖檔大小到200k以內、上傳到 WordPress 媒體庫。接著還得設定精選圖片、分類、標籤、圖片替代文字（Alt Text），以及對 SEO 比較友善的英文網址（URL Slug）等等許多相當枯燥的事。

每個動作都不困難，但每次創作完文章都要重複一遍。尤其當文章有好幾張圖片時，光是圖片處理就得花上一些時間，想到就令人焦燥。

前面幾篇，我們已經陸續替 AI 分身擴充了不少能力，也讓它開始學會我的工作習慣。這時我突然想到：既然分身已經會使用各種工具，能不能連文章上稿這件事，也一起交給它？

於是，這篇的目標就出來了：讓我的分身從 Notion 中取得我寫好的文章，依照我的創作習慣處理文字與圖片，再自動上架到 WordPress。

這次實作，也讓我開始思考一件事：當工作橫跨好幾套軟體時，我們該怎麼教 AI 分身，把這些工具組合成一套完整的工作流程。

甚至能不能進一步整合成一個會用我的觀念、我做事方法的 Skill？這篇就讓我們一起一步步建構。

會使用單一工具，和用多個工具完成整套工作流，還有一段距離

前面我們用 Hermes 訓練出我們本尊做事方法的 Skills，也讓它學會透過 MCP 使用我們平常在用的工具執行各種工作。但平常在公司工作時，很少有一件工作只需要使用一套工具。

例如製作一份客戶提案，可能需要從Google Drive 雲端硬碟取得資料、用 Excel 整理數字、用 Canva 製作簡報，再透過 Email 交給客戶。

AI 工作分身也是一樣。

這次的文章上稿，至少需要串起幾項能力：

1. 從 Notion 取得文章內容與圖片。
2. 依照我的規則整理內文、處理圖片及格式轉換。
3. 使用 WordPress 建立文章、上傳圖片、設定分類與標籤。
4. 檢查上稿結果，確認沒有缺圖、格式錯誤或重複建立文章。
5. 將完成的草稿交還給我，由我決定是否發布。

當我們把這些操作依照工作順序串在一起，就形成了工作流程（Workflow）。

這裡也可以順便區分幾個之前學過的觀念：

• Tool（工具）：讓 Agent 具備操作某個系統或執行某項動作的能力。
• Workflow（工作流程）：定義多個步驟如何依序執行、傳遞資料，以及遇到問題該怎麼處理的邏輯
• Skill（技能）：將完成工作的規則、操作方法與相關知識整理起來，讓 Agent 日後可以重複使用。

Workflow 也不一定要全自動執行。像這次，我仍然希望由自己決定哪篇文章要上稿，Hermes 則負責處理收到指令後的工作。

工具怎麼接進來？除了 MCP，也可以直接使用 API

確定要把 Notion 和 WordPress 串起來之後，接下來遇到的問題是：要用什麼方式，讓 Hermes 能操作這兩套軟體系統？

前面介紹過 MCP（Model Context Protocol），它能讓 AI Agent 透過標準化的方式，連接各種外部工具：讓 AI 分身用我平時在用的軟體做簡報：Canva MCP 實戰

不過，這次我選擇了另一條路：直接透過 API 實作。

API 和 MCP 有什麼不同？

API（Application Programming Interface，應用程式介面）可以理解成軟體對外提供的操作入口。

例如 WordPress 除了讓我們透過網頁後台新增文章，也提供 REST API，讓外部程式可以透過網路請求，執行建立文章、修改內容、上傳圖片等操作。

MCP 則是在 AI Agent 和外部工具之間，建立一套共通的工具連接與呼叫方式。Agent 可以透過 MCP 知道有哪些工具可用、需要提供什麼參數，以及如何執行。

兩者其實不是互斥的技術。事實上，非常多的 MCP 實際在背後，也是在呼叫原本服務提供的 API。

為什麼這次我選擇 API？

以這次的上稿任務來說，我需要的是一套相對固定的工作流程。當文章來源確定後，下載圖片、檢查檔案大小、轉換格式、上傳媒體庫等步驟，其實都有明確的處理規則。

一般狀況下，直接使用 API 搭配程式封裝這類固定流程，往往比讓 AI 逐步呼叫多個 MCP 工具更省 Token。

原因主要有三個：

1. 減少工具描述佔用的 Token：部分 MCP 整合會將工具名稱、功能說明與參數結構提供給模型。如果連接大量工具，這些資訊也會佔用上下文空間。
2. 減少重複推理：例如處理六張圖片，若每張都要 AI 決定下載、轉檔、命名及上傳的動作，就會產生多次模型與工具之間的往返。如果事先寫成邏輯，就能依照規則直接執行。
3. 減少不必要的資料回傳：API 經常回傳大量 JSON 資料。透過程式，可以先整理出真正需要的結果，再回報給 AI，不必將所有中間資料都塞進對話。

不過，這並不代表 API 在任何情況下一定都比較省 Token。真正影響成本的關鍵，是有多少工作需要模型參與，以及工具回傳多少資料。設計良好的 MCP 工具，同樣可以把一整段工作封裝起來。Hermes 也提供 Tool Search 機制，能減少大量 MCP 工具描述佔用上下文的問題。

兩種方法各有優缺點：

如果只是希望 AI 能快速使用某項外部服務，而且已經有成熟的 MCP Server，我通常會優先考慮 MCP。

但這次涉及文章轉換、圖片處理，以及不少個人化的上稿規則，直接透過 API 搭配程式來完成，會比較穩定，效能也較好。

實作：讓 Hermes 用 API 串起我的文章上稿流程

接下來就實際動手做。這次使用的是 Notion 官方 API，以及我架設在遠端伺服器主機上的 WordPress 網站。

步驟一：先和 Hermes 討論整套工作流程

遇到這類跨工具任務，我建議先不要急著安裝工具或設定 API，可以先要求 Hermes 協助釐清需求與執行步驟。

例如，可以給它這樣的指令：

我想讓你協助把 Notion 裡完成的文章，連同圖片一起上稿到 WordPress。
先評估適合的串接方式，並列出各種方式的優缺點，及我需要注意的地方。

《R森小叮嚀》

也可以使用前面介紹過的 /plan 規劃模式，它可以產生執行計畫，讓我們有機會檢查方向，再決定是否開始實作。

忘記怎麼用的朋友請參考這篇：要求 Agent 先計畫再動手：Hermes 內建二種模式 plan & goal

我這次實際和 Hermes 討論時，也是先要求它評估幾種不同的方案，確認是我想要的之後，才決定要它實作什麼方案。

在過程中，我也逐步補上自己在做這類工作時的規則，例如：

• WordPress 只能建立草稿，不能直接公開發布。
• 圖片必須真正上傳到 WordPress 媒體庫。
• 圖片超過 200KB 時，轉成 JPEG 並壓縮至指定大小以下。
• 圖片依照出現順序命名，例如 img01_簡短英文語意.jpg。
• SEO ：
  • Alt Text 依照圖片內容與文章主題撰寫，不刻意堆砌關鍵字。
  • 自動產生簡短、符合文章主題的英文 URL Slug。
• 分類與標籤優先使用網站已有的項目，不得擅自新增。

你會發現，上面這些「我平常上架時的邏輯和工作方式」，其實不容易一次就完整交代。所以需要來回跟 Agent 討論，請它不確定的地方就問你不要急著實作，等一切都確定清楚後，才讓 Agent 開始寫建立連線技能。

步驟二：讓 Hermes 接上 Notion API，取得文章內容

Notion 提供官方 API，讓外部程式存取授權範圍內的頁面、資料庫與內容區塊。

基本設定可以分成三個動作：

(1) 前往 Notion Integrations 相關管理頁面，建立自己的 Integration（整合應用），取得 API Token。

(2) 設定必要的讀取權限，並將希望 Hermes 能讀取的頁面或資料庫授權給這個 Integration。

(3) 將 API Token 安全地存放在 Hermes 的執行環境中，最簡單的方式是放在對應 profile 的 .env，再請 Hermes 測試是否能讀取指定的 Notion 頁面。

要注意，拿到 API Token 不代表能讀取整個 Notion 工作空間。你仍然得授權相應的頁面。如果沒有授權，即使頁面連結正確，API 也可能回傳找不到頁面的錯誤。

設定完成後，我把我在 Notion 中一篇已經寫好的文章網址，交給 Hermes，看看能否讀的到。

從測試結果可看到，Hermes 成功取得內容。至此，讓 Hermes 透過 API 連接 Notion 這步驟就算是成功了。

步驟三：讓 Hermes 接上 WordPress API，取得上稿能力

Notion 連線完成後，接下來就要處理 WordPress。

WordPress 本身提供 REST API，因此不需要額外裝外掛，就能讓外部程式（這個例子中是「Hermes Agent」）建立文章、上傳圖片及讀取分類資料。

不過，為了日後方便稽核，我不打算直接把自己平常使用的管理員帳號交給它，而是建立 Agent 專用帳號，再搭配 WordPress 的 Application Password（應用程式密碼）。

設定過程大致如下：

1. 登入 WordPress 後台，在「使用者」中建立一個專門給 Hermes 操作的帳號。
2. 依工作需求配置角色與權限。這次使用作者（Author）角色，讓它能處理文章及媒體。
3. 進入該帳號的個人資料頁面，找到「應用程式密碼」區塊，產生一組專用密碼。
4. 將密碼安全地保存到 Hermes 的秘密環境設定中（例如 .env 中），這裡要注意不要直接貼進聊天對話中，有點危險。
5. 請 Hermes 測試 WordPress REST API 是否可以正常連線與操作。

Application Password 和平常登入 WordPress 的密碼不同。它專門提供 API 使用，可以個別撤銷。萬一日後不想讓 Hermes 繼續操作網站，只需要停用相應的授權，不必更換自己的主要登入密碼。

《R森小叮嚀》

我個性比較保守，只要是 AI 幫我做的東西，我都不允許直接出去。例如 Agent 寫完信最多只能幫我放在草稿夾等待我 review、Agent 完成文章上架最多只能放在草稿區，等到我確認真的沒問題後才放行發佈。

設定好之後，Hermes 以後就能透過 WordPress API 操作網站，例如：

• /wp-json/wp/v2/posts：建立與更新文章。
• /wp-json/wp/v2/media：上傳與管理圖片。
• /wp-json/wp/v2/categories：查詢文章分類。
• /wp-json/wp/v2/tags：查詢文章標籤。

這些都會由 Hermes 實際撰寫介接 API 完成，我們需要做的事，就是跟他說我要接上我的 WordPress，接著它就會邊寫程式，遇到需要我們的地方也會引導我們做，例如 API Key 的存放。

步驟四：將兩套工具串起來，完成實際上稿

兩邊的連線都建立後，就可以開始測試整套工作流。

我用一篇之前就已經寫好的「小宅裝修與空間規劃」的 Notion 文章進行上架測試。文章除了正文，還有六張圖片，以及一些預留給不同社群平台使用的文案。

AI 分身此時就會依照先前我教會它我平常上架工作的方式，完成了以下工作：

1. 從 Notion 取得文章，保留需要的內文與排版結構，排除 IG、FB、Thread 的社群文案區塊。
2. 下載六張圖片，轉換為 JPEG，並將每張圖片壓縮到 200KB 以下。
3. 將圖片依序重新命名為 img01_...jpg、img02_...jpg 等檔案，並產生對應的繁體中文 Alt Text。（SEO 考量）
4. 將六張圖片上傳到 WordPress 媒體庫，以第一張作為精選圖片，其餘五張依序放回正文。（SEO 考量）
5. 將文章轉換成 WordPress Gutenberg 編輯器可使用的格式，設定既有分類、標籤與 SEO 考量的英文 Slug。
6. 建立 WordPress 草稿
7. 最後，再透過 API 重新讀取一次 WordPress 中的文章，確認圖片、內容與草稿狀態正確。

這次測試產生的英文 Slug 是：small-home-functional-zoning，文章也成功建立在 WordPress 後台，狀態為 draft，沒有公開發布。

可喜可賀！現在，AI 分身已經能依照我平常的上稿規則，把不同的外部工具串在一起用我做事的方式完成任務。

做過一次還不夠：把成功的工作流整理成 Skill

如果我明天重新開一個對話，請它上稿另一篇文章，我的分身還會知道剛才這整套做法嗎？

光靠這次對話的紀錄，並不是最可靠的方式。尤其這套工作流包含不少細節，例如圖片尺寸限制、命名規則、分類選擇方式，以及禁止發布等條件。

於是，我請 Hermes 把這次對於 Notion 和 WordPress 的操作方式整理成 Skill，讓它下次可以重複使用。

我真正想交給分身的工作，其實很單純：把一篇已經完成的文章，依照我的規則上傳到 WordPress。文章來源可能是我自己在 Notion 手打的文，也可能是我在對話中和 AI 分身一起完成的文章，起點可能不同，但最終要完成的上架工作卻一樣。

所以我要求 Hermes 將它們整合成一個 Skill，命名為：push-to-wordpress

這個 Skill 保留了上稿流程、圖片處理規則、API 使用方式、草稿限制，以及上稿後的檢查標準。

下次不論我要上架任何部落格文章創作，都可以一句話交代給這個 Skill 處理。

當然，Skill 本身並不會憑空產生操作 WordPress 的能力。實際的連線與上傳，仍然需要 MCP 或 API、相關程式及身份授權。Skill 負責保存這套工作的使用方法，讓分身知道何時該執行、如何執行，以及什麼情況應該停止。

有能力操作，不代表 AI 分身有權替我做所有決定

在這次實作的一開始，我就下了一項規則：任何對外發布後難以復原、或回復成本很高的內容，都只能先儲存為草稿，嚴禁直接發佈。

這個規則不只適用 WordPress。未來讓分身協助寫寄 Email、社群貼文或其他對外內容的內容發佈，我也希望由自己做最後把關，決定什麼時候正式送出。

因此，WordPress 上稿流程中，我特別要求 Hermes 在建立文章時明確指定儲存為草稿，並且在完成後重新再讀一次資料，務必確認狀態確實是草稿。

類似的概念，如果在文章分類與標籤找不到合適的既有項目，它也不能自己建立一大堆新分類，而是應該先來問我。

這些其實都是人類參與決策（Human-in-the-loop）的設計。

當我們開始讓 AI 接觸真實工作系統時，除了教它怎麼完成任務，也要把可以自行執行的範圍、需要確認的事情，以及出錯時的緊急停止條件交代清楚。

這次，AI 分身學會了「連續用我的多種工具，處理一整串瑣碎的工作」

這次的實作結果，讓我之後的確省下許多時間，蠻有那種「分身替我代勞瑣事」的解放感。

以前文章寫完後，我還得在 Notion、圖片處理工具與 WordPress 之間來回切換，完成那些重複的上稿動作。

現在，我在 Notion 中把文章寫完後，接著只要下一個指令給分身，它就會依照我的上稿方式的 Skill 處理整篇的文字、圖片、SEO 與各種網站繁雜的細節瑣事，有效率地將全部事情都處理好，並放進 WordPress 草稿夾中。

當然，這不代表我可以完全不管上稿工作：文章內容是否正確、圖片呈現是否符合預期，以及什麼時候適合正式發布，仍需要由我判斷。

但至少，原本得靠自己操作的一連串與創作無關的枯燥上架工作，現在我的 AI 分身已經可以幫我接手。

這個方法不限於 Notion 和 WordPress。只要你平常的工作有需要在多個工具之間，依照某種說得清楚的工作邏輯執行操作，都可以試著使用本篇所分享的方式，讓你的 AI 分身開始能處理跨工具的日常任務。