没有明确的格式标准化规则时，模型对输入格式的复现是不一致的。输入”March 15, 2025”的日期，输出可能是”March 15, 2025”、“3/15/2025”或”2025-03-15”，每次运行都可能不同。下游解析器直接崩。
明确指定输出标准
| 数据类型 | 标准 | 规则 |
|---|---|---|
| 日期 | ISO 8601 | YYYY-MM-DD |
| 电话号码 | E.164 | +[国家代码][号码] |
| 货币 | 数字 + 代码 | 金额为数字，货币为单独字段 |
| 地址 | 结构化字段 | street、city、state、zip——不是一个字符串 |
模型会处理输入到标准格式的转换。告诉它输出格式后，它能读”March 15th”然后输出”2025-03-15”。它能读”$1,234.56 USD”然后输出 {"amount": 1234.56, "currency": "USD"}。
Schema 类型是必要但不充分的
type: number 阻止了字符串但没指定小数规范。type: string 用于日期时，“12/31/24”和”2025-12-31”都合法。JSON Schema 的 format 关键字是提示，不是强制器。Prompt 层的规则在每个类型内部定义精确标准。
实测效果
给提取 prompt 加上格式标准化规则：
| 类别 | 之前 | 之后 |
|---|---|---|
| 日期解析错误 | 12% | 0.5% |
| 货币解析错误 | 8% | 0.2% |
| 电话解析错误 | 3% | 0.1% |
| 总下游错误 | 23% | 0.8% |
降低 97%。每条规则针对一个具体的格式类别，带来可度量的叠加改进。
一套规则覆盖所有国家
对于多国流水线（15+ 个国家），定义一套国际输出标准。不要创建国家专属的 prompt 或下游解析器。模型在语义层面理解各国的格式差异，能转换到指定标准。
结构化字段优于单字符串
对于地址这类复杂数据，定义单独的 schema 字段而不是一个字符串。配合 prompt 分解规则，这能产出一致可解析的输出，不需要靠正则拆分。
一句话总结： 给提取 prompt 加上明确的格式规则——日期用 ISO 8601、货币用数字、电话用 E.164——下游解析错误从 23% 降到 0.8%。