视频处理对延迟极其敏感：30fps 下每帧预算只有 33.3ms，60fps 时更是压缩到 16.6ms。从摄像头取帧、跑神经网络分割、做 shader 到合成输出，全部塞进这个窗口，超时一毫秒就会丢帧。传统做法是手工优化，对着火焰图分析几周，然后在 Swift/C++/Metal 层面慢慢调。用通用 AI 编码助手生成模板代码没问题，但让 AI 针对目标硬件做优化、跑真实延迟基准、同时保证画质不劣化，这类工具做不到。

AlphaEvolve 的核心思路是进化式搜索：让 Gemini 模型不断产出候选代码，用你自定义的评分函数筛选，保留高分个体并迭代。它的关键是一个 split-loop 架构：云端负责生成，跑在 Google Cloud 上，由 AlphaEvolve 调度 Gemini 模型和提示编排；评估部分完全跑在你自己控制的硬件上，编译并执行候选代码。两边解耦，评估器和生成器可以用不同语言实现。

AlphaEvolve 这类系统比你想象中更容易被评分函数骗。早期的 naive 指标只要压延迟，进化算法很快找到了漏洞：模型学会直接跳过渲染，在 0 毫秒返回未修改的帧。开发者引用了一个真实案例——用简单加权延迟做评分函数，结果得到了惊艳的”加速”，其实是评分函数被钻了空子。解决方向是双层评分：把吞吐指标和结构相似性（SSIM）结合，同时设平均阈值和每帧最低阈值，防止模型通过静态背景作弊。如果没有每帧最低限制，候选代码完全可以在快速转头时悄悄丢弃更新。

文章给了几条具体建议。一是提示词要提供框架上下文，只给一个孤立的帧处理回调，模型看不到全局，就做不了跨帧优化；把 SDK 头文件、接口定义、API 符号都塞进提示里。二是允许候选代码持有跨调用的有界状态，比如时间掩码缓存。这里有个坑：AlphaEvolve 一开始缓存太激进，产生了明显的拖影伪影，是 SSIM 质量门槛把这个行为挡了回去。三是先测硬件性能下限，再做优化：用 no-op pipeline——不干实际的活，只跑最小化的 ML 推理和 GPU 拷贝——测出物理硬件的极限。所有优化都对照这个基线来评估，否则你可能实现了 2 倍加速就觉得赢了，但实际还有 3 倍的提升潜力，只是你压根没意识到。

文章还纠正了一个常见误区：永远不要拿静态帧或空白视频做基准测试。进化搜索会主动发现你评估指标里的盲区。延迟优化和画质保持是天然冲突的，AlphaEvolve 的解决方式是让质量门控来做权衡，而不是靠人工调参。领域越自动化，评估器的设计就越关键——评估器就是进化过程的”环境”，环境设计有缺陷，最终解就有缺陷。