在給出任務之前先給出上下文

AI 沒法像你那樣看到你的專案。它不知道你的框架版本、你的檔案結構，或者你早已確立的慣例。當你跳過這些時，它就靠猜——而且猜得很糟。更糟的是，它自信地猜。所以在它撞上你真實的程式碼庫之前，輸出看起來都挺像樣。

對比同一個請求的這兩個提示詞。

新增一個校驗郵箱的函式。

這是一個 TypeScript 後端，使用 Express，並用 Zod 做校驗。
我們已經在 src/schemas/ 裡用 Zod schema 校驗輸入。
按那種風格新增一個郵箱校驗 schema。郵箱必須是
小寫、最多 254 個字元，並拒絕來自 src/config.ts 裡
現有 BLOCKED_DOMAINS 列表的一次性域名。

第一個提示詞產出泛泛的程式碼，它可能用了一個你不想要的正則，風格也和你的程式碼庫不匹配。第二個產出的程式碼你可以直接貼上進去。規則是：陳述技術棧、慣例，以及 AI 應該複用的現有部件。

一個好的提示詞把這些部件自下而上按順序堆疊——上下文在底層，真正的請求靠近頂層：

        ┌──────────────────────────────┐
        │   示例                       │  一個輸入 → 輸出
        ├──────────────────────────────┤
        │   約束                       │  不該做什麼
        ├──────────────────────────────┤
        │   邊界情況                   │  空值、無效、錯誤
        ├──────────────────────────────┤
        │   輸入 / 輸出                │  型別與形態
        ├──────────────────────────────┤
        │   目標                       │  一個明確任務
        ├──────────────────────────────┤
        │   上下文                     │  技術棧、檔案、模式
        └──────────────────────────────┘
              先打地基 ▲

在你敲下回車之前，一份有用的心理清單：語言和框架（如果版本要緊就連版本一起），相關的檔案或模組，專案裡已有的模式，以及 AI 該偏好或該避開的庫。不必每次都湊齊這四樣——但如果答案會因其中之一而改變，就把它點出來。拿不準時，把新程式碼要適配的那個真實簽名、型別或配置直接粘上去。幾行現有程式碼教給 AI 的慣例，遠勝過一整段描述。