0. 先和大家打个招呼吧 
-
大家好，我是AI研究室-帆哥，一名AI 内容创作者和独立开发者。
-
我一直对“AI 怎样真正进入现实生活”这件事很感兴趣。因为一些机缘巧合我们接触到视障群体，我意识到AI的能力能够带给他们非常大的帮助。AI不能仅仅只停留在屏幕中，它应该走近真实的物理世界，进入人们的生活，帮助那些真正需要它的人和群体。
-
这副AI 助盲眼镜，就是我和 TRAE 一起尝试回答这个问题的作品。
-
它实时主动辅助盲人出行寻物，具有强大智能，真的能够给视障朋友”重获视力“的体验，并且成本仅300元的盲人的”第三只眼“ ！
-
这个项目横跨了产品设计、视觉模型、地图导航、Flutter App、Python 服务端、ESP32 固件、传感器、实时音视频协议和 3D 结构设计。过去，这样的项目通常需要一个完整的软硬件团队；而这一次，我把脑海里的需求、实际测试时遇到的问题，以及每一次串口报错、状态机异常和端云联调结果，一步步告诉 TRAE，再和它一起拆解、实现、验证。TRAE让我现在拥有了全栈式工程师的能力，把最疯狂的想法也可以付诸现实。我负责提出问题、做产品取舍和真机验证，它帮助我快速理解陌生领域、补齐实现细节、定位跨端问题。
-
在这个过程中，我觉得最重要的就是怎么把你的需求和逻辑梳理得很清楚，一步步地告诉AI，尤其是面对这种横跨软硬件，复杂实时功能的工程性项目，一开始需要花大量的时间来把项目的各个需求环节想得很清楚，花上几周的时间其实也不为过。
1. Demo 简介
-
1.1 它是什么？
“第三只眼”是一套专门面向盲人和低视力人群的低成本便携式 AI 助盲系统，由 AI 眼镜 + 手机 App + 云端智能体 三部分组成。它的优势是
它不是一副只能“拍一张图、回答一句话”的普通 AI 眼镜，而是尝试在用户连续移动的过程中，主动完成环境感知、通路判断、危险提醒、实时导航、找物抓取和持续观察。 -
一句话概括：
我希望它成为盲人朋友的“第三只眼”——不仅告诉用户前方有什么，更要持续告诉用户该往哪里走、哪里不能走、什么时候停下，以及目标物体在哪里。 -
1.2 它面向谁？
-
核心用户包括：
- 盲人和低视力人群；
- 有独立出行、室内找物和环境理解需求的视障朋友；
- 在特定场景下需要实时视觉辅助的人群。
我们最关注的，是视障用户日常生活中那些看似普通、实际却需要持续判断的场景：
- 从家里步行到地铁站；
- 在人行道上寻找可通行区域；
- 接近路口时寻找斑马线、识别红绿灯；
- 避开脚下坑洞、突起物和近距离障碍；
- 在室内外寻找物体，如座椅、水杯、钥匙、门把手等物品；
- 持续观察公交车、门口来人、水是否烧开等状态。
-
1.3 几个核心功能：
-
核心功能状态流程全览：
-
核心功能展开介绍（功能完整实测演示可查看视频”* https://v.douyin.com/ih9vA0TGVhY/ 10/19 f@b.At goD:/ :8pm”）
功能一：实时导航与主动避障
用户说出目的地后，手机 App 通过高德地图完成 POI 搜索、目的地确认和步行路线规划。行走过程中，眼镜把摄像头、IMU 和 TOF 数据通过 Wi-Fi 直连发送给手机，手机本地实时融合地图、视觉与传感器信息，生成简短、可执行的引导：
-
“向左转。”
“向右移动，回到通路中心。”
“保持直行。”
“停下，前方地面有危险。”
“正在寻找斑马线。”
“红灯，请等待。”导航的实时安全主链路以及语音引导播报都运行在手机本地。即使云端网络短时抖动，本地通路识别、方向纠偏、语音引导和危险提醒仍可以继续工作。
-
【GIF 01：导航完整流程】
推荐画面：语音说出目的地 → App 确认 POI → 高德地图算路 → YOLO 通路分割 → IMU/TOF 面板 → 眼镜播报引导。功能二：找物与抓取辅助
用户可以直接说“帮我找一下水杯”或“键盘在哪里”。系统识别目标物体后，会引导用户转头、对准并靠近目标，再结合方向和距离判断，提示：
-
“键盘在你的右前方。”
“再向右一点。”
“向前靠近。”
“已经进入手可触达范围，可以伸手拿取。”找物不是只回答“画面里有一个水杯”，而是把视觉识别结果转化为连续的行动指引，让用户真的能够找到接近目标，实时判断用户手可触及的距离范围，引导抓取。
-
【GIF 02：找物抓取流程】
推荐画面：发出找物指令 → 目标框选 → 方向引导 → 距离变化 → 进入可抓取范围。功能三：自定义视觉任务与实时智能体
除了固定功能，用户还可以用自然语言临时定义任务：
-
“帮我看看周围是什么环境。”——触发 360° 环境扫描；
-
-
“帮我盯着门口，有人来了提醒我。”——触发持续监测；
-
“看看水有没有烧开。”——持续观察指定状态；
-
-
“19:10后提醒我出门。”——创建定时视觉任务；
-
-
“帮我查一下今天的天气和地铁运营信息。”——触发联网搜索；
-
- “我面前现在有什么？”——触发单图视觉问答。
这部分能力由云端实时智能体理解用户意图，再调用对应工具、调度摄像头和后台任务，并把结果通过语音返回眼镜。它让眼镜不只是一个固定功能设备，也可以根据用户当下的真实需求临时“学会”一项任务。
-
-
2. Demo 创作思路
2.1 灵感来源：一条评论背后的真实需求
最初让我认真思考这个方向的，是 AI 眼镜相关内容下反复出现的一句话：
“其实盲人才是最需要 AI 眼镜的人。”
对于普通人来说，AI 眼镜可能是一种更方便的信息入口；但对盲人和低视力人群来说，“看见并理解周围环境”直接关系到能否独立出门、能否安全通过路口、能否找到日常物品。
当我进一步查看盲人出行视频、视障用户分享和相关评论后，我发现真正的痛点并不是“识别一次物体”这么简单，而是在连续行动中持续获得可靠、低延迟、可执行的反馈。
2.2 现有方案为什么还不够？
盲人朋友往往需要同时依赖盲杖、手机导航、路人帮助和个人经验，但这些工具解决的是不同局部问题：
方案 能解决什么 仍然缺少什么 盲杖 探测近距离地面和障碍 无法理解远处通路、斑马线、红绿灯和目标物体 手机地图导航 给出宏观路线与转向 不知道眼前哪里能走、脚下是否危险 普通视觉问答 回答“画面里有什么” 多为单次问答，无法持续低延迟地引导行动 高价 AI 眼镜 提供语音和视觉能力 价格高，且通常不是围绕盲人导航与避障设计 -
对视障用户来说，最重要的问题其实是：
- 我现在应该往哪边走？
- 眼前哪一块区域可以通行？
- 脚下有没有坑洞或凸起？
- 前面是不是斑马线？现在能不能通过？
- 目标物体在什么方向？手是否已经能够到？
因此，我没有把做成“更会聊天的眼镜”，而是选择围绕 实时行动辅助 设计整个系统。
2.3 第一版给我的答案：需求是真实存在的
在第一版 AI 助盲眼镜中，我发布了《“失去”双眼，我用自制的 AI 眼镜体验失明的一天……》演示视频。视频在【AI研究室-帆哥】等各社媒平台全网获得广泛关注，也收到了大量普通观众、盲人朋友和视障社群的留言与反馈。
这些反馈让我看到两件事：
第一，公众非常关心视障群体在真实生活中的处境；第二，盲人用户需要的并不是一个概念产品，而是一套能在导航、找物和自定义任务中真正连续工作的系统。
第一版证明了“AI 眼镜可以帮助盲人锁定盲道，理解环境”，第二版则要继续回答：“它能不能在可能大部分盲道都被占用，真实复杂的环境中去更实时、更自由地行走、更安全、更低成本地帮助用户行动？”
2.4 第二版不是加功能，而是软硬件重构
基于第一版原型验证和用户反馈，第二版从软硬件两端进行了重新设计。
软件层面
- 将导航实时主控迁移到手机本地，降低云端抖动对安全链路的影响；
- 引入高德地图 + YOLO Seg + IMU + TOF 的多源融合；
- 构建从空闲、算路、起步对准、人行道行进、接近路口、寻找斑马线、等待红绿灯、通过路口到到达目的地的完整状态机；
- 基于 RealtimeAgent 重构智能体架构，完成实时语音、视觉输入、多设备协作、工具调用和后台任务；
- 将导航、单图问答、360° 环境识别、万物监测、定时任务、联网搜索等能力拆分为可组合的业务模块。
硬件层面
-
从开发板堆叠转向自主外观、结构设计和 3D 打印；
-
从飞线原型转向自研 PCB + FPC；
-
集成摄像头、IMU、TOF、麦克风、扬声器、左右震动与电源模块；
-
围绕佩戴重量、传感器朝向、镜腿空间和整机走线重新布局。
3. Demo 核心亮点
3.1 自研万图级 YOLO 视觉模型
为了让系统真正理解“哪里能走”，我们没有只依赖通用视觉问答，而是自建户外出行数据集，完成万张级图像的收集、筛选、标注、训练和多轮调优。
模型覆盖：
-
pass：人行道等可通行区域； -
crossing：斑马线； -
road：机动车道； -
bicycle：非机动车道； -
obstacle：障碍物； -
red / green：红绿灯状态。
手机端运行 YOLO nano 分割/检测模型，根据 pass 和 crossing 的中心线生成微观方向引导；进入等灯状态后，再按需加载红绿灯专项模型。这样可以避免所有模型始终满负载运行，在准确率、发热和帧率之间取得平衡。
这套模型最重要的价值，不是回答“前面有一条人行道”，而是持续计算：
3.2 端侧 Wi-Fi 直连 + 手机全栈融合
ESP32 眼镜通过手机热点或同一局域网与 App 直连，高频摄像头、IMU 和 TOF 数据不需要绕行云端。手机同时完成：
-
高德地图 POI 搜索与步行算路；
-
YOLO ONNX 推理；
-
IMU 朝向计算；
-
TOF 地面风险判断；
-
导航状态机与优先级仲裁；
-
引导词生成和导航语音调度。
这套设计把用户已有手机变成眼镜的本地算力中心，在降低眼镜成本和重量的同时，也缩短了实时安全链路。
需要说明的是：眼镜与手机之间的传感器实时链路走局域网，不消耗手机移动数据；云端视觉问答和联网搜索仍需要互联网。
3.3 宏观地图 + 微观视觉 + 安全传感器三层融合
单一地图、单一摄像头或单一距离传感器，都不足以覆盖盲人步行导航。
我们的融合顺序是：
-
**安全优先：**TOF 发现脚下坑洞、凸起或近距离风险时，以 P0/P1 高优先级打断其他引导，先提示用户停下。
-
**方向正确：**高德路线 bearing 与 9 轴 IMU 的绝对朝向做差值计算，完成起步对准和持续偏航纠正。
-
**通路可走：**YOLO Seg 识别人行道、斑马线和道路区域，计算可通行中心线，给出左移、右移或保持直行等微观动作。
-
**动作简短：**最终只给用户播报当前最重要、最容易执行的一条提示，避免复杂信息占用听觉。
3.4 AI 眼镜 + 手机 App + 云端智能体互连
云端部分基于 RealtimeAgent 构建。它不是一个单纯的聊天接口，而是一套面向实时语音、视觉输入和多设备协作的 Agent 框架：
-
眼镜、手机等设备可以注册在同一个用户会话中；
-
控制通道与音频、视觉媒体通道分离；
-
支持 ASR、视觉语言模型、工具调用和流式 TTS；
-
一次性能力由 Tool 执行，持续监测和定时任务由后台 Tool 执行；
-
运行过程会记录模型请求、工具事件、流事件与播放决策，方便复盘和排障。
在助盲业务中，RealtimeAgent 负责理解“用户现在想做什么”，再把任务路由到导航、自定义视觉、单图识别、联网检索或定时任务等能力。云端增强智能，手机守住实时安全，两者并不是相互替代，而是各自承担最合适的工作。
3.5 硬件与外观一体化自研
从第一版原型到第二版，我不仅重写了软件架构，也重新设计了眼镜的形态。摄像头和 TOF 需要稳定朝向前方与地面，麦克风和扬声器需要兼顾收音、播报与佩戴，电池和主板需要尽量分散重量，FPC 则需要沿镜架完成可靠走线。
从手绘眼镜外观，到AI大模型文生图来设计概念图，我比选了很多不同的版本，选定的这版外观也迭代建模了很多轮，为的是最小化地把硬件装配进去的同时，又不缺未来的科技美感。外观采用了扭转流线型的设计，和硬件更好地
3D打印了很多版，测试了内部空间与硬件的碰撞问题，铰链，鼻托，前框等细部结构构造，以及佩戴后的舒适度，重量。
因此，结构设计不是最后一步“套壳”，而是与传感器方案、固件接口和交互方式同步推进。最终得到的是一套从外观、结构、PCB/FPC 到固件和 App 都围绕助盲场景设计的完整硬件交互 Demo。
4. Demo 体验地址
本项目属于硬件交互赛道，核心体验依赖真实眼镜、手机 App、传感器和户外环境，因此以公开演示视频作为主要体验方式。
4.1 完整实测演示视频
*目前实测演示用的还是手搓的样机，完整版硬件和外壳还在优化制作中，后续会在比赛中现场呈现。
-
公开链接：【https://v.douyin.com/ih9vA0TGVhY/ 10/19 f@b.At goD:/ :8pm 或 https://www.douyin.com/video/7662727996284996927】
-
视频标题: AI助盲眼镜实测演示
视频按以下顺序展示：
-
产品概览动画：眼镜实物、手机 App 与一句话定位；
-
实时导航：第一视角行走 + 手机 App 录屏 + 眼镜播报；
-
找物抓取：识别、转向、靠近、进入可触达范围；
-
自定义视觉：360 环境识别、持续监测、定时提醒；
-
其他云端智能体功能：实时语音对话、工具调用和终端运行记录；
4.3 交互式 HTML 展示
AI助盲眼镜创意方案 -v2.html (1.4 MB)
HTML 页面用于补充展示产品背景、系统架构、硬件组成和开发路线；实际硬件能力请以公开实测视频为准。
5. TRAE 实践过程
5.1 从需求描述到工程拆解
最开始，我并没有直接让 TRAE “帮我写一副 AI 眼镜”。我花了一两周的时间来和TRAE一起来梳理项目开发需求和逻辑，生成了几份开发需求文档，分阶段开发文档等。之后让TRAE根据这些文档来一步步分阶段来开发突破。
TRAE 帮我把这段产品需求拆成：
-
高德地图负责宏观路线；
-
YOLO 负责微观可通行区域；
-
IMU 负责绝对朝向和偏航；
-
TOF 负责地面安全兜底；
-
手机负责本地融合；
-
ESP32 负责采集与反馈；
-
云端负责语音意图、视觉理解和后台任务。
这一步决定了后续的整体架构，也避免把所有能力都压到云端或眼镜端。
5.2 重构 RealtimeAgent 实时智能体架构
第二版需要同时处理眼镜、手机、浏览器测试端、音频、视觉和后台任务，旧的单体链路很难继续扩展。
我和 TRAE 一起把架构重构为：
-
Server SDK、Device SDK 与通信协议分离；
-
control、audio input、visual input、audio output 分通道；
-
Omni / Realtime 与 VL 两种模型链路可切换；
-
短任务用 Tool，持续任务用后台 Tool；
-
业务能力独立放在
capabilities，不侵入框架核心； -
每次运行保存模型、工具、流和播放决策日志。
在这个过程中，TRAE 不仅协助写代码，也不断帮助我检查业务边界：哪些能力属于通用框架，哪些属于眼镜设备，哪些应该留在助盲业务层。
5.3 ESP32 固件与真机联调
硬件开发中最耗时间的，往往不是“写出一段能编译的代码”，而是面对真实设备上的不确定性：
-
摄像头、PDM 麦克风、I2S 扬声器同时运行时的资源冲突；
-
BNO080/BNO085 与 VL53L5CX 共用 I2C 的初始化和稳定性；
-
Wi-Fi 断连重试；
-
图片、IMU、TOF 高频传输带来的带宽和发热问题；
-
导航语音播放与摄像头、传感器任务之间的抢占关系；
-
P0/P1 安全提示如何打断普通播报。
我把串口日志、复现步骤和预期行为交给 TRAE，让它协助定位问题、修改固件、补充 ACK、超时、重连、缓存和降级策略，再通过一次次烧录进行验证。
例如，为了让安全提示尽快播放，我们增加了高优先级导航音频的 PSRAM 预加载；命中缓存时直接从内存播放，未命中时再安全降级到 HTTP 拉取。
5.4 手机 App、YOLO 与多传感器融合
手机端是实时导航的主控，也是整个项目中状态最复杂的部分。
我和 TRAE 一起完成了：
-
Flutter 四大功能页与设备连接状态；
-
高德 POI 搜索、候选确认、步行算路和地图展示；
-
Android 原生 ONNX 推理与 Flutter 数据桥接；
-
YOLO 分割结果、通路中心线和微观动作生成；
-
IMU 起步对准、偏航纠正；
-
TOF 地面危险优先打断；
-
从空闲到到达目的地的完整导航状态机；
-
语音优先级、打断、节流和去重。
开发中最典型的一次取舍，是放弃“只用 GPS 距离判断到达路口”。在斜交路口或宽路口，GPS 可能等用户走到马路中间才提示，风险很高。后来我们改为视觉多帧确认斑马线和道路横穿关系，并加入距离与朝向门控，让路口判断更贴近真实第一视角。
5.5 云端业务能力与持续任务
完成导航后，我继续让 TRAE 协助把“用户的一句话”变成可以执行的业务任务：
-
“看看我面前有什么” → 单图视觉问答；
-
“看看周围环境” → 360° 扫描；
-
“帮我盯着门口” → 后台持续监测；
-
“半小时后再看一下” → 定时视觉任务；
-
“帮我查最新信息” → 联网搜索；
-
“开始导航去……” → 导航任务与手机端事件。
这些能力统一由意图路由器分发，并通过可取消、可查询、可记录的 Tool 或后台 Tool 执行。相比把所有逻辑写进一段提示词，这种方式更稳定，也更方便继续增加新的助盲能力。
5.6 TRAE Session ID
以下为完成本 Demo 的关键任务对话记录：
-
需求拆解与系统架构设计
Session ID：
【7484094513502503991:1d326e7c57d053a2f47f7dea4122c329_6a53239e8b835cfda39cec13.6a53239e8b835cfda39cec16.6a53239e8b835cfda39cec14:TRAE Work.0.1.30.no_sid.no_ppe.T(2026/7/12 13:18:22)】 -
RealtimeAgent 实时音视频与多设备架构重构
Session ID：
【7484094513502503991:1d326e7c57d053a2f47f7dea4122c329_6a53239e8b835cfda39cec13.6a53239e8b835cfda39cec16.6a53239e8b835cfda39cec14:TRAE Work.0.1.30.no_sid.no_ppe.T(2026/7/12 13:18:22)】【7484094513502503991:f1f65aacf60780c5e0d089477d105fc5_6a53239e8b835cfda39cec13.6a5325ae8b835cfda39cecc1.6a5325ae8b835cfda39cecbf:TRAE Work.0.1.30.no_sid.no_ppe.T(2026/7/12 13:27:10)】【7484094513502503991:506e1d0a37dd5faef99b47116b91a1b7_6a53239e8b835cfda39cec13.6a532bc78b835cfda39ced26.6a532bc78b835cfda39ced24:TRAE Work.0.1.30.no_sid.no_ppe.T(2026/7/12 13:53:11)】 -
ESP32 固件、摄像头与 IMU/TOF 真机联调
Session ID：
【.7484094513502503991:c823c705ae46800d1a7ace5861442da4_6a530e27068f3ca4d2d371a5.6a530e48068f3ca4d2d371a7.6a530e48fe1ad94856cac04f:Trae.T(2026/7/12 11:47:20)】 -
Flutter、高德地图与 YOLO 导航融合
Session ID：
【7484094513502503991:e3a55f5890ef47fdd435a716c0ba72e6_6a5330648b835cfda39ced8b.6a5330648b835cfda39ced8e.6a5330648b835cfda39ced8c:TRAE Work.0.1.30.no_sid.no_ppe.T(2026/7/12 14:12:52)】【7484094513502503991:3838eb44c641bab2b990662051af1a40_6a5330648b835cfda39ced8b.6a5331678b835cfda39cee36.6a5331678b835cfda39cee34:TRAE Work.0.1.30.no_sid.no_ppe.T(2026/7/12 14:17:11)】【7484094513502503991:3d91725c719bc5f846ba6a04e13fb3d5_6a5330648b835cfda39ced8b.6a53345c8b835cfda39cef1b.6a53345c8b835cfda39cef19:TRAE Work.0.1.30.no_sid.no_ppe.T(2026/7/12 14:29:48)】【.7484094513502503991:c5c7e9aac5a6defc7d43cf85f4dc9f9e_6a3bdb64c39f8b0dd633b04d.6a3e532bc39f8b0dd633c6d7.6a3e532a1181296b97be1e8d:Trae.T(2026/6/26 18:23:39)】 -
自定义视觉、定时任务与联网搜索开发
Session ID：
【.7484094513502503991:4d98fc862b264a86ed3fb143a84d5962_6a3bdb64c39f8b0dd633b04d.6a3e4176c39f8b0dd633c245.6a3e41751181296b97be1e86:Trae.T(2026/6/26 17:08:06)】【.7484094513502503991:02e212524f52216fcbd9b76e88bfcdd5_6a3bdb64c39f8b0dd633b04d.6a3ce379c39f8b0dd633b107.6a3ce3791181296b97be1e66:Trae.T(2026/6/25 16:14:49)】
6. 开发心得与经验总结
这次的开发量特别大，也需要把工程化做好，和TRAE交互的每一步都得有迹可循。最重要的是把需求完整整理好，把问题一直拆分下去，想得越具体，越细致，产品才可能做的更好。以及一定一定要分阶段来让AI开发，按照一个阶段一个阶段去攻破，同时每一阶段的改动都需要让AI整理到对应的README.md文档中来留存，一方面给自己看，一方面也给下一次的新窗口中的ai看。
还有一个技巧就是，问题解决不了的时候，可以重开一个新的窗口，以及先不用agent模式直接改，而是先用ask的模式把根本问题定位了，再去用agent根据刚才定位的问题来解决，一方面这样可以每次的动作上下文窗口都比较充裕，另一方面，也和自己的交互也会更好，能在ai给出来的问题分析再基于你自己的判断，再给到后面的agent去执行。
6.1 AI Coding 最重要的不是“一句话生成”
AI Coding 并不是把一句需求交给 AI，然后等待完整产品自动出现。
真正有效的协作方式是：
-
先描述真实用户场景，而不是只描述页面和按钮；
-
把大问题拆成可以验证的小链路；
-
每一步都明确输入、输出、状态和失败方式；
-
用真机日志、截图和测试结果给 AI 反馈；
-
让 AI 根据新证据继续修正，而不是坚持第一次方案。
TRAE 显著降低了我进入陌生技术领域的门槛，但产品判断、取舍和最终验收仍然需要人来完成。
6.2 软硬件项目里，“能跑”只是开始
网页功能出错，通常可以刷新或重试；但助盲导航如果在错误时间播报、延迟提醒或给出相反方向，可能直接影响安全。
因此，我逐渐把开发重点从“功能能不能启动”转向：
-
断网或断连后会发生什么？
-
两条语音同时到达时谁优先？
-
安全提示能不能打断普通对话？
-
模型暂时没有识别到斑马线时，系统是继续走还是保守停下？
-
云端延迟时，本地导航是否仍然可用？
-
每次错误能不能通过日志复盘？
这些看不见的异常处理和安全边界，才是硬件 Demo 从“展示效果”走向“真实可用”的关键。
6.3 不把所有问题都交给大模型
大模型擅长理解意图、回答开放问题和编排任务，但实时安全决策需要稳定、确定、低延迟。
所以我们做了明确取舍：
-
地图、YOLO、IMU、TOF 和导航状态机在手机本地运行；
-
云端负责自然语言、复杂视觉理解和低频长任务；
-
TOF 风险用确定性高优先级规则打断；
-
视觉置信度不足时采用保守策略，而不是让模型“猜”。
这也成为第二版最重要的架构原则：让 AI 发挥理解力，让本地系统守住安全性。
6.4 技术普惠不只是降低售价
约 300 元的目标成本很重要，但普惠还意味着：
-
设备尽量轻便、容易佩戴；
-
反馈尽量短，不增加认知负担；
-
弱网时关键能力仍能运行；
-
功能可以由自然语言触发，降低学习成本；
-
产品要与真实用户持续共创，而不是替他们想象需求。
第一版让我看到公众的关注，第二版让我更清楚：真正有价值的不是做出一个“看起来很酷”的 AI 硬件，而是把用户的每一个具体困难，转化为可以验证、可以改进的产品能力。
结语
我希望“第三只眼”最终带来的，不只是一次 Demo 展示。
它应该让视障用户在出门时少一点不确定，在路口前多一层安全，在寻找日常物品时少一次求助，也让更多人看到：AI 的价值不只在生成内容和提高效率，还可以进入街道、家庭和每一个具体的生活场景，帮助那些最需要技术的人。
让 AI 从“回答问题”走向“辅助行动”，让技术真正被更多人用得起、用得上——这就是我做这副 AI 助盲眼镜的原因。
感谢大家看到这里，也欢迎视障朋友、开发者、硬件工程师和公益组织提出建议，与我们一起把它继续做下去，让视障朋友可以在现实生活中真实的摸到它，体验它，为自己的生活打开新的窗户！