作者：枰先森
企业导入AI落地应用，通常会关注功能是否可用、流程能否运行。对我而言，验收还要回答一个更长远的问题：当客户要求或内部资料改变，企业自己的团队能否继续调整这项应用？
近期的沙龙与共创，让我更希望在下一次交流中听到具体反馈：某个办法回去试过了，哪里有效，哪里还需要商量。企业能力正是在这些使用和修正中逐渐积累。
业务骨干从首个试点参与
业务骨干知道一项判断为什么成立，也了解例外情况。如果一直等到系统完成后才参加培训，这部分经验很容易留在交付之外。
我更倾向于在首个试点中，让业务人员讲清判断依据，工程人员接入AI能够承担的部分，再拿实际结果共同核对。发现问题、明确由谁修正、确认修改是否有效，都应成为团队参与的过程。
以客户资料整理为讨论场景，AI辅助提取需求与待确认事项，业务人员核对原始记录，涉及商务承诺的内容仍由授权负责人决定。这类分工需要进入验收记录，不能只存在于口头交代中。
把三类接手能力纳入验收
第一类是解释。接手同事能够找到结果依据，知道哪部分来自业务资料，哪部分仍需人工确认。
第二类是调整。客户要求、产品资料或内部规则变化时，团队知道信息由谁维护、哪些修改需要工程支持，以及何时暂停使用不确定的结果。
第三类是核对。修改完成后，团队会用正常记录和异常记录检查，并保留问题、处理人和复核结论，避免只确认页面能够打开。
这些动作可以在一个具体试点里演示，不必等到全面推广以后再补。验收所用的记录应在授权范围内，涉及客户隐私的内容先做必要处理。
为持续使用安排清楚的分工
在尚易至尚科技集团的业务讨论中，FDE工程师重在应用交付与技术处理，FDC教练重在教会企业使用、核对和持续改进。这里的FDE、FDC表达的是我们的协作分工。
业务负责人对业务要求作判断，工程人员负责技术实现，教练协助团队掌握接手方法。三者配合，才能让“应用已交付”和“企业会继续用”各自有可检查的依据。
骨干参与需要时间，企业可以在立项时就把这项投入安排进去。我愿意把它看作下一项应用的准备：团队知道如何提出问题、验证结果，再讨论扩大范围时，就有了自己的经验。
项目结束后，企业留下的不只是交付文件，还应包括明确的维护责任、复核方式和遇到异常时的处理路径。