AI 接入表格前，先立好这份“字段契约”：五道防线挡住批量错误

销售团队把线索表接入 AI，希望自动判断客户等级、生成跟进建议。

流程跑起来后，结果却让人摸不着头脑：业务员填写的预算“10”，原本代表 10 万元，AI 却按 10 元理解，将本应优先跟进的客户判成了低价值线索；“10 万”“100000”“约十万”也被识别成不同量级。遇到空白字段时，AI 甚至自行补出一套看似合理的客户需求。

问题未必出在模型不够聪明。

真正的原因是：这张表从来没有告诉 AI，“10”的单位是什么、空白代表什么、哪些状态可以填写，以及结论必须依据哪些信息。

人看表格时，会借助上下文“脑补”；自动化流程却不会。只要一个含糊字段进入批处理，原本偶发的小问题，就可能沿着工作流一路复制。

把 AI 接入表格，第一步不是写提示词，而是为关键字段建立一份可执行的“字段契约”。

这份契约至少应包含五类约束：类型、范围、缺失、来源和复核。它们分别解决五个问题：能不能正确读取、数据是否合理、不知道时怎么办、结论依据是什么，以及出错后由谁负责。

---

一、为什么 AI 一接进表格，小问题就会变成批量事故

传统表格的很多“灵活”，其实建立在人的默契之上。

例如同一列“预计预算”中，可能同时出现：

• 10
• 10万
• 100000
• 约十万
• 空白

业务员知道这些值大致是什么意思，但对于自动化程序来说，它们分别可能是数字、文本、模糊表达和空值。

再看“客户状态”：

• 已成交
• 成交了
• done
• 已签
• 完成

人可以判断它们含义接近，程序却很难确定这些值是否完全等价。更麻烦的是，后续筛选、统计和 AI 分类都会基于这些不稳定的输入继续运行。

这就是为什么“接入 AI 前清洗一次数据”还不够。

一次性清洗解决的是历史问题，字段契约解决的是未来每一条数据如何进入系统。它不仅规定单元格怎么填，还要能被表格验证规则、脚本或工作流真正执行。

以销售线索表为例，一份最小字段契约可以这样设计：

这张表看似多了几列，实际上是在提前回答：AI 能读什么、能判断什么、不能猜什么。

---

二、先管住输入：类型约束与范围约束

1. 类型不只是“文本、数字、日期”

很多表格把数据类型简单分成文本、数字和日期，但业务中的“类型”要具体得多。

例如：

• 客户状态是枚举
• 是否已授权联系是布尔值
• 客户标签是数组
• 预计预算是带单位的货币
• 官网地址是URL
• 联系电话是有格式要求的手机号
• 首次联系时间是带时区的日期时间

如果“客户状态”允许自由输入，就会同时出现“已成交”“成交了”和“done”。更稳妥的方式，是把它限制为固定选项：

金额字段也不能只规定“填写数字”，还要明确：

• 单位是元还是万元；
• 是否允许小数；
• 是否允许负数；
• “约十万”应转换为数值，还是保存为备注；
• 未知预算究竟填空白、null，还是 unknown。

2. 范围约束负责拦住“格式正确但业务错误”的值

一个单元格即使是数字，也不代表它合理。

例如：

• 客户评分必须在 0—100 之间；
• 折扣比例不能超过 100%；
• 预计成交日期不能早于首次联系日期；
• 客户名称不能只有一个字符；
• 已经标记为“成交”的客户，不应重新跳回“新线索”。

这里既有单字段规则，也有跨字段逻辑。

读者可以先用公式建立最简单的校验列。检查预算是否为合法的非负数字：

=IF(B2="","待补充",IF(AND(ISNUMBER(B2),B2>=0),"通过","格式错误"))

检查预计成交日期是否早于首次联系日期：

=IF(OR(C2="",D2=""),"待补充",IF(D2>=C2,"通过","日期冲突"))

不同表格产品的函数名称、日期处理方式和参数分隔符可能略有区别，使用前应根据 Excel、WPS 或在线表格的实际语法调整。

规则还要区分两种强度：

• 硬拦截：状态不在枚举中、金额为负数、日期逻辑冲突，不允许进入 AI 流程。
• 软提醒：预算异常偏高、文本过短、预计成交日期较远，可以保存，但标记为待确认。

