用 Codex 自动生成 Visio 流程图：COM 接口与 PowerShell 脚本实战

用 Codex 自动画 Visio 流程图，这件事我最近认真跑过几轮。结论先说：它不是用 Codex 直接把图片画出来给你看，而是用 Codex 生成 Visio 能识别的脚本或文件，再交给 Visio 完成排版和保存。对科研人员来说，最值钱的部分是——你不用再对着画布一个个拖方框和箭头，只要把流程图逻辑写清楚，剩下的重复劳动可以交给自动化流程。这篇文章适合谁看？需要画流程图、架构图、实验流程图的科研人员，以及想用 Codex CLI 做桌面自动化的开发者。下面按我实际测试的顺序拆开讲。

1. 先想清楚：Codex 和 Visio 之间到底怎么“连起来”

1.1 Codex 是“生成代码的引擎”，不是 Visio 插件

很多人第一次看到这个标题，会以为 Codex 装个插件之后，说一句话就自动生成 .vsdx 文件。这个预期需要先纠正。

Codex 本质上是命令行里的 AI 编程助手，它能做的事情是：读你的文字需求、生成代码、执行命令、读写文件、甚至跑起一个小程序。但它不是 Visio 的组件，也没有官方“一键导出 Visio 文件”的专用开关。真正画在 Visio 里的方框、箭头、连线、文字，仍然需要 Visio 自己处理。

所以这里的问题就转化为：用什么方式，让 Codex 生成的内容能被 Visio 接受。想清楚这一层，后面所有步骤才不会乱。

1.2 Visio 自动化有两条常见路径：COM 接口和 XML 文件

我实际测试下来，比较稳的有两条路。

第一条是 COM 接口。在 Windows 系统里，Visio 桌面版会暴露一组 COM 接口，你可以用 PowerShell 或 Python 调用这些接口，让 Visio 在后台启动、新建文档、添加形状、设置文字、保存文件。Codex 负责写这段调用脚本，PowerShell 负责执行，Visio 负责真正绘图。

第二条是 XML 文件。Visio 早期版本支持通过 XML 描述图形内容，后续版本默认使用 .vsdx 格式，底层也是 XML 结构。你可以让 Codex 生成一个 Visio 能识别的 XML 文件，再在 Visio 里打开或导入。这条路径的好处是不依赖 COM 权限，但坏处是 Visio 的 XML schema 比较复杂，Codex 不一定每次都写得完全正确，不同版本的兼容性也需要单独验证。

我建议优先尝试 COM 接口。原因是它更直接：Codex 只需要生成“启动 Visio、加形状、连线条、保存文件”这几步操作，逻辑清晰，出错也容易排查。

1.3 为什么建议先做最小闭环，而不是直接上复杂图

科研人员最容易犯的错误，是上来就让 Codex 画一张包含十几个模块、几十条连线的完整实验流程图。结果往往是：Codex 生成脚本跑完，Visio 打开后少了一半节点，或者线条全部乱掉，这时候你根本分不清问题出在哪个环节。

我一般会先把目标拆成一个“一个方框、一个箭头”的最小闭环。目的不是产出成品，而是验证整条链路通不通。只有确认 Codex 能生成脚本、脚本能启动 Visio、Visio 能保存文件，再往复杂方向扩展。

这个思路适用于绝大多数自动化任务：先证明链路可用，再讨论规模。

2. 前置准备：Windows、Visio、Codex CLI 的安装与验证

2.1 需要哪些软件和权限

先说结论：这不是一个纯云端方案，需要本机环境支持。

• Windows 操作系统，建议 Windows 10 或 Windows 11。
• Visio 桌面版。需要是完整安装的桌面应用，不能是网页版或只读查看器。
• Codex CLI。这里指的是 OpenAI 提供的命令行编程工具，需要能正常安装和登录。
• PowerShell。Windows 自带，版本至少 5.1 以上。
• 可选：Python 3 和 pywin32。如果你更熟悉 Python，也可以用 Python 调 COM，但这不是必须的。

权限方面，需要注意两点。第一，PowerShell 执行脚本可能需要调整执行策略，如果直接跑 .ps1 报错，可以先用 Set-ExecutionPolicy -Scope CurrentUser RemoteSigned 放行本地脚本，具体以你的安全策略为准。第二，Visio COM 调用需要在当前用户环境中能启动 Visio，如果用的是受限账号或者 Visio 授权没激活，后台启动经常会失败。

注意：不要一上来就同时折腾 PowerShell、Python、COM 三套方案。先选一套最顺手的，我用 PowerShell 跑通过，所以下面的示例也用 PowerShell 写。

