带 JSON Schema 的 tool_use 保证两件事：零 JSON 语法错误和零 schema 违规。每个响应都是合法 JSON，所有必填字段都在，类型都对。这是 API 生成层面的强制保证——不是概率性的，不是事后检查的。
它保证不了的是：语义正确性。作者名跑到 version 字段里。行项目加起来不等于总计。必填字段里放的是编造数据。日期在逻辑上矛盾。
三层错误模型
| 层级 | 错误类型 | tool_use 能修？ |
|---|---|---|
| 1 | 语法（JSON 格式错误） | 能——已消灭 |
| 2 | Schema（字段缺失、类型错误） | 能——已消灭 |
| 3 | 语义（值错误、逻辑错误） | 不能——原封不动 |
三阶段改进的数据：
- 阶段 1（基于 prompt 的 JSON）：28% 总错误率（4.2% 语法 + 8.1% 字段缺失 + 12% 语义）
- 阶段 2（tool_use）：13% 错误率（0% 语法 + 0% 缺失 + 11% 语义）
- 阶段 3（tool_use + 字段描述 + 验证）：3% 错误率
每个阶段处理不同的错误类别。tool_use 本身砍掉了一半错误，但语义问题原封不动。应用层验证处理了剩余的差距。
详细字段描述减少语义错误
当 8% 的提取把值放进了错误字段时，给工具参数加上清晰的描述——说明每个字段该放什么值——引导 Claude 做正确的语义映射。这是弥补 schema 合规和内容正确性之间差距的推荐做法。
基于 Prompt 的 JSON 是反模式
在 prompt 里写”输出合法 JSON”无法保证语法正确性或 schema 合规。解析失败后重试是被动的变通方案，浪费 API 调用。tool_use 在设计上就提供结构保证。
tool_choice：强制 vs 自动
用 tool_choice: auto 配合虚拟提取工具时，模型有时会返回文本而不是调用工具，打断下游解析。切换到强制 tool_choice 来确保每次调用都返回结构化输出。
验证仍然不可省
“把验证全删了——tool_use 保证了正确性”是错的。tool_use 保证的是结构，不是语义。对于财务文档，业务逻辑验证（行项目加总、日期先后顺序）仍然必不可少。JSON Schema 表达不了跨字段的算术约束。
一句话总结： tool_use 在 API 层面消灭语法和 schema 错误，但语义验证（跨字段逻辑、值的正确性）仍然是你的责任——结构有保证，含义没有。