如果所有异常都硬拦截，团队很快会觉得系统“难用”；如果全部只是提醒，规则又会形同虚设。判断标准很简单：会直接破坏机器理解的数据硬拦截，可能合理但值得关注的数据软提醒。

截图 1：接入前的脏表格

使用虚构客户信息，展示“10”“10万”“约十万”等预算格式，以及混乱的日期、状态和含义不明的空白。

截图 2：数据验证设置

展示客户状态枚举下拉、预算非负数字验证，以及预计成交日期不得早于首次联系日期的规则。

---

三、不要让 AI 猜：缺失约束与来源约束

1. 空白并不只有一种含义

表格里最危险的内容，有时不是错误值，而是什么都没填。

同一个空单元格，可能表示：

• 尚未填写；
• 暂时无法获取；
• 对当前客户不适用；
• 等待同事补充；
• 数据采集失败；
• 真实值为零。

如果这些情况全部用空白表示，AI 就无法判断该继续分析、退回补充，还是把它当成零。

更可靠的设计是，将“值”和“状态”分开保存。例如预算字段可以配套一个预算状态：

• known：已知，读取预算数值；
• unknown：客户尚未透露；
• pending：等待补充；
• not_applicable：不适用。

关键字段还应设置不同的必填级别：

1. 强制必填：客户名称、客户状态，没有就不调用 AI。

2. 条件必填：客户状态为“已报价”时，报价金额必须存在。

3. 允许缺失：预计成交日期可以为空，但 AI 必须返回“需补充”。

4. 禁止猜测：没有预算和沟通记录时，不得强行生成 A/B/C 等级。

提示词只能告诉模型“不要猜”，字段契约则可以让流程在缺失数据时直接停止或分流。后者更可靠。

2. 每个 AI 结论都要能回到原始记录

假设 AI 把某客户判定为 A 类，销售经理首先会问：“依据是什么？”

如果表里只保存了“A 类”三个字，而没有记录输入来源，那么团队很难判断问题究竟发生在哪里：

• 业务员录入错误；
• CRM 同步失败；
• 文件提取错位；
• 字段转换丢失单位；
• AI 推理存在偏差；
• 提示词或规则版本发生变化。

因此，进入 AI 流程的关键数据至少应保存：

• 原始内容或记录链接；
• 来源类型：人工、CRM、文件或 AI；
• 采集或更新时间；
• 字段转换方式；
• 使用的模型、提示词或规则版本。

来源约束不是为了“多留日志”，而是为了让异常能够定位。

一条成熟的 AI 输出，不应只写“客户等级：A”，而应同时记录：

• lead_grade
• confidence
• evidence_fields
• missing_fields
• source
• review_required

没有依据的结论，即使听起来正确，也不适合直接进入业务系统。

---

四、给 AI 输出加一道闸：复核约束怎么设计

复核不是在表格末尾增加一个“已检查”复选框。

真正有效的复核规则，要明确哪些记录必须进入人工队列。销售线索场景中，可以按照以下条件分流：

• 高价值客户必须复核；
• AI 返回低置信度时必须复核；
• 预算、需求或联系方式等关键字段缺失时必须复核；
• 客户等级为 A 时由负责人确认；
• 涉及报价、合同、付款等操作时禁止自动执行；
• AI 判断与已有 CRM 状态冲突时退回检查。

金额和置信度阈值应根据业务风险自行设置，不应机械照搬别人的数字。

一套最小复核闭环，需要同时记录：

人工修改记录还有一个经常被低估的价值：它能帮助团队发现系统性问题。

如果复核人员不断把“预算未知”的客户从 B 类改为“信息不足”，问题可能不是某一次模型失误，而是字段缺失策略没有执行。如果“已报价”客户频繁被误判为新线索，则可能是状态映射或提示词定义有问题。

复核不是替 AI 擦屁股，而是在持续检查字段定义、流程规则和模型选择是否合理。

截图 3：AI 回写后的结构化字段

将客户等级、置信度、判断依据、来源、缺失字段和复核状态分列保存，避免把所有内容塞进一段自然语言。

截图 4：人工复核视图

