最近一段时间，我用 Vibe Coding 陆续做了一些小项目。

它们横跨了摄像头、实时字幕、HDR、移动影像、空间音频、NPU 和 CPU 微架构。虽然看起来有点杂，但出发点其实很一致：

行业里不是没有现成软件，而是很多功能要么没人做，要么藏得太深，要么宣传得很热闹，却很难知道它到底有没有在真正工作。

于是我就想，干脆自己做几个工具，把这些底层细节彻底弄清楚。

1. USB-Camera：让普通 USB 摄像头进入 HDR 工作流

---

市面上的 USB 摄像头软件，大多停留在“识别设备、预览画面、调整分辨率和帧率”这一步。

但如果摄像头输出的是 HLG 这种 HDR 信号，问题就复杂了：软件能不能正确接收？传输中会不会把 HDR 当成普通 SDR 丢弃细节？最终又该怎么接进直播和录制流程？

所以我做了 USB-Camera。除了基本的摄像头预览和参数控制，它核心支持 HLG 视频流的无损传输与显示，尽量保留高光、色彩和动态范围。同时，我写了一个 OBS 插件，让 USB 摄像头的 HLG 画面可以直接无缝接入 OBS 的内容生产流。

它和普通摄像头预览软件最大的不同在于：

- 关注传输格式：不仅是“能看到画面”，更关心画面以什么底层格式传输；

- 真 HDR 支持：完美适配 HLG 视频流；

- 直通生产力：面向 HDR 直播、录制和采集场景，通过 OBS 插件直接接入工作流。

2. OBS-FunASR-Captioner：用局域网闲置算力为 OBS 提供实时字幕

---

给 OBS 做实时字幕不是新需求，但现有方案通常有两条路：要么使用云端语音识别（涉及费用和隐私问题）；要么在本地运行识别（直接和直播编码、游戏推流争抢 CPU 或 GPU 算力）。

为了解决这个痛点，我把 FunASR 的中文语音识别能力接进了 OBS，并设计了一套 局域网分布式计算工作流。

它可以把语音识别任务甩给局域网里的另一台 PC 或 Mac：

- 各司其职：主电脑专心运行 OBS、编码和推流，保证帧率稳定；

- 分摊压力：另一台空闲电脑在后台默默负责语音识别，识别结果通过局域网实时返回并显示为字幕。

旧电脑、备用设备甚至 Mac，都可以成为字幕计算节点。对直播和录课场景来说，这比单纯在本机跑模型要实用得多。

3. HDRImageViewer：不止于查看，一个更完整的 HDR 图片转换与编辑工具

---

现在很多看图软件都宣称支持 HDR，但“能打开”并不等于“能正确显示”。HDR 图片涉及不同的格式、色彩空间、传递函数和元数据，常常打开后画面发灰、过曝，或者在后台被悄悄压成了 SDR。

所以我做了 HDRImageViewer。它不仅是一个查看器，更是一个围绕 HDR 图片处理的轻量工具箱：

- 精准显示：正确还原多种格式的真 HDR 图片；

- 格式转换与编辑：支持在不同 HDR 格式之间进行转换和编辑；

- 适配 Live Photo：支持查看和处理 HDR 动态照片（Live Photo）——这在现有的桌面工具里支持得并不完整。

我们的目的，就是把静态 HDR 图片、动态内容和 Live Photo 放入同一套清晰、无损的工作流中。

4. lens-app-prototype：一个更直观的等效光圈与进光量计算器

---

在影像领域，关于不同画幅、焦距和光圈之间的对比，经常陷入参数一样但实际效果不同的争论。比如同样是 F2.8：

- 放在不同尺寸的传感器上，实际进光量应该怎么比较？

- 手机宣传的大光圈，和相机镜头的大光圈是不是一回事？

- 不同镜头、焦段和画幅之间，谁的相对进光能力更强？

lens-app-prototype 就是为此设计的等效光圈计算器。

它抛开那些营销层面的宣传数字，直接通过底层的物理关系，将画幅、镜头参数和进光量拉到同一个公平的尺度进行对比。它不是为了评价谁能打败谁，而是希望给大伙提供一个清晰直观的数据参考。

5. check_audio_gui：探究 Android 空间音频的底层运行状态

---

Android 上的空间音频实现方案比较繁杂。不同品牌、系统版本甚至耳机，都有不同的处理方式：有的基于 Android 标准接口，有的采用厂商私有方案，还有的只是一个调整了 EQ 的音效开关。

普通用户打开“空间音频”或“沉浸声”后，很难判断系统底层到底发生了什么。

所以我写了 check_audio_gui，专门用来检测 Android 设备上的空间音频状态：

- 系统能力扫描：检测系统底层到底启用了什么音频能力；

- 真实性检测：验证设备是否真的支持空间音频，以及头部追踪有没有在实际工作；

- 链路监控：监控播放链路是否真正进入了空间渲染模式。

这个工具不评判音质好坏，只是为了回答一个基础问题：当你打开空间音频开关时，系统底下究竟有没有在工作？

6. NPU Check：检测 Android 手机上的 NPU 是否在实际中发挥作用

---

现在手机发布会几乎都会讲 AI、NPU 和多少 TOPS 的算力。但无论是对于用户还是开发者，很多时候都很难知道这些宣传背后的实际情况：

- 设备里到底是什么 NPU？

- Android 系统和应用能不能成功调用它？

- 你的 AI 任务究竟是运行在 NPU 上，还是悄悄甩给了 GPU 和 CPU？

所以我做了 NPU Check。

硬件信息软件通常只会告诉你“这里有一块 NPU”，而 NPU Check 则更想确认：“它在实际任务中到底有没有在工作？” 我们不看纸面参数，只通过实际运行状态来检验调用情况。

7. 快否 2.0：提供更直观、更具可读性的设备性能报告

---

传统的性能测试软件通常在测试结束后只给出一个综合分数，而这些数据往往容易被厂商的“针对性优化”所蒙蔽。
在 快否 2.0 中，我们依然关注测试结果的可读性()。但相比常规的手机测试软件，我们针对目前一些厂商习惯使用的“投机取巧”手段，新增了许多底层检测规则。比如：
- 有效刷新率：检测系统是否在后台悄悄限制、降低了实际物理刷新率（锁帧、锁刷新率）。
- 渲染分辨率：精准识别游戏或应用真实的渲染分辨率，避免被厂商的画质拉伸和插值算法所蒙蔽。
- 插帧检测：准确区分出哪些是 GPU 原生渲染的真实帧，哪些是通过独立显示芯片或算法“插”出来的虚拟帧。
跑分是过程，帮助用户理解设备的真实状态才是结果()。我希望它最后给人的感觉，不是一张堆满被修饰过的数据成绩单，而是一份能照出真实表现的设备性能体检报告()。

8. MicroArchBench：从微架构层面探究 CPU “为什么快”

---

Cinebench、Geekbench 这类工具很适合用来比较整体性能，但一个综合总分很难解释处理器内部微架构的特征。两颗总分接近的 CPU，内部可能完全不同：

- 缓存延迟存在差异；

- 内存访问和带宽能力不同；

- 指令吞吐、分支预测和执行管线的设计不同。

所以我写了 MicroArchBench。它更像是一个用来观察 CPU 内部特征的微观显微镜。