这两年明显感觉到一个趋势：技术博客的图文流量在下滑，视频教程的流量在涨。
B站的技术区越来越活跃，CSDN也在推视频内容，YouTube上编程教程的播放量持续增长。同样的内容，写成文章可能几百阅读，做成视频可能有几万播放。
原因不复杂。技术内容的消费场景在变化。以前大家对着电脑查资料，文章最方便。现在很多人在通勤路上、午休时间用手机看技术内容，视频比文章更适合碎片化场景。
但开发者做视频的效率远低于写文章。写一篇技术博客，从构思到发布可能两三个小时。录一个教程视频，录制加剪辑导出，一天能搞完就不错了。
其中一个很大的时间黑洞是录屏文件的处理。
录屏文件动不动几个G。QuickTime录10分钟1080P屏幕，文件大概1-2G。OBS录同样的时长，如果码率设高了也有1G多。4K录屏更夸张，10分钟可能3-4G。
文件太大带来三个问题：硬盘存不下、剪辑软件打开卡顿、上传平台被二次压缩后画质跳水。
很多开发者卡在第一步——录屏参数设置不当，导致文件从一开始就大得离谱。
录屏参数优化其实有明确的最优解：
录制分辨率设1080P就够了。4K录屏看着清晰，但大多数观众的播放设备是1080P甚至手机端720P。4K录屏文件是1080P的四倍大，收益极低。除非你的教程需要展示超小字体的代码细节，否则没必要。
帧率15-30帧。教程内容不需要60帧的流畅度——你又不是录游戏。15帧打字和鼠标操作完全够看，30帧已经很流畅了。帧率减半，文件体积也接近减半。
编码选H.264。前面说了，H.264兼容性最好，几乎所有平台和播放器都能直接播放。OBS里选x264编码器，CRF模式设23-25，画质够用且文件不会太大。
码率控制在2-4Mbps。1080P的屏幕录制，2Mbps码率文字清晰可读，4Mbps已经很精细了。超过6Mbps纯属浪费空间。
这些参数设好，10分钟的录屏文件能控制在200-400MB，比默认设置小一个数量级。
但参数优化只是第一步。录屏教程的效率瓶颈不仅在录制，还在后处理。
剪辑导出后体积爆炸是另一个常见问题。很多人用Premiere或Final Cut导出时选了高码率，结果剪完10分钟的视频导出2G。其实教程类视频对画质要求不高，导出时码率压到2-3Mbps就行。
上传到平台后的二次压缩更坑。B站、CSDN视频、YouTube都会对上传的视频重新编码压缩，你的高码率源文件上传后还是会被压。与其上传高码率让平台压，不如自己先压到合理体积再传。平台的二次压缩算法不一定比你手动压缩好，尤其是代码区域的文字清晰度，平台压缩后经常糊掉。
我自己的处理流程是这样的：OBS录制1080P/30帧/H.264/CRF24，录完用VideoCompress在线压一道，把文件压到100-200MB再上传。它还能裁剪掉开头结尾的无关片段，不用单独开剪辑软件。浏览器直接操作，比装一个本地剪辑工具省事。
还有个进阶技巧：代码区域单独高分辨率截图 + 录屏视频分开处理。录屏时全屏录制，但关键代码另外截一张高清PNG。上传时视频用合理体积，关键代码用图文补充。这样兼顾了视频文件大小和代码清晰度——观众看视频理解流程，看图文理解代码细节。
很多技术教程其实不需要全程录屏。录屏+图文混合的方式效率最高。概念讲解用图文（写起来快、读者扫得快），操作演示用录屏（直观、有代入感），代码细节用截图（清晰、可复制）。三种形式配合，比纯录屏教程的质量高，制作时间还更短。
最后说个容易被忽略的效率点：录屏前先写大纲。不需要完整脚本，但至少列个提纲——这期教程讲什么、分几步、每步演示什么操作。有了大纲，录制时不会跑偏，后期剪辑的剪切点也少。我之前录屏经常录到一半发现漏了内容，重录一遍又二十分钟过去了。写个三五行的大纲，能省掉大量返工时间。
开发者做技术内容，核心是内容质量而不是画面精美度。把录屏参数和后处理流程理顺，把时间花在内容本身上，而不是跟文件格式和体积较劲。
