PUG 已废弃，设计文档仅供参考。
本文档是关于自动搬运系统 PUG 的设计文档，在一定程度上消除了先前讨论中的术语分歧，并试图以简单易懂的方式解释整个系统预计的工作流程。
PUG
PUG 名起自《水瀬いのりと大西沙織のPick Up Girls!》[1]，是试图解决单次视频搬运不定时、步骤繁多，但多次搬运视频步骤相同、重复劳动的产物。PUG 目前的计划项目有：
pug：本体，负责主体逻辑。pugc：Electron 客户端，负责在个人使用时提供简单易用的用户界面。pug-web-extension：浏览器插件，负责在浏览器段提供易用的用户界面。pugw-frontend：前端页面，负责与服务器上的后端对接，提供托管的搬运业务。该项目属于多人课设项目（据说），并计划将该项目的界面应用到其余两个客户端中。
同时，因 PUG 而废弃的项目有：
[u2b](https://github.com/Yesterday17/u2b)：试图自动搬运YouTube视频到bilibili的项目，其功能是 PUG 的子集，故废弃。[bili-archive](https://github.com/Yesterday17/bili-archive)及其衍生项目（包括[bili-archive-frontend](https://github.com/Yesterday17/bili-archive-frontend)、[bili-archive-helper](https://github.com/Yesterday17/bili-archive-helper)、[bili-archive-report](https://github.com/Yesterday17/bili-archive-report)）：其功能相当于从 bilibili 搬运视频到本地，功能亦为 PUG 的子集，故废弃。
值得注意的是，虽然该项目的起因是搬运视频，但设计中并没有局限于视频本身。理论上只要有模块支持，PUG 也能完成自动诸如搬运推文等非视频性工作。
总览
下面我们给出一张单个 Work 工作的流程图。这张图看起来可能有点像固定管线，但其实这些分块只是为了描述这条 Workflow 的工作流程而做出的人为划分，实际过程中并不存在强制的步骤关系。
我们注意到，我们称整个工作为一个 Work，工作在 Workflow 中运行，因此这张图描绘的是 Workflow 的一个缩影；图中右边四列都是 Pipeline，而 Workflow 就是一个从左至右的过程，这表明了一个 Workflow 的设计意图是用来完成一种任务，本质不同的两类任务应该分成两个不同的 Workflow；代表 Pipeline 框中有许多蓝色的 Pipe，这表明了 Pipe 应该是用来完成某一项具体任务的最小单位。
针对 Pipe，我们的单位是“节”；针对 Pipeline，我们的单位是“条”；针对 Work，我们的单位是“件”；而针对 Workflow，我们的单位是“个”。
整个理解过程中，如果你有不明白的地方，可能需要多次回来观察这张图片，这张图片描绘了 PUG 运行的基本流程。下文为了简单期间，会将这张图简称为总览图。
Pipe
正如上文所说，Pipe 是完成某一项任务的最小单位，这是狭义的 Pipe 定义；从广义上来说，Pipe 是整个系统中的通用结构单元，Pipeline 和 Workflow 本质上也是 Pipe，只不过其并不满足狭义上 Pipe 的定义。当然了，广义上的 Pipe 属于实现细节，在后文的叙述中，如无特殊说明，Pipe 一般均指狭义上的 Pipe。
把任务拆分成 Pipe，也就是为最小单位，是有原因的。设想下面这种情景：在一个 Workflow 中，我们可能需要多次登录某一网站。登录的目的是为了重新获取被注销的用户账户的用户凭据，因此在每次用户登录失效时都需要重新登录。那假如我们将登录的任务和上传的任务实现在了一起，那么我们就无法完成单独的登录功能了。
上面的案例对应的是总览图中的最右边一列，图中对应用户账户登录失效的处理措施是用户干预，而用户干预的一般用途是要求用户输入对应的凭据，即用户名和密码。在用户干预完成后，势必需要登录操作，因此将登录操作单独拆分称 Pipe 是有必要的。
Pipe 是没有状态的，它的状态由上层管理，其本身只存在属性。属性代表了 Pipe 的基本性质，一般情况下不应该发生改变。
Pipeline
Pipe 的功能的确很细致，细致到我们常常不需要那么细致的操作，因此出现了 Pipeline。一条 Pipeline 对应的是一些 Pipe 的组合，它组合了这些操作，并成为了高一级的复用单元，我们称 Pipeline 是用户态的复用单元。
还是以上文的登录情景为例：验证用户凭据是否有效很显然是一个 Pipe，而需要用到用户凭据认证的情况有很多，除了无效时重新登录之外，还有很多有效时的操作，如获取 Timeline、获取关注列表等，而每一个上述的操作都会用到验证用户凭据这一节 Pipe。这时候，我们就可以将验证用户凭据的 Pipe 和对应的操作 Pipe 组合成一条 Pipeline，以便在 Workflow 中使用。
这里可能会有读者对 Pipeline 的功能表示不解。确实，在简单流程下 Pipeline 的作用可能不大，但当 Workflow 存在非线性流程，或存在多个 Workflow 时，其可能就会需要复用一些相同的单元，而 Pipeline 就代表了这样的复用单元。
此外，Pipeline 的用户态复用性还意味着其可以作为一个处理部分被打断，被打断后，Pipeline 不会保存其中的任何内容，相当于该 Pipeline 未被执行。
和 Pipe 一样，Pipeline 也是没有状态的。
Workflow
Workflow 是多条 Pipeline 按照一定逻辑执行直至结束的流程体现，大多数用户态的操作都针对 Workflow 完成，比如输入、暂停、中止等。此外，全系统的状态也由 Workflow 管理。
为了控制 Workflow 的流程，我们计划引入一些特殊的 Pipeline。区别于普通的单输入单输出的 Pipeline，它们可以拥有复数输入复数输出，以完成特定的应用目标。（draft）