Day 02中，我們為AI設定好了 .cursorrules開發規範。然而在實際的Vibe Coding過程中，許多開發者常常會遇到以下狀況：
請幫我寫一個登入頁面→AI寫出了一個簡陋的HTML表單，既沒有驗證邏輯，也沒有串接API。
請幫我修這個Bug→AI改了A檔案，卻意外破壞了B檔案的狀態，甚至開始胡言亂語（Hallucination）。
這些問題的根源，往往在於需求表達過於模糊以及脈絡（Context）污染或不足。今天我們將深入探討如何寫出高精準度的規格書Prompt，以及如何精確管理喂給AI的Context。

1. 為什麼AI會產生幻覺與寫出廢碼？LLM是一個基於機率預測下一個Token的模型。當你給予的需求太短、資訊不足時，AI為了完成對話，會主動填補你沒說出口的空白。

要防止AI盲目發揮，關鍵在於將模糊的自然語言需求轉譯為結構化的程式規格。

2.高效溝通的CRISP規格書Prompt框架
當我們要交付一個非微型功能時，建議使用CRISP框架來撰寫Prompt：
C-Context（上下文脈絡）：說明這個功能在系統中的位置與目標。
R-Role / Requirement（角色與具體需求）：明確列出要實作的功能細節。
I-Inputs & Outputs（輸入與輸出）：定義Data Schema、API參數與傳回值結構。
S-Constraints（限制條件）：明確指出不能做什麼與技術規範（例如：必須使用 Server Component、禁止外部套件）。
P-Pattern / Proof（參考範例與驗收標準）：給予期望的結構參考或Corner Cases。
壞的Prompt：
幫我寫一個待辦事項（Todo）元件，要可以新增和刪除，用API存資料。

好的規格書Prompt範例：

@components/todo/(請參考目前的元件結構)

任務目標

請幫我建立一個用於管理待辦事項的客戶端元件TodoList.tsx。

功能需求 (Requirements)

1. 展示待辦事項列表，包含標題、完成狀態（Checkbox）與刪除按鈕。
2. 上方提供輸入框與新增按鈕，支援按下 Enter 鍵直接新增。
3. 支援標記完成狀態（Toggle Complete）與刪除功能。

資料結構 (Data Schema)

interface TodoItem {
id: string;
title: string;
isCompleted: boolean;
createdAt: string;
}

技術限制 (Constraints)
請使用React Hooks (useState / useOptimistic)進行本機狀態管理。
樣式請使用Shadcn UI的Button, Input, Checkbox元件。
暫時不要串接後端API，寫一個 mockTodos假資料作初始狀態。
邊界條件（Corner Cases)
輸入框為空或全為空白字元時，禁止新增並提示錯誤。
標題超過50個字元時需進行截斷顯示。

3.Context脈絡管理的三大鐵則

寫好Prompt後，如何把正確的背景資訊送給AI是另一個決定勝負的關鍵

[相關檔案@file] + [規格書Prompt] + [核心文件@docs]
避免：將無關的完整目錄 (@Codebase) 一股腦餵給AI

鐵則一：精準投放（Minimal Context Principle）
只丟相關檔案：寫前端組件時，只@該組件與其對應的Type定義檔。
避免過度開啟全域對話：不要長年使用同一條對話視窗。當討論主題切換（從寫UI切換到修API）時，開啟新的 Chat Session，避免舊的歷史紀錄干擾AI推理。

鐵則二：使用文件標籤(@docs)鎖定版本
LLM的訓練資料有截止時間，對於新版套件（Next.js App Router、Tailwind v4、Prisma v5）常會混淆舊語法。在Cursor中，透過添加 @docs 指向官方文件，能大幅減少語法錯誤。

鐵則三：利用.md建立專案記憶庫
在專案中建立docs/architecture.md或docs/spec.md，記載資料庫欄位與API規格。對話時直接@docs/spec.md，AI就能瞬間掌握整體的專案全貌。

一個好的Vibe Coding開發者，寫Prompt的時間往往比寫Code還少，但思路卻無比清晰。

透過CRISP框架+精確Context控制，你就能掌控AI的輸出品質，讓產出的Code一發命中，省去後續來回修改的時間。