第2章 任务编排适用场景识别

任务编排并非所有项目、所有团队都适用。盲目引入编排层只会增加认知负载与维护成本。本章提供一套可量化的场景识别框架，帮助你快速判断：当前项目是否需要任务编排？编排深度应为多少？

2.1 哪些项目需要任务编排

通过项目特征识别，可以快速筛选出需要引入任务编排的项目。以下四类特征独立评估，满足条件越多，编排优先级越高。

2.2 团队规模与复杂度判断

团队规模直接影响编排的粒度、层级和工具选型。规模越大，编排的系统性和自动化需求越高。

2.3 场景分类表

结合项目特征与团队规模，可将编排场景分为 4 个象限，对应不同的编排深度与投入。

2.4 前置条件清单

在进入具体的任务编排设计之前，必须完成以下前置条件的核查与准备。缺少任何一项都可能导致编排设计返工或执行失效。

1. 明确的目标定义
   • 项目期望达成的最终状态（可量化、可验证）
   • 关键交付物清单与质量标准
   • 决策权归属与变更流程
2. 资源清单
   • 可用人力（角色、技能、排期）
   • 硬件/软件/环境资源（GPU 配额、测试环境、API 密钥）
   • 外部依赖（第三方服务、数据源、许可证）
3. 依赖关系图（初版）
   • 任务间的逻辑依赖（串行/并行/互斥）
   • 数据依赖（上游产出为下游输入）
   • 时间依赖（固定时刻触发/滑动窗口/事件驱动）
4. 风险登记册
   • 已知阻塞项（单点故障、资源瓶颈）
   • 降级策略（部分失败时的回退/跳过/重试）
   • 安全与合规约束（数据隔离、审计日志）

2.5 操作步骤

按照以下 4 个步骤完成编排适用场景识别：

1. 步骤一：特征采集 — 对照 2.1 节四类特征，逐项评估当前项目。每个特征记录为“是/否”，并附上简要证据。
2. 步骤二：规模定级 — 统计项目核心参与人数，按 2.2 节确定团队规模等级。
3. 步骤三：场景匹配 — 将特征数 + 团队规模代入 2.3 节场景分类表，确定所属象限与编排深度。
4. 步骤四：前置核查 — 使用 2.4 节前置条件清单逐项核查，未通过项需补齐后方可进入下一阶段。

# 适用场景识别核查脚本（伪代码）
def check_scenario(project):
    features = 0
    if project.has_multi_step_dependency: features += 1
    if project.has_cross_role_collaboration: features += 1
    if project.has_resource_contention: features += 1
    if project.has_time_constraint: features += 1
    
    team_size = project.team_member_count
    
    if features <= 1 and team_size <= 5:
        return "象限Ⅰ: 无编排 / 浅度编排"
    elif features >= 2 and 6 <= team_size <= 20:
        return "象限Ⅱ: 中度编排"
    elif features >= 3 and team_size >= 10:
        return "象限Ⅲ: 深度编排"
    elif features >= 4 and team_size >= 20:
        return "象限Ⅳ: 全域编排"
    else:
        return "边缘场景 — 需人工复审"

2.6 输入输出物

2.7 责任边界

2.8 记录材料

• 《特征评分工作底稿》 — 记录每项特征的判定理由、证据来源、评估人及日期。
• 《团队规模登记表》 — 含成员姓名、角色、参与时长、排期冲突备注。
• 《场景分类确认单》 — 项目经理与技术负责人双签，确认象限定位及编排深度。
• 《前置条件检查表》 — 每项条件标注“通过/未通过/不适用”，责任人签字，归档留存。

2.9 异常处理

2.10 验收标准

本章工作完成的验收标准如下，所有条目必须全部满足：

1. 《编排适用场景评估报告》已完成，包含特征评分、团队规模定级、象限定位及编排深度建议。
2. 场景分类确认单已由项目经理与技术负责人双签。
3. 前置条件检查表所有项均标注“通过”或“不适用”，无“未通过”项遗留。
4. 记录材料（特征评分工作底稿、团队规模登记表、前置条件检查表）已归档至项目文档库。
5. 异常处理记录（如有异常）已闭环，升级处理结果附在报告附录中。