标签：开发运维

前沿哨所

• 嫌官方 App 不好用，开发者用 Claude 为 Ulanzi VibeKey 打造开源替代品

  一位 Ulanzi VibeKey 用户因不满官方 App 体积过大且不支持跳转 App，借助 Claude 进行 vibe coding，开发出一款名为 Open VibeKey 的第三方替代工具，并申请了 Apple 开发者账号，通过 Homebrew 发布，供其他 VibeKey 用户免费使用。Open VibeKey 的功能覆盖官方 App 的核心能力并有所扩展：用户可为按键、旋钮的左右旋转和按下动作自定义快捷键或媒体控制；可将按键或旋钮绑定为一键打开或切换指定 App；支持保存多套配置方案，并在菜单栏快速切换。在设备管理方面，该工具可调整设备灯光、麦克风开关、降噪模式和输入音量，还能在菜单栏切换 Mac 的音频输入设备并锁定常用输入。此外，它支持查看设备连接状态、电量和固件信息，并支持登录时自动启动。与官方 App 相比，Open VibeKey 的优势在于轻量化以及对 App 跳转等细节场景的支持。该项目从需求产生到实现均由开发者与 Claude 协作完成，是 AI 辅助编程在个人开发者日常工具开发中的一个典型案例，也为 VibeKey 用户提供了开源、可定制的软件新选择。

  事件分析

  这一案例折射出 AI 辅助编程对软件开发门槛的重塑。VibeKey 属于小众桌面硬件，官方软件迭代动力不足，过去用户只能忍受或放弃；如今借助大模型，个人开发者足以在短时间内完成一个功能完备的 macOS 原生应用。值得注意的是，项目还完成了 Apple 开发者签名与 Homebrew 分发，说明 AI 编程已覆盖从编码到打包发布的完整链路，而不仅是生成代码片段。此类’民间替代官方’的项目未来可能更频繁出现，倒逼硬件厂商开放通信协议与 API，或将官方软件插件化、开源化。对小众硬件生态而言，社区驱动软件有望成为官方工具的重要补充，甚至反向定义产品的使用场景与边界。

  核心观点：AI 编程让个人开发者具备了重写官方软件的能力，小众硬件的软件生态正悄然由社区接棒。

  原文链接：V2EX 分享发现

  刚刚

• 基于 MiniMax H3 Max 的在线工作台亮相：短视频音画一体生成

  V2EX 用户分享了一款名为 H3 Max Generator 的在线短视频生成工作台，该工具基于 MiniMax H3 Max 模型构建，完全运行在浏览器中，无需本地部署。工作台支持文生视频与图生视频两种生成方式，用户可通过设定首帧和尾帧来控制镜头过渡效果。其突出特点是支持在同一段提示词中同时描述画面、镜头、对白、环境声、音乐和音效，实现画面运动与声音设计的一体化生成。参数配置方面，提供 5 秒、10 秒、15 秒三种时长，480P 与 768P 两种分辨率，以及横屏、竖屏、方形等多种画面比例。开发者表示，做这个工作台的初衷是希望将画面运动和声音设计纳入同一个可反复迭代的流程，避免创作者在多个工具之间来回拼接。网站展示了多个测试示例，涵盖镜头跟拍、首尾帧过渡、人物连续性、同步声音、统一艺术风格和多步骤变形等场景，用于验证模型在不同创作任务中的表现。目前使用该工具生成视频需要登录账号并消耗 credits。开发者邀请用户体验，并希望收集关于运动稳定性、音画同步、提示词组织方式和整体工作流的反馈意见。

  事件分析

  该工作台的技术看点在于将音频生成与视频生成合并到单次提示词流程中，区别于业界常见的先出画面、后配音的两段式管线。首尾帧控制与多步骤变形能力指向镜头语言的可编程化，使视频生成从随机抽样向可控创作演进。从产业角度看，MiniMax 的视频模型正借助社区工具生态扩展应用面，第三方工作台的出现降低了试用门槛，也反映出模型厂商与开发者工具之间的互补关系。后续值得关注的方向包括更长时长的时序一致性、音画同步的精度上限，以及此类工作台能否沉淀出标准化的提示词组织规范。若 credits 消耗模式能够跑通，这类垂直整合的创作工作流可能成为 AIGC 工具落地的典型形态。

  核心观点：音画一体生成正在取代拼接式创作流程，把多模态输出收敛进单一可迭代工作流，是 AIGC 工具化的关键一步。

  原文链接：V2EX 分享发现

  3小时前

