# 舞台工艺审图智能体派单门禁：用发车前 gate 脚本把六成员覆盖钉成硬约束

## 一、背景：比"漏派一个人"更隐蔽的是"清单漂移"

把舞台工艺审图这类强专业、强协作的活儿交给智能体团队之后，最容易出事的环节不是模型能力，而是派单。一个真实的脱敏案例很能说明问题：某剧院音视频审图团在甲、乙两个标段的审图任务里，先后两度漏派了"文档成稿成员"，结果审图结论没人整理成稿，整条成稿链路直接断档——审图做得再漂亮，最终交付的却是一堆散落的审查意见，客户拿不到可归档的成稿文件。

有意思的地方在于，复盘时大家第一反应是"谁忘了派文成规"，但真正翻到底层才发现，根因根本不是某个人记性差，而是**派单清单本身就是多份、而且对不齐**。

- 主理人脑子里有一份名单：习惯性的五个人，文档成稿"默认会有别人管"，所以脑内清单天然缺一项。
- 微信群公告有一份名单：每次新标段临时手敲，措辞还不一样，漏了也不会有人对着原始规范核对。
- 派单配置里有一份名单：写进调度系统的一次性字段，上线后没人专门维护。
- 喂给智能体的 prompt 里又有一份名单：为了省事直接抄微信群那版，漂移继续累积。

四份清单各自生长、各自漂移，没有任何一份被公认是"完整真相"。每次新标段开工，靠的还是口头派单加记忆，谁也没在发车前对着一份权威清单逐项核对。于是甲标段漏一次，乙标段又漏一次——这不是偶发失误，是结构性失守。

团队后来把这条铁律写进了内部规范 R38 的第 7 条，叫"六成员覆盖自查"：**派单前强制核对六成员，缺一不可发车**。这六名成员分别是：

- 主理人：全局统筹与派单决策；
- 显微显：显微级缺陷审查；
- 闻过喜：错漏碰缺交叉校验；
- 图析微：图纸语义与规范解析；
- 源章：溯源与依据核验；
- 文成规：文档成稿与归档。

注意"文成规"正是前两次事故里被漏掉的那位。它本质上是"收尾角色"，不像前五位那样在审图主流程里高频出场，所以最容易被人脑自动脑补成"肯定有人管"。

根因一句话概括：**口头派单靠记忆 + 无门禁（没有一道强制卡点，派了就直接发车）**。本文要给出的打法，不是再开一次复盘会、再发一遍强调通知，而是把"六成员覆盖"做成一道有非零退出码的 gate 脚本——发车前强制过门禁，过不了就崩，而且把它接进 WorkBuddy 调度循环和 CI 卡点，让"漏派"在发车那一秒就暴露，而不是两周后成稿断档才被发现。

## 二、环境准备

这套方案刻意做成"零业务侵入、零重依赖"，方便直接塞进任何已经跑着调度逻辑的云环境里。

前置依赖：

- Python 3.9 及以上：只用标准库 `json`、`sys`、`pathlib`，不引入任何三方包，避免给调度环境增加体积与版本风险。
- 一个工作目录：用来放"单一真相源"和 gate 脚本本身，建议和派单逻辑同仓但独立成子目录，职责隔离。
- （可选）bash 环境：用来写发车入口脚本，先调 gate 再真正发车。
- （可选）CI 流水线：GitHub Actions、GitLab CI、或者任意支持以退出码判定成败的流水线，甚至一个 git pre-commit 钩子都行。

推荐的目录骨架（一个子目录收口所有派单门禁相关文件）：

```text
dispatch-gate/
├── roster.json          # 单一真相源：六成员合约（权威名册）
├── dispatch_plan.json   # 本次派单意图（准备发车的实际名单）
├── dispatch_gate.py     # 门禁脚本：集合差检查 + 非零退出码
└── dispatch.sh          # 发车入口：先过 gate，不过就别发车
```

这里有两个关键点先说清楚，它们正是用来治"清单漂移"的：

