智能编程工具能力对比与架构图生成实践

一、问题的提出：如何客观评价一个智能编程工具

在代码生成工具层出不穷的今天，”谁更强”几乎成了一个无法用一句话回答的问题。原因在于，不同工具的设计取向差异极大：有的偏重交互式补全，有的偏重任务级代理执行，有的把重心放在多模态理解上。如果不先建立评估维度，任何对比都容易沦为个人体验的宣泄。

结合工程实践，我建议从以下四个维度建立评估框架：

1. 理解能力
指工具能否准确理解需求意图，包括对自然语言描述的解析、对既有代码库上下文的把握、对文档与图表等非代码输入的解读。理解能力决定了”返工率”——理解偏差越大，后续修正成本越高。

2. 代码质量
不只是”能不能跑”，还包括可读性、模块划分合理性、错误处理完备性、以及是否符合项目既有规范。高质量输出应当尽量少地依赖人工二次润色。

3. 生成速度
包含首字节响应时间与任务整体完成时间。对于交互式场景，前者更关键；对于任务级代理，后者才是真实体验。速度还应当与”一次通过率”结合看，否则快速产出大量待修代码并无意义。

4. 使用成本
既包括直接的调用费用，也包括隐性成本：配置复杂度、上下文长度限制带来的拆解工作量、以及为弥补能力短板而额外引入的辅助组件。

这四个维度并非并列关系。实践中，理解能力是基础，代码质量是结果，速度与成本是约束条件。脱离约束谈质量，或者脱离质量谈速度，都会得出误导性结论。

二、工具形态的演进：从补全到任务代理

回顾近两年的变化，智能编程工具的形态大致经历三个阶段：

• 行级补全阶段：以编辑器内联建议为主，开发者保持完全主导，工具只做局部预测。
• 对话式生成阶段：通过对话窗口描述需求，工具产出整段代码或整个文件，开发者负责筛选与整合。
• 任务代理阶段：工具具备计划拆解、多文件编辑、命令执行与结果校验能力，开发者从”写代码”转向”审代码”。

形态演进带来的核心变化是责任边界的转移。在补全阶段，正确性主要由开发者保证；在代理阶段，工具需要自行完成”理解—规划—执行—验证”的闭环，开发者则退居评审角色。这也解释了为什么同样的大模型能力，在不同形态的产品中体验差异会如此之大——决定体验的往往不是模型本身，而是围绕模型构建的上下文管理、工具调用与反馈机制。

需要说明的是，本文不针对任何具体商业产品做推荐或排名。下面以一个通用的智能编程代理为对象，讨论如何把它用出效果，尤其是架构图这类”非代码产出”场景。

三、关键前置：让文本模型具备视觉理解能力

许多编程代理背后的主力模型是纯文本模型，不具备图像识别能力。这在”生成架构图”场景中会成为硬约束：你无法直接把一张参考图丢给它，让它提取风格。

解决办法是引入视觉理解能力作为外挂组件。业界常见做法是通过标准化的工具调用协议，把视觉模型封装成一个可被代理调用的服务。配置思路大体如下（示意，非具体产品参数）：

{
  "name": "vision-helper",
  "command": "运行视觉服务的启动命令",
  "env": {
    "API_KEY": "你的服务密钥",
    "MODE": "VISION"
  },
  "transport": "stdio"
}

配置完成后，务必在代理内验证组件是否被正确加载——多数代理提供列出已注册工具的指令，确认后再进入正式任务。这一步看似琐碎，却是后续所有图像相关任务的前提。若跳过验证，常见后果是代理”假装”看图，实际只依据文件名或你的文字描述作答，输出与参考图风格完全脱节。

四、功能模块图的生成流程

4.1 用参考图做风格迁移

生成功能模块图时，最大的不确定性不是内容，而是视觉风格。与其用文字描述”要蓝色系、圆角、分层布局”，不如直接给一张参考图。

