Forms did five things. Natural language kept one. 这句话如果只看字面像是在比较表单和自然语言谁更先进。放在 AI 应用开发的语境里它其实是一个很值得拆解的架构问题传统表单界面过去承担了哪些职责当交互入口从下拉框和输入框变成一段自然语言时哪些职责真正消失了哪些只是换了个位置这篇文章不谈某个具体开源项目而是讨论一种交互范式变化表单在过去业务系统里承担了五件事自然语言交互只“保留”了其中一件。文章会拆解表单的五项职责解释自然语言保留的那一项是什么再给出一套“自然语言转表单数据”的可落地实现思路。后面还会讨论表单与自然语言混合交互的工程范式、常见坑位和设计原则。适合读这篇文章的读者有三类正在做大模型应用开发的工程师想在业务系统里加入自然语言入口的前端开发以及负责企业级表单流程设计的产品经理。读完你至少能回答一个问题到底有没有必要用自然语言替换现有表单替换时应该保留哪些边界1. 核心信息速览在做技术拆解之前先把文章的核心信息放在一张表里方便快速判断这篇文章是否值得继续读。项目内容核心议题传统表单交互与自然语言交互的职责分工表单的五个职责意图采集、输入约束、流程引导、结构化输出、校验反馈自然语言保留的职责用户意图表达也就是“把需求说出来”被转移的职责校验、流程引导、结构化输出等转移到 LLM 与后端系统承担适合读者LLM 应用开发、前端工程师、产品经理、企业系统架构师技术落地方式自然语言预填表单保留原表单作为校验和兜底推荐切入场景咨询量大的简单表单、工单创建、报销单预填、搜索筛选主要风险模型输出不可信、字段缺失、权限绕过、延时增加这里先给一个核心结论自然语言交互不是把表单做没了而是把表单的一部分工作转移到了模型和后端。如果你只在前端放了一个对话框后面没有 Schema、校验和兜底流程那这个自然语言功能大概率只能在演示环境里跑通很难安全进入生产环境。2. 表单曾经承担的五项职责要理解“Forms did five things”必须先定义清楚是哪五件事。不同团队对表单的理解可能不同但从业务系统交互的本质看表单通常承担以下五项职责。2.1 采集用户的真实意图表单本质上是一套固定的“问答脚本”。业务系统不太可能一开始就理解用户的自然表达于是通过字段设计把“用户要做什么”翻译成系统能看懂的数据。举个例子一个报销单里的“费用类型”字段使用下拉框选项是“交通费、餐饮费、住宿费、办公用品、其他”。用户可能原本想说的是“我打车去了客户现场”但在表单交互下只需要选择“交通费”即可。这个过程看起来是选择实际上是系统在帮用户做意图分类。这一项职责是表单最核心的价值让用户在不需要理解后端数据结构的前提下用最少成本说清楚自己需要什么。2.2 约束输入范围与格式表单第二个职责是约束输入。邮箱、手机号、日期、金额、状态值每一种类型都由控件本身或前端校验规则保证格式合法。一个日期字段会弹日期选择器用户不需要知道后端要求的是yyyy-MM-dd还是时间戳一个金额字段会限制只能输入数字避免用户写“大概86块”这种系统无法直接处理的文本。这种约束的价值体现在数据质量上。系统在拿到表单提交的数据时基本可以默认它符合业务要求除非用户绕过前端直接调接口。2.3 呈现业务规则与约束业务规则不只存在于后端代码里也需要在交互层让用户提前感知。典型的例子包括请假单中“请假天数不能超过剩余年假”报销单中“发票金额必须填写”“备注不能超过200字”审批流中“部门经理表单不能直接提交到财务”表单用必填标记、置灰控件、提示文案、动态显隐等方式把规则前置到输入阶段。用户不需要自己去翻后台规则文档照着表单填大概率不会踩到业务红线。2.4 引导用户完成多步流程复杂业务不会一屏展示完。比如入职登记、采购申请、合同审批往往有步骤条、分页、草稿箱、暂存和提交。表单承担了“流程导航器”的职责告诉用户现在在哪一步、下一步是什么、前面是否有未完成的必填项。这个职责与后端流程状态机是强绑定的。表单当前展示的字段往往依赖前面步骤的输入结果。步骤之间还可能存在联动规则比如选择“住宿费”之后需要展示“酒店名称”和“入住日期”。2.5 生成结构化数据输出表单最后一个职责是生成结构化数据。用户在界面上输入的每一个值最终都要映射为后端数据结构中的字段名、字段类型和字段关联关系。后端接口通常接收的是类似下面的对象{ expense_type: 交通费, amount: 86.0, date: 2025-04-12, note: 客户现场拜访打车 }表单的每个输入控件在开发时就已经绑定了一个字段名前端把控件值收集起来转换成接口要求的 JSON 格式。这个环节是表单系统价值的最终体现不是页面好看而是数据可以进入审批流、财务报表、BI 分析。基于以上五项职责传统表单在业务系统中的定位可以概括为一句话在用户和系统之间建立一条低错误率的结构化通道。每一项职责都在压低“用户表达”和“系统理解”之间的偏差。3. 自然语言只保留了一件让用户直接表达意图那自然语言交互保留了表单五件事中的哪一件答案是第一件采集用户的真实意图。自然语言界面的核心能力是允许用户用一段话描述需求例如“我4月12号打车去客户现场花了86块钱帮我记一笔交通费。”“ 我想请三天假从下周一开始理由是家里有事。”“我要申请一台16G内存的开发机用途是跑本地大模型。”用户不需要知道系统内部有没有expense_type、leave_start_date、machine_spec这些字段也不需要知道某些字段是必填、某个枚举值叫什么。他要做的只是把自己脑海中的需求说出来。从交互体验上看自然语言确实比表单更“像人”。但这里有一个关键问题自然语言只承担了“表达意图”这一件事表单原本承担的其他四件事并没有被自动解决。输入范围和格式约束怎么办业务规则和流程如何让用户感知多步骤流程怎么引导结构化数据由谁来生成这些职责不会因为界面从表单变成了对话框就凭空消失。它们只会转移到系统侧由 LLM、规则引擎、后端服务继续承担。这就是“Natural language kept one”这句话的真正含义自然语言没有消灭复杂的业务数据链路只是把复杂度的位置移动了。如果团队没有意识到这一点很容易做出一个“有一块聊天框但完全没有业务闭环”的 AI 功能。用户说话之后模型确实理解了意图但系统拿不到合法结构化数据后续审批流、财务校验、权限控制全部接不上最终这个功能只能停留在 Demo 阶段。4. 为什么最终只剩“意图表达”架构职责发生了迁移从系统架构视角看表单把大部分职责放在 UI 层靠页面控件和前端校验保证数据质量。自然语言交互则把同样的职责推给了模型、后端和中间逻辑层。用户输入一段自然语言之后系统通常需要完成以下环节意图识别用户到底想做什么操作实体抽取从文本中提取字段值字段映射把实体对应到业务 Schema 中的字段名和枚举值缺失追问发现必要字段不足时主动向用户询问规则校验检查金额范围、日期合法性、业务约束结构化输出生成后端可以接收的数据对象兜底处理模型失败或输出不可信时回退到人工/表单模式这七个环节里真正属于“用户界面”的只有第一个和最后一个动作中的用户输入部分。其余环节都是工程侧要解决的工作。更直接地说自然语言交互把原本放在前端的约束逻辑搬到了模型和系统层。表单时代的“因为前端已经限制了所以数据基本合法”这种安全感在自然语言时代不存在了。模型可能输出非法 JSON、可能把金额识别成字符串而不是数字、可能漏掉一个重要字段甚至还可能编造一个不在业务枚举里的费用类型。所以自然语言保留的是“表达意图”这一项不是因为它只配做这一件事而是“让用户说出来”是模型最擅长也最值得替代的部分。剩下的部分需要复杂系统的校验能力来兜底。这也是“Forms did five things. Natural language kept one”在架构意义上的正确读法。5. 一个可落地的实现自然语言转表单数据下面用一个通用示例来演示“自然语言预填表单”的完整链路。假设业务是一个报销单需要包含四个字段费用类型、金额、发生日期、备注。一个用户可能输入我4月12号打车去客户现场花了86块钱帮我记一笔交通费。我们需要把它转换成以下结构化数据{ expense_type: 交通费, amount: 86.0, date: 2025-04-12, note: 客户现场拜访打车 }5.1 定义业务表单 Schema第一步是先定义一份 Schema它是表单和自然语言共同遵守的“唯一事实来源”。以 JSON Schema 为例{ type: object, properties: { expense_type: { type: string, enum: [交通费, 餐饮费, 住宿费, 办公用品, 其他] }, amount: { type: number, minimum: 0 }, date: { type: string, format: date }, note: { type: string, maxLength: 200 } }, required: [expense_type, amount, date] }这份 Schema 定义了字段类型、允许的枚举值、必填项和长度限制。在传统表单里这些约束靠页面控件实现在自然语言模式里约束会被写进 Prompt并在模型返回后用同一份 Schema 再做一次校验。5.2 让模型输出结构化 JSON第二步是调用大模型接口要求模型根据用户文本输出符合 Schema 的 JSON 对象。这里以常见的 OpenAI 兼容接口风格为例实际项目需要替换为自己的模型地址、密钥和模型名import requests # 这里按你自己的服务地址修改例如本地 vLLM / Ollama / 中转服务 API_URL http://127.0.0.1:8000/v1/chat/completions MODEL_NAME your-model-name system_prompt 你是表单填写助手。用户会输入一段自然语言你需要从文本中提取报销单字段。 字段定义如下 - expense_type费用类型只能是 [交通费, 餐饮费, 住宿费, 办公用品, 其他] - amount报销金额数字 - date报销日期格式为 yyyy-MM-dd - note备注简短说明 只输出一个 JSON 对象不要输出其他解释。 user_input 我4月12号打车去客户现场花了86块钱帮我记一笔交通费。 payload { model: MODEL_NAME, messages: [ {role: system, content: system_prompt}, {role: user, content: user_input} ], temperature: 0.1, response_format: {type: json_object} } response requests.post(API_URL, jsonpayload, timeout60) data response.json() # 从响应中取出模型输出内容 content data[choices][0][message][content] print(content)这里有两个前提需要注意部署的模型不一定支持response_format: json_object如果不支持可以从content里解析 JSON 代码块。模型输出只是“候选数据”不能直接当作最终结果写入业务系统。如果要用 curl 验证接口也可以使用类似下面的方式curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: your-model-name, messages: [ { role: system, content: 你是表单填写助手只输出 JSON 对象。 }, { role: user, content: 我4月12号打车去客户现场花了86块钱帮我记一笔交通费。 } ], temperature: 0.1 }5.3 用 Schema 校验模型输出第三步是校验模型返回的 JSON。这一步绝不能省略。模型可能在枚举值上出错比如把“交通费”写成“出租车费”也可能把金额86.0返回成86元这种字符串。下面是一个通用的校验函数import json from jsonschema import validate, ValidationError def check_llm_result(raw_content, schema): # 如果模型返回文本带有 json 包裹先做清理 cleaned raw_content.strip() if cleaned.startswith(): cleaned cleaned.strip() if cleaned.startswith(json): cleaned cleaned[4:] try: result json.loads(cleaned) except json.JSONDecodeError: return False, result_error(JSON 解析失败, raw_content) try: validate(instanceresult, schemaschema) except ValidationError as e: return False, result_error(f校验失败: {e.message}, result) return True, result def result_error(reason, data): return {error: reason, raw: data}校验通过后再把数据回填到原来的表单页面。这里就可以进入混合交互模式用户看到自己刚才说的内容已经被自动填好了只需要确认或修改最后再点提交。5.4 缺失字段自动追问模型输出会漏字段。比如用户只说了金额和日期没有说费用类型。这时不应该把数据直接提交而是需要进入一个“补全环节”。一个简单的思路是把模型返回结果和required字段做对比找出缺失字段然后生成一个动态表单或让模型在对话里继续追问。def find_missing_fields(submitted, schema): required schema.get(required, []) missing [] for f in required: value submitted.get(f) if value is None or value : missing.append(f) return missing如果缺失字段很多直接回退到原表单让用户填写效率更高如果只缺一两个字段可以用自然语言追问例如“您这笔报销属于哪个费用类型”。这样既保留了自然语言的便捷性又不至于让用户和模型反复对话五分钟。6. 表单与自然语言混合交互范式自然语言和表单不是谁取代谁的关系。在真实业务系统里更推荐的方式是混合交互。根据场景复杂度可以采用三种模式。6.1 模式 A自然语言预填表单用户先通过对话描述需求系统把提取到的字段回填到原表单用户确认后提交。这种模式对现有系统的影响最小适合已经存在成熟表单的业务场景。优点保留原表单的完整校验和流程能力用户不需要学习新交互仍能看到字段模型出错时用户可以直接修改6.2 模式 B对话补全缺失字段用户描述需求后系统在对话中自动追问缺失字段收集完整后再提交。适合字段较少、流程较简单的工单系统。典型流程用户输入意图系统提取已知字段系统判断缺失字段系统在对话中发起追问用户补充后再次校验最后提交后端流程6.3 模式 C纯对话 后端强校验对于探索型、非强流程场景比如智能客服、帮助中心、文档检索可以使用纯对话方式。但前提是后端必须有强校验和兜底不能直接让模型输出进入核心数据库。经典反例是用户对机器人说“帮我删掉本月所有报销单”模型识别为“删除操作”结果没有二次确认、没有权限校验数据直接被删。这就是典型的权限和确认逻辑缺失。一张表总结三种模式的适用场景模式入口兜底方式适合场景自然语言预填表单对话/搜索框原表单校验报销单、工单、请假、申请对话补全字段对话动态 Schema 校验字段较少的简单表单纯对话对话后端强校验 人工审核客服、知识库检索、探索性功能6.4 复杂流程建议保留表单多角色审批、预算联动、强合规约束、步骤依赖等复杂流程不建议直接用自然语言替代整个表单。这类流程中用户需要明确感知每个字段背后的规则也需要可视化的步骤确认。一个可行的折中方案是复杂表单前增加一个自然语言入口帮助用户先预填一部分字段后续步骤仍然回到表单界面。这样既降低了填写门槛又保住了流程的严谨性。7. 工程落地中的重点与排查在自然语言转表单的落地过程中以下问题几乎一定会出现。下面给出一份排查清单。问题现象可能原因排查方式解决方案模型输出不是合法 JSON模型不支持 JSON 模式、返回了解释文字、输出被截断打开原始响应日志查看content原文改用支持 JSON 模式的模型或在 Prompt 中强制只输出 JSON再清理代码块包裹字段值不在枚举内用户口语说法和业务枚举差异较大模型按字面输出检查模型输出和历史失败样本在 Prompt 中补充枚举值对应的同义词增加 few-shot 示例必填字段缺失用户输入本身没有该信息模型“不敢猜”检查返回字段和required对比增加缺失字段追问流程或回退到原表单模型“幻觉”补充了不存在的字段业务 Schema 告诉模型有太多自由发挥空间对比模型输出与 Schema 字段集用 JSON Schema 的additionalProperties: false禁止多余字段金额/日期格式错误模型输出字符串类型例如86元或4月12号校验类型和格式在 Prompt 中给明确格式示例再在代码层做类型转换接口延迟过高模型推理慢、Prompt 太长、并发不足记录每次请求耗时统计对话轮数使用小模型、精简 Prompt、增加缓存、减少无关历史轮次权限和审批被绕过系统直接把对话结果写入数据库未做后端权限判断检查提交接口是否对模型输出做了过滤权限判断只能放在后端LLM 只负责生成候选数据批量调用时接口不稳定并发过高或依赖外部服务限流观察超时和返回码增加重试机制和失败队列对离线批量任务增加 sleep这里特别强调两个原则第一任何模型输出都不能直接作为最终业务流程数据。它只能作为“预填写候选”必须经过 Schema 校验、人工确认或后端规则引擎验证。第二对话交互只能影响“用户怎么输入”不能影响“谁能做什么”。审批权限、数据范围、操作类型这些必须由后端统一判断不能信任前端或模型的判断。8. 设计原则与最佳实践8.1 让 Schema 成为唯一事实来源表单字段、自然语言提取字段、后端接口字段最好都使用同一份 Schema 驱动。前端根据 Schema 渲染表单LLM 根据 Schema 抽取字段后端根据 Schema 校验入参。这样改动一个字段时各端保持一致不容易出现“模型输出有 note但表单里没有备注”的错位。8.2 校验必须双保险前端校验、模型校验、后端校验三层都要做。不能因为模型已经在 Prompt 里“看到了规则”就不再校验。Prompt 是概率约束不是硬约束。8.3 权限与流程判断放在后端自然语言界面很容易把用户带到“直接提交”的逻辑里。设计上一定要明确LLM 负责理解后端负责执行。任何删除、审批、提交操作都必须走原有权限链路。8.4 记录用户纠错数据当用户把系统自动填入的错误字段手动改掉时这条纠错数据是最有价值的训练数据。可以在前端埋点记录模型预填值、用户最终提交值、用户修改了哪些字段。等到积累一定量后可以用这些样本优化 Prompt 或微调模型。8.5 小流量灰度上线不要一开始就替换所有表单。选择一类高频、低风险的表单比如“工单创建”“简单报销”做成自然语言预填模式灰度给少量用户使用。确认提取成功率、用户修改率、提交成功率都稳定后再扩展到下一个场景。8.6 注意隐私和数据合规自然语言输入通常会被发送到模型服务。如果表单涉及个人敏感信息、人脸、身份证、医疗、财务等数据必须确认模型部署方式是否满足数据合规要求。内部私有化部署、敏感字段脱敏、访问日志审计这些都要在方案设计阶段考虑。9. 总结Forms did five things. Natural language kept one. 这句话可以理解为传统表单用界面结构同时完成了意图采集、格式约束、规则呈现、流程引导和结构化输出而自然语言交互最擅长替代的只是“意图采集”这一部分。其余约束、校验、流程和结构化能力不会消失只会转移到模型和后端系统里。如果你正在考虑给业务系统加入自然语言入口我的建议很直接不要一上来就做一个“完全取代表单”的对话系统。先挑选一个重复填写率高、字段相对简单的表单把自然语言作为预填入口保留原表单作为确认和兜底。等模型提取准确率、用户接受度和接口稳定性都验证通过后再逐步扩展。这个方向最容易踩的坑是只关注模型能不能理解用户的话而忽略模型输出是否通过了 Schema 校验、后端是否做了权限控制、用户是否还有机会修正错误。与其做一个看起来很智能却没法安全上线的聊天框不如先做一个“用户说话、表单自动填好”的可靠功能。自然语言改变的只是交互入口业务系统真正需要的依然是稳定的数据结构、明确的权利边界和可控的流程。