- `roster.json` 是唯一的真相源，六成员名册只在这里维护一份，禁止散落到 prompt、微信群、配置字段里各写一遍。
- `dispatch_plan.json` 是"本次准备发车的内容"，它必须被 gate 拿去和 `roster.json` 比对，而不是自己说自己齐了。

清单从"多份互相漂移"收敛成"一份真相 + 一份意图 + 一道比对"，漂移空间被物理消灭。

## 三、步骤

整个落地分四步，每步都很轻，但缺一不可。

第一步，建立单一真相源 `roster.json`。把六成员名册和角色定义集中写进这一个文件，作为团队公认的合同。以后无论新增标段、调整角色，只允许改这里，不允许在别处另起一份。

第二步，写门禁脚本 `dispatch_gate.py`。它做两件事：读取真相源和本次派单意图，用集合差算出"该派但没派"的成员；一旦发现缺失，就打印明确错误并以非零退出码结束。配置缺失（文件丢了、JSON 坏了）和覆盖缺失（人没派齐）要用不同退出码区分，方便上层定位。

第三步，写发车入口 `dispatch.sh`。真正的派单下发逻辑，必须排在 gate 调用之后；gate 不过，脚本直接以失败退出，下游派单动作一行都不执行。这里最容易踩的坑是"调用了 gate 但没检查它的退出码"，那样门禁等于摆设。

第四步，把 gate 接进 WorkBuddy 调度循环和 CI 卡点。在调度器真正下发票据之前调用 gate，用返回码决定要不要继续；在 CI 里把 gate 当成一个必过 job，或者做成 git 提交前的钩子，从工程层面堵死"漏派代码"合进主干的可能。

## 四、代码与命令

下面给的是可直接落地的全部文件，照抄即可跑通。

先放真相源 `roster.json`，六成员名册只此一份：

```json
{
  "required_roles": [
    "主理人",
    "显微显",
    "闻过喜",
    "图析微",
    "源章",
    "文成规"
  ],
  "role_desc": {
    "主理人": "全局统筹与派单决策",
    "显微显": "显微级缺陷审查",
    "闻过喜": "错漏碰缺交叉校验",
    "图析微": "图纸语义与规范解析",
    "源章": "溯源与依据核验",
    "文成规": "文档成稿与归档"
  }
}
```

再放本次派单意图 `dispatch_plan.json`。注意下面这份故意漏掉了"文成规"，这正是事故复盘的现场还原——乙标段当时就是这么发的：

```json
{
  "project": "某剧院音视频审图-乙标段",
  "dispatched_members": [
    "主理人",
    "显微显",
    "闻过喜",
    "图析微",
    "源章"
  ]
}
```

门禁脚本 `dispatch_gate.py`，核心就是集合差加非零退出码：

```python
#!/usr/bin/env python3
# dispatch_gate.py
# 舞台工艺审图派单门禁：发车前强制核对六成员覆盖，不全则非零退出。
import json
import sys
from pathlib import Path

HERE = Path(__file__).resolve().parent
ROSTER_FILE = HERE / "roster.json"        # 单一真相源：六成员合约
PLAN_FILE = HERE / "dispatch_plan.json"   # 本次派单意图


def _load(path: Path) -> dict:
    """读取并解析 JSON；文件缺失或解析失败一律非零退出，强制暴露配置问题。"""
    if not path.exists():
        print(f"[GATE FAIL] 文件缺失: {path}", file=sys.stderr)
        sys.exit(2)
    try:
        return json.loads(path.read_text(encoding="utf-8"))
    except json.JSONDecodeError as exc:
        print(f"[GATE FAIL] JSON 解析失败 {path}: {exc}", file=sys.stderr)
        sys.exit(2)


def main() -> int:
    roster = _load(ROSTER_FILE)
    plan = _load(PLAN_FILE)

    required = set(roster.get("required_roles", []))
    dispatched = set(plan.get("dispatched_members", []))

    missing = required - dispatched   # 该派没派
    extra = dispatched - required     # 派了合约外角色

    if extra:
        # 多派不致命，但必须告警，避免名单悄悄漂移
        print(f"[GATE WARN] 派单含合约外角色: {sorted(extra)}", file=sys.stderr)

    if missing:
        print(f"[GATE FAIL] 六成员覆盖缺失: {sorted(missing)}", file=sys.stderr)
        print("R38 第7条：派单前强制核对六成员，缺一不可发车。", file=sys.stderr)
        return 1

    print("[GATE OK] 六成员覆盖完整，允许发车。")
    return 0


if __name__ == "__main__":
    sys.exit(main())
```

