做技术选型的人这两年大概都有同感：工具列表越拉越长，真正能落地的方案反而越来越难判断。前几年挑一个代码补全插件，试试延迟、看看补全质量就能拍板；现在不行了，一个团队可能同时在用补全、对话、终端代理、代码审查机器人四五种形态的东西，彼此还有重叠，预算单上七八个席位订阅，实际日均调用可能只集中在两个上。更麻烦的是，工具的能力边界在快速漂移——同一个编号的产品，半年前还只能改一个函数，现在能自己拉分支、跑测试、提合并请求。用旧印象做决策，翻车概率极高。

这篇内容想干的事很明确：把当下主流的 33 款 AI 编程工具按能力形态分成六类，逐类讲清楚它们各自解决什么问题、在什么团队规模下划算、哪些参数是真正该看的、哪些宣传口径可以直接忽略。同时把我自己在实际使用和陪团队落地过程中踩过的坑整理出来，包括成本估算的错法、上下文预算的误判、代理型工具最容易失控的几个环节。适合正在做年度工具预算的技术负责人、刚接手研发效能的技术同学，也适合个人开发者想搞清楚"我到底需不需要为这个付费"。

为了避免对号入座，全文用 T1 到 T33 的代号来指代具体工具，每款只描述特征、定位和短板，不绑定具体品牌。你完全可以拿着这些特征去和自己的候选清单对照，特征对上了，结论就能直接用。

1. 先把"选型"翻译成工程问题

1.1 三代能力的断层线：补全、对话、代理

市面上的 AI 编程工具看着五花八门，底层其实只有三代能力在叠加。第一代是行内补全，模型根据光标前后的代码预测下一段，特征是延迟极敏感——超过三百毫秒，人的打字节奏就断了，接受率会断崖式下跌。这一代的价值在"省打字"，对逻辑正确性没有承诺，所以它天然适合样板代码、重复结构、测试骨架。

第二代是对话式，把选中的代码片段、当前文件甚至整个仓库的检索结果投喂给模型，多轮交互。价值在"解释和改写"，比如"这段为什么死循环""帮我把回调改成 async"。它的隐性成本是人的时间：你得会提问，得会判断回答对不对，对话轮次越多，注意力消耗越大。

第三代是代理式，工具自己读文件、写文件、执行命令、看报错、再修正，形成一个闭环。这一代真正改变了工作量分布，但也引入了前两代完全没有的风险维度：不可预期的副作用。补全工具改错了，你按一下撤销就完了；代理工具改错了，可能是三个文件被覆盖、一次依赖被降级、一条命令删了目录。

所以选型的第一件事不是比价格，而是判断你的仓库具不具备"被代理安全操作"的前提。这个前提有三条硬指标：构建可复现、测试能在本地几分钟内跑完、Git 基线干净且分支策略清晰。三条缺任何一条，代理型工具带来的收益都会被回滚成本吃掉。

1.2 用五个维度给 33 款工具建立坐标系

我评估任何一款工具，最后都会收敛到五个维度上。这五个维度不是拍脑袋想的，而是反复踩坑之后发现"这几项没问清楚，后面一定返工"。

第三项和第五项最容易被忽略。很多团队在试用期只看效果，签完合同才发现计费是"席位+超额按量"，而超额部分的单价足够让财务皱眉；或者把大量约束写在某个工具专属的配置文件里，换工具时全部作废。第五项的本质是：你要沉淀的是"怎么让模型在这个仓库里干活"的知识，而不是"怎么操作某个按钮"，前者能迁移，后者不能。

提示：选型评审时，把"可迁移性"单独拎出来打分。凡是规则、模板、少样本示例只能存在它自己云端的工具，权重直接下调一档。

2. 33 款工具的六大类划分与逐类解析

先给一张总览表，把六类的定位、适配规模、成本刻度和主要短板摆在一起看。成本刻度用相对指数表示，以 T1 的单席位月费为 1.0 基准，方便横向比较。

2.1 A 类：编辑器内嵌补全型（T1-T7）

这七款的差异主要在四个点上：是否支持整函数级生成、有没有"下一处编辑位置预测"、是否带轻量仓库索引、离线降级能力如何。

T1 是最典型的纯补全型，延迟控制得最好，适合前端和高频小改动场景。它的短板是几乎不理解跨文件语义，改接口时不会提醒你改调用方。T2 在补全基础上加了局部重构能力，选中一段可以指令式改写，代价是响应慢一档。T3 主打"下一编辑预测"，你改完一个地方，它会跳到下一个大概率要改的位置——这个功能对重命名类任务效率提升明显，但它也会跳错，跳错时你如果顺手改了，就是引入了新 bug，所以必须配合"每次接受后跑一次类型检查"的习惯。