具体操作分三步：

1. 进入代理的计划模式（先规划、后执行），避免它边想边改。
2. 粘贴参考图。不同操作系统的粘贴快捷键不同，需按所用终端环境确认。
3. 明确指令：请提取该图的风格、布局、配色与样式，作为后续生成的视觉基线。

这一步的产出应当是代理对参考图的结构化描述，例如”三层纵向布局、主色为深蓝、模块采用圆角矩形、连线为直角折线”。如果代理返回的描述过于笼统，应当追问细化，而不是直接进入生成。

4.2 让文档驱动内容

视觉基线确定后，内容来源应当是结构化的需求文档。将功能模块文档作为输入，要求代理先分析文档、列出模块清单与层级关系、给出生成计划，确认无误后再执行。

这里有一个容易被忽略的细节：计划阶段的质量决定成图质量。如果模块划分本身有歧义，图再好看也是错的。因此我通常要求代理在计划中显式列出”模块名—职责—上级模块”三列，人工核对后再放行。

4.3 一次成图与对比验证

在视觉基线与模块清单都明确的前提下，成熟的代理往往可以一次对话完成生成，无需多轮修正。验证方法是把新图与参考图并排对比：重点看布局层级是否一致、配色是否协调、连线是否清晰、文字是否溢出。

若出现偏差，优先调整的是提示中的约束优先级，而不是反复重试。例如明确指出”布局一致性优先于配色近似”，代理的取舍会立刻改变。

五、系统架构图的生成要点

功能模块图回答”有哪些模块”，系统架构图回答”模块如何协作”。二者容易被混为一谈，实际差异明显：

维度	功能模块图	系统架构图
关注点	功能划分与层级	组件关系与数据流
元素	模块、子模块	服务、存储、网关、消息通道
连线含义	从属关系	调用、数据流向、依赖
受众	产品与研发对齐	研发与运维对齐

生成架构图时，可以不提供参考图，直接依据文档生成，但需要在提示中明确以下约束：

• 标注数据流向方向，避免双向箭头滥用；
• 区分同步调用与异步消息；
• 外部依赖单独分区，不与内部服务混排；
• 存储类组件标注读写角色。

一个可用的提示结构如下：

请基于以下文档生成系统架构图：
1. 分层：接入层 / 服务层 / 数据层 / 外部依赖
2. 连线标注调用方式（同步/异步）
3. 数据层组件标注读写角色
4. 输出为可视化的图形描述，先给结构大纲再给图

先要大纲、再要图，是控制质量的关键技巧。大纲阶段人工纠偏的成本远低于改图。

六、经验总结与可复用清单

经过多轮实践，几点结论比较稳定：

1. 工具形态比模型参数更影响体验。同样的底层模型，具备计划拆解与工具调用能力的代理，完成复杂任务的稳定性显著更高。
2. 视觉能力是扩展项，不是默认项。涉及图像输入的任务，必须显式配置并验证视觉组件。
3. 参考图优于文字描述。风格类需求用图传递，效率远高于形容词堆砌。
4. 计划模式是质量控制点。把纠偏放在计划阶段，比放在产出阶段便宜得多。
5. 能力进步很快，结论要定期刷新。半年前需要反复抽卡才能得到的结果，如今可能一次对话即可完成。因此对工具的评估应当定期重做，而不是沿用旧印象。

最后给出一份可复用的操作清单：

• 确认代理是否支持计划模式
• 若涉及图像，配置并验证视觉组件
• 准备结构化需求文档（模块清单/职责说明）
• 提供参考图并获取风格结构化描述
• 先审计划大纲，再放行生成
• 并排对比验证，偏差时调整约束优先级而非盲目重试
• 归档提示模板，形成团队内可复用的资产

把工具用好的关键，从来不是找到”最强”的那个，而是把流程拆到足以让工具稳定发挥的粒度。架构图如此，代码生成亦然。