1. 为什么我劝新手从这 8 个 DSH 插件开始上手刚接触 DSHDeepSeek Harness的朋友十有八九会卡在同一个地方装好了本体打开界面然后盯着空荡荡的插件列表发呆不知道下一步该干什么。我当初也是这样翻了一圈文档发现官方把能力都拆成了插件核心只保留一个调度骨架剩下的全靠你自己按需拼装。这个设计思路其实很聪明但对新手来说门槛确实不低——你连有哪些插件、每个插件解决什么问题都不知道谈何配置。所以这篇内容我打算换个角度不聊架构、不聊源码就聊一件事如果你刚装好 DSH想快速感受到它到底能帮你做什么哪几个插件值得优先装上。我按自己的使用顺序和踩坑经验挑了 8 个覆盖不同场景的插件从代码诊断、文档读取、多智能体编排到本地模型接入都有涉及。每个插件我都会说清楚它解决什么问题、装完之后怎么验证生效、以及我在实际使用中遇到过的坑。需要先说明一点DSH 的插件生态更新很快版本号、命令参数可能会变。我下面提到的安装命令和配置方式是基于我写这篇内容时的版本实测可用的如果你照着做发现对不上优先去看插件仓库的 README那才是最准的。另外插件安装本身涉及 profile 的概念新手容易在这里翻车我会在第 2 节专门讲清楚。这篇文章适合三类人刚装完 DSH 想快速上手的新手、用过一段时间但插件装得比较杂想重新梳理的老用户、以及想了解 DSH 插件体系到底能覆盖哪些场景的观望者。不管你是哪种我都建议你按顺序读因为后面的插件会依赖前面讲的一些基础概念。2. 装插件之前先把 profile 和插件树这两个概念搞明白2.1 profile 到底是什么为什么装插件要指定它很多人第一次看到dsh plugin --profile web add xxx这条命令时会懵为什么装个插件还要带--profile这个 profile 你可以理解成工作场景的隔离容器。DSH 允许你同时维护多套插件组合比如一套给 Web 开发用一套给数据分析用互不干扰。web只是其中一种常见的 profile 名称你也可以叫data、daily随便什么名字。这么设计的好处是你不需要为了切换场景去反复卸载重装插件。坏处是新手如果不知道自己在哪个 profile 下操作就会出现我明明装了插件怎么界面上没有的经典问题。我踩过这个坑当时装了三次都以为失败了最后发现是装到了另一个 profile 里。提示装插件前先确认当前 profile命令里显式带上--profile参数不要依赖默认值能省掉大量排查时间。2.2 插件树加载失败是怎么回事热词里有个报错信息很典型error: dsh: plugin tree failed to load: dsh: plugin(s) failed to load。这个报错的意思是插件依赖树在加载阶段就断了通常是某个插件依赖的另一个插件没装、版本对不上或者插件本身和当前 DSH 版本不兼容。排查思路我总结成三步第一步看报错里具体点名了哪个插件deep开头的通常是官方插件第三方的一般带作者名第二步单独把那个插件卸掉看 DSH 能不能正常启动能启动就说明是它的问题第三步去插件仓库确认它要求的 DSH 版本范围版本不匹配就退回旧版本或者等更新。这个流程我在第 6 节还会展开讲这里先有个印象就行。3. 代码诊断类插件让 DSH 真正看懂你的代码3.1 代码诊断插件解决的核心痛点DSH 本体对代码的理解是文本级的它能读你的文件内容但不知道这段代码在语法上有没有问题、类型对不对、有没有明显的坏味道。代码诊断插件的作用就是补上这一层把静态分析能力接进来让 DSH 在给你建议之前先过一遍检查。我实测下来装了诊断插件之后DSH 给出的修改建议准确率有明显提升。原因很简单没有诊断的时候它只能靠语言模型自己判断容易漏掉一些低级错误有了诊断它拿到的是结构化的错误列表改起来有的放矢。这个插件特别适合做代码审查、重构辅助、以及接手别人代码时快速摸清问题分布。3.2 安装与验证的完整步骤安装命令本身不复杂关键是装完要验证。我一般按这个流程走执行安装命令带上明确的 profile 参数重启 DSH观察启动日志里有没有插件加载成功的记录打开一个有明显问题的代码文件触发一次诊断看能不能返回错误列表如果没反应检查插件是否在当前 profile 下启用验证这一步很多人会跳过结果用的时候才发现没生效又回头排查反而更费时间。我建议养成装完必验的习惯哪怕只是随便找个文件跑一下。3.3 实操心得诊断规则怎么调才不烦人诊断插件默认的规则集通常比较严格新手容易被满屏的警告吓到。我的做法是先把规则分成三档致命错误必须修、风格问题先忽略、可疑写法标记待查。这样既能保证代码质量又不会被噪音淹没。另外不同语言的诊断规则差异很大。如果你主要写 Python重点看类型检查和未使用变量这两类如果写前端重点看依赖引用和异步处理。不要指望一套配置通吃所有语言按项目类型分别配置更实际。4. 文档读取插件让 DSH 能直接吃 PDF 和 Word4.1 为什么这个插件对新手特别友好DSH 默认只能处理纯文本和代码文件你丢一个 PDF 或者 Word 进去它读不了。文档读取插件就是解决这个问题的装上之后DSH 可以直接解析 PDF、Word、甚至部分扫描件的内容然后基于文档内容回答问题、做总结、提取要点。这个插件对新手友好的地方在于它不需要你懂任何技术细节装完就能用。你把手头的需求文档、产品说明、技术手册丢进去直接问它问题就行。我经常用它来快速消化一份几十页的技术文档比我自己一页页翻快得多。4.2 配置读取范围和格式支持文档读取插件一般会提供几个配置项支持的文件格式、单文件大小上限、是否启用 OCR。我的建议是格式全开大小上限按你机器的内存来定OCR 只在确实需要处理扫描件时才开因为它比较吃资源。注意处理大文档时插件会先把内容切块再送进模型切块策略会影响回答质量。如果发现它总是答非所问多半是切块把关键信息切断了可以调整切块大小试试。4.3 实操心得怎么问才能拿到准确答案文档读取插件装好之后提问方式很关键。我试过直接问这份文档讲了什么得到的回答往往很泛。后来我改成先问结构、再问细节先让它列出文档的章节结构然后针对具体章节追问。这样拿到的答案精准得多也不容易漏掉重要内容。还有一个技巧是如果文档里有表格明确告诉它请把第 X 页的表格整理成 Markdown 格式比让它自己判断要不要处理表格效果好很多。模型不会读心你把需求说清楚它才能给对结果。5. 多智能体编排插件把复杂任务拆给多个 Agent5.1 harness 和 agent 的区别先理清楚热词里反复出现harness 和 agent 区别这个问题确实值得说清楚。简单讲harness 是骨架agent 是干活的。DSH 本体提供的是 harness 能力——任务调度、上下文管理、插件加载这些底层机制agent 则是具体执行任务的智能体一个 agent 负责一件事多个 agent 组合起来才能完成复杂工作。多智能体编排插件的作用就是让你能定义多个 agent、指定它们之间的协作关系、控制任务流转。比如你可以定义一个 agent 负责读代码一个负责写测试一个负责审查编排插件负责把它们串起来。这个能力在复杂项目里非常有用但新手不建议一上来就玩先把单 agent 用熟再说。5.2 编排配置的核心参数编排插件的配置一般包含这几块agent 列表、每个 agent 的职责描述、任务流转规则、失败重试策略。我重点说两个容易配错的参数。第一个是职责描述。这个描述不是写给人看的是写给模型看的所以要写得具体、可执行。比如负责代码审查太泛检查代码中的空指针、边界条件和异常处理输出问题列表就具体得多。第二个是失败重试策略。默认不重试的话一个 agent 失败整个流程就断了重试次数设太多又容易卡死。我的经验是设 2 到 3 次并且加上超时限制避免某个 agent 卡住拖垮整个流程。5.3 实操心得从两个 agent 开始别贪多我见过不少新手一上来就配五六个 agent结果调试起来一团乱根本不知道是哪一步出的问题。我的建议是从两个 agent 开始一个负责生成一个负责检查跑通了再往上加。每加一个 agent都要单独验证它的输入输出是否符合预期确认没问题再接入主流程。另外agent 之间的上下文传递要控制好。传太多模型会被无关信息干扰传太少下游 agent 又缺信息。我的做法是只传必要字段并且在职责描述里明确说明每个 agent 需要哪些输入。6. 本地模型接入插件把 DSH 接到你自己的模型上6.1 本地部署场景下的接入逻辑有些朋友出于数据隐私或者成本的考虑想把 DSH 接到本地跑的模型上。本地模型接入插件就是干这个的它负责把 DSH 的请求转发到你本地的模型服务再把结果拿回来。整个链路是DSH 发请求 → 接入插件转换格式 → 本地模型服务处理 → 结果回传。这个插件配置的关键是地址和端口要对上以及模型的思考模式要正确开启。热词里提到配置连接本地模型思考模式这个确实是个坑点——有些本地模型默认不输出思考过程接入插件如果没正确配置DSH 拿到的结果会缺一块影响后续判断。6.2 配置步骤与参数说明配置流程大致是这样确认本地模型服务已经跑起来能独立响应请求在接入插件里填写服务地址、端口、模型名称配置思考模式开关和超时时间保存后重启 DSH发一个测试请求验证链路超时时间这个参数要特别注意。本地模型如果跑在普通机器上响应速度可能比云端慢不少超时设太短会频繁失败。我一般先设一个宽松的值跑通之后再根据实际响应时间收紧。6.3 实操心得本地部署最容易翻车的三个点第一个是端口冲突。本地模型服务和别的服务抢端口表现是插件连不上但模型服务本身是好的。排查时先确认端口占用情况。第二个是模型名称对不上。接入插件里填的模型名必须和本地服务实际加载的模型名完全一致差一个字符都不行。第三个是思考模式配置。这个我在上面提过再强调一次如果你的本地模型支持思考过程输出一定要在插件里开启对应选项否则 DSH 拿到的结果质量会打折扣。7. 插件安装失败与版本回退的排查实录7.1 安装失败的常见原因速查我把新手最常遇到的安装失败原因整理成了一张表方便对照排查报错现象可能原因排查方向插件树加载失败依赖缺失或版本不兼容检查报错点名的插件确认版本范围装完不生效profile 不对确认安装和使用的 profile 一致启动直接崩溃插件与 DSH 版本冲突回退 DSH 或插件版本命令执行无反应网络或源地址问题检查插件源配置这张表我建议存下来遇到问题先对照一遍能省掉不少瞎折腾的时间。7.2 版本回退的正确姿势热词里有人问怎么退回到 v0.1.5-rc.2说明版本回退是个真实需求。回退的原则是先退插件再退本体。因为很多时候问题出在某个插件上退掉它就好了没必要动本体。如果确实要退本体步骤是先记录当前版本和已装插件列表然后卸载本体装回目标版本再逐个把插件装回来。这个过程比较繁琐所以我的建议是升级之前先备份配置出问题能快速恢复。7.3 实操心得升级前必做的两件事第一件事把当前能正常工作的插件列表导出保存。这样万一升级出问题你能快速知道该装回哪些。第二件事在非主力 profile 里先试升级。确认没问题再动主力 profile避免影响日常使用。这个习惯我坚持了很久帮我躲过了好几次升级翻车。8. 新手装插件的顺序建议与避坑清单8.1 推荐的安装顺序如果你是完全的新手我建议按这个顺序装先装文档读取插件因为它最容易验证效果装完丢个 PDF 进去就能看到反馈再装代码诊断插件如果你写代码的话然后根据需求决定要不要装本地模型接入最后再考虑多智能体编排这个留到你有一定使用经验之后。这个顺序的逻辑是从易到难、从独立到协作。先建立信心再逐步深入比一上来就啃硬骨头体验好得多。8.2 新手最容易踩的五个坑不指定 profile 就装插件装完找不到装完不验证用的时候才发现没生效一次装太多插件出问题不知道是哪个升级前不备份出问题回不去编排插件配太复杂调试成本远超收益这五个坑我基本都踩过写出来是希望你能绕过去。插件这东西装得对比装得多重要得多。8.3 我个人的使用体会用了这么久 DSH 的插件体系我最大的感受是它的价值不在于插件数量而在于你能不能把几个核心插件用透。我现在的日常配置其实很精简就文档读取、代码诊断加一个本地模型接入覆盖了我 90% 的使用场景。剩下的插件我都是按需临时装用完就卸保持环境干净。插件装多了启动变慢、冲突变多、排查变难这些都是实打实的成本。所以我的建议是先把这 8 个里最贴合你需求的两三个装好、用熟再考虑扩展。等你对插件之间的依赖关系有了感觉再往上加就轻松多了。
1. 为什么我劝新手从这 8 个 DSH 插件开始上手刚接触 DSHDeepSeek Harness的朋友十有八九会卡在同一个地方装好了本体打开界面然后盯着空荡荡的插件列表发呆不知道下一步该干什么。我当初也是这样翻了一圈文档发现官方把能力都拆成了插件核心只保留一个调度骨架剩下的全靠你自己按需拼装。这个设计思路其实很聪明但对新手来说门槛确实不低——你连有哪些插件、每个插件解决什么问题都不知道谈何配置。所以这篇内容我打算换个角度不聊架构、不聊源码就聊一件事如果你刚装好 DSH想快速感受到它到底能帮你做什么哪几个插件值得优先装上。我按自己的使用顺序和踩坑经验挑了 8 个覆盖不同场景的插件从代码诊断、文档读取、多智能体编排到本地模型接入都有涉及。每个插件我都会说清楚它解决什么问题、装完之后怎么验证生效、以及我在实际使用中遇到过的坑。需要先说明一点DSH 的插件生态更新很快版本号、命令参数可能会变。我下面提到的安装命令和配置方式是基于我写这篇内容时的版本实测可用的如果你照着做发现对不上优先去看插件仓库的 README那才是最准的。另外插件安装本身涉及 profile 的概念新手容易在这里翻车我会在第 2 节专门讲清楚。这篇文章适合三类人刚装完 DSH 想快速上手的新手、用过一段时间但插件装得比较杂想重新梳理的老用户、以及想了解 DSH 插件体系到底能覆盖哪些场景的观望者。不管你是哪种我都建议你按顺序读因为后面的插件会依赖前面讲的一些基础概念。2. 装插件之前先把 profile 和插件树这两个概念搞明白2.1 profile 到底是什么为什么装插件要指定它很多人第一次看到dsh plugin --profile web add xxx这条命令时会懵为什么装个插件还要带--profile这个 profile 你可以理解成工作场景的隔离容器。DSH 允许你同时维护多套插件组合比如一套给 Web 开发用一套给数据分析用互不干扰。web只是其中一种常见的 profile 名称你也可以叫data、daily随便什么名字。这么设计的好处是你不需要为了切换场景去反复卸载重装插件。坏处是新手如果不知道自己在哪个 profile 下操作就会出现我明明装了插件怎么界面上没有的经典问题。我踩过这个坑当时装了三次都以为失败了最后发现是装到了另一个 profile 里。提示装插件前先确认当前 profile命令里显式带上--profile参数不要依赖默认值能省掉大量排查时间。2.2 插件树加载失败是怎么回事热词里有个报错信息很典型error: dsh: plugin tree failed to load: dsh: plugin(s) failed to load。这个报错的意思是插件依赖树在加载阶段就断了通常是某个插件依赖的另一个插件没装、版本对不上或者插件本身和当前 DSH 版本不兼容。排查思路我总结成三步第一步看报错里具体点名了哪个插件deep开头的通常是官方插件第三方的一般带作者名第二步单独把那个插件卸掉看 DSH 能不能正常启动能启动就说明是它的问题第三步去插件仓库确认它要求的 DSH 版本范围版本不匹配就退回旧版本或者等更新。这个流程我在第 6 节还会展开讲这里先有个印象就行。3. 代码诊断类插件让 DSH 真正看懂你的代码3.1 代码诊断插件解决的核心痛点DSH 本体对代码的理解是文本级的它能读你的文件内容但不知道这段代码在语法上有没有问题、类型对不对、有没有明显的坏味道。代码诊断插件的作用就是补上这一层把静态分析能力接进来让 DSH 在给你建议之前先过一遍检查。我实测下来装了诊断插件之后DSH 给出的修改建议准确率有明显提升。原因很简单没有诊断的时候它只能靠语言模型自己判断容易漏掉一些低级错误有了诊断它拿到的是结构化的错误列表改起来有的放矢。这个插件特别适合做代码审查、重构辅助、以及接手别人代码时快速摸清问题分布。3.2 安装与验证的完整步骤安装命令本身不复杂关键是装完要验证。我一般按这个流程走执行安装命令带上明确的 profile 参数重启 DSH观察启动日志里有没有插件加载成功的记录打开一个有明显问题的代码文件触发一次诊断看能不能返回错误列表如果没反应检查插件是否在当前 profile 下启用验证这一步很多人会跳过结果用的时候才发现没生效又回头排查反而更费时间。我建议养成装完必验的习惯哪怕只是随便找个文件跑一下。3.3 实操心得诊断规则怎么调才不烦人诊断插件默认的规则集通常比较严格新手容易被满屏的警告吓到。我的做法是先把规则分成三档致命错误必须修、风格问题先忽略、可疑写法标记待查。这样既能保证代码质量又不会被噪音淹没。另外不同语言的诊断规则差异很大。如果你主要写 Python重点看类型检查和未使用变量这两类如果写前端重点看依赖引用和异步处理。不要指望一套配置通吃所有语言按项目类型分别配置更实际。4. 文档读取插件让 DSH 能直接吃 PDF 和 Word4.1 为什么这个插件对新手特别友好DSH 默认只能处理纯文本和代码文件你丢一个 PDF 或者 Word 进去它读不了。文档读取插件就是解决这个问题的装上之后DSH 可以直接解析 PDF、Word、甚至部分扫描件的内容然后基于文档内容回答问题、做总结、提取要点。这个插件对新手友好的地方在于它不需要你懂任何技术细节装完就能用。你把手头的需求文档、产品说明、技术手册丢进去直接问它问题就行。我经常用它来快速消化一份几十页的技术文档比我自己一页页翻快得多。4.2 配置读取范围和格式支持文档读取插件一般会提供几个配置项支持的文件格式、单文件大小上限、是否启用 OCR。我的建议是格式全开大小上限按你机器的内存来定OCR 只在确实需要处理扫描件时才开因为它比较吃资源。注意处理大文档时插件会先把内容切块再送进模型切块策略会影响回答质量。如果发现它总是答非所问多半是切块把关键信息切断了可以调整切块大小试试。4.3 实操心得怎么问才能拿到准确答案文档读取插件装好之后提问方式很关键。我试过直接问这份文档讲了什么得到的回答往往很泛。后来我改成先问结构、再问细节先让它列出文档的章节结构然后针对具体章节追问。这样拿到的答案精准得多也不容易漏掉重要内容。还有一个技巧是如果文档里有表格明确告诉它请把第 X 页的表格整理成 Markdown 格式比让它自己判断要不要处理表格效果好很多。模型不会读心你把需求说清楚它才能给对结果。5. 多智能体编排插件把复杂任务拆给多个 Agent5.1 harness 和 agent 的区别先理清楚热词里反复出现harness 和 agent 区别这个问题确实值得说清楚。简单讲harness 是骨架agent 是干活的。DSH 本体提供的是 harness 能力——任务调度、上下文管理、插件加载这些底层机制agent 则是具体执行任务的智能体一个 agent 负责一件事多个 agent 组合起来才能完成复杂工作。多智能体编排插件的作用就是让你能定义多个 agent、指定它们之间的协作关系、控制任务流转。比如你可以定义一个 agent 负责读代码一个负责写测试一个负责审查编排插件负责把它们串起来。这个能力在复杂项目里非常有用但新手不建议一上来就玩先把单 agent 用熟再说。5.2 编排配置的核心参数编排插件的配置一般包含这几块agent 列表、每个 agent 的职责描述、任务流转规则、失败重试策略。我重点说两个容易配错的参数。第一个是职责描述。这个描述不是写给人看的是写给模型看的所以要写得具体、可执行。比如负责代码审查太泛检查代码中的空指针、边界条件和异常处理输出问题列表就具体得多。第二个是失败重试策略。默认不重试的话一个 agent 失败整个流程就断了重试次数设太多又容易卡死。我的经验是设 2 到 3 次并且加上超时限制避免某个 agent 卡住拖垮整个流程。5.3 实操心得从两个 agent 开始别贪多我见过不少新手一上来就配五六个 agent结果调试起来一团乱根本不知道是哪一步出的问题。我的建议是从两个 agent 开始一个负责生成一个负责检查跑通了再往上加。每加一个 agent都要单独验证它的输入输出是否符合预期确认没问题再接入主流程。另外agent 之间的上下文传递要控制好。传太多模型会被无关信息干扰传太少下游 agent 又缺信息。我的做法是只传必要字段并且在职责描述里明确说明每个 agent 需要哪些输入。6. 本地模型接入插件把 DSH 接到你自己的模型上6.1 本地部署场景下的接入逻辑有些朋友出于数据隐私或者成本的考虑想把 DSH 接到本地跑的模型上。本地模型接入插件就是干这个的它负责把 DSH 的请求转发到你本地的模型服务再把结果拿回来。整个链路是DSH 发请求 → 接入插件转换格式 → 本地模型服务处理 → 结果回传。这个插件配置的关键是地址和端口要对上以及模型的思考模式要正确开启。热词里提到配置连接本地模型思考模式这个确实是个坑点——有些本地模型默认不输出思考过程接入插件如果没正确配置DSH 拿到的结果会缺一块影响后续判断。6.2 配置步骤与参数说明配置流程大致是这样确认本地模型服务已经跑起来能独立响应请求在接入插件里填写服务地址、端口、模型名称配置思考模式开关和超时时间保存后重启 DSH发一个测试请求验证链路超时时间这个参数要特别注意。本地模型如果跑在普通机器上响应速度可能比云端慢不少超时设太短会频繁失败。我一般先设一个宽松的值跑通之后再根据实际响应时间收紧。6.3 实操心得本地部署最容易翻车的三个点第一个是端口冲突。本地模型服务和别的服务抢端口表现是插件连不上但模型服务本身是好的。排查时先确认端口占用情况。第二个是模型名称对不上。接入插件里填的模型名必须和本地服务实际加载的模型名完全一致差一个字符都不行。第三个是思考模式配置。这个我在上面提过再强调一次如果你的本地模型支持思考过程输出一定要在插件里开启对应选项否则 DSH 拿到的结果质量会打折扣。7. 插件安装失败与版本回退的排查实录7.1 安装失败的常见原因速查我把新手最常遇到的安装失败原因整理成了一张表方便对照排查报错现象可能原因排查方向插件树加载失败依赖缺失或版本不兼容检查报错点名的插件确认版本范围装完不生效profile 不对确认安装和使用的 profile 一致启动直接崩溃插件与 DSH 版本冲突回退 DSH 或插件版本命令执行无反应网络或源地址问题检查插件源配置这张表我建议存下来遇到问题先对照一遍能省掉不少瞎折腾的时间。7.2 版本回退的正确姿势热词里有人问怎么退回到 v0.1.5-rc.2说明版本回退是个真实需求。回退的原则是先退插件再退本体。因为很多时候问题出在某个插件上退掉它就好了没必要动本体。如果确实要退本体步骤是先记录当前版本和已装插件列表然后卸载本体装回目标版本再逐个把插件装回来。这个过程比较繁琐所以我的建议是升级之前先备份配置出问题能快速恢复。7.3 实操心得升级前必做的两件事第一件事把当前能正常工作的插件列表导出保存。这样万一升级出问题你能快速知道该装回哪些。第二件事在非主力 profile 里先试升级。确认没问题再动主力 profile避免影响日常使用。这个习惯我坚持了很久帮我躲过了好几次升级翻车。8. 新手装插件的顺序建议与避坑清单8.1 推荐的安装顺序如果你是完全的新手我建议按这个顺序装先装文档读取插件因为它最容易验证效果装完丢个 PDF 进去就能看到反馈再装代码诊断插件如果你写代码的话然后根据需求决定要不要装本地模型接入最后再考虑多智能体编排这个留到你有一定使用经验之后。这个顺序的逻辑是从易到难、从独立到协作。先建立信心再逐步深入比一上来就啃硬骨头体验好得多。8.2 新手最容易踩的五个坑不指定 profile 就装插件装完找不到装完不验证用的时候才发现没生效一次装太多插件出问题不知道是哪个升级前不备份出问题回不去编排插件配太复杂调试成本远超收益这五个坑我基本都踩过写出来是希望你能绕过去。插件这东西装得对比装得多重要得多。8.3 我个人的使用体会用了这么久 DSH 的插件体系我最大的感受是它的价值不在于插件数量而在于你能不能把几个核心插件用透。我现在的日常配置其实很精简就文档读取、代码诊断加一个本地模型接入覆盖了我 90% 的使用场景。剩下的插件我都是按需临时装用完就卸保持环境干净。插件装多了启动变慢、冲突变多、排查变难这些都是实打实的成本。所以我的建议是先把这 8 个里最贴合你需求的两三个装好、用熟再考虑扩展。等你对插件之间的依赖关系有了感觉再往上加就轻松多了。
