夜雨聆风我们之前测摄像头云台的转动噪音，有多少被MIC回采回来，一直是这么干的。把录像导出来，用手机或者电脑播，举着分贝仪对着喇叭，读个数。直到有天我盯着那个分贝仪，反应过来一个事：这测的也不是录像里的噪音啊，倒像是喇叭放出来的音量。
你换个手机，把音量开到最大，可能喇叭出来的音量也不一样，比较不同手机喇叭规格也不一样。还有分贝仪拿近两厘米、拿远两厘米，分贝数也不一样。哪台设备播、开多大声、举多远，全凭手感。两个人测同一台机器，能测出两个数。更让我没想到的是，我跟一圈做摄像头的牛马们聊这事，发现大家都在这么测。有的用电脑播，有的用手机播，有的干脆拿耳朵听一下感觉OK就说"还行"。标准没有，一致性看运气。
云台噪音这个东西直接影响用户体验，但我们连它到底有多吵（噪音程度），都测不准或者说都没有一个标准。后面我在想这问题极大概率是出在"外放再测"这一步。声音一旦从喇叭出来，就被设备污染了。那能不能不外放，直接分析录像文件里的音频本身（无视不同设备不同喇叭规格之间的影响）。音频在文件里就是一串数据，多大就是多大，不会随你怎么播、开多大声而变化。
有了这个思路，我觉得可以试一下。可我一个做硬件的，不会写代码，这可咋搞？刚好最近 vibe coding 很火，我就想，能不能跟 AI 说人话，让它帮我写，把需求啰里八嗦跟它对齐一遍：分析一段录像里的音频，自动找到云台转动那一段，给我一个噪音大小。然后一起捋了个简单的 PRD，定了个最小的 MVP，先能跑通再说。
开发之前我也想先把所有功能想全了再动手。后来发现根本想不全——很多问题、很多该有的功能，得等你实际跑起来后实际操作才会发现。所以不纠结了，先跑起来，测试的时候看哪里不爽改哪里，改到自己爽为止（不知道ai token 额度扛不扛得住，哈哈哈🤣）。
改改之后，第一版核心功能跑起来了：导进视频，能预览，能解析音频波形。但用着别扭。必须一个一个选中文件才解析出波形，解析出来还得手动去框振幅峰值。一个个的点、一个个去框，效率很低，还不如直接用Audition。
继续顺着用着别扭的地方改：把重复操作解决掉，加上多文件同时解析，给每个视频的预览窗口都配上音频波形。就这么来回磨，断断续续两个晚上。中间加了一堆东西：阈值判断设置、波形自适应显示、音视频时间轴对齐，测试结果一键导出功能等。也踩了不少的坑，4 分屏同时放，没事；一上 6 分屏，卡，崩，没响应，最后想了个折中办法：加一个低帧率预览模式，多文件同时分析的时候降一点资源占用，先把卡顿压下去。还有其他小的bug我都没看，直接让ai出方案修改。
最后工具做出来了。实现了单文件、多文件、整个文件夹导入；音视频能分开看，也能联动着看；波形能单独预览，峰值能手动框、也能自动框；测完一键导出数据等等各种功能，都是围绕核心MVP功能拓展出来的，就类似搭积木。
很多功能都不是一开始规划的，都是一边做一遍想到，再慢慢增加上来的。现在同一台机器，谁测、测几次，结果是一样的。因为测的是文件里的数据，不是外放的喇叭。
说两点我自己的感受：这个测试难题其实一直能解，以前要找软件同事排期，没人愿意为这种小事专门写工具。现在一个做硬件设计开发的，自己能把工具手搓出来，这个还是挺有意思的。
二来，AI 写的代码也不全信，里面肯定有我不懂的坑。但作为一个测试工具，能跑、能标准化，已经比举着分贝仪靠缘分强太多了。
如果你也在刚好要测什么东西，可以试试这个路子：把需求说清楚，让 AI 先给你跑个原型出来。你们遇到哪些重复性流程化的工作？可以试下AI是否能帮你实现一二？评论区聊聊。
