作为一个接了十多年各种奇怪外包项目的程序员我最近完成了一个挺有代表性的单子一套商用弹珠机控制与计分系统客户预算4万合同期限20天。项目本身不算大但时间压得很紧还要全程兼顾硬件选型、固件开发、上位机管理端和现场联调。我在这20天里大量使用了AI辅助编程从协议解析到界面开发再到调试脚本差不多把“AI提效”四个字榨干了。这篇文章就把这个项目的完整过程写出来——需求怎么拆、架构怎么定、AI在哪些环节真正帮我省了时间、哪些环节它完全帮不上忙以及最后交付时那些容易被忽略的坑。想用AI接小项目、做硬件控制类外包、或者单纯对“AI到底能不能在真实项目里提效”感兴趣的程序员应该都能从里面找到点能直接用的东西。1. 接到这个4万弹珠机项目需求边界与报价逻辑1.1 这个弹珠机到底是什么客户是一家做商场礼品机运营的小公司手里有一批现成的机械弹珠机机箱透明的亚克力罩、金属轨道、弹簧发射器、一整排落珠槽位玩法就是投币后拉动弹簧弹珠沿轨道滚上去掉进哪个槽位就对应哪个奖励。传统版本是纯机械的玩久了挡板会变形、卡球、掉珠位置随机性变差运营方想升级成“电子控制版”增加传感器检测落珠位置用电磁铁或者舵机控制挡板复位加上一块液晶屏显示得分和奖品等级同时把每台机器的投币次数、中奖记录通过网线上报到后台管理系统。说白了这是一个典型的“机械硬件嵌入式软件上位机管理软件”的小型综合项目。客户自己有机箱和机械结构我负责电子控制系统、固件、上位机管理后台、现场安装联调四部分。4万块钱看着不多但如果只做软件部分其实是够赚的难就难在跨了硬件边界。很多程序员一听“弹珠机”就以为是写个游戏实际完全不是这个项目的核心在于传感器信号处理和设备通讯的稳定性。1.2 报价拆解与工期测算签合同之前我按模块把工作量和成本拆了一遍。电子控制系统按一台3套计算ESP32主控板30块一套传感器、电磁铁驱动板、电源模块等元器件大概200块一套三套硬件成本不到800块。后台管理系统用B/S架构部署在一台阿里云轻量服务器上一年几百块。剩下的空间全是人力成本固件开发、上位机开发、现场安装调试、往返客户仓库的车马费。工期拆成20天其实非常紧。我的实际排期是硬件样板制作和传感器选型4天固件协议层和状态机开发5天上位机管理后台5天硬件组装和整机联调4天最后留给现场部署和交付验收2天。听起来每块都有富余但中间一旦遇到传感器误触发、电磁铁过热、现场网络不稳之类的问题20天根本兜不住。所以我从一开始就决定凡是代码逻辑上能用AI压缩时间的环节绝不手写。1.3 项目范围里的“隐形需求”这类商业项目最麻烦的不是明面上的功能而是合同里没写但运营方必然要用的东西。第一防作弊。弹珠机的奖励是实物的运营方最怕玩家通过某种方式预判落点或者控制弹珠轨迹技术上必须保证传感器读数不被人为干扰而且后台要有异常检测比如单台机器某时间段内中大奖次数突然变多系统要能告警。第二掉线自恢复。商场里的网络环境很复杂Wi-Fi信号被促销展架挡住是常有的事设备必须能在网络恢复后自动补传数据。第三售后维护。客户不会写代码机器的故障提示必须直观——屏幕上直接显示“传感器2异常”而不是啥错误码人工一看就知道哪个部件出了问题。这些需求在写进合同之前我全都列成了文档逐条跟客户确认过。这一点我强调过很多次4万的小项目也要按正规项目的方式做需求确认否则后面每改一条需求都是在消耗本来就不富裕的20天工期。2. 选型定架构为什么是ESP32加B/S管理端而不是全集成方案2.1 控制系统选型对比弹珠机的控制系统选择有很多最常见的有三套路线51/STM32单片机、ESP32模组、树莓派加继电器板。这三条路线的取舍很直接。单片机方案成本最低、最稳定但有个致命问题它没有原生网络能力。弹珠机需要实时上报数据到后台如果是我自己玩或者做单一设备MCU方案完全可以接受。但商用运营是几十台设备分布在不同的商场没有网络等于残废再加一块串口Wi-Fi模块的话稳定性又要重新测试会占用大量本就不够的工期。树莓派方案开发效率最高Python写控制逻辑舒服得很IO口也够用但成本太高——现在一块树莓派几百上千而且它的定位是微型电脑用在商场设备上大材小用不说TF卡在震动和断电场景下特别容易损坏机房运维最怕这种不确定的存储故障。ESP32是我这个项目选的方案。它带Wi-Fi和蓝牙价格只有十几到三十块GPIO数量足够驱动传感器和电磁铁支持Arduino框架和ESP-IDF开发效率接近树莓派但成本远低于它。更关键的是它支持OTA固件升级设备部署到现场之后我不用亲自跑到商场插USB线改程序。对比一下ESP32用在这里几乎是量身定做的。方案成本网络能力开发效率适合场景STM32/51极低需外接模块低无联网需求ESP32低原生Wi-Fi高本类项目首选树莓派高原生最高样机/高复杂度2.2 弹珠机执行机构与传感器清单弹珠机最常见的两种落珠检测方案是光电对射传感器和微动开关。光电对射传感器检测弹珠经过时对光路的瞬间遮挡优点是响应快、无机械接触不存在磨损问题。微动开关装在落料槽底部弹珠撞上去触发开关闭合逻辑更简单但存在寿命问题——商用机器一天几百次触发机械结构很快就会疲劳损坏。我在这个项目里选了光电对射传感器作为主要检测器件每台机器有4个落珠槽位所以每个槽位上方装一组对射传感器。发射端是红外LED接收端是光电二极管弹珠从中穿过时接收端信号会产生一个由高到低再回到高的脉冲固件检测到这个脉冲变化就判定有弹珠落入。同时考虑到商场环境有大量红外干扰源传感器模块外面加了一层黑色热缩套管做遮光处理减少误触发的概率。执行机构方面选择了电磁铁推杆而不是舵机原因是弹珠机落珠挡板的动作需要瞬间完成舵机的转动速度不够快弹珠已经滚过去了挡板还没到位。电磁铁通电瞬间就能把挡板顶出去响应速度在几十毫秒级别配合传感器检测到弹珠到挡板顶出的时间窗口完全来得及。当然电磁铁也有问题后面章节我会重点说它的发热处理。2.3 通信协议与主控固件职责划分主控固件的职责边界我在动手写代码之前就划分得很清楚传感器扫描、电磁铁控制、显示驱动、设备状态上报这一层尽量做得薄只做数据采集和指令执行。业务逻辑像奖品等级判定、概率控制、异常检测这些一方面在固件里保留基础版本作为离线兜底另一方面完整版本放在上位机后台做这样将来调整运营策略比如把一等奖概率从1%改成0.5%不用重新烧固件直接在后台改配置就行。通信协议我用的是一套简单的JSON-over-TCP方案。设备端主动维持一个到后台服务器的长连接每隔5秒发送一次心跳心跳包里面带着设备ID、当前状态、传感器读数、累计投币数和中奖记录。服务器返回指令帧包含下发配置中奖概率、增益参数、强制停机等和任务指令。这套协议写起来其实不需要我盯着琢磨太久真正的功夫在边界情况的处理连接断开要自动重连断开期间的投币和中奖数据要本地存储等网络恢复之后补传防止商场掉电断网的时候数据丢失。这些逻辑如果用传统方式手写估计要两三天我当时是把通信协议文档和ESP32的SDK文档一起扔给AI让它按我的要求生成底层连接管理模块然后人工审查最关键的重连和补传部分。2.4 上位机管理端的功能设计上位机管理端我做的是B/S架构后端用Node.js加SQLite前端直接上了Vue3加ElementPlus部署在一台云服务器上。麻雀虽小五脏俱全这个后台需要管的事情不少设备列表和在线状态、实时游戏事件流、中奖记录查询、设备的参数远程配置、异常告警列表。这里我要提一个管理后台的常见误区很多人在这种小项目上会把后台做得过于复杂——又是用户角色管理又是报表图表大屏结果后台开发时间比设备端固件还长。商用弹珠机运营方真正需要的只有两个核心页面一个地图或列表页面显示几十台机器的实时状态一眼能看出哪台掉线、哪台传感器报警另一个是中奖和营收记录页面能按天、按机器筛选能导出Excel报表。其余的功能都是锦上添花。就这两个核心页面加上设备端心跳与数据上报接口再加上一个简单的管理员登录认证我用AI辅助自然语言描述组件功能让它生成Vue代码模板加人工调样式两天多就把整个后台从零跑通了。如果按传统工作流白手写估计要一周往上了。3. 让AI真正提效我把开发任务拆成了四条流水线3.1 协议层代码AI最擅长这类“翻译工作”这个项目里AI提效最明显的部分就是协议层的代码。通信协议本质上是一份规范文档翻译成代码的过程字段怎么定义、帧格式怎么组装、校验和怎么计算、异常怎么处理这些内容没有复杂的算法和隐性的业务逻辑天然适合AI生成。我处理的时候是这么操作的自己先把协议的所有字段和状态转换整理成一份很详细的Markdown文档字段名、类型、取值范围、默认值、异常含义全部写清楚。然后在这份文档的基础上把ESP32侧的网络通信库说明文档、JSON序列化库的API文档一起扔给AI让AI生成对应的通信模块代码。这里有个经验值得重复一次AI生成代码的质量上限取决于输入上下文的完整度而不是提示词本身有多炫酷。你给它一份字段名都含糊不清的协议让它写代码不管提示词怎么优化生成的代码都会缺三少四。相反你的协议文档写得越像正式设计文档AI生成的代码越接近可以直接编译的成品。我用这个方式拿到的ESP32网络通信模块基本上一遍过了编译只有两处类型问题需要手动修正。3.2 状态机与业务逻辑提示词要信息量足够弹珠机的运行状态说起来简单但真正写成状态机也有一堆分支。游戏状态我分成待机、发射中、弹珠移动中、落珠判定、奖励发放、故障暂停六个状态每个状态之间的转移条件都跟传感器信号、定时器和指令有关。状态机的代码结构并不难难的是不要漏掉边界情况。举例来说弹珠从发射到落槽这个过程中最多允许几秒如果玩家把弹珠卡在某条轨道上不动超过这个时间就必须强制判定为无效发射并把弹珠回收。再比如玩家操作过程中断电了掉电瞬间已经发射的弹珠怎么处理要不要做掉电恢复这个项目的答案是不要——商业弹珠机的单次游戏时间很短掉电恢复逻辑会显著增加固件复杂度直接把本次数据标记未完成等玩家下次游玩时自动恢复可用状态。状态机这块AI能帮的忙不是生成代码本身而是帮你查漏。我的做法是把状态表、转移条件、边界场景按非正式文档整理出来扔给AI让它列出所有它认为可能遗漏的边界条件。这个环节通常能挖出几个自己完全没考虑到的场景比如弹珠在传感器位置来回滚动导致重复触发、投币后玩家迟迟不发射导致的超时处理。这些场景再反过来补充到状态机里设计的完整性提升很多。3.3 上位机界面与后台管理AI在Web端的浓度最高前端开发是我个人在这个项目里痛苦度最高的部分我对Vue3生态没那么熟CSS布局和组件细节很容易写崩。这次借助AI从零开始做后台基本没太受折磨。细节是这样执行的我按页面拆分成独立任务每个页面的需求用几百字描述清楚包括布局结构、哪些字段、哪些按钮、交互逻辑然后让AI生成Vue3单文件组件初版。组件出来之后我人工跑起来看有问题再针对性反馈给AI让它修改。迭代三轮之后一个“设备状态列表页”基本就是可用的状态了。这个工作流能跑得通前提是你对HTML和CSS本身要有足够的基础能判断AI生成的布局是不是合理、结构是不是能改。纯小白拿着AI生成的代码大概率会在某个增删改查功能上卡死——不是代码跑不起来是不知道改哪里。我见过不少朋友抱怨AI生成的前端代码“看着很好一改就崩”多半是缺乏前端基础导致的。3.4 多AI协作的真实分工这20天里我不止用了一个AI工具不同工具用在不同的场景。写固件和网络通信模块的时候我用的是在嵌入式代码库上训练效果较好的代码生成助手写Web前端和后台管理接口时用通用大语言模型效果更好还有一个专门的AI工具负责把串口日志和后台数据库记录转成可视化报表帮我分析设备现场运行数据对应的规律。为什么要多AI协作而不是一个工具通吃因为不同工具擅长的事情确实不一样。嵌入式工程代码的AI在日常编程对话中回答质量更高包括内存管理、中断优先级、外设配置这些细节比通用模型专业得多。而Web前端和界面设计通用大模型对Vue生态的理解更深生成组件的灵活性明显好于偏嵌入式的工具。这个经验归纳一下就是围绕一个大项目干活不要把AI当成一个入口而是每个环节选最适合该环节的工具。你不用真的订阅十几个AI服务大部分重度环节两个工具就够关键是让工具匹配场景而不是反过来强迫一个工具做所有事。3.5 一个AI帮不上忙的环节机械结构与现场布线说实话如果只做软件部分这个项目我估计12天就能交付。真正吃掉工程量的全在软件和硬件交界的地方而这里的核心决策AI一点忙都帮不上。比如传感器安装的高度。装高了弹珠飞过时遮挡光路不够充分信号脉冲过窄容易被滤波逻辑当作干扰吞掉。装低了弹珠碰撞到传感器支架导致弹珠路径偏离影响游戏公平性。这个位置只能是拿游标卡尺在现场反复量、反复试出来的没有任何AI能代替你做出这个决定。再比如电源线的走线。电磁铁通电瞬间的电流能达到2到3安如果跟传感器的信号线绑在同一个线槽里传感器信号会被严重干扰轻则读数异常重则直接误判中奖。这时候唯一的解决办法就是信号线和动力线分开两边走中间留足间距。这些物理世界的规则AI再强也没办法隔着屏幕帮你判断。4. 弹珠机的物理特性传感器、电磁铁与概率公平的坑4.1 传感器误触发与消抖弹珠机的环境比想象中恶劣得多。商场里人来人往射灯和LED屏幕都在发射红外光光电对射传感器很容易捡到这些杂散红外信号。我把传感器装的黑色热缩套管挡掉了一部分环境光但机械震动引发的误触发是另一个麻烦——弹珠砸在轨道上会产生震动震动传导到传感器支架上会让传感器产生几十毫秒的信号波动固件里如果没有消抖逻辑这个波动就会被当成一颗弹珠。消抖逻辑我用的是“连续读取N次确认稳定电平后再判定有效变化”的方案。具体做法是传感器状态变化后先不立即确认而是在1到2毫秒后再次读取如果两次读到的状态一致再判定有效。这个时间参数在实验室调到5毫秒是稳定但拿到现场就发现不够——商场的地面有时候有低频震动会把参数撑到更宽的区间。最后我在测试模式下用实际弹珠数据回放来分析波形宽度最终确定10毫秒的确认窗口。这块我重点说一句消抖的时间窗口不是越大越好。窗口太大会把连续两颗弹珠快速通过传感器的间隔吞掉导致漏检窗口太小又抗不住环境干扰。解决方案是把消抖延时做成可配置参数通过后台下发到每台设备方便我在现场根据实际情况微调而不是把参数写死在固件里改一次就要去现场刷一次机。4.2 电磁铁击打机构与过热保护电磁铁是弹珠机里唯一的大功率执行机构。它的驱动方式也有讲究直接用GPIO驱动肯定不行ESP32的GPIO引脚只能输出几毫安的电流必须通过功率MOSFET或者继电器来切换电磁铁的电源回路。我选的是MOSFET方案因为继电器有机械触点寿命问题在每分钟几十次动作的场景下很快会老化。电磁铁最大的坑是发热。商场里的弹珠机营业时间是早10点到晚10点如果一直有人玩电磁铁每几分钟就通电一次线圈温度会不断抬升。线圈超过80度后电阻增大吸力下降挡板顶不到位弹珠就会卡在槽位边缘——这是弹珠机最常见的运营投诉来源。我在固件里加了简单的温度保护逻辑用电磁铁每次通电的时长和间隔做温度估算模型如果短时间动作过于频繁就自动降低响应速度或者干脆拒绝发放最高奖励档因为那个档位需要电磁铁动作幅度最大。这个方法不需要额外加温度传感器成本零效果立竿见影。另一个更直接的物理降温手段是给电磁铁加一块小的散热铝片这种改造在硬件上只花几块钱但对寿命提升非常明显。4.3 中奖判定与概率公平算法商用弹珠机最不能出问题的是中奖判定。如果玩家明明看到弹珠掉进了三等奖的槽位屏幕却显示“未中奖”这种事故一次就能让店铺信誉崩盘。所以落珠判定必须做到“传感器信号为准后台记录为辅”。实际工况下的问题远比想的复杂。弹珠落槽之后不是静止不动的它可能在槽位里来回弹跳几次每次经过传感器位置都会触发一次信号如果固件只做单次检测一次落珠会被记成好几次。我在逻辑里加了一个“冷却时间”字段同一个传感器检测到有效触发后接下来500毫秒内的重复触发都不再计数。这个冷却时间比弹珠在槽内的弹跳时间长能保证最多只记录一次落珠。但冷却时间也不能无限制加长否则玩家快速连续投币玩两把的时候第二颗弹珠的落珠会被吞掉。为了测准这个时间窗口我做了个很笨但很有效的实验用一台真实弹珠机发射了上千颗弹珠让AI帮我写了一个串口日志分析脚本统计每颗弹珠从首次触发到最终稳定的时间分布然后取了一个覆盖95%以上情况的值——430毫秒。这个数据是实打实在设备上跑出来的不是拍脑袋定的。另外概率公平这块也要多说一句。奖励档位的实际概率不是随机数生成器决定的而是机械结构决定的。弹簧发力大小、挡板角度、轨道摩擦系数这些物理因素决定了弹珠落在不同槽位的概率分布。固件层面的随机算法只能影响“恭喜还是谢谢参与”的判定卡片改变不了真实的物理概率。所以后台配置的“中奖概率”数据要跟实际机械概率做对照校准否则运营方设置的是30%的一等奖概率实际可能只有10%后台看到的数据就会失真。我做概率对照的方法是用积分球做批量验证连续发射200颗弹珠统计每个槽位的落珠次数然后调整挡板角度和弹簧张力让分布接近预期的比例。这个环节AI能帮的有限但日志统计脚本它能帮上不少忙——每条记录的落珠槽位、时间戳自动汇总成分布表省去了手搓Excel的时间。4.4 现场干扰与地线问题硬件联调阶段最噩梦的问题是诡异信号干扰。有一次所有传感器读数在开机后都稳定得漂亮但只要电磁铁动作一次传感器就开始疯狂误触发像直播间弹幕一样刷屏。排查之后发现是接地问题。电磁铁和传感器共用一个开关电源电磁铁通电瞬间的电流突变让电源的地电平发生波动这个波动传导到传感器信号上就变成了干扰。解决方法是把电磁铁驱动回路的电源地跟传感器信号的地分开走或者用光耦把电磁铁驱动信号隔离出来。我选了光耦隔离方案效果好不说还顺便保护了ESP32的GPIO不会被电磁铁反电动势打死。排查这种问题日志的重要性立刻凸显。如果设备没有运行日志你在现场看着传感器数值跳来跳去只能抓瞎。我当时的做法是让固件把所有关键事件带时间戳打出来电磁铁动作时间、传感器触发时间、电源电压采集值全部写到日志里。之后再排查就是把时间线对齐看干扰是不是总在电磁铁动作后的几百毫秒内出现。这种关联规律一旦定位到修复方案就是顺理成章的。5. 联调阶段的“AI盲区”串口日志、现场测试与应对记录5.1 日志设计让你少熬夜写嵌入式代码的很多人不重视日志觉得日志占用Flash容量、影响运行速度。在开发小型单机项目时这个习惯还能将就但一旦设备要部署到离你几十公里的商场里没有完善的日志就是自断后路。我在固件里实现了一个循环日志缓冲区所有关键事件传感器变化、电磁铁动作、游戏状态切换、网络重连、本地上报缓存操作都带时间戳写入日志。这些日志平时存在ESP32的片外Flash里等到有调试需求时可以通过串口导出也可以在下一次网络连接建立后自动上传到后台。日志格式我一开始设计的是“给程序看”的事件ID加数值比如EVT_231:420ms。但现场调试的时候我发现这种格式太不友好了一眼根本看不出发生了什么。后来改成[sensor3] triggered at 420ms语义化程度高了读日志的效率翻了好几倍。这个转变是被AI的一次吐槽点醒的——它看到我上传的日志样本之后反馈说“这一点都读不懂”我这才意识到设计日志格式时应该把“人在现场阅读”也当成第一优先级。现在每次做这类项目我都要求至少记录四类事件传感器原始状态变化、执行机构动作、状态机状态转换、网络连接断开与恢复。这四个维度的日志配上时间戳几乎覆盖了所有远程排障场景。5.2 现场测试的“非理想环境”清单实验室调试顺利不等于现场调试顺利。我总结了弹珠机这类商用设备现场容易踩的坑大部分都和“理想环境”和“真实环境”的差距有关。第一个是电磁环境。实验室里没有商场射灯、大型LED屏、空调压缩机的干扰传感器相安无事一到现场就疯狂误报。解决思路就是上文提到过的遮光、消抖、光耦隔离三件套。第二个是电源稳定性。商场供电线路一般能扛住常规设备但弹珠机旁边如果有大型的冰柜、咖啡机在同一个插座回路上电磁铁启动时可能直接把电压拉低导致ESP32因为欠压重启。如果现场发现设备频繁重启第一排查顺序应该是电源不要先怀疑代码逻辑。第三个是网络环境。商场Wi-Fi要求密码但设备端如果只配置了密码才能连接的办公室网络到商场就完全失联。我的方案是设备支持WEB配网现场用手机连上设备自建的Wi-Fi热点在配网页输入商场的Wi-Fi账号密码省去刷机这种蠢办法。这些坑的共同点是代码层面看不出任何问题只有拿着设备到现场跑一遍才能暴露。所以说20天交付听起来轻松实际上最后两天的现场调试才是决定成败的真正时刻。6. 交付不是代码跑通验收清单、文档与售后边界弹珠机项目的交付不是代码仓库一交就完事对于甲方来说他们需要的是能运行、能维护、能操作的一整套体系。验收清单我列了三层。第一层基础功能验收投币、发射、落珠检测、显示、中奖判定、网络上报每个环节逐项打钩。第二层异常场景验收断网恢复、传感器遮挡报警、重复快速投币、模拟卡球所有能想到的异常路径都过一遍。第三层运行稳定性验收设备连续运行72小时不重启、不卡死、不误触发。这三层全过客户才签字。文档方面我交付的东西包括固件烧录说明、硬件接线图、后台管理操作手册、常见故障排查表。特别是第四份文档价值比前三份加起来都大——因为商用设备的日常维护很可能是一个完全不懂技术的商家店员他看到的问题描述都是“屏幕提示传感器3异常怎么办”。故障排查表里就直接写明“检查传感器与主控板之间的接线重新插拔如果无效请更换传感器”。有这份东西售后电话能少接一半。售后边界更要提前划清楚。弹珠机这类非标设备我明确跟客户说的是硬件自然损坏不在质保范围内但固件和软件的功能性问题在项目验收后6个月内免费修复。这一条写进合同避免交付后客户拿任何硬件故障来要求免费维修。最后说回AI提效这件事。这次单人20天交付4万弹珠机项目AI的最重要帮助不是像很多人想的那样“一键生成整个项目”而是把那些琐碎的、重复的、纯翻译性质的编码工作压缩到了一个很小的比例。真正决定项目成败的还是对硬件物理特性的理解、对现场环境的敬畏、以及对验收和维护流程的把控。下个项目如果再来一次我会把经验往这些非代码环节再倾斜一点因为代码问题AI能解决物理世界的问题它还得靠我。