六点刚过,楼下传来洒水车的音乐。那旋律是《世上只有妈妈好》,用电子琴音色循环播放,音量固定,速度也固定。它每天准时经过,水雾洒在路面上,音乐跟着水雾一起灌进临街的窗户。没人问过这条路两边的住户想不想在这个时间听这支曲子,也没人想过换一首。这个场景里藏着一个容易被忽略的事实:技术早就能做到让洒水车识别路段、调节水量,却没人去改一段音乐的播放逻辑。
技术从不缺能力,缺的是对细节的在意。洒水车的音乐播放器大概是最简单的那种芯片方案,成本几块钱,只能存一首曲子,按一个按键就开始循环。换曲子在工程上没有任何难度,加个光敏传感器让它天亮再响也毫无难度。可这些改动不会出现在采购清单上。供应商提供什么,采购方就接受什么,司机按一下开关,剩下的交给惯性。技术落地之后,往往就停在离人最近的那一步之前。
这让我想起很多类似的东西。公共厕所的自动冲水器,人还没站起来就哗地冲一次,站起来又冲一次。感应龙头的出水时间短到洗手要反复伸手。小区的门禁卡消磁了得跑三趟物业。这些设备都用了芯片、传感器、电磁阀,技术上属于自动化范畴,可它们的“自动”只是把某个动作交给机器,没有把人的实际使用节奏考虑进去。设计者可能从没在早晨六点被洒水车吵醒过,也没蹲在感应龙头前洗过手。
真正的技术改进常常发生在有人被吵到之后。有城市试过让洒水车在居民区路段关掉音乐,只闪灯。也有地方把音乐换成音量更低的提示音,或者干脆改成语音播报“正在洒水,请注意避让”。这些调整不需要新技术,只需要把现有技术的参数改一改。可就是这种改动,往往要等到投诉积累到一定程度才会发生。技术系统的默认值,通常是设计者凭想象设定的,而想象和现实之间有距离。
距离来自哪里?来自技术决策链条上的人离使用场景太远。芯片方案商在深圳的写字楼里写代码,他考虑的是稳定性和成本,不是某条街道的早高峰。采购人员在表格里填参数,关心的是价格和售后,不是音乐好不好听。司机只管开车,音乐是随车带的,他也没法改。每个环节都合理,合起来就产生了一辆在错误时间播放错误音乐的洒水车。技术越复杂,这种链条越长,默认值就越难被质疑。
要打破这种默认,得让改动的成本低到随手就能做。比如洒水车的音乐模块做成可插拔的,司机自己就能换。或者加一个简单的旋钮,调音量。再或者,把播放逻辑写进一个开源配置文件,谁都能改。这些做法在技术上都不新鲜,新鲜的是有人愿意把控制权放出去。技术不只是芯片和代码,还包括谁有权决定芯片和代码怎么运行。清晨那支曲子什么时候停,其实是一个权力问题,只不过它穿着技术的外衣。
