从需求到成品：一个真实的 5 分钟项目

起因很简单：看 YouTube 视频时字幕没有中文翻译，需要一个实时翻译方案。讨论了三个方向后，最终选择做浏览器扩展——用户体验最好，不依赖外部软件。

值得注意的是，这个 AI 之前从来没写过浏览器扩展。但它的处理方式很值得借鉴：理解需求、拆解技术栈、找到关键 API。不需要"已经会"，只需要"能学会"。这恰恰是 AI 作为劳动力最核心的能力——零经验冷启动。

技术方案的几个关键决策

字幕捕获：MutationObserver 替代轮询

YouTube 的字幕是动态插入 DOM 的，传统做法是轮询检查，慢且耗资源。这里用 MutationObserver 实时监控 DOM 变化，字幕出现即捕获，零延迟。这个选择很实用。

翻译引擎：Google Translate 免费 API

没有选 DeepL 或 OpenAI，原因很务实：完全免费、无需 API Key、无调用限制、响应时间低于 100ms。对实时字幕场景来说，翻译质量够用，而速度和免费才是刚需。

智能缓存：Map 结构去重

相同字幕不翻译两次，用 JavaScript Map 做缓存，重复字幕响应时间直接降到 0。实现简单，效果明显。

双语显示：原文在下，译文在上

这个设计方便对照学习，不遮挡原字幕，符合阅读习惯。CSS 定位直接融入 YouTube 原生界面，不突兀。

过程中的问题处理

图标生成时遇到了一个小坑：浏览器扩展需要三个尺寸的图标，先尝试 ImageMagick 转换 SVG，因为缺 Ghostscript 失败了。没有纠结，直接写了个 Python 脚本用 PIL 生成 PNG，几分钟搞定。Plan A 不行就 Plan B，这种务实的切换在实际开发中非常重要。

文档方面，输出了 README、INSTALL、SKILL 文档和可视化测试页面。最终打包成 19KB 的 zip，包含所有代码、图标和文档，在另一台电脑上解压即用。

"AI as Labor" 的核心启示

这个案例最有价值的不是技术细节，而是协作模式的变化。整个过程中，人只负责提出需求（"我要一个 YouTube 实时字幕翻译"），AI 独立完成了方案设计、技术选型、编码实现、异常处理、文档编写和打包交付。

这就是 AI as Labor（AI 作为劳动力）和 AI as App（AI 作为应用）的本质区别。后者是你在用一个工具，前者是你在和一个能独立工作的同事协作。对一人公司来说，这意味着你可以把完整的开发任务交给 AI，而不仅仅是让它补全几行代码。

这个插件已经完全开源，后续可以扩展更好的翻译引擎（DeepL、OpenAI）、本地离线模型、上下文理解，以及多平台支持（Netflix、Bilibili 等）。如果你也在探索 AI 协作开发的边界，不妨从一个类似的小项目开始——给 AI 一个明确的需求，看看它能独立走多远。