Codex自动化Visio绘图：科研流程图脚本化生成全攻略

科研绘图里最磨人的一幕，往往不是数据处理，而是那种只有五六个框的流程图。为了对齐一个箭头，你可能会在 Visio 里来回拖十几分钟；导师一句“样式统一一点”，整张图又得重排。更麻烦的是，这类图没办法像代码一样提交到 Git，改过一版以后，上一版去哪了根本说不清。如果你正在写论文、做课程设计，或者维护一份经常要更新的技术文档，大概率已经经历过这种“画图半小时，改图一小时”的痛苦。

Codex 这类 agent 化的 AI 编程工具出现以后，这件事完全可以用另一种方式做：把“画 Visio 图”变成“写一段生成 Visio 图的脚本”。脚本可以被反复执行，能进 Git，能放进自动化任务里，想改图只需要改坐标和文字再跑一次。本文要给出一个明确判断：Codex 真正值得关注的，不是“自动补全代码”这种单点能力，而是它能把 Visio 这类桌面工具当作一个可编程的渲染引擎。

这篇文章会按一条可落地的路径展开：先说明 Codex 是什么、怎么安装和登录，再对比“用脚本调用 Visio COM 接口”和“直接修改 .vsdx 文件”两条自动化画图路线，给出可运行的 Python 示例，最后集中整理 Codex 安装、模型配置、网络连接、文件损坏等高频问题。如果你近期要给论文、项目文档或课程设计画流程图，这篇文章可以直接当手边操作手册用。

1. 为什么说 Codex 适合处理科研绘图问题

科研绘图有三个特点：单个图并不复杂，版本却迭代频繁，最终成果还要被别人反复查看。手动拖拽出来的 Visio 文件很难同时满足后两个特点。

首先是可重复性差。手动画的图，框的位置、连线的弧度、字体的间距都藏在鼠标动作里，没有“参数”可言。下次想批量生成十张不同实验条件的流程图，只能一张一张改。其次是版本管理难。Visio 的 .vsdx 文件是二进制加 XML 的混合体，Git 虽然能追踪变化，但 diff 出来基本没法读，想回滚到某个历史版本只能靠文件名后面的日期后缀。最后是协作成本高。学生画完发给老师，老师提意见，学生再改，中间反复的沟通成本很容易超过画图本身。

Codex 的解决方式是把“图”变成一段可执行的代码。画几个框、连几条线、写什么文字，全部用脚本描述；脚本进入 Git 之后，和普通代码一样可以 review、可以回滚、可以复用。你需要多版本输出时，只要改一个参数列表，再运行一遍脚本即可。这里很容易被误解的一点是：Codex 并不是替你做艺术设计，它只是把“重复调整坐标”的手工劳动拿掉了，把 Visio 变成“定义即生成”的工具。

所以，这篇文章最合适的读者有三类：需要频繁产出论文流程图的科研人员；要维护项目架构图、部署图、技术路线图的后端或算法工程师；以及想把绘图工作流放进自动化脚本里的进阶开发者。如果你只是偶尔画一张图，手动拖也行；但只要你有“批量出图、多版本维护、随时回滚”的需求，就值得学习这套思路。

2. Codex 的基本概念、安装与登录

2.1 Codex 到底是什么

先把概念说清楚。Codex 是 OpenAI 推出的编程代理工具，典型形态是命令行工具或桌面应用。它的关键特征不是“聊天”，而是“执行”：它能读取你的项目文件，运行你要它运行的命令，编辑代码，然后根据终端输出判断下一步该怎么改。

过去我们用聊天式 AI，拿到的是文本片段，之后建文件、复制粘贴、运行、看报错、再把报错贴回去，这些动作都需要人来做。Codex 把这串动作压缩了，它会自己在工作区里完成“尝试—观察结果—修正”的循环。这也是它被称为 agent 的原因。

举个例子。你让它“写一个脚本生成 Visio 流程图”，它不只给你代码，还可能自己创建文件、安装依赖、运行脚本，然后根据报错信息调整 API 调用。这种能力对绘图场景特别有价值，因为 Visio 自动化涉及的 COM API 细节非常多，第一次写很难没有报错，而 Codex 恰恰擅长按报错反复修。

2.2 安装：CLI 与桌面版

