# Vibe Coding 體驗 — 製作描字帖（含 Github Copilot 節費心得）

**作者：吉祥法师**

## 緣起：一個懶人開發者的新嘗試

在程式開發領域深耕多年後，我首次嘗試了一種全新的開發模式——只定義規格與指導方向，將程式碼撰寫與除錯工作完全交由 AI 處理，甚至全程不閱讀程式碼。這種被稱為「Vibe Coding」的開發方式，對我而言是一次徹底的體驗革新。

所謂 Vibe Coding，簡單來說就是開發者只負責描述需求、設定目標與驗收標準，其餘包含程式碼生成、錯誤修正、邏輯調整等繁重工作，皆交由 AI 自動完成。這種模式大幅減輕了開發者的腦力負擔，讓程式開發從「親力親為」轉變為「監督指導」。

然而，這種開發方式也伴隨著無法預測的風險——當開發者完全不檢視程式碼時，可能會有潛在的邏輯錯誤或安全漏洞未被發現。因此，我為自己設定了使用 Vibe Coding 的四項嚴格前提條件：

**第一，自用性質。** 僅限於個人使用的小工具或小程式，不需為造成他人損失負責。若是工作相關、需交付他人使用或長期運轉的系統，則必須全程參與程式碼檢視。

**第二，風險可控。** 程式出錯造成的損失必須在可接受範圍內，不會危及財產、健康及安全。這意味著高風險場景絕對不適合貿然採用 Vibe Coding。

**第三，結果可驗證。** 程式執行結果必須能立即檢驗，正確與否一望即知，不會埋下未來才爆發的問題種子。

**第四，技術含量低。** 開發所涉及的技術對當前成長幫助不大，或屬於重複性高、無需深度理解的領域。

這四項原則，成為我日後判斷是否採用 Vibe Coding 的重要依據。

## 專案背景：從需求到解法的靈感

本次 Vibe Coding 的題目來自 YouTube 上的一個硬筆字教學頻道「寫字練心」。該頻道不僅提供免費的教學影片，還貼心地準備了可供下載練習的 PDF 字帖，可謂佛心來著。

然而，這份字帖存在一個美中不足之處：習字帖只有第一欄提供示範字，其餘欄位完全留白。對於像我這樣的初學者而言，沒有描紅範本可供臨摹，學習效果勢必大打折扣。

憑藉多年程式開發經驗，我立刻想到解決方案——將第一欄的中文字樣擷取出來，以淡色方式疊加在後續空白欄位上，如此便能自製一份個人化的描字帖。這個概念在技術上並不複雜，但當下缺乏動手實作的興致，加上剛好碰上 Github Copilot 每月點數重新計算的時機點（一月未用完的點數在二月歸零重算），天時地利人和之下，決定趁此機會體驗 Vibe Coding 的魅力，同時累積 Github Copilot CLI 的實戰經驗。

## 第一次嘗試：AI 的迷航與教訓

初次嘗試我選擇了 Github Copilot CLI，搭配 Claude Sonnet 4.5 模型。我的指令如下：

> 分析 CopyBooks/01首點居正.pdf，它是一本中文描字帖，共有 10x15 個格子，目前只有第一 Column 有字，請寫一支程式將第一 Column 的字刷淡印疊在第 2 ~ 8 Column，結果輸出成 PDF

出乎意料的是，AI 在第一輪就遭遇了挫折。由於未能察覺字帖中紅線分隔內外框的設計，AI 產出了不符合預期的結果。儘管 AI 具備圖片解讀能力，能將輸出結果轉為圖檔進行自我檢查並修正，但過程中逐漸陷入無止盡的影像識別演算法調整循環。

只見 AI 不斷嘗試各種演算法——從調整紅色閾值偵測、改寫分析程式、安裝影像處理套件，到反覆檢視除錯圖檔，每一步看似有進展，實則原地踏步。它始終未能理解一個關鍵：這類格子計算根本不需要複雜的影像識別技術，只需測量外框尺寸，將總寬度除以欄位數量，即可得出每個格子的精確寬度。

