自定义字段提取入门：
先把这三类字段想清楚，再动手
你打开简录AI的提取页面，看到"输入列名"四个字——然后愣住了。不是因为操作复杂，而是因为不知道该写什么。写"金额"？一张发票上可能有含税金额、不含税金额、税额、行小计四个不同的"金额"。写太少怕漏，写太多怕 AI 分不清。这不是你的问题——这是传统 OCR 工具从来没教过的基本功：提取不是"找文字"，是定义输出。
Key Takeaways
- 打开提取页面后你愣了 30 秒——不是界面复杂，是第一次有人要求你定义输出而非识别输入。
- 文档上没有印出来的数字 AI 照样给你——计算列让"数量×单价"发生在提取那一刻而非之后的 Excel 公式栏。
- 三类列一层比一层深但不是三步——直接提取、计算列、推断列在同一次处理中完成，输出一张直接可入账的完整表。
你输入的列名不是标签，是指令
要理解自定义字段提取，只需要抛弃一个思维惯性：不要把文档处理想成"机器扫描文字然后输出"的流水线。把它想成你和一位能读懂文档的同事之间的对话——你说"帮我把这张发票上的发票号码、开票日期和价税合计找出来"，它读懂了，回答你。
这就是简录AI自定义列提取的核心机制：你在界面里输入想要提取的列名（如"发票号码""价税合计""销售方名称"），AI 根据这些列名的语义在文档中定位对应的值——不是按坐标框选，不是模板匹配。它靠理解"发票号码"这四个字意味着什么，然后在文档中找到它。你输入的列名决定了最终表格的列标题——你定义输出，AI 理解输入。
这和传统 OCR 的差别是根本性的。传统 OCR 只回答"这一页上有什么字"，把页面上的 50 到 80 个文本字符串全部倾倒出来——包括水印、页码、页脚里的无关文字。然后你需要人工从中挑出你要的那几个值。自定义列提取从相反的方向出发：你先告诉 AI 你要什么，AI 带着明确目标去读文档，只返回你要的。
记住这个公式
列名越具体 → AI 搜索范围越窄 → 提取精度越高。写成 "金额"，AI 在四种可能的金额之间犹豫；写成 "价税合计（纯数字，无货币符号）"，AI 准确定位到含税总价并去掉"¥"。你省的每一个字的代价，AI 都需要用猜测来补。
从模糊到精准：一个列名的进化之路
让我们用一个采购订单的真实字段来演示这个"进化"。假设你想提取采购订单的总金额。你会怎么写这个列名？
| 版本 | 你写的列名 | AI 会怎么理解 | 可能出现的问题 |
|---|---|---|---|
| 版本1 | 金额 | "找一个叫'金额'的数值" | 采购订单上同时有单价、行小计、总金额——"金额"太模糊，AI 可能返回单价而非总金额 |
| 版本2 | 订单总金额 | "找采购订单的总金额" | 已大幅改善——但采购订单上可能印的是"Total（含税）"和"Subtotal（不含税）"，AI 还需要判断你要哪个 |
| 版本3 | 订单总金额（不含税，纯数字） | "找采购订单的不含税总金额，只返回数字" | 没有问题了——AI 知道找哪个金额、如何处理货币符号 |
这个进化过程揭示了自定义字段提取的核心设计原则：列名同时是搜索指令和格式指令。"订单总金额"告诉 AI 找什么；"（不含税，纯数字）"告诉 AI 怎么处理和输出。这两个角色完全可以放在同一个列名中，不需要额外的配置面板。
如果到这里你觉得"每次都要写得这么精确，是不是太麻烦了"——值得记住一个数据：Raymond Panko 教授对电子表格错误率的研究表明，人工数据录入的固有错误率为每次按键 1% 到 3%，88% 的电子表格包含至少一处错误。列名设计时多花 10 秒，省掉的是事后逐行核对原始文档的 10 分钟——以及那个可能在下游流程中引发连锁反应的隐藏错误。
文件处理过程加密，完成后自动删除
明细行：当一列里有多个值时
初学者最容易困惑的一个场景：一张发票上有 5 种商品，每种都有自己的名称、数量、单价和小计。你该为每种商品单独建列吗？把列名叫"商品1名称""商品2名称""商品3名称"？
答案是不需要。AI 能识别文档中的表格结构——它知道哪些列是表头字段（发票号码、日期、供应商——整张发票只有一个值），哪些列是明细行字段（商品名称、数量、单价——每一行一个值）。你只需定义"商品名称""数量""单价"三个列名，AI 会逐行提取每个商品的对应值。输出结果中，每个明细行对应电子表格中的一行，表头字段在每一行中重复出现——这正是你最终需要的格式。
不需要为每个明细行单独建列
一张包含 200 个明细行的 10 页采购订单，你的列名仍然是"商品名称""数量""单价""行小计"四列。AI 输出 200 行数据——不是需要手动拼接的 10 个独立表格。表头字段通用，明细行逐行变化，这是你设计列名时不需要考虑的结构问题，AI 自动处理。
但有一条原则需要留意：不要把多个独立信息挤进同一个列名。如果你把列名写成"商品名称和规格"，AI 可能会把"苹果（5kg装）"整体返回——但如果你需要分开处理名称和规格，就应该拆成"商品名称"和"规格型号"两列。数据库设计的基本原则"一个字段存一个信息"，在提取列设计时同样适用。
文档上没有的数据，怎么让 AI 给你
这是自定义字段提取中容易被忽略但最有价值的部分——也是大多数入门教程完全不覆盖的地方。自定义列不只能提取文档上已经写好的数据。你可以让 AI 在提取的同时执行运算或推断，直接在输出表里给你答案而非原始数据。
这分为两类，初学者需要同时理解：
计算列：让 AI 提取时同步完成运算
有些值你需要的，文档上根本没有直接印出来。比如采购订单上只印了每行的数量和单价，但没有行小计——你需要自己算。传统流程是：提取数量和单价 → 导出到 Excel → 拉一列公式 =B2*C2。计算列把这个步骤前移到了提取阶段。
做法极其简单：在列名中直接写出计算逻辑。比如把列名写成"行小计（数量 × 单价）"，AI 在读取文档时会先提取数量与单价，然后自动执行乘法，最终输出的"行小计"列里就是算好的结果——不需要你在 Excel 里额外操作。
计算列常用写法示例
| 场景 | 列名写法 |
|---|---|
| 行小计 | 行小计（数量 × 单价） |
| 不含税金额（发票只印了含税价） | 不含税金额（价税合计 ÷ (1+税率)） |
| 税额验算（核对发票税额是否正确） | 税额验算（金额 × 税率） |
| 差值（核对账单与实际） | 差额（账单金额 − 实际应付） |
需要更复杂的计算（多步推导、条件判断）时，可以在简录AI登录后使用 Rule Format——列名保持简洁，把计算逻辑写在一个 JSON 规则里。但对于新手入门来说，列名内嵌算式已经覆盖了 80% 以上的计算需求。
推断列：文档上没有，但 AI 能判断
另一种"文档上没有但你需要"的数据是分类或判断。比如你收到一批收据，需要按费用类型（餐饮/交通/办公/其他）归类。收据上没有"Category"这个字段——但 AI 可以看懂收据内容：餐厅名称 + 食品品类 → "餐饮"；加油站名称 + 升数 × 单价 → "交通"。
做法是把分类选项写进列名："费用类别（选项：餐饮/交通/办公/其他）"。AI 读取每张收据的内容，根据语义判断归属类别并填入对应行。这本质上是用自然语言告诉 AI 一套分类规则——不需要训练模型、不需要编写代码。
一句话总结：三类列，一层比一层深
直接提取——文档上写了什么，我拿什么（"发票号码"）。计算列——文档上有 A 和 B，你帮我算出 C（"行小计（数量 × 单价）"）。推断列——文档上没写，但你能从内容中判断出来（"费用类别（选项：餐饮/交通/办公）"）。从提取到计算到分类，一表完成。
这三类列可以在同一个批次中混合使用——你既可以让 AI 提取发票号码（直接提取），同步算出不含税金额（计算列），同时判断这笔费用归哪个部门（推断列）。处理完上传的 20 张发票后，你得到的不只是"发票上写了什么"，而是直接可以入账的完整数据。如果你对计算列的更高级用法感兴趣，可以阅读关于自定义列提取的完整操作指南——里面包含了计算列 Rule Format 的详细用法和更多实操场景。
设计你的第一个提取模板：三条入门心法
把上面所有内容浓缩成你动手前可以记住的三条原则：
从核心字段开始，不是全部字段
第一次设计，只列 5 到 8 个你最确定需要的列。每批文档都有的——发票号码、日期、金额——这些是核心；"开户行账号"这类偶尔需要的边缘字段，晚点再加也不迟。5-12 个聚焦的列比一份 30 列的清单产生更好的提取效果——因为 AI 可以对每个字段给予更集中的注意力。
列名说人话，不是写代码
AI 理解的是自然语言语义。你不需要遵循编程命名规范——不要用驼峰式（invoiceDate），也不用写下划线（total_amount）。就用中文自然表达："开票日期""订单总金额""供应商名称"——就像你在跟一位同事描述你需要在表格里看到什么。你写什么，最终 Excel 的表头就是什么。
先试一张，再批量处理
上传一张典型的文档，用你设计好的列名跑一次。检查提取结果——有没有漏掉的字段？有没有列名写得太模糊导致 AI 拿错值？有没有该拆成两列的挤在一列里了？调整列名后，再上传一批。5 分钟的试跑成本，换来的是后续批量处理时的一致准确。
这三条心法的共同指向是同一个认知：自定义列提取的精髓不是操作熟练度，是列名设计的思虑周全。这和免模板的文档提取思路一脉相承——不依赖固定版式，靠语义理解。你在这方面投入的前期思考，会在每次重复使用同一个模板时持续产生回报。一旦为一类文档（发票、采购订单、收据）设计出一套好用的列名，就可以保存为模板——下次只需加载模板即可，不需要重新设计。把字段设计跟传统全页识别对比来看，更能理解为什么"定义输出"这个范式的转变如此关键。
常见问题
如果某个列在文档中不存在，输出会怎样？
该单元格留空。比如你定义了"税额"列，但某张发票是免税的——对应行的"税额"列就为空。这不会导致整行数据丢失，也不会让列结构变形。电子表格的结构保持一致——所有行有相同的列——只有 AI 在文档中找到对应值时才填入。这是设计多类文档混合批次时的一个重要特性。
我可以在一个批次里混合发票、收据、采购订单吗？
技术上可以，但不建议。如果混在一起，列名需要设计得足够通用——比如"单据编号"（而非"发票号码"或"采购单号"），"金额"（而非"价税合计"或"订单总金额"）。通用的列名比专用的列名更容易引起歧义。为获得最佳效果，建议将同类文档放在一个批次处理——同类文档的列定义可以写得更精准，输出也更整洁。
计算列的算法写错了会怎样？AI 能识别我的计算错误吗？
AI 会忠实执行你写的计算逻辑——但它不会校验公式本身的正确性。如果你把"行小计（数量 + 单价）"写成了加法，AI 就会返回加法的结果。计算列的正确性取决于你的公式设计。建议先用一张文档试跑，核对计算结果后再批量使用——这和 Excel 里的公式验证逻辑是一样的。
每个批次最多能定义多少列？
没有硬性限制。但经验上，15-20 列以内提取结果最可靠。超过这个数量，你开始覆盖一些不是每份文档都有的边缘字段。如果确实需要很多字段，可以考虑分两批处理：第一批提取核心字段，第二批补充边缘字段——这样每批的列都保持聚焦，提取质量也更高。
AI 提取不准时，我应该改列名还是换文档？
先改列名。大多数"提取不准"的问题是列名设计问题，而非 AI 能力问题。"日期"在一张有五个日期的发票上，AI 无法确定你要哪个——把列名改成"开票日期（YYYY-MM-DD）"通常就能解决。如果列名已经足够精确但结果仍有偏差（如低分辨率照片中的小字识别错误），此时才是文档质量的问题。关于精度提升的系统讨论，可以参考自定义列提取与全页识别的精度对比。
从"我该提取什么"到"我还能让 AI 算什么"
读到这里，你脑子里的自定义字段提取应该不再是"一个需要填列名的输入框"。它是一套思维框架：直接提取拿到文档上的数据，计算列算出文档上不直接显示的值，推断列让 AI 替你分类和判断。三层叠加，一次处理，一张表出结果。
设计第一个提取模板不需要完美。你需要的只是五到八个对你有意义的列名，加上"先试一张再批量"的节奏。发现列名太模糊就改具体一点，发现有字段漏了就加一列——这个过程本身就是在建立你对"AI 能理解什么"的直觉。下次你打开简录AI时，不再会对着"输入列名"四个字发呆——你知道你是在定义输出，而 AI 负责理解输入。