Codex 有两种使用方式。如果你习惯纯命令行工作流，可以安装 Codex CLI；如果你更想要一个带界面的运行入口，可以下载桌面版安装包。具体安装包以官网或官方仓库的说明为准。

如果本机已经有 Node.js 环境，一种常见的安装方式是通过 npm 进行：

bash复制# 全局安装 Codex CLI（包名以官方仓库 README 为准）
npm install -g @openai/codex

# 安装后查看版本，确认是否成功
codex --version

# 启动登录流程
codex login

桌面版则直接下载对应系统的安装包，运行后跟着初始化向导完成登录即可。出现“Windows 设置未完成”这类提示时，通常是首次初始化没有走完，重新打开安装程序跑一遍引导流程一般就能解决。

2.3 登录与配置文件

Codex 需要账号登录，登录过程中可能会要求手机验证。首次运行 codex login 后，终端会打开浏览器完成授权。如果登录不上，优先检查网络连通性、账号状态和所属组织是否有权限。

Codex 的全局配置文件通常位于用户目录下，例如 ~/.codex/config.toml。里面可以指定模型、审批策略等。下面是一个常见配置的示意，字段以你安装版本的官方文档为准：

toml复制# 文件路径：~/.codex/config.toml 示意
# 模型标识请以官方文档和账号实际可用为准
model = "your-model-id"

# 命令执行审批策略：on-request 表示需要人工确认
approval_policy = "on-request"

approval_policy 值得单独解释。on-request 模式下，Codex 想执行命令时会先请求你确认，适合刚上手的人；如果改成每次都自动允许，必须保证仓库是测试环境，否则误操作的成本会很高。刚开始使用，建议保持 on-request，等熟悉了它的行为再调整。

如果你看到终端提示 “Codex is ignoring X unrecognized configuration setting”，说明配置文件里出现了当前版本不认识的字段。处理方式很简单：看提示中提到的字段名，把它删掉，或者把 Codex 升级到支持该字段的版本。

3. 核心思路：两条把 Visio 画图代码化的路线

Visio 不是为自动化而生的软件，但它的文件格式和对 COM 接口的支持，给自动化留了两扇门。这两扇门对应两条完全不同的技术路线。

3.1 路线 A：通过 COM 接口操作 Visio

Visio 和 Office 其他组件一样，暴露了一套 COM 对象模型。Windows 下安装 Visio 后，Python 可以通过 pywin32 启动 Visio 进程，在进程里新建文档、创建页面、绘制矩形、写入文字、连线，最后保存为 .vsdx 或导出图片。

这条路径的优势是“接近真人操作”，Visio 的所有绘图能力都可用，适合画带有样式的流程图、组织架构图、设备拓扑图。缺陷也很明显：必须在 Windows 系统上，并且本机必须安装可运行的 Visio。如果你平时用 macOS 或 Linux，这条路直接走不通。

3.2 路线 B：直接修改 .vsdx 文件

Visio 的 .vsdx 格式本质上是一个 zip 压缩包，里面装着大量 XML 文件。页面上的每个形状、每条连线，在 XML 里都有对应的节点。所谓“直接修改 .vsdx”，就是先把文件解压出来，找到页面 XML，修改 shape 的坐标、文字，再重新打包成 .vsdx。

这条路径不依赖 Visio 本体，因此可以在 Linux、macOS 甚至 CI 服务器上运行，非常适合作业化批量出图。缺点是 XML 结构繁琐，手写容易出错，稍微改坏一个节点，Visio 就提示文件损坏。

3.3 该选哪条路线

判断标准并不复杂：

如果你想快速跑通，选路线 A；如果要把绘图流程工程化，放进 CI 或非 Windows 机器，选路线 B。最推荐的是“模板 + 脚本”混合：先手工做一个样式统一的 Visio 模板，解压后交给 Codex 分析，再让脚本基于这个模板批量修改内容。这样既有样式保证，又具备代码化的维护能力。

4. 实战一：用 Codex 生成 pywin32 脚本自动画 Visio 流程图

4.1 先给 Codex 下达明确任务

路线 A 的实操入口是让 Codex 生成一个 Python 脚本。Prompt 写得越具体，Codex 产出的脚本越接近可用状态。下面是一个可以直接复制的任务描述：

