# 用 WorkBuddy 把舞台审图复盘教训固化成可复用 Skill：让智能体把老毛病挡在审图最前

舞台工艺审图（灯光、音视频、机械三专业）每审完一轮，主理人都要拉着团队复盘，把这一轮踩的坑记下来。可记完之后呢？下一个项目、下一个人来审，照样把同样的坑再踩一遍。问题的根子在于：复盘结论躺在文档里，而真正干活的智能体读不到它。本文用 WorkBuddy 的 Skill 机制，把这事一次性解决——把历轮复盘教训写成一个可被智能体随时调用的 Skill，新图一送审，Skill 先对照教训清单过一遍，老毛病在出结论之前就被拦下。

## 一、为什么复盘教训该做成 Skill 而不是再写一份规范

写规范是给人看的，做 Skill 是给智能体用的。一份《审图复盘手册》再厚，智能体在 WorkBuddy 里也不会主动翻开它；但一个 Skill，只要被挂进工作流，每次审图都会自动加载它的指令。这两者之间的差距，就是"靠人记住"和"靠系统卡口"的差距。

更关键的是，Skill 是带触发条件的。你可以用指令写清楚：只要本轮出现"缺图"判定，就必须检查是否附带 layout 或 OLE 通道的取证证据；只要意见里出现电气判读，就必须确认类13 电气计算说明书是否已产出。这些原本靠主理人开会强调的纪律，变成 Skill 里的一行硬指令，智能体想绕都绕不掉。

还有一个被低估的好处：Skill 复用成本极低。上虞、石家庄、雄安多轮审图沉淀的教训，本来散在十几份复盘文档里，新人根本无从下手。把它们收敛进一个 Skill，新人接手时只要启用这个 Skill，就等于同时继承了全部前人的判读纪律。知识资产化，指的就是这种"经验不随人走"。

当然，Skill 不是银弹。它解决的是"已知教训的自动复检"，而不是"新问题的发现"。发现新问题仍靠人和智能体去探索，但一旦某个新问题被复盘固化进 Skill，它就从偶然发现变成必然拦截。这种"发现一次、永久防护"的闭环，才是复盘真正该有的闭环。

最后要提醒：Skill 里的指令必须可判定，不能是"要严谨"这种虚话。能写成"出现 X 就必须检查 Y"的，才配进 Skill；写不清楚判定条件的，先放回文档打磨。Skill 的威信来自它每次都拦得准，误伤一次就没人信了。

## 二、Skill 的载体与环境准备

在 WorkBuddy 里，一个 Skill 本质上是一份带 frontmatter 的说明文件，里面写清它叫什么、什么时候该被调用、具体要执行什么检查。最小可用结构包含三块：名称与描述、触发条件、检查指令。

名称要直白，让人和智能体一看就知道它是干嘛的，比如 `stage-audit-lesson-guard`。描述里要写清它承接的是"舞台工艺审图复盘教训复检"这一职责，以及它覆盖哪几条教训。触发条件用自然语言描述：当输入是审图意见草稿或审图产物时启用。

检查指令是核心。这里不写大道理，只写可执行的判定清单：逐条列出教训 id、对应的判定动作、违反时的处置（拦截并给出理由）。每条指令对应一条复盘结论，能直接映射到代码或规则检查。

Skill 还要约定一个输出格式：每次调用完，产出一份"复检报告"，列出命中的教训、未命中的项、以及哪些条目被拦截。这份报告既给人看，也让上层工作流据此决定是否放行。可验证，是 Skill 能被信任的前提。

承载层面，Skill 文件进版本库管理，每次增删规则都留提交记录。这样哪天某条教训被绕过，一翻历史就知道是规则没覆盖还是被改坏了。治理成本和可信度，往往是一枚硬币的两面。

## 三、把复盘结论写进 Skill 指令

下面给出这个 Skill 的 frontmatter 与指令骨架。五条教训来自上虞、石家庄、雄安几轮舞台工艺审图脱敏后的沉淀，每一条都可判定。

