首页/新闻资讯/正文详情

读懂大语言模型:预训练、SFT/RLHF对齐与千问模型谱系

发布时间:2026/11/6 5:27:58 来源:云帆数科 栏目:资讯中心
读懂大语言模型:预训练、SFT/RLHF对齐与千问模型谱系
简介这是一份面向大语言模型学习者与开发者的通义千问技术资料核心为阿里巴巴Qwen团队发布的官方技术报告适合希望系统了解Qwen系列模型架构设计、预训练流程与对齐策略的读者也可作为论文写作与模型选型时的参考依据。压缩包内共1个文件为PDF格式整体约1.53MB单篇文档即可完整呈现模型的训练数据构成、分词方案、上下文长度扩展方法及实验结果便于通读与检索。目前已有1698人学习下载具备一定的参考热度。资料正文从预训练数据、Tokenization、模型架构与上下文扩展等方面展开并介绍监督微调、RLHF人类反馈强化学习等对齐环节同时覆盖基础模型Qwen、对话模型Qwen-Chat以及面向编程的Code-Qwen和面向数学推理的Math-Qwen-Chat等衍生模型配有下游任务评测与智能体工具调用、代码解释器等复杂任务的对比结论可帮助读者理解开源模型与专有模型之间的性能差距及优化方向。1. 一句话说清大语言模型它其实是个读过三万亿字的“接话高手”不少人第一次听到“大语言模型”这五个字脑子里浮现的是一台会考试的机器。更贴切的比喻是它像是一个把海量文本通读了一遍、被训练成“接话高手”的统计系统——你给它上半句它算下半句最可能是什么。所谓“大”一是指参数多二是指读过的 token 多这套开源系列的基座模型训练规模已经到了三万亿 token 的量级。“千问”这个名字本身就是“千千万万个提问”的意思起得挺实在。搞清参数和 token 这两个词后面所有概念才有落脚点你也才能看懂一份技术资料里那些数字到底在说什么。2. 从“只会接话”到“听懂人话”预训练和对齐到底在做什么2.1 预训练三万亿 token 是怎么被“读”进去的先拆一个词token。它不是字也不是词而是介于两者之间的“碎块”。中文里一个字可能是一个 token也可能半个词才凑成一个 token具体怎么切由分词器的词表决定。模型不认识汉字它只认识一串整数编号所以“读文本”这件事在模型内部其实是“读编号序列”。也正因为如此同一段中文交给不同分词器切出来的块数可能差不少——这一点后面第 5 章还会展开。预训练的任务朴素到有点意外给前面的 token猜下一个 token 是什么。就这么一个动作在海量数据上重复几万亿次模型被逼着学会了语法、常识、算术规律甚至代码的括号怎么配对。通俗地说它不是被“教”会了推理而是在无数次“猜下一个”的过程中把语言里反复出现的结构压进了参数里。这也是为什么代码数据对通用能力有帮助——代码的语法严格、层级清晰猜下一个 token 的难度更高练出来的“结构感”能迁移到别处。数据这块是重头戏。这套系列的预训练语料包括公开网页、百科、书籍、代码等是多语言的其中中英文占大头。原始网页是不能直接用的得走一条清洗流水线先从 HTML 里把正文抽出来扔掉导航栏和广告再用语种识别工具判断这段文本是什么语言分门别类放好接着去重先做归一化之后的精确匹配去重把一模一样的段落删掉再用 MinHash 配合 LSH 这类近似算法做模糊去重把“改了几个字”的转载稿也揪出来。去重看着琐碎其实是玄学重灾区。重复数据会让模型把某几句话背得滚瓜烂熟浪费算力不说还会放大数据里本身的偏向。清洗完还不算完还要过质量关用多个模型给内容打分包括语言模型打分、文本质量评分模型、以及识别不当内容的模型同时人工从各个来源抽样看一遍确认机器没放过明显垃圾。最后一步是“上采样”——对少数高质量来源的数据重复采几次让模型多读几遍好东西。一套流程走完才攒出三万亿 token 这个量级。还有一块容易被忽略上下文长度。预训练阶段的窗口是有限的想让它一次处理更长的文档就得做窗口扩展通常是调整位置编码的表示方式再补一段训练让模型适应新长度。这不是改个配置就完事扩完还得重新验证短文本上的能力有没有退化——这类“改一处、崩一片”的情况在模型训练里太常见了。2.2 对齐SFT 是师傅示范RLHF 是师傅打分预训练完的模型有个毛病它太爱“接话”了。你问它“怎么把这段代码改成异步的”它可能接着你的问题再编一个问题出来因为它学的是“续写”不是“回答”。这一步就需要对齐把这台续写机器调教成能听懂指令的助手。第一道工序叫监督微调英文缩写 SFT。做法是准备一批高质量的问答样本人工写好“用户问什么、助手该怎么答”然后拿这些样本继续训练模型。它教的是格式、语气和边界什么时候该分点回答什么时候该拒绝什么时候该老老实实说“我不知道”。这批数据的覆盖面很关键技术资料里提到涵盖任务执行、闲聊、工具调用、智能体、安全等方向——缺哪一块模型在那类场景下就容易翻车。一条微调样本在结构上大概长这样# 一条对话微调样本的典型结构示意非真实数据 sample { system: 你是一个严谨的助手不确定时要说不知道, # 角色设定决定语气与边界 messages: [ {role: user, content: 把这段话改成给客户看的邮件}, # 用户输入 {role: assistant, content: 您好关于您提到的事项……} # 人工精修的目标回答 ], loss_mask: [0, 0, 1, 1] # 只在助手回答的部分算损失提问部分不参与 }这里三个参数各有分工。system是角色设定它不是装饰同一句提问配上不同的 system输出风格能差出一大截messages是对话轮次多轮样本能让模型学会“接着上文说”而不是每轮从零开始loss_mask是最容易被忽略的一项它规定只在助手的回答上计算损失如果连用户的提问一起算模型就会学成“复述问题”这也是不少自建微调踩过的坑。数据格式统一之后批量拼接、截断长度这些环节才不会出岔子。第二道工序叫基于人类反馈的强化学习英文缩写 RLHF。它的思路是同一个问题让模型生成多个回答请人给这些回答排序谁更好谁更差然后用这些排序数据训练一个“奖励模型”让它学会模仿人的偏好打分最后用强化学习把主模型往高分方向推。打个比方SFT 是师傅手把手示范一遍怎么做菜RLHF 是师傅站在旁边你做一道他尝一口打个分你根据分数调整火候和咸淡。前者教“怎么做”后者教“做成什么样更受欢迎”。两道工序不是二选一而是先后关系。跳过 SFT 直接上强化学习模型连基本格式都输出不稳奖励模型也没法给出有意义的分数只做 SFT 不做 RLHF回答虽然规整但在“两个都不算错、但一个更好”的场合里往往挑不中那个更让人舒服的。2.3 奖励模型那个替人打分的裁判也会被钻空子奖励模型的本质是把人的偏好压缩成一个小小的打分器。它学得好不好直接决定强化学习阶段模型往哪儿跑。这里有个绕不开的隐患模型会去找裁判的漏洞。通俗地说奖励模型只是人类偏好的近似不是人类偏好本身凡是近似就有缝隙。模型可能学会写得很长、很有礼貌、堆满小标题因为这类回答在人工排序时容易得高分但真把事情办对的比例未必提高。这也解释了为什么技术资料里除了自动评测还要单独做人工评测。自动评测跑得快、可复现但题目固定、口径固定模型见过的题多了分数就容易虚高人工评测慢、成本高却能看到“答得对不对”之外的东西比如有没有胡编、有没有绕开问题、语气是否得体。两套结果放在一起看才不至于被单一数字骗过去。对使用者来说这一节的现实意义是看到“对话模型在某某评测上很强”这种说法先问一句是自动评测还是人工评测、题目有没有公开、和谁比的。口径不同数字之间根本没有可比性。3. 一套模型为什么分成这么多型号基座、对话、代码、数学各管一段3.1 基座模型什么都懂一点但不会好好说话基座模型是整个家族的起点它只干过一件事在海量文本上猜下一个 token。它的能力分布很特别——续写、补全、改写这类“顺着往下写”的任务表现很好但你让它“回答一个问题”它可能理解成“续写这个问题的下一句”。这不是它笨是它的训练目标里根本没有“回答”这个概念。把基座模型当成二次开发的起点是它最主要的用途。想做垂直领域的助手可以在它上面继续预训练或者直接微调想研究模型内部机制基座版本比对话版本更“干净”因为它没有被对齐过程改写过表达习惯。反过来说如果你只是想让模型帮你写封邮件直接拿基座模型来用体验会很差——这就是很多新手第一次跑开源权重时的困惑明明参数不小怎么答非所问。不是模型不行是拿错了型号。3.2 对话模型会聊天只是表象能调工具才是分水岭对话模型是在基座之上做了 SFT 和 RLHF 的那一支。它的价值不只是“说话好听”更关键的是它被专门训练过工具使用、代码解释器和智能体这类能力。通俗地说普通对话是“你问我答”工具调用是“你问我答答之前我先去查一下、算一下、跑一下”。这个差别在实际使用中非常明显。纯对话模型遇到需要精确计算的问题只能靠“感觉”给个数字具备工具调用能力的模型会先输出一段结构化的调用请求等外部把结果返回再基于结果组织回答。技术资料里提到这类模型在代码解释器这种复杂任务上的表现即使和参数量更大的模型比也不落下风。原因不神秘它把“算”这件事外包出去了自己只负责“想清楚要算什么、结果怎么解释”。这里有个容易混淆的点工具调用能力是训练出来的不是模型自己“涌现”的。你给它一套工具描述它得见过足够多类似的样本才知道什么时候该调、参数怎么填、失败了怎么重试。所以不同模型在这方面的差距往往比在闲聊上的差距大得多。3.3 专精模型代码和数学为什么要单独练一遍通用模型在代码和数学上不是不能做而是“能做”和“做得好”之间隔着一条沟。这两类任务的共同点是对错可验证中间步骤不能跳格式要求严格。代码少一个括号就编译不过数学推导跳一步就全错而通用语料里这类严格结构占比有限模型容易学成“看起来像那么回事”。专精模型的做法是在基座之上先用大量代码或数学语料做继续预训练让模型在这个领域的“语言习惯”里浸泡够久再用这个领域的对话数据做微调教它怎么把过程讲清楚。技术资料里给出的代码专精版本有 7B 和 14B 两档对话版本同样分档数学专精也分 7B 和 14B 两档对话模型。它们在代码理解生成和数学推理上的表现明显好于同尺寸的开源模型但仍略逊于最强的闭源模型——这个定位很重要说明它是“够用的专业工具”不是“全能冠军”。型号分支训练路径擅长明显短板基座模型海量文本预训练续写补全、作为二次开发起点不按指令回答直接对话体验差对话模型基座 SFT RLHF多轮对话、格式输出、工具调用长链条推理仍会出错代码专精代码语料继续预训练 代码对话微调生成、调试、解释代码非代码领域不如通用版数学专精数学语料继续预训练 对话微调应用题、竞赛题的分步推导开放式写作和闲聊偏弱3.4 多模态支线能看图的那一支解决的是另一类问题除了纯文本这几支这个系列里还有能同时处理图像和语言的多模态模型。它支持中英文的文本识别和视觉定位也能做多图对话和看图讲故事。这一支和前面的型号不是“升级关系”而是“并行的另一条线”——它解决的是“图片里有什么、这个界面哪里有问题、这张图表说明了什么”这类问题纯文本模型再强也无从下手。对使用者来说认清这条支线的意义在于别拿错工具。想让它读一份扫描件里的表格那属于多模态的活想让它根据表格数据写一段分析那还是文本模型的活。混着用来回折腾是最费时间的一种踩坑方式。4. 五个最容易混的术语参数、对齐、开源、上下文和智能体4.1 误区一参数越多模型越强易混点在于把参数量当成唯一的实力指标。参数确实决定容量上限但它只是“脑子有多大”不等于“书读得多好、方法练得多对”。之所以会混是因为厂商宣传时最爱把参数量放在最显眼的位置数字大好记也容易横向对比。但真实表现取决于三件事的乘积训练数据的规模与质量、训练策略、以及有没有做针对性微调。技术资料里就提到基座模型在多项下游任务上能超过比自己大得多的模型反过来说一个参数更大但数据清洗粗糙的模型很可能打不过一个参数更小但数据干净的模型。区分方法很简单看同尺寸对比而不是跨尺寸比。7B 和 7B 比、14B 和 14B 比才有意义拿一个 7B 专精模型去和几十 B 的通用模型比代码赢了也不说明架构更先进只说明领域对上了。另外要留意评测口径——自动评测和人工评测的结论经常不一致只看一个数字容易得出相反结论。4.2 误区二SFT 和 RLHF 是两条路选一条走易混点在于这两个词经常并列出现读起来像是两种可替代的方案。之所以会混是因为它们都属于“对齐”这个大类名字又都是英文缩写初次接触时分不清谁在前谁在后。实际上它们是串行的两道工序SFT 用人工写好的样本来教格式和基本能力RLHF 用人工排序训练出的奖励模型来优化偏好。前者解决“会不会按指令说话”后者解决“说得好不好”。区分方法看数据形态SFT 用的是“问题 标准答案”的成对数据RLHF 用的是“同一个问题 多个回答 人的排序”。如果你的目标是让模型学会某个固定输出格式SFT 就够了如果目标是让它在多个都说得通的回答里挑更合适的那个就得引入偏好数据。跳过前者直接做后者通常连稳定的输出格式都拿不到。4.3 误区三开源模型就等于免费随便用易混点在于把“权重可以下载”直接等同于“没有约束”。之所以会混是因为“开源”这个词在日常语境里被用得太宽泛指一切“能拿到手的东西”。但模型发布通常附带许可条款涉及能不能商用、要不要标注来源、改完之后怎么分发这些条款各家不同而且可能随版本调整。技术资料里强调开放权重是为了提升可复现性和可获得性这是技术层面的动机不等于放弃所有使用条件。区分方法很直接动手之前先找到随权重一起发布的许可文本看三件事——商用是否允许、再分发是否要求同样许可、有没有用户规模或用途上的额外限制。这一步花十分钟能省掉后面很多麻烦。把许可当成“反正没人管”的心态是最容易在项目上线前才发现要返工的地方。4.4 误区四上下文窗口越长记性就越好易混点在于把“能塞进去”当成“能记住并会用”。之所以会混是因为窗口长度是个特别好宣传的数字看着就直观。但模型对上下文里不同位置的关注度是不均匀的中间部分的信息被忽略是常见现象而且窗口越长同样一次推理要处理的 token 越多成本和延迟都会上升。技术资料里提到做过上下文长度扩展也说明这是个需要额外训练和验证的工程动作不是把参数一调就自动变强。区分方法拿你自己的真实文档去测而且要把关键信息故意放在中间、放在开头、放在结尾各试一次看结果是否一致。如果只有放在开头才答得准那说明它的有效窗口远小于标称窗口。另一个实用做法是把长文档先做摘要或分段检索只把最相关的几段塞进去往往比硬塞全文更准也更便宜。4.5 误区五智能体是一种更高级的模型易混点在于把“智能体”当成某个型号觉得升级到那个型号就自动有了智能体能力。之所以会混是因为技术资料里常把对话模型和智能体能力放在一起讲读起来像是同一个东西的不同档位。实际上智能体是一种使用方式模型负责拆解任务、决定下一步调什么工具、根据返回结果决定继续还是收尾真正干活的是外部那些工具和系统。模型再强如果没有可调用的工具、没有把结果传回去的机制它也只是在聊天。区分方法看依赖纯对话只需要模型本身智能体需要一套外围——工具描述、调用协议、失败重试、结果校验。判断一个模型有没有这方面的能力别只看它会不会说“我来帮你查一下”要看它输出的调用请求格式对不对、参数填得准不准、拿到错误返回后会不会改。只会说不会调的那只是话术。5. 开源技术资料真正的价值可复现、可测量、可修改5.1 可复现性为什么“报告写得漂亮”不等于“你能跑起来”一份技术资料最有价值的部分往往不是那些亮眼的评测数字而是它把过程摊开讲了数据从哪来、怎么清洗、分几个阶段训练、对齐用了什么数据形态、评测怎么设计。这些东西决定了别人能不能沿着同样的路走一遍哪怕走不到终点至少知道坑在哪。但要破除一个幻想开放权重不等于开放训练过程更不等于开放训练数据。权重是结果数据往往因为版权和合规原因无法完整放出。所以“可复现”在这里是有层次的——权重层面可以复现推理结果方法层面可以复现训练流程的大致形状数据层面基本只能复现清洗策略而不是具体语料。技术资料里详细描述去重算法、质量打分模型、上采样策略恰恰是因为数据本身给不了只能把方法讲透让别人用自己的数据复刻这套流程。这一节对实际工作的启发是读这类资料时重点看“他们为什么这么选”而不是“他们用了什么”。为什么用模糊去重而不是只做精确去重为什么对某些来源上采样为什么在微调数据里要覆盖工具调用这一类——这些决策背后的理由换个领域照样成立。5.2 分词与压缩率中文场景里一项被低估的成本分词器决定一段文本被切成多少块块数直接决定两件事成本和上下文能装多少内容。同一个意思用中文说和用英文说token 数可能差出一截同样一句中文不同分词器切出来的块数也可能差不少。技术资料里专门做了编码压缩率的对比用某个支持上百种语言的分词器作为基准值 1 做归一化比较不同模型在多种语言上的切分效率结论是在保证中英文和代码都能高效解码的同时对其他语言也有不错的压缩率。这件事对使用者的意义很实在。假设上下文窗口是固定的压缩率高的分词器能塞进去更多内容相当于窗口“变大”了按 token 计费的场景下压缩率高就是直接省钱。而且中文的分词效率差异比英文更明显英文天然按空格分词中文没有这个边界全靠分词器自己学。# 同一段中文分别喂给两个分词器比较切出来的块数 # 块数越少、每 token 承载的字数越多压缩率越高 text 请把这段产品说明改写成给客户看的邮件语气正式但不生硬 for name, tok in [(分词器A, tok_a), (分词器B, tok_b)]: ids tok.encode(text) # 编码成一串 token 编号 ratio len(text) / len(ids) # 平均每个 token 承载多少个汉字 print(f{name}: {len(ids)} 个 token1 token 约合 {ratio:.2f} 字)这里的len(ids)是 token 数量ratio是字数除以 token 数比值越大说明同样的内容占用越少的 token。实际对比时要注意三点样本要足够长且贴近你的真实业务文本太短的句子波动大同一段文本要保证编码前完全一致别一边带空格一边不带比较的是相对值而不是绝对值不同分词器词表大小不同绝对值没法直接横比。5.3 评测怎么读那些数字的真实含义评测这一块最容易看走眼。技术资料里通常会给出多类评测自动评测跑公开题库速度快、可对比人工评测请人打分慢但能看到质量。两类结果的用途不一样自动评测适合看趋势人工评测适合看体验。看数字时留意几个信号。一是题目有没有可能进过训练数据尤其是那些流传很广的公开题库模型见过原题和没见过原题分数差得不是一点。二是比较对象是谁和同尺寸开源模型比、和更大的闭源模型比结论完全不同技术资料里通常会说“优于同尺寸开源模型、略逊于最强闭源模型”这句话本身就是一种诚实的定位。三是看分项而不是看总分代码、数学、语言理解、工具调用这几块的表现往往不均衡总分接近不代表各项都接近。对做选型的人来说最靠谱的做法是自建一小批贴合业务的题目几十条就够人工对一遍答案然后拿候选模型各跑一遍。公开榜单负责筛掉明显不行的自建小测负责挑出真正合适的。6. 什么时候该翻这份资料什么时候先别急着上手先说该用的时候。如果你的目标是搞清楚“一个大模型从零到能用要经过哪些环节”这份资料的结构本身就是答案预训练打底、对齐调教、专精分支、多模态支线一条线一条线铺开。它适合产品和技术方案阶段的人快速建立全局观也适合已经会用模型、但说不清“为什么这个模型在某个场景下就是不行”的人去找原因。比如你发现模型老是答非所问翻到对齐那一节就明白了——你手里拿的可能就是基座版本。再说别急着上手的时候。如果你只想找一个能直接聊天或者写文案的工具那读技术资料是绕远路直接试模型更快。如果你打算拿它做对外服务先别管架构多漂亮去看许可条款和评测口径这两件事排在性能前面。如果你期待的是“下载完就能复现出同样的模型”那也要先调整预期——权重能拿到数据拿不到训练细节只能复现方法不能复现结果。你的目标建议先看哪部分建立概念、写方案模型谱系和总述部分先看清各分支关系自己动手微调预训练数据、微调样本格式、对齐流程做代码或数学方向的助手专精模型那一节重点看训练路径而非分数评估能否落地许可条款、评测口径、分词压缩率研究训练方法数据清洗流程、去重策略、上采样做法有个具体的判断标准可以参考当你读到一个数字时能立刻说出它是怎么测出来的、和谁比的、口径是什么那就说明你读到位了如果只是记住了“某个评测得了多少分”那基本等于没读。我自己有过一次翻车经历。早些年拿到一套开源权重看到参数量不小就直接拉起来当对话模型用结果问什么都是“接着往下编”答非所问得离谱。折腾了大半天翻回资料才发现自己下的是基座版本连微调都没做过。从那以后我每次碰一个新的模型系列都强制走一遍流程先看谱系图搞清有哪些分支再看评测口径搞清数字怎么来的最后才动手跑。这个习惯看起来慢实际省下的时间比花掉的多得多。希望帮到你。本文还有配套的精品资源点击获取

