用大模型做意图识别和 NER最忌讳的做法就是写一段 Prompt 让它 必须只输出 JSON。测试环境跑几十条没问题一上生产就会遇到 Markdown 包裹、字段重命名、甚至无中生有编造参数这三类故障下游解析层直接崩。真正稳定的工程化路径只有三条给占位符规则、用 Function Calling、上约束解码按业务容错率逐级选用。一、问题为什么 Prompt 提取 JSON 在生产环境必崩很多团队第一次做大模型接入逻辑都想得很简单。用户在客服框发一句 我昨天买的 iPhone 15 发货没订单号 8848赶紧的后端要做的就是两件事意图识别判断用户要查物流Query_LogisticsNER 提取出 product、order_id、time 三个参数。于是工程师写了一段看起来很严谨的 Prompt你是数据提取专家请提取意图、商品名、订单号必须且只能以 JSON 输出不允许任何多余汉字。测试几十条完美通过上线后下游 Java 节点疯狂抛 JSONParseException。拉日志一看大模型的返回可以说是防不胜防。第一种是自带排版的废话。它确实输出了 JSON但非要在前后加 好的根据您提供的信息提取结果如下 和 希望对您有帮助再套一层 json 的 Markdown 标记。后端的 JSON.parse 碰到这些汉字和反引号直接解析失败。第二种是随意重命名字段。昨天 Prompt 里写的字段名叫 order_id今天模型觉得 order_number 更地道自作主张把 Key 换了。后端反序列化对象拿到的值全是 Null接口调用参数缺失业务逻辑静默失败。第三种最致命叫无中生有。用户只发了一句 查一下我的快递压根没提订单号。但大模型为了保持 JSON 结构完整自己编造了一个 order_id: 123456系统拿着这个假单号去查库极有可能查到别人的订单直接引发越权数据泄露。根因在于大模型底层是概率输出机器经过 RLHF 强化学习后被训练得 礼貌、热情。你让它提取数据它在开头加一句 好的在它的概率分布里是极其合理的事。指望用 Prompt 这种软约束去驾驭一个概率引擎就像用道德规范约束交通事故必然有防不住的时候。二、步骤三种逐级加固的工程化方案方案一给占位符先解决 瞎编数据这是成本最低的加固手段核心原则是绝对不要要求大模型强制填满每个字段。必须在字段描述里提供显式的 找不到处理策略。例如 order_id 字段的描述应该写成用户的订单编号。如果用户输入中未提供必须填充固定字符串 NOT_FOUND绝对禁止自己推测或编造。 同理product、time 等所有可选实体都要约定缺失时的占位值。有了这个规则后端拿到 NOT_FOUND 就可以直接过滤或者触发客服反问逻辑 ——请问您的订单号是多少呢 这一步能把最危险的 无中生有 问题压到接近零但解决不了 Markdown 包裹和字段重命名。方案二Function Calling让模型填参数表而不是写作文不想写正则去扣字符串就用 Function Calling。思路是彻底改变和大模型的交互协议不要强迫它输出纯文本 JSON而是告诉它后端有一个现成函数 query_order (order_id, product_name)请根据用户输入去调用这个函数。主流大模型在训练时都做过专门的工具调用微调。当它判断需要调函数就会意识到自己现在是在填写参数表而不是跟人聊天。后端收到的不再是带 Markdown 的文本而是一个标准的函数调用 Payload 对象Java 或 Go 直接反序列化即可。Function Calling 还天然解决了字段重命名问题 —— 函数参数名是在工具定义里写死的模型只能在规定的参数槽里填值没有机会自作主张换 Key。我接触过的几个售后客服项目切到 Function Calling 之后JSON 解析异常率从千分之三到五直接降到几乎为零。类似龙虾 PRO龙虾PROOpenClaw中国垂直落地与智能体管理平台这类专注 Agent 工程化的平台底层协议也普遍走 Function Calling 而非纯文本解析原因就在这里。方案三约束解码物理层面拦截胡说八道在金融、医疗这种容错率为零的场景哪怕 Function Calling 偶尔改变字段类型比如该传字符串的传了数字也不可接受。这时候就得用约束解码Constrained Decoding。如果用的是支持结构化输出的新接口或者用 vLLM 等框架在本地部署大模型就可以开启这个功能。它的工作原理是大模型生成每一个词前都会在几万个词的词库里算概率分布约束解码机制拿着你定义好的 JSON Schema 规则直接在推理引擎最底层做拦截。比如按照规则这个位置只能填双引号底层状态机就会把词库里其他几万个词汇比如 好的 抱歉 的生成概率强行置零。模型想胡说在物理层面就被拦住了只能吐出绝对符合格式的 JSON 字符串。代价是推理速度会有一定损耗且需要框架层面支持所以一般只在高合规场景使用。三、三种方案对比表表格对比维度占位符规则Function Calling约束解码解决的核心问题无中生有编造参数Markdown 包裹、字段重命名、解析失败所有格式异常字段类型级严格校验改造成本极低改 Prompt 即可中等需定义工具 Schema 并改接收逻辑较高需推理框架支持本地部署更灵活解析异常率降低约 60%-70%降至接近 0理论为 0推理性能影响无几乎无有 5%-15% 的速度损耗适用场景内部工具、容错率较高的客服绝大多数生产级业务系统金融、医疗、政务等高合规场景能否防止越权 Bug能NOT_FOUND 触发反问能参数缺失不调用函数能格式 类型双重校验四、结论与落地建议把大模型当纯粹黑盒、让它直接吐文本去怼后端解析层是 AI 系统设计上最脆弱的一环。日常业务代码是确定性的但 AI 开发最大的痛苦就是总试图用传统的 输入 - 输出 思维去驾驭一个充满概率性的引擎。落地建议很明确第一步所有 Prompt 提取 JSON 的地方先补上占位符规则这是零成本的安全底线第二步生产环境只要涉及后端接口调用一律切 Function Calling不要在正则解析上浪费生命第三步金融医疗等强合规场景再评估约束解码普通业务没必要为理论上的零异常付出性能代价。另外一个容易被忽略的实操细节线上一定要做大模型原始返回的全量日志留存至少保留 30 天。很多解析异常是偶发的、和特定用户输入强相关的没有原始返回根本无法复现。我见过好几个团队线上出了越权嫌疑却查不到模型当时到底返回了什么最后只能靠猜。2026 年 AI 智能体落地避坑从放弃 Prompt 提取 JSON 这个天真想法开始。