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


<!-- VIDEONOTE_PUBLICATION_WARNINGS_BEGIN -->
## ⚠️ 可先使用，仍有待修正項目

本筆記已完成可閱讀的逐字稿與時間跳轉；下列為待處理問題，建議播放原片確認。

- 待修正：逐字稿全文快速校讀未完成（已保留自動字幕/原始逐字稿並繼續生成筆記。；未完成的全文速讀項目可在精進模式回聽確認。）
- 待修正：逐字稿可先使用，但有待校正清單（segment=1 unnatural_sentence_boundary: 標點出現在句首或停在逗號位置，斷句可能不符合文法/口語；segment=6 unnatural_sentence_boundary: 標點出現在句首或停在逗號位置，斷句可能不符合文法/口語）

<!-- VIDEONOTE_PUBLICATION_WARNINGS_END -->

## 一句話總結
非工程師使用者應利用 **Git** 與 **GitHub** 建立版本控制系統，透過「本地提交、雲端推送、提出請求、合併」四個階段的確認機制，來管理 AI 快速修改帶來的風險，確保在出錯時能安全回退並驗證結果。

## 核心重點
1.  **版本控制的必要性**：AI 修改速度快且易出錯，依賴檔名（如 `_最終版`）管理效率低且痛苦；需要一個能「回退」且能「檢視歷史」的系統。
2.  **Git 與 GitHub 的分工**：
    *   **Git**：本地工具，負責記錄每一次存檔時的資料夾狀態及備註，離線可用。
    *   **GitHub**：雲端平台，負責存放有版本紀錄的資料夾，提供雲端備份、公開網址及完整歷史。
3.  **四個階段的確認動作**：
    *   **Commit (本地提交)**：建立本地回退點，確認 `.git` 資料夾存在。
    *   **Push (雲端推送)**：上傳至 GitHub，確認金鑰未透過 `.gitignore` 外洩。
    *   **PR (提出請求)**：供檢視後合併，確認提案狀態為「開啟」。
    *   **Merge (合併)**：正式納入正本，確認衝突處理正確。
4.  **安全與衝突管理**：
    *   使用 `.gitignore` 隱藏金鑰、密碼等敏感資訊。
    *   多個 AI 同時工作時，使用 `worktree` 建立獨立資料夾以避免覆蓋衝突。
    *   AI 處理衝突時可能選錯方向，需親自測試。
5.  **修復與驗證**：
    *   **Restore**：丟棄未記錄的改動（不可逆）。
    *   **Revert**：抵消已記錄的錯誤（保留歷史）。
    *   **驗證標準**：以 GitHub PR 頁面顯示的行數統計為權威，而非 AI 自行計算的結果。

## 詳細大綱

### 一、 為什麼需要版本控制？
*   **現狀問題**：一般使用者靠檔名（如 `_最終版`、`_最終版2`、`_這版才對`）管理版本，效率低且痛苦。
*   **AI 的特性**：AI 一次修改的內容多，出錯機率高，需要一個「做壞了可以回得去」的地方。
*   **雲端 vs 本地**：僅存在電腦本地會面臨換機、壞機、無法分享的風險；需要雲端備份與歷史紀錄。

### 二、 核心工具與概念定義
*   **Git**：安裝在電腦內的程式，負責記錄每一次存檔時的資料夾狀態及備註。離線可用。
*   **GitHub**：網路網站，專門存放有版本紀錄的資料夾，提供雲端備份、公開網址及完整歷史。
*   **兩者關係**：Git 管紀錄（本地），GitHub 管存放與展示（雲端）。
*   **Google Drive**：被指出不適合存放程式碼的原因，僅備份檔案，無版本歷史。

### 三、 版本控制的四個階段與確認動作

#### 階段 1：本地提交 (Commit)
*   **定義**：在電腦上建立一個「回得去的點」，記錄當前專案狀態與備註。
*   **時機**：不確定是否會壞、修改不熟的地方、一次改很多檔案、改完覺得可以時。
*   **確認動作**：
    *   檢查資料夾是否開始記版本。
    *   確認 `.git` 資料夾存在（預設隱藏）。
    *   **關鍵認知**：Commit 僅存在本地電腦，未上傳前，電腦壞掉則紀錄消失。

