AI 的導入與管理議題 —— 薩泰爾娛樂如何治理內部數位工具

「AI 不是科技題，而是管理題。」鄭晴元（Sunny）在 《商業周刊》第 1963 期 的專訪裡這麼說。

聽起來像顧問會議的標語，但在薩泰爾娛樂（STR Network），它是一個工程順序的描述——當大多數公司還在比較 ChatGPT、Cursor、n8n 哪個更強的時候，這位共同創辦人已經把問題顛倒過來：先把內部要管什麼定義清楚，工具才有意義。

這篇文章是薩泰爾在 Zeabur 上跑的幾個內部系統的盤點。但故事的順序——以及為什麼薩泰爾的工程節奏跟一般「新創跑得快」的印象不一樣——要從他們怎麼組織自己開始講起。

At a glance

一、薩泰爾如何落地 AI 等新工具的導入

薩泰爾娛樂是台灣以諷刺喜劇起家的內容製作公司，旗下節目包括《博恩夜夜秀》等。公司核心 DNA 是內容——企劃、編劇、製作、藝人經紀——技術部門嚴格說只有一個人，工程師小馮。

從 Zeabur 的視角看薩泰爾團隊的應用與導入，他們在建立內部系統以及使用工具上，跑得比同規模的內容公司快。並非團隊工程資源很多，是內部的角色分工很清楚：

共同創辦人 Sunny（鄭晴元） 負責 brief。她定義公司要管什麼、誰看得到什麼、權限怎麼分、新工具進來時用什麼框架接住——這層的判斷下放成一份 brief，往下交給執行者。

在 Sunny 交付的 brief 之後，小馮 把這些需求落地成跑得起來的系統。流程盤點跟工程實作不是接力賽，是兩個人坐在同一張桌前的對話——Sunny 寫出來的需求文件，小馮在實作時會回頭問「這個欄位真的需要這層權限嗎」，然後在 weekly brief 上和 Sunny 同步。

是「Sunny 的決策 + 小馮的實作」這個結構，讓每個新工具、新系統在進公司之前都先過一道濾網——而不是讓單一工程師同時承擔治理、設計、施工三件事，這正是所謂的「治理結構」、在薩泰爾早已行之多年，而多數中型公司在 AI 時代被工具淹沒的真正原因，就是缺乏這個結構。

給個具體場景，每一檔演出要保留 20 到 200 張不等的公關票，給董事會貴賓、給媒體、給業務合作對象、給經紀人脈，給每個重要關係人還有助理；一年要簽的合約、要追蹤的勞報單、要對的售票回報，跨進了 Google Sheet 撐不住的量級。

誰都知道要做流程、要建系統，在 pre AI 的時代、薩泰爾就已經在系統性地解決這個問題，對一間沒有技術部門的公司來說，下一個問題絕對不是「要用什麼 AI 工具」，而是「我們到底要管什麼」—— 在 ChatGPT 問世的 2022、甚至是更早的 GPT-3 時期，薩泰爾很早就在思考這個問題。

二、「管理債」在薩泰爾的三個層次

「管理債」這個詞 Sunny 在 《商業周刊》第 1963 期 的專訪裡用過，也是這篇文章的開場引述。她在跟 Zeabur 的訪談裡把這個詞拆得更具體——三個層次。

第一層：管理的定義要先於系統設計。

「管理的定義先出來之後，這些所謂的系統設計跟概念，它才有辦法長出來。」

她舉的具體例子是「帳本」這個內部概念——一個演出專案可以有兩本、三本帳本，每本帳本權限不一樣，最後都回歸到同一個專案。系統能不能做到這件事是工程問題；要做這件事，前提是因為公司管理層先把「薪資是個資、不能公開」、「劇組便當是任何助理都可以報的」這些規則定義清楚了，用工程的術語來說，就是將資料的權限給定義好。

沒有第一步，第二步無從做起。

