# 长任务总崩在半路？WorkBuddy 把读图工具链拆成 A→B→G→C 四段实现断点续跑

你接过一个 200 多页的剧院图纸重审任务吗？三专业（建筑、结构、舞台工艺）的 DWG（AutoCAD 图纸文件格式）叠在一起，要逐张读、逐张查、逐张出意见。脚本跑起来，前 150 张都顺利，第 151 张因为一个图层名异常抛了异常——整批进程直接退出，前面 150 张的成果虽然落了盘，但后面的 68 张全没动。你改完 bug 重新跑，WorkBuddy 又老老实实把前 150 张重读一遍，token 和时间双重浪费。这就是"长任务总崩在半路"的真实代价：不是崩一次，是每修一次 bug 就要为已经完成的部分买单。

本文讲的是我们怎么用一套编排思路，让脚本在长任务里"自己活下去"：不靠人盯，不靠重跑，靠的是把读图工具链拆成四段、用 manifest 派单、用失败隔离兜住单图异常、用 --resume 断点续跑跳过重做。

## 一、断点续跑的代价：不是加个 flag 那么简单

很多人第一反应是"给脚本加个 --resume 不就行了"。但真做起来会发现，断点续跑成立的前提有三个，缺一不可：

第一，每一张图的处理结果必须能落盘成独立文件，且文件名可逆推出图号。如果所有成果都堆在一个大 JSON 里，断点续跑时就没法判断"哪张算完成"。

第二，单张失败不能连累整批。长任务里总会有几张"脏图"——图层名带特殊字符、引用了外部缺失字体、或者几何严重畸形。如果一张崩就整批退出，断点续跑也救不回来。

第三，派单逻辑必须显式、可序列化。脚本得知道"本次一共要处理哪些图"，而不是在目录里现找。现找的问题在于：目录里混入了临时文件，或者某张图本次不该处理，现找就会把不该处理的也处理了。

这三点，本质上就是后面四段拆分里 A 段要解决的事。我们不是先写四段，而是先被"崩在半路"毒打过，才反过来把工具链拆清楚。

**把读图工具链拆成 A(编排)→B(核查)→G(齐套)→C(成稿) 四段，用 manifest 派单＋失败隔离＋--resume 断点续跑，让脚本在长任务里自己活下去。**

下面先交代环境约定，再按"先拆后连"的顺序把每一段讲透。

## 环境准备（依赖与约定）

- 运行环境：Python 3.10+，下面的编排骨架只用到标准库 `json` / `pathlib`，无需额外依赖；真正读 DWG 的环节调用你已有的解析器即可，本文不绑定具体库。
- 规则配置：B 段的 R49 基线、R28 三关以配置文件形式存在，和脚本解耦，便于不同项目换规则。
- 目录约定：`read/` 下每张图落 `<id>.read.json`；失败记 `<id>.fail.json`；manifest 与 expected 期望目录同目录存放。
- 工具前提：已装 WorkBuddy 命令行或等价执行环境，能跑 `python xxx.py` 与 `bash` 命令。

## 二、A 段：批量读图编排器（manifest 派单）

A 段是整条流水线的"调度中枢"。它的输入是一份 manifest（派工单：一份描述"本次要处理哪些图、各自做什么"的 JSON 清单），输出是每张图独立的 read.json。

manifest 长这样：

```json
{
  "batch": "music_hall_2026_review",
  "expected": ["A-01-ARCH", "S-12-STRU", "T-07-STG"],
  "tasks": [
    {"id": "A-01-ARCH", "path": "dwg/A-01.dwg", "role": "arch"},
    {"id": "S-12-STRU", "path": "dwg/S-12.dwg", "role": "stru"},
    {"id": "T-07-STG",  "path": "dwg/T-07.dwg", "role": "stage"}
  ]
}
```

编排器的核心逻辑只有三步：加载 manifest、判断哪些已完成、逐张处理并对单图失败做隔离。下面这段骨架可直接照抄运行思路：

