记录第一个接单的两天:网页控制单片机电机与摄像头项目

Day 1

抱着试一试的态度,在小红书上无偿帮助了一个人做单片机程序,但是对方实在过意不去,给了我四百块,由此我萌生了接单的想法,把成功案例拍照挂在了海鲜市场上.或许是对新用户有照顾,没几个小时就接到了第一单,要求是一个单片机项目如图 ,需要我写网页控制电机转动和摄像头拍照.当时我认为这很简单,思路是前端 react+vite 搭网页,后端用 python 通过串口与单片机通讯,单片机烧录相关电机驱动和摄像头联网代码,这就完成了需求.预计工时不超过三小时,于是询问预算之后我开价三百,对方就付钱了.(写本文时我还没收到,因为我还没发货,这个后文再提).

事情开始进行的很顺利,网页我熟练的写完了,后端也是.拿到硬件和烧录器之后,电机通过串口控制也很快写完,期间遇到一点小麻烦,ai 写的 uln2003 驱动电机代码有问题,不过我用循环步数很快解决了 ai 的问题,使用 pio 进行编译和烧录.自己购买的 stlink 不能直接串口通信,因此遇到了一点麻烦.之前对这块板子经验比较少,查资料找到串口之后,自己焊接了四根杜邦线引出串口通信引脚,用 cp2102 USB 转 TTL 连接,终于还是顺利实现了前端对电机的控制.到这里其实初见端倪,ai 写这么常见的硬件驱动代码都有问题,后面本应该多注意的.

摄像头是 esp32-cam,这里 ai 写的驱动代码也有问题,我一直停在服务器无法访问 502 的错误上.502 错误其实有两种,一是无法访问,二是过于繁忙.通过sudo nmap -sn 192.168.229.0/24扫端口,nmap -p 80 192.168.229.184查端口连通性,发现可以联通,但是仍然错误.ai 也没有好办法,但是它反复提到例程.我回想起来之前没有 ai 的时候做单片机确实是从例程改一改抄一抄现用的,于是我决定回到传统办法,从例程开始.装好了 arduino 的 esp32 环境(注意修改 arduino--preferences--Network 里面的代理,即使我有全局环境变量

$ cat /etc/environment | grep "7890"
http_proxy="http://127.0.0.1:7890"
https_proxy="http://127.0.0.1:7890"
HTTP_PROXY="http://127.0.0.1:7890"
HTTPS_PROXY="http://127.0.0.1:7890"

,但是这里似乎需要单独设置). arduino 没有现成的摄像头例程,但是服务器例程可用,我改了一下 HelloServer 的例程果然可以访问视频流了.但是拍照的 url 还是有 502 错误,这里就是过于繁忙的错误,在前端加了视频流与拍照互斥之后就解决了.至此,大概用时四个小时(不算取快递和微信沟通).我自信满满觉得可以发货收工,拍了演示视频.

到晚上十一点,客户突然提到要求适配她之前论文里写到的程序,要求那个安卓手机 APP 的控制和网页控制要共存.我询问有无 APP 源码,询问三次未果,均被忽视.她只把 APP 发过来,还有她原先就有(但是之前完全没提到的)esp32-cam 驱动代码和 stm32 的里面的程序.第一天就此结束.

Day 2

既然要共存,我的想法是只要改一下 api 接口,之前的前后端完全可以直接复用.于是我开始分析他的代码. 那个 esp32-cam 代码是一个美国人写的例程,api 写的很好,能直接替换我的 api.而 stm32 代码则是 keli 项目(下次应该首先根据文件结构判断项目类型,我错误判断为 stm32cubeide 项目又浪费了几十分钟,而且因为有 linux 依赖所以有些排斥 windows)我按照要求抹除了昨天我写的代码,烧录进她的程序.她给我一份 APP 组网说明,大意是需要手机设置特定热点的 SSID 和 passwd,然后就能控制.还补充道,板子上的按钮用来控制电机.没有其他有用的消息了.实际上上电之后按钮并不能控制电机,这让我疑惑.而且,手机显示热点已连接 esp 设备(那块 8266)之后,仍然无法控制,这让我更疑惑了.询问控制方案,回答是"用 WIFI 呀"这简短的话.然而,偶尔切换电源供电,重启手机应用,按 reset 几秒就能控制了,但是这些方法没有一个能稳定复现.我想过可能是电流不足,或者网络不稳定.首先换上了更多的电源确保电流充足,其次我尝试用抓包工具分析手机与 8266 间的通信,试了快一个小时用各端各种组网方式和抓包工具均无结果.只有连接我的主手机才能控制.为什么呢?控制变量只剩下互联网连接这一项.我想起来她的 stm32 项目名字是 OLED,里面有很多 OLED 相关代码,还有 usart 之类的东西,也许这里其实并不完全都是多余的.看到奇怪的aliyun.c,我开始怀疑其实 8266 实际上需要连接互联网才能进行控制,而不是她所说的组网.果然,里面是通过手机 APP 上传给阿里云 mqtt,再从那里订阅获取控制指令给 esp8266.而实体按键控制需要在 mqtt 连接成功后才启用,怪不得通电无法直接使用.之前的控制问题原来也是因为阿里云服务器返回消息到 esp 需要时差,才导致即使 esp 已经联网也不能控制.我试图用不同 id 向阿里云 mqtt 订阅,结果是不成功,发送也无法发送,因此怀疑是白名单制度.现在向她再次询问 APP 源码或者是阿里云账号,至今没有回复.

