企业官网建设流程全解析

每次聊到流程管理，总会有人把ftrack、ShotGrid和CGTeamwork这三个名字摆到一起，问我到底该选哪个。说实话，工具参数表我背得再熟，也很难直接给一个标准答案：这三款产品虽然都叫制作跟踪工具，但底层思路完全不是一回事。ftrack让人最舒服的是“审片反馈”闭环，打开浏览器就能和异地合伙人同步批注；ShotGrid则像一张自由度极高的生产数据大表，适合有人专门维护流程的大型团队；CGTeamwork把任务分配和文件交接这些国内工作室最没耐心的环节做得极轻。我在不同项目里把三款都亲自推过、改过、踩过坑，这篇就按实际使用体验聊聊，怎么选才不至于项目做到一半想换系统。

1. 三个工具，三种管理哲学

1.1 别急着比功能，先看团队是怎么工作的

很多团队选工具时喜欢拉功能对照表，比谁家的控件多、谁家字段全。我后来发现这个思路容易带偏。ftrack的设计前提是“所有人都围绕审片反馈来协作”，它把所有功能都往Review上面收拢；ShotGrid的前提是“生产数据应该像数据库一样可查询、可关联、可统计”，所以它提供海量自定义字段和视图；CGTeamwork的前提更朴素，“把活派下去、把文件传到位、把完成进度数清楚”，把复杂度留在界面之外。

换句话说，三款工具根本是在解决不同层次的问题。如果一个二十人的动画小组，核心痛点是导演和外包团队每天要花两小时开视频会审片，那ftrack的媒体审查几乎是为这个场景量身定做的。如果一个百人规模的制作公司，需要同时管理资产、镜头、版本、任务、权限、发布记录，并且有专门的流程TD去维护数据规范，那ShotGrid的灵活模型更好发力。如果团队多数成员不擅长用新软件，只是想找个带进度管理的派活工具，CGTeamwork的轻量和中文界面，能省掉大量培训成本。

我给了一个比喻：ftrack像一间带专业审片室的办公室，ShotGrid像一套可自由拼装的生产管理系统，CGTeamwork像一个剧组用的任务白板。三样东西都能帮上忙，但买错类型，越大越难受。

1.2 三个项目里试了三套方案

为了避免纸上谈兵，我说说我实际接触过的三种场景。

A项目是一个二十多人的动画短片组，周期三个月，导演和主美在不同城市办公。我们最后用了ftrack的云端版本，把所有镜头、资产、任务和审片都放进去。导演每天晚上把意见画在Review评论里，第二天美术打开软件同步任务，效率提升非常明显。

B项目是一个中大型长片项目，人数接近百人，有资产、绑定、动画、灯光、特效多个环节，制片还要求每周出一份跨环节进度表。那个项目沿用了ShotGrid。数据模型够强，各种视图和筛选能满足制片需求，但配置工作量和日常维护压力都不小。

C项目是一个外包比例很高的游戏美术组，核心团队三十人，外包分布在不同地区。团队最终选了CGTeamwork，理由是上手快，美术外包只需要装个客户端，就能接收任务、上传文件、看到进度，不用学一堆流程概念。

三个项目跑下来，我才真正确认了那句话：流程工具选型，本质上不是技术问题，是团队管理和协作习惯的匹配问题。

2. ftrack使用体验：这些细节决定流程能不能跑起来

2.1 项目架构设计：模板带来的秩序感与约束感

ftrack里有个核心概念叫Architecture，也就是项目空间的任务层级模板。默认思路是从Project（项目）往下挂Episode（剧集）或Sequence（场次），再挂Shot（镜头）和Asset（资产），最底层挂Task（任务）。这个结构比ShotGrid更“强制性”，好处是新人不会把层级建乱，坏处是遇到非标准资产时，需要手动调结构。

我在第一个项目里就碰到了这类问题。比如某个特效镜头既要出角色模型，又要出镜头专用场景，默认模板里没有这个组合，软件层面又不像ShotGrid那样可以自由造Entity类型，于是需要我们自定义Schema，把Task类型配好，再给对应镜头单独挂资产。这块的配置经验是：前期花半天时间，和制片一起把“最小任务层级”定清楚，不要什么环节都开Task。像灯光环节内部的“内部自检”，放到任务备注里即可，否则看板会堆满状态标签，反而看不清关键卡点。

另一个需要留意的点是Task状态流转。ftrack默认提供的状态通常就是“未开始、进行中、待审、审核中、完成、失败”这一套。我们当时按自己项目习惯改了状态名，结果发现导出报表时状态字段的映射逻辑跟着变了，统计口径对不上。所以改状态前，最好先和负责统计的人确认字段语义，别让流程系统变成了一个需要解释数据的额外工作。

2.2 Review与异地审片：比预期更重要的一环

ftrack最让我意外的不是任务跟踪，而是内置的Media Review。打开一个镜头，可以直接加载视频、序列帧，甚至多版本并排播放，用绘图笔在上面批注，评论会按帧号和图层保存下来。异地导演第二天打开同一视图，所有批注都在，不需要再开视频会议对着画质稀烂的会议软件沟通。

