• ImageGlass
• Honeyview
• XnView MP
• Windows 內建相片 App
• QuickLook

ImageGlass

這款軟體非常直覺，只要你開啟資料夾中的第一張圖，視窗左右兩側會有隱形的點擊區域。

• 操作方式：直接點擊圖片的右半部即可切換到下一張，點擊左半部則是上一張。
• 工具列：視窗上方也有明顯的箭頭按鈕可以一鍵切換。

ImageGlass 下載: https://imageglass.org/releases

建議使用: “Get ImageGlass Classic” 的方式來下載安裝檔.

在安裝的過程, 要小心, 不要把綑綁的 Opera 也一起安裝, 要選正中間的 “Install ImageGlass only”

Honeyview

Honeyview 對於大量圖片切換的優化做得非常好。

• 操作方式：視窗下方有一條控制列，上面有大型的往左與往右箭頭，點擊即可切換。
• 滑鼠滾輪：它預設支援使用滑鼠滾輪切換圖片，向上捲是上一張，向下捲是下一張，操作速度非常快。

XnView MP

這款軟體在預覽模式下也支援滑鼠操作。

• 操作方式：在全螢幕或視窗模式下，你可以設定點擊滑鼠左鍵切換到下一張圖，完全不需要找按鈕。

Windows 內建相片 App

其實 Windows 內建的程式也支援一鍵切換，只是按鈕比較小。

• 操作方式：滑鼠游標移到圖片邊緣，會出現半透明的箭頭圖示，點擊即可。

QuickLook

如果你是希望在不用開啟任何軟體的情況下切換，QuickLook 本身也支援類似功能。當你按下空白鍵開啟 QuickLook 預覽視窗後，只要用手指點擊鍵盤的方向鍵（下或右），預覽視窗就會自動跳到下一個檔案，這對於快速過濾資料夾內的照片非常有效。

QuickLook 下載:
https://github.com/QL-Win/QuickLook/releases/tag/latest

Files 是一個在 GitHub 上非常受歡迎的開源專案，目標是打造一個介面美觀且功能強大的替代方案，讓檔案管理變得更直覺。

Files 使用體驗更佳, 介面也很漂亮, 安裝檔案下載:
https://files.community/appinstallers/Files.stable.appinstaller

Files 使用說明:
https://files.community/docs/getting-started/overview

Files 的預設值是刪除檔案都會彈出確認框, 實在很煩, 應該可以在 Shift + Delete (直接永久刪除) 時彈確認框就好了.

使用 Files 的預設值去開啟「下載」資料夾時, 我其實很不習慣使用有「群組功能」的清單, 讓我感覺畫面反而更零亂, 可以在空白處按右鍵, 選「群組依據」, 再選無, 就可以關閉群組。

內建的檔案總管, 還有一個很兩光地方, 就是太貼心, 反而讓人覺得很難用, 例如: 開啟一個都是 mp3 的資料夾時, 會讓人暈到, 因為顯示的方式和上一層的完全不一致。

建議額外再安裝 QuickLook, 在 Files 按空白鍵, 可以直接預覽內容, 很方便, 檔案下載:
https://github.com/QL-Win/QuickLook/releases/tag/latest

Ctrl + Alt + I 切換右側的預覽視窗也做的很方便和漂亮.

我已經讓 Files 取代為預設的檔案總管, 因為比原本的好用太多.

Files 的操作完檔案之後, 右上角有一個「狀態中心」, 覺得很礙眼而且又設計的很強眼, 但又找不到設定值可以關掉, 只好練習無視右上角的勾勾.

現代化的介面設計與分頁功能

Files 最直觀的優點就是它的外觀。它採用與 Windows 11 系統一致的設計語法，看起來非常乾淨現代。最實用的功能之一就是分頁標籤，這讓你可以在同一個視窗裡開啟多個資料夾，就像使用瀏覽器一樣，省去在多個視窗之間切換的麻煩，桌面也不會再擠滿各種視窗。

效率倍增的雙面板與檔案標籤

這款軟體提供雙面板模式，讓你在同一個畫面中同時操作兩個不同的路徑。這在整理檔案或搬移資料時非常方便，不需要頻繁按複製與貼上。此外，它還加入了檔案標籤系統，你可以幫不同類別的檔案加上顏色標記，即便檔案散落在不同資料夾，也能透過標籤快速分類與尋找。

深度整合雲端硬碟與自定義選項

對於習慣使用雲端儲存的人，Files 提供了良好的整合，像是 OneDrive、Google Drive 或 iCloud 都能直接在側邊欄存取。它的設定選項非常豐富，無論是佈景主題、右鍵選單的內容還是操作快速鍵，都可以根據個人使用習慣進行深度調整，打造最適合自己的工具。

開源社群驅動的免費軟體

因為它是開源軟體，所以全世界的開發者都可以參與改進，這代表軟體更新速度很快，功能也會持續進化。你可以直接在 GitHub 的釋出頁面下載安裝檔，不建議從微軟商店取得，因為好像需要付費。

進入外觀設定

點擊視窗左下角的齒輪圖示進入設定，接著在左側選單選擇外觀。這個頁面集中管理所有跟視覺有關的選項，讓你可以調整視窗的整體風格。

選擇預設主題與模式

在應用程式主題區段，你可以手動切換深色或淺色模式，也可以讓它跟隨 Windows 系統的設定。下方有一個佈景主題下拉選單，裡面提供多種預先配置好的配色方案，你可以直接套用喜歡的色彩。

我個人是偏愛「深灰色」主題, 預設的主題對比太強烈, 黑色的部份太黑.

設定背景材質效果

你可以調整背景材質來改變視窗的透明感。開啟背景材質選項後，可以選擇雲母或亞克力效果。雲母效果會根據桌布顏色產生柔和的背景色調，而亞克力則會讓背景呈現半透明的磨砂玻璃質感。

自定義背景與色彩

如果內建的主題不能滿足需求，你可以點擊自定義按鈕。這裡允許你自行設定視窗背景與側邊欄的顏色。你只需要輸入顏色代碼或點選調色盤，就能把 Files 變成完全個人化的外觀。

視窗管理捷徑

• Ctrl + N 開啟新視窗
• Ctrl + T 開啟新分頁
• Ctrl + W 關閉目前分頁
• Ctrl + Shift + T 重新開啟關閉的分頁
• Ctrl + Tab 切換到下一個分頁
• Ctrl + Shift + Tab 切換到前一個分頁

檔案編輯與查看

• F2 重新命名選取的項目
• F5 重新整理頁面
• Alt + Enter 開啟內容內容視窗
• Ctrl + Shift + N 建立新資料夾
• Ctrl + Shift + C 複製檔案路徑
• Ctrl + F 啟動搜尋功能

效率與導覽功能

• Alt + Shift + D 開啟或關閉雙面板模式
• Alt + Up 進入上一層資料夾
• Alt + Left 回到上一個位置
• Alt + Right 前進到下一個位置
• Del 將選取項目移至回收桶
• Shift + Del 永久刪除項目而不進入回收桶
• Ctrl + L 選取網址列的路徑文字

解法:
https://github.com/yt-dlp/yt-dlp/issues/15586#issuecomment-3758088372

See this:
#15012

update installed yt-dlp and install deno or nodejs

pip install -U "yt-dlp[default]"

說明, 一定要執行上面這行, 會多安裝一些新的元件.

Linux/Mac users:

# install deno
curl -fsSL https://deno.land/install.sh | sh

# upgrade yt-dlp
pip install -U "yt-dlp[default]"

Windows 平台下載 mp3 使用 dl.bat

yt-dlp -x --audio-format mp3 --js-runtimes node --cookies c:\max\bin\www.youtube.com_cookies.txt --embed-thumbnail %1 %2

如果不需要使用 cookie 也可以下載話, 你可以使用這個 dl.bat

yt-dlp -x --audio-format mp3 --js-runtimes node --embed-thumbnail %1 %2

如果你是要下載影片, 直接使用 yt-dlp 下載, 無法下載到正確版本的影片, 請使用這個 dlvideo.bat

yt-dlp -f "bestvideo[ext=mp4]+bestaudio[ext=m4a]/best[ext=mp4]/best" --js-runtimes node %1 %2

取得瀏覽器的 cookies:

在 yt-dlp 改用 –cookies 參數來解決問題

你要先在 chrome 瀏覽器安裝擴充工具(extension): Get cookies.txt LOCALLY

傳送門: https://chromewebstore.google.com/detail/get-cookiestxt-locally/cclelndahbckbenkjhflpdbgdldlbecc

點下上面網址後, 按右上角的 “Add to chrome”

接著到 youtube 網站, 並登入你的Google 帳號.

在 chrome 瀏覽器網址列右側點開擴充工具的小圖, 並點擊 get cookies.txt locally 的小圖:

點擊 Export As

預設會取得 youtube 網站的 cookies 並儲存到「下載」的資料夾下,

我是使用 “Export As”, 請把 www.youtube.com_cookies.txt 檔案移到一個你記得起來的與 youtube 外部指令相關的資料夾, 我放在 C:\max\bin\ 目錄下,

想偷懶, 不想多點幾下滑鼠去選擇資料夾, 也不想用鍵盤打太多字的話, 可以直接在檔案名稱第一個字之前插入一個 \ 符號, 就會直接存到根目錄.

不用自己架設網站, 就可以有自己的網站, 網頁上傳的圖片會放在自己的 google drive, 收集的提示詞儲存於 google sheet, 刪除的照片會移動到 google drive 的垃圾桶.

下載點: https://github.com/max32002/PromptNano

執行畫面:

YouTube: https://youtu.be/gbjrb-OC3Qw

PromptNano 是一個輕量級、視覺化的 AI 提示詞（Prompt）管理工具。專為 Nano banana, chatGPT, Midjourney、Stable Diffusion 等 AI 創作者設計。

不同於冷冰冰的文字表格，PromptNano 讓你透過「看圖」的方式直覺管理靈感。搭配溫暖可愛的 UI 設計，支援深色/淺色主題切換，讓整理提示詞變成一件療癒的事。

本專案使用 Google Apps Script 架構，支援線上使用流暢的操作體驗。如果想在本地端或雲端虛擬主機上使用，可以使用 Node.js + SQLite 架構的 PromptNano-Node。

主要功能

• 視覺化瀑布流 捨棄枯燥的文字列表，採用卡片式瀑布流設計，透過圖片直接回想並複製提示詞。
• 雙色溫暖主題 內建「草莓牛奶（淺色）」與「黑巧克力（深色）」兩種主題，隨點隨切，所有介面與彈窗完美適應。
• 智慧標籤檢索 支援 #Tag 快速過濾與關鍵字搜尋。輸入框右側附帶一鍵清除功能，操作更流暢。
• 內建詠唱秘籍 整合「提示詞教學」模組，包含逆向工程技巧、光影氛圍關鍵字與手繪風格指令，點擊關鍵字即可一鍵複製。
• 繁體中文友善 新增的提示詞都會先轉換為繁體中文再存入Google Sheet資料庫。
• Google Drive 整合 基於 Google Apps Script (GAS) 開發，圖片與資料直接儲存在你的 Google Drive 與 Sheets，無需架設伺服器。

技術架構

• Frontend: HTML5, CSS3 (CSS Variables for Theming), Vanilla JavaScript
• Backend: Google Apps Script (GAS)
• Database: Google Sheets (儲存資料), Google Drive (儲存圖片)

如何部署 (Installation)

本專案適合部署於 Google Apps Script 環境。

1. 建立 Google Sheet 在 Google Drive 建立一個新的試算表，記下網址的 Spreadsheet ID。 在 Google Drive 建立一個用於上傳的資料夾，記下網址的 Folder ID。
2. 建立 Apps Script 在試算表中點擊 擴充功能 > Apps Script。
3. 貼上程式碼
   • 將 Code.gs 的內容複製到編輯器的 .gs 檔案。
   • 建立一個 index.html 檔案，將前端代碼貼入。
4. 發布為網頁應用程式 點擊右上角 部署 > 新增部署作業 > 選取 網頁應用程式。
   • 執行身分：我
   • 誰可以存取：任何人 (或僅限自己)
5. 開始使用 取得生成的 Web App URL，即可開始管理你的靈感庫。

如何詠唱出你自己的版本 (Build app prompt)

生成 Google Apps script + html 網頁的 AI提示詞:

使用 google GAS, 寫一個相簿管理的網站, 網頁顯示風格為溫暖可愛, 上傳的圖片要在放 google driver 指定的上傳路徑, 上傳後自動產生縮圖, 圖片的屬性有:標題,說明欄位,tag,圖片實際google driver 存放路徑.

前端相簿網頁, 可以輸入關鍵字進行圖片的說明欄位過濾查詢,

前端相簿網頁在顯示上傳的照片時, 以縮圖的方式顯示, 並將圖片的 hash tag 欄位以 # 號進行分隔顯示, 點下某一個 tag, 以 tag 名稱過關鍵字, 對 tag 欄位進行 "#" + tag 名稱的過濾查詢,

點下某一個縮圖後,彈出實際完整圖片, 並顯示標題與說明欄位, 有要一個"複製" 的按鈕, 把說明欄位內容複製到剪貼簿.

如果你有VPS 或 GCP / AWS 的話, 修改掉提示詞裡的 Google GAS, 就可以取得你需要的程式碼了.

有了相簿管理程式之後，提示詞用於修改網站名稱與相關按鈕上的名稱：

修改溫暖相簿為"AI靈感資料庫", 圖片的說明欄位, 修改為"提示詞", 讓我們透過「圖片」直覺尋找提示詞， 結合強大的「逆向工程」分析，一鍵提煉雲標籤，讓創意隨取隨用。

增加刪除提示詞與相薄功能：

在圖片清單的頁面, 增加刪除照片的功能, 刪除前要讓使用者做確認後才實際從 google drive 與 sheet 中刪除資料.

以下增加微調元件位置，與增加提示與確認不使用瀏覽器內建指令：

* <button> tag 比照 hash tag 的 span 在 hover 時變換顏色.
* #uploadOverlay的  modal 彈出後, <input type="text" name="title"> auto focus()
* 移動 <button> 📋 複製提示詞 到 <div class="prompt-label">提示詞 (Prompt)</div> 右側, 讓使用者不用 scroll down.
* #detailModal 裡的 #modalTags 比照瀏覽清單的 hash tag 顯示方式與規則.
* #detailModal 裡的提供刪除該組照片的功能.
* 整個網站, 要支援深色主題/淺色主題的切換功能.
* 修改 confirm() 為使用 modal, 因為 confirm() 畫面太醜.
* 修改 alert(), 以 Modal 取代.

用來切換整個網站風格：

重新改寫這個整個網站的 css, 風格是可愛溫暖, 要支援深色/淺色主題的切換, 所有的彈出式 modal 都要套用到深色/淺色的主題.

增加”清除過濾”功能：

增加"清除過濾" button 在 search box 右側, 點下後清除 search 關鍵字, 並重新取得無關鍵字的 list.

「詠唱魔法秘籍」的新增, 也很奇葩，這句是提問，結果變成實作：

想在這個網頁增加提示詞教學的功能, 有那些設計的選擇, 教學的內容如下:
---
不知道怎麼下高品質的提示詞，也可以先去收集別人的作品，上傳給AI 之後，請 AI 分析圖片並生成可以生成出圖片的提示詞，有了提示詞再進行調整就比較有效率。

另一個方式是先知道常用的提示詞用於風格與質感...。

調整右側的按鈕：

調整 .header-top 下, 右側3個 button 在視窗width 較小之下, 要置右.

這句比較神奇，AI 反而給出更具建設性的解法，是要把右側的按鈕變成群組，並集體置右。

修改 hash tag 沒有正確被分隔開：

修改 <span class="tag" onclick="filterByTag('#opennana #nano', event)">##opennana #nano</span> 的顯示方式為:
tag 的內容, 以 "#" 進行 split, 前端顯示為多個 span tag.
span tag 的 text 不要顯示 # 符號, 

同一個檔案名稱在Google Drive 是可以同時存在，但使用者下載之後就會被覆蓋：

解決上傳檔案名稱相同造成的問題

這個解法最後只有修改上傳的檔名，加入前置的目前時間，例如 “20251230_” + 原檔名

增加 footer：

在不起眼的地方, 想增加版本號碼, 第一版是 1.0.0 版.

如果你是簡體中文的使用者，請註解掉文字轉換的scrip，因為提示詞都會先轉換為繁體中文再存入Google Sheet資料庫，看不懂 Code.gs 程式，可以服用下列提示詞對 Code.gs 進行修改:

移除程式中關於提示詞語言轉換繁體中文的程式碼，並確保上傳的資料內容維持正確。

