明确流水线阶段责任，关键是把每个阶段拆成可交接的责任单元：按交付流划分阶段并指定负责人，为每个阶段写明输入、动作、输出与完成标志，再用准入准出条件和证据记录把责任固定下来。本文围绕交付流执行中的阶段分工展开，不涉及平台对接与发布审批规则设计，适合研发交付负责人或流水线维护者对照落地。
要点总览（TL;DR）
- 按交付流而不是工具功能划分阶段，每个阶段用输入、动作、输出、完成标志四要素写成可交接的责任单元。
- 每个阶段区分阶段负责人、执行人与评审人，负责人对放行结果负责，一人兼任多阶段时补上独立复核或可事后检查的证据。
- 把责任转成可判断的准入准出条件并绑定证据，失败、回退与阻塞场景预先指定责任人和升级路径。
- 用一份完成检查清单逐项核对，并抽取已完成变更回溯各阶段负责人、交付物与判断证据，确认机制真正落地。
先把流水线阶段拆成可交接的责任单元
阶段责任说不清，通常源于阶段本身没有边界。按工具功能划分（代码扫描一段、构建一段、部署一段）容易形成“各管一段代码”的视角，交接时没人对整体结果负责。更稳妥的做法是按交付流划分：从一次变更进入流水线到形成可发布产物，中间经过哪些必须交接的环节，每个环节就是一个责任单元。
每个责任单元用四要素描述，缺一项就会在交接处留下模糊地带：
- 输入：进入本阶段前必须具备的东西，如已合并的代码、通过的单元测试报告、待部署的制品版本。
- 动作：本阶段实际执行的工作，如编译打包、自动化测试执行、制品入库、环境部署。
- 输出：本阶段结束时产出的交付物，如构建产物、测试报告、制品坐标、部署记录。
- 完成标志：判断本阶段结束的可观察信号，如构建成功且产物已归档、测试通过率达到约定值、部署后健康检查通过。
阶段边界的确定遵循两条原则：一是交接点必须对应一个可验证的产物或状态，口头说“测完了”不能作为边界；二是边界两侧的责任人不同，如果两个环节始终由同一人完成且无需交接，可以合并为一个阶段，避免形式化拆分。
常见划分粒度可参考下表，团队按实际交付流增删：
| 阶段 | 典型输入 | 核心动作 | 典型输出 | 完成标志 |
|---|---|---|---|---|
| 构建 | 已合并代码、依赖清单 | 编译、打包、生成版本号 | 构建产物、构建日志 | 构建成功且产物已归档 |
| 测试 | 构建产物、测试用例集 | 执行自动化与必要的人工验证 | 测试报告、缺陷清单 | 通过率达标、阻断缺陷清零 |
| 制品 | 通过测试的构建产物 | 制品入库、版本标记、完整性校验 | 制品坐标、校验记录 | 制品可被下游按版本拉取 |
| 部署 | 指定版本制品、环境配置 | 部署到目标环境、执行健康检查 | 部署记录、环境状态 | 健康检查通过、版本可回退 |
完成这一步的交付物是一份阶段责任单元清单，逐行填写阶段名、输入、动作、输出、完成标志。清单写完后让相邻阶段的责任人互相确认一遍，交接点上的分歧往往在这一步暴露。
每个阶段的责任角色与交付物怎么定
阶段结构清楚之后，要把人放进去。每个阶段至少区分三类角色：阶段负责人（Owner）对阶段结果负责，决定本阶段是否可以放行；执行人完成具体动作；评审人独立检查输出是否满足完成标志。负责人与执行人可以由同一人担任，但评审人应尽量独立，尤其在质量相关阶段。
角色分工的常见安排：开发角色在构建阶段负责代码可编译、依赖可解析，交付物是构建产物与必要的变更说明；测试角色在测试阶段负责用例执行与缺陷记录，交付物是测试报告和缺陷清单；运维角色在部署阶段负责环境就绪与部署执行，交付物是部署记录和回退方案；发布审批角色在制品与部署之间确认版本与变更范围，交付物是审批结论。角色名称可按团队习惯调整，职责与交付物对应关系要保持稳定。
| 阶段 | 阶段负责人 | 执行人 | 评审人 | 关键交付物 |
|---|---|---|---|---|
| 构建 | 开发负责人 | 提交代码的开发人员 | 同组开发或构建维护者 | 构建产物、构建日志、变更说明 |
| 测试 | 测试负责人 | 测试执行人员 | 测试负责人或质量代表 | 测试报告、缺陷清单、通过率记录 |
| 制品 | 制品库维护者 | 构建或发布工程人员 | 发布审批角色 | 制品坐标、完整性校验记录、审批结论 |
| 部署 | 运维负责人 | 运维执行人员 | 值班负责人或发布审批角色 | 部署记录、健康检查结果、回退方案 |
小团队常见一人兼任多个阶段。兼任本身没有问题，需要补的是复核安排：当同一人既是执行人又是负责人时，完成标志的核验应由另一人完成，或至少留下可事后检查的证据记录，如测试报告、部署日志。涉及生产环境的部署阶段，即使人员紧张，也建议保留一名独立确认人，避免“自己执行、自己放行”。
角色与交付物确定后，责任信息需要落在团队日常使用的协作工具中，否则清单只停留在文档里。以 ONES 为例，需求、研发任务等工作项可以关联代码提交与流水线数据，在项目、迭代、需求视图中呈现构建、发布等过程状态（F2、F3、F4）。团队可以把阶段负责人、交付物链接和完成标志记录挂在对应工作项上，让阶段责任随交付流一起被查看和追溯；具体到阶段级责任人指派如何配置，需以实际集成情况为准。
用准入准出条件把责任固定下来
角色和交付物写在文档里，执行时仍可能被跳过。把责任转成准入条件与准出条件，才能让“谁负责”变成“什么情况下才能进入、什么情况下才算完成”。
准入条件描述进入本阶段的前置要求，写法是“对象＋状态＋判断方式”，例如“构建产物已归档且版本号与提交记录一致”“测试环境已就绪并通过连通性检查”。准出条件描述离开本阶段的要求，同样要可判断，例如“自动化测试通过率不低于约定值且无阻断级缺陷”“部署后健康检查连续通过且回退包可用”。避免写“质量良好”“测试充分”这类无法核验的表述。
完成标志转成判断项时，尽量绑定证据：测试阶段绑定测试报告链接，制品阶段绑定制品坐标与校验记录，部署阶段绑定部署日志与健康检查结果。判断项与证据一一对应，评审人只需核对证据是否存在、是否符合条件，减少主观争论。
失败、回退与阻塞需要预先指定责任归属：构建失败由提交人或构建维护者定位；测试不通过由测试负责人判定阻断级别并通知对应开发角色；部署失败由运维负责人决定回退并记录原因；阶段因外部依赖阻塞时，由该阶段负责人发起升级，明确阻塞对象和期望解除时间。责任归属写在条件表旁边，异常发生时按表执行，不临时找人。
条件不是一成不变。业务节奏、环境或质量标准变化时，条件需要更新，更新应保留变更记录与生效时间，并通知相邻阶段的责任人。建议每季度或每次重大流程调整后复核一次条件表，删掉已无判断意义的条目，补上新增风险对应的检查项。
一个示例：从提交到上线的阶段责任分配
以下为演示情景，用于说明方法如何落地，不代表特定团队的真实配置。某团队的一条 Web 服务交付流水线划分为构建、测试、制品、部署四个阶段。
构建阶段：输入是已合并到主干的代码和依赖清单，执行人完成编译打包，输出构建产物与构建日志，完成标志是构建成功且产物按版本号归档。阶段负责人为开发负责人，评审由同组开发完成。若构建失败，提交人负责定位，超过约定时间未修复则由构建维护者升级。
测试阶段：输入是构建产物和本轮测试用例集，测试执行人运行自动化测试并记录结果，输出测试报告与缺陷清单，完成标志是通过率达到约定值且阻断缺陷清零。测试负责人判定是否放行，质量代表复核报告。测试不通过时，测试负责人标注阻断级别并通知对应开发角色，修复后重新进入本阶段。
制品阶段：输入是通过测试的构建产物，发布工程人员完成制品入库与版本标记，输出制品坐标和完整性校验记录，完成标志是下游可按版本拉取。发布审批角色确认变更范围后给出审批结论。制品校验失败时，由制品库维护者冻结该版本并通知构建阶段负责人重新出包。
部署阶段：输入是指定版本制品和环境配置，运维执行人完成部署与健康检查，输出部署记录和回退方案，完成标志是健康检查通过且回退包可用。运维负责人对部署结果负责，值班负责人复核。部署失败时运维负责人按预案回退，并记录失败原因反馈至测试与构建阶段。
这个示例可迁移的规律有三条：每个阶段的输出都是下一阶段可验证的输入；每个阶段都有明确的放行人和独立复核；异常路径与正常路径一样写清了责任归属。团队照此填写自己的阶段清单，即可得到本团队的版本。
责任落地后的完成检查
责任机制是否真正建立，可以用下面这份清单逐项核对。每项都应有明确答案和可查证据，而不是“大致清楚”。
- 每个阶段都有写明的阶段负责人，且负责人知晓自己对放行结果负责。
- 每个阶段都填写了输入、动作、输出与完成标志四项，没有空缺。
- 完成标志对应可核验的证据，评审人能在不询问执行人的情况下完成判断。
- 准入条件与准出条件均已写成可判断的表述，并绑定证据位置。
- 失败、回退与阻塞场景指定了责任人和升级路径。
- 一人兼任多个阶段时，存在独立复核安排或可事后检查的证据记录。
- 条件变更保留了变更记录与生效时间，相邻阶段责任人已知悉。
- 阶段责任信息在协作工具中可查，工作项、交付物与流水线状态能够对应追溯。
清单核对完成后，建议在下一次交付中实际走一遍：随机抽取一个已完成的变更，按阶段清单回溯每个阶段的负责人、交付物和判断证据是否齐全。能完整回溯，说明责任机制已经落地；出现断点，则回到对应章节补齐阶段结构、角色或条件。若团队使用 ONES 承载研发过程，可结合工作项与流水线数据的关联视图核对阶段状态，并利用效能度量报表观察交付效率与质量的变化，作为责任机制持续改进的依据（F5、F6）。
常见问题
阶段负责人和执行人是同一人时，责任还算明确吗？
可以算明确，前提是补上复核安排。负责人对阶段放行结果负责，执行人完成具体动作，两者由同一人担任时，完成标志的核验应交由另一人完成，或至少留下测试报告、部署日志等可事后检查的证据。涉及生产环境的部署阶段，建议保留一名独立确认人，避免自己执行、自己放行。
阶段划分到什么粒度比较合适？
判断标准是交接点：边界两侧的责任人不同，且交接点对应一个可验证的产物或状态，就值得单独成段。如果两个环节始终由同一人完成、无需交接，可以合并为一个阶段，避免形式化拆分。常见参考是构建、测试、制品、部署四段，团队按实际交付流增删。
准入准出条件写好后，业务节奏变化了怎么办？
条件需要随业务节奏、环境或质量标准变化更新。更新时保留变更记录与生效时间，并通知相邻阶段的责任人。建议每季度或每次重大流程调整后复核一次条件表，删掉已无判断意义的条目，补上新增风险对应的检查项，避免条件表与实际执行脱节。
阶段责任信息放在文档里够不够？
文档适合定义和评审，日常执行时责任信息最好落在团队常用的协作工具中，便于随交付流查看和追溯。以 ONES 为例，需求、研发任务等工作项可以关联代码提交与流水线数据，在项目、迭代、需求视图中呈现构建、发布等过程状态，团队可把阶段负责人、交付物链接和完成标志记录挂在对应工作项上（F2、F3、F4）。阶段级责任人指派如何配置，需以实际集成情况为准。
怎么验证责任机制真的在运转，而不是纸面清单？
随机抽取一个已完成的变更，按阶段清单回溯每个阶段的负责人、交付物和判断证据是否齐全。能完整回溯说明机制已落地；出现断点，就回到对应阶段补齐结构、角色或条件。若团队使用 ONES 承载研发过程，可结合工作项与流水线数据的关联视图核对阶段状态，并用效能度量报表观察交付效率与质量的变化（F5、F6）。
