貓宿研究所如何運用AI？文章製作與WordPress發布實例

在貓宿研究所，我們使用AI與WP-CLI製作文章稿件、登錄至WordPress、更新內部連結，並在發布後進行確認。不過，這並不表示我們把「網站就交給你了」這樣的任務全部交給AI。

實際運作時，我們曾在委託過程中發現前提有誤、功能已實作卻沒有反映在畫面上，或發布前的備份未能正常完成。每次遇到這些情況，我們都會停止作業、進行確認，並將結果納入下一次的規則。

本文介紹貓宿研究所實際發生的案例，整理成其他旅宿也能使用的判斷方法。我們不公開伺服器連線目標、內部路徑、使用者名稱、驗證方式、實際的指令包裝器等可能成為攻擊線索的環境資訊。

交給AI的是「作業協助」，而不是「判斷」
實際的基本流程
實例：從討論到發布一篇文章
不讓WordPress成為AI唯一的記憶
正本不只放在WordPress
案例1：也修正自己網站的檔名錯誤
案例2：將ZIP下載改為Markdown直接連結
案例3：從過於具體的公開範例中移除環境資訊
案例4：首頁最新文章的排除功能起初未生效
案例5：文章能發布，內部連結卻不足
案例6：備份失敗時，沒有把它當作成功
不在一次委託中全部交給AI
不讓AI自由執行WP-CLI
AI完成報告的必要項目
將失敗轉為下一次的規則
1. 從對話成為規則的實例
旅宿經營者從小規模開始
總結
參考資料

交給AI的是「作業協助」，而不是「判斷」

AI擅長調查多個檔案、起草文字、整理修改候選項目、執行既定步驟，以及比較確認結果。另一方面，下列判斷由人掌握。

網站要傳達什麼
文章是寫給誰看的
哪些資訊可以公開
如何區分親身經驗與調查資訊
哪些修改要套用至正式環境
備份失敗時，哪些範圍可以繼續處理
是否會讓住客、宿貓或相關人士蒙受不利

如果分工不清，即使AI把文章修飾得很流暢，仍可能寫出與旅宿實情不符的文章，或造成危險的操作。

實際的基本流程

貓宿研究所將作業分成以下階段。

旅宿經營者說明目的與條件
  ↓
AI調查既有文章、計畫與官方資訊
  ↓
在本機製作Markdown稿件與圖片
  ↓
確認內部連結、分類與description
  ↓
在修改正式環境之前取得並驗證備份
  ↓
透過WP-CLI限定處理對象並套用修改
  ↓
重新讀取文章ID、作者、分類與圖片
  ↓
確認公開URL、本文、連結與首頁
  ↓
將失敗經驗與心得記錄至作業規則

重點是不要把文章製作與正式環境的套用合併成一次操作。調查時不修改，稿件完成後也不立即發布；套用至正式環境後，更不能只因「指令成功」就當作完成。

實例：從討論到發布一篇文章

貓宿研究所新增一篇給旅宿經營者看的文章時，會依照以下方式進行。

1. 透過對話釐清目的

即使最初的要求只有「請製作文章」，AI仍會確認既有的內容計畫與已發布文章，調查是否已有預定要製作的文章、是否已有相同結論的文章，以及是否能自然銜接上一篇。

如果已有類似文章，就整合至既有文章，而不增加另一個URL。只有搜尋詞不同、內容卻相同的頁面變多，讀者與搜尋引擎都會更難分辨差異。

2. 透過官方資訊確認容易變動的事實

WordPress、Codex、Claude Code、訂房服務、支付與Google的功能都會改變。我們不只憑AI的記憶撰寫，而是開啟目前的官方資料進行確認。

撰寫貓咪健康或行為相關文章時，優先參考獸醫師協會、動物福利組織與經同儕審查的論文等。介紹旅宿時，確認旅宿官網、官方社群、地方政府與觀光協會等資訊；沒有實際住過的內容，不寫成親身體驗。