```yaml
name: stage-audit-lesson-guard
description: 舞台工艺审图复盘教训复检 Skill，对审图意见草稿与产物做已知教训自动复检
trigger: 输入含审图意见草稿、意见清单或外发意见文本时启用
instructions: |
  逐条执行以下复检，违反即拦截并附教训 id 与理由：
  - L01 版本绑定：结论草案中的 draft_version 必须等于本次输入底稿版本号，禁止用旧版结论改新版。
  - L02 缺图取证：凡判定为缺图等级的条目，必须附带 layout 或 OLE 通道取证证据字段，否则拦截。
  - L03 编号区间：编号缺口检测函数调用前必须传入 expected_range，禁止用序列自身 min/max 推区间。
  - L04 占位符扫描：外发意见正文禁止出现 X.2.xx 这类未填模板占位符，命中即拦截。
  - L05 跨文件联动：意见含电气判读条目时，必须确认类13 电气计算说明书已同步产出。
  输出复检报告，列出命中、未命中和被拦截项。
```

这五条指令和 CI 门禁里的规则同源，但形态不同：CI 里是 pytest 断言，Skill 里是自然语言判定清单。前者卡在流水线末尾的外发前，后者卡在智能体出结论的当下。两者互补，一个治"产物层"，一个治"生成层"。

写指令时要避免把教训写成形容词。比如不要写"取证要充分"，要写"判定为缺图的条目，证据字段必须含 layout 或 ole"。后者智能体读得懂、执行得了；前者只会让智能体觉得自己已经做过了。

指令里的判定动作尽量指向具体字段或文件，而不是模糊的"相关材料"。字段名要和审图产物的 schema 对齐，否则智能体在产物里找不到对应内容，复检就会变成走过场。

## 四、Skill 自检节点与触发条件

Skill 不是挂上去就完事，它自己也要有自检，防止规则被悄悄绕过。下面这段 Python 模拟 Skill 在 WorkBuddy 里被调用时的复检逻辑，和指令一一对应。

```python
# lesson_guard.py —— Skill 复检核心逻辑（WorkBuddy 内调用）
import re

LESSONS = {
    "L01": lambda p, m: bool(m.get("draft_version")) and p.get("draft_version") == m.get("draft_version"),
    "L02": lambda p, m: all("evidence" in it and ("layout" in it["evidence"] or "ole" in it["evidence"])
                             for it in p.get("items", []) if it.get("level") == "缺图"),
    "L03": lambda p, m: p.get("gap_call") is not None and p["gap_call"].get("expected_range") is not None,
    "L04": lambda p, m: re.search(r"X\.\d+\.\w+", p.get("opinion_text", "")) is None,
    "L05": lambda p, m: not any("电气" in it.get("tag", "") for it in p.get("items", []))
                             or m.get("class13_electrical") is True,
}

def run_guard(produced, meta):
    report = {"hit": [], "blocked": []}
    for lid, fn in LESSONS.items():
        ok = fn(produced, meta)
        report["hit" if ok else "blocked"].append(lid)
    return report
```

这段逻辑被 WorkBuddy 在每次出审图结论前自动执行：返回 `blocked` 非空，上层工作流就拦截草案，把命中哪条教训、为什么拦，一并返回给智能体去改。智能体不必记住五条教训，Skill 替它记、替它查、替它拦。

自检节点还要防一种情况：产物 schema 改了，字段名变了，Skill 找不到字段就悄悄放行。做法是给每个判定加字段存在性预检——读不到关键字段直接报异常而不是默认通过。宁可门禁报错，也不能门禁静默失效。

触发条件也值得打磨。触发过宽，每次审图都跑全套复检，拖慢节奏；触发过窄，又会有漏网之鱼。建议以"产物类型"而非"文件名"做触发，只要流入的是意见草案或外发意见，就必过 Skill，不靠人工记得去调用。

## 五、接进 WorkBuddy 工作流的接法

单独一个 Skill 还不够，要把它接进实际的审图工作流，才算真正落地。WorkBuddy 的工作流编排里，把 lesson-guard 放在"智能体起草意见"和"主理人复核"之间，作为一道自动复检关。

