Vibe Coding 实战：跟着教程做出 AI 视频助手

引言

我一直在关注 AI 辅助开发的进展，从 GitHub Copilot 到 Cursor，从自然语言写代码到各种 AI 编程工具的涌现，每一条资讯都让人兴奋。但兴奋归兴奋，始终有一个问题卡在面前：没有具体的项目想法去实践。工具再好，没有落地的场景，就只能停留在”围观”的阶段。与此同时，我有一个真实且反复出现的痛点——经常看 YouTube 和 B 站的长视频，很多时候只想快速了解内容，而不是花半小时甚至更长时间看完全程。回头看，不是我没有需求，而是这些需求太日常，以至于我从来没把它们当成一个项目。

转机来自 WayToAGI 组织的一场 Vibe Coding 训练营。训练营里，有人做了手势互动网页，有人做了 Q 版拜年图片，也有人做了个人门户网站。看着这些作品，我突然意识到一件事：阻碍我的从来不是”不会做”，而是”没想好做什么”。恰好在刷信息流的时候，我看到了编程导航发布的一个”AI 万能视频下载总结器”教程，功能描述和我日常的需求几乎完美匹配：粘贴视频链接，自动下载并用 AI 生成结构化总结。更重要的是，它不只是给了我一个方向，而是给了我一条可以照着做下去的路径。需求有了，教程有了，没有理由再拖下去。

这篇文章记录了我跟着编程导航教程，用 Vibe Coding 做出 AI 视频助手的过程。做完之后，我最大的感受是：Vibe Coding 不只是加快开发，更在于它能让一条已经明确的实现路径更快落地，并逐步变成适合自己的版本。

01 什么是 Vibe Coding

2025 年 2 月，Andrej Karpathy（前特斯拉 AI 总监、OpenAI 联合创始人）在 X 上发了一条推文：

“There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”

翻译过来就是：有一种新的编程方式，你完全沉浸在氛围里，拥抱指数级的变化，忘掉代码本身的存在。

和传统编程有什么区别？

传统编程的思维方式是：我要实现什么功能 → 拆分成步骤 → 写代码 → 调试 → 完成。整个过程，代码是核心载体。

Vibe Coding 的思维方式则更像：我要做什么东西 → 用自然语言告诉 AI → 看它做得对不对 → 再继续修改。整个过程，意图是核心载体，你不再从代码细节开始，而是从结果开始。

用一个类比来说：传统编程像自己砌砖盖房子，Vibe Coding 更像当甲方——你提需求、看效果、提修改意见，AI 负责施工。

但它不是”不用学编程”

这里需要纠正一个常见的误解。Vibe Coding 不等于”完全不懂代码也能做出复杂系统”。更准确地说，它是换一种方式写代码。你仍然需要具备一些基本能力：

• 能清晰描述需求——知道你要做什么
• 能判断生成结果的好坏——知道做出来的东西对不对
• 能在 AI 卡住时给出方向——知道问题可能出在哪

门槛确实降低了，但并不等于不需要判断、表达和拆解问题的能力。

02 项目是什么 & 最终效果

一句话定位： 一个轻量 Web 工具，粘贴视频链接即可下载并用 AI 生成结构化总结。

支持平台： YouTube、Bilibili、Twitter/X、TikTok、Instagram 等 1000+ 平台，抖音有专用无水印通道。

如果只看功能描述，这个项目其实不算新鲜：下载视频、提取字幕、调用大模型做总结，拆开看都不是什么从未出现过的能力。但对我来说，它的价值恰恰在于：这不是我凭空想出来的一个炫技项目，而是一个现成教程刚好击中了我长期存在的真实需求。

过去我也会觉得”要是有个工具能帮我快速看懂长视频就好了”，但这种念头通常只是一闪而过；直到看到别人把它整理成完整教程，我才真正意识到，这件事不只是值得做，而且是可以沿着一条明确路径做出来的。

技术栈速览： Flask 3.1 + Vue 3 + Vite + yt-dlp + DeepSeek（OpenAI SDK 兼容接口）+ SSE 实时推送 + Docker Compose 一键部署。

