ffmpeg批量合成抖音卡点视频:从BPM计算到脚本实操全流程
做短视频的朋友基本都绕不开“卡点”这个词尤其是那种十几张、几十张图片卡着音乐鼓点哐哐切的视频在短视频平台上的数据一直很能打。但我一开始是抗拒做卡点视频的因为手动在剪辑软件里一帧帧对鼓点、拖图片、调时长做一条两三分钟的视频能磨掉一下午。直到后来我专门研究用 ffmpeg 批量合成抖音卡点短视频把整套流程脚本化之后才发现这件事完全可以变成流水线工程图片一丢、命令一跑成片就出来了。这篇就把我个人打磨并验证过的思路、参数、脚本和坑一次性整理出来希望能帮你少走点弯路。1. 开始前想明白卡点视频的底层逻辑与批量方案选型1.1 所谓卡点卡的到底是什么卡点视频看起来花哨本质其实非常朴素画面切换的节奏和音乐节拍的节奏同步。人耳对节拍有非常敏锐的预期鼓点响的时候画面正好切换视觉和听觉在同一瞬间“撞”在一起大脑就会产生很爽的反馈。也因此做卡点视频真正要解决的问题只有一个如何让你的画面切换时间点精准踩在音乐的重拍上。手动剪辑做这件事有多烦做过的人都懂。你得反复听音乐在某个重音响起的地方去剪切画面图片多的时候眼睛看花、耳机戴麻一条三四十秒的视频能做一两个小时。要是突然发现中间有一张图的位置放错了那基本要从错的地方重新对齐到尾心态很容易崩。ffmpeg 解决这个问题的思路完全不同。它不跟你讲“第几秒第几帧”而是直接把“图片时长”和“视频帧率”换算成数字只要你给定了正确的参数它能保证每次都在精确的时长点切换画面。同样一张图手动剪可能要拖5秒命令跑则永远是0.044秒的精度。加上脚本可以重复执行换一批图就是一条新视频这种效率差距做内容的人一旦试过就很难再回去手动剪了。1.2 批量合成的前提规则命名、统一画幅、节拍换算既然要批量就必须要让工具能自动化地理解你的素材。第一条就是图片命名。ffmpeg 读取图片序列依赖数字编号如果你手上是IMG_001.JPG、DSC0234.jpg、photo.jpeg这种混乱命名那脚本跑起来百分之百排序错乱。所以批量合成的前置动作是把所有图片统一重命名成0001.jpg、0002.jpg这种连续编号。第二条是统一画幅。短视频平台的主流画幅是 9 比 16 竖屏也就是 1080x1920。但你手上的图片大概率是 3 比 4、4 比 3 或者 16 比 9。如果不做处理直接塞进竖屏视频画面会被拉伸变形观感直接报废。批量流程里必须设计一个“统一画幅”的环节简单说就是先等比缩放再居中裁切把每张图都处理成 1080x1920。第三条是节拍换算。做卡点必须算清楚“一张图停留多少秒”而这个数字又由音乐 BPM每分钟节拍数决定。最常见的手算是每拍时长秒 60 / BPMBPM 为 120 时每拍 0.5 秒BPM 为 90 时每拍约 0.667 秒。定了“每几拍切一次画面”之后用音乐总时长除以单张图时长就知道需要多少张图。这一步看着简单但很多人会漏掉最后音乐播完了画面还没放完或者画面全放完了音乐还挂着尾巴。这三个前提全部理顺ffmpeg 批量合成才算真正具备条件。不要试图一上来就处理几百张图跑流水线先把思路捋清楚后面每一步才会有据可依。2. 参数拆解一条 ffmpeg 命令里的卡点密码2.1 图片序列读取%03d与 glob 的正确姿势ffmpeg 读取图片序列时最典型的写法是给文件名留一个数字占位符。比如图片命名为frame_001.jpg、frame_002.jpg这种命令里就用frame_%03d.jpg让 ffmpeg 按数字递增顺序读取ffmpeg -i frame_%03d.jpg -c:v libx264 output.mp4%03d里的03表示至少三位数字从001数到999。如果你的图片超过一千张就得用%04d。这里有几个非常容易被坑到的点文件名不能“断号”。ffmpeg 读到 003 发现文件不存在时大概率会直接报错退出而不是自动跳到 005。所以要么老老实实补齐编号要么用 glob 方式。glob 方式对文件名兼容性更好适合文件命名比较随意的场景。写法是在输入项前加-pattern_type globffmpeg -pattern_type glob -i imgs/*.jpg -c:v libx264 output.mp4Linux 和 macOS 下这个方式很稳但 Windows 原生的 cmd 对 glob 支持不理想。如果你在 Windows 下用建议要么用 Git Bash 或 WSL要么直接先把文件名批量重命名成四位连续数字再走%04d路线。2.2 竖屏画幅处理宁可裁掉边缘不要拉变形目标画幅是 1080x1920但图片比例千差万别所以不能拿原图直接缩放。很多新手会写scale1080:1920这个命令确实能把图片强行变成 1080x1920但它做的是“拉伸变形”原图中的人物会变胖、建筑会变歪放到大屏上肉眼可见的假。正确逻辑是“先等比缩放再居中裁剪”。举个例子一张 4000x3000 的横图要变成 1080x1920如果直接让宽度变成 1080那高度只有 810离 1920 差得远所以先让高度变成 1920宽度等比变成 2560然后从左右各裁掉一半多余的部分剩下中间 1080 宽。对应的 ffmpeg 滤镜链是-vf scale-1:1920,crop1080:1920:(in_w-1080)/2:0-1表示宽度按高度比例自动计算crop后面的四个参数分别是裁切宽度、裁切高度、裁切起点 x、裁切起点 y。(in_w-1080)/2就是让裁切区域在水平方向居中0表示从顶部开始裁。但这里有个隐患。如果原图是竖构图比如 3 比 4 的图你按高度 1920 缩放后宽度根本达不到 1080那 crop 出来的区域会超出图片边界ffmpeg 会报错或者裁出黑边。实际批量处理时我建议在脚本里对图片比例做一个判断宽高比大于 9 比 16 的按宽度做基准宽高比小于等于 9 比 16 的按高度做基准。这样能覆盖绝大多数图片。还有一个跟构图相关的细节居中裁剪会把图片两侧的内容裁掉。所以素材准备阶段尽量挑主体在中间的图或者前期手动把关键主体放到中间区域否则自动裁剪很可能把你想展示的人脸或者核心景物切出画面。2.3 帧率与每张图的时长卡点的数学核心视频的每一秒是由很多帧构成的常见帧率是 30fps也就是每秒 30 帧。想让一张图停留 1 秒它就需要占满 30 帧停留 0.5 秒就是 15 帧。帧率和图片停留时长的乘积直接决定了画面精确在哪一毫秒切换。如果只用-i输入单张图片且不设置时长ffmpeg 默认这张图只有 1 帧播出来就是瞬间闪一下根本看不出内容。所以必须让每张图片拥有足够的帧数。最简单粗暴的方式是加-loop 1循环输入再用-t限制总时长但这种方式对所有图片一视同仁没法做到“某张图停留 2 秒、某张图停留 0.5 秒”。想要精细控制每张图的展示时间更推荐 concat demuxer 思路。先建一个清单文件里面用duration明确指定每张图持续多少秒ffconcat version 1.0 file prep_0001.jpg duration 1.0 file prep_0002.jpg duration 0.5 ...然后交给 ffmpeg 读取。这样做的好处是每张图的时间可以完全独立控制做“前奏慢、高潮快”这种节奏设计非常方便。工具层面上的差别不大但内容设计层面上的自由度差太多了。2.4 编码与封装为什么我坚持用 libx264 配 faststart视频编码方案很多但做短视频平台内容我个人的固定选择是 H.264也就是 ffmpeg 里的libx264。H.264 有最广泛的兼容性几乎所有的播放器和上传平台都能识别。虽然 H.265libx265压缩率更高但很多播放器和平台对它的支持不够好转码失败或者上传后被二次压制到画质崩坏的情况并不罕见。封装成 MP4 时我会加一个faststart参数。这个参数因为代表把 MP4 的索引信息放到文件头部播放器打开的时候不用先把整个文件下载完就能开始播放。对短视频平台来说这个参数对“打开速度快不快”有直接影响建议无脑加上。音频部分我通常用 AAC 编码码率设在 192k 以上。短视频平台的音乐本来就是听个响太高的码率没有意义反而会增加文件体积和上传时间。另外我建议音频和视频在同一个命令里直接处理不要先出无声视频再二次封装。分开处理容易引入音画时间轴的微小偏移而且多跑一次转码就多损失一次画质。3. 实操记录从图片素材到卡点成片的完整流程3.1 素材整理命名、裁切、检查三步走很多人拿到素材就直接往脚本里丢结果跑出来的视频乱七八糟。我在实际做的时候会先把图片集中到一个imgs文件夹然后统一重命名。Linux 或 macOS 下这个循环写法很顺手cd imgs i1 for f in *; do mv $f $(printf %04d $i).jpg i$((i1)) doneWindows 下用 PowerShell 也能做同样的事核心思路是一样的按顺序遍历文件并重命名为连续的四位数字。这一步至少能帮后面省掉一半的排查时间。接下来做预裁切。尽管最终合成命令里有裁剪滤镜但我还是建议先单独跑一遍预处理把每张图都变成统一的 1080x1920这样可以提前发现比例特别奇怪的图顺便看一眼构图是否被裁坏。预处理的命令大致是这样ffmpeg -y -i imgs/0001.jpg -vf scale-1:1920,crop1080:1920:(in_w-1080)/2:0 prep/prep_0001.jpg跑完以后用看图软件快速过一遍全部预处理图抽到明显变形的就手动替换。这一步虽然不算“技术活”但非常值得做因为后期如果视频里出现一张比例崩掉的图整条视频都得重出。3.2 音乐 BPM 测定与图片数量的匹配计算选好背景音乐后第一步是测 BPM。手机上有现成的节拍器软件也可以直接在音频编辑软件里看节拍波形但手点节拍器也够用。假设你测出来 BPM 是 120那么每拍时长就是 0.5 秒。接下来要定你的卡点密度也就是每隔几拍切换一张图喜欢密集切屏可以每 1 拍一切每张图 0.5 秒常规卡点每 2 拍一切每张图 1 秒节奏舒缓的大片感每 4 拍一切每张图 2 秒。定好单张图时长后再计算需要的图片数图片数量 音乐总时长 / 单张图时长比如 30 秒音乐每张图 1 秒那就需要 30 张图如果每张图 0.5 秒就需要 60 张图。素材不够就临时补图素材多了就删掉多余的这样跑出来的视频才不会有“音乐没放完画面先停”或“画面没放完音乐先停”的尴尬。这里需要特别强调一下精度。很多时候 BPM 不是 120 这种整数比如 105那每拍是 60/105 ≈ 0.5714 秒。如果你用 0.57 去算30 张图累计误差 0.042 秒肉耳几乎听不出来但累计多了还是会感觉画面和鼓点慢慢错开。我自己的习惯是保留三位小数并且让脚本自动计算不要手算然后写死。3.3 一个可直接复用的 bash 脚本预处理、清单、合成三合一下面这个脚本是我日常工作流的核心版本它把图片预处理、concat 清单生成、最终合成三个步骤整合在一起。逻辑很清楚Linux/macOS 直接跑Windows 用 Git Bash 或 WSL 环境也兼容#!/bin/bash BPM120 BEATS_PER_CUT2 CUT_DURATION$(echo scale3; 60 / $BPM * $BEATS_PER_CUT | bc) IMG_DIRimgs PREP_DIRprep OUT_DIRoutput mkdir -p $PREP_DIR $OUT_DIR # 第一步预处理所有图片 for img in $IMG_DIR/*.jpg; do base$(basename $img .jpg) ffmpeg -y -i $img \ -vf scale-1:1920,crop1080:1920:(in_w-1080)/2:0 \ -q:v 2 $PREP_DIR/${base}_prep.jpg 2/dev/null || exit 1 done # 第二步生成 concat 清单 list_file$PREP_DIR/list.txt $list_file for img in $IMG_DIR/*.jpg; do base$(basename $img .jpg) echo file $PREP_DIR/${base}_prep.jpg $list_file echo duration $CUT_DURATION $list_file done # 第三步合成最终视频 ffmpeg -y -f concat -safe 0 -i $list_file -i music.mp3 \ -vf formatyuv420p \ -c:v libx264 -preset medium -crf 20 \ -c:a aac -b:a 192k \ -shortest -movflags faststart \ $OUT_DIR/final.mp4 echo 已完成输出文件在 $OUT_DIR/final.mp4脚本里值得注意几个细节。concat 清单中每个file行之后必须紧跟对应的duration行这个顺序不能反。并且file后面的路径是相对于当前目录而言的如果脚本里用了相对路径就要确保在正确的目录下执行。-safe 0是为了允许 concat 文件里出现相对路径或非标准路径。如果这个参数不加ffmpeg 出于安全考虑可能会拒绝读取部分清单路径。-vf formatyuv420p这一段很多人不理解其实非常关键。H.264 编码的兼容性要求视频采用 yuv420p 的色彩空间如果不显式转换编码器可能会采用其他色彩采样方式导致某些播放器出现色偏或无法硬解。加上它顺便还能解决一批“播放器显示绿色画面”的诡异问题。如果你只是做一次简单卡点所有图片都统一时长且已经提前处理好也可以用更简短的命令ffmpeg -framerate 1 -i %04d.jpg -i music.mp3 -c:v libx264 -c:a aac -shortest output.mp4这里-framerate 1表示每秒读 1 帧对应一张图停留 1 秒。但这个方式不适合做精细卡点因为没办法让不同的图停留不同的时长。正经做卡点我还是推荐 concat 清单路线。3.4 进阶技巧控制“前奏慢、副歌快”的节奏曲线用 concat 清单之后你其实已经可以做到非常精细的节奏编排。比如一首歌 30 秒前 10 秒是前奏你希望每张图停留 2 秒中间 10 秒进入主歌每张图停留 1 秒最后 10 秒副歌鼓点密集每张图停留 0.5 秒。那只需要在 list 里对应位置把duration改成 2.0、1.0、0.5 即可。我通常是在脚本生成基础清单后再手动微调特殊位置的duration。比如封面图或转场图可以多停留一会儿结尾留一张图配音乐尾音慢慢淡出。这种用剪辑软件做需要反复拖动时间轴的操作在文本清单里改一个数字就能实现做完一批素材后的灵活性非常高。4. 常见问题与排查技巧实录4.1 图片顺序错乱或漏帧最常见的原因是文件命名没有补零。系统按字符串排序时1.jpg会排在10.jpg后面于是画面上出现跳来跳去的顺序。解决办法是把所有文件名统一改成四位数字比如0001.jpg到0030.jpg这个问题基本立解。排查思路很简单先用ffprobe看输出视频的帧数再用ls看图片数量两相一对比就知道有没有漏帧。如果遇到ffmpeg在处理某一张图时报错退出一般是那张图本身损坏或者尺寸特殊。可以先单独处理那张图确认后决定是否换素材。4.2 音画不同步音画不同步的根子基本在图片时长和音频时长的匹配精度上。concat 清单里duration如果保留太多小数位累计误差会越来越大。比如你在计算每拍 0.5714 秒时直接写 0.5730 张图下来就是 0.042 秒误差还不算明显但如果图片更多或者音乐长达两三分钟误差就会大得离谱。另一个容易忽视的是音频总时长。如果音频文件开头或结尾带有一段静音那即使你的图片总时长精确等于音乐的总时长听起来仍然会有“对不上点”的错位感。我一般会先用工具把音乐处理成“去头去尾、从重拍直接开始”的干净版本再用它来做卡点计算。做完视频后建议用 ffprobe 检查一下时长ffprobe -v error -show_entries formatduration -of defaultnoprint_wrappers1:nokey1 output.mp4如果视频总时长和音频总时长误差大于 0.2 秒说明图片时长跟音频节拍没有对齐需要重新检查清单数据。4.3 画面变形、黑边或裁错位置画面变形基本可以断定是用了scale1080:1920这种直接拉伸的写法解决办法是把滤镜改成-vf scale-1:1920,crop1080:1920:(in_w-1080)/2:0但前面说过这个写法只适合宽图。如果你的素材横竖图都有我更建议脚本里针对每张图单独判断比例。这样在批量处理时不会因为某张竖图被裁出黑边而中断。还有一种情况是裁切把主体裁掉了。比如人物在图片左侧居中裁剪后人物被切掉半张脸。这种没法用通用命令完美解决只能自己在准备素材阶段注意主体的构图位置重要图手动裁好再进流程。4.4 生成太慢或文件太大图片超过 50 张编码时间会明显拉长。如果你只是做预览看效果可以临时把-preset调整为veryfast牺牲一点画质换取速度确认最终效果没问题后再用-preset medium -crf 20正式导出。CRF 数值是画质和体积的权衡点越低画质越好、文件越大一般短视频用 18 到 23 之间都合理不需要追求低于 18 的极低数值。提速的另一个思路是分步合成不要每次改动一点就重新把所有图片预处理一遍。预处理的中间图保留好最终合成时只跑一次编码试错成本会低很多。4.5 加文字、logo 与片尾在最终合成命令的-vf里叠加 overlay 滤镜就可以给视频加 logo-vf overlayW-w-20:H-h-20W和H是主视频的宽高w和h是 logo 素材的宽高这个写法表示 logo 放在距右下角 20 像素的位置。加文字水印则需要用到drawtext滤镜同时指定字体文件路径否则系统找不到字体就会报错。要注意滤镜顺序裁切相关的滤镜一定要放在 overlay 之前否则坐标计算会出错logo 不知道会飘到画面外还是错位。结尾我对卡点视频从抗拒到熟练其实就是从学会“用 ffmpeg 算节拍”开始转变的。过去在剪辑软件里拖素材、对鼓点、调时间轴的工序现在统统变成改数值、跑脚本原来一下午磨一条视频的时间现在能批量解决一批素材剩下的精力可以花在内容的选题和画面挑选上。最后再分享一个小习惯每次跑完脚本以后我不会直接拿最终文件去发布而是先极速预览一遍重点检查有没有照片构图被裁歪、有没有相邻两张图片颜色跳跃太大、有没有某个切换点刚好卡在音乐空隙上。卡点的精度是算法的事但内容的观感仍然需要人来判断。只要把流程拆成“可验证的步骤”再用脚本把重复劳动自动化你会发现批量做卡点视频这件事真的没有想象中那么耗人。

相关新闻

Django 5模型层数据库连接实战:从配置到迁移再到ORM优化

Django 5模型层数据库连接实战:从配置到迁移再到ORM优化

Django 5 发布之后,我把手头一个模拟项目从 4.x 升级到了 5.x,前后折腾最久的地方,不是新特性研究,反而是最不起眼的“模型层连接数据库”这一环。很多人觉得连数据库不就是填个配置吗?等真开工就会发现,驱…

2026/10/15 6:59:51 阅读更多 →
天鹰优化算法AO实现多无人机三维协同避障路径规划

天鹰优化算法AO实现多无人机三维协同避障路径规划

1. 从"能飞"到"飞得聪明":多无人机三维路径规划到底难在哪多无人机协同集群避障路径规划,说白了就是让一群无人机从各自的起点出发,在充满山峰、雷达威胁区和禁飞区的三维空间里,找到一条既安全又省油、还能按…

2026/10/15 6:59:51 阅读更多 →
无铜点击化学荧光探针:生物标记技术新突破

无铜点击化学荧光探针:生物标记技术新突破

1. 项目概述:绿色荧光探针的技术突破在生物标记和分子检测领域,荧光探针就像黑夜中的信号灯,能够精准标记目标分子并发出光学信号。传统铜催化点击化学(CuAAC)虽然应用广泛,但铜离子容易导致荧光淬灭&#…

2026/10/15 6:59:51 阅读更多 →

最新新闻

CentOS 7.6搭建DNS正向解析服务:BIND配置实战

CentOS 7.6搭建DNS正向解析服务:BIND配置实战

平时做运维的朋友肯定都有过这种经历:公司内部新起了一套系统,IP地址越来越多,今天要连这个、明天要连那个,总不能天天翻Excel表格。更尴尬的是,内网服务想用一个好记的域名访问,结果发现公共DNS根本不认识…

2026/10/15 7:37:59 阅读更多 →
ConcurrentHashMap 1.7与1.8源码对比:从Segment到CAS+synchronized的并发演进

ConcurrentHashMap 1.7与1.8源码对比:从Segment到CAS+synchronized的并发演进

做Java开发的朋友,多少都被ConcurrentHashMap“教育”过。面试要问,源码分析要讲,线上排查高并发问题也绕不开它。而只要一聊到源码,1.7和1.8这两个版本的区别就是永远躲不开的坎:一个是Segment分段锁,一个…

2026/10/15 7:37:59 阅读更多 →
WinForm文本编辑器源码解析与高级功能扩展实战指南

WinForm文本编辑器源码解析与高级功能扩展实战指南

简介:这份C#文本/代码编辑器专题文档,面向具备一定C#基础、想从零构建或二次开发编辑器的研发人员,解决从界面搭建、文件操作到功能扩展各环节的关键问题。文档先讲解基于WinForm与RichTextBox的基础实现,包括字体加粗/斜体/下划线…

2026/10/15 7:37:59 阅读更多 →
微信小程序投票系统怎么从零搭建?以活动评选为例的完整流程

微信小程序投票系统怎么从零搭建?以活动评选为例的完整流程

从技术视角看,在微信生态里"创建一个投票活动",本质是配置一套活动数据结构 报名审核状态机 防刷策略 数据导出能力。本文以「活动评选」场景为例,梳理从创建到发布的完整流程,并以投票帮小程序作为落地实践案例。 …

2026/10/15 7:37:59 阅读更多 →
T型三电平逆变器VSG自适应控制与并离网切换优化

T型三电平逆变器VSG自适应控制与并离网切换优化

1. 项目背景与核心价值电力电子变换器在新能源发电系统中扮演着关键角色,而T型三电平逆变器因其高效率、低损耗的特性,在中大功率场合得到广泛应用。传统逆变器控制策略在并离网切换过程中常面临暂态冲击大、同步性能差等问题,这正是虚拟同步…

2026/10/15 7:37:59 阅读更多 →
软件的本质是行为:REA式行为克隆全流程拆解与实操复盘

软件的本质是行为:REA式行为克隆全流程拆解与实操复盘

说真的,看到“REA三天狂揽12万星”那条标题的时候,我第一反应是:这又是标题党?一个Agent,不用源码就能克隆一切软件,听起来太像营销号编出来的故事。但等我顺着链接把演示看完,又拿自己手头一个…

2026/10/15 7:36:59 阅读更多 →

日新闻

Docker Compose 容器化部署 ChirpStack LoRaWAN 网络服务器实战

Docker Compose 容器化部署 ChirpStack LoRaWAN 网络服务器实战

1. 为什么选择容器化方式部署 LoRa 网络服务LoRa 物联网项目落地时,网络服务器是整个链路的核心枢纽。它负责接收网关上报的数据包、完成去重与解密、再把有效载荷分发给上层应用。早期大家习惯把网络服务器直接装在物理机上,依赖一堆系统库和特定版本的…

2026/10/15 0:00:46 阅读更多 →
共享LLM服务下的跨模型自动扩缩容:Kubernetes实战与避坑指南

共享LLM服务下的跨模型自动扩缩容:Kubernetes实战与避坑指南

1. 共享推理服务里,扩缩容到底难在哪做过大模型推理服务部署的人,大概都经历过这样的场景:一个团队共用一套推理集群,A 业务跑的是 7B 的小模型,B 业务跑的是 72B 的大模型,C 业务白天流量高、晚上几乎归零…

2026/10/15 0:00:46 阅读更多 →
Systemd 启动阶段根文件系统只读之谜:fstab 与 remount-fs 服务深度解析

Systemd 启动阶段根文件系统只读之谜:fstab 与 remount-fs 服务深度解析

1. 引子:一次内核恐慌引发的追查先从一个真实场景说起。某次我给一台老旧的嵌入式设备折腾系统裁减,为了把启动时间压进两秒以内,我手贱地把一串自认为“没用”的 systemd 服务给 disable 了,其中就包括systemd-remount-fs.servic…

2026/10/15 0:00:46 阅读更多 →

周新闻

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

简介:基于 ARIMA、LSTM、Transformer 等模型的流感时间序列预测 Python 源码,面向计算机相关专业课程设计与期末大作业学生,以及项目实战学习者。内容覆盖预处理、平稳性检验、定阶、残差分析、多模型对比预测的完整时序建模流程,…

2026/10/14 3:30:28 阅读更多 →
影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别 做影刀RPA自动化,十个新手有八个栽在"往输入框里填东西"这件事上:要么填不进去,要么填了一半,要么直接把原来内容追加在后面。这背后的根因&…

2026/10/14 16:30:29 阅读更多 →
影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容 1. 认识影刀:什么场景该用RPA采小说数据 起点中文网的页面结构相对稳定——分类榜单、书籍详情、章节内容三块独立页面,跳转链路清晰。这种场景非常适合影刀自动化&#x…

2026/10/14 3:29:58 阅读更多 →

月新闻

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

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

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

2026/10/15 0:14:36 阅读更多 →
Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

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

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

2026/10/14 22:45:47 阅读更多 →
黑夜航拍船只数据集训练YOLOV5模型全流程解析

黑夜航拍船只数据集训练YOLOV5模型全流程解析

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

2026/10/14 7:53:34 阅读更多 →