```python
# run_ab_pipeline.py 的 A 段骨架（节选，思路可复制）
import json
from pathlib import Path

def load_manifest(manifest_path):
    # manifest = 派工单，列出本次所有待处理图及其任务类型
    return json.loads(Path(manifest_path).read_text(encoding="utf-8"))

def already_done(read_dir):
    # 扫描已落盘的 read.json，得到"已完成图号集合"，供 --resume 跳过重跑
    return {p.stem.split(".")[0] for p in Path(read_dir).glob("*.read.json")}

def run_a(manifest, read_dir, resume):
    done = already_done(read_dir) if resume else set()
    for item in manifest["tasks"]:
        tid = item["id"]
        if tid in done:
            print(f"[skip] {tid} 已完成，断点续跑跳过")
            continue
        try:
            process_one(tid, item)   # 单图失败隔离：try 包住，崩一张不炸整批
        except Exception as e:
            print(f"[fail] {tid} 处理失败，记录后继续：{e}")
            (Path(read_dir) / f"{tid}.fail.json").write_text(
                json.dumps({"error": str(e)}, ensure_ascii=False), encoding="utf-8")
            continue
```

这里有三处是"让脚本活下去"的关键：

- manifest 派单：任务来源是显式清单，不靠目录现找，避免了"多处理/漏处理"。
- 失败隔离：每张图的处理被 try 包住，单图异常只写一条 .fail.json 然后 continue，整批不退出。
- --resume（断点续跑：从中途断掉的地方接着跑，已完成的图不再重做）：重跑时 done 集合加载已落盘成果，命中即 skip。

## 三、B 段：自动核查前置（AI 智能体干脏活）

A 段只负责"把图读出来"，读得对不对、有没有问题，交给 B 段。B 段是一套自动核查前置，由 AI 智能体（能自主调用读图与比对工具的智能体程序）跑一套结构化检查：

- 建立 R49 基线：以本轮重审的参考版本为基线，所有图都对齐到同一基准，避免拿旧版当新版查。
- 跑 R28 三关：对每张图执行三道检查关（规范性、一致性、完整性），把疑点转成结构化信号。
- 跨图比对：同一专业不同图号之间、不同专业之间做交叉核对，找出"单图看不出、跨图才暴露"的矛盾。

B 段还提供一个 `--strict`（严模式）开关，用来压住假阳性——把把握不大的疑点降级或过滤，不让"虚惊一场"的信号淹没真正的问题。命令如下：

```bash
python verify_stage_b.py --input read/ --baseline R49 --strict
```

B 段产出的不是"人话结论"，而是一份信号清单：图号、信号类型、位置、置信度。这份清单是后面 C 段的原料，也是 G 段齐套比对的附注来源。说到底，把脏活交给 AI 智能体去跑，人只审它吐出来的信号，才是长任务可持续的姿势。

## 四、G 段：齐套性自动比对（别让缺张溜过去）

A 段读图、B 段核查，但还有一个最容易被忽略的问题：本次该有的图，是不是全齐了？这就是齐套性（一套图纸/资料是否完整、不缺张不缺专业）。

G 段扫一遍 A 段落盘的 read.json，汇总"实际读到的图号集合"，再和一份"期望目录集合"比对，自动算出 EXPECTED 矩阵的齐全度百分比。伪代码：

```python
def check_completeness(read_dir, expected_set):
    actual = {p.stem.split(".")[0] for p in Path(read_dir).glob("*.read.json")}
    missing = expected_set - actual
    pct = len(actual & expected_set) / len(expected_set) * 100
    return {"missing": sorted(missing), "completeness_pct": round(pct, 1)}
```

把期望目录写进 manifest 的 `expected` 字段，G 段就能一键报出"缺了哪几张、齐全度多少"。这步放在成稿前，能拦住"图没读全就出了意见"的低级事故。三专业之间靠提资（专业与专业之间互相提交设计资料）对齐接口时，缺一张提资图往往意味着接口对不上，G 段能在成稿前先把它揪出来。

## 五、C 段：意见初稿半自动（人只补最后一列）