只筛选低置信度、高金额或关键字段缺失的记录，避免人工重新阅读整张表。

---

五、把五类约束变成一条可运行的表格流程

完整流程可以收束为：

原始数据进入表格
↓
类型与范围校验
↓
缺失项识别和分流
↓
携带来源信息调用 AI
↓
结构化结果回写
↓
按风险规则分流
↓
人工复核或进入下游系统

这五类错误对应的成本也非常直观：

1. 小白路径：先用表格自带功能

不需要一开始就搭建复杂系统，可以先做四件事：

1. 用下拉选项限制枚举字段；

2. 用数据验证限制数字和日期；

3. 用公式生成“通过、待补充、格式错误”等校验状态；

4. 用条件格式标红异常记录，并建立“待复核”筛选视图。

先选一张真实业务表，再圈出 5—10 个真正进入 AI 请求或影响业务决策的字段。用 10 行脱敏数据跑通流程，比直接改造整张表更稳妥。

2. 进阶路径：使用 JSON Schema 统一校验

当表格要接入 API、脚本或自动化工作流时，可以在调用 AI 前使用 JSON Schema 约束输入：

{
"type": "object",
"required": ["customer_name", "customer_status"],
"properties": {
"customer_name": {
"type": "string",
"minLength": 2,
"maxLength": 100
},
"budget_yuan": {
"type": ["number", "null"],
"minimum": 0
},
"customer_status": {
"type": "string",
"enum": ["new", "contacting", "quoted", "won", "lost"]
},
"source": {
"type": "object",
"required": ["source_type", "updated_at"],
"properties": {
"source_type": {
"enum": ["manual", "crm", "file", "ai"]
},
"updated_at": {
"type": "string",
"format": "date-time"
}
}
}
}
}

模型输出也不要直接回写一段自然语言，而应要求返回可校验字段：

{
"lead_grade": "A",
"confidence": 0.86,
"evidence_fields": [
"budget_yuan",
"customer_status",
"latest_contact_note"
],
"missing_fields": [],
"review_required": true,
"review_reason": "高价值客户，需要人工确认"
}

这里的 0.86 只是格式示例，不代表模型已经达到某种可验证的正确率。置信度可以参与分流，但不能替代人工复核和实际评测。

---

接入 AI 前，先复制这份五类约束检查表

为每一个关键字段回答以下问题：

• 字段名称和业务含义是什么？
• 接受什么数据类型和格式？
• 单位是什么，是否允许自动换算？
• 合法范围或枚举值是什么？
• 能否为空？为空时具体代表什么？
• 数据来自哪里？能否回到原始记录？
• AI 能否读取、生成或修改该字段？
• 什么情况下必须人工复核？
• 复核结果和修改原因保存在哪里？
• 校验失败后是拦截、提醒，还是进入补充队列？

不要试图一次治理整张表。

今天就选一张表，找出最关键的 5—10 个字段，补齐类型、范围、缺失、来源和复核规则，再拿 10 行脱敏数据测试一次。确认输入校验、结构化输出和人工复核都能闭环后，再逐步扩大自动化范围。

当字段契约定义完成后，可以通过 api.884819.xyz 测试不同模型的结构化调用效果，重点观察三件事：

1. 是否稳定返回指定字段；

2. 信息不足时是否拒绝猜测；

3. 异常结果是否能够进入人工复核队列。

8848AI 平台使用用户名和密码即可注册，不需要邮箱验证；平台内置 AI 对话功能，注册后可以直接使用。国产模型如 Deepseek、千问等完全免费，其他模型没有月租和订阅，采用按量付费方式。

AI 流程的可靠性，不是从模型回答开始，而是从第一个单元格的定义开始。

字段约束解决了“喂给 AI 的数据是否可靠”，但下一步还有一个更容易被忽略的问题：怎样要求 AI 只返回表格能够接收的结构，而不是一段格式飘忽的自然语言？

下一篇，我们将继续拆解结构化输出、JSON Schema、失败重试与异常回写，做一套可以直接用于 Excel、飞书多维表格和自动化工作流的 AI 输出模板。

#AI教程 #表格自动化 #数据治理 #结构化输出 #人工智能 #JSONSchema #8848AI #Prompt技巧