小型语言模型（SLM）调研：从端侧部署到专业化 Agent

小型语言模型SLM调研从端侧部署到专业化 Agent调研时间2026-06-12适用读者关注本地 AI、端侧 Agent、低成本推理、私有化部署和模型选型的开发者核心观点小模型不再只是“大模型的低配替代品”。在工具调用、代码补全、端侧助手、隐私敏感任务和固定流程自动化中小模型正在成为更经济、更可控、更容易落地的默认选项。但在复杂推理、开放式长文档理解和高可靠多轮规划中大模型仍然是必要兜底。目录为什么重新关注小模型主流小模型版图代表模型与适用场景关键趋势小模型正在变强的原因行业观察与洞察结论应用场景与边界模型选型指南生产落地架构如何验证一个小模型是否可用值得继续关注的项目参考资料1. 为什么重新关注小模型过去两年开发者谈 AI 应用时默认会从大模型开始更强的推理、更好的泛化、更少的工程约束。但真实业务系统里大量请求并不需要通用智能而是更接近下面这些任务把自然语言路由到一个 API 或工具从固定格式中抽取参数在局部代码上下文中补全几行代码对本地文档做轻量问答或分类在手机、浏览器、边缘设备上执行低延迟推理在企业内网处理敏感数据不上传到外部服务。这些任务的共同点是输入空间有限、输出格式可约束、业务目标明确、可收集领域数据。小模型在这些条件下通常更有优势维度小模型优势代价成本推理成本低可本地部署需要更精细的评估和路由延迟CPU、NPU、浏览器 WASM 均可运行首 token 质量和复杂推理弱于大模型隐私数据不必离开设备或内网运维和模型更新由自己负责可控性容易微调、蒸馏和约束输出泛化能力有限工程集成可作为系统中的专用组件需要 fallback 和监控因此小模型更合理的定位不是“替代所有大模型”而是成为 AI 系统中的第一层执行器高频、低风险、格式明确的任务交给小模型低置信度或复杂任务再交给大模型。2. 主流小模型版图下面按照参数规模和模型定位梳理当前值得关注的小模型。表格中的性能数字来自模型卡、官方博客或公开 benchmark不同评测集之间不可直接等价应作为选型线索而不是最终结论。2.1 极小模型100M 以下这类模型通常不适合开放式对话更适合作为分类器、路由器、格式化抽取器、嵌入式 demo 或研究对象。模型参数量典型定位License备注Needle26M单轮工具调用MIT极窄专家模型专注 function/tool callingDoge-60M55M超轻量语言模型Apache 2.0适合研究和极低资源实验Lite-Oute-1-65M65M移动端轻量模型Apache 2.0偏端侧部署llama-68m68M社区小模型Apache 2.0生态活跃度较高Yuuki NxG Nano81M低成本训练实验Apache 2.0适合观察小模型训练方法Pythia-70M约 96M可复现实验Apache 2.0EleutherAI训练过程透明这一区间的核心价值不是“聪明”而是“便宜、快、可控”。如果任务可以被定义为分类、路由、抽取或模板化生成它们才有实际意义。2.2 100M 到 1.5B端侧和轻量服务的主力区间模型参数量上下文License适合场景SmolLM2-135M135M8KApache 2.0教学、研究、轻量文本任务SmolLM2-360M360M8KApache 2.0轻量问答、分类、实验Qwen3-0.6B0.6B32KApache 2.0多语言、端侧、轻量 AgentQwen3.5-0.8B0.8B262K 级别Apache 2.0较新小模型规格以模型卡和平台支持为准LFM 2.5 1.2B1.2B依实现而定待确认非 Transformer/混合架构速度表现突出MobileLLM-Flash 1.4B1.4B依实现而定Research面向移动端推理DeepSeek-R1-Distill-Qwen-1.5B1.5B依版本而定Apache 2.0推理蒸馏、CoT 类任务这个区间最值得关注的是 Qwen、SmolLM、LFM 等模型家族。它们已经能承担部分真实业务任务但仍需要明确边界不要把 1B 级模型当成通用助理而应把它们放在“结构化、可验证、可兜底”的系统里。2.3 1.5B 到 4B当前性价比最高的通用小模型区间模型参数量上下文License亮点主要限制Qwen3-1.7B1.7B32KApache 2.0多语言、推理、Agent 能力均衡端侧部署需量化和性能测试SmolLM3-3B3B128KApache 2.0Hugging Face 出品长上下文、双模式推理代码和复杂 Agent 能力需单独评测Qwen2.5-Coder-3B3.1B32KApache 2.0本地代码补全和代码生成强非通用 Agent 模型Llama 3.2 3B3B128KMeta Community生态成熟、工具链完善License 不是 Apache/MITPhi-4-mini3.8B128KMIT推理能力强、体积小仍建议以具体模型卡为准Gemma 3 4B4B128KGemma Terms多模态、数学和代码能力强许可证和使用条款需评估Qwen3-4B4B32K 原生可扩展Apache 2.0综合能力强开源友好长上下文扩展需实测Qwen3.5-4B4B262K 级别Apache 2.0新一代长上下文、工具和推理能力较新模型生态成熟度仍在变化如果目标是“本地可用但能力不要太弱”3B 到 4B 是目前最值得测试的范围。它们在 4-bit 量化后可以进入普通消费级设备但实际体验强依赖硬件、推理框架、上下文长度和任务类型。2.4 多模态与专项小模型模型参数量方向适合场景SmolVLM256M-2B视觉-语言图片理解、端侧 VLMGemma 3n E4B4B effective端侧多模态移动端视觉、语音、文本任务Gemma 4 small/edge modelssmall/edge 系列多模态、Agent、function calling端侧多模态和工具调用Qwen3-VL compact models4B/8B 等视觉-语言截图理解、视觉问答、GUI AgentNorth Mini Code3B active / MoE代码生成本地代码助手、低成本代码服务多模态小模型是接下来一年最值得关注的方向之一。原因很简单端侧 AI 真正有价值的场景往往不是纯文本而是摄像头、屏幕、语音、传感器和本地应用状态共同参与。3. 代表模型与适用场景3.1 Qwen 系列开源友好、能力均衡Qwen3 公开了从 0.6B 到 32B 的 dense models也包括 MoE 模型官方说明为 Apache 2.0。对小模型开发者来说Qwen 的优势主要有三点中文和多语言能力相对稳模型尺寸覆盖完整从 0.6B 到 4B 都有可选项推理、工具调用、代码、长上下文能力比较均衡。推荐用法任务建议模型轻量本地问答/分类Qwen3-0.6B、Qwen3.5-0.8B本地 Agent 原型Qwen3-1.7B稳定一点的本地通用助手Qwen3-4B、Qwen3.5-4B代码专项Qwen2.5-Coder-3B需要注意的是Qwen3.5 属于较新的模型家族Hugging Face collection、推理平台和第三方评测已经提供了不少规格和部署信息但正式选型时仍建议以具体模型卡、运行框架支持和自己的 benchmark 为准。3.2 SmolLM 系列研究友好和训练透明SmolLM 系列由 Hugging Face 推出特点是模型规模清晰、训练资料相对完整、适合研究和教学。SmolLM3-3B 支持长上下文和 dual-mode reasoning是 3B 区间值得对比的基线。推荐用法教学和研究SmolLM2-135M、SmolLM2-360M长上下文小模型实验SmolLM3-3B构建可复现训练和评测流程优先考虑 SmolLM 家族。SmolLM 的价值不只是模型本身还在于它提供了一个相对透明的小模型训练参考系。3.3 Gemma 系列强能力但需要关注条款Gemma 3 4B 已经是 4B 档位中很强的候选具备 128K 上下文、多语言和多模态能力。Google 近期也发布了 Gemma 4官方文档强调 small/edge models 具备 128K 上下文、function calling、coding 和 agentic capabilities。推荐用法多模态端侧应用数学、代码和通用推理需要 Google 生态兼容的应用。需要注意的是Gemma 使用 Google 的 Gemma Terms不是 Apache 2.0 或 MIT。商业使用前应单独检查条款。3.4 Phi 系列小体积推理能力强Phi-4-mini 这类模型的优势在于小体积下的推理和知识密度。它适合做本地推理助手、低资源问答、数学或逻辑类任务的候选模型。Phi-4-mini 常见模型卡显示为 MIT License但 Phi 系列存在不同版本和分发渠道商用、再分发、微调发布等场景仍应以具体模型卡和许可证文件为准。3.5 Needle极窄专家模型的代表Needle 是 Cactus Compute 在 2026 年 5 月发布的 26M function/tool calling 模型。它的特殊之处不是“通用能力强”而是把一个任务做到非常窄单轮工具调用。核心信息属性说明参数量26M量化后体积约 14MB架构Simple Attention Network去掉 Transformer 中的 MLP/FFN任务单轮 function/tool callingLicenseMIT官方速度Cactus Runtime 上约 6000 tok/s prefill、1200 tok/s decodeNeedle 的启发在于并不是所有 Agent 子任务都需要通用 LLM。工具选择、参数填充、JSON 生成等环节可以被拆成更小、更快、更可验证的组件。但它的边界也非常清楚不适合开放式对话不负责复杂推理缺少天然拒绝机制输入不匹配时仍可能生成工具调用生产中需要 guard、置信度阈值和 fallback。因此Needle 更适合作为“工具路由器”或“结构化调用层”不是通用小模型的替代品。3.6 LFM、Mamba 和 MoE架构路线正在分化除了标准 Transformer小模型领域还在探索混合架构LFM 2.5 等非 Transformer/混合模型强调速度和长序列效率Falcon-H1-Tiny 等模型使用 Mamba AttentionNorth Mini Code 等 MoE 模型用较低激活参数获得更大容量Qwen3.5 等新模型也出现了 hybrid architecture 的描述。这类模型值得关注但选型时要更谨慎生态、推理框架、量化支持、部署文档往往比模型指标更重要。4. 关键趋势小模型正在变强的原因4.1 专业化而不是小号通用模型小模型最容易成功的路线不是“什么都做一点”而是聚焦任务代码模型专注代码语料和代码评测工具调用模型专注 schema、参数和 JSON端侧多模态模型专注摄像头、屏幕和语音场景轻量问答模型专注 RAG 后的短答案生成。专业化让模型不必把有限参数浪费在过宽的能力面上。4.2 蒸馏和合成数据成为核心生产方式小模型的能力很大程度来自大模型蒸馏用强模型生成训练数据、推理轨迹、工具调用样本再训练小模型执行固定任务。这意味着未来的常见架构会是训练阶段大模型生成数据 / 评审数据 / 修正样本 推理阶段小模型本地执行 / 大模型低频兜底“训练靠大模型推理用小模型”会成为很多垂直场景的默认实践。4.3 长上下文下沉到小模型过去长上下文主要属于大模型。现在部分 3B-4B 模型已经支持 128K 上下文一些较新的小模型或平台版本也宣称支持 256K 级别上下文。长上下文并不自动等于强理解但它让小模型能处理更多本地上下文例如单个代码仓库片段长会议记录本地知识库检索结果多轮工具调用状态GUI 或浏览器操作轨迹。需要注意的是长上下文会显著增加 KV cache 和延迟端侧部署不能只看“最大上下文”。4.4 约束解码和结构化输出降低了模型压力很多业务场景并不需要模型自由发挥而是需要输出合法 JSON、选中一个工具、填对几个参数。通过约束解码、schema validation、grammar decoding 和后处理校验可以把生成空间缩小很多。这对小模型尤其重要让模型只在允许范围内生成比期待它自然学会所有格式规范更可靠。5. 行业观察与洞察结论5.1 AI 应用架构正在从“单模型调用”变成“模型分层系统”早期 AI 应用通常是一个前端加一个大模型 API用户输入直接交给大模型模型负责理解、推理、生成、调用工具和兜底。这个架构简单但成本高、延迟不稳定也很难解释每一次失败来自哪里。小模型普及后更合理的架构会变成分层系统规则和传统模型处理确定性逻辑、权限、安全、简单分类 小模型处理高频、低风险、结构化、可验证任务 大模型处理复杂推理、开放式任务、异常兜底 人工流程处理高风险、不可自动决策的场景未来的 AI 工程能力不只是“会调用哪个大模型”而是“会把任务拆到合适的智能层级”。模型路由、评测、监控、fallback、数据闭环会比单次 prompt 设计更重要。5.2 端侧 AI 会从体验优化变成产品能力端侧小模型的价值不只是省钱。它会改变产品形态低延迟语音助手、车载座舱、AR 眼镜、输入法、代码补全等场景不能每一步都等云端返回。隐私医疗、金融、办公文档、个人日程、企业代码等数据更适合在本地处理。离线可用可穿戴设备、工业现场、车载系统和跨境应用都需要弱网甚至断网能力。个性化本地模型更容易基于用户行为持续适配而不必把所有数据上传。因此端侧 AI 不是云端 AI 的低配版而是另一种产品能力靠近用户、靠近数据、靠近设备传感器。5.3 开源小模型会压缩中间层 API 的利润空间大模型 API 仍然会有价值尤其在复杂推理和高质量生成上。但对大量中低复杂度任务来说开源小模型会不断压低成本基线。这会带来三个变化只包装通用模型 API 的应用会越来越难形成壁垒真正的壁垒会转向业务数据、工作流集成、评测体系和交付能力企业会更倾向于混合架构内部小模型处理常规任务外部大模型处理疑难请求。换句话说模型能力本身会继续商品化系统能力和行业数据会变得更值钱。5.4 小模型让“私有数据飞轮”更容易建立大模型 API 时代很多团队没有持续训练和微调的习惯因为成本、权限和工具链都比较重。小模型降低了这件事的门槛真实用户请求 - 失败样本 - 人工/大模型修正 - 小模型微调 - 回归评测 - 灰度上线这套闭环一旦跑起来小模型会越来越贴合某个企业、某个产品、某个流程。长期看通用模型提供基础能力垂直小模型承接业务经验这会成为企业 AI 落地的重要路线。5.5 Agent 的瓶颈不只是模型智商而是可靠执行Agent 热潮容易让人误以为核心问题是“找一个更聪明的模型”。但真实系统里的难点通常是工具描述是否清晰权限和状态是否可控每一步输出是否可验证失败后能否恢复是否知道什么时候不该行动是否能在成本和延迟预算内完成任务。小模型在 Agent 系统里的角色往往不是替代大模型思考而是承担稳定的执行部件路由、抽取、格式化、校验、短链路工具调用。Agent 要真正进入生产靠的是“可控执行链”不是单纯更长的思维链。5.6 行业会出现更多“模型组合”而不是单一赢家未来不会只有一个最强小模型通吃所有场景。更可能出现的是模型组合层级典型模型/方法作用规则层规则、正则、传统分类器处理确定性逻辑和低成本过滤极小模型100M 以下模型、专用 tool model路由、抽取、简单结构化输出轻量模型0.5B-1.7B端侧问答、RAG 短答、轻量 Agent能力模型3B-4B本地助手、代码、多语言、长上下文大模型GPT/Claude/Gemini/大参数开源模型复杂推理、兜底、数据生成和评审对企业和开发者来说关键问题不是“哪个模型最强”而是“哪个组合在我的业务里最稳、最便宜、最好维护”。5.7 洞察结论综合来看小模型的发展代表了 AI 行业从“能力崇拜”走向“工程效率”的阶段变化。大模型继续推动能力上限小模型负责把这些能力拆解、压缩、部署到真实产品里。可以把未来两三年的趋势概括为五句话大模型定义上限小模型决定普及速度。通用能力会商品化行业数据和评测体系会成为壁垒。端侧 AI 会从可选优化变成关键产品能力。Agent 的核心竞争力会从 prompt 转向可靠执行链。最优解不是选一个模型而是构建可评测、可路由、可迭代的模型系统。6. 应用场景与边界6.1 适合小模型优先的场景场景推荐模型类型原因单轮工具调用Needle、Qwen 小模型、专用微调模型输出结构明确可约束本地代码补全Qwen2.5-Coder-3B、North Mini Code代码上下文局部性强企业内网文档分类Qwen3-1.7B、SmolLM3-3B隐私和成本敏感RAG 后短答案生成Qwen3-1.7B、Qwen3.5-0.8B/4B上下文由检索控制移动端助手Qwen3-0.6B/1.7B、Gemma 3n、Gemma 4 small低延迟、本地运行浏览器/边缘 WorkerWASM/ONNX 小模型部署轻、靠近用户固定流程自动化专用微调模型任务边界清晰6.2 不适合完全交给小模型的场景场景风险高风险医疗、法律、金融建议需要更强模型、审计和人工复核复杂多步推理小模型容易中途偏航开放域深度问答参数知识不足幻觉风险高超长文档综合分析长上下文不等于稳定综合能力无明确评测集的 Agent无法判断真实可靠性需要强拒绝能力的安全场景很多小模型不会稳定 abstain一句话小模型适合“把确定的事做得便宜又快”不适合“在不确定中独立负责最终判断”。7. 模型选型指南7.1 按任务选任务首选候选备选重点验证单轮 Tool CallingNeedle、Qwen3-0.6B/1.7B 微调Qwen3.5-0.8B工具选择、参数 exact match、拒绝能力多步 AgentQwen3-1.7B/4BGemma 4 small、Phi-4-mini多轮状态、错误恢复、是否乱调用工具代码补全Qwen2.5-Coder-3BNorth Mini Code本仓库代码风格、延迟、隐私通用本地助手Qwen3-4B、Gemma 3/4 smallSmolLM3-3B、Phi-4-mini中文、推理、长上下文教学/研究SmolLM2、PythiaTinyLlama 类模型可复现性、训练资料端侧多模态Gemma 3n、Gemma 4 small、SmolVLMQwen3-VL compact设备兼容、功耗、模型格式超低资源路由Needle、100M 以下模型传统分类器误路由成本、fallback7.2 按资源选资源限制可考虑模型20MBNeedle INT4、传统 ML 分类器100MB100M 以下量化模型1GB RAMQwen3-0.6B、SmolLM2-360M、专用小模型3GB RAMQwen3-1.7B、Qwen3.5-0.8B、部分 3B Q44-8GB RAM/VRAMQwen3-4B、SmolLM3-3B、Gemma 3/4 small浏览器WASM/ONNX/WebGPU 优先模型越小越稳手机 NPU优先选择已有端侧 runtime 支持的模型7.3 按 License 选License 类型模型/家族备注MITNeedle商用友好仍需确认依赖许可Apache 2.0Qwen、SmolLM、Pythia、部分代码模型企业落地通常更容易Meta Community LicenseLlama 3.2需遵守 Meta 条款Gemma TermsGemma 3/4不是 Apache/MIT商用前需审条款MITPhi-4-mini 常见模型卡不同 Phi 版本和渠道仍需逐项确认选型时不要只看模型能力。License、推理框架、量化格式、部署工具链、社区活跃度经常比 benchmark 更决定能不能上线。8. 生产落地架构8.1 小模型优先大模型兜底用户请求 | v 轻量 Guard / 意图识别 / 安全检查 | -- 高置信度、低风险、结构化任务 -- 小模型处理 | | | -- 工具调用专用 tool model / Qwen 小模型 | -- 代码补全Coder 小模型 | -- RAG 短答1B-4B 通用小模型 | -- 低置信度、复杂推理、高风险任务 -- 大模型或人工复核这个架构的关键不是“永远用小模型”而是明确路由条件小模型能否给出置信度输出能否被校验错误成本是否可接受是否有 fallback是否能记录失败样本并持续微调。8.2 工具调用系统建议工具调用是小模型最容易落地的场景但也最容易被低估。建议把系统拆成几层用户输入 - 安全检查 / 意图分类 - 工具候选召回 Top-K - 小模型生成调用 JSON - JSON schema validation - 参数业务校验 - 执行工具 - 失败时 fallback 或追问特别注意 abstention 问题模型不仅要知道“调用哪个工具”还要知道“什么时候不该调用工具”。如果模型本身不会拒绝必须用外层 guard 或分类器补上。8.3 持续微调闭环小模型上线后的价值来自持续迭代1. 为每个任务构造初始评测集 2. 上线灰度记录失败样本 3. 人工或大模型修正失败样本 4. 加入训练集或偏好数据 5. 定期微调并回归测试 6. 只在指标提升且无关键回退时发布小模型微调成本低这是它相对大模型 API 的重要优势。但低成本不等于可以随意更新。每次更新都需要固定评测集和线上监控。9. 如何验证一个小模型是否可用不要只看公开 benchmark。真正的判断标准应该来自你的任务、数据和约束。9.1 最小评测集建议至少准备200-500 条真实或近似真实用户输入覆盖高频路径、低频路径、异常输入、恶意输入每条样本包含期望输出、可接受输出范围和错误等级工具调用任务要包含“不应调用任何工具”的负样本。9.2 核心指标指标说明Task success rate最终任务是否完成Exact match工具名、参数名、参数值是否完全匹配JSON validity输出是否是合法结构Schema pass rate是否通过 schema 校验Abstention accuracy不该调用时是否能拒绝P50/P95 latency平均延迟和尾延迟Memory peak峰值内存/显存Cost per 1K requests每千次请求成本Fallback rate有多少请求需要大模型兜底9.3 对比基线至少对比三类方案方案目的规则/传统分类器判断是否真的需要 LLM小模型判断本地部署收益大模型 API作为质量上限和 fallback 参考如果小模型只比规则系统好一点但复杂度高很多可能不值得引入。反过来如果小模型能覆盖相当一部分高频请求即使剩余请求交给大模型系统成本和延迟也会明显下降。10. 值得继续关注的项目项目关注理由Qwen 系列Apache 2.0中文、多语言、Agent 和代码能力均衡SmolLM 系列训练透明适合研究和复现Gemma 3/4多模态和端侧能力强Google 生态推进快Phi 系列小体积推理能力强Needle极窄专家模型和工具调用组件化的代表LFM 系列非 Transformer/混合架构方向SmolVLM端侧视觉语言模型Qwen3-VL compact modelsGUI Agent、截图理解、端侧视觉任务llama.cpp / GGUF 生态本地部署事实标准之一ONNX Runtime / WebGPU / WASM runtime浏览器和跨平台部署关键工具链awesome-mobile-llm端侧模型索引11. 参考资料以下资料用于核对模型信息、发布时间、上下文长度、许可和代表性指标。社区 benchmark 和博客应作为参考不应替代自己的业务评测。Cactus Compute Needle 官方博客https://cactuscompute.com/blog/needleNeedle GitHubhttps://github.com/cactus-compute/needleNeedle Hugging Facehttps://huggingface.co/Cactus-Compute/needleNeedle SAN 文档https://github.com/cactus-compute/needle/blob/main/docs/simple_attention_networks.mdQwen3 官方博客https://qwenlm.github.io/blog/qwen3/Qwen3 GitHubhttps://github.com/qwenLM/qwen3Qwen3-1.7B Hugging Facehttps://huggingface.co/Qwen/Qwen3-1.7BQwen3.5 Hugging Face Collectionhttps://huggingface.co/collections/Qwen/qwen35Qwen3.5 small models 规格参考https://artificialanalysis.ai/articles/qwen3-5-small-modelsSmolLM3 Hugging Facehttps://huggingface.co/HuggingFaceTB/SmolLM3-3BSmolLM3 官方博客https://huggingface.co/blog/smollm3Llama 3.2 官方博客https://ai.meta.com/blog/llama-3-2-connect-2024-vision-edge-mobile-devices/Llama 3.2 3B Hugging Facehttps://huggingface.co/meta-llama/Llama-3.2-3B-InstructPhi-4-mini Hugging Facehttps://huggingface.co/microsoft/Phi-4-mini-instructPhi-4-mini Microsoft Foundryhttps://ai.azure.com/catalog/models/Phi-4-mini-instructGemma 3 4B Hugging Facehttps://huggingface.co/google/gemma-3-4b-itGemma 3 Technical Reporthttps://arxiv.org/html/2503.19786v1Gemma 4 Google AI Docshttps://ai.google.dev/gemma/docs/coreGemma 4 Google Bloghttps://blog.google/innovation-and-ai/technology/developers-tools/gemma-4/Tool calling benchmark 示例https://github.com/MikeVeerman/tool-calling-benchmarkONNX Runtime Webhttps://onnxruntime.ai/docs/tutorials/web/llama.cpphttps://github.com/ggml-org/llama.cpp结语小模型的机会不在于证明“参数越少越好”而在于重新拆分 AI 应用架构把高频、结构化、可验证的任务交给便宜快速的小模型把复杂判断交给大模型或人工流程。从行业角度看小模型会让 AI 从“云端能力调用”进一步走向“本地智能基础设施”。未来真正有竞争力的 AI 产品不会只依赖某一个最强模型而会拥有自己的任务分层、模型路由、评测数据、失败样本闭环和持续优化机制。对开发者来说最务实的路线是先用业务数据做一个小评测集再同时测试规则系统、小模型和大模型。只有当小模型在真实任务上同时满足质量、延迟、成本和可维护性它才是一个真正值得上线的选择。如果您觉得有用欢迎点赞、转发、评论、关注。