T4 和 T5 属于带仓库索引的补全型，能引用其他文件的符号定义，适合中型单体仓库。二者差异在索引更新策略：一个增量索引，改完几秒生效；另一个是定时全量，大仓库下会有延迟，跨文件补全可能引用了旧签名。T6 是轻量离线型，模型跑在本机，靠量化压缩，笔记本上能跑，质量比云端弱一截，但在网络受限或代码不允许外发的场景里是唯一选择。T7 则偏向教育向，补全会附带解释，适合新人上手，老手会觉得啰嗦。

这一类的核心陷阱是"接受率迷信"。有些团队把补全接受率当成效率指标，结果发现接受率上去了，代码评审的返工量也上去了。原因很简单：补全给出的是"看起来合理"的代码，不是"符合你们团队约定"的代码。如果你的仓库没有统一的命名规范、错误处理模式和目录约定，模型学到的就是混乱。

注意：A 类工具的收益上限由仓库一致性决定。花两天统一命名和错误处理模式，比换一款更贵的补全工具收益大得多。

2.2 B 类：终端代理型（T8-T14）

这一类是这两年变化最剧烈的。它们的共同特征是：能读写文件、能执行命令、能根据执行结果自我修正，通常以命令行交互或独立窗口的形式存在。

T8 走的是"计划先行"路线，接到任务先输出一份改动计划，你确认后才动手。这个设计看起来慢，实际上大幅降低了失控概率，我个人最推荐给刚引入代理型工具的团队。T9 更激进，直接开工，速度快，适合边界清晰的小任务，比如"把这个测试文件里的断言改成新的 API 形式"。T10 强在长任务编排，能自己拆子任务、并行跑多个方向，代价是令牌消耗成倍增长，跑一次大重构账单可能顶一周的席位费。

T11 和 T12 的差异在沙箱策略：一个默认在容器里执行，文件系统隔离，安全但每次启动有几十秒开销；另一个直接在宿主机跑，快，但命令白名单必须自己配好。T13 主打与版本控制深度集成，每次改动自动落成一个可回滚的提交，回溯非常方便。T14 面向多仓库场景，能跨仓库检索，适合微服务架构，但也最容易出现"改了 A 服务的接口没改 B 服务的调用"。

用这一类工具，我总结了三条铁律。第一，命令白名单必须显式配置，删除类、推送类、数据库变更类命令默认禁止，需要时临时开。第二，约束写在仓库内的规则文件里，不要每次对话里重复——代理跑十几轮之后会忘记你在开头说的那句话，但规则文件每轮都会被读入。第三，每次任务结束强制看一眼改动清单，尤其是被删除的行数，删除行数异常往往意味着它"简化"掉了不该动的逻辑。

# 代理型工具的典型约束配置（示意结构，各工具字段名不同） agent: mode: plan_first # plan_first | auto max_files_per_task: 8 # 超过则强制拆任务 deny_commands: - "git push" - "rm -rf" - "drop table" require_confirm: - "modify_migrations" - "touch_lockfile" rules_file: ".agent/rules.md" budget: max_tokens_per_task: 120000 warn_at_ratio: 0.8

上面这段配置里，max_files_per_task是我强烈建议加的。代理最典型的失控方式是"顺手重构"——你让它改一个函数，它觉得周边三个文件也不够优雅，一起改了。改动面越大，评审越难，回滚越痛。设个上限，超了就强制它先出计划。

2.3 C 类：Web 沙箱型（T15-T19）

这一类的形态是在浏览器里给你一个完整的运行环境，打开就能写、能跑、能预览，不需要本地装任何东西。

T15 是最纯粹的沙箱，前端项目秒开预览，适合给非技术同事演示、或者临时验证一个想法。T16 加了协作能力，多人同时编辑，适合结对和教学。T17 主打跨端预览，一次编写能看多个尺寸的渲染效果，做响应式布局时省事。T18 偏向数据与脚本场景，内置常见的分析库，跑一次性数据处理脚本很顺手。T19 是"从仓库直接开环境"型，粘一个仓库地址就能起完整环境，适合代码评审时快速验证。

这一类的短板非常明确：仓库规模有上限，依赖重的项目起不来；网络是硬依赖；代码托管在第三方环境这件事本身需要过合规评估。我见过团队用它做原型验证，效果很好，但把原型直接当生产代码用，最后迁移时发现构建配置、环境变量、路径别名全都要重写。

提示：C 类工具产出的代码，建议只当作"设计草稿"。真正入库前，在本地完整跑一遍构建和测试，别信沙箱里的绿灯。

2.4 D 类：代码审查守门型（T20-T24）

这一类不参与写代码，专门在合并请求环节做检查。