本地验证一下，故意漏派的这份意图应当被拦下：

```bash
python3 dispatch_gate.py
echo "exit code = $?"
```

预期输出：

```text
[GATE FAIL] 六成员覆盖缺失: ['文成规']
R38 第7条：派单前强制核对六成员，缺一不可发车。
exit code = 1
```

把 `dispatch_plan.json` 补上"文成规"再跑一次，应当放行：

```text
[GATE OK] 六成员覆盖完整，允许发车。
exit code = 0
```

发车入口 `dispatch.sh`，先过门禁再发车，门禁不过直接终止：

```bash
#!/usr/bin/env bash
# dispatch.sh — 发车入口：先过门禁，不过就别发车
set -uo pipefail

echo "==> 运行派单门禁"
if ! python3 "$(dirname "$0")/dispatch_gate.py"; then
  echo "门禁未通过，终止发车。" >&2
  exit 1
fi

echo "门禁通过，正式发车。"
# 真正下发派单的逻辑放在这里，例如：
# python3 "$(dirname "$0")/actually_dispatch.py"
```

接进 WorkBuddy 调度循环时，门禁就是一个普通子进程调用，靠返回码裁决。示意如下：

```python
import subprocess
from pathlib import Path

GATE_DIR = Path("/opt/dispatch-gate")


def safe_dispatch():
    """发车前先过门禁，非零退出码一律取消发车。"""
    result = subprocess.run(
        ["python3", str(GATE_DIR / "dispatch_gate.py")],
        cwd=GATE_DIR,
    )
    if result.returncode != 0:
        raise RuntimeError("派单门禁未通过，已取消发车，请先补齐六成员覆盖。")
    # 门禁通过，继续真正的派单下发
    # do_actual_dispatch()
```

接进 CI 同样简单，把 gate 当必过 job 即可（以 GitHub Actions 为例）：

```yaml
jobs:
  dispatch-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.11"
      - name: 派单门禁检查
        run: python3 dispatch-gate/dispatch_gate.py
```

CI 默认以退出码判定步骤成败，gate 返回 1 或 2 时该 job 直接标红，PR 合不进去，漏派从提交阶段就被挡下。

## 五、踩坑

把这套门禁真正用起来，有几个坑是实战里反复撞过的，逐一列清楚。

**坑一：清单漂移——多份名单各自维护。**
现象：甲标段名册全、乙标段漏一项，微信群和 prompt 里的版本还互相矛盾。成因：六成员名册散落在脑子、群公告、配置、prompt 至少四处，没有权威源。解法：名册只写在 `roster.json` 一处，其它地方一律引用或脚本读取，不允许另起副本；改名册只改这一个文件。

**坑二：门禁形同虚设——gate 跑了但没人看退出码。**
现象：脚本里调了 `dispatch_gate.py`，可即便缺失成员，派单照样"成功"发出。成因：调度代码只调用、没判断返回值，或者 shell 里没用 `set -e`、也没写 `if ! ...`。解法：发车入口必须显式检查退出码，像 `dispatch.sh` 那样 `if ! python3 gate.py; then exit 1; fi`，让"过不了"必然导致"发不了"。

**坑三：gate 放在发车之后。**
现象：漏派已经发生、派单已下发，才弹一条报警，于事无补。成因：把 gate 当成了"事后审计"而不是"事前门禁"。解法：所有真正的下发动作必须排在 gate 调用之后；gate 是发车动作的"前置条件"，不是"后置复盘"。

