SmartHomeAI----尧图网络科技

今日学习：从 Vibe Coding 到产品原型

我完成的不是“几段代码”，而是一个产品闭环

今天的 SmartHome AI 项目包含了一条完整链路：摄像头→ OpenCV 获取画面→ MediaPipe 提取手部 21 个关键点→ 手势识别判断用户意图→ 虚拟房间选择→ 智能家居设备状态改变→ PySide6 图形界面反馈→ PyInstaller 打包成 Windows 应用

这说明一个可展示的 AI 产品，不只是“模型识别成功”，而是要让用户能看到、理解、操作，并获得反馈。

软件项目应分层，而不是把所有内容写进 main.py

我逐渐理解了模块化的价值：

文件	职责
`main.py`	程序入口和界面协调
`vision.py`	摄像头、OpenCV、MediaPipe 视觉识别
`gesture.py`	手势判断逻辑
`device.py`	灯光等设备状态与未来硬件控制接口
`config.py`	字体、摄像头、阈值等配置
`styles.py`	界面视觉风格

核心思想是：

每个文件只负责一类问题。

未来接 STM32 时，只需要重点修改device.py，而不需要重写摄像头、手势识别或界面。

AI 识别不是“有结果就够了”，还需要稳定机制

摄像头每秒会产生很多画面。如果每一帧都直接执行命令，灯会被反复触发。

所以项目加入了两个工程思想：

连续多帧识别到相同手势，才确认动作。
同一个手势只执行一次；松手或改变手势后，才允许再次触发。

这叫作“防抖”和“防重复触发”。

它提醒我：

真实系统不仅要识别正确，还要在连续输入中稳定工作。

用户体验也是技术的一部分

项目从最初的摄像头窗口，升级为桌面应用，加入了：

实时画面
手部骨架和手掌光标
客厅、卧室、厨房分区
当前目标房间
当前手势
灯光状态
操作日志
摄像头启停按钮

这说明：

功能能运行，不等于产品好用。

产品设计需要让用户随时知道：

系统有没有看到我？
系统认为我选中了什么？
系统识别了什么手势？
最终执行了什么结果？

虚拟设备层是为未来硬件预留接口

目前项目中的灯是 Python 变量模拟的：卧室灯：开启 / 关闭

未来可以替换成： Python→ 串口 / WiFi / MQTT→ STM32 或 ESP32→ GPIO→ LED、继电器、真实灯光

重要思想：

先做软件原型验证交互逻辑，再接入硬件执行层。

这样开发风险更低，也更容易逐步升级。

打包失败不是“项目失败”

今天遇到的 PySide6、OpenCV 缺失问题，本质是：运行环境≠打包环境

一个 Python 项目能运行，不代表打包后的 exe 一定带齐全部依赖。

我学到的处理方式是：

使用同一个 Python 环境安装依赖。
用requirements.txt固定依赖列表。
打包前验证关键库能否导入。
PyInstaller 打包时显式收集复杂库，例如 PySide6、MediaPipe、OpenCV。
复制程序时复制整个dist/SmartHomeAI文件夹，而不是只复制 exe。

这是一种很重要的工程意识：让别人也能运行你的成果。

Vibe Coding 的正确使用方式

Vibe Coding 不是“不需要理解代码”，而是把 AI 当成一位高效率的开发伙伴。

我需要负责：

明确产品要解决什么问题。
判断界面是否美观、交互是否自然。
提出真实需求和反馈。
运行、测试、截图、定位问题。
理解核心模块之间的关系。

AI 可以帮助我：

快速生成代码骨架。
修复错误。
设计界面。
重构项目结构。
编写打包脚本和说明文档。

最重要的能力不是记住每一行代码，而是学会提出清晰的问题：

我想做什么？用户如何使用？系统如何反馈？未来如何扩展？

我当前掌握的技术地图

Python├── OpenCV：摄像头与图像处理├── MediaPipe：手部关键点检测├── 几何规则：手势识别├── PySide6：桌面软件界面├── PyInstaller：打包 Windows 应用├── 软件模块化：分离视觉、逻辑、设备、UI└── 未来 STM32 / ESP32：真实硬件控制