前十天，我們探索了各種 AI 開發工具和方法論。從 AI-DLC 到 Claudable，從 Spec-Driven Development 到各種實戰應用。但所有這些工具和方法都建立在一個核心技能之上：Prompt Engineering。
今天，我們要深入探討這個 AI 時代最關鍵的技能。
還記得你第一次使用 ChatGPT 或 Claude 時的情景嗎？那種充滿期待卻又略顯笨拙的對話。
你：「幫我寫程式」
AI：「好的！請問你需要什麼樣的程式？」
你：「就是...一個網站」
AI：（生成一個超級簡單的 HTML 頁面）
你：「不是啦！我要的是...」
這種挫折感幾乎每個人都經歷過。問題的根源在於，我們還在用搜尋引擎的思維與 AI 對話。但 AI 不是 Google，它不是透過關鍵字匹配來找答案，而是一個需要理解你的意圖、知道你的背景、明白你的期望的協作夥伴。
在軟體開發領域，有個有趣的現象叫「Vibe Coding」。正如 RuddyBlog 的文章所提到的，這是指那種「感覺對了」的開發方式——程式碼看起來應該能動，架構感覺很合理，但實際執行時卻問題重重。這種現象在 AI 協作中更加明顯。
當我們給 AI 一個模糊的指令，它會基於自己的理解生成看似合理的結果。但這個結果往往只是表面上符合要求，深入一看就會發現各種問題。就像兩個人在霧中對話，彼此都在猜測對方的意思。
要走出這個困境，我們需要從「隨興」轉向「可控」，建立一套清晰的溝通協議。而這正是 Prompt Engineering 的核心價值。
CRISPE 框架精準地捕捉了優秀 Prompt 的核心要素：
這個框架的妙處在於，它不是死板的公式，而是一種思考方式。讓我用實際案例來展示如何應用。
第一次嘗試（Vibe Coding 式）：
幫我優化這段程式碼
這就是典型的 Vibe Coding——我們覺得 AI 應該懂我們要什麼，但實際上這個指令充滿歧義。
「作為一位在大型電商公司工作的資深效能工程師，你擅長處理高併發場景下的程式碼優化，特別是在黑色星期五這種流量爆發的情況。」
「將這段購物車計算程式碼的執行時間從 3 秒降低到 300 毫秒以內，同時保持程式碼的可讀性和可維護性。」
「這段程式碼在平時運作良好，但在促銷期間，當百萬用戶同時結帳時，資料庫查詢成為瓶頸。每個商品都單獨查詢價格，導致 N+1 查詢問題。」
def calculate_cart_total(items):
total = 0
for item in items:
price = get_item_price(item['id']) # 每次都查詢資料庫
total += price * item['quantity']
return total
「請用工程師的思維分析問題，提供具體的優化方案和程式碼實現，並解釋每個優化點的原理。」
「請提供優化前後的效能對比數據，包括時間複雜度分析和預期的改善幅度。」
這樣完整的 Prompt 讓 AI 能夠全面理解問題，提供的解決方案也會更加精準實用。
還記得我們在 Day 4 介紹的 AI-DLC Sprint 嗎？其實它的核心理念與 Prompt Engineering 的進階技巧不謀而合。
在 AI-DLC Sprint 中，我們會讓 AI 扮演不同的角色，每個角色負責開發流程的特定環節，這正是 Prompt Chaining 思想的實際應用。
在一個典型的 AI-DLC Sprint 中，我們會定義這些角色：
負責理解需求、定義功能規格、撰寫 User Story。這個角色需要從商業角度思考，關注用戶價值和市場需求。
負責系統設計、技術選型、架構決策。需要考慮可擴展性、效能、安全性等技術層面的問題。
負責介面設計、互動流程、用戶體驗優化。要從用戶角度出發，確保產品易用且美觀。
負責具體的程式碼實現、功能開發。需要遵循最佳實踐，寫出高品質的程式碼。
負責測試策略、測試案例設計、品質把關。要找出潛在的問題和邊界條件。
從 Spec 到實現：一個完整的 Chain
讓我用一個實際例子展示這個流程如何運作。假設我們要開發一個「習慣追蹤器」應用：
你是一位經驗豐富的產品經理，專門設計提升個人效率的工具。
請分析「習慣追蹤器」的市場需求，定義核心功能和用戶價值主張。
輸出格式：
你是一位資深技術架構師，擅長設計可擴展的 Web 應用。
基於以下產品需求：[Chain 1 的輸出]
請設計技術架構，包含：
你是一位注重用戶體驗的 UI/UX 設計師。
基於產品需求和技術架構：[Chain 1 & 2 的輸出]
請設計：
你是一位 Full Stack 開發工程師，精通 React 和 Node.js。
根據架構設計和 UI 設計：[Chain 2 & 3 的輸出]
請實現：
你是一位細心的 QA 工程師，擅長找出潛在問題。
基於實現的功能：[Chain 4 的輸出]
請設計：
這種多角色的 Prompt Chaining 方法有幾個關鍵優勢：
每個角色只需要關注自己的專業領域，不會被其他考量分散注意力。就像真實的團隊分工，每個人都能發揮所長。
透過角色設定，我們能激活 AI 在特定領域的專業知識。告訴 AI「你是產品經理」和「你是架構師」，會得到截然不同的思考角度。
後面的角色會自然地檢查前面角色的輸出。比如開發者會發現架構設計中的問題，QA 會找出實現中的漏洞。
每個環節都有清晰的輸入輸出，如果出現問題，很容易定位是哪個環節需要優化。
如果說 Prompt Engineering 是優化單次對話，那麼 Context Engineering 就是構建整個對話環境。這是從戰術到戰略的躍升。
想像你正在指導一個新加入團隊的工程師。你不會每次都從頭解釋公司背景，而是會逐步建立共同的認知基礎。Context Engineering 就是將這種人類的溝通智慧系統化。
定義基本的運作原則和價值觀。比如：「我們優先考慮用戶體驗，寧可犧牲一些技術優雅性也要確保產品易用。」這層上下文影響所有後續的決策。
不同領域有不同的潛規則和最佳實踐。金融領域強調安全合規，社交媒體重視互動體驗，電商關注轉換率。明確領域背景能讓 AI 的建議更貼合實際。
現實的約束條件：團隊有 5 個人、使用 Python 技術棧、兩週後要上線、預算有限。這些約束直接影響技術選型和架構決策。
具體的需求細節。有了前三層的鋪墊，這層可以更精簡，因為 AI 已經理解了大背景。
這種分層架構不是為了增加複雜度，而是為了提高溝通效率。就像配合默契的團隊，一個眼神就能傳達複雜的意思。
面對複雜任務，人類的本能是分而治之。Prompt Chaining 正是這種智慧在 AI 協作中的應用。與其寫一個包羅萬象的超長 Prompt，不如將任務分解成環環相扣的步驟。
假設我們要開發一個功能完整的部落格 API。傳統的 Vibe Coding 方式可能是：
請幫我開發一個部落格系統的後端 API，要支援文章 CRUD、標籤管理、
評論功能、用戶系統、權限管理，使用 Node.js + Express + TypeScript，
資料庫用 PostgreSQL，要有完整的錯誤處理和輸入驗證，還要寫測試，
部署到 Docker...
這樣的 Prompt 就像是要求某人一口氣吃下整個蛋糕。結果往往是消化不良。
分析一個現代部落格系統的核心功能，設計 RESTful API。
輸出：完整的 API 端點列表，包含路徑、方法、請求/回應格式。
重點：用戶體驗和開發者友好性。
基於上述 API 設計，創建 PostgreSQL 資料庫架構。
考慮：正規化、索引優化、關聯完整性。
輸出：完整的 SQL DDL 語句。
使用 TypeScript + Express 實現文章管理的 CRUD API。
包含：輸入驗證、錯誤處理、分頁功能。
遵循：RESTful 最佳實踐和 SOLID 原則。
為上述 API 設計測試案例。
包含：單元測試、整合測試、邊界條件。
使用：Jest + Supertest。
每個環節專注於特定目標，前一步的產出成為下一步的輸入。這種方式不僅提高成功率，也讓整個過程更透明可控。
有時候，告訴 AI「不要做什麼」比「要做什麼」更有效。特別是在安全敏感的領域：
設計用戶認證系統時，請特別注意避免以下常見錯誤：
請解釋你的設計如何避免這些問題。
這些負面提示就像路標上的警告，有效引導 AI 繞過已知的陷阱。
角色設定看似玄學，實則有其心理學基礎。當你告訴 AI「你是 Netflix 的資深工程師」時，你實際上在啟動特定的知識模式和思維框架。
比較這兩個版本：
普通版本：
如何處理大量並發請求？
角色版本：
你是 Netflix 的串流架構師，負責確保全球數億用戶能流暢觀看影片。
在你的經驗中，如何設計系統來處理晚間高峰期的並發請求？
後者會得到更具體、更實戰的答案，包含真實場景的考量和權衡。
與其費勁解釋你要的格式，不如直接示範：
請將錯誤訊息轉換為用戶友好的提示：
範例 1：
技術錯誤：UNIQUE constraint failed: users.email
用戶提示：這個 email 已經被註冊了，請使用其他 email 或直接登入
範例 2：
技術錯誤：Connection timeout after 30000ms
用戶提示：網路連線逾時，請檢查網路後重試
現在請轉換：
技術錯誤：Invalid JWT token signature
透過範例，AI 能快速理解你要的轉換風格和語氣，比冗長的規則說明更有效。
隨著經驗積累，你會發現某些場景會重複出現。建立一個個人的 Prompt 模板庫能大幅提升效率：
As a senior {language} engineer, review this code focusing on:
Provide specific suggestions with examples.
Context: {project_background}
Constraints: {technical_constraints}
Scale: {expected_traffic}
Design a {system_type} that:
Consider trade-offs between {factor1} and {factor2}.
筆者非常愛用 Claude Code 的 Sub Agent，基本上就是類似模板庫的功能，後面實戰的文章會深入探討
經過無數次的實驗和失敗，我總結出三個關鍵洞察：
最好的 Prompt 往往不是最長的，而是最精準的。學會用最少的詞傳達最準確的意思。
不要追求一次就寫出完美的 Prompt。快速嘗試、觀察結果、持續改進，這個過程本身就是學習。
掌握一兩個技巧很容易，但建立一個完整的 Prompt 系統才能帶來持續的價值。
隨著 AI 能力的提升，Prompt Engineering 也在進化。我們正在從「如何讓 AI 理解我」轉向「如何與 AI 共同思考」。未來的 Prompt Engineering 可能會更像是一種新的編程範式——用自然語言編寫意圖，讓 AI 處理實現細節。
但無論技術如何發展，清晰思考和準確表達的能力永遠不會過時。在這個 AI 無處不在的時代，掌握 Prompt Engineering，就是掌握了開啟 AI 潛能的鑰匙。
今天我們深入探討了 Prompt Engineering 的方方面面，從基礎框架到進階技巧，從理論到實踐。特別是看到了它如何與 AI-DLC Sprint 的理念完美融合，形成一個強大的開發方法論。
真正的學習始於實踐。選一個你正在處理的實際問題，試著用 AI-DLC Sprint 的角色分工方式，配合 CRISPE 框架來設計你的 Prompt Chain。觀察結果的改善，思考背後的原因。
記住，每一次與 AI 的互動都是一次學習機會。在 AI 時代，Prompt Engineering 不是選修課，而是必修課。掌握它，你就掌握了與未來對話的語言。
明天我們將探討如何建立個人專屬的 AI 開發環境，打造最適合自己的 AI 輔助開發工作流。在那之前，開始練習吧！試著用今天學到的方法，為你的下一個專案設計一個完整的 AI 協作流程。
iThome鐵人賽
看影片追技術