现在我实际收到的是这块板子,以上的经验,和 0 元钱.

更新:抓包其实是可以抓到的,密码并没有用来加密 http 的上传,而是用于服务器端的连接验证.这里就是因为没学过网络基础模型而犯的错误.应该记住常见的本地发送端口,手机作为联网设备也是应用和电脑一致的约定端口规则.要谨记这些重复出现的约定端口.比如向 mqtt 服务器的通信发送端口一般约定为 1883.这样可以在抓包得到的数据中快速筛选有用的信息.

总结

让 ai 根据我手打的真实经历总结

好的，根据你这篇接单经验，总结几个关键教训如下：

1. 需求沟通与确认至关重要：

   • 初期需求明确：在项目开始前，务必与客户充分沟通，获取所有已知需求和约束，包括是否需要兼容现有系统、是否有未提及的旧代码或特定硬件行为。避免在项目进行中或后期才暴露关键需求。
   • 警惕信息遗漏：客户可能不会一次性提供所有信息，需要主动询问和挖掘，例如“是否有现有代码/APP 需要兼容？”“硬件是否有特殊配置或行为？”。

2. 技术选型与评估需谨慎：

   • 熟悉度与例程优先：在不熟悉或有风险的技术点上（如特定硬件驱动），优先查找和依赖官方例程或成熟方案，AI 生成的代码仅作参考，尤其在驱动层面。
   • 项目类型判断：快速准确判断项目类型（如 Keil vs STM32CubeIDE）能节省时间，注意观察文件结构和依赖。

3. 问题排查与调试方法：

   • 系统性排查：遇到问题时，采用控制变量法、逐步排除法。例如，网络问题从物理连接（电流）、本地网络（抓包、端口扫描）、再到外部网络（云服务依赖）逐层排查。
   • 深入分析代码：当行为与预期不符时（如按键无效、网络控制不稳定），不能仅听信客户的简略描述，要深入分析现有代码（如发现aliyun.c），理解其真实工作原理。
   • 基础知识的重要性：网络基础模型、常见端口（如 MQTT 的 1883）等知识对于分析和解决网络通信问题非常有帮助。

4. 项目管理与风险预估：

   • 警惕需求变更：对于中途提出的重大需求变更（如适配旧 APP），要重新评估工作量、技术可行性，并与客户明确沟通可能带来的影响和额外成本。
   • 对“黑盒”保持怀疑：当客户提供的组件（如 APP、旧代码）行为不透明且无法获取源码时，要预估到调试和集成的困难，并尝试获取更多信息。

5. 心态与经验积累：

   • 从错误中学习：每次遇到的问题和解决方法都是宝贵的经验，及时记录和反思（如本文所做）有助于未来避免类似错误。
   • 不要盲信 AI：AI 可以辅助编码，但在硬件驱动、复杂逻辑或特定场景下，其代码可能存在问题，需要人工审查和调试。

简而言之，这次经历强调了在接单项目中，清晰的需求沟通、扎实的技术基础、系统的调试能力以及对项目风险的预判都非常重要。

1. 需求沟通 & 确认：强调初期与客户的深入沟通，明确所有显性和隐性需求，警惕信息遗漏。对于项目进行中出现的需求变更，要及时评估其影响。（对应你总结的教训 1 和部分教训 4）
2. 技术选型 & 风险评估：在选择技术方案时要谨慎，优先考虑团队熟悉度高、有成熟例程的方案。对 AI 生成的代码要持评估态度。识别项目中可能存在的“黑盒”部分（如客户提供的无法获取源码的 APP），并预估风险。（对应教训 2、部分教训 4、部分教训 5） 设计, 实现 & 集成：在编码实现阶段，AI 可以作为辅助工具，但其产出必须经过人工的严格审查和调试。采用逐步实现、模块化的方式有助于管理复杂性。（对应部分教训 5）
3. 调试 & 问题排查：遇到问题时，采用系统性的排查方法，如控制变量法、逐层分析（从物理连接到网络服务）。深入阅读和理解现有代码（即使是客户提供的）至关重要。扎实的计算机和网络基础知识能极大帮助定位问题。（对应教训 3）
4. 测试 & 客户反馈：进行充分的内部测试，并及时向客户演示成果，收集明确的反馈，这是迭代和完善项目的基础。
5. 总结经验 & 持续学习：每个项目结束后，都应该花时间记录遇到的问题、解决方法以及整个过程中的得失，从中学习，避免未来犯类似的错误。（对应部分教训 5）