openSMILE音频特征提取实战：配置、批量与避坑-北京尧图网络

简介openSMILE 3.0 Windows 64位安装包面向语音情感计算、音乐信息检索与音频特征工程的学习者和开发者提供在Windows环境下快速部署这一开源音频特征提取工具所需的核心文件无需从源码开始编译即可进入实验。压缩包共509个文件、约13.71MB内含可执行程序与动态库以及大量conf特征配置、txt/html说明文档、C/C源码与头文件、示例wav音频和网页资源便于按任务选择声学特征集、理解参数含义并做二次开发参考。该版本覆盖IS11、IS12、avec2011等常用配置适合语音情感识别、副语言分析等实验场景也可用于课堂演示与算法复现。已有457人学习适合希望跳过繁琐编译、直接开展音频特征提取实验的初级与中级用户其完整目录结构和配置样例能为特征工程入门与项目排错提供直接参考。1. 从一段 3 秒人声到 88 维向量这个安装包省掉的是一整条链路手上有一批录音想先区分情绪、语速或说话人状态最先卡住的往往不是模型而是特征。自己从零写一遍基频追踪、MFCC、共振峰光处理静音段和爆音就能耗掉一周。openSMILE 这个音乐音频特征提取工具的价值就在这里音频读取、重采样、预加重、分帧、加窗、LLD 计算、统计函数聚合它整条链路都打包好了。3.0 的 win-x64 安装包双击装完一条命令行就能出特征表不用配 Python 环境、不用编译、不用解决依赖冲突。它适合做语音情感、副语言分析、音频事件分类的从业者也适合课程设计里需要一个能跑通基线特征的学生。它没有图形界面所有能力藏在配置文件和SMILExtract的参数里这就是后面几章要拆开看的东西。2. 装完先跑通一条命令目录结构、配置体系与参数骨架2.1 安装后先认清楚三个位置按默认路径装完根目录下大致是这么几块bin、config、lib、include、doc。真正天天打交道的是前两个。bin里放的是SMILExtract.exe和它依赖的动态库config里是几十份.conf配置文件每一份代表一套特征定义。include和doc更像给二次开发者准备的做纯特征提取可以不碰。位置主要内容用不用得上binSMILExtract.exe、运行库 DLL每次都要用configeGeMAPSv02.conf、ComParE_2016.conf、emobase.conf等选型时要对照lib静态库 / 导入库只在 C 二次开发时用include头文件同上doc配置语法说明、组件手册改 conf 前值得翻这里有个很多人第一次就会踩的点SMILExtract.exe不是绿色单文件它启动时要按顺序在几个位置找同目录下的 DLL。所以最省事的用法是先把工作目录切到bin再调用相对路径或者干脆把bin加进系统环境变量。直接把 exe 复制到桌面双击多半是窗口一闪就没了。配置文件用的是 openSMILE 自己的配置语法一段方括号开头下面是键值。刚上手不用全懂把它当成“特征集的压缩包”看待就行换一个.conf等于换一套特征定义输入的音频和输出的表格格式都不变。这一点很关键意味着你的批处理脚本可以跟特征集解耦——脚本只认配置路径特征集想换随时换。2.2 一条命令的骨架-C、-I、-O 三件套最小可跑的命令就三个参数配置文件、输入音频、输出文件。先别急着上批处理拿一个十几秒的 wav 手动跑一次把输出打开看一眼比看十页文档都有用。echo off REM 切到 bin 目录避免 DLL 搜索路径问题 cd /d C:\Program Files\openSMILE\bin REM -C 指定配置-I 指定输入-O 指定输出-csvoutput 让输出走 CSV SMILExtract.exe ^ -C ..\config\eGeMAPSv02.conf ^ -I D:\data\demo.wav ^ -O D:\data\demo.csv ^ -csvoutput 1 ^ -instname demo这三行里-C决定“算什么特征”-I决定“算什么”-O决定“写哪儿”。-instname会被写进结果的第一列批处理时用它标记来源文件后期对齐样本特别省事。-csvoutput 1是把默认的 ARFF 输出切换成 CSV不加这个参数你拿到的是.arff文本。参数作用常见取值备注-C配置文件..\config\eGeMAPSv02.conf必填路径别用中文-I输入音频.wav/.flacwav 最稳mp3 视编译选项而定-O输出文件xxx.csv/xxx.arff同名文件会被直接覆盖-l帧级输出开关0/11会输出逐帧 LLD 序列-csvoutput输出 CSV1不加则输出 ARFF-instname实例名任意字符串写进第一列-t打印时间戳无调试长音频时看进度用-l这个参数值得单独说一句因为它直接决定输出文件的形态。-l 0默认只给你整段音频的统计汇总一行数据-l 1会把每一帧的 LLD 值也写出来行数变成几百上千行末尾再附一段汇总。做整段分类用前者做时序分析或者想看特征怎么随时间漂移才需要后者。2.3 用一段人声和一段静音做交叉验证装完之后不要直接投生产数据先做两组对照一段正常说话的 wav一段纯静音或者只有底噪的 wav。正常音频应该输出一行完整数值静音音频应该输出一行——但那行里的能量类特征、F0 相关特征会大面积是 0 或者特定占位值。这个对照能同时验证三件事链路通了、配置文件没写错、你能看懂哪些列在静音时失效。如果手头没有静音文件用 Python 现场生成一个# make_silence.py —— 生成 3 秒 16kHz 单声道静音 wav用于对照 import wave with wave.open(silence_3s.wav, wb) as w: w.setnchannels(1) w.setsampwidth(2) w.setframerate(16000) w.writeframes(b\x00\x00 * 16000 * 3)生成完再跑一次上面那条命令把两个 CSV 并排打开对比。真正要看的不是数值大小而是列数是否一致、有没有整列全空。列数一致说明输出结构没问题整列全空说明那一列对应的特征在该音频上确实没算出来——这在静音上属于正常但在正常语音上出现就得排查了。再补一个纯文本层面的快速体检脚本不依赖 pandas装完就能跑# verify.py —— 数行、数列、找全空列 import sys def sniff(path): with open(path, r, encodingutf-8, errorsreplace) as f: lines [l.rstrip(\n) for l in f if l.strip()] data_idx next((i for i, l in enumerate(lines) if l.strip() data), None) if data_idx is None: print(没有找到 data 行文件可能不是 openSMILE 的 CSV 输出) return header [l.split()[1] for l in lines[:data_idx] if l.startswith(attribute)] rows [l.split(;) for l in lines[data_idx 1:]] print(f列数: {len(header)} 数据行数: {len(rows)}) # 逐列检查是否全为 0 或空这类列通常意味着对应特征没算出来 empty_cols [] for j, name in enumerate(header): vals [r[j] for r in rows if j len(r)] if all(v in (, 0, 0.000000) for v in vals): empty_cols.append(name) print(f疑似全空列: {len(empty_cols)}) for c in empty_cols[:10]: print( -, c) if __name__ __main__: sniff(sys.argv[1])脚本逻辑很直白先找data这个分隔行前面是头部后面是数据。注意头部里attribute那一行的第二个字段才是列名第三个字段是类型声明numeric或string别把类型当成列名。这一步做对后面接 pandas 就不会出问题。3. 特征集选型88 维、988 维、6373 维到底怎么挑3.1 三套常用配置的维度、耗时与适用面config目录里配置文件很多真正高频使用的是那么四五份。维度差别非常大从 88 维到 6373 维差了七十倍。维度不是越高越好特征维度上去之后小样本场景下过拟合会来得非常快——这是选型时第一个要想清楚的事。配置文件大致维度特征构成相对耗时典型场景eGeMAPSv02.conf8825 个 LLD 一组统计函数最快情感识别、副语言分析、小样本eGeMAPSv01b.conf88同上早期版本定义最快需要跟老论文对齐时用emobase.conf988更多 LLD 与统计函数组合中等通用音频分类基线IS09_emotion.conf384情感挑战赛定义集中等复现早期情感识别结果ComParE_2016.conf6373大规模 LLD 与统计函数交叉最慢大数据量、追求上限选型我一般按这个顺序问自己三个问题。第一样本量多少几百条以内直接上 eGeMAPS88 维在几百个样本上还撑得住6373 维基本必炸。第二任务是不是跟韵律、音质强相关如果是情绪、疲劳、紧张度这类eGeMAPS 里的 F0、jitter、shimmer、HNR 这几组特征性价比极高没必要上大集合。第三有没有算力预算ComParE_2016跑一小时音频的耗时可能是 eGeMAPS 的十几倍几千条数据跑下来差距是几小时和几十小时的区别。还有一个常被忽略的点eGeMAPS 的设计初衷就是可复现、低维度、有理论依据它挑的这 25 个 LLD 是有生理和语音学依据的不是什么统计筛出来的。这意味着在跨语料、跨设备的场景下它比大集合更不容易崩。我带过一个跨设备的项目用 ComParE 训练换一批录音设备后指标掉得很难看换回 eGeMAPS 反而稳一些。这不是说大集合不好而是说它的方差更大需要更多数据去压。3.2 帧级与话语级-l 参数实际改变的是什么很多人以为-l 1只是“多输出一些行”实际上它改变的是整个输出的组织方式。帧级模式下openSMILE 把每一帧默认 10ms 步长的 LLD 值逐行写出最后再追加一段整段汇总。也就是说一个 10 秒的音频-l 0给你 1 行-l 1给你大约 1000 行加上 1 行汇总。这两类输出服务的任务完全不同。话语级一行数据适合直接喂给 sklearn 的RandomForest、SVM一条样本一个标签流程干净。帧级序列适合做时序建模比如用 LSTM 看情绪在对话中的起伏或者做语音活动检测、事件定位。如果你只是想做一个“这段录音是不是愤怒”的二分类帧级输出纯属浪费还得自己做聚合。帧级的聚合有个坑openSMILE 在帧级模式下追加的那行汇总用的统计函数跟你想象的可能不一样。默认配置里通常包含均值、标准差、最大最小值、偏度、峰度、四分位数等一大组具体哪些由配置文件里的函数集合决定。想把汇总控制得干净一点可以用-frameModeFunctionalsConf指定一份自定义的统计函数配置只保留均值、标准差、最大值、最小值这四个。这样输出维度可控后期也少一层清洗。实际做的时候我一般先用-l 0把整条链路和标签对齐跑通确认模型能出结果再回头考虑要不要上帧级。反过来做的人经常卡在“输出文件几百兆、pandas 读进来内存爆掉”这一步。3.3 批量跑批处理循环加 Python 兜底合并单文件跑通之后下一步一定是批量。Windows 下最直接的是写个.bat循环让每个 wav 输出一个同名 CSV再用 Python 统一读进来合并。这种“一文件一输出”的策略比追加写入更抗中断——跑到一半崩了已经完成的文件还在补跑时跳过已存在的就行。echo off setlocal enabledelayedexpansion set SMILEC:\Program Files\openSMILE\bin\SMILExtract.exe set CFGC:\Program Files\openSMILE\config\eGeMAPSv02.conf set INDIRD:\data\wav set OUTDIRD:\data\feat if not exist %OUTDIR% mkdir %OUTDIR% REM 遍历输入目录下所有 wav逐个输出到 OUTDIR for %%f in (%INDIR%\*.wav) do ( set NAME%%~nf echo 处理: !NAME! %SMILE% -C %CFG% -I %%~ff -O %OUTDIR%\!NAME!.csv -csvoutput 1 -instname !NAME! ) echo 全部完成 pause%%~nf取的是不带扩展名的文件名%%~ff取的是完整路径。这两个修饰符很重要-I需要完整路径才能避免相对路径解析问题-O用纯文件名更干净。enabledelayedexpansion和!NAME!是为了在循环体内正确展开变量用%NAME%会拿到循环开始前的旧值这是批处理的经典陷阱。批量跑完合并交给 Python# merge_features.py —— 把逐文件输出的 CSV 合并成一张宽表 import glob import os from io import StringIO import pandas as pd def load_smile_csv(path: str) - pd.DataFrame: 读取 openSMILE 3.0 的 CSV跳过 relation/attribute 头按分号切分。 with open(path, r, encodingutf-8, errorsreplace) as f: raw [l for l in f.read().splitlines() if l.strip()] data_idx next(i for i, l in enumerate(raw) if l.strip() data) header [l.split()[1] for l in raw[:data_idx] if l.startswith(attribute)] body \n.join(raw[data_idx 1:]) return pd.read_csv(StringIO(body), sep;, namesheader, headerNone) frames [] for path in glob.glob(rD:\data\feat\*.csv): df load_smile_csv(path) df[source_file] os.path.basename(path).replace(.csv, ) frames.append(df) merged pd.concat(frames, ignore_indexTrue) # 去掉第一列的实例名和后续用不到的时间列只留数值特征 drop_cols [c for c in merged.columns if c in (name, frameTime)] merged merged.drop(columnsdrop_cols) merged.to_csv(rD:\data\features_all.csv, indexFalse) print(merged.shape)这段的关键在load_smile_csv它不假设文件结构而是靠data这一行去切分头部和数据。namesheader, headerNone是明确告诉 pandas“列名我自己给了你别再从第一行猜”。少了这一步pandas 会把relation那行当表头整张表的列名全部错位而且不报错等到训练时才发现特征和标签对不上那种排查是最耗时的。4. 输出格式CSV 里的 attribute 行与分号分隔符4.1 为什么 pandas 直接读会多出几行第一次用pd.read_csv(demo.csv)读 openSMILE 输出的人几乎都会看到一张很怪的表列名是relation eGeMAPSv02、attribute name string这类字符串数据从中间某行才开始。原因很简单——3.0 版本的 CSV 输出沿用了 ARFF 的头部写法文件开头是relation、若干行attribute、一行data然后才是真正的数值。这不算 bug它只是让同一份输出既能被当成 CSV 处理也能被当成 ARFF 直接喂给 Weka 这类工具。但对 pandas 用户来说默认的“第一行是表头”假设就失效了。三种处理方式按场景选方式做法适用手动定位先读文本找data再交给 pandas最稳推荐固定跳过skiprowsN写死行数只适合单一配置换配置就崩切成 ARFF不加-csvoutput用 scipy.io.arff 读需要做 Weka 兼容时第三种其实挺省事openSMILE 默认输出就是 ARFFscipy.io.arff.loadarff能直接读连头部解析都省了。缺点是字段全变成 bytes 类型还得自己转 float而且 ARFF 文件比 CSV 大一圈。数据量大时我一般还是走 CSV。另一个细节是分隔符。openSMILE 3.0 的 CSV 用分号而不是逗号pd.read_csv不加sep;会把整行当成一列。这个问题不会报错只会让你看到一张只有一列、列名超长的表。4.2 ARFF 与 CSV 的取舍两种格式的信息量其实一样差别在生态。ARFF 是 Weka 的原生格式头部自带类型声明扔进 Weka 的 Explorer 直接能可视化、能跑分类器做快速验证很舒服。CSV 是通用格式pandas、R、Excel、各种深度学习框架都认做工程化流水线更合适。我的习惯是探索阶段用 ARFF 快速看分布进入正式流程就切 CSV。切换成本就是一个-csvoutput 1参数不涉及重新计算但可以省掉后面所有工具链的格式转换麻烦。有一点要注意ARFF 里的字符串字段和数值字段是分开声明的如果你用-instname传了中文某些工具读进来会乱码。稳妥做法是实例名只用 ASCII 字符中文标签单独存一张映射表合并的时候再贴回去。这个习惯我保持了挺久跨工具链时省过不少事。4.3 读回来、对齐、入库的一段脚本真正落到项目里特征表不是终点它得跟标签表对齐。常见结构是一个目录放音频一张 CSV 放文件名, 标签跑完特征后按文件名 join。下面这段把读取、去冗余列、合并标签、类型转换一次做完# build_dataset.py —— 特征表标签表 - 可训练的数据集 import pandas as pd from build_features import load_smile_csv # 复用上一节的读取函数 feat pd.read_csv(rD:\data\features_all.csv) # 标签表至少两列source_file 和 label labels pd.read_csv(rD:\data\labels.csv) df feat.merge(labels, onsource_file, howinner) # 把所有非标签列转成数值转不动的置为 NaN方便后面统一填 label_col label value_cols [c for c in df.columns if c not in (label_col, source_file)] df[value_cols] df[value_cols].apply(pd.to_numeric, errorscoerce) # 统计每列缺失比例超过 30% 的列先记下来别急着删 na_ratio df[value_cols].isna().mean().sort_values(ascendingFalse) print(缺失率前 10 列) print(na_ratio.head(10)) print(合并后形状:, df.shape) df.to_parquet(rD:\data\dataset.parquet, indexFalse)howinner是有意为之只保留特征和标签都存在的样本避免后面训练时出现空标签。errorscoerce把无法解析的值变成 NaN 而不是抛异常因为 openSMILE 在某些极端音频上确实会输出非数值占位符直接崩掉整条流水线不值得。缺失率统计那一步是给自己留个观察窗口——如果某一列缺失率特别高往往是那段音频有问题而不是特征本身有问题值得回去看看原始文件。存 Parquet 而不是 CSV是因为特征表通常列多行多Parquet 读取快一个量级类型也能保住不用每次读回来再转一遍。5. 避坑与排查五个会让特征跑歪的细节5.1 现象输出文件只有表头一行数据都没有现象很直观打开 CSV 只看到relation和一堆attributedata后面空空如也。原因通常有三个。一是输入音频太短短于一个分析窗eGeMAPS 里 F0 相关特征用的是 60ms 窗连一帧都凑不出来自然没有输出。二是音频格式不被识别比如某些编码的 mp3 或者带特殊头部的 wav读取组件直接返回空流但进程不报错。三是路径里有 openSMILE 解析不了的特殊字符文件其实没被打开。解决办法按顺序试先用播放器确认音频能正常播放且时长大于 1 秒再把音频转成 16kHz、16bit、单声道 PCM wav 重跑最后把输入输出路径都换成纯英文短路径。三步走完还在复现的基本可以排除音频本身的问题去看命令行的 stderr 输出——openSMILE 的警告信息默认打在标准错误上很多人只看标准输出就以为一切正常。5.2 现象不同文件的输出列数对不上合并时报错现象是批量合并时 pandas 抛ValueError: Plan shapes are not aligned或者合并出来的表里有一堆 NaN。原因一般是混用了不同配置文件跑出来的结果。eGeMAPSv02.conf出 88 列emobase.conf出 988 列两者一合并必然错位。另一种更隐蔽的情况是同一份配置在不同音频上输出的列数不同——这通常发生在特征集里包含条件分支的时候某些特征在特定条件下才被计算。解决办法是合并前先做一次列名一致性检查把所有文件的attribute列名集合取出来比对from build_features import load_smile_csv import glob def columns_of(path): with open(path, encodingutf-8, errorsreplace) as f: for line in f: if line.startswith(data): break if line.startswith(attribute): yield line.split()[1] sets {p: set(columns_of(p)) for p in glob.glob(rD:\data\feat\*.csv)} base next(iter(sets.values())) for p, s in sets.items(): if s ! base: print(列集合不一致:, p, 多:, s - base, 少:, base - s)跑一遍就能定位到具体是哪个文件、多了哪列少了哪列。确认是配置混用的话最干净的处理是分目录重跑别在合并阶段做补列。5.3 现象命令行一闪而过或者报找不到某个 DLL现象是双击SMILExtract.exe窗口瞬间消失或者在别的目录用绝对路径调用时报“找不到 xxx.dll”。原因在于 Windows 的 DLL 搜索顺序exe 启动时会先在自身所在目录找依赖库再按 PATH 找。SMILExtract.exe的依赖库就在同目录下所以一旦工作目录不对或者被复制到别处加载就失败。解决办法只有两条选一条固定下来要么每次调用前cd到bin目录要么把bin的完整路径加进系统 PATH。我倾向前者因为批处理脚本里写死cd /d更可控也不污染全局环境。加了 PATH 之后如果还报错检查是不是装了多个版本PATH 里靠前的是旧版目录。顺带一提安装路径里带空格Program Files是没问题的只要在脚本里用引号包住。真正会出问题的是中文路径和过长的路径这两个在配置文件加载环节容易翻车。5.4 现象特征数值明显不合理能量爆表或者 F0 全是 0现象是模型怎么调都不收敛回去看特征表发现某些列的数值范围跟正常音频差了数量级。原因多半在采样率和声道。openSMILE 的配置文件里对期望采样率有假设输入不匹配时它通常会做重采样但重采样本身会引入轻微的能量变化如果音频是立体声而配置按单声道处理某些通道相关的计算就会偏。更常见的是音量问题录音电平过低能量类特征接近 0F0 追踪直接失败输出一串 0。解决办法是先统一输入规格再做特征提取。转码这一步用 ffmpeg 一行搞定# 统一成 16kHz、16bit、单声道 PCM这是绝大多数语音配置的期望输入 ffmpeg -i input.mp3 -ar 16000 -ac 1 -sample_fmt s16 -acodec pcm_s16le output.wav-ar 16000定采样率-ac 1混单声道-sample_fmt s16定位置深度。三个参数缺一个都可能引入变量。转完再跑特征如果 F0 还是大面积 0那就是音频内容本身的问题——静音太多、或者说话人音量太低这种情况要么做增益归一化要么在建模阶段把这些样本剔掉。5.5 现象批处理跑到一半输出文件被覆盖或者名字冲突现象是跑完发现输出目录里的文件数量比输入少或者某些文件的特征明显是别人的。原因是文件名冲突。%%~nf只取文件名不带扩展名如果输入目录下同时有a.wav和a.flac两个都会输出成a.csv后跑的覆盖先跑的。另一种是输入分散在多个子目录同名文件在扁平化输出时撞车。解决办法是输出文件名带上相对路径的哈希或者干脆按输入目录结构镜像输出。最简单的改法是给文件名加个前缀REM 用输入文件的完整路径算一个短哈希做前缀避免重名 for %%f in (%INDIR%\*.wav) do ( set HASH%%~pf set HASH!HASH:\_! %SMILE% -C %CFG% -I %%~ff -O %OUTDIR%\!HASH!%%~nf.csv -csvoutput 1 )把路径里的反斜杠替换成下划线等于把目录信息编码进文件名重名概率降到接近零。这种写法不优雅但足够可靠跑完一眼就能看出哪个文件来自哪个目录。跑之前先用dir /b /s数一遍输入文件数跑完再数一遍输出文件数两个数对不上就说明有覆盖这一步花不了十秒能省掉后面几小时的排查。6. 进阶改一份自己的 conf把帧长和特征段控住用久了会发现现成配置不够用。比如做的是语速相关的任务10ms 的帧移太细想改成 20ms又比如只关心韵律不关心频谱想把 MFCC 那一整段砍掉。这些都能通过复制一份.conf改参数实现不用重新编译。做法是先在config目录里挑一份最接近的复制成my_set.conf然后用编辑器全文搜索三个键frameSize、frameStep、frameCenterSpecial。帧长的单位是秒0.025就是 25ms。很多配置里这两个值会出现不止一次因为不同特征组用不同的窗长——eGeMAPS 里 F0 和音质特征用 60ms 窗频谱类用 20ms 窗改的时候要分清你改的是哪一组。只改数字别动键名和段落结构。改完必须验证维度没变。我的做法是跑同一段音频两次一次用原配置一次用改过的比较列名集合from build_features import load_smile_csv a load_smile_csv(rD:\data\demo_eGeMAPS.csv) b load_smile_csv(rD:\data\demo_my.csv) print(原列数:, a.shape[1], 新列数:, b.shape[1]) print(列名差异:, set(a.columns) ^ set(b.columns)) # 只改帧长帧移的话列数应该完全一致数值会有细微差别如果列数变了说明你改到了会触发条件分支的键回去检查是不是动了frameCenterSpecial这类影响特征定义的参数。改动目标要动的键风险提高时间分辨率frameStep调小输出行数线性增加磁盘和内存压力上升平滑短期波动frameSize调大帧长超过音素长度会糊掉瞬态特征只保留韵律特征注释掉频谱相关组件段容易连带注释掉依赖它的下游组件跑起来才报错减少汇总维度换用自定义 functionals 配置需要另写一份函数列表语法要对着文档核最后说个教训。早些年我改配置的时候习惯直接改原文件觉得省事结果某次批量跑了几千条之后才发现帧长被改过前后两批数据的特征不可比只能全部重跑。从那以后我每次动配置都强制走一遍“复制—改名—跑对照—比列名”的流程配置文件本身当只读资源对待。这个习惯看着笨但省下的返工时间远超那几分钟。希望帮到你。本文还有配套的精品资源点击获取

openSMILE音频特征提取实战：配置、批量与避坑

相关推荐

Qwen3-Coder 30B：256K长文本AI编码免费实战教程

GA-BP神经网络在滑坡稳定性预测中的工程实现

Android 架构 - 组件化 Modularzation（Kotlin版）

更多资讯

滑动窗口的使用（一）

FileLocator Pro v9.3.3566：免索引全文搜索+压缩包内容扫描+正则布尔，安装包下载

STM32MP2 Developer Package(stm32mp-openstlinux-6.6-yocto-scarthgap-mpu-v26.06.10) - （2）

我的Token根本用不完

【Quectel Pi M2 实战】Day1 开箱：双开发板对比，硬件初识与上电准备

小白程序员必看：收藏这份AI大模型学习指南，轻松掌握核心概念与实战技巧

今日更新

AI智能体开发实战：从技术原理到商业落地

OpenShell 完全定制指南：从安装到深度配置，打造高效 Windows 开始菜单

Superpowers技能体系全解析：从Skills引入到安装的完整指南

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？