03 开发过程实录

这个项目不是一句 Prompt 就生成成品的，也不是我从白纸开始独立定义需求。更准确地说，这是一篇跟做复盘：教程给了完整需求和主路线，我用 Vibe Coding 把它一步步落地，并在实现过程中持续处理问题、调整体验、补上一些更适合自己的细节。

回头看，它有很明显的阶段推进：先把下载能力跑通，再扩成 AI 总结器，然后补体验细节，最后把整个交互打磨成一个真正顺手的工作台。

先把”下载”这件事跑通

先把最简单的链路跑通，验证项目基础可行性。

项目最开始并不是我自己拍脑袋定义一个”AI 视频助手”，而是按照教程的主线，先去做一个浏览器里就能用的万能视频下载器。之所以从这里开始，是因为教程本身就是这么拆的，而且这个阶段最容易验证。只要用户粘贴链接，系统能解析视频信息、给出画质选项、完成下载，这条主链路就算成立。

技术选型上，一开始就不想自己造轮子。多平台下载这种能力，最合理的做法就是站在成熟开源项目上做封装，所以核心下载能力直接选择了 yt-dlp。后端用 Flask 跑 API 和下载流程，前端后来演进成了 Vue 3 + Vite，核心目标都是尽快做出一个能用的版本。

这一阶段 AI 最有帮助的地方，是让我在跟教程实现的过程中，能更快把需求翻译成可运行的后端接口、任务流程和前端骨架。真正需要我自己判断的，不是大的功能方向，而是实现细节：哪些能力直接复用开源项目，哪些地方保持轻量，哪些地方再按自己的使用习惯调整。

从下载器扩成总结器

下载只是手段，理解视频才是目标。

下载功能跑通之后，项目继续沿着教程主线往下走，开始进入我最在意的那部分：不只是把视频存到本地，而是快速理解视频内容。加入 AI 总结之后，它才开始接近我真正想要的那个东西。

这一轮迭代的核心是把”下载视频”扩展为”理解视频”。后端增加了字幕提取、总结任务、流式返回和问答接口；前端则需要承接总结、章节、思维导图和字幕原文这些内容。这里最关键的一个现实是：AI 总结并不是凭空理解视频，而是先拿到字幕，再基于字幕做结构化生成。

这一步一旦想清楚，整个链路就会变得很明确：提取字幕 -> 截断和整理文本 -> 调用 DeepSeek -> 按约定格式拆出总结、章节和导图。

AI 在这一阶段依然很好用，但方式跟第一轮不太一样。第一轮更像是按教程把骨架搭起来，第二轮则更像是在已有目标下把接口和数据流补完整。比如总结结果怎么分块、章节和思维导图怎么组织、进度如何反馈给前端，AI 都能很快给出一版实现；但最终还是要我自己决定：什么样的输出结构才真的适合阅读和后续迭代。

把能用补到好用

能演示和能上手之间，差的是反复打磨细节的耐心。

主链路打通以后，项目并没有马上结束。相反，真正花时间的部分，往往是把”可以演示”补到”真的顺手”。

这一轮我主要做的，是把教程里的几项关键能力真正落到页面里，并把体验做顺。比如 Markdown 渲染、思维导图全屏与导出、SRT 字幕下载、基于总结继续问答，我在跟做过程中花了不少时间让 AI 反复调整，直到每项能力都真正顺手。

这一阶段也最能体现 Vibe Coding 的真实样子。大方向上，AI 能很快给出一个可用方案；但一旦进入导图导出尺寸、字幕格式兼容、Markdown 排版细节、问答错误处理这些地方，事情就会从”写功能”变成”反复试、反复修”。真正耗时间的，往往不是功能有没有，而是体验有没有做顺。

从功能堆叠到同屏工作台

用户不需要自己把模块串起来，产品应该替他们做好衔接。

