ARTICLE · 980241
WorkBuddy + 接口文档,一键自动配置 E10 连接器
一份接口文档 + 一条命令，E10 ESB 中心的连接器、连接、接口全部建好
周五下午，开发甩过来一份「合同组织信息查询接口」文档，5 个接口，参数带嵌套对象。
按老路子，我得先建连接器、再配连接、再一个个把接口点出来——抄 method、抄 path、抄参数。抄到第三个接口的时候，我已经在算「漏一个字段，调用报错，排查要多久」了。
后来我换了个思路：把接口文档直接丢给 WorkBuddy，让它自动在 E10 里把连接器、连接、接口一次性建好。
结果：10 个接口的活儿，从 1~2 小时压到了几分钟。这篇文章就聊聊这条路子怎么走，踩了哪些坑。
一句话省流：建连接器 → 配连接 → 建接口，这套「照着文档点点点」的流程，可以完全交给 AI。你只负责两件事：审一遍模型、跑一条命令。
一、先看痛点：手工建连接器，到底繁琐在哪
以「合同组织信息查询」为例，假设文档里 5 个接口，手工建的过程是这样的：
打开 ESB 中心 → 新建连接器，填名称、描述； 切到连接，填基地址； 切到接口，新建第一个接口，填 method、path； 点开参数表，把请求参数、响应参数一条条抄进去； 重复第 3、4 步，直到 5 个接口全部配完。
如果参数里还有嵌套结构——比如响应里是个对象数组——抄起来更是灾难：漏一个字段，调用就报错，排查半天。
痛点就三个：抄得累、容易错、改起来烦。 一个接口还好，十个、二十个呢？半天就耗在点表单上了。
二、WorkBuddy 怎么干：一份文档，一键落地
我做了个技能（Skill），干的活就是把「接口文档」直接变成「E10 里的连接器」。
支持输入的文档格式：Markdown、Word、纯文本、OpenAPI、Postman。开发甩来的 markdown 接口说明，还是标准的 OpenAPI / Postman 导出，都能吃。
工作流长这样：
0. 确认 E10 环境可用1. 解析文档 → 归一化连接器模型（model.json）2. 人工复查模型（show-model，缺啥补啥）3. 推送创建（先 dry-run 演练，再真推）一命令就搞定：
跑完最后一条命令，控制台打印出连接器 ID 和成功创建的接口数。回到 E10 界面刷新，连接器、连接、接口全都在了。
三、几个值得一看的技术细节
这个技能不只是「套了个壳」，几个容易踩的坑都提前处理了：
1. 接口地址占位符要带 $
文档或 OpenAPI 里通常写 {var}，但直接写进 E10，URL 变量解析不到，调用时不会替换。技能会自动规范化成 ${变量名}，不用手动加。
2. 全链路按名称幂等
连接器、连接、接口三级都先按 name 查重，命中了就复用、不重复建。同一份文档反复跑，不会堆积重复对象。交付里脚本重跑是常态，幂等才是王道。
四、效率到底提升多少
数字不一定精确，但方向明确：把「抄参数」这种纯体力活交给 AI，把「审模型、补缺口」这种判断活留给人。
五、说点实在的：AI 到底帮了什么忙
很多人觉得「AI 二开」是噱头。但这次连接器这个事挺有代表性——它帮我省掉的不是「思考」，是「重复」。
解析文档、生成模型，是 AI 的强项； 复查模型、确认语义对不对，是人的强项； 真正推送创建，靠的是摸清 E10 后台接口，这是「落地」的最后一公里。
三者合起来，才是一套能用的东西。AI 不是替你做决定，而是把你从繁琐的配置里解放出来，让你把精力花在该花的地方。
在 E10 这种配置项多、层级深、还带版本差异的系统里，「自动化落地」的想象空间还很大。连接器只是一个开始，后面的动作流、表单、门户，都有类似的机会。
结尾
如果你的工作里也有一堆「照着文档在系统里点点点」的活儿，不妨想想：能不能把它变成「一份文档 + 一条命令」？
拥抱 AI，不是为了赶时髦，是为了把时间花在真正需要人的地方。
三个小问题，评论区聊聊
你最近有没有被「照文档抄参数」这种活折磨过？ 你手头最想自动化的 E10 环节是哪个？动作流、表单，还是门户？ 把文档交给 AI 自动建配置，你最大的顾虑是什么？
回复「连接器」，我把这次用的技能包发你。