此時我深刻體會到，Vibe Coding 雖然能讓 AI 自主思考與修正，但若沒有適時的引導，AI 可能會在錯誤的方向上愈走愈遠，浪費大量時間與資源。

## 修正版：轉折與突破

意識到問題所在後，我決定重新調整指示並重開一局。這次的指令更加精確且富有策略性：

> 分析 CopyBooks/01首點居正.pdf，它是一本中文描字帖，共有 10x15 個正方形細紅線格子，整頁有粗紅框。
> PDF 目前只有第一欄(Column)有字，請寫一支程式將第一欄的字刷淡印疊在第 2 ~ 8 欄位，第 9 ~ 10 欄維持原樣。
> 每個格子為正方形，先找出 150 格的座標以便精準定位。
> 將第一欄位使用 Overlay 方式疊加在 2 ~ 8 欄位，選擇正確影像重疊算法，讓原本紅框線加上刷淡的中文字，紅框線顏色不變。
> 結果輸出成 PDF

這次 AI 接受了教訓，改採總寬總高推算的方式進行定位，效率大幅提升。然而，最終輸出仍存在微小誤差——每個格子都向右偏移了約 1 個像素，導致整體排列出現偏差。

面對這個問題，我評估了兩個選項：繼續教導 AI 修正，或是捲起袖子自己來。考量到這僅是單一像素的細微差異，與其花費時間精力指導 AI 理解像素級別的誤差問題，不如直接手動調整更有效率。於是我找到計算格寬的程式碼區段，將 cell_width 減去 1，結果便完全吻合。

這個經歷讓我體會到一個重要原則：Vibe Coding 並非萬能，適時的人力介入往往是提升效率的關鍵。開發者不必事必躬親，但也不能完全撒手不管，而是要在關鍵時刻做出正確的判斷與行動。

## 進階優化：追求完美的代價

第一版成果雖然堪用，但由於原始 PDF 來自掃描，每份文件的尺寸位置存在差異，部分紙張甚至有些許歪斜，導致部分字帖的描字線無法完美銜接。

想說 Copilot 的點數不用白不用，加上想要測試更高等級的模型效能，我便切換到最貴的 Claude Opus 4.5 模型繼續優化。這款模型每次提問需扣除 3 點（Pro 訂閱每月有 300 點，Pro+ 則有 1500 點），點數消耗速度驚人。

在多次嘗試中，我嘗試了各種優化策略：圖形識別演算法調整、先刪除外框再進行識別以減少干擾、底色白化處理、甚至完全捨棄原始掃描稿改由程式自行繪製格子等。總計花費了七八個小時、提問二十餘次，最終靠著加入一些預處理的人工步驟，簡化了整體難度，才成功產出令人滿意的結果。不過，後期的開發過程已非純粹的 Vibe Coding，而是混合了人工介入與 AI 輔助的協作模式。

## Github Copilot 節費實戰心得

在這次體驗過程中，我發現了 Github Copilot CLI 的計費機制與一般認知存在差異。Github 的計費方式是以「任務完成」為單位，從最初提問到 AI 判定任務執行完成為止，中間歷經的所有步驟與 Token 消耗都只計算為一次。這意味著一次提問可能包含多個步驟——反覆檢查輸出結果、發現錯誤、修正程式、重新執行——而無論中間消耗多少 Token，都只扣除一點或三點。

這項發現帶來了兩個寶貴的節費技巧：

**技巧一：善用每次提問的價值。** 提示內容愈完整、涵蓋的任務範圍愈大，每次提問所能完成的任務就愈多。將「實作 20 行規格」與「第一欄向左移 5px」相比，兩者消耗的點數相同，但前者顯然更具成本效益。後者如同搭乘計程車去買茶葉蛋，浪費資源又不划算。

**技巧二：採取「執行動作前先詢問」的策略。** 這個原則有雙重好處：一方面可以監督 AI 的動作，防止它刪改不該動的檔案；另一方面，當發現 AI 判斷有誤時可以立即要求調整，避免在錯誤的方向上繼續投入時間與點數。這就好像在下棋時，每一步都先確認對手的意圖，再決定如何應對。