项目后期，开始把注意力从”功能清单”转向”使用感受”。最明显的一次调整，是把原本相对分离的下载区和总结区，改成了左右同屏的工作台：左边负责视频信息、画质选择和下载，右边负责 AI 总结、章节、思维导图、字幕和问答。用户解析成功之后，会自动开始总结，而不是再多点一次按钮。

这看起来像前端小改动，但影响很大。因为一旦进入同屏工作台，用户理解项目的方式就变了：它不再是”先下载、再去另一个区域看总结”，而是”围绕一个视频展开的完整工作流”。

后面做右侧面板内部滚动、桌面端固定工作区、移动端堆叠布局、下载完成卡片收起/展开，甚至双击输入框隐藏 Slogan 这种演示友好的需求，本质上都属于同一件事：让项目从”功能堆叠”变成”真正能顺手使用，也方便展示”的产品形态。

04 踩坑与解决

如果要挑几个最能代表这个项目真实难点的问题，我会选下面三个。它们都不是抽象的“AI 好不好用”，而是这个项目在真正落地时必须面对的具体问题。

问题 1：不是所有平台都能稳定拿到字幕，B 站必须单独处理

• 现象： AI 总结依赖字幕，但不同平台字幕来源和格式差异大，B 站直接用通用方案不稳定。
• AI 帮了什么： 快速搭出字幕提取、格式解析和总结链路的第一版。
• 自己做了什么： 发现问题后，判断方向——给 B 站单独做一条路，查 B 站弹幕/字幕 API，优先选中文字幕。

不再把"字幕一定能拿到"当成默认前提，而是把字幕提取当成需要单独治理的上游依赖。能跑通不代表稳定——外部依赖的脆弱性必须主动暴露和处理。

问题 2：AI 输出不是生成完就能用，先得约定好结构

如果只是让 AI “总结一下视频”，它确实能写出内容，但未必适合被前端稳定展示，更别说继续拆成章节、思维导图、字幕和问答。AI 可以给出多种输出格式让我选，但选哪种、怎么约束，需要我自己拍板。

我对比了三种方案：

最终选择了固定分隔符，用 ===SUMMARY===、===CHAPTERS===、===MINDMAP===、===SUBTITLES=== 把输出切成不同段，后端正则切分 + 前端按字段渲染。方向是我定的，代码是 AI 写的。

AI 输出和前端展示之间的对接，必须一开始就当作独立问题来设计，而不是事后打补丁。

问题 3：功能都有了，但页面流程并不顺，最后改成同屏工作台

下载和总结能力都具备之后，页面依然不够顺。AI 可以快速给出多种布局方案，但哪个方案真正好用，需要我自己反复体验来判断。

改前问题：

• 下载区和总结区分离，流程断裂
• 用户需要手动触发总结
• 演示和实际使用都不够自然

改后体验：

• 左右同屏工作台：左下载，右总结
• 解析成功后自动触发总结
• 移动端自动堆叠为上下布局

流程不顺的根本原因不是"功能不够"，而是功能之间的衔接方式不对——用户不该自己把各模块串起来。

如果重做一次，我会怎么改

如果从头再来，我大概率不会换掉这套轻量技术栈。Flask + Vue 3 + yt-dlp + SSE 对这样一个中小型项目来说是够用的，关键是它让项目可以很快进入可迭代状态。不过我会在更早的时候就把几件事想清楚：第一，字幕提取是上游依赖，不能把它当成理所当然；第二，任务状态管理和清理策略最好一开始就定好；第三，文档要及时跟着代码走，不然多轮 AI 迭代之后，最先失真的往往不是代码，而是你对项目现状的描述。

05 Vibe Coding 的真实体验与边界

做完这个项目之后，我对 Vibe Coding 的感受比一开始更具体了。对这种”教程给方向，自己负责落地和收口”的场景来说，它非常有效。教程解决的是”做什么”，AI 帮我加快的是”怎么把它做出来”，最后真正决定结果的，还是你怎么验收和调整。

它最适合什么

Vibe Coding 最适合目标明确、链路可验证、可以边做边验收的项目。教程已经把主路线给出来了，你只需要把注意力集中在实现、验证和调整上。

