integration-orchestrator

集成编排

项目简报告诉团队要做什么。创意方向告诉他们应该营造怎样的感受。但两者都没有告诉他们每项决策何时定稿、谁审查什么，或如何防止上一阶段尚未完成就启动下一阶段。这正是本技能要填补的空白。

输出是一份分阶段编排计划，PM 周一早上可以直接贴进日历，周二就开始执行。计划涵盖阶段、关卡、定稿节点、交接、QA 验证规则，以及针对团队实际使用的技术栈（Jira、Linear、Notion、Figma、GitHub、敏捷冲刺）的平台专属实施指南。

---

本技能是什么

创意方向项目有三个层面。项目简报层定义范围、受众、交付物、约束和成功标准。方向层定义语气、美学、关系和感官层面的追求。两者都会产出书面文档，但都无法回答时间安排上的问题：项目简报何时定稿、品牌形象何时定稿、文案何时定稿、谁负责审查每项内容、关卡开放期间哪些工作会被阻塞、下游任务发现项目简报有误时该怎么办，以及如何确保“完成”意味着已测试，而不是仅由执行者自行报告。

本技能会产出这一时间安排层。大多数团队都有项目简报和创意方向，却没有编排计划。结果到了第 3 周，每个人都在并行工作，却没人清楚哪些决策仍未确定、哪些已经定稿。项目简报偏离。返工。文案已经按照旧方案起草后，品牌形象规范却发生了变化。工程团队在设计团队还没来得及审查前就已发布。“已完成”工单实际上从未验证过。

编排计划会解答所有这些问题。它不是理论，而是一份分阶段时间表，包含日历周、PM 可直接贴入 Jira 或 Linear 的工单模板、用于设置的 MCP 命令、带有可量化通过标准的关卡定义、包含交付物要求的交接规范，以及通过 Playwright 或 Chrome MCP 调用进行的 QA 验证关卡。

---

适用场景

• 启动新的品牌建设、品牌重塑或营销活动，团队需要安排工作顺序
• 项目进行到一半，需要重新审视项目简报，下游工作因不断重置而受影响
• 使用 MCP 和 CLI 集成，为新团队设置由 Agent 驱动的工作流
• 多团队协作中，品牌、设计和工程团队之间的交接已出现问题
• 建立 QA 验证关卡，让“完成”可衡量，而非由执行者自行报告
• 从临时编排迁移到有文档记录的节奏
• 为现有项目的新 PM 或设计负责人提供入职支持；该项目已有正在执行的工单，但没有记录工作顺序
• 为现有工作流添加新平台或工具，并需要重新规划节奏

---

不适用场景

• 如果交付物是项目简报本身，包括范围、受众、交付物、约束和成功标准，请改用 creative-brief。编排技能会将项目简报作为输入。
• 如果交付物是美学方向，包括语气、美学、关系和感官层面的追求，请使用 creative-direction。编排技能会安排围绕该方向开展的工作，但不会制定方向。
• 通用项目管理软件是运行平台；本技能产出的是在该平台中执行的计划。如果团队需要帮助选择工具，请不要运行本技能；它假设工具栈已经选定。
• 冲刺规划策略（故事点估算、回顾、速度图表）属于编排之后的工作。本技能制定节奏；冲刺规划则填充其中的具体安排。

---

必要输入

• 项目类型。 新品牌构建、品牌重塑、单页落地页、营销活动、品牌识别系统更新、网站更新、微型网站、产品发布。项目类型决定默认的阶段划分，技能会根据具体项目进行调整。
• 团队构成。 团队总人数和角色组合。个人、小型（2-3 人）、中型（4-7 人）、大型（8 人以上）。AI Agent（Claude Code、Claude in Chrome 等）是否参与制作、QA 或两者兼有。
• 工具栈。 团队使用 Jira、Linear、Notion、Figma、GitHub 中的哪些工具。此外，还包括 QA 工具（Playwright、Chrome MCP、Windows MCP、移动端测试工具套件，如已知）以及沟通和通知渠道（Slack、电子邮件、工具内提及）。输出会根据实际工具栈进行调整。
• 时间安排目标。 快速（压缩时间线、减少审核人员、接受较高的返工风险）、标准（按该项目类型的默认时长采用典型节奏）或全面（增加审核人员、进行正式阶段评审，以交付速度为代价降低返工风险）。
• 现有约束。 哪些内容已经确定？简报已批准、品牌识别系统已定稿、平台已固定、品牌语调已发布、内容管理系统不可更改。编排计划同样适用于从零启动和进行中的项目；现有约束这一输入用于适配进行中的项目。
• AI Agent 参与情况。 哪些工作流会包含 Agent，以及参与程度如何。例如：Claude Code 根据仓库中的状态文件执行制作任务；Claude in Chrome 在预发布环境上运行易于人工阅读的 QA 流程；Agent 可以访问 Linear MCP 和 GitHub MCP，但无法访问 Jira；Agent 可以将工单移至 Todo、In Progress、Waiting 和 Blocked，但不能移至 Done（Done 需要人工验证）。
• 风险概况。 可选输入，用于说明团队最担心的失败模式：简报偏离、并行工作冲突、QA 漏洞、Agent 失控。编排计划会优先针对所列风险制定缓解措施。

