表单规则提示词的生成，绝不能只停留在“必填”或“格式错误”这种通用文案上。正如标题所言，必须覆盖用户理解、开发实现、测试验证、无障碍访问这四大维度，每个字段的提示词都要基于真实的业务意图来设计。例如，手机号字段不只是“用于登录”，而是“作为实名认证主标识，需与运营商实名库比对，且同一账户仅允许绑定一个有效号码”。这个底层逻辑一旦漏掉，后续所有的提示词都会偏离实际风控场景。

换句话说，先打开产品需求文档或与后端接口定义对照，逐个确认每个字段在业务流程中承担什么角色。把业务约束写成一句话，用“必须”“禁止”“仅当”这些强逻辑词来表述，别用“建议”“尽量”这类模糊表达。这一步是地基，地基不牢，后面全是空中楼阁。

明确表单字段的真实业务意图

做这件事的关键在于：每个字段到底为什么存在？比如手机号字段，它不仅仅是让用户填一串数字，而是作为实名认证主标识，需要与运营商实名库比对，且同一账户仅允许绑定一个有效号码。这一层业务意图搞清楚了，才能写出有灵魂的提示词。

把每个字段的业务约束写成一句话，用“必须”“禁止”“仅当”等强逻辑词，避免“建议”“尽量”这类模糊表述。这样，开发、测试、甚至产品经理都能对字段的边界达成共识。

拆解用户可能出错的典型路径

那么，具体该怎么拆解？从用户的操作流入手是最实用的方法。

填写→失焦→提交→校验失败→修改→再提交。在“失焦”环节，提示词要足够轻量，比如“请输入11位手机号”；在“提交”环节，提示词需要带上下文，比如“手机号未通过实名认证，请核对是否为本人登记号码”。

另外，模拟三类高频错误场景也很有必要：
① 格式类：邮箱少@、身份证末位X写成小写x——注意，这里X必须大写，否则公安库校验失败；
② 逻辑类：结束日期早于开始日期、优惠券使用时间超出有效期；
③ 环境类：iOS Safari下日期控件不触发onchange、微信内置浏览器禁用clipboard API导致粘贴校验失效。这些场景不在前期考虑进去，测试阶段就会炸锅。

适配不同技术实现层的提示载体

提示词最终要落到具体的载体上，而不同载体要求截然不同。

首先，区分HTML原生属性提示和JS动态提示。title属性仅作为hover辅助，aria-describedby必须绑定到对应input的id，而Formik/Yup的error.message是纯文本，不能直接塞进aria-live区域。

其次，为每种载体设计差异化文案长度。title：不超过30字符，不换行，例如“密码需含大小写字母+数字”；aria-live区域：支持完整句子，可包含动作指引，例如“密码强度不足：请至少输入8位，包含1个大写字母、1个小写字母和1个数字”；表单底部全局提示栏：允许带链接，例如“忘记密码？点击重置”。

最后，检查各载体是否被屏幕阅读器正确朗读。给required字段加aria-required="true"，但不要同时设required属性又设aria-required，否则会造成重复播报。

注入无障碍与本地化预埋点

这一点常被忽略，但极其关键。在文案中预留占位符而非硬编码值：把“请输入6位验证码”改成“请输入{length}位{type}验证码”，其中length和type由JS动态注入。这样既能支持多语言（英文版自动变为“Enter {length} digit {type} code”），也方便视障用户配合语音合成引擎理解数值含义。

同时，避免使用颜色单独传递状态信息。所有“红色错误提示”必须同步有图标和文字说明，比如 ❌ 电话号码格式不正确，而不是仅靠红色文字。这才是真正的无障碍设计。