Vibe Coding：AI 輔助編程速成

「Vibe Coding」= 以 AI 助手／代理 為主體、用自然語言驅動程式開發；重點不在手寫語法，而在用清晰意圖 + 快速迭代把 MVP 拉起來，同時用測試與審查把風險壓住。這個詞近年由 Karpathy 帶火，主流平台（Replit、Microsoft Learn 等）已有入門模組；同時也有媒體對「只憑 vibe 而不審碼」提出質疑。

甚麼是Vibe Coding

💡 定義

Vibe Coding 並非「只憑感覺寫程式」，而是一種以 AI 代理（Agent / LLM）為協作核心的新式編程工作流。 在這種模式下：

• 人類的角色：負責「說明需求、設定限制、撰寫驗收條件」。
• AI 的角色：根據這些描述生成、修改或測試程式碼。

換句話說，Vibe Coding = 描述 + 驗收導向的開發流程， 而不是傳統「從零開始手寫語法」的編程。

---

⚠️ 風險提醒與專業責任

Vibe Coding 近年成為熱門詞彙，但許多報導也指出其潛在誤導與風險：

1. 🚫 誤解 1：Vibe Coding = 不用看程式
   錯。AI 生成的代碼只是草稿，仍需人工閱讀、理解與測試。
   真正的專業在於：你是否能判斷這段代碼是否安全、合理、可維護。

2. 🔍 誤解 2：AI 生成程式一定正確
   實際上，LLM 會出現「幻覺」（Hallucination）或腳位錯誤、邏輯漏洞。
   因此必須進行 三道關卡：

   • ✅ 測試 (Testing)：確認功能正確與邏輯一致。
   • ✅ 審查 (Review)：人工逐行檢查程式註解與腳位。
   • ✅ 授權 (License Check)：確認 AI 是否引用外部程式碼或開源庫。

3. ⚙️ 誤解 3：AI 可以完全取代工程師
   現階段 AI 仍依賴人類提供明確需求（Prompt Engineering），
   若需求模糊，AI 可能生成錯誤或危險代碼。
   因此，Vibe Coding 是「共同創作」而非「全自動化」。

方法論（PRD → Prompt → Agent）

🧩 Prompt 對比示例：低配版 vs 專業版

🚫 差的 Prompt（學生常犯例子）

整一個呼吸燈。

---

❌ 問題分析

問題	為什麼唔得
🎯 目標太模糊	「整一個呼吸燈」可以有十種解讀：ESP32？Arduino？用 PWM？用 delay？AI 唔知道。
⚙️ 缺少技術細節	無講腳位、無講亮度範圍、無講週期長短、無講需唔需要平滑效果。
🧪 無驗收標準	「呼吸」有幾快先算呼吸？AI 無法測試或優化。
📦 無限制條件	AI 可能亂用 delay()、亂用外部函式庫，導致程式卡死。
🔁 無法迭代	因為前面無明確條件，學生後面講「慢啲啦」AI 只會亂調。

🧨 結果：AI 可能生成一個閃爍燈（Blink）， 而唔係真正亮暗平滑嘅「呼吸燈」。 學生睇落以為「好似啱」，但實際邏輯錯晒。

---

✅ 標準 Prompt（可直接使用）

你是一名嵌入式系統工程師。
請為 ESP32 生成一個可在 Arduino IDE 執行的程式。
功能如下：

• 控制一顆 LED（接在 GPIO 2 腳位）
• LED 亮度需平滑地由暗變亮，再由亮變暗，形成「呼吸效果」
• 一個完整週期約 2 秒
• 必須使用 PWM (analogWrite) 控制亮度，不得使用 delay()
• 用 millis() 控制時間，使主程式可持續運行
• 不使用外部函式庫，程式需在單一 .ino 檔案完成
• 請加入清晰註解，說明每段邏輯
• 在最後加入一個測試函式，用以改變呼吸速度並列印結果

---

✅ 為什麼呢個好？

關鍵元素	說明
角色明確	告訴 AI 佢係嵌入式工程師，代碼風格會自動變專業。
目標具體	「平滑亮暗」+「週期 2 秒」= 可驗證、可測試。
I/O 清楚	指定 GPIO 腳位，AI 唔會亂用。
限制明確	禁止 delay()、禁止外部函式庫。
驗收條件	可以量化結果，方便檢查與 debug。
結構化思維	用清單分段，AI 會按邏輯生成乾淨 code。

PDR(Prompt Requirements Document)

Prompt Requirements Document (PRD): A New Concept for the Vibe Coding Era

