鄭晴元：以柔制剛：從混沌走向脈絡

1. 一句話總結

薩泰爾娛樂共同創辦人鄭晴元從「macro、micro、management」三個尺度，拆解一間四十人娛樂公司在缺乏產業專用管理系統的前提下，怎麼用「人—機器」「機器—機器」的資訊節點盤點、領域驅動設計（DDD）與Mermaid流程圖，把口述經驗轉化成可以持續討論、可以交給AI參與的清晰結構。

2. 重點筆記

講者背景

鄭晴元是薩泰爾娛樂股份有限公司（英文對外名稱STR Network，取自「satire」諷刺一詞）的共同創辦人，公司成立於二〇一八年，是以線上喜劇《博恩夜夜秀》《炎上BURN》系列與線下喜劇專場為主要產品的內容公司（經查維基百科、遠見雜誌報導）。他負責公司的營運後台設計、知識系統梳理與AI工具整合。

他先回顧去年的分享：那場簡報去年累積約四萬次觀看，官方議程列出的講題是「與AI共同打造一個有機的管理『系統』」，他自己在台上則稱那次分享的英文標題是「Drafting and Crafting with Generative AI」——用一句話總結，就是他身為一個「麻瓜」學會Apps Script之後，重塑了公司合約開立、勞保單開立的邏輯，並試著打造一套帳務系統；那段導入歷程去年五月時還沒完成，到去年第四季才算完成。

三個尺度：macro、micro、management

他從「AI first」這個當下產業的流行語切入，指出Shopify、Duolingo都曾發表類似宣言：要開新職缺，得先證明這件事AI做不到，才會核准招募。他把這個問題拆成三個尺度來看：宏觀（macro）是科技巨頭持續狂飆帶來的焦慮感，每天都有新模型、新產品發表；中觀（micro）是娛樂業、表演藝術這類產業整體仍然相對傳統，管理方式很傳統，因為沒有一套屬於這個產業的ERP或管理系統可以直接套用（他半開玩笑地說，不然他也不用自己去處理勞保單的問題）；微觀落到management，則是薩泰爾娛樂自己的真實場景——回到自己能處理的範圍，世界的狂飆才會真的和自己有關。

他順帶自我調侃介紹了公司規模：薩泰爾娛樂是一間四十人的娛樂公司，主要產品是線上喜劇與線下喜劇製作，服務對象涵蓋一般觀眾、企業客戶與喜劇演員本身；核心能力在於體驗設計、品牌與節目企劃，以及怎麼用四十人的規模去調度整個喜劇產業的人才。他也提到當天晚上七點，薩泰爾娛樂在同一個場地另外安排了一場喜劇演出——經查，這場是《炎不由衷 Feat. Generative AI 年會》，由藍恩、壯壯、學仁三位演員演出。

從一個簡單問題看見資訊流動的複雜真相

他用「薩泰爾娛樂現在正在賣多少張票」這個看似簡單的問題示範複雜真相：公司同時有多場演出在賣票，不同售票系統的條件與API都不一樣，最土法煉鋼的做法是每天固定時間人工一個個開後台去填數字；但同一個問題背後，每個角色真正想問的其實不一樣——這跟大家平常用大型語言模型對話時，問題會不斷延伸下去是同一種現象。

他們因此盤點出三種協作節點：人與人之間需要口頭對焦（同一個名詞、同一個「專案」，大家講的是不是同一件事，這也是為什麼需要開場會議kick off meeting來對齊想像）；人與機器之間，他提出一個具體主張——跨組織溝通不要再用LINE工作，因為只要還在用LINE，自動化就很難推動；機器與機器之間，則是API介接要盡量順暢準確。他也點出人與機器的閱讀方式天生不同：人喜歡看圖、看表格、看摘要，機器要看的卻是攤平（unpivot）後一列一列的原始資料，同一份資料在不同情境下，使用者真正想看的呈現方式也不一樣——例如主管平常想看彙總後的中間層級表格，但只是想在午餐時間隨口確認一下售票狀況時，連看表格都嫌麻煩。

把票務設定轉成schema：DDD與Mermaid的實際做法

具體案例是票價和票區的設定：把後台設定畫面截圖丟給大型語言模型，請它轉換成資料庫需要的schema（每個票區的ID、票區設定等），再用這份schema去跟票務系統對接溝通。這套做法背後，是薩泰爾娛樂過去三個月左右嘗試導入的框架——領域驅動設計（DDD），把口述的、有機的經驗訪談內容，轉化成可以持續討論、繼續工作的清晰結構。

他坦言自己已經很難做第一線執行，設計出來的流程常常跟第一線實際操作對不上，所以必須靠大量訪談（有時候只是在茶水間隨口問一兩個問題，或請同仁丟一兩份文件過來）去理解第一線執行時真正依賴的思路。訪談內容會先用手繪、白板加便利貼的方式展開，再轉成Mermaid語法的流程圖——因為Mermaid同時滿足機器可讀（文字語法）與人類可讀（渲染出來的流程圖）兩種需求。他們其實從二〇二一、二〇二二年左右就開始用Mermaid畫各種流程圖（包括分析合約架構），這次新的體會是還可以進一步用AI協助把手繪流程圖轉成Mermaid語法，他也在簡報裡附了一個可以直接嘗試的GPTs工具連結，讓人把流程手稿拍照上傳、自動轉出Mermaid語法。目標是得到一份清晰的業務流程圖、統一的領域用語（例如「貴賓」「邀請人」「代表人」這類第一線同仁才懂、但管理者未必知道的用詞）與關鍵事件定義；他的心得是，當語境被看見、語言被定義之後，技術才有落點。

