# 审图工作流编排实战：用 WorkBuddy 正则闸门机器化拦截消防广播越界意见，守住舞台工艺专业边界

在一座大型剧院的音视频深化设计审核里，舞台工艺审图从来不是"打开一张图、写几条意见"的单步动作。它是一条多节点工作流：图纸与说明文本抽取 → 专业识别 → 审查意见生成 → 意见校验 → 路由分发 → 人工复核。舞台工艺只是这条流水线上的一个专业节点。真正棘手的不是"看不出问题"，而是"智能体生成的意见会越界"——把本属于消防专业的表述，当成舞台工艺本职写进意见里。本文从工程自动化流水线的视角，讲清楚如何把一道正则闸门（regex gate）作为机器关卡，焊死在"意见生成"与"路由分发"之间，让消防广播类越界意见被自动拦截、标注、转交。

## 一、审图流水线的节点编排：正则闸门插在哪一道

先把整条审图工作流摊开看。一个典型的剧院音视频深化设计审图流水线，节点编排大致如下：

- 节点 A（抽取）：从某剧院音视频深化设计图的图纸说明、系统图中抽取纯文本意见素材。
- 节点 B（生成）：WorkBuddy 依据舞台工艺审查规则，产出初版审查意见草稿。
- 节点 C（正则闸门）：对节点 B 的每一条意见做越界词扫描，识别是否混入消防专业归属表述。
- 节点 D（路由）：本职意见入册归档；命中越界词的，标注"非舞台工艺本职，建议由消防专业复核"并转交消防专业。
- 节点 E（豁免回退）：人工维护的白名单片段，可让部分含敏感词但确属本职的意见回退到舞台工艺。

这里的关键设计判断是：正则闸门必须放在"意见生成之后、路由分发之前"。原因有三。第一，意见生成是软环节——WorkBuddy 这类智能体的产出是概率性的，不保证每次都遵守专业边界；把边界纪律寄托在生成端，等于把门禁装在了会漏的人手里。第二，路由分发是硬环节——一旦越界意见进了消防专业的收件箱，责任归属就乱了。第三，正则扫描是确定性操作，O(n) 复杂度、零推理成本、可审计、可复现，正好补上"软生成、硬路由"之间的断层。把机器守门做成独立节点，而不是塞进生成提示词里，是这条流水线能稳定跑起来的工程前提。

## 二、越界意见是怎么长出来的：一份脱敏实证

问题不是理论推演，而是实打实踩过的坑。在某大型剧院音视频深化设计图的审核中，图纸说明里出现过这样一句表述：

> 消防广播点位由舞台音视频系统统一集成。

这句话看似顺理成章——音视频系统确实要管"广播"，于是生成端顺手把"消防广播"也揽进了舞台工艺的管辖范围。但专业边界是清楚的：舞台工艺只负责演出用广播与内部通讯（舞台监督对讲、演职人员调度广播），而消防广播是火灾自动报警系统（FAS）的子系统，归消防专业。把"消防广播点位由舞台音视频系统统一集成"写进意见，等于让舞台工艺越权认领了消防专业的工程范围。

为什么 WorkBuddy 生成的初版意见容易犯这个错？根因在语义邻近：在模型的世界里，"广播"是一个高频共现词，音视频系统要处理演出广播、消防系统也要处理消防广播，两者在向量空间里挨得很近。当图纸说明本身就把"消防广播"和"音视频系统"并列陈述时，生成端会顺着文本流把两者合并成"统一集成"的表述，而不会先验地知道"消防广播"受专业边界纪律约束。换句话说，越界意见不是模型"恶意"越权，而是它在缺乏硬约束时的默认合并倾向。这恰恰说明：专业边界守门必须机器化，不能靠生成端的自觉。

除了"消防广播"，舞台上还常见几类高频越界表述，本质都是把消防专业的事说成了舞台工艺的事：

- 消防强切：火灾时强制切断非消防电源，属消防联动范畴，不是舞台配电本职。
- 火灾自动报警（FAS）：火灾探测与报警系统，与音视频扩声完全是两套逻辑。
- 消防联动：消防设备间的联动控制，与舞台机械、灯光控制联动是两回事。

这些表述一旦混进舞台工艺审查意见，下游专业就会接收到错误的责任信号。正则闸门要解决的，正是这一类"表述归属错配"。

