Git Commit 訊息產生器

🍽 這道菜在做什麼

每個工程師都幹過這件事：改完程式碼準備提交，卻在 commit message 欄前面卡住，最後隨手打了一句「fix bug」「update」「修一下」就送出去。短期沒事，但半年後當你想追查某個功能是什麼時候、為什麼改成這樣，翻開 git log 看到一整排「update」「wip」「修改」，根本無從查起。糟糕的提交訊息不是當下偷懶，而是把麻煩留給未來的自己和隊友。

這道配方就是替你把「寫 commit message」這件人人都嫌煩、卻又很重要的事自動化。你只要把 git diff 貼給 AI，它會依照業界通用的 Conventional Commits 規範，產出一則結構完整的提交訊息：標題是 type(scope): 簡短描述 的格式（type 用 feat、fix、docs、refactor、test、chore 等），用英文、50 字以內、祈使句寫成；空一行後用條列說明這次改了什麼、為什麼；如果有破壞性變更，會加上 BREAKING CHANGE: 段落；最後附一句繁體中文白話總結，讓你確認無誤再提交。

最需要這道菜的是任何用 Git 的工程師，尤其是開源貢獻者和重視 commit 規範的團隊成員。開源專案的維護者常常要求 PR 遵守 Conventional Commits，格式不對直接被退；而採用語意化版本（semantic versioning）自動發版的專案，根本是靠 commit 的 type 來決定版號要不要進位——feat 進次版號、fix 進修訂號、BREAKING CHANGE 進主版號。寫對格式不只是好看，是會直接影響自動化流程。這道配方把原本要花一兩分鐘糾結、還常常寫不規範的事，壓縮到貼上 diff、看一眼、提交，幾秒鐘搞定。

為什麼這樣設計

別小看一則提交訊息，這道配方背後其實藏著不少巧思。

第一個關鍵是對齊 Conventional Commits 這個業界標準。它不是隨便發明的格式，而是被 Angular、Vue 等大型開源專案廣泛採用、並被一整套自動化工具鏈支援的規範。當你的 commit 遵守它，就能無痛接上自動產生 CHANGELOG、自動計算版號、自動發版這些工具。提示詞把規則寫死成 type(scope): description，等於讓 AI 替你守住這道格式門檻，再也不會因為格式不符被 CI 或維護者退件。

第二個關鍵是標題與內文分工。規範要求標題 50 字以內、祈使句、講「做了什麼」，內文則用條列補上「為什麼這樣改」。這個設計呼應了 Git 工具的實際運作——git log --oneline 只顯示標題，所以標題要能獨立看懂；而完整訊息保留了脈絡，方便日後深究。AI 同時產出這兩層，等於幫你兼顧「掃一眼就懂」和「追根究柢時查得到」。

第三個、也是最容易被忽略的關鍵：它會在你「一次改太多」時點名提醒。提示詞明確要求「若 diff 涉及多個不相關變更，提醒我應該拆成多個 commit」。這直接對治工程師最常見的壞習慣——把修 bug、加功能、改樣式全部塞進一個 commit。這種「大雜燴 commit」之後極難回溯、也無法單獨 revert 某個變更。AI 幫你把關，等於隨身帶了一位提醒你維持良好提交習慣的 mentor。最後那句中文白話總結則是安全網，讓你提交前用母語快速確認 AI 有沒有誤解你的變更。

怎麼用

第一步，在終端機跑 git diff（看尚未 staged 的變更）或 git diff --staged（看已經 git add 準備提交的變更），把輸出整段複製。如果 diff 太長，貼一段精簡的文字描述也可以。

第二步，打開 AI 對話工具（Claude、ChatGPT、Gemini 皆可），把上方提示詞整段貼進去，再把剛剛複製的 diff 貼到「變更內容」區塊，按 Enter。

第三步，AI 會回給你符合規範的提交訊息——英文標題、條列內文，必要時還有 BREAKING CHANGE 段落，最後附一句中文白話總結。先看那句總結，確認 AI 沒有誤解你這次到底改了什麼；沒問題就把訊息複製起來，用 git commit -m "標題" 或開編輯器貼上完整訊息再提交。如果它提醒你「這應該拆成多個 commit」，那就乖乖回去用 git add -p 分段提交，別偷懶。這個流程對應 frontmatter 的「貼 diff → 拿到提交訊息 → 確認後提交」三步。

調整技巧

輸出的語言和範圍都可以用講的調整。團隊習慣中文 commit 的話，用「純中文版」請它整篇用繁體中文寫；想連 scope 都更精準，可以告訴它「這是 auth 模組的變更」，它就會把 scope 標成 auth。