更換主題 (Theme)

複製 index.html 內容貼到 AI, 提示詞:

重新改寫這個整個網站的 css, 風格是可愛溫暖, 要支援深色/淺色主題的切換, 所有的彈出式 modal 都要套用到深色/淺色的主題.

AI 自動生成網頁通常提供以下幾種主流風格：

按視覺氛圍分類

按專業功能分類

• 專業商務 (Corporate)：嚴謹排版、藍灰色調，適合律師、金融業。
• 藝術創意 (Artistic)：誇張漸層、不對稱設計，適合設計工作室。
• 沉浸式 3D (Immersive)：玻璃擬態、動態渲染，適合高端產品展示。
• 俐落電商 (E-commerce)：清晰網格、醒目 CTA 按鈕，適合零售業。

 小撇步：在 AI 生成指令（Prompt）中加入 Glassmorphism (玻璃擬態) 或 Clean Typography (乾淨排版) 等關鍵字，可以大幅提升產出的質感。

檔案結構

PromptNano/
├── Code.gs         # 後端邏輯 (處理圖片上傳、刪除、讀取 Sheet)
├── index.html      # 前端介面 (包含 CSS, JS 與 HTML 結構)
├── appscript.json  # 資訊清單（Manifest），記錄專案的時區、權限範圍（OAuth Scopes）與程式庫等核心設定
└── README.md       # 專案說明文件

版本紀錄

• v1.1.0 (2025-12-31)
  • 增加下載圖片按鈕。
  • 置換部份按鈕的圖示。
  • 調整部份顏色。
• v1.0.0 (2025-12-30)
  • 初始版本發布。
  • 實作深色/淺色主題切換。
  • 文字內容簡轉中。
  • 新增「詠唱魔法秘籍」教學模組。
  • 優化 RWD 手機版瀏覽體驗。

授權 (License)

本專案採用 MIT License 授權。 歡迎自由修改、使用或作為學習用途。

相關文章

• GAS 除錯
• GAS web app 與 Google drive 的「防盜連機制」造成圖片無法顯示
• GAS 執行的2種網址: 正式版 /exec , 測試版 /dev
• GAS – 編輯有版本的部署作業
• GAS appsscript.json 被稱為資訊清單（Manifest）
• GAS 雲端硬碟權限錯誤
• GAS 簡體中文字轉成繁中
• GAS 串接 telegram bot
• GAS 網頁服務
• GAS 跨檔案抓取資料
• GAS 寄送電子郵件
• GAS 用程式自動填寫試算表的格子
• Google Apps Script 入門教學

心得

Google 的 Apps script 真好, 給大家免費(有限流量)的圖床(Google Drive), 還可以架設免費的網站, 還提供免費的資料庫(Google Sheet).

在處理教學影片、訪談、Podcast 或逐字稿影片時，常見的需求是：只保留「有字幕的內容」，自動剪掉中間的停頓、空白或無聲段落。如果手動在剪輯軟體中一段段對齊字幕，不但耗時，也容易出錯。

這篇文章會帶你使用圖形化的設定介面，讓你不必記憶複雜的指令，即可透過滑鼠點擊完成剪掉影片空白段落。想了解複雜指令有附在下半部。

這套腳本，能自動刪除空白片段並保留語意內容。核心邏輯是先將影片轉成單聲道 MP3，再透過 OpenAI Whisper 生成 SRT 字幕。最後根據字幕的時間軸，利用 ffmpeg 進行影片裁切與合併。

建議安裝 AI 相關的 CLI, 使用指令: “幫我修正字幕檔的用字錯誤, 例如: 勇唱改為詠唱”

超讚的, 省下好多校稿的時間.

AI CLI（命令列介面）已經從單純的對話工具演進為能直接操作檔案、執行指令甚至修復 Bug 的智慧代理人（AI Agents）。以下是目前主流且功能強大的 CLI:

• Claude Code：由 Anthropic 推出。它能理解複雜的專案架構，適合進行大規模重構（Refactoring）或修復測試失敗。它的強項在於強大的邏輯推理能力。
• Aider：開源社群非常受歡迎的工具。它能與 Git 深度整合，每次修改程式後會自動生成適當的 Commit Message。它支援多種模型（如 GPT-4o, Claude 3.5/3.7）。
• Gemini CLI：Google 推出的官方工具。特色是擁有極大的上下文視窗（Context Window），可以一次讀取整個大型專案的所有程式碼，並支援多模態輸入。
• Cursor CLI：雖然 Cursor 以 IDE 聞名，但其 CLI 版本在工具編排（Tool Orchestration）上非常流暢，適合追求快速迭代的開發者。
• GitHub Copilot CLI：GitHub 官方提供的工具（透過 gh copilot 使用）。它主要功能是「翻譯」指令，當你忘記 git 或 docker 的複雜參數時，它可以幫你寫好指令並解釋其意義。
• Ollama：如果你想在本地端（Offline）執行 AI，Ollama 是首選。它讓你在終端機就能輕鬆下載並執行各種開源模型（如 Llama 3, Mistral, Gemma 等）。

語意切割 vs 靜音偵測

• 靜音偵測（silencedetect）： 僅判斷聲音能量高低，容易誤留呼吸聲、笑聲或環境雜訊，無法判斷語句邊界。
• SRT 字幕辨識： 判斷「人類說話的意義」，能確保剪輯出的片段具備完整語意。
• 最佳策略： 以 SRT 作為主判斷基準，輔以靜音偵測做品質檢查。

FFmpeg 音訊優化技巧

• 音量調整： 使用 loudnorm 過濾器可自動進行音量標準化，讓小聲變清晰、大聲不破音。
• 人聲增強： 透過 highpass=f=80 濾除低頻噪音（如冷氣聲），並用 equalizer 提升 3000Hz 頻段強化清晰度。
• 去噪處理： afftdn 能智慧去除背景底噪，agate 則可在沒人講話時自動關閉音量。
• 環境感： 加入微小的 aecho（如 40ms）能模擬錄音室空間感，讓聲音聽起來更厚實。

解決 Whisper 辨識異常

• 幻覺與長片段問題： 若模型在空白處亂寫或時間軸拉太長，應縮短 min_silence_duration_ms（如 500ms）並關閉 condition_on_previous_text。
• 強制切分： 設定 max_speech_duration_s（如 15 秒）限制單一片段長度，避免多句話被擠在同一個時間戳。
• 效率提升： 使用 faster-whisper 並配合 VAD（語音活動檢測）進行平行處理，速度比原版快 4-5 倍。
• 增加簡體轉繁體字，避免whisper 誤判。
• 由於模型產生的 segment 不等於「一句話」，最穩定的做法是在程式碼中加入後處理邏輯：設定每行最大字數（如 22 字），若超長則平均分配時間點並換行。

YouTube: https://youtu.be/FNh-PhIEBPY

使用情境

這支腳本特別適合以下場景：

• 教學影片只保留講話段落
• 訪談或會議影片去除空白等待時間
• Podcast 錄影自動裁切發言片段
• AI 轉錄後，直接用字幕反推影片剪輯

你只需要：

• 一個影片檔（mp4 / mkv / mov…）
• 運行 ffmpeg + whisper 的電腦環境. (Mac / Linux / Windows)
• max 的腳本. (選配)

max 的腳本下載：
https://github.com/max32002/srt-video-cutter/

環境與套件需求

在開始之前，請確認以下環境已準備好：

• Python 3.8+
• 系統已安裝 ffmpeg , openai-whisper
• Python 套件：

pip install ffmpeg-python pysrt fastapi uvicorn python-multipart jinja2 openai-whisper setuptools-rust faster-whisper opencc-python-reimplemented

其中：

• ffmpeg-python：FFmpeg 的 Python 封裝，用來描述影片處理流程
• pysrt：專門解析 .srt 字幕檔的工具
• whisper：聲音轉 .srt 字幕檔的工具
• opencc：簡體字轉繁體字

腳本整體流程說明

video_cutter.py 程式的邏輯可以拆成 6 個步驟：

1. 讀取並檢查影片與字幕檔是否存在
2. 解析 SRT，取得每一段字幕的開始與結束時間
3. 對影片與音訊分別做 trim
4. 重設時間軸（PTS），避免剪接錯位
5. 將所有片段依序 concat
6. 輸出成一支新的影片檔

來源檔案轉換為單聲道 MP3 (16kHz), 是透過 ffmpeg 指令

ffmpeg -i input.mp3 -ar 16000 -ac 1 -ab 16k output.mp3

生成字幕, 是透過 whisper 指令

whisper audio.mp3 --language=zh --device=cpu --model=turbo

安裝的教學, 參考: https://max-everyday.com/2025/12/whisper-python/

指令的使用方式

python video_cutter.py input.mp4

video_cutter.py 實作的細節

不知道也沒差，建議直接略過這個區塊

1⃣ 合併過短字幕

• 設定最小片段長度（例如 0.4 秒）
• 若某段太短，嘗試與前一段合併
• 合併條件：時間間隔不超過指定閾值（例如 0.3 秒）

2⃣ 前後 padding

• 對每段字幕加上前後緩衝（例如 ±0.15 秒）
• 自動 clamp 在 0 與影片總長度之間
• padding 在「合併後」才套用，避免重疊錯亂

3⃣ 靜音偵測（輔助條件）

• 使用 ffmpeg 的 silencedetect
• 先跑一次分析音訊，取得靜音區段
• 若字幕區間完全落在靜音內 → 捨棄
• 若只部分靜音 → 保留（字幕仍有意義）

使用「靜音偵測」就不需要輸入 srt 字幕檔了嗎?

這是一個非常關鍵、而且問得很精準的問題。結論先給你，再把背後的設計邏輯一次說清楚。

結論一句話：
只用「靜音偵測」可以剪影片，但「不能等價取代 SRT（Whisper）」；兩者的角色本質不同。

先把兩者在「影片自動切割」中的定位講清楚。

Whisper 產生的 SRT，本質上是在回答一個問題：
「這段時間，人類在說『有意義的話』嗎？」

而靜音偵測（silencedetect），回答的是另一個問題：
「這段時間，聲音能量是否低於某個門檻？」

這兩件事不是同一件事，也不互為子集。

一、只用靜音偵測，不用 SRT，會發生什麼事？

你可以完全不用 SRT，只靠靜音來切，例如：

• 偵測所有非靜音區間
• 每段非靜音就是一個剪輯段

這在「技術上」完全可行，而且程式還更簡單。

但實際效果會有幾個不可避免的問題：

1. 會保留大量「沒有語意價值」的聲音
   例如：
   • 呼吸聲
   • 笑一下
   • 背景音樂
   • 咳嗽
   • 嘆氣、嗯、啊
2. 無法判斷「語句邊界」
   一句話中間短暫停頓 0.2 秒，
   靜音偵測可能直接把它切成兩段。
3. 對內容型影片不友善
   像是：
   • 教學影片
   • 訪談
   • Podcast
   • YouTube talking head
   你要的是「一句話一段」，
   不是「有聲音就留」。

因此：
只靠靜音偵測，剪出來的是「聲音片段」，不是「語意片段」。

二、那是否代表一定需要 SRT（Whisper）？

這要看你的「剪輯目標」。

可以這樣判斷：

如果你的目標是這種 → 可以不需要 SRT

• 去掉完全沒聲音的空白
• 快速裁掉長時間靜默
• 監控錄音品質
• Podcast 粗剪（人工後製）

如果你的目標是這種 → SRT 幾乎是必要的

• 依照「一句話」切段
• 產生短影音（Reels / Shorts）
• 自動章節
• 後續做摘要、關鍵句擷取、翻譯

你目前描述的用途是：

SRT 主要是透過 whisper 來產生，目的是利用 SRT 字幕自動切割影片

這個用途，本質上就是 語意導向切割，
所以 SRT 不是多餘的，而是核心訊號來源。

三、正確的工程思路：不是「二選一」，而是「主從關係」

在成熟的系統裡，設計通常是這樣：

Whisper / SRT：主判斷（語意）
靜音偵測：輔助過濾（聲學）

實務上最穩定的策略是：

1. 用 SRT 決定「候選剪輯區間」
2. 用靜音偵測做「品質檢查」
   • 字幕區間內如果 90% 都是靜音 → 丟棄
   • 字幕前後有長靜音 → 裁掉
3. 最後再補 padding，讓語音自然進出

也就是你目前優化方向中，最合理的一條路。

四、什麼情況下「可以完全不要 SRT」？

只有在以下情境，我會建議你拿掉 SRT：

1. 你已經不在乎「說了什麼」
2. 你只想保留「有聲音的地方」
3. 或你後面還會人工看一遍再修

例如：

• 監控錄影
• 課堂錄音粗剪
• 音檔清理工具

一旦你的目標是「自動產出可直接發布的內容」，
SRT（Whisper）就不是 optional，而是語意層的 ground truth。

ffmpeg 增加影片的音量

要讓音量達到最大但不破音，最保險的做法是先進行音量標準化。這通常需要跑兩次指令，或者用一個比較聰明的過濾器。

使用簡單的標準化

這個指令會自動搜尋音軌中的最高點，並將其提升到 0dB，也就是不失真的最大極限。這對於聲音太小的檔案非常有用。

ffmpeg -i input.mp4 -af "loudnorm=I=-16:TP=-1.5:LRA=11" -c:v copy output.mp4

兩步驟自動偵測

如果你想更精確地提升，可以先執行 volumedetect 找出最大增益。這個指令不會輸出新檔案，只是幫你計算數據。

ffmpeg -i input.mp4 -af volumedetect -f null /dev/null

在 Windows 中，我們把空輸出指向 NUL。

ffmpeg -i input.mp4 -af volumedetect -f null NUL

執行後在輸出的文字裡找 max_volume。如果顯示為 -6.0dB，代表你還有 6dB 的增加空間。接著再手動輸入增加的數值。

ffmpeg -i input.mp4 -af "volume=6dB" -c:v copy output.mp4

分析偵測結果

你的 max_volume 是 -1.2 dB。這代表這段影片中最大聲的地方，距離數位音訊的極限（0 dB）只剩下 1.2 dB 的空間。如果你的目標是單純增加音量且不想讓聲音破掉，你最多只能增加 1.2 dB。

執行調整指令

如果你確定要調到極限（也就是讓最大聲的地方剛好達到 0 dB），請在 Windows CMD 執行以下指令：

ffmpeg -i input.mp4 -af "volume=1.2dB" -c:v copy output.mp4

關於音量的建議

雖然最大值接近極限，但你的 mean_volume（平均音量）只有 -25.0 dB。這表示這段影片大部分時間聲音其實很小，只有少數幾個地方突然很大聲。

如果你覺得聽起來還是太小聲，單純調高 volume 可能會導致大聲的地方破音。這種情況建議改用前面提到的 loudnorm 指令，它會壓縮大聲的部分並提升小聲的部分，讓整體的聽感變大。

ffmpeg -i input.mp4 -af "loudnorm" -c:v copy output_norm.mp4

為什麼直接使用 loudnorm 過濾器處理過的檔案, 再使用偵測可增加的音量空間, max_volumn 反而下降?

這是一個很專業的觀察。直接使用 loudnorm 後 max_volume 反而下降，主要是因為這個過濾器的工作邏輯與單純調整增益（Gain）完全不同。

動態範圍壓縮的影響

loudnorm 是一種智慧型的音量標準化工具。它不只是把聲音推大，還會同時檢查聲音的動態範圍。為了讓整體聽感達到目標的響度（預設通常是 -16 LUFS），它會壓縮聲音的高峰。當它偵測到原始音軌中某些瞬間的峰值太高時，為了符合整體的響度標準，它會主動把這些高峰壓低，導致你看到的 max_volume 數值從 -1.2 dB 往下降。

防止數位失真的保護機制

loudnorm 內建了一個參數叫作 TP（True Peak），預設值通常是 -2.0 dB。這是一個安全閥，目的是確保處理後的聲音在任何播放設備上都不會產生數位破音。因為你原本的 max_volume 是 -1.2 dB，已經比這個安全標準還要大聲，所以 loudnorm 會強制把它壓回到 -2.0 dB 左右或更低，這就是為什麼偵測結果數值會變小的原因。

響度與峰值的差異

在音訊處理中，大聲不代表峰值高。max_volume 只代表影片中最響的那一個瞬間，而 loudnorm 關注的是整段影片聽起來的平均感覺。雖然峰值下降了，但因為它把原本微弱的聲音補償上來了，實際聽起來的感覺反而會比原本更清晰、更大聲。

你的測試結果驗證

這證明了 loudnorm 正在正確執行它的任務：它放棄了極少數的最高點空間，換取了整段音軌更一致、更飽滿的聽感。如果你希望處理後的 max_volume 更接近 0 dB，可以在指令中手動加上 TP 參數：