相关推荐

SpringBoot+JDBC连接MySQL实战:从配置到避坑全指南
SpringBoot+JDBC连接MySQL实战:从配置到避坑全指南

简介:本资源是一套面向Java初学者与SpringBoot入门开发者的MySQL数据库集成实战方案,聚焦JDBC原生方式连接与操作MySQL的完整实现路径,覆盖环境搭建、驱动配置、连接池管理、CRUD编码及常见异常处理等核心环节。压缩包共136个文件&#xff0c… · 2026/11/6 5:27:58

从开题卡壳到定稿提交:我把写论文的整套工具链重做了一遍(附各阶段选工具的思路)
从开题卡壳到定稿提交:我把写论文的整套工具链重做了一遍(附各阶段选工具的思路)

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/6 5:27:58

Safari兼容IM源码包:四端互通的WebSocket通信底座
Safari兼容IM源码包:四端互通的WebSocket通信底座

简介:这是一套2024年亲测可部署的国产IM即时通讯系统源码,面向具备Java、OC、C#及Vue开发能力的技术人员,解决多端互通、高并发实时通信与私有化安全部署需求。资源完整覆盖安卓、iOS、PC及Web四端,基于国产tio通信框架&#xff0… · 2026/11/6 5:27:58

什么是升压ic
什么是升压ic

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/6 6:19:11