2.2 Codex CLI 安装和登录的基本流程

Codex CLI 的安装方式主要有两类：一类是通过 Node.js 的 npm 包安装，另一类是直接下载官方发布的二进制程序。本机如果已经有 Node.js，用 npm 安装是常见路径；没有 Node.js 就考虑用二进制版本。

安装细节我不在这里展开太多，因为官方文档更新比较频繁。你需要确认的三件事是：

1. codex 命令在当前终端里能被找到。
2. 登录认证已经完成，比如通过 codex login 或首次启动时的交互流程。
3. 终端能正常访问 Codex 服务端。如果登录时一直转圈或者报连接失败，优先检查网络连通性、账号凭据和服务地址配置，不要先怀疑本机防火墙。

另外，如果你用的是模型服务商提供的自定义接口，可能需要在配置里填服务地址和模型名称。这类配置不同组织差异很大，建议以你实际使用的服务说明为准。

2.3 验证 Visio 自动化接口是否可达

在让 Codex 动手之前，我建议先手动确认 Visio COM 接口能正常启动。

打开 PowerShell，执行：

powershell复制$visio = New-Object -ComObject Visio.Application
$visio.Visible = $true

如果执行后能看到 Visio 程序启动，说明 COM 接口可用。如果报错，通常是这些原因：

• 本机没有安装桌面版 Visio，或者版本太旧。
• PowerShell 是 32 位而 Visio 是 64 位，或者反过来，位数不匹配。
• 当前用户权限不足以创建 COM 对象。
• Visio 授权没有激活，启动后被系统拦截。

这一小步能省下后面大量排查时间。因为一旦 Codex 生成脚本跑失败，你会先怀疑 AI 写得不对，但实际上一半概率是环境问题。

验证完成后记得把 Visio 关掉：

powershell复制$visio.Quit()
[System.Runtime.InteropServices.Marshal]::ReleaseComObject($visio) | Out-Null

2.4 初始环境验证清单

下表是我每次换机器后会快速过一遍的检查项，你可以直接抄下来当清单用。

把这些项都过一遍，通常十五分钟以内能完成。不要怕慢，这个环节省下的时间是后面对数倍。

3. 最小可运行示例：让 Codex 生成一个流程图

3.1 给 Codex 的提示词怎么写

最小闭环的目标是：生成一个 PowerShell 脚本，脚本能调用 Visio COM 接口，在空白页上画一个“开始”方块，再画一个“结束”方块，用一条箭头连接，然后保存成 .vsdx 文件。

我给 Codex 的提示词措辞大概是这样的：

text复制请用 PowerShell 写一个脚本，要求如下：
1. 通过 COM 接口启动 Visio，并设置为可见。
2. 新建一个空白绘图画布。
3. 在第 1 页上添加两个形状，分别设置文字为“开始”和“结束”。
4. 用连接线将两个形状连接起来。
5. 将文件保存到 E:\work\visio_output\01-basic.vsdx。
6. 保存后退出 Visio，并释放 COM 对象。
请给出完整可运行的 PowerShell 脚本。

注意几个措辞要点。一定要指定“PowerShell”和“COM 接口”，否则 Codex 可能给你生成 C# 项目或 Python 脚本，你还要额外处理编译和依赖。一定要指定保存路径，否则它可能只是把脚本打印出来，不真正写文件。一定要说“保存后退出 Visio，释放 COM 对象”，否则脚本跑完后进程会一直挂着。

3.2 生成脚本后的保存和检查

Codex 执行过程中会显示它做了什么操作。如果它直接生成了一个 .ps1 文件，打开看一下内容。如果它只在对话里输出代码，你需要自己把它保存成 01-basic.ps1。

我在本地通常会建立一个这样的目录结构：

text复制E:\work\visio_output\
  01-basic.ps1
  output\

脚本放在根目录，生成的文件统一放进 output\ 子目录。这样批量跑起来不会把脚本和成品混在一起。

打开脚本后，重点看几件事：

• 有没有创建 Visio.Application 对象。
• 有没有调用 Documents.Add 新建文档。
• 有没有 SaveAs 操作，路径是否和你的目录一致。
• 有没有 Quit 和释放对象的语句。

如果这些都在，就可以运行了。如果 Codex 写了一个看起来像伪代码的东西，直接告诉它：“这是不完整代码，请生成可直接运行的 PowerShell 脚本”，比你自己动手改更快。

3.3 运行脚本并检查结果