接法上，工作流每一步都有"步骤审核人"：审核它执行得对不对、有没有产物。Skill 这一步的审核人就是它自己产出的复检报告——报告里 `blocked` 为空，才允许流向下一步；非空则回到起草步骤重来。这种"步骤审核人"机制，把复盘复检变成了不可逆的卡口。

多专业审图时，Skill 可以按专业加载不同教训子集。灯光、音视频、机械三专业的复盘教训侧重不同，硬塞同一份清单会让某专业误伤。做法是在 Skill 指令里用专业标签分流，只激活和当前专业相关的那几条，既精准又不拖慢。

还要把 Skill 的复检报告回流进审图记录。每轮审图结束后，统计哪些教训被命中、哪些长期零命中，零命中的可以考虑降级或合并，频繁命中的说明仍是高发区要重点盯。Skill 自己也要被复盘，才不会越积越臃肿。

最后，Skill 和 CI 门禁要分工清晰：Skill 管"生成层当下拦截"，CI 门禁管"产物层最终兜底"。两层都过，复盘教训才算从文档真正搬进了生产线。

## 应用实例：Skill 怎么在审图工作流里拦下一条越级意见

讲清机制后，用一次脱敏过的真实调用看 Skill 怎么干活。某轮音视频审图，判读智能体起草了一条"某厅吊杆布置图缺图"的意见，证据字段空着。Skill 被工作流在"起草"之后自动调用，`run_guard` 走到 L02，发现这条等级是"缺图"却没有 layout 或 ole 证据，立刻把这条写进 `blocked`，并附上理由返回给上游。工作流依据报告里的 `blocked` 非空，把草案退回起草步骤，要求先补四通道取证。主理人只看了眼报告，没翻原图就知道这一刀被拦得有理——Skill 替他把"证据不足"这层纪律钉死了。

多专业分流也在实例里显形。同一套 Skill，加载灯光子集时只激活 L01 到 L05 里和灯光相关的那几条；切到机械专业，激活集随之变化。某轮机械审图如果硬套灯光的"照度必填"规则，会误伤一堆本就不该在机械层查的条目，分流后这类误伤归零。Skill 不靠人记得"现在审的是哪个专业"，标签一打，规则自动收放。

再看一次版本串扰的拦截。雄安某轮有人拿旧版底稿的结论改了改就当新版用，Skill 的 L01 比对 `draft_version` 和输入底稿版本号，不一致直接拦，避免了一份结论在不同版本间被悄悄复用。这类错误人工很难每次都记得查，Skill 把它变成了强制动作。三次实例下来，团队最直观的感受是：复盘教训不再是文档里的"建议"，而是工作流里真会红、真会拦的关卡。

L05 跨文件联动也在实例里显形。某轮音视频审图，判读智能体起草了一条含电气判读的意见，却没同步产出类13 电气计算说明书。Skill 的 L05 扫到条目带"电气"标签但 `class13_electrical` 为假，立刻拦截，要求先把电气计算说明书补出来再外发。这条守的是"电气意见不能只留在说明书里当独立依据"的纪律——过去这类意见常随批次丢失，因为没人专门核对两份文件是否同批次产出，Skill 把它变成了一条硬规则。这一步看似只是多勾一个框，却是电气意见不再随批次丢失的关键。

Skill 拦下的条目，主理人怎么快速判断是不是误拦？实例里有个约定：报告里每条 blocked 都带教训 id 和判定理由，主理人不必翻原图，先看理由就能拍板。某轮机械审图，L03 拦了一条编号缺口意见，理由是"未传 expected_range"，主理人一看就懂——判读智能体确实偷懒用序列自身 min/max 推区间，真该拦。理由写得越具体，主理人复核越快，Skill 才不会被当成"误报机器"而遭人绕过。

触发条件的打磨也值得单列。早期触发靠文件名，有人把意见草案存成 `draft_v2.json` 而不是 `opinion.json`，Skill 没触发，教训漏检。改成按产物类型触发后，无论文件名怎么变，只要流入的是意见草案或外发意见，就必过 Skill，不靠人工记得去调用。触发过宽会拖慢节奏，过窄会漏网，按类型触发是目前最稳的折中。

