在实际产品和 AI 应用开发里交互设计一直存在两条路线一条是传统的表单填写另一条是用自然语言直接表达需求。最近经常看到这样一句讨论“Forms did five things. Natural language kept one.” 意思是传统表单完成了五件事而自然语言界面只保住了其中一件。这句话的真正价值在于提醒开发者把输入方式从表单切换成自然语言时表单原本承担的数据质量职责不会自动转移需要重新设计。做 Web 开发和后台系统时我们对表单的体感很明确字段、必填、校验、报错、提交。可一旦前端换成聊天框或自然语言输入框这部分体感会全部消失。用户输入一句话系统解析出意图然后呢缺失字段谁来补格式错误谁来拦数据归一化谁来做错误提示怎么反馈如果这些问题没有在架构层面重新安排自然语言界面就会把脏数据直接送进数据库体验提升了数据质量下降了。这篇文章不评价“表单派”和“自然语言派”谁更正确而是把那五件事逐个拆开分析自然语言到底保住了什么、丢掉了什么再给出一个可落地的混合方案自然语言负责表达表单负责边界LLM 负责抽取确定性代码负责校验收口。1. 拆解“五件事”表单不是采集工具而是一层数据协议1.1 先给表单一个准确的技术定位表单不是单纯的 UI 组件集合。从数据流的角度看表单是“人类意图”和“机器可消费数据”之间的协议层。协议的含义是它同时约定了数据的形状、数据的约束和数据的解释方式。一个表单背后至少有三类契约字段契约有哪些字段每个字段的类型、长度、是否必填。业务契约字段之间的依赖关系、合法性规则、默认值。交互契约用户如何知道该填什么填错了之后会得到什么反馈。这三类契约合在一起才是表单真正在做的事。很多系统把表单写得很简单只做了字段收集没有做约束校验所以数据质量问题最后全部暴露在报表和分析阶段到那时再清洗成本和风险都更高。1.2 表单完成的具体五件事第一件结构化。表单把用户脑子里零散的信息拆成固定字段。用户在表单里不会说“昨天中午和同事吃饭花了128”而是分别填金额、日期、支出项目、分类。这个过程的价值在于数据进入系统时已经是结构化记录下游不需要再做一层解析。第二件引导。表单通过标签、占位符、选项、必填星号告诉用户这里该填什么、填成什么样。用户不需要自己思考格式输入成本低出错概率也低。第三件校验。提交之前系统可以检查字段是否为空、格式是否正确、枚举值是否合法、金额是否为正数。校验发生在写入之前这是表单最重要的兜底能力。第四件归一化。同一个信息不同用户的表达不一样。表单通过输入框格式限制和提交前处理函数把“2024/3/1”“2024-03-01”“3月1日”统一成同一种日期格式把“128”“128块”“一百二十八”统一成数字 128。第五件纠错。表单可以做到字段级错误反馈“日期格式不正确”“金额必须大于 0”。用户看到提示后可以精准修改错误字段而不是把整句话重新说一遍。1.3 自然语言保留了哪一件被保留的那一件是表达层的能力也就是用户可以用自然语言直接把意图说出来。这是自然语言界面最大的优势也是它唯一默认继承下来的优势。但剩下四件结构化、引导、校验、归一化自然语言界面默认并不提供。用户输入“昨天中午和同事吃饭花了128”系统收到的是完整的一句话必须自己完成字段拆分、意图识别、格式转换才能得到和表单一样的结果。这个过程不一定稳定也不一定对用户可见。这里就出现一个关键判断自然语言替代表单替代的只是“输入交互”而不是“数据协议”。协议仍然需要存在只是它从用户可见的界面退到了系统内部的解析和校验逻辑。注意自然语言界面不是消灭表单而是让表单从“用户面对的界面”变成“系统内部的约束层”。2. 丢掉的那四件事会在真实系统里以什么形式爆发2.1 没有结构化约束解析结果直接污染数据库自然语言输入经过 LLM 抽取后返回的是 JSON。但 LLM 的输出天然不稳定字段可能缺失字段名可能变化枚举值可能落在预期范围之外。如果把这个 JSON 直接入库就会出现脏数据。举例支出系统要求分类只能是“餐饮、交通、住房、医疗、教育、其他”但模型可能输出“工作餐”“通勤”“房租”这类具体表达。这些词对用户来说是准确的对系统来说却是未知枚举。下游统计分类时会多出一堆无法聚合的类别。2.2 没有引导用户表达不完整时全靠追问表单里必填字段用星号标出来用户一眼就知道要填什么。自然语言界面没有这个机制。用户说“记一笔吃饭的钱”系统缺金额、缺日期只能靠对话追问。追问一轮可能还好追问三轮体验就会明显下降尤其是在移动端。2.3 没有归一化同一含义会变成多种存储值在没有输入格式约束的情况下模型输出的日期、金额、单位很可能不一致。今天输出2025-06-03明天输出6月3日后天输出June 3。下游 SQL 查询、报表聚合、数据统计全部依赖统一格式归一化必须单独处理。2.4 纠错成本从“改一个字段”变成“重说一遍”表单的纠错是局部的、低成本的。自然语言界面的纠错往往需要用户重新组织语言。比如用户说“报销打车费50昨天从公司到机场”系统理解错了日期用户只能纠正“不是昨天是前天”或者“日期应该是6月2日”。这种对话式纠错在字段较多、规则较复杂的场景下成本远高于表单。2.5 自然语言真正有优势的场景对于简单、字段少、意图明确的场景自然语言确实更好。比如“设置下午两点的提醒”“查一下这个月的支出总额”“把任务按优先级排序”这些动作往往只有一个核心参数表单反而显得繁琐。两种场景的对比对比维度复杂表单场景简单指令场景字段数量多有跨字段规则少通常只有一个核心参数输入确定性要求高不允许格式错误中容忍表达偏差纠错成本字段级纠错价值大重说一遍成本低用户熟练度低需要引导中高指令本身清晰推荐输入方式表单为主自然语言预填自然语言为主表单兜底所以正确的结论不是“自然语言取代表单”而是交互复杂度不同适合的输入方式不同。混合方案的核心思路就是让两种方式共存并共用同一套数据协议。3. 可落地的混合方案自然语言负责表达表单负责边界3.1 方案整体链路推荐方案不是二选一而是分层处理用户可以在表单里直接录入也可以切换到自然语言输入框用一句话描述需求。如果是自然语言输入系统调用 LLM 做意图识别和结构化抽取输出固定格式的数据。抽取结果回填到表单控件中用户可以看到、修改、确认。用户确认后走传统表单校验逻辑校验通过才提交入库。整个过程里LLM 只是“输入增强器”它把一句话翻译成表单里的字段值。真正保证数据质量的仍然是表单本身的校验层。这样设计的好处是即使模型抽取错误用户也有机会在提交前发现和修正。3.2 五件事的责任分配表表单五件事传统表单自然语言界面混合方案结构化字段定义LLM 抽取输出不稳定JSON Schema 定义LLM 按 schema 输出引导标签、占位符、选项无只能追问抽取结果回填表单用户可查看校验提交前规则校验弱或缺失保留原有校验逻辑提交前统一执行归一化输入处理函数不保证格式统一入库前调用格式化函数统一处理纠错字段级提示用户重新表述校验不通过时定位到具体字段提示3.3 为什么用 JSON Schema 作为事实标准在混合方案里JSON Schema 是连接表单、LLM 和校验逻辑的“事实标准”。表单字段由它生成或由它约束LLM 的输出要求由它描述校验规则也可以从它的定义推导。这样做的好处是三处逻辑使用同一个协议而不是各写一套后期修改字段时不会出现“表单改了、模型没改、校验没改”的问题。注意LLM 工具调用的 API 在不同 SDK、不同版本里名称可能不同落地前要先确认当前依赖版本支持哪种调用方式。4. 代码示例把一句话支出记录转成表单数据并完成校验4.1 定义支出表单的 JSON Schema先定义支出记录的结构。这里包含四个字段支出项目、金额、日期、分类其中分类限定枚举。{ type: object, required: [name, amount, date, category], properties: { name: { type: string, minLength: 1, description: 支出项目名称 }, amount: { type: number, minimum: 0.01, description: 支出金额单位元 }, date: { type: string, format: date, description: 支出日期格式 YYYY-MM-DD }, category: { type: string, enum: [餐饮, 交通, 住房, 医疗, 教育, 其他] } } }这个 schema 同时是表单渲染、LLM 抽取和提交校验的依据。注意enum字段它是分类字段唯一的合法集合后续所有校验都会围绕它展开。4.2 定义 LLM 的工具调用参数以常见的 function calling 风格为例让模型输出符合 schema 的结果。参数定义要和 JSON Schema 保持一致避免模型侧和表单侧出现字段漂移。{ name: save_expense, description: 根据用户描述保存一笔支出记录, parameters: { type: object, properties: { name: { type: string, description: 支出项目名称 }, amount: { type: number, description: 支出金额单位元 }, date: { type: string, description: 支出日期格式 YYYY-MM-DD }, category: { type: string, enum: [餐饮, 交通, 住房, 医疗, 教育, 其他] } }, required: [name, amount, date, category] } }这里要理解工具调用的边界模型的任务只是把用户表述中的信息抽出来按字段返回。模型不需要判断金额是不是合理也不需要判断日期是不是真实存在这些工作留给后面的确定性代码。4.3 校验逻辑不信任 LLM 输出LLM 返回 JSON 之后先解析再跑校验。下面这段 Python 示例只使用标准库不依赖业务框架方便直接理解思路。from datetime import datetime ALLOWED_CATEGORIES {餐饮, 交通, 住房, 医疗, 教育, 其他} def validate_expense(data): errors [] if not isinstance(data, dict): return [{field: _root, message: 解析结果不是对象}] name data.get(name) if not isinstance(name, str) or not name.strip(): errors.append({field: name, message: 支出项目不能为空}) amount data.get(amount) if not isinstance(amount, (int, float)) or isinstance(amount, bool): errors.append({field: amount, message: 金额必须是数字}) elif amount 0: errors.append({field: amount, message: 金额必须大于 0}) date data.get(date) if not isinstance(date, str): errors.append({field: date, message: 日期格式不正确}) else: try: datetime.strptime(date, %Y-%m-%d) except ValueError: errors.append({field: date, message: 日期必须是 YYYY-MM-DD 格式}) category data.get(category) if category not in ALLOWED_CATEGORIES: errors.append({ field: category, message: f分类必须是 {sorted(ALLOWED_CATEGORIES)} 之一 }) return errors这段校验函数有三个关键点。第一金额判断先排除布尔值因为 Python 里True也是int的子类。第二日期用strptime解析能拦截2025-02-30这种格式正确但日期不存在的输入。第三枚举字段做精确匹配不接受 schema 之外的任何字符串。4.4 回填与提交链路用伪代码描述完整的数据流。自然语言输入、LLM 抽取、回填表单、用户确认、校验、入库每一步都要有明确的出口。user_input 昨天中午和同事吃饭花了128 llm_result call_llm_tool(user_input, tool_schema) # 假设 llm_result 为 # {name: 午餐, amount: 128, date: 2025-06-03, category: 餐饮} form_values fill_form(llm_result) # 回填表单用户可见、可修改 confirmed user_confirm(form_values) # 用户点击确认按钮 errors validate_expense(confirmed) # 提交前执行校验 if errors: render_field_errors(errors) # 字段级错误回显用户局部修正 else: save_to_db(confirmed) # 校验通过后入库这段链路的核心原则是LLM 只在最前面负责翻译从校验开始后面全部是确定性代码。“昨天”转成具体日期应当由系统在运行时根据当前日期计算而不是依赖模型猜测。4.5 运行验证正常分支和失败分支正常输入用户输入: 昨天中午和同事吃饭花了128 LLM 输出: {name: 午餐, amount: 128, date: 2025-06-03, category: 餐饮} 校验结果: [] 入库结果: 成功失败输入用户输入: 记一笔打车费 LLM 输出: {name: 打车, category: 交通} 校验结果: - field: amount, message: 金额必须是数字 - field: date, message: 日期格式不正确失败分支触发后系统把错误提示回显到表单的对应字段。用户只需要补全金额和日期二次提交即可不用重新说一遍完整需求。这就是混合方案相对纯自然语言界面的核心改进纠错成本重新降回了字段级。5. 常见问题与排查思路5.1 LLM 输出字段缺失现象模型返回的 JSON 缺少必填字段甚至没有触发工具调用。可能原因工具描述的 required 没有写全或与 JSON Schema 不一致。用户输入本身信息不足模型没有能力补充用户没有提到的信息。检查方式先查看模型原始输出确认是模型漏字段还是提示词约束不足。检查工具调用参数中的 required 列表和字段 description 是否清晰。处理建议缺失字段不要直接报错让用户重说而是回填到表单中让用户补全。如果用户输入里确实没有日期可以默认填入今天并明确提示用户确认。5.2 金额和日期格式不统一现象同一条记录今天存的是128明天存的是128元日期有时候是2025-06-03有时候是6月3日。原因模型输出格式依赖提示词和模型本身不具备稳定性。工具参数里虽然写了 format也不是每次都生效。处理建议解析完模型输出后对金额和日期统一执行格式化函数。校验层不允许非规范格式通过宁可报错也不要等入库后再清洗。5.3 用户表达本身模糊现象“记一笔吃饭的钱”“随便”“差不多就行”。这类输入没有完整信息模型无法抽取。处理建议不要要求模型编造缺失字段。识别到关键字段缺失时回到表单让用户手动补或触发一轮最小追问例如“这笔花了多少钱”。5.4 表单校验通过但入库后发现枚举无匹配现象分类字段保存的是“工作餐”而不是“餐饮”。原因模型输出时把“工作餐”当成了分类的值而校验函数只判断了字段非空没有做枚举匹配导致数据放行。处理建议枚举字段一定做精确匹配校验不允许 schema 之外的字符串入库。在工具描述里明确枚举候选并提示模型只能从中选择。5.5 排查顺序建议按以下顺序定位问题能避免在错误层面浪费太多时间先确认模型原始输出是否正常例如是否真的调用了工具。再确认 JSON Schema 与工具调用参数是否一致有没有字段名漂移。接着确认校验函数是否覆盖全部必填字段和格式约束。然后确认失败分支是否把错误信息回显到了正确的表单字段。最后确认入库前数据是否已经通过格式化函数完成归一化。6. 最佳实践清单让自然语言界面不失控6.1 原则一交互可以变协议不能丢表单可以隐藏schema 不能隐藏。无论前端是聊天框、输入框还是语音输入系统都必须有一个明确的数据协议在支撑。脱离 schema 做自然语言录入等于把数据结构设计交给模型自由发挥这是最大的风险源。6.2 原则二LLM 只做翻译不做决策不要问模型“这个金额合理吗”“这单能不能通过审批”。模型擅长把一句话翻译成结构化结果但校验、判定、权限控制这些事项必须由确定性代码执行。涉及金额、日期、枚举、状态流转的逻辑全部要用代码写死。6.3 原则三必须给用户确认机会自然语言解析完成后不要直接入库。把解析结果展示给用户允许修改。这样既避免解析错误直接污染数据也让用户对系统行为有掌控感。对于敏感数据例如银行账号、身份证号、报销金额这个确认步骤不能省。6.4 接入前检查清单[ ] 已经为每个自然语言入口定义了 JSON Schema。[ ] 工具调用参数与 JSON Schema 的字段名和类型一致。[ ] 必填字段、枚举值、格式规则全部有确定性校验。[ ] 模型输出会先进入格式化函数再做校验。[ ] 校验失败时会回显到具体字段而不是让用户重说。[ ] 用户确认后才触发入库操作。[ ] 日志中记录模型原始输出、格式化后结果和校验结果。[ ] 模型超时、解析失败、字段缺失都有降级路径默认回到手动表单。6.5 生产环境额外保障以上示例用于说明核心链路生产环境还需要额外考虑这几件事日志与追踪每次自然语言录入都记录请求 ID、模型输出、校验结果方便问题回溯。监控与告警统计抽取成功率、字段缺失率、校验失败率指标异常时及时告警。模型版本管理工具调用参数变更时要与模型版本一起发布避免线上模型和 schema 不一致。限流与成本自然语言接口会消耗模型 token需要有配额、超时和降级机制。回滚方案当模型能力弱化或服务不可用时系统要能自动切回纯表单模式。6.6 什么场景仍然优先用传统表单字段多、约束多、有跨字段业务规则例如报销、审批、订单录入。数据敏感、不允许出现格式错误例如身份证号、银行卡号、精确金额。用户操作频次低、熟练度低表单的确定性比对话效率更重要。合规要求高、需要留痕和审计表单的字段级操作记录更容易审计。“Forms did five things. Natural language kept one” 这句话真正的价值不是否定自然语言而是提醒开发者当我们把输入方式从表单换成自然语言时需要重新为那四件被丢掉的事情找到替代方案。JSON Schema 定义结构工具调用约束抽取规则校验守住边界回填确认保留人的最终决定权。按这个思路做自然语言界面才不会变成数据质量的灾难。对于刚接触这个方向的团队建议先选一个小功能验证完整链路例如“一句话记一笔账”或“一句话创建一个待办”跑通 schema、抽取、回填、校验、日志五个环节后再逐步把复杂表单接入自然语言入口。这样既稳妥也能积累一套可复用的自然语言表单接入范式。