AI 写的 Swift 音频代码为何启动即崩
作者与 Claude 编写的音频功能通过编译和测试，却因渲染闭包继承主 Actor 隔离，在音频线程执行时触发运行时检查崩溃。修复将回调移至非隔离上下文并显式标注 @Sendable，也暴露出原有验证未覆盖实际回调执行。
AI 深度解读
Claude 帮作者给一个小型 Swift 游戏写了自适应音频功能。编译通过、测试通过、安装成功，应用却在音频回调第一次执行时崩溃，只留下 SIGTRAP。
问题出在 Swift 6 的 actor 隔离与 Core Audio 实时音频线程之间。作者修掉了代码，也补了一道运行验证：让应用真正走过那条回调路径。这篇案例值得看，因为它指出了 AI 编程里一个容易误判的信号：构建成功，离功能可用还有距离。
为什么编译和测试都过了，应用还是会崩
作者的音频类标记了 @MainActor。在这个上下文里创建的渲染闭包，也被 Swift 6 视为主 actor 隔离。
下面这段代码把音频渲染逻辑交给了 AVAudioSourceNode：
let node = AVAudioSourceNode(format: format) { _, _, frames, buffers in
synth.render(frames: Int(frames), into: buffers)
return noErr
}
要看的是第一行：闭包在哪里创建，会影响它继承的隔离约束。
但闭包最终在哪里执行，由调用它的框架决定。Core Audio 会在实时音频线程上调用这个闭包，并不会把它安排到主 actor 上。于是，创建时继承的隔离要求，与执行时所在的线程发生冲突。
在作者的案例中，编译器接受了这次交接；等 Core Audio 首次调用闭包，运行时 actor 检查才触发陷阱，应用以 SIGTRAP 崩溃。
构建通过，不能证明框架会在满足隔离要求的上下文中执行回调。
测试通过也不构成反证。原文没有给出测试内容，我们只能确定：已有测试没有拦住这次运行时故障，不能进一步断言它们具体漏测了什么。
修复代码之外，还要让回调真正跑起来
作者把回调的创建移到了 actor 隔离上下文之外，并显式标注线程相关约定：
nonisolated private static func sourceNode(
format: AVAudioFormat,
synth: MusicSynth
) -> AVAudioSourceNode {
AVAudioSourceNode(format: format) { @Sendable _, _, frames, buffers in
synth.render(frames: Int(frames), into: buffers)
return noErr
}
}
重点看 nonisolated 和 @Sendable：前者让这个静态工厂方法脱离类的 actor 隔离上下文，后者显式表达闭包可跨并发上下文传递的约束。
这段修复并没有把音频工作搬回主线程，而是调整闭包的创建位置和并发约定，使其适配框架实际的调用方式。不过，原文没有展示 MusicSynth 的内部实现，不能仅凭这段代码判断其全部线程安全性。
作者随后修改了工作流程。凡是 AI 辅助完成、涉及向系统框架传递闭包的改动，都增加一道小型运行验证：
- 在模拟器里启动应用。
- 实际触发对应回调路径。
- 让应用继续运行 60 秒。
- 通过后，再进行后续安装或发布。
关键是第二步。应用停在启动页上等一分钟，并不能验证音频回调是否正常。
作者把这种验证称为可运行的冒烟测试：用一次小规模执行，确认关键路径能走通。它的价值在于跨过真实边界，让框架接手并执行代码。
原文还列出了类似边界：actor 隔离、生命周期、权限、后台执行和硬件状态。AI 写出的局部代码可以很像正确答案，真正的问题却可能出现在它与外部系统交接的地方。Claude 后来也帮助作者诊断并修复了崩溃，因此作者反对的不是 coding agent，而是把构建结果当成功能验证。
我的判断
我认同这个取舍：与其泛泛要求「再仔细审查一次」，不如明确指出哪条路径必须实际运行。尤其是框架回调，阅读闭包内部的几行代码，很容易忽略执行线程、触发时机和生命周期。
但这仍是一篇单次故障的经验记录。作者没有提供采用这道验证前后的故障率，也没有解释为什么选择 60 秒。这个时长可以作为他们团队的操作习惯，不能直接当作普遍有效的标准。
模拟器验证也有范围。既然作者自己提到了硬件状态，涉及真实设备行为时，就不能把模拟器运行成功视为覆盖完整。原文没有交代真机验证方案。
与单元测试相比，这道冒烟测试补上的是框架实际调用代码的过程；与代码审查相比，它提供的是运行证据。它们各自回答不同的问题。一次运行成功，也只证明本次触发条件下没有出现相同故障。
能拿来做什么
- 接受 AI 编写的框架回调代码时，把「触发回调并观察结果」写进验收步骤，避免只记录构建和测试是否通过。
- 遇到类似 Swift 6 隔离问题，检查闭包的创建上下文与实际执行上下文，再核对修复代码中的
nonisolated、@Sendable及捕获对象。 - 让 AI 协助修复运行时故障时，同时要求它给出最小复现路径和运行验证步骤，把「代码已修改」推进到「故障路径已验证」。
- 根据功能选择验证环境与观察时长。可以参考作者的模拟器运行 60 秒做法，但涉及权限、后台执行或硬件状态时，要覆盖相应条件。