模型犯错时不该直接产生副作用，这是选型的底线。
两种"让模型输出结构化数据"的路线
· 路线 A：让模型填表（给它 schema，让它产出 JSON）；
· 路线 B：让模型调用工具（用函数调用/工具调用，参数就是 schema）。
两者都能拿到结构化结果，但适用场景与风险不同。选错的代价通常体现在稳定性和可控性上。
什么时候该"填表"
· 任务是抽取/分类（从这段文本里取出字段），没有副作用；
· 一次要给多个字段（模型能一次看全上下文再决定）；
· 结果要整体校验（字段之间有关联，如起止日期）；
· 希望批处理（一次处理很多条，填表更省往返）。
什么时候该"调工具"
· 需要执行动作（查库、下单、发信），而不只是产出数据；
· 参数之间有先后依赖（先查 ID 再更新）；
· 需要幂等与审计（每次调用是一条可追踪的记录）；
· 需要在执行前做权限校验（工具层能拦住越权）。
一个务实的组合
"填表"负责意图，工具负责落地：
1. 让模型填一张"意图表"（动作 + 参数 + 理由）；
2. 程序校验意图表（字段、范围、业务规则、权限）；
3. 校验通过后，由代码按意图表去调用工具（而不是让模型直接调）。
好处：模型犯错时不会直接产生副作用；校验与审计都在一条链上；重试也更容易做。
三个常见错误
· 让模型直接执行写操作：一旦幻觉出参数，代价是真实的；
· 只校验 JSON 合法性：合法 JSON 也可能是错的业务值（金额为负、ID 不存在）；
· 把工具返回塞回模型再让它填表：容易形成"模型改数据"的链路，越改越偏 —— 数据变换应交给代码。
选型检查清单
1. 这个任务是"取数据"还是"做事"？（取→填表；做→工具）
2. 参数有没有依赖与幂等要求？
3. 出错时的后果可控吗？（不可控 → 加人工确认）
4. 有没有更简单的做法？（能用规则/正则解决的，不要上模型）
本文由云枢 AI导航整理，内容以官方来源为准。
相关文章
顺序阅读
← 上一篇：多语言场景的坑：分词、时区与本地化格式
下一篇：把成本按租户摊开：单位经济模型怎么看 →
第 28 / 171 篇