如何用日常语言写出好用的提取结构（Schema）

大多数人用 Ztract 做的第一件事，是创建一个项目。第二件事——也是真正决定结果好坏的那件事——就是告诉我们要从中提取什么。这段说明，就是你的 Schema。

有一点常让人意外：你不用写代码。没有语法要学，不用声明字段类型，也不用在页面上画模板。你只要像跟新同事解释一样，把需求说清楚就行：“每张发票，帮我提取供应商、总金额，以及每一条明细项。” 剩下的交给引擎。

这种自由正是关键所在——但它也意味着，你拿到的结果有多好，取决于你的描述有多清楚。含糊的要求，得到含糊的结果；精准的要求，第一次就能得到可以放心使用的干净数据。这篇文章要讲的，就是那几个让日常语言 Schema 变精准的小习惯——无论你处理的是哪一类文档，都用得上。

好用的 Schema 长什么样

在讲规则之前，先看看一段管用的描述大致是什么样子。假设你要提取发票：

“每张发票，提取发票号、开票日期、供应商名称和应付总金额。同时提取每一条明细项，包含说明、数量、单价和小计。如果文档上没有某个字段，就留空，不要猜。”

留意一下这段话做了什么。它点名了具体的字段，而不是笼统地说”重要的东西”。它把每份文档只出现一次的内容（发票号、总金额）和会出现很多次的内容（明细项）分开了。而且它说明了缺字段时该怎么办。这些都不涉及技术——只是说得够精准而已。下面五个习惯，就是帮你做到这一点。

让 Schema 变精准的五个习惯

1. 说清楚你要的是哪一个值

文档里满是长得很像的数字和日期。发票上的”金额”，可能是小计、税额、折扣前金额，也可能是最终应付金额。如果你只写_“提取金额”_，那等于把选择权交给了运气。

点名你要的那一个：

• ❌ “日期” → ✅ “发票开票日期（不是到期日）”
• ❌ “金额” → ✅ “含税并扣除折扣后的应付总金额”
• ❌ “名称” → ✅ “供应商的公司名称（不是联系人姓名）”

文档里相似字段越多，这一点就越重要。

2. 说明你想要什么格式

引擎读取页面上的内容，但你往往希望它被整理成统一的样子——尤其是日期、数字和金额。如果你在意格式，就直接提出来：

• “所有日期都格式化为 YYYY-MM-DD。”
• “金额用纯数字表示，不带货币符号，也不带千位分隔符。”
• “借记金额记为负数。”
• “把货币代码（USD、EUR 等）作为单独的字段提取出来。”

不说明的话，文档上是什么样你就拿到什么样——$1,250.00、1.250,00、(1,250.00)——回头还得在表格里一个个清理。开头多写一句话，就省下了这些活。

3. 把”每份文档一个”和”每行一个”分开

这是最容易绊住大家的一点，值得放慢节奏说清楚。有些字段每份文档只出现一次——发票号、银行对账单的账期、账户持有人。另一些则会重复出现——每一条明细、每一笔交易、机票上的每一位乘客。

如果你不把它们区分开，可能会出现该是一份列表的地方只拿到一个值，或者该有结构的地方被压成一团乱。解决办法就是把它说出来：

“对账单级别的字段只提取一次：账户持有人、账号、期初余额、期末余额。然后把每一笔交易作为单独一行提取，包含日期、说明和金额。”

“每一个”这几个字是你的好帮手。“每一条明细项……”、“每一笔交易……”——它们告诉引擎要预期一份列表，于是返回给你的是干净、重复的一行行数据，而不是一团乱麻。

4. 给容易混淆的字段加一句区分说明

有些字段本身就有歧义，再怎么读页面也理不清——只有你的意图能定夺。一份报关文档上可能同时有发票号和采购订单号，同时有收货地址和账单地址，同时有毛重和净重。

当两个字段可能被搞混时，加一句简短的说明：

• “发票号（卖方的，标着 ‘INV’ 的那个——不是 PO 号）”
• “收货地址（货物送达的地址，不是账单地址）”

你心里清楚自己真正要的是哪一个。说出来，就消除了猜测的余地。

5. 决定字段缺失时该怎么办

真实的文档参差不齐。这张发票有 PO 号，下一张就没有。如果你不说明该怎么办，就等于把它留作未知数——而对于提取来说，你几乎总会想要的那个安全默认值是：什么都别编：

“如果文档上没有某个字段，就留空。绝不要猜，也不要填占位符。”

对于财务、法律和医疗类文档，这一句尤其值得写——在这些场景里，一个自信地填错的值，远比一个你看得见、能去追查的空格危险得多。

创建 Schema 的三种方式——以及各自的适用场景

Ztract 给了你三个起点。上面那些习惯对三种方式都适用；区别只在于你从哪里开始。

• 从现成的 Schema 开始。 对于常见文档——发票、收据、银行对账单、证件、简历、合同、化验报告、报关单据——都有现成模板，已经知道通常该提取哪些字段。如果你的文档是标准类型、想快速上手再做微调，这种方式最合适。
• 自己描述字段。 从零开始写日常语言的描述。如果你的文档比较特殊，或者你只想要这些字段、其他一概不要，这种方式最合适。这正是上面五个习惯派上用场的地方。
• 从样本推断。 放进一份有代表性的文档，让引擎根据它看到的内容提出一套 Schema。如果你得先看过一份文档才知道里面有哪些字段，这种方式最合适——然后再用日常语言完善这套建议。

大多数人最后都会把它们结合起来：从模板或样本起步，再用上面的习惯亲手把描述打磨精准。

想了解更多，可以查看我们的设计你的 Schema 文档页面。

一张快速排查表

当输出不是你预期的样子时，原因通常出在描述上。常见的几种：

你看到的现象	可能的原因	解决办法
”金额”提取出了错误的数字	字段不够具体	点名确切的值：“含税后的应付总额”
日期格式混乱不一	没有要求格式	加上_“所有日期格式化为 YYYY-MM-DD”_
想要列表却只得到一个值	没有标明这是重复字段	用_“每一个……提取……”_
列表被压进了一个单元格	同上	同样——明确点名每一行要提取的字段
凭空冒出一个字段	没有缺字段规则	加上_“没有就留空，绝不要猜”_
两个相似字段被对调了	没有区分说明	加一句澄清：“是 PO 号，不是发票号”

Schema 只是整个流程的一半

即便写得再好的 Schema，也值得再看一眼，而 Ztract 正是围绕这一点设计的。每一个提取出来的值都锚定在源文档上的位置——点一下某个值，就能看到它究竟来自哪里。你扫一遍那些看起来不对劲的，一键修正，就完成了。修正不收任何费用；只有提取会计入你的页数，之后的编辑不算。

所以，好 Schema 的目标不是第一次就完美无缺——而是足够接近，让审阅这一步只是快速扫一眼，而不是从头返工。上面五个习惯，正是帮你做到这一点。

用一份真实文档试试看

要快速找到感觉，最好的办法就是为一份你日常真正会处理的文档写一段描述，看看会返回什么。新账户可获得 30 页免费额度，无需信用卡——足够你起草一套 Schema、不断完善，并亲眼看着输出在这个过程中越来越准。

如果某类文档，或者你想描述的某套 Schema 把你绊住了——如果你怎么也找不到合适的措辞来得到想要的结果——那恰恰是我们最想听到的反馈。告诉我们；让 Schema 设计对非工程师也变得一目了然，是这款产品中我们最在意做好的部分。