## 三、R17 禁词闸门的扩展：从"禁词"到"归属路由"

我们沿用了团队既有的 R17 禁词闸门思路，但做了一层关键扩展——把"单纯拦截"升级为"归属路由"。R17 原本是命中即阻断，而专业边界守门需要更细的动作：识别归属 → 标注非本职 → 转交消防专业。

这个三段式路由的逻辑是：

1. 识别归属：用正则扫描意见文本，判断是否出现消防专业归属术语。
2. 标注非本职：命中即在意见前追加固定标注——"非舞台工艺本职，建议由消防专业复核"。
3. 转交消防专业：将该条意见从舞台工艺意见池剥离，路由到消防专业审核队列。

核心正则规则如下，覆盖了脱敏实证中出现的主要越界词：

```regex
消防广播|消防强切|火灾自动报警|FAS|消防联动
```

逐词说明其归属依据：

- 消防广播：火灾应急广播子系统，GB 50116 明确归于火灾自动报警系统。
- 消防强切：消防联动中的非消防电源强制切除，消防专业管辖。
- 火灾自动报警：即 FAS，火灾探测、报警、联动控制的总系统。
- FAS：Fire Alarm System 缩写，与"火灾自动报警"同义，必须一并拦截。
- 消防联动：消防设备间的联动控制逻辑，跨出舞台工艺边界。

这五个 token 构成越界词表的最小可用集。它不是穷举——新的工程语境会冒出新的越界表述，所以词表本身要可扩展（见第七节）。但就"守住舞台工艺不认领消防广播"这个核心目标而言，这一组已经能挡住九成以上的典型越界。

## 四、实现：把 WorkBuddy 写的脚本焊进流水线

工程落地的关键，是让这道闸门成为流水线里一个可独立运行、可重复调用的节点，而不是临时粘贴的逻辑。我们让 WorkBuddy 编写了一个轻量拦截脚本，职责单一：读入一条意见文本，输出路由判定。

环境：Python 3.8+，仅依赖标准库，无外部包，保证在任意审图流水线的执行环境里零摩擦运行。

```python
# gate_fire_boundary.py
# 职责：对单条舞台工艺审查意见做消防专业边界正则拦截
import re
import sys
import json

# 越界词表：归属消防专业的术语，舞台工艺意见不得主张所有权
FIRE_TERMS = ["消防广播", "消防强切", "火灾自动报警", "FAS", "消防联动"]

# 人工白名单：确属舞台工艺本职、允许出现的豁免片段
WHITELIST = ["演出用广播", "内部通讯广播", "舞台监督对讲"]

# 编译正则，忽略大小写以覆盖 FAS / fas 变体
GATE_PATTERN = re.compile("|".join(re.escape(t) for t in FIRE_TERMS), re.IGNORECASE)


def scan_opinion(opinion: str) -> dict:
    """扫描单条意见，返回越界命中详情。"""
    hits = []
    for m in GATE_PATTERN.finditer(opinion):
        snippet = opinion[max(0, m.start() - 15): m.end() + 15]
        hits.append({"term": m.group(0), "snippet": snippet})
    return {"overstep": bool(hits), "hits": hits}


def is_whitelisted(opinion: str) -> bool:
    """白名单豁免：含本职广播片段时，即使命中敏感词也回退到舞台工艺。"""
    return any(w in opinion for w in WHITELIST)


def route(opinion: str) -> dict:
    """三段式路由：识别归属 -> 标注非本职 -> 转交消防专业。"""
    result = scan_opinion(opinion)
    if not result["overstep"]:
        return {"route": "stage_craft", "note": "本职意见，入册归档"}
    if is_whitelisted(opinion):
        return {"route": "stage_craft", "note": "白名单豁免，仍属本职", "hits": result["hits"]}
    return {
        "route": "fire_protection",
        "note": "非舞台工艺本职，建议由消防专业复核",
        "hits": result["hits"],
    }


if __name__ == "__main__":
    text = sys.stdin.read()
    print(json.dumps(route(text), ensure_ascii=False, indent=2))
```

为了让闸门规则可维护、可版本化，我们把词表和动作抽到一份配置里，脚本读取配置而非硬编码：

