# 舞台工艺审图交付链：在 WorkBuddy 多智能体闸门流水线中锁死六列意见表的字段纪律

舞台工艺（剧场里机械、灯光、音响、幕布等设备的工艺布置与接口）深化施工图（在初步设计之后、把构造与接口画到可施工深度的图纸）审图，最后总要落到一张张可供业主签字确认的意见表上。这张表最容易被 AI 智能体（能自主读取图纸、比对规范并产出意见的 AI 程序）搞乱的，不是文字写得好不好，而是两列字段的边界：位置列只装图号（图纸的编号，用于在成百上千张图里唯一定位一张）+图名+区域，复核栏（审图意见的签字确认格，属于业主方的权责）永远留空待业主手填。本文不重复已经讲过的"用某种文档库把六列结构守住"的写法，而是把这条纪律守卫嵌进 WorkBuddy（腾讯出品的智能体工作台，下文用它指代我们的文字与流程智能体）多智能体审图交付链（从读图、审图到出成果文件的全过程）里，做成一道前置闸门（流水线里的一道校验关卡，不过就拦截，宁可不出成果文件也绝不放行）。这是腾讯云线独有的工程化视角：字段纪律不是靠人盯着，而是靠流水线在交付前最后一道门卡住。

## 一、背景：六列意见表的字段纪律是审图的专业边界

先说清楚这张表长什么样。我们日常用的六列意见表，列序固定为：

1. 序号——第几条意见；
2. 位置——只装图号+图名+区域，例如"D-103 主舞台栅顶平面图 舞台区"；
3. 问题描述——看见了什么不对；
4. 整改要求——希望怎么改；
5. 责任方——归谁改；
6. 复核栏——永远留空，等业主方现场师傅（在一线按图施工的师傅）拿着表去现场逐条核对后手写签字。

金标准结论只有一句话：位置列只装图号+图名+区域，复核栏永远留空待业主手填。这不是排版偏好，而是专业边界。

为什么是边界？两件事：

其一，位置列一旦混入机器读取坐标，人就无法定位。AI 智能体检查（指用人工智能智能体去扫描图纸并抽取信息，而不是人工逐张翻）一张 CAD 时，很容易顺手把"line 882 / p 14"这种程序内部坐标塞进位置列。问题在于，现场师傅手里拿的是打印出来的图册，他只看得到图号、图名和区域。你把"line 882"写进去，他根本不知道去哪张图、哪个位置找。位置列的本质是"给人看的定位索引"，不是"给机器看的读取指针"。把坐标塞进去，等于把给计算机的字节当成了给人的地址。

其二，复核栏一旦被预填，审图方就越了权。复核栏是业主方对"这条意见我确认收到、已到现场核对"的签字位。某剧院某次三厅深化施工图审核里，成表智能体图省事，把"已核对"三个字预填进了复核栏。这看似贴心，实则越界——审图方只是提意见的人，没有资格替业主确认"已核对"。一旦业主默认表格已经核对过，后面真出了错，责任链就乱了。复核栏留空，是把确认权牢牢交回业主手里。

这两点合起来，就是字段纪律：位置列守"可读"，复核栏守"权属"。过去这种纪律靠审图负责人最后肉眼扫一遍，但人工扫在量大的时候必漏。我们把纪律变成流水线里的一道闸门，就解决了"靠人盯着"的不确定性。

## 二、环境准备：搭起 WorkBuddy 多智能体审图交付链

要把纪律嵌进流水线，得先把链搭起来。我们在 WorkBuddy 里编排了四个各司其职的智能体（多智能体指多个各司其职的 AI 智能体协作完成一项任务），它们按阶段接力：

- 读图智能体：负责把 PDF 或 CAD 图纸解析成结构化图层与文本，记住它只产出"发现了什么"，不负责填表；
- 规范比对智能体：把读图结果与舞台工艺相关规范逐条比对，产出"哪里不满足"的问题清单；
- 意见成表智能体：把问题清单整理成六列意见表的草稿，这是最容易越界的一步；
- 闸门校验智能体：不写内容，只负责在成果文件出库前，按顺序跑三道闸门，任何一道不通过就打回重做。

这套链跑在腾讯云的环境里，读图与比对用云上的算力弹性扩容，成果文件落在云存储桶，最后的闸门在交付前最后一步触发。这样的好处是：无论谁发起一次审图，走的都是同一条链、同一组闸门，纪律不会因为换人或换项目而漂移。我们刻意把"字段纪律闸门"放在最前面，因为它是成本最低的拦截——连表都没填对，后面的语义检查根本没必要跑。

