业务赋能中心
成片协作流程
成片上传、版本审核、驳回修改、复审、交付与通知链路说明。
流程概览
成片模块承担的是“把制作结果送入审核并完成交付闭环”的职责。它通常承接直播录制素材、脚本分镜拆分和剪辑制作之后的成果。
常见链路如下：
- 从剪辑任务或上传页面上传成片
- 提交审核
- 审核通过或驳回
- 如被驳回，补充修改建议并重新提审
- 审核通过后进入交付、推送或资源归档
- 有外部投放时，在推送记录中追踪结果
- 外出审片时可走外网 480p 预览，但最终交付仍以原片和最新版本为准
页面分工
上传成片
- 负责把新成片或待审核成片送进系统
- 负责选择目标目录和上传位置
- 适合首次入库、剪辑任务交付、修改后重传和审核前准备
成片库
- 负责查看成片详情、流程记录和审核状态
- 负责提交审核、驳回、重新提审、推送、平台卡审和逐点建议
- 负责配合标签管理和回收站使用
- 负责沉淀最终交付版本和历史修改记录
常见状态节点
文档里需要重点关注这些状态变更场景：
- 初次提交审核
- 审核通过
- 审核驳回
- 重新提审
- 推送完成
- 平台卡审
- 创建修改建议
- 推送失败或部分成功
建议日常处理时，先在成片库定位记录，再决定是推进状态、补充建议，还是进入待办继续跟进。
成片和前置素材的关系
成片不是孤立文件。建议在成片进入审核前确认：
- 使用的直播录制素材或原始素材已经入库。
- 相关脚本、分镜、转写结果或文案库已经可追溯。
- 如果来自剪辑任务，任务、附件、关联文案和最近交付成片能够对应。
- 成片文件名、版本号和目录能对应到项目或场次。
- 必要标签已经补齐，便于后续检索和复用。
审核和修改建议
处理成片时建议保持这几个习惯：
- 审核结论尽量明确，不要只写“有问题”
- 修改建议要可执行，能落到镜头、文案、包装或时长层面
- 重新提审前确认旧问题是否已经逐条关闭
推荐审核闭环
- 制作人员上传成片并提交审核
- 审核人员在成片详情中查看版本、标签和流程记录
- 审核通过，或者驳回并填写修改建议
- 制作人员在待办中处理问题并回传
- 重新提审后再次审核
- 审核通过后进入交付、推送、归档或外部投放动作
推送和平台卡审
成片审核通过后，可以根据业务需要发起推送。推送不是审核流程的替代品，它依赖：
- 成片状态已经满足推送条件。
- 广告账户授权可用。
- 本地网关推送链路正常。
- 推送参数和目标账户完整。
- 平台限流、上传模式和目标网关状态可排查。
推送完成后，应在 推送记录 中查看账户级结果。出现失败或部分成功时，先看失败账户、失败原因和外部平台响应，再决定是否重新推送。
当前推送上传可能走云端代理，也可能由本地网关向云端换取一次性 token 后本地直传。业务人员不需要手工选择底层模式，但排查大文件、平台限流或上传超时时，要在推送记录里看上传模式、重试次数和网关回写的错误摘要。
平台卡审 用于标记外部平台侧审核卡住或未通过的状态，便于运营继续跟进。
平台卡审不是内部审核驳回。内部审核关注成片质量和客户要求，平台卡审关注外部平台、广告账户、资质、素材规格或投放规则。处理平台卡审时，应保留外部平台返回原因，并在推送记录或广告账户体系里继续排查。
飞书通知
成片状态落库成功后，会异步投递通知任务，发送飞书应用卡片到固定群，并尝试 @ 上传人。平台里也有剪辑任务、脚本分镜拆分、直播录制等飞书通知服务，具体是否触发取决于当前环境配置和队列状态。
这条链路的特点是：
- 通知失败不会回滚业务状态
- 失败会在异步队列里记录并重试
- 接收人依赖飞书外部账号绑定关系
如果业务状态已经变化但群里没收到通知，优先排查：
- 上传人是否已绑定飞书账号
- 飞书群
chat_id配置是否正确 - 队列是否正常消费
日常排查建议
- 看成片当前状态和最新操作时间
- 看是否生成了修改建议或审核记录
- 看是否触发了推送、推送记录或飞书通知队列
- 外网审片异常时，看 480p 预览、媒体入口和资源归属网关
- 推送异常时，看广告账户、平台卡审、本地网关和外部平台限流
- 看当前用户是否有查看该条记录的权限
角色分工建议
- 制作人员：上传、修改、重新提审
- 审核人员：查看详情、给出审核结论、补充修改建议
- 运营或管理员：关注交付结果、推送结果、平台卡审和异常状态