T20 做变更摘要，把一个大 PR 压缩成几段人话，评审的人上手快很多。T21 做缺陷模式识别，重点抓空值处理、资源释放、并发竞态这些经典问题。T22 专攻依赖治理，识别过期依赖、许可证冲突、升级后的破坏性变更。T23 做测试缺口分析，指出这次改动哪些分支没被覆盖。T24 是综合型，把上面几种能力打包。

这一类的关键指标不是"发现了多少问题"，而是"误报率"。误报率一旦超过某个阈值，团队就会开始无视通知，工具等于白买。我的经验是：上线初期只开一两类高置信度规则，让团队先建立"它说的有道理"的信任，再逐步放开。上来就全量开启，一周之内评论区就会被"这条不是问题"刷满。

另一个细节是：D 类工具的输出要能被机器读取。如果你的流水线想在发现问题时自动打标签、自动指派，就要确认它提供结构化输出而不是只有一段自然语言评论。

2.5 E 类：本地与私有部署型（T25-T29）

这一类解决的是"代码不能出内网"的硬约束。

T25 是本地小模型方案，跑在开发机上，参数量在可接受范围内，质量够做补全和简单问答。T26 是内网服务化部署，一个团队共享一套推理服务，统一管理模型版本和配额。T27 主打检索增强，把内部文档、组件库说明、历史决策记录建成索引，回答"我们内部这个组件怎么用"这类问题特别准。T28 是私有化的审查型，把 D 类的能力搬到内网。T29 是混合路由型，简单请求走本地、复杂请求走云端，但云端那部分通常需要脱敏。

硬件门槛要算清楚，别拍脑袋。显存占用的粗略算法是：参数量乘以位宽除以 8，得到权重占用（GB），再留出 30% 到 50% 给键值缓存和批处理。举例来说，一个 320 亿参数的模型用 4 位量化，权重约 16GB，加上缓存和上下文余量，单卡 24GB 能跑但并发很低，实际团队共享建议按每 10 个活跃用户配一张卡来估。这只是起点，真实容量还得压测。

维护成本是最容易被低估的。模型要升级、推理服务要监控、索引要重建、出问题要找得到人。没有专职的基础设施同学，我建议先用 T25 这种单机方案试水，别一上来就搭集群。

2.6 F 类：专用场景型（T30-T33）

这四款的价值高度集中在单一场景，出了场景几乎没用，但场景内效率提升非常明显。

T31 做自然语言到查询语句的转换，配合表结构说明使用，做数据分析的同事受益最大。T32 做设计稿到页面结构的还原，产出的是骨架不是成品，样式细节仍需人工调，但省掉了大量重复结构搭建。T33 专攻遗留语言迁移，把老语法逐段翻译成新语法并标注风险点，适合做渐进式重构而不是一次性重写。

这类工具最忌讳"为了用而用"。判断标准很简单：这个场景每周消耗团队多少小时？低于五小时的场景，引入一个新工具的维护成本大概率超过收益。

3. 两笔账：令牌成本与上下文预算

3.1 成本的三层结构，别只算第一层

绝大多数团队做预算时只算第一层：席位订阅费。实际上总成本是三层叠加。

第一层是席位费，固定、可预测，按人数乘月费。第二层是按量令牌费，代理型工具尤其明显，跑一个复杂任务可能消耗几万到几十万令牌。第三层是隐性人力成本，也就是评审 AI 产出的时间。这一层最容易被忽略，也最容易失控。

举个量化的例子。假设一个二十人的团队，给每人配一个 A 类席位（成本指数 1.0），再给其中八人配 B 类代理席位（指数 3.0），月度总成本指数就是 20×1.0 + 8×3.0 = 44。如果团队每天有三十次代理任务，平均每次消耗相当于指数 0.2 的令牌量，按二十二个工作日算，额外增加 30×0.2×22 = 132 的月成本指数。令牌费用是席位费的三倍。这个结构下，优化重点根本不在席位，而在"怎么让每次代理任务的令牌消耗降下来"。

降消耗的几个实操手段：把规则文件精简到只保留真正必要的约束（规则文件每轮都读，冗长的规则是持续的隐性开销）；任务拆分，让每次代理只处理一个明确目标，避免它在无关文件里探索；给代理明确指定"相关文件范围"，而不是让它自己全仓库搜。

3.2 上下文窗口不等于可用上下文

宣传页上写着"超长上下文"，实测下来你会发现模型的注意力分布极不均匀。业内常提的中段遗忘现象是真的：关键信息放在输入的开头和结尾，召回率高；放在中间，尤其是被大量日志、堆栈、文件内容包裹的中间，召回率明显下降。

