当 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 在 Facebook 贴文里解释了 Skill 的演化：

「去年在 STR Network 做的议题分级流程图，原本用『影响范围 × 延续性 × 复杂度』交叉出三个级别来协助我们判断如何监管。然而『影响范围 × 延续性 × 复杂度』本身就过于抽象。我总想关于『诊断』的技巧，病人能描述的是感受，而医生的智慧是要如何从症状连结到病名再解决方案。」

换句话说，她在重写管理框架本身——不是让用户学会「影响范围 × 延续性 × 复杂度」这套词，而是直接让他们描述症状，由 Skill 把症状对应到该采取的开发模式。

Skill 不是工具，是公司治理写进 markdown 的版本。Sunny 自己的总结：「我在意的是，一个团队里的基础判断能不能有共识，一致性的同步率提高了，才能再去放大不同个人经验带来的观点。」

回应「无所畏惧的建造」一言，更多技术债，以及伴随而来的运维债，更重要的是从源头有架构、有意识地去检视新建系统的必要性。

四、跑在 Zeabur 上的几套系统

下面是萨泰尔娱乐在 Zeabur 上运行的产品与系统。一部分跑在 Zeabur 共享集群（自 2026-02-23 起不再开放），一部分透过 BYOS 接到他们的自有 GCP 主机上。

1. 礼宾系统 INVITI

INVITI 不是从写程序开始的，是处理公关票处理得很头痛的 CEO 特别助理 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。