真正的議題不是生產力，而是損耗

他認為現在真正該問的問題不是「能不能生更多產出」，而是「能不能減少損耗」。他毫不掩飾地說，自己很不喜歡那種AI生成的說故事式內容——「你對整個環境是沒有責任的」；回到自己的工作場域，他也常被夥伴挑戰「這個數據分析真的有意義嗎」，如果一件事不會促進任何改變，那就不要做。他給的簡單判準是：這個行為的下一步會不會影響誰，如果不會造成任何正面影響，那就不要做，這也是他保護自己有限精力的方式之一。

他把節點的損耗也分成三類：人與人之間有理解落差（例如「票賣得怎麼樣」，問的人可能想知道的是張數，答的人卻在講營收，而不同票價的填座率原本就不一樣）；人與機器之間會有操作障礙；機器與機器則相對單純。他重申真正的目的是協作，不是生產力本身。

議題分級：框架由上而下，解法由下而上

他提到公司雖然有專門團隊協助盤點議題，但真正想擴散的對象是整個組織，而不是所有問題都值得投入百分之百的力氣。他歸納出一套三個級別的分工原則：級別一是個人開發，公司提供AI軟體補助，同仁想怎麼開發都不干涉，也不管產出用途，目前已經有不少Slack流程自動化就是這樣長出來的；級別二是依規範開發，規範是由管理層定義部門與部門之間協作要用的共同語言，同仁依規範開發完成後，團隊會協助把資料庫之間可以關聯的部分再做調整；級別三則是由團隊主導開發，通常涉及比較複雜的資料串接，需要進一步評估是否要做出一個好的前端介面——他認為當流程涉及全線管理、步驟與情境都很複雜時，把規範定下來、按照流程走，其實對執行的人反而更好做事，不是每件事都需要那麼多自由。他希望最終形成一個正向循環：由上而下提供清晰的語言，由下而上長出解法。

這一年的轉變：從drafting走向crafting

去年他把整體歷程比喻成戲劇曲線；今年他認為自己是在收尾drafting（草擬）的部分，開始走向crafting（精修）——把去年拆解完的流程，逐步變成比較站得住腳的頁面與做法。不變的是「make it fun」，捨棄的是對導入速度的追求，轉而更專注在拆解場域細節，並且對任何前端形式（無論是Slack、網頁或App）都保持彈性，隨時準備好用同一份資料去搭配不同的前端。

結尾呼應

他在結尾提到，如果薩泰爾娛樂也要發一篇「AI first」新聞稿，他不會強調AI如何取代人，而是想強調AI如何賦能組織裡的人才，讓由下而上的貢獻被看見。他也分享自己過去半年花了很多時間讀小說，體悟到像《哈利波特》這樣的故事之所以讓人記得住細節，是因為創造了完整的世界觀——他認為這跟「魔法要能被想像出來才管理得了細節」是同一回事，因此鼓勵大家在追求效率之外，也重新感受文學的美好。最後他把整場收在對同一天稍早李怡志老師分享內容的呼應上：他說，這也像是在回應李怡志講的——你要怎麼樣為通過自己的訊息負責、為自己創造的訊息負責，不要帶著太多情緒去招惹整個世界（詳見「李怡志：如何生成有效的圖騙」）。

3. 關鍵數據與案例

4. 金句

• 「當你整個語境被看見了，你的語言被定義了之後，你的這些科技它才有落點。」
• 「真正的議題其實不是生產力，而是損耗。」
• 「這個行為的下一步會影響誰？如果不會造成任何正面的影響，那就不要做。」
• 「讓框架由上而下，讓解法由下而上。」

5. 提到的工具與名詞

• DDD（領域驅動設計，Domain-Driven Design）：把口述經驗轉化成清晰結構的方法框架
• Mermaid：兼顧機器可讀與人類可讀的流程圖語法，團隊自二〇二一、二〇二二年起使用
• schema：票務系統資料結構化後的欄位定義
• GPTs：講者提到可以把手繪流程圖轉成Mermaid語法的工具
• Apps Script：去年分享中重塑公司合約與帳務邏輯所用的工具

6. 延伸觀察

這場最特別的地方是幾乎沒有秀任何AI生成結果，反而花最多時間在講「怎麼把一群人腦中的口述經驗，變成一份大家都認得的schema」。這跟同一天張志祺那場（簡訊設計）其實骨子裡在講同一件事——AI能不能真的落地，不是看模型多強，而是看組織有沒有把自己的語言與流程定義清楚；只是張志祺從「體驗設計」切入，鄭晴元從「領域驅動設計與治理分級」切入，兩條路徑殊途同歸。

他讓LINE群組退場、改用結構化資料溝通的堅持，對照「機器要看攤平資料、人要看樞紐表格」這句話，其實點出很多組織導入AI卡關的原因，不是模型能力不夠，而是資料呈現的形式，從一開始就沒有替兩種使用者分開設計。

7. 資料來源