在给出任务之前先给出上下文

AI 没法像你那样看到你的项目。它不知道你的框架版本、你的文件结构，或者你早已确立的惯例。当你跳过这些时，它就靠猜——而且猜得很糟。更糟的是，它自信地猜。所以在它撞上你真实的代码库之前，输出看起来都挺像样。

对比同一个请求的这两个提示词。

添加一个校验邮箱的函数。

这是一个 TypeScript 后端，使用 Express，并用 Zod 做校验。
我们已经在 src/schemas/ 里用 Zod schema 校验输入。
按那种风格添加一个邮箱校验 schema。邮箱必须是
小写、最多 254 个字符，并拒绝来自 src/config.ts 里
现有 BLOCKED_DOMAINS 列表的一次性域名。

第一个提示词产出泛泛的代码，它可能用了一个你不想要的正则，风格也和你的代码库不匹配。第二个产出的代码你可以直接粘贴进去。规则是：陈述技术栈、惯例，以及 AI 应该复用的现有部件。

一个好的提示词把这些部件自下而上按顺序堆叠——上下文在底层，真正的请求靠近顶层：

        ┌──────────────────────────────┐
        │   示例                       │  一个输入 → 输出
        ├──────────────────────────────┤
        │   约束                       │  不该做什么
        ├──────────────────────────────┤
        │   边界情况                   │  空值、无效、错误
        ├──────────────────────────────┤
        │   输入 / 输出                │  类型与形态
        ├──────────────────────────────┤
        │   目标                       │  一个明确任务
        ├──────────────────────────────┤
        │   上下文                     │  技术栈、文件、模式
        └──────────────────────────────┘
              先打地基 ▲

在你敲下回车之前，一份有用的心理清单：语言和框架（如果版本要紧就连版本一起），相关的文件或模块，项目里已有的模式，以及 AI 该偏好或该避开的库。不必每次都凑齐这四样——但如果答案会因其中之一而改变，就把它点出来。拿不准时，把新代码要适配的那个真实签名、类型或配置直接粘上去。几行现有代码教给 AI 的惯例，远胜过一整段描述。