很多开发者写表单交互说明时，容易陷入一个误区：只写“用户点击后有反馈”，却没说清楚怎么触发、在哪响应、状态怎么变、异常了怎么兜底。结果前端拿到文档，第一行代码就开始报错。今天咱们聊聊，怎么写一份能直接落地到开发任务里的表单交互提示词。

先锁定平台与载体类型

打开当前项目部署环境文档，确认是微信小程序、Web网页还是App内H5。三者对“提示”的实现能力完全不同：微信小程序不能调用alert，Web端必须支持键盘焦点切换，App内H5需先用na vigator.userAgent判断是否支持clipboard API。没确认平台就写提示词，前端同学拿到后第一行代码就会报错。

在Trae提示词开头加一句：“你正在为【微信小程序】编写表单交互说明，所有动词必须匹配小程序原生组件行为（如wx:if控制显隐、bindtap触发、showToast仅限1秒内连续调用1次）。”

按用户操作流分层写提示词

第一个是失焦校验层。输入框失去焦点时，只显示最简规则。比如邮箱字段失焦后提示“请输入含@的邮箱”，不需要出现“格式错误”这种黑盒表述，用户看了也是一头雾水。

第二个是提交拦截层。点击提交按钮后，如果校验失败，提示信息必须带上下文动作指引。举个例子：“手机号未通过实名认证（运营商返回code=102），请核对是否为本人登记号码，并尝试重新发送信息验证码。”这样用户才知道下一步该做什么，而不是干瞪眼。

第三个是成功反馈层。提交成功后，别写“操作成功”这种废话，要写清楚跳转路径或状态变更。比如：“跳转至订单详情页，页面顶部toast显示‘已提交，预计30分钟内客服联系您’。”

用原子条件替代长句描述

把复杂的规则拆成一行一个条件，开发同学一目了然，测试用例也好写。比如密码规则，不要写“8-16位，必须包含大小写字母、数字和特殊符号”，而是拆成四行独立条件：

• 8–16位
• 含至少1个大写字母
• 含至少1个小写字母
• 含至少1个数字或!@#$%^&*中的任一符号

身份证号字段同样要暴露后端校验点：“18位，末位可能是X；X必须大写，小写x会被公安库拒绝。”

绑定真实DOM结构与可验证路径

在提示词中强制指定绑定关系：“错误提示必须插入到#email-input后面紧邻的中，不可使用全局弹窗。”这一步漏掉，前端同学会把提示塞进tooltip或modal里，导致屏幕阅读器无法聚焦、自动化测试脚本找不到目标节点。

如果表单用了AXUI框架，提示词要写明组件路径：“@trae/ui-kit/src/components/TextInput.vue → error slot需接收message prop并渲染为红色行内文本。”