这个特性直接决定了你怎么组织投喂内容。我的做法是三层结构：最前面放任务目标和不可违反的约束（比如"不要修改数据库迁移文件""保持现有公开接口签名不变"）；中间放证据材料，包括报错日志、相关源码、历史提交；最后再重复一遍输出格式和验收标准。中间的证据材料按相关度排序，最相关的靠近两端。

还有一个更隐蔽的坑：上下文被"填满"之后，模型不一定会告诉你它读不下。有些工具会静默截断，你以为它看了全部文件，实际它只看了前一半。带代理的工具里，这个问题的表现是"改了 A 文件却忘了 B 文件"，而 B 文件恰好排在检索结果的末尾。

注意：判断工具是否静默截断，有个简单办法——在投喂内容的中段塞一个独特的标记字符串，然后问它"标记字符串是什么"。答不上来，说明中段被丢了。

4. 落地实操：搭一条能切换的工具链

4.1 分层结构：让规则和工具解耦

工具会换，规则应该留下来。我的做法是把所有对模型的约束沉淀成仓库内的纯文本文件，工具只是读取者。这样换工具时，迁移成本几乎为零。

目录结构大致是这样：一个统一的规则目录，里面按"全局约定""模块专属约定""任务模板"分层；一个命令白名单配置；一个评测任务集。这些文件全部随仓库走版本控制，改动要经过评审——因为一条错误的规则会影响所有人。

repo/ ├── .ai/ │ ├── rules.md # 全局约束，所有工具共用 │ ├── rules.backend.md # 模块级补充约束 │ ├── tasks/ │ │ ├── fix-bug.md # 修 bug 的任务模板 │ │ └── add-test.md # 补测试的任务模板 │ ├── deny-commands.txt # 命令黑名单 │ └── eval/ │ └── cases/ # 回归评测用例 └── src/

4.2 规则文件怎么写才真正生效

这是我最想强调的一节。大部分团队写的规则文件是抒情式的："请保持代码优雅""注意代码质量""遵循团队规范"。这类描述对模型几乎无效，因为它不可验证。

有效的规则必须满足三个条件：可验证、有具体触发条件、有明确的正反例。

# 全局约束 ## 不可违反 - 不修改 `migrations/` 下任何已存在的文件。 - 不修改公开接口的函数签名；如需变更，先输出变更清单等待确认。 - 不引入新的第三方依赖；确需引入时说明理由并列出替代方案。 ## 代码风格 - 错误处理统一返回 Result 类型，不使用抛出异常的方式传递业务错误。 正例：`return Err(DbError::NotFound)` 反例：`throw new Error('not found')` ## 提交前自检 - 运行类型检查，不允许出现新增类型错误。 - 运行受影响模块的单元测试，失败则不提交。

对比一下：前一种写法模型只能"尽量理解"，后一种写法模型可以逐条对照执行。规则文件不需要长，二十条精准的规则，效果远好过两百条泛泛而谈。

4.3 灰度、评测与回收

引入任何一款工具，我建议都走"小样本评测 → 灰度 → 全量 → 定期回收"这条路径，别跳过评测直接全量。

评测集怎么建？最省事的办法是从历史提交里挖。找过去三个月里被合并的修复类提交，把每个提交还原成一个任务描述：给定修改前的代码状态，任务是"让某个测试通过"。然后让候选工具去跑，统计三个指标：一次通过率、人工介入次数、消耗的令牌量。

回收机制同样重要。工具引入后每个季度看一次使用数据：日均活跃、任务成功率、成本。连续两个月低于阈值就下线。我见过太多团队订阅列表只增不减，年底一算，三分之一的席位半年没人登录。

5. 常见坑位与排查实录

5.1 十个高频翻车场景与处置

下面这些是我在实际使用和协助团队落地时反复见到的，按出现频率排序。

其中"测试被改而不是被修"这条最危险，因为它会让所有质量信号失真。代理发现测试挂了，最快的路径是改断言，不是找根因。防护办法是把测试文件放进保护清单，任何改动都要人工确认，并且在规则文件里明确写"不允许为了让测试通过而修改断言"。

5.2 快速排查表：症状到原因的映射

遇到问题时，先按现象定位大类，再往下查。

我个人在实际操作中的体会是：工具选型这件事，八成的功夫不在"选"，而在"准备"。仓库结构清晰、测试跑得快、规则写得准，用哪款工具都能出效果；反过来，仓库一团乱、测试跑半小时、规则全是形容词，买最贵的工具也是白花钱。所以每次有人问我"该选哪款"，我通常先问三个问题：你们的测试跑完要多久、命名规范有没有成文、最近一次大重构回滚了几次。这三个答案，基本就决定了你该从哪一类工具开始，以及要不要先花两周把地基补上。