• 我把 40 个 Sublime 标签缩到 12 个，插件开源了

  

  我的 Sublime Text 经常开着一排临时标签。里面有命令、配置片段、会议记录和没想好该放哪里的草稿。它们越积越多，我又不敢随手关，因为未保存标签里可能藏着以后还要用的内容。

  我最后写了 Sublime Auto Archive。首次实测处理了 40 个标签：26 份内容写进 Obsidian Clippings，2 个已经保存且没有修改的文件直接关掉，最后留下 12 个常用标签。迁移错误和哈希错误都是 0。

  这个插件已经按 MIT 许可证开源。它不联网、不需要账号，也没有第三方 Python 依赖。

  

  为什么标签页一直关不掉

  问题通常不在标签数量，而在“我不知道关掉以后还能不能找回来”。已经保存到项目里的文件很好处理，未命名草稿和修改未保存的文件才让人犹豫。

  手动整理也很容易半途而废。你要给每个草稿起名、选择目录、保存，再回头关闭原标签。几十个标签摆在一起时，这件事很快就会被拖到下次。

  普通的自动关闭又太冒险。只要其中一次写盘失败、路径填错或同步盘状态异常，所谓的“整理”就可能变成数据丢失。

  Sublime Auto Archive 的核心价值很简单：只有确认归档内容和原文完全一致，它才关闭原标签。

  它具体会做什么

  插件在 Sublime Text 启动后等待 15 秒，只执行一次自动检查。它没有周期轮询，也不会每隔几分钟突然动你的标签页。

  默认策略会保护当前标签和最近使用的 8 个标签。当文本标签超过 12 个时，它从较旧的标签开始处理；超过设定天数、长期没有活动的标签也可以进入候选列表。

  不同标签有不同处理方式：

  • 未命名且内容为空：直接关闭，不生成空笔记；
  • 已保存且没有修改：原文件已经存在，只关闭标签并记录台账；
  • 未命名草稿或有未保存修改：把完整正文写入归档，校验成功后再关闭；
  • 写入或校验失败：保留原标签，并把错误写进本次运行结果。

  自动开关关闭后，预览和手动归档命令仍然能用。状态栏会显示 Sublime Archive: ON 或 Sublime Archive: OFF。

  为什么我没有做成定时清理器

  文本编辑器不是缓存目录。你正在输入时，后台任务不应该突然开始批量判断和关闭标签。

  启动后的单次检查更容易理解。你打开 Sublime，插件等窗口和 Package 加载稳定，再做一次收敛。之后的编辑过程不受打扰。确实想马上整理时，可以先预览，再手动执行。

  代码里的启动逻辑只有一次调度：

  def plugin_loaded():
      _update_all_statuses()
      _schedule_startup_check()
  
  def _schedule_startup_check():
      # Guarded so one Sublime session schedules only once.
      sublime.set_timeout_async(run_once, delay * 1000)
  

  回调执行后不会再次注册自己。_startup_check_scheduled 防止重复调度，_sweep_running 防止两次归档同时运行。

  安装 Sublime Auto Archive

  打开 Sublime Text 的 Preferences → Browse Packages…，在 Packages 下创建 SublimeAutoArchive 目录，并把仓库文件放进去。

  macOS 用户可以直接运行：

  git clone https://github.com/cfrs2005/sublime-auto-archive.git 
    "$HOME/Library/Application Support/Sublime Text/Packages/SublimeAutoArchive"
  

  安装后重启 Sublime Text。插件默认关闭，archive_root 和 ledger_root 也故意留空。没有完成配置时，它不会归档任何正文。

  配置归档目录

  打开 Command Palette，运行 Sublime Archive: Settings，写入自己的目录：

  {
    "enabled": true,
    "archive_root": "~/Documents/Obsidian/MyVault/Clippings",
    "ledger_root": "~/Library/Application Support/SublimeAutoArchive",
    "max_open_tabs": 12,
    "keep_recent_tabs": 8,
    "archive_after_days": 7,
    "startup_delay_seconds": 15
  }
  

  archive_root 存正文，适合指向 Obsidian 的 Clippings 或其他笔记目录。ledger_root 存运行台账，建议放在本机应用数据目录，不要和正文混在一起。

  归档文件按日期组织：

  <archive_root>/
  └── 2026-09-07/
      ├── 20260907-091500 - Project decision.md
      └── 20260907-091501 - Untitled note.md
  

  插件保存原始正文，不添加 frontmatter，也不改写格式。文件名会取正文第一行或原标签名，并过滤路径中不能使用的字符。

  第一次使用先预览

  打开 Command Palette，依次运行：

  1. Sublime Archive: Preview Old Tabs
  2. 检查窗口显示的总标签数、计划处理数和保留数
  3. Sublime Archive: Archive Old Tabs Now
  4. Sublime Archive: Open Last Archive

  同样的入口也能在 Tools → Sublime Archive 找到。确认目录和结果都符合预期后，再保持自动开关为 ON，让它在以后启动时做一次检查。

  “写完再关”是怎么实现的

  未保存正文进入 archive_content() 后，会走完一条固定链路：

  create temp file in target directory
    → write exact buffer content
    → flush + fsync
    → chmod 0600
    → atomic os.replace
    → reopen and read back
    → compare SHA-256
    → append manifest.jsonl
    → close original tab
  

  临时文件和目标文件位于同一目录，最终使用 os.replace() 原子替换。写入后，插件重新打开目标文件，读取完整正文并计算 SHA-256。只有读取结果与原始 buffer 的哈希一致，archive_content() 才会返回成功。

  关闭标签的动作发生在成功返回之后。任何异常都会进入 errors，源标签继续留在窗口里。目录权限会尽量设置为 0700，归档文件和台账文件为 0600。

  台账记录了什么

  每次落库会在 ledger_root/manifest.jsonl 追加一条记录，包括：

  • 归档时间、字节数和 SHA-256；
  • 原标签的安全化名称与语法类型；
  • 文件是否有未保存修改；
  • 正文在归档目录中的相对路径；
  • 是否检测到疑似 Token、密码或私钥内容。

  台账只保留安全化元数据。正则检测到敏感内容时，标题和来源字段会脱敏，不会把密钥抄进 JSONL。

  归档正文会原样保存。插件不会替你删除草稿里的密码、Token 或私钥。如果 archive_root 位于 iCloud、Dropbox、Git 仓库或团队同步盘，原文也会进入那个同步范围。请按自己的隐私要求选择目录。

  实际运行结果

  第一次整理时，Sublime 会话有 40 个 buffer，大约 23 万字符。插件归档了 26 份有内容的旧标签，关闭 2 个已保存文件，保留当前与最近标签，最终剩下 12 个。

  后续一次自动运行从 18 个标签收敛到 12 个，归档 6 份正文，错误列表为空。当前本机台账累计 32 条记录。这个数字不代表性能跑分，只说明插件在真实日常会话里持续按同一套规则工作。

  源码验证

  项目是纯 Python 插件，可以在没有 Sublime API 的环境测试归档核心和启动策略：

  python3 -m unittest discover -s tests -v
  python3 -m py_compile archive_core.py sublime_auto_archive.py
  

  发文前我重新运行了这两条命令。4 个测试全部通过，两个 Python 文件也能正常编译。GitHub Actions 在 Python 3.8 和 Python 3.12 下均为成功状态。

  测试覆盖原文写入与哈希、敏感元数据脱敏、Bearer/JWT/查询参数检测，以及“启动后只调度一次”。它没有假装能覆盖真实 Sublime 窗口行为，因此第一次安装仍应执行人工预览。

  这个小插件适合谁

  如果你把 Sublime 当作随手记录和临时编辑器，长期留着一排 untitled 标签，Sublime Auto Archive 会很合适。它也适合已经用 Obsidian，希望旧草稿自然进入 Clippings 的人。

  如果你的所有内容都严格保存在项目文件里，标签也不多，Sublime 自带的会话恢复已经足够。需要自动分类、加标签、生成摘要或跨设备知识整理的人，也应在归档完成后交给 Obsidian 或其他工具处理。

  这个项目的范围很窄。源码不长，规则能读懂，默认状态不会碰用户内容。它只给关闭旧标签这件事增加一份可以检查的确定性。

  查看 Sublime Auto Archive 源码 · v0.1.0 Release

  3小时前

