【AI前沿】AI 助力改造非智能升降桌：智能升降、语音控制、多端联动……

2026-08-25 来源：大出海网采编

2026年08月24日49 分钟阅读AI 助力改造非智能升降桌：智能升降、语音控制、多端联动……主作者关注dong4j新手上路dong4j关注dong4j新手上路联合作者关注dong4j新手上路dong4j关注dong4j新手上路49 分钟阅读微信扫码分享以图片分享分享到微博点击下方按钮可复制链接分享收藏举报利益相关声明：作者与文中产品有直接的利益相关（开发者、自家产品等）注：本文在提纲整理、技术段落润色和代码摘录整理等环节使用了 AI 辅助拆板、逻辑分析仪抓包、I²C 时序、上拉电阻排查、软件 I²C 失败统计、ToF 读数和多端接入，则来自作者真机实验成稿时已核对文中键码、7-bit 地址、上拉阻值、传感器型号和开源仓库链接；笔者已核对所有文本表述，并修改不便于理解的描述文中的 Desk Gateway 是我自己维护的开源项目（MIT），没有商业赞助升降桌改造存在夹伤风险，文里的童锁和 ToF 保护不能替代原厂安全认证；紧急情况请用 STOP、原厂面板或直接断电背景早在 2019 年搬入新家之后，我就一直在迭代优化办公桌，现在应该是 V3 版本了：这个桌子从搬入新家就一直陪伴着我，它承载了太多太多——是的，就是字面上的意思：后来因为工作原因，我有点轻微腰椎间盘突出，所以决定给它换一个「躯干」，但桌板还是用的原来的（毕竟好一点的升降桌都要 3000+）。最终我选择了一款非智能的双电机版本，升降范围 64~129 cm。我确信凭借自己对硬件的热爱，可以很容易将其改装成智能控制，但可能也是因为对自己的技术过于自信，这个想法拖到最近才得以实现。一方面因为有充足的时间了，二则是因为有了 AI 的加持。升降桌的基本情况我的升降桌之前只能通过原厂控制面板操作，面板上有上升、下降和四个档位键：有时候会出现 B12 错误码，不过同时按住上下键 5 秒就能重置。我最初想增加一个旋钮，顺时针旋转升高，逆时针旋转降低，按下旋钮停止。动手前，我看了少数派的《从零开始，改造一张可以用 Siri 控制的升降桌》，也研究了开源项目Upsy Desky，它们使用的通信协议和我的升降桌不同，我需要重新分析原厂控制面板与控制盒之间的通信。除了旋钮，我还准备接入键盘、手机、Web、手表和语音控制。ESP32-S3 负责接收这些入口的指令，再按照原厂协议控制升降桌。后来我又接入了小智 AI：一块 JC3636W518C，放在桌上作为语音终端。如果你和我的控制面板一样，那大概率是可以复刻的。不过我还是建议你最好拆开面板看一下，看看控制面板的线序、网线的线序是否与我的一致。如果不一样可能就需要使用逻辑分析仪来抓包分析原始数据了。只要能通过 ESP32-S3 发送正确的指令控制升降，那多端接入就非常简单了。改造目标与方案选择原厂控制面板的使用局限如上面所说，原厂控制面板有上升、下降和四个档位键。单击档位键可以移动到保存的高度，长按会覆盖对应档位。每次操作都需要使用安装在桌边的控制面板。目前最大的问题是没有童锁功能，家里的小孩儿觉得好玩儿，经常趁我不注意按着玩儿，有一次离家之前将升降桌设置到了最高位置，正好超过了椅子的高度，不知道是不是老人的安全意识不够，把孩子抱起来按了档位 1，椅子抵住了桌面差点把桌子顶翻（这也是一个局限的点，没有障碍检测）。所以我老早就决定改造成智能升降桌，而且必须加上童锁功能。契机则是一个 zFrontier 的上的一个旋钮控制方案。从旋钮控制扩展到多终端接入玩儿客制化键盘的都知道 zFrontier，我没事就会在 ZF 上逛逛。正好看到Serendipity Dial，我觉得它的可定制化功能非常多，正好我桌面上有 2 个旋钮设备，想着是不是可以通过旋钮来控制升降桌。然后就是上面提到的《从零开始，改造一张可以用 Siri 控制的升降桌》并了解到了Upsy Desky这个开源项目，脑海中逐渐有了可落地的方案：这套架构的核心是 ESP32-S3，它当控制中枢，北向对接 App、手表、键盘、旋钮这类控制端，设备只发统一指令，不需要处理原厂协议；南向对接升降桌控制盒，由 ESP32-S3 把这些指令翻译成控制盒能识别的键码，桌子才会动。借助 ESP32-S3 内置的 Wi-Fi 和蓝牙通信，我们可以集成多种控制入口。硬件架构如下：整套方案里最关键的是如何拿到原厂控制盒认的那套指令。当前分层和硬件拓扑记在仓库的架构总览里。现有开源方案的适配限制少数派的 Siri 升降桌改造和 Upsy Desky，思路都是在控制盒与面板之间加一块控制模块，这点和我后来做的网关接近。但升降桌面板没有统一协议，品牌不同、批次不同，通信方式都可能不一样。我把这两份方案对照自己的桌子看过之后，发现都不适配。Upsy Desky 支持的控制盒和我的不是一种，我的原厂面板用 RJ45 插头只引出四根线，线序、协议和按键数据都得自己确认，然后用 ESP32-S3 模拟原厂控制面板和控制盒通信。原厂控制面板拆解与总线识别RJ45 接口与四线定义原厂面板通过 RJ45 插头与控制盒连接。拆开面板后，电路板背面有四个测试点，标记分别为GND（接地）、CLK（时钟信号）、DAT（传输数据）和3.3V（电源）：TM1650 芯片与总线类型判断原厂面板使用 TM1650 驱动数码管，结合CLK和DAT两个测试点，初步判断面板与控制盒之间使用 I²C 通信。芯片型号还不能确定完整协议。只能继续通过总线抓包确认主从关系、设备地址、按键编码和高度数据。逻辑分析仪接线与采样参数调整抓包时，原厂面板保持与控制盒连接，逻辑分析仪接入GND、CLK和DAT三个测试点。分析仪不连接面板的 3.3V，也不参与供电。我最初把采样率设为 20 kHz，只能看到电平变化，无法解码完整数据。把采样率提高到 12 MHz 后，PulseView 可以稳定识别地址和数据。我分别采集了静置、按住上升、按住下降、单击档位和长按保存的数据。采集高度数据时，我让桌子从 64 cm 升到 129 cm，同时记录面板显示的高度，方便后续对照。抓包步骤见逻辑分析仪抓包。SDA 对应 DATSCL 对应 CLK然后将协议修改为 I²C 后就可以正常读取I²C 通信机制与协议解析物理上我们只有一对CLK/DAT，TM1650 用不同从机地址拆成两条通道：控制盒读0x24问现在按了哪颗键，写0x34到0x37刷数码管；PulseView 显示的是 7-bit 地址；TM1650 手册常用 8-bit 写地址，0x24就是手册里的0x48，0x34就是0x68。完整键码、时序和抓包索引在协议逆向笔记。I²C 主从关系与周期轮询通过抓包，我们可以确认：控制盒是 I²C Master，原厂面板是 Slave时钟由控制盒产生，SCL 大约 9.6 kHz面板不主动上报，只在被问到时把当前键态放上总线。另外静置时总线不是空闲的。控制盒大约每 3.7 毫秒做一轮完整问答：先往0x24写一字节DW=0x01，再读一字节DR。DW实测一直是0x01，像显示控制 / 亮度一类的寄存器，键态不在这里。键码在DR里。静置时DR是0x2E。这张图是静置总览，写0x01和读0x2E一直在交替：这一轮写和读是分开的两笔事务，中间各有一次 STOP，一次完整轮询是：S Address write 0x24 ACK Data write 0x01 ACK P 约 29 us S Address read 0x24 ACK Data read 0x2E ACK P 约 95 us 后再开下一轮读完那一字节之后，控制盒用的是 ACK 再 STOP，不是常见的 NACK 再 STOP。后面用 ESP32 去复放面板侧时序，就是卡在这一点上。这张图是单次读写放大：持续返回上升或下降键码时，桌子保持运动；改回0x2E后停止。控桌的本质是改 Slave 每次被读时交出的DR，不是往总线上塞一条「升桌命令帧」。升降、停止与档位指令解析对比静置、按住上升、按住下降的抓包：DW始终0x01，变的只有DR。操作DR说明空闲、松手0x2E必须一直回这个，不要静默不应答按住上升0x47要升多久就回多久按住下降0x4F要降多久就回多久档位 1 单击0x17前往已保存高度档位 1 长按保存0x570x17加上 bit6（0x40）档位 4 单击0x2F前往已保存高度档位 4 长按保存0x6F0x2F加上 bit6上升和下降只差 bit3（0x47 ⊕ 0x4F = 0x08）。档位短码和长按差的是 bit6，事务骨架不变。另外，档位 2 和档位 3 暂时没有抓包，因为我现在常用的只有档位 1 和档位 4，后续可以通过高度传感器来处理多档位问题。同时按住上和下大约 5 秒，原厂可以清 B12。抓包里对应DR=0x7F，有效区间大约 7.5 秒，结束后必须回到0x2E。数码管高度数据解析高度不在0x24的DR里。按住上升时DR一直是0x47，不会跟着厘米数往上爬。我最初在键通道里搜 64、102 这种字面量，找不到，还把写往0x34至0x37的帧当成电机干扰滤掉了。拆板确认 U2 是 TM1650 之后，这些地址对上了手册里的 digit 寄存器（8-bit0x68 / 0x6A / 0x6C / 0x6E）。控制盒一边读键，一边把七段段码写到数码管。面板自己没有高度 MCU，总线上的高度是显示镜像，整数厘米。逻辑位7-bit显示DIG10x34百位，两位高度时常写0x00消隐DIG20x35十位DIG30x36个位DIG40x37第四位；静止时常等于 DIG3总线写序多数是 DIG3 → DIG2 → DIG1 → DIG4，组装高度要按逻辑编号，不能按时间顺序当百、十、个。长按保存档位 1 / 4 的静置帧里，四元组精确重复，段码不变：AW:36 DW:C5 / AW:35 DW:DB / AW:34 DW:00 / AW:37 DW:C5 → 64 cm AW:36 DW:9E / AW:35 DW:5F / AW:34 DW:44 / AW:37 DW:9E → 102 cm对照 TM1650 段码表，还能还原出 82、121。静态大约每 2 到 3 秒刷一整帧；运动中更密。ESP32-S3 控制链路验证拿到了指令数据，就可以开始使用 ESP32-S3 来模拟指令实现升降桌控制了：控制盒通过 RJ45 接口和控制面板连接，如果需要使用 ESP32-S3 来下发控制指令的话，需要一个 RJ45 模块。这里我买的是独立的双口 RJ45 模块，左侧接口通过网线连接到升降桌的控制盒，进而使用 ESP32-S3 下发指令来控制升降桌，右口是连接原厂控制面板，意思是保留原厂控制面板的控制功能，不过这里需要 ESP32-S3 来透传指令。ESP32-S3 模拟原厂控制面板我把 ESP32-S3 配置成地址0x24的 I²C Slave，用它替代原厂面板响应控制盒。Web 页面按住上升时返回0x47，松手时返回0x2E；下降操作返回0x4F。控桌不是 ESP32 主动发一条「升桌帧」，而是控制盒每大约 3.7 ms 来读一次，Slave 把当前键码交出去。固件在mxtark.c里大致是这样：#define ADDR_KEY_7BIT 0x24u #define DR_IDLE 0x2Eu #define DR_UP 0x47u #define DR_DOWN 0x4Fu i2c_slave_config_t cfg = { .i2c_port = I2C_NUM_0, .scl_io_num = GPIO_NUM_4, /* CLK / .sda_io_num = GPIO_NUM_5, / DAT */ .slave_addr = ADDR_KEY_7BIT, .addr_bit_len = I2C_ADDR_BIT_LEN_7, .send_buf_depth

