当一台 2016 年的 MacBook Pro 因 Wi-Fi 驱动问题沦为「电子垃圾」，一位开发者尝试用 AI 生成驱动，结果发现 AI 并非魔法——它需要人类精心设计流程，甚至先生成详细文档再动手写代码。这背后的故事，或许能重新定义我们对 AI 编程的认知。

FreeBSD 系统对部分老旧硬件的支持一直存在挑战。以 2016 年款 MacBook Pro 为例，其内置的 Broadcom BCM4350 Wi-Fi 芯片在 FreeBSD 中缺乏原生驱动支持。常规解决方案是运行轻量级 Linux 虚拟机，通过 PCI 直通将 Wi-Fi 设备交给 Linux 处理，但这显然不是理想的长期方案。详细过程记录在原文中。

旧设备的困境与 AI 的介入

FreeBSD 作为注重稳定性和安全性的操作系统，对部分老旧硬件的支持一直存在挑战。以 2016 年款 MacBook Pro 为例，其内置的 Broadcom BCM4350 Wi-Fi 芯片在 FreeBSD 中缺乏原生驱动支持。常规解决方案是运行一个轻量级 Linux 虚拟机，将 Wi-Fi 设备通过 PCI 直通交给 Linux 处理，但这显然不是理想的长期方案。

一位开发者尝试用 AI 直接移植 Linux 的 brcmfmac 驱动代码到 FreeBSD。然而，AI 生成的代码虽然能编译通过，却在加载时引发内核崩溃。即使多次调整代码，驱动仍无法正常工作。Hacker News 上的讨论中，有用户指出：AI 生成的代码在没有硬件反馈的情况下无法正常工作，必须有实际测试环境才能验证。

从「直接移植」到「规范先行」的转折

意识到直接移植的困难后，开发者调整了策略：先让 AI 生成详细的规范文档，再基于文档重写代码。这个过程中，AI 被要求将 Linux 驱动的工作原理分解为 11 个章节的详细说明，包括数据结构、总线层、协议层等。随后，通过多个 AI 模型交叉验证文档的准确性，修正其中的错误。

这种「规范先行」的方法显著提高了开发效率。开发者在 Hacker News 中提到：生成的规范文档经过 Codex 和 Opus 模型验证后，AI 才开始编写代码。这比直接修改原始代码更有效。最终，AI 生成的驱动支持 2.4 GHz/5 GHz 连接和 WPA/WPA2 认证，但仍有已知问题，仅适合学习用途。相关讨论在Hacker News上，用户们指出：没有文档的专有硬件，AI 无法凭空生成驱动。

版权与许可的灰色地带

值得注意的是，原 Linux 驱动采用 ISC 许可证，允许自由重用。但 AI 生成代码的版权归属仍存争议。Hacker News 讨论中，有人质疑：AI 训练数据可能包含受版权保护的代码，是否构成侵权？但也有观点认为，由于开发者使用「clean-room 方法」（先生成规范再独立实现），代码与原驱动差异较大，法律风险较低。

实际操作中，开发者明确标注了 ISC 许可证，并注明「基于 Linux brcmfmac 驱动」。Hacker News 用户指出：ISC 许可允许自由重用，但 AI 生成代码的版权问题尚未有明确法律判例，需谨慎处理。一位开发者补充道：如果 AI 模型在训练时接触过受版权保护的代码，生成结果可能涉及法律风险。

AI 辅助开发的现实边界

尽管 AI 生成了可用的驱动代码，但实际应用中仍面临诸多挑战。有用户尝试复现该驱动，发现「无法扫描网络，需大量修改才能编译」。Hacker News 上，有开发者指出：AI 生成的代码缺乏质量保证，生产环境使用风险高。驱动需要硬件测试，AI 无法替代物理调试。

更关键的是，AI 在处理复杂硬件时仍依赖已有文档。例如，对于没有公开规格的专有硬件，AI 难以凭空生成驱动。一位用户评论道：没有文档的专有硬件，AI 无法凭空生成驱动。这需要人类专家的深入研究。另有开发者分享：用 AI 生成 Greasemonkey 脚本解决银行 OFX 导出问题，但这类简单任务和系统级驱动有本质区别。

未来：工具还是替代者？

AI 在软件开发中的角色正在变化。例如，有人用 AI 生成 Greasemonkey 脚本解决银行 OFX 导出问题，大幅缩短开发时间。但这种应用通常局限于简单任务，且需要人类验证。Hacker News 讨论中，有观点认为：AI 将改变开发流程，但不会取代专业技能。它更像是一个高效的助手，而非完全替代者。

未来，随着 AI 工具的成熟，开发流程可能更依赖规范文档和自动化测试。但正如一位开发者所言：AI 生成的代码仍需严格测试，生产环境使用必须谨慎。技术的进步永远需要人类的智慧与经验。一位资深工程师总结道：当 AI 能自动验证硬件兼容性并生成测试用例时，或许才是真正的转折点——但目前我们仍处于「AI 辅助」而非「AI 主导」的阶段。