尧图网络 高端网站定制 · 原创设计
免费咨询热线
400-888-6620
免费获取方案
Mac本地离线听写与LLM改写实战:Whisper+llama.cpp全流程指南
1. 为什么我要在 Mac 上折腾本地听写和 LLM 改写我平时写东西的量很大会议记录、草稿、随手记的灵感一天下来零零碎碎能攒好几千字。早几年我一直用云端听写服务方便是方便但有两个问题始终绕不开一是网络一断就抓瞎飞机上、地铁里、咖啡馆信号差的时候对着麦克风说话半天没反应二是有些内容涉及还没公开的项目细节往云端传心里总有点膈应。后来 Apple Silicon 的机器性能上来了M 系列芯片的神经网络引擎跑本地推理完全够用我就开始琢磨把听写和文本改写这两件事全部搬到本地来做。TalkScribe 这个项目就是在这个背景下进入我视野的。它的定位很明确在 macOS 上做完全离线的听写并且用本地 LLM 对听写结果进行改写润色。整个链路不碰网络音频不出本机文本也不出本机。对于经常处理敏感内容、又想要流畅听写体验的人来说这个组合相当有吸引力。它适合几类人一是对隐私敏感的文字工作者二是网络环境不稳定但需要随时记录的人三是想在自己 Mac 上玩转本地大模型、又不想从零搭环境的开发者。我前后花了大概两周时间把整套流程跑通中间踩了不少坑也总结出一些让体验更顺滑的配置技巧。这篇文章就把我的完整实践过程拆开讲从底层原理到具体参数从模型选型到性能调优尽量让不同基础的人都能照着复现。2. 整体架构与核心思路拆解2.1 为什么是“本地听写 本地改写”这个组合先说说这个组合为什么合理。听写和改写本质上是两个不同的任务听写是语音转文字ASR改写是文本到文本的生成LLM。如果两个都放云端延迟叠加、隐私风险叠加如果只把听写放本地、改写放云端那隐私问题依然存在因为原始文本还是要传出去。所以真正彻底的方案就是两端都本地化。本地化的前提是硬件够用。Apple Silicon 的统一内存架构在这里帮了大忙——CPU、GPU、神经网络引擎共享同一块内存模型权重加载一次就能被不同计算单元访问省去了传统架构里频繁拷贝数据的开销。这也是为什么 M 系列芯片跑本地模型比同价位的 x86 机器体验好很多的原因。我实测下来M1 16GB 的机器跑一个 7B 量级的量化模型做改写响应速度完全能接受如果是 M2 Pro 或 M3 以上体验会更从容。2.2 听写引擎的选择逻辑听写这块目前本地方案里 Whisper 系列是绕不开的。OpenAI 开源的 Whisper 模型有多个尺寸从 tiny 到 large 一共好几档。选哪个尺寸核心是在准确率、速度、内存占用三者之间找平衡。我的建议是这样如果你主要处理中文和英文的日常口语small或medium就够用了如果涉及专业术语多、口音重、或者需要多语言混合识别那就上large系列。但要注意large模型在 M1 上跑实时听写会比较吃力延迟明显。我自己的配置是日常用small遇到重要会议需要高准确率时切到medium这个切换成本很低因为模型文件都是本地缓存的。这里有个细节值得说Whisper 的模型文件格式和加载方式会影响首次启动速度。如果用官方的 PyTorch 权重加载会比较慢换成 Core ML 格式或者 GGML 量化格式加载和推理都会快不少。这个后面在实操部分会详细讲。2.3 改写环节的 LLM 选型考量改写环节用本地 LLM选型逻辑和听写不太一样。听写追求的是“准”改写追求的是“顺”和“可控”。你需要模型能理解你的意图——比如“把这段口语化的记录整理成书面语”“把这段会议纪要提炼成要点”“修正错别字和标点”——然后按照指令输出。本地 LLM 的选择面其实挺广的。7B 到 13B 量级的模型经过 4-bit 量化之后在 16GB 内存的 Mac 上跑起来没什么压力。我试过几个不同的模型各有侧重有的中文能力强有的指令跟随好有的输出风格更自然。关键是要选一个指令微调做得好的版本因为改写本质上是指令跟随任务基座模型直接拿来用效果会差很多。还有一个容易被忽略的点上下文长度。听写出来的文本可能很长如果模型上下文窗口太小长文本会被截断。所以选模型的时候要留意它的上下文长度至少要有 4K token最好能到 8K 以上。2.4 两个环节如何衔接听写和改写之间的衔接方式直接决定了整个工作流的顺畅程度。最粗糙的做法是听写完保存成文本文件再手动喂给 LLM。但这样太割裂了用起来很累。理想的方式是做成一个流水线按下快捷键开始听写松开后自动把文本送进 LLM 改写改写结果直接插入到当前光标位置。这个流水线可以用脚本串起来也可以用现成的工具做胶水。我自己的做法是写了一个简单的 shell 脚本加 AppleScript 的组合监听快捷键、调用听写、触发改写、回填文本。虽然土了点但胜在可控每个环节出问题都能单独排查。3. 核心细节解析与实操要点3.1 Whisper 模型在 Apple Silicon 上的运行方式Whisper 官方实现是基于 PyTorch 的直接在 Mac 上跑也能跑但没有充分利用 Apple Silicon 的硬件加速。想要更好的性能有几条路可以走。第一条路是用whisper.cpp。这是一个用 C/C 重写的 Whisper 推理实现专门针对 CPU 和 Apple Silicon 做了优化支持 Metal 加速和 Core ML。它的优点是依赖少、启动快、内存占用低。编译也很简单克隆仓库之后用 make 就能搞定。跑的时候可以指定模型路径和线程数实测在 M1 上跑small模型实时因子能到 0.3 左右也就是说处理 10 秒音频只需要 3 秒左右。第二条路是用faster-whisper。它基于 CTranslate2 推理引擎速度比原版快好几倍显存占用也更低。不过在 Mac 上它主要走 CPUMetal 支持不如 whisper.cpp 那么直接。如果你的机器内存够大这条路的吞吐量很可观。第三条路是 Core ML 转换。Apple 官方提供了 Whisper 的 Core ML 版本可以直接调用神经网络引擎。这条路的能效比最高但转换和配置流程相对复杂适合愿意折腾的人。我最终选了whisper.cpp原因是它在 Mac 上的综合体验最均衡编译简单、运行稳定、Metal 加速开箱即用。下面是一个典型的编译和运行命令# 克隆仓库 git clone https://github.com/ggerganov/whisper.cpp cd whisper.cpp # 编译开启 Metal 支持 make WHISPER_METAL1 # 下载模型以 small 为例 bash ./models/download-ggml-model.sh small # 运行听写指定模型和音频文件 ./main -m models/ggml-small.bin -f audio.wav -l zh --output-txt这里的-l zh是指定语言为中文如果你经常中英混说可以不加这个参数让它自动检测但自动检测会稍微慢一点。--output-txt会把结果输出成文本文件方便后续处理。3.2 音频输入的处理细节听写效果好不好音频质量占一半。很多人忽略了这一点拿着笔记本内置麦克风在嘈杂环境里录然后怪模型不准。其实只要做好几件事准确率能明显提升。首先是采样率。Whisper 要求输入音频是 16kHz 单声道。如果你的录音设备是 44.1kHz 或 48kHz需要先重采样。ffmpeg一行命令就能搞定ffmpeg -i input.m4a -ar 16000 -ac 1 -c:a pcm_s16le output.wav这里的-ar 16000是采样率-ac 1是单声道-c:a pcm_s16le是输出格式。这三个参数缺一不可格式不对 Whisper 会直接报错或者识别出乱码。其次是降噪。如果录音环境有持续的背景噪音比如空调声、风扇声可以先过一遍降噪。Mac 上可以用sox做简单的降噪sox input.wav output.wav noisered noise.prof 0.2不过降噪是把双刃剑处理过度会把语音细节也抹掉反而降低识别率。我的经验是只有在噪音确实影响识别时才用而且强度不要超过 0.3。第三是分段。Whisper 对长音频的处理是分段的如果一段音频太长中间又没有明显停顿识别质量会下降。所以录长内容的时候最好每隔几分钟手动切一下或者用 VAD语音活动检测自动切分。whisper.cpp本身支持一定的流式处理但效果不如手动切分来得稳。3.3 本地 LLM 的部署与量化本地 LLM 的部署目前 Mac 上最省心的方案是llama.cpp或者基于它的封装工具。llama.cpp支持 GGUF 格式的量化模型4-bit 量化之后7B 模型大概占 4GB 左右内存13B 模型大概 7-8GB对大多数 Mac 来说都能承受。模型文件可以从一些公开的模型仓库获取下载之后直接用llama.cpp加载。下面是一个典型的运行命令./llama-cli -m models/qwen2-7b-instruct-q4_k_m.gguf \ -p 请把下面这段口语化的文字整理成书面语\n{input_text} \ -n 512 \ --temp 0.7 \ --top-p 0.9参数解释一下-n 512是最大生成 token 数改写任务一般不需要太长512 够用了--temp 0.7是温度控制输出的随机性改写任务建议在 0.5 到 0.8 之间太低会死板太高会跑偏--top-p 0.9是核采样配合温度一起用让输出既有多样性又不至于离谱。量化等级的选择也有讲究。GGUF 格式常见的量化等级有 Q4_K_M、Q5_K_M、Q8_0 等。Q4_K_M 是性价比最高的质量和体积平衡得很好Q5_K_M 质量略好体积也略大Q8_0 接近原始精度但体积翻倍。我的建议是 16GB 内存的机器用 Q4_K_M32GB 以上可以上 Q5 或 Q8。3.4 提示词工程在改写环节的应用改写效果好不好提示词占很大比重。同样一个模型提示词写得好和写得差输出质量能差出一个档次。我的经验是提示词要包含四个要素角色设定、任务描述、输出格式、约束条件。举个例子你是一个专业的中文编辑。请把下面这段语音听写的原始文本整理成通顺的书面语。 要求 1. 修正错别字和标点符号 2. 去掉口头禅和重复的词 3. 保持原意不变不要添加原文没有的信息 4. 如果原文有逻辑跳跃可以适当调整语序使其连贯 5. 输出直接给整理后的文本不要加任何解释 原始文本 {input_text}这个提示词里“专业的中文编辑”是角色设定“整理成通顺的书面语”是任务描述五条要求是约束条件“直接给整理后的文本”是输出格式。四要素齐全模型的表现会稳定很多。还有一个技巧是少样本示例。如果你对输出风格有特定要求可以在提示词里给一两个例子让模型模仿。比如示例输入呃那个我们今天这个会主要是讨论一下下个季度的计划 示例输出我们今天这个会主要讨论下个季度的计划。 现在请处理 {input_text}加上示例之后模型对“去掉口头禅”这个要求的理解会准确很多。4. 完整实操流程与关键环节实现4.1 环境准备与依赖安装先把基础环境搭好。我假设你用的是 macOS 12 以上的系统并且已经装了 Homebrew。第一步是安装必要的命令行工具brew install ffmpeg sox cmake git wgetffmpeg用于音频格式转换sox用于降噪处理cmake用于编译一些需要构建的工具git和wget用于下载源码和模型。然后是编译whisper.cppgit clone https://github.com/ggerganov/whisper.cpp cd whisper.cpp make WHISPER_METAL1编译完成之后下载模型。我建议至少下载small和medium两个日常用small重要场合用mediumbash ./models/download-ggml-model.sh small bash ./models/download-ggml-model.sh medium模型文件会放在models/目录下small大概 500MBmedium大概 1.5GB。下载速度取决于网络如果慢的话可以手动从镜像源下载后放到对应目录。接着编译llama.cppgit clone https://github.com/ggerganov/llama.cpp cd llama.cpp make编译完成后下载一个量化好的 LLM 模型。我推荐用指令微调版本比如 Qwen2 或 Llama 3 的 7B 指令版量化等级选 Q4_K_M。模型文件放到models/目录下。4.2 听写脚本的编写环境搭好之后写一个听写脚本把流程串起来。我用的是whisper.cpp自带的stream示例它支持从麦克风实时采集音频并识别。不过stream示例的交互方式比较原始我更喜欢用sox录音再用main识别的方式可控性更强。先写一个录音脚本record.sh#!/bin/bash # 录音 10 秒输出 16kHz 单声道 wav sox -d -r 16000 -c 1 -b 16 /tmp/dictation.wav trim 0 10sox -d表示从默认音频设备录音trim 0 10表示录 10 秒。你可以根据需要调整时长或者改成按回车停止录音。然后写识别脚本transcribe.sh#!/bin/bash WHISPER_DIR$HOME/whisper.cpp MODEL$WHISPER_DIR/models/ggml-small.bin AUDIO/tmp/dictation.wav $WHISPER_DIR/main -m $MODEL -f $AUDIO -l zh --output-txt -of /tmp/transcript cat /tmp/transcript.txt这个脚本会调用whisper.cpp识别音频输出文本到/tmp/transcript.txt然后打印出来。4.3 改写脚本的编写改写脚本接收听写结果调用 LLM 处理输出改写后的文本。我写了一个rewrite.sh#!/bin/bash LLAMA_DIR$HOME/llama.cpp MODEL$LLAMA_DIR/models/qwen2-7b-instruct-q4_k_m.gguf INPUT$(cat /tmp/transcript.txt) PROMPT你是一个专业的中文编辑。请把下面这段语音听写的原始文本整理成通顺的书面语。 要求 1. 修正错别字和标点符号 2. 去掉口头禅和重复的词 3. 保持原意不变不要添加原文没有的信息 4. 输出直接给整理后的文本不要加任何解释 原始文本 $INPUT $LLAMA_DIR/llama-cli -m $MODEL -p $PROMPT -n 512 --temp 0.7 --top-p 0.9 -no-cnv这里的-no-cnv是关闭对话模式直接输出生成结果方便脚本捕获。如果你用的是支持对话模板的模型可能需要调整参数具体看模型的说明。4.4 把流程串起来最后写一个总控脚本dictate.sh把录音、识别、改写三步串起来#!/bin/bash echo 开始录音... bash record.sh echo 识别中... bash transcribe.sh /tmp/raw.txt echo 改写中... bash rewrite.sh /tmp/final.txt echo 改写结果 cat /tmp/final.txt这个脚本跑起来之后按顺序执行三步最后输出改写后的文本。你可以把它绑定到一个快捷键上比如用 Automator 或者 Karabiner 设置一个热键按一下就跑完整流程。4.5 性能实测与参数调优我在 M1 16GB 的 MacBook Air 上做了几组测试数据如下环节模型耗时内存占用听写whisper small10秒音频约3秒约1GB听写whisper medium10秒音频约8秒约2.5GB改写Qwen2-7B Q4_K_M约5秒约4.5GB改写Llama3-8B Q4_K_M约6秒约5GB从数据看small模型加 7B 量化模型的组合总耗时在 10 秒以内日常使用完全够用。如果换成medium总耗时会长一些但准确率提升明显适合重要场合。调优方面有几个参数值得关注。whisper.cpp的-t参数控制线程数默认是 4可以调到 CPU 核心数但超过物理核心数反而会变慢。llama.cpp的-t参数同理。另外llama.cpp的--mlock参数可以把模型锁定在内存里避免被换出但会占用更多内存16GB 机器慎用。5. 常见问题与排查技巧实录5.1 听写识别不准怎么办识别不准是最常见的问题原因通常有几个。第一是音频格式不对检查是不是 16kHz 单声道用ffprobe看一下ffprobe -v error -show_entries streamsample_rate,channels -of defaultnoprint_wrappers1 input.wav如果采样率不是 16000 或者声道不是 1用前面说的ffmpeg命令转换。第二是模型太小。tiny和base模型在中文上的表现确实一般换成small或medium会有明显改善。第三是语言设置。如果你说的是中文但没指定-l zh模型可能会按英文识别结果就是一堆乱码。指定语言能大幅提升准确率。第四是背景噪音。如果录音环境嘈杂先降噪再识别。但注意降噪强度不要太高。5.2 LLM 改写跑偏或输出无关内容LLM 改写跑偏通常是提示词的问题。检查几点提示词里有没有明确说“不要添加原文没有的信息”温度是不是设得太高模型是不是指令微调版本。如果模型输出的是英文或者夹杂英文可能是模型的默认语言倾向问题。在提示词里明确写“请用中文输出”或者在系统提示里设定语言。如果输出被截断检查-n参数是不是太小。改写任务一般 512 够用但如果原文很长可能需要调到 1024 甚至 2048。5.3 内存不足导致进程被杀16GB 的 Mac 同时跑 Whisper 和 LLM内存会比较紧张。如果遇到进程被杀有几个办法一是换更小的模型比如 Whisper 用small不用mediumLLM 用 7B 不用 13B二是串行执行听写完释放内存再跑 LLM而不是同时加载三是用--mlock的反面让系统可以换出部分内存。我自己的做法是串行执行听写脚本跑完退出再启动 LLM 脚本。这样峰值内存占用会低很多。5.4 首次加载模型特别慢首次加载模型慢通常是因为模型文件在机械硬盘上或者文件太大需要从磁盘读取。解决办法是把模型放在 SSD 上Mac 内置 SSD 速度很快加载 4GB 的模型也就几秒钟。如果放在外置硬盘上速度会慢很多。另外llama.cpp支持mmap默认就是开启的它会把模型文件映射到内存加载速度快但首次访问某些页时会有缺页中断。如果内存充足可以用--no-mmap强制全部加载到内存后续访问会更快。5.5 常见问题速查表问题现象可能原因解决方法识别结果全是乱码音频格式不对转成 16kHz 单声道 wav识别结果缺字漏字模型太小或噪音大换大模型先降噪LLM 输出英文提示词未指定语言提示词加“用中文输出”LLM 输出被截断最大 token 数太小调大-n参数进程被系统杀掉内存不足换小模型串行执行模型加载慢磁盘慢或文件大放 SSD用 mmap改写结果跑偏温度太高或提示词模糊降温细化提示词5.6 几个我踩过的坑第一个坑是模型文件路径。whisper.cpp和llama.cpp都要求模型路径是绝对路径或者相对于可执行文件的路径用相对路径容易出错。我一开始用models/ggml-small.bin结果在别的目录跑就找不到文件。后来改成绝对路径就稳了。第二个坑是音频设备选择。Mac 上如果有多个音频输入设备sox -d可能选错设备。可以用sox -d -n stat看一下当前默认设备或者在命令里指定设备名。第三个坑是提示词里的换行。在 shell 脚本里写多行提示词换行符处理不好会导致提示词格式错乱。我的做法是用$...语法或者printf来构造带换行的字符串避免直接用双引号包裹多行文本。第四个坑是模型版本兼容性。llama.cpp更新很快有时候新版本不兼容旧格式的模型文件。遇到加载失败先检查模型格式和llama.cpp版本是否匹配必要时重新下载模型或者回退llama.cpp版本。6. 进阶玩法与扩展思路6.1 用流式识别做实时字幕whisper.cpp的stream示例支持从麦克风实时采集并识别可以做实时字幕。不过实时识别的准确率会比离线识别低一些因为模型需要边听边猜。我的经验是实时字幕适合做辅助参考正式记录还是用离线识别更靠谱。如果要做实时字幕可以调整stream示例的参数比如--step控制每次处理的音频长度--length控制上下文长度。步长太小会导致频繁重识别步长太大延迟高。我一般设--step 3000 --length 10000也就是每 3 秒处理一次上下文 10 秒。6.2 针对特定领域微调提示词如果你经常处理特定领域的内容比如法律、医疗、技术文档可以针对性地调整提示词。比如技术文档改写可以要求模型“保留专业术语不变”“代码片段原样保留”“按照技术文档的风格组织语言”。这些约束能让输出更符合你的需求。更进一步如果你有大量历史改写记录可以用这些数据做少样本示例甚至微调一个小模型。不过微调成本比较高对于大多数场景精心设计的提示词已经够用了。6.3 多语言混合场景的处理中英混合是很多人的日常Whisper 对中英混合的支持还可以但需要一些技巧。如果一句话里中英夹杂指定-l zh可能会把英文部分识别成中文谐音指定-l en又会把中文识别成英文。我的做法是不指定语言让模型自动检测虽然慢一点但混合场景下准确率更高。LLM 改写环节可以在提示词里说明“中英文混合的内容英文部分保持原样中文部分整理成书面语”。这样模型就不会强行把英文翻译成中文。6.4 把流程集成到常用编辑器如果你用 VS Code 或者 Obsidian 写作可以把听写和改写流程集成进去。VS Code 有 Task 功能可以配置一个任务调用 shell 脚本然后绑定快捷键。Obsidian 有 Shell commands 插件也能做类似的事情。这样你写作的时候按个快捷键就能听写并改写结果直接插入到当前文档体验非常顺滑。我自己的配置是在 VS Code 里加了一个 task调用dictate.sh然后把输出插入到光标位置。虽然不如原生功能那么无缝但用习惯了效率很高。6.5 模型更新与维护本地模型的好处是稳定坏处是需要自己维护。Whisper 和 LLM 都在快速迭代新版本可能准确率更高、速度更快。我的做法是每隔一两个月检查一下有没有新版本如果有明显提升就更新。更新之前先备份旧模型和配置万一新版本有问题可以快速回退。另外模型文件占空间不小几个模型加起来可能十几个 GB。如果硬盘紧张可以只保留常用的模型不常用的用完就删需要时再下载。7. 一些个人体会这套本地听写加改写的流程我从开始折腾到用顺手大概花了两周。中间最耗时的不是配置而是调参和试错——试不同的模型、不同的量化等级、不同的提示词找到最适合自己使用习惯的组合。但一旦跑通那种“完全离线、完全可控”的体验是云端服务给不了的。我现在的工作流是这样的开会时用small模型实时听写做草稿会后用medium模型重新识别一遍保证准确率然后用 LLM 改写成正式纪要。整个过程不碰网络敏感内容也不担心泄露。飞机上、高铁上照样能用这点对我来说价值很大。如果你也想搭一套我的建议是从最简单的配置开始先跑通whisper.cpp加small模型确认听写没问题再加 LLM 改写。不要一上来就追求最高配置那样容易在细节上卡住消磨耐心。跑通基础流程之后再根据自己的需求逐步优化这样每一步都有正反馈也更容易坚持下来。最后分享一个小技巧把常用的命令写成 alias 或者脚本放到~/.zshrc里用的时候敲几个字母就能调用。比如我设了dict对应完整流程dict-raw只做听写不改写dict-long用medium模型处理长音频。这些小快捷键看起来不起眼但日积月累能省下大量时间。
RELATED

