AI 一天 24 小時都在直播、都在銷售。
昨晚，我的 LINE 上正在進行一場「直播」。留言區裡，「從大阪收看！」、「我想預約諮詢」等訊息不斷流動，主講人也一一接話回應。畫面底部出現了一個按鈕，一對一諮詢的名額正被按下按鈕的人一個一個填滿。
等等，那是錄影。那些留言也是照劇本演的。
覺得有點掃興嗎？但影片中的主講人自己揭開了祕密：「這場直播是錄好的。你剛才感受到的那股現場熱度，全都是設計出來的。」觀眾這才發現，自己以為的現場直播，其實是產品展示。而這整個結構本身就是產品。
所謂的「Auto-Webinar」到底是什麼？
簡單來說，就是一套就算我在睡覺或玩樂，也會自動開直播、吸引顧客、建立銷售名單（商談機會）的系統。
就算睡著了，直播也會幫你銷售。
它的真面目，就是「把一支錄影變成偽直播」。先認真錄製一場直播。之後，這支錄影就會依照排定的時間，以「直播」的形式不斷自動開播。從觀眾的角度來看，這是一場真正的直播體驗：在固定時間即時開播、留言不斷出現、主講人接話回應、最後作為一次性活動結束——只是，螢幕後面根本沒有主講人。
就算在玩樂，吸引顧客也不會停。
無論是吸引顧客還是銷售，全都無人化。加你為好友的人會收到自動引導訊息 → 他們選擇想參加的場次並完成預約 → 開播前 5 分鐘收到提醒 → 直播開始 → 產品資訊配合講解節奏出現 → 不用暫停影片就能填完申請表。這段時間裡，我人在睡覺、玩樂或做其他工作。手機上收到的只有「已有人預約」、「已收到表單回覆」這類通知。
一天自動開 10 場，自動吸引顧客。
我們這裡從上午 9 點到下午 6 點，每小時自動安排一場直播，總共 10 場。如果是真人每場都現場直播，喉嚨和精神都會撐不住；但既然是錄影，每一場都能維持 100% 的狀態。就算半夜突然想到，也能預約「明天上午 9 點那場」再安心入睡。
傳統 Webinar 對比 Auto-Webinar
本質上，就是把表現最好那一場直播，每天重播 10 次。這個機制已經以我正在開發的開源專案 LINE Harness 的新功能形式實作出來。換句話說，可以免費使用。接下來，我會一步步告訴你怎麼打造它。
這是發布後整整一天的實際數據：
連結點擊：330 → 場次預約：166（50%）→ 觀看人數：146 → CTA 點擊：66（佔觀看者的 45%）→ 諮詢名單：14（其中包含 2 位年營業額超過 1 億日圓的 CEO）
廣告費 0 日圓、發送伺服器成本幾乎為 0、當天人力 0。本文將以我手邊這份 15,000 字的實戰手冊為基礎，從錄影的放置方法到防止回轉、預約與提醒、CTA 設計、分析、緊急停止程序，完整公開所有內容。
想先體驗真實運作的樣子，請點這裡。加入好友後，LINE 會收到引導訊息，可以直接選擇要參加的場次👇
https://line.the-harness.com/x-autowebinar
每一章都附上了「可以直接貼給 AI 的工作提示詞」。如果你使用 Codex 或 Claude Code，只要把【 】內的內容替換成你自己的環境再貼上，就能繼續建置。篇幅非常長，建議先加入書籤。
5 個設計原則
先掌握這 5 個設計原則
不知道這 5 點就動手做的話，通常只會變成「發送錄影 URL」的成果。
- 光是把影片切成 HLS 並不能防止回轉。必須組合伺服器端的中途參加秒數、EXT-X-START、封死進度條、以及 5 秒誤差修正，才能成為「無法回轉的直播」。
- 不要以觀眾裝置的時間為基準。「現在是第幾秒」只由伺服器決定。裝置端只需加上接收後的單調遞增經過時間（monotonic elapsed time）。就算裝置時間不準，播放位置也不會偏移。
- 影片放在 R2，並透過短期有效的 HMAC 簽名 Worker URL 傳遞。不要把公開的 R2 URL 直接貼進教材或 LINE。
- 包含預約確認、開播前通知、事後追蹤在內，所有 LINE 發送都必須經過會保留記錄的發送路徑。如果系統無法追查「明明應該寄出卻沒收到」的問題，正式營運開始後一定會卡關。
- 不要把 OSS 版的基本功能與 production 先行功能搞混。設定之前，先確認自己使用的 commit 與 DB migration。
第 1 章：完成後的樣貌與整體地圖
從申請到追蹤，一條線貫穿整個流程。
先看完成後的樣貌。以觀眾的視角，流程如下：
選擇要參加的場次 → LINE 收到預約確認 → 開播前 5 分鐘 LINE 收到觀看連結 → 開播前 10 分鐘進入等候室（開播前留言開始流動）→ 觀看偽直播（暗樁留言＋你自己的留言）→ CTA 卡片配合講解節奏出現 → 不暫停影片直接填寫表單 → 自動貼標籤 → 觸發追蹤腳本 → 所有操作全部記錄到 DB
後端基礎設施只有 5 個：
Auto-Webinar 傳遞架構圖
- 管理畫面 — 建立／排程研討會、編輯留言／CTA、數據分析。
- LIFF — 在 LINE 內開啟的觀看頁面。好友識別在這裡完成。
- Cloudflare Worker — 判斷是否正在開播、發行簽名 URL、所有 API。
- R2 — 影片儲存。傳輸費用 0。
- D1 — 記錄預約、觀看位置、留言與 CTA 點擊。
不需要建立任何伺服器。一切都在 Cloudflare 的邊緣網路上運作。
老實說，LINE Harness 的 OSS 版和我先行營運的 production 版之間有些差異。OSS 版包含基本管理畫面、排程、HLS/R2 傳遞、heartbeat、留言、基本 CTA 與分析。多張 CTA 卡片、頁面內表單、場次預約、開播前 5 分鐘的 LINE 通知、僅限預約者參加的入場管制、針對 iOS 的 EXT-X-START 修正、管理端預覽等功能，則是 production 版先行，之後會陸續釋出到 OSS。
因此第一個任務，就是盤點「你的環境裡已經有哪些東西」。請把以下內容貼給 AI。
請盤點目前 LINE Harness auto-webinar 的實作現況，但不要修改任何東西。 1. 確認 Git 儲存庫、分支、commit、origin/upstream 與未儲存的 diff。不要動任何 diff。 2. 閱讀管理畫面的側邊欄、webinars 頁面、Worker 的 webinars 路由／client、DB 的 webinar migration、Cron 與提醒服務、R2 binding。 3. 將以下項目分類為「已實作／部分實作／未實作」：管理畫面 CRUD、HLS/R2、簽名 URL、開播判斷、預約、等候室、中途參加控制、LINE 通知、留言、CTA 卡片、頁面內表單、標籤、腳本、分析、預覽。 4. 以「畫面／API／D1 資料表／外部服務／故障時的症狀」製作一張從申請到追蹤的流程表。 5. 不要自行實作缺少的功能；先列出安全新增的順序、必要的 migration、測試與復原方式，然後等待指示。 不要顯示任何機密值；只需回報目前的功能表與第一個操作。
完成確認：已確認目前使用的 commit／能區分 OSS 與 production 先行功能／能說明畫面、API、DB、R2 之間的流程／沒有把未實作的功能誤判為「已設定」。
只要把影片轉成 HLS 然後放上去。
第 2 章：將 MP4 轉成 HLS 並從 R2 傳遞——¥0 傳遞成本的真相
一支 MP4 會切成每段 6 秒的片段（21 分鐘的影片約 425 段），並準備 1080p、720p、480p 等不同畫質。這就是 HLS，YouTube 與 Netflix 內部也是同樣的機制。主播放清單（master.m3u8）負責選擇畫質，各畫質的播放清單則顯示片段的排列順序。網路不穩的觀眾會自動切到低畫質，所以在電車上也不容易卡住。
HLS 的優點是，不需要讓觀眾下載整支 2 小時的影片，只需要抓取目前播放位置附近的一小段。不過先警告你：光是轉成 HLS 並不能防止回轉（這個問題會在下一章解決）。
存放位置是 Cloudflare 的 R2。這裡正是這個架構在成本上的核心。
- 傳輸費用 0。影片傳遞最可怕的就是頻寬成本，但不管多少人看都是 ¥0。
- 儲存費用方面，21 分鐘、700MB 的影片每月只要 1～2 日圓。
- 就算 1,000 人完整看完，讀取費用也只有幾十日圓。
每個月付好幾萬日圓給 webinar SaaS 的人，光是看到這一段就值回票價了吧。
三個實務上的注意事項：
- 原始影片是 720p 的話，就不要做 1080p。放大畫質只會讓容量變成兩倍，畫質連一毫米都不會變好。
- 上傳前一定要確認連到的是哪個 Cloudflare 帳號。最經典的意外，就是工具的設定檔指向了別的帳號而收到 403（我也曾經栽過一次）。
- 不要把影片放在公開 URL。Worker 會發行短期有效的 HMAC 簽名 URL，只能透過這個 URL 播放。
要貼給 AI 的提示詞：
請將這支影片轉為 LINE Harness auto-webinar 用的 HLS，並先放到驗證用 R2。未經核准前，不要上傳到 production。 【輸入 MP4 的絕對路徑】【webinar slug】【驗證用 Cloudflare 帳號】【驗證用 R2 bucket】 1. 閱讀 scripts/encode-webinar.sh 與 apps/worker 中的 wrangler 設定，決定實際要執行的指令。 2. 用 ffprobe 確認影片長度、編碼、解析度、幀率與音訊聲道。 3. 以唯讀模式確認 wrangler whoami、account ID 與 R2 bucket 清單；如果與指定的環境不同就立刻停止。 4. 以 1080p／720p／480p、6 秒 GOP、HLS VOD、完整 playlist 的方式轉檔。如果原始影片低於 1080p，請提出變更計畫，避免不必要的放大。 5. 在本機確認 master.m3u8、各畫質的 index.m3u8、開頭／中間／結尾的片段、播放長度差異、音訊與畫質切換。 6. 顯示預定上傳的物件數量與大致總容量，然後等待我的核准。 7. 核准後，將 m3u8 以 application/vnd.apple.mpegurl、ts 以 video/mp2t 的 Content-Type 上傳。 8. 透過 Worker 的簽名 asset 路由，確認 master、variant 與 segment 都回傳 200。 9. 回報要輸入管理畫面的影片前綴與秒數，以及 R2 的刪除方法。目前還不要發布到 production。
完成確認：已產生 3 種畫質的 master playlist／關鍵影格以 6 秒為單位對齊／已放到正確的 R2／可透過簽名 Worker 播放。
禁止回轉。
第 3 章：維持中途參加的播放位置，防止回轉
偽直播的命脈就在這裡。不管是重新整理、換裝置開啟、還是從背景回到前景，都必須永遠從「現在」的位置繼續播放。只要任何一個環節破功，就會被識破「這只是錄影」。
時間基準是伺服器。Worker 會回傳「從這場開始到現在經過了幾秒（offsetSeconds）」，裝置端只需加上接收後的單調遞增經過時間（performance.now() 的差值）。就算觀眾的裝置時間差了 5 分鐘，播放位置也不會偏移，也不需要每秒向伺服器查詢。
而這次最讓我卡關的，就是 iPhone。LINE 的應用程式內瀏覽器有時會忽略 JavaScript 的 seek 指令（對 video.currentTime 的賦值），直接跳回 0 秒。不管我在客戶端重試幾次都沒用。
答案在於轉變想法：「不要下令給播放器，而是讓傳遞資料本身宣告起始位置」。開始觀看時，在 playlist URL 後面加上「?at=目前秒數」，Worker 就會把 HLS 標準的 #EXT-X-START 標籤動態注入 master 與 variant playlist。播放器會把這個位置視為「起點」，所以這不是 seek，播放器也無法拒絕。結果所有裝置瞬間全部解決。
總結來說，偽直播是靠以下 4 個項目組成的：
- 以伺服器為準的 offsetSeconds — 只有伺服器知道位置的真實秒數。
- 注入 EXT-X-START — 由傳遞資料宣告起始位置（iOS 的主要解法）。
- 不顯示進度條 — 沒有控制列。只有管理端可以用 ?preview=1 從 0 秒開始以 2 倍速確認（而且不會污染分析數據）。
- 每秒誤差修正 — 只要偏移超過 5 秒，就強制同步回直播位置。分頁回到前景時重新同步。遇到 AirPods 脫落等系統造成的暫時停止，也會自動恢復播放（直播沒有暫停這回事）。
要貼給 AI 的提示詞：
請驗證 LINE Harness auto-webinar 在中途參加或重新整理時，是否不會回轉到開頭。先閱讀既有程式碼與測試；只有在真的有問題時，才提出最小限度的修正。 1. 閱讀 webinar-schedule.ts、webinar 路由的 asset 處理、worker 內部的 webinar client 與相關測試。 2. 具體說明 session 開始時間、伺服器目前時間、offsetSeconds、收到 API 回應時的 performance.now 與預期播放位置之間的關係。 3. 明確指出「光切 HLS 不能防止回轉」，並製作一張關於控制列、EXT-X-START、currentTime、誤差修正、visibilitychange、暫停恢復的職責分工表。 4. 用單元測試檢查開始前一刻／開始後／中途／結束後一刻、每天／每週／單次、以及 JST 跨日邊界等情況。 5. 用 asset 測試確認 ?at 會傳遞到 master 的 variant URI，且 EXT-X-START 只會被注入 master 與 variant 各一次。 6. 建立驗證用 session，並在開始 10 分鐘後分別用 iPhone LINE、Safari、Android LINE、Chrome 參加。記錄重新整理後、背景 10 秒後、等同 AirPods 脫落的暫停、切換網路時，是否都能回到 5 秒誤差範圍內。 7. 如果需要變更 production，請顯示原因行、最小 diff、測試與復原方式，然後等待核准。
完成確認：以伺服器 offset 為時間基準／EXT-X-START 已寫入 m3u8／超過 5 秒的偏移會自動修正／包含 iOS LINE 應用程式內瀏覽器在內的實機驗證完成。
預約 → 提醒 → 入場管制
第 4 章：預約、等候室與 LINE 提醒——將「聚集觀眾」自動化
如果直接把錄影 URL 丟出去，結果一定是「晚點再看」。讓他們選擇時間、做出承諾，並在開始前提醒他們。這就是參與率的分水嶺。
把場次設為每小時一場（我們是上午 9 點到下午 6 點、一天 10 場），讓觀眾自己選擇場次。他們一選擇，LINE 就會收到預約完成通知，並在開播前 5 分鐘推播觀看連結。實際測量中，50% 的點擊會繼續完成預約。
實作上真正關鍵的，其實是這些不起眼的地方：
- 預約只接受「行程表上實際存在且尚未開始的場次」。不存在的時間或過去的時間一律拒絕。
- 就算是同一個人重複預約同一場，也會因為 DB 的唯一性限制而只算一筆。
- 提醒只會送出一次。做法是在發送前先競爭一個「已通知」的標記（只有搶到的程序才能發送），所以就算 cron 跑了兩次，也不會變成兩封訊息。
- 不要發送給封鎖你的好友。
- 所有發送都會經過一條會保留在管理畫面訊息記錄中的路徑。
開播前 10 分鐘，觀眾開始聚集。
開播前 10 分鐘，觀看頁面會切換成等候室。在「距離開播還有 4 分 32 秒」的倒數計時下方，留言已經開始流動——「第一次參加！」、「收到通知馬上就衝來了」、「還有 3 分鐘左右」。營造出「開演前會場已經有人在等」的氛圍（開播前留言其實只是把留言的秒數設定成負數而已。開播前 3 分鐘就是 -180 秒）。
而且我禁止中途參加。直播進行中才進來的人，會看到灰色的「目前直播中／無法中途參加本場次」，並被引導去預約下一場。這麼做一方面是為了避免穿幫，另一方面是為了確保「所有人都能從頭開始看到 CTA」，而「進不來」這件事本身，反而成了直播感的證據。唯一的例外是，已經預約該場次的人遲到了（把已預約的人擋在門外反而會造成反效果）。
要貼給 AI 的提示詞：
請在驗證環境中，以 E2E 方式確認 auto-webinar 的預約、等候室、開播前 5 分鐘的 LINE 通知、以及僅限預約者參加的入場管制。不要發送給實際顧客。 【你的驗證用 LINE 好友】【驗證用 webinar slug】【驗證用 session 的日期與時間 JST】 1. 閱讀 reservation migration、預約 DB 函式、register API、提醒服務、Cron 呼叫端與 LINE 發送服務。 2. 將驗證 session 建立為「單次、且即將開始、現在就能確認」的場次。顯示目標帳號、LIFF ID、時區與影片長度，然後等待核准。 3. 從你的 LIFF 預約一個未來的場次，並確認即使重複送出相同預約，DB 也只會有一筆。不存在的時間與過去的時間必須被拒絕。 4. 確認預約完成通知只會送到你手上，並保留在管理畫面的訊息記錄中。 5. 確認開播前 10 分鐘會進入等候室、開播前 5 分鐘會成為提醒對象、開播後只有預約者會變成「已參加」。 6. 確認即使重新執行程序，提醒也不會送出兩次。 7. 測試「未預約」、「預約了其他場次」、「被封鎖」、「LINE API 失敗」、「DB 更新前失敗」等情況。 8. 回報建立的驗證資料、收到的訊息數量、訊息記錄、參加資格與刪除方法。
完成確認：只有未來且實際存在的場次才能預約／重複預約只算一筆／開播前通知只送一次／所有 LINE 發送都有記錄。
「選擇場次 → 預約完成 → 5 分鐘前提醒 → 等候室」這個流程，實際動手點過一次比讀十遍還快。馬上體驗👇
https://line.the-harness.com/x-autowebinar
讓流失率歸零的 CTA 設計。
第 5 章：留言、CTA 與表單——為什麼 45% 的觀眾按下了按鈕
留言全部可以用 AI 製作。但是，如果只是隨便產生，馬上就會穿幫。因為真人直播的留言區有它的一套規律。我把我們使用的所有生成規則列出來：
- 主講人覆誦的「我在大阪喔」，必須是在覆誦前幾秒就已經出現過的留言，否則會很突兀。配合逐字稿，以秒為單位對齊。
- 問題的回覆會延遲約 10 秒的「打字時間」才出現。秒回反而很不自然。
- 混入 10～20% 不會被主持人搭理的留言。例如打招呼、中途參加報告、閒聊、無法回答的問題。每一則都被接話的留言區才可疑。
- 偶爾安排幾段喜歡當老師的觀眾從旁回答其他人的問題（「那個，OO 小姐，那個意思是說……」）。
- 不要加入「啊，原來如此」這類自言自語。直播留言區幾乎不會有自言自語。這往往就是 AI 味的真面目。
- 名字則是將真實好友名單稍微變形，並經過機械化驗證，確認不會與任何真人對應之後才使用。
把實際直播的音訊轉成逐字稿，再讓 AI 照著這些規則生成，21 分鐘的影片需要的 128 則留言，幾分鐘內就能完成。
CTA 會與講解內容同步。錄影中說到「我想畫面下方應該出現按鈕了」的那一瞬間，CTA 卡片就會流入聊天區。因為語音與畫面完全同步，觀眾的體驗就是「我剛剛真的被現場引導了」。
最後一段引導則設定為自動開啟，不用點擊，整個聊天區就會切換成申請表單。
表單會以從底部滑出的 sheet 形式覆蓋在影片上方。影片與聲音仍然繼續播放。填寫 → 送出 →「🎉」→ 回到觀看。原本在跳轉到外部 LP 的那一刻會發生的流失，在這裡從結構上歸零。送出表單的同時自動貼上標籤、追蹤腳本開始動作、LINE 收到感謝訊息——全部自動完成。
測量上有一個鐵則：「CTA 點擊」、「表單送出」、「付款完成」是不同的事件。一旦把點擊數當成轉換來計算，之後所有的改善都會走歪。
要貼給 AI 的提示詞：
請為驗證用 webinar 安全地設定留言、CTA 卡片、頁面內表單、標籤與追蹤腳本。未經核准前，不要發送給 production 的觀眾，也不要覆寫既有資料。 【驗證用 webinar】【既有或新表單的用途】【CTA 顯示秒數】【送出後的標籤】【追蹤腳本】 1. 閱讀 CTA 相關的 migration／DB／API／client、表單 submit 路由、標籤的副作用與腳本觸發條件。 2. 列出既有的 webinar、表單、標籤與腳本，避免重複。製作一張包含目標 ID、目前值與變更後值的表格，然後等待核准。 3. 用 preview=1 確認留言與 CTA 的秒數都大於等於 0、位於影片長度內，並與講解內容一致。只有等候室留言允許負數秒。 4. 表單卡片只能參照既有且啟用中的表單；URL 卡片只能使用 https URL。 5. 自動顯示會擋住收看畫面，所以先只使用一張測試。確認關閉後影片、留言與直播位置都維持原樣。 6. 只用你自己的驗證用 LINE，走一遍「參加 → CTA 顯示 → 點擊 → 表單送出 → 貼標籤 → 腳本」的流程。 7. 確認「參加」、「heartbeat」、「CTA 點擊」、「表單送出」、「轉換」都是獨立的記錄，並確認即使重複送達也不會產生重複資料。
完成確認：多個 CTA 依秒數依序出現／表單在觀看頁面內完成／與標籤和後續追蹤只連動一次／點擊與轉換分開測量。
補充講義：內部資料結構就是這麼簡單
看起來我們在做很複雜的事，但資料表其實很單純。研討會本體有指定秒數的留言與 CTA，並掛著好友的預約／觀看紀錄。
自動研討會資料結構
我想讓你帶走的一個小技巧：如果把留言的秒數設成負數，它就會變成「開場前在等候室裡流動的留言」。 我很喜歡這個設計，因為不用新增 migration，就能營造出等候室的熱鬧感。
所有數字都會被記錄並串連起來。
第 6 章：用數字改善參與率、流失率與 CTA
因為「參加場次、每 30 秒的觀看位置、CTA 點擊、表單送出」都會針對每位觀看者記錄為獨立事件，所以漏斗會串連成一條線。
再次用整整一天的實際數據來看：點擊 330 → 預約 166（50%）→ 觀看 146 → CTA 點擊 66（45%）→ 諮詢名單 14。 名單會根據表單回答（年營收、預算、開始時間）自動篩選並排序，所以你只要從最上面依序回覆就好。
我對自己訂下的分析規則：
- 觀看位置是「每 30 秒最後確認到的位置」，並非實際中離的瞬間。通話中斷、把 App 切到背景等情況也會混在裡面。請在知道這點的前提下閱讀。
- 不要因為人數很少的單一場次就下結論。要把場次之間的差異，對應到影片的哪個段落來比對。
- 改善要一次只改一個變數。改了開頭，就不要動 CTA 的秒數，在接下來的多個場次中比較。
- 不要只追求 CTR。就算你把氣氛炒熱、讓人家點下去，如果表單內容很空洞就沒有意義。最終要以名單的品質來判斷。
貼給 AI 的提示詞：
以唯讀模式分析這個自動研討會的成效，並只提出一個下次要嘗試的改善項目。彙整結果中不要輸出個人姓名或回答內容。 【目標研討會】【目標期間／場次】【最終 CV 的定義】 1. 閱讀觀看、預約、CTA、表單的 analytics API 與 DB 實作。 2. 針對每個場次，彙整預約數、已通知數、參加數、平均／中位數最終位置、25/50/75/90% 到達率、CTA 點擊、表單送出、CV。 3. 區分預覽、管理測試、異常短連線、同一人的重複進入。 4. 請注意：heartbeat 是每 30 秒最後確認到的位置，並非實際中離的秒數。 5. 將每 10 分鐘間隔的主要流失點，對應到影片章節、留言、CTA 顯示秒數。 6. 顯示「問題／依據／下次只改一項的內容／成功條件／要觀察的場次數」。
完成確認：用「好友 × 場次」避免重複／已檢視從預約到 CV 的漏斗／已明確說明 heartbeat 的限制／一次只改變一個變數。
順帶一提，你現在就可以進入這個漏斗。點這裡實際體驗👇
https://line.the-harness.com/x-autowebinar
在發布之前，先設計好怎麼停止它。
第 7 章：正式發布前的測試，與停止方式的設計
這是大部分人會跳過的部分，也是最多意外發生的地方。
發布前的測試，最快就是「用自己的 LINE，把購買流程從頭到尾走一遍」。預約 → 報名確認 → 等候室 → 5 分鐘前通知 → 觀看 → CTA → 表單 → 標籤 → 後續追蹤，全部自己走過一次。Build 通過和流程通過是兩回事。
更換影片時也有陷阱。不要覆寫在同一個位置。 觀看者端長時間快取的舊片段會和新 playlist 混在一起，導致影片壞掉。請放到帶有新版本名稱的資料夾，切換參照，並保留舊版本一段時間，以便隨時可以還原。
緊急停止的關鍵全在順序：
- 停止入口（把研討會改回草稿）
- 停止自動處理（提醒、後續追蹤）
- 發布引導說明
- 刪除資料放最後——如果先刪 R2，正在觀看的人的畫面會在那個瞬間掛掉。
貼給 AI 的提示詞（發布判定）：
在不修改程式碼的前提下，判斷這個自動研討會可否發布到正式環境（GO／NO-GO）。 1. 確認 repo／branch／commit、未儲存的 diff、已套用的 D1 migration、Worker 部署、R2 bucket／prefix、研討會狀態。不要顯示機密值。 2. 針對行程、token、路由、素材、預約、提醒、CTA、DB，執行相關測試、typecheck 和 build。 3. 確認 master／variant、開頭／中間／結尾片段、長度、音訊、畫質、Content-Type、簽章有效期限，以及路徑穿越（path traversal）是否被拒絕。 4. 用你其中一個驗證用的 LINE，完整走過：場次選擇 → 預約確認 → 等候室 → 5 分鐘前通知 → 開始 → 中途參加／重新載入 → CTA → 表單 → 標籤 → 情境 → 數據分析。 5. 在 iPhone 的 LINE／Safari、Android 的 LINE、PC 的 Chrome 上，確認自動播放限制、音訊開啟、背景回復、結束畫面。 6. 確認 Cron 重複執行、LINE 傳送失敗、token 過期、R2 物件不存在、表單失敗。 7. 確認所有 LINE 傳送都有紀錄。 8. 更換影片時，計畫使用帶版本號的新 R2 prefix，並保留舊 prefix 以便 rollback。 9. 顯示停止程序（入口 → Cron → 引導 → 最後才刪除）。 10. 將 commit、測試證據、成本、監控、rollback、未解決風險彙整成一張表；只要有一項重大的未確認項目，就判定為 NO-GO。正式環境的變更需要等我明確核准。
最後，我把實際在用的 GO／NO-GO 判斷標準原封不動地留在這裡。只要有一項沒確認，就不要發布：
- 正在使用的 commit、未儲存的 diff、已套用的 migration 是否都已確認？
- 是否已在實機上確認 HLS 的開頭、中間、結尾，以及音訊和畫質切換？
- 是否已在 iPhone 的 LINE 內建瀏覽器中確認中途參加、重新載入、背景回復？
- 是否已確認預約確認和 5 分鐘前通知只送達你一個人、只送一次，而且都有紀錄？
- 是否已將 CTA、表單、標籤、情境、CV 各自對應為獨立事件？
- 是否能說明停止程序、更換程序和 rollback？
我連一行程式碼都沒寫
到目前為止的所有機制，都是我靠著和 AI 對話做出來的。只要一句「iPhone 上沒辦法從中間開始播」，它就改成 EXT-X-START 的方式；再說一句「拿下 AirPods 後就和留言對不上了」，它就變成「直播中沒有暫停」的規則。把我注意到的事情說出口，幾分鐘後就會反映到正式環境。開發與其說是「下指令」，不如說是一場「對話」。
我在每一章放上的提示詞，就是我在那些「對話」中實際使用的工作指示。基礎架構 LINE Harness 是開源的，所以任何人都能用自己擁有的 LINE 官方帳號，做到一模一樣的事。
你可以直接進入實際 Demo
與其解釋，不如直接看 Demo。從下面的連結加入好友後，引導訊息就會送到 LINE，你可以選擇要參加的場次。點這裡實際體驗👇
https://line.the-harness.com/x-autowebinar
順帶一提，你從這篇文章進來後選了哪個場次、看了幾分鐘、有沒有進到表單——這些全部都會被自動記錄。這就是這套系統。