---

框架：编排的 7 项考量

交付编排计划处于七项考量的交汇处。每项都会筛选后续决策。

1. 阶段划分

项目如何拆分为各个阶段。标准结构包括探索、方向、品牌识别、制作、QA 和发布。并非每种项目类型都需要所有阶段。营销活动会跳过品牌识别阶段（沿用已定稿的品牌识别系统）。落地页会将探索和方向合并为一个简报阶段。品牌重塑会以审计取代探索（定位已明确；审计用于评估哪些内容应予保留）。

相比阶段的具体结构，更重要的是明确回答每个项目的两个问题：哪些阶段必须按顺序开展，因为下游阶段必须等待前一阶段的产出；哪些阶段可以并行，因为它们的产出互不依赖。品牌识别必须先于文案完成（文案取决于语调轴上的定位，而这属于品牌识别的一部分）。QA 必须先于发布完成。探索和审计可以与简报起草并行，因为简报会随着探索结果逐步形成而吸收这些发现。

2. 关卡

关卡是决定阶段转换的审批节点。标准关卡包括简报审批、方向审批、品牌形象审批、语调审批、文案审批、设计审批、QA 验证和发布就绪检查。每个关卡都有触发条件（开启该关卡的工作）、审批人（负责通过审批的人员或测试套件）、通过所需标准（可衡量的通过或不通过条件）、关卡通过前暂停的工作，以及之前关卡中已锁定的内容。

只有标准可衡量，关卡才能发挥作用。“简报已获批”太含糊；“客户以书面形式签署了简报文档，或在有记录的评审中批准了该文档”则可衡量。“QA 通过”太含糊；“Playwright 关键流程测试套件全部通过，控制台错误数量不高于基线，并维持无障碍标准底线”则可衡量。无法衡量的关卡会沦为政治博弈；可以衡量的关卡则会成为结构性保障。

3. 锁定点

锁定点是文档变为不可变的时刻。方向获批后，简报即锁定。身份标识元素在身份审批关卡后锁定。语调规则在语调审批后锁定。文案在每个页面通过文案审批后锁定。锁定后，下游工作不能更改该文档；只有通过正式变更申请才能修改，并且需要重新审核依赖于该文档的工作。

如果没有明确的锁定点，所有文档在概念上都可以被无限期修改。这正是简报偏离的根源。编排计划会注明哪些内容在哪个关卡锁定、锁定后的文档存放在哪里、谁可以申请变更，以及批准变更后需要重新审核哪些内容。锁定不等于最终定稿；锁定意味着“任何后续变更都会触发下游审核工作，因此请谨慎修改”。

4. 交接

交接是工作在不同阶段或技能之间转移的时刻。标准交接包括从调研到简报、从简报到身份标识、从简报到语调、从身份标识和语调到文案、从身份标识和文案到设计、从设计到工程，以及从工程到发布。每次交接都会移交特定的文档和决策，并明确哪些内容仍待确定，哪些内容已经锁定。

还有一种横向贯穿各阶段的交接：相邻观察交接。有人或 Agent 在处理主页主视觉时，注意到页脚文案与新的语调不一致。这个观察结果不是当前任务的一部分，因此会作为观察项记录在项目分诊队列中。PM 或技术负责人会定期审查观察项，并将其分诊为正式工单。这种模式能让当前工作保持专注，同时又不遗漏与上下文相关的发现；否则团队可能会直接忽略这些发现，或被迫中断当前工作来处理。

5. 团队规模调节

2 人团队和 12 人团队需要不同的编排方式。单人工作意味着一个人承担所有角色。小型团队（2-3 人）每个关卡只需一位审核人，异步交接即可。中型团队（4-7 人）需要多位审核人和异步同步节点。大型团队（8 人以上）需要正式的阶段评审、专职 PM 负责编排，以及明确的跨轨道同步会议，因为没有这些机制，并行轨道就会逐渐偏离。

编排计划的输出会根据团队规模调整。单人团队会获得每个阶段的自审清单。小型团队会获得每个关卡的“审核人”分配。中型团队会采用审核人轮换和阶段内小型关卡。大型团队会进行正式的阶段评审、跨轨道同步，并设置简报负责人角色。框架相同，但评审频率和会议形式会随团队规模而变化。

6. 工具栈实施

