打开 VS Code 扩展市场搜 AI，一屏几十个插件，名字差不多、介绍都在吹。装了三四个之后发现侧边栏挤满图标，真正天天用的只有一两个。这篇按「你想让编辑器帮你干什么」来分，讲清每一类的功能定位、在扩展市场里怎么找、装完用什么动作验证它值不值得留；具体哪家强、免费额度多少，去站内榜单和目录页看当时的数字。
打开 VS Code 扩展市场搜 AI，一屏几十个插件，名字差不多、介绍都在吹。装了三四个之后发现侧边栏挤满图标，真正天天用的只有一两个。原因通常不是插件差，而是装之前没想清楚「我要编辑器帮我干什么」。
这篇按用途分三类：读懂陌生代码、生成单测、诊断 Bug。每一类只讲功能定位、在扩展市场里怎么筛、装完用什么动作验证它值不值得留。具体哪家强、免费额度多少，去站内目录和榜单页核对当时的数字。
先按用途分类，别按名气装
一个扩展很难三样都强。代码解释做得好的一般是对话式交互，单测生成做得好的一般要深度读项目结构和测试配置，Bug 诊断做得好的一般要能接日志和堆栈。混着装的结果是快捷键打架、侧边栏挤满图标、补全互相抢。先定你当前最痛的那一类，只装一个。
| 你现在的痛点 | 该看的类别 | 判断标准 |
|---|---|---|
| 接手遗留项目、看不懂老代码 | 代码解释类 | 能不能带整个文件或目录的上下文，而不是只发选中的几行 |
| 有代码没测试、不敢改 | 单测生成类 | 能不能识别你项目用的测试框架和已有测试文件风格 |
| 报错堆栈看不懂、定位慢 | Bug 诊断类 | 能不能把堆栈、日志和代码位置对起来给出可疑点 |
| 只想少敲点样板代码 | 补全类（本文不展开） | 和上面三类不是同一需求，别混在一起选 |
- 看扩展详情页第一处：权限。要不要读整个工作区？只读当前文件通常更安全也更轻。
- 看第二处：是否强制登录。不登录就用不了的，先想清楚你愿不愿意把代码路径交给对方。
- 看第三处：隐私说明里有没有默认上传代码片段到远端。有的话看能不能关。
- 同一类只留一个，装第二个之前先明确它在什么场景下比第一个强，说不出来就别装。
代码解释类：读老代码、读别人的仓库
常见形态有两种：选中一段右键「解释」，或者在侧边栏对话里用 @ 引用当前文件。选手感的关键差别在于上下文范围——只发选中那几行的，遇到跨函数调用就答得含糊；能带上整个文件甚至相关文件的，解释里才会出现真实的变量来源和调用关系。
适用场景是接手遗留项目、看陌生框架源码、读别人刚提交的模块。不适用场景是你已经熟悉的业务代码，来回解释比直接读还慢，纯属浪费时间。判断标准很简单：如果它讲完之后你还得回去读一遍代码确认，那这段解释对你没产生价值。
- 拿一段没注释的复杂函数试挑一个你自己写过、清楚它真实行为的函数，别挑简单 getter。
- 看它说的是行为还是复述好的解释会说出「先查缓存、没命中再回源、回源失败走降级」这种真实逻辑；差的只是把函数名和参数名翻译一遍。
- 再试一次跨文件场景问它这个函数被谁调用、改这里会影响哪里。能答上来说明上下文范围够，答不上来就只适合单文件速读。
单测生成类：从「能跑」到「测得有意义」
模型生成的测试有个通病：只覆盖 happy path，输入正常、返回正常、断言通过，然后你提交了。等线上出问题才发现空输入、超长输入、重复调用这些分支一个都没测。所以选这类扩展时，重点不是它能不能生成，而是它生成得够不够挑刺。
- 能不能识别你项目用的测试框架，直接生成对应写法的文件，而不是给你一段要手动改的伪代码。
- 能不能跟着已有测试文件的风格走，命名习惯、setup 写法、断言库和你项目一致。
- 生成完之后边界用例要自己补：空输入、超长输入、并发或重复调用，这三类模型默认很少主动写。
- 验收标准是跑一遍覆盖率工具看行数有没有真的上来，不是看着像模像样就提交。
不适用的场景也要说清楚：逻辑高度依赖外部服务、需要真实数据库或网络往返的代码，生成的测试大多要靠大量 mock 才能跑，mock 写歪了测试本身就是假的。这种代码先考虑能不能拆出纯函数再生成。
Bug 诊断类：从报错到定位，谁负责哪一段
这类扩展擅长的是把堆栈、日志和代码位置对起来，给你几个可疑点。它不擅长的是复现环境和线上时序问题——那部分只能你自己跑。所以用它的正确姿势是：先自己把日志补全，再让它给排查方向，最后逐条验证。
| 它负责 | 你负责 |
|---|---|
| 把堆栈对应到具体代码行 | 确认本地能不能复现 |
| 根据日志给几个可疑原因 | 逐条验证，先排除最简单的 |
| 解释报错信息的含义 | 判断是不是环境差异导致 |
| 提示可能相关的最近改动 | 查提交记录和发布记录对时间 |
- 把它的建议当检查清单，不要直接按它说的改代码，尤其是「把这一行换成另一种写法」这种建议。
- 涉及并发、缓存、跨服务调用链的问题，先把日志补全再问，否则答案全是猜。
- 它说「可能是这里」，你就去看这里，别跳过直接改别处。
- 连续两轮它都给不出新方向，说明信息不够，回去补日志比继续追问有用。
装完怎么验证、冲突怎么排
很多人一次装三四个，然后用两天觉得卡、觉得乱，全卸了。这样永远分不清谁在起作用。正确做法是先只装一类，用一个真实任务跑一遍，跑完再决定要不要装下一类。
- 只装一个，配一个真实任务比如今天要读一个新模块，就只用解释类，别同时开单测和诊断。
- 记录三个观察点响应速度、侧边栏占用、快捷键有没有被抢。这三项有任一让你不舒服，就考虑换或卸。
- 出现卡顿时倒序排查代码补全变卡、保存变慢，按「最近装的」倒序禁用，而不是先怀疑电脑配置。
- 快捷键冲突处理多个扩展都想占同一个快捷键或都想占侧边栏时，先关掉其中一个的自动补全，保留它的命令式调用。
判断一个扩展值不值得长期留，标准只有一个：过去一周你主动用过它几次、每次有没有省下时间。想不起来就别留。扩展市场的安装量和评分只能当参考门槛，真正适合你的组合得自己跑一遍才知道，具体哪款当前口碑如何，去站内目录页核对当时的数字。
下一步站内已经整理好按用途分类的扩展目录和可信度说明，可以对着本文的三类需求直接筛，不用在扩展市场里一个个点开看。→常见问题
装一个「全能」扩展是不是就够了？
能省事，但通常每一项都不深。如果你只做一类活，比如天天写单测，专精的比全能的好用；如果你的工作内容来回换，先装一个覆盖面广的用两周，哪一步最别扭再补一个专精的，别一上来就装满。
这些扩展会不会把公司代码传出去？
多数云端扩展默认会把选中片段或相关文件发到服务端。装之前看权限说明，把工作区里不该外传的目录加进忽略配置，敏感项目优先选能接本地模型或自建端点的方案，具体边界可以去站内的安全合规分区对一遍。
怎么判断一个插件是在变好还是变差？
看更新频率、issue 区的响应、以及你自己每周实际用它的次数。连续几周没打开过，就是该卸了。插件和站点一样会悄悄退化，别只看刚装那天的印象，具体指标口径可以参考站内关于站点退化的观察方法那篇。
