我在做客服工单分类时遇到过一件很折磨人的事。第一次调用大模型让它从用户反馈里抽出几个字段很快就跑通了。可一放到真实数据里输出就开始“表演”有时把 JSON 包在 markdown 代码块里有时多返回一个字段有时把布尔值写成 “yes”偶尔还认真写了一段解释根本没法直接解析。当时同事建议我再改改提示词我改了一下午提示词越来越长结果反而更不稳定。后来我换了一个思路不再把“让模型输出正确”当作第一目标而是先为模型的输入输出定义一套类型。回头看这正是标题 “Types with AI: Working with LLMs Through Types” 想表达的核心理念——用类型系统和大模型协作把不可控的生成过程变成可编程、可验证、可维护的工程流程。这个方向看起来不像“提示词工程”那样容易感知但它正在改变 LLM 应用从“能跑”到“能上线”之间的关键差距。下面我会拆开讲两件事这类思路到底解决了什么问题以及当你真正把它放进项目时要注意哪些边界和坑。1. 为什么要在 LLM 调用里引入“类型”这个概念1.1 LLM 输出的本质是字符串而开发需要的是结构化数据先回到最基础的观察。无论调用哪家模型只要走普通文本接口你拿到的本质上都是一串 token也就是字符串。即使你要求模型“返回 JSON”它也只会先输出一个 JSON 字符串然后由客户端去JSON.parse或model_validate_json处理。问题在于传统 API 的响应是有契约的。后端返回一个对象前端可以依赖字段名、类型和结构。但 LLM 的文本接口没有内置契约。它可能遵守 JSON 格式也可能不遵守可能一次性给出正确结构也可能在字段名里多加一个空格。于是开发者在拿到输出后不得不做大量防御式解析先判断是不是 JSON再判断有没有被代码块包裹再判断字段是否存在再判断类型是否正确再判断有没有多出意外字段。这些代码写起来不难但很碎而且每遇到一个新场景就要重写一遍。更麻烦的是这类解析逻辑通常不会出现在单元测试覆盖里因为样本一变解析失败方式也变。类型系统的价值在这里才开始显现它允许你把“模型输出应该长什么样”这份隐式期待变成一份显式定义。开发者不再靠人脑记忆而是靠代码来表达期望。1.2 类型不只是校验更是生成流程的契约很多人听到“类型”第一反应是运行时校验。的确拿zod或pydantic对模型输出做parse是直接的一步。但类型的作用不止发生在解析那一刻它更应该在写提示词之前就参与设计。如果你已经定义了一个Ticket类型字段是category、urgency、demandsRefund那么你在写提示词时可以直接把这份字段清单或 JSON Schema 交给模型。模型看到的不再是模糊的“请返回以下信息”而是一份明确的结构说明。它能因此减少对字段名、枚举值、嵌套关系的猜测。这很像前后端对接时的接口文档。传统开发里后端定义好 OpenAPI spec前端按 spec 生成客户端代码。现在与 LLM 协作类型定义就扮演了 spec 的角色。给模型的提示词是“用户需求说明”类型定义是“接口契约”。两者结合模型才知道该怎么把自由生成的文本装进业务系统需要的数据结构里。1.3 从“结果校验”到“过程约束”的转变再往前走一步类型约束不应该只发生在最终输出阶段。尤其在 LLM Agent 场景模型需要主动调用工具而工具函数的参数本身就是强类型约束。举个例子一个 Agent 需要调用searchOrder工具这个工具的参数可能是{ orderId: string, country?: string }。模型生成的参数不能直接丢给真实函数执行因为模型可能把country写成一个对象也可能把必填的orderId丢成空字符串。如果先按类型 Schema 校验一次非法参数会被拦截而不是带着脏数据进入业务系统。这也是目前“llm agent”开发里一个非常稳定的落地点。过去我们更关注模型能不能读懂用户意图却忽略了给模型一套“允许操作什么、参数必须长什么样”的安全边界。类型系统正好提供了这一层边界。它不负责让模型变得更聪明但负责让模型的动作不越界。所以我理解到的核心判断是用类型和 LLM 协作真正解决的并不是“让模型回答得更准”而是“让不可控的生成变得可编程、可验证、可维护”。2. 从“写死提示词”到“类型驱动的 LLM 工作流”2.1 最小流程用 Schema 定义输入和输出结构如果你想实际尝试不必引入复杂框架。一个最小流程只需要三样东西一个 Schema 校验库、一段把 Schema 注入提示词的逻辑、一个在拿到模型输出后执行的解析函数。下面是一个 TypeScript zod 的示例结构import { z } from zod; const TicketSchema z.object({ category: z.enum([refund, shipping, account]), urgency: z.enum([low, medium, high]), demandsRefund: z.boolean(), }); type Ticket z.infertypeof TicketSchema;然后你可以把JSON.stringify(TicketSchema.shape)或一个写好的 JSON Schema 描述放进提示词里。最后模型返回文本执行const parsed TicketSchema.parse(rawText.replace(/json|/g, ));Python 生态里类似的结构通常用 pydantic 表达from pydantic import BaseModel from typing import Literal class Ticket(BaseModel): category: Literal[refund, shipping, account] urgency: Literal[low, medium, high] demands_refund: bool然后在拿到模型输出后parsed Ticket.model_validate_json(raw_text)注意这只是一个通用示例。具体模型接口返回的是纯文本还是已经剥离代码块不同 SDK 处理方式不一样。落地前要先确认依赖版本和实际返回格式。2.2 类型如何同时服务模型、IDE 和运行时校验类型定义在 LLM 调用流程里的价值是同时作用于三端的。对模型来说Schema 提供了一份精确的字段清单。很多模型在直接看 JSON Schema 时的表现会比看一段语义含糊的“请返回如下字段”更稳定因为模型不需要猜测字段类型和可选项是什么。这是我把类型定义放进提示词后的实际体感。对开发者来说类型定义让 IDE 能自动补全。你在业务代码里使用解析出来的Ticket对象时编辑器能准确提示字段名和类型。如果以后把字段从demandsRefund改成requestRefund编译器会在所有引用处给出报错而不会再出现“找到不到字段”的运行时错误。对运行时来说解析结果已经是一份强类型对象。下游的统计、存储、展示逻辑都不需要再手写一堆if (data.category ! undefined)的防御代码。只要校验通过字段就存在类型就正确。这能省下大量重复的防御式解析。2.3 流式输出与工具调用里类型依然能兜底很多实际应用不满足于一次性返回而是采用流式输出让用户看到逐字生成的效果。此时类型依然可以介入只是方式要调整。一个常见做法是维护一个文本缓冲区当缓冲区里的内容足够完整时尝试用 Schema 做增量解析。可能前几个 chunk 还不够解析但一旦到了某个边界字段已经能解析出来就可以提前进入后续处理。这种方式不会替代最终解析但它能让决策更早发生。工具调用场景更直接。当前很多平台支持 function calling模型会输出结构化的工具调用参数。但这些参数同样可能不合法。比如模型应该在country字段里放国家代码却传入了完整国家名或者把可选字段都填了空字符串。对这些参数执行一次 Schema 校验是 Agent 工程里成本很低但收益很高的一步。from pydantic import BaseModel class SearchOrderArgs(BaseModel): order_id: str country: str | None None拿到模型的raw_arguments后直接做SearchOrderArgs.model_validate(json.loads(raw_arguments))。如果这一步失败就不要调用真实工具先尝试修正参数或要求模型重新生成。2.4 从“单次调用”到“批量化”先定义好输入边界另一个容易忽略的点是类型不仅约束输出也应该约束输入。尤其是做批量任务时输入数据本身就可能很脏。比如一个字段本应是字符串结果调用方传入了嵌套对象直接拼进 prompt 后就变成了[object Object]。这个问题很难通过“加强提示词”解决。我一般会在批量处理前先给输入定义一个基础 Schema。这样既能在源头拦截脏数据也方便记录失败样本。单次任务跑通只能说明流程没有断批量任务稳定才说明边界定义已经足够清楚。不要一上来就把批量数和并发数拉满。先用一条样例确认输入、输出和日志都正常再逐渐扩大规模。类型校验不是保险箱但它能帮你更早发现哪一层出了问题。3. 落地这套思路时最容易踩的坑3.1 场景边界结构化结果加约束没问题开放写作别硬套类型约束最适合的场景是信息抽取、分类打标、表单填充、工具调用参数、Agent 动作编排。这些任务共同点是业务系统需要结构化数据模型只是负责把非结构化输入转换成结构化结果。但如果是写营销文案、创意故事、自由对话类型约束就不应该过多介入。你不能要求一首诗必须返回{ title: string, content: string, emotion: happy }还把情感也强构成枚举值。创作类任务需要的是表达空间硬套类型只会让生成结果变得干瘪。如果确实需要在创作场景里保留一点约束可以只在最外层做轻量封装例如只限定{ title: string, content: string }内容字段本身还是自由文本。这样就兼顾了流程可控与内容开放。不要把类型约束当成万能钥匙。它更适合当一个输出网关而不是创作编辑器。3.2 字段设计过细会诱发幻觉和缺失类型定义不是越细越好。我见过有人把客服系统中一个工单对象定义成 30 个字段要求模型一次全部返回。结果模型面对大量必须填写的字段时开始自己编内容未知的客户类型被硬塞进一个枚举缺失的订单号被补成一个相似但不存在的值。这其实就是幻觉的一种表现而根因是类型结构超出了模型单次输出的合理承载量。从经验看单次输出的结构化字段控制在 5 到 10 个以内会稳定很多。嵌套层级尽量别太深尽量把枚举值写得明确并为每个字段提供一个示例值。如果业务对象确实很复杂不要试图让模型一次生成完整对象可以把任务拆成几轮先抽取摘要再抽取实体再填充关系。每一次都只面对一个小而明确的 Schema。3.3 模型升级后的类型漂移类型定义不会一劳永逸。模型版本升级后推理能力、格式遵循能力、字段偏好都可能发生变化。原来 90% 能通过校验的 Schema换到新版模型后可能下降到 70%。这不是 Schema 写错了而是模型分布变了。处理这类问题要靠回归测试。准备一组固定样本不频繁改动每次模型升级后跑一遍记录字段缺失率、枚举非法率、总解析失败率。只有这样你才能区分“这一次模型输出质量波动”和“长期趋势下降”。类型定义应该像代码一样被管理。变更时要有记录上线前要有测试。不要让一个 Schema 在模型升级、提示词改版后悄悄失去了约束力。3.4 类型解析失败时的排查链路遇到解析失败第一反应不要改成“再试一次”或“换个说法”。先按顺序排查下面几层拿到原始输出。先看模型到底返回了什么是 JSON、markdown 代码块还是一段解释文本。检查 Schema 与提示词是否一致。字段名是否拼写一致枚举值是否和示例一致有没有把布尔值描述成字符串。检查生成参数。temperature 是不是太高是否开启了 JSON mode有没有要求模型“不要输出解释”。检查截断。如果 max_tokens 设置太小输出的 JSON 可能被切断缺少右括号或字段。最后再考虑重试或换模型。只有前四层都确认无误重试才有意义。失败现象常见原因处理方式输出被 markdown 包裹模型默认生成 markdown 文本解析前剥除代码块标记或在提示词中明确只输出 JSON字段名对不上提示词与 Schema 描述不一致把 Schema 作为唯一字段来源避免两套描述枚举值不合法模型自创了一个不在列表里的值为每个枚举提供示例并让 Schema 明确列出可选项JSON 不完整输出超过 max_tokens调大 token 上限或缩短输入上下文重复解析失败Schema 过于复杂拆分成多个子任务每个任务只做一小段输出4. 类型优先的接入方法论从单次调用到工程化4.1 一个类型优先的四步接入框架如果你要把这套思路带进真实项目我建议按四步走顺序不要跳。第一步定义类型边界。先写出期望返回的字段、类型、可枚举值。就像设计接口一样考虑哪些是必填哪些是可选哪些值是业务可以接受的默认值。这一步不写任何提示词。第二步设计提示词与示例。把 Schema 或字段说明注入提示词同时提供一到两个 few-shot 示例。示例不应该只展示理想输出还应该展示边界情况例如缺失字段时应返回什么。第三步小样本回归验证。挑 20 到 50 条有代表性的真实样本不要挑太干净的跑一轮统计失败率。如果失败率过高先回去修 Schema 和示例不要急着加“再来一次”的重试。第四步监控与迭代。上线后记录每个样本的原始输出、解析结果、校验错误类型。定期抽样观察类型覆盖率和字段非法率。模型升级或提示词改动后重新跑一遍回归集。4.2 如何定义错误分类与重试策略没有类型校验时一个异常只能笼统地叫“解析失败”。有类型校验后你可以把错误拆成更细的类别并针对每一类设计不同处理策略SchemaValidationError通常是模型输出结构不合法盲目重试收益不高应该先看原始输出再判断是 Schema 问题还是模型问题。TimeoutError / 网络错误这类错误和模型输出无关可以使用指数退避重试。ContextWindowError输入太长导致请求超过上下文窗口重试无意义应该缩短输入或做摘要。ContentFilterError内容被安全策略拦截需要调整提示词或检查输入是否触发了敏感规则。我习惯把每类错误对应到自己的处理函数而不是用一个大的try/catch吃掉所有异常。这样当线上数据反馈回来时你可以快速知道是哪一类问题占多数而不是只在错误日志里看到一堆堆栈。4.3 团队协作中类型约定的价值类型定义对团队协作的影响往往比个人使用更容易被低估。当多个角色都依赖同一个 LLM 调用时类型定义就是大家共同的接口契约。后端可以按类型定义准备存储字段前端可以按类型定义做展示测试可以按类型定义准备断言。如果类型变更了代码评审时一眼就能看到影响范围。而如果每个人各写各的提示词字段名靠默契沟通最后一定会有人踩到“模型返回的是user_name但页面读的是username”这样的坑。这也是我把“类型”和“AI 协作”放在一起理解的原因它不是给模型看的魔法而是让整个团队面对模型输出时仍然能像做传统 API 一样稳定协作的工具。4.4 长期监控“类型覆盖”而不是只看生成结果很多团队上线 LLM 功能后只关注“回答质量高不高”“用户满意度怎么样”却没有把结构稳定性纳入监控指标。事实上对结构化抽取类应用来说一个更客观的指标是类型通过率也就是所有请求里能通过 Schema 校验的占比。我会在日志里记录每次调用的原始输出、解析结果、校验错误类型。全量记录可能成本高那就抽样。当发现类型通过率突然下降时优先检查三件事模型版本是否变了、输入数据分布是否变了、Schema 是否最近被改过。这个指标比“看起来差不差”要可靠得多。因为它不依赖人来做主观判断只看结构是否符合约定。模型能力再强如果输出拿不到业务系统里价值就为零。5. 对“AI 编程”和 Agent 开发来说这个方向的边界在哪里5.1 什么场景值得用什么场景不值得用值得用类型约束的场景通常会有一个共同点输出需要被程序继续消费。比如自动化工单分类、信息抽取、结构化报表、表单自动填写、Agent 的工具调用参数。这类场景如果不用类型约束下游程序就必须处理大量非预期输入开发成本和稳定性会严重受损。不值得用类型约束的场景则通常是生成结果直接面向人、不需要被程序严格解析的。比如开放式的故事生成、营销创意脑暴、闲聊对话、诗歌创作。这类场景强行加 Schema只会限制模型的表达能力增加生成失败的概率。当然也存在混合模式产品需要一段“有感染力的文案”作为最终呈现但标题字段、目标用户、推广渠道等元信息仍然需要结构化。这种情况下最外层的自由文本交给模型发挥外围的元数据结构交给类型约束。适合类型约束不适合硬套类型信息抽取开放式写作分类打标创意文案表单填充自由对话工具调用参数情感陪伴Agent 中间状态多轮无关主题闲聊5.2 这个方向不会替代提示词工程但它把工程的地基修好了有一种担心是如果都靠类型约束了提示词还要不要写当然要写。类型负责的是结构边界提示词负责的是表达和上下文。两者是分层关系。一个合适的比喻是提示词是给模型的“产品说明书”类型定义是给系统的“接口契约”。产品说明书要写得清楚模型才知道客户需求是什么接口契约要定得严格程序才能安全地处理模型输出。没有前者模型理解不对没有后者系统稳定不住。可以预见的是随着 LLM 应用逐渐进入生产环境开发方式会越来越像常规后端开发。定义接口、mock 数据、单元测试、灰度发布、监控告警这些原本属于软件工程的流程会在 LLM 应用里变得越来越重要。类型驱动只是其中最早能落地的一环。5.3 给正在入门的开发者的一个落地顺序如果你刚接触这个方向我建议不要一上来就搭一套 Agent 框架。更稳的路径是第一步找一个非常简单的字段抽取任务例如从一段快递反馈中抽取“是否拒收”和“客户情绪”。第二步用顺手的数据校验库定义三到五个字段先不用管复杂嵌套。第三步把 Schema 注入提示词拿到输出后立刻做解析校验。第四步找 50 条真实样本统计一下第一次解析成功率。大概率你会看到不少失败这是正常现象。第五步根据失败类型回改 Schema让它更贴近模型实际的生成偏好。第六步确认稳定后再考虑接入工具调用、流式输出和批量处理。不要急着把这个方法用到所有功能上。在一个小任务上建立完整闭环比在十个任务上各跑一遍更有价值。因为类型驱动的工作流最大收益不是第一次跑通而是后期维护时少踩很多坑。只要流程闭环了后续扩大范围只是复制方法论的问题。如果你正准备把某个 LLM 功能从脚本搬进正式业务我的建议很简单先别急着写 prompt先打开一个空白文件定义第一组类型。把输入和输出边界说清楚。再让模型去填空。你会发现很多看起来像玄学的问题最后都会被拆成可以定位、可以修、可以回归验证的普通工程问题。