---
title: "Tsuzuri：AI 時代又再做一個字幕編輯器，是在重複造輪子嗎？"
date: 2026-09-30T00:00:00+08:00
publishDate: 2026-09-30T00:00:00+08:00
lastmod: 2026-09-28T17:24:42+08:00
tags: ["LLM","AI","經驗","Rust","字幕","ASR","翻譯"]
toc: true
permalink: "https://blog.aotoki.me/posts/2026/09/30/tsuzuri-reinventing-subtitle-editor/"
language: "zh-tw"
---


近期我印象最深刻的，是 YouTuber [壹加壹](https://www.youtube.com/@illyandlean)開發的 [What'Sub](https://whatsub.equal2.app/) 這套字幕工具，大多數情境只要有人需要處理影片字幕，我通常會直接推薦。

然而，時間往回推半年前左右，朋友來問我「有沒有辦法做逐字稿？」「有辦法對逐字稿做翻譯嗎？」的問題時，都有一個前提「不能用雲端」這就讓市面上大多數選項無法使用。

這個時代很棒的一點，就是 AI 讓任何人都能針對自己需求客製化，而 [Tsuzuri](https://github.com/elct9620/tsuzuri) 剛好在這樣的背景下誕生。

<!--more-->

## 隱私優先{#privacy-first}

最初，朋友會提起這個需求是因為他的女朋友正在讀心理相關的科系。需要處理的大多是有個人資訊的問題，但是過去這樣大量的資料要做語音轉錄，並不是那麼容易。

但是 AI 時代下，我們還能夠取得「開放權重」模型，就讓我們有很多不同的選擇，像是聯發科的 [Breeze-ASR-25](https://huggingface.co/MediaTek-Research/Breeze-ASR-25) 對台灣人說話、口音都有非常好的辨識能力，已經有非常多專案在使用。

最初我是找了一些開放原始碼的圖形化工具給朋友使用，然而用起來並不方便，而且我自己用 [MacWhisper](https://www.macwhisper.com/) 也沒有這樣的困擾，因此我們最後選擇用 [Whisper.cpp](https://github.com/ggml-org/whisper.cpp) 的命令列工具來處理，幸好我的朋友對這類型的工具使用沒有太大的困難。

後續的翻譯需求也是相同的情境，雖然不清楚原因，但是在學校學術相關的議題也會有英文翻譯的需求，我先使用 [LM Studio](https://lmstudio.ai/) 搭配簡單的 Python 腳本，盡可能讓整個處理都能從純人工，轉換到半自動的處理。

要在完全離線的前提下做這些事情，最困難的是朋友只有一台筆電，搭載的顯示卡是 RTX 3050 4G VRAM 的規格，至少市面上大部分語言模型都跟他的筆電無緣，這很可能更接近現實的情境。

## 真的有用{#it-is-useful}

Tsuzuri 的誕生是在上週，朋友告訴我他想寫一份教學，來教身邊認識的人使用我提供給他的解決方案，因為在學校和學生，有不少人有類似的需求存在。

我當下直覺的反應是「你認真要教大家用一個 Command Line 工具嗎？」以及提醒他，在做翻譯工具時，我有跟他說過「這只是概念驗證，好用我會做成有圖形化介面的版本」

當他告訴我想推廣給別人的時候，我的直覺告訴我不能再把「桌機版」這個選項擱置，剛好 Anthropic 提供了一次用量重設跟 $250 的雲端額度，搭配中秋連假根本是最佳的開發時機。

真正的挑戰在於，如果是朋友的筆電我已經很清楚硬體狀況，也能直接在線上協助排除錯誤，但要推廣到更多人使用，問題又更加困難。

## 你只是少數{#you-are-minority}

有 AI 訂閱、有不錯的顯示卡等等條件，雖然因人而異，然而在工程師或者跟科技相關的產業，大家可能會很習以為常，也就是「大家條件差不多」這樣的感覺。

當你把視野放到更多不同的領域跟產業時，確實都會有少數人正在嘗試 AI 做些什麼，更多的人可能幾乎沒用過，或者只依靠免費方案以及手邊有的裝置在工作，把很多現實的因素放進去後，能做的事情往往比原本預想的困難。

> 以 $20 的訂閱費來說，按照 2027 年台灣的最低工資標準，大概會用掉 2% 的月薪，如果是 $100 的訂閱費，就佔用月薪的 10% 左右，對大多數人來說不一定是「必需品」如果想要完全離線，顯示卡也因為 AI 變得貴非常多，至少很難當作選項。

也因此 Tsuzuri 的開發由我來負擔，實際的使用跟驗證則是由朋友測試，我們利用中秋連假三天左右的時間，打造一款能減少朋友一半處理字幕時間的工具。

在設計上，就需要考慮像是 CUDA 很難安裝、GitHub Actions 要解決 CUDA 預先編譯等複雜問題，假設使用者是使用 AMD 顯示卡或者根本沒有顯示卡，還有沒有機會正常使用等等因素都要考慮到軟體設計裡面。

> 不論是過去的「記帳軟體之亂」跟「輸入法之亂」我認為在解決個人問題的層面 AI 是非常好的工具，但是拓展到有更多使用者的時候，考慮的問題和面向就會差異很多，這也是專業工程師在 AI 時代的價值之一，過去也曾分享過[我不認為專業會被取代的理由](https://blog.aotoki.me/posts/2026/01/28/design-pattern-in-ai-era/)，給一個人用跟給一千個人使用，思考的方式是不同的。

## 好用的定義{#definition-of-useful}

大部分時候，我都是把自己用的工具隨手放到 GitHub 上，有實際使用者的情境不多，這次是處理朋友的需求，因此我的功能基準都是以「朋友覺得順手」當前提，也不打算接受任何人的需求。

在 AI 時代要修改、調整軟體很簡單，但是處理「需求」仍然困難，以我們在中秋連假的狀況為例子，第一天我把基礎功能的版本提供後做了幾次修改，讓軟體可以開始編輯字幕後，隔天我拿到大概 30 個不同情境的需求，這些都是真實而且影響使用的。

假設開放讓所有使用者都提出需求，很快地就會出現 A 覺得好用 B 覺得難用的狀況，怎樣處理廣大使用者的需求找到交集，也是軟體開發常見的難題，厲害的軟體產品通常都是依靠幾個主要使用者品味，或者細緻調整協調才能達到，這也是為什麼我不覺得 AI 會讓商業軟體服務被自製工具取代，個人覺得好用跟大多數人都用得順手，是不同的概念。

在這幾天的時間，我跟朋友處理的都是「怎樣可以讓工作流暢」的問題，其中很多問題，可能都源自於歷史的包袱。

## 習以為常{#historical-baggage}

這些字幕編輯的設計，很大一部分是源自於過去並沒有像是語音辨識（ASR，Automatic Speech Recognition）這樣的技術存在，是為了讓人類可以「聽」然後「打」的設計，因此很多地方在現代編輯字幕的方式下是不流暢的，不同軟體的優點也沒有互相學習累積。

因為最初的出發點是「語音辨識」所以我們的字幕大多不是現存的，會直接從影片或者錄音檔產生，那麼字幕編輯軟體的「自動停止播放」可能就不太好用，字幕已經存在，要做的事情從「輸入」變成「檢查」所以在這些機制上就會做出一定的調整。

既然目的是檢查，字幕大多數時候不會是一份，而是像這樣的結構

- （草稿）語音辨識版本
- （備份）第一次修正
- （目前）處理中的版本

字幕軟體並不會有「比較」的設計，在 Tsuzuri 下則是變成預設的能力，每當編輯後就會顯示跟上一個版本的差異，這樣「檢查」的效果就會更好，不用來回確認上一次的進度，相應的重新翻譯某個區塊、重新對某段時間做語音辨識，也是類似的用意。

除此之外，還有一個我認為很有趣的需求。

在編輯字幕時，通常會搭配一個影片的預覽，根據朋友的描述字幕軟體是無法將預覽「分離」到視窗外的，但現在大多數人很可能有多個螢幕，因此能夠分離反而可以把字幕的編輯空間加大，同時又可以讓預覽在獨立的螢幕更好確認呈現。

還有很多根據編輯習慣調整的設計就不特別整理出來，但正因為是 AI 才能讓我們很快地打造這樣的工具。

## 重新思考{#rethinking}

我認為這次是一個很有趣的開發經驗，在過去很難想像這種「我有需求就開發」的方式，一個工程師的時間在這樣的成本下是很不划算的，但是 AI 時代讓這件事情發生。

我記得自己開始比較仔細記帳，也是因為記帳用的腳本處理起來很花時間，但是用 AI 很快就能處理到可用，就開始認真做記帳，因為那種「差一點點」的小事終於有低成本的方式解決。

以 Tsuzuri 來說，三天左右的開發花掉的 Token 拿 API 換算，可能有數千美金左右，但以一次性的成本，換來朋友處理字幕能快一倍（根據目前實際處理字幕測試的狀況）長期來看是很值得，而且這表示朋友可以有更多時間，或者能把時間拿去其他更有用的地方，都是很有意義的。

我們預期的新技術發展總是能這樣，即使現在 AI 在很多人類「希望」可以自動化的地方仍然不能很穩定的運作，但至少可以看到這樣的未來，我認為還是很值得期待的，最危險的反而是那些還保持「動手做重複性工作」心態的人，因為我們想要靠新技術解決，讓大家往更多創造性任務前進的理由，仍有這種心態就很容易被新技術取代掉。

同樣的，AI 時代能自己創造工具，並不一定總是在重複造輪子，而是能針對不同情境做出更細緻的區別。

> 手寫程式並不一定等於做重複性工作，雖然這個專案是完全依靠 Claude Code 開發，但是過去每一次手寫程式會注意到的細節差異學到的知識，都很好的被應用在開發過程中，正因為有嘗試過各種不同的做法，才能在新的問題出現時，重新思考怎樣的設計最適合。