环境上要准备三样东西：第一，一个描述六列表结构的 schema 文件，告诉成表智能体每一列允许的内容形态；第二，一份字段纪律规则集，列清位置列禁填什么、复核栏必须空；第三，一条流水线编排配置，把上面四个智能体和三道闸门串成有顺序的 gate 调用。下面第三节讲顺序，第四节给代码。

## 三、步骤：把关卡嵌进交付闸门流水线的顺序

闸门流水线不是把校验一股脑堆上去，而是有讲究的顺序。我们把交付链拆成六个有序步骤，字段纪律闸门排在最前：

步骤一，读图智能体抽取图纸要素，产出原始问题集合，此时还没有任何表格形态。

步骤二，规范比对智能体把问题集合与规范逐条对齐，标出严重等级，产出结构化问题清单。

步骤三，意见成表智能体根据 schema 生成六列意见表草稿。这一步是纪律风险的源头，所以紧接着就交给闸门。

步骤四，字段纪律闸门先跑。它只检查两件最硬的事：位置列是否只含图号+图名+区域，且不含任何机器坐标；复核栏是否整体为空。任何一条不满足，直接打回成表智能体，不进入后续闸门。它的定位是"格式与权属的守门员"，轻量、快、零语义。

步骤五，opinion 闸门再跑。它接手字段纪律已经合格的表，检查六列是否齐全、复核栏是否仍为空（二次确认）、文字是否为纯黑字（不带颜色标记）、是否命中禁词清单。注意，复核栏为空在字段纪律闸门查过一次，opinion 闸门再确认一次，这是纵深防御，不是重复劳动——前者管"生成时没填"，后者管"后续环节没被偷偷补上"。

步骤六，表线渲染扫描闸门最后跑。它不读文字内容，只扫描表格渲染产物：列线是否完整、有没有断线、六列宽度是否对齐、有没有错位跨列。它是纯视觉/结构层的最终保险。三道闸门都过了，成果文件才允许出库交付。

这个顺序的设计哲学是"先廉价后昂贵、先结构后语义、先权属后视觉"。字段纪律闸门最廉价也最前置，先挡掉明显违规；opinion 闸门做语义与合规；表线扫描做呈现。三者分工，互不替代，合力把一张表从"能生成"变成"能签字交付"。

把这份顺序落到运行时，关键是把 review_pipeline.yaml 里的 gates 数组直接映射成 gatekeeper 智能体的串行调用列表。也就是说，配置里闸门写的顺序，就是云上实际执行的顺序，没有任何隐藏环节。这样做的好处是可读、可审计、可回滚：哪天要新增一道"签字栏占位检查"闸门，只需在 yaml 的 gates 里追加一项并在 gatekeeper 注册对应函数，不必改动成表智能体本身。字段纪律闸门因此始终稳居第一位，不会被后续维护无意中挪到后面。对一个要反复跑几十个项目的交付链来说，这种"配置即顺序"的硬约束，比任何口头约定都可靠。

## 四、代码：字段纪律校验 gate 的编排与配置

下面给出流水线编排配置，以及字段纪律闸门的核心校验代码。这段是腾讯云线的核心资产，和别处讲"用文档库生成六列表"的路线不是一回事——我们守的是流水线里的动态闸门，不是静态模板。

先是一条流水线编排配置（用声明式写法描述 gate 调用顺序）：

```yaml
# review_pipeline.yaml
# 舞台工艺审图交付链：六列意见表字段纪律闸门编排
pipeline:
  name: stagecraft_review_delivery
  runtime: tencentcloud   # 跑在腾讯云环境
  agents:
    - reader       # 读图智能体
    - matcher      # 规范比对智能体
    - tabler       # 意见成表智能体
    - gatekeeper   # 闸门校验智能体
  gates:            # 闸门按此顺序串行触发
    - field_discipline   # 字段纪律闸门（最前置，守位置列与复核栏）
    - opinion            # opinion 闸门（六列/复核栏空/纯黑字/禁词）
    - table_line_scan    # 表线渲染扫描闸门（列线对齐与断线）
  on_gate_fail: reject_to_tabler   # 任一闸门不过，打回成表智能体重做
```

字段纪律闸门的核心校验函数，由 WorkBuddy 的 gatekeeper 智能体在交付前调用：