• FoloToy Usage 上手：把 AI Passport 变成用量仪表盘

  

  FoloToy AI Passport 有一块 240 × 320 屏幕、三个实体按键和一颗 ESP32-C3。故事机固件之外，这套硬件也很适合做一块安静的桌面仪表。

  FoloToy Usage 会显示 Claude 和 Codex 的额度、重置倒计时、今日与累计 Token，以及 API 等价费用。它没有麦克风、TTS 或模型密钥，也不会把网页硬塞进小屏。整个界面按 240 × 320 的真实尺寸重新设计。

  

  为什么要把用量放在一块小屏上

  手机和浏览器都能查用量，但它们需要一次主动操作。拿起手机、解锁、找到页面，通常还会顺手被别的通知带走。

  小屏的价值来自“常驻”。它放在键盘边，额度接近上限、重置时间变化或数据变旧时，抬眼就能看到。它不会让工作流更复杂，也不负责替你做额度管理。

  FoloToy Usage 还保留了硬件本身的手感：

  • 上下键在额度页和用量页之间切换；
  • 额度页轻按确认键，在“已用”和“剩余”之间切换；
  • 长按确认键主动刷新；
  • 每分钟自动取数，重置倒计时在设备端持续更新。

  界面用红色区分 Claude、蓝色区分 Codex。首页保留头像、名称、日期和时间。数字使用独立等宽字体，中文标签使用 Noto Sans SC 子集，避免在 240 × 320 上缩成一团。

  谁适合用，谁不适合

  如果你已经有 FoloToy AI Passport，又经常同时使用 Claude Code 与 Codex，这个项目能把闲置硬件变成每天都看得见的工具。它也适合喜欢物理设备、希望用量信息离开主显示器的人。

  下面几种情况更适合直接使用 UsageHub 网页或 Android 版：

  • 你没有 AI Passport；
  • 你不想安装 ESP-IDF，也不想通过 USB 刷写固件；
  • 你希望同一套固件继续承担故事音频功能。FoloToy Usage 是独立固件，不包含故事机语音资源；
  • 你要一套完全自托管云端。仓库只公开设备固件，云服务需要另行实现兼容接口。

  它和 UsageHub Open 的关系

  FoloToy Usage 是显示端。电脑上的 Claude/Codex 数据仍由 UsageHub Open 采集器写入同一个工作空间。

  Claude / Codex on computer
            │
            ▼
  UsageHub Open collector
            │
            ▼
  UsageHub workspace
            │ read-only Display Token
            ▼
  FoloToy AI Passport
  

  设备通过 HTTPS 调用 GET /v1/dashboard。它先同步网络时间，再校验证书，不接受重定向。Wi-Fi 只能连局域网、不能访问 Internet 或 NTP 时，数据不会刷新。

  安装前要准备什么

  你需要：

  • 一台 FoloToy AI Passport；
  • 一根可传数据的 USB 线；
  • 2.4 GHz Wi-Fi，且能访问 Internet 和 NTP；
  • ESP-IDF 5.5.3；
  • UsageHub 的只读 Display Token，或一次性显示设备配对码。

  配置前关闭串口监视器，避免它占用设备端口。macOS 的端口通常类似 /dev/cu.usbmodem...，请以自己电脑实际显示的名称为准。

  第 1 步：获取源码并固定版本

  git clone https://github.com/cfrs2005/folotoy-usage.git
  cd folotoy-usage
  git checkout v0.1.0
  

  Release 同时提供通用固件、源码 ZIP 和 SHA256 校验文件。已有设备仍建议按仓库文档使用分段 idf.py flash，不要看到 full.bin 就整片覆盖。

  第 2 步：激活 ESP-IDF 并检查工程

  先安装 ESP-IDF 5.5.3，再激活环境。下面的路径只是示例：

  source /path/to/esp-idf/export.sh
  idf.py --version
  ./tools/validate.sh
  

  idf.py --version 应显示 ESP-IDF v5.5.3。校验脚本会执行公开内容审计、主机测试、固件构建和分区检查。

  项目保护三类硬件边界：应用镜像不能超过 3 MB；0x356000 的设备身份区要保留；0x700000 的 Recovery 和开机长按上键五秒的恢复入口也要保留。

  已有 AI Passport 不要运行 erase-flash。整片擦除会破坏设备身份和永久恢复固件。

  第 3 步：通过 USB 刷入

  把端口替换成你的设备端口：

  idf.py -p /dev/cu.YOUR_DEVICE flash
  

  这条命令按工程分区表写入需要更新的分区。刷入后不要急着打开串口监视器，下一步的配置工具还要使用同一个端口。

  第 4 步：写入 Wi-Fi 和显示凭据

  python tools/configure.py --port /dev/cu.YOUR_DEVICE
  

  工具会询问 2.4 GHz Wi-Fi，以及只读 Display Token 或一次性显示设备配对码。配对码要在 UsageHub 登录后创建。采集器接入码不能拿来给小屏配对。

  电脑会通过校验证书的 HTTPS 兑换一次性配对码，只有只读 Display Token 会写入设备。Wi-Fi 和 Token 保存在 NVS，不会编进源码或公开固件。

  如果想先连 Wi-Fi、稍后再配对，可以运行：

  python tools/configure.py --port /dev/cu.YOUR_DEVICE --wifi-only
  

  装好后怎么检查

  启动后先看额度页。Claude 和 Codex 各有 5 小时与 7 天数据、进度条和重置倒计时。按上下键切到用量页，确认今天和累计 Token 已出现，再试一次确认键刷新。

  缺失值应显示 --，不能伪装成 0。网络中断时，设备保留内存里的最后一份数据；超过三分钟或云端标记为旧数据时，屏幕会显示“数据较旧”。额度和 Token 各自判断新鲜度。

  需要保留验收证据时，可以通过 USB 获取设备实际渲染的像素块：

  python tools/screenshot.py --port /dev/cu.YOUR_DEVICE --output screen.png
  

  截图可能包含头像和真实用量，发到公开 Issue、博客或社交平台前要先脱敏。本文使用的是仓库已经处理过的示例图。

  头像同步是可选项

  默认固件不会编入个人头像或 Token。配对后可以用本机私有配置同步云端头像：

  python tools/sync_profile.py 
    --port /dev/cu.YOUR_DEVICE 
    --config device.local.json
  

  这个工具需要 Pillow 和 pyserial。它把头像缩到 40 像素后单独写入 NVS。device.local.json 含服务地址和只读 Token，不能提交到 Git。

  我重新跑过哪些检查

  发文前，我在 ESP-IDF 5.5.3 环境运行了 ./tools/validate.sh --static。公开内容审计检查了 60 个源码文件，没有发现构建产物或未脱敏敏感值；9 个主机测试和 Usage 数据模型测试全部通过。

  长期无人值守仍需单独验证。仓库当前明确写着：USB 刷入、云端加载、头像同步、真实屏幕渲染和多次切页已经检查；小程序实际安装和长时间稳定运行仍未完成验收。

  转让设备前别忘了清理

  设备的 NVS 目前没有加密。拿到 Flash 物理读取权限的人可能恢复 Wi-Fi 和只读 Display Token。转让设备前，要先在 UsageHub 撤销 Token，再清除 usage NVS 命名空间。不要上传整片 Flash 备份、NVS 镜像或串口日志。

  查看 FoloToy Usage 源码。项目使用 MIT 许可证，当前公开 Release 为 v0.1.0。

  3小时前