阶段和关卡在概念上已经定义，具体通过工具来实现。编排计划会按平台明确实施方式：在 Jira 中，阶段转化为 Epic，并添加“Phase”（阶段）、“Locked”（已锁定）、“Approver”（审批人）和“Gate Status”（关卡状态）自定义字段；在 Linear 中，阶段转化为 Project，并使用 cycle 和基于标签的视图；在 Notion 中，简报成为数据库行，并通过关联属性连接到方向文档、身份规范、语气指南和文案集；在 Figma 中，阶段转化为资源库文件夹，并设置画板级审核状态；在 GitHub 中，阶段与分支保护、PR 模板以及由 CODEOWNERS 驱动的审核分配流程协同运作。

对于提供 MCP 的平台（Atlassian、Linear、Notion、GitHub），计划会说明 MCP 可以执行哪些编排设置操作，哪些仍需通过 UI 手动完成。对于 MCP 功能有限的平台（Figma 的 Dev Mode MCP 侧重开发模式；设计资源库的设置仍需手动完成），计划会记录建议，但不会声称可以实现端到端自动化。

7. 自动化与 QA 验证

这是框架中影响最重大的纪律。只有在自动化验证通过后，任务才能从“QA”转为“Done”。这样一来，“Done”就是可衡量的关卡，而非自行报告的状态。

标准状态分类为 Todo、In Progress、Waiting、Blocked、Done。Blocked 是独立的一等状态，与 Waiting 不同。Waiting 表示任务因正常交接或计划审核而暂停；Blocked 表示任务遇到具体问题，必须由人工解决才能继续。Agent 无法自主解决工作时，会将任务移至 Blocked；这可以避免 Agent 在无法解决的问题上反复尝试、耗尽上下文。

QA 验证关卡会自动触发。Playwright MCP 运行关键流程测试；Chrome MCP 执行便于人工阅读的演练并收集证据；Windows MCP 负责桌面应用；移动端测试框架覆盖移动应用。失败时，任务会转至 Blocked；如果失败还暴露出无关问题，则会创建相邻观察项；随后通过已配置的渠道通知人工并停止。Agent 不会自主重试。

---

常见项目类型的节奏

七种模板。每种都是简化的阶段图；节奏模式参考文件中会逐一展开。

• 全新品牌建设。 历时 6 到 8 周，分为 5 个阶段：探索（1 周）、方向确定（1 周）、品牌识别（1 到 2 周）、制作（2 到 3 周）、发布（1 周）。每个阶段结束后都会触发评审关卡；品牌识别定稿后才能开始撰写文案。
• 品牌重塑。 历时 4 到 6 周，分为 4 个阶段：审查（1 周，替代探索）、方向确定（1 周）、品牌识别（1 到 2 周）、制作（1 到 2 周）。审查阶段假定定位和受众已明确；工作重点是评估哪些内容应保留、舍弃或更新。
• 单页落地页。 历时 1 到 2 周，分为 3 个阶段：简报（2 到 3 天）、制作（5 到 7 天）、QA-发布（1 到 2 天）。假定品牌识别已定稿，品牌语调也已定稿。工作内容是针对页面撰写文案、设计和工程实现。
• 营销活动。 历时 2 到 4 周，分为 4 个阶段：简报（3 到 5 天）、制作（1 到 2 周）、QA（3 到 5 天）、发布（1 到 2 天）。营销活动假定品牌识别和品牌语调均已存在且已定稿。
• 品牌识别更新。 历时 3 到 4 周，分为 3 个阶段：审查（1 周）、品牌识别（1 到 2 周）、制作（1 周）。跳过探索和定位阶段。交付成果是更新后的品牌识别系统，并将其投入制作，以生成应用示例。
• 网站更新。 历时 4 到 8 周，分为 4 个阶段：审查（1 周）、方向确定（1 周）、制作（2 到 4 周）、QA-发布（1 到 2 周）。如果审查发现定位方面存在差距，方向确定阶段可能会产出更新后的简报。
• 微型站点或产品发布。 历时 3 到 5 周，分为 4 个阶段：简报（3 到 5 天）、制作（2 到 3 周）、QA（3 到 5 天）、发布（2 到 3 天）。微型站点或产品发布通常有固定的发布日期，需要据此倒排计划。

每种节奏都应当写得仿佛项目经理可以直接复制到日历中并开始执行。阶段边界尽可能与日历周对齐，因为这才符合团队实际的规划方式。

---

失败模式

编排计划旨在防止以下问题。每一种都是在真实项目中实际观察到的失败模式。