ffmpeg -i input.mp4 -af "loudnorm=TP=-0.1" -c:v copy output.mp4

這樣雖然峰值會上升，但通常不建議這麼做，因為留一點預留空間（Headroom）對音質比較好。

產生 Echo 回音音效

ffmpeg 使用 aecho 濾鏡來製作回音。你需要設定輸入增益、輸出增益、延遲時間以及衰減比例。

ffmpeg -i input.mp4 -af "aecho=0.8:0.8:1000:0.5" -c:v copy output.mp4

這行指令的參數意義如下：

• 0.8：原始聲音的音量。
• 0.8：回音的音量。
• 1000：延遲時間（毫秒），1000 代表 1 秒。
• 0.5：每次回音衰減的比例。

調整 EQ 均衡器

如果你想調整高低音，最直覺的是使用 equalizer 濾鏡。你可以針對特定的頻率進行增益或衰減。

例如，如果你想提升 1000Hz 附近的聲音（讓人聲更清晰），增加 6 分貝：

ffmpeg -i input.mp4 -af "equalizer=f=1000:width_type=h:w=200:g=6" -c:v copy output.mp4

• f=1000：中心頻率。
• width_type=h：頻寬單位。
• w=200：影響的頻率範圍寬度。
• g=6：增益分貝數。

快速調整高低音 (Bass/Treble)

如果你不想設定複雜的 EQ，可以直接用 bass 或 treble 濾鏡。這對高中生理解音訊調整最簡單。

提升重低音：

 ffmpeg -i input.mp4 -af "bass=g=10" -c:v copy output.mp4

提升高音：

ffmpeg -i input.mp4 -af "treble=g=8" -c:v copy output.mp4

多重濾鏡組合

你可以把音量調整、EQ 和回音全部串在一起使用，中間用逗號隔開即可。

ffmpeg -i input.mp4 -af "volume=1.2,bass=g=5,aecho=0.8:0.5:500:0.3" -c:v copy output.mp4

完整的人聲優化指令

這串指令包含了高通濾波、人聲強化和動態門檻去噪。

ffmpeg -i input.mp4 -af "highpass=f=80, lowpass=f=8000, afftdn=nr=10, equalizer=f=3000:width_type=h:w=200:g=3, loudnorm" -c:v copy output.mp4

濾鏡參數詳細解說

1. 高通與低通濾波 (highpass/lowpass)

highpass=f=80 會切斷 80Hz 以下的聲音。人聲通常不會低於這個頻率，但冷氣運轉或電流聲的低頻雜訊會被擋掉。lowpass=f=8000 則是過濾掉極高頻的刺耳雜音。

2. 智慧去噪 (afftdn)

afftdn 是 ffmpeg 內建強大的降噪工具。nr=10 代表降噪強度。如果你的背景嘶嘶聲很明顯，可以適度調高這個數值（建議在 10 到 20 之間），但調太高會讓人聲聽起來像在水底下說話。

3. 人聲頻段強化 (equalizer)

equalizer=f=3000:g=3 針對 3000Hz 左右進行微幅增益。這個頻段通常是人聲清晰度的關鍵，稍微拉高能讓講話聲更突出、更有磁性。

4. 終端響度標準化 (loudnorm)

最後放上 loudnorm 是為了確保優化後的聲音音量穩定，不會因為去噪過程讓音量忽大忽小。

進階去噪：使用動態閘門 (agate)

如果你的錄音環境有明顯的間歇性背景噪音（例如翻書聲或細微鍵盤聲），可以加入 agate 濾鏡。它會在沒人講話時自動把音量關到極小。

ffmpeg -i input.mp4 -af "agate=threshold=-30dB:ratio=2, highpass=f=80, afftdn, loudnorm" -c:v copy output.mp4

加入一點點空間感（Room Ambience）可以讓人聲聽起來更自然，不會像是在完全真空的密室裡講話。我們可以利用 aecho 來模擬微弱的牆面反射，讓 Podcast 更有專業錄音室的質感。

錄音室空間感指令

這組設定會加入極短的回音，聽覺上不會感覺到有明顯的「回聲」，而是覺得聲音變厚實了。

ffmpeg -i input.mp4 -af "highpass=f=80, afftdn=nr=12, aecho=0.8:0.3:40:0.2, loudnorm" -c:v copy output.mp4

參數調整重點

1. 空間感設定 (aecho)

aecho=0.8:0.3:40:0.2 這裡的核心在於 40 毫秒。這是一個非常短的時間，人耳聽不出延遲，只會覺得聲音多了一層包覆感。如果數字調到 500 以上，就會變成像在山洞說話的效果。

2. 去噪強度 (afftdn)

我把 nr 微調到了 12。這在去除 Podcast 背景底噪（如電腦風扇聲）非常有效。如果雜音還是很大，你可以嘗試把這個數值加到 15。

3. 低頻切除 (highpass)

這一步絕對不能省。Podcast 聽眾很多是用耳機收聽，切掉 80Hz 以下的雜訊，能大幅減少聽覺疲勞，讓人聲聽起來很乾淨。

檢查處理後的波形

處理完後，建議你再次使用 volumedetect 檢查。

ffmpeg -i output.mp4 -af volumedetect -f null NUL

你會發現 mean_volume（平均音量）應該會提升到 -16dB 附近，這正是目前國際 Podcast 平台的標準響度，聽眾在切換不同節目時，不需要一直手動調整手機音量。

highpass=f=200 與 highpass=f=80 的差異

濾除雜訊的強度

highpass=f=200 會切掉更多聲音。它能有效去掉冷氣運轉、交通工具轟鳴或遠處的低頻噪音。但缺點是它可能會切到男聲的基頻，讓聲音聽起來像透過舊式電話講話，變得很薄。對於 Whisper 來說，這通常不是問題，因為它辨識的是特徵而不是音質。

保留人聲的自然感

highpass=f=80 則溫和得多。它只會切掉人耳幾乎聽不到、但會讓麥克風產生震動的極低頻雜訊。這個設定能保留說話者聲音的厚度與磁性。如果你錄音的環境本來就很安靜，只是想做基本的清理，選 80 比較能維持原音。

針對 Whisper 的實務建議

如果你的錄音環境有明顯的環境低音，或是說話者離麥克風很近產生的噴麥聲（氣流撞擊聲），直接設定 200 會比較保險。Whisper 不需要好聽的低音，它需要的是乾淨的語音邊界。切掉 200Hz 以下的內容，可以讓模型更專注在 1kHz 到 4kHz 這些充滿語意資訊的頻段。

兩者的適用場景

如果你不確定該選哪一個，可以先聽聽看原始檔。如果背景有很重的嗡嗡聲，選 200。如果錄音很乾淨只是想稍微過濾，選 80 或 120 是比較折衷的做法。通常在嘈雜的咖啡廳或戶外錄音，我會建議直接從 200 起跳。

lowpass=f=3000 與 lowpass=f=8000 的差異

lowpass=f=3000 會把 3000Hz 以上的聲音全部切掉。這會讓聲音聽起來悶悶的，像是在隔壁房間說話。絕大多數的漢語或英語元音資訊都在這個範圍內。但要注意的是，像「s」、「f」、「sh」這類高頻的摩擦音，頻率通常在 4000Hz 以上。切得太乾（3000Hz）可能會讓這些齒音變得模糊。

高頻雜訊的過濾

lowpass=f=8000 則寬鬆許多。它能保留大部分的人聲細節，包含那些細微的發音特徵。它主要的功能是過濾掉電子設備的高頻嘶嘶聲、蟬鳴聲或極端尖銳的雜音。對於 Whisper 來說，8000Hz 通常是一個比較安全的平衡點，既能去噪又不會傷到語音特徵。

對 Whisper 的影響

Whisper 在訓練時看過各種品質的音檔。雖然 16kHz 的採樣率最高只能容納 8000Hz 的聲音，但如果你預處理時直接切到 3000Hz，可能會損失掉一些辨識子音的重要資訊。除非背景有非常刺耳的高頻電流聲，否則不建議切到 3000Hz 這麼低。

建議的設定值

如果你發現錄音中有很多噴麥或環境雜音，選 8000Hz 已經足夠應付多數情況。如果環境真的很糟糕，可以嘗試設定在 4000Hz 或 5000Hz 之間，這能保證語音的關鍵摩擦音不會被濾除。通常 3000Hz 是在極端惡劣、滿是高頻干擾時才考慮的最後手段。

套用 loudnorm, 開場的第一句話變的很小聲.

這通常是因為 loudnorm 預設是「單次掃描」（One-pass）模式。在這種模式下，ffmpeg 還沒分析完整段音訊，只能邊走邊猜。當開場的第一句話突然出現時，濾鏡為了保險起見會壓低音量，導致聽起來悶悶的。

解決開場音量過小的問題

要解決這個問題，最專業的做法是提供「預測數據」。你可以手動調整以下細部參數，或是改用兩次掃描模式。

1. 調整目標響度與峰值

你可以透過調整 I（目標響度）和 TP（真峰值）來讓整體聲音更響亮。

ffmpeg -i input.mp4 -af "loudnorm=I=-14:TP=-1.0:LRA=11" -c:v copy output.mp4

• I=-14：目標響度。數值越小（如 -12）聲音越大。Podcast 建議在 -16 到 -14 之間。
• TP=-1.0：允許的最高峰值。從預設的 -2.0 改成 -1.0 可以釋放更多音量空間。

2. 關閉線性限制 (measured)

如果你發現第一句話被壓得太厲害，可以嘗試強制設定 measured 參數。但更簡單的方法是調整 LRA（響度範圍）。

LRA=15：增加動態範圍。這會讓大聲與小聲的落差變大，有時候能減緩開場被強行壓低的感覺。

徹底解決方法：兩次掃描 (Two-pass)

這是大部份專業人士的做法。第一次先讓 ffmpeg 記住整段影片的音量特徵，第二次再根據這些數據進行精確調整。這樣濾鏡就不會在開場時「反應過度」。

在 Windows 上手動做兩次掃描比較麻煩，但有一個作弊的方法，就是調大內建的緩衝區。

增加預測緩衝

雖然 ffmpeg 的 loudnorm 主要靠演算法，但你可以嘗試在人聲處理鏈中，先放一個 compand（壓縮器）來預處理，或是直接改用 speechnorm。

如果你堅持用 loudnorm 且不想跑兩次指令，可以試試看這個組合，這對開場壓抑會有改善：

ffmpeg -i input.mp4 -af "loudnorm=I=-16:TP=-1.5:LRA=11:measured_I=-25.0:measured_TP=-1.2:measured_LRA=7.0:measured_thresh=-35.0" -c:v copy output.mp4

註：上面的 measured 數值是我根據你之前提供的偵測數據填入的。手動餵入這些偵測到的數據，能讓 loudnorm 在開場時就知道該怎麼處理。

另一個選擇：speechnorm

如果 loudnorm 讓 Podcast 開場聽起來還是很不自然，我強烈建議換成 speechnorm。它是專門為語音設計的，能非常平滑地調整每一句話的音量。

ffmpeg -i input.mp4 -af "speechnorm=e=4:p=0.9" -c:v copy output.mp4

你想試試看用 speechnorm 處理的效果嗎？它通常比 loudnorm 更適合解決「第一句話變小聲」的問題。

Whisper 進行語音轉文字（Audio to Text），「將檔案切成小片段」是否比較有效率

關於使用 OpenAI Whisper 進行語音轉文字（Audio to Text），「將檔案切成小片段」是否比較有效率，答案是：是的，通常比較有效率，但前提是「切分的方式要正確」。

如果只是單純為了速度而粗暴地切割檔案（例如固定每 60 秒切一刀），可能會導致辨識準確度下降。

以下為您詳細分析為什麼要切分、以及如何切分才是最好的策略：

1. 為什麼切成小檔案比較有效率？（優點）

• 平行處理（Parallel Processing / Batching）：
  這是最大的優勢。如果您將一個 1 小時的檔案切成 60 個 1 分鐘的檔案，您可以利用 GPU 的「批次處理（Batching）」功能，同時辨識多個片段。這比依序讀取一個長檔案要快得多。
• 記憶體管理（VRAM Usage）：
  雖然 Whisper 的記憶體使用量主要取決於模型大小（如 large-v3），但處理極長的音訊檔案有時會導致記憶體溢出（OOM）或處理緩衝區過大的問題。切分檔案可以讓記憶體負載更穩定。
• 避免累積錯誤（Hallucination Loop）：
  Whisper 在遇到長時間的靜音或背景噪音時，有時會產生「幻覺」（Hallucinations），例如不斷重複同一句話。切分檔案可以強制模型在每個新片段「重置」狀態，減少這種錯誤無限延續的風險。
• 容錯率：
  如果處理長檔案到 99% 時程式崩潰，您可能要從頭再來；如果是小檔案，您只需要重新跑失敗的那一小段。

2. 切分檔案的潛在風險（缺點）

• 上下文遺失（Context Loss）：
  Whisper 是利用上下文來判斷同音異字的。如果您剛好切在一個句子的中間，模型會失去前後文，導致誤判。

例子： 如果您在「人工智…」切斷，下一段是「…能」，模型可能分別辨識成錯誤的字，而不是完整的「人工智慧」。

• 邊界效應：
  切分點附近的音訊可能會因為波形被截斷而產生雜音，影響辨識。

3. 如何正確地切分？（最佳實務）

為了兼顧效率與準確率，絕對不要使用「固定時間切割」（例如每 30 秒切一次），建議採用以下策略：

A. 使用 VAD（語音活動檢測）切割

這是最標準的做法。利用 VAD (Voice Activity Detection) 演算法，找出音訊中的「靜音片段」，在說話者停頓換氣的地方進行切割。

• 優點： 確保句子是完整的，不會切斷單字。
• 工具： pyannote-audio 或 Silero VAD。

B. 使用優化過的函式庫（推薦 faster-whisper）

原版的 OpenAI Whisper 程式碼在處理長檔案時速度較慢。目前社群最推薦使用的是 faster-whisper。

• 原理： 它底層使用了 CTranslate2 引擎，比原版快 4-5 倍，並且內建了很好的 VAD 處理邏輯。它會自動在記憶體中幫您做好「切分 -> 批次辨識 -> 合併」的動作，您不需要手動去切實體檔案。

C. 若必須手動切檔 (使用 FFmpeg)

如果您因為某些原因必須手動切檔，請利用 ffmpeg 的 silencedetect 功能來尋找靜音點切割，而不是單純用 -segment_time。

4. 總結比較表

處理方式	速度效率	準確度	記憶體消耗	建議程度
單一長檔案 (原版 Whisper)	低 (依序處理)	高 (上下文完整)	高 (可能不穩)
固定時間切割 (如每30秒)	高 (可平行)	低 (容易切斷句子)	低	(不建議)
VAD 靜音切割 (手動/程式)	極高 (可平行)	高 (保留句子完整)	低
使用 faster-whisper	極高	高	最佳化

Whisper 模型陷入了「幻覺」或「長片段過度延伸」

例如: 一句話占用了 2分鐘.

問題原因與調整建議

這種情況通常不是 VAD 沒運作，而是模型陷入了「幻覺」或「長片段過度延伸」。當語音結尾出現較長的空白，或者背景有極微弱的環境雜音（例如底噪、電扇聲），Whisper 有時會以為這句話還沒結束，硬生生把結束時間往後拉，直到遇到下一個明顯的聲音。

你可以嘗試調整 transcribe 函數中的參數來修正這個現象。

建議修改的參數

在你的程式碼中，找到 model.transcribe 的位置，建議加入以下參數進行微調：

Python

segments, info = model.transcribe(
    input_file, 
    language=language, 
    vad_filter=True,
    # 調整 VAD 參數
    vad_parameters=dict(min_silence_duration_ms=1000), 
    # 控制無聲片段的判斷
    no_speech_threshold=0.6,
    # 限制沒有聲音時的處理方式
    compression_ratio_threshold=2.4
)

修改重點說明

• min_silence_duration_ms: 這是 VAD 判斷「靜音」的門檻。預設通常是 2000ms（2秒），如果你覺得兩分鐘太誇張，可以縮短這個數值（例如 1000 或 500），讓它更敏感地切斷句子。
• no_speech_threshold: 這是模型對「無聲」的信心門檻。提高這個數值（例如 0.6 或 0.7），可以讓模型在不確定有沒有人聲時，更果斷地放棄辨識，避免把底噪硬抓來轉文字。
• compression_ratio_threshold: 當模型開始亂寫、重複字詞或陷入長延時幻覺時，壓縮比通常會飆高。設定這個門檻可以讓模型在發現內容太混亂時，主動切斷該片段。

