用 Jev 构建动态表单和工作流

Jev 能决定表单的下一步吗？

可以，前提是所有可能的下一步都已经事先写好。静态表单依据精确的值来分支：如果设备是笔记本电脑，就显示笔记本电脑那一部分。自由文本的回答会让这套逻辑失效，因为“是我把它摔了之后才开始的”对不上任何一个下拉选项。Choice 问题可以读取目前已有的回答，从你准备好的后续问题中选出一个。字段、校验，以及提交之后发生的一切，仍然由你的表单负责。

打开可编辑的下一个问题模板。其中有一份虚构的设备支持申请，包含 3 条回答和 4 个可能的后续问题。载入只会建立草稿，主动点击检查才运行。

把后续问题写成附带理由的选项

一定要留一个停止的出口。否则表单会一直问下去，因为总得有某个选项胜出。法律或安全方面的必答问题不要交给模型决定：只要某个字段是必填的，就每次都由代码来问。

每次只改一项，再比较结果

1. 运行模板，记录选中的后续问题及其他选项的概率。
2. 把问题描述换成“最近一次系统更新之后，屏幕开始闪烁”，再运行一次。
3. 添加一行“保障计划：有效期至 2027 年”，看关于保修的那个问题是否变得没有必要。

模板没有预填正确答案，运行几次也不等于测试了你的表单。上线之前，请收集真实或贴近真实的未填完的表单，写下一位训练有素的同事会接着问什么，再作比较。

在一个请求里问多个问题

在你自己的集成中，一个请求可以携带多个问题。TypeSafe 的推测式扇出模式把可能用到的问题一并发出，其中包括最后也许用不上的问题，再由代码只读取与所选分支相关的答案。其文档称这些问题是并行评估的，因此多加几个问题通常对响应时间影响很小。对表单来说，这意味着一次调用就能返回类别、用户是否提供了订单号、语气是否表明需要安排电话回访，然后由表单决定显示什么。本站的自定义编辑器每次检查只问一个问题，因此它演示的只是这种设计中的一步。

社区做过哪些尝试

一个密码管理器团队在 2026 年 9 月 17 日分享了一项实验：用 Jev 识别复杂网页表单中的字段，取代手写规则。帖子里的改进幅度和延迟数字都是作者自己给出的，来自他们自己的测试页面；这些数字尚未经过独立复现，作者也说明这是一项实验，而不是全面部署。更多例子见项目案例页。

模型可能误读反话、多种语言混用的文字，或填错了字段的回答。请给用户留一个看得见的入口，让他们能手动进入每一个分支；发布之前，请先了解 Jev 的能力与限制。