相关推荐

Go Context模式:从超时控制到goroutine泄漏排查

Go Context模式:从超时控制到goroutine泄漏排查

今年年初,线上有个订单查询接口的P99突然从80毫秒飙到快8秒。日志干净得像什么都没发生,CPU和内存都毫无异常,一度把问题归到上游网络波动。直到某天晚上拉了一个goroutine dump,才发现卡住的那批请求背后,下游MySQL重…

📅 2026/10/31 5:27:39
context-mode:上下文感知架构与MCP协议实践

context-mode:上下文感知架构与MCP协议实践

1. “context-mode”不是功能开关,而是上下文感知架构的代号“context-mode”这个词在当前技术社区里正快速升温,但它既不是某个软件里的下拉菜单选项,也不是IDE里一个勾选框就能启用的“高级模式”。它本质上是一套围绕上下文感知&#xff0…

📅 2026/10/31 5:27:39
context-mode 设计:用模式栈替代布尔值管理复杂上下文状态

context-mode 设计:用模式栈替代布尔值管理复杂上下文状态

1. context-mode 不是玄学:一个模式栈解决的状态管理痛点最近半年我一直在重构一个内部后台系统,权限、编辑状态、预览模式、移动端适配这些逻辑散落在几十个页面里。改到后面我发现一个非常明显的问题:真正难缠的从来不是某个业务逻辑本身&a…

📅 2026/10/31 5:27:39
MORE NEWS

更多资讯

📰

08:字符替换

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

📰

【前后端】沙箱机制

概念 沙箱机制的核心目标:限制不可信代码的能力范围,保护主程序和系统安全。不是所有的沙箱机制都差不多,其实因平台、语言、目标不同而差异巨大。 有的沙箱是通过权限声明(如浏览器扩展 Manifest) 有的是通过系统级隔…

📰

07:配对碱基链

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

📰

04:石头剪子布

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

📰

05:输出亲朋字符串

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

📰

ESP32模组料号解析:N/R/H/U后缀含义与选型指南

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

TODAY

今日更新

THIS WEEK

本周精选

THIS MONTH

本月热门

读完文章,想聊聊您的网站?

告诉我们您的行业与需求,资深顾问一对一梳理方案与报价,全程免费。

📞 💬