做 AI 视频时，最让人头疼的往往不是"模型能不能出画面"，而是工作流总被切断：需求写在对话里，脚本在文档里，素材散落在网盘，生成任务又跑到另一个页面。等视频出完，团队还要重新找上下文、核对版本。
如果你已经用 WorkBuddy 整理产品资料和内容需求，可以借助 MCP 把 Maestro 接入同一个工作入口。真正值得关注的不是"连接成功"这四个字，而是连接以后，需求、任务状态、成片和修改意见能否形成闭环。
先把三者的职责分清
可以把这套组合看成一个小型视频制作团队：
- WorkBuddy 是工作入口：读取当前对话和你提供的产品资料，把自然语言需求整理成可执行任务；
- MCP 是连接层：让客户端发现并调用服务端暴露的工具；
- Maestro 是成片执行层：围绕视频简报继续完成脚本、素材、配音、剪辑、字幕与渲染等环节。
因此，正确的链路不是"WorkBuddy 自己生成视频"，而是：
产品资料 / 活动需求
↓
WorkBuddy 理解上下文并补齐约束
↓
通过 MCP 调用 Maestro
↓
保存任务标识并查询状态
↓
返回成片，继续在对话中提出修改这一区分很重要。出现问题时，你才能判断该检查会话上下文、MCP 连接，还是视频任务本身。
接入时，不要把密钥写进截图
在 WorkBuddy 的设置中进入 MCP 管理区域，新增 MCP Server。服务器地址和认证信息应以当前服务控制台展示的内容为准；若采用 OAuth，则按页面完成授权。
这里有几个容易踩的坑：
- URL 多了空格、少了路径，或者复制了过期配置；
- 认证信息失效，但仍在反复修改提示词；
- 当前会话使用的模型不支持原生工具调用；
- 新增服务后没有刷新会话，导致工具列表尚未加载；
- 团队网络或权限策略拦截了连接。
排错时一次只改一项。先确认服务可用，再确认工具已加载，最后用一个极简任务验证调用链。不要同时更换地址、认证方式和模型，否则即使恢复正常，也很难知道问题究竟出在哪里。
真实 Token 不应出现在文章、录屏、截图或共享文档中。团队协作时可以记录配置步骤，但应把凭据放在受控的密钥管理位置。
第一次调用，先验证闭环，不要追求大片
第一次测试的目标不是展示效果，而是验证下面四件事：
- WorkBuddy 能识别视频任务；
- 能实际调用 Maestro，而不是只返回一段建议；
- 提交后能拿到任务标识和状态；
- 任务完成后能返回可访问的结果。
可以先用一条边界清晰的需求：
制作一条横版产品概念短视频，主题是"把分散的视频制作工具连接成一条工作流"，受众为需要快速生产产品内容的市场团队。整体风格克制、专业，画面保留充足留白。不要出现价格、客户数量或未经核实的数据。任务提交后返回任务状态，完成后给出视频结果。
这条简报没有堆叠大量形容词，但说明了主题、受众、画幅、风格、禁用内容和交付要求，足够用来验证流程。
等闭环跑通，再逐步加入品牌色、参考图、产品截图、配音语气、时长和渠道规格。每轮只增加少量变量，比第一次就塞进一长串要求更容易定位问题。
"一句话生成视频"不等于提示词越短越好
一句"做个很酷的宣传片"看起来省事，实际上把大量决策留给了系统：给谁看、看完要理解什么、必须使用哪些素材、哪些信息不能出现，全部不明确。结果可能好看，却不一定能交付。
更实用的视频简报可以按这个顺序组织：
目标受众 → 核心信息 → 必用素材 → 叙事结构
→ 风格与节奏 → 画幅/时长 → 禁止项 → 交付要求例如：
面向第一次接触产品的运营团队，制作一条用于官网和社交媒体的介绍视频。核心信息是"在 WorkBuddy 内调用 Maestro 完成视频制作"。使用已提供的产品截图和品牌色：先展示多工具切换造成的混乱，再呈现统一工作流。旁白自然，不写成口号；不虚构界面、数据或客户案例。先输出横版主片，并为后续裁切竖版保留安全区域。
这类简报的关键不是长，而是给出验收标准。团队后续也能据此判断问题出在素材、节奏还是信息表达，而不是笼统地说"感觉不对"。
视频生成是异步任务：提交成功不等于成片完成
完整视频会经过脚本、素材、配音、音乐、剪辑、字幕和渲染等步骤，不适合被当成一次普通的文本回复。Maestro 采用任务方式执行时，"提交成功"只表示任务进入处理流程，不代表已经生成完毕。
一个稳妥的调用逻辑应该是：
job = create_video(video_brief)
job_id = job["id"]
while True:
result = query_video_task(job_id)
if result["status"] == "succeeded":
print(result["video_url"])
break
if result["status"] == "failed":
raise RuntimeError(result.get("error", "视频任务失败"))
sleep(10) # 示例轮询间隔，实际以接口约束为准这段代码是流程示意，字段名、状态值、轮询频率和返回结构应以调用时的公开文档为准。工程实现中还应补充超时、退避、日志和任务持久化，避免页面关闭后丢失任务标识。
等待期间不必让整个工作停住。可以继续整理发布文案、准备落地页，或者确定下一版修改方向。异步任务的价值之一，就是把"等待渲染"和"继续工作"拆开。
失败后先看错误，不要原样重复提交
任务失败时，直接把同一请求再发一遍通常不是好策略。更合理的顺序是：
- 检查素材 URL 是否能被服务端访问，是否临时过期；
- 对照文档核对画幅、时长、文件类型等参数；
- 查看认证、权限和额度是否满足当前调用；
- 保留任务 ID、时间和错误信息，方便追踪；
- 修正明确问题后，再创建新任务。
原样重试可能产生重复任务，也可能把一次可解释的参数错误变成多次无效等待。对于生产系统，任务 ID 应和业务单号绑定，并对"创建任务"增加幂等控制或重复检测。
怎么验收一条真正可用的成片
只确认视频 URL 能打开还不够。建议把验收拆成四层：
内容层：核心信息是否准确，是否出现虚构数据、界面或客户案例。
品牌层：Logo、品牌色、字体和产品截图是否正确，是否存在拉伸或错误裁切。
视听层：旁白、字幕、画面节奏是否同步，音乐是否盖住人声，首尾是否突兀。
交付层：画幅、时长、分辨率和文件格式是否符合发布渠道要求，横版内容是否为竖版改造预留了安全区。
修改意见也要尽量具体。相比"节奏再快一点"，下面这些表达更可执行：
- 把痛点压缩到开头几秒，保留后半段结构；
- 旁白改成产品经理讲解的语气，减少广告口号；
- 不改镜头顺序，只替换为新版本功能截图；
- 保留横版主片，同时为竖版裁切调整字幕安全区。
接入完成后，真正要建设的是团队习惯
MCP 的价值不是让团队每天研究协议，而是让调用方式变得稳定：大家知道如何提交需求、在哪里看任务、怎样拿到结果、失败时先检查什么。
当产品资料、视频简报、任务状态和修改意见都留在同一个工作上下文中，Maestro 才不再是一个孤立的视频工具，而成为 WorkBuddy 工作流里的成片能力。
最后给一份上线前检查清单：
- MCP Server 已连接，工具能在当前会话中被发现；
- 凭据没有进入提示词、截图和公开文档；
- 小任务已跑通"提交---查询---结果"闭环；
- 任务 ID 会被持久保存，失败不会盲目重复提交；
- 简报包含受众、目标、素材、风格、禁止项和交付规格；
- 成片经过内容、品牌、视听和交付四层验收。