這篇文章介紹了一個名為**「提示詞需求文件 (Prompt Requirements Document, PRD)」的新概念，它是在「Vibe Coding Era)」中，因應人類與 AI 協作開發軟體**所誕生的。

簡單來說：

💡 核心觀念：提示詞需求文件 (PRD)

• 傳統 PRD：主要處理非結構化資訊，用於人類對人類的對齊。
• 新的 PRD (提示詞需求文件)：專注於生成、編輯和管理結構化的提示詞（包括文字、圖片、影片等），這些提示詞必須是AI 和人類都能理解和有效使用的。
• 目的：成為人類與 AI 共同理解專案、保持一致性的關鍵橋樑和唯一事實來源。

🛠 內容三大支柱

一個精心編寫的提示詞 PRD 通常包含三個部分：

1. 《指南 (Guideline)：共享 AI-人類理解》
   • 一個全面的知識庫，建立專案背景、技術原理和架構決策。
   • 確保 AI 助理和人類團隊成員從相同的理解基礎上運作，類似於傳統 PRD 讓所有利害關係人對齊需求。
2. 《指導 (Guidance)：提示詞演進方法論》
   • 一種結構化的方法，幫助開發者將抽象概念演變為 AI 系統能準確解釋和執行的精確指令。
   • 包括帶註解的提示詞範例、模式庫、情境最佳實踐和常見錯誤警告，讓新手也能建立有效、高品質的提示詞。
3. 《護欄 (Guardrails)：AI 輔助程式碼審查》
   • 一套明確定義的自動化評估標準和品質檢查點，專門針對已知的專案風險和常見痛點。
   • 讓 AI 系統能對程式碼進行初步審查，在人工審查前就找出基本問題，減輕人類審查的負擔，確保程式碼品質一致。

🧩 PRD 結構化 Prompt 組成

組成元素	應包含內容	說明（為何重要）	示例（以 ESP32 呼吸燈為例）
1. 🎭 角色 (Role)	指定 AI 的身份、專業角色	令 AI 採用正確語氣與知識框架，減少幻覺	「你是一名嵌入式系統工程師。」
2. 🎯 目標 (Goal)	明確任務目的與要達成的效果	讓 AI 理解最終成果，而非只執行片面動作	「請為 ESP32 生成一個 Arduino IDE可執行的呼吸燈控制程式。」
3. 🔌 輸入 / 輸出 (I/O)	清楚列出輸入來源、資料類型、輸出格式	幫 AI 知道該讀取／輸出的內容與型態	「輸入：無（自動執行）；輸出：LED PWM 亮度變化（0–255）」
4. ⚙️ 限制 (Constraint)	指定開發條件、不可做的事、技術邊界	限制範圍可令 AI 生成安全、可測試、可重現的結果	「不得使用 delay()；不可用外部函式庫；單一 .ino 檔完成。」
5. 🧪 驗收標準 (Acceptance Tests)	寫出 3–5 條可測試條款（PASS / FAIL）	學習用「測試」思維驗證 AI 代碼品質	「LED 每 2 秒完成一次呼吸週期；變化平滑無閃爍；含註解說明邏輯。」
6. 🔁 迭代規則 (Iteration Rule)	定義 AI 應如何修正或優化	應理解 Vibe Coding 不會一次到位，而是多輪調整	「若亮暗變化太突兀，請 AI 調整 PWM 步進值或更新間隔。」
7. 🧷 授權與註解 (License / Comments)	要求列出 AI 工具、作者及程式註解	建立資料倫理與透明開發習慣	「請在程式結尾註明作者與生成工具名稱。」

• Prompt ≠ 句子，而是結構： 要學懂「講清楚」，不是「講多啲」。
• Role + Goal = Context；Constraint + Test = Guardrail： 結構化 prompt 就是為 AI 建立「任務邊界」。
• 同一個任務，不同結構 → 不同結果： 學懂比較「差 prompt」與「結構化 prompt」輸出差異。

非常重要

• ==Vibe coding 不是「不寫程式」；是把人力投到定義問題、驗收與風險，把低層繁瑣交給代理。==
• ==真實世界可交付，靠的是清晰 PRD + 可重複測試 + 審查習慣，而不是「接受所有建議」。==

🧾《Vibe Coding 結構化 Prompt 練習 》

1. ESP32 呼吸燈

2. 幫我整一個 ESP32 紅綠燈程式

   

3. ESP32有線搶答機

4. (Bonus)為有線搶答機，加入蜂鳴器，報聲時系統照常能復原和搶答

工作紙

1. Vibe Coding 1