之前玩STM32的USB时，我顺手做了一块类似手柄的板子，刚好上面留了一个OLED的接口。于是，一个想法诞生了：用MCU+OLED+按键的组合，试试看让AI帮我写一个贪食蛇游戏。
说干就干。基础的驱动已经准备好了，主要包括OLED显示和通过74HC165读取按键状态，这些代码都放在了专门的文件夹里。我打开了TRAE国内版，选择了据说性能不俗的GLM-4.7模型，准备开始“许愿”。
我的第一个提示词是这样写的，除了交代清楚硬件连接和驱动位置，我还特意要求它先别急着写代码，而是做好规划。
AI很快给出了回复，包括游戏界面的布局规划和具体的参数设计。从结果来看，规划得还挺有模有样。
规划看起来没问题，那就开工吧！AI一阵“噼里啪啦”的输出，大约五分钟左右就“写完了”。然而，编译过程并不顺利，报错了。经过几分钟的修改，再次编译通过，烧录程序，上电！
游戏竟然真的跑起来了，甚至还实现了暂停功能。
来看一个动图演示：
等等，这不就是几分钟搞定的事吗？为什么标题里说是“三天”？故事，其实才刚刚开始。
先看一张项目文件夹的截图：
文件夹stm32_snake01是准备好的工程模板，驱动都已配置好。从02到05，看后面的修改日期就知道，我整整折腾了三天。
一切始于1月16日晚上10点47分。当时我天真地以为，顺利的话11点半就能睡觉了。我向AI提出了最初的需求。
敲下回车，AI只用了三分钟就“完工”了。我满怀期待，但还没编译，就发现不对劲。
代码里while循环的结束花括号竟然不见了！我只能手动补上。开始编译，结果又报了其他错误。
错误提示使用了未声明的变量。这属于典型的C语言编程中变量作用域和声明问题。没办法，继续修改。再次编译通过后，下载程序，终于看到了画面。
这闪烁的屏幕和“优雅”的刷新率……我试着按下按键改变蛇的方向：
这条蛇……怎么变成“斑马线”了？
我向AI指出了屏幕闪烁、按键响应慢、蛇身显示不连续等问题。AI也积极给出了优化方案。
经过几轮修改，大部分问题得到了改善，但唯独“蛇身上下移动变成斑马线”这个致命问题，AI怎么也解决不了。我甚至更换了模型，尝试了DeepSeek、通义千问，都无济于事。那种万事俱备，只欠“东风”，但“东风”死活不来的感觉，你懂吗？当时已是凌晨，心力交瘁，只好先睡了。
1月17日，我思考了一下。推测当前snake.c和snake.h的代码架构可能已经“积重难返”，让模型在原有基础上大改或许很困难。于是我新建了一个空白工程，换了通义千问模型，从头开始。
新模型一顿输出，编译运行后，同样的问题再次出现：上下移动的蛇依然是斑马线。反复沟通几次后，甚至把AI给问“死循环”了。
继续换模型。这次尝试了Kimi K2，保持工程模板不变。运行后，似乎有戏！
蛇的移动看起来正常了！但是，当游戏结束时，屏幕最上方会出现一行乱码。无论我怎么向AI描述这个问题，修改N遍后，乱码依然顽固存在。
我想放弃了，但又忍住了。
当晚，没忍住的我再次准备了一个新的工程模板，用阿里的千问模型又试了一次，问题依旧。绝望感开始蔓延。
时间来到1月19日，我不死心。我在反思：是不是我的提示词太急切了？是不是应该让AI先做好设计，再动手写代码？
于是，就有了文章开头那一版“先规划再实现”的提示词。这次，AI从功能规划到代码实现，一气呵成，终于产出了一个基本可用的版本。
但是，即便这次成功了，我也认为有很大的偶然成分。因为后来我想让AI再帮忙修改一些其他功能时，它直接陷入了逻辑死循环。
所以，就到此为止吧。
很早以前我就有一种感觉：面向底层设备的嵌入式编程，可能并非当前大模型最擅长的领域。我们应该在它擅长的领域（如代码生成、逻辑梳理）充分利用它，而在它不擅长的领域（如需要精准内存操作、时序控制的底层调试）则需要依靠传统的基础综合知识和方法论。这次为期三天的开源实战般的折腾，更像是一次探索边界的实验。当然，我的感觉不一定对。也许，是时候看看更广阔的技术世界了。
发表于 13 小时前
|
查看: 0|
回复: 0