進階解決方案：強行切斷

如果調整 VAD 參數後效果還是有限，通常是因為錄音環境的底噪被模型誤認為是人聲。你可以試著加入 condition_on_previous_text=False。

這個參數會讓模型在處理下一段時，不參考前一段的內容。雖然可能會降低語意連貫性，但能有效防止「上一句的幻覺」一直帶到下一句，導致時間軸無限延伸。

整合參數後的程式碼

我把建議的參數直接加入 model.transcribe 裡。這樣可以讓 VAD 更敏銳，並減少模型在空白處「硬湊」時間的問題。

Python

import os
from contextlib import ExitStack

def run_faster_whisper_task(input_file: str, language: str, model_size: str, device: str, output_formats: List[str]):
    try:
        print(f"--- 開始處理: {input_file} (Device: {device}, Model: {model_size}) ---")
        
        compute_type = "float16" if device == "cuda" else "int8"
        model = WhisperModel(model_size, device=device, compute_type=compute_type)

        # 加入優化參數解決長延遲問題
        segments, info = model.transcribe(
            input_file, 
            language=language, 
            vad_filter=True,
            # 只要靜音超過 1 秒就切斷，不讓它連在一起
            vad_parameters=dict(min_silence_duration_ms=1000),
            # 提高對無聲的判定標準，避免抓到底噪
            no_speech_threshold=0.6,
            # 防止上一句的內容影響下一句，減少幻覺
            condition_on_previous_text=False
        )

        base_name = os.path.splitext(input_file)[0]
        print(f"偵測到語言: {info.language} (信心度: {info.language_probability})")
        
        with ExitStack() as stack:
            f_srt = None
            f_txt = None

            if "srt" in output_formats or "all" in output_formats:
                srt_path = f"{base_name}.srt"
                f_srt = stack.enter_context(open(srt_path, "w", encoding="utf-8"))

            if "txt" in output_formats or "all" in output_formats:
                txt_path = f"{base_name}.txt"
                f_txt = stack.enter_context(open(txt_path, "w", encoding="utf-8"))
            
            for i, segment in enumerate(segments, start=1):
                start_time = format_timestamp(segment.start)
                end_time = format_timestamp(segment.end)
                text = segment.text.strip()
                
                if f_srt:
                    f_srt.write(f"{i}\n")
                    f_srt.write(f"{start_time} --> {end_time}\n")
                    f_srt.write(f"{text}\n\n")
                    f_srt.flush() 

                if f_txt:
                    f_txt.write(f"{text}\n")
                    f_txt.flush()
                
                print(f"[{start_time} -> {end_time}] {text}")

        print(f"--- 處理完成 ---")

    except Exception as e:
        print(f"Faster-Whisper 執行錯誤: {e}")

調整說明

這段程式碼主要做了兩件事。第一是把 min_silence_duration_ms 縮短，讓 VAD 看到超過 1 秒的空白就強制收尾，不讓它繼續延伸。

第二是關掉了 condition_on_previous_text。這很重要，因為有時候模型會因為上一句還沒講完的錯覺，把後面的空白時間全部吃掉。關掉它後，每一段辨識都會比較獨立，時間軸也會精準很多。

最後也保留了你要的「不產生多餘檔案」的邏輯。如果跑完後發現時間軸還是偏長，可以再把 no_speech_threshold 往上調。

解決多句話合併的方法

解決多句話合併的方法

多句話被擠在同一個時間軸，通常是因為 Whisper 的 max_initial_timestamp 或內部的 word_timestamps 機制覺得這些句子之間停頓不夠明顯。要解決這個問題，除了調整 VAD 參數外，最有效的方法是加入「時間戳限制」與「強制切分」參數。

建議調整的參數

請在 model.transcribe 中加入 max_new_tokens 與 chunk_length 相關的限制：

Python

segments, info = model.transcribe(
    input_file, 
    language=language, 
    vad_filter=True,
    vad_parameters=dict(min_silence_duration_ms=500), # 縮短靜音判定，強制切分
    # 限制一個片段的最長秒數，避免過長合併
    clip_timestamps=[0], 
    # 加入以下關鍵參數
    max_initial_timestamp=1.0, 
    word_timestamps=False, # 如果不需要逐字時間戳，關閉它有助於穩定句子邊界
    # 這是核心：限制模型一次處理的長度
    initial_prompt="以下是逐句對話。", # 給模型提示，讓它傾向於斷句
)

修改重點說明

• 縮短 min_silence_duration_ms: 將 1000ms 改為 500ms（0.5秒）。只要講話稍微停頓，VAD 就會把這段切開，不會讓它變成一大串。
• max_initial_timestamp: 限制模型在搜尋聲音起點時的範圍，這能強迫模型更頻繁地重新對齊時間軸。
• initial_prompt: 這是一個小技巧。在提示詞裡加入標點符號或說明「這是逐句轉錄」，模型在輸出時會更傾向於加上標點並斷句，而不是吐出一長串沒有停頓的文字。
• 語音長度限制: 如果你的音檔底噪真的很大，導致 VAD 失靈，可以在程式碼層面檢查 segment.end - segment.start。如果差值超過 15 秒，就代表這一句太長了，這通常是模型卡住的徵兆。

在 faster-whisper 中，雖然參數名稱和原始的 OpenAI Whisper 略有不同，但我們可以透過 vad_parameters 中的 max_speech_duration_s 來限制每個片段的最長秒數。

另外，我們可以用 initial_prompt 強制模型在語氣停頓處斷句。

加入長度限制後的程式碼

Python

segments, info = model.transcribe(
    input_file, 
    language=language, 
    vad_filter=True,
    # vad_parameters 是控制切分長度的關鍵
    vad_parameters=dict(
        min_silence_duration_ms=500,  # 只要停頓 0.5 秒就切斷
        max_speech_duration_s=15      # 強制每一段話最長不能超過 15 秒
    ),
    # 限制模型一次生成的字數，避免一段話塞進太多內容
    # beam_size 設小一點有助於減少模型過度延伸的幻覺
    beam_size=5,
    # 給模型暗示，讓它知道要分句
    initial_prompt="，。！？", 
    # 關閉前文關聯，防止模型為了連貫性把句子硬湊在一起
    condition_on_previous_text=False
)

參數修改說明

• max_speech_duration_s: 這是最直接的解藥。我把它設為 15 秒，這代表 VAD 只要偵測到語音長度快到 15 秒，就會強行切斷並產生一個時間戳。這能解決你看到那種一整分鐘都沒斷句的問題。
• min_silence_duration_ms: 調降到 500ms（0.5秒）。這會讓程式對說話者的換氣、停頓更敏感，進而增加斷句頻率。
• initial_prompt: 我直接給它標點符號。這會引導模型在生成文字時，主動在該斷句的地方放上標點，這在處理「然後」、「接著」這種口頭禪時效果很好。
• beam_size: 雖然這主要影響準確度，但設在 5 左右通常是速度與穩定度的平衡點，能減少模型胡言亂語的機率。

你可以先試試看這組設定，15 秒的強制限制應該能馬上解決多句合併的問題。

為什麼已經知道是不同句話, 卻還是要合併句子

這是一個常見的技術陷阱。之所以會出現「明明語氣斷了，時間軸卻連在一起」，主要有三個原因：

為什麼會被合併

1. VAD 沒抓到夠長的靜音：Whisper 預設要看到一段明顯的「無聲區」才會切段。如果說話者語速快，或環境底噪（如風扇、電腦運流聲）太重，VAD 會以為中間那幾毫秒的停頓只是換氣，不是句子結束。
2. 模型試圖補完語意：Whisper 的特色是它會「預測」下一句。當它聽到「然後」、「接著」這種連接詞，它會覺得這句話還沒講完，為了語句通順，它會把後面的內容強行拉進同一個時間戳裡。
3. 預設的最短片段限制：模型為了避免產生太多只有 1 秒的碎片段，有時會自動把相近的聲音合併，結果反而造成了你看到的 15 秒長句。

解決方案：強制切分與語境分離

要修正這個問題，必須在 model.transcribe 裡加上更嚴格的參數。請將這段整合進你的程式中：

Python

segments, info = model.transcribe(
    input_file, 
    language=language, 
    vad_filter=True,
    vad_parameters=dict(
        min_silence_duration_ms=400,  # 更敏感，停頓 0.4 秒就切斷
        max_speech_duration_s=10,     # 強制每段最長 10 秒，解決長句問題
        speech_pad_ms=200             # 減少片段前后的緩衝音
    ),
    # 這是關鍵：關閉前文關聯
    condition_on_previous_text=False, 
    # 加入提示詞，強迫模型在看到連接詞時斷開
    initial_prompt="。，接著。然後。", 
    # 提高對無聲的判斷，不要讓底噪把兩句話連起來
    no_speech_threshold=0.6
)

修改後的變化

這組參數會讓 VAD 變得非常「沒耐心」。只要你稍微停頓 0.4 秒，它就會強行結束這一局。

加上 condition_on_previous_text=False 後，模型就不會因為看到「然後」就想去接前面的話。它會把每一段都當作全新的開始，這樣時間軸就會被切得很碎、很精準。

如果修改後發現句子斷得太細，可以再把 min_silence_duration_ms 稍微往上調。

需要我幫你把這組「嚴格斷句版」參數放進完整的函數程式碼中嗎？

還是 chatGPT 解決問題能力較強,

你這份設定其實已經接近 faster-whisper 能做到的極限切分了，多句字幕被合併，原因主要不是「bug」，而是 Whisper 本身的語言模型行為 + VAD 與 segment 定義方式。下面我直接用「為什麼會合併 → 怎麼徹底解」的角度來說，並給你可直接套用的修正方案。

先說結論：
只靠 transcribe 參數，無法 100% 防止多句合併在同一個 segment。
真正穩定的解法是 「模型切段 + 後處理再切一次字幕」。

為什麼你現在的設定還是會合併？

即使你已經做了這些正確的事：

• condition_on_previous_text=False
• vad_filter=True
• 縮短 min_silence_duration_ms
• 限制 max_speech_duration_s
• 設小 beam_size
• 提高 no_speech_threshold

但 Whisper 的 segment 不是「一句話」概念，而是「語音連續區間」：

• 只要中間沒有被 VAD 判定為「明確靜音」
• 或模型認為語意連續（尤其是中文）
• 就會把「多句話」吐在 同一個 segment.text

所以你現在看到的是「一個 segment 裡面有好幾句話」

正確做法：保留 Whisper segment，但自己再切字幕

核心策略

1. 讓 Whisper 只負責「時間區段」
2. 字幕斷句交給你自己（用標點 / 長度 / 停頓）

這是專業字幕系統（YouTube、Netflix pipeline）實際用的做法。

解法一（強烈推薦）：依標點再切 SRT（最穩）

新增一個「字幕斷句函式」

import re

def split_text_to_sentences(text):
    # 中文 + 英文常見斷句符號
    pattern = r'(?<=[。！？!?；;])'
    parts = re.split(pattern, text)
    return [p.strip() for p in parts if p.strip()]

修改你原本的 for loop（關鍵）

srt_index = 1

for segment in segments:
    start = segment.start
    end = segment.end
    text = segment.text.strip()

    sentences = split_text_to_sentences(text)

    if len(sentences) == 1:
        # 原本行為
        if f_srt:
            f_srt.write(f"{srt_index}\n")
            f_srt.write(f"{format_timestamp(start)} --> {format_timestamp(end)}\n")
            f_srt.write(f"{sentences[0]}\n\n")
        srt_index += 1
        continue

    # 多句 → 平均切時間
    duration = end - start
    per_sentence = duration / len(sentences)

    for idx, sentence in enumerate(sentences):
        s = start + idx * per_sentence
        e = s + per_sentence

        if f_srt:
            f_srt.write(f"{srt_index}\n")
            f_srt.write(f"{format_timestamp(s)} --> {format_timestamp(e)}\n")
            f_srt.write(f"{sentence}\n\n")

        srt_index += 1

效果

• 一個 Whisper segment → 多個 SRT 條目
• 時間仍然合理
• 字幕不再塞成一大句

解法二（進階）：限制每行字數（更像專業字幕）

你可以加上「字幕長度限制」，例如 20～25 字：

def split_by_length(text, max_len=22):
    result = []
    buf = ""
    for ch in text:
        buf += ch
        if len(buf) >= max_len:
            result.append(buf)
            buf = ""
    if buf:
        result.append(buf)
    return result

可以先「標點切 → 再長度切」。

你現在這些參數，哪些是「有效的」？

保留（做得對）：

• condition_on_previous_text=False
• vad_filter=True
• min_silence_duration_ms=300
• max_speech_duration_s
• beam_size=5

影響有限：

• initial_prompt
• clip_timestamps
• max_initial_timestamp

無法根治的：

• 單靠 VAD 期待「一句一段」

最佳實務建議（總結）

一句話版本：

Whisper 負責聽，字幕斷句要自己來。

你的 pipeline 建議是：

1. faster-whisper：
   • 穩定切出時間 segment
2. Python 後處理：
   • 依「標點 / 長度」再切字幕
3. 輸出 SRT

這樣你會得到：

• 不合併句子
• 時間合理
• 可控字幕品質
• 不依賴模型幻覺行為

下面是直接可用的「production 等級 SRT pipeline」，在你原本程式基礎上完成這些事：

1. Whisper 只負責時間段（segment）
2. 字幕後處理再斷句（標點 → 長度）
3. 每個 SRT 最多 2 行
4. 每行最多 N 個字（可調）
5. 時間合理平均分配
6. 不再出現多句塞同一條字幕

你可以整段直接取代原本的 function。

核心字幕切分工具（production 用）

import os
import re
from contextlib import ExitStack
from typing import List
from faster_whisper import WhisperModel

斷句：先標點，再長度

def split_sentences(text: str):
    pattern = r'(?<=[。！？!?；;])'
    parts = re.split(pattern, text)
    return [p.strip() for p in parts if p.strip()]

控制每行長度

def split_by_length(text: str, max_len: int):
    lines = []
    buf = ""
    for ch in text:
        buf += ch
        if len(buf) >= max_len:
            lines.append(buf)
            buf = ""
    if buf:
        lines.append(buf)
    return lines

合成「最多 2 行」字幕 block

def build_subtitle_blocks(text: str, max_line_len=22, max_lines=2):
    sentences = split_sentences(text)
    blocks = []

    for sent in sentences:
        lines = split_by_length(sent, max_line_len)

        for i in range(0, len(lines), max_lines):
            block = lines[i:i + max_lines]
            blocks.append("\n".join(block))

    return blocks

最終版：production SRT pipeline

def run_faster_whisper_task(
    input_file: str,
    language: str,
    model_size: str,
    device: str,
    output_formats: List[str],
    max_line_len: int = 22
):
    try:
        print(f"--- 開始處理: {input_file} ---")

        compute_type = "float16" if device == "cuda" else "int8"
        model = WhisperModel(model_size, device=device, compute_type=compute_type)

        segments, info = model.transcribe(
            input_file,
            language=language,
            vad_filter=True,
            condition_on_previous_text=False,
            vad_parameters=dict(
                min_silence_duration_ms=300,
                max_speech_duration_s=4,
                speech_pad_ms=200,
            ),
            beam_size=5,
            no_speech_threshold=0.6,
        )

        base_name = os.path.splitext(input_file)[0]

        with ExitStack() as stack:
            f_srt = None
            f_txt = None

            if "srt" in output_formats or "all" in output_formats:
                f_srt = stack.enter_context(
                    open(f"{base_name}.srt", "w", encoding="utf-8")
                )

            if "txt" in output_formats or "all" in output_formats:
                f_txt = stack.enter_context(
                    open(f"{base_name}.txt", "w", encoding="utf-8")
                )

            srt_index = 1

            for segment in segments:
                start = segment.start
                end = segment.end
                text = segment.text.strip()

                if not text:
                    continue

                blocks = build_subtitle_blocks(
                    text,
                    max_line_len=max_line_len,
                    max_lines=2
                )

                duration = end - start
                per_block = duration / len(blocks)

                for i, block in enumerate(blocks):
                    s = start + i * per_block
                    e = s + per_block

                    if f_srt:
                        f_srt.write(f"{srt_index}\n")
                        f_srt.write(
                            f"{format_timestamp(s)} --> {format_timestamp(e)}\n"
                        )
                        f_srt.write(f"{block}\n\n")

                    if f_txt:
                        f_txt.write(block.replace("\n", " ") + "\n")

                    print(f"[{format_timestamp(s)} -> {format_timestamp(e)}]")
                    print(block)

                    srt_index += 1

        print(f"--- 處理完成 ({info.language}, {info.language_probability:.2f}) ---")

    except Exception as e:
        print(f"Faster-Whisper 錯誤: {e}")

