表单验证的提示词，看起来只是几个字的小事，但要真正覆盖五种技术视角、每条字数控制在22字以内、还带上可操作动词和明确拒绝原因……这个任务比想象中更容易走样。下面这套方法，是我从多个真实项目中摸爬滚打总结出来的，照着做基本能一次到位。

明确表单字段语义与业务约束

第一步，先给Cursor搭好舞台。打开它，新建一个名为 form_rules_prompt.md 的文件。这可不是随便起名字，它是后续所有对话的上下文容器，没有它，后面问的问题就容易跑偏。

文件头部必须压上一句“定场诗”，写清楚我们要什么：「请为以下表单字段生成5类提示词——每类对应一个技术视角，不重复、不抽象、带具体触发条件和输出示例」。这句话是关键，是AI理解你“五路并进”要求的唯一锚点。缺了它，它大概率会给你回一堆“必填项”之类的通用内容。

紧接着，用代码块把真实字段摆上桌，清清楚楚，别用伪代码糊弄：

email: 用户注册邮箱，需验证域名有效性（如拒绝 @qq.com 但允许 @gmail.com），且后端已启用SMTP预检；  
phone: 中国大陆手机号，支持+86前缀，不允许空格或横线；  
password: 至少8位，含大小写字母+数字，不含常见弱密码子串（如123456、password）；  
nickname: 2–12个汉字/英文字母/下划线，禁止emoji和全角符号。

分角度生成提示词模板

明确了语境，接下来有三条路可以选，每条都能绕开“什么都能套但什么都不够精准”的坑。

方法一：触发条件+文案+技术说明三段式

这是最经典的结构，但每个字段必须严格按顺序走完五个角度，用 → 符号把整个逻辑链条串联起来。举个例子，针对 email 字段的无障碍视角，它应该长这样：用户用键盘Tab聚焦到邮箱框 → 屏幕阅读器读出一段清晰的说明（“邮箱地址需为有效商业域名，例如name@company.com，当前输入xxx@qq.com不被接受”）→ 这段文案直接绑定到 aria-describedby 属性上。整个过程要讲清楚谁来消费、如何消费。

方法二：用角色代入法强制区分视角

当五个角度写出来感觉都是一个味道时，就用这招。对Cursor说：“你现在是前端工程师，请写UI反馈角度的提示词”。等它写完后，清空对话历史再发：“切换身份，现在你是W3C无障碍专家，请重写同一字段的提示词”。角色切换会迫使它动用不同的知识库，从而写出真正有差异性的内容。务必记住，每次切换后必须清空历史，否则它会偷懒沿用上一轮的思路。

方法三：反向约束生成

这招比较高级，利用的是人类的否定心理。先写一条反面教材，比如“邮箱格式错误”，然后命令Cursor：“生成5条提示词，每条都必须包含可操作动词（如‘请更换’‘请补全’）、明确拒绝原因（如‘QQ邮箱暂未开通验证通道’）、且长度控制在22字以内”。你给出一个坏样本，它为了避开，自然会绞尽脑汁想出更好的。

校验提示词是否真正多角度

写完了别急着收工，得用四把尺子量一量，才能保证这堆提示词真的能用、好用。

第一步：建立Excel校验库

把所有提示词一股脑扔进Excel，A列写字段名，B列写角度类型（用户输入校验、UI反馈等），C列写文案内容。这是最原始但最有效的去重和分类手段。

第二步：验收国际化适配

筛选B列为“国际化适配”的所有行，逐条检查。合格的提示词必须包含 locale 占位符（如 {{error_email_domain}}），并且有明确的回退机制说明（例如“若zh-CN缺失则回退至en-US”）。缺任何一项，都不是真国际化，标红删除。

第三步：实机测试UI反馈

随机挑3条UI反馈类的文案。在Chrome开发者工具中模拟 focus → blur 事件，看看这条文案能不能直接赋值给 element.title 或者塞进 aria-live 区域。不能直接用的，就是纸上谈兵，必须删掉重写。

第四步：后端错误码匹配测试

剩下的文案按角度分组后，每组挑一条最有代表性的。复制粘贴进Cursor，并提问：“如果后端返回 status=422 且 detail=[{'field':'email','code':'domain_blocked'}]，这条提示词能否无修改匹配该错误码？”如果Cursor回答“否”，说明你的文案和后端的错误码体系脱节了，需要立即重构，让前端提示和后端报错能对应上。