第二層：每一次小修改都有溝通成本。

「你要增加一個標籤，你要增加一個狀態，你要增加一個使用者角色，你要增加一個使用的這個東西——它的成本很高，它的溝通成本很高。」

在試算表上隨手新增一欄是免費的；搬到系統之後，每一個欄位變動牽動的是工程人力、權限設計、後續維護、相關使用角色的訓練。把這條鏈打開來算清楚，算時間成本、也算人力資源，是薩泰爾決定「要不要做」之前必須做完的事——不是先讓工程師動手，再回頭收拾溝通殘局。

第三層：人走了系統就沒人接手。

Sunny 對於把系統（指的是下方 Jerry 開啟的禮賓系統 INVITI 專案）從 Google Sheet 搬遷到自己寫的工作網頁一事，持保守態度。她講得直接，順手丟了一個黑色玩笑（喜劇公司裡人人都會講笑話？）：

「假如我哪天出車禍死掉沒關係，可是小馮如果走的話，這整個東西（其他人）不知道，就是沒有人可以接手維護。其實一直到現在這個問題都還沒有解決。」

把流程系統化的同時也製造了新的依賴，而這條依賴落在唯一的工程師身上。「管理債」在這個層次的意思是：你還沒解掉「整套系統只有一個人懂」這條依賴之前，每一個新系統都是借更多的債。

這三層加起來，是「管理債」在薩泰爾的真實意思——不是用什麼工具的問題，而是把組織內部要管什麼、誰管什麼、誰看得到什麼，攤開、定義、追蹤清楚，再決定要不要把它做成系統，尤其在這樣一個「寫什麼都非常容易」的時代。

三、「技術債」是 Sunny 對 vibe coding 的直接擔心

薩泰爾完全不抗拒 AI 工具——相反，他們已經跑了一輪自動化、用 Gemini Embedding 接 RAG、Sunny 自己用 Claude Code 寫 Skill 框架。她擔心的是另一件事 ——新的 AI 管理問題。訪談快結束的時候她講得很直白：

「薩泰爾還好，營運與業務模式是穩定的。可是很多剛起步的公司，在近期的 AI 焦慮下、大家都會有一個衝刺的心態，想著要做很多東西出來，長在原本的產品服務上。我覺得最讓人痛苦的事情是，大家可能會做一百個類似的東西，但彼此基本上是重工的。一味地推 vibe coding，其實它會造成更大的效率問題——更多技術債，也伴隨而來的維運債。」

「若只是單純告訴 ChatGPT、Cursor，我需要一套系統，它只會給我很爛的東西，」小馮在《遠見雜誌》的訪談裡也這樣提到。

技術債跟維運債，是她在訪談裡直接點名的兩個風險。訪談結束隔天（4 月 2 日），她在 Facebook 公開發了一篇〈How to Read the Vibes〉，把這個擔心寫得更完整：

「我在意的一直都不是強調個體變得多強多厲害，但我對於可以再也不做哪些事感到很好奇；同時，我最深的恐懼就是大量建造之後，會變成更多違章建築的技術債和管理債。當大家對維修感到疲憊，而建造又很方便，我們對於『如何設計走得更久的框架』便會失去信念。」

「違章建築」——這是她對失控的 vibe coding 結果的具體形容。一句話之後她又加了一個轉折：

「但也請別誤會，我並非排斥建造，正是為了要無所顧忌的建造，才會需要管理的框架。」

她的回應是寫一套「Dev Diagnosis Skill」，已經以 Claude Code Skill 的形式公開在 GitHub 上。README 開頭「在動手之前，先辨識價值」接著一句尖銳的「高效率生產垃圾還是垃圾。」

這個 Skill 把需求進來的處理拆成四階段——診斷 → 選解法 → 分級管理 → 落地。Sunny 在臉書貼文裡解釋了 Skill 的演化：

