真不是AI不行，是它压根没被放在‘真实战场’上考过。你让它修个JSON解析器的空指针，它秒回带单元测试的PR；可一旦你说‘把整个嵌入式网关系统——20万行C代码、17个硬件抽象层、3种中断上下文、4类内存池管理——原封不动搬到Rust里，API一毛不改，时序误差不能超2微秒’，所有模型当场静音。Claude删了三遍提示词，GPT-4o卡在unsafe块边界上反复生成注释，Gemini 3.2 Flash倒是甩出2200行炫酷SVG，但没人敢把它合进生产分支。
这不是算力问题，是认知断层。AI学的是“代码模式”，工程师干的是“系统契约”。C里一个volatile uint32_t reg = (uint32_t)0x40001000;背后绑着芯片手册第87页的寄存器时序图、BootROM的初始化约束、JTAG调试器的读取限制——这些根本不会出现在任何训练数据里。它能完美复刻Rust的FFI签名，但不知道为什么那个函数必须加#[no_mangle]，更不懂为啥drop impl里漏了一行munmap就让设备驱动半夜重启。机器之心测过DeepSWE：跨文件重构任务通过率从96%掉到70%，而20万行C→Rust这种全库演进，连测试集都没法构造——因为人类自己都得边写边调示波器。
有意思的是，Anthropic那40万次Claude Code会话数据反而揭了底：真正跑通项目的，从来不是最会写async/await的人，而是那个盯着Wireshark抓包、能指着TCP重传日志说‘这里必须加backoff’的网络老炮。他可能连Rust生命周期规则都背不全，但一句‘这个回调必须在软中断上下文里执行，不能碰堆分配’，AI立刻收敛到正确路径。所以别怪AI失语——它一直在等你开口说人话，而不是语法。
这事儿其实早有端倪。2023年Linux内核邮件列表里，Linus本人就回过一封：「别指望AI替你审patch——它连CONFIG_PREEMPT_RT要不要开都搞不清，更别说判断一个spin_lock_irqsave()放错位置会导致音频卡顿还是USB掉线。」这不是杠，是实打实的反馈。去年Red Hat工程师团队做过对照实验：让Claude-3和资深内核开发者各自处理同一份ARM64中断嵌套bug报告，AI生成的5个修复方案里，3个在QEMU里跑不过10秒，1个绕开了问题但引入了timer jitter，只有1个勉强能用——而人类只用了7分钟，靠的是看dmesg里那行“irq 42: nobody cared”，再翻SOC厂商的errata文档第B.3.1节。
更现实的卡点其实在流程里。嵌入式项目上线前得过三关：静态分析（Coverity）、硬件在环测试（HIL）、功能安全认证（ISO 26262 ASIL-B）。AI写的Rust绑定层，Coverity直接报27处“untrusted pointer dereference”；HIL台架上一跑，CAN总线误帧率从0.001%飙到1.2%，因为AI没意识到Rust的Arc<T>在中断上下文里会触发spinlock争用；至于ASIL-B文档里的“failure mode effect analysis”表格？目前所有大模型生成的FMEA条目，92%被TÜV南德的审核员当场标红——不是逻辑错，是根本没覆盖MCU的Flash写保护失效场景。
所以现在真正落地的AI辅助，反而是最土的那部分：TI的CCS IDE里，AI插件不帮你写驱动，只把《AM62x TRM》第12.4.2节的时钟树图自动转成dot脚本；NXP的MCUXpresso里，它不碰FreeRTOS源码，但能把你手写的task_create()调用，实时映射到对应SDK版本的configTOTAL_HEAP_SIZE计算公式里。说白了，AI在当“人肉手册索引+计算器”，而不是“替代工程师”。
最近华为鸿蒙团队公开过一组数据：在OpenHarmony 4.1的分布式软总线模块重构中，工程师用CodeWhisperer辅助写Rust FFI层，代码产出快了3倍，但关键路径的时序验证时间反而多花了11天——全花在反复校准示波器探头接地、重烧OTP熔丝、比对JTAG trace buffer原始dump上。他们总结就一句：“AI能写出语法正确的unsafe，但安全的unsafe，还得人来签那一行// SAFETY: xxx”。
技术没有银弹，但人有手感。那种摸一下PCB就知道晶振偏频、听一声UART波形就能断定电平阈值漂移的手感，算法学不会。它只能学我们怎么描述这种手感——所以下次别问“AI能不能干”，先想想你怎么把“示波器上看到的毛刺像被狗啃过”翻译成它听得懂的信号特征。毕竟，真正的智能，从来不在模型里，而在你开口说话的那一刻。
嘉多网提示：文章来自网络，不代表本站观点。