我觉得 Vibe Coding 最适合的，是这种目标明确、链路可验证、可以边做边验收的项目。尤其是像这次这样，教程已经把主路线给出来了，你不需要从零定义需求，而是把注意力集中在实现、验证和调整上。这个视频下载总结器就是典型例子：链接能不能解析、下载能不能完成、总结结构顺不顺、导图能不能看，这些反馈都很直接。

它也特别适合”先做出一个版本，再慢慢打磨”的任务。如果一开始就要求完整、稳定、抽象优雅，AI 往往会给出一套看起来很完整、实际上未必适合当前阶段的方案；但如果目标是先把东西做出来，再一点点补细节，Vibe Coding 的优势就会很明显。

它不适合什么

Vibe Coding 可以帮你推进实现，但不能替你做产品判断。进入外部依赖复杂、状态多、边界条件多的部分时，AI 很容易写出"看起来对、实际一跑就漏问题"的实现。

它不适合把所有判断都交给 AI。尤其当项目进入外部依赖复杂、状态很多、边界条件多的部分时，AI 很容易写出”看起来对、实际一跑就漏问题”的实现。这个项目里，字幕提取、SSE 状态管理、思维导图导出、错误处理，几乎都属于这种区域。

换句话说，Vibe Coding 可以帮你推进实现，但不能替你做产品判断。哪些体验算顺手、哪些异常必须被显式处理，这些地方最后还是得自己拍板。

跟传统开发相比，效率和代码质量怎么样？

效率

效率提升集中在启动阶段——把"从零手写每一层"的成本大幅压低，但"判断项目该往哪里走"这部分并没有变少。

传统模式下做这样一个项目，光是搭后端框架、配前端工程、组织下载链路、设计总结接口这些基础设施，就需要不少时间，而且很多工作在动手之前就已经在消耗动力了。Vibe Coding 把这一层成本大幅压低——我可以更快把骨架做出来，再边用边改。

代码质量

AI 生成的代码初始质量低于手写，但差距可以通过迭代追回来。真正危险的不是"AI 写的代码差"，而是人以为"能跑就等于完成了"。

传统开发中，写代码的人通常对整体结构有更连贯的理解，边界处理也更自觉；而 AI 更偏向功能堆叠，边界条件往往要等跑起来才暴露。这个项目里，字幕格式兼容、SSE 状态管理、思维导图导出尺寸这些问题，都是在后续迭代中才逐步补上的。不过只要愿意持续收口——验收、修正、同步文档——几轮之后的结果并不会差到不可维护。

如果没有后续的验收、重构和文档同步，代码质量问题迟早会暴露出来。这个项目后面补任务清理、错误处理和文档治理，本质上都是在补这一课。

06 总结

我之前缺的不是兴趣，也不完全是需求，而是一条能把需求真正转成动作的路径。需求早就存在，只是以前的我会下意识地忽略它——直到看到别人把它整理成完整教程，才真正觉得"这件事原来可以开始做"。

写到这里，我反而更确定一件事：我之前缺的不是兴趣，也不完全是需求，而是一条能把需求真正转成动作的路径。这个视频下载总结器就是这样。需求早就存在，只是以前的我会下意识地忽略它；直到看到编程导航把它整理成完整教程，我才真正觉得，“这件事原来可以开始做。”

对我来说，这个项目做到现在其实已经结束了。它的功能已经完整覆盖了我的需求，不需要我再继续往上叠更多东西。比起无限扩展功能，我更在意的是它现在已经真正可用。

也是在这个阶段之后，我才额外补上了 Docker Compose 一键部署。它不属于前面那些”把功能补到好用”的内容，而是项目已经满足我的核心需求之后，为了让它能更快启动、并且在后台稳定运行，才继续往前多做的一步。

到这里，这个项目对我来说就已经完整了：它既覆盖了我的需求，也让我真正体验了一次，如何沿着一条刚好击中痛点的教程，用 Vibe Coding 把它一步步做成自己能长期使用的版本。