从踩坑到打包：我用AI一天做出一个视频上字幕工具

本文记录「视频上字幕工具.exe」从需求到成品的完整开发过程——不是教程搬运，是真实踩坑实录。

一、起点：一个很小的需求

那天晚上我在剪一支B站视频，3分38秒，需要上字幕。正常流程是：打开剪映→识别字幕→逐条校对→导出。但我不太信任在线工具的隐私，也不想为每条视频都开一次剪映，就想着：语音识别这种事，本地能不能一条命令搞定？

于是有了最初的需求：把一个视频文件丢进去，旁边自动出现一份带时间轴的SRT字幕。就这么简单。

二、第一次尝试：环境全是坑

本地语音识别，业界标准答案是 faster-whisper。装上、跑起来，理论上十分钟的事。实际呢？我在自己这台机器上连续撞了四个坑。

坑一：torch 直接罢工。 机器上已有的 Python 环境里装着 torch，但加载 DLL 时报错。只要是间接依赖 torch 的库，全部阵亡。

坑二：ctranslate2 新版本段错误。 换了干净环境装 faster-whisper，模型一加载，进程直接 Segmentation fault——没有任何报错信息，就是无声无息地死。查下来是 ctranslate2 4.8.1 的二进制和这台机器不兼容，降到 4.4.0 立刻正常。

坑三：模型下载不下来。 HuggingFace 直连超时。设了国内镜像（hf-mirror.com）之后，几秒下完。

坑四：VAD 组件带崩。 语音活动检测依赖 onnxruntime，这台机器上它的 DLL 也加载失败。好在 VAD 是可选的——关掉，识别照样跑。

四个坑，说穿了都是环境问题。同一个工具，换一台机器可能一行命令就通；但要在自己的主力机上稳定跑，就得把每一个依赖都钉死版本。 这是所有本地AI工具的共同宿命。

三、第二次迭代：从"能跑"到"能用"

环境通了，转写也出来了，但新问题暴露出来：中文语音识别的同音字错误多到没法直接用。

那支视频的字幕，识别稿里有四十多处错：副业识别成"复业"，报522识别成"爆5R2"，Emlog 识别成"AMLOCK"，Nginx 反代识别成"Jinks反带"，银河麒麟识别成"迎合其林"。如果直接发布，观众一眼就看出是机器转的，观感很差。

解法很朴素但很有效：因为视频是我自己录的，我手里有口播稿。 拿识别稿和口播稿对照，专有名词和数字一律以稿子为准，再顺手统一"他/它"指代、清理中文之间的多余空格。四十多处修正，两分钟扫完。

到这里，流程变成了三步：转写 → 对照纠错 → 校验格式（时间码、序号完整性）。一支3分38秒的视频，全程不到三分钟出片级字幕。

四、第三次迭代：做成给别人也能用的软件

上面的流程对我不是问题——但对不懂命令行的人，等于没有。

所以第三步是封装：做一个图形界面，选文件、选模型、点开始，字幕自动生成在视频旁边。界面用 Python 自带的 tkinter，不引入任何额外依赖：一个文件路径框、一个模型下拉框（小模型快、中模型准，各取所需）、一个语言选择、一个实时滚动的日志区、一个状态灯。模型文件首次使用时自动下载到用户目录，之后永远离线可用。

这一步的关键设计只有一个：把"踩坑经验"直接写进代码。 比如模型下载走国内镜像、禁用有问题的VAD组件、输出用带BOM的UTF-8防止某些编辑器乱码。用户不需要知道这些坑的存在，因为坑已经提前填好了。

五、打包：最后一公里，坑最密

软件能跑，但它还是一堆 Python 脚本。要发给朋友，得打包成单个 exe。

用 PyInstaller 打包，又撞了三个坑：

坑一：打包出来的exe双击闪退。 控制台版正常，图形版必死。原因很隐蔽：图形模式下 Python 的标准输出是空的（None），而底层库初始化时往标准输出打印日志，一打就崩。解法是在程序入口加一个"垫片"：检测到输出流为空，就把它重定向到黑洞文件。三行代码，救活了整个程序。

坑二：重新打包总是失败。 报"拒绝访问"。原因是测试时启动的旧进程还占着exe文件。更有意思的是：exe 改名之后，进程名也跟着变——按旧名字去杀进程，永远杀不掉。这个坑坑了我两次。

坑三：验证脚本自己也有坑。 用 PowerShell 脚本做自动化验证，中文字符串在无BOM的脚本文件里全部乱码。最后改用 Python 做验证，一次通过。

最终产物：一个94MB的单文件exe，免安装，双击就用。冒烟测试通过，窗口正常，转写正常。

六、复盘：AI时代的开发模式变了

回头看这个过程，最值得说的不是工具本身，而是开发方式。

全程我没有"写代码"——我是"提需求、验收、看报错"的那个角色。环境撞坑，是 AI 一个个版本试出来的；界面，是一句话描述出来的；打包踩坑，是 AI 看日志定位的。我的输入始终是自然语言："做一个能选视频、生成字幕的窗口程序"。

传统开发里，"会写代码"是门槛；这次开发里，"会描述需求、能判断结果"才是门槛。前者需要多年训练，后者几乎人人都有。

最后做了一件事：把整个开发过程——包括所有坑和它们的解法——沉淀成了一份可复用的"技能"文档。下次再遇到"给视频上字幕"的需求，从踩坑到产出只要一分钟，因为路已经修好了。

工具很小，一天就做完了。但这个模式可以复制：发现重复劳动 → 让AI做成工具 → 把坑沉淀成文档。这才是普通人用AI的正确姿势：不是每次都从零开始问，而是把每一次折腾都变成资产。

本文案例全部来自真实开发记录，工具与踩坑细节可复现。