海外仓错发率居高不下?从WMS系统设计看二次复核与防错机制
海外仓错发率居高不下从 WMS 系统设计角度看“二次复核”与防错机制的实现跨境电商圈子里有个说法发错一件货轻则赔运费、赔货款重则丢账号、丢信任。我见过不少做海外仓的朋友月错发率从0.5%涨到2%就急得睡不着因为海外仓不像国内仓退换货链路长、成本高一旦发错到海外消费者手里基本很难挽回。很多人第一反应是“加强员工培训”“增加人工检查”但实际折腾一圈下来发现错发率降幅微乎其微甚至因为环节变多导致效率崩了。我自己做过几个海外仓的 WMS仓储管理系统项目最深的体会是错发率的根子不在人而在系统防错机制设计得到不到位。4000多个SKU、多平台多渠道订单、多国别多物流方式混在一起如果 WMS 不在关键节点主动“卡住”错误光靠肉眼盯是盯不住的。这篇文章我想从 WMS 系统设计的角度聊聊海外仓错发问题的根源、二次复核机制到底该怎么设计、以及一套完整的防错机制包含哪些关键环节。适合海外仓运营负责人、WMS 产品经理、仓储系统开发工程师以及正在被错发率困扰的卖家朋友参考。1. 错发率为什么降不下来从业务表象到系统设计缺陷1.1 海外仓的业务复杂度是错发的温床先看一组我整理过的现场情况一个典型的海外仓同时服务几十家第三方卖家商家托管模式每家卖家几十到几千个 SKU这些 SKU 可能来自不同国家、不同批次外包装长得极其相似。订单从多个电商平台不同渠道和独立站接入再按不同的物流渠道分流每个渠道对标签格式、装箱要求、报关信息的要求还不一样。在这种复杂度下错发几乎无处不在拣货时拿错相似 SKU外观近似条码被遮挡或破损贴标时贴错目的国标签尤其是一票多国混发时装箱时混入其他订单的商品一单多箱或一箱多单搞混集货时放错道口同一个波次里多个目的国/渠道并行夜班或大促期间人困马乏扫描枪“滴”一声就过根本没看屏幕这些问题表面看着是“操作失误”但往深了看每一个场景背后都是系统设计问题要么校验点设得少要么校验点设得晚要么校验逻辑太弱要么干脆没有校验。1.2 常见的系统设计误区我在不少项目里见过这三类典型误区。第一类只在出库环节设一次复核。整条链路里收货、上架、拣货都没有防错校验所有风险堆到打包复核一次性拦截。结果就是纠正成本极高——货已经拣完、箱已装好复核发现错了要重新开箱、重新拣货、重新打包效率损失巨大。第二类复核只是“再扫一遍”但没有逻辑校验。很多 WMS 的复核流程就是扫描包裹面单系统确认这个包裹存在就放行根本不校验包裹里的商品是否等于订单明细。这是最典型的“假复核”——流程走完了错发照样发生。第三类校验全部硬中断导致作业阻塞。有一些系统设计得很“严格”任何校验失败立刻停机等待人工处理。听起来很安全但实际上海外仓一天几万单复核台一旦卡住整个出库线就得瘫痪。于是为了保时效现场管理者往往选择“先放行后处理”防错机制形同虚设。这三类误区的核心病根是同一个把“防错”理解成了“查错”把“复核”理解成了“再扫一遍”。真正的防错机制应该嵌入到 WMS 的每一个关键作业节点让错误在“发生的那一刻”就被系统识别并拦截而不是等错发事实形成了再靠人去找出来。2. 二次复核的四道关键节点校验点设在哪、怎么设2.1 节点一收货上架复核——让错误从源头就进不来很多海外仓把防错重点放在出库端却忽略了入库端。实际上很多错发是“源头错”供应商贴错标、采购单与实物不符、批次混装、SKU 与条码不一致这些错误如果在收货环节没拦住后面所有环节都会跟着错。国内某海外仓项目里曾遇到过一个典型情况同一款产品有 200g 和 500g 两个规格外包装长几乎一样供应商把两层标签叠贴外面一层是 200g撕开里面是 500g。收货员如果只扫最外层条码50 箱 500g 的货就会被当成 200g 上架到对应库位。等到拣货时系统按 200g 的库位索引下发拣货任务拣出来的实际全是 500g发到消费者手里必然货不对板。在 WMS 设计里收货复核不能只是“扫了条码就算完”至少要包含三件事实物比对按采购单收货时要求收货员在 RF 枪上录入实收数量系统与预期数量比对不一致则强制进入差异处理流程。规格属性确认针对多规格相似的 SKU系统应弹出该 SKU 的关键属性规格、颜色、重量、批次让收货员做二次确认而不是扫完即走。库位绑定校验上架时系统要求输入目标库位并校验该库位是否允许存放此 SKU。如果某库位已经被其他 SKU 占用上架任务直接报错杜绝“混放”。2.2 节点二拣货复核——分拣墙模式下的防错设计海外仓拣货主流的模式是“波次拣货”系统把多笔订单合成一个波次拣货员按波次单到库位拣货再回到分拣区按订单分播。这种模式效率高但也是错发高发环节——几十个订单的商品堆在同一辆拣货车上任何一个放错格口整波次里至少一单会错。针对这个环节防错机制有两种主流设计。一种是SCA扫描确认分配模式分播时每放入一个商品到某个格口RF 枪必须扫描该商品的 SKU 条码和该格口的条码系统校验该 SKU 是否属于该格口对应的订单。校验通过才能完成分播。这种模式防错能力强但效率相对低适合高货值、易混淆品类的精细化管理。另一种是PDA 枪显屏引导数量校验模式分播时不逐个扫描而是通过分拣墙电子标签电子标签拣选系统或 PDA 显示目标格口拣货员按引导放入放完后在枪上确认数量。系统比对“应分数量”和“实分数量”不一致则报错。这种模式速度更快但对操作员专注度要求较高。我实际项目里更推荐的是混合方案普通 SKU 走引导式分播易混淆 SKU系统通过历史差错率打标强制走扫描确认模式。这需要 WMS 具备 SKU 风险等级画像的能力而不是对所有商品一刀切。2.3 节点三打包复核——出库前的最后一道硬校验打包复核是大家通常理解的“二次复核”也是最需要系统支撑的一道关。如果前面节点都做对了打包复核的核心任务就是把“系统认为要发的”和“实际装箱要发的”做一次完整比对并把复核结果持久化到数据库作为后续追溯的依据。在我设计的系统里打包复核的流程是这样扫描包裹面单或订单号→ 系统调取出该订单的完整明细SKU、数量、目的国、渠道。逐件扫描箱内商品条码 → 系统实时比对该 SKU 是否属于当前订单。数量比对扫入的商品数量应与订单数量一致多扫、少扫、漏扫均报错。属性校验目的国、渠道、运输方式与面单关联信息比对拦截“一国贴标误发到另一国”场景。完成后自动打印面单与装箱单面单信息与订单信息同源杜绝手写。这一步最关键的设计原则是必须做到“扫一件、校验一件”。如果系统允许先扫完全部商品再统一校验操作员极可能漏扫一件而系统完全无感知。2.4 节点四集货出库复核——防“最后一百米”乱套打包完成之后包裹进入集货区按目的国、渠道、承运商分堆然后装车出库。这一步看似简单但大规模出货时非常容易乱同样是发往某国家的包裹不同承运商的面单格式相似集货员一不留神就会把 A 承运商的包裹放进 B 承运商的货堆。集货出库节点的防错机制业界常用的是道口扫码绑定每个道口对应一个目的国/渠道/承运商组合集货员将包裹放入道口前必须扫描道口条码和包裹面单条码系统校验两者是否匹配不匹配则声光报警并禁止放入。这样每个包裹从“打包完成”到“装车出库”的路径都有系统记录事后若发生错发可以精准定位到是哪个环节、哪个人、哪次操作出了问题。这个节点的复核还有一个副作用数据的价值。集货出库数据是后续做错发率归因分析的基础——到底是拣错、贴错、还是装错通过四个节点的数据一比照几分钟就能定位出来。3. 防错机制的系统化实现条码规则、波次策略与校验逻辑3.1 条码规则的统一设计一码到底防错机制的地基是条码。很多海外仓错发率高根源在于条码体系混乱同一个 SKU 在不同卖家那里有不同条码有些商品有条码有些没有条码打印模糊、贴错位置一个商品上有多个条码导致扫描枪不知道扫哪个……我在项目里第一条硬规矩是所有入库商品必须重新打码换成本仓统一格式的“库内条码”。库内条码至少包含三段信息卖家编号 SKU 编号 批次号可选。通过条码规则就能实现两个效果一是条码的唯一性拿到任何一个条码系统都能唯一定位到“谁的货、什么东西、哪一批”二是校验的可编程性所有环节的防错逻辑全部基于这个条码展开。同时还要规范打印位置和标签尺寸。多数海外仓的错发现场里“标签贴歪导致扫描失败后手输条码”是高频事故源——操作员手输条码一旦输错一位系统查无此码可能还能拦截但若查到另一个真实存在的 SKU就直接错发了。因此标签打印质量控制、扫描失败后的异常流程设计跟条码规则本身一样重要。3.2 波次策略从源头减少混发机会波次策略听起来跟“防错”没什么关系但我在多个项目里实测下来波次设计对错发率的影响非常显著。一个波次里的订单如果目的国、渠道、承运商五花八门拣货、分播、集货环节的操作复杂度会指数级上升错发概率自然也上去了。合理的波次策略应该做到**“作业单元内部尽量同质化”**同一波次尽量合并同渠道、同目的国的订单同一波次尽量合并相同承运商/面单模板的订单热门 SKU 集中波次、冷门 SKU 分散波次避免一个波次里 SKU 数量过多导致分播压力易混淆 SKU 尽量不进同一个波次比如不同规格但外观相似的 SKU分到不同波次从物理上隔离错拣的可能性这个策略我在某海外仓落地后错发率三个月内下降了 40% 多。不需要额外增加复核人员只是改变了订单组合方式效果却非常明显。3.3 校验逻辑的层级设计软校验与硬校验校验逻辑不能一刀切。全部软校验等于没校验全部硬校验会导致作业阻塞。我在实际设计中通常把校验分成三个层级第一层提示级软校验。系统发现潜在风险但不确定一定是错的仅给出提示操作员确认无误后可继续。例如扫描的商品不属于当前波次但可能是绑定了其他波次的同款商品系统提示“该商品已绑定其他波次是否继续”由操作员判断。第二层拦截级硬校验。系统明确认定操作与订单不符强制中断必须由组长或系统管理员授权才能继续。典型场景扫描的商品条码根本不存在、订单已取消但仍在拣货、扫描数量超过订单数量。第三层冻结级异常闭环。系统发现重大问题如盘点差异、批次异常、疑似串货自动冻结该商品、该库位或该订单转入异常处理队列等待库内核查完成后再解除。一个好的 WMS 应该让这三种校验层级可配置针对高风险 SKU 提高校验层级针对大促期间阶段性放宽软校验阈值针对新员工操作时开启更严格的全量硬校验。系统要能适应业务场景的变化而不是一套死逻辑用到底。3.4 异常联动复核发现错误后系统该做什么很多 WMS 的复核流程设计漏掉了最关键的“异常分支”复核发现错误后系统只是报个错然后就没了。操作员要把错误商品拿走但怎么处理完全靠人工这就容易出现二次失误。我设计复核异常处理流程时遵循一条原则系统必须给出“下一步做什么”的明确指引不允许操作员自由发挥。具体来说复核报错后系统需要做四件事阻止当前校验动作继续锁定该包裹/订单。生成一个异常处理任务分配给操作员或组长带着上下文信息订单号、应发 SKU、实扫 SKU、差错类型。将错误商品自动退回“待拣区”或“异常隔离区”更新库位库存状态。记录完整差错日志并联动流程引擎决定是否重新生成拣货任务或补货指令。只有做到这四步错发问题才能形成一个“自我修复”的闭环而不是每次差错都要人工现场协调、口头传达、事后忘记。3.5 数据支撑复核数据回流与绩效绑定防错机制建设的最后一步是数据建设。每一次复核、每一个校验失败、每一笔异常处理都应该形成结构化数据沉淀。这些数据有三个用途定位薄弱环节按环节统计差错拦截率看看错误主要发生在收货、拣货、打包还是集货阶段针对性投入资源。优化 SKU 画像沉淀每个 SKU 的差错历史持续识别易混淆 SKU、高差错商品动态调整复核策略从轻复核升级为重复核。绩效到人按操作员统计差错记录考核到个人结合培训计划定向提升。很多仓库管理者会说“考核太难了员工会抵触”但数据透明之后反而是最公平的管理手段——系统记录精准到每一票每一件比人工记小本本靠谱得多。4. 常见问题与排查技巧实录4.1 复核效率太低日处理单量上不去怎么办这是推行二次复核后最常遇到的问题复核流程变重打包台成了瓶颈。排查思路先看校验逻辑的软硬分布。如果所有订单都走全量逐件扫描效率必然低。建议做风险分级把商品分为高、中、低三个风险等级低风险 SKU标准条码、单一规格、历史零差错走快速复核仅扫描面单确认订单存在即可。中风险 SKU相似商品、多规格、历史差错率中等逐件扫描校验但不强制称重复核。高风险 SKU易混淆、高货值、历史差错率超标逐件扫描 称重复核 强制拍照留档。实测下来这种分级方案能覆盖 80% 的日常订单而复核效率大约只下降 15% 左右在可控范围内。4.2 员工扫码后不看屏幕系统校验形同虚设“滴”一声就过根本没看屏幕上的校验结果这是所有仓库数字化转型都会遇到的顽疾。系统已经拦截了错误但操作员不看直接按确认前面那单错发照样出去了。我的做法有两个层面。技术上把拦截级校验设计成“必须二次确认”的交互当校验失败时系统不只是在屏幕角落弹一行红字而是全屏高亮警示、强制要求操作员选择异常类型、并在枪上按确认键才能继续。通过交互层迫使操作员注意到异常。管理上把“校验失败率”和“二次确认率”作为操作员的 KPI 之一每周公示。校验失败率高说明操作员拣货注意力有问题校验失败但二次确认率超标则说明操作员在“盲扫”。数据透明之后问题就变成了管理问题而不是单纯的技术问题。4.3 硬件设备扫描不灵敏旧条码识别率低条码破损、脏污、印刷质量差是 WMS 防错机制最大的敌人。扫描枪读不出来操作员就会选择手输手输就要看键盘看键盘就会输错。经验是“条码识别兜底方案”给复核台配备影像式扫描枪比起传统激光枪对脏污条码识别率高得多。扫描失败时系统自动弹出“模糊匹配”功能操作员只需输入条码末尾几位 商品名称关键词系统列出候选列表供选择减少全码手输的出错概率。对反复扫描失败的条码自动打标触发商品重新打码流程而不是每次复核都跟这个破条码死磕。4.4 系统已经拦住错误但包裹还是发错了这种“灵异事件”通常有两个原因一是面单打印环节出了问题系统校验正确但打印好的面单被贴错包裹二是复核完成后包裹被二次操作复核完放到暂存区又被其他人移动混放。针对第一个原因我习惯在复核流程中增加“面单与包裹绑定校验”打印面单时操作员扫描包裹箱上的临时条码或复核时生成的打包任务号系统将面单信息与该包裹绑定面单贴上去之前再做一次扫描确认。针对第二个原因复核完成后的包裹必须进入“已复核暂存区”该区域的道口扫描逻辑与前文讲的集货出库一致确保复核完成的包裹不会脱离系统视野。4.5 大促期间错发率飙升怎么平衡时效与防错大促期间单量翻倍、临时工增多、系统承压防错机制往往第一个被牺牲掉。我的建议是不要牺牲校验而是优化校验的节奏。大促期间把“全量逐件校验”降级为“首件校验 尾件校验 抽样校验”的组合每波次拣货后的分播环节系统抽查若干订单做逐件复核对高价值订单、易错 SKU 订单保持全量复核其余订单做打包后的外包装完整性校验不拆箱逐件查。这样做虽然做不到 100% 拦截但可以做到“高风险单子全拦截、低风险单子效率最大化”。大促结束后恢复全量校验并根据大促期间的差错数据重新评估哪些 SKU 应该从低风险转到高风险。5. 写在最后几个我踩过的坑和心得做海外仓 WMS 防错设计这么多年有一个体会特别深防错机制不是上线一个功能就结束了而是持续运营的过程。系统逻辑落地只是第一步真正决定错发率高低的是系统设计完之后有没有人去盯数据、去优化策略、去推动管理动作闭环。我自己踩过最痛的一个坑是早期做一个“严格复核方案”时没有和现场作业人员充分沟通硬上全量逐件校验结果上线第二天打包区就堆了几百票待处理件操作员怨声载道。后来我改了方式先小范围试点 3 天收集效率数据和问题清单调整之后再逐步铺开。现在我做任何防错相关设计都会先问三个问题校验强度会不会卡死作业流异常处理路径是否清晰操作员是否理解系统的“意图”如果这三个问题没有明确答案再完美的防错逻辑也落不了地。另一个经验是错发率的指标拆解不能只看总数。总错发率 上架差错 拣货差错 复核漏检 集货差错。通过四个节点的数据流转我们可以把每个环节的差错率拆出来单独考核。如果没有这个拆解能力管理者看到的只是一个大数想发力都不知道往哪儿打。这也是我为什么在系统设计里坚持要求每个复核节点都保留完整操作日志——不是为了事后追责而是为了让管理者随时能看到“错在最前面一环”。如果你们也在为海外仓错发率发愁我的建议是先别急着加人、加检查、加罚款先把 WMS 的四道复核节点捋一遍把校验逻辑从“查有没有”升级到“查对不对”把异常闭环从人工协调变成系统驱动。大多数错发问题改完系统逻辑之后会有明显改善。剩下的再靠管理手段慢慢磨。

