先刪掉，再自動化：AI 不該加在不該存在的流程上

這幾年在企業內推 AI，有一個越來越強烈的觀察：

很多公司不是 AI 做得不夠快，而是太快把 AI 加到一個本來就不該存在的流程上。

第一個直覺：「哪一步可以放 AI？」

例如一個原本需要這樣跑的流程：

需求提出 → 多層確認 → 人工整理 → 開發 → 測試 → PR → 再確認

大家第一個直覺通常是：「哪一步可以放 AI？」

我以前也是這樣想。看到一條長長的流程，就開始找哪一段最耗人力、最適合自動化。AI 幫忙整理需求、幫忙寫測試、幫忙檢查 PR，每一段都省一點，加起來好像很可觀。

但現在反而會先問：這一步真的需要存在嗎？

馬斯克的五步驟

這其實很像 Elon Musk 提過的 5-step algorithm：

• 1. Question every requirement：先質疑需求，不要因為「以前都這樣做」就接受。
• 2. Delete the process：能刪掉的流程，先刪掉。如果沒有刪掉至少一些東西，通常代表還不夠積極。
• 3. Simplify：流程還存在，再把它簡化。
• 4. Accelerate：簡化之後，才值得加速。
• 5. Automate：最後一步，才是自動化。

這五步最反直覺的地方，是自動化被放在最後。我們在企業裡談 AI，通常是直接從第五步開始，跳過了前面四步。結果就是，把一個本來就有問題的流程，自動化得更快、更穩定，然後更難改。

「多層確認」就是一個很好的例子。多一層確認，通常是因為過去出過事，有人加了一道關卡。但多年之後，可能沒人記得當初為什麼要加，只知道「流程就是這樣」。這時候用 AI 加速這道確認，不如先問：這道確認還需要嗎？

放到 Agent 時代特別適用

我發現這套邏輯放到 Agent 時代特別適用。

舉例來說，工程開發流程可以從：

工程需求 → Coding → Unit Test → PR

進一步變成：

需求定義清楚 → Agent 自動拆 Task → Coding → Test → 修正 Fail → 建 PR → Engineer 只 Review 關鍵風險

注意這條新流程的第一步：需求定義清楚。這不是 AI 做的，而是人要做的，而且比以前更重要。因為 Agent 會非常認真地執行你給它的需求，如果需求是錯的，它也會非常認真地做錯。

而最後一步，Engineer 只 Review 關鍵風險，也代表工程師的角色變了：從寫程式的人，變成判斷風險、對結果負責的人。

分水嶺在這裡

真正的價值，不是「AI 幫工程師多寫 30% 的 Code」，而是重新思考：

• 哪些工作根本不需要人做？
• 哪些流程根本不需要存在？
• 哪些決策應該保留在人？

這也是現在看企業 AI Transformation 最大的分水嶺：

• 有些公司在做：AI + Existing Process
• 領先的公司開始做：Redesign the Process with AI

兩者看起來都叫 AI 導入，但最後產生的 Productivity、Cost Structure，甚至 Organization Design，可能完全不同。

前者是在舊房子裡裝新家電；後者是重新想這個房子要怎麼住。

最後

最好的 AI 專案，不是把現有流程自動化，而是先把不合理的流程刪掉，再讓 AI 接手剩下真正有價值的工作。

AI Transformation 最難的，從來不是模型，是我們願不願意「重新設計工作」本身。

而重新設計工作，第一步通常不是加東西，是敢刪東西。