text复制请帮我写一个 Python 脚本，使用 pywin32 调用本地 Microsoft Visio 的 COM 接口：
1. 新建一个空白 Visio 绘图；
2. 画出 4 个流程框，依次是“开始”“数据采集”“特征提取”“结束”；
3. 相邻流程框之间用带箭头的连接线连接；
4. 保存为 flow.vsdx，并把当前页面导出为 flowchart.png；
5. 代码注释要清楚，在注释里说明 Visio 默认的坐标单位。

把这段 Prompt 发给 Codex，它会先生成一个初版脚本，然后尝试运行，遇到报错再继续修。这才是使用 Codex 的正确姿势：不要期待一次成功，把它当成一个能看报错、能连续修改的执行者。

4.2 完整示例脚本

在 Windows 环境安装好 Python 和 pywin32 后，最终脚本通常长这样：

python复制# 文件路径：scripts/create_visio_flow.py
"""
生成 Visio 流程图的示例脚本。
依赖：pip install pywin32
条件：Windows 系统，本机已安装 Microsoft Visio。
"""
import win32com.client


def main():
    app = win32com.client.Dispatch("Visio.Application")
    app.Visible = True

    # 新建空白绘图
    doc = app.Documents.Add("")
    page = app.ActivePage

    # 四个流程节点的位置，坐标单位为英寸（Visio 默认页面坐标）
    # 每个节点：(文字, 左上角 x, 左上角 y, 右下角 x, 右下角 y)
    nodes = [
        ("开始", 2.0, 7.0, 4.0, 6.0),
        ("数据采集", 2.0, 5.0, 4.0, 4.0),
        ("特征提取", 2.0, 3.0, 4.0, 2.0),
        ("结束", 2.0, 1.0, 4.0, 0.0),
    ]

    shapes = []
    for text, left, top, right, bottom in nodes:
        shape = page.DrawRectangle(left, top, right, bottom)
        shape.Text = text
        shapes.append(shape)

    # 相邻节点之间画连接线
    # 3.0 是框的水平中心 x 坐标，y 坐标取相邻节点之间的空隙
    connectors_y = [(6.0, 5.0), (4.0, 3.0), (2.0, 1.0)]
    for y_start, y_end in connectors_y:
        line = page.DrawLine(3.0, y_start, 3.0, y_end)
        # 设置箭头样式，具体枚举值以 Visio 对象模型为准
        line.Cells("EndArrow").FormulaU = "13"

    doc.SaveAs("flow.vsdx")
    page.Export("flowchart.png")

    app.Quit()


if __name__ == "__main__":
    main()

这里真正容易踩坑的地方是 Visio 的坐标单位。Visio 绘图页默认使用英寸，坐标原点和很多绘图软件不太一样，如果不清楚这一点，画出来的框会跑到页面外。上面代码把节点位置写在了页面中部，同时用固定坐标画连接线，这是为了让初版脚本足够简单。实际项目里，更推荐的做法是先用宏录制在 Visio 里手动操作一次，然后把录制的 VBA 代码交给 Codex 参考，让它照着 API 生成 Python 脚本，这样程序里的对象和属性都会和你的 Visio 版本严格匹配。

4.3 如何运行

脚本写好后，在项目根目录执行：

bash复制cd scripts
python create_visio_flow.py

运行成功时，当前目录会生成 flow.vsdx 和 flowchart.png 两个文件。如果中途报错，直接把终端里的报错信息复制给 Codex，让它继续修改脚本。这一步是 Codex 和普通 AI 代码生成最大的区别所在。

5. 实战二：不装 Visio，直接修改 .vsdx 文件

如果你没有 Windows 环境，或者想把这个流程放进 CI，可以走路线 B。这条路的核心是理解 .vsdx 是一个压缩包。

5.1 .vsdx 的文件结构

把任意一个 .vsdx 文件的扩展名改成 .zip，再用解压工具打开，你会看到类似这样的结构：根目录下有 [Content_Types].xml，有 _rels 文件夹，还有 visio/pages/page1.xml。页面 XML 中记录了页面上每个形状的位置、大小、文字内容、连线关系。

这意味着：只要你会处理 XML，就等于会画 Visio 图。难点只有一个——XML 结构复杂，手写容易出错。这一步恰好可以让 Codex 介入：它能直接读取解压后的 XML 文件，理解结构，再生成修改脚本。

5.2 先写一个分析脚本