Java中关于HashSet常见问题
Java中关于HashSet常见问题

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/6 6:19:11

ego-lite:共享登录态的 AI Agent 浏览器,复杂网页任务免费跑快 2.5 倍
ego-lite:共享登录态的 AI Agent 浏览器,复杂网页任务免费跑快 2.5 倍

ego-lite:共享登录态的 AI Agent 浏览器,复杂网页任务免费跑快 2.5 倍 【免费下载链接】ego-lite The fastest browser for AI agents to run browser automation, built for sharing your logged-in browser state with your AI agents, like Codex or … · 2026/11/6 6:19:11

Docker + IDEA 一键部署!
Docker + IDEA 一键部署!

Docker IDEA 一键部署! 作为 3 Year全栈开发者相比对Docker一定很熟悉,镜像容器化技术,就不过多介绍了! 很久之前做的 Docker 入门学习Blog ,现在回头看发现有点过于臃肿,后期会总结一套常用命令&#x… · 2026/11/6 6:19:11

Mars 踩坑实录:Android 2.1 缺 Object.keys 时的两行 for-in 替代写法
Mars 踩坑实录:Android 2.1 缺 Object.keys 时的两行 for-in 替代写法

Mars 踩坑实录:Android 2.1 缺 Object.keys 时的两行 for-in 替代写法 【免费下载链接】Mars 腾讯移动 Web 前端知识库 项目地址: https://gitcode.com/gh_mirrors/mar/Mars 维护低版本 Android 页面的人,大概率撞见过这样一个报错:An… · 2026/11/6 6:18:11