調查時會記錄參考URL與確認日期。不過，不會只依搜尋結果顯示的簡短說明就下定論，而會閱讀原始頁面的正文。

3. 將稿件、圖片與內部連結一併製作

稿件除了標題，還會記錄slug、description、分類、確認日期，以及精選圖片的位置與替代文字。

文章中的圖片，要避免以看起來像真實旅宿或貓咪紀錄照片的方式使用。不擅自轉載旅宿或貓咪的照片；即使是生成插畫，也採用不會讓人誤以為「實際拍攝了該場景」的構圖。

內部連結不只從新文章連向既有文章，也會從相關的既有文章與旅宿經營者指南頁面，建立返回新文章的路徑。

4. 由人確認公開範圍

發布前，由人判斷並確認下列事項。

符合想向讀者傳達的結論
沒有將未曾住宿的內容寫成親身體驗
旅宿、貓咪與人物的資訊可以公開
沒有包含連線目標、內部路徑、使用者名稱或秘密值
沒有推測訂房條件、價格、法律或健康資訊
沒有與相關文章內容重複

不會只因文章讀起來自然，就視為符合核准條件。

5. 限定對象後套用至正式環境

修改前先執行備份，確認正常完成與完整性。發布的只有已核准的稿件、圖片與必要的內部連結，不同時修改與委託無關的佈景主題、外掛或伺服器設定。

備份失敗時，不把它當作成功，而是確認停止與繼續的條件。可逆的文章更新，與資料刪除、遷移或伺服器更新，其復原風險並不相同。

6. 確認讀者看到的結果

從WordPress重新讀取作者、發布狀態、slug、分類、description與精選圖片，接著確認公開URL、旅宿經營者指南、相關文章與首頁。

也會擷取電腦與手機畫面，目視確認表格、圖片、標題與訂房路徑是否顯示正常。旅宿經營者文章還會確認能按預期從專用頁面閱讀，且沒有混入面向一般讀者的首頁最新文章。

不讓WordPress成為AI唯一的記憶

WordPress是向讀者發布內容的地方，但不是儲存全部文章計畫、依據資料、稽核紀錄與作業規則的地方。

資訊	正本範例
公開文章的正文與屬性	Markdown稿件
文章主題與發布順序	內容計畫
旅宿或功能的確認來源	調查紀錄
AI必須遵守的作業規則	`AGENTS.md`、`CLAUDE.md`
WordPress上的發布狀態	文章ID與公開頁面
發布後的結果	檢查與稽核紀錄

如果重要判斷只留在與AI的對話裡，另一天作業時就找不到。結論確定後，應記錄至符合其用途的正本。

正本不只放在WordPress

我們以本機的Markdown檔案作為文章正文的正本。標題、slug、description、分類區分、精選圖片的位置與確認日期等，也記錄在稿件中。

---
title: "文章標題"
slug: "example-article"
description: "說明文章內容的文字"
category: "給旅宿經營者"
owner_section: "ai-site-management"
status: "publish"
fact_checked: "YYYY-MM-DD"
featured_image: "公開用圖片的位置"
featured_image_alt: "說明圖片內容的文字"
---

如果只在WordPress管理介面直接編輯，就更難追蹤修改了什麼、先前稿件是哪一份，以及是否也修正了相關頁面。手邊有正本，AI便能確認正文以外的內部連結，以及與文章計畫之間的差異。

不過，不會在公開用Markdown中加入伺服器配置或驗證資訊。我們將AI作業使用的內部規則，與提供給讀者的範例分開管理。

案例1：也修正自己網站的檔名錯誤

情況

我們曾將向Codex傳達專案作業規則的檔案，視為單數形式的AGENT.md。在製作旅宿經營者範本的過程中，確認正式檔名是複數形式的AGENTS.md。

判斷