相关新闻

AI让数学再也回不去那个旧世界了。

AI让数学再也回不去那个旧世界了。

昨天早上,可能会是人类时代的一个分水岭。 以至于这篇文章,在我即使有提前做了大量功课,有一定的知识储备的情况下,还是写了整整一天的时间,完稿时间是今天的凌晨6点15,无他,还是因为这个事件的…

2026/10/10 2:54:07 阅读更多 →
Python Java PHP底层对比:内存并发性能全解析

Python Java PHP底层对比:内存并发性能全解析

1. 为什么突然想聊这个话题最近在群里看到不少朋友争论“到底该学 Python 还是 Java”,还有人问 PHP 是不是真的不行了。说实话,这类问题很难用一句话回答,因为三个语言背后的设计思路差别挺大。今天不打算站队,就单纯从底层实现的…

2026/10/10 2:54:07 阅读更多 →
Meta:大模型协同进化并自我精炼

Meta:大模型协同进化并自我精炼

📖标题:Recursive Self-Improvement via On-Policy Distillation for Reasoning 🌐来源:arXiv, 2609.30652v1 🛎️文章简介 🔸研究问题:在大型语言模型的推理训练中,如果负责指导的“…

2026/10/10 2:53:06 阅读更多 →

最新新闻

MATLAB联合CST建模:超表面仿真自动化工作流实战