• 3 步装好 UsageHub Open：Claude + Codex 用量看板

  

  同时用 Claude Code 和 Codex 一段时间后，我总会碰到同一个问题：额度分散在不同入口，5 小时窗口和 7 天窗口的重置时间也不同。忙起来以后，我通常不是忘了看，就是等到任务跑不动才发现额度快见底。

  UsageHub Open 把这些数字放在一张常驻看板上。它不会帮你增加额度，也不会替你控制消费。它做的事很朴素：让你抬眼就知道 Claude 和 Codex 还剩多少、什么时候重置，以及本机累计用了多少 Token。

  

  我为什么做这块看板

  Claude 和 Codex 给出的官方额度信息各自都能查到，但它们不在同一个地方。Token 历史又是另一套口径。只靠浏览器标签页，我很难在工作过程中形成稳定的用量感知。

  我想要的是一块桌面仪表，不是另一套复杂后台。屏幕应该在两秒内回答四件事：

  • Claude 的 5 小时和 7 天用量是多少；
  • Codex 的短周期和周周期用量是多少；
  • 各窗口还要多久重置；
  • 今天及累计 Token 大约对应多少 API 费用。

  费用栏写的是“API 等价估算”。它按标准 API Token 价格折算本机历史，不是 Claude 或 ChatGPT 订阅账单，也不能拿来推算账户会被扣多少钱。

  为什么你会想用它

  UsageHub Open 比较适合同时重度使用 Claude Code 和 Codex 的人。你可能有一台闲置 Android 平板、墨水屏设备或横屏手机，希望它长期显示工作状态。你也可能只用网页端，但想把两个工具的额度放在同一页。

  它还有一个很实际的好处：采集端的代码、上传字段和接口契约都能审查。仓库公开了 Android 客户端、Claude/Codex 采集器、严格的数据结构，以及给 AI 编程代理读取的安装说明。

  下面几种情况不必折腾：

  • 你一周只偶尔用一次 Claude 或 Codex；
  • 你只想查某一次额度，官方页面已经够用；
  • 你要求把整套云服务部署在自己服务器上。当前开源范围不包含 SaaS、数据库、OAuth 和运维代码。

  数据是怎么走的

  数据链路没有读取聊天内容，也不需要把模型账号密码交给项目。

  Claude Code statusLine ─┐
                         ├─> local collector ─> UsageHub ─> Web / Android
  Codex local app-server ┘
  
  ccusage / ccusage-codex ─> local token history and API-equivalent cost
  

  Claude 额度来自 Claude Code 已公开的 statusLine 输入。Codex 额度来自本机只读的 account/rateLimits/read 调用。采集器会把原始数据裁成允许上传的数字字段，再加入随机生成的安装 ID。

  安装前准备

  普通用户需要：

  • 一台 Android 11 或更高版本的设备，或直接使用网页看板；
  • 一台正在使用 Claude Code / Codex 的电脑；
  • 一个可以在本机执行安装任务的可信 AI 编程代理；
  • 一个 UsageHub 账号。

  如果只看网页，不需要安装 APK。Android 版更适合放在桌面长期显示。

  第 1 步：安装 Android 显示端

  打开 UsageHub Open 最新 Release，下载 app-standard-release.apk 并安装。

  Standard 版是普通 Android 应用。它不会注册为系统 Home，也不会接管桌面。应用可以全屏、保持亮屏，并在自身位于前台时显示在锁屏上；PIN、图案或密码锁不会被绕过。

  以后升级也应继续使用 Release 中的签名 Standard APK。Debug 构建不是稳定升级通道。

  第 2 步：配对显示端

  登录 UsageHub，创建一个 10 分钟有效的显示设备配对码。打开 Android 应用的设置页并输入配对码。

  应用只兑换一次配对码，随后把只读 Display Token 保存在 Android Keystore 中。它只调用配对、看板和健康检查接口。配对完成后，屏幕已经能访问你的工作空间，但还要等电脑端采集器上传数据。

  第 3 步：让 AI 代理接入电脑

  在 UsageHub 网页打开“AI 接入”，给电脑起一个名字，点击“生成接入提示词”。把完整提示词交给运行在那台电脑上的可信 AI 编程代理。

  提示词包含一个 10 分钟有效、只能使用一次的接入码。代理会完成下面这些工作：

  • 检查 Node.js、ccusage 和 ccusage-codex；
  • 安装并构建开源采集器；
  • 保留你现有的 Claude 状态栏，再接入 UsageHub bridge；
  • 把 Codex 采集器注册为 macOS LaunchAgent 或 Linux user service；
  • 连续取样、上传并检查本地队列是否清空。

  接入结束后，代理应该只报告安装目录、后台服务状态、最近一次成功上传时间和验证结果。它不应在聊天中打印接入码或长期 Token。

  怎么确认真的装好了

  不要只看“服务正在运行”。我建议同时确认四个结果：

  1. 网页和 Android 都出现 Claude 与 Codex；
  2. 额度窗口有百分比和重置倒计时；
  3. 今日 / 累计 Token 能更新，费用旁边明确标注 API 等价估算；
  4. 数据没有显示为 stale，电脑端待上传队列为 0。

  某个平台暂时没有官方额度时，本地 Token 历史仍可以独立工作。采集器不会因为额度缺失就编一个 0%。

  想从源码构建

  仓库根目录需要 Node.js 22 或更高版本。Android Gradle 构建需要 Java 17。

  git clone https://github.com/cfrs2005/usagehub-open.git
  cd usagehub-open
  npm ci
  npm run check
  

  Android Standard 调试包可以这样构建：

  cd android
  ./gradlew testStandardDebugUnitTest lintStandardDebug assembleStandardDebug --no-daemon
  

  我在发文前重新跑了当前源码的 npm run check。18 个采集器测试和 9 个契约测试全部通过，TypeScript 构建通过，敏感信息扫描结果为 secret_scan=ok。

  隐私边界比功能更重要

  采集器只上传允许的数字用量字段和随机安装 ID。它不会上传提示词、对话、账号邮箱、工作目录、Cookie、OAuth 凭据或 Claude/Codex 的访问令牌。

  长期采集 Token 默认保存在 ~/.local/state/usagehub/ingest-token，文件权限只允许当前用户读取。一次性接入码过期后，应回网页重新生成，不要把长期 Token 复制到聊天里救急。

  查看 UsageHub Open 源码。当前开源许可证是 Apache-2.0，最新稳定 Release 为 v0.1.4。

  3小时前