如果只修正提供給讀者的文章說明，自己的專案卻繼續使用舊名稱，推薦給讀者的方法就與實際運作不一致。因此決定將正本統一為AGENTS.md。

執行與確認

不只修改檔名，也對專案內引用舊名稱的說明、範本、腳本與Claude Code指南進行全文搜尋，並確認新舊兩份正本不會同時留下。

心得

發現名稱或規格錯誤時，不只修正公開文章，也一起修正自身作業與引用來源。與其只請AI「改名字」，請它「調查引用舊名稱的地方，列出修改候選項目」，更能減少遺漏。

案例2：將ZIP下載改為Markdown直接連結

情況

起初，我們以ZIP提供AGENTS.md與CLAUDE.md範本。不過，有人指出，對不熟悉IT的旅宿經營者來說，必須解壓縮才能確認內容的ZIP可能令人不安。

判斷

技術上能提供下載，與使用者能放心使用，是不同的事情。因此改為下載前就能在瀏覽器閱讀內容的Markdown直接連結。

執行與確認

不只確認新連結能開啟，也確認能直接取得Markdown，以及文章或列表中沒有殘留舊ZIP的連結。

心得

AI容易將「檔案已放好」「可透過HTTP開啟」視為完成條件。有必要把使用者的疑慮、儲存時的檔名與舊導覽路徑是否殘留，也納入完成條件。

案例3：從過於具體的公開範例中移除環境資訊

情況

為了讓AI作業範例更容易理解，我們曾在公開範本中加入接近實際伺服器方式、內部配置與作業指令的資訊。

判斷

具體範例有助於理解，但不需要公開的內部資訊可能成為攻擊或非法存取的線索。「越具體就越貼心」並不一定成立。

執行與確認

刪除環境專屬的描述，改為「限制權限」「取得可復原的備份」「發布前由人核准」等不透露配置、仍能重現行動的表達方式。不只搜尋範本，也搜尋說明範本的文章與列表。

心得

向讀者公開的範圍限於判斷原則、確認項目與虛構環境範例。不公開連線目標、內部路徑、使用者名稱、秘密值或實際作業的防護方法。請AI處理時，不只要求「刪除秘密值」，也要請它「將可能成為攻擊線索的配置資訊列為候選項目」。

案例4：首頁最新文章的排除功能起初未生效

情況

我們新增了將旅宿經營者文章排除於首頁一般最新文章的處理。設定與程式碼看起來正確，但確認公開頁面的HTML時，文章卡片仍然存在。

判斷

不能因「已啟用功能」就視為完成，必須確認讀者看到的最終結果。我們調查一般文章列表與首頁獨立的最新文章區，是否透過不同機制取得文章。

執行與確認

先調查首頁顯示了多少篇目標文章，再將排除條件加入相應的文章取得流程。修正後確認以下兩點。

旅宿經營者文章的卡片為0張
首頁最新文章的總數維持預定數量

心得

確認「不顯示」時，光確認目標消失還不夠，也要確認整個最新文章區沒有一起消失。設定畫面、資料庫、HTML與實際畫面，是不同的確認位置。

案例5：文章能發布，內部連結卻不足

情況

增加旅宿經營者文章後，我們發現即使分類設定正確，早期文章仍沒有相關文章連結，新文章也沒有列在入口頁面。

判斷

不只依賴分類，而是透過以下三層建立讀者路徑。

從頁首選單進入「給旅宿經營者」
在入口頁面選擇目的或分類
從文章正文前往前後文章或相關文章

執行與確認

將公開文章URL與內部連結列成清單，確認入口頁面的收錄、文章間的雙向連結與分類。不在頁首列出所有文章，而只放通往已有文章的分類之入口。

心得

文章發布的完成條件要包含「入口」「相關文章」「返回路徑」。只替新文章加上連結，而既有文章無法連到它，仍是單向路徑。因此也同時更新相關的既有文章。