MATLAB联合CST建模:超表面仿真自动化工作流实战

最近不少做超表面的同学都在折腾CST仿真,尤其是想把MATLAB联合CST建模这条路彻底走通,用来处理超透镜、轨道角动量、吸收器、极化转换器、EIT(类电磁诱导透明)这些常见方向。这篇文章不打算讲教科书推导,只写我在真实仿…

2026/10/10 3:48:27 阅读更多 →
PostgreSQL权限管理实战:角色体系、层级授权与行级安全

PostgreSQL权限管理实战:角色体系、层级授权与行级安全

1. 权限分配这件事,先搞懂 PostgreSQL 的角色体系做数据库运维这些年,我发现一个特别有意思的现象:很多人对 PostgreSQL 的权限管理第一反应是“这不就是 grant 一下嘛”,可真到了线上环境,经常被各种“没权限”“权限…

2026/10/10 3:48:26 阅读更多 →
1996-2024年各省农业总产值无缺失面板数据:从处理到分析完整指南

1996-2024年各省农业总产值无缺失面板数据:从处理到分析完整指南

做农业数据分析的人应该都有过这种经历:想研究各省农业生产的长期变化,打开官方数据库发现要么年份对不上,要么某些省份某几年突然缺了一块,要么当年价格和可比价格混在一起,搞不清谁是谁。最后大量时间花在找数据、拼…

