文章寫到一半存成草稿，過幾天回來看，分不清這篇到底是還沒寫完、寫完等人審、還是審完等著修。等到稿子愈積愈多，後台「草稿」分頁躺著三十幾篇，每一篇都叫「草稿」，卻各自卡在不同階段——這就是沒做好文章草稿狀態管理的下場。

對一人部落格或小型編輯團隊來說，問題不在於少了什麼花俏工具，而在於「狀態」這件事從來沒被定義清楚。WordPress 內建的狀態其實夠用，缺的是一套把待審、待修、排程這些階段講明白，並且能一眼看出每篇卡在哪的看板式管理法。這篇會先拆解 WordPress 原生狀態各自代表什麼，再帶你把它們組成一條可運作的多狀態工作流，最後談自訂狀態與常見的踩雷點。

WordPress 內建的文章狀態有哪幾種

WordPress 預設提供 8 種文章狀態，全部記在資料庫 wp_posts 資料表的 post_status 欄位裡。決定一篇文章是公開、等待審核，還是被丟進垃圾桶，靠的就是這個欄位的值。

這 8 種狀態裡，撰稿與發布流程實際會用到的是前 5 種，後 3 種屬於系統自動管理：

實際在文章編輯畫面，你會看到的大約是 6 種。值得注意的是，同一個狀態在不同地方的名稱不一定一致，例如 pending 有時顯示「待審核」、有時只寫「待審」，但內部值都是同一個。把這張對照表貼在手邊，後台任何一個下拉選單或篩選分頁出現的狀態，你都能對得上實際意義。

草稿和待審差在哪，什麼時候該用哪一個

草稿代表「我還在寫，這篇還沒好」；待審代表「我覺得寫好了，請有權限的人來審核並發布」。兩者最關鍵的差異，其實綁在使用者角色上。

對單人經營、本身就有發布權限的作者來說，草稿和待審在操作上沒什麼實質差別——反正最後都是自己按發布。但只要團隊裡出現「投稿者」這種沒有發布權限的角色，差別就出來了。投稿者在編輯文章時，工具列只會給「儲存草稿」和「送交審閱」兩個選項，沒有「發布」按鈕。

• 儲存草稿：投稿者按下後，文章維持 draft，等於對自己說「還沒寫完，之後繼續」。
• 送交審閱：投稿者按下後，文章轉成 pending，等於通知編輯或管理員「這篇可以審了」。

編輯和管理員要找出所有待審稿件很簡單，到「文章」列表點「待審」分頁就能看到一整批等著審核發布的文章。這個區分之所以存在，是因為投稿者角色早期只能存草稿，沒有辦法表達「我寫好了」，後來 WordPress 才補上待審狀態來解決這個溝通斷層。

所以判斷準則很單純：是不是有非發布權限的人在交稿。有，待審就是交稿的訊號；沒有，草稿和待審你可以自己約定一個用法，重點是團隊內部講好同一套語意。

排程文章是怎麼運作的，跟草稿有什麼不同

排程文章的狀態是 future，代表這篇已經完稿、內容鎖定，只是設定了一個未來的發布時間，時間一到 WordPress 會自動把它轉成 publish。這跟草稿是兩件完全不同的事：草稿是「還沒好」，排程是「好了，但故意晚點上」。

操作上，你在發布面板把發布時間改成未來的某個日期與時段，原本的「發布」按鈕就會變成「排程」。按下去之後，文章進入 future 狀態，列表頁會標示「已排程於某時某分」。

排程的價值在於把「完稿」和「上線」這兩個動作拆開。你可以週末一次寫好五篇，分散排到接下來兩週的不同時段，維持穩定的更新節奏，而不必每天守在後台手動按發布。對需要固定出刊頻率的內容站，這是最省力的節奏控制方式。

要留意的是，排程依賴 WordPress 的 WP-Cron 機制觸發。WP-Cron 不是真正的系統排程，而是靠網站有人造訪時才被喚起檢查。流量很低的站偶爾會出現「錯過排程」——時間到了卻沒發布、狀態卡在那。遇到這種情況，多半要改用主機層級的真實 cron 來定時呼叫，這部分留待後續另談，先知道排程沒發出來通常不是你設定錯，而是觸發機制沒被叫醒。

待審、待修、排程怎麼組成一條完整的工作流

把單篇狀態串起來看，一篇文章從零到上線會經過幾個固定階段，每個階段對應一個狀態。問題是 WordPress 原生狀態裡，「待修」並沒有對應的值——這正是多數人卡關的地方。

一條典型的內容流程長這樣：

撰寫中對應 draft、送交審閱對應 pending、排定時間對應 future、上線對應 publish，這四個都有原生狀態撐著。中間那個紫色的「待修」沒有原生狀態，代表審核者看完後認為要退回作者改，這時你有兩種處理方式。

第一種是不另開狀態，直接把文章退回 draft，靠審核留言或文章備註說明要改哪裡。好處是零設定，壞處是「待修的草稿」和「還沒寫完的草稿」混在同一個分頁，分不出來。第二種是用自訂狀態獨立出「待修」這一格，讓退回修改的稿子有自己的位置，這也是下一節要談的。

無論用哪種，核心原則是每個階段只對應一個明確狀態，狀態之間的流向講清楚。一篇文章在任何時刻都應該能用單一狀態回答「它現在卡在哪、下一步該誰動手」。

把工作流變成看板，一眼看出每篇卡在哪