报告回流同样关键。每轮审图结束后，统计哪些教训命中、哪些长期零命中，零命中的考虑降级或合并，频繁命中的说明仍是高发区。Skill 自己也要被复盘，否则它只会越积越臃肿。这套"生成层当下拦截"的机制，和产物层末尾兜底的 CI 门禁分工清晰：Skill 管智能体出结论的当下，CI 管外发前的最终兜底，两层都过，复盘教训才从文档真正搬进了生产线。

## 六、踩坑与验收

坑一，指令写太虚，智能体以为自己执行了其实没有。早期我们把 L02 写成"取证要充分"，结果智能体在报告里写"已充分取证"就通过了。改成字段级判定后，没有 layout/ole 证据就真拦，假落实才消失。验收口径：每条指令都能对应一个返回布尔值的判定。

坑二，触发靠文件名，漏了一类产物。有人把意见草稿存成 `draft_v2.json` 而不是 `opinion.json`，Skill 没触发，教训漏检。改成按产物类型触发后，无论文件名怎么变，只要内容是指意见草案就必过。

坑三，字段改名导致静默放行。meta 里 `version` 改成 `draft_version`，Skill 读不到就当通过。加了字段存在性预检后，读不到关键字段直接异常，门禁失效变成门禁报错，反而安全。

坑四，规则只增不删。几个月后 Skill 里堆了二十多条，大半已被上游工具兜住，每次复检都慢且噪声多。做了季度瘦身，把重复断言合并，Skill 重新变得轻快可信。

坑五，没有把报告回流，无法判断是否真拦住。后来每轮统计命中率，才发现有条教训半年零命中，说明它早该降级。Skill 也要被复盘，这是闭环的闭环。

把舞台工艺审图复盘教训做成 WorkBuddy 的 Skill，本质是给智能体配了一个"永远在岗的纪律委员"。它不替智能体发现新问题，但保证已知的老问题绝不第二次漏网。对于动辄几十厅、上百张图的审图任务，这种"一次固化、永久防护"的机制，比任何靠人盯的复盘都靠谱。


舞台工艺审图（灯光、音视频、机械三专业）每审完一轮，主理人都要拉着团队复盘，把这一轮踩的坑记下来。可记完之后呢？下一个项目、下一个人来审，照样把同样的坑再踩一遍。问题的根子在于：复盘结论躺在文档里，而真正干活的智能体读不到它。本文用 WorkBuddy 的 Skill 机制，把这事一次性解决——把历轮复盘教训写成一个可被智能体随时调用的 Skill，新图一送审，Skill 先对照教训清单过一遍，老毛病在出结论之前就被拦下。

用 WorkBuddy 把舞台审图复盘教训固化成可复用 Skill：让智能体把老毛病挡在审图最前

舞台工艺审图（灯光/音视频/机械）每轮复盘的结论，常躺在文档里下轮照样踩。本文用 WorkBuddy 的 Skill 机制把复盘教训固化成可复用技能：把版本绑定、缺图取证、编号区间、占位符扫描、跨文件联动五条可判定教训写进 Skill 指令，新图一送审就自动复检，老毛病在出结论前被拦下，在 WorkBuddy 内的复检逻辑，演示如何接入审图工作流作为步骤审核人，复盘从"写了"变成"赢了"。

人工智能

架构设计

测试

把舞台工艺审图复盘教训固化为WorkBuddy可调用Skill，通过五条可判定指令（L01-L05）在智能体出结论当下自动拦截缺图无取证、版本错配等老毛病，配合字段预检、按类型触发与报告回流机制，实现"发现一次、永久防护"的审图纪律闭环，解决复盘结论躺在文档而智能体读不到的问题。

代码解释

智能体

WorkBuddy 

Python

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

用 WorkBuddy 把舞台审图复盘教训固化成可复用 Skill：让智能体把老毛病挡在审图最前-腾讯云开发者社区-腾讯云

用 WorkBuddy 把舞台审图复盘教训固化成可复用 Skill：让智能体把老毛病挡在审图最前

用 WorkBuddy 把舞台审图复盘教训固化成可复用 Skill：让智能体把老毛病挡在审图最前

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