★ FEATURED ARTICLE 1. 先做减法插件装得越多编辑器越容易被拖慢聊 VSCode 插件这件事我第一反应不是去扩展商店按下载量排序而是先打开自己那台老笔记本看一眼启动耗时。三年前我装过四十多个扩展冷启动要等七八秒输入一个字符光标要迟滞半拍当时还以为是电脑老了后来把插件清单砍到二十出头同样的机器启动直接回到两秒半。这个反差让我意识到一件事插件提升开发效率的前提是它自己别成为新的效率黑洞。所以这篇不按下载量给你念排行榜而是按“我在什么场景下会打开它”来分组把二十多款真正在我机器上活过三个月以上的 VSCode 插件拆开讲包括它们各自解决什么具体问题、配置怎么写、什么时候该果断卸载。刚接触编辑器的新手可以照单装已经装了三十个以上的老手建议先看这一章再往下翻。1.1 我筛插件只看三条硬标准第一条是使用频率。一个插件如果一周用不到三次它带来的收益基本被它占用的启动时间吃掉了。我给自己定的线是“每天至少触发三次”低于这条线的要么扔进“尝鲜层”临时目录用完就删要么干脆不装。这条标准拦掉了很多看着炫酷、实际一年点不开两次的可视化工具。第二条是是否存在内置替代。编辑器这几年把大量曾经需要插件的能力收进了核心最典型的就是括号对着色。早年大家装 Bracket Pair Colorizer现在只要在设置里打开editor.bracketPairColorization.enabled就够了而且内置版本是原生渲染比插件在扩展宿主进程里跑要快一个量级。类似的还有自动闭合标签、路径补全的一部分能力。装之前先去设置里搜一遍关键词能省一个是一个。第三条是是否常驻扩展宿主进程。这里要说一个很多人忽略的机制绝大多数插件并不跑在编辑器主进程里而是跑在一个叫 Extension Host 的独立进程。这个进程是单线程的所有插件的激活逻辑、事件监听、文件扫描都在里面排队。你装五个都要监听“文件保存”事件的插件每次 CtrlS 就是五次串行回调。所以我看到插件的activationEvents里写着*意思是编辑器一启动就激活警觉度会立刻拉满除非它是格式化工具这种必需的否则一律换掉或者禁用。提示判断一个插件是否“无脑常驻”最简单的办法是打开命令面板执行Developer: Show Running Extensions列表里会直接标出每个扩展的激活耗时超过 200ms 的就值得怀疑了。1.2 花十分钟给编辑器做一次性能体检在往里塞东西之前先量一次基线不然你永远不知道变慢是谁的锅。我的流程是三步清空工作区、重启编辑器、记录冷启动耗时和“启动性能”报告里的慢扩展名单。这个报告在命令面板里搜Developer: Startup Performance就能拿到里面按耗时排序一眼能看出哪个扩展在拖后腿。观察指标正常区间需要处理处理动作冷启动到可输入1.5s 以内超过 3s排查activationEvents: *的扩展单扩展激活耗时50ms 以内超过 200ms改为按需激活或卸载保存一次文件的回调耗时300ms 以内超过 800ms减少监听保存事件的插件大文件打开1MB 文本2s 以内超过 5s关闭该语言的高亮类扩展体检完之后我习惯把插件分成三层内核层格式化、语法检查、Git缺了没法干活、场景层写接口时用的调试工具、写文档时的 Markdown 工具按项目开关、尝鲜层看到推荐随手装的加个书签两周不用就删。分层之后插件总数控制在二十五到三十之间启动稳定在两秒出头这个平衡点我用了两年没再动过。2. 写代码这段把机械重复的活儿交出去写业务代码时最耗神的不是想逻辑而是那些“知道该写什么但手指要动很多下”的部分改一个变量名要同步改十个地方、新建组件要敲一遍模板、路径引错了要翻三层面包屑。这一类劳作占了编码时间的相当比例也是最容易被插件吃掉的部分。这一章里我按“补全、骨架、闭合”三个环节来讲涉及的插件基本都是我每天都要碰的。2.1 格式化与检查的分层搭配别让工具互相打架先说最容易被配错的一组。Prettier负责纯排版——缩进、引号、换行、行宽ESLint负责代码质量——未使用变量、错误的 Hook 依赖、禁止的语法。这两个东西的职责边界如果没划清你会遇到“保存一次文件代码被格式化两遍光标跳到文件末尾”的经典乱象。我的配法是让 Prettier 独占排版权ESLint 关掉所有格式类规则。具体做法是装eslint-config-prettier把它放在 ESLint 配置的extends最后一位作用是关掉与 Prettier 冲突的规则。然后在编辑器设置里把默认格式化器指给 Prettier{ editor.defaultFormatter: esbenp.prettier-vscode, editor.formatOnSave: true, editor.codeActionsOnSave: { source.fixAll.eslint: explicit }, [javascript]: { editor.defaultFormatter: esbenp.prettier-vscode }, [vue]: { editor.defaultFormatter: esbenp.prettier-vscode } }source.fixAll.eslint的值这里要特别注意新版本编辑器已经废弃了布尔值必须写explicit或always写true会静默失效——这个坑我在三个不同项目里踩过每次都是同事问“为什么保存不自动修 ESLint”才想起来。排版之外还有一层团队级的EditorConfig。它的价值在于跨编辑器一致用别的 IDE 的同事打开同一个仓库缩进也不会跑偏。配置文件放在仓库根目录几行就够用root true [*] charset utf-8 indent_style space indent_size 2 end_of_line lf insert_final_newline true trim_trailing_whitespace true [*.md] trim_trailing_whitespace false单独给 Markdown 关掉行尾空格清理是有原因的Markdown 里两个空格加换行等于硬换行自动清掉会破坏排版。这种细节不写进配置团队里迟早有人被文档格式折磨。样式文件另算一套。Stylelint在写 CSS、SCSS、Less 的项目里几乎是刚需尤其是团队约定“禁止使用 ID 选择器”“颜色必须走变量”这类规范时靠人肉 review 根本守不住。它的配置思路和 ESLint 类似装上stylelint-config-standard打底再叠加项目自己的规则文件编辑器端开启保存时自动修复。2.2 骨架生成代码片段比补全更懂你的项目很多人只关注 AI 补全忽略了自定义代码片段这个更朴素但更可控的能力。AI 补全给的是“大概对”的代码代码片段给的是“完全符合本项目约定”的模板两者不冲突但后者在团队协作里的确定性高得多。编辑器自带的片段配置通过首选项: 配置用户代码片段打开选具体语言后是一个 JSON 文件。举个我常用的例子新建一个带日志打点的函数骨架{ Function with logger: { prefix: fnlog, body: [ /**, * $1, */, export function $2($3) {, logger.debug($2 called, { $4 }), $0, }, ], description: 生成带调试日志的函数骨架 } }$1、$2是跳转占位符按 Tab 依次跳过去$0是最终光标位置。实测下来一个中等规模的项目里光是这一条片段就能把新建函数的平均耗时从二十秒压到五秒以内。除了自定义片段几个现成的片段包也值得装。JavaScript (ES6) code snippets覆盖了impimport、clgconsole.log、freforEach这类高频前缀写组件框架的话对应的官方片段包会提供vbase、vdata这类模板。这类插件体积小、激活条件明确只在你打开对应语言文件时才激活属于典型的低风险高收益。2.3 标签、括号与路径让编辑器自己收尾Auto Rename Tag是我认为性价比最高的插件之一没有之一。改一个开始标签结束标签跟着改省下的是每次改结构时那一下“翻到后面找对应闭合标签”的注意力损耗。写模板类代码的人应该都懂这种损耗看着小一天累积几十次到下午就开始烦躁。Auto Close Tag补的是同一类需求敲/自动补全。不过说实话编辑器新版本对 HTML 的自动闭合已经做得不错了这个插件在纯 HTML 场景下收益有限真正需要它的是那些把模板嵌在字符串里的老项目。我的建议是先不装用一周如果确实频繁手打闭合标签再补上。Path Intellisense解决的是引用路径的补全。原生编辑器对相对路径有一定提示能力但在别名路径比如/components/xxx和深层目录下经常失灵。装完之后import语句里敲引号就能看到目录树配合项目里配置的路径别名做映射跨目录引用的出错率能降下来一大截。配置里有一项值得注意{ path-intellisense.mappings: { : ${workspaceFolder}/src } }这个映射必须和打包工具的别名配置保持一致否则补全出来的路径是对的运行时却解析不到排查起来非常浪费时间。括号着色这一块要单独提醒网上大量老教程还在推荐 Bracket Pair Colorizer这个插件早已停止维护功能被内置了。开启方式是在设置里搜索bracketPairColorization把editor.bracketPairColorization.enabled打开再配合editor.guides.bracketPairs设成active就能得到只在当前层级显示引导线的效果。用内置版本不额外占进程这是我做减法的典型案例。3. 读代码与找位置陌生项目里最值钱的一环接手别人代码的前两周时间基本全花在“这个函数在哪定义”“这个常量被谁改了”“上次改这块是为了修什么”这类问题上。写代码的插件省的是手速读代码的插件省的是脑力后者对整体效率的影响其实更大。这一章里的工具我建议无论什么技术栈都装上因为它们和语言无关。3.1 TODO、书签与注释给未来的自己留路标Todo Tree干的事情很朴素把代码里所有TODO、FIXME、HACK注释收集到侧边栏的一棵树上点一下直接跳过去。它的价值在项目交接和长期维护场景下才真正显现——你三个月后回来能立刻知道哪几处是当时挖的坑。配置上有两个参数建议改。一个是todo-tree.general.tags加上团队自己的标记词比如OPTIMIZE、REVIEW另一个是todo-tree.highlights.enabled打开之后注释在代码里也会高亮扫读时更容易注意到。注意这个插件默认会扫描整个工作区大仓库几十万文件下建议用todo-tree.filtering.excludeGlobs排除node_modules、dist这类目录否则第一次索引会卡住十几秒。Bookmarks解决的是另一个场景读代码读到一半被打断回来找不到刚才的位置。它的用法是给任意行打标记然后按CtrlAltK跳到下一个。我一般的用法是在读一个复杂调用链时给关键跳转点各打一个书签形成一条可以来回走的路径比自己记行号靠谱得多。Better Comments是纯视觉增强把注释按前缀染色// *是高亮重点// !是警告// ?是疑问// TODO是待办。这东西一开始我觉得是花架子用了一段时间之后发现它确实改变了写注释的习惯——为了让注释有颜色你会下意识地给注释分类半年后翻回去看可读性明显比一堆灰色文字强。3.2 结构预览与依赖体积把看不见的成本可视化Import Cost会在import语句后面直接标出这个包压缩后的体积红色表示超过阈值。这个插件改变了我对依赖的直觉判断以前觉得“装个工具库而已”装上它之后看到某次随手引入的日期库标着 72KB 红色当场就换成了手写三行代码。它的阈值可以调{ importCost.smallPackageSize: 20, importCost.mediumPackageSize: 100, importCost.largePackageColor: #E4361A, importCost.maxCallersCount: 5 }单位是 KB。把中等阈值设到 100 意味着超过 100KB 的包会标黄这个数字我按项目实际打包预算调过两次——预算紧的项目会调到 50。Project Manager用于多仓库切换。它可以把你常驻的几个工程保存成列表存到侧边栏一键切换不用每次去文件菜单里翻最近打开记录。这个插件对我最大的帮助其实是心理层面把十来个工程列在侧边栏之后我清楚知道自己同时在维护哪些项目不会出现“某个仓库三个月没动过依赖全烂了”的情况。3.3 视觉锚点让眼睛少迷路Indent Rainbow给每一级缩进染不同颜色。刚学编程时我以为这是个装饰后来在深层嵌套的配置对象和 JSX 里被它救过好几次——缩进对齐错误一眼就能看出来。注意它对性能有一点影响超大文件几千行以上下建议临时关掉或者把indentRainbow.excludedLanguages里加上你项目里最大的文件类型。Peacock是给工作区窗口染标题栏颜色。同时开三个项目窗口的时候这个插件能防止你在错误的仓库里改代码——我用它把测试环境的窗口染成橙色生产配置相关的窗口染成红色改之前先看一眼颜色这个习惯帮我避免过几次误操作。Material Icon Theme是文件图标主题。它不影响功能但影响“扫读目录树的速度”。带图标之后一眼能区分组件文件、样式文件、配置文件找文件的时间确实短一点。这类纯视觉插件占用的资源很少装上不亏。Error Lens把错误和警告直接显示在出错行的末尾不需要鼠标悬停看波浪线。这个改动看着小实际扫读体验提升明显尤其在批量重构之后快速过一遍报错。这里有一点要注意它会把所有诊断信息内联渲染如果项目里有大量警告比如一堆未使用变量的提示整屏会显得很花。我的做法是先集中清理一轮警告再开这个插件不然就是给自己添堵。4. 调试与接口验证别在浏览器和终端之间反复横跳写完整流程里最容易被低估的是“验证”这一步。改一行代码切到浏览器刷新点三下进到目标页面看接口返回切回编辑器改再切回去。这套动作一轮二十秒一天做五十次就是十几分钟纯浪费。这一章的插件目标都是把验证环节收回到编辑器内部。4.1 接口调试把请求写成文件REST Client允许你新建一个.http后缀的文件直接在里面写请求点一下“Send Request”就在编辑器右侧看到响应。相比在图形化工具里点点点建请求这种文本形式的请求有个巨大优势它可以进版本库。团队里谁要复现某个问题拉到仓库打开那个.http文件就行不用再互相传截图。写起来大概是这样host http://localhost:8080 token eyJhbGciOi... ### 查询列表 GET {{host}}/api/items?page1size20 Authorization: Bearer {{token}} ### 创建条目 POST {{host}}/api/items Content-Type: application/json Authorization: Bearer {{token}} { name: test-item, tags: [a, b] }三个###分隔不同请求开头定义变量变量可以在同文件内复用也可以拆到http-client.env.json里按环境切换。这个环境文件我一般加进.gitignore因为里面会放测试环境的密钥共享出去不合适。Thunder Client是同类需求的图形化方案界面更像传统的接口工具适合习惯点击操作的人。两者不必都装选一个就好。我倾向保留 REST Client因为它更轻而且纯文本的东西 diff 起来舒服。4.2 本地预览与快速执行Live Server给静态页面起一个带热更新的本地服务右键“Open with Live Server”就开。它适合纯 HTML/CSS 的小页面和原型验证不适合有构建流程的项目——那种情况用项目自己的 dev 脚本更靠谱。这个插件有个细节容易被忽略默认端口 5500如果你的后端也在这个端口上会出现莫名其妙的冲突建议在设置里改成liveServer.settings.port指定的其他值。Code Runner用来快速跑单文件脚本点右上角三角就能执行当前文件。它在验证一段算法、试一个正则、跑个小脚本的时候非常顺手。但有两个坑必须提一是它默认用系统全局的解释器如果你的项目依赖某个虚拟环境或特定版本跑出来结果可能和项目里不一致二是它对多文件依赖的项目支持很差别指望用它跑真实业务代码。我一般只在临时脚本上用配置里把code-runner.runInTerminal设为true这样能拿到真实终端环境问题会少很多。4.3 日志注入与错误定位Turbo Console Log是那种“用之前觉得无聊用之后离不开”的工具。选中一个变量按CtrlAltL它自动在下一行插入一条带变量名的日志语句输出格式会包含文件名和行号方便定位。它省下的是“敲 console.log、复制变量名、加说明文字”这三步单次节省不到十秒但一天几十次就是可观的量。风险在于很容易留下大量日志提交上去。我的应对是提交前搜一遍特定前缀或者干脆在它设置里限定只在开发模式下生效的日志函数名{ turboConsoleLog.logMessagePrefix: DEV, turboConsoleLog.logType: log }配合DEV前缀提交前搜DEV就能一次清干净。这个习惯是从一次把调试日志推到线上环境的事故之后养成的。Error Lens在这一章再提一次是因为它在调试阶段的价值最高。跑完测试看到一片失败开启内联显示后不用逐个悬停直接扫一遍就知道错在哪几行。5. 版本管理与协作让提交记录自己说明问题Git 本身不难难的是“看懂历史”。一个函数为什么长成现在这样往往要翻十几次提交、比对三个版本才能拼出线索。这一章的插件核心目标就是把这条线索拉直让历史变得可读。5.1 GitLens把行级历史摊开看GitLens是我装了之后再也没卸过的插件核心能力是行内 blame。光标停在任意一行行尾就会淡显这行代码是谁、什么时候、因为哪次提交改成现在这样的。它把“考古”这件事从“打开命令行 blame 再对照提交信息”压缩成一次视线移动。它的功能很多容易开得过头导致界面拥挤。我习惯关掉大部分装饰只留几个真正用的{ gitlens.currentLine.enabled: true, gitlens.currentLine.format: ${author, }${agoOrDate} • ${message}, gitlens.hovers.currentLine.over: line, gitlens.codeLens.enabled: false, gitlens.gutterIcons.enabled: false }codeLens关掉是因为它会在每个函数上方插一行“作者/提交信息”文件一长满屏都是灰字反而干扰阅读。gutterIcons关掉是同理。这些开关值得花十分钟调一遍默认全开的配置对大多数人是过载的。除了 blame它还提供一个“比较当前分支与某次提交”的能力排查“这个 bug 是哪次改动引入的”时非常顺手选中一段可疑代码看它的历史列表逐个版本对比差异比在网页端翻提交记录快得多。5.2 Git Graph分支拓扑一眼看清Git Graph把提交历史渲染成一张图分支、合并、标签都在一张画布上。命令行git log --graph也能看但在几十个分支并行、合并频繁的仓库里图形界面的可读性优势是碾压性的。我用它最多的两个场景一是合并前确认分支从哪儿切的、有没有落后主干太多二是查某个功能为什么在测试环境表现异常顺着图谱往回看有没有漏合的分支。图谱上点击任意提交可以看 diff、可以做 cherry-pick操作都在编辑器内完成不用来回切终端。这里有个使用建议仓库历史很长时Git Graph 默认会加载全部提交第一次打开可能卡几秒。在设置里限制加载条数比如 500 条日常使用完全够需要深挖再临时放宽。6. 配置同步与插件搬运换一台机器十分钟恢复战场插件配好之后真正的麻烦在于“换机器”。新电脑、新容器、临时借用别人的工作站把二十多个插件和一堆设置重新配一遍一上午就没了。这一章讲怎么把这件事变成几分钟的事。6.1 内置同步与手动备份的取舍编辑器自带的设置同步功能开启后会把设置、快捷键、已安装插件列表、代码片段同步到账号下。日常换机器最省事的方案就是它登录之后等几分钟环境基本恢复。但它有两个局限要知道。第一它同步的是“全部设置”如果你在不同机器上想用不同配置比如台式机用大字号、笔记本用小字号它会把配置互相覆盖。第二插件是按“已安装列表”同步的如果你在某台机器上临时装了十个尝鲜插件没删这些也会被同步过去。所以我的做法是日常用内置同步同步设置插件清单单独用工作区文件管理两者配合。6.2 用工作区文件给团队统一插件清单项目根目录建一个.vscode/extensions.json里面列上这个项目推荐装的插件。别人克隆仓库打开时编辑器会弹提示“此工作区有推荐扩展”一键全装。{ recommendations: [ esbenp.prettier-vscode, dbaeumer.vscode-eslint, editorconfig.editorconfig, eamodio.gitlens, streetsidesoftware.code-spell-checker, usernamehw.errorlens, formulahendry.auto-rename-tag, christian-kohler.path-intellisense ], unwantedRecommendations: [ hookyqr.beautify ] }unwantedRecommendations这个字段很多人不知道它可以明确告诉新人“别装这个”。比如老的 beautify 格式化和 Prettier 会打架把它列进不推荐名单能省掉新人踩坑后的一轮排查。配套的设置也应该进版本库放在.vscode/settings.json里只放项目相关的格式化器、检查规则、排除目录个人偏好类的字号、主题留在用户设置别混进仓库。7. 我踩过的坑与问题速查插件这东西装的时候都挺顺出问题的时候往往很难定位——因为症状看起来像“编辑器卡了”“保存没反应”“提示不准”很少有人第一反应是插件冲突。这一章把我实际遇到过的高频问题整理一遍。7.1 三类典型故障与定位思路第一类是格式化结果反复横跳。现象是保存一次文件代码被改两遍光标乱跳。原因几乎总是多个格式化器抢占默认权或者 ESLint 的修复规则和 Prettier 的排版规则重叠。排查路径打开命令面板执行Format Document With...看列表里有几个候选格式化器再看 ESLint 配置里有没有引入eslint-config-prettier。解决办法是明确指定editor.defaultFormatter并且关掉 ESLint 的格式类规则。第二类是输入延迟。打字时光标跟不上手。这时候先看是不是某个插件的实时检查在跑——Developer: Show Running Extensions里如果有扩展的 CPU 占用一直很高基本就是它。常见的元凶是大文件上的语法高亮插件、全量扫描的 TODO 类插件、以及实时预览类插件。临时禁用验证一下确认后再决定换配置还是卸载。第三类是补全不准或者乱补。有几个插件同时提供补全时候选列表会混进一堆不相干的建议。这时候要看是不是装了多个 AI 补全类插件它们之间没有协调机制各推各的。我的原则是同类只留一个剩下的全关。注意排查插件问题时用“扩展”面板里的“禁用工作区”而不是直接卸载。工作区级禁用只影响当前项目能快速做 A/B 对比排查完再决定要不要全局处理。7.2 常见问题速查表症状最可能的原因快速验证处理方式保存后代码被改两次多个格式化器抢占Format Document With...看候选固定defaultFormatter关闭其余启动明显变慢存在*激活事件的扩展启动性能报告卸载或改按需激活大文件打开卡死高亮/缩进类插件全量解析关掉插件对比对大文件类型设排除路径补全给出错误路径别名映射与打包配置不一致对比两处配置统一映射规则提交前忘了清理调试日志日志无统一前缀全文搜索约定统一前缀便于清理同一项目不同人格式不一致缺少工作区级配置检查.vscode目录配置与推荐清单入库Git 历史图加载很慢提交数量过大观察首次打开耗时限制加载条数8. 按角色组装的插件组合照着自己的活儿挑最后这一章不讲新插件讲组合。同样是二十多款前端、后端、写文档的人需要的子集完全不同全装只会互相干扰。下面这三套是我实际配过、跑过半年以上的组合可以直接抄。8.1 三套组合的差异与取舍偏前端界面开发的一套核心诉求是“改样式能立刻看到、结构改动不出错”。必装的是格式化三件套Prettier ESLint EditorConfig、Auto Rename Tag、Path Intellisense、Live Server、Error Lens、Import Cost、Peacock。这一套的侧重点是反馈速度每次保存就能看到结果不用来回切窗口。体积控制在十个以内启动基本无感。偏服务端接口开发的一套核心诉求是“接口能自测、日志能定位、历史能追溯”。必装 REST Client、Turbo Console Log、GitLens、Git Graph、Todo Tree、Code Spell Checker。这一套里日志和接口工具占大头因为服务端排查的成本主要在这两块。格式化工具按语言选Node 生态用 Prettier其他语言用各自的官方格式化扩展。偏文档与知识整理的一套核心诉求是“写得快、看得清”。必装 Markdown All in One提供目录、列表自动续写、快捷键、Markdown Preview Enhanced更强的预览和导出能力、Code Spell Checker英文拼写检查中文文档里也能抓出误拼的单词、Better Comments。这套组合很轻几乎不影响启动。三套之间有重叠的部分格式化、Git、拼写检查这些是通用底座无论做什么都建议留着。差异部分按项目类型在.vscode/extensions.json里分目录配置切换项目时编辑器会自动提示装缺的、提醒关多余的。8.2 安装顺序与首次配置的实操建议装插件这件事我建议的顺序是先装格式化与检查再装导航与 Git最后装锦上添花的视觉类。原因是前两类会直接改变你写代码的方式需要几天适应期视觉类随时可以加不影响习惯。首次配置有四个动作值得花半小时做完。第一把editor.formatOnSave打开同时确认只保留一个默认格式化器这一步做完从此不再手动整理缩进。第二把 GitLens 的装饰项按前面给的配置精简一遍不然信息过载。第三给项目建.vscode/extensions.json和settings.json把团队约定固化下来。第四跑一次启动性能报告记下基线数字以后变慢了有对比依据。至于那二十多款之外的东西我的态度一直是看到推荐先记下来别急着装。扩展商店的推荐机制会推很多“看起来很酷”的工具但真正能留下来的永远是那些每天被你按三次以上的。我现在的清单稳定在二十六个过去一年只增删过两个其中删掉的那个是因为编辑器内置了同样的功能。装插件和整理衣柜其实是一回事塞得越满找东西越慢。这套清单我在三台机器上跑了一年多冷启动都在两秒出头最直观的体会是效率提升从来不是靠某一个“神器插件”而是靠把二十个每天都在发生的小摩擦逐个磨平。你不需要全装挑出眼下最烦的那三件事各找一个对应的插件用一周形成肌肉记忆之后再考虑下一批。这个节奏比一次性装满四十个然后被各种冲突折磨要快得多。
阅读完成 · 觉得有帮助？
![AI要接管电脑了？[特殊字符]](http://pic.xiahunao.cn/yaotu/AI要接管电脑了？[特殊字符])
