為什麼工作流要「先設計再自動化」：把爛流程自動化，只會更快地產生爛結果

當一個團隊決定要「導入自動化」時，最常見也最危險的衝動，就是直接拿現在手上那套天天在跑的流程，原封不動地交給工具去自動執行，想著「反正它本來就這樣跑，自動化只是讓它跑更快」。問題是，自動化從來不會修正流程，它只會忠實地放大流程的本質。如果你交給它的是一套清晰、職責分明、每一步都有理由的流程，自動化會讓它又快又穩；但如果你交給它的是一套到處是例外、補丁與口耳相傳潛規則的爛流程，自動化只會讓你更快、更大量地產出爛結果，而且因為跑得太快，你連踩煞車檢查的機會都沒有。這篇文章站在要為產出負責的業務角度，講清楚為什麼順序一定是「先設計、再自動化」，以及該怎麼在按下自動化按鈕之前，把流程先理乾淨。

一、自動化是放大器，不是修理工

理解這件事，最簡單的方式是記住一句話：自動化是放大器，不是修理工。它不會在執行的過程中幫你發現「這步好像沒必要」或「這個判斷其實會出錯」，它只會把你給它的每一步，照原樣、用更高的速度與頻率重複下去。所以同一個自動化動作，套在好流程跟爛流程上，會得到方向完全相反的結果。

                 ┌────────────────────┐
                 │      自動化（放大器）  │
                 └─────────┬──────────┘
            ┌──────────────┴──────────────┐
            ▼                              ▼
   ┌────────────────┐            ┌────────────────┐
   │  輸入：好流程     │            │  輸入：爛流程     │
   │  清晰 / 職責分明  │            │  到處例外 / 補丁  │
   └───────┬────────┘            └───────┬────────┘
           ▼                             ▼
   ┌────────────────┐            ┌────────────────┐
   │ 又快又穩         │            │ 更快地產出爛結果  │
   │ 規模化的好結果    │            │ 規模化的災難     │
   └────────────────┘            └────────────────┘

這張對照圖想凸顯的是：放大器本身是中性的，它把好的放大成更好，也把壞的放大成更壞。所以真正決定自動化成敗的，從來不是工具多強，而是你餵進去的那套流程，本身到底是經得起放大，還是一放大就現形。先把這個觀念立穩，後面所有的紀律才有意義。

二、「直接自動化爛流程」會付出哪些加倍代價

很多人以為，就算流程沒那麼完美，先自動化起來總比手動快。但實際上，把爛流程自動化，付出的代價往往是加倍的，因為你不只承擔了原本流程的問題，還額外承擔了「把問題規模化、並讓它更難被發現」的新問題。我自製了一張對照表，把「先設計再自動化」與「直接自動化爛流程」這兩條路，在幾個關鍵面向上的差別攤開來看：

這張表最該被記住的一列是「改起來的成本」。流程在還是一張設計圖的時候，你要拿掉一個多餘步驟、修正一個錯誤判斷，成本只是橡皮擦；但一旦它被自動化、跑進真實業務、和其他系統綁在一起之後，再要回頭動它，動的就不只是那一步，而是一整串依賴它的東西。順序錯了，你等於是把最便宜的修改時機白白跳過，去換一個最昂貴的修改處境。

三、好流程跟爛流程的差別，往往不在步驟，而在「為什麼」

要在自動化之前先把流程理乾淨，得先知道「乾淨」長什麼樣。一個值得被自動化的流程，特徵不是步驟少，而是每一步都答得出「為什麼存在」。相對地，爛流程的典型症狀，是裡面塞滿了沒有人說得清來由的步驟——可能是某次出包後加的補丁、某個離職同事的習慣、或是「以前都這樣做」的歷史遺留。這些步驟在手動時還有人會臨機應變地跳過或調整，但一旦自動化，它們就會被當成神聖不可違背的規則，一絲不苟地永遠執行下去。

所以「設計」這個動作的核心，不是把流程畫得更漂亮，而是逐步去質問每一個步驟：它解決了什麼問題？如果拿掉會怎樣？它真的還需要嗎？這個質問的過程，往往會讓一條看似複雜的流程瘦下一大圈，而瘦下來之後的版本，才是真正值得交給自動化去放大的東西。

四、用一段流程梳理 Prompt，逼出每一步存在的理由

要做這種質問，你可以借助一段流程梳理 Prompt，把你現有流程的每一步丟給它，逼它幫你逐步檢視、找出可疑的環節，再由你定奪。這段 Prompt 不是要它替你決定，而是要它把「該被質問的點」一個個攤出來，讓你在自動化之前先看清楚：

我會提供一個目前手動在跑的工作流程，請依下列方式幫我做「自動化前的設計檢視」，逐步輸出：

1. 步驟拆解：把流程拆成清楚的步驟，每步一行，標出「輸入 → 動作 → 輸出」。
2. 存在理由質問：對每一步，提出一個問題「這步解決了什麼問題？拿掉會怎樣？」，並標記你判斷它是「必要 / 可疑 / 疑似多餘」。
3. 例外與補丁標示：指出哪些步驟看起來像是為了處理特例或歷史遺留而加的補丁，這些最不該被原樣自動化。
4. 判斷依賴：標出哪些步驟包含「需要人判斷」的環節，這些在自動化前必須先把判斷規則寫清楚，否則會被亂自動化。
5. 精簡建議：在不改變最終目的的前提下，提出一個更乾淨的步驟版本，並說明你拿掉了什麼、為什麼。

