豆包前端表单：规则提示词让AI先输出结构

强制AI先输出结构再写代码

与AI沟通时，不要直接说“帮我校验表单字段”，那样AI大概率会直接抛出一堆正则表达式。正确做法分三步：

第一步，明确要求：在输入框中逐字粘贴以下提示词，缺一不可——

“你是一名前端架构师，负责将业务需求转化为可交付的表单校验体系。请先输出【表单结构定义】，再基于该结构生成校验规则代码。【表单结构定义】必须包含三项硬性内容：①字段名列表（英文小写，下划线分隔）；②每个字段的类型（string/number/boolean/date/email/phone）；③每个字段的必填性（required/optional）。”

第二步，堵死AI绕过去的惯性路径：追加一段否定式约束——

“禁止将结构混在代码注释里；禁止用‘建议’‘通常’等软性表述；禁止在未输出【表单结构定义】前生成任何正则表达式、validator函数或schema对象。”

第三步，绑定真实字段锚点：最后加上具体字段，防止AI泛化输出——

“已知表单字段为：user_name, email, phone, age, is_agreed”

三步完成后，AI才会老老实实先输出结构，而不是跳过定义直接写代码。

验证结构是否合格的三道卡口

结构输出后不能直接信任，需要亲手验证。以下三招比较实用：

卡口一：检查字段名与类型是否一一对应
拿到AI输出的结构后，立即核对每个字段是否都明确标注了类型。例如字段phone应该对应string，而不是写成“手机号”。一旦出现中文描述或模糊类型（如将类型写成“日期字符串”），说明结构不合格，必须退回重写。原则：所见即所得，不允许任何模糊表述。

卡口二：反向压力测试
将AI输出的结构单独复制出来，作为新提示词输入豆包：“按以下结构定义，生成一个违反它的校验规则：【粘贴刚输出的结构】”。如果AI能成功写出email: { type: 'number' }这样明显错配的规则，说明结构边界清晰，不怕被误读；相反，如果AI表示“无法构造”，则说明结构本身缺失了关键维度。能经得起反向测试的结构才是可靠的。

卡口三：对接Zod Schema可行性验证
拿AI输出的结构，手动尝试转成Zod基础声明。例如email字段能否拆成z.string().email()？age字段能否写成z.number().min(0).max(120)？如果某个字段无法映射到Zod原生类型——比如“date”字段未注明是ISO字符串还是Date对象——就说明结构缺少序列化约定。这一关过不去，后续自动化注入就是空谈。

结构输出后的下一步操作路径

结构确认无误后，后续落地路径非常清晰：

① 确认字段名与后端API字段完全一致（注意大小写和下划线位置）→
② 标出需要特殊校验逻辑的字段（如phone需匹配+86前缀、email需防disposable域名）→
③ 指定校验触发时机（blur时？submit时？还是实时？）→
④ 要求AI按Zod Schema格式输出完整可运行代码，并且每个字段校验链必须附带中文错误提示。

四步完成后，前端与后端的对接点才算真正落到实处。与AI沟通的关键不是让它多聪明，而是先帮它搭好骨架，再填充血肉。结构定义这一关把牢了，后面的校验逻辑自然顺理成章。