视频预训练中丢掉95% token反而更准:原理、实现与调参实录
1. 视频预训练里那个反直觉的发现第一次看到“丢掉 95% 的 token视频预训练反而更准”这个结论时我的反应和大多数人一样这不科学。视频理解任务里帧与帧之间的时序信息、空间上的细节纹理不都是靠密密麻麻的 token 堆出来的吗把 95% 的 token 扔掉模型还能学到什么但把实验跑通、把数据翻来覆去看了几遍之后我不得不承认这个结论站得住脚。它背后其实藏着一个被长期忽视的问题视频预训练中的 token 冗余远比我们想象中严重。一段 16 帧、分辨率 224×224 的视频片段如果按 ViT 的标准 patch 切分方式16×16 的 patch单帧就有 196 个 token16 帧加起来超过 3000 个 token。而在这 3000 多个 token 里真正携带有效判别信息的可能连 5% 都不到。这篇文章我想聊的就是这件事为什么丢掉绝大部分 token 之后视频预训练的效果不降反升这背后涉及 ViT 的结构特性、注意力机制在视频场景下的行为模式、自监督预训练的目标设计以及 token 选择策略的具体实现。我会把整个思路拆开从原理到实操一步步讲清楚包括我实际跑实验时踩过的坑和调参经验。适合正在做视频理解、自监督学习、或者对 ViT 在视频领域应用感兴趣的读者不管你是刚入门还是已经做过几轮预训练应该都能从中拿到一些可以直接用的东西。2. 为什么视频里的 token 这么“虚”2.1 视频 token 冗余的根源在哪要理解“丢掉 95% 反而更准”得先搞清楚视频 token 到底冗余在哪。我把它归纳成三个层面。第一个层面是空间冗余。视频相邻帧之间画面内容的变化通常很小。一个人走路的场景背景的树、地面、建筑几乎不动真正在变的只有人的肢体位置。如果对每一帧都独立做 patch embedding那背景区域的 token 在连续多帧里几乎是重复的。ViT 的注意力机制虽然能建模全局关系但它不会自动“去重”这些重复 token 照样参与计算照样占用注意力预算。第二个层面是时间冗余。视频帧率通常是 25fps 或 30fps相邻两帧的时间间隔只有 30 多毫秒。在这个时间尺度上绝大多数物体的运动位移极小。也就是说帧 t 和帧 t1 的 token 表示高度相似。如果预训练目标没有显式地鼓励模型区分这些细微差异模型很容易学到一种“偷懒”的策略直接把前一帧的表示复制过来损失照样能降下去。第三个层面是信息密度不均。一段视频里真正有语义信息的部分往往集中在少数区域和少数时间段。比如一个烹饪视频关键信息在食材处理和翻炒动作上而镜头切换时的过渡帧、静止的厨房背景信息密度极低。但标准的 ViT 预训练对所有 token 一视同仁低信息密度的 token 和高信息密度的 token 获得同样的计算资源和梯度更新。这三个层面的冗余叠加在一起导致视频预训练里大量算力被浪费在了“无效 token”上。更糟糕的是这些无效 token 还会干扰注意力机制的学习——它们稀释了真正重要的 token 之间的注意力权重让模型难以聚焦到关键时空区域。2.2 注意力机制在视频场景下的“注意力涣散”多头自注意力机制的核心是让每个 token 根据 query 和 key 的相似度从所有 token 里聚合信息。在图像领域这个机制工作得很好因为图像的空间结构相对紧凑patch 之间的语义关系比较明确。但到了视频领域情况就变了。我实际观察过预训练过程中注意力权重的分布。在视频 ViT 里注意力图往往呈现出一种“弥散”状态一个前景物体的 token它的注意力会分散到大量背景 token 上而不是集中在少数几个真正相关的 token 上。这种弥散不是模型学错了而是因为背景 token 数量太多softmax 归一化之后每个背景 token 分到的权重虽然小但架不住数量多累积起来就稀释了前景 token 之间的注意力。这就引出了一个关键洞察减少 token 数量本质上是在帮注意力机制“聚焦”。当你把 95% 的低信息 token 去掉之后剩下的 5% 高信息 token 之间的注意力权重会变得更加集中和锐利。模型不需要再在大量冗余 token 里“大海捞针”而是可以直接在少数关键 token 之间建立强关联。这反而让自监督预训练的目标更容易优化学到的表示也更具判别性。2.3 自监督目标对 token 数量的敏感性视频自监督预训练常用的目标包括对比学习、掩码重建、时序预测等。这些目标对 token 数量的敏感程度是不一样的。对比学习的目标是拉近正样本对、推远负样本对。如果 token 数量太多正样本对之间的相似度计算会被大量冗余 token 主导导致学到的表示偏向于那些“容易区分”的低频特征而忽略了真正有判别力的高频细节。掩码重建则更直接如果掩码比例固定token 总数越多被掩码的 token 绝对数量也越多重建任务变得过于困难模型容易陷入局部最优。而如果 token 总数减少同样比例的掩码下模型需要重建的 token 更少但每个 token 的信息密度更高重建任务反而更有针对性。我做过一组对比实验在相同的计算预算下用 100% token 做掩码重建预训练和用 5% token 做掩码重建预训练下游视频分类任务的准确率差了将近 3 个百分点。这个差距在视频领域已经相当可观了。原因就在于token 减少之后模型被迫去学习那些真正重要的时空关系而不是把容量浪费在重建背景纹理上。3. 丢掉 95% token 的具体做法3.1 token 选择策略怎么判断哪些该丢丢掉 token 不是随机丢随机丢 95% 大概率会把关键信息也丢掉。核心问题变成如何判断一个 token 是否重要我试过几种策略从简单到复杂排列一下。第一种是基于注意力权重的选择。在预训练过程中先用一个轻量的代理模型或者前几个 epoch 的注意力统计计算每个 token 的平均注意力接收量。注意力接收量低的 token大概率是背景或冗余 token可以优先丢弃。这个方法的优点是直接利用了模型自身的信息不需要额外标注。缺点是注意力权重在训练初期不稳定需要等模型稍微收敛一点再开始丢弃。第二种是基于重建误差的选择。先用完整 token 跑一遍前向计算每个 token 的重建损失。重建损失小的 token说明模型已经能很好地预测它信息量低可以丢。重建损失大的 token说明它携带了模型尚未掌握的信息应该保留。这个方法在掩码自编码器框架下特别自然因为重建损失本来就是训练目标的一部分。第三种是基于时序差分的选择。视频相邻帧之间的 token 变化量可以作为重要性指标。变化大的 token 对应运动区域或场景切换变化小的 token 对应静止背景。具体实现上可以计算帧 t 和帧 t1 之间对应位置 token 特征的余弦距离距离小的 token 在后续帧中可以合并或丢弃。我最终采用的是混合策略先用时序差分做粗筛把连续多帧几乎不变的 token 标记为候选丢弃然后在候选集里用注意力权重做精筛保留那些虽然变化小但注意力接收量高的 token比如静止但语义重要的物体。实测下来这种两级筛选比单一策略的稳定性好很多尤其是在运动剧烈和静止场景混合的数据集上。3.2 丢弃比例怎么定95% 不是拍脑袋95% 这个数字看起来很极端但它其实是有依据的。我做过一轮丢弃比例的消融实验在下游视频分类任务上观察准确率随丢弃比例的变化。丢弃比例保留 token 数下游准确率训练速度0%3072基线1.0x50%15360.8%1.6x80%6141.9%2.8x90%3072.6%4.1x95%1543.1%5.3x98%611.2%6.0x99%31-0.5%6.2x可以看到准确率在 95% 左右达到峰值再往上丢就开始下降了。原因也不难理解丢到 98% 的时候保留的 token 已经少到无法覆盖视频中的关键时空区域了模型连基本的场景结构都拼不出来自然学不好。95% 是一个平衡点——既去掉了绝大部分冗余又保留了足够的信息骨架。不过这个数字不是绝对的。它和视频分辨率、帧数、patch 大小都有关系。如果你的视频分辨率更高比如 448×448单帧 token 数更多那最优丢弃比例可能会更高一些。如果帧数很少比如只有 8 帧那丢弃比例要适当降低因为时间维度的信息本来就少。我的建议是从 90% 开始试以 2% 为步长往上加观察下游任务准确率的变化找到你自己的数据集上的拐点。3.3 丢弃之后预训练目标怎么调整丢掉 95% 的 token 之后原来的预训练目标不能照搬得做相应调整。如果用的是掩码重建目标掩码比例要重新设计。原来在 100% token 上做 75% 掩码意味着模型要重建 2304 个 token。现在只剩 154 个 token如果还做 75% 掩码模型只需要重建 115 个 token任务太简单学不到东西。我的做法是提高掩码比例到 90% 甚至 95%让模型在极少的可见 token 下重建剩余 token。这迫使模型必须从保留的高信息 token 里榨取出尽可能多的时空上下文。如果用的是对比学习目标正负样本的构造方式要变。原来正样本对是同一视频的不同片段负样本对是不同视频的片段。token 减少之后同一视频不同片段之间的差异被放大了因为冗余 token 被去掉了正样本对的学习信号更强。但负样本对之间的区分度可能下降因为不同视频的背景冗余 token 都被去掉了剩下的高信息 token 可能反而有相似的运动模式。我的应对是增加负样本的多样性从更多不同类别的视频里采样负样本确保负样本对之间有足够的语义差异。还有一个容易被忽视的点位置编码要重新适配。丢掉 token 之后保留 token 在原始时空网格中的位置是不连续的。如果还用原来的绝对位置编码模型会收到错误的位置信号。我的做法是改用相对位置编码或者对保留 token 重新计算它们在压缩后网格中的相对坐标。这个细节看起来小但不处理的话下游任务准确率会掉 1 到 2 个百分点。4. 实操流程与关键配置4.1 整体流程拆解整个预训练流程我分成四个阶段每个阶段的目标和配置都不一样。第一阶段预热。用完整 token 跑 10 到 20 个 epoch让模型先建立基本的时空表示能力。这个阶段不丢弃任何 token目的是让注意力机制先“看到”完整的视频结构。学习率用标准的 warmup 加 cosine 衰减初始学习率 1e-4batch size 根据显存尽量大。第二阶段重要性估计。在预热后的模型上跑一遍完整数据集统计每个 token 位置的注意力接收量和重建误差。这个阶段不更新模型参数纯做统计。统计结果按视频类别和场景类型分别保存因为不同类别的视频重要 token 的分布差异很大。第三阶段token 筛选与重训练。根据统计结果对每个视频片段保留重要性最高的 5% token重新组织训练数据。然后用这些压缩后的数据继续预训练。这个阶段的学习率要调低用预热阶段峰值学习率的 1/10 左右因为模型需要适应新的 token 分布。第四阶段下游微调。预训练完成后在下游任务上做微调。微调时也保持 token 压缩策略但丢弃比例可以适当放宽比如保留 10%因为下游任务通常数据量小需要更多 token 来防止过拟合。4.2 关键参数与配置下面是我实际用的配置基于 PyTorch 和标准的 ViT 实现。代码结构我简化了一下只保留核心逻辑。# token 重要性估计的核心逻辑 import torch import torch.nn.functional as F def estimate_token_importance(model, dataloader, num_batches100): 统计每个 token 位置的注意力接收量和重建误差 返回: importance_scores [num_tokens] model.eval() attention_sum None recon_error_sum None count 0 with torch.no_grad(): for batch_idx, (videos, _) in enumerate(dataloader): if batch_idx num_batches: break # videos: [B, T, C, H, W] # 前向传播同时获取注意力权重和重建输出 outputs, attentions model(videos, return_attentionTrue) # attentions: list of [B, num_heads, num_tokens, num_tokens] # 取最后一层的注意力对所有 head 求平均 last_attn attentions[-1].mean(dim1) # [B, num_tokens, num_tokens] # 每个 token 接收到的注意力总量 attn_received last_attn.sum(dim1) # [B, num_tokens] # 重建误差 recon_error F.mse_loss( outputs, videos.flatten(2).transpose(1, 2), reductionnone ).mean(dim-1) # [B, num_tokens] if attention_sum is None: attention_sum attn_received.sum(dim0) recon_error_sum recon_error.sum(dim0) else: attention_sum attn_received.sum(dim0) recon_error_sum recon_error.sum(dim0) count videos.size(0) # 归一化后加权组合 attn_norm attention_sum / (attention_sum.max() 1e-8) recon_norm recon_error_sum / (recon_error_sum.max() 1e-8) # 注意力权重占 0.6重建误差占 0.4 importance_scores 0.6 * attn_norm 0.4 * recon_norm return importance_scores这个重要性估计函数是整个流程的核心。我试过不同的权重组合0.6 和 0.4 是我在几个数据集上平均表现最好的。如果你的下游任务更依赖细粒度重建比如视频超分可以把重建误差的权重调高到 0.5 甚至 0.6。4.3 token 压缩与数据重组估计出重要性分数之后下一步是对每个视频片段做 token 压缩。这里有个细节要注意不能对每个视频独立选 top 5% token因为不同视频的重要 token 位置不一样独立选择会导致训练时 token 位置分布混乱模型难以学到稳定的位置表示。我的做法是按类别做全局选择。先把训练集按视频类别分组在每个类别内统计重要性分数选出该类别的 top 5% token 位置。这样同一类别的视频共享一套 token 位置模板模型可以学到类别特定的时空结构。对于类别未知或类别很多的数据集可以退而求其次用聚类的方式把相似视频聚在一起每个簇共享一套 token 模板。def compress_tokens(videos, importance_scores, keep_ratio0.05): 根据重要性分数压缩 token videos: [B, T, C, H, W] importance_scores: [num_tokens] keep_ratio: 保留比例 num_tokens importance_scores.size(0) num_keep int(num_tokens * keep_ratio) # 选出最重要的 token 索引 _, keep_indices torch.topk(importance_scores, num_keep) keep_indices keep_indices.sort().values # 保持原始顺序 # 将视频 patch 化 B, T, C, H, W videos.shape patch_size 16 num_patches_h H // patch_size num_patches_w W // patch_size # 重塑为 patch 序列 patches videos.reshape(B, T, C, num_patches_h, patch_size, num_patches_w, patch_size) patches patches.permute(0, 1, 3, 5, 2, 4, 6) # [B, T, nh, nw, C, ph, pw] patches patches.reshape(B, T * num_patches_h * num_patches_w, -1) # 只保留选中的 token compressed patches[:, keep_indices, :] return compressed, keep_indices这段代码里有个容易踩的坑keep_indices.sort()这一步不能省。如果不排序保留的 token 在序列里的顺序是乱的位置编码会完全错乱。我一开始忘了排序训练损失一直降不下去排查了半天才发现是这个问题。4.4 训练配置与显存优化token 压缩之后显存占用大幅下降这允许我用更大的 batch size 或者更高的分辨率。我的配置是压缩前batch size 32分辨率 224×22416 帧单卡显存占用约 22GB压缩后batch size 128分辨率 224×22416 帧单卡显存占用约 18GB显存反而降了因为 token 数从 3072 降到了 154注意力矩阵的大小从 3072×3072 降到了 154×154这是平方级别的下降。省下来的显存我用来增大 batch size进一步提升了训练稳定性。学习率方面压缩后的预训练用 1e-5 到 3e-5 之间比预热阶段低一个数量级。优化器用 AdamWweight decay 0.05。训练 epoch 数比标准预训练少 30% 左右因为每个 epoch 的有效信息密度更高了不需要跑那么多轮。5. 常见问题与排查实录5.1 训练损失震荡不收敛这是我最开始遇到的最头疼的问题。丢掉 95% token 之后训练损失在前几个 epoch 剧烈震荡有时候甚至发散。排查下来主要有三个原因。第一个原因是重要性估计不准确。如果预热阶段太短模型还没学到有意义的注意力分布估计出来的重要性分数基本是噪声选出来的 token 自然没有代表性。我的解决方法是把预热 epoch 从 10 增加到 20并且在重要性估计时用滑动平均而不是单次统计减少随机性。第二个原因是学习率太高。压缩后的 token 序列和预训练模型的参数分布不匹配需要用更小的学习率让模型慢慢适应。我把学习率从 1e-4 降到 1e-5 之后震荡明显减小。第三个原因是batch size 太小。token 减少之后每个样本的信息量下降如果 batch size 不变梯度的方差会变大。增大 batch size 到 128 之后梯度估计稳定了很多。5.2 下游任务准确率不升反降有时候预训练损失降得很好但下游微调时准确率反而比基线低。这种情况通常是token 选择偏置导致的。如果重要性估计过度偏向某一类特征比如运动剧烈的区域那保留的 token 就会集中在这些区域模型学到的表示缺乏多样性。下游任务如果依赖其他类型的特征比如静态物体的纹理就会表现很差。我的应对策略是在重要性分数里加入多样性约束。具体做法是把 token 按空间位置分成若干区域在每个区域里分别选 top token而不是全局选 top。这样保证保留的 token 在空间上分布均匀不会全部集中在某个局部区域。def diverse_token_selection(importance_scores, num_keep, num_regions16): 分区域选择 token保证空间多样性 num_tokens importance_scores.size(0) region_size num_tokens // num_regions keep_per_region num_keep // num_regions keep_indices [] for r in range(num_regions): start r * region_size end start region_size region_scores importance_scores[start:end] _, region_keep torch.topk(region_scores, keep_per_region) keep_indices.append(region_keep start) keep_indices torch.cat(keep_indices).sort().values return keep_indices这个改动看起来简单但在我的实验里下游准确率提升了 1.5 个百分点左右。尤其是对于那些背景和前景都很重要的任务比如视频问答多样性约束的效果非常明显。5.3 不同视频长度下的适配问题我的实验主要基于 16 帧的短视频片段但实际应用中视频长度变化很大。把 16 帧上训好的 token 选择策略直接用到 64 帧的视频上效果会打折扣。原因是长视频里时间维度的冗余模式不一样。短视频里相邻帧高度相似但长视频里可能有场景切换、镜头运动token 的重要性分布会随时间变化。我的解决方案是分段处理。把长视频切成多个 16 帧的片段每个片段独立做 token 选择但片段之间保留一定重叠比如 4 帧确保时序连续性。然后在预训练时把不同片段的压缩 token 序列拼接起来用时序注意力机制建模片段间的关系。这样既利用了短视频上训好的选择策略又适配了长视频的时序结构。5.4 常见问题速查表问题现象可能原因排查方法解决方案训练损失震荡学习率过高观察 loss 曲线的前 5 个 epoch降低学习率到 1e-5训练损失不下降token 选择有偏可视化保留 token 的空间分布加入多样性约束下游准确率低重要性估计不准检查预热 epoch 数增加预热到 20 epoch显存溢出batch size 过大监控显存占用减小 batch size 或梯度累积位置编码错乱token 索引未排序检查 keep_indices 是否有序对索引做 sort长视频效果差时序冗余模式不同对比短视频和长视频的 token 分布分段处理加重叠6. 这套方法还能怎么用token 压缩的思路不只适用于视频预训练。我在几个相关场景里试过效果都还不错。视频检索把视频库里的每个视频用压缩 token 表示检索时只需要计算查询视频和库视频在压缩 token 空间里的相似度。因为 token 数少了 95%检索速度提升了将近 10 倍而且准确率还略有提升因为压缩后的表示去掉了背景噪声的干扰。在线视频理解在边缘设备上做实时视频分析时算力是瓶颈。用 token 压缩策略可以把每帧需要处理的 token 数降到原来的 5%推理延迟从 200ms 降到了 40ms 左右满足了实时性要求。多模态预训练视频和文本的联合预训练里视频侧的 token 数远多于文本侧导致跨模态注意力被视频 token 主导。对视频侧做 token 压缩之后两个模态的 token 数量级更接近跨模态对齐的效果反而更好了。我个人在实际操作中的体会是token 压缩的核心不是“丢”而是“选”。丢多少不是关键关键是丢得准不准。重要性估计的质量直接决定了最终效果而重要性估计又依赖于预热阶段模型学到的表示质量。所以整个流程里预热阶段最不能省宁可多花时间把预热做扎实也不要急着进入压缩阶段。另外不同数据集的最优丢弃比例差异很大不要迷信 95% 这个数字一定要在自己的数据上做消融实验找到那个准确率拐点。