但Review用起来有几个实操上的坑。第一，转码问题。第一次我们往里面直接传了高码率的序列帧和MP4，结果转码队列排队排了一个多小时，导演那边刷新半天看不到画面。后来统一改成低码率的代理文件传上去，再把原片放在文件服务器里，情况才有改善。转码参数别选太低，不然放大看细节时糊成一团，批注就没意义了。

第二，打点偏移。不同软件之间帧号起点不一样，Maya、Nuke和剪辑软件对同一镜头的帧号定义经常有偏差。如果在Review里直接用默认时间轴打点，很容易出现“意见标在了错位帧上”的情况。我后来要求所有上传版本在文件名里带上起始帧信息，并统一软件工程帧起始一致，批注错位的问题就基本消失了。

第三，权限要留神。ftrack的角色权限可以控制谁能访问Review页面。有一次我图省事，给外部审核角色只勾了“查看任务”权限，结果对方打开镜头一片空白，以为我们没传素材。检查后发现是Review模块权限没开。权限配置完一定要用测试账号走一遍审片流程，别只看后台有没有权限树。

2.3 用Action和API搭自动化

光靠界面手动点，流程工具用半个月就会让人失去耐心。ftrack提供了Python API和Action机制，Action简单说就是在界面上注册成“按钮”的服务，点一下就会执行一段脚本。我们当时用Action做了两件很基础的事：把本地文件注册到当前任务版本，以及一键把任务状态从“待审”推进到“最终”。

一个最简单的Python会话大概是这样的：

import ftrack_api session = ftrack_api.Session() # 查询项目 project = session.query('Project where full_name is "demo_project"').one() # 查询该项目的所有任务 tasks = session.query('Task where project.id is {}'.format(project["id"])).all() for task in tasks: # 输出任务名称和当前状态 print(task["name"], task["status"]["name"]) session.close()

写Action时候最后悔没早点做的一件事：把所有Action的日志输出到文件里。因为Action如果脚本报错，网页端经常只返回一个笼统的失败信息，具体情况要看服务端日志。我们第一版Action偶发失败，网页上看不到原因，排查了好久才发现是文件路径里中文目录导致的编码问题。把日志落盘，再遇到问题十分钟内就能定位。

体验下来，API文档写得不错，但曲线不算平缓。如果你没用过这类API，别急着写复杂Action，先跑通一个查询，再试着创建Task，最后再做状态流转，一步一步来，坑会更少。

2.4 私有化部署背后的维护账

ftrack有云版本和Server版本，前者官方托管，后者要自己部署到CentOS或RHEL服务器上，并且依赖MySQL、Nginx等一系列组件。我们其中一个阶段考虑过Server模式，理由是数据不出内网。但评估下来，TIM每月的补丁更新、数据库备份、转码资源规划都要专人跟进，不是装上就完事。

后来确实用上了Server模式，感受是：如果你没有一个愿意周末更新补丁的人，这个维护成本是实打实的负担。数据备份这件事不能只做数据库备份，ftp存储目录、转码缓存、用户上传附件都要纳入备份范围。我曾见过只备份数据库、没备份媒体文件的案例，结果服务器故障后，任务结构都在，但所有Review评论对应的版本文件全丢了，等于审片脑白质被挖走。

如果团队规模不大，也没有硬性要求数据必须留内网，我建议直接上云版本，把精力留给流程设计。

3. 换上ShotGrid和CGTeamwork后，真实差别比参数表更大

3.1 ShotGrid的自由度与维护成本

ShotGrid（以前叫Shotgun）在VFX和动画行业沉淀多年，它的强项是数据模型自由度。几乎所有Entity都能加字段，字段之间能做各种关联，还有Pipeline Configuration这套框架，让TD可以按项目定义加载项、工作区模板、自动命名规则。简单说，它是可以“造体系”的工具。

但自由度是有代价的。没有TD带队的中型团队，很容易把ShotGrid用成一张没人维护的大型Excel。有一次我们想配置一个“模型审核未通过自动退回动画环节”的规则，涉及状态枚举、字段联动、hook脚本，前前后后调试了两天，确实能做，但复杂度远远超出预期。对比起来，ftrack的Action逻辑更轻，CGTeamwork则基本不提供这么细的控制面。

另外，海外云服务对国内团队的访问延迟问题很现实。美术同事上传文件、刷新页面时，经常会遇到转圈。后来团队加了加速或换网络，才勉强可以接受，但这类网络层面的事情不应该由制作团队来操心。

ShotGrid对需要自由建模和深度自动化的中大型团队而言，仍旧是首选。它适合那些已经有流程规范、有人专门维护的成熟团队，不适合从零开始、没有TD的团队。

3.2 CGTeamwork的轻量与务实

CGTeamwork给我最直观的感受是“不端着”。它的菜单基本都是中文，美术外包装上客户端就能看懂。任务分配、文件上传下载、状态更新、消息提醒，整个闭环做得很直白。团队里老一辈制作人员也能很快上手。

