去年这个时候我把 Copilot 的订阅取消了。现在回头看这个决定本身不算难真正花掉我大量心思的是后续选型——我没有去翻各大平台的排行也没有照着社区热帖盲选而是用了一个听起来很笨的办法自己列需求、自己写测试用例、逐项打分。最后留下来那款工具反而是这一年里我几乎每天都会打开、真正离不开的那个。这篇不恰饭也不做参数打架式的评测只想把这一段“放弃 Copilot 之后”的路原原本本写清楚给正在纠结选型的人一个参考。1. 用了大半年后我为什么要跟 Copilot 说再见很多人觉得我是因为订阅费才走的其实不是。月费对我来说不算贵真正让一个普通开发者下决心迁移的通常是好几个问题叠在一起最后超过了某个临界点。1.1 订阅费只是导火索先说说钱的事。个人版订阅按年算下来对国内个人开发者来说是一笔可以感知的开支。如果是公司出钱那无所谓但如果自己掏腰包做开源项目、写side project就会不自觉地去算“值不值”。我当时的心理账本大概是这样的一个月的费用能买两顿饭但真正让我犹豫的不是这两顿饭而是“我到底从它身上拿回了多少价值”。这个疑问一旦冒出来后面看什么都觉得别扭。所以订阅费更像是一根导火索它逼着我去做一次诚实的体验复盘复盘的结果并不乐观。1.2 真正影响体验的不是“能不能补”而是“敢不敢信”Copilot 刚出来那阵子确实有惊艳感。写几行注释它能给你吐出一整个函数写个测试框架它能顺着命名猜出意图。但用久了之后我发现一个更本质的问题我不能完全信任它给的代码。举一个我印象很深的例子。当时我在维护一个老项目项目里所有请求都走统一的实例封装带了统一的鉴权头和错误处理。我用 Copilot 补一个新增接口的调用它直接把fetch摊开写在业务代码里绕过了项目里的封装。代码单独看完全能跑但放到团队规范里就是不合格的产出。这种事情发生几次之后我的使用姿势就变了。原本我是放心大胆地 Tab 补全后来变成只敢让它补注释、补简单模板核心逻辑还是自己写。一旦用户对工具失去了“信任感”补全工具的边际价值就大打折扣。这比延迟高、比偶尔出错都更致命。1.3 私有代码与合规问题是压垮我的最后一根稻草我所在团队对代码外发越来越敏感某些内部模块明确规定不能进入第三方编辑器插件、不能交给外部补全服务处理。Copilot 的云端补全在这种约束下几乎没有回旋余地。也许有人会说那可以关掉某些文件的补全或者只用来写非敏感代码。但“防泄密”这种事靠自觉和手动开关根本不可控。我身边遇到过不止一次同事在公开场合演示代码时自动补全直接把内部接口名和数据库字段名带出来了场面非常尴尬。这种风险一旦被团队负责人意识到工具的命运基本就定了。不是它不好而是“不适合我们的数据边界”。到这一步换工具就不是可选项而是必选项了。2. “笨办法”选型不刷榜单自己列需求、写测试、算加权分决定换工具之后我没有立刻去搜“2026 最好用的 AI 补全插件”之类的内容因为我知道那些榜单背后有评测人的工作习惯、有厂商投放、有时效性它代表不了我的真实日常。我选择了一个更原始、更笨的流程把需求写下来把任务集造出来然后用打分表把候选工具过一遍。2.1 先把需求拆成每天都会遇到的七个场景很多选型文章上来就比“代码补全准确率”但准确率这个概念太抽象真正该问自己的是我每天打开编辑器之后到底在做哪些事我当时给自己列了七个高频场景函数体补全写一个命名清楚的函数让它补完主体。单测生成给一个函数写断言风格一致的测试用例。模板类代码新写一个组件、接口、配置文件的初始骨架。重构辅助批量改字段名、提取函数、调整结构。注释生成与解释给逻辑补注释或者反过来用它解释一段残废代码。非编程文件体验写 SQL、JSON、YAML、Markdown 时补全是否顺手。本地与隐私约束不联网时能不能用代码会不会发到第三方服务器。这七条就是我当时给候选工具出的“考纲”。你会发现我完全没提“支持多少种语言”“上下文窗口多大”这类参数因为那是厂商视角而上面这七条才是用户视角。2.2 我为自己写的一组“选型测试用例”光有场景还不够我专门建了一个仓库把真实项目里脱敏后的代码片段放进去做成固定任务集。每个候选工具都用同一组任务跑一遍避免凭感觉打分。测试用例不需要多难但必须贴近你的真实工作。我的任务集一共十条举几个例子给buildQueryFilter函数补全剩余部分要求使用项目内已有的escapeLikehelper。在Vue组件里新增一个watch需要同步更新meta对象里的某个计数器。给一段无注释的日期处理函数写单元测试断言风格要和项目里现成的测试文件保持一致。重构一个getUserInfo的历史版函数把它分为fetchUser和normalizeUser两部分。在knex迁移文件里补全up方法格式对齐项目模板。把一段重复三次的错误处理逻辑提取成公共函数并生成调用注释。每条任务我会设置一个“满意分”标准不是看它生成的代码能不能跑而是看它是否符合现有工程风格。这个标准非常重要补全出的代码光“能用”是不够的还得“融得进项目里”。2.3 加权评分表一个能直接抄走的模板任务集跑完之后我把七个场景作为维度按个人权重打分。权重完全根据我自己的使用频率和重要程度定比如“函数体补全”我给了 25%“单测生成”只有 10%因为我写单测少“本地与隐私约束”给了 20%这是硬约束。下面是我当时的简化评分表候选工具我用了代号 A、B、C需求场景权重候选A候选B候选C函数体补全25%876单测生成10%655模板类代码15%787重构辅助10%565注释生成与解释10%866非编程文件体验10%587本地与隐私约束20%398加权总分100%6.357.156.45候选 A 的补全效果其实最惊艳但隐私约束一项直接把它拖垮了。候选 C 各项表现均衡没有致命短板。候选 B 单看任何一项都不是最拔尖的但总分最高因为它恰好踩中了我“本地优先 不冒进 行为可预期”的需求重心。提示这张表里的权重和分数是我的主观结果你拿过去用的时候一定要替换成自己的使用频率。别小看这个过程它逼着你把“感觉”转化成“标准”。2.4 为什么我说这是“笨办法”但它依然值得说它笨是因为它耗时间。每个候选我都要先跑一遍任务集再在真实项目里连续用几天前后折腾了两周。别人看榜单可能十分钟就定了我这套流程确实麻烦得不像个“效率党”该干的事。但它给了一个非常确定的结果就算之后我会对某款工具产生“这功能好炫”的冲动也不能推翻那个加权总分。打分表像一个稳定器把“广告效应”和“新鲜感”挡在外面。现在回看这两周时间花得非常值因为工具选型一旦选错后面浪费的是每个月、每个工作日的碎片时间那才是真正的大头。3. 一次实测跑下来几个反直觉的发现选型过程中最有价值的不是最终选出了谁而是我在实测里被迫面对了一些和直觉相反的事实。这些事实会直接影响你的使用预期所以单独拿出来说。3.1 模型参数和模型名对日常体验的区分度远没有想象中高候选 A 和候选 C 背后用的都是当时最新的模型参数比候选 B 大得多。但实测下来在“函数体补全”评分上A 只比 B 高 1 分C 甚至比 B 低 1 分。为什么会这样因为代码补全的实际质量更多取决于它能不能读懂你当前项目里的已有代码、符号习惯和函数命名法而不是它的参数规模。一个大模型如果拿不到项目级上下文编出来的代码再流畅也是“通用代码”放到具体项目里反而显得突兀。与其关心模型参数不如关心一个更实际的问题它对你的编辑器、框架、代码组织方式有多少感知能力。3.2 响应速度比“聪明”更影响心流这个结论是我完全没想到的。在候选 A 和候选 B 的对比里A 的补全内容质量更高但它的响应大概慢 600~1000 毫秒B 的响应几乎是即时的肉眼不可感知。600 毫秒听起来不长但在敲代码的节奏里这个等待窗口足以让你从“思考当前代码”切换到“怀疑它是不是卡了”。我后来回忆自己在 A 上的使用体验发现我按 Tab 的次数远少于 B不是因为 A 不准而是因为它“太慢了”我不愿意停下来等它。注意补全工具的第一价值是“顺着你的节奏”不是“抢在你的前面”。一个在停顿瞬间就能给出逐行建议的工具比一个想了三秒给出完美方案的工具更让人舒服。3.3 触发机制与编辑器集成度体验的分水岭同样是“多行补全”候选 A 给我的是“整段补全”看起来确实酷但很多时候它补全的时机是错的——我还没表达完意图它就脑补了一整段。候选 B 则倾向于“逐行补全”每补一行都很克制我可以用 Tab 快速确认也能随时转向。这个细微差别在真实编码里被放大得非常明显。整段补全意味着我只能在“接受”和“清空”之间二选一逐行补全则允许我一步步引导生成方向更像是在跟一个懂事的实习生协作。另外编辑器集成度也比我想象得更重要。能不能在 SQL 文件里根据表结构给出列名提示、能不能在写断言时对齐项目里的测试风格、能不能正确识别模板字符串里的插值表达式这些细节才是一家补全工具的真实功底。而那些用 Demo 展示的“惊艳长文本补全”反而对我的日常帮助没那么大。3.4 官方 Demo 和真实工程完全是两回事几乎每个候选工具都有一批精彩的官方演示当时看完确实想立刻下单。但把它们放到我是实际项目中一跑就会发现“演示界的主角”和“真实场景的主角”完全不是一回事。在官方 Demo 里代码往往是干净的单文件、上下文简单、预期明确。而真实项目里前面可能有一百行互相依赖的接口定义、十几个风格不太统一的组件、还有一些历史遗留的怪写法。补全工具在 Demo 里“聪明”是因为信息太少太规整在真实项目里“断片”是因为上下文里充满了业务噪音。所以我在打分表里特意设置了一条“是否贴合项目现有风格”的隐性标准专门用来惩罚那种“Demo 很华丽、进项目就失忆”的工具。候选 A 就是栽在这一条上的。4. 留下来那款工具我是怎么配置和调教的最终得分最高的是候选 B这里我就不打广告了就叫它 B 工具。它不是什么大厂出品也没有铺天盖地的宣发但它有一个对我来说很宝贵的特质行为可预期。同样一段代码早上和晚上补全出来的结果基本一致不会因为服务端换了个模型第二天整个人都“变样了”。4.1 选择它的核心原因本地优先、行为可预期B 工具默认是本地模型为主补全逻辑不依赖外部卫星只有在主动开启云端增强时才联网。这一点对我所在团队的数据边界来说非常友好我可以在内部仓库里放心地开着它同时给同事演示也不会发生“缓存泄漏”那种事故。行为可预期这一点也很重要。Copilot 时代我最大的不安全感来自“每次建议都像抽奖”同一个注解写法今天是一个风格明天可能是另一个风格。B 工具的生成策略相对稳定虽然少了一些“灵光一现”的时刻但在产线上稳定带来的是可控。4.2 一个可复用的最小配置示例B 工具支持按项目级和用户级两层配置。我把我个人最推荐的一份最小配置贴出来它不是最复杂的但足够让一个中重度用户获得不错的体验{ suggestions: { enabled: true, maxLines: 8, triggerPrefixes: [return , const , if (, async ], disableLanguages: [plaintext, markdown] }, telemetry: { enabled: false }, trustedFolders: [./src, ./tests, ./scripts] }这份配置做了四件事限制单次补全行数为 8 行避免整段失控只在最常见的几类代码前缀触发减少弹窗噪音关闭 Markdown 等非代码文件里的补全把补全权限只交给信任的源码目录。你可以直接抄这份跑一阵子再做增减。4.3 三天的“默认配置观察期”比我预想中更重要装好 B 工具之后我一开始也忍不住想调参数但最后强迫自己忍住先按默认配置连续用了三天。这三天里我干了一件很笨但很有效的事准备一个空白文档专门记录“它不该出现却出现了”的场景。比如在某框架的模板字符串里误触发补全、在写 YAML 时弹出一堆 JS 建议、在旧代码的any类型里给出类型无关的乱猜。三天后我打开这份记录发现真正让我烦躁的场景不超过五个。这个观察期非常重要因为它能让你知道自己的痛点分配在哪里而不是凭第一印象去乱改配置。我后来把所有配置改来改去的错误几乎都发生在没有观察就动手的阶段。4.4 手工校准个人工作流的完整路径三天观察期结束后我做了一次集中校准步骤大致如下把误触发频率最高的文件类型加入禁用列表。把高频触发前缀从三四个扩大到七八个确保我需要建议的时候它一定出现。针对框架特有的模板语法在配置里增加正则排除规则让补全器不碰行内模板表达式。每改一项就回到之前的测试任务集里跑一遍确保没有因为配置改动破坏了原有的补全质量。最后把配置同步到用户级目录这样换电脑也不会丢。整个过程花了一个晚上之后 B 工具在我的编辑器里就变得“润物细无声”了。它很少出来刷存在感但每次出现几乎都是我想让它出现的时刻。这种拿捏感才是让补全工具真正留在我手边的关键。5. 换工具之后我的“注释驱动开发”工作流工具选完故事还没结束。我发现换了 B 工具之后我自己写代码的习惯也跟着变了。这是一个挺有意思的副作用值得展开聊聊。5.1 从“等它补完”到“我给它画格子”以前用 Copilot我的习惯是写一个函数名然后让光标停在那里等待它像变魔术一样给我补出整个函数体。这种工作流看起来很爽但最大的问题是你把主导权交给了模型——它补什么你就看什么看着看着就被带跑了。现在我的习惯变了我会先把注释写得非常明确把返回值、边界条件、甚至关键算法的倾向都写在注释里然后再让 B 工具把注释翻译成代码。一句话总结就是我负责想清楚它负责填格子。这听起来好像用起来更累了但实际恰恰相反因为填格子这种工作是机器最擅长的重复劳动而“想清楚”本来就是我的核心职责。5.2 注释驱动的局部补全实践举一个我经常遇到的场景。我需要在一个订单任务队列里把重试次数少的记录优先捞出来处理。以前我会直接写实现现在我先把这种业务逻辑用自然语言写清楚// 从 failedQueue 中过滤出重试次数小于 3 的记录 // 按 nextAttemptAt 升序排序取前 10 条返回。 // 注意每条记录需要附带 attempts 字段的增长逻辑。然后让 B 工具补全。它给我的结果基本符合预期而且直接用了项目里已有的排序工具函数而不是自己重新写一遍比较逻辑。这套流程下来我发现注释本身变成了代码的一部分抽象能力和表达能力都因此变强了。你说不出口的业务规则代码自然写不出来你注释写得含糊工具给你的代码就会含糊。选一款工具并不只是选工具本身它也会反过来塑造你的编码方式。5.3 给同事带去最小配置而不是逼所有人都用同一套一个人把工具用好不代表整个团队都能顺利接上。我后来给团队同事交付的不是“逼你换工具”的行政命令而是一份最小配置模板。这份模板只有上面那四行 JSON加上一条说明先用默认配置跑三天记录痛点再决定改什么。结果还挺有意思有的同事第二天就把补全行数从 8 改成 20因为他是快速原型党有的同事直接禁用了所有语言的补全只留注释生成因为他觉得弹窗烦人。团队落地的核心其实是放松控制让每个工程师保留“说不用”的权利。一旦你用“为你好”的姿态强推工具本身的收益就会被逆反心理抵消大半。5.4 团队层面选型的本质确定边界而非追逐最强模型我在这个过程中最大的认知转变是把选型从“找最强的模型”变成了“设定一个可管理的边界”。对个人来说这个边界是你愿意相信它的程度、你愿意忍受弹窗噪音的程度、你愿意为隐私约束付出的成本。对团队来说这个边界还包括哪些代码能进第三方服务、哪些目录默认关闭补全、接到异常提示时回退到哪种手动方案。只要边界清晰工具本身平庸一点也能高效运转边界模糊再先进的模型也可能在项目里闯祸。这是我这一年最想分享的结论也是我那套“笨办法”最终指向的方向。最后说一个我自己踩过的小坑。选定 B 工具的头几天我一心想榨出它的全部潜力把配置改得很花哨结果补全建议忽好忽坏。后来我把配置恢复成“几乎默认”只改了禁用列表和触发前缀两项整个世界清净了。如果你也在做类似选型别急着一步到位先用默认配置跑三天记清楚真正让你觉得痛的那些时刻再动手改也不迟。这一年的体会浓缩成一句话就是选择工具不是选择最强的模型而是选择一个你能持续信任的日常伙伴。