Pipeline和Workflow的区别是什么？
作为一名流程TD，这两个概念非常重要。但是在平常的交流中，我发现很多朋友对这两个概念还是比较模糊的。而且纵使是大佬们之间的理解也或多或少的存在差别。
为了统一这些重要的基本概念，我觉得确实有必要写一篇东西来科普一下。（当然，我的理解也不是标准答案，大家仅做参考，有异议的也欢迎找我交流！
为什么要区分这两个术语？
在开始解释定义之前，我们最好先弄清楚一件事——精确地区分这两个术语的意义是什么？
在很多的语境下，这两个词所表达的意思是非常接近的。
比如我们经常会听到Pipeline TD这样的职位名称，很少会听到Workflow TD这样的称呼，但了解Pipeline TD工作内容的人一般都知道，无论是Pipeline还是Workorkflow通常都属于Pipeline TD的工作范畴。
当你的老板或者艺术家们和你讨论工作流程问题时，无论他们使用的术语是Pipeline还是Workflow，通常情况下都指的是生产方式相关的问题。
所以，你确实无需无时无刻地抠这些字眼儿，在非专业的语境下完全可以根据韵脚需要Freestyle选择说哪个词。但是，这并不意味这两个词之间没有区别。
对于专业的流程TD来说，这两个词有着明确的区别，并且对这些区别的认识程度直接影响着你审视流程架构的维度。有句话叫：夏虫不可以语冰。视角上的缺失是悲哀的，对于流程设计专业来说有时甚至是致命的。
什么是Pipeline？
我一般把Pipeline翻译为“管线”，顾名思义，它应当像管子一样，存在较为确定的输入和输出。
虽然一些情况下，Pipeline会被用于指代相对复杂的流程系统，但是通常情况下，它可以更加精准地表达一个输入到一个输出之间的线性关系。
我们可以举个例子来说明：假如在某个动画电影制作中，我们决定使用abc格式的文件将携带动画信息的模型数据从动画环节传递给灯光环节，这就是一条Pipeline。其实，在没有Pipeline的情况下，我们有很多种方式可以完成这个过程。如果项目很短，这个过程重复的次数并不多，我甚至可以每次使用不同的方法。但是，通常情况下，专业内容制作公司所面临的问题往往非常复杂，相同的过程需要成千上万次地进行。没有一些结果可控的固定流程来支撑，结果将会是灾难性的。
明确的接口定义加上程序化的过程实现，将大幅提升组织对生产结果的控制能力，这就是Pipeline存在的意义。也是国内外头部内容制作公司如此重视Pipeline技术的主要原因。
回过头来梳理一下Pipeline的概念：可以这么说，Pipeline是对数据流通方式的定义，它是个抽象的概念，是每一次数据传递操作的理论依据。
在Pipeline TD的实际工作中，你所需要面对的往往不止是局部的数据流通关系，而是涉及了大量环节的复杂系统。这样的复杂系统往往涉及了很多的规则和技术，需要精心地构建。
Pipeline TD最重要的工作往往就是Pipeline的设计，当然，更多的时候是基于设计开发工具，来辅助Pipeline的实施。
什么是Workflow？
Workflow可以直接翻译成工作流，中英文术语都非常的贴切。
当我们谈到work，绝大多数情况下我们谈论的是人的工作。因此Workflow的含义更多是偏向人的协作方式的。一般情况下，Workflow的制定会考虑更多关于工作实施的内容。
“流（Flow）”是Workflow的另一半，它描述了日常工作的另一个性质——流动性。这是经过设计的协作方式具备的典型特征，所有的事件都在非线性的活动网络中顺滑地进行。是否丝滑也是评价一套工作流质量的主要考量指标。
作为Pipeline TD，Workflow同样是你不可回避的工作内容。这不是一件一蹴而就的事情，你需要不断地思考、观察、打磨才能逐渐构建起一套优秀的工作流框架。当然，在此之前，你最好可以具备一些理论知识，来确保自己知道在做什么。
构成工作流的主要单位是“事件”。我们不可能捕获工作中的所有人的所有行为，呼吸、挠痒痒、上厕所，这些都不重要，重要的是与协作相关的活动。当这些提前定义的活动发生时，我们需要捕获它，这就是事件。
实时发生的各种事件构成了工作流的脉搏，与此同时，数据在管线中有节奏地传输，这就是Workflow与Pipeline的关系。这种描述可能比较抽象，你能领会这种微妙的关系吗？
定义事件是一件复杂的事情，你可能很容易地关注到与目标相关的那些事情，而例外的情况和突发的事故则往往需要吃一堑才能长一智。所以，Pipeline TD的经验确实如真金白银一样值钱。
在完成了事件的定义之后，就到了设计行为规范来应对各种事件的阶段了。此时，你需要做大量的沟通，充分倾听艺术家们的诉求，了解他们的日常，结合内外因素全面地考虑辨别问题的本质，才能设计出合理可行的工作流。由于工作流直接决定了团队的整体效率，因此脱离实践的纸上谈兵是非常危险的。
构建Workflow一个很重要的思想就是：优先考虑为日常工作制定标准。比如，内容审核、文件版本控制、技术支持工单等等。你可以为生产任务制定通用的生命周期，也可以为内部审核会议制定标准化的会议流程以及会议记录模板……
除了日常工作以外，应对不可预期的状况也是工作流设计的重点内容，你可能需要更早地形成原则，比如“人身安全大于数据安全”，或者“优先完成主要角色的资产”等等，并基于此灵活应对，而非总是拍脑袋做决定。同时也不能抱残守缺，死抱着冰冷的规则钻牛角尖。在不影响整体的前提下，充分地考虑兼容性，来应对各种可能出现的问题，才是成熟TD该做的事情。
读到这里，你应该已经看出了，不同于定义精确的Pipeline，Workflow的定义非常的广泛，甚至需要考虑到公司运营活动中的方方面面。这并不是Pipeline TD自己的事情，很多时候它需要更多相关人员的参与，骨干艺术家、制片、CG总监（或者VFX总监）、导演、制片人甚至所有的企业高管。
从涉及的领域上看，合理的Workflow需要涵盖大量直接CG内容制作以外的活动，包括而且不限于考勤、软硬件运维、人力调度、其他的集体活动等方方面面。
Pipeline和Workflow的对比
- 首先，这两个概念并非泾渭分明的，大多数非专业语境下甚至可以混用。
- Pipeline往往具有明确的输入输出，关注的是数据的流通；而Workflow则相对边界模糊，关注的是人的协作。
- Pipeline具备更强的产品性质，设计仅取决于技术，具备很高的复用性，同时也很方便替换；Workflow遵循较为基础的原则，设计上依赖资源，很难适用于不同的团队或不同的业务。
思考一个小问题，看看你领会了没有
Pipeline TD经常做的一件事——绘制生产流程拓扑图——把各个生产环节以节点图的方式连接起来，你觉得这件事属于设计工作流的范畴还是设计Pipeline的范畴呢？
欢迎通过TD学习交流社区来找我交流。
参考
机器猫的大喇叭：为什么CG公司间流程非得不一样？
DATA MACGYVERED
Question: Difference Between "Pipeline" And "Workflow" ?
Producer 软件文档