C 段消费 B 段的信号清单，产出一份六列审查意见初稿 markdown。六列分别是：

- 图号：来自 B 信号清单的图号字段。
- 位置：信号标注的图纸位置（如某轴线、某标高）。
- 问题描述：把结构化信号翻成一句人能读的话。
- 等级建议：按信号置信度与影响面，给出 A/B/C/D 等级建议（A 最严重）。
- 规范依据：关联到的条款，如 JGJ57（《剧场建筑设计规范》，住建部发布的行业标准）或 WH/T（文化行业推荐性标准，由文化和旅游部发布）相关条文。
- 人工复核栏：留给专家最终确认的一列，初稿阶段刻意留空。

C 段有三个硬约束：禁词清零（初稿里不能出现内部黑话，统一改用"AI 智能体自动核查"等可读表述）；等级建议必须给出，不空白；人工复核栏留空，绝不在初稿阶段替专家下结论。

下面是一行初稿的样子（仅示意字段，不含具体工程数据，且放在代码块内避免渲染问题）：

```markdown
| A-01-ARCH | 轴线③交轴线C | 舞台口净宽与台口高度比值偏小 | B | JGJ57 相关条文 | （待复核）|
```

注意：这一行的"待复核"就是人工复核栏的留空占位，不是 AI 智能体替人拍板。C 段只做"信号→可读初稿"的搬运与格式化，不替专家写最终结论。

## 六、一键串联：run_ab_pipeline.py --with-c --with-g

四段各自能跑，但每次手工串四个命令既慢又易错。我们已经落地了一键串联脚本：

```bash
python run_ab_pipeline.py \
  --manifest manifest.json \
  --with-b \
  --with-g \
  --with-c \
  --resume
```

`--with-c` 和 `--with-g` 控制是否纳入 C、G 两段；`--resume` 保证中断后续跑不重做。四个开关组合，覆盖了"首次全跑""补跑中断""只出齐套报告"等多种工况。一键串联的本质，是把"人记步骤"变成"脚本记步骤"，进一步降低长任务出错概率。

## 七、实证：某城市交响音乐厅 218 页三专业重审

说一个落了地的例子。某城市交响音乐厅项目，一轮三专业（建筑、结构、舞台工艺）重审，共 218 页 DWG。当天要出重审意见，时间紧。

我们按上述四段编排：A 段用 manifest 派单 218 张，B 段跑 R49+R28+跨图核查并开 --strict，G 段比对齐全度，C 段出六列初稿。中途第 143 张舞台工艺图（涉及吊杆（剧场舞台上空悬挂布景、灯具的杆状承重构件）排布与调光柜（剧场灯光系统中存放调光模块、分配电力的设备柜）供电路由）因一个 DMX512（舞台灯光与吊挂设备通用的数字控制协议）地址标注异常抛错——但因为 A 段做了失败隔离，整批没崩，这张被记进 .fail.json 后继续往下跑；修好标注后加 --resume 重跑，前面 142 张已完成的直接跳过，只补了 143 及之后。

结果：218 页当天全齐套出了初稿，断点续跑让单页异常没有拖垮整批，也没有为已完成部分重复买单。这正印证了开头那句话——让脚本自己活下去，靠的不是人盯，是编排。轮次权重相对估算显示，失败隔离 + 断点续跑把"重跑已完成部分"的成本压到了接近零。

## 八、踩坑实录

**坑一：read.json 文件名带图号后缀，--resume 却认不出。**
现象：加了 --resume 仍然全量重跑。
成因：落盘文件名是 `A-01-ARCH.read.json`，而扫描时用 `p.stem.split(".")[0]` 切分，stem 已是 `A-01-ARCH.read`，再按点切得到的是 `A-01-ARCH` 没错——但某批文件被存成了 `A-01-ARCH_read.json`（下划线），切分得到 `A-01-ARCH_read`，和 manifest 的 `id` 对不上，于是全部判为未完成。
解法：统一落盘命名约定为 `<id>.read.json`（点分隔），扫描端和写入端用同一套 `id` 拼接，并加一个启动自检：打印 done 集合前 5 个，肉眼核对是否和 manifest 同形。