• 开发者推出LLM评测基准浏览器：610个基准的构建与评分流程一站可视

  一位开发者在V2EX分享了自己制作的LLM/Agent评测基准浏览器项目，旨在解决为Agent挑选benchmark时需要在论文、代码仓库和数据集页面之间反复切换的问题。该项目名为LLM Benchmark Costco，目前收录了610个LLM和Agent评测基准。用户可按能力类别、年份、开放程度等条件筛选候选基准，查看中英文介绍以及论文和官方项目入口。工具的核心特色是用流程图分别展示数据构建和运行评测的完整过程，可展开查看分支、循环和各阶段说明，帮助使用者理解任务来源、Agent可见信息、可用工具及成功判定标准。以AutomationBench为例，打开构建流程页面即可看到跨应用任务、工具调用和终态评分的关联方式。整理后的说明还区分了公开任务、本地成绩和官方私有榜单的适用范围。该网页无需注册即可使用，定位为基准检索和协议理解工具；作者提示真正复现时仍应回到对应版本的原论文、数据和官方实现。作者承认内容可能存在遗漏或理解偏差，欢迎用户指出具体条目和来源位置，并邀请从事LLM/Agent评测的开发者以真实需求试用，反馈评测任务、查看条目及卡点信息。

  事件分析

  评测基准碎片化是Agent开发中的普遍痛点，基准信息散落在论文、代码仓库和数据集平台之间，缺乏统一的协议描述标准。该项目将数据构建与评分流程以流程图形式结构化呈现，本质上是在做基准元数据的标准化整理，此类工作此前多由社区以表格或文档形式零散维护。随着Agent应用落地加速，评测体系的重要性持续上升，Stanford HELM、Hugging Face等机构也推出过基准聚合平台，但多数侧重榜单排名而非协议细节。该工具将构建流程、观测空间与判定标准作为核心展示维度，切中了复现者的实际需求。后续走向可能取决于社区维护机制能否建立，基准数量增长与人工整理成本之间的矛盾能否解决，以及能否与主流自动化评测框架打通，这些因素将决定其长期价值。

  核心观点：Agent开发进入深水区后，评测基准的结构化整理正成为比榜单排名更稀缺的隐性基础设施。

  原文链接：V2EX 分享发现

  3小时前