## 關於 Vibe Coding 的深度省思

### AI 的自主能力與限制

首次使用 CLI Agent 的體驗相當有趣。在終端機視窗中觀看 AI 的「實況轉播」，它會自主分析問題、撰寫程式、執行測試、檢視結果，甚至將輸出轉為圖檔進行視覺化檢查，確認是否符合規格，若不滿意則自行調整程式再試一次——這是完全具備除錯能力的 AI。此時的我宛如一個旁觀者，看著 AI 忙得不可開交，內心不禁讚嘆科技的進步。

然而，我同時也發現了一個關鍵問題：永遠只提規格而不指導做法，Vibe Coding 往往會陷入低效率的困境，甚至跑進死胡同。問題的解決路徑往往有多種可能性，例如：直接轉灰階進行圖形識別，或是先依據顏色移除紅框線再轉灰階，前者的處理難度與成功率明顯不如後者。因此，適時引導 AI 使用特定策略、選擇簡單可靠又省力的解法，能有效降低失敗率並加速得到正確結果。

### 人類經驗的不可替代性

AI 會不會自己找到最佳解法？答案並非絕對。這取決於問題的複雜度、提示指令的品質、上下文資訊的完整性，甚至帶有幾分運氣成分。但可以確定的是，由具備相關背景知識的人監督 Vibe Coding 過程，適時提示 AI 使用正確的方法解決問題，絕對能更快地產出更好的系統。

以這次的描字帖專案為例，同樣的題目交給對電腦一無所知的小白、略懂影像處理皮毛的開發者，或是經驗豐富的影像處理專家，最終的成果品質將截然不同。個人的開發經驗與領域知識，對 Vibe Coding 的速度與品質仍然具有關鍵性的影響。

### 未來展望：責任與作者的消逝

在反思 Vibe Coding 的深層影響時，我想起了古代工匠的「物勒工名」傳統。古時候建造寺廟的工匠，會在梁柱或磚石上刻下自己的名字，以示負責與榮譽。這讓我不禁思考：當 Vibe Coding 全面風行之後，程式是否還有所謂的「作者」？當開發者不再親自撰寫程式碼，只是扮演監督與指導的角色時，程式的歸屬與責任該如何界定？

這個問題沒有標準答案，但值得每一位擁抱 Vibe Coding 的開發者深思。也許，未來的程式開發會像導演與編劇的關係——靈感來自人類，執行交給 AI，但最終的成果與責任，仍由人類承擔。

## 總結：實用技巧與心態建議

最後，整理這次 Github Copilot CLI Vibe Coding 體驗中學到的實用技巧：

**建立專案規範檔案。** 使用 .github/copilot-instructions.md 檔案規範程式撰寫方式，例如 Python 套件統一使用 uv 與 venv 管理、暫存檔放置於特定目錄、輸出結果存放於指定位置等。這能確保 AI 生成的程式碼符合個人偏好與專案需求。

**善用計費機制。** 既然 Github Copilot 以次計費，每次提問內容愈完整愈好。將所有需求一次說清楚，避免頻繁提問浪費點數。

**採取監督模式。** 若條件允許，建議採行「每次動作前先詢問」的原則。這不僅能阻止 AI 做出危險行為，也能即時監督與糾正 AI 的錯誤方向，避免在錯誤的道路上浪費時間與點數。

**發揮人類優勢。** 如果你具備相關經驗或專業知識，別放任 AI 自由發揮。主動提示 AI 採取可靠且有效率的做法，往往能事半功倍。但若 AI 採用的方法確實比你的想法更好，記得放下身段虛心學習。

Vibe Coding 代表了程式開發的新紀元，它讓開發者能更專注於解決問題的本質，而非被繁瑣的實作細節所困。但這並不意味著開發者可以完全放手，而是需要以更智慧的方式與 AI 協作。唯有理解 AI 的優勢與限制，善用每一次互動的價值，並在關鍵時刻發揮人類的判斷力與創造力，才能真正釋放 Vibe Coding 的強大潛力。