**坑二：B 段不开 --strict，假阳性淹没真问题。**
现象：信号清单里 80% 是"虚惊"，专家不愿意看。
成因：默认阈值过宽，把图层命名差异也报成疑点。
解法：重审场景默认开启 --strict，并把"仅样式差异、无功能影响"的类目整体降级；确需宽松时再显式关掉。

**坑三：G 段 expected 集合漏写，齐全度永远 100%。**
现象：明明少了几张，G 段报齐全度 100%。
成因：expected 为空集，交集除以空集被兜底成 100%。
解法：expected 缺失时 G 段直接报错退出，不允许"空期望蒙混过关"；并把 expected 写进 manifest 强制校验。

**坑四：C 段初稿替专家下了结论，复核栏没留空。**
现象：初稿里"建议整改"写死，专家复核时改不动。
成因：生成时把等级和结论一起固化。
解法：C 段输出约束为"等级建议 + 待复核占位"，结论列永远留空，专家在最终稿里才填。

## 九、总结

长任务崩在半路，根源往往是"把整批当成一个不可拆的整体"。我们用 A(编排)→B(核查)→G(齐套)→C(成稿) 四段把读图工具链拆开，靠 manifest 派单解决"处理哪些"，靠失败隔离解决"崩一张不炸批"，靠 --resume 断点续跑解决"修一次 bug 不必重买已完成"，靠 G 段齐套比对解决"缺张溜过去"，靠 C 段半自动初稿解决"人只补最后一列"。

回到那句话：把读图工具链拆成 A(编排)→B(核查)→G(齐套)→C(成稿) 四段，用 manifest 派单＋失败隔离＋--resume 断点续跑，让脚本在长任务里自己活下去。这不是某个工具的功劳，而是一套"让脚本自己活下去"的编排纪律——当你的任务长到会崩，纪律比聪明更重要。


你接过一个 200 多页的剧院图纸重审任务吗？三专业（建筑、结构、舞台工艺）的 DWG（AutoCAD 图纸文件格式）叠在一起，要逐张读、逐张查、逐张出意见。脚本跑起来，前 150 张都顺利，第 151 张因为一个图层名异常抛了异常——整批进程直接退出，前面 150 张的成果虽然落了盘，但后面的 68 张全没动。你改完 bug 重新跑，WorkBuddy 又老老实实把前 150 张重读一遍，token 和时间双重浪费。这就是"长任务总崩在半路"的真实代价：不是崩一次，是每修一次 bug 就要为已经完成的部分买单。

长任务总崩在半路？WorkBuddy 把读图工具链拆成 A→B→G→C 四段实现断点续跑

剧院 218 页三专业 DWG 重审，脚本常崩在半路：修一次 bug 就要重跑已完成部分。本文用 WorkBuddy 把读图工具链拆成 A 编排→B 核查→G 齐套→C 成稿 四段，靠 manifest 派单、失败隔离、--resume 断点续跑让脚本自己活下去。踩坑：命名不一致致续跑失效、--strict 没开假阳性淹没真问题。实测单页异常未拖垮整批，当天全齐套出初稿

人工智能

WorkBuddy将读图工具链拆解为A→B→G→C四段编排，通过manifest派单、单图失败隔离及--resume断点续跑机制，彻底解决长任务崩溃重跑痛点。实测218页DWG重审场景，异常中断后自动跳过142张已完成图纸，仅补跑故障后续内容，将重复成本压缩至接近零，实现长流程自动化自愈与高效交付。

代码解释

智能体

WorkBuddy 

Markdown

路由

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

长任务总崩在半路？WorkBuddy 把读图工具链拆成 A→B→G→C 四段实现断点续跑-腾讯云开发者社区-腾讯云

长任务总崩在半路？WorkBuddy 把读图工具链拆成 A→B→G→C 四段实现断点续跑

长任务总崩在半路？WorkBuddy 把读图工具链拆成 A→B→G→C 四段实现断点续跑

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