案例6：備份失敗時，沒有把它當作成功

情況

修改正式環境前的備份過程中，系統偵測到運作中的檔案被修改，新的備份程序未能正常完成。

判斷

執行了備份指令，與取得正常的備份，是不同的事情。我們沒有隱瞞失敗，而是確認下列事項。

是否仍有製作中的不完整檔案
是否有最近已確認完整性的備份
這次的修改能否逐項復原
是否包含資料刪除、遷移或伺服器更新

執行與確認

只有在符合繼續條件時，才將範圍限定為可個別取消公開或退回原狀的文章新增。不將失敗的封存檔回報為「已取得」，並在完成報告中明列限制。

心得

發生錯誤時的安全判斷，不依當下心情決定。應在作業規則寫明「最近已驗證的備份」「確認不完整檔案」「只有可逆修改」「刪除或遷移不繼續」等條件。

不在一次委託中全部交給AI

實際溝通時，我們會如下拆分委託。

只做調查

請確認相關稿件、文章計畫與WordPress上的狀態。
這次只進行讀取，不要編輯檔案、修改設定或發布。
請回報不足的資訊、重複內容、內部連結候選項目與需要確認的事實。

製作本機稿件

請只使用已確認的資訊製作Markdown稿件。
不要修改正式環境的WordPress。
請自行檢查標題、slug、description、分類、內部連結、參考資料，
以及是否包含不得公開的資訊。

套用至正式環境

請只將已核准的1篇稿件與相關內部連結套用至正式環境。
修改前請取得備份，確認正常完成與完整性。
不要修改範圍外的文章、佈景主題、外掛或伺服器設定。

發布後的驗證

請確認文章ID、作者、狀態、slug、分類、精選圖片與description。
請確認公開文章、入口頁面、相關既有文章與首頁的HTTP回應和連結。
請分別回報應顯示的位置，以及不應顯示的位置。
未確認事項與失敗，不得視為已完成。

拆分委託後，更容易辨識認知在哪個階段出現偏差。

不讓AI自由執行WP-CLI

貓宿研究所的公開文章提供可學習機制的虛構指令範例，但不公開實際作業的連線方式或執行路徑。

重要觀念是一致的。

一開始只進行讀取
固定目標網站、文章ID與數量
將建立草稿與發布分為不同操作
比較修改前後的分類
每次匯入1個圖片檔案，確認附件ID
只發布人已核准的文章ID
將刪除、任意程式碼執行與資料庫操作排除於一般操作路徑
執行後從WordPress重新讀取數值

只允許已核准操作通過，而不開放自由使用WP-CLI的觀念，請見如何製作受限制的指令包裝器。

AI完成報告的必要項目

只說「已發布」，旅宿經營者無法判斷安全性。至少應要求回報下列事項。

作業結果
- 對象：文章名稱、slug、文章ID
- 修改的項目：稿件、圖片、內部連結、WordPress文章
- 未修改的項目：範圍外文章、設定、伺服器
- 備份：正常完成、完整性、儲存時間
- WordPress確認：作者、狀態、分類、圖片、description
- 外部確認：文章、列表與首頁的HTTP回應
- 顯示確認：顯示的位置、被排除的位置
- 未確認事項：人工畫面確認、訂房表單等
- 錯誤：發生內容、停止的階段、繼續處理的判斷依據

能回報失敗與未確認事項的AI作業，比起斷言「全部沒有問題」的作業更值得信賴。

將失敗轉為下一次的規則

為了避免每次在對話中重複相同提醒，判斷確定後，應保存在適當的正本。

心得	記錄位置
AI必須始終遵守的安全規則	`AGENTS.md`、`CLAUDE.md`
文章主題、發布順序與分類	內容計畫
實際發生的失敗與判斷	案例筆記
文章正文、description與圖片資訊	各Markdown稿件
發布後的確認結果	作業紀錄與稽核紀錄