把 AI 工作流導入公司營運

01 一個產品有兩端，我兩端都跑過

用 AI agent 工作流可以做兩件很不一樣的事：一端是創造——從零生出一個新東西（這是 Beat Slash 做的）；另一端是營運——讓已經在發生的重複瑣事自己跑下去，不再吃人力。

這一頁講的是營運端。同一套「人做判斷、AI 做執行」的思路，這次不是拿來生新東西，而是接進公司每天都在發生的營運流程裡。把這兩端合起來，就是我想證明的事：我用 AI 工作流跑過一個產品的上下游，不只會做 demo，也讓它在真實組織裡持續運轉。

同一套思路，用在兩端——我都跑過。

創造端 · Beat Slash

從零生出一個新原型
目標是「快速驗證一個想法」
一次性、做完就驗證
可公開展示

營運端 · 公司工作流

讓重複的瑣事自己跑
目標是「持續省下人力」
每天運行、要穩、要被信任
綁公司內部，只談形狀

多數人會做其中一端。能把同一套思路用在兩端——既能從零做出新東西，又能讓它在組織日常裡長期運轉——才是「用 AI 跑完一個產品生命週期」真正的意思。

02 我在公司設計的幾條工作流

不只一條。同一套「人做判斷、AI 做執行」的思路，我把它接到公司營運的不同環節——會議、設計、企劃文件。下面是這幾條工作流的「形狀」（不含任何公司實際內容、畫面或演算法）：

會議錄音 → 會議記錄 → 知識庫

把一段會議錄音，自動轉文字、整理成格式統一的記錄，再歸進公司知識庫、跟相關主題連起來。同事只要丟錄音，最後看一眼確認。

解決開完會還要手動整理、貼上、歸檔的重複工。

Figma 設計稿 → Unity

設計師在 Figma 畫好的介面，自動轉成 Unity 引擎裡能用的東西，工程師不用照著設計稿一個個手刻。設計改了，重跑一次就好。

解決設計到實作之間，反覆手工搬運、容易跑掉的那段。

知識庫文件 → 試算表 / HTML 企劃書

同一份知識庫裡的內容，自動派生成不同格式的交付物——整理成試算表給人篩選排序，或排成一份 HTML 企劃書直接拿去報。寫一次，多種輸出。

解決同樣的內容，為了不同場合一再重排、重做版面。

三條工作流，環節完全不同（會議、設計、文件），但骨架是同一個：把重複的轉換和搬運交給 AI，人只在關鍵處做判斷。能在一個組織的多個地方都布上這種流程，才是「把 AI 導入營運」真正的樣子——不是一個亮點功能，是一張網。

03 導入「組織」跟做給「自己」差在哪

把這套接進公司，難的從來不是技術，是這些：別人願不願意用（它得比原本的做法更省事，不然沒人理）、信不信得過（出錯了怎麼辦、誰負責看那一眼）、融不融得進既有流程（不能要大家為了它改變所有習慣）。這些判斷，跟「做一個自己用的腳本」完全是兩回事——而這正是把 AI 落地到真實組織，最值錢的部分。

這個工作流幫我證明的三件事：

主張 01 我能把 AI 落地到真實組織的營運，不只做 demo。 這套工作流在現職公司每天都在跑，不是躺在 GitHub 上的 side project。「能跑一次」和「天天有人用、出錯有人扛」是兩個世界，我做的是後者。

主張 02 我設計的工作流，把判斷留給人。 AI 做所有搬運、轉換、整理，人只在最後確認一眼。我不追求「全自動」這種好看但危險的東西——該由人把關的地方，我刻意留一個關卡。