```yaml
gate:
  name: fire_boundary_r17
  stage: post_opinion        # 闸门所处的流水线位置：意见生成之后
  rules:
    - id: R17-FIRE
      terms: [消防广播, 消防强切, 火灾自动报警, FAS, 消防联动]
      action: route_to_fire_protection
      annotation: 非舞台工艺本职，建议由消防专业复核
  whitelist:
    - 演出用广播
    - 内部通讯广播
    - 舞台监督对讲
```

在流水线编排里，节点 C（正则闸门）就是一个调用：

```bash
# 节点 B 产出意见 -> 节点 C 正则闸门 -> 节点 D 路由分发
python gate_fire_boundary.py < opinion_stage_craft.txt > routed_result.json
```

如果流水线用编排工具串接，这道闸门就是一个幂等的、无状态的校验步骤：无论跑多少次，同一份意见得到同一份路由判定。正是这种确定性，让它适合做"硬关卡"而不是"软建议"。

## 五、工程化部署：为什么用正则而不是再调一次智能体

一个自然的问题是：既然越界是智能体生成的，为什么不"再让 WorkBuddy 审一遍"来纠正？答案是工程权衡。

第一，确定性优先。正则闸门是写死的规则匹配，结果可预测、可审计、可在争议时回放。再调一次智能体，结果是概率性的，今天拦下明天可能放过，无法作为责任判定的依据。

第二，成本与延迟。审图流水线往往一次处理几十条乃至上百条意见，每条都再走一遍智能体推理，token 成本和延迟都会失控。正则扫描是微秒级、零 token 的本地操作，适合放在高频、必过的关卡位。

第三，职责分离。生成端负责"想到问题"，闸门端负责"守住边界"。把两类职责拆成两个节点，任何一端出问题都不拖累另一端——生成端漂移了，闸门端照样拦；闸门端规则漏了，生成端也不至于把错意见直接发出去。这正是流水线编排相比"一个超级提示词包打天下"的健壮性来源。

部署形态上，这道闸门有两种常见落法：一是作为审图流水线的预路由校验（类似 CI 里的 quality gate），意见不通过闸门不得进入分发队列；二是封装成一个内部 API，编排器在节点 B 与节点 D 之间同步调用。无论哪种，它都应该是无状态、幂等、可并行的——每条意见独立判定，天然支持多进程并发扫描整批图纸。

## 六、规范与纪律：机器化守门的合规底座

机器守门不是技术炫技，而是专业边界纪律的硬性要求，底座是两份依据。

其一是 GB 50116《火灾自动报警系统设计规范》。该规范把火灾应急广播、消防强切、消防联动统一纳入火灾自动报警系统，与建筑音视频、舞台扩声分属不同子系统。图纸说明里"消防广播点位由舞台音视频系统统一集成"这类表述，在规范层面就是把两个独立系统错误合并，审图意见若不加甄别地采纳，会误导后续施工责任划分。

其二是审图 SOP 的专业边界纪律：每个专业只审本专业范围，跨边界事项必须路由转交，而非自行吸收。舞台工艺的意见池里出现消防广播，本身就是对这条纪律的违反。正则闸门把"纪律"翻译成了"代码"——凡命中越界词的，系统强制标注并转交，让纪律不再依赖个人警觉。

换句话说，机器化守门的价值，是把"应该怎么做"的规范，固化成"一定会怎么做"的执行。人工可以漏看，代码不会。

## 七、踩坑与回退：白名单豁免的工程细节

闸门上线后，真正考验工程功力的在边界 case。我们踩过、也预判了这几类坑：

**坑一：FAS 的大小写与变体。** 图纸里可能写 "FAS"、"fas" 甚至 "F.A.S."。正则必须 `re.IGNORECASE` 覆盖大小写；对带点的变体，可补一条 `F\.A\.S\.` 备选分支。否则小写 "fas 主机" 会漏网。

**坑二：全称与缩写混用。** "火灾自动报警系统" 与 "火灾自动报警(FAS)" 语义相同，词表要同时收录 "火灾自动报警" 与 "FAS"，避免只拦全称、放过缩写。

**坑三：假阳性——舞台工艺确实要管的广播。** 舞台工艺本职包含"演出用广播""内部通讯广播""舞台监督对讲"，这些词里带"广播"二字，但绝不能误伤。白名单机制就是为此：命中越界词的同时，若文本含有白名单片段，则回退到舞台工艺，并保留命中记录供人工复核。这正是 `is_whitelisted` 函数存在的原因。