#### 階段 2：雲端推送 (Push)
*   **定義**：將本地的 Commit 紀錄上傳至 GitHub。
*   **風險管理 (.gitignore)**：
    *   金鑰、密碼等敏感資訊若寫在專案檔案中，Push 時會一併上傳。
    *   GitHub 刪除紀錄後仍留有痕跡，可能被掃描。
    *   **做法**：建立 `.gitignore` 清單，指定不記帳、不上傳的檔案。
*   **確認動作**：
    *   檢查 GitHub 專案頁面的檔案清單，確認金鑰未公開。
    *   若金鑰已外流，應「換掉金鑰」而非僅刪除檔案。

#### 階段 3：提出請求 (PR - Pull Request)
*   **定義**：將自己的改動提出來，供他人檢視後再收進正本。
*   **合併 (Merge)**：正式將改動納入正本。
*   **常見誤區**：
    *   推送成功不代表提案被接收。若提案已關閉，後續推送不會進入正本。
    *   AI 回報成功僅代表技術上送達，不保證邏輯上被接收。
*   **確認動作**：
    *   確認提案是否仍為「開啟」狀態。
    *   確認 PR 狀態，檢查後續推送是否因提案關閉而未進入正本。

#### 階段 4：協作與衝突處理
*   **Clone vs Pull**：
    *   **Clone**：第一次整包下載，包含完整歷史紀錄。
    *   **Pull**：之後每次拉取別人的新進度。
    *   **警告**：不要在網頁按「下載」，那會得到無歷史的死檔案。
*   **衝突 (Conflict)**：
    *   當兩邊修改同一處時發生。
    *   AI 通常會自動處理衝突（二選一、保留兩邊或重寫）。
    *   **危險點**：AI 可能選錯方向且無警告。
    *   **確認動作**：詢問 AI 如何解決衝突，並親自測試兩邊版本。
*   **多 AI 同時工作**：
    *   **問題**：多個 AI 視窗修改同一個資料夾，後存者會覆蓋前者，且無通知。
    *   **解決方案 (Worktree)**：為第二個 AI 開啟獨立的資料夾（Worktree），讓兩者互不干擾。
    *   **確認動作**：分別詢問兩個 AI 所在的資料夾路徑，確保不同。

### 四、 錯誤修復與驗證
*   **修復類型**：
    1.  **Restore**：丟棄尚未留點（Commit）的改動，回到上一個點。
        *   **特性**：不可逆，無回收桶。
        *   **確認**：詢問會丟掉哪些未記錄的改動。
    2.  **Revert**：針對已留點但有問題的版本，新增一筆紀錄來抵消錯誤。
        *   **特性**：保留歷史，讓協作者看到「加錯」與「抵消」。
*   **行數統計驗證**：
    *   AI 計算的行數可能因算法不同（直接比對 vs 回到共同祖先計算）而與預期不符。
    *   **權威標準**：以 GitHub 在 PR 頁面顯示的新增/刪除行數為準。
    *   **確認**：比對 GitHub 顯示的份量與預期是否成比例。
    *   **案例**：講者舉例中，AI 回報刪除「兩千六百二十一行」，實際比對後僅刪除「三十行」，而誤刪了「五百七十行」。

## 工具 / 模型 / 名詞整理
*   **Git**：本地版本控制系統，用於記錄專案歷史。
*   **GitHub**：雲端程式碼託管平台，用於備份與協作。
*   **Codex**：逐字稿中提到「像 Codex 這種」，指代能直接操作電腦檔案的 AI 模型類型。
*   **Google Drive**：僅備份檔案，無版本歷史，不適合存放程式碼。
*   **.gitignore**：用於指定不記帳、不上傳的檔案清單（如金鑰、密碼）。
*   **Worktree**：Git 功能，用於為第二個 AI 開啟獨立的資料夾，讓多個 AI 互不干擾。
*   **Commit**：本地提交，建立回退點。
*   **Push**：雲端推送，將本地紀錄上傳至 GitHub。
*   **PR (Pull Request)**：提出請求，供檢視後合併。
*   **Clone**：第一次整包下載，包含完整歷史紀錄。
*   **Pull**：之後每次拉取別人的新進度。
*   **Restore**：丟棄尚未留點的改動。
*   **Revert**：抵消已記錄的錯誤。
*   **Gucci**：影片講者。
*   **guccidgi.com/aifree**：逐字稿中的社群連結網址。