**坑四：退出码语义混乱。**
现象：配置错误（文件丢了）和覆盖缺失（人没派齐）混在一起，排障时不知道先查哪头。成因：两种情况都草率用了同一个 `exit 1`。解法：约定 `0=通过`、`1=覆盖缺失`、`2=配置/解析错误`，上层据此做不同告警与重试策略。

**坑五：文档成稿成员被"默认有"。**
现象：前五位派出去就觉得齐了，文成规这种收尾角色自动被脑补。成因：它是低频出场角色，不在主流程视线内。解法：门禁从真相源拉全集做集合差，任何角色都不允许靠人脑假设；"以为有"在脚本面前一律现形。

**坑六：把 gate 逻辑内联进派单脚本。**
现象：后期要改六成员，得翻派单主流程代码，耦合越积越重。成因：门禁和派单没做职责分离。解法：gate 独立成 `dispatch_gate.py`，派单脚本只负责"调用并看返回值"，名单变更与派单逻辑互不影响。

## 六、总结

回到开头的事故：甲、乙两个标段两度漏派文档成稿成员，根子不在谁记性差，而在"派单清单多份漂移 + 口头派单无门禁"。本文给的治法是把规范翻译成一道可执行的工程卡点——

一份 `roster.json` 收口六成员真相源，消灭多份清单互相漂移的空间；一个 `dispatch_gate.py` 用集合差做覆盖检查并以非零退出码说话，让"漏派"成为可机器判定的失败；一层 `dispatch.sh` / WorkBuddy 调度调用把门禁顶到发车动作正前方，过不了就发不了；再借 CI 或提交钩子把同一道门禁前置到代码合入阶段。

和"写完再开复盘会"相比，这种门禁化的好处是确定的：漏派不再依赖人的记忆力或事后审计，而是在发车那一秒被强制拦截。六成员覆盖从一条写在 R38 第 7 条的纸面要求，变成调度链路里一道谁绕不过去的硬约束。对云上跑智能体派单的团队来说，这种"小脚本、非零退出码、接进调度与 CI"的范式，同样可以套到任何"发车前必须齐某组条件"的校验场景上，性价比极高。


把舞台工艺审图这类强专业、强协作的活儿交给智能体团队之后，最容易出事的环节不是模型能力，而是派单。一个真实的脱敏案例很能说明问题：某剧院音视频审图团在甲、乙两个标段的审图任务里，先后两度漏派了"文档成稿成员"，结果审图结论没人整理成稿，整条成稿链路直接断档——审图做得再漂亮，最终交付的却是一堆散落的审查意见，客户拿不到可归档的成稿文件。

舞台工艺审图智能体派单门禁：用发车前 gate 脚本把六成员覆盖钉成硬约束

某剧院音视频审图团在甲、乙两个标段两度漏派文档成稿成员，审图结论无人成稿、链路断档。根因是派单清单多份漂移、靠记忆口头派单且无门禁。本文用 roster.json 单一真相源加带非零退出码的 dispatch_gate.py 门禁，在发车前强制核对六成员覆盖，并接进 WorkBuddy 调度与 CI。上线后漏派在发车瞬间即被拦截，成稿断档归零。

人工智能

舞台工艺审图智能体派单门禁通过发车前gate脚本将六成员覆盖钉成硬约束，解决清单漂移与漏派问题。以roster.json为单一真相源，dispatch_gate.py执行集合差检查并返回非零退出码，接入WorkBuddy调度与CI卡点，确保文成规等低频角色不被遗漏，实现发车前强制拦截。

代码解释

智能体

WorkBuddy 

Python

Ubuntu

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

舞台工艺审图智能体派单门禁：用发车前 gate 脚本把六成员覆盖钉成硬约束-腾讯云开发者社区-腾讯云

舞台工艺审图智能体派单门禁：用发车前 gate 脚本把六成员覆盖钉成硬约束

舞台工艺审图智能体派单门禁：用发车前 gate 脚本把六成员覆盖钉成硬约束

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