在让 Codex 动 XML 之前，先用一个 Python 脚本查看 .vsdx 内部结构，明确要修改哪些节点。下面这个脚本用标准库 zipfile 读取文件，并打印页面 XML 中的文本内容：

python复制# 文件路径：scripts/inspect_vsdx.py
"""
读取 vsdx 中的页面 XML，打印其中出现的形状文字。
用法：python inspect_vsdx.py template.vsdx
"""
import zipfile
import re
import sys


def inspect(vsdx_path: str) -> None:
    with zipfile.ZipFile(vsdx_path) as z:
        # 打印压缩包里的所有内部文件，先建立结构认知
        for name in z.namelist():
            print("[zip]", name)

        # 读取第一个页面的 XML
        page_xml = z.read("visio/pages/page1.xml").decode("utf-8")
        print("--- visio/pages/page1.xml ---")
        for m in re.finditer(r"<Text>(.*?)</Text>", page_xml, re.S):
            print("text:", m.group(1).strip()[:80])


if __name__ == "__main__":
    if len(sys.argv) != 2:
        print("用法: python inspect_vsdx.py <file.vsdx>")
        sys.exit(1)
    inspect(sys.argv[1])

运行方式：

bash复制python scripts/inspect_vsdx.py templates/template.vsdx

输出会列出压缩包内的文件，以及第一个页面上所有形状的文字。这个脚本的价值在于：你不需要一开始就去啃 XML 规范，先让脚本告诉你模板里有哪些文本，再决定要改什么。

5.3 解压与重打包工具

修改 XML 的标准流程是：先解压，修改 XML，再重新打包。下面这段代码演示了解压和打包两个动作，中间留出了修改位置。注意重新打包时，必须保证 [Content_Types].xml 位于压缩包根目录，否则 Visio 会认为文件损坏：

python复制# 文件路径：scripts/repack_vsdx.py
"""
把 vsdx 解压到目录，并在修改内容后重新打包。
典型流程：
1. 运行本脚本解压 template.vsdx
2. 在解压目录中修改 XML（可由 Codex 生成修改脚本）
3. 再次运行本脚本，把目录打包回 output.vsdx
"""
import zipfile
import os
import shutil

SRC_VSDX = "template.vsdx"
WORK_DIR = "template_vsdx"
OUTPUT_VSDX = "output.vsdx"

# 解压
shutil.rmtree(WORK_DIR, ignore_errors=True)
os.makedirs(WORK_DIR)

with zipfile.ZipFile(SRC_VSDX) as z:
    z.extractall(WORK_DIR)

print("已解压到", WORK_DIR)

# 在这里修改 XML
# 例如：用 lxml 或字符串替换修改 page1.xml
# 修改完成后重新打包

with zipfile.ZipFile(OUTPUT_VSDX, "w", zipfile.ZIP_DEFLATED) as z:
    for root, _, files in os.walk(WORK_DIR):
        for f in files:
            full_path = os.path.join(root, f)
            rel_path = os.path.relpath(full_path, WORK_DIR)
            z.write(full_path, rel_path)

print("已重新打包为", OUTPUT_VSDX)

运行解压、修改、再打包之后，用 Visio 打开 output.vsdx。如果提示文件损坏，第一件事就是检查重新打包时是否把内部文件放进了子目录，[Content_Types].xml 是否还在根目录。

5.4 让 Codex 修改 XML

有了模板和解压脚本以后，Codex 的用法就非常清晰了。把解压后的模板目录作为工作区，然后给它一个明确的修改任务：

text复制请分析 template_vsdx/visio/pages/page1.xml 的结构，写一个 Python 脚本：
1. 把页面中 4 个流程框的文字分别替换为“样本输入”“预处理”“神经编码”“结果输出”；
2. 保持所有坐标和连线不变；
3. 修改完成后重新打包为 output.vsdx；
4. 脚本需要有备份逻辑，修改前把原文件复制一份。

Codex 会读取 XML，理解 shape 节点中文字所在的标签，然后生成一个精确的替换脚本。相比之下，这里的修改范围是“文本替换”，风险较小；如果要移动坐标，务必保留原文件备份，并且每次修改后都打开 Visio 验证一次。

6. 运行结果与效果验证

6.1 路线 A 的验证