变慢变高变响亮:如何调好文字转语音TTS的pace、pitch_rate与energy_rate三旋钮
变慢变高变响亮:如何调好文字转语音TTS的pace、pitch_rate与energy_rate三旋钮

【免费下载链接】tts-fastspeech2-ljspeech 项目地址: https://ai.gitcode.com/hf_mirrors/speechbrain/tts-fastspeech2-ljspeech 点击查看 免费下载 tts-fastspeech2-ljspeech 是 SpeechBrain 提供的文字转语音(TTS)语音合成预训练模型&am… · 2026/11/6 6:18:11

双极步进电机控制实战:DRV8818PWPR与PIC18F86K22驱动调试
双极步进电机控制实战:DRV8818PWPR与PIC18F86K22驱动调试

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/5 10:27:59

STM32F207ZG + DRV8818PWPR 步进电机驱动实战解析
STM32F207ZG + DRV8818PWPR 步进电机驱动实战解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/5 10:28:03

DRV8818PWPR+dsPIC30F4013工业级双极步进电机控制方案
DRV8818PWPR+dsPIC30F4013工业级双极步进电机控制方案

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/5 10:28:07

三菱PLC数据采集到数据库的时序设计:Python+MC协议实战
三菱PLC数据采集到数据库的时序设计:Python+MC协议实战

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/6 1:02:11

ASIC主模式RTL设计:状态机与三态驱动的流片级实现
ASIC主模式RTL设计:状态机与三态驱动的流片级实现

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/6 1:02:11

STM32嵌入式C++开发:GDB调试与Renode仿真实战指南
STM32嵌入式C++开发:GDB调试与Renode仿真实战指南

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/6 1:02:11

双极步进电机控制实战:DRV8818PWPR与PIC18F86K22驱动调试
双极步进电机控制实战:DRV8818PWPR与PIC18F86K22驱动调试

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/5 10:27:59

STM32F207ZG + DRV8818PWPR 步进电机驱动实战解析
STM32F207ZG + DRV8818PWPR 步进电机驱动实战解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/5 10:28:03

DRV8818PWPR+dsPIC30F4013工业级双极步进电机控制方案
DRV8818PWPR+dsPIC30F4013工业级双极步进电机控制方案

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views … · 2026/11/5 10:28:07

了解更多?预约专属演示

我们的顾问将为您一对一讲解产品与方案

企业微信二维码