它解决的是国内工作室最常见的痛点：沟通靠喊，文件靠手动拖，进度靠日报。用上CGTeamwork之后，至少派活、文件交接和状态同步这三件事有了固定渠道。审批逻辑也不需要像ShotGrid那样搭体系，界面本身就很近似国内软件的习惯。

当然它的局限也很明显。数据模型相对简单，想在“镜头级资产”和“版本责任归属”之间做复杂检索比较吃力。审查功能更适合粗看文件，做不到ftrack那种帧级批注的粒度。API和插件生态也偏封闭，跨软件自动化基本靠官方提供的插件和自己写独立脚本，和另两款工具的开放性不是一个量级。

适合CGTeamwork的团队画像，我总结是：国内项目为主、外包比例高、没有专职TD、需要一个月内让全组跑起来。会有上限，但解决80%的日常问题。

3.3 三种团队怎么选

我在项目里慢慢形成了一个选型判断，供参考：

• 团队规模20到50人，动画或广告项目为主，有人负责流程维护，选ftrack。
• 团队规模100人以上，长线项目多，数据模型自由度和自动化需求高，选ShotGrid。
• 团队以外包接包和内部管理为主，希望快速上手、少维护，选CGTeamwork。

这个判断不是定死的。国内很多团队也会混用：内部流程用CGTeamwork管派活，审片环节单独用ftrack，数据台账用ShotGrid做统计分析。但混用会带来数据割裂，除非你确实需要不同工具解决不同环节的问题，否则不太建议一开始就搞多系统并存。

4. 横评对照表与迁移成本

4.1 一张表看完三款工具

这张表不是要分高低，而是用来做快速排除。比如你团队最关心审片反馈，那ShotGrid再强，也得先确认自己是否愿意花精力把审查流程配置出来。而如果团队连角色权限模型都懒得研究，CGTeamwork上手确实更快。

4.2 换工具的隐性成本

换流程工具最大的成本不是软件授权费，而是迁移过程中的历史数据和用户习惯。

历史数据里最重要的是“版本与审片记录”，因为这属于无形资产。我们当年从旧工具换到ftrack时，想把过去项目里的评论和备注导出来，结果发现旧格式的时间戳、用户ID和当前工具对不上，最后只导出了纯文本，评论和帧号的关联全丢了。作为教训，建议在换工具之前先做一次数据导出测试，别等老平台即将下线时才害怕。

用户习惯同样费时间。老同事用惯了旧界面的看板式视图，换成ftrack的表格视图后，每天都会有人问“我这个任务怎么跑到这个状态里了”，培训成本远高于预期。这里给一条经验：换工具期间，新旧系统并行运行两个星期，所有任务以新系统为准，旧系统只读不写，能大幅度减少适应期混乱。

4.3 小团队月内落地的简化路径

如果团队在30人以下，又没有专职TD，我推荐一条简化落地路径：直接上ftrack云版，先不要碰Action和复杂自定义Schema，用默认的项目模板跑通流程。

顺序是这样的：第一天建好项目和用户，分配好角色；第三天让各组把任务补录进去，把资产上传、版本创建这些基础操作跑顺；第一周导入一批真实镜头，做一次完整的Review流程；第二周根据反馈微调状态枚举和默认页面布局；第三周开始接Webhooks，比如任务状态变化后自动通知到企业微信群，替代一开始想做的复杂自动化。这样一个月内，团队就能稳定使用，风险小、见效快。

等稳定几周后，还能再用API把数据导出到自己公司的数据看板里，做更细的统计。这时候你会发现，比一开始就想搭建所有功能，靠谱得多。

5. 一些实在的收尾建议

5.1 如果只保留一个功能，我选审片记录

用过的工具多了以后，我最深的感受是：流程系统的价值不在任务看板，在“决策可追溯”。那次美术改了一版镜头，导演说“这不是我上次批注的样子”，结果大家翻聊天记录、翻网盘、翻邮件，折腾了一个小时，最后在审片评论里找到原话。有了帧级批注和版本关联，这类沟通成本能大幅下降。选工具时，我建议优先看重这个能力，而不是谁家状态栏更好看。

5.2 我踩过之后不会再踩的三个坑

第一，权限配置过紧。流程工具越管得严，越没人愿意用。上线初期尽量把审核角色的权限放宽，等运行顺畅后再逐步收紧。

第二，转码格式不测试就上线。多人审片场景一定要提前用真实素材跑一遍代理文件转码，确认各人的电脑都能流畅播放，而不是等到导演开始批注了才发现卡成幻灯片。

第三，自动化和手工操作混用。如果同一种任务有时候用Action自动流转、有时候人工拖拽状态，数据会有双份逻辑，统计报表就说不清了。要明确分工，哪类任务走自动化、哪类任务走人工，写在一页纸上，所有人都遵守。这也是我在这个项目里得到的最大教训。

如果问我现在自己会怎么选，我的答案很直接：看有没有人愿意为流程操心。有人，选自由度高的ShotGrid或者功能最顺手的ftrack；没人，选能让所有人平稳接手的CGTeamwork。工具只是把大家的协作习惯固化下来，真正把流程跑起来的，永远是团队自己。