**坑四：术语漂移。** 新的工程语境会冒出新的越界表述（如"火警广播""疏散广播"），词表要靠 R17 扩展机制持续维护。我们把词表外置到 YAML 配置，就是为了让人能低成本增删，而不必改脚本逻辑。

**坑五：中英文混排的边界。** "FAS 主机""FAS模块"里 FAS 是独立 token，正则用 `\bFAS\b` 配 `re.IGNORECASE` 更稳妥；若直接用 `FAS`，要确认不会误匹配 "fashion" 之类（虽在审图语境罕见，但工程上应防患）。

针对前三坑，闸门正则可迭代为：

```python
GATE_PATTERN = re.compile(
    r"消防广播|消防强切|火灾自动报警|消防联动|\bFAS\b|F\.A\.S\.",
    re.IGNORECASE,
)
```

白名单与越界词是"双保险"：越界词负责拦，白名单负责放，二者在路由函数里做与/或判定，既不放过越界、也不误伤本职。

## 八、总结：机器守门是专业边界纪律的刚需

回到开头那条流水线。舞台工艺审图的价值，不在于智能体"写了多少意见"，而在于"写对的意见有没有越界"。把正则闸门焊在意见生成与路由分发之间，本质是给专业边界纪律上了一道机器化的锁：

- 生成端（WorkBuddy）负责把问题想全；
- 闸门端（正则拦截）负责把边界守死；
- 路由端负责把越界意见准确转交消防专业；
- 白名单与人工复核负责兜底边界 case。

这套机制不是一次性的临时补丁，而是可版本化、可复现、可审计的工程节点。对大型剧院音视频深化设计这类多专业交叉的审图场景，专业边界守门的机器化，不是可选项，而是流水线能稳定交付的前提。当"消防广播点位由舞台音视频系统统一集成"这类越界表述再次出现时，闸门会在毫秒级把它拦下、标注、转交——舞台工艺的意见池，从此只装本职的事。


在一座大型剧院的音视频深化设计审核里，舞台工艺审图从来不是"打开一张图、写几条意见"的单步动作。它是一条多节点工作流：图纸与说明文本抽取 → 专业识别 → 审查意见生成 → 意见校验 → 路由分发 → 人工复核。舞台工艺只是这条流水线上的一个专业节点。真正棘手的不是"看不出问题"，而是"智能体生成的意见会越界"——把本属于消防专业的表述，当成舞台工艺本职写进意见里。本文从工程自动化流水线的视角，讲清楚如何把一道正则闸门（regex gate）作为机器关卡，焊死在"意见生成"与"路由分发"之间，让消防广播类越界意见被自动拦截、标注、转交。

审图工作流编排实战：用 WorkBuddy 正则闸门机器化拦截消防广播越界意见，守住舞台工艺专业边界

一座大型剧院音视频深化设计审核里，舞台工艺审图是一条多节点工作流：抽取→生成→校验→路由→复核。智能体（WorkBuddy）出的意见常越界——把消防广播、消防强切、FAS 等本属消防专业的表述写进舞台工艺意见。本文把一道正则闸门焊死在「意见生成」与「路由分发」之间：用 消防广播|消防强切|火灾自动报警|FAS|消防联动 做识别归属→标注非本职→转交消防专业的三段式路由，配白名单豁免防误拦。附可运行

人工智能

架构设计

开发工具

本文介绍如何通过正则闸门在审图工作流中拦截消防广播越界意见，实现专业边界机器化守门。基于GB50116规范，采用确定性规则匹配替代智能体二次审查，确保舞台工艺意见不越权认领消防专业职责。该方案支持白名单豁免、术语漂移扩展，提升多专业交叉审图的交付质量与效率。

代码解释

智能体

WorkBuddy 

路由

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

审图工作流编排实战：用 WorkBuddy 正则闸门机器化拦截消防广播越界意见，守住舞台工艺专业边界-腾讯云开发者社区-腾讯云

审图工作流编排实战：用 WorkBuddy 正则闸门机器化拦截消防广播越界意见，守住舞台工艺专业边界

审图工作流编排实战：用 WorkBuddy 正则闸门机器化拦截消防广播越界意见，守住舞台工艺专业边界

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