工作清單

AI 改壞了只能整個重做？不用｜非技術人員 Vibe Coding 必學的 GitHub

逐字稿文字預覽

你的電腦裡有沒有這種檔案：
提案_最終版、提案_最終版2、
提案_這版才對。
如果有，那你其實已經在做版本控制了。
只是用的是最痛苦的做法：
靠檔名，靠記憶，靠運氣。
工程師二十年前就受不了了，
做了一套工具解決它：那套工具叫
Git，存放的地方叫 GitHub。
GitHub 你可能點進去過一次，
然後就關掉了，因為
那看起來是工程師的地方。
但如果你最近開始用 AI
幫你做東西，那個地方遲早會變成你的。
不是因為你要變成工程師，是因為 AI
一次改的東西比你多得多，你需要一個地方
，讓你做壞了回得去。
這支影片用一條線串起來，
從你做出第一個東西，到你同時開兩個
AI 幫你做事。
每個名詞出現之前，
我會先讓你遇到那個問題。
而且每一個動作我都會多講一句：
做完之後，你怎麼確認它真的做到了。
因為這一年我自己踩過三次，
每一次都是它做的事情，
跟我以為它在做的事情，中間差了一層。
我們直接開始。
如果你還不認識我，我是 Gucci。
我曾經是全球前三大記憶體廠的大數據
工程師，2019 年放棄年薪近兩百萬，
全職創業。
去年，我的線上事業收入 440 萬。
一年多前，我帶著老婆和剛滿 3
歲的女兒開始旅居世界——不是度假，
我照常工作，女兒照常上學，
世界就是她的課本。
從峇里島、清邁到檳城，支撐這種日子的，
就是槓桿 AI：
用更少的工時，把生活還給家人。
好，回到今天的主題。
假設你請 AI 幫你做一個東西。
一頁網站也好，一個會自己跑的小工具也好
，或是一份自動整理資料的表格。
過了半小時，它做出來了，打得開。
第一個問題馬上來了：這東西現在在哪裡？
它在你的電腦裡，某個資料夾。
這代表三件事：換一台電腦你就沒有它了、
電腦壞了它跟著沒了、
想給朋友看你只能整包壓縮寄過去。
所以你需要一個雲端的地方。
你可能會想，那用
Google Drive 不就好了？
不行。
而原因就是這支影片的第一個重點。
還記得開頭那幾個檔名嗎？
你為什麼要留那些版本？
不是因為你愛整理檔案，
是因為你知道會有一刻，
你想回到昨天那個版本。
程式比報告更需要這件事，
因為改壞的機會高太多了。
所以放程式的那個地方，
不能只是把檔案收好，
它還要記得每一次改了什麼、為什麼改。
Google Drive
只做前面那半。
做後面那半的，是今天的第一個名詞：
Git。
Git 是一個裝在你電腦裡的程式。
它只管一件事：你每存一次，
它就記下這一刻整個資料夾長什麼樣子，
還有你留給自己的一句話。
它從頭到尾都在你的機器上跑，
沒有網路也能用。
而 GitHub 是網路上的一個網站，
專門放這種有版本紀錄的資料夾。
這兩個名字只差三個字母，是兩個東西。
一個在你電腦裡管紀錄，
一個在網路上管存放跟給人看。
怎麼開始？
你不用學指令。
不過下面每一句話，
都要說給能直接動你電腦檔案的 AI
聽，像 Codex 這種。
貼進一般聊天視窗，它只會教你怎麼做，
不會真的去做。
幫我把這個資料夾建立版本紀錄，
之後我要放到 GitHub 上。
做完怎麼確認？
請 AI 檢查這個
資料夾有沒有開始記版本，
並把它查到的結果貼給你看。
不要特地去找那個叫 .git
的資料夾，它預設是藏起來的，
看不到很正常。
Git 裝好了，但它不會自己動。
你請 AI 加一個新功能，
它動了七八個檔案。
跑起來，壞了。
這時候的問題不是「壞了」。
壞掉可以修。
真正的問題是你不知道它剛剛動了哪幾個
地方，也不知道要退回到哪裡才是好的。
你連「半小時前」在哪都指不出來。
所以在事情還正常的時候，
你要先留一個回得去的點。
這個動作叫 commit。
一次 commit 就是一個點。
它記下這一刻你整個專案長什麼樣子，
加上你自己寫的一句話：
「第一版做好了」。
之後不管 AI 怎麼改，
你都指得回這個點。
所以當 AI 問你「要不要
commit」，
它在問的是：現在這個狀態，
值不值得留一個回得去的點？
判準很簡單：只要
接下來那件事你不確定會不會壞，就先留。
要請 AI 動一個你不熟的地方，先留。
要一次改很多檔案，先留。
改完覺得可以了，再留一個。
你不用記指令，只要會講這句話：
這一版是好的，先幫我留一個紀錄點，
說明寫「第一版做好了」。
做完怎麼確認？
這裡有第一個陷阱，而且它最不起眼。
你留的這些點，全部
都還在你自己這台電腦上。
回到開頭那些檔名。
你存了好幾個版本，每一版你都找得到。
可是對方一份都還沒收到。
你只是在自己桌上把東西整理好，
你沒有把它交出去。
commit 就是這樣。
它不是上傳。
這台電腦壞掉，那些點會跟著一起消失。
所以確認的方式是問它：
「這些改動現在只在我的電腦上，
還是已經上去了？
」那另一半怎麼辦？
把你電腦上記好的那些點，送到
GitHub 去，這個動作叫
push。
送上去之後你就有了三樣東西：
一份雲端備份、一個可以給人看的網址、
還有一份不會因為電腦壞掉而消失的完整
歷史。
到這裡都很順。
但這一段的重點在下一句：
有些東西不能跟著送上去。
你請 AI 串一個服務，
它可能會需要一組金鑰。
那組金鑰就像你家大門的鑰匙，
誰拿到誰就能用你的帳號、花你的錢。
問題是那組金鑰通常就寫在專案的某個檔案
裡。 你 push 的時候，
如果沒有特別交代，它會一起上去。
而 GitHub 上的東西是有紀錄的。
你把它刪掉，紀錄裡還留著。
有人專門在掃這種東西，
而且掃得比你想像中快。
所以這裡要做一件事：告訴 Git
哪些檔案不要記帳、不要上傳。
那份清單叫 .gitignore。
你可以直接這樣講：
幫我檢查一遍：這個專案裡有沒有金鑰、
密碼這類不該公開的東西？
有的話幫我設成不要上傳。
做完怎麼確認？
打開 GitHub
上你那個專案的頁面，
用眼睛看一遍檔案清單。
這一段值得你親眼看，因為金鑰一旦公開，
光把檔案刪掉也收不回來。
而且如果你發現它真的上去了，
正確的做法不是把紀錄刪掉，
是立刻去把那把金鑰換掉。
紀錄可以整理，但
外流的那幾分鐘裡誰複製走了，
你不會知道。
東西上去了，但它還不是「正式版本」。
GitHub 上
通常有一份大家公認的正本。
你送上去的是你自己那一份。
要讓你的改動變成正本的一部分，
得先提出來，讓人看過，才會被收進去。
這個「提出來」叫 PR。
收進去的那一下叫 merge。
一個人做專案的時候，這一段常常會被跳過
，AI 也可能直接幫你合併。
但只要有第二個人、或第二個 AI
參與，這一段就是
你唯一看得到「誰改了什麼」的地方。
做完怎麼確認？
這是我踩過最尷尬的一次。
我們自己的專案裡有一支編號 708
的提案。
它被收進去了，正式結案。
結案之後，同一天晚上，
我又往同一個地方推了幾次。
每一次都成功，沒有錯誤訊息，沒有警告，
什麼都沒有。
然後我回報：推上 708 了。
那支提案早就關閉了。
後面那幾次不屬於任何一個提案，
永遠不會進到正本裡面。
推送本來就會成功，
因為它只負責把東西送到 GitHub，
不負責判斷「你送的地方還收不收」。
而 AI 也不會提醒你，
它照著你說的做，做完回你成功，
因為對它來說那確實成功了。
所以確認的方式是多問一句：
這個提案還開著嗎？
幫我確認我剛剛推上去的那個 PR
現在是什麼狀態。
如果已經 merge
了，那我後來推的東西是不是還在外面。
到目前為止都是你一個人。
很多人在這裡誤會，
是因為AI回報「已commit」的時候
，那個語氣聽起來就像事情辦完了。
它辦完的是一半：在你這裡辦完了。
所以整條路是四段，
你記這四段就好：在你電腦上留點，
送到GitHub，提出來，被收進去。
只有最後一段完成，
你的改動才算是正式版本的一部分。
前面三段做完，東西都還在旁邊等。
這件事的重點是：
這個系統在那個情況下不會提醒任何人。
你不用會判斷，你只要會問。
現在假設有第二個人要加進來。
他要先把東西拿到自己電腦上，
而這件事有兩個名字，差別只在第幾次。
第一次整包拿走，叫 clone。
之後每次拿別人的新進度，叫 pull。
這裡有個很多人會踩的地方：
第一次拿的時候，
不要在網頁上按「下載」。
下載拿到的是一包死檔案，
沒有紀錄、沒有歷史，改完也送不回去。
clone 拿到
的才是連同整本紀錄的完整專案。
合作的循環就是四步：拉下來、改、留點、
送上去。
現在，那個「別人」常常不是人，
而是另一個 AI。
而 AI 不會跟
你說一聲它拉了什麼、改了什麼。
然後就會遇到最麻煩的那一種：
兩邊改到同一個地方。
Git 這時候會停下來，跳出
conflict，中文叫衝突。
意思很直白：同一段
內容出現了兩個不同的版本，
它不知道該聽誰的，所以它不猜，它問你。
現在的 AI 遇到衝突通常會自己處理。
它會看懂兩邊各自想做什麼，
然後幫你合：有時候是二選一，
有時候是兩邊都留，
有時候是乾脆重寫一段把兩邊的功能接
起來。
做完怎麼確認？
這裡是我覺得最值得你記住的一件事。
AI 卡住的時候其實很安全，
因為它會停下來問你。
危險的是它沒有卡住。
它沒有你的產品規劃，它只看得到程式碼。
所以它可能很順地選了一邊，
而那一邊剛好是你不要的，
然後回你一句「衝突已解決」。
畫面上什麼警告都沒有。
所以合併完之後，
你要問的不是「解決了嗎」，是：
這次衝突你是怎麼解的？
兩邊各自原本想做什麼，
你留了哪一邊、為什麼？
重點不是它答不答得出來，是它講的那兩邊
，你自己各試一次。
少了一邊，就叫它重做。
接下來會發生一件很自然的事：
你會想同時開兩個。
一個在幫你改版面，你在旁邊等，
你會想那我為什麼不順便開另一個去處理
別的。
問題在於，這兩個
視窗會直接改同一個資料夾，而
Git 不會攔。
剛剛那個衝突警告，
只在合併兩份紀錄時才會出現。
同一份東西，兩個人同時在上面動手，
這件事你在辦公室裡見過。
兩個人各自打開同一份共用檔案，各自改，
各自存。
最後存的那個人，
蓋掉前一個人的所有修改。
而前一個人不會收到通知，
他要到很久以後才會發現自己那半天不見
了。 在專案裡一樣，只是更難察覺，
因為兩邊都是 AI，
它們不會抬頭跟你說一聲。
這時候 AI 可能
會問你要不要開一個分支。
分支的意思是「跟正本隔開來做」，
改壞了整條丟掉就好。
那是好東西，但它解決不了現在這個問題。
因為分支再多，你
電腦上那個資料夾還是只有一個，兩個
AI 還是站在同一張桌子前面。
真正解決這件事的做法只有一個：給第二個
AI 第二個資料夾。
這個做法叫 worktree。
它在你硬碟上多開一個資料夾，
裝的是同一個專案，
但跟原本那個各自獨立。
一個 AI 待一個，互不干擾。
做完怎麼確認？
分別問這兩個 AI：
你現在在哪個資料夾？
兩個答案不一樣，才是真的分開了。
沒做到的時候會發生什麼，
我們是用最貴的方式知道的。
有一次，我們有兩個 AI
同時在做事，而它們沒有各自的資料夾，
用的是同一個。
其中一個想看「原本的版本長什麼樣」，
就下了兩道指令。
這兩道指令，一個
人單獨工作的時候完全正常。
你不用會下這兩道指令，
你只要知道它們做了什麼：把桌面收乾淨，
然後把資料夾換成另一個版本。
但那天不是一個人在工作。
那兩道指令的作用範圍，涵蓋了另一個
AI還沒有存好的東西。
大約五百七十行被掃掉了，是另一個 AI
還沒留下紀錄的工作。
而它不會報錯。
指令成功執行，畫面上什麼都沒有。
要等到另一邊回頭找自己的東西，
才會發現。
如果那個人是你，
你的第一個念頭會是自己記錯了。
所以這一段你要帶走的只有一句：
不要讓兩個 AI
在同一個資料夾裡動手。
我要同時開兩個來做不同的事，
幫我各開一個獨立的工作資料夾，
不要讓它們共用同一個。
最後講你每天都在怕的那一刻：AI
真的把東西改壞了。
分兩種情況，而且分法只有一個問題：
你有沒有留過點。
第一種，你還沒留點。
AI 剛剛改了一堆檔案，
你跑起來完全不對。
這時候的動作叫 restore，
意思是把這些還沒留過點的改動全部丟掉，
回到上一個點。
就當剛剛那半小時沒發生過。
第二種，你已經留過點了，
而且是那個點本身有問題。
這時候比較安全的做法叫 revert。
它不是把歷史刪掉，是再記一筆，
內容是把前面那筆抵消掉。
為什麼要繞這一圈？
因為直接刪掉歷史的話，
跟你一起做的人手上版本會對不上，
而且他不會知道發生過什麼。
多記一筆抵消，所有人都看得到「加錯了、
然後被抵消了」。
這兩個你都不用記，你只要說：
剛剛這次的改動我不要了，
請幫我回到上一個正常的版本。
AI 會自己看現在的狀態，
決定該用哪一個。
做完怎麼確認？
這裡有兩件事是我覺得沒有人會先告訴你
的。 第一，restore 是不可逆的。
它丟掉的東西沒有回收桶。
不像刪檔案還能去垃圾桶撿，
那些改動是真的消失了，Git
裡面任何地方都找不到，
因為它們從來沒有被記下來過。
剛剛那五百七十行其實不是這一種。
那次是被暫時收起來，
還找得回來；restore
丟掉的才是真的沒有回收桶。
但兩次的傷害是同一種：
做那件事的不是壞掉的程式，
是收東西的動作本身，
而你不會知道要去哪裡找。
所以在說「回到上一個正常版本」之前，
值得多問一句：
這個動作會丟掉哪些還沒記錄的改動？
先列給我看。
第二件是他們很少講的第三種情況：
東西已經送出去了。
這時候光救你自己的電腦沒有用，要連
GitHub 上那一份一起處理。
你問 AI 的時候要把這件事講出來：
「這批改動我已經推上去了，
也要一起處理。
」所以這一章的判準是：
在說「回到上一個版本」之前，
先問它會丟掉什麼。
救回來之後還有最後一件事，
而且跟前面幾章不一樣：
前面都是事情沒到，這次是事情做到了，
但份量不對。
這是我踩過最容易被騙的一次。
有一次我叫 AI 算給我看它改了多少。
它回我：刪掉兩千六百二十一行。
兩千六百多行。
而我心裡預期的是幾十行。
我們當時真的停下來查了。
實際上那次刪掉的是三十行。
比對兩個版本有兩種算法。
一種是拿兩邊現在的樣子直接比。
另一種是先回到你們還一樣的時候，
再從那裡往後算你改了什麼。
當你這一份比正本少了幾次更新，
第一種算法會把別人後來加進去的東西，
全部算成你刪掉的。
你手上沒有，於是它就被記成你刪的。
而你看不出來。
兩個數字長得一模一樣，都是「刪掉 N
行」，沒有任何東西告訴你這兩個 N
的意思不同。
判準是最好記的一個：不要自