兩個變體很順手。準備開 PR 時，用「PR 描述版」請它在產生 commit 訊息之餘，順便生出對應的 Pull Request 標題與描述，連開 PR 那關都省了。如果你一次 diff 裡確實混了好幾件事又不想拆，可以反過來請它「依變更性質幫我分成幾組，各寫一則 commit 訊息」，它會幫你把該怎麼拆、每組訊息怎麼寫都列好，你照著用 git add -p 分段提交即可。

注意事項

最該記住的一條：AI 只看得懂 diff 的「表面」，看不懂你的「意圖」。它能準確描述「這幾行新增了一個函式、那幾行刪掉了一個判斷」，但它不知道你為什麼要這樣改、這個改動是為了解決哪張票上的問題。所以提交前一定要看那句中文總結，確認 AI 的理解跟你的真實意圖一致。尤其當你的改動有「言外之意」（例如某個看似無害的修改其實是為了修一個 security issue），務必自己補上脈絡，別讓 commit log 失真。

其次，貼 diff 時留意敏感內容。如果這次變更裡含有 API 金鑰、密碼、token 或客戶資料（這本身就是不該 commit 的東西），請先處理掉再貼，別把機密貼進對話工具。公司有程式碼外流規範的話要遵守。這道配方雖然簡單、難度只有一星，但它產出的是會永久留在版控歷史裡的東西——commit 一旦推上去，很難乾淨地抹除。所以提交前的那一眼複查不能省，AI 是幫你寫初稿，按下提交的責任仍然是你的。

台灣情境案例

高雄一位接案工程師，平常一個人開發，commit 訊息向來隨便，git log 滿滿都是「fix」「update」「再改一下」。有天他接了一個需要長期維護的客戶專案，三個月後客戶回報「某個功能上個月還正常，現在壞了」，他想用 git log 回溯是哪次改動造成的，結果翻開歷史一片「update」「update」「update」，完全看不出每次到底改了什麼，最後只能一個一個 commit 用 git checkout 試，整整耗掉一個下午。

被這次教訓嚇到後，他開始用這道配方。每次提交前把 git diff 貼上，幾秒就拿到規範的訊息。一開始覺得只是「訊息變好看」，直到某次 AI 提醒他「這個 diff 同時改了登入邏輯和首頁樣式，建議拆成兩個 commit」，他才意識到自己長期把不相關的東西塞在一起，難怪日後難以追溯。

半年後，同一個客戶又回報問題，這次他用 git log --oneline 一掃，看到清楚的 fix(checkout): handle zero-quantity coupon，三秒就定位到該 commit，當天就修好了。他說這道配方真正改變的，不是訊息漂不漂亮，而是逼他養成了「一個 commit 只做一件事」的好習慣。

延伸用法

寫提交訊息是開發循環的收尾，前後都能串接其他工具。提交之前，先用PR Code Review 助手把這次變更跑一遍審查，確認沒有明顯 bug 再提交，品質更有保障。如果提交或測試時冒出看不懂的錯誤，就用錯誤訊息解碼器逆推根因，整條「審查 → 修正 → 提交 → 除錯」的鏈路就完整了。

想找更多工程師日常的效率配方，可以逛食譜總覽；如果你想把「diff → AI 寫 commit → 開 PR」變成團隊的標準流程，工作流專區有可參考的範本。需要快速生出 PR 描述、CHANGELOG 或 release notes 時，產生器也能幫你省下不少功夫。乾淨的 commit log 是專案的長期資產，越早養成習慣，未來的你越感激現在的你。

材料

• AI 對話工具（Claude／ChatGPT／Gemini）
• git diff 或變更說明

步驟

1. 貼 diff：執行 git diff 後把內容貼上。
2. 拿到提交訊息：取得符合規範的標題與條列說明。
3. 確認後提交：看過白話總結沒問題再 git commit。

配方本體（可複製帶走）

# 任務
請依以下程式碼變更，產生一則符合 Conventional Commits 規範的 Git 提交訊息。

變更內容（git diff 或文字描述）：
{貼上}

規則：
1. 標題格式為 type(scope): 簡短描述（type 用 feat/fix/docs/refactor/test/chore 等）
2. 標題用英文、50 字以內、祈使句
3. 空一行後用條列（-）說明這次改了什麼、為什麼
4. 如有破壞性變更，加上 BREAKING CHANGE: 段落
5. 若 diff 涉及多個不相關變更，提醒我應該拆成多個 commit
最後附上一句繁體中文的白話總結，方便我確認。

試吃報告

變化版

• 純中文版：團隊習慣中文 commit，請它整篇用繁體中文。
• PR 描述版：請它順便生出對應的 Pull Request 標題與描述。

你可能也想看