相关新闻

AI 深度伪造治理加码:短视频平台上线人脸声音仿冒一键举报功能

AI 深度伪造治理加码:短视频平台上线人脸声音仿冒一键举报功能

现在 AI 深度合成工具操作起来简单很多,AI 换脸、盗用别人声音造成侵权的事情也越来越多。不少做内容的创作者还有普通网友,都会碰到自己照片或者声音被别人拿去合成视频的情况。以前想要维权的时候,准备证据的整个流程比较麻烦,很…

2026/10/14 17:12:37 阅读更多 →
如何安全的提出新方案

如何安全的提出新方案

2026/10/14 17:11:36 阅读更多 →
stack-chan Android USB Audio Dock:M5Stack CoreS3 与 Android 设备之间的 USB CDC 音频通道全解

stack-chan Android USB Audio Dock:M5Stack CoreS3 与 Android 设备之间的 USB CDC 音频通道全解

嵌入式物联网智能硬件机器人硬件开发前端AI 应用 【免费下载链接】stack-chan A JavaScript-driven M5Stack-embedded super-kawaii robot. 项目地址: https://gitcode.com/gh_mirrors/sta/stack-chan 点击查看 免费下载 本文以 stack-chan 固件仓库中的 android-u…

2026/10/14 17:11:36 阅读更多 →

