漂亮的表格可能掩盖了缺失
销售把客户需求交给 AI 整理，输出表格每一格都填满了，看起来很省心。但客户没有说部署数量，系统却补了一个零；没有问上线日期，系统写成“暂无计划”。这两种补全都在替客户作判断。字段格式没有报错，业务含义却已经改变，后续分流、报价或跟进可能因此走到错误分支。
我们用这个假设场景讨论一个交付细节：缺失也是信息。企业 AI 不应为了让结果显得完整而消灭未知状态。零表示已经知道数值为零，未知表示还没有答案，不适用表示这个问题对当前对象不成立，提取失败则表示资料可能有答案但系统没读出来。几者需要不同的后续动作，不能只用一个空白单元格承载。
先让业务人员解释每种空白
拿几个常用字段逐个问：未填写会影响什么，能不能稍后补，谁有权确认，系统是否已有旧值。对意向数量，可能允许先生成需求草稿；对执行所需的目标对象，缺失就应该停止动作。规则取决于业务，不应由开发为了方便接口校验统一设置默认值，也不能让提示词作者一个人决定所有缺失的含义。
可以先选少量明确状态，例如已确认、未提供、待确认、不适用和提取异常，避免设计一长串员工分不清的标签。每个状态都配一个例子和一个处理动作。一个字段可以同时保存值和状态，显示给员工时再转成自然语言。这样既便于系统判断，也方便业务人员看出为什么需要补资料。
提取时保留证据位置
如果输入资料里出现“暂时没定”，就保存为待确认，不要变成没有需求。如果写着“本次不包含培训”，可以按已确认的范围处理，但仍应保留对应原句或定位信息。证据不需要在每个界面都展示出来，却应该在复核时找得到。资料存在矛盾时，指出冲突比猜一个平均值更有用。
补问也要有针对性。不要因为一个字段缺失就让客户重填整张表，可以问“本次预计覆盖多少个使用席位，若未确定可先标待确认”。问题本身不能暗示客户必须给出精确数字。对于材料提取失败，先检查源文件是否可读，再决定是否找客户，避免把技术故障伪装成客户没有提供信息。
写回接口要区分三种动作
许多事故发生在生成结果进入旧系统时。字段没有出现在本次输出里，通常意味着本次未处理它；明确清空一个旧值，是另一种操作；写入零，又是第三种操作。具体接口可能有不同约定，交付团队必须检查文档和测试结果，不能凭习惯认定空字符串、空值和缺少字段总有同样效果。
假设客户原有地址已经核实，本轮只补充需求类别，AI 输出里地址为空。若把整条对象覆盖写回，原地址可能被清掉。更稳妥的设计是只提交已确认需要变更的字段，并把清空操作单独列出供核对。执行前展示“修改什么、保持什么、清空什么”，员工就不用在一大段 JSON 里找风险。 字段更新的规则还应覆盖导出和报表。上游已经区分未知与零，下游导出表格时若又把空值统一填零，前面的保护就失效了。检查范围要沿着数据经过的路径走到实际使用处，包括分流条件、统计表和员工查看的任务列表。不要只验收模型返回的那一段结果，然后默认其他系统会保留同样含义。
举例说，统计平均需求量时，未知数量是否进入分母，需要业务定义；不能一边把未知当零，一边把得出的低平均值解释为客户需求变小。这里不需要新增复杂分析模型，只要记录统计口径，并让计算遵循它。处理不适用状态时也一样，应先问这个字段对该对象有没有意义，再决定如何展示和计算。状态设计的价值，最终要体现在员工据此作出的判断没有被数据转换误导。
默认值只能在有规则的地方使用
默认值并非永远错误，错误在于没有区分业务约定与事实推断。比如内部流程可以规定未选优先级时按普通任务排队，这属于系统规则；但不能据此认定客户不着急。字段里应能追溯该值来自用户输入、系统默认还是人工确认。后续分析时也要知道这些来源不同，不能把默认结果当成客户真实反馈。
如果默认值会触发外部动作，尤其需要在规则制定阶段确认边界。对无法恢复的修改，缺失信息应先补齐或交人工判断。界面可以明确标出“按默认规则”，让员工有机会改正，而不是用与客户确认值完全相同的样式呈现。少一次误导，比多填满几个格子更有价值。
测试用例要覆盖状态转换
除了正常数字，还应测试零、空字符串、缺少字段、不适用、文本里的“尚未决定”，以及前后资料冲突。然后模拟从待确认变成已确认、从已有值变成明确清空，看每一步是否经过正确授权和记录。测试数据可以虚构，但应明确用于验收，不能拿真实客户隐私做演示材料。
验收时让业务人员看实际页面，判断他能否分清“真的没有”和“目前不知道”；让技术人员检查写回后旧字段是否被保护。最终交付的不只是字段列表，还包括状态含义、补问负责人、更新规则和异常样例。系统如果能诚实保留未知，并把它交给合适的人解决，往往比把所有空格填满更接近可靠的企业 AI。
要点总结
- 不需要。优先处理会影响分流、执行或覆盖旧数据的字段，状态数量以业务人员能区分为准。
- 因为零本身是确定的业务数值，会影响计算和判断；未知应使用独立状态表达。
- 不能据此推断清空意图。应按接口契约保留未修改字段，明确清空需要独立的业务依据。
参考来源说明
本文为业务方法讨论，文中场景为说明用例。下列官方技术资料用于核对相应机制，站内服务页用于了解相关业务；不作为客户案例或效果数据的证明。