放弃 Copilot 快一年了。准确说是某次迭代之后我关掉了它的自动建议又过了一个月把扩展完整卸掉。没有那种网上常见的“一到手就失望”的戏剧感相反早期我用它写了不少还不错的代码每天都会按 Tab 按得很顺。但后来它慢慢变成我最想省掉的那个环节不停接受建议再不停改回自己真正想要的写法这种来回消耗比没有它更磨人。放弃之后我用了一个特别笨的办法重新选工具不刷测评、不看热评而是把需求一条条写下来给候选工具设计同一组任务像验收外包代码一样逐个试用。最后留下来的是一个看起来最不性感、大概率不会上热榜的选择——一个跑在终端里、需要我主动描述任务、并且把每一步改动都交给我确认的开源编码代理。到今天用了也将近一年我想把这段经历和这套“笨办法”完整记录下来多半能帮正在纠结选型的人省点时间。1. 先说结论我把“自动补全队友”换成了“需要主动追问的分析师”打开编辑器的时候我的界面已经不再有那个浅灰色的补全气泡。现在我会开一个终端窗口用一段自然语言描述问题配上一个明确的代码范围然后等它给我一份带依据的分析或改动计划。这跟 Copilot 的工作方式几乎是两个方向一个是尽力替我补全“下一个词”另一个是揣着整个仓库的上下文等我追问到足够清楚才动手。这个转变一开始并不舒服甚至觉得倒退。毕竟 Copilot 的弹窗是无感的它在你打字的时候就静静出现在光标后面接受它只需要按一下 Tab。而新的工具要你先说清楚意图、指定文件、再让它读上几十秒甚至几分钟上下文效率听起来就低了。但用久了我才意识到过去那种“无感补全”让我丢掉了一样东西对自己正在写代码的意图控制。每按一次 Tab我其实是在把思维的一部分外包出去而外包得越流畅越不容易发现它给出的方向本来就不对。所以这篇文章里我说的“笨办法”最终选中的也不是什么神秘黑科技而是一类把“过程透明”放在“生成速度”前面的工具。它不会主动猜测你的下一步但当你签下指令它可以沿着代码库的证据链给你一条完整路径并且每一步改动都有 diff 可查。对做过一段时间的工程的人来说这种工作方式比单纯的行级补全要可靠得多。2. 我放弃 Copilot 的真实经过不是一下受不了而是一点点没耐心2.1 早期确实香这没什么好否认的先交代一下自己不是那种“什么都想卸载”的选手。我用 Copilot 相当认真而且确实在初期得到过正反馈。最明显的是样板代码和重复模式的补全写类型定义、ORM 模型、路由注册这一类结构高度相似的代码时几乎是一路 Tab 过去的。还有给函数补注释、给测试补参数名它能把我脑子里已经成型的半句话先打出来省掉大量机械击键。那段时间我觉得它是值得的。原因很简单我会写一部分代码它会补另一部分补出来的部分刚好是我本来就准备写的。注意“刚好”这个词后来它不“刚好”的频率越来越高才是问题的起点。2.2 热度退去我发现自己变成了高速审阅员用多了以后我发现自己每天的节奏发生了变化。以前敲完代码直接跑测试后来会先停下来逐行检查它补出来的部分。短函数还行一旦逻辑复杂一点它给的往往是“看起来答案正确”的代码而不是“真的正确”的代码。比如处理边界条件时它会把一个分支写得特别漂亮但漏掉 null 检查或是在异步流程里错误地吞掉异常。这些错误并不是一眼就能看出来的它们游走在接受建议的瞬间潜伏到你写完整个模块后才从测试失败中浮出来。这带来的隐性成本很反直觉表面上我一直在按 Tab好像速度很快实际上我花了更多时间在事后检查、调试和清理它造成的误解。尤其是跨文件场景情况更明显。自动补全模型本质上是基于当前文件的上下文在预测下一段代码它缺乏对整个模块的全局理解。当我要重构一个被十几个地方引用的函数时它的建议往往停留在“补齐当前函数体”而不会告诉我哪些调用方需要同步调整。于是我在做真正的工程决策时它不但没有帮忙反而提供了多余的视觉噪音。2.3 真正推动我卸载的是那个“低垂果实吃完了”的时刻我一直注意不到到底是哪一天开始讨厌它的直到有个下午在处理一段老代码某个服务模块里有两套并存的错误处理策略需要统一成一套。我尝试用 Copilot 帮我识别所有不一致的分支结果它只能补我当前光标所在的函数完全没法告诉我“另一处同样的问题在哪”。我意识到我需要的不是更快的补全而是能够理解整个文件甚至整个模块的助手。一整周的磨合让我确定了一件事当前这种“弹出建议—接受/忽略”的交互模式能解决的只有那些本来就不需要动脑筋的增量代码。而真正需要我花时间的地方它几乎插不上手。与其让它在我思考过程中不断弹出干扰不如换一个能在思考路径上真正帮我的工具。于是卸载。3. 选工具我用了一个没有算法的笨办法需求清单 同题试验3.1 先列需求清单把“想要的感觉”翻译成可验收的指标离开 Copilot 之后我发现网上关于选型的内容大多在某个极端不是狂热吹捧就是情绪化否定。这类内容对我的参考价值不大于是我把重点放在自己过去的痛点里列了一个需求清单上下文理解能力能不能理解整个代码库而不是当前打开的文件。可验证性改动有没有清晰的 diff 或说明而不是直接把结果贴出来。控制权要不要我主动确认操作能不能防止它自作主张。集成成本是只能在网页里用还是能贴近我日常的终端和编辑器。成本模型是订阅付费还是按量计费会不会因为误操作让账单失控。这个方法听起来像废话但真正执行的人很少。大多数人“选工具”是看哪个提的最多、界面最炫、Demo 最有冲击力。而把这些维度量化之后我筛掉了一批只适合演示场景的候选。3.2 给每个候选相同的任务是唯一的公平测试法在定测试集的时候我没有挑那种最能展示空气的 Demo 级任务而是从我自己日常代码里抽了五个真实片段。每个候选工具都用完全相同的 prompt跑完全部任务然后记录结果。这有点像面试但比面试更严格因为考题来自实际工作而不是面试官编出来的理想场景。我的测试集大概是这样的给一个陌生的历史模块写一份架构说明并指出它最脆弱的设计点。在一个业务函数里定位状态更新不同步的 bug给出修复建议。帮我重构一个多层嵌套的条件判断要求在行为不改变的前提下降低复杂度。为一个新接口生成测试骨架覆盖正常的、边界和异常场景。解释一段涉及异步和回调的遗留代码并建议如何改成更清晰的写法。这里有一点很关键我会刻意使用模糊的任务描述比如第一步只说“看看这个模块哪里最复杂”不给任何提示。因为有价值的工具必须有能力自己阅读代码而不是等你把答案线索喂到嘴边。真正好用的工具能自己找到切入点并在结果里显示它参考了哪些文件。3.3 五轮测试下来结论跟预期不太一样测试的结果我做了个简单的二维表格横轴是工具类型纵轴是我关心那些维度维度自动补全型工具对话式编码工具我最终留下的 Agent 型工具补全速度极快中等慢需要预先读取上下文代码库理解只理解当前文件可读取多个文件可递归扫描模块并引用具体位置是否主动改动直接插入候选代码需要手动复制结果生成改动计划经确认后执行出错的隐蔽性高错误藏在补全里中错误藏在回复里低改动以 diff 呈现对高质量重构的辅助弱中等强从表里可以清楚看到速度不代表收益。自动补全型工具在“写重复代码”这个场景里无人能敌但在“我的真实痛点”里表现是最差的。对话式工具理解力强一些可它在没有明确文件范围时容易发散输出很漂亮但没法直接落实到代码。最后被我留下的 Agent 型工具在最初测试时最笨重但有个指标让我决定长期使用它会诚实地告诉我“我读了哪些文件我打算做哪些改动我不确定的点是哪些”。这种可追溯性才是工程场景里最值钱的东西。用笨办法选出来的东西不一定是最聪明的但一定是经过验收、适合我自己工作节奏的。选择工具不是选择最强的而是选择最不会在日常使用中消耗你的。4. 留下的工具是怎么融进我日常开发的4.1 定位它不替代我思考而是替我把“找线索”的时间省下来我现在的工作流大概是这样的白天主要时间花在维护一个由几个模块组成的中型服务仓库。纯新功能开发其实占比不大大多数时候是在老代码里查逻辑、修 bug、重构横向依赖。这种场景里最耗时的不是写代码本身而是定位代码之间的关系。Copilot 式补全对我没有任何帮助而新工具的价值恰恰在定位环节。我通常这么用先在终端里指定自己最近关注的模块范围让它先把模块结构读一遍然后直接提问。比如先别动手改代码。帮我梳理一下 order 模块里几个文件的关系 特别是错误处理和重试逻辑分别在哪一层然后用几句话告诉我最可能出问题的地方。这个 prompt 的关键是“先别动手改代码”。大多数 AI 编码工具的通病是太着急输出结论恨不得直接给你一段替换后的代码。但符合工程习惯的路径应该先解释、再计划、最后才改动。我留下这个 Agent就是因为它会遵循这种顺序。4.2 接上静态分析器把它变成真正的“老代码通”一开始我以为这类 Agent 只能靠模型对代码的天然理解后来发现它可以调用一些外部工具来提高准确率。我把项目里的测试命令、lint 命令和一个简单的索引方式都写进了它的配置。每次让它处理改动之前它会先跑一遍相关测试再基于失败信息定位问题。这样它的判断就不只是模型记忆推测而是有测试结果的支撑准确率高了不少。配置本身不复杂但它带来的习惯变化很关键我现在给工具的任务越来越像给一个资深开发者的任务。我会写清楚“需求是什么、验收标准是什么、改动范围有多大、有哪些文件不要碰”。工具越是收到清晰任务产出的代码就越接近可合并的状态。反过来说我过去用 Copilot 的时候从来没有这个意识因为弹窗补全根本不需要表达意图。4.3 案例一在陌生的历史模块里做安全重构做过老项目重构的人都懂最怕的不是改不动而是改完以后业务行为出现隐藏差异。前阵子我需要重写某个通信模块里的一段状态机转换逻辑这个模块已经有一年多没人碰过内部还有两个分支互相覆盖。换以前我肯定先花几个小时把入口和出口摸清楚再动手。现在我让 Agent 先处理这一步请以 order_state_machine.go 为起点找出所有修改订单状态的地方列出每一个调用方和被调用的转换函数帮我把这条调用链画成文字说明。它很快给出了一张包含调用位置、函数签名和数据流向的清单。我在此基础上挑出需要改动的那条链再给第二条指令“只重构 transferPendingToPaid 这个函数保持对外行为不变改动前先跑测试。”整个过程里我相当于同时拥有一个会读代码的搭档和一个不会随意越界的执行者。真正需要我拍板的部分比如“这个错误是应该直接返回还是记日志”我花的时间一点没少但准备、检索、试错的时间确实省了很多。4.4 案例二让它在测试失败的信息里“倒着推”找 bug还有一类高频场景我特别愿意用它测试挂了但报错信息指向的现象跟实际原因隔了两层。比如有一次某个接口偶发超时测试的报错信息只说是“context deadline exceeded”没有具体到哪个调用链。我用 Copilot 完全没用因为这种问题根本没有显式代码可以补全。于是我把相关测试文件和最近改动过的几个文件路径丢给 Agent让它先解释问题可能出在哪一层。它的思路倒是跟我想得差不多先看超时时间从哪里传入再看哪些 function 可能阻塞了 context。但它比我多的一个优势是不会累可以一次性把十几个文件的调用链全部拉齐不会因为我脑子记不住而漏掉一环。最后定位到一个加锁等待导致 ctx 被截断的位置并提供带测试验证的改动。这种几十行级别的修复价值不在代码量而在定位效率的提升。4.5 重要习惯每一条改动都要过 diff 审查说个必须强调的纪律我用这个工具但从不允许它提交未审阅的代码。它再准确也会犯错。我的习惯是凡是它生成的改动一律放进git diff里逐块查看。特别是删除和改动的行我会问自己“为什么这里原来的写法被改掉新的写法真的覆盖了原来的行为吗”如果答不上来就直接 git checkout 回原状再补充 prompt 信息让它重新来。这条纪律看起来很笨重但它恰恰是这个工具长期可用而不是翻车的原因。AI 生成的代码向来得之容易弃之也容易。产生速度远大于理解速度就会埋下地雷。而git diff这个最原始的动作是我可以给工程稳定性上的保险。5. 这一年里踩过的坑和对应摸索出来的解法5.1 上下文窗口再大也有顾不过来的死角遇到的第一个问题是它读不到一个文件里太深太细的依赖。有一次我让它修改一个需要同步更新配置文件的接口它只改了入口函数漏掉了另一个目录里的变更声明而且相当有自信地以为改动已经完成了。这个坑发生在模型上下文覆盖不全的时候尤其是模块之间跨了三四个文件调用关系盘根错节。我的解决办法是每次任务里强制要求它列出“引用过的文件清单”而且给定一个列表明确告知“这些是相关文件必须全部检查”。在 prompt 里我可以直接写这里涉及的文件至少包括 a.go、b.go、c.go。请在改动前分别检查这三个文件里的相关引用最后输出时列出每个文件分别改了什么。如果它给出的文件清单里缺了某一个说明它没有考虑我一眼就能看出来。别把工具当成搜索引擎也别把它当成不需要路由的节点。给它明确的边界它反而稳定得多。5.2 自信的错误它可能一本正经地开一个不存在的 API另一个典型问题是“模型幻觉”但它不是无中生有的小概率事件。有一次我需要用一个比较冷门库的版本兼容写法它给出的代码看着完整导入路径也像真的但一运行就报错。我去翻库里函数签名发现那个 API 在这个版本根本不存在。彩蛋是它的说明文档里还写了“该 API 自 1.4 版本起可用”实际上是它自己编出来的。这给我最大的教训不是“AI 不可信”而是执行环节必须有自动检查兜底。现在遇到它给出不熟悉的第三方库用法我会要求它把根据什么文件得出这个结论的依据找出来。同时测试命令必须接在生成之后。宁可多一步验证也不把编译错误带进代码评审。5.3 成本失控大量并行请求会在一夜之间烧掉预算这类 Agent 型工具的计费是按 token 算的不加控制的时候账单飞涨。我有过一次七天烧掉平时一个月预算的教训起因是任务中插件自动重复了多次扫描且 Token 量远超直觉判断。后来我做了几个调整限制每次任务前先进行范围确认把长文件的解释单独拆开不给它完整读一遍对不确定的部分让它先用一分钟搜索而不是直接全文分析。这个也是我用笨办法的重要侧面它引导我去了解自己说话详略的价值。prompt 写得不清楚模型就要靠大量重试去猜这都会体现在 token 里。我把需求想清楚既省成本又省时间还提高输出质量。5.4 多人协作时最怕的是“别人不知道这代码是怎么来的”在团队仓库里工作我用这个 Agent 尤其小心。AI 生成的代码如果没有解释别人 review 时会一头雾水。我的做法是让工具产出的摘要在 commit message 里尽量详细保留必要的背景。更重要的是涉及公共模块、核心数据结构的改动时我坚持让 Agent 先生成“改动理由和影响范围”再由我用自己的语言重新叙述一遍这段改动的作用。也就是说即使代码是它写的最终理解它的人必须是我。建立一个微小的“复述习惯”至少在出了问题的时候你能向别人解释清楚你的设计意图而不是把锅丢给一个谁都看不见的黑盒。6. 一年之后我判断“该不该用 AI 编码工具”的思路6.1 什么样的项目最适合这种工具根据一年的总结受益最大的场景有几个共同特征代码库规模中型、历史代码多、模块间耦合较高并且团队成员愿意保留审查流程。在这些地方工具负责的是搜索、对比、解释和初步重构人负责的是判断取舍和最终验收。反过来如果你主要在写一次性脚本、短小的 CRUD 接口、没有任何历史包袱的新模块这个工具的优势不大甚至给你带来过重的流程负担。那种场景里Copilot 款自动补全也许比 Agent 型更顺手。但如果你和我一样大部分时间都在维护老项目的稳定性和可读性让工具深入理解代码库的价值会远大于快速补全的函数体。6.2 规律归纳工具负责“目之所及”我负责“因果链”用了一年我给自己定下一句原则我可以接受机器替我找到线索但绝不能接受机器替我从头到尾讲完故事。AI 编码工具每次给出答案都默认我知道它在说什么。事实上在复杂系统里它会忽略很多团队默认约定某些函数是禁止直接调用的某些字段写错了只是看着无害。这些知识不在模型训练里而在我和团队的共同记忆里。所以无论工具多聪明我最终都会把它当成一个和分析师对话的过程它会告诉我“这里有两处不一致”但我必须自己去确认“哪一处才是团队想要的规则”。AI 编码时代的最大骗局是让人以为只要 prompt 足够长就能得到一个不需要负责的结果。实际上越容易得到的代码越需要你投入去消化。6.3 这套笨办法的延伸价值最后说点题外话。我后来挑其他辅助工具也都沿用了这个笨办法先写需求清单再设计几组真实任务把候选工具按同一套标准测一遍然后留下最不“热闹”的那个。这样做选择有个额外好处它逼着我把自己的使用场景抽离出来而不是被别人的评价牵着走。放弃 Copilot 这一年的体会其实不只关于某个具体工具。它更像是对我工作方式的一次校准从追求“看起来很快”转向追求“改动可追溯、行为可预测”。我现在打开的终端里没有自动弹出的灰色建议但我多了一个愿意把找到的每条线索都摆在我面前的伙伴。用笨办法选出来的这个工具看起来不性感却很对我的日常。这大概就是我能坚持一年的全部原因。