Product archive / Case study

海外短剧项目经理

为海外短剧项目设计生产侧与审核侧双工作台,在保护商业边界与方法资产的同时,让素材、意见和修改状态持续回流。

01项目名称
海外短剧项目与三方协作工作台
02我的角色
项目负责人|协作流程设计与工具搭建
03项目周期
2026.06,约半个多月
04协作规模
约 10-12 人跨组织协作
案例目录

01三方协作带来的信息落差

该海外短剧制作项目的协作关系同时包含委托方、项目管理方和制作执行方。三方关注点并不相同:委托方需要快速判断角色、场景和成片方向;制作团队需要掌握剧本、资产、提示词、生成版本和修改任务;项目管理方需要让进度与问题在两端持续同步。

01

委托方

聚焦可判断的角色、场景、声音和画面结果。

02

项目管理方

理解需求、推动进度,并把意见转换为执行任务。

03

制作执行方

管理剧本拆解、生产资产、提示词和迭代版本。

02为什么不能只做一张共享表

如果把全部生产信息放进同一张表,审核方需要在大量内部字段中寻找可判断内容,制作方的生产过程也会失去必要边界;如果完全依赖群聊,素材、意见和版本又会迅速脱离上下文。

核心问题不是“有没有表格”,而是如何在实时同步、商业边界、方法资产保护和执行效率之间建立清楚的信息分层。

因此我没有继续堆字段,而是把协作拆成甲方审核台和制作方协作台。两端分别服务不同决策,却通过关联记录与自动化保持同一条生产链路。

03双工作台承担不同任务

已脱敏的海外短剧甲方审核工作台
甲方审核台:围绕角色与场景资产呈现原文依据、审核图、声音参考和反馈状态。
已脱敏的海外短剧制作方协作工作台
制作方协作台:围绕场景资产、出现集数、复用规则、提示词和初稿组织生产。

审核台只保留足够做判断的信息,制作台则保留完成执行所需的上下文。同一项资产在两端拥有不同的信息密度,既减少审核负担,也避免内部生产方法被无差别展开。

04用飞书原生能力建立反馈闭环

工作台完全使用飞书原生能力搭建,没有引入云函数、外部脚本或自建接口。字段捷径帮助成员快速发起操作,关联记录与 Lookup 维持两端数据关系,自动化负责状态和意见流转。

FIELD

字段捷径

将常用提交、审核和更新动作收敛为明确入口。

RELATION

关联记录

让角色、场景、集数和版本保持可追溯关系。

LOOKUP

信息引用

按协作对象提取必要字段,控制两端信息密度。

AUTOMATION

自动化回流

审核状态变化后,将意见同步回对应制作任务。

双工作台闭环:生产提交到修改更新 生产提交 01 甲方审核 02 意见回流 03 修改更新 04
Diagram双工作台闭环:生产提交到修改更新

05结果、职责与复盘

半个多月完成协作搭建与首集推进

10-12 人跨组织协作规模

约 5 分钟按期交付首集成片

项目按期交付约 5 分钟首集成片、全套美术资产和规范化提示词格式。第一集同时承担视觉定调和生产标准建立的作用,为后续集数提供可复用的资产结构与协作方法。

我负责项目统筹、主要对接、需求理解、进度推进、技术评估和质量把关,并在关键资产受阻时补位制作。工作台不是独立于项目的附加工具,而是我为解决真实协作问题所做的流程设计。

01信息透明不等于信息无差别公开。不同协作对象需要看到不同密度的信息,分层设计反而让项目状态更清楚。

02工具结构必须跟随决策结构。审核方做判断、制作方做执行,两套界面比一张超宽表更符合真实工作。

03反馈只有回到任务才算闭环。意见需要关联具体资产、版本和责任动作,否则仍然只是聊天记录。

Next case / 下一个案例 明日导演