只做檢視與建議，不要替我做最終決定。

跑完這段，你手上會多出一份「哪些步驟其實可疑、哪些判斷還沒講清楚」的清單。這份清單就是你的設計工作底稿——把上面的可疑與多餘處理乾淨，再來談自動化才有意義。這段 Prompt 不含框線字元，是一段乾淨的可用工具。

五、導入 SOP：先設計、再自動化的正確順序

把觀念落到可執行的步驟上，「先設計再自動化」其實是一套有明確先後的紀律。以下這套順序，可以直接套用在你下一個想自動化的流程上：

第一步，畫出現況流程。先誠實地把現在實際在跑的版本畫出來，不是畫「應該長怎樣」，而是畫「真的怎麼跑」，包含那些大家心照不宣的繞道與補丁。第二步，質問每一步的存在理由。拿上一節那段梳理 Prompt 或自己逐步問，把每一步標成必要、可疑、疑似多餘三類。第三步，先把流程改乾淨。在還沒碰任何自動化工具之前，先把可疑與多餘的步驟處理掉，把需要人判斷的環節規則寫清楚，產出一版「設計定稿」。第四步，挑一小段先自動化試跑。不要一次自動化整條線，先挑風險低、邊界清楚的一小段，驗證自動化後的結果跟設計定稿一致。第五步，確認穩定後再逐段擴大。等小段穩了，再依序把其他段落接上來，每接一段都回頭確認它放大的是好結果而不是壞結果。

這套順序的精神很單純：把最便宜、最容易改的「設計階段」用好用滿，等流程真的乾淨了，再讓自動化這個放大器上場。

六、設想情境：先自動化、再後悔的對帳流程

設想一個情境，幫你把順序的重要性對到實際工作。某個團隊覺得每月對帳太花時間，決定直接把現有的對帳流程自動化。問題是，這套流程裡藏了好幾個「老同事才知道」的手動修正——某些特殊客戶要套用不同規則、某幾筆款項要人工跳過。手動時，這些特例都靠人腦臨場處理，從來沒被寫下來。一旦自動化，工具不知道這些特例的存在，於是它非常有效率地、每個月都把這些特例用錯誤的方式處理一遍，而且因為報表跑得又快又整齊，沒有人會懷疑它哪裡不對，直到季底才發現帳對不起來。

這個設想情境（非真實公司、非真實數據）想說的是：他們跳過的不是技術，而是「設計」這一步。如果在自動化之前，先用梳理流程的方式逼出那幾個「需要人判斷的特例」並把規則寫清楚，這條自動化就會是放大一套乾淨流程；但因為順序倒過來，他們等於是花錢買了一台高速產出錯誤的機器。順序錯了，工具愈強，反而摔得愈重。

七、ROI 評估：別只算自動化省下的工時，要扣掉爛流程被放大的損失

替自動化算 ROI 時，大多數人只算一邊：自動化之後，每個月省下多少人工時。但如果你是把一套還沒設計乾淨的流程直接自動化，這個算法會嚴重高估收益，因為它完全沒有把另一邊——爛流程被放大後產生的錯誤、重工、與信任損失——扣回去。真實的 ROI，應該是「自動化省下的工時」減去「被規模化的流程缺陷所造成的損失」，而當流程本身有問題時，後面這一項很可能大到把前面的節省整個吃掉，甚至變成負的。

所以更聰明的算法，是把這筆帳分成兩種情境來對照：一種是「先花時間把流程設計乾淨、再自動化」，另一種是「直接自動化現況」。把兩者各自的預估省時、預估出錯成本、預估修改成本帶進站內的自動化效益計算機與 AI ROI 計算機，分別跑一遍再相減，你會很清楚地看到，前期花在設計上的那段時間，並不是成本，而是一筆把後期災難擋下來的投資。當你把這兩條路的數字並排看時，「要不要先設計」就不再是一個拖慢進度的問題，而是一個關於你想要哪一種長期結果的選擇。

❓ 讀完後，先問自己這幾個問題

第一，你打算自動化的這條流程，現在每一步你都答得出「為什麼存在」嗎？　引導思路：如果有幾步你只答得出「以前都這樣」，那它們很可能就是不該被原樣放大的補丁，先把它們質問清楚再說。

第二，這條流程裡有沒有「老同事才知道」的特例或人工修正，從來沒被寫下來？　引導思路：這些沒被寫下來的判斷，正是自動化最容易踩爛的地雷；自動化之前，先把它們攤出來變成明文規則。

第三，你現在是想「先設計再自動化」，還是只是急著把現況原樣加速？　引導思路：誠實回答這題，你就會知道自己接下來要打造的，是一套規模化好結果的系統，還是一台高速產出問題的機器。

結語：先把流程理乾淨，自動化才會站在你這邊

自動化本身沒有對錯，它只是忠實地放大你交給它的流程。把一套清晰、職責分明、每一步都有理由的流程交給它，它會替你把好結果規模化；把一套滿是例外與補丁的爛流程交給它，它只會更快、更大量地把問題攤在你面前。差別不在工具，而在順序——願不願意在按下自動化之前，先花那段看似拖慢進度、實則最划算的時間，把流程質問乾淨。先設計、再自動化，不是流程上的講究，而是決定這套系統未來是替你省事、還是替你製造災難的分水嶺。