「去年在 STR Network 做的議題分級流程圖，原本用『影響範圍 × 延續性 × 複雜度』交叉出三個級別來協助我們判斷如何監管。然而『影響範圍 × 延續性 × 複雜度』本身就過於抽象。我總想關於『診斷』的技巧，病人能描述的是感受，而醫生的智慧是要如何從症狀連結到病名再解決方案。」

換句話說，她在重寫管理框架本身——不是讓使用者學會「影響範圍 × 延續性 × 複雜度」這套詞，而是直接讓他們描述症狀，由 Skill 把症狀對應到該採取的開發模式。

Skill 不是工具，是公司治理寫進 markdown 的版本。Sunny 自己的總結：「我在意的是，一個團隊裡的基礎判斷能不能有共識，一致性的同步率提高了，才能再去放大不同個人經驗帶來的觀點。」

回應無所畏懼的建造一言，更多技術債，以及伴隨而來的維運債，更重要的是從源頭有架構、有意識地去檢視新建系統的必要性。

四、跑在 Zeabur 上的幾個系統

下面是薩泰爾娛樂在 Zeabur 上運行的產品與系統。一部分跑在 Zeabur 共享叢集（自 2026-02-23 起不再開放），一部分透過 BYOS 接到他們的自有 GCP 主機上。

1. 禮賓系統 INVITI

INVITI 不是從寫程式開始的，是處理公關票處理得很頭痛的執行長特助 Jerry 花一個月做的盤點開始的。

如開頭所述，薩泰爾每一檔演出根據不同規模，要保留 20 到 200 張公關票，給董事會貴賓、媒體名單、業務的合作對象、經紀負責的媒體名單。每張票背後是一個關係人，每個關係人還有助理——資料量很快就撐破單張 Google Sheet 能負載的量。

Sunny 和小馮在訪談裡分享 Jerry 做的事：「前面大概花了一個月的時間，盤點他自己走過整個禮賓邀請的流程。」那是把禮賓邀請的完整流程畫成一份「角色對應表」文件——誰邀請誰、什麼角色看得到什麼欄位、票種怎麼分類、每一個環節要做什麼。這份文件不是系統架構圖，是現實生活中的流程。

接著小馮花一個半月，把資料庫加前端做出來。對 Zeabur 在這個系統裡扮演的角色、是內製化的推手，他的描述很直接：

「Zeabur 在這塊最大的幫助，是 Postgres 的一鍵部署。在這之前我們幾乎沒有部署除了 BigQuery 或是 Google 上面的資料部署外的方案，而 Zeabur 上一鍵開起來的 Postgres，讓我本地測試很方便。我覺得這讓我在不上雲測試時，成本降低非常多。」

2. 營運系統——把公司所有數字、流程收進來的內部中臺

「整個東西是部署在 Zeabur 上面的」小馮在訪談裡重複了四次，他指的是內部的中臺——薩泰爾的營運系統，管報帳、勞報單、售票成效的回報、專案列表。「公司裡面的數字都有在收集，全部都集中在這個網站。」

技術架構其實是一整套 web 的應用：Django + Celery 應用層、PostgreSQL 資料層、Redis 跑 Worker 跟背景作業、django-celery-beat 處理定時任務、Nginx 反向代理。小馮提到自己當初「沒刻意往微服務的方向實作，但回頭發現已經有雛形了」——服務分散、各自跑、彼此隔離。當然，這離嚴格意義上要獨立資料庫、獨立部署的微服務還有距離（Zeabur 的後端工程師 Pan 在 SITCON 2025 分享過微服務的定義與實作）；薩泰爾正在持續迭代系統，下一階段是漸進式把服務給隔離好——降低相依風險之外，也能進一步改善開發效率：

「理想上是這個服務佈在這個主機，然後另一個服務佈在另一個主機。」

然而，營運系統真正困難的不是技術組成、是權限。

