夜雨聆风这几天我使用 AI 高强度的来编程，用 AI 开发一个实时音视频通信程序。
不是写个 Hello World，不是做个 TodoList，是实打实的音视频通信。采集、编码、传输、解码、播放，整条链路全让 AI 来。
目的很单纯，两个。一是练习怎么用 AI 更好地开发，二是想看看在这种复杂场景下，AI 编程到底会踩多少坑。
坦率的讲，开始前我觉得还行。iroh-live 这个项目摆在那里，Rust 写的，基于 QUIC 和 MoQ 协议，架构清晰，文档齐全。AI 读一下代码，应该能很快上手吧。
结果呢。
几乎每一块都出了问题。音视频采集，编码，传输，解码，播放，没有一个顺的。
当时我就有点懵了。代码看着没问题啊，API 调用也没错啊，为啥就是跑不通呢？
让 AI 分析原因，AI 也能给出一堆理由。换个参数，加段错误处理，调整一下线程模型。改完试一下，不行。再让 AI 分析，再改，再试。
循环往复。
改了十几轮之后，我突然意识到一个问题。AI 每次分析，其实都是在猜。
它没有经历过这个程序在 macOS 上跑不通的过程，没有听过 CoreAudio 报错是什么样的，没见过 AVFoundation 返回的帧格式跟预期不一样是什么情况。它只是根据代码和错误信息，在庞大的训练数据里找最像的答案。
猜对了一次两次可以，猜多了，代码就变得异常复杂。各种 fallback，各种条件分支。最后代码能编译通过，但就是不能正常工作。
这就是我今天最想说的一个点。
如果你不了解相关技术，只要程序一报错就让 AI 去分析解决，AI 很可能越改越乱。因为你没法给它足够的上下文，它只能靠猜。而猜问题的代价，是代码越来越复杂，问题依然没解决。
那怎么办？
我自己摸索出了一个思路。先花几天时间，老老实实把相关技术学一遍，搞清楚整体架构和关键细节。然后再用 AI 解决问题的时候，给它足够的上下文。
先学架构：iroh-live 是怎么组织音视频管道的
这次我就花了几天时间，把 iroh-live 这个项目从头到尾扒了一遍。
这个项目三层架构，挺清晰的。最上面是 iroh-live，负责会话管理、信令和连接。中间是 moq-media，做媒体管道，捕获、编码、解码、自适应比特率、播放时序都在这块。最下面是 iroh-moq，基于 QUIC 的传输层。再往下还有 rusty-codecs 负责编解码器，rusty-capture 负责跨平台媒体捕获。
数据流从捕获源开始，经过编码器管道，变成 MoQ 包，通过 QUIC 传输，到对端再解码，最后渲染出来。
看着简单对吧。真动手的时候，每一层都有坑。
视频采集：每个平台的实现方式完全不同
先说视频采集这块。
macOS 上用 AVFoundation，Linux 上用 V4L2 或者 PipeWire，Windows 上有 DirectShow，Android 更特殊，用的是 Java 层的 CameraX 通过 JNI 推帧到 Rust。每个平台的实现方式完全不同。
AI 写代码的时候，经常默认你用的是某个平台的方式。比如它可能直接调CameraCapturer::new()，觉得这就能获取摄像头画面。但在 Android 上，这个类根本不存在，实际用的是 JNI 桥接方案。Java 层用 CameraX 捕获 NV12 格式的帧，通过 JNI 推到 Rust 层的CameraFrameSource里，再由编码器拉取。
这种平台差异，AI 不查代码是不可能知道的。就算查了代码，它也不一定理解为什么这么设计。
Android 为什么要走 JNI 而不是纯 Rust？因为摄像头权限请求必须在 Activity 主线程里做，摄像头生命周期要跟 Activity 绑定，纯 Rust 搞不定。
这些背景知识，不在代码里。在你了解它们之前，AI 永远想不到你需要考虑这些东西。
音频管线：听起来简单，背后全是坑
再说音频。
音频采集用的是 cpal 这个跨平台音频库。听起来很简单，创建 AudioBackend，获取输入流，设置到广播就行。
但背后的东西多着呢。
cpal 在不同平台上对应不同的后端。macOS 是 CoreAudio，Linux 是 ALSA 或者 PipeWire，Windows 是 WASAPI，Android 是 Oboe。采样率、通道数、数据格式，每个平台都可能不一样。
iroh-live 里面做了很多统一处理。设备采回来的音频，先在回调线程里做通道映射，单声道变立体声。然后用 sonora 库做 AEC 回声消除。再经过 fixed_resample 重采样到统一的 48kHz。最后才分发给用户的 InputStream。
这里有个很关键的线程模型：
• 调用者线程：在 tokio 任务里创建流、读取音频 • 驱动线程：独立运行，管理 cpal 流的生命周期和设备切换 • cpal 回调线程：实时线程，里面不能有内存分配，不能用锁
AI 写代码的时候，如果不知道这个实时线程的限制，可能会在回调里塞一堆动态分配的操作。编译能通过，运行时直接卡死或者爆内存。
还有 AEC 的处理流程也挺有意思。输出回调把播放的音频写入 render_ref_prod，输入回调从 render_ref_cons 读取渲染参考，然后用 sonora 做回声消除。也就是说，你自己的扬声器播放的声音，也会被处理掉，避免回传给对方。
这种设计细节，你不读代码根本不知道。AI 不读代码更不可能知道。
编码和解码：专用线程、渲染后端
编码和解码这块也一样。
视频编码器支持 H.264、AV1，有软件编码也有硬件加速。macOS 用 VideoToolbox，Linux 用 VAAPI，树莓派用 V4L2。音频用 Opus。
编码管道跑在专用 OS 线程上，不是 tokio 任务。因为编码器需要稳定的低延迟执行环境，async/await 在那种高频实时场景下反而不合适。
解码管道也是类似的思路。解码后的视频帧经过 FramePacer 控制播放节奏，基于 PTS 保证音视频同步。渲染可以用 wgpu 做零拷贝，也可以用 OpenGL ES 2.0，实在不行还能走 CPU 回退拿到 rgba\image。
每次 AI 给我一段代码，我都得自己判断它有没有考虑到这些细节。
有了上下文之后，AI 才真正开始好用
那学了几天之后，我用 AI 开发的状态发生了什么变化？
最大的变化是，我给 AI 的上下文变多了。
以前报错的时候，我只能把错误信息扔给 AI，说"帮我看看怎么回事"。AI 只能猜。
现在我会说，音频采集在 Android 上用 Oboe 库，采样率 48kHz，通道数 2，声音在安卓上没有播放。你看看这里哪里有问题。
效果完全不一样。
有了这些上下文，AI 的分析准确率高了很多。因为它不用再猜测平台差异，不用再猜测线程模型，不用再猜测数据格式。它只需要在已有的框架里找那个具体的 bug。
说白了，AI 不是一个能凭空理解你系统的魔法。它是一个很强的代码生成和调试助手，但前提是你得告诉它这个系统是怎么工作的。
你告诉它的上下文越精确，它帮你解决问题的效率就越高。你什么都不说，只丢错误信息，它就只能靠猜。而猜这个问题的成本，是代码会越来越复杂，复杂度还会反过来让你更难理解问题到底在哪。
这是个恶性循环。
用 AI 开发复杂项目，学习成本省不掉
所以我这几天的结论是，用 AI 开发复杂项目，学习成本省不掉。
你可以让 AI 帮你读代码、总结架构、解释某个函数做了什么。但你自己的脑子里必须有一个整体的图景。知道数据从哪来到哪去，知道每个环节的平台差异，知道哪些地方容易踩坑。
有了这个图景，AI 才是你的加速器。没有这个图景，AI 就是你的拖延症。你以为让它改改就能好，结果越改越乱，最后还得你自己从头看代码。
回到音视频开发这个事儿。
整个程序的架构并不复杂。采集、编码、传输、解码、播放，五个环节。但每个环节背后都是大量的工程细节。
采集环节，不同平台用完全不同的 API 和数据结构。编码环节，硬件加速和软件编码的切换、帧率控制、码率调节。传输环节，QUIC 的流管理、MoQ 的 group 和 track 机制、丢包和乱序处理。解码环节，解码器状态管理、帧缓冲、音视频同步时钟。播放环节，渲染后端的适配、帧间隔控制、音量调节。
任何一个环节出问题，都可能是多层原因叠加。网络抖动导致丢包，丢包导致解码器状态异常，解码器异常导致渲染黑屏。如果你只看渲染层，永远找不到根因。
所以学习整体架构这件事，不是可选项，是必选项。
当然，我也不是说要先把所有技术都学精通了再用 AI。那太慢了，也没必要。
我的做法是，先用 AI 辅助学习。让它帮你梳理架构，解释概念，总结代码。然后自己带着问题去看源码，验证它的总结对不对。遇到不理解的地方，再让 AI 解释。
这样来回几次，你对整个系统的理解就会越来越深。等到真正写代码、修 bug 的时候，你就能给 AI 提供足够精确的上下文，让它发挥真正的价值。
最近在尝试用 AI 做一件本来觉得自己搞不定的事。踩了不少坑，也学到了一些东西。
以前我们觉得，会写代码就行。现在 AI 能帮你写大部分代码了。但 AI 写代码的前提是，你知道要让 AI 写什么，知道写出来的代码应该长什么样，知道出了问题该怎么定位。
这些能力，AI 暂时替代不了。
所以别怕花时间学基础。你花在理解系统上的每一分钟，都会在后面以十倍的速度赚回来。
因为我这几天真的感受到了。当你理解了整个音视频管道的运作方式之后，再看 AI 给出的代码，哪些是对的，哪些是瞎搞的，一眼就能看出来。
而看不懂的时候，你连让 AI 往哪个方向改都不知道。
那时候 AI 不是在帮你开发，是在替你焦虑。