By 大出海网采编

【AI前沿】派评 | 近期值得关注的 App

2026-08-25 来源：大出海网采编

2026年08月24日18 分钟阅读派评 | 近期值得关注的 App主作者关注少数派编辑部少数派成员少数派编辑部官方账号。少数派编辑部关注少数派编辑部少数派成员少数派编辑部官方账号。联合作者关注Vanilla少数派作者Vanilla关注Vanilla少数派作者关注ElijahLee少数派作者ElijahLee关注ElijahLee少数派作者关注大大大K少数派作者大大大K关注大大大K少数派作者关注Peggy_少数派作者Peggy_关注Peggy_少数派作者关注化学心情下2少数派作者化学心情下2关注化学心情下2少数派作者关注Snow少数派作者Snow关注Snow少数派作者少数派编辑部等 7 位作者18 分钟阅读微信扫码分享以图片分享分享到微博点击下方按钮可复制链接分享收藏举报欢迎收看本期《派评》。你可以通过文章目录快速跳转到你感兴趣的内容。如果发现了其它感兴趣的 App 或者关注的话题，也欢迎在评论区和我们讨论。Motrix 2.0：3 年后，「白月光」下载器更新了平台：macOS / Windows / Linux关键词：下载器@Snow：在几年之前，Motrix 大概是可以被列入 macOS 装机必备清单的应用。它没有扰人的广告、没有骇人的劫持、没有烦人的资源占用，凭借 aria2 多协议、多线程下载能力以及简洁易上手的 UI 设计，Motrix 一度成为不少用户心中的「白月光」下载器。不过自上架起，Motrix 的更新就算不上积极，大多每年更新一个小版本，1.8.19 版本后更是停更长达 3 年之久，以至于社区同好们都坐不住了，纷纷开发出了 Motrix Next、imfile 等衍生应用。加上近些年，网盘逐渐接管了普通用户的大文件传输需求，常规下载工具的存在感越来越低，就当大家快遗忘了这款应用时，开发者仿佛被人「夺舍」一般，在一周之内疯狂迭代十几版，而且不同于以往的小修小补，这次是实实在在从底层重新构建的 2.0 大版本更新。开发者为 Motrix 2.0 起了一个新名字 Motrix Turbo，使用 Electron、React 和 TypeScript 重写，这其中最突出的变化就是把下载核心与用户界面「拆散」了。这意味着 Motrix 不再只是一个运行桌面端的下载应用，同一套下载能力完全可以独立运行在没有桌面环境的服务器上。Motrix 2.0 首先引人注目的是直观的 UI 更新。全新的仪表盘由自定义卡片构成，你可以点击右上角的编辑按钮，调整卡片的展示和尺寸，不仅支持查看各项下载进程，还可以快速核查引擎状态、调整限速模式以及开关 UPnP 端口映射等。相比过去打开 Motrix 后直接面对堆砌的任务列表，新版仪表盘可以帮你更直观且高效地掌控下载时的资源调度。原本藏在设置中的自定义 Trackers 获得了独立页面，你可以在这里快速订阅或屏蔽 Trackers 列表，并随时查看各个 Tracker 是否可用、屏蔽规则是否生效，管理上直观不少。新版还加入了扩展生态，Motrix 目前提供了 3 款官方扩展，分别是文件名模板、网页内容提取和 URL 解析，后续你可以在应用官网的扩展商店或开源社区下载更多扩展，对于一个重新活跃起来的开源项目来说，这或许比单纯增加几个功能更有价值，如果哪天开发者又「神隐」了，社区大神们说不定还能借助扩展为它助力。下载能力当然还是 Motrix 的核心，2.0 这次将重点放在了「断点续传」上。新版重新整理了下载核心，并加入任务恢复机制，无论是意外锁屏导致下载中断，还是退出应用重新打开，2.0 不会再像 1.x 那样完全摆烂，而是争取找回之前的下载任务，继续未完成的工作。不过，Motrix 恢复成功与否很大程度上取决于下载服务器是否允许续传，像网盘或是临时下载链接你还是别指望它有什么黑科技可以「续命」。对于「动手能力」更强的用户来说，真正 Turbo 的地方，是下载核心可以单拎出来用了。新版提供了 Headless Server，可以通过 Node.js 或 Docker 部署到家庭 NAS 或云端服务器上。你不用再为了维持下载的进程一直开着电脑，也不用担心转移场地会影响下载进程，直接让 NAS 这样常年运作的「牛马」承担下载任务即可，你可以通过 Web 页面随时随地添加下载、查看任务以及管理下载文件。如果还想进一步折腾，2.0 版还提供了新的命令行工具，你可以通过 motrix add 等命令远程操作任意一台搭载 Motrix 2.0 的设备处理下载任务。这套 CLI 还专门为 AI Agent 留出了调用入口，配置完成后你可以让 AI 根据你的要求找到下载地址后，通过命令行直接把任务交给 NAS 执行，串起一套更高效的自动化流程。Motrix 2.0 目前仍处于测试阶段，安装前请备份现有 Motrix 应用数据与下载文件。你可以在应用官网或GitHub项目页免费下载 2.0 beta 版。11WebToApp：在手机上把网页变成 App平台：Android关键词：网页封装@大大大K：不知道从什么时候开始，手机 App 动辄就飙升到几个 G，占用内存不说，实际上里面很多功能我们根本用不到。其实我们常用的工具站、社交网络等，其网页端本身就已经足够干净好用，只是用浏览器访问时标签一多就容易混乱，即使使用「添加至主屏幕」功能，本质上还是调用浏览器打开，如果网站还不支持 PWA，那体验真不算好。那为什么我们不直接把这些常用网页服务做成一个独立的 App 呢？说到制作 App，或许你以为很困难，但有了 WebToApp，这一切就会变得很简单。不同于其他类似 App「把网页套进 WebView 里」的简单粗暴，也无需打开电脑配置复杂的开发编译环境，WebToApp 内置了一套功能完备的「标准应用外壳模板」（包含完整的浏览器内核、网络栈与扩展接口）。当我们在手机里填好网址、设置好参数、配置好自定义选项后，WebToApp 会解析网页中的相关项目，连同你的配置导入到模板中快速生成一个独立的 APK，同时还能直接在手机端完成签名动作。整个过程不需要你懂代码编译，也不用太多人工操作，更不用把数据上传到云端，所有操作都在手机本地一气呵成。当然了，如果网站支持 PWA，也可以直接套用 PWA 配置的同时获取独立 App 的使用体验。在创建应用时，普通用户最常用的自然是「网页」类型，只需要输入目标网址、应用名称并挑选一个心仪的图标即可。但 WebToApp 远不止打包网页这么简单，如果你是一位喜欢折腾的玩机高手，WebToApp 支持多达 12 种类型的 App 构建，它甚至能在手机本地直接运行 Node.js、PHP、Python 甚至是打包 WordPress。这意味着哪怕是一个依赖后端服务或者数据库的网站，也能被它直接打包成完全独立 App。WebToApp 根据每种打包类型，提供了不同程度的自定义选项。比如在视觉和交互上，你可以配置全屏显示、自定义首屏、状态栏自适应取色等等；在浏览体验上，它支持拦截网站上的广告，或者启用桌面模式等等。配置完成后还能直接擎进行效果预览，确认整体符合预期后即可点击「构建 APK」完成打包与签名，并直接弹出系统的应用安装界面。更棒的是，除了基础的打包和定制，WebToApp 的扩展能力也非常强大。它允许用户使用油猴脚本优化浏览体验，还直接打通了 Chrome Web Store 搜索通道，让你可以把桌面端的 MV3 浏览器扩展直接下载并装进 App 里。在网络层面，除了系统自带的 WebView，你还可以按需切换为 GeckoView（也就是 Firefox 的内核），并获得 DoH、TLS JA3 指纹伪装等等一系列我甚至都看不懂的硬核特性。要是觉得海量的自定义配置太复杂，应用内还贴心地集成了 Agent，接入大模型后就可以像 Vibe Coding 一样直接说出你的需求，AI 就能自动调用 WebToApp 的能力替你完成参数调整与打包全流程。整体而言，WebToApp 上能给高级玩家提供多种玩法、下能满足普通用户的轻量化 App 打包体验。无论你是想给常用的网页工具换个清爽独立的入口，还是想把复杂的脚本和程序打包成客户端，WebToApp 都能在一台 Android 手机上为你轻松搞定。你可以在GitHub免费下载 WebToApp。发表首评Algidy：追踪食物过期日平台：Android关键词：物品管理@Peggy_：又到了采购日，你从超市购买了零食、牛奶、鸡蛋、蔬菜、肉类，到家后，一部分食物被你放到了冷藏室，一部分进入了冷冻室，还有一部分则凭借经验放在了厨房或储物室。然而，随着时间的推移，你发现总是能从各处搜索出来一堆过期的食物、酱料。Algidy 是一款想帮你解决上述问题的应用。在 Algidy 中，我们可以看到多个物品存放区域，应用默认给出了冰箱、冷冻室、储物室，基本上涵盖了主要的食物的存储区域。我们可以根据自己家庭的存放习惯来设置食物的存放区域。除了根据存放位置分类外，我们还能自行在 Algidy 设置不同的食物分类，例如调料、水果、米面、零食等。点击首页加号，便可以开始添加食物了，这里应用给出了两种添加方式，一种是扫描食品包装袋上的条形码，系统扫描后自动判定食品的名称，我扫描了部分身边的食品条形码，部分能准确识别，也存在无法识别的情况。对于无法通过扫描识别的食品，我们可以选择手动添加。无论是哪种添加方式，在详情页面，我们都能附加食品的图片，设置食品的存放位置和所属种类等。随着食品的不断添加，我们便相当于有了一个掌心超市，应用会在首页直观展示出已添加食物的可食用时间还剩余多少，有效避免食物放置过期造成浪费。如果某种食物我们开封后食用完毕了，则可以点击相应图片，选择「已食用」，来达到归档效果。Algidy 还支持搜索功能，方便我们查找相应的食物。在食品排序上，Algidy 支持按照食品过期时间排序、按照食品名称排序，也可以一键筛选出已过期食物，方便后续的清理。目前 Algidy 的不足之处在于添加食品分类后，无法对标签进行删除或二次编辑，期待后续更新能补足相应功能。你可以通过GitHub发布界面下载体验 Algidy。发表首评不空：钓鱼天气分析与鱼情记录平台：iOS / iPadOS关键词：钓鱼、鱼情分析@ElijahLee：《不空》是由个人开发者推出的钓鱼应用，核心亮点是帮助钓鱼佬判断鱼情、查看天气、记录钓鱼数据并辅助提升下一次出钓。应用大小仅 10.8 MB，支持在 iPhone 和 iPad 上使用。打开应用，即可感受到这款应用看起来非常专业。首页密集排列鱼情指数、鱼情分析、天气、未来爆护指数等等。先别急，出钓前，先看「鱼情」指数。在应用上方，先选择目标鱼类后，应用会基于当前天气、地理位置和时间段内，判断分析各种鱼类的活跃度和咬钩概率，并提出「鱼情」指数，搭配显示停口、口稀、良好等标签提示。选择鱼种后，我们可以直观地判断现在这个天气下，目标鱼是不是好钓。除了当天，应用还提供了未来 24 小时、未来 7 日鱼情分析，并且提供逐小时的气温、气压、风向、风力和降雨等信息，将这些天气变化与目标鱼的鱼情结合起来，即可判断哪天哪时最容易钓到鱼。如果你是周末才有时间钓鱼，可以提前比较未来几天的鱼情和推荐时段，再决定具体哪一天出门。除了查看钓鱼天气之外，在应用中，我们可以把自己的钓鱼经历记录下来。在「出钓记录」中，我们可以记录每次的「上鱼」时刻或是「空军」情况。每次记录都支持选择钓点、时刻、鱼种和钓法，以及补充照片。应用会自动记录当时的天气，并且在今后出现相似天气时发出通知提醒。在「钓点地图」中，我们可以记录并查看自己的私有钓点，在应用内的地图中定位，即可快速添加。这样积累一段时间之后，每个钓点都会形成一段历史数据，记录本身会反过来帮助判断下一次出钓。例如，你去年在某个位置钓鲫鱼时，恰好遇到气压下降、微风和小雨，鱼口很好。那么下一次遇到相似天气时，就可以回到自己的历史记录进行对照。应用还提供了钓鱼百科、出钓记录统计、出钓习惯分析等功能。从版本历史来看，不空目前还

By 大出海网采编