AI写代码无助于解决功耗墙问题

我注意到一个有意思的细节，这个9年iOS开发者用AI写代码2周做出游戏，但所有的精力都花在“设计图纸”上，而不是“砌砖”。

先说结论：这种100% AI生成的代码，在工程落地层面几乎不可能通过任何严肃的商业App审核。Cursor Vibe Jam是个创意比赛，不是工业标准。游戏类产品对性能、功耗、内存的敏感度远低于我们日常面对的5G基带芯片驱动。

作为在展锐干过5G基带的工程师，我看到的不是AI替代开发者，而是工艺节点的降级——从手工精调到自动布线。代码生成本质是源于大型语言模型对token的统计预测，它没有功耗墙的概念，不需要考虑3nm节点下漏电和动态功耗的tradeoff。这个游戏之所以能跑，是因为iOS生态的NSTimer、CADisplayLink这些高层API把底层硬件抽象掉了。换成任何需要精确控制时钟门控、电压频率调节的固件场景，AI生成的代码百分之百会触发看门狗。

Cursor和Copilot这类工具，给我的感觉就像先进制程里的EDA工具——它们能加速标准单元布局，但架构创新、功耗域的划分、memory hierarchy的设计，仍然要靠人类的物理直觉。这位开发者花15天做出一款游戏，本质是把时间从“写循环”转移到了“写提示词”和“调试输出”。而调试工作本身，依然需要理解iOS的Render Loop和Metal API的底层行为。

[!info] 一个数据点：我在展锐时测试过AI辅助生成的PHY层驱动代码，它的静态时序分析通过率比手工代码低12个点，而且大多数违反路径都出在时钟跨域同步上。AI不理解异步FIFO的深度应该如何根据延迟和带宽折中。

游戏的代码量小，IO密集型操作少，所以AI生成的版本能拿到2.5万美元奖金。但换个场景——比如一个需要实时处理1080p60帧视频的AR应用，AI生成的代码光是在CPU-GPU间的数据搬运就会撞上DDR带宽瓶颈，最终被功耗墙拍死。

直接收住。

原文链接：代码 100% 由 AI 编写：9 年 iOS 开发者 15 天打造外卖游戏，斩获 2.5 万美元奖金 - IT之家