ai编程工具对比图怎么做

团队要选编程工具或代码模型时，最常见的卡点是：候选一堆，但每家的官方页面和评测口径都不一样，摆在一起根本没法比。这篇不讲哪个模型强，而是给一套可复用的对比图做法——先定维度、再定取值口径、最后落成一张表或图，让讨论从「我觉得」变成「按这张表看」。

团队要选编程工具或代码模型时，最常见的卡点是：候选一堆，但每家的官方页面和评测口径都不一样，摆在一起根本没法比。有人看价格、有人看榜单、有人凭手感，讨论三轮还是回到「我觉得那个好」。这篇不讲哪个模型强，而是给一套可复用的对比图做法——先定维度、再定取值口径、最后落成一张表或图，让讨论从主观印象变成按同一张表看。

整套流程分四步：定维度、采数据、排图、定期重做。核心原则只有一条：但凡会变的数字，都不要写死在图里，只写口径和查询路径。这样图做完能撑一段时间，也不用每次调价就重画一遍。

第一步：先把对比维度定死

维度不要从工具介绍页抄，要从你自己的实际用法倒推。同一批工具里，做代码补全和做多文件改动、在终端里跑 Agent，看重的点完全不同。先写清楚团队主要怎么用，再决定哪些维度必须留、哪些可以砍。

• 通用维度清单可参考：代码能力、上下文长度、工具调用支持、协议兼容性、并发与限流、计费方式、可自建程度、数据合规
• 每个维度必须给一个可判定的取值范围，比如只写是/否/星级，避免出现没有标准的口头评价
• 维度数量控制在 6-8 个，超出就拆成两张图，否则图没人看
• 能力类维度可以直接对站内模型库和榜单的条目，但注意榜单会更新，取值以你查的当天为准
• 维度定完先让一个不参与选型的人看一遍，如果他说不出每个维度的判定标准，说明还没定死

什么情况这套维度不适用

如果你的团队用法非常单一，比如只做单文件补全，那把「Agent 支持」「多文件改动」这类维度留着只会稀释注意力，砍掉一半更清爽。反过来，如果团队里有人做后端、有人做前端、有人写基础设施脚本，用法差异大，那就别硬塞一张图，按角色拆成两张。

第二步：数据从哪来、口径怎么对齐

这一步最容易翻车的地方是：图做完两个月，价格变了、模型换代了，图变成误导。解决办法是把所有易变数据从图里拿出来，改成备注列，写上查询路径和核对日期。读者自己去看当时的数字。

能力类数据不要只抄一家榜单。官方文档、独立评测、你自己跑的小样本，各占一栏。三者冲突时不要取平均，直接把冲突标出来，反而更能说明这个维度本身就有争议。自己跑的那一栏最有说服力：拿项目里真实的十几到二十个任务，比如改 bug、加接口、写单测，跑一遍，只记录「一次过」还是「要来回改」。

1. 先列候选把候选压到 6 个以内，超过就先按硬性门槛筛一轮，别都带进对比图。
2. 填易变列价格、版本这类只填口径和站内路径，不填具体数字。
3. 跑小样本用真实任务跑一遍，记录通过情况和返工次数，作为能力列的自有数据。
4. 交叉核对官方文档、独立评测、自测三栏摆一起，冲突处标红，不强行调平。

第三步：图表怎么排才不会变成一堆数字

候选不超过 6 个、维度不超过 8 个时，表格最直观，也最容易维护。要展示更多候选，就在表格上加颜色标注，别急着上雷达图。雷达图适合给非技术同事看趋势，但维度超过 6 个就会糊成一团，而且看不出「某项其实是硬性门槛」。

• 表格第一列放候选名，其余列放维度，最后一列加备注写查询路径
• 单独留一列硬性门槛，比如必须支持某个协议、必须能走自建，不满足的直接出局，不参与打分
• 如果要出总分，先声明权重是谁定的、为什么这么定，否则总分只是把主观判断包装了一遍
• 颜色标注只用于区分「满足/不满足/待确认」三态，别用来表示强弱，颜色表强弱没人记得住
• 图做完存成可编辑源文件，比如表格或 Markdown，下次换模型只改数据行，不用重画

第四步：怎么用、什么时候该重做

图做完不是贴进文档就完事。要明确写出这张图的失效条件：官方调价、模型换代、或者你的用法从补全转成 Agent，任一发生就要重看。给图加一行最后核对日期和一个站内链接，方便后来人知道去哪页刷新数据。

团队共用时把「谁负责哪个维度」写清楚，否则每次重做都得从头问一遍。谁盯价格、谁盯合规、谁负责跑自测，分工写进图的备注里，比写在会议纪要里有用的多。

能撑住的对比图，不是因为数据填得全，而是因为易变的东西都没写死在图里。

不适用的情况也说清楚：如果你的团队用法单一、候选只有两个，直接拉个试验分支跑一周，比做图更快也更准。对比图适合候选多、口径乱、需要多人对齐的场景，不适合当个人选型的第一动作。