```python
# field_discipline_gate.py
# 字段纪律闸门：位置列只装图号+图名+区域；复核栏永远留空
import re

# 机器读取坐标的几种典型形态，位置列严禁出现
MACHINE_COORD_HINTS = [
    r"\bline\s*\d+",          # line 882
    r"\bp\s*\d+",             # p 14
    r"\(\s*\d+\.?\d*\s*,\s*\d+\.?\d*\s*\)",  # (12.3, 45.6)
    r"坐标",                   # 任何"坐标"字样
    r"@\d+",                  # @1024 类内部指针
]

POSITION_COL = "位置"
REVIEW_COL = "复核栏"

def check_field_discipline(table_rows):
    """返回 (passed, reasons)。任一越界即拦截。"""
    reasons = []
    for idx, row in enumerate(table_rows, start=1):
        pos = row.get(POSITION_COL, "")
        # 1) 位置列不得含机器坐标
        for pat in MACHINE_COORD_HINTS:
            if re.search(pat, pos, re.IGNORECASE):
                reasons.append(f"第{idx}行位置列含机器坐标[{pat}]，应只写图号+图名+区域")
        # 2) 复核栏必须整体为空
        if row.get(REVIEW_COL, "").strip():
            reasons.append(f"第{idx}行复核栏被预填，越权——必须留空待业主手填")
    passed = len(reasons) == 0
    return passed, reasons

# WorkBuddy 闸门调用入口
def gate_field_discipline(context):
    rows = context["opinion_table"]["rows"]
    ok, why = check_field_discipline(rows)
    if not ok:
        # 打回成表智能体，不进入 opinion 闸门
        return {"pass": False, "stage": "field_discipline", "block": why}
    return {"pass": True, "stage": "field_discipline"}
```

opinion 闸门对复核栏的二次确认，只补一行独立校验，避免和字段纪律闸门耦合：

```python
# opinion_gate.py（节选：复核栏二次确认，纵深防御）
def gate_opinion(context):
    rows = context["opinion_table"]["rows"]
    for idx, row in enumerate(rows, start=1):
        if row.get("复核栏", "").strip():
            return {"pass": False, "stage": "opinion",
                    "block": f"第{idx}行复核栏非空，opinion 闸门二次拦截"}
        # 另含六列齐全 / 纯黑字 / 禁词清单检查（此处略）
    return {"pass": True, "stage": "opinion"}
```

这三段代码串起来，就是"字段纪律闸门最前置、opinion 闸门做语义与二次确认、表线扫描做呈现"的落地。它和"用文档库把六列结构写死"是两条完全不同的技术路线：一个是静态模板守卫，一个是动态流水线闸门；一个发生在写文件时，一个发生在交付前。

## 五、踩坑：被闸门拦下的两处越界与纪律红线

讲一个真实被拦的案例（已脱敏，单位为"某剧院"）。某剧院三厅（歌厅、戏剧厅、多功能厅）深化施工图审核，一次自动跑链里，成表智能体出了两个越界：

越界一，位置列被写进 CAD 读取坐标。成表智能体在生成"主舞台栅顶预埋件缺失"这条意见时，把位置列填成了"D-103 主舞台栅顶平面图 line 882 p 14"。字段纪律闸门立刻命中 `line\s*\d+` 与 `p\s*\d+` 两条规则，打回。原因很直白：现场师傅拿到表，只会按图号 D-103 去图册里翻"主舞台栅顶平面图"，再定位到舞台区；他电脑里没有那套 CAD 的 line 编号，line 882 对他毫无意义。闸门把它拦下来，逼成表智能体改回"D-103 主舞台栅顶平面图 舞台区"。

越界二，复核栏被预填"已核对"。成表智能体"贴心"地把复核栏填了"已核对"，想表示自己认真查过。字段纪律闸门直接命中"复核栏非空"规则，打回。这一拦拦住的是权属越界：审图方只是提意见的人，没有资格替业主确认"已核对"。即便 opinion 闸门也会二次拦，但字段纪律闸门先一步就把它挡在门外，省掉了后续所有无效检查。

事后复盘，这两条越界不是偶发，而是成表智能体的两个默认倾向：一是"能多给信息就多给"，把机器内部坐标当定位信息吐出来；二是"显得负责"，顺手替人确认。闸门的价值，正是把这些看似善意、实则破坏专业边界的行为，在交付前掐掉。

