先記住：Prompt 至少要有背景、目標、限制、驗收與交付。
需要深入時：再拆成多輪任務。

「你是資深工程師」之後，還是得把事講清楚

替 AI 加上專家角色，有時能改變回答方式，但無法取代規格。
假設任務只有「請用最佳實踐重構購物車」，它可能新增抽象層，也可能整套換掉，而這些都未必是你要的。

我把 Prompt 當成一份小型工作說明：
誰在什麼系統裡，為了什麼目的，要完成哪個可驗證的變化。

五段就足夠開始

Context 是脈絡：現有購物車由頁面管理草稿，報價來自服務層，使用 Vue 與 TS。
Goal 是目標：修正舊報價覆蓋新商品的問題。
Constraint 是限制：不改 API 契約、不清空草稿、不新增全域 store。
Acceptance 是驗收：A 先發後到時，畫面仍顯示 B 的結果。
Output 是交付：變更說明、關鍵程式與實際驗證結果。

這五段讓它們的價值在於讓「好一點」變成能確認的行為差異。

給限制，也要交代原因

「不要新增 store」如果只是個人偏好，可能擋住合理方案。
這裡的理由是報價狀態只活在單一購物車頁面，離開即失效，沒有跨頁共享需求。
寫出理由後，AI 若發現例外，也可以提出討論。
反過來，如果存在多頁共用的報價需求，我們可能就要重新檢查這個限制。
同樣地，「不能改 API」是因為此次授權只涵蓋前端修正，不代表後端永遠不能改。
別把任務限制誤當成宇宙定律，會讓設計越來越彆扭。

一段能直接使用的 Prompt

背景：購物車頁面管理商品草稿，服務層取得伺服器報價。
問題：使用者快速修改數量時，舊請求晚回會覆蓋新結果。
目標：只有對應目前商品版本的回應可更新畫面。
限制：沿用現有 API，不新增全域 store；失敗保留草稿；不要修改無關樣式。請先讀取相關實作與測試，說明資料流和修改計畫，再實作最小變更。
驗收：正常回應、A 先發後到、失敗保留草稿、離開頁面後不套用結果。最後區分實際執行的檢查與尚未驗證的環境。

這段沒有要求「寫出有效率的程式」，而是實際給一個具體問題及可觀察結果。
它用到 SA 的流程與不變條件，也接到 SD 的狀態責任。

檢查 Prompt 本身的漏洞

如果驗收只說「沒有 bug」，其實沒有說。
如果限制一邊要求保留介面，一邊又指定全新回傳型別，也有衝突。
發送前先讓自己扮演執行者，看看能否在不猜測的情況下開始。

提供檔案時只放必要脈絡，避免把無關規格混進來。
若內容包含公司資訊，也應使用團隊允許的工具與資料範圍，不把憑證當成測試素材。

今日練習與筆記

把「幫我優化這段程式」改成五段工作說明。
最重要的是寫出優化前的問題，以及優化後如何判斷改善。
接著會把 Prompt 的背景往前推一步：在切 Component 之前，先走完使用者流程。