Sunny 提到一場大型演出的團隊組成本質是外包協作，活動現場大部分人不是正職員工，每個人能看到哪些帳本、哪些專案、哪些薪資資料，要嚴格分流。系統用 RBAC 處理，但 Sunny 在先前訪談裡點明前提：「管理的定義先出來之後，然後這些所謂的就是系統的設計跟概念，它才有辦法長出來。」

薩泰爾在專案管理上設計的「帳本」概念 —— 一個專案可以有兩本、三本帳本，每本帳本權限不同，最後都會回歸到同一個專案。這本質上就是資訊安全領域裡的「最低權限原則（Principle of Least Privilege, PoLP）」—— 每個角色只看得到完成工作所必需的那本帳，不多給。

這套機制的設計目的，是讓外包人員也能順利進系統幫正職做準備：「這是我們的內部工具，但它不能只有內部人用。如果只有內部人用的話，它會遇到瓶頸，仍會受限於內部團隊的產能」Sunny 這樣補充道。

這是對外，同樣的管理邏輯拉回內部，一本帳本在內部、真的是所有成員都有必要、需要去瀏覽嗎？答案很明顯，但當涉及更負責的內部權責歸屬，如何落地是更進階的挑戰。

從外到內的權限、從使用者端到底層架構的隔離，兩者交織而成的便是企業在導入 AI 後下一步會遇到的管理問題，而薩泰爾解決了最前段的導入，現在正在透過系統本身的更新，回過頭來去推著管理框架的迭代。

3. 總務 Slack Bot RAG

這套系統訪談前一天才剛部署。

薩泰爾內部有個叫「#help-總務」的 Slack 頻道，同仁在裡面問：Wi-Fi 密碼、公司帳號密碼、會議室預約、到薩泰爾的公車搭幾號。原本是用 Apps Script 寫的關鍵字比對 bot，後端資料庫是 Google Sheet——欄位對不上就答不出，同一個問題甚至會觸發兩三次重複回覆。

小馮整套搬到 Zeabur 上做：Gemini Embedding 2 API（2026 年 3 月 10 日釋出）做語意向量、PG Vector 模板（Zeabur 一鍵開）存向量、Python FastAPI 當後端。關於上線時機，他的解釋反映了薩泰爾的工程節奏：

「跟模型沒有什麼關係。剛好 3 月 10 號 Gemini Embedding 2 API 發布，然後它就留在我的待辦清單。它本來就會動，只是它本來是用關鍵字去出發的，沒有 LLM 的成分在裡面。」

不是模型發布就馬上做，是這個需求一直留在待辦清單，新工具讓它優先序終於排到。對 Zeabur 的角色，小馮形容：「Zeabur 的關係其實就是，它要部署變得容易。因為我們原本是用 Apps Script 去跑它的，就像 LINE 後端的感覺。現在相當於是把 FastAPI 包起來，在 Zeabur 上面跑。」

RAG 也有自我迭代機制：當系統查不到答案時，會反查為什麼查不到、做語意判定、把案例補進資料庫，小馮強調這個跑一段時間後才會「越來越聰明」。

五、這幾套系統如何運行在 Zeabur 上？

把上面這幾個系統的需求疊起來，Zeabur 之於薩泰爾的角色就清楚了——它不是取代維運團隊，而是重新想像「把系統部署上線、穩定跑著」這件事該怎麼做：讓團隊現有的夥伴、搭配 Zeabur Agent 輔助，做到原本需要一整個維運團隊才扛得起的事。

在薩泰爾，技術團隊就是小馮一個人——他因此一個人就管得動好幾套上線的系統、不用細究它們跑在哪種主機上，也不必為了「把東西部署上線」、「確保系統穩定、半夜不出事」、「顧好資料庫的備份跟效能」各請一個專職的人，而是透過 Zeabur 的三項功能來進行運維：