看板管理的精神，是把抽象的「狀態」變成畫面上一欄一欄的格子，每篇文章是一張卡片，卡在哪一欄就代表它在哪個階段。最基本的看板只要三欄就成立——待處理、處理中、已完成——但用在內容流程上，把欄位對齊上一節的狀態會更有用。

一個對應內容流程的看板，欄位大致是這樣排：

• 撰寫中：對應 draft，作者還在生產內容的稿子都停在這一欄。
• 送交審閱：對應 pending，作者認為寫好、丟給審核者的稿子集中在此，審核者每天掃這一欄就好。
• 退回修改：對應自訂的待修狀態或退回的草稿，需要作者再動手的稿子待在這裡，避免跟全新草稿混淆。
• 已排程：對應 future，完稿且排定上線時間的稿子，等系統自動發布。
• 已發布：對應 publish，上線後移到這一欄當作存放區，要回頭更新舊文時也找得到。

看板的優勢有兩個。一是視覺化的庫存盤點：哪一欄堆太多卡片，瓶頸就在那裡。如果「送交審閱」長期塞著一堆，代表審核這關卡住了；如果「撰寫中」永遠是空的，代表沒人在補新稿。二是責任歸屬清楚：卡片在「撰寫中」是作者的事，移到「送交審閱」就換審核者接手，狀態本身就是交接的訊號。

對一人經營者來說，看板一樣有用，只是「交接」變成提醒自己現在該切換到哪個角色——是該坐下來寫新稿，還是該審昨天寫完的那兩篇。WordPress 後台的「文章」列表頁，本身就提供按狀態篩選的分頁（全部、已發布、草稿、待審、已排程），算是一個極簡版的清單式看板；想要拖拉式的視覺看板，再考慮搭外掛或外部工具。

原生狀態不夠用時，怎麼加自訂狀態

當你需要「待修」「已校對」「待配圖」這類原生沒有的階段，就得靠自訂狀態。WordPress 從 3.0 版起就支援用 register_post_status() 函式註冊自己的狀態，這是所有自訂狀態方案底層共用的機制。

直接寫程式的做法，是在佈景主題的 functions.php 掛一個 init 動作，呼叫 register_post_status() 註冊新狀態，並設定它的標籤、是否公開、是否出現在後台清單等參數。要提醒的是，WordPress 核心只負責「登記」這個狀態，並不會自動把它加進文章編輯畫面的下拉選單——那部分還要額外掛 post_submitbox_misc_actions 之類的鉤子處理，自己純手刻的工程量不小。

對不想碰程式碼的人，外掛是更務實的選擇。這類編輯流程外掛通常做幾件事：

• 提供現成的常用狀態（像是 Pitch 提案、In Progress 進行中、Approved 已核可），可以保留、改名或停用。
• 讓你拖拉排序，決定文章在工作流裡的前進順序。
• 可以指定哪個狀態當新文章的預設，不再被綁死在「草稿」。
• 文章狀態變動時，自動寄信通知指定的人或群組，省掉手動催稿。

外掛多半會把狀態分成兩區管理：發布前的主工作流（草稿、待審這些核心狀態加上你新增的），以及發布後的可見性狀態（已排程、已發布、私密發布）。其中草稿和待審是核心狀態，可以重新排序但不能刪除，因為 WordPress 的權限與投稿機制依賴它們。

要不要動用自訂狀態，取決於團隊規模。單人或兩三人的小團隊，原生五個狀態加一個約定好的「退回草稿」做法往往就夠；一旦審稿、校對、配圖分給不同人，且每個交接點都需要一眼可辨的狀態，再導入自訂狀態才划算。先別為了流程完整而堆一堆用不到的狀態，那只會讓選單變長、沒人記得每格的定義。

狀態管理最常見的幾個坑

做了狀態與看板，不代表就不會亂。實務上最常翻車的，是這幾個地方。

狀態語意沒講好，每個人理解不一樣。 同一個「草稿」，作者當「寫到一半」、編輯當「等我審」，交接就會漏。解法是把每個狀態的定義寫成一句話的內部約定，新人進來照著走，不靠默契。

草稿無限堆積，變成內容墳場。 後台躺著幾十篇半成品草稿，多半是因為沒有定期清理的習慣。建議定期掃一次草稿分頁，每篇做一個決定：排程上線、退回重寫、還是直接丟垃圾桶。讓「撰寫中」這一欄保持流動，而不是只進不出。

排程設了卻沒發出來。 前面提過，這多半是 WP-Cron 在低流量站沒被觸發，不是你設定錯。排了重要文章後，最好回頭確認狀態是不是真的從 future 翻成 publish，別讓一篇「以為上線了」的文章卡在排程裡好幾天。

待修沒有獨立位置，混進草稿堆。 退回修改的稿子如果直接丟回 draft，過幾天就跟全新草稿分不清。要嘛開個自訂狀態，要嘛在標題或備註加個明顯標記，讓「等我改」和「等我寫」分得開。

從找出每篇卡在哪、到讓稿子穩定地往發布推進，靠的不是更貴的工具，而是先把 WordPress 既有的草稿、待審、排程這些狀態定義清楚，再用一塊看板把它們攤在眼前。先用內建的五個狀態加列表篩選跑起來，等到交接點真的多到需要肉眼分辨，再考慮自訂狀態與視覺化外掛。下一步，打開你的後台文章列表，數數看「草稿」分頁現在躺著幾篇分不清階段的稿子——那個數字，就是你該開始管理狀態的理由。