AI编程工具之争：架构图与模块图生成实践

在AI编程工具的讨论区，“谁最强”是一个永恒的话题。但真正动手做过实验的人都会明白一件事：早期“反复抽卡才得到一张能看的图”的困境，症结往往不在需求文档写得不好，也不在工具选错了，而在于方法没有跑通。如今大模型技术以月为单位快速迭代，八个月前的结论放到今天大多已经失效。与其追问工具排名，不如把注意力放在三个真正决定产出质量的变量上：模型底座的文本与代码能力、是否具备（或可扩展出）多模态理解能力、以及你的工作方法是否可复现。本文围绕“用AI编程助手生成功能模块图与系统架构图”这一具体场景，给出一套与具体工具弱耦合的完整实践方案。

一、工具之争的真相：决定产出质量的三个变量

第一个变量是模型底座能力，它决定了助手能否准确理解长篇功能文档、能否生成结构正确的前端绘图代码。第二个变量是模态覆盖，即助手能否“看懂”图片，这直接决定了它能否从参照图中学习风格。第三个变量最容易被忽视，却最影响结果稳定性：工作方法，包括参照物质量、文档结构化程度、任务拆解方式。三者的关系可以概括为：模型能力决定下限，方法决定你离上限有多近。当方法跑通之后你会发现，不同工具之间的差距远没有想象中大，反而是一套标准流程能让你在任何工具上都获得稳定产出。

二、核心思路：给纯文本编程助手“外挂一双眼睛”

很多团队的主力模型是纯文本大模型，出于成本与推理性能的考虑并未选择多模态版本。这类模型在理解长文档、编写渲染代码方面表现出色，但有一个硬伤：无法直接“看懂”截图。如果你把参照图直接丢给它，它要么忽略图片，要么产生幻觉式描述。

解法并不复杂：通过业界通用的工具扩展标准（一类让编程助手在对话中按需调用外部服务的协议），为助手接入一个独立的视觉理解服务，形成三层分工：

• 编程助手：负责任务编排、文档解析与绘图代码生成，是整条流水线的“指挥官”；
• 视觉理解服务：只做一件事，把图片内容转成结构化的文字描述（风格、布局、配色、元素），是“眼睛”；
• 渲染层：由助手生成的网页或矢量图形代码负责最终呈现，是“手”。

这套架构的价值在于完全解耦：视觉服务不可用就换视觉服务，模型升级就换模型，流程本身保持不变。

三、环境准备：三步接入视觉理解扩展

接入扩展的关键是理解配置的三个要素：本地桥接服务的启动方式、与助手的通信方式、服务鉴权。绝大多数编程助手的扩展配置都遵循同一结构，示意如下：

{
  "type": "stdio",
  "command": "<本地桥接服务的启动命令>",
  "args": ["<桥接服务脚本或包路径>"],
  "env": {
    "VISION_API_KEY": "你的视觉服务密钥",
    "VISION_MODE": "image"
  }
}

• type 为 stdio，表示助手与扩展服务通过标准输入输出通信，无需额外开放网络端口；
• command 与 args 描述如何启动一个本地桥接服务，由它把助手的识图请求转发给视觉服务；
• 鉴权信息通过环境变量注入，避免硬编码在配置文件中。

配置完成后，进入助手会话，执行查看扩展的命令，确认视觉扩展处于可用状态后再进行下一步。这里有两个安全建议：第一，密钥不要出现在任何会提交到代码仓库的文件里，团队协作时应使用环境变量或统一的密钥管理服务；第二，为不同使用场景分配独立密钥并定期轮换，便于审计与止损。

四、四步实操：从参照图到高还原度模块图

第一步：计划模式 + 参照图，提取视觉风格。 将助手切换到计划模式（先规划、后动手），粘贴参照图，桌面环境下常见快捷键为 Alt+V，具体以所用工具的说明为准。参照图可以是你过去手工绘制的、风格满意的任意一张图。提示AI提取四类信息：整体布局结构（分栏方式、模块排列逻辑）、配色方案（要求给出具体色值）、字号与标题层级、连线与图标风格。

第二步：让AI复述提取结果并人工确认。 这一步的价值在于把“审美”这种模糊经验显性化为“参数”。AI复述的色板、间距、层级关系经过你确认后，后续生成会严格遵循，随机性大幅降低。

第三步：提供功能模块文档。 用结构化的Markdown文档描述系统，建议包含四个字段：模块名称、模块职责、子功能清单、模块间依赖关系。文档越规整，AI的解析越稳定。

第四步：分析文档、生成计划、确认后执行。 让AI先复述对文档的理解，列出制图计划（画布尺寸、分组方式、连线规则），你确认后它再执行，最终产出以网页或矢量图形式呈现。

验收标准可以定得很苛刻：一次对话完成、无需人工修正、与参照图风格基本一致、图中模块与文档条目一一对应。 实践证明，只要风格参数提取充分，这套标准完全可以达到，这正是“从抽卡到稳定产出”的分水岭。

五、分清两种图：功能模块图与系统架构图不是一回事

维度	功能模块图	系统架构图
视角	业务视角	技术视角
核心问题	系统提供哪些能力	能力如何被实现
关注点	模块划分、职责边界	分层结构、组件交互、数据流向
目标读者	产品与业务方	研发与运维

生成前可以把这张差异表作为提示词交给AI，要求它先判断目标读者与图的定位，再决定元素粒度与连线语义。同一套四步流程，换一份架构描述文档，即可平移生成系统架构图。放在不久之前，让AI画出一张“能看”的架构图还需要反复调教；如今只要流程跑通，它已经是流水线上的常规动作。

六、从单次成功到团队级流水线

• 风格资产化：把第一步提取的风格固化为团队的“风格规范文件”（色板、布局栅格、组件样式），后续无需参照图，直接引用规范即可批量出图；
• 文档标准化：统一功能文档的模板字段，降低不同撰写者带来的解析波动；
• 资产沉淀：生成的绘图源文件与图片应与文档同库进行版本管理；团队若已在百度智能云等云平台开通了对象存储这类通用云产品，也可将图片资产统一归档，配合细粒度权限实现共享与追溯；
• 保留人工评审：AI负责“画得像”，架构是否合理、边界是否清晰，仍需要人来把关。

七、避坑清单

• 参照图质量决定上限：低分辨率或风格混杂的图会污染提取结果；
• 一次对话只做一件事：风格提取与文档出图分两轮进行，不要混在同一任务里；
• 不要给纯文本模型硬塞图片：未接入视觉扩展时，改用文字描述风格要求；
• 密钥安全：坚持环境变量注入，绝不进代码库；
• 生成后必做对照检查：逐条核对图中模块与文档条目的对应关系。

八、结语：一个稳定的评估框架

回到最初的“谁最强”之问：答案会随版本迭代不断刷新，但评估框架是稳定的，看模型底座能力、看模态覆盖与扩展性、看计划与执行能力、看成本与稳定性。工具会过时，方法不会。把“能力组合 + 标准流程”沉淀为团队资产，无论底层工具如何更替，你的产出质量都会始终在线。