Wang的博客

起因是一个很具体的现象：桌面端的「归档」一直提示失败，换一条对话还是失败，重启也没用。 顺着这个问题查下去，发现真正有价值的东西不在「归档坏了」本身，而在于：一条对话在本地到底被存成了多少份、分散在多少个地方。把这张地图画清楚之后，归档失败的原因、为什么应用自带的「删除」删不干净、以及一个彻底删除的工具该怎么写，就都顺理成章了。 本文分两部分：前半部分是实测出来的本地存储结构，后半部分是据此写的清理工具。 文中的盘符、目录名、线程 ID 和对话标题均为脱敏示例，请替换成自己的实际值。 一、先确定「桌面端」是哪个程序这一点比想象中重要。OpenAI 现在有好几个同名或近名的客户端，路径也不一样： 形态 进程名 本地数据根 桌面客户端（ChatGPT + Codex 合一） ChatGPT.exe、codex.exe %USERPROFILE%\.codex VS Code 扩展 codex.exe 同样是 %USERPROFILE%\.codex 网页版 浏览器标签 不落本地会话，只有浏览器缓存 判断方法很直接： 12Get-Process | Wher...

功能说明博客助手运行在访客自己的浏览器中。首次启用时，页面会从 Hugging Face 下载 ONNX 模型，保存到当前博客来源的 Cache Storage，然后使用 WebGPU 或 WASM 在本地生成回答。 它可以检索本站文章、流式回答中文问题，并在回答下方附上原文链接。对话问题和生成过程不需要发送到博客服务端，但浏览器仍需联网下载页面资源、文章索引和模型文件。 这是一项实验功能。第一次使用前需要确认浏览器、磁盘空间和站点存储配置，首次下载通常需要较长时间。 下载量与运行模式当前使用的固定模型版本如下： 12模型：w10110/qwen3-0.6b-zh-blog-style-onnx版本：a41c0b941ee4ca797b1e750e683eb4ef36ea1992 页面提供两种运行模式： 模式 首次下载估算 浏览器要求 建议自定义配额 WebGPU 约 663 MB 支持 WebGPU，显卡支持 shader-f16 至少 700 MB，建议 800 MB WASM 兼容模式 约 765 MB 支持 WebAssembly 至少 850 MB，建...

前言这次给 Hexo Butterfly 博客增加了一个“博客助手”页面。它不是接入云端聊天接口，而是在访客浏览器中下载并运行 ONNX 模型，再从博客文章中检索相关段落，生成带原文引用的中文回答。 最终页面具备以下能力： 从顶部菜单进入独立的 /chat/ 页面； 只有进入对话页并主动点击启用后，才下载模型和启动 Worker； 优先使用 WebGPU，不满足条件时由访客手动切换到 WASM 兼容模式； 在浏览器中流式生成回答，可展开思考内容； 从本地 RAG 索引检索文章，并在回答后显示原文链接； 支持停止生成、重试、清空对话和本次会话恢复； 将模型文件保存到当前站点来源的 Cache Storage，后续访问优先复用。 页面看起来只是一个对话框，实际实现中最难处理的部分是大文件缓存、浏览器配额、WebGPU 精度和异步状态。本文聚焦页面设计、接入、调试和验证过程。 技术方案为什么使用独立页面最初可选方案有两个：在所有页面显示悬浮入口，或者在顶部菜单增加独立页面。最终选择独立页面，原因很直接： 模型首次下载约为数百 MB，需要完整展示下载、缓存和初始化状态； 对话、思考...

前言本文记录如何使用 Mender 建立一套“总部统一发布版本，各地区服务器主动获取并升级”的系统。 目标场景如下： 总部维护一个 Mender Server； 前端、后端等业务服务通过 Docker Compose 运行； 每个地区有一台或多台 Linux 服务器； 地区服务器只需要主动访问总部的 HTTPS 地址，不开放升级端口； 总部可以按地区分组、灰度发布、查看结果并停止异常批次； 发布制品必须经过签名，地区服务器拒绝未签名或被篡改的制品； 应用升级失败时能够回退容器版本； 涉及数据库变更时，由业务脚本完成备份、迁移和恢复。 本文重点介绍 Docker Compose 应用升级。Mender 的 A/B 根文件系统适合操作系统整体升级，但需要磁盘分区、bootloader 和系统镜像适配，不能通过安装一个客户端直接获得，文末会单独说明。 本文版本和环境Mender 的软件仓库、Chart 和命令会继续变化。本文固定以下示例环境，实际部署前应再次检查官方 Supported releases 页面。 项目 示例值 部署位置 Mender Serve...

使用 Codex 一段时间后，偶尔会遇到这样的情况：侧边栏还保留着一条对话，但点击后打不开；日志反复提示某个 rollout 文件不存在；重启 Codex 后，失效记录又重新出现。 这类问题通常不是项目代码损坏，而是本地索引还指向已经被移动或删除的对话记录文件。本文介绍一个 Python 清理脚本 cleanup_codex_orphan.py 的工作原理和使用方法。文中的盘符、目录名和线程 ID 均为脱敏示例，请替换成自己的实际值。 问题是怎么产生的Codex 本地状态大致分成两部分： SQLite 线程索引：默认位于 %USERPROFILE%\.codex\state_5.sqlite，保存线程 ID、标题和 rollout_path 等信息。 全局 JSON 索引：默认位于 %USERPROFILE%\.codex\.codex-global-state.json，保存侧边栏和客户端关联等状态。 当 SQLite 仍然保存着一条线程记录，但 rollout_path 指向的 JSONL 文件已经不存在时，就形成了“孤儿索引”。只删除 JSONL 文件本身并不能清理这些...