在 PowerShell 里执行：

powershell复制powershell -ExecutionPolicy Bypass -File E:\work\visio_output\01-basic.ps1

用 Bypass 是为了避免本地执行策略挡住脚本，但它不是长期方案。确认没问题之后，建议还是把执行策略配置好，不要每次都绕过安全策略。

执行完去看 output\ 目录。如果生成了 01-basic.vsdx，用 Visio 打开，确认里面有两个形状和一条连接线，任务就算跑通了。

我实际测试时遇到过一个典型情况：脚本执行没有报错，但 output 目录里是空的。检查后发现 Codex 生成脚本时用的是相对路径，但 PowerShell 的工作目录并不是 E:\work\visio_output，所以文件被保存到了别的地方。解决办法很简单，在脚本开头加一行：

powershell复制Set-Location "E:\work\visio_output"

保证所有相对路径都从项目根目录出发。

3.4 第一次跑失败的常见顺序

如果这次最小测试没通过，不要急着改代码，按照下面的顺序排查。

• 先看是否有 Visio 进程起来。如果完全没有启动，是 COM 环境问题。
• 再看是否报“找不到文件”或“访问被拒绝”。这通常是目录、权限问题。
• 再看是否报自动化接口相关错误。这通常是脚本里调用了本机 Visio 版本不支持的方法。
• 最后才看形状位置、连接线方向这类绘图内容问题。

这个顺序很重要。很大比例的错误并不是 Codex 逻辑写得不对，而是环境和路径问题。

4. 从“画一张图”到“按描述自动画整套科研流程图”

4.1 科研绘图可以拆成哪些可描述模块

流程图只是科研绘图中最基础的一类。实际需求还包括实验步骤图、系统架构图、数据分析流水线、组织架构图、泳道图等。

这些图拆开来看，元素类型并不多。我把常见需求整理了一下：

想清楚你画的是什么图，才能把需求转成文字描述。Codex 不是读心术，它只能从你的文字里提取信息。科研人员最擅长的是逻辑思考，这部分恰恰是自动化的前置条件。

4.2 用外部需求文件驱动 Codex

如果只是一张图，直接在对话里描述就够了。但科研绘图经常是多张图，今天改一版，明天换一个实验条件再画一版。这时候最好的做法不是反复在对话里说，而是把图表需求写成一个文件，让 Codex 读文件再生成脚本。

我习惯用 JSON 描述单张图的节点和连线。一个简单示例是：

json复制{
  "nodes": [
    { "id": "start", "label": "开始", "shape": "rectangle" },
    { "id": "process", "label": "数据处理", "shape": "rectangle" },
    { "id": "end", "label": "结束", "shape": "rectangle" }
  ],
  "edges": [
    { "from": "start", "to": "process" },
    { "from": "process", "to": "end" }
  ]
}

然后让 Codex 读这个文件，再生成对应的 PowerShell 绘图脚本。好处是数据结构化成独立文件后，改图只改 JSON 不改代码，Codex 的生成任务变得更稳定。

这一步是“从单张图到批量绘图”的关键转折点。很多人停在“每次让 Codex 直接写死数据”的阶段，所以每次都要从头生成，又慢又容易出错。

4.3 生成可复用的模板脚本

跑过几轮之后，我建议强制让 Codex 把脚本模板化。核心目标：把“每个节点的坐标、名称、连线关系”全部提取成变量或外部数据，脚本本身不再关心具体图内容。

比如要求：

text复制请把脚本改造成模板形式：
- 从 data.json 中读取节点和连线。
- 根据节点数量自动布局，不要写死坐标。
- 每个节点的文字来自 label 字段。
- 保存文件名根据输入参数生成。

这样做的好处显而易见。后续新增一张图，只需要新增一个 JSON 文件，然后用同一套脚本跑一遍。Codex 的价值从“每次帮你写脚本”变成了“帮你维护脚本和数据文件的对应关系”，效率和可维护性高出很多。

需要注意，自动布局是这里面最不稳定的部分。Visio 本身有自动布局功能，但不同版本的位置算法不一致。Codex 生成的脚本如果自己计算坐标，第一次可能很整齐，第二次节点一多就重叠。我的应对办法是：先用少量节点验证布局公式，不要一开始就指望 20 个节点自动排得很漂亮。

4.4 程序化调整字体、颜色、形状和连线样式

科研图表对字体、线条粗细、颜色往往有固定要求。Codex 的脚本里可以设置这些属性，但你需要明确告诉它，不然默认效果很可能不符合期刊要求。

