在使用Cursor生成错误提示文案时，如果不在提示词（Prompt）中加入几条真实上线的参考样例，结果往往会是“操作失败，请重试”这类通用到让人无奈的表述。这类文案虽然在逻辑上没错，但放在具体的交互场景中，用户看完基本得不到有效帮助——既没有说明问题具体出在哪里，也不提供任何有意义的下一步操作指引。

原因其实很简单：错误文案从来不是孤立的文本。它需要嵌入按钮状态、表单校验、API响应处理、Toast弹窗、模态框等具体场景中。如果没有样例作为上下文参照，Cursor很难准确判断几个关键要素——语气应该温和还是严肃，责任归属是用户输入错误、网络中断还是后端服务异常，以及文案中是否需要附带具体的操作路径（比如“请检查邮箱格式”远比“邮箱有误”更实用）。

举个例子：你的项目里登录页的邮箱校验文案原本是“邮箱格式不正确，例如 name@example.com”。如果不把这个样例提供给AI，Cursor自己生成的可能就是“邮箱地址无效”这种抽象表达——既没给出正确的格式示例，也没有沿用你项目中习惯使用的“不正确”这个措辞。结果就是你得手动再改一遍，等于做了无用功。

那么，如何提供参考样例才能让Cursor真正理解你的需求？以下三种方式可以根据场景灵活选用。

• 第一种最简单：直接挑选2到3条已经上线的真实文案，连同它们出现的场景一起贴进去。比如：@login-form.tsx 中邮箱校验失败提示：“邮箱格式不正确，例如 name@example.com”；@payment-modal.tsx 中余额不足提示：“账户余额不足，请先充值”；@profile-api.ts 中头像上传超限提示：“头像文件不能超过 5MB，请压缩后重试”。这样一带，Cursor就能快速对齐你项目中文案的实际风格。
• 第二种方式适合文案风格尚未统一的早期项目：用结构化描述替代零散句子。比如直接在Prompt中写清楚规则：用户侧错误用“请…”开头，给出具体修正动作；系统侧错误用“无法…”开头，说明限制条件和数值边界；所有文案结尾不加句号；长度控制在20字以内。
• 第三条路是混搭——样例加规则一起上，这是最稳妥的做法。例如：参考以下已上线文案：“密码长度至少 8 位，需包含大小写字母和数字”“验证码已过期，请重新获取”。再结合规则：所有文案必须含具体数字或操作动词，禁用“可能”“建议”“应该”等模糊词。输出效果会稳定很多。

实际操作路径也很清晰：打开项目里存放错误提示的源文件（通常在 src/components/form/ValidationMessage.tsx 或 locales/zh-CN.json 这类位置），挑出至少两条语义清晰、场景明确的文案，连同其触发的具体条件一起写进提示词。最后在Prompt末尾加上一句硬性要求——“只输出新文案，不解释，不加引号，不换行”。

这步操作本身并不复杂，直接把文件拖进去即可。但一旦漏掉任何真实样例，Cursor大概率会从通用模板库里拿出一堆需要你手动改写的文案，相当于一切要从头开始。