很多“下载页”看起来解决的是“我要一个 WAV 文件”，但用户真正想完成的，往往不是“终于拿到一个文件”。
他们真正要完成的事情，通常是后面的那一步：
- 确认转换任务是不是还在跑
- 确认结果是不是自己要的音频
- 再决定要不要下载这个 WAV
- 然后把文件继续拿去剪辑、归档、播客整理或别的音频流程
这也是我做 YouTube to WAV 时最在意的一件事：它不是一个“支持尽可能多下载场景”的工具，而是一个“把 link -> WAV 这条路径做顺”的工具。
真正要解决的，不是“能不能给一个下载按钮”
如果只是把“开始转换”放出来，其实很多场景并没有真的被解决。
对编辑和播客用户来说，最怕的是等了一轮以后才发现结果不对；对想快速留存音频的人来说，最怕的是任务状态不清楚，不知道该继续等还是重试。
换句话说，用户要的不是一个页面里“告诉你可以下载”，而是：
- 粘贴 YouTube URL 或 raw video ID。
- 发起转换任务。
- 查看进度直到 WAV 准备完成。
- 先预览音频结果。
- 确认后直接下载 WAV。
这条链路一旦中间断掉，页面就会重新变回一个不太可信的下载页。
为什么我没有继续把它做大
一开始我也想过，要不要顺手扩成更大的视频下载或处理工具。
但越往后越觉得，这样很容易把一个原本清晰的工作流做散。用户第一次来这个产品，不是来研究一套复杂系统的。他只是想尽快把眼前这件事完成。
所以我最后保留的核心判断是：
- 先把任务状态做清楚
- 再把预览这一步做稳
- 最后把 WAV 下载这一步做成真正可交付的结果
如果这三层没有做好，后面再多能力，也很容易变成“看起来很全，实际很绕”。
为什么 preview 和 progress 不是装饰
很多人会把进度和预览看成“顺手加一下”的小功能。
但我越来越觉得，这两件事本身就是产品契约的一部分。
进度让用户知道任务还在正常推进，预览让用户在下载前先确认结果值不值得保存。对这种转换类工具来说，它们不是附加值，而是“这个页面到底靠不靠谱”的关键。
这个产品最需要被明确写出来的限制
这里有个限制必须提前说清楚：这条 WAV 流程当前支持最长 120 分钟的视频，依赖第三方转换提供方，输出质量取决于源媒体本身，也只适用于用户拥有或获准下载的内容。
我反而觉得，这种限制写清楚是好事。因为越是转换类工具，越不能靠模糊承诺取胜。把边界讲明白，用户才能知道什么时候它适合自己，什么时候不适合。
对做产品的人来说，这个题目真正有意思的地方
这个项目让我反复确认了一件事：很多产品价值，不在“有没有给一个下载入口”，而在“用户下载前能不能先建立信任”。
如果一个工具能让人更快地判断任务状态、先预览结果、再把 WAV 接到下一步，它就有存在价值。
如果它只完成了“看起来能下载”，却没有把中间那几步接住，那它更像一个入口，而不是一个真正可用的工具。
如果你也经常遇到这种场景，可以直接试试：
