本文记录的是我的思考内容，本篇是我从 2023 年思考到现在的内容。我感觉我大概对整个方向清晰了，于是记录了本文，期望能给大家带来一些灵感
我想做的事情很简单：让用户用自己的 AI App 就能操控任何设备。对着手机说话，设备就动。
先说一下 AI App 是什么。我说的 AI App，就是未来每个人手机里那个懂自己的 AI 助手。它知道你的习惯、喜好、说话方式，你每天跟它聊天，让它帮你做事。可能是某个大厂做的，也可能是某个创业团队做的，形态也许就是一个 App，也许是系统内置的，不重要。重要的是用户会越来越依赖它，跟它越来越默契。
但你熟悉的是这个 AI，不是每台设备。你走进一间教室、面对一台一体机、坐进一辆车——设备是陌生的。你不知道它的菜单在哪、不知道它有什么功能、不知道出问题该怎么办。最自然的想法就是：继续跟自己的 AI 说，让 AI 去搞定设备。
这就是我想做的：设备和 AI App 之间的那一层东西。让 AI App 能理解设备、操作设备。用户只跟自己的 AI 对话，不需要学设备。
说几个情景。
科学课上，老师想把种子发芽的实物投到大屏上给全班看。点了展台图标，没反应。再点，还是没反应。学生开始交头接耳。课后才知道是摄像头驱动掉了。如果当时他对着自己的 AI App 说一句”展台打不开了，帮我看看”，AI 自己判断原因，释放占用，打开展台。课堂不会断。
另一个老师每天早上到教室：开一体机，等启动，打开课件，登录，调音量，切输入源。每天三分钟，一学期五六个小时。对着手机说一句”上课”，全部自动跑完。
还有个语文老师，公开课前打开 PPT，排版全乱，字体飞了。版本兼容问题，调不过来。说一句”课件排版乱了，帮我调回正常”，AI 识别字体问题，批量替换，两分钟搞定。
美术课上，老师想用大屏展示梵高的《向日葵》，让学生感受色彩的层次。但屏幕颜色怎么看怎么怪，整幅画泛黄，像蒙了一层旧报纸。翻设置、找显示、点来点去，学生在下面哄堂大笑。老师越着急越是找不到在哪调好。如果她说一句”把屏幕颜色调正常”，AI 自己判断是护眼模式开着，自己找到开关位置，关掉。颜色瞬间对了。
这些场景里设备功能都在。展台能开，字体能调，护眼模式能关。问题从来不是设备没能力，而是入口藏太深、步骤太多、出了事不知道原因。
再往下说我要做的具体是什么。
每台设备上跑一个程序，我们写的。设备出厂带上或者后续装上都行。我把它叫做设备连接器，它做几件事。
第一是连接。让 AI App 靠近设备时能发现它。可能是扫码，可能是 NFC 碰一下，可能是蓝牙广播，也可能是超声波。方式不重要，重要的是用户不需要输入 IP、不需要手动配对、不需要注册账号。靠近就能连，交互方式便捷轻量。
第二是理解。设备要能告诉 AI App “我是谁、我能做什么”。一份写给 AI 读的设备说明书，里面有设备身份、能力清单、每种操作怎么调用、已知问题怎么处理。没有人比厂商更懂设备，所以厂商来写基础版。但它不是固定的，这个后面再说。
第三是执行。AI App 想做什么操作，把指令发过来，设备连接器负责真正去执行。调系统接口也好，改配置文件也好，走 IPC 也好，操作文件也好。这个执行器可以很轻——只做执行，不推理。
这里有一个分叉，有两个方向。刚才说的是方向一：AI App 把所有事情想清楚，发结构化指令过来，设备端只执行。还有方向二：设备这边自己也带一些智能，AI App 把用户意图用自然语言描述发过来，设备侧的 Agent 自己理解意图、自己决定怎么做。两个方向不是非此即彼，可能并存。比如设备侧可以内置一些预制解决方案，遇到匹配的场景直接走预制方案，没有预制的再让 AI App 去推理。这个还没定。
回到说明书。它不是静态的。AI 在实际使用中会遇到厂商没写进去的情况：某个隐藏更深的功能入口、某种异常状态的恢复手段、某个报错的真实原因。某次 OTA 应用更新后的行为变更。这些经验可以补充进说明书。一台设备被操作得越多，积累的经验越多，后来的 AI 连接这台设备时直接继承。设备越用越聪明。
技术方面简单说一下。设备端用 C# .NET，跨平台，Windows 和 Linux 的设备都能跑。AI App 端试错阶段我自己做一个简单的来验证链路，调 DeepSeek 或者别的现成大模型，薄壳应用。甚至于用现成的 IM 工具，如 QQ 等这些。等跑通了，AI App 这边是各大厂的事情，我丝毫不想也不敢上这个赛道，我只做设备连接器这一层，以及我自己的可控设备的这一层。
路径上，不是先写一份标准等人来接入。纯协议没人理的。得先自己对接具体的设备和场景，做出实际效果给人看。场景一个一个啃下来，连接器这一层在这个过程中自然长出来。积累够了，才有可能变成厂商愿意预装的东西。
还有很多没想好的，比如第一个突破口选哪个场景、设备侧要不要内置预制方案、软件架构怎么划。但大方向清楚：让用户的 AI App 能操控任何设备，用户只跟自己的 AI 说话，不需要学设备。
现在这个世界上是有很多“屏”的，也有很多设备的。哪怕是像我一样的 IT 深度用户，也会遇到令我无助的设备，面向“屏”干瞪着。人类的与机器的交互形态都会在变化。从一开始的飞机驾驶舱的超级多按钮，到面向电脑的交互，到面向手机、触摸屏的交互。后面的车机上的语音交互，智能家居的语音交互。我不是在想有更新的人类与设备的通讯交互方式，而是想着是否有改变人类与哪台设备的通讯交互方式。是否在陌生设备与人类之间，放入一个人类熟悉的设备
虽然我认为我自己是想明白了的，但是却很难将这个想法实施起来。我就想将这个想法公开发出来，也许能激发一些伙伴的灵感
这是 2023 年的思考： 非技术 对以后各大应用功能与 AI 助手的思考 - lindexi - 博客园
我请了 AI 帮我润色了一下，以下内容看起来应该比较正式一些
产品痛点：用户面对物理设备时的困境：功能存在但入口隐蔽、操作路径长、异常状态无法自行诊断。典型场景如教学一体机的护眼模式关闭、展台摄像头切换、侧边栏工具配置——这些操作需要用户具备超出日常经验的技术知识。延伸扩展为一切可操作的设备，甚至未来包括其他嵌入式一体机，或 IOT 设备
用户侧效应：用户与自己的 AI App 对话，AI App 操作设备。用户不需要学习设备。
核心卖点： 生态位+护城河建立
技术细节
角色
- AI App：用户侧 AI 端点。理解用户意图，持有设备能力描述，做推理决策。
- 设备连接器（Device Connector）：设备侧运行时。负责设备被发现、暴露能力描述、接收并执行指令、返回结果。
- 设备：物理硬件与其操作系统。
组件
设备连接器包含以下模块：
- 发现层（Discovery）：使 AI App 在物理邻近范围内感知到设备。途径包括二维码、NFC、BLE 广播、超声波编码等。不限定具体技术，输出统一为设备地址与获取能力描述的入口。
- 能力描述（Agent.md）：一份结构化的、面向 AI 消费的设备能力描述文件。内容包括设备身份、可调用能力列表及其接口定义、已知限制与异常处理方式。由设备厂商编写初始版本；运行时支持由 AI App 回写增量经验，实现设备使用经验的累积与跨用户继承。
- 执行器（Executor）：接收结构化操作指令，映射为系统调用、文件操作、协议指令（如 UDI）、进程管理等。执行器不做推理，仅做执行与状态返回。尺寸目标为极轻量，可嵌入资源受限设备。
- 可选智能层（Device Agent）：在模式 A（AI App 侧推理）之外提供模式 B——设备侧内置推理能力。AI App 将用户意图以自然语言转发，设备侧 Agent 自行理解并调度。两种模式可共存：预制解决方案优先匹配，未命中时回退至 AI App 推理。
数据流
模式 A（远端推理）： 用户语音 → AI App 转录与意图识别 → AI App 匹配设备能力描述 → 生成结构化操作指令 → 设备连接器执行 → 返回结果 → AI App 判断是否完成。
模式 B（设备侧推理）： 用户语音 → AI App 转发自然语言意图 → 设备连接器接收 → 设备侧 Agent 匹配预制方案或自行推理 → 执行 → 返回结果。
技术选型
- 设备连接器运行时：C# .NET，采用 Native AOT 编译。跨 Windows/Linux 平台。无运行时依赖。客户端与服务端、连接端与执行端均可统一使用相同的语言和框架，可在确保质量下限的前提下借助 AI 辅助编程。
- 通信协议：待定。初期考虑轻量 HTTP/WebSocket，后续可能针对局域网场景优化。
- AI App 端：验证阶段为薄壳移动端应用，甚至依托于三方 IM 应用，接入第三方 LLM API（DeepSeek 、豆包 等）。非核心交付物。
评论摘要
以下为我摘要在各个群+博客评论的内容，经过 AI 润色后的内容
-
哪个厂商愿意变成「透明硬件盒子」？ 这不是技术问题，是战略问题。这也是为什么 CarPlay 和 Android Auto 在汽车行业推了很多年，依然有大量车企拒绝——他们不想把车内体验的控制权交给苹果和Google。
-
Windows上关键的设备操作（显示色彩、驱动管理、系统设置）确实需要管理员权限，而学校IT管理员不给。产品能做，但只能做到「查状态」和「给建议」——不能自动执行。用户价值大打折扣，从「AI自动操控」降级为「AI操作指南」。产品找不到PMF（Product-Market Fit），做不下去。
-
安全感+稳定性难以保证。现在有多少人习惯对着手机说「帮我做什么」？Siri、小爱、小艺这些语音助手存在了十年以上，但绝大多数人的使用方式还是「定闹钟」「问天气」「放音乐」——不是「帮我操作这台设备」。除非做得好，否则用户有几次无法达到预期，将会放弃
-
幻想未来某一天，移动设备上的 Agent 已经普及，设备上的协议也都开发完成、支持对接，用户起心动念便可完成对任意设备的调用。
-
有没有可能，交互方式既不是触摸，也不是语音，而是人面向自己熟悉的 AI，让这个 AI 去跟各种不一样的设备、系统、应用打交道？
USB 的比喻
在USB出现之前，键盘用PS/2口、鼠标用串口、打印机用并口、扫描仪用SCSI口。每接一个新外设都是一场噩梦。USB没有发明更好的鼠标或更好的打印机——它做了一个所有设备都说的「通用语言」。
这个想法做的不是更好的设备，是设备与AI之间的USB。
USB的价值不在于它有多复杂，而在于它让所有设备变得简单。这个连接器的价值不在于它有多聪明，而在于它让所有设备变得「不用学」。
但谷歌推了这么多年 A2A 也没有起色，可能这个事情不好做。
技术方向
AI APP 可能没机会，前有豆包、中兴，后有小米、华为。
技术上有两个大方向：
设备提供 “说明书” Agent.md 让 AI APP 感知到，再提供各种操作路径
- 优势：边际成本低，无 Token 费用。由 AI APP 掏 Token 费用
- 缺点：基础设施搭建、操作路径（各类工具，如前面提到的 CLI 等等）繁杂，适配工作量高
设备本身是一个 Agent，AI APP —(自然语言)—> 设备 Agent
- 优势：上限高，没有比厂商自己更懂自己的产品了，体验感可能更高
- 缺点：要烧 Token，每多一个设备都是成本
本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。 欢迎转载、使用、重新发布，但务必保留文章署名 林德熙 (包含链接: https://blog.lindexi.com )，不得用于商业目的，基于本文修改后的作品务必以相同的许可发布。如有任何疑问，请与我 联系。