还有一条隐性踩坑：有人想把字段纪律检查也塞进 opinion 闸门，省一道 gate。我们试过，结果是 opinion 闸门越来越胖，且一旦 opinion 逻辑改动，字段纪律也被牵连。拆成独立前置闸门后，职责单一、好测、好回滚。这也是流水线设计的纪律——每个闸门只管一件事。

更深一层的坑，是"贴心"这种倾向会反复回潮。成表智能体在大模型微调或提示词调整后，可能某次又把坐标或"已核对"带回来，因为从它的视角看，多给信息、替人确认似乎是更"完整"的输出。闸门存在的意义，恰恰是让这种回潮在交付前必然被截住，而不依赖某次人工复检的运气。我们后来把字段纪律闸门的规则集也接进了 WorkBuddy 的回归测试：每次提示词或模型版本变动，都先用一批历史越界样例跑一遍闸门，确保"拦得住"这件事本身不被改坏。纪律不是写一次就完，而是用测试用例养着。

## 六、总结：字段纪律是工具与专业的分界线

回看整条链，字段纪律守的不是格式，而是两条专业底线：位置列守"给人看的定位索引"，复核栏守"业主方的确认权属"。把这两件事做成 WorkBuddy 多智能体审图交付链里最前置的闸门，意味着无论谁来发起审图、无论量多大，纪律都不会漂移——它不依赖某位负责人的细心，而依赖流水线在交付前最后一道门的硬性拦截。

字段纪律闸门、opinion 闸门、表线渲染扫描闸门三者分工：一个管结构权属、一个管语义合规、一个管呈现对齐，合力把一张"能生成的表"变成"能签字交付的表"。这条腾讯云线的工程化路线，和别处讲"用文档库把六列结构写死"的静态守卫是两回事——我们守的是动态流水线里的纪律闸门，是工具替人把专业边界焊死的地方。

说到底，AI 智能体检查再强，也该懂得在什么地方住手：位置列不替人写机器坐标，复核栏不替业主做确认。字段纪律，就是那条工具应当止步、专业应当接手的线。


舞台工艺（剧场里机械、灯光、音响、幕布等设备的工艺布置与接口）深化施工图（在初步设计之后、把构造与接口画到可施工深度的图纸）审图，最后总要落到一张张可供业主签字确认的意见表上。这张表最容易被 AI 智能体（能自主读取图纸、比对规范并产出意见的 AI 程序）搞乱的，不是文字写得好不好，而是两列字段的边界：位置列只装图号（图纸的编号，用于在成百上千张图里唯一定位一张）+图名+区域，复核栏（审图意见的签字确认格，属于业主方的权责）永远留空待业主手填。本文不重复已经讲过的"用某种文档库把六列结构守住"的写法，而是把这条纪律守卫嵌进 WorkBuddy（腾讯出品的智能体工作台，下文用它指代我们的文字与流程智能体）多智能体审图交付链（从读图、审图到出成果文件的全过程）里，做成一道前置闸门（流水线里的一道校验关卡，不过就拦截，宁可不出成果文件也绝不放行）。这是腾讯云线独有的工程化视角：字段纪律不是靠人盯着，而是靠流水线在交付前最后一道门卡住。

舞台工艺审图交付链：在 WorkBuddy 多智能体闸门流水线中锁死六列意见表的字段纪律

舞台工艺审图多智能体交付链，六列意见表的字段纪律（位置列装图号图名区域、复核栏留空待手填）常被破坏：坐标塞进位置列、结论预填复核栏。本文把这条纪律做成 WorkBuddy 交付闸流最前置的 gate，与 opinion 闸门、表线渲染扫描闸门分工串行；给出 review_pipeline.yaml 与字段纪律 gate 实现，让字段纪律在出稿前就被机器拦住，而非靠人肉抽检。

人工智能

架构设计

开发工具

舞台工艺审图交付链在WorkBuddy多智能体闸门流水线中，通过前置字段纪律闸门锁死六列意见表的位置列与复核栏边界，拦截机器坐标混入与越权预填，确保图纸定位可读、业主确认权属清晰，形成可签字交付的工程化硬约束。

回归测试

代码解释

云存储

智能体

WorkBuddy 

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

舞台工艺审图交付链：在 WorkBuddy 多智能体闸门流水线中锁死六列意见表的字段纪律-腾讯云开发者社区-腾讯云

舞台工艺审图交付链：在 WorkBuddy 多智能体闸门流水线中锁死六列意见表的字段纪律

舞台工艺审图交付链：在 WorkBuddy 多智能体闸门流水线中锁死六列意见表的字段纪律

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