运行 python create_visio_flow.py 后，检查两点。第一，目录下是否存在 flow.vsdx 和 flowchart.png；第二，用图片查看器打开 PNG，确认页面中有四个横向排列的流程框和三条连接线。如果文件生成了但内容不对，常见原因是 Visio 页面坐标原点和预期不一致，调整 nodes 里的 y 坐标即可。如果脚本运行到一半报错，优先查看报错行是否在 COM 调用位置，再确认 pywin32 是否正确安装。

6.2 路线 B 的验证

路线 B 的验证分三层。先运行 inspect_vsdx.py，确认修改后的文本已经写入 XML；再用 Visio 打开重打包文件，确认能正常渲染；最后检查导出的图片或手动查看页面，确认坐标没有跑偏。修改 XML 最隐蔽的问题不是文本没改，而是标签配对错误导致文件损坏，所以验证顺序应该是“先看 XML 结构，再打开文件”。

无论哪条路线，失败后的第一步都不要改业务逻辑，先看三点：终端报错信息、生成文件是否存在、文件能不能被 Visio 正常打开。确定问题在哪一层之后，再决定是调整脚本、修正坐标还是检查打包结构。

7. 常见问题与排查思路

下面这张表整理了实践中出现频率较高的问题，按“现象—原因—排查—解决”展开：

表格里有一类问题要额外提醒：涉及软件授权和网络访问的问题，务必按正规渠道操作，不要使用非官方激活工具，也不要绕过所在网络的安全策略，这是工程习惯，也是合规底线。

8. 最佳实践与工程建议

把这套流程用于真实项目前，有几个工程建议值得先落地。

第一，让“模板”负责样式，让“脚本”负责内容。手工拖拽适合用来做一个高质量的母版，反复调整颜色、字体、箭头样式；母版定稿后，解压交给脚本批量修改。这样最终生成的每张图都来自同一个样式源，不会出现“这张图箭头粗一点，那张图字体小一点”的拼接感。

第二，把“生成脚本”“模板文件”“输出图片”一起提交进 Git。很多人只把最终图片存在项目里，模板和生成逻辑随手丢到某个临时文件夹，这是最可惜的。只要把这三样都纳入仓库，后续每张图的改动都能被 Git 追踪，回滚时也只需要切一个 commit。

第三，命名和路径要规范化。脚本放在 scripts/，模板放在 templates/，输出放在 output/；文件名使用类似 fig01_experiment_flow.vsdx 的规则，避免 最终版.final.really.final.vsdx 这种混乱命名。

第四，注意 Codex 的权限边界。Codex 会在工作区里执行命令，涉及安装依赖、修改文件甚至运行脚本，如果 prompt 里涉及生产数据，风险会明显放大。建议先在独立测试仓库里跑通流程，保持 approval_policy = "on-request"，不要用管理员权限运行不信任的任务。每次重大修改前，先 git commit，确保有回滚点。

第五，关于公式需求。科研流程图里经常要出现数学公式，Visio 本身支持公式插入。实践中既可以直接在 shape 里用 Visio 编辑公式，也可以让 Codex 帮你把 LaTeX 公式渲染成图片再插入到页面中。后者更可控，因为图片方式不依赖 Visio 的公式引擎版本，缺点是放大后清晰度需要注意。

9. 总结与后续学习方向

这篇文章真正讲清楚了三件事。第一，Visio 绘图不是只能靠鼠标拖拽，它可以通过 COM 接口被脚本驱动，也可以通过修改 .vsdx 的 XML 被直接编辑。第二，Codex 这类 agent 工具的价值在于“执行”，它会自己读文件、跑命令、看报错，所以非常适合处理 Visio 自动化这种 API 细节多、需要反复试错的场景。第三，无论走哪条路线，模板、脚本和输出文件都必须一起纳入版本管理，否则自动化只会制造更多混乱。

如果你接下来只做一件事，建议先拿一个手头已有的 Visio 模板，把扩展名改成 .zip 解压出来，用文中的 inspect_vsdx.py 看看页面 XML 长什么样，再把修改任务交给 Codex 试一试。这一步跑通之后，剩下的批量出图、CI 维护、多版本设计，都是顺手的事情。

Codex 与 Visio 自动化的组合，并不是什么高不可攀的技术，它只是把“画图”从手工操作变成了代码维护。对经常被导师一句“重新画”打击的科研人员来说，这可能是近期最值得花一小时掌握的小技能。建议收藏备用，下次需要批量出图时直接对照本文操作。