## 操作流程整理
1.  **初始化與設定**：
    *   安裝 Git。
    *   建立 `.gitignore` 檔案，將金鑰、密碼等敏感資訊列入清單。
2.  **本地開發與提交 (Commit)**：
    *   進行程式碼修改。
    *   在關鍵節點執行 `Commit`，記錄當前狀態與備註。
    *   **確認**：檢查 `.git` 資料夾是否存在。
3.  **雲端同步 (Push)**：
    *   將本地 Commit 上傳至 GitHub。
    *   **確認**：檢查 GitHub 專案頁面，確認金鑰未公開。若已外流，立即換掉金鑰。
4.  **提出請求與合併 (PR & Merge)**：
    *   建立 Pull Request (PR)。
    *   **確認**：確保 PR 狀態為「開啟」。
    *   處理衝突（若發生）。
    *   合併 (Merge) 至正本。
5.  **多 AI 協作管理**：
    *   若有多個 AI 視窗工作，使用 `Worktree` 為每個 AI 分配獨立資料夾。
    *   **確認**：分別確認各 AI 操作的資料夾路徑不同。
6.  **錯誤修復與驗證**：
    *   若需丟棄未記錄的改動，使用 `Restore`。
    *   若需抵消已記錄的錯誤，使用 `Revert`。
    *   **驗證**：以 GitHub PR 頁面顯示的行數統計為最終驗證標準，比對實際變更量。

## 值得注意的限制或風險
1.  **金鑰外洩風險**：即使從 GitHub 刪除檔案，歷史紀錄中仍可能留有痕跡，需定期換掉金鑰。
2.  **AI 衝突處理盲點**：AI 自動處理衝突時可能選錯方向且無警告，使用者需親自測試。
3.  **多 AI 覆蓋風險**：多個 AI 修改同一資料夾，後存者會覆蓋前者且無通知，必須使用 `Worktree` 隔離。
4.  **行數統計誤差**：AI 自行計算的行數可能因算法不同而與 GitHub 顯示的權威數據不符，應以 GitHub 顯示為準。
5.  **本地紀錄丟失**：Commit 僅存在本地，若電腦壞掉且未 Push，紀錄將消失。
6.  **網頁下載陷阱**：在 GitHub 網頁按「下載」會得到無歷史的死檔案，應使用 Clone 或 Pull。

## 逐字稿辨識疑點
*   **segment 1, 6, 9, 16, 17, 20, 24, 25, 30, 34, 35, 37**：標點出現在句首或停在逗號位置，斷句可能不符合文法/口語。
*   **Codex**：逐字稿中提到「像 Codex 這種」，指代能直接操作電腦檔案的 AI。需查證此處是否泛指特定模型或泛指具備此能力的 AI 類別。
*   **提案_最終版、提案_最終版2、提案_這版才對**：逐字稿中的檔案命名範例，保留原樣。
*   **編號 708 的提案**：講者舉例的特定提案編號，保留原樣。
*   **guccidgi.com/aifree**：逐字稿中的社群連結網址，保留原樣。
*   **五百七十行**：講者舉例中被誤刪的行數，保留原樣。
*   **兩千六百二十一行**：AI 回報的刪除行數，保留原樣。
*   **三十行**：實際比對後的刪除行數，保留原樣。
*   **峇里島、清邁、檳城**：講者旅居地點，保留原樣。

## 可延伸追問
1.  對於完全不懂命令列的非技術人員，是否有更直觀的圖形介面工具可以執行上述 Git/GitHub 流程？
2.  `.gitignore` 的具體寫法與常見誤區有哪些？
3.  當 AI 處理衝突時，使用者應如何具體驗證 AI 的選擇是否正確？
4.  Worktree 的實際操作步驟與常見錯誤是什麼？
5.  如何定期檢查 GitHub 歷史紀錄中的金鑰洩漏情況？