2026/10/10 3:48:26 阅读更多 →
SCSI磁盘实战指南:从协议原理到Linux诊断调优

SCSI磁盘实战指南:从协议原理到Linux诊断调优

1. 项目概述:为什么“SCSI磁盘”这个老词还在工程师的日常对话里反复出现你可能在服务器机房巡检时听到运维同事说“这台存储柜挂了两块SCSI盘,热备没切过去”,也可能在旧系统迁移文档里看到“需兼容SCSI-3 SPI协议的磁盘阵列”,甚…

2026/10/10 3:48:26 阅读更多 →
PostgreSQL自定义函数规范:从命名到性能排查的完整指南

PostgreSQL自定义函数规范:从命名到性能排查的完整指南

1. 为什么自定义函数必须讲规范1.1 从一次线上事故说起先说一个我亲眼见过的教训。某公司的订单系统,早期为了赶业务进度,开发人员在 PostgreSQL 里写自定义函数时完全放飞自我——函数名有的叫get_data、有的叫f_order,参数类型混用 varchar…

2026/10/10 3:48:26 阅读更多 →
PyTorch+LSTM电影评论情感分析实战:从预处理到模型部署

PyTorch+LSTM电影评论情感分析实战:从预处理到模型部署

简介:一份评审分达99分的基于深度学习的电影评论情感分析项目资源包,适合计算机相关专业课程设计、期末大作业及入门实战,重点解决从数据爬取到模型训练演示中缺完整代码、缺数据集、缺文档的常见问题。资源围绕豆瓣短评设计,约5万…