來源：transcript.txt

本次執行流程與問題處理

  1. 下達指令

    指令：videonote https://www.youtube.com/watch?v=tktHAs17V8Q --language zh --adopt-source-subtitles

    來源：https://www.youtube.com/watch?v=tktHAs17V8Q

    辨識語言：zh ｜ 參數：--language zh --adopt-source-subtitles

  2. 預期流程

    依指令產生的處理順序：

    1. 採用來源字幕（略過語音辨識）
    2. 來源選擇與品質檢查
    3. 文字校正與句子單元
    4. 筆記與發布
    5. 公開網頁發布

  3. 1. 下載與語音辨識

    工具：videonote-transcribe-url（主辨識管線：下載、Whisper 辨識與選稿）

    處理：下載音訊、以 Whisper 辨識並選出最佳逐字稿

    產出：yt_dlp_meta.json（影片元資料）、audio_16k_mono.wav（16kHz 單聲道音訊）、transcript.whisper.json（Whisper 辨識結果）、transcript.json（正式逐字稿）、transcript_selection_report.json（來源選擇報告）

    耗時：3.7 秒

    關係：依序執行

    結果：完成

  4. 2. 全文快速校讀

    工具：videonote_rapid_transcript_review.py

    處理：先速讀完整逐字稿，再修正高可信突兀詞句並列出待確認項目

    產出：rapid_transcript_review_report.json（產出檔案）

    耗時：52.7 秒

    關係：依序執行

    結果：完成

  5. 3. 建立句子單元

    工具：videonote-build-sentence-units

    處理：將逐字稿切成帶時間軸的句子單元

    產出：sentence_units.json（句子單元）

    耗時：0.8 秒

    關係：依序執行

    結果：完成

  6. 4. 時間軸稽核

    工具：videonote_timeline_audit.py

    處理：檢查時間軸與音訊對齊

    產出：timeline_audit_report.json（時間軸稽核）

    耗時：0.8 秒

    關係：依序執行

    結果：完成

  7. 5. 品質檢查

    工具：videonote_controlled_quality.py（檢查時間軸與品質）

    處理：檢查語言、時間軸與可讀性品質

    產出：controlled_quality_report.json（品質報告）、language_sanity_report.json（語言檢查）

    耗時：0.9 秒

    關係：依序執行

    結果：完成

  8. 6. 播放時間軸回填

    工具：videonote_rebase_display_timeline.py

    處理：將網頁播放時間軸回填為校正字幕時間

    產出：display_timeline_rebase_report.json（時間軸回填報告）

    耗時：0.9 秒

    關係：依序執行

    結果：完成

  9. 7. 來源句整理

    工具：videonote_prepare_source_entries.py

    處理：整理來源句子供時間軸與頁面使用

    產出：sentence_units.json（句子單元）

    耗時：0.9 秒

    關係：依序執行

    結果：完成

  10. 8. 生成筆記摘要

    工具：videonote-generate-note（生成筆記摘要）

    處理：生成筆記摘要與重點

    產出：note.md（筆記 Markdown）、note.html（筆記 HTML）

    耗時：112.0 秒

    關係：依序執行

    結果：完成

  11. 9. 建立筆記頁面

    工具：videonote-render-html（產生筆記 HTML）

    處理：產生可閱讀的筆記 HTML 頁面

    產出：note.html（筆記 HTML）

    耗時：1.1 秒

    關係：依序執行

    結果：完成

  12. 10. 發布公開頁面

    工具：videonote-publish（發布公開頁面）

    處理：發布到公開網站與每日列表

    產出：公開筆記網址、result.json（管線結果）

    耗時：0.2 秒

    關係：依序執行

    結果：完成

手動來源字幕

自動來源字幕

Whisper 字幕

Qwen 字幕

Parakeet 字幕

MOSS 字幕

聲學時間證據（PyAnnote / WhisperX）

校正前後逐字稿

目前待解決問題與初步改善方向

進一步精進字幕與筆記
使用 Workbench 上傳校正字幕、中文參考稿或回饋 SRT，重新產生雙語與學習單元。
開啟 Workbench