例如在 PowerShell 脚本中，可以设置形状文字、填充颜色、线条样式。这类设置不同 Visio 版本的方法差异比较大，建议在项目开始时先用文档里的“样式检查”功能手动确认一次，再把对应操作固化到脚本模板里。

我一般会在模板里固定：

• 字体统一为“宋体”或“Arial”。
• 字号统一，例如正文 12pt，标题 16pt。
• 形状填充色使用统一 RGB 值。
• 连接线使用直线或折线，不用贝塞尔曲线。
• 判断节点统一用菱形，普通处理节点用矩形。

这些看起来是细节，但批量生成时，统一风格比“每一张图都不同”更重要。科研图表的排版一致性，最终会体现在论文的整体观感上。

5. 批量出图：多张 Visio 自动生成的工程化思路

5.1 先跑单图，再跑批量

能生成一张图之后，很多人会迫不及待地把十张需求一次性塞给 Codex。这是一个常见的翻车现场。

原因是：单图脚本里路径、文件名、节点数据都是写死的。改成批量后，任何一个文件路径出错、一个 JSON 字段缺失、一次 COM 对象未释放，都能让后面的图全部失败。如果不先验证单图，等于同时引入了数据问题和运行问题。

我的建议是分三步：

1. 跑通一张图，确认脚本、数据、输出路径都正确。
2. 准备两张图的测试集，覆盖不同节点数量和分支逻辑。
3. 扩大到全部图，并加入日志和失败记录。

只有到第三步，才算是真正的批量任务。

5.2 输出命名、子目录和日志

批量任务最容易被忽略的是输出组织方式。假设你生成了 20 张图，全部叫 output.vsdx，那后面整理文件就是灾难。

建议输出目录按需求文件名称一一对应。例如输入数据是 data/exp01.json，输出就是 output/exp01.vsdx。文件名保持一致，方便追踪。如果同一张图有多个版本，再追加版本号或时间戳。

同时，脚本每一步都要写日志。最简单的做法是在 PowerShell 里输出关键节点：

powershell复制Write-Host "[INFO] 开始处理 $jsonFile"
# 绘图逻辑
Write-Host "[INFO] 保存 $outputFile 完成"

如果是十万火急的需求，可以暂时不弄日志。但只要批量超过 5 张图，没有日志的话，失败时你根本不知道哪一张没生成，就只能全部重跑。

5.3 失败重试和人工检查点

批量任务中，单张图失败是常态。失败原因可能是数据文件格式问题，也可能是 Visio 某个版本 bug，或者是脚本本身在特定数据下没处理好。

我把失败情况分成两类：

第一类是脚本执行报错。这种情况通常要继续跑后面的图，不要让一张失败中止整个批次。可以用 try-catch 捕获异常后继续下一个文件。

第二类是脚本没有报错但输出内容不对。比如每个节点都重复、连接线缺失、文字没有写进去。这种情况脚本继续跑没有意义，需要停下来检查模板或数据。如果自动流程无法判断绘图正确性，就需要设置人工检查点。

我实际使用的做法是：每次批量跑完后，生成一个结果汇总表，列出每个输入文件、是否生成了输出文件、脚本是否报错、输出文件大小。文件大小可以被当作粗糙的检查指标，比如小于 10KB 的很可能缺少内容。

5.4 不要盲目拉满并发

Visio COM 自动化有一个坑：多个 Visio 进程同时启动会互相干扰。尤其是旧版本 Visio，多个 COM 实例抢同一个文档对象时，会出现随机失败。

我实际测试中，并行跑三个任务就出过问题：第一个任务保存的文件被第二个任务覆盖，还有一个任务报“对象已被释放”。这不是 Codex 写脚本的问题，而是 COM 对象在多进程场景下的固有风险。

更稳妥的做法是串行执行。即使你的机器性能很强，也不建议同时启动太多 Visio 实例。如果确实要并行，建议每个任务启动独立进程并隔离输出目录，但复杂度会明显增加，初期不需要。

6. 常见问题和排查顺序

6.1 Codex 安装和登录阶段的问题

如果你在“安装-登录-进入对话”阶段就卡住，后面所有绘图都无从谈起。

常见报错包括：codex 命令找不到、登录时一直转圈、模型配置不被支持、启动后自动退出。排查顺序我建议如下：

