從 Prompt 到 Agent：AI 提示詞寶典 v2.0 與 Vibe Coding 新章節
說真的，2025 到 2026 這一年多，我寫程式的方式整個變了。以前我會花半小時雕琢一句 prompt，反覆推敲措辭、加上範例、調整語氣，只為了讓模型吐出一段我想要的程式碼。現在呢？我更像是在「指揮」一個 agent：一個會自己讀檔案、跑指令、改程式碼、再回頭看測試有沒有過的夥伴。我下的不再是一句話，而是一個任務；我盯的不再是輸出，而是過程。
這種轉變細微但深刻，所以這次我們把它寫成了一 整個新章節。今天想跟你聊聊「AI 提示詞寶典」v2.0，以及裡面這個我醞釀很久的主題：Vibe Coding 與 AI 編碼代理。
什麼是 vibe coding？
先把名詞講清楚，免得我們各說各話。
「Vibe coding」這個詞是 Andrej Karpathy 在 2025 年 2 月提出的。它描述的是一種放鬆、跟著感覺走的開發狀態：你把意圖丟給 LLM，看它跑出什麼，覺得對味就留下，不對味就再叫它改一輪。
但 vibe 歸 vibe，真正讓我覺得這個概念有重量的，是 Simon Willison 給的那個比較嚴格的定義：vibe coding 是用 LLM 來開發，但不去審查它寫的程式碼。注意這個「不審查」：這是重點，也是界線。
所以 vibe coding 到底適不適合用？我的答案是：看場合。
- 拿來做原型、探索想法、週末玩個小工具？太適合了，速度快得會讓你上癮。
- 拿去跑正式上線、要對使用者負責的系統？那就要非常小心了。沒看過的程式碼直接上 production，這不是 vibe，是賭。
換句話說，vibe coding 是一種模式，不是一種紀律。它解放了你的探索力，但它本身不保證品質。
比工具更大的轉變：從 prompt 到 context
如果你跟我一樣，前兩年都在練 prompt engineering，那你可能也感覺到了：光「會寫 prompt」已經不夠了。
現在真正的功夫，往兩個方向長出去：
- Context engineering（情境工程）：與其雕一句完美的 prompt，不如好好經營 agent 能看到的整個「情境」。它讀得到哪些檔案？知不知道你的專案慣例？有沒有一份說明它該怎麼做事的文件？這些加起來，比任何一句巧妙的措辭都重要。
- Spec-driven development（規格驅動開發）：先把「要做什麼」寫成清楚的規格，再讓 agent 照著規格去實作。規格成了人和 agent 之間的合約。
我自己會用一句話來幫朋友理清這三者的關係：用 vibe coding 探索、用規格驅動交付、用 agentic engineering 當那把專業的大傘。 探索時你可以放飛；交付時你要有合約；而把整件事做得專業、可重複、可信賴，那就是 agentic engineering 要罩住的範圍。
新章節帶你走一遍
這次的 Vibe Coding 章節我拆成 7 篇，盡量做到「看完就能上手，而且知道為什麼這樣做」。我簡單帶你過一遍：
- 總覽：先把整張地圖攤開，搞清楚 vibe coding、context engineering、spec-driven development、agentic engineering 各自站在哪、彼此怎麼接。
- Claude Code 實戰指南：怎麼把 Claude Code 當成日常的編碼夥伴，從第一次對話到讓它跑完整個任務。
- OpenAI Codex 實戰指南：另一條主流路線。你會發現很多觀念是共通的，差別在使用手感與工作流。
- Context Engineering：CLAUDE.md 與 AGENTS.md：這篇是我私心最推的。怎麼用一份
CLAUDE.md或AGENTS.md把你的專案慣例、邊界、地雷一次交代給 agent，讓它「懂你的專案」。 - Agentic 工作流程：把 agent 接進真實的開發循環（讀、改、跑、驗證、再來一輪），而不是一次性的一問一答。
- 規格驅動開發：把規格當成第一公民，讓「要做什麼」先於「怎麼做」。
- 驗證、安全與工程紀律：這篇是整個章節的安全帶。agent 能跑指令、能改檔案，那要怎麼確保它不會把事情搞砸？
如果你想先暖身，也可以先回去翻翻舊的 程式碼生成教學，再接著讀新章節，銜接會更順。
我真正想說的：工具再強，紀律才是分水嶺
寫到這裡，才要講這篇文章的核心，也是整個 v2.0 我最想傳達的一句話。
我用過很猛的 agent，也看過很多人被它的速度沖昏頭。但我越用越確定一件事：工具再強，真正拉開差距的，還是那些老派到不行的工程紀律。
具體是哪些？我列幾個我每天都在用的：
- TDD（測試驅動開發）：先寫一個「會失 敗的測試」，把它當成 agent 的驗證關卡。agent 改完程式碼，測試由紅轉綠，你才知道它真的做對了，而不是它「看起來」做對了。這比你瞪著程式碼猜有沒有 bug 可靠太多。
- Small CLs（小而聚焦的變更）：一次只改一件事。別讓 agent 一口氣翻動三十個檔案：那種 diff 沒人 review 得動，出事也找不到兇手。小變更，好讀、好驗、好回滾。
- Boy Scout Rule（童子軍原則）：離開營地時，讓它比你來的時候更乾淨一點。你或 agent 動到哪個檔案，就順手讓那個檔案乾淨一點點。日積月累，整個專案的健康度就守住了。
- 避開 LLM 最愛的兩個壞習慣：一是過度生成：它很愛多寫一堆你沒要的功能、沒要的設定、沒要的「貼心」抽象層；二是過早抽象：明明還沒看清需求，它就急著幫你包一層通用框架。這兩件事不擋下來，程式碼會以驚人的速度長出脂肪。
你發現了嗎？這些原則，沒有一條是 2025 年才發明的。TDD、小變更、童子軍原則，在 agent 出現之前就是好工程師的內功。v2.0 真正想說的是：把這些紀律套到 agent 身上。 agent 改變了「誰來打字」，但它沒有、也不該改變「什麼叫做好的工程」。誰能把老紀律穩穩地架在新工具上，誰就能真正吃到這波紅利，而不是被它反噬。
最後
如果你只從這篇帶走一句話，我希望是這個：讓 agent 跑得快，讓紀律守得住。 速度交給工具，品質交給你自己。
去讀讀新章節吧。我寫的時候，一直想著當年那個「技能樹亂點」的自己（從醫學、電機資訊一路晃到戲劇）。我越來越相信，寫程式跟跨領域學習其實是同一件事：工具會一直換，真正帶得走的，是那套你願意一遍遍打磨的判斷力與紀律。
這份寶典是開源的，它也是被許多人一起讀、一起改、一起變好的。歡迎你來踩、來挑錯、來貢獻：我們在這條從 prompt 到 agent 的路上，一起走。
作者簡介：蔡秀吉，清大電機資訊學院學生，開源社群參與者。興趣橫跨資訊工程、神經科學、心理學、本土語言到戲劇表演。相信跨領域思維與工程紀律，是 AI 時代裡最值得長期投資的兩件事。