• 一鍵部署模板： INVITI 的起點是 Postgres，總部 RAG Bot 的起點是 PG Vector，工作網頁靠 Postgres 跟 Redis 撐。小馮形容這降低了「本地測試 vs 雲端測試」的成本差——對一個人撐全端的工程師來說，這直接決定迭代與測試新想法的速度。
• 混合雲管理： 部分核心生產跑在自己的 GCP 伺服器上，部署、監控、日誌都走 Zeabur 介面，同時部分的資源則是部署於透過 Zeabur 購買的其他資源上。伺服器資源是混合的（甚至薩泰爾有地端 Mac 機臺、也有在考慮綁上 Zeabur 做管理），運維介面是同一個。
• 統一抽象層： 光營運系統就有六個服務（Django、Celery、Redis、Postgres、Nginx、django-celery-beat）；加上 INVITI、總部 RAG Bot 等跑在 GCP 上核心系統——在同一個 Zeabur 介面看完所有服務的健康狀態，可視化統一管理。

當然，對本來就有人專門顧技術底層的團隊，Zeabur 則讓同一群人把維運做得更快、更省力，把省下來的精力放回更需要領域專業判斷的事情上——迭代產品架構、確保資安合規、規劃系統未來怎麼長更大。

六、回到「AI 導入不是科技題」

「AI 導入不是科技題，而是管理題」這句話的意思，不是 AI 不重要。

它的意思是：AI 之前要先有完整的資源與流程盤點（甚至是已經累積經年的內部資料源），且經過 Sunny 反覆審視才寫得進系統的評判流程，更要有對每一次小修改的溝通成本的精算，薩泰爾是這樣處理 AI 導入的兩大難題的——管理債、技術債：

底層的管理債以及伴生的技術債，表面看起來像技術混亂的東西——架構太雜、服務太多、寫得越快爆得越快——根本上都是「管理系統沒定義好」的鍋。薩泰爾用兩個東西解決這項根因：

• 第一節跟第二節講的「Sunny brief × Jerry × 小馮」三人治理結構，加上帳本與 RBAC 權限模型，組織層級從很早就把要管什麼、誰管什麼、誰看得到什麼界定清楚。
• Sunny 最近寫的 Dev Diagnosis Skill，每個需求進來時做一次診斷——表面看起來像技術問題、底下其實是管理沒定義清楚的，當場攔下來，避免「違章建築」式的重複造輪。

當底層管理債還掉、需求結構清楚之後，剩下的就是「維運」，把系統跑起來、跑穩定。這層由 Zeabur Agent 處理——把 Postgres 一鍵開、把 FastAPI 一鍵推上線、把服務從一台主機調度到另一台，所有服務的狀態收進同一個介面。

底層還有下一道題在等：當系統長到多人協作、多主機、多環境的時候，誰可以訪問哪台主機、誰能改哪個服務、誰看得到哪段日誌——這是因技術而生的管理需求，是薩泰爾接下來正透過 Zeabur 釐清與辯證的挑戰。

工具的部分、AI 時代下一直在變——從 Apps Script 到 FastAPI、從關鍵字比對到 RAG、從共享叢集到 BYOS——但底下的盤點邏輯沒變。

「AI 不是科技題，而是管理題」Sunny 是這樣說。

引用文獻

• 何佩珊、陳盈螢（2025-06-26）。〈AI 先鋒薩泰爾為何不停打掉重練？做 AI，先理好你的「管理債」〉。《商業周刊》第 1963 期。
• 曾子軒（2025-02-27）。〈《博恩夜夜秀》幕後功臣：薩泰爾團隊 AI 神用法，如何讓全員升級？〉。《遠見雜誌》。
• 鄭晴元（2026-04-02）。〈How to Read the Vibes〉。Facebook 公開貼文 + GitHub repository mseatingtpe/dev-diagnosis-skill。
• Yuanlin Lin（2026-02-23）。〈共享叢集將不再開放新專案〉。Zeabur Changelog。