前言本文记录一次在 Windows 主机上使用 VMware Workstation 和 OC4VM 安装 macOS Sequoia 的完整过程。目标不是追求最新版本，而是在现有硬件和虚拟化软件下尽量兼顾系统版本、兼容性与可维护性。 本次实际环境如下： 项目 配置 宿主系统 Windows 11 25H2 CPU Intel，24 线程 VMware Workstation 17.6.4 build-24832109 引导方案 OC4VM 3.0.0 Intel 模板 客体系统 macOS Sequoia 15 虚拟机内存 8 GB 虚拟 CPU 2 核 系统盘 128 GiB 稀疏 VMDK 网络 NAT，e1000e 虚拟网卡 需要先说明两个边界： Apple 的软件许可将 macOS 的安装和虚拟化限制在 Apple 品牌硬件上，在普通 PC 上运行不属于官方许可与支持场景。 VMware Workstation 在普通 Windows PC 上也不正式支持 macOS 客体系统。即使安装成功，GPU/Metal...

项目背景在视频相关的科研课题中，找到数据只是第一步。真正耗时的工作通常是从长视频中定位画面清晰、动作明确、镜头连续的短片段，并把结果整理成后续实验能够直接使用的数据。 基于目前需求在AI协助下完成了下面的项目，这个项目围绕 Internet Archive 公开资源实现了一套完整处理流程：先采集动漫、动画、短剧等视频的元数据，再自动分析源视频，最终输出 2～15 秒有效片段的起止时间。程序不会批量保存最终视频片段，只保留元数据、原视频链接和时间戳，便于后续按需取用。 从技术路线来看，它不是单纯的爬虫，也不是端到端的模型训练项目，而是一个“数据采集 + 传统计算机视觉 + 本地多模态大模型”的混合系统。 整体架构 flowchart TD A[Internet Archive 搜索 API] --> B[获取候选视频标识] B --> C[Metadata API 获取文件与作品信息] C --> D[清洗、分类、去重] D --> E[导出 CSV / JSON 数据集] E --> F[按需...

什么是webhookWebhook 是一个 API 概念，是微服务 API 的使用范式之一，也被成为反向 API，即前端不主动发送请求，完全由后端推送; GtiHub中就存在这种功能，通过创建一个GitHub的webhook可以实现项目的自动部署，issues的自动推送等功能; 如何创建GitHub的webhook首先我们要了解它的工作流程： sequenceDiagram Github Webhook ->> API Service: 发送POST请求，带有特殊Header，以及payload API Service ->> Shell: 子进程启动对应脚本 API Service ->> Github Webhook: 返回200状态码，及其他自定义信息 编写webhook接口 flowchart LR A[校验是否是github发送的请求] -->|是| B[执行构建脚本] A --> |不是| C[返回UNAUTHORIZED] 此处以nest.js创建的接口为例 1234567891011...

远程搜索下拉框封装首先要有需求，需求驱使才能让我们打工人创造业务组件 需求分析我们平时做一些管理系统之类的应用时都需要一些关联搜索的下拉选择，所以就需要我们写很多下拉相关的业务组件 方案选择思路呢，我暂时就想得到以下几套方案： 所有的远程搜索下拉框都写一个组件 封装一个组件作为通用组件，通过props传参实现不同的搜索 首先分析第一个方案，每个远程搜索都写一个独立的组件。 优点：很明显不用考虑别的就实现输入和输出就完事了； 缺点：就是会制造大量的重复代码，以及很多组件出来； 第二个方案就是封装一个通用组件，不同的搜索传不同参数。 优点： 一个组件支撑某些情况下更改起来会相对便捷 通过配置项实现不同的搜索下拉减少功能重复的组件 缺点： 编写起来需要考虑很多情况，很多奇怪的搜索可能照顾不到 需要的props可能会相对较多 实现思路首先考虑远程搜索组件需要用到的必要的属性(element-plus的二次封装，所以它需要的属性以下不在过多赘述，会进行透传的) 这种组件实际需要的核心属性只包含以下几种： props 说明 类型 默认值 是否必传 mode...

Vue SchedulerVue中的Scheduler(任务调度系统)，主要责任就是收集Vue在程序执行过程中产生的Jobs(任务)，让每个Job按照固定的顺序执行，避免资源的浪费和程序中的循环依赖导致的死循环。 Vue Scheduler中的核心分为以下几个部分： 任务队列(queue、pendingPostFlushCbs、activePostFlushCbs) 任务入队程序(queueJob， queuePostFlushCb) 任务执行状态(isFlushing、isFlushPending) 当前正在执行的任务Promise(currentFlushPromise) 任务执行程序(flushJobs、flushPostFlushCbs、flushPreFlushCbs) 任务优先级调配程序(comparator) 源码位置：packages/runtime-core/src/scheduler.ts 任务队列在Vue Scheduler中的所有任务分为pre、普通任务、post三种显式优先级，以及根据id进行排序的隐式优先级(主要用...