Boomi Scribe 自动写流程文档：先把 XML 变成 DAG，再让模型解释

Boomi Scribe 自动写流程文档：先把 XML 变成 DAG，再让模型解释

Boomi 与 AWS 9 月 1 日介绍了 Scribe 的实现：它为企业集成流程自动生成概览、流程图、元数据、业务上下文和逐步说明，并比较两个版本中的新增、修改与删除。输入来自 Boomi 流程的 XML，但模型实际读取的是经过解析和整理的有向无环图（DAG），生成模型使用 Amazon Bedrock 上的 Claude Haiku 4.5。

技术文档自动化常见的失败方式，是把一个大型仓库或配置文件完整塞进上下文，再要求模型“写得全面”。Boomi 的案例采取了更窄的路径：程序负责提取节点、连接关系、版本和组件属性，模型负责把结构翻译成人能读懂的说明。确定性解析与语言生成各自承担擅长的部分。

DAG 比原始 XML 更接近文档需要的事实

企业集成流程包含连接器、数据转换、条件分支、异常处理和子流程。原始 XML 里还混有布局、内部 ID 与平台配置，直接生成容易遗漏真正的执行关系。Scribe 先把相关特征转成 DOT 形式的 DAG，节点表示步骤，边表示流向，再把过程名称、创建和修改时间、组件数量等元数据一并交给模型。

[AWS 技术案例](https://aws.amazon.com/blogs/machine-learning/how-boomi-scribe-streamlines-documentation-using-aws/)展示的输入契约明确分出任务目标、领域上下文、DAG、生成规则、输出结构和验证条件。输出顺序也提前固定：目标、可视化、流程元数据、业务上下文、步骤与功能。模型的自由度集中在解释，事实范围由解析器和 schema 约束。

这套做法能迁移到 CI/CD、数据管道、Agent 工作流和微服务调用链。团队不必让模型自己猜依赖关系，可由静态分析、OpenAPI、工作流引擎或 Trace 先生成结构化事实。若解析器不知道某个节点的业务含义，就明确标为未知，避免模型用流畅语言填补空白。

文档更新的核心是版本差异

Boomi 称已部署流程平均记录 42 个版本，中位数为 16。Scribe 会保存每次生成的 DAG 与文档，再用 Lambda 层的专有算法比较版本，列出组件级的新增、修改和删除。这个顺序比让模型阅读两篇长文后总结变化更可复现，因为差异来自结构，而不是两次生成文本的措辞变化。

企业可以把版本差异作为增量文档入口：代码或配置变更触发解析，仅更新受影响章节，同时保存生成时使用的模型、Prompt 版本和输入摘要。审阅人看到的应是“结构发生了什么变化”和“模型如何解释变化”两部分，前者可自动验证，后者需要业务负责人确认。

供应商案例称 Scribe 将文档时间最多减少 85%，并能为每位客户每天处理数百个流程。这是特定产品的案例结果，不能直接套到代码仓库或所有企业。衡量自己的效果时，应记录事实遗漏率、错误陈述数、审阅时间、版本延迟和用户反馈，而不只统计生成了多少页。

多模型接入也不能取消结构化校验

模型可能误解自定义连接器、把 GET 描述成发送动作，或将异常分支写成正常路径。上线前可用规则检查节点是否全部被覆盖、步骤顺序是否与 DAG 一致、组件名和版本号是否原样保留，再让另一个模型或人工抽样检查业务解释。独立复核适合发现语言层的错误，图结构验证负责守住事实层。

模型升级也要留回归集。挑选包含循环替代结构、并行分支、失败补偿和敏感字段的代表流程，比较不同模型的完整性、稳定性和成本。更换 Claude、GPT、GLM 或其他模型时，统一模型网关可以减少接口修改，但 Prompt、Token 预算和输出差异仍需单独评测。

AnyAIS 可以为文档 Agent 提供统一模型入口和切换能力，企业侧则应保留 XML 或代码解析、DAG 版本与审批记录。自动文档的可信度来自可追溯输入和结构化差异，模型负责把这些事实讲清楚；一旦让生成文本成为唯一事实源，更新速度越快，错误也会扩散得越快。