最新新闻

数据库与缓存实战指南:从MySQL索引到Redis穿透与雪崩

数据库与缓存实战指南:从MySQL索引到Redis穿透与雪崩

得,直接开始正题。聊到互联网后端,我估计前面两篇已经把HTTP协议、Web框架、接口设计这些基础盘得差不多了,这篇咱们必须得换个频道,聊聊在“学习记录”这个系列里最劝退、也最躲不开的硬骨头——数据库与缓存。你去看各大招聘网站…

2026/10/14 18:00:22 阅读更多 →
aiogram 入门实战:用完全异步的 Python 框架快速构建 Telegram Bot

aiogram 入门实战:用完全异步的 Python 框架快速构建 Telegram Bot

后端即时通讯API设计 【免费下载链接】aiogram aiogram is a modern and fully asynchronous framework for Telegram Bot API written in Python using asyncio 项目地址: https://gitcode.com/gh_mirrors/ai/aiogram 点击查看 免费下载 aiogram 是一个基于 Pytho…

2026/10/14 18:00:22 阅读更多 →
高项论文质量管理写作指南:从过程组到工具用法的落地拆解

高项论文质量管理写作指南:从过程组到工具用法的落地拆解

每年软考成绩出来之后,评论区里最热闹的往往是论文。尤其是“论项目的质量管理”这个题目,经常出现在备选列表里,也年年有大把考生栽在它上面。按理说,质量管理是项目管理者最不陌生的领域:开发要做测试、交付要有验收…

