做一个很小的开发工具时，最容易犯的错误是把功能清单写得很长，却没有把用户真正要完成的动作串起来。
以 YouTube 字幕为例，表面需求是“拿到 transcript”。但实际使用时，用户往往不是为了看一整段文字，而是为了继续完成后面的工作：查找某句话、回到视频时间点确认上下文、复制到笔记里、整理成素材，或者导出到字幕和剪辑流程。
所以我在做 AI YouTube Transcript 时，先把问题收窄成一个具体链路：输入视频 URL 或 video ID，打开 transcript，在文本里搜索关键词，点击时间戳回到视频位置，复制需要的段落，最后按用途导出 TXT、SRT 或 VTT。
只展示结果还不算完成工作流
很多工具的第一版都能“展示一个结果”。但对工作流型工具来说，展示结果只是中间状态，不是交付终点。
如果 transcript 打开以后不能搜索，用户仍然要自己在长文本里翻。如果搜索到了文本却无法回到对应时间点，用户还要重新拖动视频。如果只能复制一段纯文本，却不能导出适合后续系统处理的格式，用户的时间会继续浪费在转换环节。
这也是为什么这个工具的核心不是“多加几个 AI 功能”，而是先把几个朴素动作做顺：
- 输入 YouTube URL 或 video ID。
- 选择可用语言。
- 打开 transcript。
- 在字幕文本中搜索关键词。
- 用时间戳回到原视频位置。
- 复制文本，或导出 TXT、SRT、VTT。
这些动作看起来都不复杂，但组合起来以后，才真正减少用户在视频和文本之间来回切换的成本。
输出格式不是附加按钮
TXT、SRT、VTT 这几个格式很容易被当成“顺手做一下”的导出按钮。实际看，它们对应的是不同的后续场景。
TXT 更适合阅读、摘录、写笔记和内容整理；SRT 和 VTT 则保留时间信息，更适合字幕校对、视频剪辑、资料归档或需要继续进入其他工具处理的流程。
如果一个工具只让用户看到内容，却不能让内容进入下一步，那么它解决的是演示问题，不是实际问题。对开发工具来说，能否交付一个可继续处理的结果，往往比页面上多一个功能入口更重要。
范围收窄反而更容易建立可信边界
我没有把这个工具一开始就扩成摘要、改写、素材管理或大而全的视频助手。原因很简单：这些方向都有价值，但它们会把产品判断从“字幕工作流是否顺畅”拉到另一个更大的系统里。
在早期，更重要的是把边界说清楚。这个工具能帮用户更快地访问、搜索、定位、复制和导出 YouTube transcript；但它不能承诺每个视频都有可用字幕，也不能承诺字幕本身一定准确。
字幕能否加载，取决于视频本身是否公开了可用的 subtitle 或 caption 轨道；如果没有可用轨道，工具就无法凭空生成稳定 transcript，文本质量也取决于原始字幕轨道。
这个限制必须放在内容里。因为开发者工具如果只强调能力，不说明边界，最终会让用户在异常场景里付出更多试错成本。
对开发者工具的一个小结
这个项目给我的启发是：工具的价值不一定来自功能数量，而是来自它能不能把一个重复动作从头到尾接稳。
用户第一次打开工具时，通常没有耐心理解一套复杂系统。他们只想知道：我现在能不能把这个视频里的字幕拿出来，能不能搜，能不能定位，能不能复制，能不能导出到下一步。
当这些问题都能被顺手完成时，一个窄工具也可以变得有用。
如果你也经常需要把 YouTube 视频转成可搜索和可导出的 transcript，可以试试这个工具：
