近期，Claude的“Fable 5”引起了广泛关注。笔者也尝试使用Fable 5，并用“Claude Code”编写了一些简单的数字音乐制作相关程序。于是萌生了一个想法：如果用Windows的ASIO驱动输出制作一个播放器，会不会很有趣？于是开始了尝试。
最初计划使用Fable 5，但基于之前的使用经验，觉得它对于本次用途来说性能过剩，便放弃了。取而代之的是OpenAI的Codex。几天前，一位朋友告诉我，他之前用Claude Code开发某乐器系统，但后来全部转向了更方便易用的Codex。
此前我几乎没用过Codex，但实际尝试后，仅用30分钟左右就完成了支持ASIO的音乐播放器“DAL Player”。以下是整个过程的详细报告。
从Fable 5转向Codex：策略调整的缘由
最初的想法很简单：“Fable 5这么火，不如用它做点什么作为Digital Audio Laboratory的内容。既然如此，做一个能用Windows ASIO驱动播放声音的播放器会很有趣。”
市面上已有许多音乐播放器，如foobar2000、MusicBee、JRiver、AIMP、Roon等，因此自己做播放器并无太大价值。
但如果能自己开发原创播放器，尤其是利用ASIO驱动实现比特完美播放，还是有一定意义的。
此外，如果成功，还可以扩展支持WASAPI等音频API，做成一个音频实验工具也很有趣。
然而，准备尝试时策略发生了变化。朋友推荐了Codex。
当时Fable 5正用于其他项目，感觉本次需求不需要那么强大，加上Claude使用达到上限，等待时间长达6小时，便决定尝试此前未用过的Codex。
初试Codex遇到的困难
对Codex了解不多，但在ChatGPT界面左侧发现了Codex选项。
点击后，从Microsoft Store安装了Codex。
但不懂如何使用，询问ChatGPT后得知需在终端输入“codex”启动，然而PowerShell中无法启动。
原因是ChatGPT Desktop和Codex是两个独立应用，启动Codex Desktop后问题解决。
启动后，系统要求设置“Agent Sandbox”，据ChatGPT解释，这是Codex在本地PC安全运行的机制。指定工作文件夹后，开发正式开始。
刚开始接触编码AI难度较大，因此我选择边与ChatGPT对话边操作Codex。
ChatGPT不仅负责功能需求，还帮忙审查设计合理性，优化给Codex的指令（prompt）。我只需将ChatGPT生成的prompt复制给Codex即可。
不是直接让Codex写播放器，而是与ChatGPT商讨后逐步推进。
我原本想用Python快速实现，但ChatGPT帮我评估了Python、C#、WPF、WinForms、NAudio等方案，最终确定采用：
- C# / .NET 10
- WPF
- NAudio
Python虽是候选，但考虑ASIO兼容性、Windows原生API访问、未来支持WASAPI Exclusive及Visual Studio集成，C#更合适。
实际上，这些设计决策都是ChatGPT和Codex自我讨论得出的，我几乎没参与。
ChatGPT选择WPF是因为相较WinForms更易于未来UI扩展和MVVM架构发展。
音频库方面，NAudio、ManagedBass、CSCore比较后选了NAudio，因为它支持ASIO、WASAPI、DirectSound、Media Foundation等多种接口。
命名方面，我最初用“ASIO-TEST”，但ChatGPT建议用“DAL Player”，DAL即Digital Audio Laboratory的缩写，寓意将其作为一个持续成长的项目。
30分钟内完成版本0.1
ChatGPT给Codex的第一个指令是先做设计，不直接写代码。AI擅长写代码，但不先确认设计容易偏离方向。于是先让Codex提出架构、库选择和开发计划，由我审核。
Codex提出了.NET 10、WPF、NAudio 2系列架构，并建议未来抽象ASIO/WASAPI接口。ChatGPT建议先不抽象，优先实现声音播放，版本0.1只实现ASIO驱动选择、打开WAV文件、播放和停止的最简功能。
Codex按步骤进行：确认.NET SDK、创建WPF项目、添加NuGet包、编写README，流程与人类开发者类似。
期间遇到NAudio安装时的TLS错误，Codex没有放弃，尝试了Python安装、构建本地NuGet缓存等多种方案。
每当需要权限时，弹出对话框，我都与ChatGPT确认后继续。
大约10分钟后，Codex完成了所有工作，文档也准备好了。
查看工作文件夹，包含源码和项目文件，但需要用Visual Studio自行编译。
操作非常简单，双击DAL Player.csproj打开Visual Studio，点击编译无任何问题。
点击工具栏播放按钮，出现了简洁的界面。界面顶部有许多小图标，是调试版本和Visual Studio功能显示。
主界面仅有ASIO驱动选择、WAV文件选择、播放和停止按钮，默认设置为Ableton Move的ASIO驱动，点击可显示当前系统中所有ASIO驱动。
选择WAV文件并播放后，声音通过ASIO驱动成功输出。如此简单就完成了ASIO播放器，令人惊讶。
从开始到完成仅30分钟，且我一边做其他事务一边完成，过程轻松。
版本0.2新增ASIO控制面板
版本0.1运行顺利后，想让播放器更实用，首先想到添加ASIO Control Panel按钮。
无论是DAW还是支持ASIO的播放器软件，通常都会提供该按钮，用于调整采样率、缓冲大小和时钟设置，作为“支持ASIO”的基本功能必不可少。
在ChatGPT协助下，给Codex下达“仅添加ASIO Control Panel按钮，其他不变”的指令，确保不破坏版本0.1功能。
结果MainWindow.xaml和AsioPlaybackService.cs被修改，编译成功，界面新增了ASIO Control Panel按钮。
确认驱动选择功能正常后，点击按钮成功打开ASIO驱动设置界面。
版本0.1用的是44.1kHz/16bit的CD翻录WAV，版本0.2还测试了48kHz/24bit的ProTools导出WAV，ASIO控制面板采样率自动切换到48kHz，说明播放器根据文件自动调整采样率。
但播放时程序崩溃。ChatGPT推测是因为未完全释放44.1kHz的ASIO流就尝试创建48kHz流，导致内部状态不一致。
作为初版播放器，未考虑采样率切换崩溃也属正常，修复留待后续版本。
引入Git，打造“DAL Player成长项目”
虽然考虑将版本0.2作为免费软件发布，但程序价值有限且存在安全风险。咨询ChatGPT后，决定作为连载项目，使用版本管理并逐步完善，最终发布到GitHub。
我虽偶尔用GitHub，但未独立发布过项目，询问ChatGPT后获得了Codex生成的初始化Git仓库、添加.gitignore、MIT许可证、CHANGELOG、README、首次提交及打标签v0.2的完整指令。
排除了bin、obj、.nuget等不必要文件，项目已具备发布条件。
不过这次暂时搁置GitHub发布，留作下次内容。
GitHub环境搭建较复杂，这次先停留在程序可用阶段。
AI不仅是“代码生成机器”
此次开发让我感受到Codex不仅仅是代码生成工具。
它能设计架构、发现问题、分析错误、尝试替代方案、编译项目、整理README，整体表现更像是新加入团队的初级工程师。
ChatGPT则担任设计审查角色，协助决策WPF或WinForms、何时引入Git、是否公开GitHub等问题。
最终形成了三方分工：Codex负责编码，ChatGPT负责设计审查和方向讨论，人类决定开发内容和范围以及文章呈现方式。
我几乎没写代码，也没详细查看代码，但ASIO播放器一天内就能运行，充分展现了与AI协作开发的潜力。
DAL Player并非普通播放器，而是希望成为能瞬间切换ASIO、WASAPI Exclusive、WASAPI Shared、DirectSound，显示采样率、缓冲大小、延迟和当前API的Windows音频实验工具。
下一步计划修复采样率切换崩溃，发布GitHub版本，并增加MP3支持、WASAPI Exclusive支持等功能。
从版本0.1到0.2，边与AI对话边成长的软件实验将走多远，敬请期待后续报道。