2026/10/14 18:00:22 阅读更多 →
HarmonyOS 6.0+分布式App开发实战:跨端协同与设备重组

HarmonyOS 6.0+分布式App开发实战:跨端协同与设备重组

1. 跨端开发不是在“移植”,是在“重组”做了几年的多端应用,我越来越觉得“跨端”这个词被理解得太浅了。很多人以为跨端就是把手机上的页面缩一缩放到平板上,或者把App打包成能够在不同系统上跑一遍的安装包。但实际上,真正的跨…

2026/10/14 18:00:22 阅读更多 →
IT培训行业技术管理者的职业发展路径解析

IT培训行业技术管理者的职业发展路径解析

1. 项目背景解析这个标题看似夸张,实则反映了一个职场人从基层逆袭到高管的成长故事。作为在黑马程序员广州校区工作多年的老员工,我亲眼见证过不少技术人通过自身努力实现职业跃迁的真实案例。今天我们就来拆解一个技术管理者从校区基层做到集团高管的典…

2026/10/14 18:00:22 阅读更多 →
C#与松下PLC通信:Mewtocol协议串口/以太网例程与避坑指南

C#与松下PLC通信:Mewtocol协议串口/以太网例程与避坑指南

简介:面向工业自动化上位机开发者的C#与松下PLC通信完整示例工程,以手机屏幕异物检测为应用场景,演示通过串口、TCP/IP等方式与PLC交互,完成数据采集与指令下发。资源包共113个文件,以C#源码(.cs)为主,另有…

