下载解析层几乎零自研：解析交给 yt-dlp，字幕用 whisper.cpp，渲染走 unified/remark，思维导图用 markmap。整个产品从立项到第一版上线只用了两周，其中大部分时间花在 AI 总结和付费体验上。利用开源项目快速构建产品，本质是”站在巨人肩膀上”，把工程精力集中在自己最擅长的差异化部分，代价是对开源协议的合规、对上游变更的跟随，以及对核心依赖崩坏的风险预案。下面把这套取舍完整复盘一遍。
一、开源加速了哪些环节
开源真正省下的是那些”会但不值得做”的环节。视频解析、字幕提取这类工作，单平台就要一两个月，何况要覆盖几百上千个站点，靠自研根本不现实。立项时我们把主要模块过了一遍，按单人月估算自研成本，对比结果如下：
| 环节 | 自研成本 | 开源方案 | 节省时间 |
|---|---|---|---|
| 多平台视频解析 | 6 个月 | yt-dlp | 1 周接入 |
| 字幕提取 | 3 个月 | yt-dlp / whisper.cpp | 1 周接入 |
| Markdown 解析 | 1 个月 | unified/remark | 3 天 |
| 思维导图渲染 | 1 个月 | markmap | 1 天 |
| 文件下载重试 | 1 个月 | aiohttp + 自封装 | 3 天 |
总节省时间在半年以上，使团队能集中精力做 AI 总结与产品体验。半年是什么概念？我们两个人，半年能交付一到两个完整功能模块；把这段时间省下来，产品才能在需求热度过去之前上线。
二、为什么可行
光”省时间”不够，还得说清楚为什么敢把核心链路交给社区。三个前提让这种策略成立：
- yt-dlp 已经覆盖 1000+ 站点，且社区更新快；
- 各家模型的 API 标准化，OpenAI 兼容接口让切换成本下降；
- 前端生态成熟，Vercel/Next.js、shadcn/ui、Tailwind 让首屏搭建变成 1 天。
其中第一点是关键：覆盖广意味着绝大多数视频不用我们自己写解析器，社区更新快意味着站点改版后通常几天内有人跟进修复。我们的下载服务接入它只花了一周，核心调用就一行命令：
yt-dlp -f "bv*+ba/b" --write-subs --sub-langs "zh-Hans" -o "%(title)s.%(ext)s" "视频地址"这条命令同时拿到视频流、音频流和中文字幕，输出文件自动命名。第一次跑通时我反而有点慌，太顺了，后来连续测了十几个站点才放心。注意参数要写全：漏掉 --sub-langs 字幕就丢了，漏掉 -f 可能拿到低清版本，这些都要写进团队的使用手册。
三、合规边界
省下的时间，要用合规工作补回来。开源不等于免费，许可证是法律文件，踩线一次可能毁掉整个产品。我们按四条边界执行：
- 许可证：选择 MIT/BSD/Apache 2.0 协议的项目，避免 GPL；
- 品牌归属：在 About 页面致谢开源项目，不删除版权信息；
- 数据合规：不开通盗版内容下载，仅对官方允许下载的内容提供服务；
- 二次发布：若产品本身闭源，要避免静态链接 GPL 依赖。
第一点是选型阶段就要查的：GPL 有传染性，闭源产品静态链接 GPL 依赖，等于把自己的代码也开源出去。我们在下载层坚持用宽松协议组件，需要 GPL 能力时改实现思路。品牌归属这步常被漏掉，但不少项目对”删除版权信息”比”商用”更敏感，About 页面加一行致谢，成本几乎为零。
四、风险与应对
开源依赖的特点就是”不归你管”。上游今天删个分支、明天改个协议，你都拦不住，能做的只有预案。我们的应对清单：
- 上游接口变更：跟踪 yt-dlp 仓库订阅，企业用户锁定 LTS 版本；
- 上游维护中断：核心下载逻辑抽象出 Adapter，必要时切换 fork；
- 法律风险：按地区法规增加内容过滤与提示；
- 性能问题：自研性能关键路径，例如下载调度与缓存。
抽象 Adapter 是性价比比较高的一步。我们把下载调用封装成接口，内部对接 yt-dlp，外部只暴露”给我视频地址，还我元数据和文件”。这个抽象层大概两百行代码，万一上游维护中断，换一个实现，业务层零改动，等于给整个产品上了保险。
五、为什么不能全靠开源
用开源省时间，但别指望开源替你差异化，这是复盘里想强调的一条。原因很直接：
- 差异化能力会被同质化：所有用 yt-dlp 的产品功能相近；
- 用户体验要靠自研打磨：进度反馈、断点续传、错误提示都需要设计；
- 商业模式要自建：开源项目没有付费版本，企业用户不接受无服务承诺。
同质化我们感受很深：市面上用 yt-dlp 的下载工具一大片，功能几乎一样，拼的只剩价格和体验。进度反馈、断点续传、错误提示这些细活，开源给不了现成答案，必须自己磨。商业模式也一样，企业客户要服务承诺，开源项目不提供，这部分只能自己挣。
六、推荐的取舍
经过前面几轮对比，我们形成了一张取舍表，按”是否差异化、是否涉合规”两个维度划分：
| 模块 | 建议 |
|---|---|
| 下载器 | 用开源 + 自研适配层 |
| 字幕与转写 | 商业 API + 开源兜底 |
| 总结与思维导图 | 自研，差异化核心 |
| 付费与权限 | 完全自研，涉及合规 |
| 监控与日志 | 开源 + 商业 SaaS 组合 |
规则很简单：差异化核心和合规敏感部分自研，通用工程用开源，边界模糊的地方再加一层适配。字幕转写我们选了商业 API 为主、开源兜底，理由是服务保障更重要，出故障有人接电话。
七、给同类项目的建议
最后是给想走同样路线的团队四条建议，都是交过学费换来的：
- 选择活跃度高的开源项目，看 commit 频率、issue 响应；
- 抽象自己的服务层，开源依赖只作为可替换 Adapter；
- 合规与免责声明放进 ToS 与 About 页面；
- 关键路径准备”降级方案”，开源挂了产品还能跑。
回看整个过程，开源加速让我们活了下来，但真正让产品站稳的，是自研的那一小块：总结质量、付费体验、降级预案。建议把”选活跃项目、抽象服务层、写清合规声明、备好降级方案”当成四项基本配置，缺一项，省下来的时间迟早要加倍还回去。
常见问题（FAQ）
Q1：使用 yt-dlp 会不会有法律风险？
合法用途内使用风险较低，仍要遵守 ToS 与地区法规。
Q2：开源依赖要不要锁定版本？
要。企业环境锁定主版本号，避免自动升级带来兼容问题。
Q3：什么时候应该自研而不是用开源？
差异化能力、与付费强耦合、合规敏感部分建议自研。