2026/10/10 3:47:26 阅读更多 →

日新闻

卫星轨道分类全解析:从LEO到GEO的选型逻辑与工程实践

卫星轨道分类全解析:从LEO到GEO的选型逻辑与工程实践

1. 从“卫星轨道分类”这个标题说起:为什么值得花时间搞懂第一次接触“卫星轨道分类”这个概念,很多人会觉得它离自己很远——不就是天上的星星怎么转吗?但如果你正在做航天任务规划、遥感数据接收、星座设计,甚至只是准备一场航天…

2026/10/10 0:00:39 阅读更多 →
Spring AOP 核心原理与实战:从概念到日志切面落地

Spring AOP 核心原理与实战:从概念到日志切面落地

1. 从一个真实痛点说起:为什么你的代码里到处都是重复逻辑刚入行那会儿,我写过一个用户管理模块,注册、登录、改密码、注销四个接口。每个接口里都塞了几乎一样的日志打印、参数校验、事务开启和提交。当时觉得没什么,能跑就行。直…

2026/10/10 0:00:40 阅读更多 →
Python招聘数据采集与分析可视化:从采集清洗到薪资技能城市可视化全链路

Python招聘数据采集与分析可视化:从采集清洗到薪资技能城市可视化全链路

简介:这是一套面向计算机相关专业学生与项目实战学习者的Python数据采集与分析可视化完整项目,以Boss直聘岗位数据为对象,适合用作毕业设计、课程设计或期末大作业。资源包共38个文件,约246KB,以13个py源码文件为核心&…

2026/10/10 0:00:40 阅读更多 →

周新闻

KT148A语音芯片外挂8002D功放的工程实践指南

KT148A语音芯片外挂8002D功放的工程实践指南

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

2026/10/8 15:26:32 阅读更多 →
LLC谐振变换器增益公式推导:从FHA等效到完整归一化表达式

LLC谐振变换器增益公式推导:从FHA等效到完整归一化表达式

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

2026/10/10 1:36:08 阅读更多 →
ARM架构深度解析:从RISC设计理念到交叉编译实战

ARM架构深度解析:从RISC设计理念到交叉编译实战

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

2026/10/9 10:11:06 阅读更多 →

月新闻

我发现了一个新思路:用 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/8 21:13:17 阅读更多 →
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/9 21:32:20 阅读更多 →
黑夜航拍船只数据集训练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/9 6:17:20 阅读更多 →