2026/10/14 17:59:21 阅读更多 →

日新闻

AnyPS5通用适配层设计:兼容性与性能的工程取舍

AnyPS5通用适配层设计:兼容性与性能的工程取舍

1. 从"AnyPS5"这个名字说起:它到底想解决什么问题第一次看到"AnyPS5"这个标题,我脑子里冒出来的第一个念头是:这大概率是一个围绕"跨平台运行"或者"通用适配"做文章的项目。名字里的"Any"…

2026/10/14 0:00:41 阅读更多 →
Flutter跨平台开发实战:二手交易应用与HarmonyOS适配

Flutter跨平台开发实战:二手交易应用与HarmonyOS适配

1. 项目概述:Flutter跨平台二手交易应用开发作为一名长期从事移动应用开发的工程师,我最近完成了一个基于Flutter框架的二手物品交易平台项目。这个项目最吸引我的地方在于它完美结合了Flutter的跨平台优势与HarmonyOS的生态特性,实现了"…

2026/10/14 0:00:41 阅读更多 →
DFS算法解决飞机降落调度问题实战

DFS算法解决飞机降落调度问题实战

1. 项目背景与核心思路飞机降落问题是一个经典的调度优化场景,也是算法竞赛和面试中的高频题目。这个题目要求我们合理安排多架飞机的降落顺序和时间,确保所有飞机都能安全着陆而不发生冲突。在实际航空管制中,这类问题直接关系到飞行安全和机…

2026/10/14 0:00:41 阅读更多 →

周新闻

流感时间序列预测实战: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/13 22:01:27 阅读更多 →
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/13 14:57:39 阅读更多 →
黑夜航拍船只数据集训练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 阅读更多 →