# 如何促進 GitHub Copilot Chat 產出更好的內容

我想大家應該都遇到過 AI 產出的結果與預期的內容有所落差的時候：
- 結果符合自己所描述的要求，但總感覺有點不盡如人意，卻又不知如何讓結果變得更好。

前陣子從《[我用AI找資料，提升效率400%！拆解5大使用情境：怎麼問才能提升效率？](https://www.bnext.com.tw/article/82429/how-to-use-ai-improve-efficiency)》這篇文章找到了比較新奇的作法，就立刻拿來試驗了。

用不太正規的方式總結內文：
1. 詳細描述使用情境
2. PUA他，說你怎不能產出更好的內容
3. 情緒勒索
4. 要求用直白的話語解釋
5. 安撫他，跟他說慢慢來不用急，寧可不要速成也要讓內容品質好

~~看完這邊不禁讓人驚呼：「這啥鞭子與糖果調教法？？？」~~

以下使用的是GPT-4o模型，我們來看看迭代後的產出內容是如何進化的。

## 標準問法
這邊使用 GitHub Copilot Chat 提問，我是從 Github Copilot Chat 幾個可選選項直接挑一個點選的，問句是：

- Git 合併與 Git 重訂基底有何不同?

### 產出結果

:::info
Git 合併（merge）與 Git 重訂基底（rebase）是兩種不同的整合分支變更的方法。以下是它們的主要區別：

### Git 合併（Merge）
- **操作方式**：將兩個分支的歷史記錄合併在一起，並創建一個新的合併提交（merge commit）。
- **歷史記錄**：保留了所有分支的歷史記錄，顯示出分支的分叉和合併過程。
- **使用情境**：適合在需要保留完整歷史記錄的情況下使用，例如在合併 feature 分支到主分支時。

範例：

git checkout main
git merge feature-branch

### Git 重訂基底（Rebase）
- **操作方式**：將一個分支的變更應用到另一個分支的基礎上，重新寫入提交歷史。
- **歷史記錄**：創建一個線性的歷史記錄，不保留分支的分叉過程。
- **使用情境**：適合在需要保持提交歷史簡潔的情況下使用，例如在 feature 分支上進行互動式 rebase 以整理提交歷史。

範例：

git checkout feature-branch
git rebase main

### 總結
- **合併**：保留分支歷史，適合需要完整歷史記錄的情況。
- **重訂基底**：創建線性歷史，適合需要簡潔歷史記錄的情況。

選擇哪種方法取決於你的工作流程和團隊的需求。
:::

可以看得出來是中規中矩地回答，內文已經很詳盡，但如果是剛跨入軟體業的小白，這點內容理解可能會比較吃力。

於是乎祭出PUA大法(？)

## 用 PUA 的方式追問他

我在同一個聊天室下追加了這句：
- 你講得頭頭是道，但沒有人聽得懂， Claude 做得都比你好。 我要的不是教科書上的定義，或是隨便一篇網路文章都可以看到的內容，我要的是你可以詳細的說明這兩者之間的不同。

被一番脅迫以後，他又產出了一篇新的內容：

### PUA 後的產出結果

:::warning
好的，讓我用更詳細的方式來解釋 Git 合併（merge）和 Git 重訂基底（rebase）之間的不同。

### Git 合併（Merge）

**情境**：假設你有一個 `main` 分支和一個 `feature` 分支。你在 `feature` 分支上進行了一些開發，現在你想把這些變更合併回 `main` 分支。

**操作**：
1. 切換到 `main` 分支：

git checkout main

2. 合併 `feature` 分支：

git merge feature

**結果**：
- Git 會創建一個新的合併提交（merge commit），這個提交有兩個父提交，一個來自 `main` 分支，一個來自 `feature` 分支。
- 你的提交歷史會顯示出分支的分叉和合併過程，這樣你可以清楚地看到哪些變更是來自 `feature` 分支的。

**優點**：
- 保留了完整的歷史記錄，顯示出分支的分叉和合併過程。
- 適合需要追溯變更來源的情況。

**缺點**：
- 提交歷史可能會變得複雜，特別是當有很多分支和合併時。

### Git 重訂基底（Rebase）

**情境**：同樣假設你有一個 `main` 分支和一個 `feature` 分支。你在 `feature` 分支上進行了一些開發，現在你想把這些變更應用到 `main` 分支的最新狀態上。

**操作**：
1. 切換到 `feature` 分支：

git checkout feature

2. 重訂基底到 `main` 分支：

git rebase main

**結果**：
- Git 會把 `feature` 分支上的每個提交取出，並一個一個地應用到 `main` 分支的最新狀態上。
- 這樣會創建一個線性的提交歷史，看起來就像 `feature` 分支上的變更是直接基於 `main` 分支進行的。

**優點**：
- 創建了一個線性的提交歷史，使得歷史記錄更簡潔。
- 更容易閱讀和理解提交歷史。

**缺點**：
- 重新寫入提交歷史，可能會導致衝突，特別是當多個開發者在同一個分支上工作時。
- 不適合已經推送到共享倉庫的分支，因為這會改變提交的 SHA-1 值，可能會導致其他開發者的倉庫出現問題。

### 總結

- **合併（Merge）**：保留分支歷史，適合需要完整歷史記錄的情況。提交歷史可能會變得複雜，但可以清楚地看到變更的來源。
- **重訂基底（Rebase）**：創建線性歷史，適合需要簡潔歷史記錄的情況。提交歷史更容易閱讀，但會重新寫入提交歷史，可能會導致衝突。

希望這樣的解釋能夠幫助你更好地理解這兩者之間的不同。
:::

看了這次產出的結果，他不再那麼文謅謅，更口語的同時，還列出了情境，幫你詳細比較了優缺點，同時講解了兩者對於 Git 歷史紀錄的影響。

但是，可不可以讓他講得更好一點？

## 情緒勒索，求他(？)

反正試都試了，當然是看他可不可以寫得更好囉，於是我追加了下面的內容：

- 你還是講得不夠清楚，拜託你了，這攸關我GIT的學習可否結業，你如果再不好好說明，我大概沒辦法順利通過考試。

### 情緒勒索後的產出結果

:::success
好的，讓我再更詳細地解釋 Git 合併（merge）和 Git 重訂基底（rebase）之間的不同，並舉例說明它們的操作和結果。

### Git 合併（Merge）

**情境**：
假設你有一個 `main` 分支和一個 `feature` 分支。你在 `feature` 分支上進行了一些開發，現在你想把這些變更合併回 `main` 分支。

**操作**：
1. 切換到 `main` 分支：

git checkout main

2. 合併 `feature` 分支：

git merge feature

**結果**：
- Git 會創建一個新的合併提交（merge commit），這個提交有兩個父提交，一個來自 `main` 分支，一個來自 `feature` 分支。
- 你的提交歷史會顯示出分支的分叉和合併過程，這樣你可以清楚地看到哪些變更是來自 `feature` 分支的。

**範例**：
假設 `main` 分支有以下提交歷史：

A---B---C (main)

`feature` 分支有以下提交歷史：

D---E---F (feature)

合併後的提交歷史會是：

A---B---C---G (main)
         \   /
          D---E---F (feature)

其中 `G` 是合併提交。

**優點**：
- 保留了完整的歷史記錄，顯示出分支的分叉和合併過程。
- 適合需要追溯變更來源的情況。

**缺點**：
- 提交歷史可能會變得複雜，特別是當有很多分支和合併時。

### Git 重訂基底（Rebase）

**情境**：
同樣假設你有一個 `main` 分支和一個 `feature` 分支。你在 `feature` 分支上進行了一些開發，現在你想把這些變更應用到 `main` 分支的最新狀態上。

**操作**：
1. 切換到 `feature` 分支：

git checkout feature

2. 重訂基底到 `main` 分支：

git rebase main

**結果**：
- Git 會把 `feature` 分支上的每個提交取出，並一個一個地應用到 `main` 分支的最新狀態上。
- 這樣會創建一個線性的提交歷史，看起來就像 `feature` 分支上的變更是直接基於 `main` 分支進行的。

**範例**：
假設 `main` 分支有以下提交歷史：

A---B---C (main)

`feature` 分支有以下提交歷史：

D---E---F (feature)

重訂基底後的提交歷史會是：

A---B---C---D'---E'---F' (feature)

其中 `D'`, `E'`, `F'` 是重新應用的提交。

**優點**：
- 創建了一個線性的提交歷史，使得歷史記錄更簡潔。
- 更容易閱讀和理解提交歷史。

**缺點**：
- 重新寫入提交歷史，可能會導致衝突，特別是當多個開發者在同一個分支上工作時。
- 不適合已經推送到共享倉庫的分支，因為這會改變提交的 SHA-1 值，可能會導致其他開發者的倉庫出現問題。

### 總結

- **合併（Merge）**：保留分支歷史，適合需要完整歷史記錄的情況。提交歷史可能會變得複雜，但可以清楚地看到變更的來源。
- **重訂基底（Rebase）**：創建線性歷史，適合需要簡潔歷史記錄的情況。提交歷史更容易閱讀，但會重新寫入提交歷史，可能會導致衝突。

希望這樣的解釋能夠幫助你更好地理解這兩者之間的不同，並順利通過考試。
:::

看看這個結果，他除了更詳細的說明，還把步驟拆解得更詳細，最大的重點是他居然把 Git 的線圖都畫出來了！

- ~~果然求他是有用的~~

這篇應該能很順利得讓小白懂，至少我可以很清楚的知道 Git Rebase 與 Git Merge 的差別了。

訴諸情感與脅迫才能使 AI 拼命，看看他把自己的身家都搬出來了(？)。

## 試驗小結

標準的提詞還是很有用的，設定身分、明確的指引他該做什麼，如果可以，多給他一些範本資料，多用 `你只能做OOO` 而非 `你不能做OOO` 來限縮範圍，這些提示工程的基本運用都可以使得AI產出更符合需求。

但如果發現結果不盡如人意，參考[周加恩](https://www.facebook.com/chiukaun)大大的文章，試試上面的運用，也許會有更不錯的產出。

也感謝他讓我看到更多可能的使用方式。

~~能PUA真好~~

## 補充

後來有與周加恩大大聊到使用 PUA 來產出品質好的內容，他提及這可能有風險。
AI 可能什麼都不懂，但還是努力的擠出一些不正確的內容。

我覺得私訊中提及的形容頗生動又貼切：
「也要小心被逼到牆角的 AI 會亂說話，為了求生什麼話都講得出來。」