vscode-drawio插件本身不生成代码，仅负责图表绘制；真正实现自动化代码生成需lsp+tasks.json+模板引擎协同：插件导出xml后，由filesystemwatcher触发任务，调用cli解析并渲染代码，再通过lsp通知编辑器刷新。
vscode-drawio 这类插件本身不生成代码，它只负责图表绘制；真正让“代码生成”走向自动化的是语言服务器（LSP）+ 自定义任务（tasks.json）+ 模板引擎的组合方案。单靠一个插件点几下鼠标就自动生成可交付代码，目前并不存在——那是对自动化边界的误判。
为什么不能只靠插件一键生成完整代码？
VSCode 插件运行在受限沙箱中，无权直接读取项目全量类型信息、无法跨文件推导逻辑上下文、也不具备执行复杂业务规则的能力。比如你画了一张状态机图，vscode-drawio 可以导出 XML，但要把那张图变成带 useEffect 和 reducer 的 React 组件，中间缺三步：
- 需要
LanguageClient向后端语言服务器发起语义分析请求 - 依赖 TypeScript 编译器 API 解析当前
src/下所有接口定义 - 用模板（如 EJS 或 Handlebars）注入变量，而非简单字符串替换
tasks.json 是代码生成链路的调度中枢
它不写代码，但它决定“什么时候、用什么命令、基于什么输入”去触发生成。常见错误是把生成逻辑全塞进 command 字段，结果命令过长、不可维护、无法调试。
- 正确做法：把生成逻辑封装成独立 CLI 工具（如
gen-api-client），再在tasks.json中调用 - 必须用
args传参，而不是拼接长字符串——否则 Windows 和 macOS 路径分隔符会崩 - 若生成过程含交互（如选择模板类型），得配
"type": "shell"+"presentation": {"echo": true}，否则输入卡死 -
problemMatcher要匹配你 CLI 工具输出的错误格式，否则报错行点不开
真正起效的自动化 = LSP 响应 + 任务触发 + 模板渲染
以 vscode-drawio 为例：它导出的 .drawio 文件只是中间产物。要转成代码，需额外配置：
- 一个监听
.drawio文件保存的FileSystemWatcher - 触发
tasks.json中定义的"label": "gen-from-drawio"任务 - 该任务调用 Python 脚本，用
lxml解析 XML，再用jinja2渲染 TypeScript 接口 - 最后通过
LanguageClient发送textDocument/didChange通知编辑器刷新符号表
这整条链里，vscode-drawio 只贡献了第一个节点；漏掉任意一环，自动化就断在半路。