• 先确认安装是否真的成功，输入 codex --version，能输出版本号说明基本安装完成。
• 再确认登录状态，有些版本是通过浏览器授权完成认证的。
• 如果登录失败，优先检查终端网络连通性、账号凭据和服务地址配置。
• 如果你配置了自定义模型端点，需要确认模型名称是否被当前服务端支持。原始报错里如果出现类似“model is not supported”的提示，问题通常出在模型名或者服务端能力上，而不是绘图脚本本身。

不要把这类问题误判成 Codex 不会画 Visio。工具本身没有进入工作状态，画图的讨论是没有意义的。

6.2 生成的脚本在 Visio 端报错

脚本已经生成，运行时报 COM 错误，这种情况要看几个点。

首先是位数问题。PowerShell 有 32 位和 64 位之分，Visio 也有位数之分。两边不一致时，COM 对象可能创建失败。你可以打开 PowerShell 检查 [Environment]::Is64BitProcess 是真的还是假的，再和 Visio 安装版本对比。

其次是 COM 对象释放问题。脚本反复执行但进程没有退出，第二次跑就会报“服务器还在运行”之类的错误。失败后先打开任务管理器，看有没有多个 VISIO.EXE 残留，有的话先结束掉再重跑。

最后才是脚本语法问题。Codex 生成的 PowerShell 脚本偶尔会用错参数名。如果报错信息指向某一行，把那一行和错误内容复制回去让 Codex 修改，通常比手查更快。

6.3 生成的图能打开，但内容和需求不一致

这是更隐蔽的问题。脚本没报错，Visio 也能打开，但节点数量不对、文字缺失、连接关系错误。

我的排查经验是：先检查输入数据，再检查脚本逻辑，最后才检查 Codex 的输出。

科研绘图中，最常见的原因是 JSON 或文本描述本身不完整。比如你写了“A 和 B 有联系”，但没有说明箭头方向，Codex 就可能生成从 B 指向 A 的连线。你心里有图，但机器只能从文字里推断，这就是信息丢失。

还有一种是脚本模板问题。如果模板写得不够泛化，新数据里某个节点没有 label 字段，脚本默认生成一个空字符串，视觉上就是“有框没字”。这时把数据里缺失字段补齐即可。

6.4 格式迁移和扩展：从 Visio 到其他绘图工具

虽然标题是 Visio，但在实际项目中，你可能会遇到目标平台不支持 Visio 文件的情况。比如合作方要的是图片，期刊要求矢量图，导师只想看 PNG 预览。

这时候不建议让 Codex 绕过 Visio 去重新实现绘图逻辑，而是在 Visio 出图后写一个导出步骤。Visio 可以另存为 PDF、PNG、SVG 等格式。PowerShell 脚本可以在保存 .vsdx 后，再调用导出接口把当前页面导出成图片，这样同时拿到可编辑文件和预览用图片。

如果项目非常依赖自动化批量出图，也可以考虑让 Codex 先生成更通用的图形描述，比如 Mermaid 文本或 JSON 结构，再由另一套工具转成图片。这可以作为备选方案，但不必替代 Visio。原因是 Visio 在排版精细度上仍然有优势，尤其在复杂流程图场景。

6.5 边界提醒：哪些图不适合全自动

自动化绘图不是万能药。我做完这一轮测试后的明确感受是：适合自动化的场景，是结构清晰、元素类型固定、重复度高的图。比如实验步骤流程图、数据管道图、平台架构图。

不适合自动化的场景包括：

• 需要大量手绘风格、自由摆布元素的概念图。
• 需要精细视觉设计、讲究配色和留白的论文插图。
• 带有大量自定义图标、贴图和艺术效果的海报式图。

这类图更适合先用 Visio 手工搭建一版，再由 Codex 生成可以复用的模板。不要为了自动化而自动化，否则你花在修正脚本上的时间，会比手工画图还要长。

回到开头的问题。 Codex 自动画 Visio 真正解决的不是“动动嘴就出图”，而是把那些你已经很清楚结构、但重复操作极其繁琐的绘图过程，变成“改数据文件 + 跑脚本”的模式。对科研人员来说，这个转变的价值在于：你花一次时间把绘图逻辑固化下来，之后每次实验条件变化，只需要更新数据和重新执行，不需要再从画布空白处开始。

我个人更建议把第一次目标定小一些。先用一个方框一个箭头跑通，再扩大到 10 个节点，最后才尝试整套论文流程图。很多人上来就让 Codex 直接生成整篇论文插图，最后浪费大量时间在修格式上。真正把批量跑稳之后你会感觉到：最难的不是工具组合，而是把绘图需求描述成机器能执行的结构化内容。这也是我会继续投入时间和精力去优化提示词、数据文件和模板脚本的原因。