參數調整建議

你的設定中 max_speech_duration_s=1 數值過小。這會強制 VAD 每秒鐘就切斷一次。當語音被切得太碎，模型反而容易因為上下文不足而產生幻覺，或是把零碎的聲音補償成重複的文字。建議將這個值放寬到 15 到 20 左右。

目前的字幕出現長達 30 秒的區間，通常是因為 VAD 沒有成功切斷聲音。模型認為這段時間內一直有人在說話。這可能與 min_silence_duration_ms 太短有關。

您可以嘗試以下參數組合：

segments, info = model.transcribe(
    input_file, 
    language=language, 
    vad_filter=True,
    condition_on_previous_text=False,
    vad_parameters=dict(
        min_silence_duration_ms=500,
        max_speech_duration_s=20,
        speech_pad_ms=400
    ),
    beam_size=5,
    initial_prompt="繁體中文字幕。",
    no_speech_threshold=0.6,
    log_prob_threshold=-1.0,
    compression_ratio_threshold=2.4
)

關鍵調整說明

min_silence_duration_ms 增加到 500 毫秒。這樣模型比較能識別出正常的說話停頓。太短的設定會讓環境噪音干擾判定。

speech_pad_ms 增加到 400 毫秒。這會在切分片段的前後多留一點空間。這能幫助模型完整辨識字首與字尾，減少因為聲音被截斷導致的重複亂碼。

加入 initial_prompt。指定為繁體中文可以導正模型的語氣。這能有效減少出現奇怪贅字或簡繁混雜的機率。

調整 compression_ratio_threshold。如果模型輸出的內容重複率太高，這個參數會觸發重新辨識。這對解決你提到的重複文字問題很有幫助。

python opencc 的 s2t 與 s2tw 差異

OpenCC 是一個很方便的簡繁轉換工具。s2t 與 s2tw 看起來很像，但處理邏輯有明顯區別。這對寫程式或處理文字檔的人來說，選錯轉換模式會讓結果變得很奇怪。

核心轉換邏輯的差異

s2t 的全稱是 Simplified Chinese to Traditional Chinese。它只做字對字的轉換。也就是把簡體字直接換成對應的正體字。這種模式不考慮各地區的用詞習慣。它最適合用在想保留原始語句，只需要更換字體形狀的場景。

s2tw 則是 Simplified Chinese to Traditional Chinese (Taiwan Standard)。它除了換字，還會加入台灣的字形標準。它處理的是字形上的微調，確保轉換後的文字符合台灣教育部門定義的標準字體。

詞彙轉換的層次

雖然 s2tw 處理了台灣字形，但它不一定會處理詞彙轉換。在 OpenCC 的配置中，如果你需要把簡體的計算機換成台灣常用的電腦，通常要使用的是 s2twp。那個 p 代表的是 Phrases，也就是詞彙修正。

單純的 s2t 轉換後，你的文章看起來會像是一個用簡體邏輯寫成的繁體文章。讀起來會有一種違和感。如果你的目標讀者是台灣人，s2tw 或 s2twp 會是比較好的選擇。

實際應用建議

如果你是要開發給台灣用戶使用的 App 或網站，建議選擇 s2twp。這樣不只字形正確，連軟體、內存這種詞彙都能自動轉換成軟體、記憶體。這能大幅提升用戶的閱讀體驗。

缺點也很明顯，完全無法使用大陸的用詞，會被強制轉成台灣用詞，但台灣明明可以用腳本，s2twp 會硬把腳本改成指令碼…, 實在很無言.

實際測試, s2hk 似乎比較好用.

• 原始文字：
  通过内存清理软件，可以提高计算机的速度。
  台灣, 一台車, 芯片, 腳本, 脚本, 指令码, 指令碼, 软体, 軟體。土豆, 信息,
  水平高清发现太后的头发后面有干的长发
• s2t 模式：
  通過內存清理軟件，可以提高計算機的速度。
  臺灣, 一臺車, 芯片, 腳本, 腳本, 指令碼, 指令碼, 軟體, 軟體。土豆, 信息,
  水平高清發現太后的頭髮後面有乾的長髮
• s2tw 模式：
  通過內存清理軟件，可以提高計算機的速度。
  臺灣, 一臺車, 芯片, 腳本, 腳本, 指令碼, 指令碼, 軟體, 軟體。土豆, 信息,
  水平高清發現太后的頭髮後面有乾的長髮
• s2twp 模式：
  透過記憶體清理軟體，可以提高計算機的速度。臺灣, 一臺車, 晶片, 指令碼, 指令碼, 指令碼, 指令碼, 軟體, 軟體。土豆, 資訊, 水平高畫質發現太后的頭髮後面有乾的長髮
• s2hk 模式：
  通過內存清理軟件，可以提高計算機的速度。
  台灣, 一台車, 芯片, 腳本, 腳本, 指令碼, 指令碼, 軟體, 軟體。土豆, 信息,
  水平高清發現太后的頭髮後面有乾的長髮

輕鬆上手自動化工作流程的技術指南

n8n 是一套開源的自動化工具，可以幫你串接一堆工具或平台，打造工作流程，讓重複又無聊的事情自己跑完，不用每次都自己動手做。

在 Windows 上安裝其實只是為了體驗操作環境，在本地端安裝最大的缺點就是，電腦必需一直開著，解法就是購買別人提供的服務，或自架到雲端上。

要自架 n8n，最常見且推薦的方式是使用 Docker 部署，因為環境一致性好、方便維護，你也可以用 npx 快速體驗，或是在雲端平台如 Zeabur (例如使用它的模板) 部署來獲得無限額度的自動化。

常用自架 n8n 方法

1. Docker 部署 (推薦)
   • 先決條件: 需先安裝 Docker Desktop。
   • 步驟:
     1. 下載並安裝 Docker Desktop。
     2. 開啟終端機 (Terminal/PowerShell)。
     3. 複製官方提供的 Docker n8n 指令，並在執行前修改時區為 Asia/Taipei。
     4. 執行指令後，在瀏覽器訪問 http://127.0.0.1:5678 即可看到 n8n 啟動畫面。
2. npx 快速體驗 (適合測試)
   • 先決條件: 已安裝 Node.js。
   • 步驟:
     1. 在終端機輸入 npx n8n。
     2. npx會自動下載並執行 n8n，適合快速測試與學習，但資料保存不如 Docker 穩定。
3. 雲端平台 (Zeabur/Huggingface 等)
   • 特色: 快速部署，通常有免費額度，免去自行維護伺服器的麻煩。
   • 步驟 (以 Zeabur 為例):
     1. 在 Zeabur 註冊帳號。
     2. 建立新專案，選擇 n8n 模板 (有官方或社群維護的版本)。
     3. 設定網域，完成後即可使用，適合需要無限次數自動化但不想處理環境問題的用戶。 

額外進階方法

• 伺服器部署 (VPS/雲主機): 在自己的伺服器上部署，需要自行配置 Node.js、資料庫、反向代理 (Nginx) 等，自由度最高，適合生產環境。 

古代學 n8n 文章

【Day12】如何開始第一個 n8n 環境 : 自架與環境部屬
https://ithelp.ithome.com.tw/m/articles/10387677

AI的超自動化武裝【n8n】-安裝篇
https://www.cc.ntu.edu.tw/chinese/epaper/home/20250620_007304.html

過去要學n8n 就是在 Google 下關鍵字或到書店買買來學，現在是跟聊天機器人學。

現在應該都是直接在AI 下提示詞: 如何在 Windows 安裝 n8n

跟AI學的好處是：時間我選、節奏我掌控、學習的主題可任意轉換、再多問題它也不嫌煩！還有很多原作者沒遇到的問題，我可能會遇到。用 AI 來解決遇到的問題，雖然答然不是每次都正確，但比自己來摸索有效率很多。

文章下半部在分享 tunnel 解法.

webhook，簡單的來說就是一個網址，但由於目前一般民眾的電腦都是在路由器（網路分享器）的私人網路 (192.168.x.x)，在公共網際網路的人是無法直接把資料傳回你電腦架設的伺服器監聽的服務，所以需要透過防火牆，穿牆的方式百百種，今天要分享的是使用 tunnel, 但是我覺得實際上一般你在網路上申請的n8n服務，或是去租用虛擬主機來架設n8n 都不會有穿牆(tunnel) 的必要。

tunnel 的優點

• 安全性高：不需要在路由器上打開任何傳入端口，減少了被掃描和攻擊的風險。您的真實公網 IP 甚至不需要暴露。
• 設定簡單：完全避開了複雜的路由器設定、DDNS 設定以及電信商 CGNAT (虛擬 IP) 的問題。
• 適用性廣：只要您的電腦能上網，這個方案就能運作，不受網路環境限制。
• HTTPS 支持：隧道服務提供商通常會免費提供 HTTPS 證書，確保外部到隧道伺服器這段的傳輸安全。

文章裡關於怎麼穿牆，看不懂先了解個大概就可以了，等有實際的需求再進行深度的研究。

安裝Docker Desktop

傳送門: https://www.docker.com/products/docker-desktop/

點 “Download Docker Desktop”

Windows 版的 Docker系統要求：

• Windows 10 64 位元（版本 2004 或更高版本）或 Windows 11。
• 啟用 BIOS 中的虛擬化支援（VT-x/AMD-V）。
• 啟用 WSL 。

WSL (Windows Subsystem for Linux) 是一個在 Windows 作業系統提供的功能，允許使用者在 Windows 環境中直接執行 Linux 環境（包括大部分的命令列工具、公用程式和應用程式），而不需要傳統的虛擬機器。

如何啟用 WSL

您可以使用一個指令來快速安裝/啟用 WSL：

1. 開啟管理者權限的 PowerShell 或命令提示字元： 在 Windows 搜尋欄輸入 PowerShell，然後右鍵選擇「以系統管理員身分執行」。
2. 執行安裝指令： 輸入以下指令並按下 Enter：
   wsl --install
   • 此指令會啟用執行 WSL 所需的功能，並預設安裝 Linux Ubuntu 發行版。
   • 您可能會被提示重新啟動電腦。
3. 首次啟動與設定： 重新開機後，第一次啟動新安裝的 Linux 發行版時，系統會要求您設定使用者帳號和密碼。

小提醒： 如果您使用的是舊版 Windows 或不想使用安裝指令，也可以透過「開啟或關閉 Windows 功能」手動啟用「適用於 Linux 的 Windows 子系統」和「虛擬機器平台」選項。

Docker Desktop 啟動後，需要登入 Docker 帳號（可使用 Google 或 GitHub 快速註冊/登入）。

測試Docker

開啟 PowerShell 或命令提示字元，執行以下指令測試：

docker run --rm hello-world

如果成功，您將會看到 Hello from Docker! 的訊息。

Docker 上有哪些映像檔（image）

使用指令查詢

在你的電腦上用 docker search 指令來找。

docker search n8n

這個指令會列出所有名稱包含 n8n 的公開映像檔。不過，它不會直接告訴你有哪些版本（Tags）。

要知道一個映像檔具體有那些版本，雖然有相關指令可以使用，但比較佔空間，所以一般還是建議直接上 Docker Hub 看最快。

在 Docker Hub 的搜尋框查詢

• 1. 點輸入框，Ctrl + K
• 2. 輸入 n8n
• 3. 移到 Tag 下拉框, 就可以看到版本,
• 4. 點 Pull 就可以下載公開映像檔

下載的 Tag 會變成可以 Run 的映像檔:

按下 Run 後的畫面

在 Windows 版 Docker Desktop 的「Images」介面點擊 Run 按鈕來啟動 n8n (映像檔通常為 n8nio/n8n) 時，會跳出一個設定視窗。為了確保 n8n 能正常運作且資料不會遺失，你需要展開 Optional settings (可選設定) 並填寫以下關鍵欄位。

以下是各欄位的詳細意義與填寫建議：

1. Container Name (容器名稱)

• 意思： 給這個正在運作的 n8n 實例取個名字，方便你之後在 Docker 列表中找到它、停止它或查看它的 Log。
• 建議輸入：n8n-demo 或 my-n8n。
  • 如果不填，Docker 會隨機產生一個好笑的名字（例如 boring_wozniak），這不影響功能，但不好管理。

2. Ports (通訊埠/端口)

這是最重要的一步，決定了你能不能從瀏覽器打開 n8n。

• Local Host (本地主機端口)： 這是指你 Windows 電腦 上的端口。
• Container Port (容器內部端口)： 這是 n8n 程式在 Docker 容器裡面 預設監聽的端口（n8n 預設是 5678）。

操作結果： 設定好後，啟動容器，打開瀏覽器訪問 http://localhost:5678 就能看到 n8n 介面。

3. Volumes (掛載卷/資料保存)

非常重要： 如果你不設定這一步，當你關閉或重啟 Docker 容器時，你建立的所有 workflow (工作流程) 和帳號密碼都會 憑空消失。

我們需要將 Windows 上的某個資料夾「對應」到容器內的存檔路徑。

• Host Path (主機路徑)： 點擊 ... 按鈕，在你的 Windows 電腦上選擇一個資料夾（例如 C:\Users\你的名字\n8n-data）。這就是你實際存放資料的地方。
• Container Path (容器路徑)： 這是 n8n 在 Linux 容器內部存放資料的位置。

4. Environment Variables (環境變數)

對於「本機測試」來說，這部分可以留空。但如果你有特殊需求，可以在這裡設定。

常見的 n8n 變數範例：

• Variable (變數名): N8N_ basic_AUTH_ACTIVE
• Value (值):true
  • 用途：開啟帳號密碼登入驗證（若要在公開網路跑才需要，本機跑通常不需要）。
• Variable:WEBHOOK_URL
  • 用途：如果你需要接收外部的 Webhook（例如 LINE Bot 或 Slack），通常需要配合 Tunnel 設定這個網址。

總結操作步驟

在 Docker Desktop 按下 Run 之後：

1. Name: 輸入 n8n-local
2. Ports: Host 填 5678，Container 填 5678。
3. Volumes:
   • Host 選擇你電腦的一個空資料夾。
   • Container 填入 /home/node/.n8n。
4. 點擊 Run。

啟動後，等待幾秒鐘，打開瀏覽器輸入 http://localhost:5678 即可開始使用。

進階建議：為什麼大家推薦用 Docker Compose？

雖然用 Docker Desktop 的圖形介面 (GUI) 按一按很方便，但在管理 n8n 時，使用 docker-compose.yml 檔案是更標準的做法。因為：

1. 設定檔化： 你不用每次 Run 都要重新手動輸入上面那些路徑和端口。
2. 升級方便： n8n 更新很頻繁，用 Compose 只需要改一行版號就能升級，不用重新設定。

接下來你希望我直接給你一份適合 Windows 使用的 docker-compose.yml 範本，讓你複製貼上就能一鍵啟動嗎？

Docker Compose

從 Docker Desktop 的圖形介面 (GUI) 改用設定檔，會讓你之後管理 n8n 輕鬆很多。

使用 docker-compose 的好處是，你只需要保存一個文字檔，之後換電腦或重灌，只要把這個檔案和資料夾複製過去，一行指令就能還原整個工作環境。

請按照以下步驟操作：

步驟 1：建立資料夾與檔案

1. 在你的 Windows 電腦上建立一個新資料夾（例如命名為 n8n-docker）。
2. 進入該資料夾，建立一個純文字檔案，命名為 docker-compose.yml (注意副檔名要是 .yml)。
3. 用記事本或程式碼編輯器 (如 VS Code) 開啟它，不用進行修改，直接貼上以下內容，並存檔：

YAML

version: '3.8'

services:
  n8n:
    image: n8nio/n8n:latest
    container_name: n8n-local
    restart: always
    ports:
      - "5678:5678"
    environment:
      - N8N_HOST=localhost
      - NODE_ENV=production
      - WEBHOOK_URL=http://localhost:5678/
      - GENERIC_TIMEZONE=Asia/Taipei  # 設定時區為台北，方便查看 Log
      - TZ=Asia/Taipei
    volumes:
      # 這行代表：在當前資料夾自動建立 n8n_data 來存資料
      # 左邊是 Windows 路徑，右邊是容器內路徑
      - ./n8n_data:/home/node/.n8n

步驟 2：啟動 n8n

1. 開啟 Windows 的 PowerShell 或 CMD (命令提示字元)。
2. 使用 cd 指令進入你剛剛建立的資料夾。
   • 例如：cd C:\Users\User\Desktop\n8n-docker
3. 輸入以下指令並按下 Enter：

docker compose up -d

指令解釋：

