企业 AI 提取询价邮件，怎样保留原文、字段和待核实项？

一封询价邮件不等于一组已经确认的字段

来信可能把型号写在主题，把数量放在附件表格，把使用环境藏在一段说明里，还可能把“计划采购”写成“已经确定采购”。如果 AI 直接把这些片段变成一条完整记录，下游接收者容易看见整理后的表格，却不知道哪些值来自原文、哪些是系统推断、哪些仍要问客户。设计流程时，先约定“提取”只负责整理材料，不替销售确认需求或代表企业回复客户。

可以把每个拟提取字段分成四部分：标准字段名、原文值、证据位置、当前状态。证据位置可以是邮件正文引用、附件文件名与页码、表格工作表和单元格范围，或原始段落编号。状态可以标为“原文明确”“存在多个候选”“缺失”“格式待统一”“人工已确认”。具体标签由团队选择，但应能区分原文信息和模型补全。

以采购询价为例，联系人、企业名、产品型号、数量、使用场景、目标市场和期望时间可能是团队希望了解的信息；实际任务只需要其中一部分。先让业务负责人确认字段表，别为了“提取完整”把邮件里所有个人和商业信息全部复制进系统。每个字段都要能回答两个问题：它会影响什么下一步判断？谁有权确认？

先确定字段含义和边界

字段名看似清楚，团队解释可能不同。“数量”可能是每批数量、年度预计量、样品数量或多个型号的合计；“交期”可能指期望到货、要求出货或待确认计划。不要让模型通过上下文猜字段定义。把业务词写成短定义，说明单位、时间范围、允许的格式，以及多个数值出现时如何保留。

还应区分“原文表达”和“规范化值”。原文写“约两百套”，AI 不应悄悄改为精确数字 200。可在原文字段保留“约两百套”，另将待统一的数量标成“需确认”，由负责人员决定是否转换。若原文写“下季度”，不要自动把它换成某个日历日期，除非上下文、时区和相对日期基准都已核实。

对表格、扫描件或不同语言附件，保留来源标识与字段映射。产品型号可能只出现在列标题，数量单位在页脚，附件版本又可能不一致。团队要先确定文件是否有权交给当前模型服务处理、附件是否可能含机密信息、使用的系统是否符合企业批准的数据流程。文章不假设任何特定 AI 工具、存储能力或连接器已在企业启用。

让“缺少”和“含糊”有不同出口

字段为空可能有几种原因：材料里没提、附件读取失败、原文含糊，或材料互相矛盾。把这些都填成空字符串会丢失处理线索；把它们都替换成模型猜测则制造确定性。为几类情况设置不同状态，并指定下游怎么处理。

“未提及”表示当前材料没有给出；“未能提取”表示系统没有可靠读到；“存在歧义”表示原文有多个解释；“冲突”表示两个来源给出不同值；“不适用”表示经过任务规则判断字段无需填写。只有“人工已确认”才能表示有人核过并愿意对该值负责。模型给的置信分数即使可用，也不等于业务负责人确认。

遇到歧义，系统应该保留多个候选及来源，而不是只留一个看起来合理的答案。例如正文写“一批 500 件”，附件却列出五个型号各 100 件，记录可以同时保存总量和明细，标注两者需要确认是否对应同一项需求。若材料提到不同日期，先记录各自的语境，不要只依据时间新旧自动覆盖旧值；新文件可能只是报价参考而不是客户最新决定。

让人工复核者能快速回到证据

复核界面或任务卡应并排展示 AI 提取结果、原文片段、来源位置和不确定状态。不要只把全部提取值汇成一行，让销售人员通过打开多个文件反向寻找。先挑选会影响选型、库存、报价或交付判断的字段让负责人核验；低风险字段可以按企业既有流程处理，但每个字段的跳过条件要明确。

校验人员应能做三种操作：确认值和单位；修正提取并记录依据；把字段退回“待客户澄清”。如果没有证据或业务权限，不应强迫复核者选择某个模型候选。没有确认的值不应伪装成正式业务字段。将“模型整理”“人工校正”“客户确认”分别标注，避免后续使用者将它们混为一谈。

对于附件中的关键字段，可以提供源文件定位并记录所用版本。若业务流程没有稳定页码或单元格标识，可先保存经过批准的短摘录和文件识别信息；但要遵守企业的数据保留规则，避免把整封邮件或完整敏感附件无限复制。缺少适当的访问控制和删除规则时，先缩小处理范围，不要把风险留给最终复核者。

设计人工接手条件

在流程图里标清什么时候继续、什么时候暂停、什么时候询问客户。可暂停的条件包括：型号无法识别、附件版本冲突、数量单位缺失、关键字段只能推断、文件类型不受支持、或材料权限不清楚。判断条件越具体，业务同事越容易把问题分到销售、产品、技术或资料管理员。

澄清问题应直接对应一个未决字段，并避免把已提交的信息再问一次。例如缺少产品型号时，问题可以询问需要评估的型号或系列；若时间表达含糊，则确认对方所指的阶段和日期范围。提问者仍须根据企业真实客户沟通流程编辑内容，不可让模型直接代发未审信息。

如果 AI 结果准备进一步进入 CRM 或工单，先在业务确认步骤后再交给既定写入流程。提取、确认、创建记录和发送回复是不同动作，应分别定义权限和责任人。不能因 JSON 格式通过校验，就推定字段真实、授权充分或客户已作决定。NIST 的生成式 AI 风险框架也可作为团队审视输出可靠性、隐私和人工治理的参考，而不是某个系统的质量背书。

用代表性样本验收提取任务

正式使用前，准备一组经授权且去标识化的真实格式样本，或明确标为合成的测试材料。样本要覆盖短邮件、多附件、扫描件、表格、不完整请求、多个型号、单位混合、不同语言、旧版本与冲突字段。若只有最整洁的一封邮件，无法判断工作流遇到复杂输入时会怎样处理。

为每个字段准备参考答案及来源位置，由熟悉业务的人独立校对。验收时分别观察：字段是否提取正确、原文证据是否可定位、未知状态是否被保留、冲突是否触发接手、下游是否只接收到获准字段、以及人工能否及时纠正。不是每一种任务都需要相同的抽样方法或数值门槛，具体阈值由团队按误判后果和任务量确定。

每次任务变化都记录版本：输入材料类型、提示与字段规则、模型或服务版本、提取输出、人工修改、异常类型和最终处理。只保留完成复盘所需的信息，并遵守企业数据管理政策。若更换附件解析器、增加字段或调整单位转换方式，挑选受影响的样本重新测试。单次通过不代表所有后续请求都能准确完成，也不应写成稳定效果保证。

发布或上线前检查

如果这些问题没有明确答案，先缩小任务：比如只提取一个已经定义清楚的字段集，并要求人工确认后进入下一步。只在流程证据足够时扩大自动化范围。提取工作流的价值，是让资料梳理更有结构、问题更容易发现；它不会替企业确认客户意图，也不会替销售承担最终业务判断。