6000 张图做 YOLO 辅助标注:一个大模型还是拆多个
数据集里 6000 张图,想训一个 YOLO 做预标注(不是最终部署)——是把所有类别塞一个模型,还是按大类拆多个?答案要看你的类别怎么分。 场景 1:类别相近 → 一个大模型 比如都是路面场景:person、car、bus、truck、traffic_light——目标形态接近、上下文相似,塞一个模型没问题: # data.yaml nc: 20 names: - person - car - bus - truck - traffic_light - ...优点:只维护一个模型 推理一次拿全部结果 6000 张图对 YOLOv8s / YOLO11s 一点都不多,一晚上跑完 类别之间可能有互相约束(比如"斑马线附近容易有 person"),单模型能学到场景 2:类别跨度大 → 拆多个模型 要标的东西差别巨大: 交通标志:限速 / 禁停 / 左转 / 右转 车辆:car / bus / truck 家具:chair / table / sofa三个域完全不同的时候,一个模型很容易顾此失彼——训到最后 mAP 只是 balance 出的中间值。每个域一个小模型:交通标志检测模型 车辆检测模型 家具检测模型优点:新加一个大类不用重训全部 小模型训练快、精度高 误检更少(不会拿"椅子"当"汽车")缺点:推理跑多个模型 管理麻烦(模型 → 类别 → 版本)场景 3:类别很多且分层 → 分级流水线 CVAT / LabelStudio 等专业标注平台常用的做法——粗定位 + 细分类: 一级:粗定位(找目标) │ ├─ person ├─ vehicle ├─ animal ├─ traffic_sign └─ building二级:细分类(每个粗类一个小模型) ├─ traffic_sign │ ├─ speed_limit │ ├─ stop │ ├─ turn_left │ └─ turn_right ├─ vehicle │ ├─ car / bus / truck / bike └─ ...粗模型只负责"找到候选框",细分类器(可以是分类模型不是检测)判定具体类别。这套结构对增加新细类特别友好——只改对应二级分类器就行。 配合 SAM 类分割模型:SAM 出 mask → YOLO 分类头判定 → 输出精细标注。这是当前自动标注前沿方案。 6000 张的容量参考YOLOv8n / YOLO11n:几百到几千张就能有效果,训练几十分钟 YOLOv8s / YOLO11s:6000 张的甜蜜点,训练 1-3 小时 YOLOv8m / YOLO11m:需要至少 1 万张才发挥优势 YOLOv8l / YOLOv8x:几万张起步6000 张选 s / m,别上 l 或 x——过拟合概率大。 类别不平衡怎么办 6000 张里可能某些类别几百张、某些类别几十张。方法:加数据增强:mixup、mosaic、hsv、rotation——Ultralytics 默认就开 加权采样:class_weights 让少数类被多次采样 合并罕见类:训不动的类临时合并成"其它",先跑通再迭代 cascade:稀有类先由粗模型定位,再单独训一个二分类判定辅助标注 vs 最终部署 辅助标注模型要求:Recall 优先(宁多勿少,人工再删) Precision 差点没事 速度不用极致最终部署模型要求:Precision + Recall 都要 速度 / 显存有约束 需要严格评测两者训练策略也不一样。辅助标注可以 confidence 阈值调低(比如 0.15),把所有可疑目标都框出来,让人复核。 推荐做法 如果类别 <= 30、都是相似的场景:一个 YOLOv8s / YOLO11s 模型,配合置信度 0.15-0.25 做辅助标注,人工审核补漏。 类别 >= 50 或者跨大类:每个大类一个模型,或者上"检测 + 分类"分级流水线。 一句话总结 类别相近 → 一个大模型;跨度大 → 拆多个;类别多且分层 → 检测 + 分类分级。辅助标注就调低 confidence 让人复核,比追求高 precision 更实用。
OpenCode Browser 扩展能做什么:与 Chrome DevTools MCP 的差异
两种方案的架构对比 OpenCode Browser(扩展方式) Chrome DevTools MCP(CDP 方式)OpenCode OpenCode ↓ ↓ Native Messaging MCP Server ↓ ↓ Chrome Extension Chrome DevTools Protocol (CDP) ↓ ↓ DOM / Tab 操作 完整 DevTools 能力OpenCode Browser 扩展连接方式更轻量,不需要打开 --remote-debugging-port,官方说明"No DevTools Protocol, no security prompts"。 OpenCode Browser 能做什么能力 支持导航(跳转 URL) ✅点击元素 ✅输入文本 ✅获取页面 DOM / 文本 ✅截图 ✅读取 <script> 标签内容 ✅读取 window.localStorage / sessionStorage 取决于扩展实现监听 Network 请求(XHR/fetch/WebSocket) ❌设置 JS 断点 ❌查看 Webpack/闭包内变量 ❌Memory Snapshot / Performance Profile ❌拦截/修改请求 ❌Chrome 扩展标准 API(chrome.scripting.executeScript)可以在页面上下文执行脚本,所以凡是挂在 window 上的对象(window.__NEXT_DATA__、window.__INITIAL_STATE__ 等)都可以读取。 但 webpack 闭包内的局部变量: ;(() => { const token = "abc123"; // ← 扩展拿不到这个 })();无论是 OpenCode Browser 还是普通扩展都无法直接访问,必须通过 DevTools Protocol 的 Runtime.evaluate 或断点能力才能拿到。 什么时候用 Chrome DevTools MCP 如果目标是:分析混淆 JS、逆向加密参数 Hook XHR / fetch / WebSocket 请求 查看 React/Vue 组件状态树 抓取动态签名、Token 设置断点、单步执行应该改用支持 CDP 的 MCP 方案,例如通过 --remote-debugging-port=9222 启动 Chrome,再连接 CDP: google-chrome --remote-debugging-port=9222 --user-data-dir=/tmp/debug-profile然后 MCP Server 通过 WebSocket 连接 ws://localhost:9222 调用 CDP 接口。 CDP 可以做到: Sources → 设置断点 Network → 查看所有请求/响应 Console → 执行任意 JS Memory → Heap Snapshot如果目标是指纹浏览器(Adspower 等) OpenCode Browser 扩展控制 Chrome 不能隐藏浏览器指纹(Canvas、WebGL、TLS、WebRTC 等),这些由浏览器本身决定。 需要多账号防关联的场景通常走另一条路: OpenCode / Playwright ↓ Adspower / MultiLogin 本地 API ↓ 指纹浏览器实例通过 Adspower 提供的 REST API 创建/启动指纹浏览器,再用 Playwright 连接其 CDP 端口操作页面。 小结 OpenCode Browser 扩展的定位是自动化操作真实浏览器(点击、填表、截图、爬内容),适合不需要深层 JS 调试的 RPA 和 AI Agent 场景。需要分析 JS 执行过程或拦截网络请求时,应切换到 CDP 方案。
TrickyStore 替代方案:2026 年 Android Root 通过 Play Integrity 的主流组合
背景 TrickyStore 的核心功能是:劫持 Android KeyStore,注入 Keybox,伪造 TEE 硬件证明(Hardware Attestation),让 Play Integrity 拿到 MEETS_STRONG_INTEGRITY。 2026 年 Google 大规模推进 RKP(Remote Key Provisioning),设备 Keybox 越来越多通过远程下发,公开泄露的 Keybox 被大量封禁,TrickyStore 的有效性明显下降。 主流替代方案对比方案 用途 推荐度Play Integrity Fork Device / Basic Integrity 修复 ⭐⭐⭐⭐⭐ReZygisk 替代原生 Zygisk ⭐⭐⭐⭐Shamiko Root 痕迹隐藏 ⭐⭐⭐⭐HMA-OSS(Hide My Applist) 隐藏 Root、LSPosed、模块列表 ⭐⭐⭐⭐KernelSU Next + SUSFS Kernel 级隐藏,最难检测 ⭐⭐⭐⭐⭐TrickyStore Strong Integrity / TEE 硬件证明 ⭐⭐⭐(RKP 影响下效果变弱)各场景推荐组合 银行 App(不要求 Strong Integrity) Play Integrity Fork + HMA-OSS + ReZygisk很多银行只要求 DEVICE_INTEGRITY,更多是检测:Root 文件、Bootloader 状态、Magisk/LSPosed 痕迹、可疑 App 列表。HMA-OSS 可以对指定 App 隐藏已安装列表,避免被扫描到 Root 工具。 Google Wallet Google Wallet 目前仍需要 STRONG_INTEGRITY,TrickyStore 仍然是成功率最高的方案,没有更好的替代: TrickyStore + Play Integrity ForkKeybox 失效后需要更换有效的私有 Keybox,公开 Keybox 已不可靠。 游戏(Pokemon GO、吃鸡等) 游戏越来越少单纯依赖 Play Integrity,更多依赖自己的反作弊检测: KernelSU Next + SUSFS + HMA-OSSSUSFS 在内核层隐藏 /proc、/sys 特征,比用户空间隐藏更彻底,是目前社区反作弊对抗的主流选择。 完全放弃 TrickyStore 的通用方案 KernelSU Next + SUSFS + ReZygisk + Play Integrity Fork对绝大部分银行 App 和普通应用可以通过 BASIC + DEVICE Integrity,已经够用。 Magisk 体系 vs KernelSU 体系维度 Magisk 体系 KernelSU 体系方式 修改 boot.img 内核模块隐藏难度 中(用户空间检测较容易发现) 高(内核层操作更底层)兼容性 广(绝大多数设备) 需要设备支持 KMI 或自编译内核Zygisk 原生支持 需 ReZygiskSUSFS 支持 有 susfs4magisk,但效果弱于 KernelSU 原生支持,效果最好重要说明 银行 App 实际检测逻辑通常不只看 Play Integrity,还包括:/proc/mounts 是否有可疑挂载 系统分区是否有异常文件 可疑进程名(magiskd、zygote64d 等) 已安装 App 列表(通过 PackageManager)即使 Play Integrity 全部通过,Root 痕迹未隐藏干净仍可能被识别。HMA-OSS 对目标 App 可以精确控制可见的应用列表,是隐藏 Root 工具的关键一步。
NVM 安装与配置:macOS/Linux 和 Windows 环境变量设置,npm 找不到的排查
macOS / Linux 配置 安装 nvm 后,需要在 Shell 配置文件中初始化脚本,否则每次新开终端都找不到 nvm 命令。 在 ~/.zshrc(zsh)或 ~/.bashrc(bash)末尾添加: export NVM_DIR="$HOME/.nvm" [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" [ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"重新加载: source ~/.zshrc # 或 source ~/.bashrc验证: nvm -vWindows(nvm-windows)配置 nvm-windows 安装后需要两个系统环境变量: NVM_HOME=C:\Users\<用户名>\AppData\Roaming\nvm NVM_SYMLINK=C:\Program Files\nodejs并在 Path 中加入: %NVM_HOME% %NVM_SYMLINK%验证(重开终端后): nvm version node -v npm -v查看当前配置: nvm root # nvm 安装目录 where nvm # 命令位置常用命令 # 安装指定版本 nvm install 22 nvm install 20.11.0# 查看已安装版本 nvm list# 切换版本 nvm use 22# 设置默认版本(新终端自动激活) nvm alias default 22# 查看当前使用的版本 nvm current node -vnpm 找不到的排查 原因一:还没安装 Node nvm list # 如果为空,先 install nvm install 22 nvm use 22原因二:版本未激活 nvm current # 输出 none 或系统版本 nvm use 22原因三:没有设置 default alias 新开终端后 nvm 不会自动激活任何版本: nvm alias default 22设置后新终端自动使用该版本。 原因四:Windows PATH 配置错误 where node where npm echo %NVM_SYMLINK%如果 where node 返回空或旧路径,检查 NVM_SYMLINK 是否指向 nvm 创建的 nodejs 符号链接目录,并确认 %NVM_SYMLINK% 在 PATH 中。 项目级 Node 版本锁定 在项目根目录创建 .nvmrc: 22进入目录后执行: nvm use # 自动读取 .nvmrc 切换版本配合 .nvmrc 可以保证团队成员使用相同的 Node 版本。
NVM 环境配置与 npm 找不到的排查
macOS / Linux 上配 nvm 先确认 nvm 安装位置: echo $NVM_DIR通常是 ~/.nvm。在 ~/.zshrc(zsh)或 ~/.bashrc(bash)末尾加: export NVM_DIR="$HOME/.nvm" [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" [ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"生效并验证: source ~/.zshrc nvm -vWindows 上配 nvm-windows 先看 nvm 目录: nvm root通常输出: C:\Users\<你>\AppData\Roaming\nvm系统环境变量里加两条: NVM_HOME = C:\Users\<你>\AppData\Roaming\nvm NVM_SYMLINK = C:\Program Files\nodejs再把 Path 里追加: %NVM_HOME% %NVM_SYMLINK%新开一个 CMD 窗口,验证: nvm version node -v npm -v常用命令速查 nvm install 22 # 装 Node 22 nvm list # 已装版本 nvm use 22 # 切换版本 nvm alias default 22 # 设默认(macOS/Linux) nvm current # 当前使用版本which node 有输出,但 npm not found 碰到这种情况: $ which node /Users/you/.nvm/versions/node/v22.21.1/bin/node$ which npm npm not found有六种可能,从概率高到低排: 1. 只装了 nvm 没装 Node nvm list # 一片空 nvm install 22 nvm use 222. 版本没激活 nvm current # 显示 none / N/A nvm use 223. PATH 没指向当前 Node echo $PATH # 看有没有 .nvm/versions/node/v22.x.x/bin4. Node 目录里 npm 文件真的没了 ls -lah /Users/you/.nvm/versions/node/v22.21.1/bin/正常应该有 node、npm、npx、corepack。只有 node 说明安装被中断过,重装: nvm uninstall 22 nvm install 225. Windows:nvm-windows 软链坏了(最常见) dir "C:\Program Files\nodejs"看到目录是空的或者链接指向失效版本,重新 nvm use: nvm use 22.19.0之后 where node / where npm 都会有结果。 6. Homebrew 装的 nvm 没加载环境 nvm use default # 或 nvm install --lts一句话总结 nvm 有问题时按这个顺序自检:nvm list → nvm current → which node / which npm → 检查 bin 目录是否完整。95% 的问题都是"没 use 版本"或"软链坏了"。