• up: 啟動服務。
• -d: Detached mode (背景執行)，這樣你關掉 PowerShell 視窗，n8n 也不會停止。

下次重開機時, 你可能會遇到這個錯誤訊息:

docker compose up -d
unable to get image 'n8nio/n8n:latest': error during connect: Get "http://%2F%2F.%2Fpipe%2FdockerDesktopLinuxEngine/v1.51/images/n8nio/n8n:latest/json": open //./pipe/dockerDesktopLinuxEngine: The system cannot find the file specified.

這個錯誤訊息看起來很嚇人，但其實它的意思非常簡單，這通常是所有 Docker 新手都會遇到的狀況。

錯誤訊息 open //./pipe/dockerDesktopLinuxEngine: The system cannot find the file specified 的意思是：你的電腦找不到 Docker 的引擎。

簡單來說：你的 Docker Desktop 程式沒開，或是當機了。

啟動 Docker Desktop

1. 請看你 Windows 的系統列，有沒有看到那隻 鯨魚圖示？
   • 如果沒有：代表程式沒執行。請去「開始」選單搜尋 “Docker Desktop” 並點開它。
   • 如果有但游標移過去顯示 “Stopped”：請按右鍵選擇 “Restart”。
2. 打開後，請等待左下角的狀態列變成 綠色 (Engine running)。

第二步：修正版本號 (關鍵！)

我注意到你的指令裡出現了 'n8nio/n8n:2.0.2'。

注意：n8n 目前最新的版本還是 1.x 系列 (例如 1.75.0)，還沒有 2.0.2 這個版本。

如果你堅持用 2.0.2，等一下 Docker 連線成功後，它會報另一個錯 (manifest unknown)，因為找不到這個檔案。

請回到你的 docker-compose.yml 檔案，把 image 那一行改回 latest 或是穩定的 1.x 版本：

YAML

services:
  n8n:
    # 修改這一行，改回 latest
    image: n8nio/n8n:latest
    # ... 其他設定 ...

第三步：驗證並重啟

確認 Docker Desktop 已經變成綠燈後，請在 CMD 輸入以下指令測試連線：

docker version

如果跑出 Client 和 Server 的資料，代表連線通了。接著再執行一次啟動指令：

docker compose up -d

這樣應該就能正常下載並啟動了！試試看，有問題再貼上來。

這次設定的重點解析

這份設定檔幫你自動處理了以下幾件事：

1. 資料持久化 (volumes)：
   • 設定檔中寫了 - ./n8n_data:/home/node/.n8n。
   • 當你啟動後，你會發現 Windows 資料夾裡多了一個 n8n_data 資料夾。你所有的 Workflow 和帳號設定都在這裡，千萬不要刪除它。
2. 時區校正 (environment)：
   • 我加入了 GENERIC_TIMEZONE=Asia/Taipei，這樣你在 n8n 裡設定「每天早上 9 點寄信」時，它會正確使用台灣時間，而不是格林威治時間 (UTC)。
3. 自動重啟 (restart: always)：
   • 如果 Docker 當機或電腦重開機，Docker Desktop 啟動後會自動把這個 n8n 容器拉起來，不用你手動再開一次。

常見後續操作

• 如何更新 n8n 到最新版？只需要在同一個資料夾下，依序執行這兩行指令：
  docker compose pull # 下載最新版映像檔
docker compose up -d # 重新建立容器 (資料不會不見)
• 如何停止？
  docker compose stop

現在你已經可以在本地端 (Localhost) 順利執行 n8n 了。

但如果你未來想要串接 LINE Bot、Telegram 或 Slack 的 Webhook，你會遇到一個問題：外部的服務連不到你這台 Windows 電腦。

怎麼在 n8n 裡開啟「Tunnel (隧道) 模式」，讓你不用架設伺服器也能接收外部 Webhook 訊號嗎？

沒問題，這功能在開發和測試階段（例如串接 LINE Bot 或接收 Google Forms 資料）非常實用。

開啟 Tunnel (隧道) 模式 的原理是：n8n 官方會借你一個臨時的公開網址（類似 https://adjk-123.hooks.n8n.cloud），並將傳送到這個網址的流量「打洞」轉發到你家電腦的 Docker 容器裡。

請按照以下步驟修改你的 docker-compose.yml：

步驟 1：修改 docker-compose.yml

請用編輯器打開之前的檔案，並進行以下 兩個修改（我用註解標示了修改處）：

YAML

version: '3.8'

services:
  n8n:
    image: n8nio/n8n:latest
    container_name: n8n-local
    restart: always
    ports:
      - "5678:5678"
    environment:
      - N8N_HOST=localhost
      - NODE_ENV=production
      # - WEBHOOK_URL=http://localhost:5678/  <-- 1. 把這行刪掉或加 # 註解掉 (因為隧道會自動產生新網址)
      - GENERIC_TIMEZONE=Asia/Taipei
      - TZ=Asia/Taipei
    
    # 2. 新增下面這行 command 指令
    command: start --tunnel

    volumes:
      - ./n8n_data:/home/node/.n8n

步驟 2：套用設定

修改存檔後，在 PowerShell (在該資料夾下) 執行以下指令來重新建立容器：

docker compose up -d

(Docker 很聰明，它會偵測到設定檔變了，自動幫你重建容器，不會刪除你的資料)

步驟 3：找出你的「公開 Webhook 網址」

這是最關鍵的一步！因為是隨機分配的網址，你需要看 Docker 的 Log (日誌) 才知道網址是什麼。

1. 執行以下指令查看 Log：
   docker compose logs -f
   (-f 代表 follow，會持續顯示最新的訊息。按 Ctrl + C 可以退出)
2. 仔細看輸出的文字，你會看到類似下面這段話：
   Tunnel URL: https://heavy-pumas-play.hooks.n8n.cloud
3. 複製這個網址。這就是你目前 n8n 在網際網路上的「門牌號碼」。

執行 docker compose logs 畫面：

內容：

n8n-local  |  - N8N_RUNNERS_ENABLED -> Running n8n without task runners is deprecated. Task runners will be turned on by default in a future version. Please set `N8N_RUNNERS_ENABLED=true` to enable task runners now and avoid potential issues in the future. Learn more: https://docs.n8n.io/hosting/configuration/task-runners/

這是一個很好的觀察！這代表你有仔細在看 Log。

這個訊息不是錯誤 (Error)，而是一個警告 (Warning)。簡單來說，n8n 正在升級它的核心引擎，舊的執行方式即將被淘汰，官方建議你現在就開啟「Task Runners (任務執行器)」這個新功能，讓運作更穩定、效率更好。

我們順手把它修好吧！只需要在 docker-compose.yml 裡加一行設定即可。

修正步驟

1. 修改 docker-compose.yml

請打開你的檔案，在 environment: 的區塊中加入 N8N_RUNNERS_ENABLED=true。

修改後的檔案會長這樣（請注意 + 號那一行）：

YAML

version: '3.8'

services:
  n8n:
    image: n8nio/n8n:latest
    container_name: n8n-local
    restart: always
    ports:
      - "5678:5678"
    environment:
      - N8N_HOST=localhost
      - NODE_ENV=production
      # - WEBHOOK_URL=http://localhost:5678/
      - GENERIC_TIMEZONE=Asia/Taipei
      - TZ=Asia/Taipei
      - N8N_RUNNERS_ENABLED=true  # <--- 新增這一行
    
    command: start --tunnel

    volumes:
      - ./n8n_data:/home/node/.n8n

2. 套用設定

儲存檔案後，一樣在 PowerShell 執行：

docker compose up -d

執行畫面：

訊息：

docker compose up -d
time="2025-12-13T14:09:46+08:00" level=warning msg="C:\\Max\\docker\\n8n-docker\\docker-compose.yml: the attribute `version` is obsolete, it will be ignored, please remove it to avoid potential confusion"
[+] Running 1/1
 ✔ Container n8n-local  Started  

這是一個完美的結果！

那個 warning (警告) 完全不用擔心，它只是在告訴你 Docker 的規範變了，但不影響程式運作。

發生了什麼事？

1. 成功啟動： Container n8n-local Started 這行字代表 n8n 已經成功重新啟動，並且套用了你剛剛加的 N8N_RUNNERS_ENABLED=true 設定。
2. 關於那個警告：attribute 'version' is obsolete。
   • 這是因為新版的 Docker Compose (V2) 已經不需要在檔案第一行寫 version: '3.8' 了。它現在很聰明，會自動識別。

(選做) 如何消除這個警告？

如果你有強迫症，想要以後看不到這個黃色警告，只要再次打開 docker-compose.yml，把第一行 version: '3.8' 直接刪掉，存檔即可。

以後你的檔案開頭就會直接是 services:，像這樣：

YAML

# version: '3.8'  <-- 這一行可以刪掉
services:
  n8n:
    # ... (下面的內容都不用動)

狀態確認：一切就緒

執行 docker compose logs 畫面：

內容：

n8n-local  | Waiting for tunnel ...
n8n-local  | Tunnel URL: https://ayvz4dbqk52oyxdy4e4kp8d7.hooks.n8n.cloud/

不用擔心，你的 Log 顯示 Docker 和 Tunnel 其實都運作正常！

你會收到 404 Not Found，不是網路壞了，而是 n8n「現在」找不到這個路由。

這通常是新手最容易混淆的觀念：Test URL（測試網址） vs Production URL（正式網址）。

請依照以下 3 個步驟檢查，一定能解決：

1. 檢查路徑名稱 (Path) 是否一致？

你在 curl 指令中打了 …/webhook-test/api001。

請回到 n8n 的 Webhook 節點設定檢查：

• Path 欄位是填 api001 嗎？
• 如果你的 Path 還是預設的 test，那你應該要連線到 .../webhook-test/test。

2. 你按下「Listen」按鈕了嗎？ (最常見原因)

• Test URL (/webhook-test/…) 的特性：它只有在你按下 Webhook 節點下方的 “Listen for Test Event” 按鈕後，才會暫時開啟 120 秒。
  • 如果你沒按這個按鈕，直接跑 curl，n8n 會因為不知道要把資料送給誰，而直接回傳 404。

解決方法：

1. 在 n8n 介面，按下 Listen for Test Event。
2. 看到顯示 “Waiting for the webhook call…” 後。
3. 立刻 再執行一次你的 curl 指令。

3. HTTP Method 對嗎？

• curl 預設是送出 GET 請求。
• 檢查你的 Webhook 節點設定，HTTP Method 是選 GET 嗎？如果是選 POST，你的 curl 指令要加上 -X POST。

同場加映：消除 Log 中的警告 (優化版設定)

你的 Log 裡有一些 warning (例如 SQLite pool size, Environment access)，雖然不影響運作，但為了讓你的 n8n 跑得更穩、更快，建議更新你的 docker-compose.yml。

你可以用下面這份優化版設定檔取代舊的（針對你的 Log 做了修正）：

YAML

services:
  n8n:
    image: n8nio/n8n:latest
    container_name: n8n-local
    restart: always
    ports:
      - "5678:5678"
    environment:
      - N8N_HOST=localhost
      - NODE_ENV=production
      - GENERIC_TIMEZONE=Asia/Taipei
      - TZ=Asia/Taipei
      # 修正 Log 警告：開啟新版 Runner
      - N8N_RUNNERS_ENABLED=true
      # 修正 Log 警告：優化 SQLite 資料庫效能
      - DB_SQLITE_POOL_SIZE=5
      # 修正 Log 警告：加強安全性設定
      - N8N_BLOCK_ENV_ACCESS_IN_NODE=false
      - N8N_GIT_NODE_DISABLE_BARE_REPOS=true
      # 修正 Log 警告：自動修復權限問題
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
    
    command: start --tunnel

    volumes:
      - ./n8n_data:/home/node/.n8n

重要限制與注意事項

使用 n8n 內建的 --tunnel 雖然方便，但有幾個很大的缺點，你一定要知道：