• 简报变成只写一次的文档。 简报起草并签署后，就再也没人参考。下游工作逐渐偏离。解决方法：在关卡处锁定简报，并将任何对它的引用视为阅读，而非编辑。
• 简报在执行过程中解冻，却没有重新审核依赖它的工作。 有人调整简报的受众或定位，但变更并未传递到已经依赖旧版本的品牌识别、品牌语调或文案。解决方法：采用正式的变更请求流程，触发对相关产物的重新审核。
• 品牌识别先于品牌语调锁定。 字体排版已定稿，品牌语调却尚未获批。结果是字体风格与品牌语调相冲突（友好的语调搭配冷峻的字体，或严肃的语调搭配随意的字体）。解决方法：在锁定品牌识别之前或同时通过品牌语调审批关卡。
• 品牌语调锁定前就开始写文案。 撰稿人只能依据不断变化的目标起草。由于原始草稿从未与已锁定的品牌语调进行对照，返工情况也无法察觉。解决方法：先批准品牌语调，再开始制作文案。
• 多个并行设计轨道逐渐偏离简报。 轨道 A 和轨道 B 对简报的理解略有不同；到第 3 周时，两个轨道呈现的品牌已截然不同。解决方法：举行跨轨道同步会议，并设置简报负责人角色。
• 设计冻结前就开始工程工作。 组件按照仍在变动的设计进行构建。设计最终采用其他方案时，就会产生下游返工。解决方法：在针对受影响界面开始工程工作前通过设计审批关卡。
• 审核都堆积到阶段末尾。 所有人都把审核拖到最后一天；关卡变成一场长达 10 小时的审核马拉松，审批人疲惫不堪，只能仓促批准。解决方法：在阶段内设置小型关卡，分散审核需求。
• 异步交接没有明确产物规范。 只说“把设计交给工程团队”，却不说明需要哪些产物（Figma 文件 URL、导出的设计令牌、资源库引用、PR 草稿模板），工程团队就得翻找六七个 Slack 讨论串才能找到所需内容。解决方法：为每次交接明确列出产物规范。
• QA 关卡依赖自我报告。 标记为“已完成”的工单未经验证就被移至“完成”状态。错误因此进入生产环境。解决方法：在状态转换为“完成”之前触发自动验证；验证失败则转为“受阻”。
• Agent 在无法解决的工作上反复尝试。 Claude Code 任务无法自行解决；Agent 不断重试、消耗上下文、耗尽令牌，最终让工作状态比开始时更糟。解决方法：将“受阻”设为一等状态；Agent 无法自主解决时，应将任务移至“受阻”、记录阻碍因素，然后停止。

输出格式

默认输出为 Markdown 文档，通常保存为项目根目录或 docs/ 子目录中的 ORCHESTRATION.md。该文档包含完整计划，是团队的权威参考。

结构：

1. 项目编排计划。 按阶段划分的时间线，包含日历周、里程碑日期和阶段产出。
2. 各阶段关卡规范。 说明每个关卡的输入、输出、审批人，以及可衡量的通过标准，包括 QA 验证关卡。
3. 锁定点登记表。 说明何时锁定哪些内容、锁定产物存放在哪里、谁可以申请更改，以及更改会触发哪些重新审核工作。
4. 工具栈实施指南。 说明如何具体设置 Jira、Linear、Notion、Figma 和 GitHub（视情况而定），以及用于自动化部分工作的 MCP 命令或 CLI 调用。
5. QA 验证关卡规范。 说明必须通过哪些自动化测试、由哪些 MCP 运行测试、证据附加在哪里，以及失败时如何处理。
6. 交接规范。 说明每次交接要转移的产物、已锁定的内容、更改请求流程，以及相邻观察事项的流转方式。
7. 跨技能依赖关系图。 说明各阶段运行哪些技能、每项技能使用什么输入、产出什么内容。
8. 风险登记表。 列出与特定开发节奏相关的风险及其缓解措施。

该文档就是编排计划。交付后的下一步是由 PM 设置团队工具，使其与计划相匹配（Jira 史诗、Linear 项目、Notion 数据库、Figma 库、GitHub 分支保护），然后开始执行计划。

---

参考文件

• references/cadence-patterns.md。详细介绍 7 种项目类型的开发节奏，包括阶段划分、时间线、关卡定义和工具栈实施框架。
• references/gate-definitions.md。介绍每个标准关卡的触发条件、审批人、通过标准、阻塞事项、已锁定内容和更改请求流程。
• references/handoff-protocols.md。介绍阶段和技能之间的标准交接，以及在附近工作时发现事项的相邻观察交接流程。
• references/platform-implementation.md。介绍编排计划如何映射到 Jira、Linear、Notion、Figma 和 GitHub，包括各平台的 MCP 集成说明，以及 MCP 不适用时的 CLI 替代方案。
• references/team-size-modulation.md。介绍如何针对个人、小型、中型和大型团队调整开发节奏。
• references/automation-and-qa-tooling.md。介绍 QA 验证关卡模式、MCP 与 CLI 的取舍、会话记忆与进度保持模式、代码与工单的关联，以及证据追踪链。
• references/example-orchestration.md。提供一个完整示例，展示代表性场景中所有章节的填写方式。