9月12日上午10点11分，B站UP主"我认识派大星"发了条169秒的视频，标题是《嵌入式开发，越用AI效率越慢》。10点17分，隔了6分钟，另一个UP主"欧工Ai"发了条122秒的《现在AI开发嵌入式代码效率有多离谱？》，标签里挂着STM32、无刷电机、FOC、Codex。
同一天、同一个板块、结论完全相反。"慢"那边的评论区只有一条高亮回复：那不还是不熟悉AI代码吗？而真正热闹的战场，在4月份一条5.5万播放的《我搭建了一套让AI自动完成嵌入式开发、烧录、调试闭环的技能库》底下——有人在晒自己手搓的Keil自动化Agent，有人在求CH32的makefile支持，也有人留下了一句很沉的话：哔哩哔哩
用AI写了几千行的代码就有一堆问题，用AI检查根本没用，要人工一行一行纠错。我用AI写了30万行，检查了三个月，还在纠错，用的工具是Opus 4.8 Max与Codex Extra High。
工具顶配，人磨到三个月。 另一边的UP主却在喊"离谱"。嵌入式这个圈子里，AI编程的产出方差确实比以往更大。9月1日有条微博（257赞）点破了这个现象。 8月31日另一条（195赞）补了老炮心态：越是编程经验丰富，越是不放心放手让AI去写代码和验证，像带实习生。 为什么到了单片机这儿，同一把刀有人砍柴有人绣花？我把这一周多平台上的争论、案例和开源仓库翻了一遍，发现分歧不在"用哪家模型"，在三笔账上。算不清这三笔，换什么模型都是越用越慢。哔哩哔哩微博微博
01｜第一笔账：反馈链路，AI在硬件面前是瞎子
纯软件开发的迭代是改代码→跑→看报错，几秒一圈，AI一晚上能自己磨几十轮。嵌入式的迭代是改代码→编译→烧录→上电→观察现象，每一步都是摩擦力。 不把这个环路交给AI，AI就快不起来——这是知乎那个问题下高收藏回答的核心逻辑。知乎
有个案例把这件事讲得很透。一位做了多年固件和驱动开发的工程师（知乎专栏《嵌入式开发的经验壁垒正在被AI瓦解》，7月14日）讲了他处理I2C总线挂死的经历：这活儿以前要有经验的工程师拿示波器、逻辑分析仪对照协议手册逐段分析，花几天到两周不稀奇。这次他把逻辑分析仪波形截图、I2C协议白皮书、控制器寄存器手册、驱动源码一把全喂给AI Agent，AI给了5个候选根因、按概率排序，他按序验证，第二个命中，全程不到半小时。知乎
注意这个案例里发生了什么：AI并没有"看见"总线，是人把硬件世界翻译成了材料再喂给它。波形截图、手册、源码——这就是嵌入式AI编程和前端AI编程最大的区别：AI写寄存器配置代码是快手，判断"这颗板子上电到底发生了什么"是瞎子。所以"离谱"和"越用越慢"两条路都是真的：你喂给它的反馈越接近代码，它越快；你的问题越依赖物理信号，你越累。
02｜第二笔账：闭环——分水岭就是那行 verify()
上面那位把闭环方法论讲得最具体的高收藏回答作者"李尔"，给了嵌入式圈里传播很广的一套配方，值得抄作业：
编译脚本化：不依赖IDE，Keil的UV4.exe本身支持命令行，配合CMake/Makefile让AI能自己发起构建；
烧录脚本化：先写好Bootloader，不需要J-Link，一根几块钱的CH340 USB转串口走IAP就能烧；
验证脚本化：烧完保持串口常开，持续读设备回传的帧数据，用一个 verify() 函数判断这轮成没成——返回False，AI不问你，自己回到改代码重开一轮。
他给的温度补偿例子很具体：读数偏高约3度，AI第一轮改了 dataprocessing.c 的 TEMPOFFSET（5→1）和 paramsmanage.c 的 ADCGAIN（1.0→0.98），第二轮串口确认AC04帧稳定在25.1°C，然后才来汇报"闭环完成，经过2轮调试"。人只出现在起点（提需求）和终点（收结果）。知乎
这条路的可行性不是一个人说了算。上面那个5.5万播放的视频评论区已经形成了自传播：有人开源了覆盖Keil/IAR/CMake/PlatformIO多工具链构建、烧录、GDB调试、串口监视、Modbus/CAN协议调试的 embed-ai-tool，有人做了让LLM直接调PID参数的 llm-pid-tuner（智能车、电赛的刚需），还有UP主做了带Agent的QT IDE，"分析→改代码→编译→Debug验证"全自动。评论区也有人直接说：我现在就这么用的，Codex自己写、自己看日志、自己改。 开源仓库里这套东西已经长成了目录：嵌入式skills项目（embeddedskills）把底层工具的命令行参数和交互流程封装成结构化子命令。 在配好的 config.json 里，工程路径和烧录参数就摆在 build.log、flash.log 旁边。哔哩哔哩GitHub
对照一下阵营划分就清楚了：还停在"AI写一段、人编译、人烧录、人看现象"的，迭代速度被手动摩擦卡死，越用越慢是必然；把编译-烧录-读回三环脚本化、再给AI一个自己敢信的判断函数的，效率才会"离谱"。9月12日那两条对立视频，大概率就是站在了闭环的两侧。
03｜第三笔账：验收标准越硬，AI越猛；约束越藏，越翻车
知乎8月31日有个挺火的问题："怎么看OpenAI让AI写内核汇编级代码，工程师自己都看不懂？"有个回答值得细读：OpenAI给自家Jalapeño芯片适配DeepSeek MLA内核时，让Codex用低级语言Gluon自己写了3000行kernel，工程师自己都解释不清每行在干嘛——但它能上线，因为旁边架着参考实现、输入输出规格、自研sanitizer和一个与真实硬件误差约5%的chilisim模拟器。 结果错误、超时、更慢，方案就淘汰；又对又快，就保留。这个判断挺反常识：越底层，任务边界越窄、验收越清晰，LLM反而越友好。知乎
有研究数据撑腰。知乎8月20日一篇《AI冲击下嵌入式软件领域全景研判》转述了一项10个大模型生成汽车C程序的测评：简单模块800次尝试成功验证540次，约67.5%；换成带时序约束的复杂模块，只剩46/800，约5.75%。 注意这是二手转述，原始出处是国外测评，精确值建议自行交叉验证。AI的提效幅度和"隐藏约束的数量"成反比，和"代码难度"关系不大——时序、功耗、电气特性这类没写进需求的约束，才是AI看不见的坑。知乎
所以翻车样本全在约束缺位的地方。B站技能库视频评论区那位吐槽豆包和GLM的朋友：「连数据手册都不查，直接gpio i++」，加了个功能发现引脚不够用，AI开始自己头脑风暴停不下来——没有资源约束清单，AI就替你"自由发挥"。反过来，能放心交给AI的活儿其实很整齐：外设初始化样板、寄存器配置、把两千行的main.c做静态分析和模块化拆解、串口日志和协议文档解读；必须自己拍板的是引脚与电源资源分配、时序预算、“待机电流多少”“量产后bug怎么hotfix"这类真产品问题——某位做了八年面试官的工程师（同上篇研判转述）半年面47个候选人，几乎人人简历写着"熟悉STM32”，这两个问题能答上来的不超过5个。这两道题，恰恰也是AI目前答不了的。哔哩哔哩知乎
04｜老炮的正确姿势：把经验写成AI读得懂的证据链
8月31日那条"越有经验越不敢放手"的微博，评论区吵的就是：经验在脑子里，AI拿不到，你当然不敢放手。这件事已经有人做了标准答案。
RustSBI团队8月底开源了 embedded-hal-skills：把团队6年裸机芯片开发经验——BootROM分析、HAL库、提交规范——翻译成一套AI能逐步执行的Skill，关键设计是给每条指引标了证据等级：强制规范、指南、项目实践三档分层。AI因此"知道哪些是必须遵守的，哪些只是经验之谈"，不会把别人的芯片设计讹传照搬到你的板子上。中科院软件所和华中科技大学是社区支持单位，MIT/Mulan-PSL v2.0双协议。知乎
这套思路对两类人都是路线提示。对个人：你的护城河不是"会调HAL库"那部分——那部分AI三个月内人人都会；是"待机电流、量产返修、时序边界"那部分，把它写成文档、写成Skill，才是把第十年叠成一座山而不是第一年重复十遍。对企业：9月9日B站就有人提问：嵌入式企业用AI，保密和开发效率怎么兼顾？ 国内工具链路径其实已经有人实测过：知乎"阿Q在江湖"的逆变器系列（6月24日）结论是——Qoder插件市场可直接装Keil Assistant，Trae要手动装.vsix，CodeBuddy装完编译/下载图标渲染异常。Keil Assistant是VSCode插件市场上的免费插件，下载量自述超过41万次。 日常用Qoder或免费的Trae写代码，它负责编译下载，ST-LINK烧录，CubeMonitor观测——作者的背景是：国内环境下本来就调用不了GPT、Claude等国外模型，这条路等于把"国产AI IDE + 传统嵌入式工具链"焊在了一起。哔哩哔哩知乎
05｜按你现在的位置，抄这三份作业
在校学生/电赛/自制党：先别买课——这周B站刚有人发帖，标题就叫被坑6800买的AI测试课程、免费分享。 同类内容在公开视频和开源仓库里全都有。第一步把"编译-烧录-串口"三件套脚本化，CH340二十块钱以内；嵌入式AI和点灯AI的差距就在这，不在提示词。哔哩哔哩
1-3年MCU工程师：给每个模块补一个验收函数再谈提效。让AI引用数据手册页码后再写配置代码，别让它"背"寄存器；重复劳动（外设初始化、驱动骨架、测试用例）交出去，引脚表、功耗预算、时序自己攥着。
5年以上老炮/小团队：把你排查过的I2C挂死、ADC漂移、烧录变砖案例，整理成带证据等级的文档或Skill——参照embedded-hal-skills的结构。这是唯一一件"你越老越值钱、AI越强你越值钱"的事。
继续观察的信号：逻辑分析仪、示波器厂商级MCP什么时候跑通——现在大家还在人工截图喂波形，那位处理I2C的工程师早就说过：要是后续再开发出针对逻辑分析仪软件的MCP，那就更强大了。 芯片原厂会不会官方下场发机器可读手册和配套Skill；"30万行、纠错三个月"式的大库存量项目会不会出现AI可接管的分层审计方法。这三件事任何一件落地，上面三笔账都得重算。知乎
9月12日那两条对立视频互动都不高（点赞8和20），但它们底下站着的是同一批正在切换工作流的嵌入式人。你是哪一边——“离谱"还是"越用越慢”？评论区聊聊你卡在闭环的哪一环。
注：文中视频播放、点赞等互动数据为9月13日采集快照；"67.5% vs 5.75%"测评数据与"47个候选人"案例均为知乎公开文章转述，原始出处未经一手核实，量级供参考。