1. 網址會變： 每次你重啟 Docker 或是網路斷線重連，這個 URL (https://...hooks.n8n.cloud) 就會改變。
   • 後果： 如果你把網址填在 LINE Developer Console 裡，下次重開電腦後，你就要去 LINE 後台重新修改網址，非常麻煩。
2. 速度較慢： 因為流量要繞去 n8n 的伺服器再轉回來，速度會比直接連線慢一點點。
3. 穩定性： 這是官方提供的測試功能，有時候可能會連不上。

總結

現在，你已經具備了以下環境：

1. Windows 本機執行 n8n (透過 Docker Compose)。
2. 資料會自動存檔 (透過 Volumes)。
3. 可以接收外部訊號 (透過 Tunnel)。

雖然網址會變有點麻煩，但對於剛開始學習是非常夠用的。

接下來，為了測試這個隧道是否真的通了，直接做一個簡單的「Webhook 測試」，例如：只要你在瀏覽器輸入某個網址，你的 n8n 就會收到通知，這可以讓你立刻體驗 n8n 的運作邏輯。

n8n是免費的嗎？

是的，這是免費的。

只要你是自己架設 (Self-hosted) 且用於內部或個人用途，這個 License Key 只是用來啟用「免費社群版」的功能。

前往 n8n 介面：http://localhost:5678

輸入完個人的基本資料，點 send me a free license key.

這不代表你需要付費。n8n 雖然是開源軟體，但為了統計使用者數量以及提供更新資訊，新版本在第一次安裝時，會要求你輸入 Email 來「啟用」你的 社群版 (Community Edition) 帳號。

只要你是自己架設 (Self-hosted) 且用於內部或個人用途，這個 License Key 只是用來啟用「免費社群版」的功能。

接下來請這樣做：

去收信：打開你的 Gmail (xxx@gmail.com)，應該會收到一封來自 n8n 的信，標題通常是 “Your n8n license key”。

複製 Key：信件內容會有一長串類似亂碼的字串，那就是你的 License Key，請把它複製下來。

回到 docker 產生的 n8n 本機網頁，例如: http://localhost:5678

在左側選單最下方你的帳號名稱，再點擊 Settings。

進入 Settings, 預設是在 Usage and plan 分頁, 點擊 “Enter activation key” 按鈕.

你會看到一個輸入框，把剛剛複製的 Key 貼上去。

點擊 Activate (啟用)，就完成 n8n 社群帳號的啟用。

我們馬上來進行你的第一個「Webhook 實測」！這會讓你非常有成就感，因為你親眼看到資料從瀏覽器「飛」進你的 n8n 裡。

步驟 1：建立 Webhook 節點

• 打開瀏覽器，前往 n8n 介面：http://localhost:5678
• 點擊右上角的 “Add workflow” (新增工作流程)。

• 點擊中間的大加號 (+)，在搜尋框輸入 Webhook，然後選擇 “Webhook” 節點。

步驟 2：設定 Webhook 參數

你會看到一個設定面板跳出來，請確認以下設定：

• HTTP Method: 選擇 GET (這樣我們直接用瀏覽器就能觸發)。
• Path: 輸入 test (這會是網址的結尾)。
• Authentication: 保持 None。

關鍵步驟： 請把目光移到面板下方，你會看到兩個網址：

• Test URL: 用於開發測試，資料會直接顯示在編輯器裡。
• Production URL: 用於正式上線。

因為我們現在要測試，請點擊 Test URL 旁邊的網址，把它 複製 下來。

網址長得應該會像這樣：

https://heavy-pumas-play.hooks.n8n.cloud/webhook-test/test

步驟 3：開始監聽訊號

回到 n8n 介面，點擊該節點下方的 “Listen for Test Event” (監聽測試事件) 按鈕。

這時候，你會看到介面顯示 Waiting for the webhook call... (正在等待呼叫…)。現在 n8n 正在屏息以待，隨時準備捕捉訊號。

步驟 4：發射訊號！

1. 開啟瀏覽器的一個 新分頁。
2. 在網址列貼上你剛剛複製的 Test URL。
3. 為了讓測試更有趣，我們在網址後面加一點參數，請把網址改成這樣：https://你的隧道網址/webhook-test/test?name=IronMan&msg=Hello(注意：問號 ? 後面就是我們要傳送的資料)
4. 按下 Enter。

實際測試, 是回傳 404, 空白內容

找到原因了！這是一個非常合理的狀況，原因在於我們剛剛做了一次 重啟 (Restart)。

兇手是：Tunnel URL 改變了

你剛剛為了修改 docker-compose.yml 執行了 docker compose up -d 重啟容器。

請記住 n8n 隧道模式的一個鐵律：

每次重啟 Docker，n8n 都會重新產生一個「全新的」隨機網址。

你現在用的這個 https://ayvz4dbqk... 已經是上一次啟動時的舊網址了，所以才會得到 404（找不到路）。

解決步驟

步驟 1：找出新的網址

在你的命令提示字元 (CMD) 輸入以下指令查看最新的 Log：

docker compose logs -f

如果看到這個畫面

找不到 Tunnel URL, 是因為，你的 Log 還沒跑完，docker compose up -d 重啟容器時，因為開啟 Tunnel (隧道) 需要跟 n8n 官方伺服器連線，這通常需要 10~20 秒 的時間。

等20 秒後就可以看到正常的 log

請往下滑，找到最新的那一段，尋找：

Tunnel URL: https://xxxx-xxxx-xxxx.hooks.n8n.cloud/

這串亂碼肯定跟原本的不一樣, 結果, 重開機之後, tunnel url 還是同一組, 也還是顯示 404 且無法連線。

1. 關鍵診斷：檢查n8n的系統資源使用狀態

最常見造成 n8n 執行不穩定的原因是：記憶體不足 (OOM – Out of Memory)。

n8n 是一個 Node.js 應用程式，加上開啟 Tunnel 需要額外資源，如果 Docker 分配的記憶體不夠，它就會在啟動完成瞬間被系統殺掉（Killed）。

觀察即時資源使用率

在您的 ocker-compose.yml 目錄下(例如: C:\Max\docker\n8n-docker>)，開啟一個新的 CMD 視窗，輸入：

docker stats

觀察 n8n-local 的 MEM USAGE / LIMIT。如果使用率飆高接近 100% 然後容器重啟，那就確認是記憶體問題。

既然內建 Tunnel 會導致不穩且消耗資源，建議關閉它，改用 Cloudflare Tunnel 或單純用 localhost 開發。

長治久安的替代方案 (強烈建議)

因為 n8n 官方的 Tunnel 非常不穩，如果您發現它常常斷線，請不要浪費時間修復它，直接改用以下替代方案，這是所有 n8n 進階使用者的標準做法：

方案	穩定性	難度	費用	推薦情境
Cloudflare Tunnel		中	免費	首選。最穩定，無需開防火牆 Port，支援 HTTPS。
ngrok		低	免費/付費	快速測試用。免費版網址會變，有流量限制。
Tailscale Funnel		中	免費	如果你已經在用 Tailscale VPN。
VPS + Domain		高	付費	生產環境標準做法 (Docker Compose + Caddy/Traefik)。

改用 Cloudflare Tunnel 的快速做法

如果你有自己的網域（Domain），使用 Cloudflare Tunnel 是最完美的解法：

1. 開啟您的 docker-compose.yml 檔案。
2. 在 n8n 的環境變數設定 WEBHOOK_URL=https://n8n.yourdomain.com。
3. 找到 command: 部分，移除 --tunnel 參數。
4. 在同一台機器安裝 cloudflared，設定將 n8n.yourdomain.com 轉發到 localhost:5678。

這是一個非常棒的決定。Cloudflare Tunnel (前身為 Argo Tunnel) 是目前的黃金標準，它不僅免費、穩定，而且不需要你在路由器上打開任何 Port，非常安全。

前提條件：

1. 你有一個網域 (Domain)（例如 max-studio.com）。
2. 你的網域 DNS 是託管在 Cloudflare 上（免費版帳號即可）。

以下是整合到你現有 Docker Compose 的完整步驟：

第一步：取得 Cloudflare Tunnel Token

登入 Cloudflare Zero Trust Dashboard。

目前是有 free plan, plan 名稱: Zero Trust Free, 但需要綁信用卡, 綁好的畫面如下:

在左側選單點擊 Networks > Connectors。點擊 Create a tunnel。

目前提供二種, 選擇左邊建議值: Cloudflared 就可以了.

取個名字（例如 n8n-home），點擊 Save tunnel。

在 “Install connector” 頁面，選擇 Docker。你會看到一串指令，網頁有提供點小圖一鍵複製到剪貼簿.

指令長這樣：docker run ... cloudflare/cloudflared:latest tunnel --no-autoupdate run --token eyJhIjoi...

複製好之後, 到 Windows 的提示字元視窗裡執行, 就可以了.

這裡的參數的 token 後接的一串字, 之後要查詢的話, 點擊 tunnel 的 item, 再點 configure, 就可以看到了.

選擇 subdomain + domain name, 還有 local docker 的 port 即可 complete setup.

第二步：修改 docker-compose.yml

請編輯你 C:\Max\docker\n8n-docker 目錄下的 docker-compose.yml 檔案。我們需要做兩件事：

1. 加入 cloudflared 服務。
2. 修改 n8n 服務設定（移除舊 tunnel，設定新網址）。

請參考以下範例進行修改（注意中文註解處）：

YAML

services:
  # 這是你原本的 n8n 服務
  n8n-local:  # 你的 Log 顯示你的服務名稱叫 n8n-local
    image: docker.n8n.io/n8nio/n8n
    restart: always
    ports:
      - "5678:5678"
    environment:
      - N8N_HOST=n8n.yourdomain.com  # 改成你的網域
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.yourdomain.com/  # 重要：這是 Cloudflare 網址
      # - GENERIC_TIMEZONE=Asia/Taipei
    volumes:
      - ./.n8n:/home/node/.n8n
    # command: start --tunnel  <-- 重要：請務必刪除或註解掉這行！不要再用內建 Tunnel 了

  # 這是要新增的 Cloudflare Tunnel 服務
  tunnel:
    image: cloudflare/cloudflared:latest
    restart: always
    command: tunnel run
    environment:
      - TUNNEL_TOKEN=<請貼上剛剛複製的超長 Token>

修改重點：

1. 移除 n8n 的 --tunnel 啟動參數。
2. 新增 WEBHOOK_URL 環境變數，填入你即將設定的網址（例如 https://n8n.max-studio.com）。
3. 貼上 Token 到 TUNNEL_TOKEN。

第三步：啟動並設定路由

1. 重啟 Docker：在 CMD 中執行：
   docker compose up -d --force-recreate
2. 設定 Cloudflare 路由 (Public Hostname)：回到剛剛的 Cloudflare Zero Trust 網頁，點擊 Next 進入 “Public Hostnames” 設定頁：
   • Subdomain: 輸入你想要的名稱 (例如 n8n)。
   • Domain: 選擇你的網域。
   • Path: 留空。
   • Service:
     • Type: HTTP
     • URL: n8n-local:5678
     • (解釋：這裡填 n8n-local 是因為在 Docker Compose 內部，服務名稱就是主機名稱。如果你的服務名不是 n8n-local，請改成你的 yaml 裡的名稱)
3. 點擊 Save tunnel。

第四步：見證奇蹟

現在，打開瀏覽器輸入 https://n8n.你的網域.com。

你會發現：

1. 速度極快（因為走 Cloudflare 全球節點）。
2. 非常穩定（不會再有 Crash Loop）。
3. 有免費的 SSL 鎖頭（HTTPS）。

除錯小技巧：

雖然 cloudflare 網頁上的範例是寫 localhost, 但輸入 localhost 會造成 502 error,

這裡的值是要寫 n8n-local

請複製並執行這行指令，它會停止所有服務並強制移除那些佔用資源的「孤兒容器」：

docker compose down --remove-orphans

說明: –remove-orphans 是關鍵，它會把 Log 中警告的那個 Found orphan containers ([n8n-local]) 清除掉，釋放 5678 端口。

清除完畢後，再次執行啟動指令：

docker compose up -d

見證奇蹟

最後取得回傳值: {“message”:”Workflow was started”}

下一步挑戰

既然資料已經進來了，通常下一步就是「把資料送出去」或「做點處理」。

將資料自動寫入 Google Sheets 是自動化最常見的應用場景之一。

不過我要先給你一個心理建設：Google 的安全性比較高，所以設定「憑證 (Credential)」的步驟會稍微繁瑣一點點（大約需要 5-10 分鐘）。但只要設定這一次，以後你串接 Gmail、Drive 都可以通用。

為了讓你的 Docker 環境（網址會變）也能穩定運作，我強烈建議使用 「Service Account (服務帳號)」 的方式，這樣就不用擔心隧道網址變動導致連線失效。

請跟著我一步步做：

第一階段：Google 雲端設定 (只需做一次)

我們需要去 Google Cloud 申請一個「機器人帳號」來幫你讀寫試算表。

1. 建立專案：
   • 前往 Google Cloud Console。
   • 左上角選擇專案 -> New Project (新增專案) -> 取名為 n8n-automation -> Create。
2. 開啟 API 功能：
   • 左側選單點擊 APIs & Services -> Library。
   • 搜尋 Google Sheets API -> 點擊 Enable (啟用)。
3. 建立機器人 (Service Account)：
   • 左側選單點擊 Credentials (憑證)。
   • 點擊上方 + CREATE CREDENTIALS -> 選擇 Service Account。
   • Service account name 隨便填 (例如 n8n-bot) -> Done。
4. 取得鑰匙 (Key)：
   • 在列表點擊剛剛建立好的那個帳號 (像是一個 Email 地址)。
   • 上方標籤頁選 Keys -> Add Key -> Create new key -> JSON -> Create。
   • 電腦會自動下載一個 .json 檔案，請保管好它，這就是你的鑰匙。

第二階段：準備試算表

1. 打開 Google Sheets，建立一個新試算表。
2. 設定標題列 (很重要)：
   • 在 A1 儲存格輸入 name
   • 在 B1 儲存格輸入 msg(因為 n8n 會認第一列當作欄位名稱)
3. 把試算表「分享」給機器人：
   • 打開剛剛下載的 JSON 檔案 (用記事本)，找到 client_email 那一行，複製那個看起來很長的 Email。
   • 回到試算表，點右上角 「共用 (Share)」，把那個 Email 貼上去，權限設為 「編輯者」 -> 傳送。

第三階段：n8n 設定 (最後一步！)

1. 新增節點：
   • 在 n8n 裡，點擊 Webhook 節點右邊的 +。
   • 搜尋 Google Sheets 並點擊。
2. 設定憑證 (Credential)：
   • 在節點設定中，找到 Credential to connect with -> 選擇 Create New。
   • Credential Type 請選擇 「Google Service Account」 (這對 Docker 用戶最友善)。
   • 打開你剛剛下載的 JSON 檔，把裡面的 Service Account Email 和 Private Key 複製貼上到對應欄位 -> Save。
3. 設定寫入動作：
   • Resource: Document
   • Operation: Append (新增一行)
   • Document:
     • 可以用 From URL 模式，直接把你的試算表網址貼上去。
     • 或者選 From List 去搜尋你的檔案。
   • Sheet Name: 輸入工作表名稱 (通常是 工作表1 或 Sheet1)。
4. 對應資料 (Mapping)：
   • 這時候你會看到下方有 Columns 的選項。
   • 把 Data Mode 改為 Auto-Map Input Data to Columns (自動對應)。
   • (關鍵) 回到 Webhook 節點，確認你剛剛測試的資料 (name 和 msg) 還在。
   • 如果欄位名稱 (name, msg) 跟你的試算表標題一模一樣，它就會自動對應進去！

測試時刻

1. 點擊 Google Sheets 節點右上角的 Execute Node (執行節點)。
2. 如果顯示綠色勾勾，趕快切換到你的 Google 試算表。
3. 你應該會看到 IronMan 和 Hello 被寫進去了！

(如果卡在 Google Cloud 那邊設定太複雜，也可以告訴我，我們改用比較簡單的「寫入本地 CSV 檔案」來練習，不用申請任何帳號。)

Whisper 是一款通用語音辨識模型的工具程式，透過 AI 精準捕捉每一句話，可以取得逐字稿，把 YouTube / Podcast 影片/聲音轉換為文字檔，可以省下慢慢觀看或收聽的時間，以提升學習效率。

這篇文章要手把手教你怎麼設定環境與安裝 whipser, 還有分享 whisper 相關參數.

Ｑ：這個不是已經有gui的版本了？
Ａ：使用shotcut 是有 GUI 版本, 但是 shotcut 的 language 切不到 zh, shotcut 似乎使用 GPU 也會失敗, 雖然我有 GPU, 但多花一點時間進行除錯, 應該是可以試出某一個組合, 是可以使用 GPU進行辨識。

YouTube 影片: https://youtu.be/mJXUCLYjhmg

Whisper 安裝方法

以下都是官方的教學，參考:
https://github.com/openai/whisper/

安裝 python

我所安裝的版本是 3.11.9, 目前建議的版本有 3.10.11, 或 3.12.6

安裝 Whisaper

你如果已經安裝過，請先進行移除Whisper，使用以下命令移除 Whisper：

pip install -U openai-whisper

全新的安裝可以使用以下命令：

pip install git+https://github.com/openai/whisper.git

曾經安裝過，無腦進行升級，請執行指令：

pip install --upgrade --no-deps --force-reinstall git+https://github.com/openai/whisper.git

安裝 ffmpeg

此外，還需要在您的系統上安裝命令列工具 ffmpeg，比較簡單的作法是連到 ffmpeg 的 github 進行下載:
https://github.com/BtbN/FFmpeg-Builds/releases

我自己是手動下載執行檔, 並放置到系統的 path 路徑下, 教學如下:
Windows 11 設定環境變數, 以加入 ffmpeg 指令為例
https://max-everyday.com/2023/01/windows-11-environment-variables/

ffmpeg工具可透過第三方的軟體套件管理器取得：

在 Ubuntu 或 Debian 系統上

sudo apt update && sudo apt install ffmpeg

在 Arch Linux 系統上

sudo pacman -S ffmpeg

在 macOS 系統上使用 Homebrew (https://brew.sh/)

brew install ffmpeg

在 Windows 系統上使用 Chocolatey (https://chocolatey.org/)

choco install ffmpeg

在 Windows 上使用 Scoop (https://scoop.sh/)

scoop install ffmpeg

要安裝 Rust套件

執行：

pip install setuptools-rust

Whisper 可用模型和語言

共有六種模型大小。

模型 / 檔案大小 / 所需顯存 / 相對速度

• tiny 39 MB ~1 GB ~10 倍
• base 74 MB ~1 GB ~7 倍
• small 244 MB ~2 GB ~4 倍
• medium 769 MB ~5 GB ~2 倍
• large 1550 MB ~10 GB 1 倍
• turbo 809 MB ~6 GB ~8 倍

turbo 型號是 large-v3 的最佳化版本，在保證準確性的前提下，可提供更快的轉錄速度。

不趕時間的話，建議使用 large, 慢慢去辦識。

不建議使用 base 與 tiny，雖然功能是可以用，都要花時間辦識了，還要花更多時間去校對。

如果只是要用來標記有講話的地方，建議使用 base 或 tiny, 速度會比較快。

medium模型在很多情況下反而比large準確，我自已測試 turbo 還的品質還滿好的，可以拿到比 medium 更多的語助詞。

這些模型，不需要我們自己手動下載，whisper 會自動幫我們下載在 C:\Users\{account}\.cache 目錄下。如果確定這台電腦未來用不到 whisper, 不想浪費儲存空間放用不到的檔案, 可以到這個資料夾來清除快取的檔案。

Whisper 命令列用法

以下命令將使用 Turbo 模型轉錄音訊檔案中的語音：

whisper audio.mp3 --language Chinese --model turbo

預設設定（選擇 Turbo 模型）適用於轉錄英文。但是，Turbo 模型並非為翻譯任務而訓練。如果您需要將非英語語音翻譯成英語，請使用多語言模型（tiny、base、small、medium、large）之一，而不是 Turbo。

執行以下命令查看所有可用選項：

whisper --help

如果遇到問題：

Skipping audio.mp3 due to ValueError: Expected parameter logits (Tensor of shape (5, 51866)) of distribution Categorical(logits: torch.Size([5, 51866])) to satisfy the constraint IndependentConstraint(Real(), 1), but found invalid values:
tensor([[nan, nan, nan,  ..., nan, nan, nan],
        [nan, nan, nan,  ..., nan, nan, nan],
        [nan, nan, nan,  ..., nan, nan, nan],
        [nan, nan, nan,  ..., nan, nan, nan],
        [nan, nan, nan,  ..., nan, nan, nan]], device='cuda:0')

請改用指令：

whisper audio.mp3 --language=zh --device=cpu --model=turbo

預設的 language=Chinese 容易常會誤判斷簡體中文, 改成 zh 之後就會翻成繁中了.

下載 YouTube 影片指令：

yt-dlp -x --extractor-args "youtube:player_client=default" URL

下載 YouTube 影片為 mp3 指令：

yt-dlp -x --audio-format mp3 --extractor-args "youtube:player_js_version=actual" URL

影片或音檔轉為單聲道:

ffmpeg -i input.mp3 -ac 1 output.mp3

把採樣率降到16kHz，轉成MP3，速度較快，準確度可能較高

ffmpeg -i input.mp3 -ar 16000 -ac 1 -ab 16k output.mp3

如果是為了自動去除影片之中無聲音的片段，建議使用 base 模式, 速度會更快, 完整步驟參考下列文章:

用字幕自動剪掉影片空白段落(Whisper + ffmpeg)
https://max-everyday.com/2025/12/srt-video-cutter/

相關網站

SmartSub
https://github.com/buxuku/SmartSub
「妙幕」是一款跨平台客户端工具，可以批量为视频或者音频生成字幕文件，并支持对字幕进行翻译，支持百度、火山、openai、ollama、deepseek 等多家翻译

測試結果，在完全沒寫程式碼的情況下，Antigravity 確實完成網友許願的功能的增加。

使用心得：

• 第一次開啟專案, 使用提示詞: 詳細分析目前專案
• 使用 Fast + (Low) 就夠用, 如果一直彈出 Error 的話
• 分析結果不一定可以一次到位, 再給下一個提示詞即可

影片分享: https://youtu.be/VERnMoefJWg

Google Antigravity 是 Google 發布 AI 原生開發平台（IDE）。

與 Antigravity 最相似的產品是「Cursor」，兩者都基於 VS Code，但在設計哲學上有根本的差異：Cursor 是最強的 AI 輔助駕駛（Copilot），而 Google Antigravity 則試圖成為你的 AI 代理人（Agent）。另一個主要差異在 chrome 瀏覽器是 Google 開發的，所以可以輕易整合到開發環境。

Google Antigravity 與 Cursor 在 AI 輔助程式碼開發上的詳細差異比較：

1. 核心理念與定位 (Philosophy)

• Cursor (AI 輔助者):
  • 核心： “Human-Centric”（以人為中心）。
  • 模式： 你是駕駛，AI 是導航員。你寫 Code，AI 幫你補全、重構或解釋。雖然有 Composer 可以編輯多個檔案，但主要還是依賴你來驅動每一個指令。
  • 目標： 讓你寫程式更快。
• Google Antigravity (AI 代理人):
  • 核心： “Agent-First”（以代理人為中心）。
  • 模式： 你是架構師/管理者，AI 是員工。你不只是叫 AI 寫一段 Code，而是給它一個「任務」（Task），例如「修復登入頁面的 Bug 並測試」。
  • 目標： 讓 AI 自主完成開發、測試、驗證的完整流程。

2. 功能與工作流差異 (Features & Workflow)

3. 底層模型 (AI Models)

• Cursor:
  • 主力模型： Claude 4.5 Sonnet (目前公認寫 Code 最強)。
  • 選擇性： 允許用戶切換 GPT-4o 或其他模型，但深度整合是針對 Claude 優化的。
  • 優勢： Claude 3.5 Sonnet 在程式碼邏輯和指令遵循上目前仍是頂尖標準。
• Google Antigravity:
  • 主力模型： Gemini 3 Pro (Google 最新發布的最強模型)。
  • 開放性： 令人驚訝的是，Google 也支援 第三方模型（如 Claude 4.5 Sonnet, GPT-OSS）。
  • 優勢： Gemini 3 擁有超大的 Context Window（百萬級 Token），理論上對超大型專案（Monorepo）的理解力會比 Cursor 更強；且 Google 聲稱 Gemini 3 在 Agentic 任務上的表現優於 Claude。

4. 介面設計 (Interface)

• Cursor:
  • 長得像 VS Code，但把 AI Chat 和編輯器融合得非常無縫（Inline Edit）。
  • 操作邏輯是：Cmd+K (指令) -> 生成代碼 -> Tab (接受)。
• Google Antigravity:
  • 雙介面模式：
    1. Editor View: 傳統 IDE 介面，類似 Cursor，適合寫 Code。
    2. Manager View: 這是全新的概念，一個「指揮中心」，用來管理多個正在工作的 AI Agents，查看它們的進度、截圖和計畫。
  • 回饋機制： 你可以像在 Google Docs 上一樣，直接在 Agent 生成的截圖或計畫書上留言（Comment），Agent 會根據留言修正行為，而不需要停止任務。

5. 誰適合哪個？

• 選擇 Cursor，如果：
  • 你喜歡親自掌控每一行程式碼。
  • 你需要極致快速的「自動補全」體驗（Tab Tab Tab）。
  • 你已經習慣了 Claude 4.5 Sonnet 的手感。
  • 你主要做後端或邏輯層開發，不需要頻繁的 UI 視覺驗證。
• 選擇 Google Antigravity，如果：
  • 你想嘗試「將任務外包給 AI」的未來工作模式。
  • 你是 全端或前端工程師：Antigravity 的「瀏覽器視覺驗證」能力對調 UI、修 CSS 非常強大。
  • 你的專案非常龐大，需要 Gemini 級別的 Context Window。
  • 你希望 AI 能幫你跑測試、安裝環境，而不僅僅是寫字。

base 與 medium 推論比較

同一個影片, base 推論結果:

1
00:00:00,000 --> 00:00:07,040
哈喽大家好,我是MACS,今天要來分享諾貝爾的小故事

2
00:00:07,040 --> 00:00:11,240
他是一個意外獨到自己復魂的男人

3
00:00:11,240 --> 00:00:14,640
作為一個很快一世紀的製者

4
00:00:14,640 --> 00:00:20,440
93歲的巴菲特,他寫給古端的高別姓已經被管瘋的分享

5
00:00:20,440 --> 00:00:24,400
近週呢,有涵蓋很多不同領域的重點

medium 推論結果:

1
00:00:00,000 --> 00:00:03,000
哈囉大家好,我是Max

2
00:00:03,000 --> 00:00:07,000
今天要來分享諾貝爾的一個小故事

3
00:00:07,000 --> 00:00:11,000
他是一個意外讀到自己復魂的男人

4
00:00:11,000 --> 00:00:14,000
作為一個橫跨一世紀的智者

5
00:00:14,000 --> 00:00:16,000
93歲的巴菲特

6
00:00:16,000 --> 00:00:20,000
他寫給股東的告別信已經被廣泛的分享

7
00:00:20,000 --> 00:00:24,000
信中有涵蓋很多不同領域的重點

medium model 效果真的好很多, 可以省下很多修改的時間, 但是與其使用 shotcut 不如自己直接用 python 來取得字幕內容, 參考:

Whisper
https://github.com/openai/whisper
Robust Speech Recognition via Large-Scale Weak Supervision

如果要讓文字轉語音, Shotcut 也增加支援:

KokoroDoki: Real-Time Text-to-Speech (TTS)
https://github.com/eel-brah/kokorodoki/
Natural-sounding Text-to-Speech App that fits anywhere. Fast, Real-Time and flexible.

目前 Shotcut 25.10.31 附的 whisper 缺點

在明明有 GPU 但似乎程式無法檢測到, 不管是在 base model 或 medium model, 這個造成都是使用 CPU 進行推論, 造成如果使用較大的 medium model ，推論所需要的執行時間變的很長！

下載的 .bin 並沒有存在 shotcut 目錄下, 所以 shotcut 切換版本, 不需要重新下載 whisper 的 model, 缺點也變成, 移除 shotcut 記得要再去移除 .bin 檔, 不然真的肥大.

Base Multilingual 與 Quantized 的差異

這兩種模型都是基於相同的 Base Multilingual 架構訓練出來的，因此它們的語言能力範圍和基本架構是相同的。

主要的差異在於模型的儲存方式和計算精度，這會直接影響檔案大小、記憶體需求和執行速度。

ggml-base-q5_1.bin 就是一個 Quantized 模型（q5_1 指的是 5 位元的量化）。

Shotcut 內建 Whisper 喜歡使用量化模型，是因為它具有以下優勢：

1. 速度： 在 CPU 上執行時，量化模型計算更快，降低了語音轉文字所需的總時間。
2. 效率： 佔用的磁碟空間和 RAM 資源少，適合整合到應用程式中，減少了使用者下載和執行的負擔。

Shotcut 內建或自動下載的Whisper 模型儲存路徑

Shotcut 內建或自動下載的 Base Multilingual Quantized 模型（例如 ggml-base-q5_1.bin 或類似的量化版本），通常會存放在 Shotcut 的 應用程式資料 (App Data) 目錄下的特定子資料夾中。

以下是根據您提供的日誌和標準 Windows 平台的具體路徑：

這個目錄位於 Windows 的隱藏資料夾 %LOCALAPPDATA% 中：

1. 完整路徑範例 (基於您的日誌)：C:\Users\max\AppData\Local\Meltytech\Shotcut\extensions\whispermodel\
2. 通用路徑 (您可以直接在檔案總管地址欄輸入)：%LOCALAPPDATA%\Meltytech\Shotcut\extensions\whispermodel\

(如果您的帳號是 max)

為什麼要分享常見推送方式，因為AI 模型已經過大量相關資料的訓練，這意味著你只需用自然語言或口語化提示，就能讓 AI 自動生成你所需的程式碼或整合進舊的專案之中。

分享常見的推送方式，當然也有更原生和傳統正規的解法，就不在這裡介紹：

• 企業微信(+微信推送方案)
  企業可以通過企業微信的API將訊息推送到客戶的個人微信上；利用企業微信的官方功能，如將個人微信好友新增至企業微信，即可接收到企業訊息。
• 飞书的推送方案
  https://www.feishu.cn/content/message-push-tools
  整合自建應用（通過開放平臺API實現推送）、使用Webhook（接收外部應用數據並推送訊息）以及利用飛書內建工具（如多維表格和低程式碼平臺實現自動化和自定義推送）。
• LINE 企業推播
  https://tw.linebiz.com/
  分為「輕、中、高用量方案」，並根據發送的訊息量收費，包含月費及免費訊息額度。輕用量方案： 月費免費，提供200則免費訊息。
• 钉钉发送消息到企业群
  https://open.dingtalk.com/document/development/send-group-messages
  有通過自建應用實現推送，例如整合第三方企業郵箱，讓郵件新訊息推送到釘釘；或者利用釘釘自有功能，例如在群聊中、通過@成員等方式發送通知。還可以利用第三方工具，如草料二維碼，將表單數據推送到釘釘群聊中，但推送條數可能受版本限制。
• Telegram Bot 推送通知
  https://core.telegram.org/bots/api
  通過廣告向用戶推送和通過機器人向特定使用者或群組推送通知。
• ntfy
  Send push notifications to your phone or desktop using PUT/POST
  https://github.com/binwiederhier/ntfy
  ios app:
  https://apps.apple.com/us/app/ntfy/id1625396347
  android app:
  https://play.google.com/store/apps/details?id=io.heckel.ntfy
• Discord Webhook
  https://support.discord.com/hc/zh-tw/articles/228383668-%E4%BD%BF%E7%94%A8%E7%B6%B2%E7%B5%A1%E9%89%A4%E6%89%8B-Webhooks
  允許外部應用向 Discord 頻道發送訊息的機制。要使用它，你首先需要在目標頻道建立並配置一個 Webhook，獲取其獨有的 URL。然後，通過向該 URL 發送 HTTP POST 請求，在請求的 JSON 載荷中包含你想要發送的訊息內容（如文字、圖片等），即可在 Discord 頻道中看到發送的訊息
• SMTP
  傳統 email
• 透Google應用程式密碼寄送Email
  https://stackoverflow.max-everyday.com/2025/03/google-app-password/

該如何選擇?

1. 企業微信（＋微信推送）

優點

• 到達率高（微信使用率高）。
• 企業微信可直接 API 推送到用戶微信。
• 適合作為客服型或企業型通知。

缺點

• 設定流程較複雜。
• 有企業身份驗證門檻。
• 不適合一般個人用途。

適用

中大型企業、需要打入中國市場的服務。

2. 飛書（Feishu）推播

優點

• 官方提供多種整合方式：API、自建應用、Webhook、低程式碼自動化等。
• 功能彈性高。
• 很適合企業內部團隊通知。

缺點

• 飛書在台灣用戶量不如其他通訊軟體。
• 初期使用者不熟悉。

適用

企業內部流程、團隊協作推播、自動化工作流。

3. LINE 官方帳號（企業推播）

優點

• 台灣到達率最高。
• 官方提供免費額度（免費方案每月 200 則）。
• 介面與設定相對友善。

缺點

• 免費額度用完即收費。
• 對推播次數較高的個人或小團隊來說成本可能偏高。

適用

需要觸及台灣大眾，並可接受部分付費者。

4. 钉钉（DingTalk）推播

優點

• 適合中國市場。
• 支援群聊、企業應用、第三方整合。

缺點

• 台灣使用量極低。
• 功能偏企業導向，個人不適合。

適用

中國企業內部通知、表單同步、ERP/CRM 整合。

5. Telegram Bot 推播

優點

• 建立機器人完全免費。
• 速度快、到達率高、跨平台。
• 技術整合簡單（只需 Bot Token）。

缺點

• 一般大眾使用量不如 LINE（在台灣）。
• 部分企業環境可能封鎖 Telegram。

適用

工程師、開發者、社群、跨國團隊。

6. ntfy（自架或免費公共伺服器）

優點

• 完全免費。
• 可自架 → 私密且可完整掌握資料。
• API 非常簡單（curl POST 就能推）。
• 支援 Android / iOS。

缺點

• 免費公共 ntfy 伺服器可能有速率限制。
• 若自架需要伺服器環境。

適用

個人自動化通知、家用伺服器、NAS、HomeLab、工程師。

7. Discord Webhook 推播

優點

• 設定最簡單的 Webhook 之一。
• 支援圖文訊息、Embeds、美觀的格式。
• 完全免費。

缺點

• Discord 使用族群偏特定圈子（遊戲、社群）。
• 不適合廣泛群眾推播。

適用

社群伺服器通知、工程師、遊戲相關服務。

8. SMTP（傳統 Email）

優點

• 普及率 100%，人人都有 Email。
• 不需額外下載 App。
• 設定簡單、成本低。

缺點

• 到達率受垃圾信分類影響。
• 實時性不如即時通訊。

適用

帳號註冊、備份通知、較不即時的提醒。

9. Google 應用程式密碼寄送 Email

優點

• 適合 Gmail 使用者。
• 程式碼整合容易（SMTP 密碼即可使用）。
• 不需額外平台成本。

缺點

• 到達率仍受 Gmail 垃圾信規則影響。
• 部分使用情境受限於 Google 政策。

適用

個人小工具、家用伺服器通知、NAS 警告提醒。

多面向比較表

免費、跨平台、台灣民眾推薦方案

推薦1：Telegram Bot（最佳免費方案）

理由：

• 完全免費
• API 超簡單（不到 3 行程式）
• 到達率高（幾乎秒收）
• iOS / Android / PC 都能用
• 不需要伺服器就能推送（可用 curl）

對沒有企業身份、不想花錢的人最省力與實用。

推薦2：ntfy（需要更多客製化時）

推薦原因：

1. 極致的免費與開放性： ntfy 本身是開源軟體，您可以完全免費地在自己的伺服器上搭建，實現完全掌控。即使使用官方的公共伺服器，其基本的推送功能也是免費的（儘管可能存在流量或速率限制）。
2. 技術門檻極低： 推送機制非常簡單，只需向特定的 Topic (主題) URL 發送一個標準的 HTTP POST/PUT 請求即可，不需要複雜的 API 註冊、應用程式密碼或企業認證。
3. 跨平台支援完善： 提供了專屬的 iOS 和 Android 應用程式，確保訊息能夠像傳統 APP 通知一樣即時推送到手機桌面。
4. 高度自定義： 可以輕鬆設定通知的標題、優先級、標籤等，適合各種自動化腳本或簡單監控系統使用。

如何使用 (極簡概括)：

1. 在手機上安裝 ntfy App。
2. 在 App 中訂閱一個自定義的 Topic (例如：my-secret-topic-2025)。
3. 在您的程式碼或腳本中，只需執行一個簡單的 HTTP POST 請求：
   curl -d "這是我的免費通知內容！" ntfy.sh/my-secret-topic-2025
   訊息就會立即推送到您訂閱了該 Topic 的手機上。

推薦３：Gmail（SMTP 或 App Password）

如果只是：

• 備份通知
• 重要提醒
• 沒有「一定要即時」

那 Email 是最通用且沒有安裝門檻的方案。

推薦4：Discord Webhook

如果您的通知是為了小社群或非敏感的訊息，或者您已經活躍於 Discord 社群：

• 優點： 完全免費，設定極為簡單，視覺化效果較好，適合發布系統狀態、簡單警報到特定的 Discord 頻道供多人查看。
• 缺點： 訊息是發佈到 Discord 頻道中，不像 ntfy 是直接的手機推送通知，且 Webhook URL 需要妥善保管。